bicycle=unknown ways are restricted

Open Source Routing Engine
1

ways with any unknown values are restricted[1]. Which is causing any bicycle=unknown ways to be removed from the graph as well.

Here is a sample: https://graphhopper.com/maps/?point=48.929559%2C8.450231&point=48.929574%2C8.450448&profile=bike&layer=Omniscale

Relevant Way is this: https://www.openstreetmap.org/way/44357284#map=18/48.929296/8.452617

IMO unknown should not be treated as a no and completely restricted for the bicycle tag. Since it simply means “unknown” and can be penalized by other tags when needed, but complete removal causing weird routing as in the example.

Am I missing something for this case? I’m happy to discuss and open a PR to fix it on BikeCommonAccessParser

2

Isn’t this a tagging issue? I don’t understand the advantage of this tag compared to a situation without it.

3

Isn’t this a tagging issue?

Kind of.

I don’t understand the advantage of this tag compared to a situation without it.

I agree. That is why it shouldn’t be treated as bicycle=no and gets removed from the graph. Its likely to be usable by bikes, worst case by dismounting etc. But removing it makes the routing impossible.

So I suggest to remove it from restrictedValues in BikeCommonAccessParser.

What do you think? I’m new to routing, maybe I’m missing something?

4

It is a good idea to remove it completely. However removing it from the restrictedValues would mean that cases like

way.clearTags();
way.setTag("highway", "service");
way.setTag("access", "no");
way.setTag("bicycle", "unknown");

would not lead to just ignoring the bicycle=unknown tag. Instead the bicycle tag would still be picked up as the “most important” tag in the access hierarchy and as then the unknown value is not in the list it would be interpreted as “access allowed”.

At least this is how it currently works. I.e. tagging mistakes regarding access tags can cause a bit trouble, which is ugly.

See this pull request for a fix.