Proposal talk:Accessibility
Change amenity=changing_places to existing amenity=changing_room?
The new tag amenity=changing_places is suggested, although amenity=changing_room already exists. Maybe this should be unified? --Mcliquid (talk) 06:14, 21 October 2023 (UTC)
See also: Proposal:Wheelchair lifts and ramps on platforms
Just to cross-link this accepted proposal: Proposal:Wheelchair lifts and ramps on platforms --Mcliquid (talk) 06:42, 21 October 2023 (UTC)
Don't use prefix tags like "elevator"
In Germany and Belgium the dimensions of highway=elevator are already mapped via width=* and length=* tags (see https://overpass-turbo.eu/s/1Dnc). I would prefer this since I don't see any reason for prefixing these tags with "elevator" when they are tagged on an elevator element. Prefixing is only used to differentiate between sub-feature properties like the door width. Likewise I would use the existing door:width=* tag there. What is important to me is that the meaning of width and length is clearly defined. E.g. length is always the direction/distance perpendicular to the elevator door and width is always parallel to the elevator door. Also some rule needs to be defined for the special case where an elevator has 2 doors aligned perpendicular to each other. For door:width=* it could be: If different door widths exist the smaller one should be mapped. --OPENER (talk) 11:28, 14 November 2023 (UTC)
- Just noticed that all the tags should be attached to an amenity or building which then obviously would require prefixing. I'm not sure if this is a good approach though since it doesn't allow any sort of pedestrian routing. Also buildings can have multiple entrances and elevators wherefore it becomes unclear what the data even describes. If you would only tag the smallest sizes then you might end up declaring something as inaccessible even if it has a second door that is wide enough for wheelchair users. Similar problem arises if you always map the biggest sizes. --OPENER (talk) 11:44, 14 November 2023 (UTC)
Split proposal into smaller ones?
Since the tags are somewhat independent from each other I think it makes sense to split the proposal into sub proposals (elevator, entrance, toilets, ..). It will definitely increase the chance of approvals, because someone might be okay with 90% of the proposal but reject it due to the remaining 10% disagreement. --OPENER (talk) 11:28, 14 November 2023 (UTC)
Proposals splitted up in smaller ones
Hi I will make separate pages for the different sub proposals:
- For this one, I don't find it necessary. entrance=* is few and easy to add outside. You will need to find where it is anyway.
- wheelchair:turning_circle=* : What exactly is it? Length & width, area, diameter? It's not a turning_circle=* for u-turn, but a turning space (ADA term) for maneuvering. For yes/no, it would be *:wheelchair=yes . If it can be considered a landing (although it is not a resting platform in the middle of a staircase), landing=* from Proposal:Steps features as others can be adopted.
- entrance:width=* : What would it be referring to? A building will have an opening space, and potentially multiple doors. It's obviously not the total width, so it should use door:width=* thus at least entrance:door:width=* .
- entrance:automatic_door=* : I don't like automatic_door=* in the first place. There's already automated=* that can be adopted. Furthermore, it is unable to show the presence of both buttons and automatically sensing doors, and what about the contactless hand proximity sensor door switch (not a push button) popularized by the Coronavirus?
—— Kovposch (talk) 18:40, 6 January 2024 (UTC)
Other new problems here
- toilets:wheelchair=*
- toilets:wheelchair:door_width=* : Maybe you want to avoid overnamespacing, but this doesn't save much. Use toilets:wheelchair:door:width=* .
- toilets:wheelchair:space_front=* : The requirement for space in front is two-dimension, both length & width, or a diameter (same problem as wheelchair:turning_circle=* above).
- toilets:wheelchair:space_side=* : Is it referring to rail side, or empty side? Suggest eg toilets:wheelchair:handrail:buffer=* (see next) using cycleway:*:buffer=* .
- toilets:wheelchair:grab_rails=* : There is no grab_rails=* yet. Why not use handrail=* to be toilets:wheelchair:handrail=* ?
- hand_basin:wheelchair=* : No hand_basin=* . For toilets:handwashing=* , you will need to distinguish toilets:wheelchair:handwashing=* (whether the accessible toilet has a washing basin) and toilets:handwashing:wheelchair=* (whether the washing basin in toilets in general is accessible; relevant to children too).
- changing_table=*
- changing_table:adjustable_height=* : Just changing_table:adjustable=* , or changing_table:height:adjustable=* to go with a changing_table:height=*?
- parking_space:*=* : I don't find it appropriate on the feature, especially when it's not inside buildings. Should use eg type=provides_feature , or expand site=parking to include this.
—— Kovposch (talk) 19:12, 6 January 2024 (UTC)
Finalising the proposal
Hi everyone,
I would like to thank everyone for their input on this proposal. I know we like to add a lot of new tags to OSM and it's not easy to find a consensus on this. But I would like to know how we can proceed so we can finish our development of the app. We have been in discussing with the community for over a year now and we believe we did all we can to make new tags that are understandable and logical for everyone to use in OSM. As a non profit we invested a lot of money in changing tags over and over, but at some point we will have to finish and choose a way to go further. So I would like to know what's the best way to proceed for an official voting.
We have also created a save way of conflating our existing dataset into OSM without changing or overwriting the OSM data. Our script looks for the same location with the same name, location, and other parameters and adds only the accessibility info to it. We only add this info to location that are 100% the same location. So we would like to do this as soon as possible so we can launch our app.
I'm also making a wiki page about the app and all info and tags we are using in OSM: https://wiki.openstreetmap.org/wiki/On_Wheels_app. So people know how the app and the new tags work. I will also make separate pages for the new tags to make things more clear. Users that are using our app to edit or add data will also have to be logged in with an OSM account. We also train our users in how to edit and add new things. This way we can ensure correct and verified info will be added to OSM. Since we are the first using these new tags we will also take the lead in the OSM community and the accessibility community to ensure everyone is using them in the correct way. We will write manuals and create training for everyone that want to start mapping accessibility in the future.
Her some answers on questions on this proposal:
1. Don't use prefix tags like "elevator", "entrance", "toilets:wheelchair"
I believe this is the most easy and clear way of adding all this information to the node of example an amenity=restaurant. I understand that this means that some tags are pretty long, but there's no confusing to what element (like entrance or toilet) the tags is referring to. I'm also a great believer in being more detailed and mapping toilet, entrances and elevators on separate nodes, but this doesn't mean that we can also do this. We have plans to also add the ability to view and add elevators on their own node in the future and want to work with the community on indoor mapping.
2. Change amenity=changing_places to existing amenity=changing_room?
I understand this, but changing places is the official name of this type of function that is already use all over the world. So make more sense to also use the official name in OSM.