Generic intermodal routing / mode choice infrastructure

[sebhoerl]

Currently, we have multiple implementations of intermodal trip alternatives. The basic idea is always to perform a routing of [acces mode] + [public transport] + [egress mode] by composing a new RoutingModule that combines existing modules for the individual parts. A varying components of this setup are the interaction points + depending on what intermodal chain is modeled:

• @diallitoz @lvmt-matsim @TSeregina use this for park & ride scenarios where the + above are rail stations with sufficient parking. (car + pt)
• @tkchouaki uses this for shuttle-based first/last mile services (drt + pt), the interaction points are a selection of rail stations
• @diallitoz wants to use it with shared services (sharing contrib + pt), the interaction points are stations with shared vehicle stations
• @balacmi @kaghog are not using this approach, but have a similar setup using SwissRailRaptor

The main components are basically the same in those implementations:

• Routing: Define a composition of existing routing modules for the underlying modes. The composite routing module chooses the potential interaction points. Choosing those interaction points can be hidden behind an interface such that all the use cases above are covered. All other considerations (making the choice deterministic, randomizing the choice, increasing / decreasing the search radius, ...) will be hidden in the implementation of this interface. The composite routing module should hence be defined by. Note that at a later step this could even be completely configuration-based:
  • In the configuration, define a new "intermodal mode" by defining the access/egress mode that will be connected with public transport.
  • In the configuration, define an attribute name that refers to an attribute that is given to all public transport stops that can act as a access/egress point using this new intermodal mode. Such a set-up would cover all the points mentioned above.
• Mode choice: Define a utility estimator, so it can be added to the discrete mode choice. Here, we can also create a composite estimator that sums up the utilities of the individual segments (access, transit, egress). One thing we want to avoid is adding up to many ASCs, so the existing utility estimators may need to get a method getConstant to make sure that we (1) can subtract the constants from the calculated individual utilities, and (2) add a new constant for the intermodal mode to the new alternative. Even this could be configuration-based by simply defining a new intermodal utility estimator and defining which are the base estimators, and by defining the alternative specific constant.
• Constraints: In the case where a chain-based mode is used for access/egress (see P&R above), we also need constraints that make sure that the vehicle is picked up again later during the day. This can be done by extending the existing VehicleConstraints (see thesis of @diallitoz) and this can also be made generic. One issue is to make sure that not only the chain of modes is consistent, but also that the access/egress points are consistent. However, this is something that should be handled on the level of the access/egress point interface. Basically, the condition is that if a trip A to B with a chain-based mode returns (X,*) as access/egress points, then the inverse trip B to A should return (*,X) as access/egress points.

Steps for implementation are:

• Take code from @diallitoz thesis and replace the hard-coded car parts with a generic mode
• Technically, the distinction between car_pt and pt_car is not necessary, we can just have a generic pr mode and the handling fo the correct "direction" of the trip can be handled inside the access/egress interface.
• After, it would be nice to have easy tools in the code to define these modes with all three components (routing, mode choice, constraints)
• And then even later (once this is a bit tested) it would be interesting to be able to do this in configuration