This is a first stab at hacking together a UR/map problems layer for the Waze livemap view. This version is intended for users to test the core functionality required in such a layer - namely the ability for a third-party script to retrieve UR/problem data from the Waze server when no such data is already present on the page, and to then display it somehow over the existing map view.
After installation, you should see a new checkbox at the bottom of the Live Map window, titled “Update Requests”. Tick this box to activate the script. Once active, the script monitors for any movement/zooming of the live map view, and requests the current UR/problem data from the Waze server for the area being viewed. The locations of any received URs are then plotted on the map as a small red/blue box (map problems are not plotted at present).
The Waze servers will not return any data for an area wider or taller than 1 degree of lat/lon, so if the livemap is zoomed out too far the script will only retrieve data for the central area. The area in which data is being requested should show up as a translucent yellow box.
Note that the Waze server will only return data if there is a logged-in user, and the data returned is filtered according to the editable areas assigned to that user - this script cannot display ALL the URs/problems in a given area, ONLY those that the logged-in user would be able to edit.
Due to a combination of the additional effort required to generate web store release packages, plus the increasingly overbearing control-freak behaviour exhibited by Google with regards their policing of web store content, I no longer maintain or support the web store versions of this script, and users should migrate to the Userscript version in order to continue receiving updates.
A few improvements for the 0.2 proof of concept release
should now work on the NA server as well as the world one
prompts users to log-in if they aren’t already
now shows map problems as green dots
Note - the script will only be activated if you are using the secure live map server - if you do not see the checkbox at the bottom of the live map window, you’re probably on the non-secure server…
I was positively surprised that you’ve indeed tunneled the UR data through
I have even found one fresh generated Map Problem - not seen for ages
Works really nicely for a proof of concept!
V0.3 now shows the users managed and editable areas - since the UR and problem data is only returned within these areas, displaying them on the livemap makes it clearer whether or not an area is genuinely devoid of problems or simply appears so because you don’t have editing rights there…
BUG: Now I get more frequently the error message “Could not possible to connect to the UR server”.
Suggestion: It would be great if you could add a link to each red square so we could easily open the UR in the editor (something like the already existing UR in the editor)
Thanks for the bug report, 0.4 should now have solved that problem… In fixing that error, I’ve also resolved the problem where the editable area would appear and disappear if you were panning across certain parts of the map at certain zoom levels.
Linking the UR/problem markers to WME is my long-term intention for this script, but I don’t want to rush into this until I’m happy that the foundations of the code are OK, hence all of these proof of concept versions.
With the international editor out of action, I decided to dust off the LMUR source and do some long overdue updates…
0.5 fixes a data retrieval glitch which exhibited itself in the northern reaches of the UK (and would most likely also appear in other parts of the world too), it moves the script info/activation checkbox up to the top of the livemap view, and, saving the best till last, it now features overview popups for the UR and problem markers.
Note that, unlike the popups in my UROverview script, these ones are (for the moment at least) just for information - there’s no links to open WME at the UR/problem location etc.
I do not see the the overview popups for URs+MPs on INTL server - because of the shut down WME?
Never mind. The script uses a vertical yellow rectangle, sized approx. 70 x 100 km, as a looking glass for the markers. Is there any specific reason to make it vertical (if not already a square), like an API constraint? A horizontal orientation would suit more…
The Extended Tools for Papyrus and one more Timbones’ script contain (or contained) code for maximizing the usable area by (at least) hiding the upper black Waze banner and navigation bar. Could you try to bind such change (hide the “body_bg.png”, “content_wrapper”/“navigation” and “content_wrapper”/“navigation_bottom_wrapper” in order to vertically enlarge the LiveMap’s “map_container” area) on the “Show URs/map checkbox problems” state?
No, the script has been working OK for me all throughout the shutdown. If the red/green markers have been placed on the livemap, then the script has all the information it needs to generate the popups, so there must be some other reason why they’re not appearing. Do you see any errors in the javascript console?
When requesting the UR/problem data from the Waze server, the largest area you can ask for in a single request is 1 degree * 1 degree, and so this is what the script currently requests each time you move/zoom the map. The reason this 1*1 area appears to be rectangular rather than square is due to the projection method used to generate the live map - the further north or south you move from the equator, the more the projection vertically stretches the map. If you view the livemap near the equator, you should see the script bounding box appears to be a square, and as you then pan north or south, you’ll see it slowly elongating into the portrait-oriented rectangle more familiar to users in non-equatorial regions…
One of the things I’ll be looking into for future versions of the script is a more intelligent data request process, so that the script doesn’t ask for more data than necessary if you’re zoomed right into the map, and also so that it can request multiple blocks of data to cover more of the map when you’re zoomed further out.
0.6 resolves what I suspect was a long-standing problem which would incorrecly trigger the “unable to access…” handler if the server returned partial data for any other users in addition to the data expected for the logged-in user.
The LiveMap UR Layer overlay seems to break the functionality of the ‘Get Directions’ shortcut on the top left. Once it is enabled, clicking this link does nothing, where it would normally display a “From:” and “To:” text entry boxes to enter Navigation start and end points, in place of the normal “Search Address” textbox.
Clicking on livemap & setting a start end end still works and calculates the routes, but it also does not toggle the search textbox like it usually does.