Intermodal journeys

Combine DRT with public transport in a single journey

The product feature intermodal journeys allows users to plan trips that combine two or more modes of transportation within a single journey. For instance, if a user wishes to travel from point A to point B and DRT service is available only near point A, they might receive a ride offer involving a short shuttle trip from point A to a nearby public transport station. From there, they would transfer to a public transport vehicle, such as a tram operated by the local transit agency, which would take them to their final destination at point B.

Definition of intermodal

Intermodal transport combines two or more modes of transportation within a single journey. It requires travelers to switch between different vehicles, also referred to as assets.

General overview

With this feature, users can request rides not only within the DRT area, but also extend them to an intermodal area. More specifically, users can request rides to, from, and within the DRT area, with the condition that at least the origin or destination must be within the DRT area. Rides cannot be processed solely within the intermodal area.

If either the start or destination is outside the DRT area but within an intermodal area, the user may be offered a DRT ride combined with public transport — that is, an intermodal ride — provided a DRT shuttle is available. The user may also be offered an “end-to-end” public transport journey, depending on the product’s settings.

If both the start and destination are within the DRT and intermodal areas, the user may be offered an intermodal ride, if available. It’s also possible to receive intermodal solutions when the origin and destination are located in different DRT sub areas.

The system searches for the optimal route using public transport feeder stations (major PT transfer points) where passengers switch between DRT and public transport. PT feeder stations can be defined in the station settings.

If an intermodal ride is selected, the user can book the DRT portion of the trip.

Intermodal pooling

The DRT portion of an intermodal trip can be shared with other passengers’ requests, as it is handled exactly the same way as every other DRT ride on the platform. This means that two different passengers with separate ride requests can be combined into the same shuttle for the DRT portion of their respective rides. Intermodal rides can be pooled with DRT-only rides or with other intermodal rides, whether they follow the same or reverse leg order (PT→DRT or DRT→PT).

Intermodal pooling

In this scenario, Denny and Mitja are pooled together in the same DRT shuttle.

Denny’s journey:

  • Origin: Montiola Wasserfall
  • DRT shuttle pickup: 12:10
  • DRT shuttle dropoff: Ludesch Bahnhof at 12:20
  • Public transport departure time: Ludesch Bahnhof at 13:15
  • Public transport arrival time: Bregenz Bahnhof at 14:14

Mitja’s journey:

  • Origin: Gasthaus Blumenegg
  • DRT shuttle pickup: 12:13
  • DRT shuttle dropoff: Ludesch Bahnhof at 12:20

Denny books a trip from Montiola Wasserfall to Bregenz. His journey starts with a DRT shuttle pick-up at Montiola Wasserfall at 12:10. The shuttle then heads to Gasthaus Blumenegg to pick up Mitja at 12:13. Both passengers are now in the same shuttle, heading towards Ludesch Bahnhof. The shuttle drops off both Denny and Mitja at Ludesch Bahnhof at 12:20. From there, Denny continues his journey using public transport, whereas Mitja’s journey ends at Ludesch Bahnhof.

This results in the following task list for the DRT shuttle:

  • Pick up Denny at Montiola Wasserfall
  • Pick up Mitja at Gasthaus Blumegg
  • Drop off Denny Ludesch Bahnhof
  • Drop off Mitja Ludesch Bahnhof

Intermodal matching

The following four numbered sections provide a more technical description of how the core performs intermodal matching.

1. Public transport alternatives (PTAs)

The product feature public transport alternatives (PTA) serves as a foundation for intermodal journeys. With intermodal, there are three types of PTAs.

  1. End-to-end PTA: This alternative provides a full public transport option from start to finish, covering the entire journey with no need for a demand-responsive transport (DRT) service.
  2. First-mile (feeder) PTA: This alternative allows passengers to get to the DRT area using public transport. It’s like a feeder trip to “jump into” the DRT area.
  3. Last-mile (feeder) PTA: This alternative allows passengers to leave the DRT area to reach their final destination using public transport. It’s like a feeder trip to “jump out of” the DRT area.

The last two types address “feeder” situations, where public transport complements the DRT service for part of the trip.

While the term PTA still means “public transport alternative,” it not only refers to an end-to-end PTA that fully replaces a DRT ride, but also applies to public transport options for the first or last mile.

2. Creation of an intermodal ride

During the creation of a ride, the origin and destination requested points are classified. Each requested point is assigned a service type based on its location:

  • Unserved. The point is not served because it’s either outside the service area or within an unserved area.
  • PT. The point is within the intermodal area.
  • DRT. The point is within the DRT area.
  • DRT, PT. The point is within both the DRT and intermodal areas.

A ride is intermodal if either the origin or destination has the service type of PT.

Feeder stations

After a ride is initially created and matching begins, if it’s an intermodal ride, the core finds respective feeder stations. It determines possible origin feeders (“first-mile PTA feeder stations”) and destination feeders (“last-mile PTA feeder stations”).

A feeder station qualifies only if it carries the matching feeder flag: PT to DRT feeder for a first-mile feeder, or DRT to PT feeder for a last-mile feeder. Among the qualifying stations, for each trip end that touches public transport the core selects up to two: the qualifying station nearest that end itself, and the qualifying station nearest the opposite end of the trip. The nearest station overall can therefore be skipped if it does not carry the required flag. This pairing lets the core build both a DRT-heavy variant, with a short public transport hop near one end, and a public transport-heavy variant, with a short DRT hop near the other end.

Feeder stations are selected before ride variants are built. The intermodal settings do not change this selection; they operate later, on the variants built from the selected feeders.

Following this, the PTA search begins. Since the DRT search and the PTA search run asynchronously, we need to estimate the effort required to initiate the PTA calculation independently. If they ran in parallel, each component would need to account for the other’s effort, but that’s not the case here. Instead, the PTA search always occurs before the DRT search.

There are two request modes for rides:

  1. Departure-based: The passenger specifies a desired departure time.
  2. Arrival-based: The passenger specifies a desired arrival time.

Considering these request modes and the two different types of intermodal PTAs (first-mile feeder or last-mile feeder), the core needs to consider four cases for intermodal matching.

 First-mile feederLast-mile feeder
Departure-basedDirect calculation possible: The passenger plans to depart at 10:00 AM from a location outside the service area. To achieve this, the PT provider (for example, HAFAS) is queried for a PT connection departing at 10:00 AM from the start. Upon receiving the PT connection, its arrival at the feeder (for example, 10:20 AM) is determined. The DRT core is then queried with a start time of 10:20 AM at the feeder towards the destination.Estimation required: The passenger plans to depart at 10:00 AM from a location within the service area. It is necessary to estimate the approximate duration of the DRT ride from the start to the feeder, for example, 20 minutes. To do this, the platform calculates a best-case estimated driving duration for that DRT leg and multiplies it by 1.3. Subsequently, the PT provider (for example, HAFAS) can be queried for a connection departing from the feeder around 10:20 AM (10:00 AM plus the estimated DRT duration).
Arrival-basedEstimation required: The passenger plans to arrive at 11:00 AM at a location within the service area. It is necessary to estimate the approximate duration of the DRT ride from the feeder to the destination, for example, 20 minutes. To do this, the platform calculates a best-case estimated driving duration for that DRT leg and multiplies it by 1.3. Subsequently, the PT provider (for example, HAFAS) is queried for a connection arriving at the feeder around 10:40 AM (11:00 AM minus the estimated DRT duration).Direct calculation possible: The passenger plans to arrive at 11:00 AM at a location outside the service area. To achieve this, the PT provider (for example, HAFAS) is queried for a PT connection arriving at 11:00 AM at the destination. Upon receiving the PT connection, its departure from the feeder (for example, 10:40 AM) is determined. The DRT core is then queried with an arrival time of 10:40 AM at the feeder.

The PTA search supports these four cases. For each trip end that touches public transport, it queries up to two qualifying feeder stations—the one nearest that end and the one nearest the opposite end of the trip (see Feeder stations above). A selected feeder produces a ride variant only when the PT provider returns a connection for it, so a feeder with no usable public transport connection yields no variant.

After the PTAs are found, the core starts the DRT search.

When no ride variant is built

An intermodal ride is served through ride variants—the wrapper the matching core works on. A variant only exists when there is a workable way to serve the ride:

  • a DRT-only variant, which requires both ends of the ride to lie inside the DRT area, or
  • a feeder variant, which requires at least one acceptable feeder connection (see Feeder stations). Feeder connections that the PTA search rejected for quality reasons—for example waiting or walking times that are too high—do not count.

If one end of the ride lies outside the DRT area, a DRT-only ride is not possible. If, on top of that, no acceptable feeder connection is found, then no ride variant is built at all.

With no variant, there is no station at which to switch between public transport and DRT, so the matching core has nothing to work on: no vehicle is searched for and no solution is produced. This is not the same as a normal failed match—the core did not run through vehicles and reject them; there was simply no intermodal solution to match.

In the ride’s matching logs (visible to Super Admins), this appears as the message:

No ride variant was built. This can happen if a ride has an intermodal setup, but we could not find suitable feeder-PTAs.

How intermodal journeys interact with prohibit parallel rides

The product feature prohibit parallel rides has a setting, Existence of intermodal solutions suppressed DRT-only solutions, that ties the two features together. When it is enabled and at least one intermodal solution exists for a request, every DRT-only solution is removed, so the passenger is offered only the intermodal option. This step runs independently of the prohibit parallel rides feature flag and independently of end-to-end public transport alternatives. For the full behavior and configuration, see Existence of intermodal solutions suppressed DRT-only solutions.

Limitations of this feature

Itemized below is a non-exhaustive list of limitations of this feature.

  1. This feature can only be used in products that have stations and therefore use station-based matching. While hybrid-based matching is also suited for intermodal journeys, address-based matching is not supported.

  2. PT connections are offered only before and after a DRT trip, for example:
    • 🚗 DRT → 🚉 PT or
    • 🚉 PT → 🚗 DRT.

    The PT portion of the journey could include transfers, such as:

    • 🚗 DRT → 🚇 Subway (U-Bahn) → 🚊 Tram or
    • 🚇 Subway (U-Bahn) → 🚊 Tram → 🚗 DRT.

    However, complex combinations such as

    • 🚗 DRT → 🚗 DRT,
    • 🚗 DRT → 🚉 PT → 🚗 DRT, and
    • 🚉 PT → 🚗 DRT → 🚉 PT

    are not possible because this would require a complete rewrite of the matching core.

  3. The maximum number of transfers is limited to four. This corresponds to no more than five modes of transport including DRT.

  4. Long-distance trains are not included even if the intermodal area includes stations that have long-distance connections.

  5. We do not offer any special connection guarantee (“Anschlusssicherung”) for PT hops. The platform retrieves planned data from the respective PT adapter and uses it for matching. However, for DRT to PT connections, we use arrival-based matching and thus the connection is secure if there are no unforeseen delays. Additionally, it is possible to define extra buffer time for changeovers in the Intermodal Settings.

    If a PT vehicle is delayed, PT times are not recalculated. If a user is late due to their PT connection, it is treated the same as any other reason for lateness. In such cases, the usual process should be followed, as with a regular DRT ride: the driver can call the passenger if they are not at the pickup point on time.

Activate this feature

Roles: Super Admin

  1. Navigate to the management settings of the product.
  2. Select the checkbox Intermodal journeys.
  3. Select Save.

As mentioned, the product feature public transport alternatives (PTA) serves as a foundation for intermodal journeys. Therefore, this also must be activated.

If HAFAS is used, geographical coordinates from the PT feeder stations are not shown in ioki Passenger App correctly. Therefore, the PTA option Reverse geocode locations returned by the vendors adapter must be enabled in this case.

Note that reverse-geocoding works only with the routing provider HERE.

If MENTZ, Navitia, or VAO are used, reverse geocoding is not necessary.

When used with the intermodal journeys feature, PTA automatically finds intermodal journeys and complete end-to-end public transport alternatives by default. With the option disable (end-to-end) PTA calculation for intermodal rides, you can disable the latter, meaning the activated PTA feature will only find intermodal journeys via feeder stations, and users will not see end-to-end public transport alternatives as a solution.

The prohibit parallel rides adapter compares an on-demand solution against the end-to-end public transport alternative. When you disable end-to-end PTA calculation for intermodal rides, that alternative no longer exists, so the adapter can no longer prohibit those intermodal rides. This affects only the adapter: intermodal solutions are still produced, the setting Existence of intermodal solutions suppressed DRT-only solutions still applies (see How intermodal journeys interact with prohibit parallel rides), and the adapter still works for regular DRT-only rides.

Configure this feature

This feature can be configured within the section Intermodal Settings in the management settings of a product.

After feature activation, Product Admins must perform two steps to ensure users receive rides that include intermodal journeys.

  1. Create an intermodal area. As described in the general overview, the intermodal area is the larger area that surrounds the DRT area. Draw it so that it is larger than the DRT area and fully encloses it, with the entire DRT area sitting inside the intermodal area. We recommend limiting the number of points in the GeoJSON file to a maximum of 1,000.

  2. Define PT to DRT feeder and/or DRT to PT feeder stations. These options are shown on stations if the product feature intermodal journeys is activated. We recommend using existing public transport stations as feeder stations. If no feeder stations are defined, intermodal journeys will not be returned as possible solutions for ride requests.

Where to place feeder stations

Feeder stations are selected by proximity to the ends of the trip (see Feeder stations). To serve a given corridor, place qualifying feeders near both ends of the trips you want to cover: a feeder near the DRT-area end enables a short-shuttle, long-public-transport option, and a feeder near the far end enables a long-shuttle, short-public-transport option. Two conditions decide whether a feeder is actually used:

  • Direction—flag the station DRT to PT feeder for trips leaving the DRT area, PT to DRT feeder for trips entering it, or both. A station is only considered for the direction it is flagged for.
  • Public transport service—a feeder produces an option only when the public transport provider returns a connection from it toward the other end of the trip. A feeder with no usable connection is skipped, even if it is the closest station to that end.

Product Admins can modify the configuration at any time, such as by adding new stations and designating them as intermodal feeder stations.