Limit number of additional transfers

[t2gran]

Context/Example

Allow the client to search for travels with as few transfers as possible.

Solution

The number of transfers are not known before a search start, so using a 'maxNumberOfTransfer' limit can be problematic, even in cases where the traveler think he/she knows the expected minimum number of transfers.

Instead of using a absolute limit, we can use a relative number: numberOfAdditionalTransfers

[t2gran]

I have tested this with my 27 test cases, with the numberOfAdditionalTransfers = [8 .. 1].

Standard request parametre

==> mc_range_raptor_heuristic : [577, 574, 555, 517, 548, 603, 602, 604]
==> range_raptor   : [66, 61, 60, 66, 71, 73, 72, 72]

As we can see above does the check not give any performance improvement. Here is the same test before the code change:

==> mc_range_raptor_heuristic : [602, 569, 613, 603, 584, 606, 530, 594]  Avg: 587,6
==> range_raptor   : [75, 74, 74, 75, 75, 66, 60, 65]  Avg: 70,5

The most likely reason for this is that if a latestArrivalTime is set tight (no big slack) this seems to restrict the search more.

4 hours extra search window

  - earliestDepartureTime = request.fromTime - 2 * 3600
  - latestArrivalTime = latestArrivalTime + 2 * 3600
  - searchWindowInSeconds = request.toTime - request.fromTime + 4 * 3600

==> mc_range_raptor_heuristic : [891, 853, 851, 831, 822, 819, 675, 572]
==> range_raptor :              [131, 129, 146, 146, 145, 116, 108, 95]

When increasing the search window we get a small performance effect.