Ahhh right I get you, so do us editors see/notice/do anything different.
Sent from my GT-I9505 using Tapatalk
Sorry about the delay in releasing the new OS data, you can thank my not so SMART system drive for thisā¦ regular monitoring of the SMART status suggested the drive was in good condition, yet delving into the Windows event log showed bad block errors being thrown left, right and centre :roll: So one emergency system drive swap out later, weāre back in business.
2.4 uses the latest OS Locator dataset, which contains a shade over 4000 additional entries compared with the previous dataset. It also fixes the Canaries Map Tracker functionality (oh look, theyāve renamed a couple of internal variables for no discernably good reasonā¦ been taking programming lessons from the Waze team, eh?). For Chrome users, Iāve tweaked the permissions a bit too so it no longer requests access to the entire internet 
Firefox+Greasemonkey version: https://greasyfork.org/scripts/1941-wme-to-os-link
Chrome packaged version: https://chrome.google.com/webstore/detail/wme-opendata/hjkehljinhkehammgkkhabmdbdnmcfei
Ta
No changes to the script itself, however as Iāve now migrated all my scripts over to the GreasyFork repository Iāve edited the 2.4 release post above to remove the temporary download location.
Iād love if this auto-updated. Itās no big deal but itād be nice if it ājust workedā. This script has saved me a million times though, and again, thanks for keeping up with the OS Locator dataset releases 
Following hot on the heels of the mid-year Locator update, June brings a Gazetteer update, access to which is now provided by 2.5ā¦
Firefox+Greasemonkey version: https://greasyfork.org/scripts/1941-wme-to-os-link
Chrome packaged version: https://chrome.google.com/webstore/detail/wme-opendata/hjkehljinhkehammgkkhabmdbdnmcfei
As an aside, in 11 days WMEOD celebrates its 2nd birthday. It was the not only the first Waze script I wrote, it was also the first GM script I wrote full stopā¦ Without those original 10 lines of code helping me to ease into the world of GM scripting, who knows whether Iād have considered attempting anything like URO+ or LMUR, and god only knows how many more map edits Iād have racked up without the constant distraction of tweaking just one more bit of code
For those editors who end up traversing the whole of the UK in a single editing session, 2.6 should now help keep the browser memory requirements in check by unloading any cached OS Locator block data which hasnāt been accessed in the last 10 minutes.
Firefox+Greasemonkey version: https://greasyfork.org/scripts/1941-wme-to-os-link
Chrome packaged version: https://chrome.google.com/webstore/detail/wme-opendata/hjkehljinhkehammgkkhabmdbdnmcfei
Cheers Chris.
Wow, thatās quick work. Iain will be delighted.
Not sure whether itās co-incidence, but Iāve installed v2.6 and now the OS Opendata link is not working. I get the webpage OK, but itās zoomed out and centred near Edinburgh. Musical Chairs is still fine.
It isnātā¦ Thanks for reporting the fault, the code responsible for introducing it has been located and dealt with, and a fixed version will be uploaded to GF/CWS later today.
When using the UK English WME, the yellow bounding box around a road doesnāt show.
Ah yes, the old āreferencing layers by their localised name instead of their unique nameā bugā¦ Iād already experienced this one ages ago in URO+ and completely overlooked the fact that WMEOD would be similarly affected :oops: Thanks for the report, should be sorted now
For anyone who hasnāt already noticed, 2.7 was uploaded last night. Unfortunately the same couldnāt be said for the corresponding post Iām 99.9999% certain I made at the timeā¦ So slightly later than expected, hereās the official announcement that 2.7 is now available, addressing the two issues noted above.
Firefox+Greasemonkey version: https://greasyfork.org/scripts/1941-wme-to-os-link
Chrome packaged version: https://chrome.google.com/webstore/detail/wme-opendata/hjkehljinhkehammgkkhabmdbdnmcfei
2.8 introduces the Primary Road Network highlighter option, using the PRN data distilled from the VectorMap District dataset.
Similarly to how the Locator data is handled, the PRN data is stored in 20km x 20km blocks which are loaded from my server and then cached locally as you pan around the map. Blocks are removed from the cache if not accessed in the last 10 minutes. Note that when a new PRN block is requested from the server, the script doesnāt automatically redraw the PRN layer after the block has successfully loaded, so if the highlighting appears to have stopped short of where youād expect it to stop, please try moving the map view slightly to force a refresh of the highlight layer. Having said that, sometimes the PRN really does stop short of where you might think it would :shock:
Note also that there are the occasional very short isolated segments which have been defined as PRN in the VectorMap District data, but which are not shown as part of the PRN in other OS data. So far all the ones Iāve seen have been completely obvious, so there doesnāt appear to be any risk in leaving them in the data (and besides, I canāt really be arsed to manually proof-read all of the data :lol: )
Firefox+Greasemonkey version: https://greasyfork.org/scripts/1941-wme-to-os-link
Chrome packaged version: https://chrome.google.com/webstore/detail/wme-opendata/hjkehljinhkehammgkkhabmdbdnmcfei
Great job!
A quick reminder to editors: we still havenāt agreed on this proposal, so please donāt reclassify any roads just yet. Go read the other thread and add your opinion if you havenāt already.
Twister - if you added your green PRN highlight as an OpenLayer, the it would pan with the rest of the map. See my Route Tester script for an example of how to do it. Look for references to WMERC_lineLayer_routeā¦
2.9 automatically refreshes the PRN highlight as data is received from the server. It also now moves the PRN and bounding box overlays in sync with the native WME layers as the map is panned.
This latter change was spurred on by Timās suggestion above, and although I couldnāt get native layers working reliably enough for the needs of WMEOD, having seen how nice it looked having everything moving in sync I figured there had to be some way to emulate it in my own code. And as it happens, there was. Itās been staring me right in the face every time I edit the code, and I canāt believe I hadnāt figured it out a long long time ago (though not necessarily in a cluster of star systems placed at some distance from our ownā¦).
As a background update which also applies to 2.8, Iāve also generated a full set of ādummyā PRN data blocks to fill in the gaps within the OS grid area which donāt have any PRN data and where, therefore, no blocks had been generated by the VMD parser. Without these dummy blocks WMEOD would throw a wobbler if you panned across into an area of the map which required it to try loading one of these non-existent blocksā¦
Firefox+Greasemonkey version: https://greasyfork.org/scripts/1941-wme-to-os-link
Chrome packaged version: https://chrome.google.com/webstore/detail/wme-opendata/hjkehljinhkehammgkkhabmdbdnmcfei
Thanks for the suggestion, it seemed like the perfect solution and all was going oh so well until I tried to maintain the correct z-indexing when the satellite imagery layer was turned onā¦
Try as I might, I couldnāt work out how to keep the PRN and bounding box layers below the road layer but above the satellite layer - itās as if they were both stuck on the same z-index, so either I ended up behind them both or in front of them both, neither of which were workable results.
Throw into the mix the way the layers would shift themselves around every time you saved a change, requiring a hook into the save event so that the layer indices could be rescanned, and I came to the conclusion that it was easier just to stick with the existing way of doing things. Still, 'twas a useful bit of experience playing around with the native layers, and as noted in the 2.9 release comments above it also spurred me into figuring out how to achieve the same result.
I too have wrestled with z-indexing, and failed to get native layers to behave as Iād like.
Anyway, good job!