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

> USDOT's Work Zone Data Feed Registry lists 43 WZDx and Connected Work Zone feeds. We fetched every one, classified each event as live, upcoming, or ended, and found that about a quarter describe work under way when you ask.

Published 2026-10-23 by Nick Sawinyh.
Explainer in Feeds & Standards.
Canonical: https://its-feed.com/articles/wzdx-work-zone-data-feeds/
Keywords: WZDx, work zone data exchange, WZDx feed registry, connected work zone standard, CWZ, work zone data feed, 511 work zone data

---

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](https://github.com/usdot-jpo-ode/wzdx) 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](https://its-feed.com/articles/what-is-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](https://github.com/ite-org/cwz), 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](https://github.com/ite-org/cwz/blob/main/docs/annex-f-differences-wzdx4-2-cwz1-0.md)
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](https://its-feed.com/articles/mobility-data-interoperability/).

## The registry, and what you can reach

The [Work Zone Data Feed Registry](https://data.transportation.gov/d/69qe-yiui) 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.

![Horizontal stacked bar chart, one bar per WZDx feed, showing the share of each feed's events that were live, upcoming, or ended at the time of the fetch. Utah DOT, Hawaii DOT, and CivicLink are entirely ended. Florida DOT has the most events, 29,280, of which most are ended or upcoming and about 5 percent live. Maricopa County has a block of ended events. Most other feeds, including Minnesota, Kansas, Indiana, Washington, Mississippi, Maryland, and Oklahoma, are almost entirely live or upcoming.](https://its-feed.com/charts/wzdx-work-zone-data-feeds-event-state.png)

*Share of each feed's events that were live, upcoming, or ended at the moment we fetched it, with the event count at right. Three feeds were entirely ended; Florida's volume is mostly past and future detour occurrences. Source: ITS Feed census of the USDOT Work Zone Data Feed Registry (data.transportation.gov 69qe-yiui), all feeds fetched 2026-10-23.*

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](https://github.com/usdot-jpo-ode/wzdx/blob/develop/Creating_a_WZDx_Feed.md): 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](https://its-feed.com/articles/what-the-gtfs-validator-checks/)
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.

## Frequently asked questions

### What is WZDx?

The Work Zone Data Exchange specification, a USDOT-led format for publishing road work as GeoJSON feeds so navigation apps, automakers, and other third parties can read work zones from any agency the same way. It defines a Work Zone Feed of road events and detours and a Device Feed for field equipment such as arrow boards. The last release is v4.2, from February 2023.

### What replaced WZDx?

The Connected Work Zones (CWZ) Implementation Guide and Standard, published by AASHTO, ITE, and NEMA. Version 1.00 came out in December 2024, built on WZDx v4.2. It removes the deprecated WZDx fields and makes the verification flags, the feed update date, and the update frequency required. A v1.01 draft is being developed in the open on GitHub.

### Where do I find WZDx feeds?

USDOT's Work Zone Data Feed Registry on data.transportation.gov (dataset 69qe-yiui) lists every feed registered with the ITS DataHub, with its URL, version, update frequency, and whether it needs an API key. On 2026-10-23 it had 43 rows; 13 were flagged as needing a key, and all 13 refused a request without one.

### Should a WZDx feed include work zones that have ended?

Briefly. The specification's implementation guidance says 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 it has ended. It sets no upper limit, and feeds in the registry range from dropping ended events at once to keeping them for years.

---

Source: ITS Feed, https://its-feed.com/articles/wzdx-work-zone-data-feeds/
ITS Feed is an independent editorial site on the data and technology layer of transportation, published by the team at Veodyn. Figures trace to the sources linked inline.
Site index for agents: https://its-feed.com/llms.txt