Why not take the openstreetmaps address (which is long), chop it into a list of short combinations, then do a lookup for each combination, and see which short address gives you the best (geographically closest) match?
Reverse geocoding is hard
11–20 of 139 posts
Re: Reverse geocoding is hard
#12I read this as Reverse Genociding Is Hard, thought I was on a Nethack forum, and thought, No, it's pretty easy with a cursed scroll.
Re: Reverse geocoding is hard
#13Fun fact that was dredged up because the author mentions Australia: GPS points change. Their example coordinates give 6 decimal places, accurate to about 10-15cm. Australia a few years back shifted all locations 1.8m because of continental drift they’re moving north at ~7cm/year). So even storing coordinates as a source of truth can be hazardous. We had to move several thousand points for a client when this happened.
Re: Reverse geocoding is hard
#14Genealogy applications run into this a lot. The person of interest lived at Engeset. FamilySearch has geocoded a place called "Engeset, Møre og Romsdal, Norway". So that's it, right? Not so fast, [there are at least 3 Engesets in Møre og Romsdal](https://www.google.com/maps/search/Engeset/@62.3358577,6.225...).
But that's at least better than when it's some local place name which it's never heard of, and thinks sounds most similar to a place in Afghanistan (this happens all the time).
And to add to it, there are administrative regions, and ecclesiastical regions. Do you put them in the parish, or in the municipality? The birth in the parish and the baptism in the municipality, maybe? How about the burial then...
Re: Reverse geocoding is hard
#15It's a lot more expensive, but measuring navigation distance rather than straight line distance would avoid the "river" issue. Although depending on the routing engine and dataset it might well introduce more issues where points can be really close on foot but the only known route is a driving route.
If you know of an API which does navigation distance to POI, I'd love to hear about it!
Re: Reverse geocoding is hard
#16If I were giving directions to another human and not using house addresses I'd say something like "Queen street about half way down the block between Crawford and Shaw"
That's great for cities with a grid layout, but ignores most of the world.
How would you give directions to something in the middle of a park?
Re: Reverse geocoding is hard
#17I created this to solve my own need for reverse geocoding:
https://github.com/punnerud/rgcosm
(Saving me thousands of $ compared to Google API)
Uses OpenStreetmap file, Python and SQLite3.
First it finds all addresses using +/- like a square from lat/lon, then calculate distance based on the smaller list (Pythagoras), and pick the closest. It expands until a set maximum if no address is found in the first search.
Re: Reverse geocoding is hard
#18Have you looked at the geonames database?, https://www.geonames.org/ Info and schema is here, https://download.geonames.org/export/dump/readme.txt Could be a good source. Not sure how good it is worldwide, but the countries I’ve used it for, it’s been useful and pretty good. Try the search too, https://www.geonames.org/search.html?q=R%C3%ADo+grande&count... Not just roads, but there’s rivers, and other things too
That does look interesting. I could search through it for a lat & long, but it looks like it only gives a name (e.g. "Silicon Oasis") without a corresponding country. Food for thought though.
Thanks!
Re: Reverse geocoding is hard
#19Fun fact that was dredged up because the author mentions Australia: GPS points change. Their example coordinates give 6 decimal places, accurate to about 10-15cm. Australia a few years back shifted all locations 1.8m because of continental drift they’re moving north at ~7cm/year). So even storing coordinates as a source of truth can be hazardous. We had to move several thousand points for a client when this happened.
In the past year or so I have thought a lot about how to design tables and columns within databases and there is nearly nothing that wouldn't get more robust by adding in a "valid_from" and "valid_till" and make it accept multiple values. Someone's name is Foo? What if they change it to Bar at some point and you need to access something from before with the old name?
If you have only a name field that has a single value that is going to be a crazy workaround. If your names are referencing a person with a date that is much easier. But you need to make that ddcision pretty early.
Re: Reverse geocoding is hard
#20Have you looked at the geonames database?, https://www.geonames.org/ Info and schema is here, https://download.geonames.org/export/dump/readme.txt Could be a good source. Not sure how good it is worldwide, but the countries I’ve used it for, it’s been useful and pretty good. Try the search too, https://www.geonames.org/search.html?q=R%C3%ADo+grande&count... Not just roads, but there’s rivers, and other things too
That does look interesting. I could search through it for a lat & long, but it looks like it only gives a name (e.g. "Silicon Oasis") without a corresponding country. Food for thought though. Thanks!
Yeah. It’s not flat.
You can use admin fields, and it’s a recursive query to find.
I have recursive CTE (thanks to ChatGPT).
Could also be done on save, since they shouldn’t change for locations.
The recursiveness though, gives you a benefit if you extract type and save the intermediate steps, it allows you to start grouping things together at different levels which is one of the use cases you mentioned.