Bridleway is not being recognized as somewhere you can walk?

openrouteservice
1

When trying to create a route for ‘foot-*’ on a ‘Track’ which then meets a 'Bridleway`, the route does not continue onto the bridleway and ends at the end of the track.

See here

I have noticed multiple instances of this similar issue where the route is refusing to use some paths (not sure if they were also bridleways).

I am using the OSM API to compute these routes, I’ve been looking at the routing options documentation here but cannot workout how to apply any of the options to fix this issue.

2

Hey,

the main problem here is, that bridleway access is different between different countries.
Have a look at the osm wiki for this - in germany, bridleways are not accessible to the public by default, but only if allowed.

Thus, bridleways are not included in foot routing by default, but only if corresponding access tags are given.
There’s a bit more discussion about this in our github issues here.

At least for german bridleways, this is a problem in the underlying data that needs to be fixed in the openstreetmap - bridleways accessible by foot should be tagged as such.

Best regards

3

Hi, thanks for the response, don’t suppose it would be possible to host the API myself, fork the repo and then amend the code so that the foot=yes tags are applied to every bridleway?

4

Given that openrouteservice is fully open source, feel free to do so.

You can find our code on github and our backend documentation here.

Best regards

5

This problem persists even when foot permissions have been set to Yes or to designated on OSM. Is ORS using different data, or is it not recognising the permissions? Or what?

6

Hi @arbuthnot,

for which way? If it was a recent change it might not be in the data openrouteservice currently uses yet.

Best regards

7

I agree it is often a problem of the permissions not being set.
I have checked the OSM permissions and they all include foot.
You can see it on here

and here

but graphhopper gets it right:

and

8

Hey,

yes, this was an issue that was recently fixed:

Note, that while the fix has been merged, it will take some time for the fix to be released and subsequently applied to the public API instances.

Best regards