Support intermediatePlaces in OTP2

[flaktack]

OTP2 currently doesn't support the intermediatePlaces parameter in RoutingRequest.

Reimplement support for it, maybe even adding extra functionality:

• minTransferTime, maxTransferTime (slack?) at a given intermediatePlace
• allow via points, where there is no need to actually transfer, only to pass through a given Stop/StopCollection

Minutes Via Routing Meeting 10th May 2022

(by @t2gran)

1. Via location can be a Station, Stop or coordinate. This should work the same way as the from/to
   fields in the current routing works. Use Stop/Station ID it the stop/station exist, if not use
   the coordinate. Each location should have:
   1. passThroughPoint : boolean = false
   2. minSlack : Duration = 10 minutes
   3. maxSlack : Duration = 60 minutes
2. Will have to perform multiple searches. We can start with doing them in sequence, and if needed
   optimize and run them in parallel. Running the searches in parallel, will require an initial
   search for each viaTrip to find minTravelTime. Then perform searches for different viaTrips in
   parallel.
3. How should answer look? (same answer for initial implementation probably)
4. Maybe different query endpoint (same answer but different input params)
5. Skåntertrafiken would want to have this feature in transmodel as well thou
6. Support for paging (as a separate feature/task)

Open questions?

• If a Station is used as a via-point, should the next journey stat from the arriving stop of
  the first journey. I vote for no, unless it is a passThrough via point.
• What is the makimum number of via point we should allow. We should have a limit to limit the
  DOS attack possibilities. A search with 1000 via points would take down a server with one
  call.
• ArriveBy search supported? No?

Tasks

• Part A - Via search, refactor OTP Internal programming API #4156
• Part B - Via search, Design and implement the Transmodel API & Legacy API, we can start with one, then
  the other should be a transfation of the first.. (Depend on: A)
• Part C - Via search, add back the feature for the REST API. (Depend on: A)
• Part D - Via search, implement feature. (Depend on: A) #4494
• Part E - Add support for passThroughPoint. (Depends D)
• Part F - Via search, implement a hard timeout for all requests to prevent DOS attacks.
• Part G - Add StartOnboardRequest{FeedScopedId tripId; FeedScopedId stopId; ServiceDate date}. This is not part of the Via search, but a separate feature. I add it here so we do not forget. Create code or issue for this. (Depend on: Part A, via search)

[t2gran]

This not top priority at Entur, but if someone provide the resources to develop it I am happy to assist. When I say "top priority" it means that there are quite a few tings that is prioritized before this. We have some thoughts about how to implement this. I would like to make an extension point in OTP so we could do this, and also at the same time allow for similar needs, like running a multi-mode access/egress/transit parallell search with a filter at the end.

[flaktack]

In realCity:feature/intermediate-places we've started working on an initial implementation which does one trip plan between each pair of places (A - B, B - C, C - D) manipulating the searchWindow based on the previous section's results. It also takes into account that due to StopCollections each point may in fact be multiple different stops, requiring planning from different places.

We're open to suggestions on how to improve it, or what would be a better approach.

[tontonsb]

Hey, what's the current state and plans on this issue? Is anyone (maybe in a fork) actively tackling this?

We're trying to do travelling salesman by calculating pairwise distances and solving the problem outside OTP, but with rented bicycles it seems impossible as the pairwise routes are found such that the bicycle has to bet left at a station while we'd actually need it to visit a place and continue on without looking for stations.

[flaktack]

We are not actively working on this, realCity:feature/intermediate-places contains the latest state of our code. We may have time in the next few months to rebase it on a current dev-2.x.

[optionsome]

What is the use case for maxTransferTime at an intermediate place?

[flaktack]

It had two purposes:

• as a filter -- so a transfer at the intermediate point didn't contain a wait that was longer than say 2 hours
• as an optimization - the feature branch did a separate search for each pair of stops (A-B, B-C, C-D) while manipulating the searchWindow and so it was used to limit the possible results

[t2gran]

I have updated the original problem description today. I suggest doing the OTP Internal Model API to be done first, then someone can start to implement the APIs, and someone else can port @flaktack work to fit the OTP Model API. The reason why I want us to refactor the API first is:

• It opens up for a more flexible via search to be made
• It divide the Request into smaller parts, easier to maintain and understand. Today there are implicit relations witch is very hard to grasp.

[t2gran]

I am a bit unsure if we need minSlack and maxSlack, and instead should use the same as we do for regular transfers, just use a viaPointSlack. The viaPointSlack will replace transferSlack at the via point. I think the a common use case is for the user to specify how much time he/she want at least at the via point. We will then use the request searchWindow to find the "maxSlack":

  nextViaTrip latest-departure-time := min-arrival-time + (board-, alight-,viPoint slack) + searchWindow next viaTrip. 

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days