Contents
Today we're announcing the release of a new request parameter that allows users of the TravelTime API to limit the number of changes involved in a public transport journey.
The ability to configure a limit on the number of public transport changes enables users to fine-tune the searches they are making, and model real-world use cases more effectively.
For example, when running an employee commute analysis, you may want to select routes that involve fewer changes — and this new parameter allows just that.
The new parameter is called max_changes and is available through any of the core TravelTime JSON API endpoints.
How it works
If you're new to TravelTime, here's a quick summary of what we do:
- The TravelTime API allows you to calculate travel times to many locations within milliseconds. With multi-modal transport data live in over 100 countries, we can instantly return thousands of travel times for public transport, driving and other transport modes.
- Isochrones:You can use the TravelTime API to visualise all reachable locations within a time limit and display this on a map.
- Matrices:Create a matrix of travel times between thousands of origins and destinations.
- Routes:Create A to B routes for single and combined transport modes.
The logic of themax_changesparameter works in exactly the same way for the three TravelTime JSON API endpoints. It simply sets an upper limit for the number of changes between the public transit stages of a journey.
This only applies to transport types that involve public transport (not our driving, walking, or cycling modes) and is only applied to changes between public transport legs. I'll illustrate this with a few examples, showing in each case whether the possible route would be allowed or not:
| Possible Route | No max_changes | max_changes = 1 |
| walk > bus > walk | Allowed | Allowed |
| walk > bus > walk > bus > walk | Allowed | Allowed |
| bus > walk > train > walk > bus | Allowed | Not Allowed |
| walk > train > metro > bus | Allowed | Not Allowed |
How to configure the parameter
If you haven’t already, you’ll need to sign up for a TravelTime API key here.
Once you're up and running with the API, you can now configure themax_changesparameter.
For all three of the primary TravelTime JSON API endpoints, the newmax_changesparameter should be added under thetransportationobject. Within themax_changesobject there is a boolean field for whether it should be enabled or not, and an integer field for the maximum number of changes allowed.
See it in action
Let’s consider a typical commute in London, from Stratford New Town to Trafalgar Square, where we want to calculate the public transport journey to arrive at 9am on a weekday.
We’ll run three iterations using the Routes endpoint of the TravelTime API, firstly withmax_changesset tofalse, and then with it set totruewith two different values.
1. max_changes =false
This request will return the fastest possible route, regardless of the number of changes involved. The request body is shown below:
The chosen route is:
This route has a total journey time of 44 minutes and involves two changes (bus > underground > underground)
2. max_changes =true, limit =1
This request will return the fastest possible route that involves a maximum of one public transport change. The request body is shown below:
The chosen route is:
This route has a total journey time of 52 minutes and involves one change (train > underground).
3. max_changes =true, limit =0
This request will return the fastest possible route that doesn’t involve any public transport changes. The request body is shown below:
The chosen route is:
This route has a total journey time of 70 minutes and involves no changes (just one bus and walking).
As these examples show, by restricting the allowed number of public transport changes, we get routes with fewer changes but a longer overall journey time. The third example with no changes allowed may not be one that someone would choose in reality, but it’s certainly possible that a commuter would opt the second route (1 change, and 52 minutes) over the first route (2 changes, and 44 minutes).
Get started
The newmax_changesparameter allows the TravelTime API to be used in an even more configurable way.
By limiting how many changes are allowed as part of a public transport journey, analysis can be adjusted to take into account passenger preferences for simpler routes that may not always be the quickest. This is particularly applicable when looking at journeys that may be taken regularly and at busy times of the day, such as morning and evening commutes.
To learn more about what you can do with the TravelTime API,visit our documentationor get in touch.
To test the TravelTime API for your project,sign up for a free API key here.