Comparing and testing geocoding services

This guide is for developers approaching a project involving geocoding.

You will learn all the factors to consider in evaluating whether a specific geocoding solution is right for your project. Our goal is to help you avoid "I wish I had thought of that before we started" moments.

Key takeaways are at the top and the full guide below.

evaluating geocoders

Key Takeaways

  • Consider ALL the relevant criteria when evaluating solutions. Technical correctness and cost will always be critical, but there other attributes that you should also evaluate.
  • Understand and test your specific needs. Evaluate services versus your actual needs. Don't just blindly trust someone else's random internet recommendation, their needs (and data) were probably different.
  • Total Cost of Ownership is real. Before you commit, make sure you understand the financial cost of using a service, but also the terms and conditions, maintenance and support costs, and contractual lock-in.

Background / Context

There are a lot of services and tools that provide geocoding, from well-known large providers like Google Maps to small specialists like us here at OpenCage. There are also open-source tools you can run yourself, or you can develop your own solution. However, the science behind geospatial is complex and is an entire field of study in itself.

Before diving into evaluating specific solutions it's important to ensure you understand a few basic concepts and architectures.

Reverse vs. Forward

The process of converting an address to a latitude/longitude pair is known as "forward geocoding". The process of converting back the other way from a coordinate pair to an address is known as "reverse geocoding".

Example
Forward geocoding
Input Philipsbornstraße 2, 30165 Hanover, Germany
Output 52.387783, 9.7334394

Reverse geocoding
Input 52.387783, 9.7334394
Output Philipsbornstraße 2, 30165 Hanover, Germany

Some tools and services offer both forward and reverse geocoding, while others provide or specialize in only one. Each type of geocoding has its own technical challenges. Within forward geocoding you may have exact addresses or perhaps you have "places" or "POIs" (points of interest). In some regions addresses are not widely used, and instead "nearby landmarks" are a more common way of referencing locations.

Finally, geocoding differs from "geosearch", also commonly referred to as "location autosuggest" (see our guide to the difference between geocoding and geosearch), which is typically used for real-time location search, often on a map.

Example
Geosearch / Location Autocomplete
Input par
Output Paris, France
Key question: Does the provider offer the specific services you need?
Check if there are combined or separate techniques or charges for each type of geocoding.

Build vs. Buy

The decision to pay for an external service or to build and maintain one in house is almost as old as software development.

There are now numerous open source geocoding software projects. Running your own service is easier than ever as freely available open data sources like OpenStreetMap make large volumes of data available.

But managing large volumes of data can make maintenance a real challenge. As an example, OpenStreetMap has 4-5 million edits per day, every day. Maintaining that sort of complexity is not within everyone's skill set, and many organizations prefer to hand the task to someone else for a reasonable fee.

It can make sense to build and run your own geocoder when:

  • Your requirements are very unique
    No commercial service provides exactly what you need.
  • Your requirements are very basic
    You only have limited or basic needs that will not be complicated to build and maintain. This is especially the case if the underlying data does not change frequently.
  • You have the needed skills in-house
    and are likely to always have capacity in your team to maintain your solution.

In Chapter 3 of our Guide to Reverse Geocoding we provide a detailed list of things you should consider in building your own geocoder. In Chapter 4 of the guide we provide a detailed tutorial on building your own geocoding service.

The option of using existing open source geocoders (for example OpenStreetMap's Nominatim), is appealing to many companies, and it can certainly be a workable solution. Nevertheless, many organizations underestimate the on-going maintenance challenge. The world is continually changing, and your underlying dataset will need to be refreshed regularly. Over the years we have had many customers transition from hosting and running their own Nominatim to OpenCage. We've prepared a guide that outlines the main differences between Nominatim and OpenCage.

Using a third-party service makes sense when:

  • You lack the skills or desire to run and maintain your own geocoding service
  • Your requirements are not particularly unique
    This is especially the case if your needs will not be long-term.
  • You need to move quickly

If your requirements are very unique a public service like OpenCage may not be the right match for your needs. We have several clients for whom we run custom geocoding solutions at very high volume. Please see our enterprise solutions page if you are in a similar situation.

The right answer to the build versus buy question depends on your project requirements, technical ability, and willingness to maintain the service.

Geospatial represents a unique software AND data challenge.

Points to Evaluate

Let's dive into specific topics to consider when evaluating geocoding solutions. Some are obvious, but others may be more subtle, and thus easier to overlook until too late.

teacher explaining geocoding

Developer Experience

A provider or service is only as good as it is usable. While evaluating, consider how easy it will be to build your application around the provider's API.

Start by looking at the "getting started" or "quick start" guide(s) and tutorials. Are they easy to follow, up to date, accurate, and result in a functioning application? Good guides and documentation often reflect a product and development team that cares and indicate a better developer experience overall.

Is the documentation clear and concise? Is this an API that follows standard patterns and practices for APIs or SDKs for the programming languages you use, or do you have to learn a new non-standard way to build an application? Are there integrations for common frameworks and tools? Is the service easy to test and experiment with?

Key question: Is the service easy to use?

At OpenCage we offer SDKs for over thirty (30) different programming languages and frameworks. You can play with a live demo of our geocoding API, dive into the quick start examples, or browse the full geocoding API documentation.

Correctness

It sounds obvious that the geocoder needs to provide the correct answer, but actually there is a lot of subjectivity in the word "correct".

Here are some points to consider:

  • Is the API response well documented?
  • Do you get any sort of boundaries or bounding box?
  • Is the output a jumble of data that you need to clean up and format yourself, or has it already been formatted in the local format for you?

    Example: Reverse geocode for 38.70900, -9.13246

    OpenCage Rua dos Bacalhoeiros 8, 1100-135 Lisbon, Portugal
    Other geocoder 8, Rua dos Bacalhoeiros, Sé, Alfama, Santa Maria Maior, Lisbon, 1100-135, Portugal
  • Does the response give any sort of precision measurement?
  • What exactly do you receive as the "answer"? Is it just a string, or do you also get back structured data?

    Example of the structured data, precision score, and well-formatted display string you get back with OpenCage

    "components": {
      "ISO_3166-1_alpha-2": "DE",
      "ISO_3166-1_alpha-3": "DEU",
      "ISO_3166-2": [
          "DE-NI"
      ],
      "_category": "building",
      "_type": "building",
      "city": "Hanover",
      "city_district": "Vahrenwald-List",
      "continent": "Europe",
      "country": "Germany",
      "country_code": "de",
      "county": "Region Hannover",
      "house_number": "2",
      "office": "Design Offices",
      "political_union": "European Union",
      "postcode": "30165",
      "road": "Philipsbornstraße",
      "state": "Lower Saxony",
      "state_code": "NI",
      "suburb": "Vahrenwald"
    },
    "confidence": 10,
    "formatted": "Design Offices, Philipsbornstraße 2, 30165 Hanover, Germany",
    
    
  • Can you change the language of the output?
    English Hanover, Lower Saxony, Germany
    German Hannover, Niedersachsen, Deutschland
    French Hanovre, Basse-Saxe, Allemagne
Key question: given your input data does the geocoder output the data you need, in the format(s) you need?

At OpenCage our API response is well documented, has well-formatted structured data (including a Each result has a confidence score, a well-formatted display string and structured components, and is available in local languages.

Test for yourself, generate an API response on the OpenCage demo page.

Pricing Model & Price

Assuming you work with a commercial provider there are many questions you should ask about their pricing.

  • Is the pricing transparent or does it require speaking with a salesperson?
  • Are there any set-up fees?
  • Is there a free trial of some sort for testing? If so, what are the limitations of the trial?
  • Is the pricing subscription-based, one-time fee, or usage-based, or some combination.
  • Once you are a customer, can you cancel whenever you like, or are you locked in?
  • Can you pay in your preferred currency?
  • Are you able to accurately predict what your bill will be?
  • What happens if your usage increases? Will your bill shoot up? Will your account be blocked?
  • How has pricing and pricing model chaged over time?
  • Which payment methods are supported?
  • Is support available and included in the price?

With commercial services the price you will pay is - despite all the pricing model parameters discussed above - generally able to be estimated. If, however, you decide to develop and/or operate your own service, a key factor to weigh up is the opportunity cost. Every minute spent on development and maintenance is a minute not spent on something else.

A final point: make sure you are comparing apples with apples - some services have limits on requests per day, other requests per month. Others quote prices in cost per 1000 API requests (cpm). You may need to do a bit of calculation to compare like with like.

A comparison of OpenCage vs Google geocoding pricing
geocoding API requests
daily / monthly
Google OpenCage
10,000 / 300,000 $1,100 $50
(x-small plan)
20,000 / 600,000 "contact sales" $100
(small plan)
100,000 / 3,000,000 "contact sales" $500
(medium plan)
500,000 / 15,000,000 "contact sales" $1,000
(large plan)

  • OpenCage pricing assumes a monthly subscription, but is even more affordable via an annual subscription. We also offer one-time plans.
  • Google pricing taken from this page and assumes full use of the $200 monthly credit.
  • Full details of OpenCage pricing.
  • All prices are in USD, but at OpenCage we gladly accept payment in many other currencies.
  • Unexpected surges will result in additional costs with Google, but do not with OpenCage. We win by being a stable, long-term partners for our clients, not by running a meter when they suddenly need a bit more.

Key question: do you understand the details of the provider's pricing model and do they align with your needs? How much will you pay for geocoding?

At OpenCage we offer transparent, predictable, self-service pricing. There are no set-up fees, customers can purchase one-time plans or subscriptions, and pay in their prefered major currency. Subscriptions can be cancelled any time for any reason. Increased usage doesn't result in an unexpected bill.

See all the details on the OpenCage pricing page.

Screenshot of the OpenCage pricing page
The OpenCage pricing page with various plans.

Data Protection / Privacy

Digital privacy is always a relevant concern for geospatial services. GDPR in the EU and similar legislation in other parts of the world has moved this issue to top of mind for business and end users.

It is important to ask the following questions when sharing data with third-party services like a geocoding API

  • Is the data secure while in transit? Can you make API requests via https?
  • Who is receiving the data?
  • Where (which jurisdictions) is it being processed?
  • How long is the data stored?
  • What ability do you as a customer have to influence or adapt these policies? Can you request increased privacy?

Key question: will your users' data be safe with your geocoding service provider?

OpenCage is an EU-based (German) business, and thus fully bound by GDPR. Please see our GDPR policy, or our guide to preserving privacy while geocoding.

We offer an optional privacy parameter. When set we do not log the geocoding queries we receive.

We have a long history of working with industries like healthcare where data protection is critical.

Openness / Data Terms of Use

Despite the plethora of services that provide mapping and location data, you can generally break these sources into open or closed/proprietary data.

Closed or proprietary data is typically created and maintained by one company or alliance of companies, and often has many restrictions. These can include the following limitations:

  • X Limits on how you can use the data in commercial applications.
  • X Limits on how long you can store the data. This can affect application performance and present caching issues.
  • X Limits on how your users can access the data, for example extra charges for usage behind a firewall or in multiple territories.
  • X Limits on how you can display the data, requiring you to use certain map brands or display their logo or other branding.
  • X You may need to delete the data if you stop being a customer.

If any of these factors, or others, are important to you and your use case, make sure to do thorough research, especially as often details are buried deep in terms and conditions or footnotes of payment details. Regarding payment and billing, providers that use proprietary data can cost more due to licensing charges but also because working around terms restrictions may cost you more. For example, if you’re not allowed to store data, you need to make more API calls, significantly increasing your costs.

Open data typically avoids these restrictions. See our guide to the benefits of open data.

In some countries governments have "opened" their official datasets, but typically, a diverse global community regularly contributes to and curates the data. This gives you (and your users) the opportunity to contribute to the data set, which means data fixes can be solved quickly and at the source.

Key question: Do the terms restrict what you can do with data in such a way that it limits your project? Are you able to correct data errors?

At OpenCage we use only open data. Here is a full list of our datasources. Our primary data source is OpenStreetMap, which means you can store data as long as you like, display it on any map, use it publicly or privately, for any usecase, on the web, in print, or behind a firewall. Our databases are 24-48 hours behind the public OpenStreetMap database, which means our customers get edits/corrections quickly.

Data Enrichment

Often geocoding is just one of many steps in a data processing pipeline. In today's data-rich world, location-based applications may need more than address data. There is a whole host of other useful information geographically-linked data and it may be worth considering if a provider supplies it.

This could be other forms of geographic references - some international, others used only nationally or in specific regions - that you will use to link the location with other datasets, things like geohashes, MGRS codes, Maidenhead codes, H3 reference, UN M49 codes, FIPS codes, what3words reference, or others. Or it could be information about the location, such as the local timezone, currency, country dialing code. The common reverse geocoding use case of vehicle tracking often needs information about the rod the vehicle is on, for example speed limits.

Key question: Does the geocoding service provide additional data? If so, does that data require an additional fee?

At OpenCage we enhance geocoding results at no additional cost with what we call annotations - all sorts of relevant useful information about the location to make developer's lives easier.

Support

Given the complex nature of geocoding it is almost certain you will at some point have technical questions. Who will you be able to turn to for answers? Does the geocoding service provide support? Are they responsive?

Internet giants like Google have a stellar technical relationship, but a terrible reputation for customer support.

You may consider sending a test question to your potential provider so you can see if, how quickly, and how competently they respond. Is support answered by an engineer who really understands the issue, or do you just get templated answers that are not applicable to your actual question?

If the provider does not offer support, are there online communities or forums where you can reasonably hope to find answers in a timely manner?

Key question: will you be able to get help when you need it? From whom?

At OpenCage we pride ourselves on responsive suppport. Feel free to contact us with any questions you may have.

Maintenance

Developers commonly overlook the on-going burden of maintenance. This can be considerable, especially if you are operating your own geocoding service. Keep in mind - the world is a continually changing place, you will need to refresh the underlying geodata. Technology doesn't sit still, there are always OS and security updates.

Another point to consider is redundancy. If this is a mission critical service will you set up and maintain fall back systems?

The pain of maintenance can be a strong argument for relying on a third-party geocoding API like OpenCage. This can reduce the burden considerably, but even APIs can and do change.

Key question: how much on-going time and effort will you have to invest to keep your geocoding service or integration working? How frequently has the service chaged in the past and with how much notice?

At OpenCage we have a public change log of all API changes. Changes are, intentionally, very rare.

Reliability

A geocoding service that always returns the correct location is nontheless worthless if it is down when you need it. What sort of service reliability and uptime will you need, and can you have confidence a service provider will meet it?

To consider:

  1. Does the service provide any public measurement of uptime?
  2. How quickly can you request data? Are there any limits and, if so, are they clearly documented?
  3. Do they report on past reliability?
  4. Do they have a clear escalation and communication procedure in the event of an outage?

It is worth spending a few minutes searching Twitter, Github issues, and other relevant places for comments from other developers about the reponse to past outages.

Key reliability question: are you confident your geocoding service will be available when you need it?

At OpenCage we operate multiple, fully-redundant datacenters. Our uptime is independently monitoried by a third-party. Current and historic data can always be found at status.opencagedata.com In addition, at the beginning of each year we publish an uptime report on our blog, where we review our reliability for the previous year. In 2021 we had 99.998% uptime. The next report will be published in early January.

Screenshot of the OpenCage status page
The OpenCage status page

Think Long-term

There is little point in investing time and resources into building applications and a business around a service or provider that promptly closes or changes drastically.

Both large and small, old and new providers have the potential to change their strategy, so look closely at the history of the company and its track record for supporting products. Read the fine print of terms and conditions to ascertain how much notice a company has to give of service changes and what options you will have to migrate from the provider. Some questions to ask:

  1. How long has the provider been in business?
  2. Who is the provider? Can you find out who is behind the company? Can you find their postal address on the website?
  3. How are they funded? Are the backed by VCs, and thus likely pushing for an exit or acquisition (and the resulting product disruption)?

A similar approach applies to open source projects, which can also become abandoned by maintainers or slow down in response to fixing issues or adding feature requests. There's less you can do to protect yourself from these changes, but you can check if a project has a vibrant commmunity, uses standard data formats, or has a method for you to migrate away from it if need be.

Key question: will this provider still exist in a few years? Is the provider transparent about changes and is this a relationship you can depend on?

At OpenCage we are a privately-owned, profitable business, and have operated our geocoding API since 2014, it is the core of what we do. We commmunicate actively via our blog and twitter account.

Work with Good Citizens

One final factor you may wish to consider is whether the service provider you will be funding is a good corporate citizen. Are they giving back to the geospatial open source and open data ecosystem?

Key question: Is this a business you want your fees to support?

At OpenCage we are proud to be corporate members of the OpenStreetMap Foundation, regulaarly sponsor events, fund and contribute to the development of various open geospatial projects, and run Geomob, a podcast and series of events to promote geo-innovation. On our "About" page you can find a full list of our efforts to give back to the geospatial commmunity.

Preparing your test

houses and coordinates

Understand Your Requirements

Often developers dive into technical details without really understanding the needs behind the project. You will be in a much better position to evaluate solutions if you first understand which requirements are critical and which are "nice to have".

Here are some of the questions it may be helpful to ask BEFORE you start the process of evaluating potential solutions.

  • How many locations will you need to geocode?
  • To which level of precision? Some projects need roof-top level precision, others neighbourhood level (like a dating app), some statistical region, some only country level.
  • Are there any legal concerns around who you share your data with (for example can the data not leave a certain jurisdiction)?
  • Do you need linked data (annnotations) like speed limits, etc?
  • How are disputed regions handled?
  • How critical is latency? Is this geocoding happening in real time, or is it a once a night process that just needs to finish before morning?
  • How long will you store the data?
  • Is this a one-time task, or will there be an on-going need?
  • What happens with the data next, after geocoding? What are the technical and legal implications?

Finally, are these requirements fixed, or are any of them flexible? Compromising on some points may allow you to consider a much more affordable solution.

Our recommendation: spend the time to understand your data and requirements.

Don't choose (and pay for) a sports car if you really need a truck.

Understand the Tool

Different commercial geocoding services operate differently. Each has unique technical specifications. Features that are on by default for one service may be optional (or not exist at all) for another. There's no real shortcut, you need to dive into the documentation and understand what the tool you are testing is doing.

Our recommendation: invest the time to understand the technical possibilities and constraints of the service you are considering using.

Be confident you are using the tool correctly.

See the OpenCage geocoding API documentation and best practices for using the API.

Use Realistic Data

Providers tend to use example data in the documentation and marketing copy that is cleaner and more perfect than address data from the real world. It’s important to test with the kind of data that you need to process regularly and see if what you are evaluating can handle it.

Doing a simple test with your home address is nice, but it is also meaningless. You need to really test.

Our recommendation:

  1. Randomly select a few dozen locations from your actual dataset. Does the input data make sense or are there and obvious problems? If so fix them (see "Cleaning your data" below).
  2. Make sure your test set is truly representative of the data in your project. As an example if your project requires geocoding addresses from several countries, test data for each country.
  3. Geocode the locations and then manually review the results. Does the output make sense given the input?
  4. Scale up and turn the manual steps into code. Are you able to programmatically get the information you need?

Cleaning your data

Developers make many assumptions about address and place data, while in reality geographic data is represented in very different ways around the world.

Assumptions aside, people are frequently inconsistent or make mistakes when entering addresses. For example, using abbreviations, leaving out or misspelling address components, adding or selecting incorrect details, putting them in the wrong order, or adding duplicated or conflicting information.

Some geocoding services offer data cleaning and sanitization, offering suggestions to partial or incorrect address data, while others simply return errors if they can't geocode the data. If you anticipate a lot of poor-quality data, it's worth considering a service that helps you improve it. It may be worth investing the time develop your own cleaning process before geocoding to eliminate common errors unique to your data pipeline. No third-party service knows your data better than you do.

Our recommendation:

See our detailed guide to query formatting for a long list of examples of mistakes developers often make.

OpenCage query formatting guide
The OpenCage guide to query formatting dos and don'ts

Conclusions

There are many factors to weigh when evaluating geocoding solutions. You need to test your data data and understand your specific use case rather than blindly trusting well-intended, but irrelevant, online recommendations.

Consider ALL relevant attributes to avoid making a mistake when deciding on a geocoding solution.

Next Steps

If you are ready to test the OpenCage Geocoding API you can do so without registering on the public API demo page.

For a deeper test, sign up for a free trial. Registering takes two minutes and requires just an email address. Your API key will allow 2,500 geocoding API per day while testing.

Further Reading

Ready to go deeper? You may enjoy:

Please contact us if anything in this guide was unclear or you have further questions.

Start your free trial

2,500 geocoding API requests per day.

No credit card required.