Add crossing encoded values for accessible pedestrian routing.
natedx opened this issue · comments
Crossings have additional keys in OpenStreetMap which indicate a number of features from appearance to accessibility : https://wiki.openstreetmap.org/wiki/Key:crossing
In the SonarVision app, we have been using the results of PR #2707 for a bit over a year now, allowing us to automatically display crossings to our users ! It's quite amazing ! However, crossings vary a lot in their level of accessibility, making additional crossing keys invaluable for accessible routing.
For example, our blind and visually impaired users typically prefer to be routed through crossings tagged with
crossing=traffic_signals
traffic_signals:sound=yes
tactile_paving=yes
I imagine adding these values to Graphhopper implies creating a number of new encoded values. The main ones I believe are important for a wide range of accessible routing use cases are :
- crossing=traffic_signals/uncontrolled/unmarked/no/informal
- kerb=yes/no/raised/regular/rolled/lowered/flush/...
- tactile_paving=yes/(no)/incorrect
- traffic_signals:sound=yes/no
Finally, adding these encoded values might also help solve the problems raised in issue #2809. Pedestrians have wildly different expectations when it comes to routing. A hurried sighted person might want the shortest path in terms of length, as crossings aren't a problem for them (they might even cross without stopping at red lights...), however a blind pedestrian will want to minimize the overall number of crossings to a certain extent while maximizing the number of crossings equipped with audio traffic signals for obvious safety reasons. A wheelchair user might want to avoid all crossings where kerbs are not lowered or flush.
Thank you for this amazing piece of software !
Totally aggree with this issue.
When the triage is done, if you guys thing this could be a good first issue for newcomers, I'll be happy to have a look to add this tags and/or take them into consideration when finding a route.
