1.15 now adds a drop-down list showing the 10 (1) closest place names from the Gazetteer data to the selected segment, providing yet another option for choosing a place name. At present, all non-unique names will be given a county suffix, as there's no way for the script to know which one shouldn't get it... All county names are as given in the gazetteer data, abbreviated where applicable using the UK wiki guidelines. Not all the counties in the wiki are present in the OS data, and not all the counties in the OS data are present in the wiki - corrections/alternative suggestions are welcomed here!

Also, when the UI is minimised, the bounding box highlight is now hidden - as useful as that big ol' yellow box is when naming segments, it can sometimes get in the way when doing other stuff...

http://userscripts.org/scripts/show/137249


1. except when the results list has fewer than 10 entries (2) - to reduce the search overhead, I'm limiting the results to a 5km radius (3) of the selected segment, so in sparsely populated areas there may be just a handful of results. Having said that, with 40-odd thousand entries in the slice of gazetteer data I'm using here, even areas that seem as if they'd have only one or two names nearby often surprise...

2. or if it does contain at least 10 entries, where none of the top 10 results are classed as a city but where a city name is present outside of the top 10 - here I add this city name onto the end of the list, giving 11 results in all...

3. give or take a few hundred metres every now and then - the OpenData version of the gazetteer data locates all the place names with a resolution of 1km, affecting the accuracy of the calculated distances.

4. there isn't actually a 4th footnote, I'm just not that keen on having an odd number of them

iainhouse wrote:I've been having a minor issue with the editor, that I've just pinned down to an interaction between this script and TimBones' Color Highlighting script.

I've just posted details here in his script's topic, so I won't repeat it all here, but I'm basically seeing the road & aerial images layers offset to the left immediately after permalinking or refreshing, cured by panning the screen.

I've tried and failed to replicate this in FF 18.0.1 and Chrome 25.0.1364.45 beta-m, using both public and beta WMEs, running the browsers at different window sizes, and swapping the order in which the two scripts run.

What I did notice during this testing is that, on a WME reload, the vertical scrollbar briefly appears during the page redraw process, only to disappear again by the time the reload has completed - the potential for this to occur has been in the script since I added the floating UI, but it's only since the addition of the gazetteer data that the script spends any significant length of time in the state where the scrollbar is visible. There's a chance this might, on some systems with particular timing relationships between the two scripts, cause an offset in the WMECH output equivalent to the width of the scrollbar...

As a pre-emptive step in trying to resolve the problem you've seen with WMECH (as well as to remove what is, if nothing else, a cosmetic annoyance), I've tweaked the WMEOD startup code so that it no longer causes the scrollbar to be shown.

1.16 now disables the "Copy/Apply to Properties" button if there are no segments selected, or if any of the selected segments are locked by a higher-level editor. The "Place name is..." status text is now also updated when the city name source is changed via the radio buttons rather than by changing the name field/drop-down list.

Also fixed a bug in the check for duplicate city names, which could be triggered when testing names at certain locations within the name list, and would cause the check to fail - the most obvious symptom of this was the non-appearance of the streetname bounding box until a box redraw was triggered by panning/zooming the map.

http://userscripts.org/scripts/show/137249

Timbones wrote: add a <label> tag to each suggested road name, so that clicking on the text will select it.

Ooh, didn't know about label tags, thanks for the suggestion! This has been added to the work in progress 1.17, along with support for WME beta - at least one of my scripts stands a chance of still working once that code gets released

Timbones wrote:when the selected segment already has a name, attempt to find the matching suggestion and auto-select it.
This would help verifying the extent of roads, and fix incorrect names.

Nice idea, I'll see how easy it is to get the matching algorithm working correctly for all the potential combinations of single/multiple selected segments, names that don't *quite* match up (e.g. where someone has just used the road number, but where the OS data also includes a text suffix - "A404" vs "A404 - Amersham Rd") etc. etc.

Well, persuading URO to play nicely with the new-look markers in WME beta took longer than I'd have liked, and as a result I haven't spent any more time on WMEOD since my earlier post. But since the work in progress code included a fix for beta support, plus Timbones' excellent suggestion for clickable labels, I've decided to release it now and save the rest of the to-do list for another day...

http://userscripts.org/scripts/show/137249

I can't replicate this bug here, at worst the OS site displays a blank area momentarily if I pan faster than the tile downloads can keep up with, but after a few seconds I always end up with a fully fleshed-out map display no matter whether the Chrome download bar is visible or not.

Woodvale, which browser are you using? Iain, which version of Chrome are you using?

If either of you are still seeing this problem, can you please open up the javascript console and PM me a copy of its contents.

iainhouse wrote:Maddeningly inconsistent!

Quite. No joy triggering the problem yesterday, today it's happening every time I reload the OS site, without having made any changes to my test rig... As we've all noticed, the javascript console is empty, so I'm beginning to think it's a startup timing issue causing the OS code to align the map viewport with the browser window before my code has finished tidying it up. I've got some things to look at now, fingers crossed for a resolution sooner or later!

As for the link issue you noted in WMEOD itself, I'll get that sorted for the next update.

So, the problem seems to be that, if the native code on the OS site completes before my code kicks in, the map object created by the OS code is based on the original size of the map viewport rather than the enlarged size after all the surrounding crud is removed, and so as you drag the map around the OS code that drives the map object is still rendering the new tiles based on this smaller viewport, so it never fills out the enlarged area.

If, on the other hand, the OS site takes a little longer to load, and gives my script a chance to run before the OS code completes, then the viewport is resized before the map object gets created, and so dragging the map around then allows it to be redrawn into that larger viewport.


Obviously the OS map object does know how to deal with its viewport being resized after creation, as can be seen by simply resizing the browser window even slightly, so the trick seems to be to let the native code do its thing, resize the viewport and then get the native code to redraw the map object without requiring the browser window to be resized. Bring forth version 0.7, with fingers firmly crossed...

http://userscripts.org/scripts/show/137248

Just noticed a couple of issues with OS Gazetteer placename handling, the fixes for which bring us up to v1.18...

Issue 1: placenames that were present in the Gazetteer data and that contain the - character would incorrectly be listed as "Place name is not in OS data"

Issue 2: if a placename was previously selected from the Gazetteer drop-down list, but that placename was no longer present following a list refresh, a completely different name would end up being used without any obvious indication to the user...

http://userscripts.org/scripts/show/137249

For the benefit of Iain and any other intrepid editors braving the far-flung corners of our isles in their pursuit of mapping excellence, 1.19 now uses a bodge-free OS gridref to pixel conversion, which should make the bounding box positions rather more accurate than they used to be...

http://userscripts.org/scripts/show/137249