Via-search - pass-through

[BredeD]

• The journeys in the response always pass through the via point. It is possible to change vehicles at the via point, but it’s not necessary.

• There is no given waiting time at the via point.

• The via point is a list of points. What it represents is developed in two iterations:

  Iteration 1:

  • stopplace (station)
  • quay (stop)

  Iteration 2:

  • group of stopplaces
  • multimodal stopplace

• It shall be possible to use three via points, because it is possible to store the numbers 0-3, in two bits.

• The request is a normal request with the via points to use added. This means that the via functionality shall be possible to combine with for instance different types of filters.

• The same request parameters are used before and after the via point.

• The response is the same as the response of a normal request, meaning that no information about the via points is included.

• Response time should not be a lot higher for searches with via points. Response time for searches without via points should not be affected at all.

Use cases:

• Selling a ticket for a journey passing a specific stop.

• Restricting the journey to a result that is slower, but pass through a specific stop.

[jtorin]

Tasklist:

• Raptor integration points.
  • C2 values storage data structure
    • Design
    • Test performance (BitSet vs HashSet)
    • Map from API request to this structure
  • Increment/set the C2 value.
  • Check in the destination that we have visited all via-points.
  • Inject a Pareto-function to Raptor.
  • Unit tests.
• Adapt Optimized Transfers
• Design and Implement API and connect to Raptor
  • REST API
  • Transmodel GraphQL API
• Manual system testing (performance)
• Evaluate the heuristic function

[t2gran]

The via-search is a bit unusable/hard to use. So, instead we could extend the pass-through-point feature with:

• force a visiting the location, either by boarding or alighting at the point.
• Allow for a minimum-wait-time at each pass-through-point. Any slack (board/alight) will be in addition to the minimum-wait-time.

[t2gran]

I check off the boxes witch is implemented so fare.

[t2gran]

After the #6084, there are still a few smaller things witch should be implemented:

• support for coordinate via locations. This is implemented in Raptor, but there is no module test for it. To implement this "transfers" must be generated between the to Raptor searches. To find all transfer, find the paths for all stops nearby and put all pair of them together to form a transfer (stop A -> coordinate -> stop B).
• Refactor Raptor passthrough to use the chaning feature. This will allow us to use the pass-through with transit-group-priority and also heuristics. To do this Raptor must support starting a journey on-board witch is useful in other use-cases as well. When this is done, we can remove the existing pass-through implementation.
• Mixing visit-via and passthrough-via. There is two ways to do it, either by using the existing pass-through (messy setup) or doing the above first, and we will get it for free.
• Enable the heuristics for pass-through.
• Add support to GTFS API. @leonardehrenfried Will add this in this PR.
• Add support to Debug UI
• Remove relaxCostAtDestination
• Add support for via in AStar (direct-street)
• Add information in response for via? There is no tagging for via point in the path/itinerary. This can create problems in e.g. TransferOptimizer.
• Preserve via results in OptimizedTransfer - this is an existing bug with pass-through as well.