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!
That is a very important point that I also was surprised wasn't mentioned. Google offers amazing APIs regarding locations and places, but they are expensive and prohibit you from storing it in any meaningful way.
I was surprised to see AWS' location service wasn't compared in this write-up. They are unique in that they offer both options. They ask when you provision the service if you plan on storing the data. The service works the same, but the cost is 8x. A fair trade, if your use-case involves referencing that data often.
If you think that is a fair trade I would love the chance to talk with you and save you A LOT of money.
Our experience (10+ years of offering a geocoding service) is that many people (of course depending on exact needs and use case) are significantly over-spending and could be using open data to reduce costs by 80+%.
Not being able to store results also can limit usefulness of the geocoding API itself. I have seen cases where the licensing limits affect cache TTLs and end up requiring many more API calls (latency) than would otherwise be necessary.
I'd be willing to bet most users just ignore that bit of the terms...
They're surely going to just have a column for 'user_country' in their users database which is prepopulated from the users IP and used for all kinds of uses.
Just do it anyway. The age of AI has shown that none of these terms matter. It doesn't stop the big boys, there is essentially no risk of being caught, so why let them keep that boot planted on your face?
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".
Hey, I’m acutely in the market (considering moving away from Google)
2 Qs:
1. How does OpenCage correctness/completeness compare to Google Maps API, especially in rural and industrial regions where you have addresses like “AcmeCo Industries, 234-XY Unit C, Jebel Ali Free Zone, Dubai”? I’d like to confidently query the most precise location that still matches/contains my query.
2. Do you support querying by business names? Google’s geocoding doesn’t return the business name in the result (that’s a separate API), but it does use business names to resolve queries.
Great. The only real answer is you should sign up for a free trial (takes 2 min, requires just an email address) and test with your actual input data. Which language are you working in? We have SDKs for almost all (30+) and detailed tutorials for many: https://opencagedata.com/sdks
Hi there, this is Sarthak from the Google maps Devrel team. I would love to understand what challenges you faced while using the APIs and what can we do better in the future. If you are interested to talk, please drop me a DM?
To summarize the main point of roll-your-own vs. a pay-per-request api the main point seems to be updating with updated/new OSM data.
In terms of comparing Google Maps vs. Open Cage vs. roll your own OSM / Nominatim what would you say are the main features that are different? (not dev time or infra stuff- just what's different about the request/result)
though really the key difference is the fact that we use open data. Googles data is not open, this significatly restricts what you can do with the data.
well the pricing models are per request, but just in easy to understand buckets (small, medium, large). Our experience is most people prefer this as they know exactly what they will spend, there is never a surprising bill.
That said we do have enterprise customers with other pricing models to meet their exact needs. Please get in touch if we can help you.
To be specific my use case is for a seasonal-based app. So I neither want to pay for 10 months where $45 is too large, or buy a pre-determined amount without auto-reload where it's possible to run out of requests if I'm not careful.
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!
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.
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.
This request/response format is a bit different than the native Photon format, but with GraphHopper Geocoding it is possible to easily switch between different "providers" (like Nominatim, OpenCage etc.), which are all usable under the same contract.
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.
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.
Before you do this, triple check that that the buildings and addresses for the area you are interested in are actually there (and correct). I've tried to use this approach several times, and at least for Sweden, the results are basically unusable. Hugh amount of missing buildings and missing or incorrect data. Last I tried I think it got something like 20% of my queries correct.
But it doesn't mention why you need this amount of RAM or how you could opt out of that requirement? i.e., if the queries run directly against the DB w/o indexes, etc. why the high RAM requirement?
AFAIK, a lot of the RAM requirements come from importing and processing the data. It already takes quite a long time and would be even slower without heavily utilizing RAM.
Nominatim also doesn't support any sort of typeahead queries. There's Photon(https://github.com/komoot/photon), which works in concert with Nominatim and is similarly tied to OSM as a data source.
There's also Pelias(https://pelias.io/), an open-source geocoder that handles all types of geocoding in one and supports OSM, OpenAddresses and many other sources (including custom data) out of the box. Admittedly it can have more moving parts as a result, but it can be set up with relatively little RAM if you're careful (I bet a planet install could be done somewhat slowly with 32GB RAM). Full disclosure, I have been a core-maintiner of the project since 2015.
I tried going that route and it unfortunately didn’t work well. At least in Europe OSM is missing a lot of house numbers and even has some larger flaws of missing data / invalid attributed streetnames.
Unfortunately I don't have any examples at hand right now. What I remember is that in some smaller villages in germany it was missing house numbers and some streets weren't "cut" correctly. So when you had an intersection of Street A and Street B and after the intersection it becomes Street A, sometimes OSM would still name it Street B and therefore all numbers are wrong. This was around 2 years ago so maybe the map data is better now.
Same here. Not using anything now, but when I needed it, they were a good value, and easy to use. They sponsored a PHP conference I went to, which is where I heard of them, and became a customer. LPT: conference sponsoring does work ;)
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.
> permanently storing results for future use (e.g., as a database column), in part or in whole, from the Stadia Maps Geocoding APIs without an active Standard, Professional, or Enterprise subscription with appropriate permissions;
Thanks - that quote is from a list under the heading "Furthermore, you herein agree not to make use of Stadia Maps, Inc.’s Services in any of the following ways:"
(Having scanned those terms I'm still not 100% certain I can confidently answer all three of my questions though. A classic challenge with this is that terms often have language that relates to map tile images, but it's hard to derive if those same terms apply to geocoded lat/lon points.)
> Unlike most vendors, we won't charge you 10x the standard fee per request to store geocoding results long-term! However, we do require an active Standard, Professional, or Enterprise subscription to permanently store results (e.g. in a database). Temporary storage in the normal course of your work is allowed on all plans. See our terms of service for the full legal terms.
In the case of OpenStreetMap-derived geocoding, of course, their terms of service can say "we won't continue to sell to you if that's what you're doing". But the data itself is ODbL-licensed so once you've got it, you can keep it.
I wonder if you can sign a contract with them that locks in your subscription pricing for all time (I imagine not) - without that you risk them jacking up the price on you once you're heavily invested (after they sell the company to Oracle.)
Definitely drop us a line. Our v2 response structure is still undergoing some iteration, especially around the particulars of labeling, so this may be intended (depending on the specific query), but we can certainly look into it to confirm that.
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.
Hey folks, article author here. First of all: I didn't submit it to HN.
As few people pointed out, this article was written in 2023 and it's intentionally focused just on pricing – I planned a follow up about accuracy and other aspects, but Superface pivoted away from multi-provider API abstractions and I was laid off.
So for me this is more of a time capsule of what Superface used to be about. I'm glad if you found the article still useful and the discussion here is really informative, but I won't be updating the article any further. Thanks for understanding!
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.
You might not need an API at all. OpenStreetMaps data is publicly available and there are open source tools for many use cases. For reverse geocoding there is Fast Reverse Geocoding Server[1].
I did a dive into these services back in 2019 though some of these services in the article I’ve never heard of.
The three I spent a lot of time with were Azure Maps, MapQuest and of course OpenStreetMap’s Nominatim.
This was for a side project so the financial restrictions alone led me to settle on Nominatim. I had a dedicated Nominatim server running on a PowerEdge R620 in my closet on an array of SAS drives. Or maybe it was 500GB SATA SSDs. Anyway, I recall the normalization of addresses being a big pain point, although I was working with government data so that was going to be a pain point whether I used Nominatim or something “higher quality”.
I also recall becoming frustrated with some of these edits users would make to OSM (that went downstream to Nominatim’s data). Like Wikipedia, OSM’s data is often made worse by new editors who don’t understand the pragmatics of the map- for example, someone had gone through my neighborhood and traced the wooded area behind it, but did it based on satellite view and just followed the pattern of trees- even though that meant going well into people’s back yards that had only a tree or two. This really should have been a property line tracing.
Founder of Smarty here, so there's some obvious bias.
We've been in the geocoding space for over 12+ years. A geocoding API should be easy to set up, deliver rooftop-accurate geocodes, be transparent about accuracy, persist in perpetuity, have a clear pricing structure, and be lightning fast.
Smarty has geocodes for 210 million US addresses, including 20 million non-USPS addresses. Our US Rooftop Geocoding product is 97% accurate to the rooftop or parcel of the property. Perpetual use of our geocoding data is also available, and Smarty does have licensing available for re-syndicating lat/long points in your APIs. Our entry-level plans for US Rooftop Geocoding have rate limits of 25,000 addresses/second. (Most customers won't reach this speed, but you're welcome to try.)
The best way to determine a company's geocoding accuracy is to test their products directly.
Good post, however what most people fail to see is that the quality of the result from a geocoder greatly depends on the quality of the input data.
Google has good normalization of that input address to identify and correct it but if the input has too much info like instructions to find the address or variations of the street name, phone numbers etc, then it gets confused and the results will not be good.
I deal with lots of very poorly formatted addresses for last mile and delivery companies and they have horrible data, so I created AddressHub which mostly focus on address normalization but also offers a router capability that connects to multiple geocoders and analyze the results to prevent false positives (results that are deemed of high accuracy but are even miles away from the real location).
It also provides caching according to the terms and conditions of the geocoders and also checks first with open data to see if the address can be geocoded with it (at no cost) then do a fallback mechanism with the geocoders to find the best result.
Take a look at it and let me know what I should improve: www.address-hub.com
> 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'm working on a side project now and I'm using Nominatum at the moment. Normalization of addresses is the real pain point for Nominatum. Sometimes something as simple as "Avenue" vs "Ave" can be the difference between finding a matching location and not finding a match.
Any comparisons that includes address normalization (in addition to price, usability of the API, etc.) would be a great help.
Anyone know of a robust comparison of these services?
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 jm@symbolic-simulation.com.
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.
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".
I'm sorry but not surprised to read that you had a bad experience with positionstack. They have been unreliable for years, and worse yet unresponsive about it.
If you still need geocoding very happy to have a conversation, or you can just check out our site: https://opencagedata.com
We use only open data, you can store it forever (even if no longer a customer) and use it for whatever you like.
For development (and experimenting & learning) I run my own Nominatim instance.
My customers who use the geocoding and mapping feature in production are very into data privacy and sovereignity, so they had Geofabrik build them their own infrastructure on premises.
I think back in the day, when I ranted about Positionstack on Twitter, we may have chatted for a bit.
We use LocationIQ and are very happy. We've negotiated a different rate limit.
The big difference between Google Maps is the quality of the results. Location IQ is basically hosted Nominatim. It is fine for many things, but at the street address level it starts breaking down.
My side project requires geocoding and the prices are absolutely extortionate. I need places to get (lat, long) and it's insane how expensive it is. Fortunately for me I found with places a relatively simple solution.
I am trying Geocod.io right now and its been a very smooth experience so far. Generous free tier, no credit card required, good docs and a dedicated node library. And I can store results.
Are you committed to running the process locally due to privacy or legal reasons?
If not, we securely run geocoding batches of that size at Geocode Earth all the time at pretty competitive rates. We are flexible on data transfer, usually we have customers set up an SFTP server or an S3 bucket and send us the credentials. We spin up a ton of hardware in EC2 to geocode it real fast (<24 hours even for a few hundred million addresses), will work with any data format you need, and then send it back.
If you _do_ need to run it locally, we're also the creators of the Pelias geocoder(https://pelias.io), which is open source like Nominatim but supports more than just OSM data (which is not a comprehensive address source globally), so often can return better results. We can help you set it up if you need.
IPLocate.io is free to use up to 1,000 reqs/day, also includes a bunch of other IP data like proxy/vpn detection, asn/company/org info. Disclaimer: I run this service, so I'm biased :)
IP2Location.io offers a free tier of 50,000 queries monthly to get started with. This allows users to explore its capabilities and compares with othe providers.
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 :)
As someone who has worked with this sort of stuff quite a bit, I can assure you that OSM is pretty terrible for Geocoding and reverse geocoding. OSM is great for all kinds of roads (everything from the largest highways to the tiniest unofficial hiking trails), pretty good for landuse and absolutely terrible for building footprints and addresses. In many countries you don't have to get far outside of major cities before half the buildings are just missing, and even the buildings that do exist very often have the wrong address or house number.
For a good geocoder, you need many other data sources (which can be open). OpenAddresses (https://openaddresses.io/) is an example of a vital dataset to delivering anything of any quality.
Returning real results requires extensive parsing and awareness of addresses and place data (including localization of them), and this is not something you get for free based on OSM data.
My experience is also that (in the uk at least) it can't be done accurately with openstreetmap data.
For context, I've tried it! I've been working on a free library for geocoding UK addresses quickly and accurately. It comes with the caveat that you need access to the dataset of all addresses you're geocoding against - which could be your own list, or a commercial product like addressbase: https://github.com/robinL/uk_address_matcher/
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."
That is a very important point that I also was surprised wasn't mentioned. Google offers amazing APIs regarding locations and places, but they are expensive and prohibit you from storing it in any meaningful way.
I was surprised to see AWS' location service wasn't compared in this write-up. They are unique in that they offer both options. They ask when you provision the service if you plan on storing the data. The service works the same, but the cost is 8x. A fair trade, if your use-case involves referencing that data often.
If you think that is a fair trade I would love the chance to talk with you and save you A LOT of money.
Our experience (10+ years of offering a geocoding service) is that many people (of course depending on exact needs and use case) are significantly over-spending and could be using open data to reduce costs by 80+%.
Happy to chat if interested
Not quite unique, ArcGIS location platform has similar terms and options.
https://location.arcgis.com/pricing/#geocoding
Not being able to store results also can limit usefulness of the geocoding API itself. I have seen cases where the licensing limits affect cache TTLs and end up requiring many more API calls (latency) than would otherwise be necessary.
>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.
Some APIs let you retrieve and store a geocode ID (sometimes they call it a "magic ID"), which you can then store information against.
But yes, your point stands.
I'd be willing to bet most users just ignore that bit of the terms...
They're surely going to just have a column for 'user_country' in their users database which is prepopulated from the users IP and used for all kinds of uses.
Just do it anyway. The age of AI has shown that none of these terms matter. It doesn't stop the big boys, there is essentially no risk of being caught, so why let them keep that boot planted on your face?
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.
Hey, I’m acutely in the market (considering moving away from Google)
2 Qs:
1. How does OpenCage correctness/completeness compare to Google Maps API, especially in rural and industrial regions where you have addresses like “AcmeCo Industries, 234-XY Unit C, Jebel Ali Free Zone, Dubai”? I’d like to confidently query the most precise location that still matches/contains my query.
2. Do you support querying by business names? Google’s geocoding doesn’t return the business name in the result (that’s a separate API), but it does use business names to resolve queries.
Hi,
Great. The only real answer is you should sign up for a free trial (takes 2 min, requires just an email address) and test with your actual input data. Which language are you working in? We have SDKs for almost all (30+) and detailed tutorials for many: https://opencagedata.com/sdks
You can also test manually on our demo page: https://opencagedata.com/demo
You can do a lot to help us by formatting the input data well: https://opencagedata.com/guides/how-to-format-your-geocoding...
re: company names, it is a real challenge as they introduce a lot of noise.
Please can you follow up by email with specific questions: support @ opencagedata.com
I hope we have the chance to work with you
Hi there, this is Sarthak from the Google maps Devrel team. I would love to understand what challenges you faced while using the APIs and what can we do better in the future. If you are interested to talk, please drop me a DM?
The comparison page link is comprehensive, nice!
To summarize the main point of roll-your-own vs. a pay-per-request api the main point seems to be updating with updated/new OSM data.
In terms of comparing Google Maps vs. Open Cage vs. roll your own OSM / Nominatim what would you say are the main features that are different? (not dev time or infra stuff- just what's different about the request/result)
There is a list here (vs. Google) https://opencagedata.com/guides/how-to-switch-from-google-ma...
though really the key difference is the fact that we use open data. Googles data is not open, this significatly restricts what you can do with the data.
And here is a similar comparison versus running your own Nominatim https://opencagedata.com/guides/how-to-switch-from-nominatim
Please let us know if anything is out of date or can be made more clear. Thanks.
Thanks!
Is there a chance you guys will ever switch to a per-request pricing model?
well the pricing models are per request, but just in easy to understand buckets (small, medium, large). Our experience is most people prefer this as they know exactly what they will spend, there is never a surprising bill.
That said we do have enterprise customers with other pricing models to meet their exact needs. Please get in touch if we can help you.
To be specific my use case is for a seasonal-based app. So I neither want to pay for 10 months where $45 is too large, or buy a pre-determined amount without auto-reload where it's possible to run out of requests if I'm not careful.
I suppose you can't please everyone.
> I suppose you can't please everyone.
correct
FYI, my site (NetToolKit) offers per-request pricing, in increments of $10 (for 100,000 requests): https://www.nettoolkit.com/docs/geo/overview/geocoding -- no monthly fees if you do not make requests.
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!
Is there any UK addresses? I can't find anything obvious, UK, GB, GBR...
Nope, unfortunately Royal Post claims copyright on all of the address data and won't release it unless you pay.
Much appreciated. I thought that might be the case. I wonder if you could collect your own if royal mail would be able to stop you?
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.
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.
And if you don't want to host Photon on your own you can have it hosted from GraphHopper: https://docs.graphhopper.com/openapi/geocoding
This request/response format is a bit different than the native Photon format, but with GraphHopper Geocoding it is possible to easily switch between different "providers" (like Nominatim, OpenCage etc.), which are all usable under the same contract.
disclaimer: I'm a co-founder of GraphHopper
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.
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.
Before you do this, triple check that that the buildings and addresses for the area you are interested in are actually there (and correct). I've tried to use this approach several times, and at least for Sweden, the results are basically unusable. Hugh amount of missing buildings and missing or incorrect data. Last I tried I think it got something like 20% of my queries correct.
In case others are looking at Nominatim, this is from the Nominatim docs:
"For a full planet import 128GB of RAM or more are strongly recommended. Do not report out of memory problems if you have less than 64GB RAM."
That's ~$150/mo at Hetzner on bare metal, $672/mo at Digital Ocean, starting at $487/mo at AWS. For a non-redundant, low-availability configuration.
I guess this is for type-ahead speed type queries? I found the page: https://nominatim.org/release-docs/latest/admin/Installation...
But it doesn't mention why you need this amount of RAM or how you could opt out of that requirement? i.e., if the queries run directly against the DB w/o indexes, etc. why the high RAM requirement?
AFAIK, a lot of the RAM requirements come from importing and processing the data. It already takes quite a long time and would be even slower without heavily utilizing RAM.
Nominatim also doesn't support any sort of typeahead queries. There's Photon(https://github.com/komoot/photon), which works in concert with Nominatim and is similarly tied to OSM as a data source.
There's also Pelias(https://pelias.io/), an open-source geocoder that handles all types of geocoding in one and supports OSM, OpenAddresses and many other sources (including custom data) out of the box. Admittedly it can have more moving parts as a result, but it can be set up with relatively little RAM if you're careful (I bet a planet install could be done somewhat slowly with 32GB RAM). Full disclosure, I have been a core-maintiner of the project since 2015.
I tried going that route and it unfortunately didn’t work well. At least in Europe OSM is missing a lot of house numbers and even has some larger flaws of missing data / invalid attributed streetnames.
I'm also thinking of trying to set this up. Can you give a specific example? Are these common house numbers?
Unfortunately I don't have any examples at hand right now. What I remember is that in some smaller villages in germany it was missing house numbers and some streets weren't "cut" correctly. So when you had an intersection of Street A and Street B and after the intersection it becomes Street A, sometimes OSM would still name it Street B and therefore all numbers are wrong. This was around 2 years ago so maybe the map data is better now.
I've found Geocodio to be a good option too, especially if you need to do batch processing: https://www.geocod.io/
Same here. Not using anything now, but when I needed it, they were a good value, and easy to use. They sponsored a PHP conference I went to, which is where I heard of them, and became a customer. LPT: conference sponsoring does work ;)
Agreed, we use them for a number of things and find them very reasonably priced (especially, unlimited plan is very good if you are doing 5+ million).
Possibly, but they only cover the US
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!
Can I store the latitude/longitude points I get back from your API forever or is there a caching time limit?
Can I keep those points if I'm no longer a customer?
Can I resyndicate those stored points via my own API?
https://stadiamaps.com/terms-of-service/
> permanently storing results for future use (e.g., as a database column), in part or in whole, from the Stadia Maps Geocoding APIs without an active Standard, Professional, or Enterprise subscription with appropriate permissions;
Thanks - that quote is from a list under the heading "Furthermore, you herein agree not to make use of Stadia Maps, Inc.’s Services in any of the following ways:"
(Having scanned those terms I'm still not 100% certain I can confidently answer all three of my questions though. A classic challenge with this is that terms often have language that relates to map tile images, but it's hard to derive if those same terms apply to geocoded lat/lon points.)
Yes, without an active subscription.
https://docs.stadiamaps.com/geocoding-search-autocomplete/bu...
> Can I Store Geocoding API Results?
> Unlike most vendors, we won't charge you 10x the standard fee per request to store geocoding results long-term! However, we do require an active Standard, Professional, or Enterprise subscription to permanently store results (e.g. in a database). Temporary storage in the normal course of your work is allowed on all plans. See our terms of service for the full legal terms.
In the case of OpenStreetMap-derived geocoding, of course, their terms of service can say "we won't continue to sell to you if that's what you're doing". But the data itself is ODbL-licensed so once you've got it, you can keep it.
I wonder if you can sign a contract with them that locks in your subscription pricing for all time (I imagine not) - without that you risk them jacking up the price on you once you're heavily invested (after they sell the company to Oracle.)
The new V2 reverse geo-coding API is excellent. But it occasionally doesn't have a formatted_address_line, even when the v1 has a full label.
Is that something I should report as a bug, or is that the way it is supposed to be?
Thanks for the compliment!
Definitely drop us a line. Our v2 response structure is still undergoing some iteration, especially around the particulars of labeling, so this may be intended (depending on the specific query), but we can certainly look into it to confirm that.
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.
IP geolocation is a different (albeit similar) topic than geocoding.
See: https://opencagedata.com/guides/how-ip-geolocation-differs-f...
My bad, thanks.
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.
Hey folks, article author here. First of all: I didn't submit it to HN.
As few people pointed out, this article was written in 2023 and it's intentionally focused just on pricing – I planned a follow up about accuracy and other aspects, but Superface pivoted away from multi-provider API abstractions and I was laid off.
So for me this is more of a time capsule of what Superface used to be about. I'm glad if you found the article still useful and the discussion here is really informative, but I won't be updating the article any further. Thanks for understanding!
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.
You might not need an API at all. OpenStreetMaps data is publicly available and there are open source tools for many use cases. For reverse geocoding there is Fast Reverse Geocoding Server[1].
[1]: https://github.com/giangndm/fast-pbf-query-server
I did a dive into these services back in 2019 though some of these services in the article I’ve never heard of.
The three I spent a lot of time with were Azure Maps, MapQuest and of course OpenStreetMap’s Nominatim.
This was for a side project so the financial restrictions alone led me to settle on Nominatim. I had a dedicated Nominatim server running on a PowerEdge R620 in my closet on an array of SAS drives. Or maybe it was 500GB SATA SSDs. Anyway, I recall the normalization of addresses being a big pain point, although I was working with government data so that was going to be a pain point whether I used Nominatim or something “higher quality”.
I also recall becoming frustrated with some of these edits users would make to OSM (that went downstream to Nominatim’s data). Like Wikipedia, OSM’s data is often made worse by new editors who don’t understand the pragmatics of the map- for example, someone had gone through my neighborhood and traced the wooded area behind it, but did it based on satellite view and just followed the pattern of trees- even though that meant going well into people’s back yards that had only a tree or two. This really should have been a property line tracing.
Founder of Smarty here, so there's some obvious bias.
We've been in the geocoding space for over 12+ years. A geocoding API should be easy to set up, deliver rooftop-accurate geocodes, be transparent about accuracy, persist in perpetuity, have a clear pricing structure, and be lightning fast.
Smarty has geocodes for 210 million US addresses, including 20 million non-USPS addresses. Our US Rooftop Geocoding product is 97% accurate to the rooftop or parcel of the property. Perpetual use of our geocoding data is also available, and Smarty does have licensing available for re-syndicating lat/long points in your APIs. Our entry-level plans for US Rooftop Geocoding have rate limits of 25,000 addresses/second. (Most customers won't reach this speed, but you're welcome to try.)
The best way to determine a company's geocoding accuracy is to test their products directly.
Good post, however what most people fail to see is that the quality of the result from a geocoder greatly depends on the quality of the input data.
Google has good normalization of that input address to identify and correct it but if the input has too much info like instructions to find the address or variations of the street name, phone numbers etc, then it gets confused and the results will not be good.
I deal with lots of very poorly formatted addresses for last mile and delivery companies and they have horrible data, so I created AddressHub which mostly focus on address normalization but also offers a router capability that connects to multiple geocoders and analyze the results to prevent false positives (results that are deemed of high accuracy but are even miles away from the real location).
It also provides caching according to the terms and conditions of the geocoders and also checks first with open data to see if the address can be geocoded with it (at no cost) then do a fallback mechanism with the geocoders to find the best result.
Take a look at it and let me know what I should improve: www.address-hub.com
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'm working on a side project now and I'm using Nominatum at the moment. Normalization of addresses is the real pain point for Nominatum. Sometimes something as simple as "Avenue" vs "Ave" can be the difference between finding a matching location and not finding a match.
Any comparisons that includes address normalization (in addition to price, usability of the API, etc.) would be a great help.
Anyone know of a robust comparison of these services?
Missing ArcGIS Location Platform: https://location.arcgis.com/pricing/#geocoding
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 jm@symbolic-simulation.com.
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.
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".
I'm sorry but not surprised to read that you had a bad experience with positionstack. They have been unreliable for years, and worse yet unresponsive about it.
If you still need geocoding very happy to have a conversation, or you can just check out our site: https://opencagedata.com
We use only open data, you can store it forever (even if no longer a customer) and use it for whatever you like.
For development (and experimenting & learning) I run my own Nominatim instance.
My customers who use the geocoding and mapping feature in production are very into data privacy and sovereignity, so they had Geofabrik build them their own infrastructure on premises.
I think back in the day, when I ranted about Positionstack on Twitter, we may have chatted for a bit.
I made a thing like this years ago, with the cheesy domain getlon.lat.
But I stopped maintaining it and renewing the domain.
You can see it here: https://stevage.github.io/which-geocoder/
We use LocationIQ and are very happy. We've negotiated a different rate limit.
The big difference between Google Maps is the quality of the results. Location IQ is basically hosted Nominatim. It is fine for many things, but at the street address level it starts breaking down.
My side project requires geocoding and the prices are absolutely extortionate. I need places to get (lat, long) and it's insane how expensive it is. Fortunately for me I found with places a relatively simple solution.
No mention of OpenRouteService, which you can spin up locally yourself and which offers a variety of similar services:
https://openrouteservice.org/
As stated in their readme on Github: for Geocoding they Pelias, which is not part of the openrouteservice software/repository.
Just found https://radar.com/pricing 100k free calls/month.
I am trying Geocod.io right now and its been a very smooth experience so far. Generous free tier, no credit card required, good docs and a dedicated node library. And I can store results.
(2023)
I actually don't see anywhere on the Nominatim website that restricts commercial usage contrary to the article's comparison chart,
Likely refers to using the OSM maintained servers "be aware that the service runs on donated servers and has a very limited capacity" https://operations.osmfoundation.org/policies/nominatim/
Nice. I need to batch process my entire database of addresses (100M entries), so only local Nominatim will work.
Are you committed to running the process locally due to privacy or legal reasons?
If not, we securely run geocoding batches of that size at Geocode Earth all the time at pretty competitive rates. We are flexible on data transfer, usually we have customers set up an SFTP server or an S3 bucket and send us the credentials. We spin up a ton of hardware in EC2 to geocode it real fast (<24 hours even for a few hundred million addresses), will work with any data format you need, and then send it back.
If you _do_ need to run it locally, we're also the creators of the Pelias geocoder(https://pelias.io), which is open source like Nominatim but supports more than just OSM data (which is not a comprehensive address source globally), so often can return better results. We can help you set it up if you need.
Geocodify is another strong option, especially if you need batch processing at a good price — see geocodify.com
Somewhat related, what are some recommended IP geolocation providers today in 2025 and associated cost?
IPLocate.io is free to use up to 1,000 reqs/day, also includes a bunch of other IP data like proxy/vpn detection, asn/company/org info. Disclaimer: I run this service, so I'm biased :)
Depending on what you need ip2location might fit. They have free versions that are country-level and sell more detailed versions as well.
We used them until we moved to fastly, which does iplocation stuff as part of their service.
IP2Location.io offers a free tier of 50,000 queries monthly to get started with. This allows users to explore its capabilities and compares with othe providers.
MaxMind's GeoIP?
https://www.geoapify.com is really nice has has some react components you can quickly hit the ground running with.
What is the best SSID to location service?
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 :)
This is advertising and also most of that can be done with openstreetmap data instead of an API, I'd expect.
As someone who has worked with this sort of stuff quite a bit, I can assure you that OSM is pretty terrible for Geocoding and reverse geocoding. OSM is great for all kinds of roads (everything from the largest highways to the tiniest unofficial hiking trails), pretty good for landuse and absolutely terrible for building footprints and addresses. In many countries you don't have to get far outside of major cities before half the buildings are just missing, and even the buildings that do exist very often have the wrong address or house number.
That's just not the case.
For a good geocoder, you need many other data sources (which can be open). OpenAddresses (https://openaddresses.io/) is an example of a vital dataset to delivering anything of any quality.
Returning real results requires extensive parsing and awareness of addresses and place data (including localization of them), and this is not something you get for free based on OSM data.
My experience is also that (in the uk at least) it can't be done accurately with openstreetmap data.
For context, I've tried it! I've been working on a free library for geocoding UK addresses quickly and accurately. It comes with the caveat that you need access to the dataset of all addresses you're geocoding against - which could be your own list, or a commercial product like addressbase: https://github.com/robinL/uk_address_matcher/