[HN Gopher] Geocoding APIs compared: Pricing, free tiers and ter...
___________________________________________________________________
Geocoding APIs compared: Pricing, free tiers and terms of use
Author : luismedel
Score : 118 points
Date : 2025-04-23 10:21 UTC (12 hours ago)
(HTM) web link (www.bitoff.org)
(TXT) w3m dump (www.bitoff.org)
| jasongill wrote:
| 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.
| lukeqsee wrote:
| 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!
| edent wrote:
| 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?
| lukeqsee wrote:
| 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.
| simonw wrote:
| 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?
| rob wrote:
| 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;
| simonw wrote:
| 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.)
| rob wrote:
| 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.
| simonw wrote:
| 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.)
| Doctor_Fegg wrote:
| 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.
| throwaway81523 wrote:
| This is advertising and also most of that can be done with
| openstreetmap data instead of an API, I'd expect.
| lukeqsee wrote:
| 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.
| dagw wrote:
| 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.
| RobinL wrote:
| 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/
| bigsassy wrote:
| I've found Geocodio to be a good option too, especially if you
| need to do batch processing: https://www.geocod.io/
| matttah wrote:
| 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).
| freyfogle wrote:
| Possibly, but they only cover the US
| mgkimsal wrote:
| 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 ;)
| apwheele wrote:
| 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.
| jillesvangurp wrote:
| 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.
| simonw wrote:
| 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."
| whichken wrote:
| 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.
| n8cpdx wrote:
| Not quite unique, ArcGIS location platform has similar terms
| and options.
|
| https://location.arcgis.com/pricing/#geocoding
| freyfogle wrote:
| 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
| londons_explore wrote:
| 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.
| runako wrote:
| 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.
| jillyboel wrote:
| 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?
| stevage wrote:
| >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.
| omnibrain wrote:
| 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".
| freyfogle wrote:
| 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.
| freyfogle wrote:
| 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.
| _hl_ wrote:
| 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.
| freyfogle wrote:
| 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
| anubis0505 wrote:
| 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?
| awongh wrote:
| 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)
| freyfogle wrote:
| 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.
| awongh wrote:
| Thanks!
|
| Is there a chance you guys will ever switch to a per-
| request pricing model?
| freyfogle wrote:
| 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.
| awongh wrote:
| 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.
| freyfogle wrote:
| > I suppose you can't please everyone.
|
| correct
| LordHeini wrote:
| 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.
| tom1337 wrote:
| 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.
| awongh wrote:
| I'm also thinking of trying to set this up. Can you give a
| specific example? Are these common house numbers?
| tom1337 wrote:
| 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.
| runako wrote:
| 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.
| awongh wrote:
| 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?
| juliansimioni wrote:
| 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.
| dagw wrote:
| 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.
| janpio wrote:
| (2023)
| atemerev wrote:
| Nice. I need to batch process my entire database of addresses
| (100M entries), so only local Nominatim will work.
| juliansimioni wrote:
| 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.
| joekrill wrote:
| 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.
| firefax wrote:
| 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.
| freyfogle wrote:
| IP geolocation is a different (albeit similar) topic than
| geocoding.
|
| See: https://opencagedata.com/guides/how-ip-geolocation-
| differs-f...
| firefax wrote:
| My bad, thanks.
| jmorrison wrote:
| 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.
| nodesocket wrote:
| Somewhat related, what are some recommended IP geolocation
| providers today in 2025 and associated cost?
| mannyv wrote:
| 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.
| kh_hk wrote:
| MaxMind's GeoIP?
| empyrrhicist wrote:
| No mention of OpenRouteService, which you can spin up locally
| yourself and which offers a variety of similar services:
|
| https://openrouteservice.org/
| karussell wrote:
| As stated in their readme on Github: for Geocoding they Pelias,
| which is not part of the openrouteservice software/repository.
| lucidhss wrote:
| Geocodify is another strong option, especially if you need batch
| processing at a good price -- see geocodify.com
| n8cpdx wrote:
| Missing ArcGIS Location Platform:
| https://location.arcgis.com/pricing/#geocoding
| iJohnDoe wrote:
| What is the best SSID to location service?
| skc wrote:
| I actually don't see anywhere on the Nominatim website that
| restricts commercial usage contrary to the article's comparison
| chart,
| mtmail wrote:
| 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/
| kingnothing wrote:
| 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.
| juliansimioni wrote:
| 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 :)
| krystofee wrote:
| 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.
| yellowbkpk wrote:
| 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!
| account-5 wrote:
| Is there any UK addresses? I can't find anything obvious, UK,
| GB, GBR...
| yellowbkpk wrote:
| Nope, unfortunately Royal Post claims copyright on all of the
| address data and won't release it unless you pay.
| Doctor_Fegg wrote:
| 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.
| karussell wrote:
| 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
| cpursley wrote:
| https://www.geoapify.com is really nice has has some react
| components you can quickly hit the ground running with.
| stormfather wrote:
| 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.
| coolThingsFirst wrote:
| 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.
| mosselman wrote:
| 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.
| stevage wrote:
| 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/
___________________________________________________________________
(page generated 2025-04-23 23:01 UTC)