Transfer cost limit

[leonardehrenfried]

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

[codecov]

Codecov Report

Attention: 63 lines in your changes are missing coverage. Please review.

Comparison is base (f20ffe8) 66.90% compared to head (428970b) 66.97%.
Report is 74 commits behind head on dev-2.x.

Files	Patch %	Lines
...pplanner/apis/gtfs/datafetchers/QueryTypeImpl.java	17.64%	14 Missing ⚠️
...ext/stopconsolidation/StopConsolidationModule.java	79.31%	6 Missing ⚠️
...tion/internal/DefaultStopConsolidationService.java	83.87%	3 Missing and 2 partials ⚠️
...planner/graph_builder/GraphBuilderDataSources.java	0.00%	5 Missing ⚠️
...tion/configure/StopConsolidationServiceModule.java	0.00%	4 Missing ⚠️
..._builder/module/configure/GraphBuilderModules.java	0.00%	4 Missing ⚠️
...m/filterchain/ItineraryListFilterChainBuilder.java	55.55%	3 Missing and 1 partial ⚠️
...rithm/mapping/RouteRequestToFilterChainMapper.java	33.33%	2 Missing and 2 partials ⚠️
...ext/stopconsolidation/StopConsolidationParser.java	91.42%	3 Missing ⚠️
...rg/opentripplanner/graph_builder/GraphBuilder.java	0.00%	3 Missing ⚠️
... and 6 more

Additional details and impacted files

@@              Coverage Diff              @@
##             dev-2.x    #5516      +/-   ##
=============================================
+ Coverage      66.90%   66.97%   +0.06%     
- Complexity     15734    15821      +87     
=============================================
  Files           1823     1833      +10     
  Lines          70366    70599     +233     
  Branches        7403     7410       +7     
=============================================
+ Hits           47080    47281     +201     
- Misses         20821    20845      +24     
- Partials        2465     2473       +8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[optionsome]

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?

[leonardehrenfried]

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?

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

cost = edgeLength * walkReluctance * slopeReluctance * stairsReluctance * ...

when we probably want something like this

cost = edgeLength * (walkReluctance + slopeReluctance + stairsReluctance + ...)

Refactoring this quite complicated because the StreetEdge has a lot of spaghetti code. Maybe one day I will get around to doing that.

[t2gran]

On cost = edgeLength */+ walkReluctance */+ slopeReluctance */+ stairsReluctance */+ ...

I would like to discuss this with @abyrd. I think using + and not * may make sense, but it changes the cost calculations a lot an it will require us to tune OTP again. My first reaction is that it makes the reluctance independent of each other - witch I think is a good thing.

[t2gran]

This looks good, only a few comments to the test. I am ready to approve this after the small fixes is applied.