Actually thinking about this in the context of the scenario at https://github.com/graphhopper/graphhopper/issues/2757#issuecomment-1435081431 I think we need a tagging solution to indicate that bicycle/foot may bypass the gate rather than having to travel through the gate. Because while in this situation there is a bypass available, other situations there may not be, and some gates may not be so simple to climb under/over.
Using another highway=path to go around the gate feels wrong as there is really just one highway=track here, there is no separate path running alongside it, so mapping it with one feels like mapping for the router. My thoughts: barrier=gate (there is a gate on the way) motor_vehicle=private (vehicles may legally pass through the gate with permission only) locked=yes (but physical access through the gate is prevented without a key) foot=yes (walkers can legally pass through the gate) bicycle=yes (cyclists can legally pass through the gate) bypass:foot=yes (there is a bypass around the gate for walkers, allowing physical access even without a key) bypass:bicycle=yes (there is a bypass around the gate for cyclists, allowing physical access even without a key) On Thu, 23 Feb 2023 at 11:16, Andrew Harvey <andrew.harv...@gmail.com> wrote: > >> 1. As far as non-emergency routing, the "locked" tag should be >> ignored. >> >> As Andy points out you may have legal access but the gate is still locked > preventing physical access. Therefore routers shouldn't just ignore the > fact that the gate is locked, they should either avoid the route or warn > you you'll encounter locked gates. > > tag value >> barrier gate >> motor_vehicle no >> locked yes >> bicycle yes >> foot yes >> >> I think this tagging says: >> >> - There is a locked gate that blocks motor vehicles >> - There are no access restrictions for pedestrians and bikes >> >> This is not the interpretation of other people, as seen in a discussion >> on a GraphHopper routing issue >> >> https://github.com/graphhopper/graphhopper/issues/2757#issuecomment-1434806229 >> > > In my opinion it depends on the highway=* value that the barrier=gate is > on. If it's something for vehicles like track then I'd interpret that as > the locked gate relates to the vehicle traffic only, a walker or cyclist > can usually simply climb over a locked gate so merely an inconvenience > rather than a true physical access restriction. > > If the highway value was path, footway or cycleway with barrier=gate and > locked=yes then I'd assume it's a gate there to stop walkers/cyclists and > therefore the locked=yes should be considered. > > My interpretation was generally accepted: >> >> 1. As far as the general public, the allowed access for various >> transportation modes is not affected by a "lock" tag: >> >> >> - A "locked=yes" tag does not restrict transportation modes with >> allowed access such as "yes" and "permissive" >> >> >> - A "locked=no" tag does not allow access for otherwise-disallowed >> transportation modes such as "no" and "private" >> >> >> 1. The locked tag should be considered by routing software only when >> used for an "emergency routing" mode. In such a mode, a "locked=no" tag >> may >> be used to allow access for otherwise-disallowed transportation modes. >> >> I would appreciate the help of the tagging list in improving the phrasing >> of my interpretation in order to update the "Key:locked" wiki page soon. > > > That's not my view, as per above, locked=yes would restrict physical > access even if legal access (access=yes) is permitted. > > Interpreting locked=no on access=private would depend on the router, in > situations routers way route on access=private e.g. a driveway to a > property may be access=private, but if your destination was set as the > house on that property it may decide to route you over it. > > I think the tagging for the single transport mode is pretty clear, locked > relates to physical access, access relates to legal access (or perhaps for > physical access if using access=no). >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
