Routing Sans Frontières

I noticed a question on StackOverflow recently, concerning the ability of various web-mapping services (Google Maps, Bing Map et al.) to plan routes across national borders. I have to say that it’s a question I’ve never really considered before – all the trans-national routes I’ve ever tried to calculate have worked as expected, just the same as those contained within a single country. However, having given it some thought, it certainly is an interesting issue.

Even across contiguous land masses such as mainland Europe, most mapping services manage their datasets on a country-by-country basis. This makes sense, because the providers of that data are often governments or other national agencies, and the quality, completeness, and timeliness of data available will therefore vary between countries.

Bing and Google both offer similar country coverage for their mapping services:

• Google publishes this spreadsheet detailing the features it offers in different countries.
• Microsoft does the same for Bing Maps, on this MSDN page.

So far, so good, but what about situations where you plan a route that passes through more than one country? Even though the dataset may internally be partitioned into separate countries, you’d still expect those national datasets to be “connected” where appropriate, at the points where a road crosses the boundary between two countries. However, it seems that, as a by-product of managing datasets at a national level, some mapping providers don’t consider certain routes to be valid because they don’t regard roads as contiguous when they cross a national boundary.

For example, Google will plot a route between Ipiales and Pasto, in Colombia, or between Tulcan and Quito, in Ecuador, say, but it cannot calculate a route between Tulcan, Ecuador and Ipiales, Colombia… despite the fact that they lie only a few miles from each other, connected by the Pan-American Highway:

Bing Maps, however, does calculate this route:

There are other examples; Google Maps, for example, doesn’t appear to calculate any route that crosses into or out of China:

Which, again, Bing Maps does without complaint via the international border crossing between Zamyn-Üüd and Erenhot:

Of course, there are some other routes where it perhaps makes sense to be slightly cautious of crossing national borders. Bing Maps suggests that travelling from Cairo to Damascus is a “simple” 10 hour drive into Israel, Jordan, and then into Syria…:

Whether it makes sense to even attempt to complete this journey, Google Maps opts to send you the long way round via the Turkey/Syria border instead:

In practice, I’m certain I probably wouldn’t attempt to drive either of these routes…

Google’s April Fools’ Day 8-bit Map

Today, Google launched its annual April Fool’s joke – go to http://maps.google.com right now and you’ll see a new “Quest” map style in addition to the regular satellite and aerial map styles.

Looks a little…. familiar? Here’s the 8-bit tileset for Bing Maps I described just over two weeks ago:

You’re welcome, Google, the invoice is in the post…

“Apple” Maps (or, “OpenStreetMap Reinvented”…)

Update: Please also read the further information about this post

—

Traditionally, map applications on Apple platforms have made use of Google Maps. But iPhoto for iOS, launched today, ditches the familiar Google Maps interface in favour of a new map style.

The new map style has no attribution and the tiles are served from Apple’s servers using a URL pattern such as http://gsp2.apple.com/tile?api=1&style=slideshow&layers=default&lang=en_GB&z=8&x=126&y=84&v=9 . Here’s the tile image you’ll get from that URL:

The image tiles themselves use quite an interesting, quasi-retro style. Nobody would be surprised if they were told that Apple had been acquiring their own sets of map data in order to launch their own map product, dispensing of their need to rely on Google Maps in their operating systems. But have they?

I took a closer look at an area I know well. Notice how “Apple Maps” on iPhoto shows the road pattern in the area of Norwich circled in red in the following extract:

Now I know that folk here in Norfolk are a little odd, but surely our town planners wouldn’t have come up with a road network that mad? And, of course, they haven’t. These “roads” are tracks through woodland in an area called Mousehold Heath, where I often walk my dog. So how did Apple’s map data providers mistakenly think these were roads?

Oh, of course – Apple haven’t been gathering their own map data at all – what they’ve done is render Open Street Map data with their own stylesheet, miscategorised the status of some ways, conveniently forgotten to include any copyright attribution, and passed it off as their own! (Or, so it appears…)

Here’s the OSM map of the same area:

And here’s the two maps overlaid on top of each other – don’t they line up well?

I’m sure the OSM community would be delighted to know that Apple have chosen to use their map over Google’s – it’s a great validation of the accuracy and completeness of the Open Street Map data. Heck – the OSM data is there to be used. But not giving any credit to the hundreds of thousands of people who voluntarily put in time and effort to create that map? That’s a big mistake for Apple.

—

Update: Having spent some more time reviewing the Apple tileset, I ought to just mention that the example above is far from a one-off isolated case. It seems that whoever rendered these tiles lacks any real understanding of how OSM data is structured. For example, the following image highlights three beautifully rendered, detailed areas of road network…

…which, unfortunately, are nothing more than the lanes in private car parks (belonging to Norwich Union and City College, respectively). Yes, OSM data is that detailed.

And those features that are rendered appropriately appear to be based on OSM data that’s two years out-of-date.

And, then of course, there’s the interesting choice of rendering style. I actually quite like it, but that’s because I’ve always quite liked pirate treasure maps, and the look and feel of the zoomed-out map image definitely makes think that there should be an “X marks the spot” there somewhere…

—

Update 2: As two of the sane-minded commentators have rightfully pointed out (thankyou Patrick Taylor and JP), Apple is a big company, and it’s perfectly possible that this situation has occurred through oversight or communication breakdown rather through deliberate malice. Either way, I look forward to Apple co-operating with the OSM foundation to address the problem and, when they do, I will retract my statement that they have stolen the data without due credit.

One thing I regret is that I have no way of gathering further information about my commenters. Particularly:-

• If they have ever personally contributed to OSM.
• How many Apple products they own.

I’d love to see if there’s any correlation between their point-of-view on the issue and either of those factors…

Correcting Errors on Google Maps – Update

A few months back, I posted a blog post describing a number of errors I had found in Google Maps, Bing Maps, and Open Street Maps, and the steps I had taken to report them to the respective providers. I said that I’d post again if/when I had any news to report.

Well, today I got an email from TeleAtlas (the provider of Google Maps’ data), as follows:

Thank you for contacting Tele Atlas. Based on a review of your report, we can now confirm that the change you suggested has been made. It will go out in the next release of our map database. This report is now closed.

 

And, checking the report on the TeleAtlas website:

Of course, this only confirms that TeleAtlas has corrected the error. I’m not going to mark this error as “resolved” myself until the correction actually appears on Google Maps, but at least it shows that something has been done…