Not blocking private locked=yes barrier for foot

Triggered by a report in the OSM Forum I can confirm that the online graphhopper instance really routes through a locked private gate barrier.

This is the barrier node in observation.

It does not happen in my local instance, where I’m using only the custom foot.json profile.

What additional rule is active on the online instance? Can you please check and evaluate if this intended?

I think the problem is access=private, which we currently ignore (with foot_access|block_private=false) as it is very often only motor vehicles related and imprecisely tagged. I have no good solution for this in mind - maybe you have :slight_smile: ?

I have no good solution for this in mind - maybe you have :slight_smile: ?

Maybe respect locked=yes even if routing over private segments is configured?

Yes, we can try this.

I’m going to prepare a PR.

Out of curiosity, can you give some examples of where people are tagging access=private when they mean motor_vehicle=private? Does that apply to barrier=gate or just specific types of barriers, like barrier=bollard. Might be useful to document this in the wiki so people know they have to tag foot=no along with access=no if they really mean it.

Might also be worth it to consider honoring access=private when both of the connected ways already prohibit motor vehicles (implicitly or explicitly).