Remove transit with higher cost than best on-street itinerary filter

[vesameskanen]

Summary

RemoveTransitWithHigherCostThanBestOnStreetOnly filter currently removes all transit itineraries, if their cost is any higher than the best of non-transit itineraries. This is bad because a citybike itinerary can erase all equally fast transit itineraries. This is quite anti-multimodal behavior.

This PR adds a similar two parameter cost limit function as other filters which compare itineraries use.

To avoid appearance of silly more walk + transit vs. plain walk itineraries, hard limit is still applied to walk street mode.

Documentation

Updated to describe how new filtering logic works

Unit tests

Unit tests updated.

[codecov]

Codecov Report

Patch coverage: 94.02% and project coverage change: +0.18% 🎉

Comparison is base (79d1cbc) 66.27% compared to head (200ed4e) 66.46%.
Report is 115 commits behind head on dev-2.x.

Additional details and impacted files

@@              Coverage Diff              @@
##             dev-2.x    #5222      +/-   ##
=============================================
+ Coverage      66.27%   66.46%   +0.18%     
- Complexity     15171    15225      +54     
=============================================
  Files           1789     1787       -2     
  Lines          69275    69296      +21     
  Branches        7351     7314      -37     
=============================================
+ Hits           45910    46055     +145     
+ Misses         20881    20763     -118     
+ Partials        2484     2478       -6     

Files Changed	Coverage Δ
...request/preference/ItineraryFilterPreferences.java	92.15% <77.77%> (-2.66%)	⬇️
...m/filterchain/ItineraryListFilterChainBuilder.java	90.00% <100.00%> (+0.34%)	⬆️
...g/algorithm/filterchain/RoutingErrorsAttacher.java	97.14% <100.00%> (+0.71%)	⬆️
...agger/RemoveTransitIfStreetOnlyIsBetterFilter.java	100.00% <100.00%> (ø)
...nflagger/RemoveTransitIfWalkingIsBetterFilter.java	100.00% <100.00%> (ø)
...rithm/mapping/RouteRequestToFilterChainMapper.java	78.43% <100.00%> (+0.88%)	⬆️
...ne/config/routerequest/ItineraryFiltersConfig.java	99.07% <100.00%> (+0.05%)	⬆️

... and 59 files with indirect coverage changes

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

[leonardehrenfried]

I think this is a good improvement but I would like someone from Entur to take a look as they are they are the main developers/user of these filters.

[vesameskanen]

New cost function is in use here:

https://reittiopas.hsl.fi/reitti/Lapinrinne%202%2C%20Helsinki%3A%3A60.16571397446897%2C24.927077293396/Merikasarminkatu%2012%20F%2C%20Helsinki%3A%3A60.16777953071638%2C24.975668191909794?setTime=true&time=1692271080

In addition to perfectly matching biking between two stations, also plain transit and citybike + transit itineraries are available.

[leonardehrenfried]

That URL leads to a 400 - could you please correct it?

[vesameskanen]

Link to example search above fixed.

[leonardehrenfried]

Indeed a very nice variety.

[leonardehrenfried]

This branch has conflicts

[leonardehrenfried]

Can you please resolve the conflicts?

[t2gran]

Does this filter do two things now?

• Filter on a hard limit compared with walking
• Filter based on a function with street itinerary

If, so the filter should be split into two filters, it should be possible to configure these things separate. An alternative is to make one filter witch is configurable with respect to matching street modes, then the same filter can be used for different cases(walk, walk+bicycle, walk+car ...).

[vesameskanen]

Right, it indeed applies two clearly different logic. I can split it if necessary.

[t2gran]

I think splitting it is the easiest way to solve it and also "good enough". We discussed it at todays meeting, where I tried to explain the more "generic way" to solve it, but I think it is overkill.

[t2gran]

Some names and doc needs to be fixed

[leonardehrenfried]

You need to format the code.