Location Data Knowledge Base

Data methodologies, and Release schedules.

What Drives Drivetimes?


Calculating Drivetime is a feature of many of the Alteryx Spatial Tools, such as Distance, Trade Area and Find Nearest.  These tools utilize TomTom’s spatial information to obtain the two variables needed to calculate Drivetime: distance and speed.   When it comes to roads, how TomTom calculates distance is easy to visualize since the underlying spatial data can be extracted and displayed using the TomTom Layer Extraction Analytic App (Figure 1).


Figure 1: Road segments for highways in Colorado can be easily displayed using the TomTom Layer Extraction Analytic App.  These segments help visualize the distance component of Drivetime calculations.



Speed data, however, is not as easy to visualize as it is not tied directly to TomTom’s spatial data.  Instead, the key to understanding this aspect of the Alteryx Drivetime calculation is digging into Guzzler, the Drivetime Engine.  Depending on a road’s designated speed limit, it falls into one of eight of TomTom’s Speed Categories.  TomTom’s Speed Category data estimates the ranges of speed at which a car can safely travel on a certain road.  Table 1 (below) shows the categorization of speed ranges.


Table 1: Roads are divided into categories by speed.  Note that Category 1 roads always have a value of 81 mph/131 kph (no matter the actual speed limit) and Category 8 roads always have a value of 5 mph/10 kph.




(miles per hour)


(kilometers per hour)





65 - 80

101 – 130


55 - 64

91 - 100


41 - 54

71 - 90


31 - 40

51 - 70


21 - 30

31 - 50


6 - 20

11 – 30






If you’ve used any of the spatial tools with Drivetime capabilities, you’ve probably noticed that you have the option to calculate Drivetime for three types of traffic conditions: Peak, Off-Peak and Nighttime.  Based on its speed categorization schema, TomTom estimates travel times for each of these traffic conditions by applying a few rules.  Peak traffic conditions use the value of the lower limit of the speed range.  Off-peak traffic speeds are one third (1/3) greater than the lower limit of the range, and Nighttime traffic speeds are two thirds (2/3) greater than the lower limit of the range.  So, if you were traveling on a highway (Category 2 road), the speeds for each traffic condition would be:

Traffic Condition (Speed Category 2)




Speed (mph)





These speed settings are applied to the road network data through an .XML file that can be found in the Guzzler folder where your data is hosted.  Figure 2 shows how this data is stored in the file.  A little known (and fun!) fact is that this file is modifiable.  That is, users can adjust these speed settings (and, consequently, Drivetime outputs) to reflect different traffic conditions.  Ever wonder how quickly Formula 1 racing speeds could get you around Los Angeles?  You could find out with a bit of .XML editing!  If you choose to do this, it is highly recommended that you make a copy of the original Guzzler .XML before making any modifications. That way, you’ll be able to revert back to the original settings if you decide your alternate-reality speeds are not, well, realistic.


Figure 2: TomTom’s Speed Category data are embedded in an .xml file in the Guzzler Engine.  Reading in the file (showing the outer .xml) allows the user to change the values of each speed category.


8 - Asteroid

Good information on this Christine, thanks! A question about being able to utilize the underlying extracted major/minor road files as it would relate to particular DT pathing between points. Is there a way to understand what pathing the algorithm has taken to derive a particular drivetime? I need to be able to expose that path, and do a polyline join of those segments to determine a complete path between multiple points.


We have a use case where we will be performing the best path to take for field personnel among a number of points in a 15km radius area (yes, this is a quasi-travelling salesman algorithm problem), but I'm only concerned with defining that particular point-to-point path. Each of those paths will be unioned together via segment ID's, to create the start to end path.


I'd like to be able to complete with the TomTom subscription we have, but if something like this can be better achieved via a Google API, we can go that route as well.