opentripplanner / OpenTripPlanner

An open source multi-modal trip planner
http://www.opentripplanner.org
Other
2.19k stars 1.03k forks source link

Add reluctance to "walk" over certain surfaces (for wheelchairs) #3524

Closed danielthegray closed 2 years ago

danielthegray commented 3 years ago

Expected behavior

In the context of using OpenTripPlanner to route trips for disabled users, it would be great to have a way to penalize going over certain surfaces (like cobblestones or other similarly rough surfaces). Doing an internally hard-coded implementation would not be ideal, since this also depends on the type of wheelchair the person is using (i.e. some wheelchairs are better equipped to handle rough surfaces than others). In short, it would be best to have these parameters be tweakable, to allow the caller application to define these values in a way that makes sense for different users.

In essence, I propose to add a set of "surface reluctance factors" with which the user can penalize going over certain surfaces. The alternative of simply excluding such surfaces is not always desirable, since pruning these too aggressively can sometimes leave the user without a possible route to reach a destination (this is a problem currently faced by disabled users using Openrouteservice, for example). Adding a factor makes it more likely that the path with the difficult surface will only be taken if there is no other alternative, or one that is considerably longer, for example.

Of course, if a way/street has no surface information, nothing should be done, but this situation would improve as more data is added to OpenStreetMap.

This could of course also be used for bicycles, I assume.

Observed behavior

Currently this is not possible in OpenTripPlanner.

Version of OTP used (exact commit hash or JAR name)

This is still true in the latest dev-2.x branch (currently at commit 8db1c600)

leonardehrenfried commented 3 years ago

A very similar concept exists already in OTP for bicycles where each street has a bicycle safety factor and the client can determine how important safety is as opposed to speed. A lot of code could be reused to take the issue proposed here into account.

A complication that springs to mind already is that OSM surfaces mostly mean the actual road surface but not the pavement next to the street. However for public squares and pedestrian-only paths it would still apply.

Do you have examples for OSM entities that a wheelchair user would like to avoid?

danielthegray commented 3 years ago

Hello, yes, I reviewed the bicycle safety factor code, but I thought that this problem was a bit different. I have added a PR with some proposed code changes. Your point on the surface of the pavement/sidewalk next to the street not being the same is a good point. Would there be a way to only apply it to pedestrian ways perhaps? Or to read sidewalk surface data?

An example would be, based on the surface values seen at https://wiki.openstreetmap.org/wiki/Key:surface that unhewn_cobblestone surfaces would be quite universally undesirable, but "sett" paving could maybe not be desirable either, depending on the wheelchair.

leonardehrenfried commented 3 years ago

With examples I meant specific ways, like so: https://www.openstreetmap.org/way/76102685

After looking at the OSM wiki the correct tag for the surface of the pavement seems to be sidewalk:surface, but I checked in my city and there weren't many instances%3B%0A%2F%2F%20print%20results%0Aout%20body%3B%0A%3E%3B%0Aout%20skel%20qt%3B&C=52.49135;13.46409;11&R) of it.

I'm sorry to say it but my feeling is that your approach is a little too simple, but I will move the conversation to the PR instead.

t2gran commented 3 years ago

I think the goal here is very interesting, as I mentioned in the PR I think we should discuss this in a developer meeting and report back on it her. We do not want to end up with a parameter for each OSM tag, so I share @leonardehrenfried concern about the parameter being to specific.

t2gran commented 2 years ago

The OpenSidewalks project was mentioned in todays PLC meeting, and is relevant for this issue.

github-actions[bot] commented 2 years ago

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days