Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reverse geocoding is hard

shkspr.mobi

Post reply on HN
Print view View original

131–139 of 139 posts

Re: Reverse geocoding is hard

#131

Post by pugworthy »

taeric wrote: post #127
Dachande663 wrote: post #13

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

This is a large part of why surveying is done to landmarks.

This is exactly what I was thinking. Except for a tectonic fault line between the point and the landmark, a relative grid of neighboring landmarks as extra reference would be useful as well. Once you establish a location of one point, it gets easier to establish the location of related points.

Re: Reverse geocoding is hard

#133

Post by juanmacuevas »

glitchc wrote: post #132

What 3 words ( https://what3words.com/ ) solves this problem, but it doesn't seem to be popular. If anyone has experience, I would be curious to know why.

What3Words had a lot of potential, but they hurt themselves by aggressively going after alternative/open versions with legal threats instead of encouraging an open ecosystem. Also, the system can make serious mistakes — similar-sounding addresses can easily point to completely wrong locations, even nearby, which is dangerous in emergencies.

Re: Reverse geocoding is hard

#134

Post by e63f67dd-065b »

ryandrake wrote: post #52
sinuhe69 wrote: post #26

Not my area of expertise, but is this not a form of perfectionist problem? I mean, most places have a clear and simple address. For the rest, either a human can solve it, or we can make a few examples and let an AI do the work. We can go back to them later and revise them if we need to. Addresses don't change often, so I think things can stay the same for a long time. Except for emergency dispatch and a few high-prof…

You can call it perfectionism or you can call it "doing it right." I think this gets at a fundamental difference in philosophy among [software] engineers: We have a problem with a lot of edge cases, where a "good enough" solution can be done quickly. What do we do? There's a class of engineers who say 1. Do the "good enough" solution and ignore/error on the edge cases--we'll fix them later somehow (may or may not hav…

Engineering is about tradeoffs -- are the resources invested in improving a system worth the return of said improvement? We know full well how to build bridges that will last a thousand years, we just choose not to because it's not an effective use of public funds compared to a fifty year bridge.

The same applies to software engineering -- each additional edge case you handle increases cost but has diminishing returns. At some point you have to say good enough and ship. The cost of perfection is infinite -- you have finite resources, and a great part of engineering is deciding how to allocate them.

Re: Reverse geocoding is hard

#135

Post by byoung2 »

I recently had to do a lot of work mapping locations inside Disneyland. Once you are inside the park, street addresses aren't useful. I used geoJSON objects to describe the geometry of the resort, the park, then each land, then each ride, restaurant, store, etc, then the elements of each of these, so you have increasingly smaller geometries. Then I used geospatial queries to determine if a point is inside, outside, or nearby a known geometry. So you can say, for example that a certain churro cart is (inside) Disneyland Resort [resort] > (inside) Disney California Adventure [park] > (inside) Buena Vista Street [land], (nearby) Grizzly River Run.

Another challenge is that these shapes change over time. Rides, lands, etc constantly change due to construction, but queues dynamically change size and shape during the day based on crowd size (cast members put extra ropes out to control long lines, and remove them to allow for parades and extra walkways)

Re: Reverse geocoding is hard

#136

Post by tough »

pavel_lishin wrote: post #50
tough wrote: post #43

Earlier quoted context omitted.

something like https://www.pgaudit.org/ ? Basically you keep an history of all changes so you can always roll-back / get that data if needed?

The last time we did this, we basically hand-rolled our own, with a database trigger to insert data into a different table whenever an `UPDATE` statement happened. But this seems like it's probably a better solution.

I just found out about bemi dot io, seems like they're targeting this issue

Re: Reverse geocoding is hard

#137

Post by coldtea »

paganel wrote: post #130
coldtea wrote: post #108

Earlier quoted context omitted.

If you want to keep your land then you need to keep it in such detail in some registry. Else it's trivial for someone to claim it or parts of it. Before such registries tons of people lost their land, lost part of their land, went bankrupt trying to save it, or murdered each other over their plots of land border dispute. There are lots of records a state shouldn't have. Something fixed and stationary that needs prote…

You made the very wrong assumption that land possession is mostly an individual thing, and second, that the State would be happy to award “common” ownership to communities big and small, and as such that it would allow said communities (in many cases much older than the State itself) to decide who gets to use what land inside of said communities. And the main reason is that the State doesn’t like, nor want, any sort…

>You made the very wrong assumption that land possession is mostly an individual thing, and second, that the State would be happy to award “common” ownership to communities big and small, and as such that it would allow said communities (in many cases much older than the State itself) to decide who gets to use what land inside of said communities.

I made neither assumption, and both arguments are irrelevant to my point.

Take the current rights of anyone to one or more plots of land they own. As those are today, and also as they change while some are sold and bought etc.

To protect those rights of those onwers (of citizens and businesses and municipalities and so on) a registry or plots and their boundaries is very useful.

>to decide who gets to use what land inside of said communities

That's a totally irrelevant point, one that I didn't bring up.

I never said the state will happily "award “common” ownership to communities big and small, and as such that it would allow said communities (in many cases much older than the State itself) to decide who gets to use what land inside of said communities". In fact, for the purposes of my argument, whether the state will do that doesn't concern me at all.

Just that the state keeping a registry of plots and their boundaries helps keep track of ownership. Not transfer it to communities, to give it to someone else to administer: to keep track.

Re: Reverse geocoding is hard

#138

Post by jillesvangurp »

sleepy_keita wrote: post #93
jillesvangurp wrote: post #66

This is a while ago but about 12 years ago I experimented with putting the whole of openstreetmap into Elasticsearch. Reverse geocoding then becomes a problem of figuring out which polygons contain the point with a simple query and which POIs/streets/etc. are closest based on perpendicular distance. For that, I simply did a radius search and some post processing on any street segments. Probably not perfect for everyt…

What were some other problems you ran in to when putting OSM in to ES? (I've had this thought before too, I'm curious why/how you did it)

It was part of a bigger project. I still have some code related to converting OSM data to json on my github: https://github.com/jillesvangurp/osm2geojson

Mainly the problem isn't Elasticsearch but dealing with openstreetmap tags and reconstructing polygons from ways, nodes, and relations. Otherwise, even back then Elasticsearch scaled fine; so no issues on that front. And it's pretty well suited for this type of stuff.

We had a largish Hetzner server (50 euro/month) with 32 GB and a quad core xeon that did the indexing. But basically that part was fine. I wrote some simple code that simply pulled out nearby street segments and then calculated perpendicular distance to each of them using some simple high school math and simply picked the nearest. And from there a simple contains query would produce neighborhoods, cities, countries, etc.

The why part was that I was building a location data startup at the time and we were interested in figuring out localities, neighborhoods, and other areas of interest from raw data with coordinates. The startup failed but the idea was kind of cool. So this was a simple reverse geocoder that I knocked out because the existing ones were kind of limited (also rate limited). And Opencage did not exist yet.

Post reply on HN