WZDx device feeds, explained

The Work Zone Data Exchange (WZDx) is an open specification, developed with the US Department of Transportation, agencies and industry, for publishing work zone information in one common format. Version 4 defines three feeds: work zones (where and when lanes are closed), field devices (the signs, sensors and beacons in the work zone) and road restrictions. Each feed is a GeoJSON document published at a URL that consumers poll.

Field devices know things a schedule does not. A location beacon on the first cone shows where the work zone really starts today, a sign's message says what drivers are being told, and a sensor's speeds show whether traffic is moving. A device feed puts that in front of the agency and of navigation and connected-vehicle services within a minute or two.

Contracts commonly ask for a refresh every 60 seconds, for every device to carry the agency's identifier for the planned work (its road event ID), and for the feed to follow new WZDx releases within a set time.

Every device carries the same core details, whatever its type:

• device_type, name, description, make, model, serial_number and firmware_version: what it is.
• device_status (ok, warning, error or unknown) and status_messages: whether it is working, and if not, why.
• update_date: when it last reported, so consumers can tell live data from stale data.
• road_names, road_direction, milepost and road_event_ids: where it is and which work it belongs to.
• has_automatic_location and is_moving: whether the position comes from GPS and whether the device is on the move.

The position itself is the feature's GeoJSON point geometry, in longitude and latitude.

This is one portable message sign from the LaneWarden demo's feed. Its message is written in MULTI, the sign markup language from NTCIP 1203: [nl] starts a new line, [np] a new page (phase), [jl3] centers the text and [pt25o0] shows each page for 2.5 seconds.

{
  "id": "M-1",
  "type": "Feature",
  "properties": {
    "core_details": {
      "device_type": "dynamic-message-sign",
      "data_source_id": "lanewarden-demo",
      "device_status": "ok",
      "update_date": "2026-11-04T14:00:00Z",
      "has_automatic_location": true,
      "road_direction": "eastbound",
      "road_names": ["Demonstration Highway"],
      "name": "M-1",
      "description": "Messenger: Eastbound approach, first stage",
      "is_moving": false,
      "road_event_ids": ["demo-work-area-a-eb"],
      "milepost": 10.4,
      "make": "LaneWarden",
      "model": "Messenger",
      "serial_number": "LW-MSG-0101",
      "firmware_version": "edge 3.4.2"
    },
    "message_multi_string": "[pt25o0][jl3]WORK[nl]ZONE[nl]AHEAD[np]TIME TO[nl]MP 20[nl]14 MIN"
  },
  "geometry": { "type": "Point", "coordinates": [-104.612552, 39.119124] }
}

• Refresh on schedule, and set each device's update_date from its own last report, not the time the feed was built.
• Report faults honestly: a warning or error status with a short status message is more useful than a device that silently disappears.
• Link every device to the right road event, so consumers can tie it to the closure it serves.
• Validate the feed against the official WZDx JSON schemas, which are published on GitHub, before going live and after every change.
• Keep the feed up for the whole project, and take it down when the devices leave.

LaneWarden Command publishes a WZDx 4.2 device feed every 60 seconds, and every LaneWarden device maps to a WZDx device type. The live demo shows the feed for each minute of its scenarios, and the website's tests check it against the official 4.2 schema.