Bowled a Googly

There’s an old saying that tells us “you get nothing for free”, and it’s certainly proved true by the Google Maps API and geo-coding of postcodes. Now before you email me ranting about what a wonderful free service Google Maps is (a sentiment with which I mainly agree), let me explain further. I had the idea of adding a small enhancement to one of our websites the other day: I thought it might be of value to put up a Google Map with pushpins to show the location of event venues. This column is about my arduous trek to achieve this goal, a journey that was at times very bumpy and which involved several dead-ends, but one that eventually resulted in a couple of new contacts and a working web page.

My first problem was how to accurately locate the event venues, and using their postcodes seemed the obvious approach. However, mapping software employs latitude and longitude to position markers or pushpins, so I’d also need some way to convert a postcode into its equivalent latitude and longitude. A skim through the documentation for the Google Maps API showed it did, indeed, include a procedure that could take a postcode and return map information, a process known as “geo-coding”. Be aware, though, that geo-coding tends to be fairly processor-intensive on the server – if you want to do it for lots of locations, you might want to use a different approach that I’ll describe later.

At this point in my own project, however, I was only dealing with a few locations. Even so, I quickly discovered that the geo-coding capabilities in the Google API are virtually useless! What’s the point of putting supposedly accurate pushpins onto a map if these markers can be out by as much as a couple of miles, as was the case with mine? I couldn’t believe it myself, and nor did any of my “Google fan” colleagues.

I decided to conduct some tests, so I grabbed my Garmin GPS and got it to tell me the latitude and longitude of a test postcode: my own office. This would give me a “real” location. Then I compared this with the location returned by the Google Maps API function, with this result:

Garmin GPS 52.06609 : 0.71071

Google API 52.04560 : 0.77727

I’ve included a couple of screenshots to give you some idea of what this degree of discrepancy means on an actual map.

Remember that I’m talking now about the Google Maps API function that you need to call Google Maps from your own code, not the Google Maps application itself, into which you can enter a postcode and get a pretty accurately placed pushpin showing its location. So why the difference? I emailed Google’s PR department, which forwarded my message to the technical department, which replied that it was aware of the inaccuracy – apparently it’s caused because the API uses a different way of looking up postcodes from the main Google Maps application.

Strange, I thought, so my next move was to try Google Maps’ main competitor in the market of free-to-use mapping software; namely, Microsoft’s Virtual Earth. Apparently, this also had some problems with geo-coding from postcodes, but in the latest release (version 6) Microsoft claims to have improved this. After an hour or so, I had some code up and running that queried Virtual Earth, and returned the latitude and longitude from my test postcode. The results looked far more promising:

Garmin GPS 52.06609 : 0.71071

Microsoft Virtual Earth API 52.06605 : 0.711029

This is a much more accurate result, so what was the reasoning behind the limitation on Google’s part? Those email replies were very cagey, agreeing that it needs fixing but giving no time-scale for the fix, and the reasons given for the broken lookup were “data usage restrictions”. This sounded like some kind of licensing restriction to me and, when I asked Google’s spokesperson if this were the case, she replied that “we [Google] do not comment on the specifics of our relationships with data partners”. So that’s probably a yes then…