ditchi56 wrote:There are quite a few little roads in towns, especially private roads, with blank names on the OS map, and there is no point in highlighting them when a local has supplied the name.

Most of the time these roads fall within the bounding box of another road, and so the script isn't able to determine that no OS name exists for that road.

ditchi56 wrote:could it please start highlighting roads (perhaps in a different colour) where the OS do have a name but WME doesn't?

The above comment is relevant here too - most WME-unnamed roads will lie within at least one bounding box, so adding this functionality into WMEOD would give results little different to using the No Name option in WMECH...


I've got some back-burner work going on to reduce the number of false positive matches, and if this produces anything useful then I'll reconsider adding the above functionality.

Just found an error in the gazetteer name checking code which would return a "Place name is not in OS data" result for valid names if, in the gazetteer name list, they were immediately adjacent to a name containing an accented character...

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

Pretty much anyone who's used the NameCheck function in previous versions of WMEOD will be aware that it isn't the fastest bit of code on the planet, especially in densely populated areas such as central London. After several days of in-depth performance analysis in both Firefox and Chrome, I'm pleased to announce the fruits of this labour are now available to one and all in the shape of 1.28...

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

So, just how much faster is it? Well, if 1.27 was a Citroen 2CV climbing up to the top of the Hardknott Pass whilst towing a trailer full of lead blocks, 1.28 is more like a Bugatti Veyron going down the other side with a Saturn V first stage rammed up its backside firing at full throttle... or something like that. For those who prefer cold hard numbers, I'm seeing results returned around 14-15x faster than before.

iainhouse wrote: First off, with the black highlights turned on, I'm sometimes encountering large blocks of segments that are all highlighted black. Sometimes a hard refresh will clear them, but as I pan around the same block tends to re-appear.

Found a bug in the code that was supposed to be handling the boundary cases where the NC function needs to pull in OS data from more than one 10km block... Now fixed, expect another release later today.

iainhouse wrote:Secondly, strange highlighting behaviour when editing, even without black highlights on. After editing a segment (say changing name or road type) the bright blue highlight disappears from the segment, although the nodes still appear if I mouseover the segment.

Oops Yeah, confirmed, will add this into the next release too.

iainhouse wrote:Finally, I have always seen the occasional time when the WMEOpenData window won't appear after a page load and I normally just do a refresh. However I am now seeing that happen a lot more.

Does it not open at all, or just stay with the "Loading OS data" message? If it's the former, then it's probably because WME itself is flakier than a flaky thing these days, and often fails to load fully (even without any scripts active you'll see this happening) which then prevents the onload event from firing, which in turn prevents WMEOD from completing its own initialisation.

Timbones wrote:More bad news - it doesn't run in Chrome Beta (v27). I've had to turn my script into a proper .crx extension. I can send you my working source, or you can copy how WME-Addons does it. Or you may be able to figure out a different way to bootstrap them into the main sandbox.

I'm really not loving Chrome at the moment Thanks for the PM, I'll have a look at that when I've got time to give it some proper attention.

Just uploaded 1.29 which should resolve the two main issues noted by Iain.

*really* not feeling the love for Chrome today... Part of the optimisation was a Chrome-specific bit of code to deal with splitting the lines of OS data into their individual parts, and it isn't splitting off the locality. Easy fix, I'll upload it later tonight once the kids settle down!

Fixed the "undefined" locality bug in Chrome, and reduced the likelihood of a segment being highlighted by NameCheck when its name is OK - seems that wazeModel.segments.objects[].getCenter() returns results that are, quite frankly, a giant steaming pile of masculine bovine waste matter... Script now calculates the true segment centre itself, resulting in far better matching to the OS bounding boxes.

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

It doesn't really feel like 6 months have gone by since the last OS Locator update... Can't argue with the calendar though, nor the appearance on the OpenData site of a shiny new May 2013 dataset, so here's 1.31 in response.

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

I swear the placename uniqueness code will drive me slowly but surely insane - every time I think it's been fixed once and for all, along comes another placename example that throws it a curveball... until then however, 1.32 now at least knows that Leeds isn't just a sleepy hamlet nestling in the Kentish countryside.

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