Visit-via and pass-through-via search

[BredeD]

Visit-via search

Force the pasenger to visit the via-location. The location must be a collection of stop or a single coordinate.

Features

• Wait time
• Stops are supported (no special handling for access/egress, you can not walk through a stop)
• Support coordinates in transfers
• Support for coordinates in access and egress (WIP)
• Support for Visit-via in direct street search (WIP)

Pass-through-via search

The pass-through is used to force the journey through a stop location with no extra time or required boarding/alighting. The journey is always passing through the stop location. It is possible to change vehicles at the via point, but it’s not necessary.

Features

• TASK-AX 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.

Generic via search features (apply to both pass-through and visit via)

Features

• Mixing visit-via and passthrough-via in a request. We need to test/update API and service code, in addition to TASK-AX.
• It shall be possible to use three via points. This is due to technical limitation in the pass-through implementation. This limit is removed after TASK-AX is done.
• 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 request preferences apply to all segments in the result.
• The response is the same as the response of a normal request, meaning that no information about the via points is included. This can be changed.
• 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.
• This is supported in the Transmodel and GTFS GraphQL APIs - the features are identical.
• Remove relaxCostAtDestination
• Enable the heuristics for via and pass-through. (This depend on TASK-AX).
• Add support to Debug UI (WIP)
• Preserve via results in OptimizedTransfer - this is an existing bug in both cases(pass-through and visit).
• Filter away bad results. One way to do this is to use a direct search witch visit/pass-through the via-locations and prune results that are worse based on the generalized-cost. (Support for filtering itineraries with just visit via locations with coordinates by comparing them to direct itineraries will be implemented automatically)

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.
• Search via a specific stop to stay there for a given time or go from one trip to another
• Search via a specific POI to stay there for a givne time or go from one trip to another

Known bugs

• Support for round trip via search #6839
• Via visit at a stop does not actually stop over for the specified period of time at the requested station, but at the station after the transfer leg instead #6537
• via search is extremely slow #6398

[jtorin]

Tasklist (THIS IS NOT LONGER RELEVANT @tgran)

Details

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