Home Plog Google Reverse Geocoding vs. GeoNames

 
Mobile version of this page


 

Google Reverse Geocoding vs. GeoNames

http://www.peterbe.com/plog/google-r...vs.-geonames/results.log.txt

17^th of August 2009

I've been experimenting with the new Google Reverse Geocoding which allows you to get the location name and country and stuff from a latitude/longitude coordinate.

What I've been doing is comparing this with GeoNames. GeoNames is available from geopy in the reverse-geocode branch.

I wrote down a list of about 15 lat/long points and the result I expect from them (taken from an existing app I'm contemplating switching to Google Reverse Geocoding for) and ran a batch of timed tests on. These results might satisfy the impatient:

 FAILURES:
 geonames_json        0
 google               0
 geonames             12

 TOTAL TIMES:
 geonames_json        2.43582677841        0.143283928142 seconds/request
 google               2.24999976158        0.132352927152 seconds/request
 geonames             1.78063511848        0.104743242264 seconds/request

First of all, a "failure" is when the place name simply can't be looked up. You could consider certain results a failure but it depends on what you intend to do with results. For example, GeoNames returned Glen Mills, United States whereas Google returned 38 Hitchcock Ln, Glen Mills, PA 19342, USA. With the Google results it's not always obvious that the "place name" (alternatively the town) is the second to last bit split by commas.

Using geopy to connect to GeoNames is clearly a bad idea. It's much better to just connect directly to the JSON REST URL.

In conclusion, I'm not going to change from using the GeoNames JSON API to Google Reverse Geocoding in my app.

You can see the complete results of my analysis here

If you're interested to see the code it's on github

Comment