Question around wheelchair routing


#1

Hello,
I want to begin by stating that I am not a programmer, so please excuse any lack of technical knowldge.

I’ve been working on a project to map mobility and accessibility in a town centre, and have been investigating why there seems to be very little directional programmes when it comes to wheelchair or visual impairment issues. The project is mapping with OpenStreetMap.

I was pleaed to come across openrouteservice, but have been unable to get the wheelchair routing to work and interested to understand why this might be.

Is because the number of data point that has to be processed becomes too high when taking into account so many variables? i.e. rather than just a single road, it has to work through kerbs/paving type etc?
Or is it simple that this sidewalk data doesn’t really exist?


#2

Hi @sam-odm,

the wheelchair profile is a lot more restrictive in terms of what it will route over in that it will only use ways that are aimed at pedestrians or roads that have a sidewalk tag. If you post an example of the query that you are using, then we can check to make sure that this is the case and not some other issue.

Also, the wheelchair profile is only available for Europe at the minute as it requires a lot more processing than the other profiles.

Adam


#3

Hi, great to know, I also am pretty much interested by this. I am planning mapping parties on accessibility for disabled, in Tahiti (French Polynesia). I would be very much interested to know all the inputs used by the routing algorythm. Is there somewhere where we can find the sources or input for calculation ? I know that ORS will not work in my area but the idea to know that the algorythm is working somewhere else and could be replicable is already great.
Keep up the great work!
Best
Violaine


#4

The first main thing for it is that it only accepts ways that are marked as pedestrian suitable highways (highway=footway, living_street, pedestrian, path, or track), or another type of highway that also has a sidewalk tag (sidewalk=yes, left, right, or both).
The next things that are looked into are the different aspects that can affect accessibility. These are width, incline, surface, and smoothness (all of which are represented by tag/key pairs e.g. width=120, surface=asphalt).
The last thing is the kerb height which is attached to a node on the way. In the current implementation, kerb height is only taken into account on crossings (which are defined by footway=crossing). So basically for the routing to be able to take into account the kerb height, the crossing and the footpath (or other pedestrian way) would have to share a node that then has a kerb:height tag (e.g. kerb:height=0.06 which says the kerb is 0.06 metres high, so 6cm).

One of the main things to note is that when creating sidewalks on ways in OSM there are two methods: creating a separate footpath object, or marking the sidewalk on the way using the sidewalk tag. Though the sidewalk tag method is the simplest, it is very limited as any other tags (such as surface) are for the road and not the sidewalk. For the wheelchair routing to work at its best, the sidewalks should be drawn separately from the road.

I hope that helps a little - it certainly is not a particularly simple thing to understand :slight_smile:

Adam


#5

Thanks Adam, really helpful.

Violaine - I’d be interested to hear more about your mapping parties work, as I’ve been running a similar project in Stockport (UK, just outside Manchester). I’ve been running workshops and mapping expeditions with disability and elderly groups. Would be good to hear how yours are going!

Sam


#6

Hey,
yes very helpful for me too!
I am thinking about using streetcomplete (adapting it) to encourage the contribution on accessibility topic (for mapping parties and extra if participant get passionated J). I would love to share experiences once we have tested a bit more. Happy to read Sam that you have experienced that kind of projects, I would also love to have your feedbacks and maybe recommendations… Have you hard about the Cartomobilite project in France? It was initiated by association Tiriad, I can share contacts if you are interested too, it’s also about mapping accessibility into OSM with people with disabilities. Huge parenthesis but great connexions I guess :wink:
@Adam, I would be curious to know how you would suggest to map connexion between sidewalk and crossing as in the wiki, highway=crossing is supposed to be on a point of a road. Then would be the projected point on the sidewalk (hope i am clear), the place to put kerb info? For now I indicated wheelchair accessibility (directly connected to kerb) and blind accessibility on the crossing. Maybe it would be best to add it at the projected point on the sidewalk then?
Plus as your are saying that ORS algorythm is taking kerb:height into account, would it be an option to use kerbe=raised or lowered also as it has a link with height? I think it is easier for people to use that as less precise. (you don’t always have a measuring tape with you).
Hope I am clear,
Look forward to reading you,
Best,
Violaine


#7

Hi @ViolaineDo

So with regards to the crossing tagging - how I would generally do it is to have a way that goes over the road which is tagged as highway=footway, footway=crossing. You can also include a node on this way /which is also part of the road) which can contain the crossing=... tag. The main reason for having it this way (using the highway=footway, footway=crossing is because that it allows different kerb heights on each side of the crossing (which can happen quite frequently). If the crossing was only stored as the corssing node, then differentiating the kerb heights on either side can become problematic, and it can also become difficult for the algorithm to determine if the route would actually go over the crossing (a continue forward action) or not (a turn at the crossing but staying on the same footpath). In general, when you draw the sidewalks as separate ways, also drawing the crossings as individual ways makes sense.

------x----o----x------

above, the horizontal line would be the footpath, and the crossing way would be the horizontal line between the two x’s., and the o would be the node marked as the crossing (which would intersect a road, but the post doesn’t want to draw that). In this case, the two x points would be used to store the kerb information and would be the nodes that connect the footpath to the crossing. (the dots in the diagram are just for layout)

In terms of the kerb=raised etc., the algorithm does actually take this into account with some default values (kerb=dropped - 0.03m, flush - 0.00m).

Adam


#8

Thanks @adam, it makes sense! Have a great day.

Violaine