There it is again, the difference between physical and legal access rights.
It also depends a bit on which barrier=* locked=yes coincides. If barrier=bollard + locked=yes, then it is clear that foot=* and usually also bicycle=* can still get past the bollard=*, although barrier=bollard + locked=no would make no sense anyway, I see (a bollard which can be removed without any key or something? :-DD ).
> At least "locked" should imply access=destination or private for routers.
Yeah, I think that, too (for locked=yes). Unless access tags are given, of course.
Although apart from gates I don't actually know of any barrier that can be locked=yes and where access is not legally restricted, at least to "destination".
For gates you really should be able to tag the bypass. Because this is in fact not influenced by the "locked", as usally you can NOT lock the "bypass" (if it exists) and so people cannot physically restrict access to the bypass, at least not with a lock.
Gesendet: Donnerstag, 23. Februar 2023 um 13:38 Uhr
Von: "Niels Elgaard Larsen" <elga...@agol.dk>
An: tagging@openstreetmap.org
Betreff: Re: [Tagging] Combining "locked=yes" with various access tags
Von: "Niels Elgaard Larsen" <elga...@agol.dk>
An: tagging@openstreetmap.org
Betreff: Re: [Tagging] Combining "locked=yes" with various access tags
Zeev Stadler:
> I would like the help of the list to clarify the meaning of having a "locked=yes" tag
> on a barrier node together with some allowed access tags.
>
> The introduction to the "locked" tag wiki page
> https://wiki.openstreetmap.org/wiki/Key:locked
> <https://wiki.openstreetmap.org/wiki/Key:locked> says:
>
> access <https://wiki.openstreetmap.org/wiki/Key:access>=* is used to describe the
> legal permission to travel through a barrier but does not indicate in emergencies
> what the physical access is
>
>
> Therefore, my understanding is that
>
> 1. As far as non-emergency routing, the "locked" tag should be ignored.
We have to accept that the tagging is never complete. And when surveying, it is often
easier to tag "locked" than "access" (we can se the lock or try to open the gate but
there are often no signs). So the tagging might reflect that we know that a gate is
usually locked, but we do not know who can use the gate.
At least "locked" should imply access=destination or private for routers.
A router that suggests shortcuts passing locked gates will not be popular.
> 2. A "locked=no" tag indicates that a legal access restriction is not enforced by a
> lock and therefore could be overcome in case of an emergency.
> 3. A "locked=yes" tag indicates that the legal access restriction is enforced by a
> lock and therefore cannot be overcome in case of an emergency.
>
> The "How to map" description in the wiki page seems to assume a gate or a barrier
> with a simple "access=no". It is not clear with respect to any permitted access methods.
>
> For example, barrier node with the following tags:
>
> tag value
> barrier gate
> motor_vehicle no
> locked yes
> bicycle yes
> foot yes
The wiki on motor_vehicle say: "This property is used for all types of roads but not
for gates."
> 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
Yes.
According to the wiki, motor_vehicle=no means that motor vehicles are not allowed to
travel through the barrier. The wiki does not say that having a key to the lock
changes that.
motor_vehicle=permit/private, locked=yes would be more appropriate if you wanted to
say that cars need a key to pass.
We should also recognize that we do in fact use access tags for other things than
legal access. For example "bicycle" is defined as "Legal restriction for cyclists."
But on cycle_barrier the wiki says:
==
bicycle=no - "a normal bicycle will not physically fit (without dismantling it or
lifting it over the barrier)"
bicycle=dismount - "barrier prevents users of normal bicycles from riding through,
but you can push a bike through"
==
motorcar=no might just mean that a car is too big to pass through the gate, and
having a key would not make a difference.
We could also tag e.g., motor_vehicle=key or motor_vehicle=unlock
It would make sense to tag the legal access on the way and then on the barrier
specify what you have to do to pass it.
For example it is common on private property
> https://github.com/graphhopper/graphhopper/issues/2757#issuecomment-1434806229
> <https://github.com/graphhopper/graphhopper/issues/2757#issuecomment-1434806229>
>
> There you could also find a picture of such a barrier.
>
> Please help us resolve the differences
>
> _______________________________________________
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
--
Niels Elgaard Larsen
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
> I would like the help of the list to clarify the meaning of having a "locked=yes" tag
> on a barrier node together with some allowed access tags.
>
> The introduction to the "locked" tag wiki page
> https://wiki.openstreetmap.org/wiki/Key:locked
> <https://wiki.openstreetmap.org/wiki/Key:locked> says:
>
> access <https://wiki.openstreetmap.org/wiki/Key:access>=* is used to describe the
> legal permission to travel through a barrier but does not indicate in emergencies
> what the physical access is
>
>
> Therefore, my understanding is that
>
> 1. As far as non-emergency routing, the "locked" tag should be ignored.
We have to accept that the tagging is never complete. And when surveying, it is often
easier to tag "locked" than "access" (we can se the lock or try to open the gate but
there are often no signs). So the tagging might reflect that we know that a gate is
usually locked, but we do not know who can use the gate.
At least "locked" should imply access=destination or private for routers.
A router that suggests shortcuts passing locked gates will not be popular.
> 2. A "locked=no" tag indicates that a legal access restriction is not enforced by a
> lock and therefore could be overcome in case of an emergency.
> 3. A "locked=yes" tag indicates that the legal access restriction is enforced by a
> lock and therefore cannot be overcome in case of an emergency.
>
> The "How to map" description in the wiki page seems to assume a gate or a barrier
> with a simple "access=no". It is not clear with respect to any permitted access methods.
>
> For example, barrier node with the following tags:
>
> tag value
> barrier gate
> motor_vehicle no
> locked yes
> bicycle yes
> foot yes
The wiki on motor_vehicle say: "This property is used for all types of roads but not
for gates."
> 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
Yes.
According to the wiki, motor_vehicle=no means that motor vehicles are not allowed to
travel through the barrier. The wiki does not say that having a key to the lock
changes that.
motor_vehicle=permit/private, locked=yes would be more appropriate if you wanted to
say that cars need a key to pass.
We should also recognize that we do in fact use access tags for other things than
legal access. For example "bicycle" is defined as "Legal restriction for cyclists."
But on cycle_barrier the wiki says:
==
bicycle=no - "a normal bicycle will not physically fit (without dismantling it or
lifting it over the barrier)"
bicycle=dismount - "barrier prevents users of normal bicycles from riding through,
but you can push a bike through"
==
motorcar=no might just mean that a car is too big to pass through the gate, and
having a key would not make a difference.
We could also tag e.g., motor_vehicle=key or motor_vehicle=unlock
It would make sense to tag the legal access on the way and then on the barrier
specify what you have to do to pass it.
For example it is common on private property
> https://github.com/graphhopper/graphhopper/issues/2757#issuecomment-1434806229
> <https://github.com/graphhopper/graphhopper/issues/2757#issuecomment-1434806229>
>
> There you could also find a picture of such a barrier.
>
> Please help us resolve the differences
>
> _______________________________________________
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
--
Niels Elgaard Larsen
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
