Public transport alternatives

Permissions: update_product

In the Public transport alternatives section of the tenant settings of a product, you can configure the product feature public transport alternatives.

If the product feature public transport alternatives 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 public transport alternatives

Select the public transport adapter used to calculate alternatives. The APIs are called using information from the ride request, including the origin place, optionally the time if origin-based booking is active, the destination place, optionally the time if destination-based booking is active, and the time zone of the requested points.

Number of persisted public transport alternatives

This defines how many public transport alternatives ioki Platform asks the configured PTA adapter to return for each query. The value can be set from 1 to 5 and defaults to 1. Some adapters may apply their own minimum, and if fewer matching alternatives are available, the adapter may still return fewer results.

For end-to-end public transport alternatives, this limit applies to the single PTA query for the requested journey.

For feeder-based intermodal journeys, the same limit is applied to each feeder-station query. This means the total number of persisted public transport alternatives can be higher than the configured value if multiple feeder stations are checked.

After fetching, ioki Platform filters, scores, and ranks the alternatives. In this context, persisted means the alternatives are kept in the system for further processing. An alternative can therefore still be persisted even if it is later rejected by the filtering rules and not offered as a valid result.

Ranking strategy

You can choose a ranking strategy to define how public transport alternatives are ordered.

  • Vendor. Uses the ranking provided by the third-party service, for example, HAFAS. This reflects the vendor’s own logic for sorting results.
  • Relevance Score. Ignores the vendor’s order and re-ranks the results internally using the relevance score.

The default is Vendor. Use vendor ranking if the original order from the adapter should be preserved. If Relevance Score is selected, the alternatives are re-evaluated to prioritize those most relevant to the user’s request: the relevance score is a penalty score, so alternatives with the lowest score are ranked first.

Use realtime data (only takes effect if vendor / PTA adapter supports this)

If enabled, supported PTA adapters use realtime data instead of planned data. Specifically, ioki Platform fetches realtime data from the PTA vendor, if available, when searching for a PT trip. HAFAS, MENTZ, NAVITIA, and VAO respect this parameter.

This parameter should not be understood as a mechanism that recalculates or refreshes times of public transport connections in case of delays. For instance, if a user’s intermodal ride includes a PT leg followed by a DRT shuttle and the PT vehicle experiences an unscheduled delay while en route, the DRT leg remains unchanged. There is no automatic rematching or rescheduling of the pickup time. In such cases, the delay is handled similarly to a DRT-only booking: the driver waits for a few minutes and then calls the user to clarify the situation.

Reestimate walking time returned by the vendors adapter

When this is enabled, ioki Platform adjusts walking times by calculating the distance between coordinates and assuming an average walking speed of 3 km/h for a typical adult. The intention behind this setting is to present public transport alternatives that are more reasonable and accurate.

Reverse geocode locations returned by the vendors adapter

HAFAS, and potentially other PTA adapters as well, may return geographical coordinates as the location name. The full PT travel chain is calculated, but no proper reverse geocoding is done by HAFAS. To address this, this option enables reverse geocoding for PTA solutions. When this setting is enabled, ioki Platform intercepts the intermediate results from the PTA adapter and reverse geocodes them.

Disable (end-to-end) PTA calculation for intermodal rides

When used with the intermodal journeys feature, PTA automatically finds intermodal journeys and complete end-to-end public transport alternatives by default. With this option, you can disable the latter. In that case, the activated PTA feature finds intermodal journeys only via feeder stations, and users do not see end-to-end public transport alternatives as a solution. Because the prohibit parallel rides adapter compares an on-demand solution against the end-to-end public transport alternative, disabling this calculation leaves the adapter with nothing to compare against for intermodal rides, so it can no longer prohibit them. Intermodal solutions are still produced, and the adapter still works for regular DRT-only rides.

Blocklist

Blocklist rules are used to exclude certain public transport alternatives (PTAs) from consideration. If any rule matches any leg of a PTA, the entire alternative is discarded. This is useful for filtering out services from specific operators, transportation types, or other unwanted characteristics.

Each blocklist rule must be defined on its own line in the following format:

[property_name]:[search_string]

Valid property names are:

  • name
  • type
  • line
  • operator
  • transportation_type

The values for transportation_type may change over time and per vendor, but common values are long_distance_train, regional_train, suburban_train, underground, tram, and bus.

A rule matches if any leg in the PTA uses a public transport product where the specified property exactly matches the given search string after normalization. Matching is case-insensitive.

A PTA consists of several legs—a walking leg, then a bus leg, a regional train leg, and another walking leg. The product data for the regional train leg might look like this:

{
"name" => "RB 16410",
"line" => "16410",
"type" => "Regionalbahn",
"operator" => "DB Regio",
"transportation_type" => "regional_train"
}

The following blocklist rules would all match this leg and cause the PTA to be discarded:

name:rb 16410
line:16410
type:regionalbahn
operator:DB Regio
transportation_type:regional_train

You can define multiple rules for the same property.

operator: ACME LTD.
line: 12
line: 155

This configuration excludes any PTA that includes a leg where the operator is “Acme Ltd.” or the line is “12” or “155”.

Before comparison, both the rule’s search string and the PT product data are normalized:

  • Leading and trailing whitespace is trimmed
  • Multiple consecutive spaces are collapsed into one

Filtering options

The filtering options represent minimum quality standards that a PT alternative must meet in order to be considered valid. PT solutions violating at least one of the conditions are discarded.

  • Maximum waiting time acceptable for public transport alternatives. The maximum time difference between the request time and the alternative departure or arrival time. Selectable from 0 to 60 minutes, in 1-minute steps.
  • Maximum walking time acceptable for public transport alternatives. The maximum time one needs to walk. Selectable from 0 to 60 minutes, in 1-minute steps.
  • Maximum travel time acceptable for public transport alternatives. The maximum non-walking travel time. Selectable from 0 to 120 minutes, in 1-minute steps.
  • Maximum travel time compared to DRT option acceptable for public transport alternatives. The maximum allowed ratio between the non-walking travel time of the PT option and the DRT direct travel duration. Selectable from 1.0 to 5.0, in steps of 0.1.
  • Maximum overall time acceptable for public transport alternatives. The maximum sum of walking and travel time. Selectable from 0 to 120 minutes, in 1-minute steps.
  • Maximum overall time compared to DRT option acceptable for public transport alternatives. The maximum allowed ratio between the overall time (which includes both walking and non-walking travel time) of the PT option and the DRT direct travel duration. Selectable from 1.0 to 5.0, in steps of 0.1.
  • Maximum number of asset changes acceptable for public transport alternatives. The maximum number of changes between non-walking public transport legs. Selectable from 0 to 5.

The DRT direct travel duration (direct_routing_duration) is the estimated direct route time for the ride request, in seconds. It is calculated from the ride’s origin and destination using the product’s configured ride direct-routing adapter, routing profile, and driving time-scaling factor.

The filtering options are defaulted to None. After the product feature public transport alternatives is activated, one or more filtering options should be configured. All filtering options can be left as None; however, this would mean there are no minimum quality standards in place, potentially allowing low-quality PT solutions to be considered valid.

Discard Public Transport Alternatives that are walking only

A walking-only alternative is one the PTA adapter returns that has no public transport travel time—the routed journey is entirely on foot, with no transit leg. When this option is enabled, such alternatives are rejected during PTA filtering and are not offered as a valid public transport alternative.

This setting is enabled by default, on the basis that an alternative with no transit leg is not a meaningful public transport option. Disabling it lets walking-only alternatives pass the filter and be considered alongside genuine transit alternatives.