Bloody Chrome... I've been working towards making the script event driven rather than polled, so in 1.8 the autotracking reloads got moved into the mousemove event handler. This seems to force Chrome into refocusing onto the reloaded tab instead of maintaining its focus on the current tab as it does when you reload outside of the event handler, but I hadn't noticed this in testing as I run WME in one window on one screen and Opendata or Musical Chairs in a second window on another screen, so the switch in focus is easy to overlook...

1.9 now moves the reload back to where it was prior to 1.8, so Chrome now behaves itself again. It also adds a minimise/maximise arrow to the dragbar, allowing the window to be rolled up leaving just the dragbar.

http://userscripts.org/scripts/show/137249

leocylau wrote:Normally I click the street name and a yellow rectangle box will be displayed on the map. It's gone now

If you're using the aerial images layer, it appears WME has been recently tweaked to bump that layer up the zIndex order just enough to hide the bounding box - easy fix for the next release.

Dave2084 wrote:Can we make the floaty box remember where it is between sessions (ie when you permalink)?

OK, will do...

Having realised what a complete muppet I'd been when implementing the dragbar code (attaching the mousemove handler to the dragbar instead of the entire screen - just call me Kermit ), I've now fixed the problem of dragging suddenly stopping if the mouse pointer drifts outside the dragbar area during the move.

In other news...

*bonnnnnggg* For leocylau, the bounding box should now be visible once again in Firefox when the aerial images layer is turned on - if you're still not seeing it after applying this update, please let me know!

*bonnnnnggg* For Dave2084, the window position is saved between sessions

*bonnnnnggg* For iainhouse, the window is now shifted up if maximised at the bottom of the screen


http://userscripts.org/scripts/show/137249

Working on it...

...and we're done.

1.11 now adds a city name drop-down list below the existing manual entry text field, populated with all the city names present in the map data currently cached by the browser.

Other changes:

When selecting a new segment, if the new OS results list includes the same street name as was used in the most recent edit, this name will be pre-selected for use with the new segment. More often than not, the only times I have to do any map editing are whilst eating breakfast or lunch, or whilst rocking my daughter off to sleep - in all these scenarios, having both hands free to drive WME is then a luxury, and if I'm trying to name a multi-segment stretch of road without the ability to ctrl-select the whole thing, having to re-select the required street name each time I click on the next segment was becoming a bit of an annoyance. Sure, I could enable the multi-select option in WME, but I'm none too fond of the way that operates (all too easy to forget to hit Escape before starting a new edit...), so giving WMEOD some basic prediction capability here makes my life easier. Hopefully it'll be of some use to other users too.

When the script loads, it now performs some sanity checking on the saved window position, preventing it from being rendered completely off-screen if the saved values aren't valid for the current browser window dimensions.

An errant piece of debug code was left in 1.10, which with the recent changes to the WME beta was preventing the script from running there. In the non-beta, it was merely trashing the locality display at the top-left corner of the map display whenever the UI window was dragged.

http://userscripts.org/scripts/show/137249

Quick update to 1.12...

UI behavioural consistency fix: if a city name was previously selected from the drop-down list, and the list is then refreshed by selecting a new segment, the same city name will be pre-selected again if present.

Script behavioural consistency fix: city names selected from the drop-down list now have the same 1km rule applied to them as is applied to manually-entered names - i.e. the user needs to confirm the continued use of a name if an attempt is made to apply it to a segment >1km away from where it was last confirmed (or originally used). Just because the name is still present in the WME data at a given location doesn't necessarily mean it should still be used at that location...

http://userscripts.org/scripts/show/137249

Odd, I never had any problems with T&W area names when I did a bunch of edits up there after my last trip home a few months ago, will have a look at this later to see what's going on now... Thanks for the report.

Twister_UK wrote:Odd, I never had any problems with T&W area names when I did a bunch of edits up there after my last trip home a few months ago

What a dingbat I am, I didn't add the use existing city name option until well after I'd finished those edits...

Problem has now been fixed in 1.13, thanks again for letting me know about it!

http://userscripts.org/scripts/show/137249

Dave2084 wrote:Twister,

The URL for the beta editor is now:
*.waze.com/beta_editor/

Thanks for the reminder, I keep forgetting to update the include directives for this script...

Also in 1.14 is the first appearance of OS Gazetteer data At the moment this is just used to verify whether the city name entered in the WMEOD UI (either manually or via the "existing city name" drop-down) is first of all present in the OS data, and if so whether or not it's unique. If it is unique, but the entered name also contains a (county) suffix, it'll then also suggest that this suffix isn't necessary. Future development plans for this data include location-based suggestions for OS-derived names.

Note that the Gazetteer data I'm using has been stripped down to the bare essentials - whereas the full dataset contains listings for farms, mountains, Roman antiquities, mountains, individual dwellings and pretty much every other name you might see listed on a 1:50000 OS map, I'm only using the entries classified as city, town and other (this last one appears to cover anything smaller than a town but larger than a single building). So when it indicates that a name doesn't exist, this doesn't necessarily mean the name doesn't exist at all, just that it doesn't exist in these three classes.

http://userscripts.org/scripts/show/137249