Proposal:Key:opened=
| Key:open | |
|---|---|
| Proposal status: | Voting (under way) |
| Proposed by: | Wielandb on behalf of OPENER |
| Tagging: | open=*, opening=* |
| Applies to: | 
|
| 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 |
 |
The proposal initially started with the key opened=* to follow the existing locked=* tag. However we realized that "opened" is only used as a verb or when something has recently been opened and therefore changed it to open=*. See: |
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=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:
- door=no or door=revolving
- barriers like barrier=entrance, barrier=turnstile, barrier=cycle_barrier etc.
- automatic_door=continuous
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
- For open=full, the key opening=* can be omitted as it is already covered by maxwidth:physical=* (or sometimes other dimensional keys like door:width=* / width=* that describe the distance between the doorposts).
- For open=partial, the key opening=* is used to record the clearance width of the opening.
Why reusing the "opening" key?
- "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=* 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 |
|---|---|---|
|
indoor=door | Open door at a train station connecting the entrance hall to the platforms. The door is always fully open, so maxwidth:physical=* is sufficient. |
|
entrance=yes | 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. |
|
entrance=yes | Partially open door at a train station. While wheelchair users do not have to open the door, their wheelchair may not fit through. |
|
barrier=gate | 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) |
|
barrier=gate | 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
- Log in to the wiki if you are not already logged in.
- Scroll down to voting and click 'Edit source'. Copy and paste the appropriate code from this table on its own line at the bottom of the text area:
| To get this output | you type | Description |
|---|---|---|
|
{{vote|yes}} --~~~~
|
Feel free to also explain why you support proposal. |
|
{{vote|no}} reason --~~~~
|
Replace reason with your reason(s) for voting no. |
|
{{vote|abstain}} comments --~~~~
|
If you don't want to vote but have comments. Replace comments with your comments. |
~~~~ automatically inserts your name and the current date.For full template documentation see Template:Vote. See also how vote outcome is processed.
I approve this proposal. --Peter Elderson (talk) 13:31, 22 April 2024 (UTC)- I approve this proposal. —Dieterdreist (talk) 13:51, 22 April 2024 (UTC)
- 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. 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. --Nielkrokodil (talk) 16:22, 22 April 2024 (UTC)
- 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. --Hypo808 (talk) 13:16, 24 April 2024 (UTC)
- 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. --Adiatmad (talk) 04:23, 25 April 2024 (UTC)
- 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)