Routing for accessibility, without Scores

[trurlurl]

This is an alternative proposal to #254, keeping BaseTripMobilityFilterGroup (almost) unchanged but nevertheless allowing for specifying low level accessibility needs and preferences.

• AccessibilityPreferences have been introduced to allow for minimizing obstacles like stairs even when there is no route with zero stairs (i.e., when NoStairs=true does not find any result).
• It is possible to do a search for a user with both visual and mobility impairment.

[ue71603]

• Jona: is the router allowed to reduce the product category
• Additional optimisationMethods ok, but probably not implemented.
• Restrictions stay.

[trurlurl]

AccessibilityRoutingPreferences are now intended to be used by a single OptimisationMethod, bestAccessibility, and allow for optimizing for mobility and other impairments.

I played through a few scenarios, and the current solution now seems satisfactory (to me). Here an example of a complexer scenario:

Example of a visually + mobility impaired passenger Strongly reduced vision, uses can, taking stairs is tedious but possible

Do a search for bestAccessibility

• noStairs prio 1
• tactileGuidance prio 2
• noSingleSteps prio 3
• noRamp prio 4 -(in order to favor elevator) -> connections may be missed

Do 2nd search for bestAccessiblity - w/o prio 4 / noRamp (to get the routes previously discarded due to the missed connections)

Do a search for fastest

For each route found for fastest, refine (RefinementRequest) each TransferLeg for bestAccessibility

• noStairs prio 1
• tactileGuidance prio 2
• noSingleStep prio 3
• noRamp prio 4

Do a search for leastWalking

For each route found for leastWalking, refine (RefinementRequest) each TransferLeg for bestAccessibility

• noStairs prio 1
• tactileGuidance prio 2
• noSingleStep prio 3
• noRamp prio 4

Quite a number of searches (one might also want to add minChanges) - but it seems possible to get a really useful collection of routes relevant for a particular impairment profile.

[trurlurl]

Remark about the serialization of the priorities

The question was raised whether the order in which the priorities are listed is guaranteed to be preserved when serializing the xml. Doing an internet search, I didn't find this to be a known problem. Surprisingly, sequence seems to be more disputed, but should work as well: https://stackoverflow.com/questions/2911919/is-there-a-way-to-enforce-preserve-order-of-xml-elements-in-an-xml-schema?noredirect=1&lq=1

[trurlurl]

Failing check is due to the fact that the branch is on my separate cloned repository. I'm going to change that for future pull requests in order to avoid that problem (and others). For this PR we can leave it like that, I guess - ?

[sgrossberndt]

No, this is not possible, otherwise we get ci/lint changes in the changes_for_v1.1 branch. Please create a new branch [accessibility_routing](https://github.com/VDVde/OJP/tree/accessibility_routing) in https://github.com/VDVde/OJP/ and push your branch to it.

[trurlurl]

Removed documentation label, documentation will be done for the follow-up PR.