Watch Out for Work Zones: FHWA’s vision and update for the Work Zone Data Exchange

Highlights and Soundbites

Todd: You develop a product that runs WZDx, you know, that’s immediately marketable to the roughly 90,000 Federal, State, and County governments across the country, so there’s a distinct value proposition there…We are up to 25 States plus the National Park Service that are actively producing work zone data exchange feeds.

Mark: WZDx actually includes two [specified] feeds. We’re talking today mostly about the work zone feed, which is for conveying where the work zones are located on road network. That data is generally produced by transportation agencies as an authoritative data source and delivered to the traveling public.

In addition to the work zone feed, the WZDx specification, and the connect work zone standard, includes a device feed which is used for communicating information about the location of connected devices in work zones to an IOO (infrastructure owners and operators) in order to help make real time data more available, because many state DOTs have a hard time keeping track of where work is actually happening compared to where work is permitted to happen.

Aaron: DriveTexas actually has it’s own API, and this actually came about during Hurricane Harvey. As Hurricane Harvey was coming through Texas, doing what it did, [Texas] DPS actually, the Texas Department of Public Safety reached out to us and said “hey, we’re struggling with looking at our data and your data at the same time. We’re continually having to bounce back and forth between the two applications to see where we can go, what we can do, how to navigate through this actual natural disaster.” So we [TxDOT] reached out, the travel division reached out to our IT division and came up with a very thrown together, crude, makeshift API feed literally in the middle of a hurricane, and got it to DPS, got it to other first responders, where they were able to take that information, overlay it onto their system, and not have to bounce back and forth across screens.

Fast forward to the end of Harvey, recovery efforts are wrapping up, we’re getting back into the rebuilding phase, so as the travel division looked at it we decided okay, we don’t need the API anymore, so we turned it off. Very shortly after we turned off the API we got a call from the Department of Public Safety again saying “hey, we’re no longer seeing your data anymore on our system, like, did you turn the API off?”, and we’re like yeah Hurricane’s over, we’re good to go. They’re like “No, no, no, we would like to have that information all the time. It’s valuable information to have.”, and so we’re like oh okay. So we went back to the IT division, met with our IT vendors, and came up with I won’t say more elaborate but a more refined API that wasn’t built in the middle of a hurricane.

Caitlin: There are two core components of the WZDx speed specification that we wanted to make sure we were hitting. One of those is having a record for each direction of cardinality that a event is impacting, so if there is a construction event that’s closing down both the Northbound and Southbound side of a highway, we want to have two conditions that represent that: one for the Northbound, one for the Southbound – and digitized in those directions as well. The way we get this data from HCRS is there’s a field that will tell us, “hey, this is impacting the westbound side or the eastbound side”, or maybe both…We would take the route, and then calculate the starting and ending points, so we would look at where the coordinates beginning, and where the coordinates are ending to determine what direction that route was moving in, so, if the starting points were less than the ending points, then we knew it was probably a Northbound route for example…[as] Any car is traveling with a mapping application that is consuming the data, they’ll hit that record with the appropriate direction of cardinality.