I'm working on a website where users will be able to register and provide information about their location. In order to prevent users from inputting incorrect data, we don't want users to provide free-text information but instead choose from predefined values as much as possible. We believe there are 2 ways of providing those values: use an API to an external service provider or create your own local database.


Some resources:
- https://developers.facebook.com/docs/reference/ads-api/get-autocomplete-data/
- http://developer.yahoo.com/geo/geoplanet/

-accuracy and completeness of data.
-no maintenance related to update of data as this it taken care of by API provider.
-easier/faster to get started (no need to create local database, just implement API).

-degradation of performance when availability issues with external API.
-outage due to changes to the external API (until your code is updated to reflect those changes).
-lock-in with external provider.

Local database

Some resources:
- http://developer.yahoo.com/geo/geoplanet/data/
- http://www.maxmind.com/app/geolitecity
- http://download.geonames.org/export/dump/

-no external dependency: improved stability and performance.

-more work to get started (you need to create the database and code to interact with it).
-risks of inaccurate/incomplete data, either initially or over time.
-more maintenance work to keep database up to date.

Assuming the depth information requested from users is as follows:
-country: interested in value. also used to narrow down list of regions.
-region (state in the US, county in the UK...): not interested in value itself, only used to narrow down list of cities.
-city: interested in value (which can be used to work out related region should we need regional statistics).
-address: interested in value although OPTIONAL.

Which option (whether API or local database) would you choose? What tips you would give for the implementation? What other resources can you share?

3 Answers 3


While my IP is dynamic (DHCP) it's never accurate to my city at times the city can be 60 miles away. If you're application is forcing users to that city you're going to have a high bounce rate.

You're best bet is to use MaxMind IP to Country database which is stored locally and is faster than API's. Gather the country of the IP behind the scenes don't force the user to provide it. Then gather the region from another database, again not when users are registering.

When asking for this type of information from a user and trying to auto generate it and compare it against a database you're going to come across a lot of people leaving your site. What happens for people who are behind proxies, VPN's, or running Tor?

  • What happens for people who are behind proxies, VPN's, or running Tor? I believe that represents a neglectable portion of Internet users in general.
    – Max
    Mar 18, 2012 at 16:47
  • I would not neglect users because they are behind corporate firewalls, proxies, or the like. AOL for a very long time user proxies and that was for all of their dial-up users.
    – Anagio
    Mar 18, 2012 at 17:54

I would re-emphasize the importance of validating the information you collect. After all, if it's important enough to collect it, you better make sure it's correct against the right authorities/sources. If it's not that important, why collect it at all and burden the user?

I work for SmartyStreets where we validate users' locations, specifically their addresses, and so I've solved a number of problems like these. I would next suggest that an API is the most robust solution to provide value to you. In other words, from your pros and cons lists, the difference is clear: building a local database is much more costly than potential, minimal side-effects of using a professional API.

One of the most effective ways to achieve accurate user geolocation is by collecting specific, correct information from them. While many people collect addresses, few make sure that it's a correct address which actually exists. Google and Yahoo and similar services do not provide this: beware that they perform address approximation not verification, and their results are best guesses.

For US addresses, the USPS CASS-certifies a handful of vendors to provide their authoritative address and location data to other people. You can Google for these yourself, but what you're looking for is something like LiveAddress API, which will verify and geolocate US addresses.

I can tell you we've invested considerable resources to build and maintain the database, risks, and other cons you mentioned about building your own database. We've also tackled the cons that you listed about an API. See the SLA for details and keep in mind we're the only vendor whose API is geo-distributed across 3 redundant datacenters to ensure performance and uptime. In other words, it's blazing fast and requests are processed in parallel.

Using modern (HTML5, etc) geolocation features are accurate to an extent but even right now their compatibility is restricted to the more modern browsers in ideal settings (I grew up in Iowa where geolocation is a far cry from urban areas). But obtaining and verifying a user's address is a sure way to get what you need, if it's really necessary. That is what I would do.


There are two approaches if you want to access your visitors' country, region and city data with address as optimal.

First, you may use IP geolocation services. It detects your visitors' locations based on their IPs. It's pretty straightforward, but only country/state/city level data is available. Also, such data won't be accurate if visitors use VPN or proxy(which assigns visitors a IP pointing to another physical location instead of real locations). Among conducting marketing strategy, it is still quite popular.

Second, if accuracy is your priority, you may consider HTML5 Geolocation API. It accesses your visitors' accurate latitude/longitude data. You can implement geocode API to further get your visitors detailed location data, even with street address. The limitation is it needs visitors permission sharing their location. Some users might not be willing to. Besides, it is not widely supported by all browsers yet.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.