Is Travel Time Reliability Data Reliable?

Why your State Department of Transportation should look carefully at their federally procured Travel Time Data

8 min readSep 25, 2020

In another article titled “Data Analysis for the Non-Analyst”, I showed how an inexperienced individual can still discover insightful information from travel time data.

Now, I will show how an individual or entity (such as a State DOT) can use the same workflow and dataset to answer questions like:

How reliable is the Travel Time Data?
Does cleaning the data affect the measures for business units?
How can business units prioritize projects accordingly?

Sections:

How to assess Reliability of your Travel Time Data
How to Clean and Transform your Travel Time Data
How to assess Measures for Business Unit Planning

Quick background:

The data is comprised of the following fields (columns):

tmc_code
measurement_tstamp
speed
average_speed
reference_speed
data_density

The tmc_code is a sort of station (in fact, raw probe) that records a number vehicles (data_density) during different timeframes (measurement_tstamp) at certain speeds (speed, average_speed, reference_speed). The amount of time it takes to travel the segment that the tmc_code is recording is travel_time_seconds.

To run the notebook, you’ll need these packages:

Required Packages:

Optional Packages:

The first question to ask is:

How reliable is the Travel Time Data?

How to assess Reliability of your Travel Time Data

Even if you don’t know this data or dataset very well, it’s not difficult to become more familiar

There’s a few things to note:

It’s a fairly big dataset (nearly 14 million rows in the data used here), so inefficient processing will easily become a nuisance
It has some missing values for two columns which could make certain transformations of the data difficult.
The field travel_time_seconds has an unusually high Standard Deviation (std), then an extremely large max value (nearly 2000 times larger than the 75 percentile)

This is probably also a good time to mention a handy tool called pandas-profiling

Pandas-profiling create an interactive output as a GUI to explore your data

Pandas-profiling noticed the same issues that were stated above and makes it easily explorable.

Because of the high maximum value and standard deviation in the travel_time_seconds, we can already assess that something may not be right. We can assume that not many roads take 274385.88 seconds (or ~76.22 hours) to traverse.

In Alaska, the longest road is the Dalton Highway, which is 414 miles and takes about 12 hours to drive (approximately).

The longest TMC segment (which is on the Dalton) is ~282 miles (length in miles present in other data).

So something is amiss. But how “amiss” is it?

There are a few ways that I’m aware of to approach and address outliers —

But first, it would make sense to attempt to verify how substantial this issue may be:

for severity (how spread out are the values?)
for prevalence (how many TMC’s have this issue?)

A check among our dataset to identify the outliers will show that there are about ~121,000 row records among 388 TMC’s that would fall into the dataset’s outer distribution.

About 31 percent of our TMC’s have some amount of these outlier values, and quite a few of them have several thousand. This amount is considerable enough to require some approach to address them.

The second question to ask is:

Does cleaning the data affect the measures for business units?

How to Clean and Transform your Travel Time Data

There is too much spread between outliers that are most likely erroneous. These unrepresentative values could be misconstruing the measures, targets, and the baseline for setting metrics.

They need to be handled individually for each TMC segment, so that we are only trimming implausible values for each TMC segment.

We can see that I have reduced our Dataframe row count by ~160k by removing implausible outliers.

Also, our travel_time_seconds field previously had a mean value of 181 and a standard deviation of 627. The maximum value was 274,385.

Now the mean is 169 and standard deviation is 422. The maximum value is at 45,730.

For future analysis and for the sake of extending the capability, I chose to merge the dataset with the TMC identification data. You can see an example in my other article or see the exact function in the notebook.

At the end of these steps, the data is bigger but much cleaner, efficient, and useful.

As far as comparing metrics and measures, Federal Highway Administration (FWHA) defines Travel Time Reliability as:

Level of Travel Time Reliability (LOTTR) is defined as the ratio of the 80th percentile travel time of a reporting segment to a “normal” travel time (50th percentile)

So a comparison between the original and cleaned dataset (processed in the same process) may reveal an accurate representation of the LOTTR, from which State DOT’s set their targets.

So first: how to compute the Level of Travel Time Reliability?

There’s no walkthrough guidance (that I’m aware of) for calculating the Level of Travel Time Reliability (LOTTR), so imaginably, everyone‘s process is slightly different

The process must include:

AM period (6–9) for weekdays
MID period (10–3) for weekdays
PM period (4–7) for weekdays
Weekend period (6AM-7PM)
*Overnight is present, but only for freight measures

This will produce the LOTTR which looks something like this:

Simply, anything over 1.5 in any period makes the TMC segment considered “unreliable”.

To compare, simply duplicate the process for the original dataset (without removing outliers).

You can see that, in general, the percent difference between the original dataset and our cleaned dataset is notable, indicated by the negative numbers meaning that the values are lower (which means more reliable).

I made a little function to pick random TMC codes, “melt” the Dataframe to compare clean and original, and plot the comparison so you could do random checks by seeing which bar has the lower value for each period.

This is what the output looks like (you can also check out the notebook)

This TMC segment (133–04364) is a great example of a segment that was considered “unreliable” for nearly every period before it was cleaned and stripped of extreme outliers.

So cleaning the data does affect the measures that State DOT’s report.

The third question to ask is:

How can business units prioritize projects accordingly?

How to assess Measures for Business Unit Planning

Decisions about funding and project prioritization are not always simple, but they can be data-driven and programmatic.

Our columns of interest are the LOTTR columns, but it is hard to tell with the dimension so large. This correlation heatmap does show us that for the LOTTR columns(in the bottom right hand corner) have stronger correlations to the f_system, aadt, and thrulanes columns.

This is a good starting place to start project prioritization targeting improving unreliability of roadways.

Every planning decision process will be approached differently, but you can easily pare down to isolate:

The most achievable (length in miles and through lanes criteria)
The most relevant (AADT density indicating amount of traffic)
The most necessary (functional system helps prioritize by road system service and use)
And the most pertinent (only segments that are considered unreliable)

For example, I was able to identify 9 TMC segment project candidates by identifying segments:

with 2 through lanes and less than .5 mile
AADT values higher than 10,000
and any one period higher than 1.49

Which then you can easily rank by most unreliable and visualize:

It should be fairly obvious that the three TMC segments that should be prioritized for project planning are 133P04320, 133P04911, and 133–04137.

Conclusion and Suggestions for Metrics/Measure Planning

As I’ve mentioned previously, this is not something that FHWA or INRIX (NPMRDS) give guidance for (that I know of). I would not propose that any State DOT completely modify their Travel Time metrics and measures reporting on this article alone.

My suggestion, to any State DOT, is to utilize my notebook with your own data or process accordingly to your current operations in effort to identify and remove extreme outliers.

Then compare the outputs. If the difference is notable or significant, perhaps you may want to take your own report and share with your FHWA representative.

These extreme outliers in the dataset referenced in this article are likely technological issues, driver behavior, or traffic/roadway pattern issues. Perhaps the raw probe had issues detecting/connecting, a parked vehicle along a TMC segment, or some other anomaly. These anomalies are not the intended target for the data collection and may misconstrue your Level of Reliability.

A segment is considered unreliable with a value of “1.5” for any time period. If projects were being planned to address “unreliable” segments, there is a risk of misdirected allotment of funding when the segment is not truly unreliable.

So if measures and targets are being considered for performance and project planning, these extreme outlier instances should not be considered when looking to assess reliability.

This allows for more appropriate project planning.

sample report using Datapane

In case, you missed it, here’s the link to my notebook!

Thank you and I hope this may help you!