3.13 fixes the fix for the permalink link... 'tis one of the great joys of software development, to discover that something which seemed to be working just fine on one of your PCs fails to work at all on your other one, despite them both running the same OS+browser setups

https://greasyfork.org/scripts/1941-wme-to-os-link

3.14 recompatibalises the code with the latest beta changes...

https://greasyfork.org/scripts/1941-wme-to-os-link

The OS road data is, not unreasonably, defined using OS grid references. And whilst there exists a (rather complex) method for converting between the OS grid and the coordinate system used by the Waze map data, there are times - related to whereabouts on the OS grid you are - when the accuracy of this conversion is a bit too far off for the results to map cleanly onto the corresponding Waze segment locations. You may sometimes see this when using the polyline or bounding box highlights to indicate the positions of all the roads its aware of in the current WME map view area, particularly on roads which are aligned N-S or E-W.

The script does attempt to compensate for these errors to some extent, but doing so sufficiently accurately across the whole of the UK map isn't something I can realistically do, and the results it does generate are good enough for the requirements of the functionality present in the script at the moment.

However, if the script tried to automatically match up the OS data with the Waze data to flag up missing roads, these inaccuracies would give rise to more false positives and false negatives than I think would be acceptable - false negatives would quickly get annoying as the script kept flagging up roads that were already mapped, and false positives could give editors an overly optimistic view of the state of the map data.


So in lieu of attempting to do any sort of auto-flagging of missing roads, the script has the option to display all of the roads it's aware of in that area either as bounding boxes or as polylines - this allows the editor to manually review the map in front of them for any discrepancies, without requiring the script to play any role in deciding whether or not there is something missing from the Waze data.


If I could figure out a cunning way to get auto-flagging accurate enough to be viable, this would then lead onto the second part of the problem - getting it to do so over a wider area of the map than the bit you're currently looking at. Anyone with a reasonably large editing area who uses the URMPT script will know how long it can take for that to perform a scan of their area looking for URs etc.

Now imagine how long it'd take to scan the same area in order to pull in, not the current UR data, but the current geometry data for all the segments within that area. That's a hell of a lot more data for the server to be sending out and for the script to also be handling locally, but if you want the script to be able to proactively direct you towards parts of the map which need attention, rather than relying on you deciding to check out a given area, then the script would have no choice but to scan beyond the parts of the map you're looking at right now. It might be feasible to scan a bit beyond the visible area, and maybe if your entire editable area is quite small then maybe even have it scan all of that. But for anyone who has a reasonably sized editable area, either through drives or being an area manager, the script would most likely have to restrict itself to scanning just a subset of that area and still be reliant on the user deciding which bits of the map they were interested in.


It's a really nice idea in theory, and one I've already given some thought to (as you may be able to tell from the length of this reply), but putting it into practice would require more effort than I'd be willing to devote to it given the quality of the results I think would be obtained. To put it another way, if I honestly thought it could be done, you wouldn't need to have asked the question, because it'd already have been done...

3.15 adds further beta compatibility updates... but soft, what light through yonder window breaks? Oh my, it's only some new functionality as well!

With thanks to Iain for giving me the nudge I needed to finally take this off the to do list, 3.15 now provides the option to add place name tags to the map view.  This is controlled from the new "Gazetteer Tags" section of the UI, and works in a similar maner to the OS Open Roads display functionality - there's a master on/off toggle controlling the overall functionality (and which, just like the Open Roads toggle, is always set to off whenever the WME session loads, to avoid having potentially hundreds of tags suddenly being rendered...), and then a list of further toggles to show/hide the tags relating to specific types of place, listed in descending order of priority.

Place names are tagged on the map using a colour-coded arrow tag which points to the location defined in the OS data for that name.  Cities have a yellow tag, towns have a purple tag, villages have a pinky-salmony tag, hamlets are light blue, and "other" places are light grey.

Fun fact - in this OS place classification scheme, there are no towns within Greater London...



https://greasyfork.org/scripts/1941-wme-to-os-link
 
 

And no, I haven't forgotten to edit the thread title to show that the script has been updated, I can't edit it thanks to the amazing new forum upgrade HQ seem to think is the best thing since the best thing since a loaf of bread met a knife 
 

3.16 restores correct operation following the latest WME update.

https://greasyfork.org/scripts/1941-wme-to-os-link
 

Kkervinjones wrote: ↑Thu Aug 19, 2021 9:50 am Hi Chris, is it possible to add Keyboard Shortcuts to toggle the enable/disable the highlighted features, without needing to open up each section?Untitled.png
 
 
 

 

I guess so - now that I think all the script updates required by the latest WME release are done, I'll have a look into this the next time I have the energy to do some more scriptbashing.
 
 

A sad day for WMEOD - the OS have finally decommisioned the last remaining part of ther original OpenSpace mapping service which WMEOD had been using to provide the georeferenced OS map via the "OS OpenData" link at the bottom of the WMEOD UI, so clicking on that link now just provides you with the opportunity to discover how your browser handles being asked to load a non-existent page from a non-existent domain...

I've started to poke around behind the scenes of the replacement service the OS now provide, to see if it'll be possible to tap into it in the same way, but it's far too early to give any indication as to a) whether this will be possible at all or b) how long it might then take to complete.  This is a pretty high priority for me though, as I used that link extensively during my own editing sessions, so I have a very keen interest in getting it working again if possible.

Still, look on the bright side, at least it wasn't the WME devs breaking shit again this time 
 
 

Quick PSA: my server used to host the OS data files for WMEOD is currently undergoing maintenance and is unavailable, and may suffer random dropouts once it comes back until everything is up and running again correctly.

Kkervinjones wrote: ↑Thu Oct 21, 2021 10:39 am Hi Chris, WMEOpenData doesn't seem to be Applying the street and city names when clicking Apply to Properties.

 

Yes, there's been a sneaky alteration to the code behind the scenes of the segment editing side panel in the latest WME update which has knocked this functionality out.  I think I've now found what the problem is, so expect an update soon.