Accurately Calculate Thousands of Cycle Times with a New TravelTime Cycling Model

TravelTime’s cycling model can be used in a number of different ways, from enabling a website user to search locations based on how long it would take to cycle to them, to creating a reachable catchment area based on a maximum cycling time.

We've recently released a brand new version of this model with an upgrade that takes into account elevation changes when calculating cycling times.

This update means that cycling analysis will be more representative of real-world conditions, where cycling up hills is slower than cycling down them.

There are no user updates required to use this new model. As it is already live, the new cycling model will be used whenever a request is made to any of the TravelTime API endpoints that use the cycling transport type. These endpoints are:

Isochrones

• Visualise all reachable locations within a time limit and display this on a map:

Travel time matrix

• Create a matrix of travel times between thousands of origins and destinations:

Routing

• Create A-to-B routes and turn-by-turn directions:

In what ways can I use the new cycling model?

The new cycling model will allow you to get more accurate answers from your location data.

From a TravelTime Search perspective, this means you can present your website or app users with more relevant results. For example, if a user were to search for jobs within a 30 minute cycle of where they live, they’d naturally want this to include the time differences of cycling uphill and downhill.

For TravelTime Analytics, the cycling model provides more reliable data to inform key business decisions. For example, for a food delivery company looking at where to locate dark kitchens to service their customers with deliveries by bike, knowing how hills will impact delivery times will be crucial to smoother operations.

How does the new cycling model work?

Previously, the cycling model assumed a constant average speed, regardless of elevation changes. So the same speed could be achieved cycling uphill as with cycling downhill.

Now, we've incorporated an elevation dataset into the cycling model, and the assumed cycling speed is modified based on the associated change in elevation.

When cycling on the flat, the assumed average cycling speed is still 20 km/h. But now, when travelling uphill, this average speed decreases. The steeper the hill, the slower the cycling speed - right down to a slow walking pace of 5 km/h.

Similarly, when travelling downhill, the average speed increases - with an upper limit of 60 km/h.

What elevation data is used in the new cycling model?

We use two different source datasets for the elevation data:

1. For locations south of 60N, we use a public dataset from the SRTM

1. For locations north of 60N (where the SRTM stops), we use the ArcticDEM dataset (DEMs provided by the Polar Geospatial Center under NSF-OPP awards 1043681, 1559691, and 1542736)

What does the new model look like in practice?

The impact of the new cycling model can be seen in several ways, but the simplest visualisation is to compare cycling isochrones (catchment areas based on a maximum travel time) in hilly areas.

The two examples below both show a 1-hour cycling isochrone for trips departing from the yellow marker in blue and a 1-hour cycling isochrone for trips arriving at the yellow marker in red. The pink is reachable by both.

In both cases, cycling away from the starting location involves going uphill. As a result, the area that is reachable within a 1-hour cycle is smaller than if you were cycling in the other direction, i.e downhill.

How to get started

The new TravelTime cycling model is live and available to use immediately.

To run your own cycling time analysis using this new elevation-based model, sign up for a free API key here. To learn what more you can do with the TravelTime API, check out our documentation.