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 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/deta ... mdbdnmcfei

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.

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/deta ... mdbdnmcfei

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/deta ... mdbdnmcfei

ditchi56 wrote:Not sure whether it's co-incidence

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.

NorfolkMustard wrote: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 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/deta ... mdbdnmcfei

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

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 )


Firefox+Greasemonkey version: https://greasyfork.org/scripts/1941-wme-to-os-link
Chrome packaged version: https://chrome.google.com/webstore/deta ... mdbdnmcfei

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/deta ... mdbdnmcfei

Timbones wrote: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...

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.