How to mark wheelchair ramps on sidewalks?

I am trying to mark a sidewalk around a building. The sidewalk has wheelchair ramps on one side of the building, quite ‘long’ wheelchair ramps that are essentially just the sidewalk goes to parking lot level. They are not on any other side of the building.
Here’s a photo of the ramp on the left side of the entrance. There is one other ramp on the right side.

My question is: Should I be splitting out these wheelchair ramps into their own paths, where I select wheelchair access? Or just make a normal path around the building and select wheelchair access for it?
Also this is my first time creating paths, so I’m not sure how to deal with one side walk that comes to a T or intersects other parts of the same path. Hopefully I don’t mess this up too badly.

1 Like

Welcome! It’s great to have more people interested in accessibility-aware mapping! :slight_smile:

Like most things in OSM, there’s a whole range of level of detail at which you could map - from basic highway=footway ways (“lines”) to micromapped individual parking spaces and footway areas.

I think a good balance between effort and impact is around here:

This keeps the topology representative of the paths people take in the real world and includes just enough information to be useful to everyone - it reads as “There’s a concrete sidewalk, with asphalt access aisles connecting to the sidewalk via flush curbs.”

Connecting paths to one another is as simple as having them share an un-tagged node (“point”) - the small grey dots in the image above.


Also, note that while it’s fine for sharing examples like this, we can’t use Google Maps data (including street-level imagery) as a source for OSM edits due to their copyright restrictions!


Don’t worry! Mapping is a learning process, and everyone makes mistakes. We’re here as a community to help - you can always post a link to your changeset and in time, someone can help to review it and suggest fixes/improvements! Happy mapping!

1 Like

Also, note that while it’s fine for sharing examples like this, we can’t use Google Maps data (including street-level imagery) as a source for OSM edits due to their copyright restrictions!

Good to know. Thankfully for this I actually was there walking around to get this data, the photo is only from Gmaps cause I realized when I got home that I wasn’t sure if I was doing this correctly.

I think maybe I haven’t explained my question well enough though. My question is more about how to mark off the path. Here’s what I had drawn in Go Maps, (just the wheelchair section on the left, middle is just a normal path, right is the path in front of the entrance).

You can see that I split up this path on this one side of the building due to the ramps here. Because I thought I would be marking this sidewalk with ‘wheelchair access = yes’, but only in these spots.

So instead should I just be marking the entire sidewalk as a single way and then not marking it as wheelchair accessible, but instead doing these nodes to mark that there is no kerb?

Would you only do flush kerbs at the access aisles, or over that whole length, as it appears that most of it is actually flush?

Correct, putting wheelchair=yes[1] on that segment would be superfluous - thinking from a network topology point of view since that’s how the data is used for routing: tagging the curb nodes is how we answer the question of how to get from the parking lot via access aisles to the sidewalk (that is, via a flush curb).

That section is actually functioning as a very wide landing for a “parallel”-type curb ramp:


(Image is from here[2], licensed CC0)

In both this case and yours, you could split at each section (ramp, flat area, ramp) and add incline=* tags, but that is also additional work on your part for not much (if any) benefit.

The barrier=kerb+kerb=flush+tactile_paving=no node where the access aisle path crosses the curb is the important bit. Additionally mapping a curb way is fine, but not very impactful.


  1. Side note, wheelchair=yes is well-intentioned and also a bit problematic.
    Different people have different physical abilities and types of wheelchairs, so one tag saying “This feels pretty accessible, generally speaking” can lead to bad routing for some users.
    For example, think of an athletic person who can “hop” a raised curb without much issue vs someone in a big, heavy powered wheelchair.
    The solution is to tag the physical details (like kerb=flush) so that data consumers can enable individual user to make properly informed routing decisions based on their own preferences. ↩︎

  2. Though I’m interacting as “just” an OSM community member right now, I manage the linked repo when I have my “work hat” on and work for the organization - the Taskar Center for Accessible Technology at the University of Washington - that owns that repo! ↩︎

1 Like