Project-OSRM / osrm-backend

Open Source Routing Machine - C++ backend
http://map.project-osrm.org
BSD 2-Clause "Simplified" License
6.29k stars 3.32k forks source link

Incorrect snapping. #7005

Closed iaroslavzif closed 2 weeks ago

iaroslavzif commented 1 month ago

Hello!

The profile is not snapping to the closest point from which the location can be accessible. In fact it snaps to nearest location, which sometimes is not direct linked to the destination.

https://map.project-osrm.org/?z=17&center=59.500673%2C24.817783&loc=59.500782%2C24.814150&loc=59.495550%2C24.826905&hl=en&alt=0&srv=0

Captură de ecran din 2024-07-22 la 16 18 50

Thank you!

jcoupey commented 1 month ago

In fact it snaps to nearest location

That is the expected behavior.

The car profile naturally discards the service road because it is marked as private. So when pointing to "the closest point from which the location can be accessible", you're actually using additional information that OSRM does not have: namely that you'd expect to use the private road, by car? or maybe foot?

If you find the snapping logic limiting, a workaround would be to use the nearest endpoint to get a list of candidates (not only the closest one), then decide on which one you want to stand for your original location.

iaroslavzif commented 1 month ago

Hi jcoupey.

Indeed looks like an expected behaviour but it's not alright at all. It just snap to the closest open for car one from which the location is just not reachable.... You can use nearest, but in that case the car (if talking about car.lua) has to come to the point where the last routable segment meet the non routable/without car access (but open for walking etc.). The present logic creates a lot of disturbance and inconvenience, it's just to rudimental. Thank you!

jcoupey commented 1 month ago

the location is just not reachable

Here "reachable" only has a relevant meaning as defined by the profile. If using a car profile, the "Tuulekivi tee" way that can only be taken by foot is out of consideration as far as OSRM is concerned.

I'm not saying this is perfect, just that snapping in a "natural" way as you expect would involve a much more complex logic, maybe you need a multi-modal engine to account for car/foot switches. Or you want to first use nearest with a foot profile, then decide on the best "car routable" candidate location based on that.

iaroslavzif commented 1 month ago

Thank you jcoupey!

Do you know by chance if there have been approaches to tackle this "issues" before. And if yes, at what extend.

Thank you!

iaroslavzif commented 3 weeks ago

Hi jcoupey!

You can see here another exemple: https://map.project-osrm.org/?z=16&center=58.246115%2C22.477094&loc=58.243998%2C22.473096&loc=58.254730%2C22.481804&hl=en&alt=0&srv=0

Captură de ecran din 2024-08-13 la 12 15 54

Thank you!

jcoupey commented 2 weeks ago

Do you know by chance if there have been approaches to tackle this "issues" before. And if yes, at what extend.

The closest I've heard about related to this is doorways. The fact that they're spinning a company for just that problem is in itself a hint that solving it is not a trivial task.

I think you can't reasonably expect OSRM to solve this as the nearest service is "just" a closest snapping. Your best bet is to use some snapping distance threshold as an indicator that you have extra work to do.

iaroslavzif commented 1 week ago

Thank you jcoupey!

I will have a look on it.

Have a great day, Iaroslav!