Foot routing requirements

Please excuse my ignorance if this is not the correct place for my following question:
GraphHopper Driving Directions has become my first choice to compile circular hiking routes for my own pleasure. It retains my interest and participation in OpenStreetMap, too. There were three instances in my most recent attempted compilation where GraphHopper would not route where I wanted. Nothing untoward showed itself on my actual walk, however. The one common factor I discovered on my return and using JOSM to analyse the situation was that ‘foot’ did not appear in the keys or values of the ways concerned. They might consist of highway/bridleway and bicycle/yes only, for example. Might this be the reason or, if not, is there another requirement in OSM or some other possible reason?

Here is the perfect place to ask any sorts of questions regarding GraphHopper, including GraphHopper Maps :slight_smile:

Really nice to hear that!

Would you provide GraphHopper Maps links for that? And foot could be indeed a bit restricted if it is not explicitely tagged e.g. like created an issue here regarding the bridleway problem you mentioned.

Peter
I thank you for your reassuring words and offer to help. I have tried to reply with three pairs of uploaded GraphHopper and JOSM .png files. I receive the message, “Sorry, new users can only put one image in a post.”. I have logged out and in again with no better result.
Bob

I’ve enabled this for you - can you try again? Also please link to GraphHapper Maps.

Peter
The highlighted red way in JOSM is the offender in each instance. I was responsible for adding foot=yes yesterday, which was not present when I attempted to compile the circular walk.
Example 1 GH:
https://graphhopper.com/maps/?point=51.604798%2C-0.943301&point=51.60773%2C-0.942593&locale=en-US&vehicle=foot&weighting=fastest&elevation=true&layer=OpenStreetMap


Example 1 JOSM:

Example 2 GH:
https://graphhopper.com/maps/?point=51.601946%2C-0.952249&point=51.600826%2C-0.959759&locale=en-US&vehicle=foot&weighting=fastest&elevation=true&layer=OpenStreetMap

Example 2 JOSM:

Example 3 GH:
https://graphhopper.com/maps/?point=51.593362%2C-0.960832&point=51.58571%2C-0.957699&locale=en-US&vehicle=foot&weighting=fastest&elevation=true&layer=OpenStreetMap

Example 3 JOSM:

I hope this is of help.
Bob

Yes, that is the German default foot=no for bridleway which we are currently not able to apply differently e.g. for UK. But after fixing this we can easily fix this bridleway issue (and the similar one on github)

Peter
I am sorry: do you mean that the existence of ‘bridleway’ equates to foot=no in the current computation, so every instance of ‘bridleway’ as an attribute will result in this problem and that adding foot=yes will not alter that situation?

The problem is that GraphHopper handles bridleway as “foot=no”, if nothing is tagged, which is correct in Germany but not elsewhere. Adding foot=yes should solve the issue but will take ~1day for an update. See the ‘+’ after the route instructions for the data age. If this does not fix the issue then it is a bug and should be fixed quickly :slight_smile:

Your reply makes total sense when I read http://wiki.openstreetmap.org/wiki/Tag:highway=bridleway again. I shall pay attention to the arrival of the updated data. I must think responsibly what my actions should be because of “Public bridleways should be tagged: highway=bridleway and designation=public_bridleway” in the webpage above, inferring this situation must exist in innumerable instances here. Do you have plans for the fix you describe, in the not-too-distant future?
I thank you for your clarification.

We have no concrete plans for this in the near future, but it is open source after all :wink:

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.