OS road names

Shaun sent me an email about a Cyclestreets problem report. There is a cycleway that crosses a railway line on a foot bridge with a cycle ramp up the steps. The steps were not in the database, as Shaun suggested. I went out to check it and knock a few OS Locator name issues off.  The new GPS gave a much better track than the old one along the cycleway which is under a lot of trees beside a railway embankment, so not only did I add the steps but improved the location of the path too. I added the steps, a bike ramp and a bollard too.

At one end of the cycleway is Perth Street West. OS Locator seems to think that a part of it is called Perth Street. This is clearly nonsense, there is a street called Perth Street to the east of Chanterlands Avenue. It contines to the west of the avenue where it is called Perth Street West. Further west it passes under a railway bridge and, according to OS, becomes Perth Street once again. There are no name plates for this section and no houses either. There are a couple of businesses on the road, including S&R Motors and on the back of their van was the address: Perth Street West, so that's what I'll take.

The OS names of roads become definative, which I don't like. In the village where I live there is a road known as Beech Hill. At one end of the road there is an old sign for Beech Hill, but at the other end there is a new sign for Beech Hill Road. All of the long-standing locals call it Beech Hill, but OS call it Beech Hill Road.  Persuading the council that the OS name is wrong is likely to be hard, so I am seeking evidence to establish the long-standing name.

More checks and a correction

A couple years ago we were checking out streets in the Anlaby Common area and I wrote a blog about it. When the OS Locator data was made easy to use by ITO's tiles I saw that Ordnance Survey were repeating the same stuff that was on Google's Map two years ago, maybe they share the same surveyors.  Since it was two years ago I thought I'd check again, as well as some other anomalies. I'm glad I did check, someone has corrected a sign board, though OS still have it wrong.

Two roads run parallel to one another, one is called Plantation Drive and one Plantation Drive West. When we last were there the most easterly road carried the name Plantation Drive West, which I commented about at the time, now the name boards have been swapped. OS still think the most easterly road is Plantation Drive East, which is not what the name board says.

Nearby in Anlaby Common there is a road with a loop called Spring Gardens. OS name all the parts separately as Spring Gardens East, West and South. The signs all say Spring Gardens and the house numbers work for a single street, even though they dot about a bit.

We did find a few small roads that were missing from OSM and a couple of names that were wrong, but there were a few other names that OS had wrong.  I'm finding the process very useful to check what we entered years ago and helping find new roads and extentions that we otherwise wouldn't know about.

Comparisons

I have used the tiles provided by ITO World for a few short sorties to improve the names in OSM. I always use what I find on the ground when I can, but many country roads don't have name boards on display. The Ordnance Survey data that has been released often has names for these roads. I add these from the OS StreetView dataset with a tag source:name=OS_OpenData_StreetView.

I found that I could only look up OS StreetView names and ITO World's tile in an editor. I wanted to see them on a web page. I like the transparent page that sautter.com provide, so I thought I'd do the same kind of page too.

The end result (http://oscompare.raggedred.net) has either a Mapnik layer or Osmarender layer at opacity 1, with either the ITO World tiles or OS StreetView or both over the base layer. The slider changes the opacity of the overlays from 0 to 1 (hidden to fully opaque). I have only tested it on Firefox; comments are, as always, welcome.

New kit and old problems

I ordered a new Garmin eTrex Vista HCx GPS and it arrived today. My old Garmin is dropping to bits, I've had it for about seven years so it has worked hard. The rubber is coming off which stops the buttons working, the screen sometimes doesn't work well and now it doesn't always download its data without switching off.

The new model is shorter and fatter, with a wider screen. The colour screen seems easy to read. It also beeps which should be better for navigating. The way of moving around the various screens is a little different and I have yet to explore it completely. I don't yet have a spare microSD card - I'll get one tomorrow, so I can't load a map yet.

I took it out for a test run and the quickly became apparent that it has a better receiver chipset. The satellite lock was very quick and the accuracy was showing +/- 8ft to 10ft for the whole test. When the old unit finally got a lock it varied from 19ft to 45ft. Not a scientific test, but I'm happy. Once I got home I could still get a lock inside the house with +/-20ft. I downloaded the track in a moment instead of the few minutes with the old unit.

As to the test route, we went out to check some more of the name anomalies thrown up by the OS Locator data, this time in Beverley. Most of the differences were small roads and especially tracks that were missing. There were a few typing errors and a few that were errors in the OS Locator data. I think the data extract has been changed to include apostrophe differences. There are many examples of inconsistencies with apostrophes on name boards and I found some today, including a small road that had two name boards facing each other, one with an apostrophe and one without. I just accepted the OS Locator version (without).

I used the new GPS track to move a few roads to the seemingly more accurate position, and in the process lined a couple up with the OS Boundary Line data, which is probably right.

New GPS: happy.
Checking apostrophes: no fun.

Wrong road names

The Ordnance Survey data that has been released is quite a mixed bag. One of the things I have overlooked is OS Locator. This gives a list of roads with a containing rectangle and some location data, such as settlement and county. The coordinates are in OS northings and eastings of course. Itoworld have taken this data and compared it to OSM data in Britain. They created an overlay showing the locations where OSM and OS road names differ, using the OS rectangle to highlight the area. They have also produced a summary of the number of differences in districts, counties and unitary authorities. As usual with Itoworld's work it is useful and accurate but carries the small penalty of taking a couple of days for changes to be reflected.

I took a look at my local area and immediately found errors. This is not a surprise, my work is not being checked on the ground by anyone else and I am as prone to errors as the next man.

When I looked closely it was clear that I couldn't tell if the OS data was wrong or if there were mistakes in the OSM data without checking it on the ground. I selected a dozen or so fairly close to home to check out.

I found a small residential road I had missed, a couple of tracks that were not on our map, one with a clear name plate I had missed. I found a small industrial site with an apparently public road through it that was missing from OSM. There were a few mis-spellings all on my part when I haven't transcribed from the photograph accurately.

Lastly I found two roads where the OS data had a fault. One was easy, OS call a road in Cottingham Middle Dike Lane, the name board shows (and we know from our local knowledge) it is Middledyke Lane. One photo of the name board and a check that there are no other name boards and we were sure. 

The second was a bit harder. There is a road called Endike Lane that runs from Hull to Cottingham, at least that's how it looks, but the name board in Cottingham says Endyke Lane and the name boards in Hull say Endike Lane. When I mapped the area I assumed that the name changed at the boundary of the city, but now I know that is not quite true. We found the break point by looking at the house numbers, they number from each end towards the join, so 601 Endike Lane is next door to 42 Endyke Lane and the break must lie between them. This is not as OS describes it, but OSM was wrong too, the boundary is about 200m away. I suspect that at sometime in the past the city boundary did lie where the name changes but has moved since.

To prevent the difference being highlighted again, even though we now know that the OSM data is correct, Peter Miller of Itoworld suggests adding a not:name=Middle Dike Lane. I was unhappy at first about adding data to OSM to show this, but now I accept that it is just metadata like a few other widely used tags, and, unlike any others, it is a negative tag which could be useful elsewhere.

All things considered, this new overlay will improve the quality of OSM, especially in areas where lone mappers are working and I welcome it.