Good idea. I need to make WMEOD county-aware in general anyway, so adding this in as part of that work shouldn't be a problem.

ditchi56 wrote:WMEOpenData seems to be permanently stuck "Loading new OS data...", which sadly makes it pretty much useless for me.

Running v2.16 on Firefox v41.0.1 under OS X v10.9.5

Help!

Ian

Haven't noticed any data retrieval problems myself today - only difference is I'm using Win7 rather than OSX, but same versions of WMEOD and Firefox. Is it still stuck now?

When it stopped working again, was this in the same area of the map you were editing earlier when it started working? If not, please could you revisit that area and see if it's still working now.

It should, however that's the first time I've seen an OS name put the "St" abbreviation anywhere except the start of the string, which is why the trap that's already in WMEOD to catch and convert these into "St." isn't working here. I'll add it to the to-do list for the next release.

Still working here - I noticed the first time I checked, the OS site took a while to initialise itself and spent several seconds looking just as you've described, but once it got its act in gear the WMEOD script kicked in and maximised the mapview as expected. The second time I checked, there was no such delay, and the maximised map view appeared pretty much instantly. Is it still misbehaving for you now?

Yup, and it'll remain broken until I've figured out a way to resolve the latest problem to be identified in URO+, or I give up in disgust and decide to try fixing WMEOD as a way to relax.

This WME release seems to have been particularly harsh on scripts - I can't recall the last time the scripts forum was so busy with so many different threads at the same time - so please bear with me as I prioritise my free coding time as best I can.

2.17 restores full operation once more following the WME update, fixes the "Saint" abbreviation issue, and is now somewhat aware of counties...

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

2.18 restores the full-screen fix for the OpenData map viewing site...

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

I can't permanently alter the z index without limiting the mobility of my UI to just the map viewport, as both the menu and Waze bars are at a higher z index than the native drop downs. What I'll have a look at doing is temporarily hiding the UI if one of the drop downs is activated.

2.19 now gets itself out of the way whenever one of the native WME drop-down menus is activated...

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