RU:Proposed features/entrance/door
Warning
This page is available for documentation purposes. Please see User:Andreas.balzer/door-proposal-version2 for updated draft version.
entrance:door | |
---|---|
Статус: | Rejected (inactive) |
Предложена: | Andreas.balzer |
Схема тегирования: | entrance:door=* |
Используется на элементах: | node |
Определение: | To specify the type of door and its operation. |
Statistics: |
|
В черновиках с: | 2011-11-17 |
начало обсуждения: | 2011-11-17 |
Голосование начало голосования: | 2011-12-24 |
Окончание голосования: | 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 door] | [Tag:door=hinged 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] and [2] | ||
[door door] | [Tag:door=sliding sliding] | The door is a sliding type door. | [3] | ||
[door door] | [Tag:door=loadingdock loadingdock] | The door is a loading dock. | [4] and [5][1] | ||
[door door] | [Tag:door=accordion accordion] | The door is an accordion type door. | [6] and [7] (folding door) | ||
[door door] | [Tag:door=overhead overhead] | The door is an up-and-over type door. | [8][2] | ||
[door door] | [Tag:door=rotating rotating] | The door is a rotating type door. You usually find these doors in shopping malls. If door:ellectricallyoperated=yes this door moves automated. If door:ellectricallyoperated=no, a person needs to push it. | [9][3] |
Physical details of door opening
Accessibility information
Use wheelchair=yes to describe the entrance possibilities for a wheelchair user if you want to define this value explicitly.
Panels or multiple doors
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)
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
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