Released April 2021
Following the major v3.0 release, the changes for the v3.1 release were developed with the goal enhancing and cleaning up the specification without making major changes or breaking backwards compatibility. Thus, in v3.1 many enumerated type values or object properties were deprecated rather than removed. Most if not all of these deprecated values will be removed in the next major release.
This repository was also renamed from jpo-wzdx
to wzdx
on 2021-04-05. All links pointing to jpo-wzdx
will automatically redirect to the new URL.
- Add
local-access-only
restriction - Add
license
property to theRoadEventFeedInfo
object
- Refactor
LaneType
enumerated type to deprecate values that can be determined from other properties of the Lane object, such asorder
,status
, andlane_restrictions
- Add value
alternating-flow
toLaneStatus
enumerated type and deprecatealternating-one-way
- Add
road_names
property to theRoadEvent
object and deprecateroad_name
androad_number
- Deprecate the
total_num_lanes
property on theRoadEvent
object as theRoadEvent
'slanes
array can be used to determine the number of lanes
- Add optional
bbox
property to allow providing a GeoJSON Bounding Box for theWZDxFeed
andRoadEventFeature
objects - Add an
id
property to theRoadEventFeature
object for providing the a road event's identifier to better follow GeoJSON ID recommendations
Released September 2020
- Restrict
version
format tomajor.minor
and enforce via v3.0 JSON schema - Add
order
property to Lane object to indicate a lane's position in sequence on the roadway - Remove
lane_edge_reference
and standardize on counting lanes from the left side of the roadway - Add
event_type
property to the RoadEvent object and new EventType enumerated type with the valueswork-zone
anddetour
, to support adding detour information (and more in the future) - Add Relationship object (one per RoadEvent) to enable describing relationships (hierarchical and sequential) between road events and other non-WZDx entities (such as a work zone phase or project)
- Add RoadEventDataSource object to allow specifying multiple data sources within a single feed
- Streamline metadata (previously given in an external file, by URL) and add relevant fields to the RoadEventFeedInfo and RoadEventDataSource objects
- Require
restriction_type
if providing a lane-level restriction - Change Spatial Verification Enumerated Type and Time Verification Enumerated Type values to be all lowercase
- Remove all plural or nonsensical lane types from the Lane Type Enumerated Type and clarify that each WZDx lane should represent a single lane on the roadway
Released January 2020
This release includes the first set of major changes to the specification.
- Added new data tables to accommodate mobility impact and lane level impacts/restrictions (i.e., closures and restrictions). The new lane-level information, as well as overall vehicle impact fields, allowing IOOs new flexibility in communicating impacts and mobility restrictions of a work zone.
- Added a new Types of Work table to provide specific information on the types of work being performed at a work zone. This enumerated table categorizes the type of work and indicates if construction in a work zone will cause any architectural changes to the roadway. This information will support keeping the maps used by autonomous vehicles up to date.
- Required GeoJSON formatting of a WZDx feed. GeoJSON is a data interchange format based on JavaScript Object Notation (JSON) designed to exchange geospatial data. Since feeds can be used with existing validation, mapping, and visualizations tools, requiring GeoJSON will improve accessibility of work zone data activity to producers and consumers.
- Converted the “common core” data dictionary into a relational data model with road event tables featuring new geometry-specific data elements. This conversion permits more efficient organization of the data elements for each work zone and supports a flexible, scalable data model.
Released September 2018
Initial release. This version served as a first step in providing a standard work zone data activity framework. This version of the specification focused on “common core” data concepts which are defined as data elements needed for most work zone data use cases. The specification included data elements that data producers were already producing as well as those that may not currently be produced.