Google Maps –vs- Bing Maps –vs- OSM – Responsiveness of Data Corrections

Yesterday, Glenn Letham published an article on the GISuser website explaining how to report map errors on Google Maps, Bing Maps, Open Street Maps etc.

Seeing as I’ve already made comparisons in some of my own recent blog posts concerning the accuracy and completeness of various online mapping providers, the content in Glenn’s article gave me an idea for another comparison…

Firstly, I would find an error somewhere in each of Google Maps, Bing Maps, and Open Street Maps. Then, using the official feedback channels described by Glenn, I would report those errors to the relevant providers. Points would be awarded to each provider based on the ease with which problems could be reported, how long it took for the error to be acknowledged, and how long it took for the error to be corrected on the map.

So, I set off to find some errors:

Google Maps Error – “Abberbury Avenue” in the Heart of Oxford

I was born and brought up in Oxford, England. When I returned there recently, I was surprised when driving down Longwall Street in the city centre that my (Google Android-based) car navigation told me to “turn left onto Abberbury Avenue”. In 18 years, I had never heard of Abberbury Avenue, and was certain that the road in front of me was the High Street.

On returning home, I checked on the main Google Maps website. Here’s a screenshot of the offending road in question, right next to Magdalen College in the heart of the city:

And here’s how that same section appears correctly in OSM – it’s definitely the High Street (also notice, once again, at the awesome level of detail in the OSM map – the college quads being individually and correctly labelled etc.):

There is an Abberbury Avenue in Oxford, incidentally, but it is found several miles away, near Rose Hill. The journey from Google’s “Abberbury Avenue” to the true location is shown as follows:

So, I set about following Glenn’s instructions to report the error. And then I stumbled across my second problem. The steps described to report a problem in Google Maps, which are also stated by Google on their own help pages here , say:

You can access Report a Problem in a couple of places:

• Right click on the map and select “Report a Problem” 
• Click the “Report a Problem” link at the bottom right of the map

Look closely at the following screenshot of what I see when I right click on “Adderbury Avenue” on the Google Maps website, and see if you can spot the problem:

That’s right – Right-clicking on the map does not give an option for “Report a Problem”, and neither is there a “Report a Problem” link at the bottom right of the map. From a quick search of the internet, it seems that the ability to report errors on Google Maps is limited to users in the USA, so that’s points lost immediately for Google…

So how exactly am I meant to report this problem? Fortunately, there is a copyright notice at the bottom of the map crediting Tele Atlas as the source for Google’s map data, and Glenn’s article also gives instructions on how to feedback directly to them. Fortunately, this is a very user-friendly step-by-step process, and I completed the details of the error  and submitted it as shown below:

I was given a tracking reference number and a link to track the progress of the error online. In theory, if the error is corrected in Tele Atlas’ own dataset will eventually feed back into Google Maps…. let’s see if it does.

Bing Maps – Driving down a Pedestrian-only way

The nature of the error I found in the Bing Maps website was slightly different. I couldn’t find any labelling errors on the map, but when trying to use the directions feature to plot a driving route between Norvic Drive and Peckover Road in Norwich, I noticed an interesting instruction:

2. Turn right onto Chalfont Walk

This immediately alerted my attention – pretty much any road named Chalfont Walk is, well, designed for walking, not for driving. Sure enough, as shown in Open Street Maps, it’s pedestrian access only:

Fortunately, the Bing Maps website does have a feedback link at the bottom right corner,  with different options to report problems with e.g. imagery, points of interest on the map, directions, etc. I filled in the feedback form with details of the error as follows:

I was given a “Thank you for taking the time to tell us about your experience” message, but no tracking reference and I didn’t have the opportunity to provide an email address, so Bing Maps also loses points here. I guess I’ll just have to keep checking back to see when (if) the problem is solved….

Open Street Maps

As noted in a previous post of mine, OSM has incredibly high quality data – higher, I believe, than that of the Ordnance Survey. Finding an error on the OSM map was therefore going to prove tricky. In fact, the only “error” I could find was not really an error – more an omission (and a pretty minor one at that). Jubilee Park, a park near my house in Norwich, wasn’t shown on the map:

So, you know what? I just logged into http://osm.org and, using the online map editor, added the missing feature. 5 minutes later, and here’s the correct OSM map:

So, that’s full marks for OSM. But who will come in second place out of Bing and Google? I’ll let you know as soon as I hear anything from either of them.

Open Street Maps –vs- Ordnance Survey (A.K.A. the Mystery of Birkbeck road)

In a previous post I compared how Open Street Maps (OSM) compared to Bing Maps and Google Maps in terms of completeness, at least for a small part of the UK. In this post I’m going to look at how OSM data compares in terms of quality, and what better benchmark to test it against than the Ordnance Survey (OS) – the historical and much-revered national executive mapping agency of Great Britain.

A UK company called ITO has produced a very useful OSM Analysis tool, that displays details of roads that are listed in the Ordnance Survey’s OS Locator dataset that are not present in the OSM dataset. The tool is provided as a service for OSM mappers, with the assumption being that the OS dataset is both complete and accurate, and therefore roads listed on the site are “missing” from the OSM dataset and need to be found and added.

Looking at the analysis for Norwich, there are a total of 38 roads (out of 1,619) of the OS Locator dataset for Norwich that are not present in the OSM dataset. This works out at a 97.65% match between OSM and OS, and ranks Norwich as 41st in terms of OSM completeness out of the listed UK areas. Being both a competitive person and proud of Norwich as my (adopted) home, I thought I’d set about tracking down those missing 38 roads and making the OSM map of Norwich 100% complete to the Ordnance Survey dataset.

But hang on, I thought that this post was about quality, not completeness? And there is the interesting thing…. it turns out that the “missing” roads are not due to incomplete data, but rather discrepancies in data quality. To explain, the list of roads currently shown on the OS Locator dataset but not on OSM is as follows:

• ALKMAAR WAY
• ATTHILL ROAD
• BIRBECK ROAD
• BLACK HORSE OPENING
• BRIGHTY’S OPENING – minor error
• BRUNEL WAY
• BUMSTEDE COURT
• CHARGE ROAD
• CHURSTON CLOSE
• CLOVELLY DRIVE
• CLOVELLY DRIVE
• CLYFFE COTTAGES
• DRAYTON ROAD (A1067)
• EBENEZER PLACE
• EDEN CLOSE
• EDWARD JORDELL PLAIN
• GEORGE DANCE PLACE
• GILDERS WAY
• GUNTON LANE
• HOOPER LANE
• KETT’S HILL (B1140) – minor error
• MIDDLETON’S LANE – minor error
• NEWBRGIN ROAD
• PLUMSTEAD ROAD
• PRINCE ANDREW’S ROAD – minor error
• QUEENS ROAD (A147)
• RANDLE GREEN
• ST FAITH’S ROAD – minor error
• ST FAITH’S ROAD – minor error
• ST FAITH’S ROAD – minor error
• ST JAMES COURT
• ST JOHN STREET
• THE MONASTERY
• THREE KING LANE
• TRILITHORN CLOSE
• UPPER ST GILES STREET
• WALL LANE
• WARRINGTON WAY

The first thing to note is that 7 of the errors are listed by the OSM Analysis tool itself as “minor” errors. In every case, the discrepancy is in the use of apostrophes in the road name. I’m not about to get into an argument on the use of English language as to which one is correct – but as far as I’m concerned if the only difference between the two datasets is in the use of an apostrophe, I’m happy to mark that down as not being relevant in terms of spatial data completeness/accuracy.

I was surprised to see some of the roads listed as apparently missing: Queen’s Road, for example, is a major part of the Norwich inner ring road – how could that be missing from OSM? The answer can be found by examining the map that shows where the “absent” Ordnance Survey record is supposed to lie:

Queen’s Road becomes Bracondale at a fairly non-descript location – it’s not a major intersection, it’s more of just a bend in the road. The OS Locator dataset contains one section of road that’s labelled “Queen’s Road”, which, in the OSM dataset, has been labelled “Bracondale” – essentially it’s just a discrepancy between exactly where the road changes name. Again, I’m happy to ignore that one.

Another road on the list that lies not far from me is “Birkbeck Road”. Or, at least, that’s what I thought it was called, and that’s what it’s called in OSM. But the OS dataset seems to think it’s called “Birbeck Road”. Could it be that I’ve been wrong? I went to check Google Maps:

Google Maps reckons it’s called “Birbeck Road”, so maybe the Ordnance Survey is right, and OSM is wrong. To double check, I went to Bing Maps:

Huh? So that’s two votes for “Birbeck”, and two for “Birkbeck”. I better carry on looking…

www.yell.com goes with “Birkbeck”, so that’s 3-2 to the OSM spelling.

But www.viamichelin.co.uk agrees with the Ordnance Survey. 3 all.

www.streetmap.co.uk agrees with OSM….

….until you zoom in, at which point it changes its mind and agrees with the Ordnance Survey!

And this is where Open Street Map really excels – it’s collaboratively created by people on the ground with local knowledge, and with the aid of my bicycle and a camera, I could demonstrate the ethos of Open Street Map and settle this dispute once and for all. So, I now proudly present….

…Birkbeck Road. So it turns out that Open Street Maps is correct, and the Ordnance Survey is wrong (as are Google Maps, Via Michelin, and StreetMap.co.uk). Enthused by this, and still on my bike, I decided to check some of the other apparently missing roads. The following photograph explains the apparent missing EDWARD JORDELL PLAIN, which once again, OSM correctly has listed as Edward Jodrell plain.

Interestingly, once again Google Maps agrees with the Ordnance Survey, and gets it wrong.

Whereas Bing Maps agrees with Open Street Maps and gets the correct spelling:

Over the next week or so I’m hoping to work my way through the rest of the list, but I continue to be amazed by the data available through Open Street Maps. Not only does it contain more data than Bing or Google (in that it contains points of interest such as postboxes, bus stops, property boundaries, and any number of other amenities), but in many cases it has higher quality data than the Ordnance Survey, at least in terms of the very limited sample I’ve looked at here. In fact, whereas I originally set out to update Open Street Maps to match the data from the Ordnance Survey, I’m beginning to think that the folks at the Ordnance Survey ought to be looking at the OSM data very closely and checking their data against it. And did I mention that OSM is free…?

Mappa Mercia Demonstrating the Power of Open Street Maps

Earlier I came across a post on the mappa mercia site that really demonstrates the power of the collaborative nature of Open Street Map compared to other web mapping providers. One determined user has chosen to explore and map all the features in a particular UK postcode area, B72, in Birmingham. And when I say “map”, I don’t just mean the road network… the Open Street Map of this area now shows 3500 individual labelled residential properties, including gardens, almost 300 named retail units, 100 commercial buildings, together with all the normal OSM details of bus stops, litter bins etc. The level of detail in the resulting map is remarkable.

For reference, here’s a screenshot from Bing Maps’ roadmap view of a small area in the B72 postcode area:

Here’s Google Map’s, marginally more detailed, view of the same area:

And, largely based on the efforts of one person, here’s the Open Street Map version (click to enlarge):

Note the house numbers, additional detail of the shape of roads, boundaries of properties, every individual retail outlet listed separately… just brilliant.

This is only a small area of one country but, with the coordinated effort of talented users on the ground, it’s easy to see how OSM’s collaborative model can create more accurate, more up-to-date mapping information than the commercial data providers used by Google, Bing, Yahoo, and the like could possibly match. The future looks bright for mapping….

Loading Open Street Map POIs with SQL Server / Bing Maps

Open Street Maps uses the same spherical Mercator projection as used by Bing Maps and Google Maps. This means that it’s possible to “mix-n-match” tile layers from each source, and there’s already a couple of posts on the internet demonstrating how to overlay Open Street Map tiles on Bing Maps (see for example, this article by Chris Pietschmann). In fact, last year Microsoft launched an official Open Street Map App that lets you overlay Open Street Map imagery in a layer on the http://www.bing.com/maps website.

However, the previous approaches demonstrate only how to display pre-rendered OSM tiles as an overlay on the map. Open Street Map has a massive (170Gb+) of raw spatial data from which those tiles are produced, all of which is publicly created, editable, and downloadable. In this post, I’ll look at how to download this base OSM vector data in XML format, shred it in SQL Server, and then display pushpins based on that data in Bing Maps.

Acquiring OSM Data

To start with, you need some OSM data. If you only want a small amount of data, then simply go to http://www.openstreetmap.org/ , pan and zoom the map to display the area of interest, and then select the “Export” tab.

From here, manually tweak the bounding box if required, ensure that the OpenStreetMap XML Data format option is selected, and then click Export to download the corresponding data file.

The XML export for the city of Norwich, shown above, is around 5Mb in size.

This method will work well for small datasets that contain up to 50,000 nodes. For datasets greater than this, you can download complete or partial subsets of planet.osm – the master file that contains all nodes in the Open Street Map dataset. The original file can be downloaded from http://planet.osm.org/ , but be warned that, when expanded, this is currently over 170Gb in size (and constantly growing).

For more manageable subsets of  OSM data, such as splits by individual country or feature type, you can try sources such as http://download.geofabrik.de/osm/ or http://downloads.cloudmade.com/

Shred the OSM Data in SQL Server

The native format for exported OSM data is a single XML file, containing a number of elements – <node>s, <way>s, and <relation>s, each with a variety of attributes. These data primitives are documented on the following Open Street Map wiki page.

To load this data into SQL Server, I’m going to shred the hierarchical XML structure into a relational structure describing each feature and its attributes.

Load the XML File

First things first, I’ll load the entire OSM XML file into a variable of the xml datatype using OPENROWSET(BULK), as follows:

DECLARE @x xml;
SET @x = (SELECT * FROM OPENROWSET(
BULK 'C:\Downloads\norwich_map.osm',
SINGLE_BLOB) AS x);

Nodes

The basic unit in the OSM dataset is a “node”. Nodes can be standalone (e.g a phone box), or they can be part of a “way”, which is a connected series of nodes forming either a line (i.e. a road or river) or an area (e.g. an area, building etc.). The following code listing uses XQuery syntax to extract all the nodes from the XML variable and inserts them into a new table, together with a geography point instance representing the location of each node.

OSM coordinates are always measured in EPSG 4326, so I’ll use the geography datatype and supply the appropriate SRID:

CREATE TABLE nodes (
nodeid int,
latitude float,
longitude float,
geog4326 geography
);
INSERT INTO nodes
SELECT
OSMnode.value('@id', 'int') AS nodeid,
OSMnode.value('@lat', 'float') AS latitude,
OSMnode.value('@lon', 'float') AS longitude,
geography::Point(OSMnode.value('@lat', 'float'), OSMnode.value('@lon', 'float'), 4326) AS geog4326
FROM
@x.nodes('/osm/node') AS OSM(OSMnode)

(14138 row(s) affected)

Here’s the first 5,000 rows from the Nodes table just created from my Norwich import displayed in SQL Server Management Studio:

NodeTags

Each Node may (optionally) have any number of tags. In the source xml file, these are represented in the child <tag> element(s) of each <node>, with an attribute k representing the property being described, and the attribute v containing the value of that property. I’ll shred these tags into a separate table, keyed by NodeId to link back to the corresponding node from the Nodes table. I use the CROSS APPLY operator to select all those tag elements that are children of each node row in the main SELECT statement:

CREATE TABLE nodetags (
nodeid int,
tagname varchar(32),
tagvalue varchar(32)
);
INSERT INTO nodetags
SELECT
OSMNode.e.value('(@id)[1]', 'int') AS 'NodeID',
OSMNodeTag.e.value('@k', 'nvarchar(32)') AS 'TagName',
OSMNodeTag.e.value('@v', 'nvarchar(32)') AS 'TagValue'
FROM
@x.nodes('/osm/node') AS OSMNode(e)
CROSS APPLY
OSMNode.e.nodes('tag') AS OSMNodeTag(e)

(5177 row(s) affected)

Selecting and Displaying Nodes from the data

Having shredded the data, we can now get on and start using it. To select a certain type of node, e.g. pubs, we can SELECT from the nodes table only those nodeids that have corresponding tags in the nodetags table. To display all nodes tagged with the “pub” amenity, for example:

SELECT
n.nodeid,
n.geog4326,
nt.TagValue
FROM nodes n
LEFT JOIN nodetags nt ON n.nodeid = nt.nodeid AND TagName='Name'
WHERE n.nodeid IN
(
SELECT nodeid FROM nodetags nt WHERE nt.TagName = 'amenity' AND nt.TagValue = 'pub'
)

Here’s the results showing pubs in my Norwich dataset in SSMS spatial results tab:

And, when viewed on Bing Maps:

Or, if you’d rather know the location of postboxes:

SELECT
n.nodeid,
n.geog4326,
nt.TagValue
FROM nodes n
LEFT JOIN nodetags nt ON n.nodeid = nt.nodeid AND TagName='Name'
WHERE n.nodeid IN
(
SELECT nodeid FROM nodetags nt WHERE nt.TagName = 'amenity' AND nt.TagValue = 'post_box'
)