Thanks for highlighting this - I'd checked that using the cursor keys moved the PRN layer correctly but hadn't noticed the lack of refresh. I had a quick look at fixing this, but the obvious fix for getting it to refresh after a cursor key move then broke the layer move synchronisation fix I put in last time, and I suspect getting it to work properly will take more time than I'm able to devote to scripting at the moment.

Sigh, the idiots in charge of my hosting service have just gone and blocked my account without any warning, preventing access to the OS files required by WMEOD

Account has now been restored, though without any explanation why it'd been suspended in the first place...

On a slightly related note, these account hassles have prompted me to do some housekeeping on the server, and consequently all of the older releases of OS data have been removed. This means all versions of WMEOD prior to 2.5 are now obsolete - apologies if this causes any difficulties, however it's been over 2 months since 2.5 was released, so there aren't really any excuses for not having upgraded by now

In future when there's an update to the OS data, I'll keep the previous version available for a few months to allow people to make the transition, but I'll no longer be leaving older versions online indefinitely as has been the case up to now.

iainhouse wrote:You're probably aware, but OpenData isn't working too well since the WME update.

I'm surprised you're getting any sort of functionality out of it at the moment, because it's not working at all for me since the update... Given the relative sizes of their userbases, fixing URO+ is my priority at the moment, so fixing WMEOD is likely to start at some point over the weekend.

iainhouse wrote:I'm seeing several errors in the console like "WMEOpenData: Current name was set 140m away from segment location". I've tried experimenting with relative positioning of the OpenData window and the segment and the segment within the WME window, without coming to any conclusions.

That's diagnostics data, not an error message - WMEOD requires you to reselect the city name once you start editing a segment more than 1000 metres away from the point at which you last selected it, those messages are indicating how far away the currently selected segment is from that point.

iainhouse wrote:I also hate to resurrect an old problem, but I'm still experiencing considerable performance issues with OpenData when editing in dense urban areas - to the extent that I find I'm regularly having to disable/enable it from the Extensions tab. Might it be possible to add an on/off switch so I can turn it off without checking extensions & then permalinking/refreshing?

Once I get it back into a fully operational state I'll have a look at performance again.

Eww... I thought the old page layout was bad, but they've somehow managed to find even more crud to pad out the page above and below the letterboxed view of the map they deign to provide us, what a mess.

Good news is, this appears to be a trivial fix, so as I may end up rolling out an interim WMEOD update that fixes this before I get around to sorting out the WME-related fixes required.

2.10 is an interim update which restores fullscreen mapping to the OS OpenData Viewer site... Resolving the compatibility issues with WME itself is still on the to-do list.

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

2.11 should now play nicely with WME...

To try and address the performance issues noted by Iain, I've also made a few changes to how WMEOD behaves.

1. When the WMEOD UI is minimised, all streetname lookup activity is disabled.

2. The streetname data is now stored in blocks of 1km x 1km, as opposed to the 10km x 10km blocks used in previous versions. This reduces the amount of data the script needs to search through when performing each name lookup, and also minimises memory usage when editing in densely mapped/named areas.

3. Unused streetname blocks are now purged from memory after 60s, rather than the 10 minutes of previous versions. This should also help minimise memory usage, particularly for editors who are in the habit of moving around the map a lot in a short space of time...


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-UK wrote:3. Unused streetname blocks are now purged from memory after 60s, rather than the 10 minutes of previous versions. This should also help minimise memory usage, particularly for editors who are in the habit of moving around the map a lot in a short space of time...

Do the data blocks get cached by the browser, so that they reload quickly when revisiting an area?

I have no idea, though as they're being loaded via the script injection code you suggested way back, rather than as a standard HTTP request, I wouldn't be too surprised if the caching mechanism gets bypassed here.

2.12 provides access to the November streetname data update, which adds another 1998 entries to the list...


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

Timbones wrote:Request: Can you add a marker and/or label on the map for the centre of the cities?
I think this would be helpful when determining if cities are in the correct location.

I'll have a play around with that idea when I next work on WMEOD, which is likely to be soon, as I need to integrate the OpenData updates from the end of last year...