Prohibit parallel rides

Permissions: update_product

In the Prohibit parallel rides section of the tenant settings of a product, you can configure the product feature prohibit parallel rides.

If the product feature prohibit parallel rides is not activated, the following warning message is displayed below the title of this section in Control Center:

Feature not enabled: Changes to the setting(s) below will not take effect unless this feature is enabled

The following fields can be configured.

Adapter for Prohibit Parallel Rides

You can select one of the following options from the dropdown menu.

  • Never. This adapter never prohibits any DRT matching solutions.
  • Scored Public Transport Alternatives. This adapter prohibits DRT solutions based on their score compared with the best-scored public transport alternative. It requires the public transport alternatives feature to be activated; otherwise, it does not suppress any DRT solutions.
  • Time Windowed Public Transport Alternatives. This adapter prohibits DRT solutions within the configured time window around the PTA departure time. It requires the public transport alternatives feature to be activated; otherwise, it does not suppress any DRT solutions.

Scored Public Transport Alternatives

Prohibit parallel rides scoring follows a penalty system. Since the weights are positive, lower-quality solutions result in higher scores. This is because longer waiting and travel times are multiplied by these positive weights and then summed up, penalizing less desirable solutions. See also the weighting of the matching algorithm.

Both the internal on-demand solution and the external public transport solution are scored using the same metrics: waiting time (how many seconds the solution is offset from the request), walking time (how many seconds the passenger has to walk), travel time (how many seconds are spent traveling without walking), overall time (the sum of walking and travel time), and asset change (the number of transport mode changes excluding walks, always 0 for on-demand solutions). On-demand offset and public transport offset are simple scoring offsets that are added to influence the offer in the desired direction.

The scoring weights are set in the product setting:

  • Waiting time weight. The delay, in seconds, from the request to the solution.
  • Walking time weight. The time, in seconds, one needs to walk.
  • Travel time weight. The non-walking travel time, in seconds.
  • Overall time weight. The sum of walking and travel time.
  • Asset change weight. The number of transportation mode changes (excluding walks), always 0 for DRT solutions.
  • DRT scoring offset. Simple scoring adjustment that is added to the final score (drt_score).
  • PT scoring offset. Simple scoring adjustment that is added to the final score (pt_score).

The scores are then calculated as follows:

pt_score = (waiting_time_weight x waiting_time) + (walking_time_weight * walking_time) + (travel_time_weight x travel_time) + (overall_time_weight x overall_time) + (asset_change_weight x asset_change) + pt_offset

and

drt_score = (waiting_time_weight x waiting_time) + (walking_time_weight * walking_time) + (travel_time_weight x travel_time) + (overall_time_weight x overall_time) + (asset_change_weight x asset_change) + drt_offset

The DRT solution is prohibited if it has a higher (penalty) score than the PT solution, so drt_score > pt_score will suppress the match.

If the strategy is to completely suppress DRT if a PT alternative is found, set everything to 0 except for the DRT scoring offset, which can be set to 1. This forces that the drt_score (penalty) is always larger than the pt_score, meaning that the public transport alternative that is found wins.

  • Waiting time weight: 0.0
  • Walking time weight: 0.0
  • Travel time weight: 0.0
  • Overall time weight: 0.0
  • Asset change weight: 0.0
  • DRT scoring offset: 1.0
  • PT scoring offset: 0.0

For arrival-based matching, waiting_time is defined as the difference between the solution’s arrival time and the arrival time requested by the passenger.

This feature is applied at the very end of the matching algorithm. This means that the public transport alternative is compared only with the winning solution.

Time Windowed Public Transport Alternatives

This adapter suppresses a planning list if at least one acceptable public transport alternative (PTA) departs within the configured threshold of the ride reference time.

The following field can be configured when Time Windowed Public Transport Alternatives is selected as the adapter.

  • Time Window Threshold. Defines how close a PTA departure may be to the ride reference time before the planning list is discarded. The default value is 30 minutes. In Control Center, you can select values from 5 minutes to 120 minutes in 5-minute steps.

The ride reference time depends on the ride context:

  • For departure-based rides, this is usually the requested departure time.
  • Otherwise, ioki Platform uses the calculated pickup time of the planning list.

Although the implementation builds a window around the PTA departure time, the practical effect is the same: if the PTA departure and the DRT ride reference time are close enough to fall within the configured threshold, the DRT planning list is prohibited.

Existence of intermodal solutions suppressed DRT-only solutions

When enabled, this option removes every DRT-only solution from a ride’s matching results as soon as at least one intermodal solution exists for the same request. An intermodal solution combines an on-demand (DRT) leg with a public transport feeder journey; a DRT-only solution serves the whole trip on demand. The effect is that, whenever the passenger could be served intermodally, they are only offered the intermodal option and the pure DRT alternatives are discarded.

The suppression is applied during initial matching, as the first step of the prohibit-parallel-rides filter, before the adapter runs. It only takes effect when at least one intermodal solution is actually found; if no intermodal solution exists for the request, no DRT-only solution is removed.

This option runs independently of the prohibit parallel rides product feature. Even if a product does not have prohibit parallel rides activated, enabling this option still suppresses DRT-only solutions when intermodal solutions exist. The prohibit parallel rides feature flag only controls the adapter, not this step.

Because it is an integration between prohibit parallel rides and intermodal journeys, it is only meaningful when intermodal journeys are configured and can produce intermodal solutions. See also extended search space for how this interacts with public transport alternatives.

The skip prohibit parallel rides for rides with validated user location exception does not apply here—it only skips the adapter, so this suppression still runs even for rides with a validated user location.

Skip prohibit parallel rides for rides with validated user location

This option is configured in the product’s Product features section, not in the Prohibit parallel rides tenant settings section.

For activation steps, behavior, and prerequisites, see Skip prohibit parallel rides for rides with validated user location.

When enabled, the prohibit parallel rides adapter is skipped if the ride origin or destination is linked to a validated user location.

If neither requested point is linked to a user location, or the linked user location is not validated, prohibit parallel rides still runs as usual.

This exception applies only to the prohibit parallel rides adapter. It does not override Existence of intermodal solutions suppressed DRT-only solutions when that option is enabled.

For regular ride creation, this exception depends on Preprocess ride requests with snapping user locations in Matching, because that setting creates the user-location link on the requested point.