Big import of accessibility data from the On Wheels app

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: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.


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.

Other facilities/functions:

  • elevator:door:width=
  • elevator:width=
  • elevator:length=
  • atm:wheelchair=
  • reception_desk:wheelchair=

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:
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.

1 Like

Hi I did my best to make a proposal page for the tags we want to use and add with our On Wheels app:

1 Like

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.

You are also in a great place in this forum to trigger community support.

1 Like

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?

This would be great, since we don’t have the knowledge are funds to do this. We have an export of our data in json: [OnWheelsLocations_20_02_2023.json - Google Drive]

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?

Don’t import “test country” in there :smile:

No we know :slight_smile:

Thanks for this proposal!

I have looked at it and would suggest to use the keys


instead of


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=*.

1 Like