`barrier=gate` disregarded for foot-walking/foot-hiking

[koebi]

Is there an existing issue for this?

• I have searched the existing issues

Where did you encounter this issue?

live API

Request URL

https://classic-maps.openrouteservice.org/directions?n1=51.510145&n2=7.353694&n3=15&a=51.509161,7.349349,51.511427,7.357997&b=2&c=0&k1=en-US&k2=km

POST Request Body

NONE

Response

NONE

Current behavior

Node https://www.openstreetmap.org/node/9437527488 is disregarded

Expected behavior

Correctly treat gates

Openrouteservice Version

9.3.0

Build date

No response

Graph date

No response

Forum Topic Link

No response

[koebi]

Possibly related to the logic in

openrouteservice/ors-engine/src/main/java/org/heigit/ors/routing/graphhopper/extensions/flagencoders/ORSAbstractFlagEncoder.java

Line 38 in 213d927

public long handleNodeTags(ReaderNode node) {

[aoles]

Most barriers are ignored by the pedestrian profile because usually they are not relevant for it unless explicitly tagged with foot = no. Is the area in question somehow enclosed by a fence and are the gates intended to keep away pedestrians rather than only motorized vehicle traffic? By looking at the surrounding area it seems you could reach the gate you mentioned from the other side by passing another gate tagged with foot = yes.

[koebi]

I was told that it was indeed a locked gate - as is indicated by the locked=yes tag.
In that case, I think foot routing shouldn't pass it?

As for the road being accessible via another way - yup, that is quite often the case, no? Think of one-way streets, nothing unusual there…

[aoles]

Thanks, I see your point. Then probably the logic of handling barrier access for pedestrians needs revising.

[aoles]

Seems to be fixed in GraphHopper v5.0 via graphhopper/graphhopper#2538.