3.17 reinstates the ability to set road names, and the OS map link...

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

Still seems to be working OK here in both production and beta.

It's been previously stated by the OS that there aren't any deliberate errors, such as have been used in commercial mapping data as a way to detect copying (trap streets), in the OpenData products, and any errors like this are therefore simply a by product of the sheer amount of data they have to deal with, which will get corrected over time.

WMEOD is highlighting this as an incorrectly named street in WME because the raw name data WMEOD uses has this incorrect spelling.  Presumably it was this same version of the raw data that the OS themselves used when generating those wider zoom level tiles for their maps, whereas the more zoomed in levels have presumably been generated from a newer version of the raw data where this error has already been corrected.  Hopefully this means the next release of the raw data files I use with WMEOD (due out next month) will also therefore include this correction...
 

Today marks 10 years since I made my first public release of a WME script, this script...  Life as a Waze editor was somewhat different back then, we were still adjusting to life after Cartouche, the UK map was still a largely barren wasteland of barely mapped, and even more barely named, roads, and there are several names in the editing community that, for one reason or another, are no longer around.

It was also a much simpler time for scripters - whilst there was next to no existing scripting community back then to lean on, and definitely no acceptance from HQ that scripts were even a thing, let alone something they ought to be embracing as a useful, necessary even, part of map editing, the way WME was designed behind the scenes made it a joy to play around with. 

With every new update to WME in recent months, those halcyon days feel further and further away, and simply maintaining existing script functionality occupies more of the time and energy we'd like to instead be expending on making our scripts work better.

I'm aware that some bits of WMEOD are currently not playing nicely with the new WME, and I've been working on fixes for these ever since things started breaking in beta, but it's getting harder to keep everything working as it should.  So please bear with me, and with every other scripter, as we learn how to deal as best we can with the increasingly shitty hands we're being dealt by the WME devs.

Thank you.
 
 
 

3.18 reinstates the OS map link.

Note that applying road names remains broken - trying to get this working again within the latest and increasingly script-hostile version of the WME UI code has so far been a fruitless task and is increasingly feeling like a giant time sink with no obvious end in sight. 

As such, 3.18 represents what I fear will start to become the norm for scripters these days - having to choose to release new versions which only partially address the known errors in the previous versions, because waiting until everything gets fixed is likely to mean taking far too long (if ever) to get anything released again...

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

3.19 restores integration with the one.network site, optimises the calculations used to convert between OS and other co-ordinate systems, and, and I can't believe I get to write this after so long waiting to do so, restores the application of road names.

Probably.

Due to the utterly delightful way the segment name editing UI behaves (in particular that bloody list of auto-complete suggestions which is annoying enough when you're adding a name by hand, and requires a devious workaround to deal with when performing a scripted change to the street or city names), getting this working again has required the addition of some time-delayed bits of code which give other bits of the code time to do what they need to do, having waited for WME to do what IT needs to do, and so on...

Consequently, this version of WMEOD is rather more sensitive to how quickly the host PC can run the client-side WME code.  I've done some stress testing here using a virtual machine granted access to 1/32nd the processing power of my development system, and whilst running WME in that CPU-constrained environment was an interesting exercise in patience, WMEOD did nevertheless perform as expected.  I'm therefore hoping I've managed to make it sufficiently responsive to different client speeds not to fall over, but it'd be remiss of me not to give you all fair warning that this fix might not work as well as expected on your systems.


The OS data on my server has also now been updated to the latest (October 2022) release, as I've been a little bit preoccupied with other scripting work to have remembered to check for updates over the last few months 
 


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

I was not, mainly because from where I'm sitting they're working just fine...  Is there anything showing up in the developer console that might suggest a problem?

No need to go looking, I managed to reproduce the problem whilst testing some other stuff. 

Should now be fixed, though you may need to clear your browser site data cache - this will force your browser to pull a new copy of the gazetteer data file from the server, and it's this file which contains the fix, not the script itself...
 

3.20 fixes a rare gazetteer data parsing error, introduces some new script startup code, and removes an annoying interaction with the beta UI.

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

 
 

I'm aware that the latest production release has broken WMEOD - this will get fixed ASAP...