alt Hacker NewsGeocoding APIs compared: Pricing, free tiers and terms of use
Comments
Hi, Ed here, one of the founders of OpenCage. This comparison is a bit shallow to be honest, as it basically just looks at price. Of course price is important, but as someone who has worked on geocoding for 10+ years and helped literally thousands of customers there are many more factors to consider depending on your needs.
For example: quality (not generally, but versus your actual input data), terms & conditions of what you can do with the data, support, data enhancements (things like timezones, etc, etc), ease of use, documentation, terms of payment, and more.
The only real answer to "which geocoding service is best" is "it depends".
We have a comprehensive geocoding buyer's guide on our site: https://opencagedata.com/guides/how-to-compare-and-test-geoc...
Please get in touch if you need geocoding, hapyp to tell you if your needs are a good match for our service. Happy also to tell you if not.
I love seeing all the great comments in here about the different APIs and the features they do and don't offer, but I want to point out that the underlying data for addresses is incredibly hard to find. The reason the commercial geocoding providers won't let you store their data is because they're worried you'll store enough data to build your own geocoder.
To help with this, a group of folks (including me) started OpenAddresses (https://openaddresses.io/ and https://github.com/openaddresses/openaddresses/) with the goal of finding every open address dataset in the world. We produce a zip file with 100M's of addresses that several of the APIs mentioned in this thread use as a major part of their dataset. We've been going for well over 10 years now, but it would be great to have more eyes looking for more address sources. Check us out!
The killer host-it-yourself component which mostly flies under the radar is Photon: https://github.com/komoot/photon
I'm simplifying slightly, but it's essentially OSM's Nominatim geocoder data with a ready-to-download db, autocomplete capabilities, and a single .jar to install. If you're happy with the limitations of OSM's data (basically, patchy housenumber coverage) then it's easy and fast.
Opencage is pretty decent value if your use case fits within what it can do. It has some limitations (e.g. limited support for house numbers and commercial place names) but it has some redeeming features and a generous free tier and rate limits. If it's good enough, the price/performance/quality ratio might be hard to beat. If it isn't, there are more expensive alternatives.
Ed Freyfogle (the founder) is a nice person, very knowledgeable about all things geo, pretty approachable and co-runs the geomob podcast (worth checking out), associated meetups (worth going to). If you are unsure, get your free API key and just give it a try. His documentation is awesome and the API is really easy to get started with.
Disclaimer, Ed's a friend and I'm a user of his product.
https://www.geoapify.com is really nice has has some react components you can quickly hit the ground running with.
One good test of geocoding API's is to put in a PO Box-only ZIP code like 22313. If you get back Alexandria VA near 38.82 N -77.05 W then you've found a decent geocoding API. If you get no location back or if you get some other place, you're going to have a bad time in production, based on my experience.
There is another option.
- Get a (cheap) docker capable server.
- Install the OSM/Nominatim stack using docker.
Setting this up used to be a pita, but due to docker its super easy.
This has a couple of benefits.
Like fixed, predicable costs. You can whatever you want without thinking about weird API points which costs a random amount of money. You can serve whatever traffic you want and a cheap v-server gets you an astonishingly long way. There are no 3rd-party privacy issues you can just embed your maps without annoying cookie banners.
I've found Geocodio to be a good option too, especially if you need to do batch processing: https://www.geocod.io/
I was hoping for information on the ACCURACY of these sources.
My team has had issues where SIEM alerts are difficult to investigate because Microsoft inaccurately declares an IP geographically distant, then fires a second alert for "Atypical travel" since they seem to have traversed a vast distance between logging in on say, one's laptop and mobile.
(For whatever reason, mobile IPs, specifically IPv6 IPs, are the worst)
For me it's not an issue of cost, it's that if the data is inaccurate it is worse than useless -- it eats up my time chasing bad SIEM alerts.
Sadly this article just compares pricing. When we were using Google instead of HERE, results were mostly better but not worth the price. I would rather see some opinions on the quality of results and examples where each API shines and fails. Price without mentioning features and quality is incomplete information. People wont make decisions just based on the price.
Since this article was written, we've (Stadia Maps) also launched and made significant progress with our own Geocoding API: https://stadiamaps.com/products/geocoding-search/
It was originally based on Pelias, but we've since augmented with additional data sources (such as Foursquare OS Places) and significantly improved the baseline for performance and accuracy.
Happy to answer questions on the topic!
For a newer list I would add the mapbox API as well.
So I work in data analytics, not so much web-mapping. For those applications, IMO local solutions, like ESRI, are good options if you are limited to addresses in the US, https://crimede-coder.com/blogposts/2024/LocalGeocoding.
Googles TOS was that you can't even cache the results, https://cloud.google.com/maps-platform/terms. So saving to a database and doing analysis of your data is not allowed AFAICT.
This is a pretty incomplete comparison. It only seems to be for real-time non-stored use cases and doesn't even include AWS or the US Census Bureau's free API.
This is a few years old now:
> The article was updated on June 26, 2023, to include LocationIQ per the provider's request.
There are a few more options now (Stadia, Geocodio, among others). And I'm surprised this doesn't include MapBox, which surely existed then and has (comparatively) reasonable prices.
I have an admittedly resource-intensive, self-hosted, podman/docker-based slippy map product prototype. Briefly, it incorporates the nominatim geocoder, the valhalla routing engine, a map tiler, and PostGIS. One of its front-ends is https://github.com/nilsnolde/valhalla-app. If you are interested in participating in a beta test, please email me at my work address [email protected].
Missing ArcGIS Location Platform: https://location.arcgis.com/pricing/#geocoding
Positionstack is missing from the comparison, so I spare you the story how they had a weeks long outage right after I implemented it in our software...
The trouble with most of the geo and map stuff is, that pricing is one dimension, but most of them have very different rules regarding usage. For example some prohibit you from persisting the geocoded locations. Others want you to pay more if you do something they consider "asset tracking".
No mention of OpenRouteService, which you can spin up locally yourself and which offers a variety of similar services:
I actually don't see anywhere on the Nominatim website that restricts commercial usage contrary to the article's comparison chart,
Geocodify is another strong option, especially if you need batch processing at a good price — see geocodify.com
Geocoding is a really fun (and sometimes frustrating) problem I've been lucky enough to have been working to solve for over 10 years now.
I joined Mapzen in 2015 which ostensibly was part of a Samsung startup accelerator, but looking back, it's more descriptive to say it was an open-source mapping software R&D lab. We built what is now foundational open-source geospatial tools like the Pelias geocoder (my team) and the Valhalla routing engine. A lot more projects like the Tangram map renderer are still really useful post-Mapzen.
A reasonable, but very wrong, first assumption about geocoding is that with a database of places you're almost there. Inputs are often structured, like some addresses, but the structure has so many edge cases you also have to effectively consider it unstructured. The data is the same, sometimes worse as a lot of data sources are quite bad.
Over the last 10 years we've explored most strategies for full text search, and no ONE solution knocks it out of the park. We started with really simple "bag of words" search, just looking at token matches. That, fairly predictably was mostly a mess. With billions of places in the world recorded in open datasets, there's going to be something irrelevant somewhere that matches, and probably drowns out whatever you're looking for.
Parsing inputs for structure is an enticing option too, but for any pattern you can come up with, there's either a search query or some data that will defeat that structure (try me).
The previous generation of ML and a lot of sweat by Al Barrentine produced libpostal(https://github.com/openvenues/libpostal), which is a really great full-text address parser. It's fast and accurate, but it doesn't handle partial inputs (like for autocomplete search), doesn't offer multiple parsing interpretations, and still isn't always right.
What we've settled on for now for autocomplete is a pretty sophisticated but manually configured parser, which can return multiple interpretations and is also quick to fall back to "i don't know" (how can you really parse meaning out of a short input like "123": is it the start of a postalcode? a housenumber? the name of a restaurant?). It's also runtime bound to make sure it always returns in a few milliseconds or less, since autocomplete is extremely latency sensitive. Then we can either search with the benefit of more structure, or worst case fall back to unstructured, with a LOT of custom logic, weights, filters, and other tricks as well.
A big question right now is will next generation LLMs completely solve geocoding, and honestly I'm not sure. Even older ML is really eager to over-generalize rules, and while newer LLMs do that less, they also still hallucinate, which is pretty much a dealbreaker for geocoding. At least for now LLMs are also orders of magnitude too slow, and would never be cost effective at current prices. Personally I think us geocodeurs will be in business a while longer.
There's so much more about geocoding I love talking about, it's truly a niche filled with niches all the way down. This is the sort of stuff we are always iterating on with our business Geocode Earth (https://geocode.earth/). We think we have a really compelling combination of functionality, quality, liberal usage license (hi simonw!), respect for privacy, and open-source commitment. We always love hearing from people interested in anything geocoding so say hello :)
(2023)
What is the best SSID to location service?
Somewhat related, what are some recommended IP geolocation providers today in 2025 and associated cost?
Nice. I need to batch process my entire database of addresses (100M entries), so only local Nominatim will work.
This is advertising and also most of that can be done with openstreetmap data instead of an API, I'd expect.
This document mentions attribution requirements, doesn't touch on the questions I'm most interested in with respect to geocoding APIs:
- Can I store the latitude/longitude points I get back from the API in my own database forever, and use them for things like point-in-polygon or point-closest-to queries?
- Can I "resyndicate" those latitude/longitude points in my own APIs?
I've encountered quite a few popular geocoding APIs (including Google's) that disallow both of these if you take the time to read the small print. This massively limits how useful they are: you can build a "show me information about this location right now" feature but if you have a database of thousands of addresses you can't meaningfully annotate data in a way that's valuable in the medium-to-long-term.
The API thing matters because it's not great having location data in your database that you can't expose in an API to other partners!
I really like OpenCage for exactly this reason: https://opencagedata.com/why-use-open-data
"Store geocoding results as long as you like. Keep results even after you stop being a customer."