Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make maxWheelchairSlope not a hard cut-off, but apply a cost instead #4088

Merged

Conversation

hannesj
Copy link
Contributor

@hannesj hannesj commented Apr 12, 2022

Summary

This changes the behaviour when an edge has steeper slope than the maxWheelchairSlope. Previously, if no path was found, the limit was dropped and the search was re-done. In this PR the behaviour is changed, and instead a cost factor is applied, if the slope is too steep.

Open questions

  • Should we apply also a time penalty
  • Should the cost be a static cost per request, per edge or a multiplier?

Also, remove retry without the limit, but instead add penalty
@hannesj hannesj added this to the 2.2 milestone Apr 12, 2022
@hannesj hannesj requested a review from a team as a code owner April 12, 2022 07:38
* What penalty factor should be given to street edges, which are over the max slope.
* Set to negative for disable routing on too steep edges.
*/
public double wheelchairSlopeTooSteepCostFactor = 10.0;
Copy link
Member

@leonardehrenfried leonardehrenfried Apr 12, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be part of the WheelchairAccessibilityRequest in the future?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think so, the same with maxWheelchairSlope

@t2gran t2gran requested a review from optionsome April 12, 2022 09:04
@optionsome
Copy link
Member

My sense is that the cost should be multiplier for the edge and it should be high enough so that if there is a reasonable alternative path, it would be used instead. There could be extra time multiplier as well for traversing an edge but I guess the normal walk elevation speed affects this as well already a bit so I don't know if it's necessary (although it might be slightly slower with wheelchair vs walking up a hill).

Side note, I don't think the wheelchair access map layer currently takes into account the configured maxWheelchairSlope in the color scheme.

@hannesj hannesj merged commit 5d42578 into opentripplanner:dev-2.x Apr 21, 2022
@hannesj hannesj deleted the otp2_remove_absolute_slope_factor branch April 21, 2022 08:12
t2gran pushed a commit that referenced this pull request Apr 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants