Improved geocoding in CiviCRM

Translate this post

Photo by W.carter, CC0.

new geocoder extension released by the Wikimedia Foundation addresses some of the geocoding issues experienced by CiviCRM users. This is timely for CiviCRM users using Google as their geocoding provider who are considering how Google changes to its service affect them and whether they are operating within Google’s terms of service.
Geocoding is the process of getting latitude and longitude data (and sometimes other data) for addresses stored in the CiviCRM database. Usually this is done by using an outside service provider,with Google being the most common. However, we strive to use open source service providers that align with our commitment to privacy where possible. In this case we opted to use a locally stored open source data set. We initially set up a custom mechanism for updating from this data but found that it was then not available in various search functions. So we decided to tackle our need in a generic way and make it available to the community at large.
Our geocoding extension uses a generic library which potentially offers many providers, but the ones currently available are OpenStreetMap, MapQuest, and Google Maps and a local look up table.


  • No more fatal errors if you exceed your geocoding quota!
  • You can now configure multiple geocoder providers – if one does not provide coordinates then it will try the next one
  • You can look up a local database for coordinates by postal code for configured countries
  • You now have control over what other data from the provider is retained (e.g timezone, city might be known for an address by them but not by your site).

In general the configuration is available via the API rather than a form. But for most sites the default config will be fine – it is:
Default provider:  OpenStreetMap unless you were already using Google, in which case it will continue to use Google. OpenStreetMap  is an open data provider and does not require any API keys.
Fallback provider: If you are already using Google then OpenStreetMap will be configured as a fallback provider, and used if you exceed your limit with Google or it cannot be found by Google. In both cases a further fall back for US sites is a postal code lookup.
Data retention:  By default any lookups using the DB table will store timezone in addition to latitude and longitude. They will also ‘fill’ State & City if they are not already known.


We needed to clean up the core CiviCRM code to remove some blockers to this extension. Ginkgo Street Labs collaborated with us on that.

Other Wikimedia Foundation extensions

Some other CiviCRM extensions that we have not promoted to date:
Unsubscribe email: creates a screen for doing data-entry on unsubscribe requests
Contact editor provides a menu action on the contact summary screen to change contact type (e.g when an Organization was mis-entered as an individual)
RIP: add opt out flag on deceased contacts
Eileen McNaughton, Software Engineer, Fundraising Tech
Wikimedia Foundation

Archive notice: This is an archived post from, which operated under different editorial and content guidelines than Diff.

Can you help us translate this article?

In order for this article to reach as many people as possible we would like your help. Can you translate this article to get the message out?

Inline Feedbacks
View all comments

Awsome !! This makes me happy.

Thanks Eileen and thanks WMF for these useful extensions. We’re going to shift our CiviCRM clients away from Google geocoding immediately as a result of their new onerous terms of service.