Proposal talk:Entrance/door

Warning

This page is available for documentation purposes. Please see User:Andreas.balzer/door-proposal-version2 for updated draft version.

Why not just door=<type>?

Why not rewrite door:type=<type-name> as door=<type-name>? Seems to me that combining

barrier=door

door=<type-name>

is the obvious drill-down refinement for defining what kind of door a feature is. The other values you propose are nicely namespaced under "door:", and it would be nice to have a "type/kind" key with exactly that string minus the colon to refer back to.

By the way, thank you for not considering type=* or other imprecise schemes. I think we can go one step terser here. --achadwick 14:11, 29 November 2011 (UTC)

I am quite new to openstreetmaps and have not completely figured out the naming scheme yet. I thought it to be more natural to use door:type instead of just door because type indicates we are talking about an attribute. I originally used door=yes until I figured out there is a barrier tag for that. I guess I am indifferent on using door or door:type. Can you adjust the proposal please? I have not used type=* as I have no clue for what it stands so far. :-) --andreas.balzer 22:48, 21 December 2011 (GMT+1)

Definition

Can you define the difference between a door and a gate?

Is barrier=door + door(:type)=rotating the same thing as barrier=full-height_turnstile ? --Fkv 08:21, 14 December 2011 (UTC)

For me a door is an entrance into a building or room used by humans or pets. A gate is an entrance into an area or a garage mainly used with a car I guess. You wouldn't use a gate to refer to indoor scenarios.

So how are we supposed to tag an entrance usable by humans only, into an area? --Fkv 19:09, 26 December 2011 (UTC)

That's a good one. Let me change my definition: gate is for outdoors, door is for buildings. For everything else please consult the lengthy Wikipedia definition (http://en.wikipedia.org/wiki/Door). :-) --andreas.balzer 21:27, 27 December 2011 (GMT+1)

EDIT (name tag): Sry, I shouldn't copy and paste anymore.. :-(

EDIT 3: barrier=full-height_turnstile is probably more for outdoors and door=rotating is for entering a building or room when using those rotating doors made of polished glass ;-)

--andreas.balzer 22:51, 21 December 2011 (GMT+1)

What if it's indoors and made of wires instead of glass? --Fkv 19:09, 26 December 2011 (UTC)

Sorry, I used glass as an example only. I don't know how to describe the difference, but turnstile is one of those barriers shown on the barrier page. Rotating doors are more like these: http://www.google.de/imgres?imgurl=http://www.door-manufacturers.com/picture/exterior-doors/rotating-glass-door.jpg&imgrefurl=http://www.door-manufacturers.com/rotating-door.html&usg=__NRU10uNO4uTYHhn8QT1IKuuKgQU=&h=400&w=400&sz=20&hl=de&start=6&sig2=AuSyQtW6uKQccJcX0trsBw&zoom=1&tbnid=fI4FcmwFUgxG9M:&tbnh=124&tbnw=124&ei=lSf6ToeHJcn4sgbE14nUDw&prev=/search%3Fq%3Drotating%2Bdoor%26um%3D1%26hl%3Dde%26sa%3DN%26biw%3D1024%26bih%3D473%26tbm%3Disch&um=1&itbs=1 You cannot find them outside when they are not an entry to a building. --andreas.balzer 22:24, 27 December 2011 (GMT+1)

door:* applicable to other barriers too

At least door:electricallyoperated=* would be handy for barrier=gate as well. Maybe rename it to barrier:electrically_operated=* or just electrically_operated=* or something even more general like operation=manual/switch/remote/smart_card/fingerprint ?

BTW: I dislike door:electricallyoperated:switch*, because remote controls don't fit in, and keys with multiple colons are just ugly. --Fkv 08:44, 14 December 2011 (UTC)

I don't recommend using electrically_operated on barrier because you cannot operate a fence, .. ;-) However a gate tag could come in handy. Actually I don't understand why gate and door have been used in combination with barrier at all..

Just try to pass it without opening it, and you will see. --Fkv 19:36, 26 December 2011 (UTC)

operation= doesn't fit because it doesn't refer to the object you are operating (in case a node has certain objects linked to it).

What do you mean by "linked"? Do you actually mean "tags" when talking about "objects"? --Fkv 19:36, 26 December 2011 (UTC)

I meant if a door has two switches, e.g. one on each side and you want to specify the properties of both (by using tags) individually. e.g. something like switch=, switch:height= would be bad as it does not specify which switch is the one being talked about. Maybe there'd be a possibility to introduce ids here, otherwise I don't have a clue about how it's done. --andreas.balzer 21:20, 27 December 2011 (GMT+1)

Considering the current naming scheme I only see the possibility to use multiple colons regardless of how ugly it is ;-)

I'll add

* door:electricallyoperated:switch=remote

* door:electricallyoperated:switch=smart_card

* door:electricallyoperated:switch=fingerprint

--andreas.balzer 22:58, 21 December 2011 (GMT+1)

Is there any documentation on how to name tags? --andreas.balzer 21:21, 27 December 2011 (GMT+1)

As we know now that the operation tags are applicable to other objects (gates, bollards, escalators elevators, fountains, lights, traffic lights, ... draw bridges), why do we have to restrict them to doors?

What about an independent tag operation=*?

* operation=manual (default if no switch or activation is defined)

* operation=proximity

* operation=pushbutton

* operation:_position=* (add the type or source of smart card here)

* operation=key

* operation:key=radar_nks (a UK standard key for wheelchair users)

* operation:key=* (describe everything else, such as 'from the shop next door')

* operation=smartcard

* operation:smart_card=* (add the type or source of smart card here)

* operation:control=* (add the list for possible handle, switch or reader positions here)

* operation:power_source=* (this is the place for power sources, if needed: electricity, gas, steam, water, etc.)

Marl 10:23, 30 December 2011 (UTC)

Hello Marl, an independent tag has a huge disadvantage. You don't know what is being operated. Imagine there are two objects represented by the same node. What is being operated when there's an "operation" tag in use? Is it the door or is it an integrated blinds. -- andreas.balzer 15 January 2012 (UTC)

There's currently no tag for blinds. I suppose that a blinds is a barrier, thus barrier=blinds. If you map this as a separate node, you can easily set a separate operation tag as well. If you use the same node, indicating that door+blinds are one unit, you need to set barrier=door;blinds (or blinds;door), and to join the operation tags with semicolon too. Which operation belongs to which barrier does not matter, as they are considered one unit. You need to operate both door and blinds to pass. --Fkv 05:37, 15 January 2012 (UTC)

Safetydirection

Is this a common definition? It seems to be a bit narrow, as often (e.g. in case of fire) the outside is the safe location and the inside the unsafe. That's why public building doors usually open to the outside. If it's not common, something more precise might be a good idea. --Errt 20:44, 26 December 2011 (UTC)

Unfortunately I didn't come up with a better naming on this one. The Wikipedia article on doors states "Door swings For most of the world, door swings, or handing, are determined while standing on the outside or less secure side of the door while facing the door (i.e., standing on the side you use the key on, going from outside to inside, or from public to private)." Maybe I could change the naming to door:swings=to_safe and door:swings=to_unsafe after the voting. What do you think? andreas.balzer 21:09, 27 December 2011 (UTC)

I think the problem may be in confusing "safe" and "secure". What you've called to_safe and to_unsafe would be more accurately described as to_secure and to_unsecure, as in the Wikipedia article. As Errt indicates, the secure side and the safe side are typically opposite. HillWithSmallFields 16:03, 05 January 2012 (UTC)

door:electricallyoperated:*

I suppose door:electricallyoperated:* could just as good be door:operated={yes|electrically|switch|remote|...}, which is a lot shorter and provides better readability. --Errt 20:47, 26 December 2011 (UTC)

Thank you for the hint. Is there any documentation on tag syntax? I would like to enable scenarios where a door has multiple elements (e.g. 2 switches, 1 remote) and each has specific properties specified as tags. Does {a|b|c} allow for (a and b and not c)? andreas.balzer 21:09, 27 December 2011 (UTC)

EDIT: Thanks. Found what I was looking for. ";" can be used to allow for multiple elements although it is highly recommended not to use it. andreas.balzer 21:37, 27 December 2011 (UTC)

alternative to multiple colons

Please leave your comments:

• door:electrically_operated = yes
• door:electrically_operated_by = switch; remote; smart_card; fingerprint; eye_scan; proximity
• door:switch = id1; id2
• door:location_of_switch-id1 = near_to_door where id1 is one of the id specified in door:switch, switch might be smart_card, fingerprint or eye_scan
• door:location_of_switch-id1 = next_to_door
• door:side_of_switch-id1 = unsafe
• door:side_of_switch-id1 = safe

I prefer multiple colons though. Could be door:switch-id1:location = unsafe andreas.balzer 22:04, 27 December 2011 (UTC)

More types

You've missed double doors (i.e. a hinged door on each of the doorposts) and stable doors (top and bottom halves open separately).

HillWithSmallFields 16:07, 05 January 2012 (UTC)

LM_1 comment

Generally I am in favour of 3D and very detailed mapping even of buildings' inside, but putting number of nodes inside a building outline just does not seem very sensible. It seems like stretching the current mapping model far beyond it should ever be.

For how to do it, I believe that there would have to be some object model so that one could edit it separately from the rest of the map. This would generally consist of several layers - one for each different level. It would require editor support. It would allow to accurately map the whole building even with the shops/offices... inside. Maybe it could save some space, because inside of the building would have its own coordinaces - no need to relate it to the whole world and measure in latitude/longitude - meters would be more sensible in this case. The whole object would be placed in the map. (Add textures and you have almost 3D buildings like Google or Nokia).

Specifically for your proposal's details: I do not see any good reason why an inside door (entrance to living room) should be tagged differently than an outside door (entrance to building). That is apparent from the door location - part of building outline. Dividing rooms as safe/unsafe is not reliable and therefor not a good refernce point for everything else. If you go from a corridor to some room, it is clear, if you go from one room to another they are the same. There is already an established division between left/right door - no need to invent a new one. (After a bit of research it seems that english language is not as clear as czech and there is some confusion). The accessibility information section is confusing and and inconsistent. door:automatic(can be hydraulic or something else)=(no)/yes(non-specified of the following)/switch(button)/remote/card(RFID or swipe)/proximity/biometric/... (now I see it is similar to what has been suggested above)