FHWA Work Zone Data Initiative

We in the work zone traffic control world and specifically the work zone ITS world have long wrestled with how best to gather and evaluate work zone data. This has been a topic of discussion at conferences, peer-to-peer exchanges, and in DOTs nationwide. These systems are now providing a great deal of data and the FHWA feels it is time we settled on a standard approach to that data. In response, they have launched the Work Zone Data Initiative (WZDI).

The stated goals of the initiative are:

“To develop a recommended practice for managing work zone data.” And to “create a consistent language for communicating information on work zone activity across jurisdictional and organizational boundaries.”

They are working to develop a specification for work zone data that supports DOT efforts throughout the project and also allows some sort of standardized evaluation and comparison once that project is complete. They want the data to become more useful for project planning, for real-time traffic operations, and for post project analytics.

This is something our industry must be involved in. Please let us know if you are. But if you are not, please contact Todd Peterson, FHWA Work Zone Management Team Transportation Specialist to express your interest. His email address is Todd.Peterson@dot.gov .

 

USDOT has also announced a competition on Advancing Innovative Ways to Analyze Crash Data. They point out that most crash data (as well as work zone data) is siloed and made available only on an annual basis. By opening those sources of data up, DOT hopes to take advantage of new tools such as machine learning (see 4/10/17 post) to gain insights on ways we can reduce roadway fatalities.

This effort is not work zone specific, but could result in improvements that our past state and project specific analysis was unable to find.

Use of Wireless Data for Work Zone Performance Measures

The second TRB paper I would like to discuss is paper number 14-2186: “Using Private Sector Travel Time Data For Project-Level Work Zone Mobility Performance Measurement” by Michael Fontaine, PilJin Chun and Benjamin Cottrell of the Virginia Center for Transportation Innovation and Research. It analyzes the value of mobile phone data as a measure of work zone performance.

They began by noting the need for more and better work zone data to be used in measuring work zone performance. They focused only on performance measures, and did not touch on safety. The measures they chose were delay time and queue length. They felt those were the two most commonly accepted measures in use today.

They did mention the potential use of this data to determine work windows in real time. This is something we have discussed before but it is interesting that they see value in that, too. They also said, “Installing new, temporary sensors specifically to monitor work zone mobility is an option, but it is often only cost effective for long-term, major projects.” That was true at one time, but it is not usually true today. And it assumes you are collecting the data only to measure performance. It does not consider its added use for queue warning and other safety enhancements.

Wireless data is collected and analyzed over road segments which they call Traffic Message Center (TMC) Links. These are a standard reporting format created by mapping companies. They are generally a section of road between major intersections or between interchanges. So in cities they are fairly close together, but in rural areas they are often much farther apart.

The limitation of this data is that a work zone two miles long may be in the middle of a TMC 10 miles long. In that case it will under report delays because speeds will be averaged over that segment rather than just through the work zone.

Longer segments will over report queue lengths. Queuing is defined as anytime speeds are reduced to less than X% of the norm anywhere in the segment. So if a queue develops somewhere in that 10 mile long segment, it is reported as a queue 10 miles long even when it is actually less than a mile long.

These issues are less consequential in urban areas where they found average segment lengths of .56 and .71 miles on the two projects studied. The amount of any error will be much smaller and would probably be fair to both agency and contractor if used in an incentive/disincentive program for work windows.

But there are still issues if this data is to be used to report delay times to travelers or to warn them of queuing. For the delay times, there will be an error. For the agencies and contractors this error averages out. But individual travelers will see the error when it occurs and that will undermine their perception of the value of such systems.

For queue warning, even in these urban areas, the spacing is set. In some cases it will provide ample warning, but on longer segments it may not. The spacing cannot be adjusted as needed.

And in rural areas, the long road segments mean both delay and queue length measures are significantly inaccurate. And they are almost useless for reporting delays or queuing to motorists.

We have not discussed whether this data can be used to trigger portable message sign messages in a timely manner. If not today, they will most likely be capable of it in the very near future. But this study does point out the weaknesses of this data for work zones. If an agency wants the data solely for internal performance measurement, it is probably an option.

But if that agency also wants to use it for contractor incentives or for reporting delays or queuing to the public, they should stick with portable systems. Only portable sensors can be spaced to meet the needs of that project. Only portable sensors can be adjusted to provide useful data in a changing work zone environment. And only portable sensors can tell you precisely where in that work zone the queue begins so that traffic control can be adjusted to minimize the disruption to traffic.