Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion for PR to improve accuracy of reverse geocoding #357

Open
LEDfan opened this issue Sep 14, 2018 · 3 comments
Open

Discussion for PR to improve accuracy of reverse geocoding #357

LEDfan opened this issue Sep 14, 2018 · 3 comments

Comments

@LEDfan
Copy link

LEDfan commented Sep 14, 2018

Hi

We are looking into using Photon as a (reverse) geocoding solution. The speed and simple setup is great, thanks for that 👍!

Currently we are bumping into some inaccuracies when reverse geocoding. Especially on parts of roads where no building are nearby.

To give an example, the point lat 51.32965, lon: 4.52222, is giving weird results:

The big difference between Nominatim and Photon is of course that Nominatim is using PostGIS and Photon is using ES. I did some research and I think the problem is that Nominatim is comparing the distance of an object to its full shape and Photon don't. Instead Photon only looks at some points of the object. This is not a surprise since ES doesn't support such a query (elastic/elasticsearch#13351).

I have a possible solution that basically works as follows:

  • when indexing ES with data from Nominatim, check if the object is a highway
  • if so, divide the highway into straight parts (using the ST_DumpPoints PostGIS function).
  • loop over all these parts:
    • if a part is larger than 20 meters: split this part into points, where the distance between two continuously points is 20 meters

These two images explains it (the second image is indexed with 50 meters distance, but this isn't good enough).
selection_005
selection_002

I open this issue because I want to know if you are interested in accepting a PR for this.
A POC implementation is available at https://github.com/komoot/photon/compare/master...inuits:indexed_shapes?expand=1. It needs some polishing (and maybe some tests) but it is working fine here. The same example now returns Essensteenweg.
During import from Nominatim I don't see a (significant) impact, also the ES database doesn't grow much.

Thanks in advance!

@LEDfan LEDfan changed the title Discussion for PR to improve accuracy of reverse geociding Discussion for PR to improve accuracy of reverse geocoding Sep 14, 2018
@simonpoole
Copy link
Contributor

The real issue is IMHO that Photon doesn't actually store the geometry of ways, instead it just stores a bounding box. Your approach more or less simply recreates the geometry by creating a lot of individual documents for essentially the same object. While the approach obviously works, I think some investigation in to other solutions is warranted (for example simply storing the way coordinates in the relevant documents see https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-geo-distance-query.html "Multi Location Per Document").

@phamtai97
Copy link

Hi all, Any update about issues?

@lyudmilpetrov

This comment was marked as off-topic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants