Skip to content

EPIC Issue: Wheelchair support #3552

@cbayerlein

Description

@cbayerlein

This is an Epic-Issue, which should serve to bundle the communication and ideas for the feature "wheelchair navigation" and to enable an open exchange. This is a long-term project and a living document or communication thread. We want to work together on a solution step by step and continuously improve it and do not expect a big breakthrough in a single release. The subject is very complex, both in terms of the needs of wheelchair users, which can be very different, and in terms of the data situation.
Among other things, we are dealing with a chicken and egg problem: on the one hand, the data in OSM and from the GTFS providers are often missing to effectively find a good route for wheelchair users, which makes navigation difficult. On the other hand, there is currently a lack of services and algorithms that would exploit the data and thus offer an incentive so that the community and also transport providers provide a better data basis or expand it.
The basic aim is to enable people with advanced requirements to be mobile on their own. While some stairs are an obstacle, others want to avoid cobblestones. The solution must therefore take into account individual needs and be able to react flexibly to disruptions or changes in the travel route. The main goal is to find an optimal route. This should cover both local public transport and footpaths.
A separate wheelchair mode might not enough be to cover all cases. The possibilities and characteristics of wheelchair users vary from person to person. Some can handle steep inclines well and even overcome individual steps without problems, others have big problems on poor surfaces. A wheelchair user who drives his wheelchair manually wants to walk as flat as possible in order to save muscle power. On the other hand, a user of an electric wheelchair, for example, has no problem at all (to a certain extent). Then there are people like me who use special controls (for example I have a mini joystick that I operate with my mouth), for whom cobblestones are a big problem.
Our idea or our approach is to be able to individually adjust the route planning using as many parameters as possible.
The advantage of this approach is that it not only helps wheelchair users, but also, for example, people with cargo bikes etc.
It might be good organize our code in a similar way to the sandbox. Then, the reviews for PRs would be easier because fewer criteria had to be met. Unfortunately, that doesn't always work because we (have to?) change things in the core, for example. The same applies to the change in the API - here we should work with a flag and only activate the parameters when they are needed. We should also mark the API as experimental so that we can change it later.
As a first step towards our it is seen as a good idea to 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 This also corresponds to our overall idea of parametrisation. For more info on this surfaces related part, see issue #3524 / #3526 and PR #3525

Metadata

Metadata

Assignees

No one assigned

    Labels

    StaleThis issue is stale, no activity for 90 days. Remove stale label or comment within 30 days.

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions