Proposal:Key:opened=

From OpenStreetMap Wiki
Jump to navigation Jump to search
Key:open
Proposal status: Approved (active)
Proposed by: Wielandb on behalf of OPENER
Tagging: open=*, opening=*
Applies to: node
Definition: Whether a feature is normally open
Statistics:

Rendered as: none
Draft started: 2024-01-23
RFC start: 2024-03-19
Vote start: 2024-04-22
Vote end: 2024-05-07


Proposal

This proposal wants to establish the key open=*. Similar to the key locked=*, open=* describes whether an object that can be opened or closed is usually open. This applies to objects such as gates (e.g. barrier=gate) and especially doors (door=*). Additionally, we propose to reuse opening=* to determine the clearance width of an object tagged with open=partial.

Rationale

OSM currently only states the existence of doors, but not if they are open or closed. There is no doubt that most doors in reality can be opened or closed at any time. So their opening state is mostly temporary and should not be mapped in OSM.

However there are doors or gates at public places (e.g. shopping centres, train stations, libraries, parks, universities etc.) that are technically doors or gates but often not perceived as such because they are constantly open. Currently this cannot be represented sufficiently in OSM. Either the doors are not mapped which is wrong (because OSM maps physically present features) or the doors are mapped but then it is not clear that they do not form a barrier.

To give an example: Interior doors at train stations and airports are in control of the the operators and constantly open so passengers can easily pass through. They are usually fixated with a door holder or door stay to prevent them from accidentally snap shutting or being closed by unauthorized people. The doors are only closed in exceptional scenarios like when a fire is broken out or on construction work.

The same logic applies to barriers like arm barriers (barrier=lift_gate) on streets and other features that can be opened / closed.

The information whether something is open by default helps to know if e.g. a door is easily passable. This is especially important for people with strollers, wheelchair users and cyclists. The information can also be used by routing engines to find more suitable / accessible routes.

Tagging

open=* describes the "default state" of a feature that can be opened / closed either by hand or a mechanism. Default means the idle or passive state of the feature without / prior to any user interaction.

Four values are proposed for the key open=*:

  • open=yes - Somehow open. Generic value, use a more specific value if possible.
    • open=full - Completely open. For doors with multiple wings, all wings have to be fully open.
    • open=partial - Only partially open. E.g. just one of several wings is open or one wing is just open to some extent.
  • open=no - Closed (default value). Needs to be opened by hand or a mechanism to pass through.

This tag as well as its default value only applies to elements, which can be opened and closed. So for example it does not apply to elements tagged with:

Automatic doors

Tagging open=* on automatic doors (automatic_door=*) is of limited use, but still possible. It is mostly useful if the doors are out of order / deactivated.

If tagged on operational automatic doors the default state is the state prior to any button press or motion sensor detection.

Clearance width of an open door

Why reusing the "opening" key?

Visualises the measurements of a permanently half-open double door
  • "opening" implicitly describes what should be measured in contrast to "width" or "maxwidth".
  • The term "opening" is linguistically connected to "open".
  • maxwidth:physical=* already describes the fully open clearance width of gates and doors, so it cannot be used.
  • opening:[[Key:|]]=* is already used to tag measurements of barrier=cycle_barrier clearance, which is similar to what is required here. The similarity becomes especially apparent for partially open sliding gates.

Conditional opening

If it is known that a feature is open at specific times or if it follows some other recurring pattern, use the *:conditional=* suffix.

For example:

  • If doors are open, but closed during winter, it can be recorded with open=yes; open:conditional=no @ (winter).
  • If doors are only open during busy hours on Monday to Friday from 7am till 9am, it can be recorded with (open=no); open:conditional=yes @ (Mo-Fr 07:00-09:00).

Relation between open and locked

  • open=no just describes an object (e.g. door) that is normally closed, but not that it is impossible to open or disallowed to pass.
  • locked=yes implies open=no, while open=no does not imply locked=yes or access=*.

Local knowledge

We want to specify that the key open=* should only be used if you have sufficient local knowledge about the place so that you can make a reasonable judgement regarding the value. Do not just tag a value if you visited the place once. This is similar to keys like locked=* and seasonal=*.

Examples

Image Tagging Description
Set of opened double doors inside Chemnitz Main Station.jpg indoor=door

door=hinged

open=full

maxwidth:physical=2

Open door at a train station connecting the entrance hall to the platforms. The door is always fully open, so maxwidth:physical=* is sufficient.
Closed set of double doors at Chemnitz Main Station.jpg entrance=yes

open=no

maxwidth:physical=1.2

Closed door leading to the entrance hall of a train station. This may provide a challenge for wheelchair users. open=no is assumed if not explicitly tagged oherwise.
Set of double doors with one door open at Chemnitz Main Station.jpg entrance=yes

open=partial

opening:[[Key:|]]=0.6

maxwidth:physical=1.2

Partially open door at a train station. While wheelchair users do not have to open the door, their wheelchair may not fit through.
Half-open sliding garage door.jpg barrier=gate

open=partial

opening=1.5

maxwidth:physical=4

A sliding gate of a garage that is partially open. (Note that the image shows a private garage which in reality is probably not regularly open nor legally accessible)
Gate Apples Rosemoor.jpg barrier=gate

open=full

maxwidth:physical=2.2

Open gate at an orchard. The gate is always fully open, so maxwidth:physical=* is sufficient.

Rendering

No special rendering is suggested for general-purpose map styles such as carto. However, indoor map styles are encouraged to adopt specific icons for the different cases.

Features/Pages affected

External discussions

Comments

Please comment on the discussion page.

Voting

Voting closed

Voting on this proposal has been closed.

It was approved with 16 votes for, 5 votes against and 0 abstentions.

  • I approve this proposal I approve this proposal. --Peter Elderson (talk) 13:31, 22 April 2024 (UTC)
  • I approve this proposal I approve this proposal. —Dieterdreist (talk) 13:51, 22 April 2024 (UTC)
  • I approve this proposal I approve this proposal. This gives a definition for an ATYL I was going to use anyway.--Sbre (talk) 13:56, 22 April 2024 (UTC)
  • I oppose this proposal I oppose this proposal. The door state open=partial is also open. opening=* is already there as maxwidth:physical=*. See this discussion. Examples in the proposal use maxwidth:physical=* for the width=* of the door, but maxwidth:physical=* applies here, as this proposal assumes the common door state is permanent enough to be mapped. --Fabi2 (talk) 14:19, 22 April 2024 (UTC)
  • I approve this proposal I approve this proposal. --Nielkrokodil (talk) 16:22, 22 April 2024 (UTC)
  • I approve this proposal I approve this proposal. I think this is an essential information for wheelchair users. —Gymate (talk) 17:21, 22 April 2024 (UTC)
  • I approve this proposal I approve this proposal. --Hypo808 (talk) 13:16, 24 April 2024 (UTC)
  • I approve this proposal I approve this proposal. This will be very useful for the default handling of barrier accessibility in routing engines. open=yes is more specific than access=yes here. This also allows more detailed travel time estimations at accessible barriers, i.e. whether you have to wait for the barrier to open or whether it is already open. --JeroenvanderGun (talk) 17:39, 24 April 2024 (UTC)
  • I approve this proposal I approve this proposal. --Adiatmad (talk) 04:23, 25 April 2024 (UTC)
  • I approve this proposal I approve this proposal. Having mapped lots of gates that are actually permanently open, this would be a very useful tag for routing and rendering. HellMap (talk) 11:00, 26 April 2024 (UTC)
  • I oppose this proposal I oppose this proposal. The subject of the proposal is important, but the proposal is not yet ready for voting. At least, two things should be added: (a) relation of the "open" tag to the "locked" tab ("locked" is missing in the examples) (b) tagging of closed doors that can be opened by pushing a button or by light barrier --voschix (talk) 17:06, 27 April 2024 (UTC)
  • I approve this proposal I approve this proposal. --Tokada (talk) 12:22, 28 April 2024 (UTC)
  • I approve this proposal I approve this proposal. --Michi (talk) 19:12, 28 April 2024 (UTC)
  • I approve this proposal I approve this proposal. I think that, as of currently, the users that voted no aren't correct for the following reasons: (1) open=partial is meant to apply, as I understood it, to doors that can be partially opened to a fixed position and (2) I don't think that the open=* tag is meant to describe the way in which you open the doors themselves and I'm not convinced it should be that way. What makes me a little bit hesitant to vote yes is that it doesn't explicitly state the relation of this tag to the opening hours of the map feature on which the doors are. But I think this is more of a nitpick and can be assumed that open=yes, means that during the opening hours. --comfyquiettree (talk) 18:13, 5 May 2024 (UTC)
  • I oppose this proposal I oppose this proposal. I see no need for this feature --chris66 (talk) 19:04, 5 May 2024 (UTC)
  • I approve this proposal I approve this proposal. This feature will let me plan hiking routes based on the number of gates I need to wrangle. --Carnildo (talk) 19:29, 5 May 2024 (UTC)
  • I approve this proposal I approve this proposal. --Nacktiv (talk) 22:08, 5 May 2024 (UTC)
  • I approve this proposal I approve this proposal. --Uboot (talk) 07:16, 6 May 2024 (UTC)
  • I approve this proposal I approve this proposal. --GanderPL (talk) 08:40, 6 May 2024 (UTC)
  • I oppose this proposal I oppose this proposal. Wherever a feature is closed or opened is in my opinion too temporary to be mapped in OSM, beyond this, is seems a tag too redundant to locked=* --Szydzio (talk) 11:59, 6 May 2024 (UTC)
  • I oppose this proposal I oppose this proposal. I don't see the point of this tag - whether a gate or door is open is temporary. They are open during the day and closed at night. It is not a permanent feature. After all, we don't know if the door is closed permanently or only at a given moment. maro21 21:35, 6 May 2024 (UTC)