[Script] WMEOpenData v4.1 (20250803)

3.23 also also restores operation following the recent WME update…

https://greasyfork.org/en/scripts/1941-wme-opendata

Would you consider adding support for Scotland’s Land Information Service into OpenData?
https://scotlis.ros.gov.uk/map-search

I’ve found it can often have details that OS Opendata does not.

Nope, wouldn’t touch it with a 10 foot bargepole having read through the T&Cs… The only reason I’m happy to make use of the OS data that I’m using to drive WMEOD is because it’s all been released under the OpenData licence (hence the name of the script), which means we can make whatever use of it we like in exchange for nothing more than a simple attribution somewhere (which we’ve done both within the source code of the script itself, as well as on the UK section of the Wazeopedia).

As soon as you step away from openly useable data like this and into the territory of data which involves even slightly more onerous licencing terms, let alone the “don’t even think of using this particular type of data for anything other than your own personal needs” type restrictions that ScotLIS refer to for some things, there’s a real risk of adding data into the Waze database that we’re simply not allowed to be adding due to its licencing terms, and if the licence holder were to then discover what had happened they’d have an entirely legitimate claim against Waze.

So we simply don’t do it.

That’s fair enough, I never looked into their ToS. I’ll keep that in mind in future.

3.24 fixes the obvious errors caused by the latest WME update - I make no guarantees that these are the only problems the update caused…

https://greasyfork.org/en/scripts/1941-wme-opendata

3.25 allows the script to correctly track WME map zooms again, fixes the London Roadworks site integration, fixes a cosmetic bug with the one.network integration, and fixes a random startup error…

https://greasyfork.org/en/scripts/1941-wme-opendata

3.26 removes a potential error condition.

https://greasyfork.org/en/scripts/1941-wme-opendata

3.27 is now compliant with the latest WME security configuration.

https://greasyfork.org/en/scripts/1941-wme-opendata

3.28 should now be fully compatible with the latest WME changes…

https://greasyfork.org/en/scripts/1941-wme-opendata

Hi Chris,

Is it a known issue that when you hover over a segment it shows the suggested name but when you click on it, it disappears, so you can’t apply to properties?

https://youtu.be/qRlJ4z3CfZA

I think I’ve seen that happening before, in that what I know I’ve seen happening before was a random desynchronisation between the WME map position and where WMEOD thought the map was positioned - if you’ve got the “Highlight by classification” option enabled then it’s obvious when it happens, because all of a sudden the highlights/polylines that WMEOD adds suddenly jump sideways so that they no longer align with the WME segments.

When this happens (and I don’t yet know why or how often it will), that seems to trigger a knock-on effect re being able to correctly select the road name, because now when you click on the segment to try selecting the name, the list of names shown in WMEOD is generated off of where it thinks the segment is, which is now no longer aligned with where it actually is, such that you might find the list suddenly emptying (if WMEOD now can’t find any potential matches at that location) or displaying names for roads somewhere off to the east or west (if the sideways jump happens to cause another roadname to end up aligned with this WME segment).

But as I’ve only seen it happening once or twice so far, and as I’ve had other more pressing things to deal with in other scripts, I’ve not assigned this one a high priority for attention - it’s on my radar, just not sure when I’ll get around to starting to look into it, or how long it might take to fix once I do.

Unfortunately, for me at least, it’s an issue I’m encountering literally all the time. I enabled the HbC option and did see some jumping around of the polylines but it seemed a bit random in that sometimes it jumped around and others it didn’t. I’ve included another screen recording which will hopefully give you a bit more to go off. You can’t see when I click but it’s when it changes from the correctly named Silica Ct to Pilkington Rd. It seems to be synched correctly when you hover over segment but clicking them throws them out. I had another example on this particular segment where it changed to Old School Dr (from over the road).

Example segment

https://youtu.be/PG0CIsMcjz8

Ah, I see what the problem is now, and why I’ve only seen it happen rarely, thanks for the clue!

So, what’s happening here is that when you mouse-over the segment, WMEOD builds a list of possible names based on where your mouse pointer is relative to the map view. So far so good. When you then click on a segment, WMEOD rebuilds the list using the same “where’s the pointer” logic, however in your example the act of clicking on the segment also causes the sidepanel to expand into view.

I’m not a big fan of having the UI jump around like this, so I tend to leave the sidepanel always expanded…

When the sidepanel expands during the segment click processing, whilst the map view itself doesn’t move, the effective position of your mouse pointer relative to the map view does move, by the width of the sidepanel, which is what’s throwing off WMEOD and causing it to rebuild the list using names off to one side of the segment you’ve just clicked on.

Now to see what’s involved in fixing it…

3.29 should now fix the problem noted above…

https://greasyfork.org/en/scripts/1941-wme-opendata

That was quick, great work!

Just noticed something else. The highlight errors feature isn’t staying highlighted. It flickers every time you click the mouse but doesn’t stay highlighted. I can do a screen recording if you’re unable to replicate it.

Odd, and no, I can’t replicate it… Which, given that WMEOD has no code in it to alter the state of that checkbox, is probably not surprising - whatever’s causing the problem you’re seeing isn’t therefore something WMEOD would do under certain circumstances.

So yeah, please do a quick screen recording to illustrate the problem in action, and also please grab a copy of the developer console output immediately before you try clicking the checkbox, and then again just after you’ve done so and triggered the flickering.

Also, it goes without saying, please make sure you’re able to replicate the problem when WMEOD is the only thing affecting (directly or indirectly) how WME is behaving - in addition to any obvious things like other WME addons, please also temporarily disable anything else you’ve got running which may affect WME on a more generic basis, such as adblockers.

Ah, it’s Color Highlights that’s interfering with it.

Tim’s script? i’ve got that as well, and it’s not causing any problems, so double check that you’ve got the latest update - remembering that Tampermonkey isn’t guaranteed to always keep scripts updated…

Looks like it was my WME. I had a 403 this morning and after clearing cache etc. it is now working again. Sorry for the false alarm.