Troubles during routing / unnecessary frontend geocoding

[d1g]

User was unable to search route

from 56.785591,52.858237
to 56.7821,52.8641

using openstreetmap.org interface while custom URL and external services work fine

• incorrect URL #1 suggested by OSM.org frontend 6.3km time 1:16 - I was able to get this result several times, but I don't remember steps right now
• incorrect URL #2 suggested by OSM.org frontend 0m 0:00 - steps to reproduce: paste "from" coord, hit tab, paste "to" coord, press "Search"
• correct starting position and results 789m 9min at graphhopper.com
• manually corrected URL works as expected 789m time 0:09

[tomhughes]

Pointing me at something in russian doesn't really help much. In general bug reports should stand alone rather than just pointing at an external resource and that goes double if the external source is in a different language...

Can you explain what exactly is the problem the user encountered when trying to make that route?

[tomhughes]

Hmm I see you've already edited it to explain a bit more clearly, but it's still quite vague.

[tomhughes]

Certainly just saying "incorrect URL" doesn't tell us much - you need to explain what is "wrong" about it.

To be honest I suspect the issue is just that we are snapping lat/lon values to geocodes.

[d1g]

Starting and ending position was incorrectly/unnecessary geocoded as "Подшиваловское сельское поселение, Завьяловский район, Удмуртская Республика, Приволжский федеральный округ, Российская Федерация" (by nominatim?)

We don't need geocoding when we search by exact coords.

[d1g]

@tomhughes problem is that two distinct points can be geocoded as same point (incorrect URL #1 or #2). While such simplification may be reasonable for car routers. This is wrong for pedestrian routers since user want his starting and end point treated as "exact coords".

Probably we want to disable geocoding for pedestrian routes or add check box to disable geocoding of coordinates.

Does use case and problem more clear now?

[tomhughes]

In understand the problem, but it's not trivial to fix I suspect because that geocoding is done client side. If it went through our normal search interface then coordinates would automatically be special cased.

[karussell]

We don't need geocoding when we search by exact coords.

The reverse geocoding is useful to know the name but it should not change the original geocodes. For GraphHopper Maps there was code (currently disabled) which did the same and showed the location name under the input box but preserved the geocodes