You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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!
The text was updated successfully, but these errors were encountered:
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
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").
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:
ST_DumpPoints
PostGIS function).These two images explains it (the second image is indexed with 50 meters distance, but this isn't good enough).
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!
The text was updated successfully, but these errors were encountered: