Comparing and testing geocoding services

Key Takeaways

Background / Context

There are a lot of services and tools that provide geocoding, from well-known large providers like Google Maps to 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".

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.

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
  You 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.

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.

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?

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",
    "_normalized_city": "Hanover",
    "_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

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 changed 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	Google	OpenCage
10,000 / day	$1,100 / month	$50 / month
30,000 / day	"contact sales"	$125 / month
125,000 / day	"contact sales"	$500 / month
300,000 / day	"contact sales"	$1,000 / month

• 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.
• Of course nothing stops you from using both OpenCage AND Google. Some of our customers do and typically cut their costs by 80-90%. Read our guide.

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?

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:

• Limits on how you can use the data in commercial applications.
• Limits on how long you can store the data. This can affect application performance and present caching issues.
• Limits on how your users can access the data, for example extra charges for usage behind a firewall or in multiple territories.
• Limits on how you can display the data, requiring you to use certain map brands or display their logo or other branding.
• 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.

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 UN/LOCODEs, 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.

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?

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.

Reliability

A geocoding service that always returns the correct location is nonetheless 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, Mastodon, GitHub issues, and other relevant places for comments from other developers about the response to past outages.

Combining Services

Different services have different strenths and weaknesses. The right solution for your needs may be to combine multiple services. While on the one hand this can add a bit of complexity it can allow you to get the benefits of each service.

As an example, many customers use our geocoding API in combination with other more expensive services: by using us for their first pass they are able to significantly reduce their geocoding costs. See our guide to using OpenCage in combination with Google maps geocoding for details.

Using multiple services does mean you will need to pay for both, understand the attributes of each service, and obey two sets of terms and conditions, but that overhead can be worth it to create the best or most cost-effective solution for your specific needs.

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 community, uses standard data formats, or has a method for you to migrate away from it if need be.

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?

Preparing your test

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 (annotations) 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.

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.

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.

As a convenience we provide sample address and coordinate lists you can use for testing, but really you should test with a representative sample of your own data.

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.

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:

• OpenCage geocoding API documentation
• OpenCage guide to reverse geocoding
• Language-specific geocoding tutorials and code examples
• SDKs for 30+ programming languages

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