Geocoder adds object geocoding and database-agnostic distance calculations to Ruby on Rails. It’s as simple as calling fetch_coordinates! on your objects, and then using a scope like Venue.near("Billings, MT"). Since it does not rely on proprietary database functions finding geocoded objects in a given area works with out-of-the-box MySQL or even SQLite.
Geocoder is compatible with Rails 2.x and 3.x. This is the README for the 3.x branch. Please see the 2.x branch for installation instructions, documentation, and issues.
Add this to your Gemfile:
gem"geocoder"
and run this at the command prompt:
bundleinstall
At the command prompt:
rails plugin install git://github.com/alexreisner/geocoder.git
A) Add latitude and longitude columns to your model:
rails generate migration AddLatitudeAndLongitudeToYourModel latitude:float longitude:float rake db:migrate
B) Tell geocoder where your model stores its address:
geocoded_by:address
C) Optionally, auto-fetch coordinates every time your model is saved:
after_validation:fetch_coordinates
Note that you are not stuck with the latitude and longitude column names, or the address method. See “More On Configuration” below for details.
Assuming obj is an instance of a geocoded class, you can get its coordinates:
obj.fetch_coordinates# fetches and assigns coordinatesobj.fetch_coordinates!# also saves lat, lon attributes
If you have a lot of objects you can use this Rake task to geocode them all:
rake geocode:all CLASS=YourModel
Once obj is geocoded you can do things like this:
obj.nearbys(30) # other objects within 30 milesobj.distance_to(40.714, -100.234) # distance to arbitrary point
To find objects by location, use the following scopes:
Venue.near('Omaha, NE, US', 20) # venues within 20 miles of OmahaVenue.near([40.71, 100.23], 20) # venues within 20 miles of a pointVenue.geocoded# venues with coordinatesVenue.not_geocoded# venues without coordinates
Some utility methods are also available:
# distance (in miles) between Eiffel Tower and Empire State BuildingGeocoder::Calculations.distance_between( 48.858205,2.294359, 40.748433,-73.985655 ) # look up coordinates of some location (like searching Google Maps)Geocoder::Lookup.coordinates("25 Main St, Cooperstown, NY") # find the geographic center (aka center of gravity) of objects or pointsGeocoder::Calculations.geographic_center([ city1, city2, city3, [40.22,-73.99], city4 ])
You are not stuck with using the latitude and longitude database column names for storing coordinates. For example, to use lat and lon:
geocoded_by:address, :latitude=>:lat, :longitude=>:lon
The string to use for geocoding can be anything you’d use to search Google Maps. For example, any of the following are acceptable:
714 Green St, Big Town, MO Eiffel Tower, Paris, FR Paris, TX, US
If your model has address, city, state, and country attributes you might do something like this:
geocoded_by:locationdeflocation [address, city, state, country].compact.join(', ') end
Please see the code (lib/geocoder/active_record.rb) for more methods and detailed information about arguments (eg, working with kilometers).
You can also set the timeout used for connections to Google’s geocoding service. The default is 3 seconds, but if you want to set it to 5 you could put the following in an initializer:
Geocoder::Configuration.timeout = 5
If you need reverse geocoding (lat/long coordinates to address), do something like the following in your model:
reverse_geocoded_by:latitude, :longitudeafter_validation:fetch_address
and make sure it has latitude and longitude attributes, as well as an address attribute. As with regular geocoding, you can specify alternate names for all of these attributes, for example:
reverse_geocoded_by:lat, :lon, :address=>:location
If you apply both forward and reverse geocoding functionality to the same model, you can provide different methods for storing the fetched address (reverse geocoding) and providing an address to use when fetching coordinates (forward geocoding), for example:
classVenue# build an address from street, city, and state attributesgeocoded_by:address_from_components# store the Google-provided address in the full_address attributereverse_geocoded_by:latitude, :longitude, :address=>:full_addressend
However, there can be only one set of latitude/longitude attributes, and whichever you specify last will be used. For example:
classVenuegeocoded_by:address, :latitude=>:fetched_latitude, # this will be overridden by the below:longitude=>:fetched_longitude# same herereverse_geocoded_by:latitude, :longitudeend
The reason for this is that we don’t want ambiguity when doing distance calculations. We need a single, authoritative source for coordinates!
Those familiar with Google’s Geocoding API know that it returns much more information than just an address or set of coordinates. If you want access to the entire response you can use the Geocoder.search method:
results = Geocoder.search("McCarren Park, Brooklyn, NY") r = results.first
r is now a Geocoder::Result object which has methods like the following:
r.geometry
=> {
"location"=>{"lng"=>-79.3801601, "lat"=>43.6619568},
"location_type"=>"ROOFTOP",
"viewport"=>{
"northeast"=>{"lng"=>-79.3770125, "lat"=>43.6651044},
"southwest"=>{"lng"=>-79.3833077, "lat"=>43.6588092}
}
}
r.address_components_of_type(:neighborhood)
=> [{
"long_name"=>"Greenpoint",
"short_name"=>"Greenpoint",
"types"=>["neighborhood", "political"]
}]Please see the Geocoder::Result class for more information, as well as Google’s API documentation (code.google.com/apis/maps/documentation/geocoding/#JSON).
SQLite’s lack of trigonometric functions requires an alternate implementation of the near method (scope). When using SQLite, Geocoder will automatically use a less accurate algorithm for finding objects near a given point. Results of this algorithm should not be trusted too much as it will return objects that are outside the given radius.
It is also not possible to calculate distances between points without the trig functions so you cannot sort results by “nearness.”
There are few options for finding objects near a given point in SQLite without installing extensions:
Use a square instead of a circle for finding nearby points. For example, if you want to find points near 40.71, 100.23, search for objects with latitude between 39.71 and 41.71 and longitude between 99.23 and 101.23. One degree of latitude or longitude is at most 69 miles so divide your radius (in miles) by 69.0 to get the amount to add and subtract from your center coordinates to get the upper and lower bounds. The results will not be very accurate (you’ll get points outside the desired radius–at worst 29% farther away), but you will get all the points within the required radius.
Load all objects into memory and compute distances between them using the
Geocoder::Calculations.distance_betweenmethod. This will produce accurate results but will be very slow (and use a lot of memory) if you have a lot of objects in your database.If you have a large number of objects (so you can’t use approach #2) and you need accurate results (better than approach #1 will give), you can use a combination of the two. Get all the objects within a square around your center point, and then eliminate the ones that are too far away using
Geocoder::Calculations.distance_between.
Because Geocoder needs to provide this functionality as a scope, we must go with option #1, but feel free to implement #2 or #3 if you need more accuracy.
You cannot use the near scope with another scope that provides an includes option because the SELECT clause generated by near will overwrite it (or vice versa). Instead, try using joins and pass a :select option to the near scope to get the columns you want. For example, in Rails 2 syntax:
# instead of :includes => :venues:City.near("Omaha, NE", 20, :select=>"venues.*").all(:joins=>:venues)
If anyone has a more elegant solution to this problem I am very interested in seeing it.
support different ORMs (DataMapper, Mongoid, etc)
use completely separate “drivers” for different AR adapters?
seems reasonable since we’re using very DB-specific features
also need to make sure ‘mysql2’ is supported
make ‘near’ scope work with AR associations
Copyright © 2009-11 Alex Reisner, released under the MIT license