How does Foot=Yes affect bike routing?

I have noticed that bike routing differs depending on my choice of Bike, MTB or Racing Bike.
Can anyone explain why?

Is there also difference in routing if a cycleway has Foot=Yes or not?

My problem is that in some cases bike routing take the streets instead instead of the cycleway.
Mainly where the cycleway has a long distance.

Racing bike favours bigger streets and bike favours ‘normal’ or more silent ones.


Your example is indeed incorrect and it should take the cycleway and the cycleway does look good: According to the name there for the recent change: did you create this way? If yes, then it can take 2-3 days until we recognize new data.

For experimental study I took away Foot=Yes to see if it matters. Does it? The cycleway itself was an old one.

If there were some kind of difference, I noticed that Bike was the alternative that prefered streets before cycleways. Not MTB or Racing Bike. They used the cycleway.

Which parameter in OSM is to tell routing if it is a big street or normal/silent one?

If the cycleway would be excluded via foot=yes then this would be a bug. Let us see if this was the case and if so, we’ll fix this. Afterwards please revert this change and grab the data to your local machine and edit it there for experiments, many of us would be not happy if all people do experiments with the real database :slight_smile:

Which parameter in OSM is to tell routing if it is a big street or normal/silent one?

There are several ways to do this as a mapper, but you should not map for the router instead just map the reality and we try to do our bests :slight_smile:

A little more experience of the matter:
In my town almost every combined foot- and cycleway is coded CYCLEWAY in OSM. In some cases, where I updated the geometry, I added Foot=Yes to reflect the reality more. In my town we haven´t got any dedicated cycleways but they´re always open for pedestrians.

In the example above I had issues in routing. Graphhopper took the parallell street instead of the cycleway when Foot=Yes was added. That applied in case of (trekking?) bike but not when MTB or road bike where used. They used the cycleway nice and fine.

For the routing to work best, I am forced to take away Foot=Yes or else the standard bike takes the streets sometimes. How can we handle this in a good way?
You said that routing was affected depending on the Foot=Yes parameter but not in what way. Can you explain this a little more?

Did you recently change the OSM data? I tried to invesigate your report and downloaded the latest OSM data via JOSM and used it as testcase for my master banch. As I was not able to reproduce the issue with my branch, I tested graphhoper master and even there I cannot reproduce, altough on the online instance I do see the reported issue.

By the way: For improved routing I recommend to add and set the segrated when adding a foot=yes to a cycleway, Otherwise the priority gets reduced compared to a cycleway with foot=yes without the tag. Per default we assume segregated=no.

I try to use segregated=yes to see how Graphhopper reacts. I think it´s a pitty that a bike route is taking a street instead of a combined foot- and bikeway. In my opinion that is not correct. At least not if they run parallell and is almost the same distance.

By law, in Sweden, a cyclist is forced to use the cycleway if there is one and most of the time they are combined with pedestrians. Sometimes separated by a line, sometimes not.

Thanks for your explaining answer!

My hint with the segregated tag was just for information. As said this does not seem to be a matter in the Graphhopper source code as it works, just the online instance is broken, most likely is due to not synchronized input data.

I end this discussion with the knowledge that, in this specific case, that segregated=yes does the trick!
I will code the rest of our cycleways where there is some kind of separation to make it more “attractive” for Graphhopper.

Thank you for your help!