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
Thanks for the interesting report. According to the Elasticsearch response debug output, it looks like the distance values calculated by Elasticsearch and in the API are different. The results are sorted correctly based on the distances calculated by Elasticsearch (which is where all the sorting is done).
I believe we calculate the distance separately in the API because Elasticsearch uses a less precise calculation of distance, but we probably haven't changed this code since the Elasticsearch 2.x or even 1.x days, so it's possible a different approach makes more sense now.
We currently use the geolibgetDistance method, I notice there's also a getPreciseDistance method, and both methods take an accuracy parameter that we don't currently set.
It looks like the difference in the distance values is only a couple meters, so this probably isn't super high priority, but it would definitely be nice if the reverse endpoint did return results in true distance order. If you happen to investigate if there are ways to either use the geolib library better, or that Elasticsearch distance values are now higher quality, let us know! Making changes here should be relatively easy to test and merge.
Describe the bug
I have found a case where the first reverseGeocode result in the list is further away and with a lower confidence value than the second one.
Steps to Reproduce
https://pelias.github.io/compare/#/v1/reverse?boundary.circle.radius=0.1&size=5&lang=en&point.lat=58.380367&point.lon=26.706314
Expected behavior
I would expect the second result to come before the first one
Pastebin/Screenshots
Result:
The text was updated successfully, but these errors were encountered: