Hello. How can we help you?

How to use the pt_change_delay parameter

An overview of how to use the pt_change_delay parameter, both through the TravelTime API and supported plugins

Contents

What pt_change_delay is and how it works

Use cases

How to use pt_change_delay in practice

Further information

What pt_change_delay is and how it 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:

Screenshot 2021-07-14 at 14.45.44

The orange dotted 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:

The pt_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 pt_change_delay, it would be possible to catch this train. However, if pt_change_delay was set at 2 minutes, you would no longer be able to catch this onward train.

Use cases

The range of potential use cases for the pt_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 9am, with a 3-minute pt_change_delay. The area in red is the additional reachable area when the same analysis is run with no pt_change_delay.

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 pt_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 everyday, 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 pt_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:

In contrast, with a pt_change_delay of 5 minutes, the route is slightly slower at 82 minutes, but only involves one public transport leg:

How to use pt_change_delay in practice

The pt_change_delay parameter can be used for any of the core endpoints or tools of the TravelTime API. These are:

  1. Time Map: calculating reachable areas based on journey time (‘isochrones’)
  2. Time Filter: calculating the journey times between 1000’s of origins and destinations 
  3. Routes: calculating A to B routes and corresponding turn-by-turn directions

These can be accessed either directly through the API or one of the GIS plugins that we support. Details of each of these can be found below.

TravelTime API

The pt_change_delay parameter 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:

 

{

 "departure_searches": [

   {

     "id": "5 minute change delay",

     "coords": {

       "lat": 51.530410,

       "lng": -0.101010

     },

     "transportation": {

       "type": "public_transport",

       "pt_change_delay": 300

     },

     "departure_time": "2021-07-16T07:00:00Z",

     "travel_time": 1800

   }

 ]

}

QGIS plugin

If using the QGIS plugin, the pt_change_delay field 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 

ArcGIS Pro add-in

If using the ArcGIS Pro add-in, the pt_change_delay field 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

Alteryx macros

If using any of the TravelTime macros in Alteryx, the pt_change_delay field 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

Further information

The pt_change_delay parameter is one of a number of ways in which analysis using the TravelTime API can be precisely configured to meet the needs of real world applications.

If you'd like to find out more, please get in touch at support@traveltime.com