Science is happy to release an open source geocoding engine built in pure Ruby for the Ruby on Rails environment. You can down load the plugin by following instructions here. (Update 10/21/07 - new features!)
The engine is capable, out of the box, of using MapQuest, Google and Yahoo API’s. All you have to do is obtain a free API key from the provider of your choice. If you get one from all three, you can play around to see which one you prefer.
Your input and comments would be welcome.
From my testing and analysis, it appears that currently Google has the best API engine on quality - though a year ago I would have said Yahoo. Right now Yahoo is the worst of the three. Google isn’t so great for bulk geocoding, at least in my experience (MapQuest is better). Here’s the skinny:
- +/- 50,000 searches per day (but rate limited in some hidden way - you can’t do 50,000 searches in a day unless you spread them out very evenly)
- + Returns street/city names with human readable / mixed-case text
- + Easy to search by intersection using human readable formats like “Main st and Pine st”
- + Provides choices on ambiguous geocodes
MapQuest
- + 50,000 searches per day
- + Provides choices on ambiguous geocodes
- - Returns street/city names in all upper case
- +/- Permits intersection searching but only if you substitute in “@” between streets
Yahoo
- - 5,000 searches per day
- - Provides no choices on ambiguous geocodes (but did a year ago)
- - Returns street/city names in all upper case
- - Doesn’t seem to provide much support for intersections
Just wondering what GeoX offers over graticule/acts_as_geocodable/acts_as_locateable/etc?
I couldn’t find a tool that supported the MapQuest OpenAPI engine which is why I wrote GeoX. That’s probably the main feature over other tools. It’s also very modular so it’s easy to write additional geocoders - not sure how hard that is in other engines.
GeoX’s design is “pure Ruby” - though it’s packaged as a plugin, it doesn’t depend on very much inside Rails (.blank? is the only method that I think I’m using out of Rails). As a result, integration with models is a little less tight which some people would regard as a defect, but which I prefer. Adapting it for Ruby-only projects would be easy. If you try it, let me know how it compares.
Adding extra drivers to graticule (a standalone gem) is very easy (I submitted the initial version of one of them) and it now supports failover, so you can recover gracefully from connection problems with your main provider.
I’ll try and spend some time with GeoX soon and add it to my comparison chart of rails geocoding tools.
Oh - that’s a really good idea. I’ll add failover to GeoX! Thanks.
I love this plug in… great work.
A couple suggestions.
1. Instead of using an API key file in the plug-in directory, copy the file to the config directory. That way you can use an svn:external link to the plugin.
2. Allow for easy switching of api keys based on environment.
[...] GeoX is the latest kid on the Ruby on Rails geocoding block. The plugin was announced a couple of weeks ago and I’ve been meaning to explore it ever since, just in case it had any new features and also so that I can add it to my comparison chart. [...]
I’ve updated GeoX to support failover geocoding. It’s as easy as passing an array into the geocode init routine instead of a single engine. See the wiki or README file for details.
Also, you can now locate your geox_api_keys.rb file in the Rails root/config folder so you can have an SVN:external link to my code base and stay current more easily.
I’ve been looking for a way to improve the geocode returns and wanted to use the phone number to get a more exact location or to enhance a current location return… Any ideas?
Jason: There are a number of resources out on the web that you can use to use a phone number to determine a general area. Because so many numbers are portable (i.e. cell phones), it’s often impossible to know for sure where a phone is located (so an 510 number indicates the Eastern part of the San Francisco Bay Area, but I know people with a 510 area code on their cell who live full time in New York City).
With that caveat you could pre-process your incoming addresses with something like:
http://www.bennetyee.org/ucsd-pages/area.html
This is just an example - google “area codes region lookup” or variations to find tons more info.
I’d recommend wrapping GeoX in a pre-processing class that handles conversion from phone numbers to geography where possible. Basically a geocoder should get geographic information, and you should pre-process phone numbers to generate required geographic information which you submit to the big geocoder engines for conversion to lat/long. Hope that helps!
Thanks, that link alone is worth your weight in gold. And thank you for the wrapper idea, should solve some issues I listed out. I will report back after some testing.
Thanks for putting in the time on this useful plugin. It’s very handy for me that it provides a list of possible locations, rather than simple pulling off the first match like other plugins like Geokit do.
One small problem I noticed is that you’re not including the option to request UTF-8 from the Google geocode service. This messes up quite a few things in an application I’m working on because place names with accent marks get truncated after the first accented character.
To fix this, simply modify google.rb on line 38:
Before:
url << “output=xml”
After:
url << “output=xml&oe=utf-8″
Norman: That’s all set - new code uploaded to SVN.
Here’s how you set Google “locale”:
When you create your geocoder, you set this value. It will persist for all subsequent geocodings using that *instance* of the Geocoder.
Perfect! Thanks a lot, I’m glad in did a “-x” when I installed the plugin now. :-)