Google Switches to Tele Atlas, Errors Proliferate

As was widely reported, Google Maps is now exclusively using Tele Atlas as its digital mapping data provider, dropping Navteq, which provided data for Google Maps proper but not for the Mobile or API products (All Points Blog, James Fee, Mike Blumenthal, Google Maps Mania). This is presumably the result of Google’s five-year deal with Tele Atlas.

But there’s a problem: Chad complains that the change has added a heavy dose of wrong to Google Maps. Based on my experience, I agree with him; since the changeover, I’ve noticed a number of changes that actually introduced error in a place where the mapping data was previously correct. (Presumably this was well known among users of the mobile and API products, but now it’s on the main site.)

Now it may be that the Ottawa area is particularly error prone, but I’ve noticed plenty of major errors in my neck of the woods. Highways follow the wrong roads; parks have the wrong boundaries. And there seems to be a problem with how the data distinguishes between major and minor thoroughfares: secondary highway markers have disappeared from the map, replaced by street names (i.e. “Provincial Road 241”); in Quebec there is no distinction between autoroutes and regular highways, as there used to be; and major thoroughfares that aren’t numbered highways look scarcely different from residential streets.

After the jump, a few screenshots of the errors I’ve found in the course of regular use (as opposed to a systematic search for error).

What’s frustrating about this is that Google’s response to inaccurate map data is to file a report with Tele Atlas (see previous entry). This works well enough when the errors are occasional; it’s far more problematic when there is apparently something wrong with the quality of the data on a fairly fundamental level, as appears to be the case where I live. There are just too many things that need fixing.

These are the kind of errors that make a mapping service very, very hard to use.

A Sampling of Map Errors in My Neck of the Woods

In Portage-du-Fort, Quebec, the alignments of Routes 301 and 303 are wrong: Route 301 should follow Purvis south, past the town and towards the Ontario border, where it becomes Ontario Secondary Road 653. Route 653 should not appear in this screenshot. Similarly, Route 303 should go through the town and make a junction at Purvis (following where the other 653 chevron is located).

Portage du Fort

In Shawville, Quebec, Route 303 should go straight down Centre to Route 148; what’s presented here is an old alignment, I believe.

Shawville

Between Shawville and Gatineau, now; I can say that Gatineau Park does not extend south of Route 148:

Gatineau Park

Following Route 148 into Gatineau, we see its new alignment along the Boulevard des Allumettières, which opened last December; however, the data still shows its old alignment along Saint-Raymond. Which one should I take?

Portage du Fort

Crossing into Ottawa from Gatineau can be problematic if you follow these driving directions. I assure you that you can make a right turn onto the Champlain Bridge from Chemin d’Aylmer; the driving directions used to show that, too:

Portage du Fort

And lest you think that all the problems are on the Quebec side, here’s a look at Carleton University that exemplifies the problem with thoroughfares. Bronson Avenue (marked as route 16) is a 70 km/h boulevard with multiple lanes in each direction; University Road is neither. Why does the map show the thoroughfare turning into the Carleton campus? (And what’s going on with Bank Street and Riverside on the right there?)

Portage du Fort

I can’t confirm whether this particular problem existed before the change, but it’s clear that the road data doesn’t line up with the aerial imagery; we’re back in western Quebec now:

Portage du Fort

Comments