Comment by simonw | Hacker News Reader

Comment by simonw | Hacker News Reader

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.

Not quite unique, ArcGIS location platform has similar terms and options.

https://location.arcgis.com/pricing/#geocoding

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

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?

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

Reply on news.ycombinator.com