WZDx feeds: what USDOT's work zone registry actually serves

USDOT’s Work Zone Data Feed Registry lists 43 feeds that publish road work in the Work Zone Data Exchange format or its successor standard. We fetched every one of them on the morning of October 23, 2026. Of the 43, 26 answered with a feed, and together they held 46,303 work zone and detour events. Of those, 10,518 described work that was under way at the moment of the fetch: the start date had passed and the end date had not. Another 16,146 were scheduled for later. The remaining 19,639 had an end date that was already in the past, and three feeds, Utah’s, Hawaii’s, and one registered by a software vendor, held nothing current at all.

The registry covers agencies in 36 states, and the format has been stable since 2023. But a WZDx feed is a list of events with dates, and working out which of them are current is left to the consumer.

What WZDx is

The Work Zone Data Exchange specification defines a set of GeoJSON documents, each meant to be served as a feed. The Work Zone Feed carries road events: a work zone or a detour, a line or set of points along a road, a direction, start and end dates, and optional detail such as which lanes are closed, whether workers are present, and a reduced speed limit. The Device Feed carries field equipment such as arrow boards, message signs, and flashing beacons. USDOT’s own description of the project says it was inspired by GTFS, and the shape is familiar to anyone from transit: one open format, published by each agency at a stable URL, so that a navigation app or an automaker can read every jurisdiction with the same code.

The specification came out of USDOT’s work on data for automated vehicles, where work zone data ranked among the top needs. FHWA and the ITS Joint Program Office led the early versions, and a Work Zone Data Working Group under the Federal Geographic Data Committee oversaw versions 2.0 through 4.2. Version 4.2, released in February 2023, is the last. The repository has had a handful of small fixes since, the latest in November 2024.

On the agency side, WZDx often lives with the state’s traveler information system. Wisconsin’s and Idaho’s registered feeds are served from their 511 sites (511wi.gov, 511.idaho.gov), and New York’s was on 511ny.org until this month. A 511 system already holds the agency’s road events for its map, app, and phone line, and the WZDx feed is one more way out for the same records.

Where the standard went next

USDOT’s ITS Joint Program Office then engaged the standards bodies to turn WZDx into a formal standard. The result is the Connected Work Zones Implementation Guide and Standard, published by AASHTO, ITE, and NEMA, with version 1.00 dated December 2024. It keeps the WZDx structure and tightens it. Its annex listing the differences from WZDx v4.2 makes the four verification flags required (whether the start date, end date, start position, and end position are confirmed), makes the feed’s update date and update frequency required, drops the GeoJSON MultiPoint geometry, removes the fields WZDx had already deprecated, and renames milepost to reference post with an explicit unit.

On October 1, 2026, the CWZ repository on GitHub took in a v1.01 draft, dated September 2026 and described as an experimental specification based on the published v1.00, under a Creative Commons license. The repository invites comments through GitHub issues and discussions; as of October 23 none had been opened. The registry has started to reflect the change: 4 of its 43 rows are CWZ 1.0 feeds, from Colorado, Massachusetts, the Illinois DOT, and a vendor.

Neither WZDx nor CWZ is among the 55 specifications graded in the Mobility Data Interoperability Principles registry, in its build of October 15, which we covered in our piece on mobility data interoperability.

The registry, and what you can reach

The Work Zone Data Feed Registry is a dataset on data.transportation.gov, last updated October 14, 2026. Each row carries a state, an issuing organization, a URL, a specification version, a stated update frequency, and a flag for whether the feed needs an API key. Its description sets out a maintenance policy: when an organization changes URL, version, or key requirement, the old row gets an end date and is removed once that date passes, and a feed that has been offline for a long time or whose data is “significantly out of date” is removed too.

We fetched every URL with a script that records the HTTP outcome, parses the feed, and classifies each event against the time of the request. The first pass ran on September 30 and the second on October 23.

Outcome on 2026-10-23	Rows	Notes
Answered with a feed	26	One, a vendor’s CWZ feed, held no events
Refused without an API key	13	Every row the registry flags as needing a key; HTTP 401 or 403
Returned something other than a feed	3	New Mexico’s URL answered HTTP 503 on both passes; North Carolina’s now answers “Invalid Key” though the registry says no key is needed; New York’s returns the HTML of the 511NY web app
No URL	1	A Michigan row the registry marks inactive, with an end date of June 30, 2025

The key flag held for all 13 rows that carry it. The two changes between passes were North Carolina and New York, which both answered with full feeds on September 30, with 6,083 and 6,470 events. On October 23 the registered New York URL served the 511NY site’s app shell, and the new site loads its data from a different platform, so the feed may well have moved. The registry still pointed at the old address.

What a feed holds right now

Every WZDx event carries a required start date and end date. That makes it possible to sort each event into one of three states at the moment of the fetch: live, if the start has passed and the end has not; upcoming, if the start is in the future; and ended, if the end has passed. Feeds differ a great deal in how much of each they publish.

Minnesota, Kansas, Indiana, Washington, Mississippi, Maryland, Oklahoma, Louisiana, Quebec City, and the City of Austin publish only work that is live or scheduled, and drop an event once its end date passes. Wisconsin, Iowa, and Idaho lean heavily toward upcoming work, with 2,601 of Wisconsin’s 3,317 events, 734 of Iowa’s 942, and 488 of Idaho’s 639 not yet started. That is useful for route planning days ahead, and it means a consumer that treats every event in those feeds as an active closure will show a lot of work zones that have not begun.

Three ways an event outlives its work zone

The specification has a view on ended events, in its implementation guidance: a producer should consider keeping a completed event with verified start and end dates in the feed for at least an hour or one refresh cycle, whichever is longer, so consumers learn the work has ended. It sets no upper limit.

The first group marks its ended events as completed and keeps them. Florida is the largest feed in the registry by far, with 29,280 events drawn from 47 data sources, most of them contractors and counties, and published through one.network. Of its events, 17,330 had ended, and all of them carried event_status: completed, a field WZDx has deprecated but still allows. Nearly all of them, 16,274, are detours, and they are recurring: a single daytime detour on a county road becomes a chain of daily occurrences linked by next-occurrence references, each with its own start and end. The oldest ended occurrence was 365 days old, which suggests a rolling year of history. Florida’s feed had 1,606 live events, 10,344 upcoming, and a year of completed occurrences behind them. None of the completed events had is_end_date_verified set to true; the end dates are the scheduled ones.

The second group marks ended events as verified and keeps them for years. Maricopa County’s feed has 2,639 events, of which 589 had ended, every one with both is_start_date_verified and is_end_date_verified set to true, which is what the spec’s guidance asks for. The median ended event in that set ended 1,196 days before our fetch, more than three years against the guidance’s minimum of an hour.

The third group is feeds that stopped. Utah DOT’s registered feed returns 744 events, every one ended, the latest on April 1, 2024. The feed header’s own update date is March 19, 2023, while it declares an update frequency of 15 minutes, and the file was identical on both passes. Hawaii DOT’s feed, published by Blyncsy, held 66 events on both passes, all ending on September 15, 2026, all last updated on September 8, with a feed header dated February 22, 2024 and a declared frequency of one week. CivicLink, a vendor feed registered without a state, held 730 events on both passes; on September 30, 693 had ended, and by October 23 all 730 had, with no new ones added. Kentucky’s feed header is current, but 95 of its 223 events had ended without any completed or verified flag, with a median of 142 days past their end date.

Across the 25 feeds with events, 1,672 events had ended more than a day earlier with no flag saying so. Most of them sit in the three stopped feeds. Utah’s is the case the registry’s own policy describes, a feed whose data is significantly out of date, and it is still listed, as is the Michigan row whose end date passed in June 2025.

Fields beyond the minimum

WZDx requires little beyond the event’s location, dates, direction, road names, and a judgment of vehicle impact. The optional fields are where a feed becomes useful to a driver or an automated vehicle, and support for them is thin.

Field	Feeds that use it (of 25 with events)	What it carries
is_start_date_verified, is_end_date_verified	18	Whether the work was confirmed to have started or ended
is_start_position_verified, is_end_position_verified	18	Whether the ends of the zone came from a GPS-equipped device
update_date on events	17	When the event last changed
reduced_speed_limit_kph	12	A posted work zone speed limit
restrictions	12	Height, width, weight, or similar limits
types_of_work	11	What kind of work, and whether it changes the road’s layout
beginning_milepost	10	A milepost reference for the start of the event
lanes	9	The status of each lane
worker_presence	9	Whether workers are present and how that is known

A count of feeds overstates the coverage for the fields that should be on every event. Lane detail appears in 9 feeds but on every event in only 3 of them, and the type of work on every event in 3 of 11. A field that is present in a feed tells a consumer the producer can send it, not that a given event has it.

The verification row is the one CWZ changes. Of the 25 feeds with events, 7 do not send the four verification flags and 8 send no update frequency in the feed header. Both become required under CWZ, as does an update date in the header. MultiPoint geometry, which CWZ drops in favor of LineString or Point, turns up in 13 feeds. For those feeds, moving to CWZ means schema work. JSON Schema validation, which the specification provides, would catch those, much as the GTFS validator catches structural faults in a transit feed. It would not catch any of the stale feeds above, which are schema-valid and simply old.

Who actually publishes the feeds

The feed header names a publisher, and in eight of the agency feeds that answered, it names a company rather than the agency. Minnesota, Kansas, and Indiana carry publisher names ending in CastleRock and are served from carsprogram.org hosts; New York’s new 511 site loads its data from the same family of hosts. Delaware and Louisiana are published by HaulHub Technologies, Florida by one.network, Hawaii by Blyncsy, and Idaho by Arcadis. New Mexico’s unreachable feed is on the same Blyncsy host as Hawaii’s. CivicLink and PurposeBuilt are vendors registered in their own right, and PurposeBuilt’s CWZ feed was empty on both passes.

When a state’s feed comes off a vendor platform, the fields it sends and how long it keeps ended events can be product decisions shared by every state on that platform. The three CastleRock feeds look alike in our census: all publish only live and upcoming events, none carries lane detail, and all declare a 60-second update frequency.

What it means for a consumer

A consumer of WZDx data has to do work the format leaves open. Filter by date at read time, because a feed’s contents are not a list of active work zones. Check the feed header’s update date against the declared frequency and treat a feed whose header is far behind as stale, which would have flagged Utah and Hawaii without looking at a single event. Prefer the verification flags where they exist, and expect them to be missing in about a quarter of feeds. Read event_status even though it is deprecated, because the largest feed in the registry uses it to mark a year of completed detours. And watch the URLs: two feeds that answered in September did not answer as feeds in October.

For a producer, the registry’s own policy and the spec’s guidance point the same way. Keep a completed event long enough for consumers to see it end, mark it as completed or verified, and then drop it. Keep the feed header’s update date honest, because it is the cheapest freshness check a consumer has. And when the URL changes, tell the registry.

What to watch

The CWZ v1.01 baseline landed on October 1, and the move to GitHub means later changes can be followed commit by commit. The thing to watch in the registry is the version column: 37 of its rows are WZDx 4.x and 4 are CWZ 1.0. How quickly states move, and whether the vendor platforms move their customers together, will decide whether the verification flags become a reliable part of the data or stay optional in practice.

The other is the registry itself. Its maintenance policy is clear and it is not yet applied to Utah or to the expired Michigan row. Every count in this piece is from our fetch of October 23, 2026, and feeds change daily; we will re-run the census as CWZ adoption grows.