Proposal talk:Key:opened=

Automatic doors

What about automatic doors? I see number of different possibilities:

• doors open automatically if a user (typically disabled person) press some button
• doors open automatically if person comes close to them
• doors constantly in motion (revolving door)

I'd tag first two options as closed (as they open automatically), but that breaks rationale for proposed tagging. I have no idea how you expect to use proposed tag with automatic_door=motion.

I also have some concerns about spelling of proposed key, but that is another matter. Kubahaha (talk) 12:03, 19 March 2024 (UTC)

This tag doesn't make much sense for automatic doors especially revolving doors. We mentioned this briefly in the rational, but will expand on it. We are interested in the "default state" of a feature that can be opened/closed. By this we mean the state of the feature without/prior to any user interaction. --OPENER (talk) 08:50, 26 March 2024 (UTC)

Pointless

I think it is pointless to specify the status of a door in a geo database. A fundamental characteristic of a door is that it can be open, closed or in countless states in between. These states can change at any time. An exception could be made if the door can no longer moved for mechanical reasons.

https://wiki.openstreetmap.org/wiki/Good_practice#Don't_map_temporary_events_and_temporary_features

Protoxenus (talk) 17:10, 19 March 2024 (UTC)

Doors might be low-value, but gates on roads aren't. A router could use it to decide between a short route that requires stopping to open (and re-close) several gates, and a longer unobstructed one. --Carnildo (talk) 18:41, 19 March 2024 (UTC)

It is absolutely true that it doesn't make sense for most of the doors in real live especially those in private places. However there are public places where certain agencies are in control of or operate the doors. At train stations and airports especially interior doors are usually opened so passengers can easily pass through. They are usually fixated with a door holder or door stay so they cannot accidentally snap shut. The doors are only closed in exceptional scenarios like when a fire is broken out or on construction work. Same is true for universities, parks or shopping malls. So for OSM, which is not about mapping doors in private house holds but for mapping of public places, it is not as unusual as one might think. Again we believe it is very similar to the locked key, because technically almost every door can be locked at any time. --OPENER (talk) 08:50, 26 March 2024 (UTC)

"normally"

I think there needs to be some clarification what the term "normally" describes. As I read it, it is the most common state during opening_hours. Nielkrokodil (talk) 18:45, 19 March 2024 (UTC)

You are right. We updated the proposal. Let us know if you still think it is too vague or otherwise flawed. --OPENER (talk) 10:53, 26 March 2024 (UTC)

Yes, it is better now. But I still am not 100% satisfied. If I happen to know more about the opening/closed/locked schedule how can I map it?

Example: A shop has opening_hours from 12:00-16:00. From 12:00-16:00 in winter the door is closed, in Summer it is opened. From 16:00-12:00 it is locked. What is the default state? It is locked 20 hours per day, is this the default? I would still say no. For the summer/winter question: Do I use conditional? Nielkrokodil (talk) 17:05, 27 March 2024 (UTC)

Yes, the idle (default) state of the door changes but it changes based on a pattern. As you already presumed this is exactly where opened:conditional=* should be used for.

One way to tag the door would be:

locked:conditional=yes @ 16:00-12:00

opened:conditional=yes @ 12:00-16:00 AND summer

Is it clear now?--OPENER (talk) 13:19, 8 April 2024 (UTC)

Yes. Thank you! Nielkrokodil (talk) 20:21, 21 April 2024 (UTC)

Adding opening_hours=* to the door may be more specific / key mixes opened/closed-state with door width

Why not add just opening_hours=* to the door? Fabi2 (talk) 04:29, 20 March 2024 (UTC)

opening_hours might be a good addition, but it does not replace opening.

Opening_hours say when you can pass, but you might have to push the door open (it is not locked, but closed/shut).

Nielkrokodil (talk) 06:40, 20 March 2024 (UTC)

This proposal mixes the door state (open/closed/time => opening_hours=*) with the width for passing the door/clearance, which exists as maxwidth:physical=* (opening=* is a special case of the generic maxwidth:physical=*) and width=* is the full width of the feature/door). opened=partial/full looks like you want something like est_maxwidth:physical=* (see est_width=*). But help this estimation really for the use case wheelchair:*=*, as the width of the door can be different from the common door=hinged?

Fabi2 (talk) 11:24, 20 March 2024 (UTC)

As Nielkrokodil already said opening_hours=* could describe when a door is openable while opened=* is supposed to describe whether a door leaf is open by default. maxwidth:physical=* describes the complete / full clearance width of e.g. a door but for the clearance width of a partially opened door (e.g. one wing is opened the other closed) a second key is needed. --OPENER (talk) 15:39, 26 March 2024 (UTC)

What should opening_hours=*, tagged on a door-node, not on the facility, other mean as when the door is opened/closed? So it is the opening-state of the door. Many entrance/exit doors in public buildings, at least in North/Central European countries, have automatic doors so they automatically close during the winter season, so they are not open by default. maxwidth:physical=* is the real, effective, physical width you have for passing through. So if a two-wing-door is always only half-opened, so it can be tagged with opened=partial, the effective width of the opening is that of the half-opened door. width=* is the full width of the object/door, ignoring any opening-states. --Fabi2 (talk) 16:40, 26 March 2024 (UTC)

In my understanding the OSM-Tag opening_hours tells you when the object "can be used". This is no geometrical question. On a door node this means I can use this door (move through). It does not say wheter I have to push/pull to get through or if the door stands wide open so I dont have to push/pull.

I know this can be misleading, but it less misleading than redefining opening_hours for door nodes. Nielkrokodil (talk) 16:52, 26 March 2024 (UTC)

There is no redefinition of opening_hours=*, cite from the English wiki page of opening_hours=*: "opening_hours=* describes when a feature is open or closed in a standard format." But the state of the door wing(s) is really left unclear when "open" with opening_hours=*. The proposal looks as if you want to add the fact, if disabled people or wheelchair users can easy pass the door without any assistance. So besides the fact, if the door wing(s) are really open, it seem as you want to describe, if the door opening is wide enough for a wheelchair to pass. The Delfi spec states that at least 1.20 m is needed for wheelchair users, but a common door e.g in a detached house is around 0.90 m. Would you like to propose, besides the opened-state, an easy to estimate proxy-key for the door width, which may differ in reality? So it may be est_maxwidth:physical=* or something more unclear like door_wings:opened=1,2,...,n. Fabi2 (talk) 17:53, 26 March 2024 (UTC)

Regarding opening_hours=*

The words "open" and "closed" have different meanings depending on the context. For example "open" and "closed" signs on doors (see https://s3.envato.com/files/287696257/_8533380.jpg) tell you that you are allowed to enter and will be served or that something is operated. This is different to the meaning if something is physically open/opened (a box can be opened, a door can be opened, a book can be opened, etc.). The words "open" and "closed" on the opening_hours=* wikipage describe the first case, the "hours of operation" and not the "hours when something is physically opened" which in our cases would mostly be 24/7.

While we are coming from a point were we are most interested in doors, we do not want to limit the "opened" key to doors, similar to the locked=* key. This also makes it important to avoid any tag collisions with the opening_hours=* key. Tagging both opening_hours=* and opened=* on other features may be sense full.

Regarding maxwidth:physical=*

I get your point. The problem is that maxwidth:physical=* and width=* on doors are used more or less interchangeably. For a barrier=gate maxwidth=* or maxwidth:physical=* should be tagged even though the gate is closed. So maxwidth:physical=* doesn't necessarily describe an "immediate clearance width", it can also be the clearance width that is available after something is opened. Therefore I think it is unclear for opened=partial whether maxwidth:physical=* refers to the full door clearance width or just the partial door clearance.

Regarding est_maxwidth:physical=*

We want to tag the measurement of the gap of a partially opened feature (partial) that can still be opened completely (full). So there are two relevant measurements. opened=partial can be seen as a lower level of detail like kerb=raised. It allows to make some estimations if the partial clearance width is not measured.

The proposal looks as if you want to add the fact, if disabled people or wheelchair users can easy pass the door without any assistance. So besides the fact, if the door wing(s) are really open, it seem as you want to describe, if the door opening is wide enough for a wheelchair to pass.

This is exactly where we are coming from.--OPENER (talk) 09:40, 27 March 2024 (UTC)

maxwidth:physical=* and width=* are not the same, when you assume with this proposal, that a door can be partial opened for a longer, mapable, time span. Only because the wiki documentation of maxwidth:physical=* could be improved for better understanding, you want to reinvent a bad wheel, as it is unclear what opened=partial is e.g. for a folding door (door=folding), besides being not appropriate for door=sliding and door=revolving. From where do you want to know, if a wheelchair user can use the door, if it is partial opened? The simple indoor schema already use wheelchair=yes on doors, at least if you look on the pictures on this page. So why not just add e.g. walker=yes and crutches=yes? --Fabi2 (talk) 01:13, 2 April 2024 (UTC)

Please remember that this proposal wants to establish a universal tagging scheme. The key width=* describes the width of the entire feature which may work for doors but not for barriers as they can occupy more space than they are actually supposed to block (example https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dsliding_beam). Tagging the passable width (maxwidth:physical=*) on gates describes the clearance width when it is completely opened. So the tag maxwidth:physical=* is already reserved for a different meaning/measurement wherefore another tag (opening=*) is required.

as it is unclear what opened=partial is e.g. for a folding door (door=folding), besides being not appropriate for door=sliding

opened=partial means the sliding or folding door is somewhat folded/slid open but not completely.

From where do you want to know, if a wheelchair user can use the door, if it is partial opened?

While we have personal interest in this tagging scheme, we don't try to build it around or tailor it to our use case. So yes we agree that you cannot safely say whether a wheelchair user fits through the door or not based on opened=partial alone which btw wheelchair=yes doesn't fully allow either because wheelchairs have different sizes.

You are jumping between multiple topics which makes it hard to understand and respond to your actual criticism. It would be nice if you can create specific sub headings for further concerns.--OPENER (talk) 13:15, 8 April 2024 (UTC)

Where is opening=partial universal? From what would you know, if a wheelchair user can use the door? Because of the different sizes of possible door using wheelchairs, technical specifications such as that of Delfi states, that the door(opening) have to be at least 1,20 m width so the most wheelchairs can sue it. But with opening=partial nobody knows it a wheelchair fits through the door. To universally describe the with of the opening you should use maxwidth:physical=* instead of making an more unclear extension of the less descriptive tag opening=*. If you want an easy to use approximation for your designated use case instead, you should propose tags such as walker=yes.

I thought you know understood, that maxwidth:physical=* has the same meaning as your proposed opening=*, if not, read the discussion above again. It is as same "reserved" as tag for something as name=* or operator=*. maxwidth:physical=* only has its meaning, which fits here, assumed that the (partial) open door is permanent enough to be mapped, as assumed by your proposal. Fabi2 (talk) 16:40, 8 April 2024 (UTC)

We believe maxwidth:physical=* on doors/gates describes the clear opening width. I started a poll in the forum to survey what other mappers think the meaning of maxwidth:physical=* on doors/gates is: https://community.openstreetmap.org/t/what-does-maxwidth-physical-describe-for-gates-and-doors/111643 --OPENER (talk) 06:46, 11 April 2024 (UTC)

The poll is useless for this issue, as it don't point to this discussion! The point is: If you assume, that the partial door open state is permanent enough to be mapped by your proposal, then the partial opening is permanent enough to maxwidth:physical=* to apply to it. --Fabi2 (talk) 13:36, 21 April 2024 (UTC)

'opened' is the wrong word

I think the choice of 'opened' for the key is the wrong word, as it's not the equivalent part of speech to the other similar tags you've cited. The equivalent to "locked" and "closed" in the context desired would be "open". i.e. we would say the "The door is closed", "the door is locked" or "the door is open". The word "opened" would instead be used in contexts describing the actual act of opening of the door, e.g. "the door was opened at 9am". -- Rjw62 (talk) 17:42, 8 April 2024 (UTC)

Thanks for pointing this out! We adjusted the proposal and added a sub section regarding the naming. --OPENER (talk) 08:57, 9 April 2024 (UTC)

Potential for confusion; something like door:status=* better?

I think whatever word is chosen for the idea of a door/barrier being open, it's likely to lead to confusion. Perhaps a better approach would be to have something like "door:status=[open|closed|locked]" with conditional tags permitted to describe different states at different times. -- Rjw62 (talk) 17:44, 8 April 2024 (UTC)

I can see the benefit because "openable features" can somewhat only be in one of the 3 states: open|closed|locked. However:

• keys like status=* or state=* do not describe themselves nor the range of possible values very well even with a prefix/suffix. E.g. possible status/states of a gate could be "rusty", "defect", "construction", or "boarded".
• given the fact that locked=* exists and is already used 79.000 times (at the time of writing) I believe it makes sense to reuse it.
• we would lose the possibility to define more precise values for the "open" key.
• technically something could be "open" and "locked" at the same time (e.g. it is locked to prevent it from closing) even though we propose that for doors locked=* implies closed.

--OPENER (talk) 08:17, 9 April 2024 (UTC)

Verifiability

• How can you ensure verifiability for such a tag?
• How can a mapper determine if an opening state is temporary or permanent?