Is your feature request related to a problem? Please describe.

When clients receive error code walkingBetterThanTransit (Transmodel API) they start paging to check if there are itineraries in the future (or in the past). These searches take surprisingly a lot of CPU, and timeout when the search-window is more than 1 day. This needs more investigation to find out why the search is not effectively pruned. In some cases we have seen 200+ optimal transit results, witch is dominated by the direct=foot result.

Goal / high level use-case
As a traveler I want to find a transit option, even if the option is fare into the future. In low frequency areas this is important. This however, create issues in areas with a lot of options slightly worse than direct walking.

Describe the solution you'd like

• The best solution to this is to feed the cost/times from the direct-search into Raptor when paging. We can inject a synthetic result in the destination arrival with (transfers=0, duration=foot.duration, cost=foot.cost). I would expect that this will prune the raptor search so much that doing 10 calls with paging is not a problem. The first search should be done like today without passing in any pruning state. For any next/previous search we should try to prune the search. This is probably the best solution, but slightly more complex to implement. There are other ways to do this as well:

  • Over-lapping-access-egress. If more than 60% of the access/egress stops are the same we could reduce the max-number-of-transfers to 1 or 2. OR, we can also limit the search to the union of the stops found in access/egress. The later is an optimization we could apply to all searches. Both of these are relativly easy to implement.
  • We can drop NEXT/PREVIOUS token if the direct foot is less than NNN meters. I do not like this because, we vil still have the issue when the walk is longer than NNN, and might miss som optimal results when walk distance is less than NNN.

• We should also limit the total-search-window to something like a week (configurable) to prevent miss-use of the API. We can do this by accumulating the search-window inside the token.

Describe alternatives you've considered

Additional context

This show a significant increase in timeouts. The overall stress on the system is less notable, but the p50 and p99 latency increased as well.