org.opentripplanner.routing.algorithm.transferoptimization.package.md Maven / Gradle / Ivy
Go to download
Show more of this group Show more artifacts with this name
Show all versions of otp Show documentation
Show all versions of otp Show documentation
The OpenTripPlanner multimodal journey planning system
# Transfers / Interchanges
OTP2 handles transfers differently than OTP1. In OTP1, transfers were optimized by applying a cost
for each transfer edge during the search. In OTP2, finding the best transfers is done partially during
routing and then improved in a post-processing step. It is easier to understand how you should tune
OTP2 if you understand this process. When optimizing transfers we first find the best paths
(sequences of trips), then identify the best stops to transfer between subsequent trips in each of
those paths (the post-processing).
## Supported Input Data
- OTP supports [GTFS Transfers.txt](https://gtfs.org/reference/static#transferstxt) and the Google
extention with [Trip to Trip transfers](https://developers.google.com/transit/gtfs/reference/gtfs-extensions#TripToTripTransfers).
- OTP supports [NeTEx Interchanges](https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728760393/timetable#Interchange.1) as specified in the Nordic profile.
## Goals
1. Prefer paths with fewer transfers over many transfers.
2. Prefer some locations (stop pairs) over others.
3. Support `StaySeated` and `Guaranteed` transfers.
4. Choose the transfer with the highest priority: `Preferred` over `Recommended` over `Allowed`.
5. Support for transfer specificity, [Specificity of a transfer](https://developers.google.com/transit/gtfs/reference/gtfs-extensions#specificity-of-a-transfer).
6. Prevent transfers between stops and/or trips/routes. GTFS Transfers `transfer_type = 3` and
Netex Transfer `priority = -1(not allowed)`.
7. Find the best place to transfer between two transit trips in a path. Normally we want to
maximize the "wait-time"/"extra-time" to allow the traveler to have as much time to do the
transfer as possible.
1. Maximize the wait-time
2. For a journey with more than one transfer we want to distribute the wait-time, if possible.
For a path with 2 transfers it is better to have 4 minutes extra for each transfer than
having 30 seconds for one and 7m30s for the other.
3. For a transfer between two trips we want to find the right balance, between
extra-transfer-time and the path generalized-cost(like the cost of walking and riding a
bus).
## Not Supported (jet)
- Using GTFS transfers.txt it is possible to set the `min_transfer_time` with `transfer_type = 2`.
See issue [#3369](https://github.com/opentripplanner/OpenTripPlanner/issues/3369)
- The NeTEx Interchange MaximumWaitTime is ignored.
- Transfer not-allowed at location.
See issue [#3505](https://github.com/opentripplanner/OpenTripPlanner/issues/3505).
- Support for Trip matching when only Route is specified in transfers.txt.
See issue [#3429](https://github.com/opentripplanner/OpenTripPlanner/issues/3429)
## Implementation
OTP finds the best transfers in 2 steps:
1. As part of the routing. The routing engine (Raptor) applies generalized-cost and
number-of-transfers as criteria during the routing. In addition, Raptor supports overriding
regular transfers with constrained transfers.
1. Goal 1 is achieved by having `number-of-transfers` as a Raptor criterion.
2. Goal 2 is achieved by giving some stops a lower _visiting-cost_ according to the
`StopTransferPriority`.
3. Goal 3 and 6 is achieved by allowing constrained transfers to override regular transfers. An
optional `RaptorTransferConstraintsProvider` is injected into Raptor which Raptor calls to
get guaranteed transfers. This service is also responsible for rejecting a transfer(TODO).
2. Optimize transfers: Goal 4, 5, and 7 are achieved by post-processing paths. Paths from the
routing search are revised, optimizing the stop at which transfers happen between each pair of
transit rides (trips). This step does NOT compare different paths returned by the router
(Raptor), but instead finds all possible transfer locations for a given path, and the different
alternatives to transfer between each pair of trips within the path. This is an outline of the
process:
1. For each path find all possible permutations of transfers.
2. Filter paths based on priority including `StaySeated=100`, `Guaranteed=10`, `Preferred=2`,
`Recommended=1`, `Allowed=0` and `NotAllowed=-1000`. Each path is given a combined score,
and the set of the paths with the lowest score is returned (more than one path might have
the same score).
3. Another filter which breaks ties based on an "optimize-transfer-cost" function.
4. Because the number of permutations grow exponentially with the number of transfers,
each filter above is applied for each sub-path starting from the end of the path. This
keep the number of options down, close to O(N), where N is the number of transfers.
## Design - Optimize transfers
The `OptimizeTranferService` is the entry point and delegates to the "domain" services in
the `services` package. The result of the optimization process is an `OptimizedPath` found in the
`api` package. The optimization process first uses the `TransferGenerator` to find all possible
transfer points between each trip in a path. Then the `OptimizePathService` constructs all possible
paths starting at the "tail" with the egress-leg, and adds legs until the path is constructed.
To avoid exploring too many paths, the optimization filters the result of each step, reducing the
set of optimal tails. The `MinCostFilterChain` is used to filter each equivalent set of paths and
the `TransitPathLegSelector` finds the best tail for each transfer used to generate a new path-tail.
Here is an outline of the calls:
### Packages
Package `org.opentripplanner.routing.algorithm.transferoptimization` has the following subpackages:
- `api` classes used outside the transfer-optimization.
- `configure` creates and wires up the the module.
- `model` simple internal model classes used by the services.
- `services` internal transfer-optimization domain services, which collaborate to do the job.
### Important classes
The `TransferOptimizationServiceConfigurator` is responsible for creating and wiring up the module.
The configuration `TransferOptimizationParameters` is used to configure classes and inject the
right versions of each class. For example, the min-cost-filter-chain is created with the
appropriate filters to perform the filtering according to the configuration.
The `OptimizeTransferService` is the entry point of the service and responsible for delegating
the sub-tasks to the internal domain services. It is also responsible for the life-cycle, mainly
injecting 'setMinSafeTransferTime' before the calculation starts.
The `OptimizePathService` finds the best optimized path using the other domain services.
The `TransferGenerator` is responsible for finding all possible transfer options and decorating each
transfer with information that the other services will use later to do their job. The additional
information added to each transfer is:
- Constrained transfer information including priority, guaranteed, stay-seated and so on
- The various cost described in `TransferOptimized`:
- `transfer-priority-cost`
- `wait-time-optimized-cost` or `generalized-cost`
- `break-tie-cost`
The `wait-time-optimized-cost` is described in [detail below](#the-optimize-transfer-cost-function).
The `TransitPathLegSelector` uses the filter-chain to prune the results already found before
combining them with new transfer-points and a new transit-path-leg.
The domain `OptimizedPathTail` is used to store the intermediate results. It decorates the `PathLeg`
from Raptor with `TransferOptimized` costs.
### The Optimize-transfer-cost Function
The optimize-transfer-cost function is used select between alternative transfers for a
"path" with the same set of on-board trips. This address goal 7 above:
1. Maximize the wait-time
2. Distribute the wait-time between transfers
3. Balance the wait-time cost and the generalized-cost
To compare two paths we need a cost function that account for the differences in the existing cost,
except the wait-time cost, and add a new inverse cost for the extra-time:
```
F(t) = path.generalized-cost - total-wait-time * waitReluctance + ∑ f(t)
```
The `∑ f(t)` is the sum over the new wait-time-cost-function `f(t)` where `t` is the wait-time for
each transfer in the path.
We have created a function with two parts:
- a linear decreasing component with a factor `a`. This should be adjusted to balance with the
components of the path `generalized-cost`.
- an inverse logarithmic function which have a high cost for short wait-times.
This function is relative to the calculated `min-safe-transfer-time`.
The `f(t)` is constructed so only 2 parameters are needed to tune it. Let:
- `t0` be the `min-safe-transfer-time`. This is defined as 6.67% of the total transit-time
including board- and alight-slack across all paths found in the search. We want the `f(t)` to
be relative to the travel-time, and fairly stable over time, independent of day of week. So,
by excluding wait time we get an ok estimate for the journey travel duration.
Then the parameters used and available for configuration is:
- `a` the `inverse-wait-reluctance`. This factor is an inverse `waitReluctance`. For example,
if it is set to 1, a wait-time of 10 seconds give a _reduction_ in cost of 10 cost points -
the same as riding a bus for 10 seconds.
- `n` the `min-safe-wait-time-factor`. This defines the maximum cost for the logarithmic function
relative to the `min-safe-transfer-time` when wait time goes towards zero(0).
The `f(t)` is created so:
- `f(0) = (n+1) * t0`
- `f(t0) = t0 - a * t0`, so if `a=1` then `f(t0)=0`.
Note that since we are comparing paths where the only difference is the transfers, the effect of
the function `f(t)` lies in the delta between the cost of transfer A for alternative 1 and the cost
of transfer B for alternative 2.
The function is:
```
(n+1) * t0
f(t) = ----------------------- - a * t
1 + n * ln(1 + C * t)
```
where the constant `C = (e - 1.0)/t0`.
Here is a plot with three examples with different values for `n` and `a` which illustrate how the
function look like when the linear, and the logarithmic part is present or not. The blue line have
only the logarithmic part(n=4, a=0), the purple line is a combination (n=2, a=0.5), and the yellow
line have the linear path only(n=0, a=1). The minimum-safe-transfer-time is set to 600s or 10
minutes in this case. Notice that the blue line gots from `f(0)=(n+1) * t0` to `f(t0)=t0` with
delta `n * t0`. The purple line goes from `f(0)=t0` to `f(t0)=0` with delta `-t0`.
