Discussion for PR to improve accuracy of reverse geocoding

[LEDfan]

Hi

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

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:

• Nominatim retunrs:
  • Address: Essensteenweg Brasschaat Belgium
  • Matching coordinate: 51.3296452381545,4.52221194871582
  • Link: https://nominatim.openstreetmap.org/reverse.php?format=html&lat=51.32965&lon=4.52222&zoom=16
• Photon returns:
  • Address: Bredabaan Brasschaat Belgium
  • Matching coordinate: 51.329201, 24.5229644
  • Link: http://photon.komoot.de/reverse?lat=51.32965&lon=4.52222&distance_sort=true

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 (https://github.com/elastic/elasticsearch/issues/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!

[simonpoole]

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]

Hi all, Any update about issues?

[lyudmilpetrov]

Hi Komoot

Great work but so far there is an issue with the return data for example if you run:

http://localhost:2322/api?q=412 Asbury Avenue,Ocean City,New Jersey,08226,United States&limit=10

vs

@.***&dedupe=0

the lat and log are very different.

It seems that the street number is not factored in. all the best,

Lyudmil Petrov

On Tue, Jan 23, 2024 at 10:07 PM AJPham @.***> wrote:

Hi all, Any update about issues?

— Reply to this email directly, view it on GitHub https://github.com/komoot/photon/issues/357#issuecomment-1906248114, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC32ZEYPXDIYJRADHTWDZNLYP7G3PAVCNFSM4FVFTGX2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJQGYZDIOBRGE2A . You are receiving this because you are subscribed to this thread.Message ID: @.***>