Hi everyone, with the On Wheels app we have collected around 25 000 data nodes were we collect accessibility data for wheelchair users (mainly in Belgium), about shops, restaurants, cafes, hotels, toilets, parking spaces, … Today this data is stored on a private server, but we want to add this data directly in OSM. We have been working on a new app that will view this data from OSM, but that can also add and edit existing data. This has been a slow and expensive process so far, discussing the right tagging and way to add the dataset to OSM. But we are getting closer and closer. There are some things we are still struggling with:
We create a node and add the different tags to it. So for the entrance and toilet.
Entrance:
entrance:step_count (for number of steps)
entrance:kerb:height (for the total height of the steps, of the kerb)
entrance:wheelchair:ramp (for a wheelchair ramp)
entrance:width (for the entrance door width)
entrance:wheelchair:turning_circle (for the turning circle)
entrance:automatic_door= (for an automatic door)
entrance:door= (for type of door)
These we previously discussed in the tagging email and received fairly positive. Please let us know if you see any problems with these tags.
Toilets:
So we are using the toilets:wheelchair tag when there is an accessible toilet in the building and adding these tags:
toilets:wheelchair:door_width (for the width of the door to the toilet)
toilets:wheelchair:space_side (for the free space next to the toilet)
toilets:wheelchair:space_front (for the free space in front of the toilet)
toilets:wheelchair:grab_rails (for the grab rails)
shower:wheelchair (for a wheelchair accessible shower)
hand_basin:wheelchair (for a wheelchair accessible hand basin)
changing_table= (for baby changing table)
changing_table:adult= (for adult changing table)
changing_table:location (for the location of the changing table)
changing_table:hoist (for if there is a hoist available)
changing_table:adjustable_height (for if the changing table is adjustable in height)
I think these we received well by the tagging community, but these tags are still in discussion and not clear yet:
highway:indoor:wheelchair:width= (we need a tag to indicate the smallest width going from the
entrance to the toilet. This could be a tag to give the width of an
indoor path for wheelchair users in the building).
toilet:accessible_via: (to indicate if the toilet is reachable with an elevator or stairs)
The other option is to ask people if there is an wheelchair accessible toilet, on what floor it is and if there is an elevator. If they say there is no elevator the toilet is not tagged as wheelchair accessible.
Please let us know if you have better ideas about this.
Naturally, you’ll need to follow the import guidelines. If you haven’t already done so, please do read those and make sure that you do everything that you need to do.
I suspect that while lots of people will be in favour of this data being added in OSM, they’d still want to see how you’d handle conflation - for example where an entrance node already exists but doesn’t have the new tags, where it exists has and has tags that disagree, and where a POI exists but has no entrance node.
Perhaps, in addition to the stuff in the import guidelines, it’d be worth manually editing 2 or 3 POIs as you propose so that can people can see the effect?
Yes the conflation issue will be the hardest. We want to add the new data to existing buildings, but it is a lot of work to do this manual. We did a test in Lisbon city were we added some of the new tags: https://www.openstreetmap.org/node/7285983235
We payed someone who has a lot of OSM knowledge for this, but we will have to see if it is financial possible to do this for the whole dataset.
One thing I noticed, some values have units, others don’t. It would be convenient to normalize those and maybe provide some guidance as to what values without units mean. It’s quite common to write meters without units. Anything else should have a unit or be transformed to meters. But since you are introducing completely new tags, you can choose what’s the default unit I suppose.
Would it be possible to add taginfo links for the usage of those? Have a look at another page to see how it is done. Usage may be low now, but as the discussion goes on, I’d expect that it would go up.
An other user added the taginfo links I believe. Thank you!
How can we make this an official proposal? Now its a draft I believe.
How can we add the voting to this?
Somebody from the OSM community also made a script to change this to OSM json data, but there is also a lot of manual work to be done. For this we would like to get some help. What’s the best approach to find people for this?
door width, space side and space front are not only attributes of wheelchair toilets, they apply to normal toilets too. It’s similar to elevator:door:width=*.
It seems that OnWheels has done a big part of their import by now.
It would have been nice if you’d have linked to this thread in your changesets, but that is not such a big issue. I’ve left a changeset comment on each of them as well.
Hi everyone, we managed to do the import where we just added our accessibility tags to the existing buildings in OSM. No OSM data was changed or deleted. Conflicting data or locations were not imported. More info about the tags we use and our app can be found here:
I will instruct our importer to add a source tag so it’s clear the dataset comes from On Wheels. We still have to do the disabled parking spaces, but we haven’t found a good way to do it yet.
Thanks for letting me know about the double locations. It seams that some students didn’t follow our rules very clearly and added new locations instead of editing the existing ones. We are also working on a bug were the app creates duplicates. I manually checked and fixed all locations from this student. Will ask the dev to put the created by tag on the changeset instead of location. Do you know how they have to do this? These fixes are coming in the next update next week:
deleting existing data when editing with the app
using capital letters in the answers box
we will only send the tag if the answer is yes (so no more tags with =no)
duplicates should also be fixed (had to to with server overload issues with pictures)
Good to hear that those changes are finally coming.
Are those students using the app? If they ‘have to follow some rules’, then a non-affiliated user will make the same errors and the user-experience should be improved.
