Proposal:Entrance/door
Warning
This page is available for documentation purposes. Please see User:Andreas.balzer/door-proposal-version2 for updated draft version.
entrance:door | |
---|---|
Proposal status: | Rejected (inactive) |
Proposed by: | Andreas.balzer |
Tagging: | entrance:door=* |
Applies to: | node |
Definition: | To specify the type of door and its operation. |
Statistics: |
|
Draft started: | 2011-11-17 |
RFC start: | 2011-11-17 |
Vote start: | 2011-12-24 |
Vote end: | 2012-01-07 |
Proposal
This proposal suggests a tag door to specify doors to be used for mapping of buildings and rooms, especially useful for future use of indoor navigation.
Tagging
General Door Specification
To specify that the current node has a door, use the two following tags:
- barrier=door specifies that the node containing the key is a door
- entrance=yes specifies that the node containing the key is a building entrance, i.e. an external door
Type of door
Key | Value | Element | Comment | Rendering | Photo |
---|---|---|---|---|---|
door | hinged | The door is a standard hinged type door. This is the default (Providing every entrance with a hinged typed door per default). A hinged type door implies wheelchair=no if not specified indirectly by door:electricallyoperated:switch=neartodoor or exclusively at the entrance node or specified exclusively at the building node and being the only entrance node without an exclusive specified wheelchair attribute. | and [1] | ||
door | sliding | The door is a sliding type door. | [2] | ||
door | loadingdock | The door is a loading dock. | [3] and [4] | ||
door | accordion | The door is an accordion type door. | [5] and [6] (folding door) | ||
door | overhead | The door is an up-and-over type door. | [7] | ||
door | rotating | The door is a rotating type door. You usually find these doors in shopping malls. If door:electricallyoperated=yes this door moves automated. If door:electricallyoperated=no, a person needs to push it. | [8] |
Physical details of door opening
Key | Value | Element | Comment | Rendering | Photo |
---|---|---|---|---|---|
door:safearea | ID | ID of area being the more safety area this door connects to. | |||
door:unsafearea | ID | ID of area being the less safety area this door connects to. | |||
door:safetydirection | safe | The door opens towards the more safety area, e.g. into the room or into the building. | |||
door:safetydirection | unsafe | The door opens towards the less safety area, e.g. out of the room or out of the building. | |||
door:direction | up | The door opens upwards. | |||
door:direction | down | The door opens downwards. | |||
door:direction | left | The door opens to the left side of a persons perspective being in the more safety area. If the door is a hinged or sliding door (see door:type), this direction is opposite for a person on the other side. | |||
door:direction | right | The door opens to the right side of a persons perspective being in the more safety area. If the door is a hinged or sliding door (see door:type), this direction is opposite for a person on the other side. |
Accessibility information
Key | Value | Element | Comment | Rendering | Photo |
---|---|---|---|---|---|
door:electricallyoperated | yes | The door is electrically operated. If door:electicallyoperated:switch is not specified, the door opens automatically. | |||
door:electricallyoperated:switch | yes | The door has a switch. It will not open automatically without the user triggering the switch. | |||
door:electricallyoperated:switch | remote | The door has a remote operating as a switch. The door will not open automatically without the remote control being operated. | |||
door:electricallyoperated:switch | smart_card | The door has a switch. The switch is operated with a smart card. The door will not open automatically without the user sliding his smart card through or holding it near to the sensor. | |||
door:electricallyoperated:switch | fingerprint | The door has a fingerprint reader. It will not open automatically without the user placing a finger onto the fingerprint reader. | |||
door:electricallyoperated:switch | eyescan | The door has an eye scanner. It will not open automatically without the user looking into the scanner. | |||
door:electricallyoperated:switch | proximity | The door has a proximity sensor. It opens or begins to turn (depending on door:type) as soon as someone approaches the door. | |||
door:electricallyoperated:switch | no | The door has no switch. It opens or begins to turn (depending on door:type) as soon as someone approaches the door. | |||
door:electricallyoperated:switch:nexttodoor | yes | The door has a switch. It is located next to the door. door:electricallyoperated:switch:nexttodoor=yes implies entrance:wheelchair=no if not door:electricallyoperated:switch:neartodoor=yes and not specified exclusively | |||
door:electricallyoperated:switch:neartodoor | yes | The door has a switch. door:electricallyoperated:switch:neartodoor=yes implies wheelchair=yes if not specified exclusively |
Use wheelchair=yes to describe the entrance possibilities for a wheelchair user if you want to define this value explicitly.
Panels or multiple doors
Key | Value | Element | Comment | Rendering | Photo |
---|---|---|---|---|---|
door:panels | 1...n | The door has has a specified amount of panels. These panels either open based on a rotation or on a sliding motion, depending on door:type |
If there are multiple doors (not only two panels opening in opposite directions) please use multiple nodes defined with the criteria above.
Access criteria
Please use the access=* values to describe who is allowed to enter.
- access=yes The public has an official, legally-enshrined right of access.
- access=delivery Access only for delivering goods to or from a customer.
- access=private Access only with key or keycard.
- access=no Access is not allowed.
Specify stairs and ramps seperatly by using stairs, DE:Stairs modelling as well as Key:ramp if the ramp is included in the staircase or Incline if it is not.
Rationale
Indoor routing requires information about where and how to enter a room. Specifically accessibility routing algorithms need to handle user difficulties. General accessibility can be specified with wheelchair=yes, however more detailed specifications would be nice.
Examples
In every public building: universities, schools, kindergarden, libraries.
Voting
--> I would like to invite everyone who has the opinion that the amount of information to be optionally provided is too much to join the discussion page. Apart of 3D representations, there are topics such as wheelchair usage, usage for blind people, routing and a lot more to benefit of details on doors. For everyone who thinks the structure of the tag names is bad, please join the discussion page too, I am new to openstreetmap and would be happy to get your thoughts. --andreas.balzer 16:44, 5 January 2012 (UTC)
- I oppose this proposal. Who need such a lot of different keys for a simple entrance/door ? --R-michael 18:09, 26 December 2011 (UTC)
- I approve this proposal. Very helpful und essential for advanced 3D representation marek kleciak 19:54, 26 December 2011 (UTC)
- I oppose this proposal. This proposal doesn't seem ready for voting yet. The definitions (eg. what a door is in the first place) are weak, and the door:electricallyoperated:switch:... constructs are awful. See discussion page. --Fkv 19:56, 26 December 2011 (UTC)
- I oppose this proposal. Fkv is completely right. --Errt 20:49, 26 December 2011 (UTC)
- I oppose this proposal. Fkv is completely rightt. User 5359 21:18, 26 December 2011 (UTC)
- I oppose this proposal. I see no need for such details. But if it should be added there should be a better structure first. Willi2006 02:11, 2 January 2012 (UTC)
- I oppose this proposal. This is way too complicated. For just a door. --Hansdorfff 20:40, 3 January 2012 (UTC)
- I oppose this proposal. This is too complicated in its present form. It might be useful to have a "door" tag to which accessibility information can be attached, but that doesn't need this much detail. HillWithSmallFields 16:13, 05 January 2012 (UTC)
- I oppose this proposal. comment in discussion LM 1 23:11, 5 January 2012 (UTC)
- I approve this proposal. Interesting to describe more for indoor mapping. J-Louis ZIMMERMANN 21:43, 18 November 2013 (UTC)
Applies to
nodes
barrier=door | door=* |
Pages affected
- Proposed_features/entrance
- Proposed_features/entrance/indoor-usage
- General information regarding indoor mapping: https://wiki.openstreetmap.org/wiki/Indoor#mapping
- Deprecates optional items of Proposed_features/building_entrance