The TravelTime public transport routing algorithm is built to optimise for time — it will always find the fastest route between locations. However, in some cases, the fastest route may not be the only factor you'll want to consider.
Public transport journeys often involve several different legs and when looking at something like employee commutability, you may also want to consider the number of changes involved in a journey. A slightly slower route that involves fewer changes may be preferable to the fastest route with lots of changes.
Finding the optimal public transport route
To address this case of optimal routing based on multiple criteria (minimum travel time and minimum changes) users of the TravelTime API or our GIS plugins can set an additional time penalty to be applied each time a public transport change is required within a journey.
The algorithm, accessed through our public transport parameter, will still find the fastest route based on shortest journey time. However, by increasing this time penalty for changes, routes with fewer changes will naturally become more likely.
This article will explain exactly how this parameter works, how it can be configured, and outline some real-world examples where it is particularly useful.
How the TravelTime public transport parameter works
Our public transport models already take into account the walking time required to move between different stops or platforms where needed. For example, the journey below involves changing platforms at Green Park Underground Station in London:
A walking change (in red) between two platforms during a public transport journey
The dotted red line illustrates the walking leg that the public transport model knows is required to get from one platform to another. This has an associated walking time, as shown in the associated route information below:
Step-by-step breakdown of the public transport journey, showing the time taken to change trains (128 seconds or roughly two minutes)
The public transport change delay parameter adds an extra time penalty in addition to this walking time required to change from one train to another.
For example, let’s say your train leaves at 10:35 am. You arrive at the station at 10:30 and there is a 4-minute walk to the next platform. Without setting any change delay, it would be possible to catch this train. However, if the change delay was set at 2 minutes, you would no longer be able to catch this onward train.
Common use cases
The range of potential use cases for the public transport change delay parameter is extensive. Here are just a couple that we have seen put to good use by existing customers.
1. Calculate journey times for lower-mobility travellers
Some use cases require journey times and catchment areas to be calculated for lower-mobility travellers. For example, this could be evaluating the accessibility of public services for wheelchair users who may need a few more minutes to board a train.
In this case, being able to add this additional boarding time into the analysis allows it to be much more tailored to the specific scenario.
For example, the map below shows the area in blue that is reachable within a 1-hour public transport journey of a Lower Manhattan location, arriving at 9 am, with a 3-minute change delay. The area in red is the additional reachable area when the same analysis is run with no change delay.
The difference in reachable area between journeys with no change delay (red) and those with a 3 minute change delay (blue)
2. Commuter-friendly routing
The algorithms we’ve built at TravelTime always optimise for the fastest journey time. However, in some scenarios there may be other factors that need to be taken into account, such as the number of changes required as part of a public transport journey.
Although the models always select routes based on shortest journey time, the change delay parameter can be used to nudge them towards selecting routes with fewer changes. This may be particularly useful when running analysis around employee commutes. If having to commute every day, it’s likely that an employee may choose a public transport route that is slightly slower but involves fewer changes.
To illustrate this difference, the image below is an example of the suggested route for a morning commute between two locations in Paris. With no change delay, the route involves four different public transport legs — bus, then train, then underground train, then bus again — with a total travel time of 68 minutes:
The public transport journey with no change delay applied
A breakdown of the public transport journey with no change delay applied
In contrast, with a change delay of 5 minutes, the route is slightly slower at 82 minutes, but only involves one public transport leg:
The public transport journey with a 5-minute change delay applied
A breakdown of the public transport journey with a 5-minute change delay applied
How to configure the public transport parameterThe public transport change delay parameter can be used for any of the core endpoints or tools of the TravelTime API. These are:
- Time Map: calculating reachable areas based on journey time (‘isochrones’)
- Time Filter: calculating the journey times between thousands of origins and destinations
- Routes: calculating A to B routes and corresponding turn-by-turn directions
The API parameter is called ‘pt_change_delay’ and comes under the ‘transportation’ parameter in the request. Below is an example of a Time Map request with a delay of 300 seconds (5 minutes) applied:
If using the QGIS plugin, the field is called ‘change delay’ and can be found under the Advanced Parameters of any of the Advanced tools in the Processing Toolbox.
For example, in Routes Advanced:
Note: this value is in seconds
If using the ArcGIS Pro add-in, the field is called ‘Public Transport Boarding Time’ and can be found under the Advanced Parameters of any of the Advanced tools in the Catalog Pane. For example, in Time Map Advanced:
Note: this value is in minutes
If using any of the TravelTime macros in Alteryx, the field is called ‘Time needed to board public transport vehicle’ and can be found in the Advanced settings in the configuration panel. For example, in the Travel Time Matrix macro:
Note: this value is in minutes
The public transport change delay parameter is one of several ways in which analysis using the TravelTime API can be precisely configured to meet the needs of real-world applications.
Specifically, it allows an extra time penalty to be applied whenever a change of public transport is required on a journey. This helps solve the problem of trying to optimise by both shortest journey time and fewest changes.
Particular use cases where this is commonly applied include analysis of lower-mobility travellers who require additional time to board public transport, as well as commute studies where employees are more likely to choose a slightly longer journey that involves fewer changes.
The parameter can be used both when working with the TravelTime API directly, or through any of the GIS plugins that we support: QGIS, ArcGIS, and Alteryx.
If you’d like to test our public transport parameter, sign up for a free trial.
Want to learn how to use TravelTime for your project? Just contact us below.