ORS is not using the correct road but instead using a very long alternative

Hello there,

Trying to find the direction/distance matrix from [39.35105, 21.89766] to [39.31178, 21.92612]
The public api’s are returning a 110 km route while the actual is 10 km, same results in the matrix, the directions and the optimization, you can check that here.

Actual


Expected

The driving-car and driving-hgv profiles use the long path, other profiles like cycling-* `foot-* are returning correct results.

On OSM it returns the right road

I checked OSM editor, the roads have correct tags and access values, what else can I do to understand why this is happening?

Thanks for reaching out and for reporting the issue, in particular for the detailed description of your findings :heart:

I can confirm your observations: for some obscure reason a whole segment of way 41421810 seems to be missing from the routing graph for the driving-* (but not cycling-*) profiles as evident from the minimal example. This is especially puzzling considering that the graph processing in ORS relays internally on Graphhopper which seems to handle the routing in OSM correctly :thinking:

1 Like

I think I’ve found the culprit: a node of type barrier = gate, see 4325326022. Proper handling of barriers in ORS probably needs revising, as another issue also related to barriers came up only recently, see #2085.

2 Likes

This might be due to this being a comparatively long higway segment with a barrier=gate on it:

Node: 4325326022 | OpenStreetMap is part of the mentioned way.

1 Like

Thank you for finding this.
It is not an actual barrier=gate it is just a mere security checkpoint they have between cities, usually you pass through it no question asked, not sure what the correct tags access should be in this case

currently locked status is unknown, will change it to no.
and the allowed access is unspecified, will change it to yes.