Proposal:Key:locked

The Feature Page for the approved proposal Key:locked is located at Key:locked

Key:locked
Proposal status:	Approved (active)
Proposed by:	aharvey
Tagging:	locked=* Data item
Statistics:
Draft started:	2020-03-26
RFC start:	2020-03-26
Vote start:	2020-04-19
Vote end:	2020-05-03

Proposal

• locked=yes The gate or barrier is usually locked and not accessible without the key.
• locked=no The gate or barrier is usually unlocked and is accessible to anyone (may still need to manually open the gate).
• locked:conditional=* To specify a condition different to the default locked value per https://wiki.openstreetmap.org/wiki/Conditional_restrictions. eg. locked:conditional=yes @ (sunset-sunrise) to say that the gate is locked at night, combined with locked=no to indicate usually unlocked during the day.

A key does not need to be a traditional key, it could be a contactless card, swipe card, or a PIN code.

Rationale

access=* is used to describe the legal permission to travel through a barrier but does not indicate in emergencies what the physical access is.

For example it can be very important to know if a gate on a roadway is usually locked and hence can't be accessed easily without obtaining the key or unlocked and can easily be opened/closed.

Examples

• A bicycle parking cage which requires a public transport card to open would be tagged locked=yes since you need a "key" in this case the swipe card to get inside. locked=yes does not make any comment on how widespread or easily obtainable the key is, just that you need a key.

Applies to

• barrier=gate
• barrier=chain
• barrier=lift_gate
• barrier=swing_gate
• bicycle_parking=shed
• bicycle_parking=building
• bicycle_parking=lockers
• amenity=toilets

See also

• barrier:personnel=* which applies to barriers which have personnel to restrict access.

External discussions

https://lists.openstreetmap.org/pipermail/tagging/2020-March/051734.html

Comments

Please comment on the discussion page.

Voting

Voting closed

Voting on this proposal has been closed.

It was approved with 19 votes for, 3 votes against and 1 abstention.

• I approve this proposal. --EneaSuper (talk) 11:19, 26 April 2020 (UTC)

• I approve this proposal. --Aharvey (talk) 12:00, 19 April 2020 (UTC)
• I approve this proposal. I'd still like to see the "Applies to" section include toilets for the disabled. Just to make it clear that it does actually apply to them. --Brian de Ford (talk) 12:19, 19 April 2020 (UTC)
• I approve this proposal. I was contemplating to write a proposal like this, and I'm glad someone finally did it. Slaves of erratic validators have been spamming barrier=gate/lift_gate/swing_gate nodes with bogus access tags for years, and for buildings etc. we also need to distinguish access from lock status. It would have been desirable to incorporate a tagging scheme for lock types and operation into this proposal, but at least it is now quite simple and uncontroversial. We can add additional keys for lock types (including "none") and operation later on, such as operation=manual/switch/remote/smart_card/fingerprint, as I suggested on the Talk page of a rejected proposal that tried to introduce a tagging scheme that was way too complicated and unnecessarily specific to doors. What I'm missing in your proposal is a value for "irregularly". This may even be considered the default if a lock (or attachment point for a lock) is encountered and no lock schedules are known. --Fkv (talk) 14:36, 19 April 2020 (UTC)
• I oppose this proposal. Sorry, but I believe the access key covers this. If a gate requires a key, then tag access=private/no. If it is unlocked, that's a sure access=yes. Feel free to comment and try to change my mind, maybe I don't understand it completely. --Floridaeditor (talk) 15:24, 19 April 2020 (UTC)

The access=* keys define legal restrictions, not physical restrictions. A lock is a physical restriction. A locked barrier=lift_gate doesn't mean that you aren't allowed to pass it. You can walk around it or shift your bicycle over it. And conversely, an open gate does not mean that you are allowed to pass it. There may be a sign prohibiting trespassing. These access restrictions concerning ways or areas behind a barrier shouldn't be tagged on the barrier anyway. They should be set on the ways or areas. Nobody cares if you walk to the gate, unless you enter the way or area behind it. access=* tags on gates should be used to describe who is allowed to operate (open, close) them. Then again, a lock doesn't mean that you aren't allowed to operate it. You just can't do it physically. Respectively, the absence of a lock doesn't mean that you are allowed to operate the gate or door. If you open the door to a house without ringing the bell, you may not be welcome, and the dog may bite you. --Fkv (talk) 17:10, 19 April 2020 (UTC)

I respect your opinion, but OSM is not used for trying to break the law. Legal restrictions should be the only thing we follow, not physical. Also, yes, the access tag is absolutely meant for the access restrictor. --Floridaeditor (talk) 17:24, 19 April 2020 (UTC)

Your reply ("Legal restrictions should be the only thing we follow, not physical.") contradicts your initial comment ("If a gate requires a key, then tag access=private/no. If it is unlocked, that's a sure access=yes."). Make up your mind. --Fkv (talk) 17:43, 19 April 2020 (UTC)

What are you talking about? An unlocked gate means you are legally allowed to go through! --Floridaeditor (talk)!

That is plain wrong, and I already delivered you an example. Trespassing (or Besitzstörung in German) is illegal in most countries and you can be sued for it. --Fkv (talk) 19:49, 19 April 2020 (UTC)

In America, that only applies to residential gates or any gate with a no trespassing sign. This tag is supposed to be for use with residential gates? If so, doubly oppose. If not, then the access=* key covers it. --Floridaeditor (talk) 21:47, 19 April 2020 (UTC)

If you ever had a glance at the OSM map, you might have noticed that the US is not the only country in the world. Voting a tag down when you know it is needed in other countries is selfish and anti-social behavior that is not adequate in a world-wide community project such as OSM. Besides, I doubt that it is legal in the US to crawl into a house thru an open window when there is no trespassing sign on it. --Fkv (talk) 22:27, 19 April 2020 (UTC)

Being rude to others isn't helping the other person's proposal --Floridaeditor (talk) 10:42, 20 April 2020 (UTC)

Floridaeditor, you seem to ignore the way Germans are expressing (at least on OSM). Yes, it could be better expressed. It may look rude, but it's a fact: OSM is not and should not be US-centric. BTW, you said America, I doubt Chile for instance was meant. --Nospam2005 (talk) 18:06, 29 April 2020 (UTC)

I'm from the western USA, and I can confirm there are lots of gates in rural areas which are unlocked, but signed "no trespassing". Not all farmers and ranchers want to pay for a lock on every gate. And the US Forest Service also has many locked gates on forest roads which are meant to stop motor vehicles, but where pedestrians and cyclists are legally allowed to pass - usually there is room to get around the gate on one side. While tagging motor_vehicle=no + bicycle=yes + foot=yes is a good idea, it's also fine to have a tag like locked=yes/no in addition. --Jeisenbe (talk) 22:38, 19 April 2020 (UTC)

As others have mentioned, take for example a gate to a property, it might have a sign up saying private property do not enter which means access=private, however the ambulance might like to know if that gate is locked or not. It would be wrong to say access=yes simply because the gate is unlocked because the signage says private property do not enter. --Aharvey (talk) 23:09, 19 April 2020 (UTC)

I'm aware of a building in a campground that is both "access=yes" and "locked=yes": it's got a combination lock on the door with the code written above it. The purpose of the lock is to keep bears and small children out. --Carnildo (talk) 04:30, 25 April 2020 (UTC)

• I approve this proposal. --Dr Centerline (talk) 17:35, 19 April 2020 (UTC)
• I oppose this proposal. IMO the key tag is access=*. On each barrier, door, entrance or enclosed amenity it is essential to know, who is able to enter or pass (legal, private or permissive). If there is a locked lock, access can't be "yes". It should be "customers" or "private". If access is "yes", locked can't be "yes". E.g. if you need a keycard to use a toilet, you can be called a customer. If there is demand to specify, you might use tagging for "authentication:" like with amenity=charging_station. – My concern is, because in many cases there are still missing or uncomplete access tags, another similar tag is counterproductive, from my point of view. --Chris2map (talk) 19:15, 19 April 2020 (UTC)

An example is public toilets which are by definition open to the public so access=yes, but during night times they may be locked. Yes you can and should still use opening_hours, but the locked tag makes it very clear that there is a physical restriction to access independent of the legal restriction. --Aharvey (talk) 23:38, 19 April 2020 (UTC)

• I approve this proposal. I approve this proposal. Some people are voting "no" and saying that only access should be used, but that's silly. Many gates in rural areas are unlocked, but the access is still private. And as mentioned, some gates are locked, but can be legally passed by pedestrians. So there are certainly some places where this tag will be needed. Having this tag available will not stop people from adding the more common "access=" tagging. --Jeisenbe (talk) 22:34, 19 April 2020 (UTC)
• I approve this proposal. --Waldhans (talk) 06:28, 20 April 2020 (UTC)
• I approve this proposal. Legit distinction between right to access (access=*) and ability to access. Thank you Fanfouer (talk) 10:13, 20 April 2020 (UTC)

• I approve this proposal. Although a bit specific, I understand this could be useful in some situations. My vote is in favor, but the wiki must be very well built, with good examples for clarification. --AntMadeira (talk) 15:58, 20 April 2020 (UTC)
• I approve this proposal. I can also understand this can be useful for particular situations, although there could be in general verifiability problems (you can see the presence of a lock, but for a more reliable infomation about the locked/open status you would have to frequently check whether it is locked, or whether they might have started locking it)--Dieterdreist (talk) 17:30, 20 April 2020 (UTC)

• I approve this proposal. --Sommerluk (talk) 10:41, 21 April 2020 (UTC)
• I approve this proposal. Access tagging simply can't cover every situation (eg. an unlocked gate with an "emergency vehicles only" sign). --Carnildo (talk) 04:30, 25 April 2020 (UTC)

• I approve this proposal. --Gendy54 (talk) 10:58, 26 April 2020 (UTC) Differences between legal restriction and physical restriction are interesting

• I approve this proposal.The differences are important, e.g. for service highways and gates there. --Heilbron (talk) 11:26, 26 April 2020 (UTC)

• I oppose this proposal.I think that this information may be useful in a few cases. However I think the authentication=* tagging scheme should be used in addition to access=*, as it already exists and allows specifying what type of lock/key it is. This information may be useful for disabled people for example. --Gileri (talk) 15:13, 26 April 2020 (UTC)

While I agree we should have a way to tag the authentication method, I find that authentication=* is still limited. eg. for a lock with a metal key that doesn't seem to be included on the list for authentication=*, what if it's a special kind of shared key like the MLAK key in Australia, or what if it's a public transport card, while technically it might be NFC ideally we'd have a way to say you need a specific kind of NFC card (eg. Opal card in NSW, Australia). --Aharvey (talk) 02:32, 3 May 2020 (UTC)

• I approve this proposal. --Libarch (talk) 18:46, 26 April 2020 (UTC)
• I approve this proposal. Have been using it and evaluating it on my maps for a long time. Was sort of surprised that there is a proposal now. :-) --Nop (talk) 19:01, 26 April 2020 (UTC)
• I have comments but abstain from voting on this proposal. I was about to vote yes, but Gileri and Fanfouer changed my mind: it's more generic but not exactly suitable for this case. locked=* can indicate the kind of lock and authentication=* how to unlock. --Nospam2005 (talk) 18:06, 29 April 2020 (UTC)

Keeping it as a simple yes/no now is a start, type of lock and authentication can be added as another proposal, eg lock:type=*. --Aharvey (talk) 02:32, 3 May 2020 (UTC)

• I approve this proposal. --Nw520 (talk) 17:51, 30 April 2020 (UTC)
• I approve this proposal. This will help enormously when I come to map a gate. Hitherto I’ve just had to leave the tagging as barrier=* whenever I see a gate, whether open or closed,

locked or not. This is often not very helpful. Legality of passage is independent of all of this. I‘ll be assuming locked=yes means locked closed. On the odd occasion that I come across a gate locked open I will probably tag locked=no and add note=* unless I see a better suggestion. I‘ve also come across gates - both closed and open - that are unlocked but lockable, often with a lock left at the gate (presumably for convenience). I’ll have to think how to deal with such cases once locked=* gains traction. --Motogs (talk) 14:49, 2 May 2020 (UTC)

• I approve this proposal. It is certainly possible to use both this key and eg authentication:*=* to show both the normal lock positio (and there can be a new key for normal barrier position as well, for ones that are usually open), and unlocking mechanism. Or even a new key on the pressence of a lock (since authentication and lock may not directly correspond), and another one on the locking mechanism (eg you may be required to indirectly lock it again after you pass). This feels quite free and open.-- Kovposch (talk) 15:04, 2 May 2020 (UTC)