Transfer cost limit - #5516
Conversation
leonardehrenfried
added
the
!Bug
299318c to
3a4f8d7
Compare
ba043a1 to
099d65e
Compare
|
Is this problem unique to transfers? Could this happens in street routing elsewhere? I'm just wondering should we slightly lower the cost of wheelchair traverse on these non-wheelchair friendly edges? |
d63c58c to
ba0c3f9
Compare
025a299 to
2a6bc4d
Compare
It's technically possible for access/egress searches but very, very unlikely since there a proper A* calculates the cost and prunes away bad choices. In a transfer you don't have an A* and simply re-traverse the pre-computed list of edges with new street preferences. As @slvlirnoff has pointed out, the cost calculation for wheelchairs increases probably a little too explosively because we multiply the reluctances with each other instead of adding them. So we currently do when we probably want something like this Refactoring this quite complicated because the StreetEdge has a lot of spaghetti code. Maybe one day I will get around to doing that. |
|
On I would like to discuss this with @abyrd. I think using |
40c0dc1 to
9e258f5
Compare
eeabd18 to
c8bec80
Compare
c8bec80 to
176f192
Compare
t2gran
left a comment
t2gran
left a comment
There was a problem hiding this comment.
This looks good, only a few comments to the test. I am ready to approve this after the small fixes is applied.
…ter/transit/TransferTest.java Co-authored-by: Thomas Gran <t2gran@gmail.com>
a48ff4d to
428970b
Compare
A street access, egress or transfer leg over a steep, wheelchair-inaccessible stairway can accumulate a generalized cost so large that converting it to Raptor's 32-bit int cost overflows to a negative value, failing the whole request with "Negative value not expected" when the path is mapped to an itinerary. Transfers were already guarded (opentripplanner#5509/opentripplanner#5516); access/egress, via and carpool were the unguarded siblings. Extract the transfer sanity-clamp into a shared CostLimit helper and apply it to all street-derived Raptor cost conversions. Addresses opentripplanner#7679
A street access, egress or transfer leg over a steep, wheelchair-inaccessible stairway can accumulate a generalized cost so large that converting it to Raptor's 32-bit int cost overflows to a negative value, failing the whole request with "Negative value not expected" when the path is mapped to an itinerary. Transfers were already guarded (opentripplanner#5509/opentripplanner#5516); access/egress, via and carpool were the unguarded siblings. Extract the transfer sanity-clamp into a shared CostLimit helper and apply it to all street-derived Raptor cost conversions. Addresses opentripplanner#7679
A street access, egress or transfer leg over a steep, wheelchair-inaccessible stairway can accumulate a generalized cost so large that converting it to Raptor's 32-bit int cost overflows to a negative value, failing the whole request with "Negative value not expected" when the path is mapped to an itinerary. Transfers were already guarded (opentripplanner#5509/opentripplanner#5516); access/egress, via and carpool were the unguarded siblings. Extract the transfer sanity-clamp into a shared CostLimit helper and apply it to all street-derived Raptor cost conversions. Addresses opentripplanner#7679
4 participants
Summary
As discussed in today's dev meeting and described in #5509 absurdly high transfer costs can lead to an integer overflow in RAPTOR.
This PR adds a safety limit when transfer costs are being calculated. This limit is still pretty high (several days of transit-equiavalence) but well below
Integer.MAX_VALUE.Issue
Closes #5509
Unit tests
✔️
Documentation
Javadoc.
cc @miles-grant-ibigroup @binh-dam-ibigroup