Work Zone Data Exchange (WZDx) Specification

The Work Zone Data Exchange (WZDx) Specification aims to make harmonized work zone data provided by infrastructure owners and operators (IOOs) available for third party use, making travel on public roads safer and more efficient through ubiquitous access to data on work zone activity.

The goal of WZDx is to enable widespread access to up-to-date information about dynamic conditions occurring on roads such as construction events. Currently, many IOOs maintain data on work zone activity. However, a lack of common data standards and convening mechanisms makes it difficult and costly for third parties such as original equipment manufacturers (OEMs) and navigation applications to access and use these data across various jurisdictions. WZDx defines a common language for describing work zone information. This simplifies the design process for producers and the processing logic for consumers and makes work zone data more accessible.

Specifically, WZDx defines the structure and content of several GeoJSON documents that are each intended to be distributed as a data feed. The feeds describe a variety of high-level road work-related information such as the location and status of work zones, detours, and field devices.

README Outline

• Data Feeds
• Repository Organization
• Project Description
• Contact Information
• Release Notes
  • Release v4.1 (Sept 2022)
• Getting Started
• JSON Schemas
• Contributions
• Versioning
• License

Data Feeds

WZDx defines the structure and content of multiple distinct data feeds. Each feed is distributed as a single GeoJSON file and is represented by both human-friendly documentation in the spec-content directory and a JSON Schema in /schemas. Each feed is designed for a specific use case is are flexible and its use in practice can vary by application.

List of Data Feeds

Feed Name	Description	Producer	Consumer	Uses	Content
Work Zone Feed	Provides high-level information about events occurring on roadways (called "road events") related to work zones that impact the characteristics of the roadway and involve a change from the default state (such as a lane closure). The Work Zone Feed is the original work zone data exchange feed and was previously named "WZDxFeed".	Agencies responsible for managing roadways and road work, typically state and local DOTs.	Traveling public via third parties such as mapping companies and CAVs.	Route planning; increased awareness; "put work zones on the map".	Work zone and detour road events (see WorkZoneRoadEvent and DetourRoadEvent).
Device Feed	Provides information (location, status, live data) about field devices deployed on the roadway in work zones.	Work zone equipment manufacturers or vendors.	Agencies responsible for managing roadways and permitting work, typically state and local DOTs. Third-parties such as mapping companies and CAVs may also be interested in field device information.	Simplifies design process for agencies wanting to interface with equipment manufacturers; aids in dynamically generating a Work Zone Feed with accurate information; reduces effort for manufacturers to conform to different agencies requirements.	Field devices (see FieldDeviceFeature).

The WZDx Specification has also been extended to define data feeds for representing other types of road events, such as restrictions (included in WZDx v4.0 as the RoadRestrictionFeed), crashes, disasters, and strong winds. The specification for those feeds are available at the Transportation Data Exchange (TDx) GitHub site.

Repostitory Organization

The WZDx Specification repository contains several files and subdirectories.

Directories

1. documents: supplementary PDF and Word documents such as the WZDx Early Adopter's Guide and WZDx Data Feed Self Validation Checklist.
2. examples: example GeoJSON documents from WZDx data feeds. examples/README.md describes the content of this directory in detail.
3. images: the images that are referenced by other Markdown files in the repository.
4. schemas: contains JSON Schemas for each of the feeds defined by WZDx for feed validation.
5. spec-content: details the data content of the WZDx specification, including objects, property names and types, and enumerated types. spec-content/README.md describes the content of this directory in detail.

Files

1. Creating_a_WZDx_Feed.md: information to assist in creating a WZDx data feed, such as the feed format, business rules, and validation tools.
2. LICENSE: the Creative Commons Zero v1.0 Universal license that the repository is licensed under.
3. README.md (this document): information about the WZDx effort and navigating the repository.
4. RELEASES.md: detailed information about every release of the WZDx specification.

Project Description

What is the WZDx Specification? The Work Zone Data Exchange (WZDx) Specification enables infrastructure owners and operators (IOOs) to make harmonized work zone data available for third-party use. The intent is to make travel on public roads safer and more efficient through ubiquitous access to data on work zone activity. Specifically, the project aims to get data on work zones to vehicles to help automated driving systems (ADS) and human drivers navigate more safely.

Why is WZDx being developed? Improving access to work zone data is one of the top needs identified through the US Department of Transportation (USDOT) Data for Automated Vehicle Integration (DAVI) effort.

Up-to-date information about dynamic conditions occurring on roads – such as construction events – can help ADS and humans navigate safely and efficiently. Many IOOs maintain data on work zone activity. However, a lack of common data standards and convening mechanisms makes it difficult and costly for third parties – including original equipment manufacturers (OEMs) and navigation applications – to access and use these data across various jurisdictions.

Inspired by GTFS, USDOT launched WZDx to jumpstart the voluntary adoption of a basic work zone data specification through collaboration with data producers and data users. Longer-term, the goal is to enable collaborative maintenance and expansion of the specification to meet the emerging needs of ADS.

Who is involved in developing WZDx? The Federal Highway Administration (FHWA) and Intelligent Transportation Systems Joint Program Office (ITS JPO) co-led the early stages of the WZDx project and remain actively involved along with the Bureau of Transportation Statistics (BTS), Federal Motor Carrier Safety Administration (FMCSA), and others in the USDOT.

Several data producers and data users voluntarily developed v1.1 of the specification in collaboration with USDOT, and have set up data feeds based on the specification. These WZDx-compliant feeds and their links can be found in the Work Zone Data Exchange Feed Registry. Data producers with feeds in the registry currently include: Texas Department of Transportation (TxDOT), Massachusetts Department of Transportation (MassDOT), Maricopa County Department of Transportation (MCDOT), and Iowa Department of Transportation (IDOT).

Going forward, the Work Zone Data Working Group (WZDWG), established under the Federal Geographic Data Committee (FGDC) Transportation Subcommittee (TSC) will maintain the WZDx Specification with the goal of publishing incremental updates to refine the features, attributes, and vocabulary needed to model work zone activity data.

How can I get help with implementation? Review Creating_a_WZDx_Feed.md which contains information to assist in creating a WZDx data feed, such as the feed format, business rules, and validation tools.

This project repository will be continually updated with resources to help with implementation - in the meantime, please make a new GitHub discussion if you need help implementing the WZDx Specification or have questions.

The Federal Highway Administration is leading efforts, via the Work Zone Data Initiative (WZDI), to develop a standard approach for collecting, organizing, and sharing data on the “when”, “where,” and “how” of work zone deployment. As part of this effort, key documents have been developed and made publicly available:

• WZDI Framework provides a conceptual architecture for work zone data systems for collecting, storing, disseminating, managing, maintaining and archiving work zone activity data.
• WZDI Data Dictionary provides digital descriptions of work zone activities that enable and support transportation agencies and third party providers to describe and communicate work zone-related information to agency, private sector, and public users timely and seamlessly across multiple jurisdictions and regions.

Contact Information

Contact Name: ITS JPO

Contact Information: [email protected]

Release Notes

WZDx v4.1 (September 2022)

New Functionality

• Add is_moving boolean property to the FieldDeviceCoreDetails to allow indicating if any field device is moving as part of a mobile operation.
• Add road_direction property to the FieldDeviceCoreDetails to allow providing the direction of the roadway that a field device is associated with.
• Recommend using Universally Unique Identifiers (UUID) for the id property of the RoadEventFeature, FieldDeviceFeature, and FeedDataSource, noting that a UUID may be required in the next major release.
• Add name property to RoadEventCoreDetails to allow providing a human-friendly name for a road event.
• Add the following values to the MarkedLocationType enumerated type:
  • personal-device
  • ramp-closure
  • road-closure
  • delineator
• Add the following values to the Direction enumerated type:
  • undefined
  • unknown
• Add no-passing to the RestrictionType enumerated type.
• Add a sign_text property to the FlashingBeacon object.
• Add a TrafficSignal object to allow represent temporary traffic signals in a WZDx Device Feed.
• Add two-way-center-turn-lane to the LaneType enumerated type to replace the existing center-left-turn-lane with a more generic value.

Refactoring

• Deprecate is_moving property on the ArrowBoard; use the new is_moving on the FieldDeviceCoreDetails instead.
• Change the conformance of the road_event_id property on the TrafficSensorLaneData from "Required" to "Optional" to allow providing lane-level data without a defined road event.
• Deprecate the road_event_feed_info property on the WorkZoneFeed object; use the new feed_info property instead.
• Add is_start_position_verified and is_end_position_verified boolean properties to the WorkZoneRoadEvent to allow indiciating if the start and end positions are verified and clarify what verified means; these properties replace beginning_accuracy and ending_accuracy.
• Deprecate the beginning_accuracy and ending_accuracy properties on the WorkZoneRoadEvent object; use the new is_start_position_verified and is_end_position_verified properties instead.
• Add is_start_date_verified and is_end_date_verified boolean properties to the WorkZoneRoadEvent to allow indiciating if the start and end date and times are verified and clarify what verified means; these properties replace start_date_accuracy and end_date_accuracy.
• Deprecate the start_date_accuracy and end_date_accuracy properties on the WorkZoneRoadEvent object; use the new is_start_date_verified and is_end_date_verified properties instead.
• Deprecate the event_status property on the WorkZoneRoadEvent object.
• Change the conformance of the road_names property on the FieldDeviceCoreDetails from "Required" to "Optional".
• Deprecate the traffic-signal value in the MarkedLocationType enumerated type; use the new TrafficSignal object instead.
• Deprecate the center-left-turn-lane value in the LaneType enumerated type; use the new two-way-center-turn-lane instead.
• Add a related_road_events property (and new supporting object RelatedRoadEvent and enumerated type RelatedRoadEventType) to the RoadEventCoreDetails to allow explicitly defining relationships/connections between road events; this replaces the Relationship object concept.
• Deprecate the relationship property on the RoadEventCoreDetails; use the new related_road_events property instead.

Cleanup

• Change the type of the average_speed_kph, volume_vph, and occupancy_percent properties on the TrafficSensor and TrafficSensorLaneData object from "Integer" to "Number"
• Change the allowed minimum value for average_speed_kph on TrafficSensorLaneData from 1 to 0.
• Add a feed_info property to the WorkZoneFeed object to replace the road_event_feed_info.
• Expand the description of the update_date property on the RoadEventCoreDetails and FieldDeviceCoreDetails to clarify what the value represents.
• Remove the RoadRestrictionFeed (it moved to usdot-jpo-ode/TDx).

Getting Started

The WZDWG welcomes feedback and comments on the WZDx v4.1 Specification. Comments can be made by posting a GitHub Issue or Discussion, while suggested changes can be made using a Pull Request.

1. Read about WZDWG activities Wiki and the WZDx Early Adopter's Guide.
2. Learn about using GitHub as a tool for collaboration and support.
3. Read Creating a WZDx feed which contains information about creating a WZDx data feed, such as the feed format, business rules, and validation tools.
4. Use the Specification Content page to understand the data components of the specification.
5. Consider using the IBI.WZDx .NET class library to facilitate development of a feed.
6. Validate your feed output using the respective JSON Schema.
7. Publish your feed and tell us about it via [email protected].

JSON Schemas

The WZDx Specification defines a JSON schema for each feed within the schemas directory. Schemas can be used to validate a WZDx feed document for compliance to the specification. The repository contains schemas for the following feeds:

Current Version (4.1)

• WZDx v4.1 Work Zone Feed
• WZDx v4.1 Device Feed

Previous Versions

• WZDx v4.0 WZDxFeed
• WZDx v4.0 SwzDeviceFeed
• WZDx v4.0 RoadRestrictionFeed
• WZDx v3.1 WZDxFeed
• WZDx v3.0 WZDxFeed
• WZDx v2.0 WZDxFeed

Contributions

How do I contribute to the WZDx Specification?

• Report bugs and request features via GitHub Issues.
• Ask the WZDx community for input on a question or propose an idea you have via GithHub Discussions.
• Create a GitHub Pull Request that implements new functionality or fixes a bug.
• Review and provide feedback on update issues/discussions/pull requests created by other users.
• Alternatively, email us with any questions.
• Help us improve our best practices and formatting on GitHub.

Versioning

The WZDx specification uses a major.minor versioning scheme, similar to SemVer. The rules are as follows:

1. The minor version number must be incremented if new, backwards compatible fields/entities/enumerations are introduced or if any existing fields/entities/enumerations are marked as deprecated.
2. The major version number must be incremented if any backwards incompatible changes are introduced.
3. Neither version number shall be incremented for documentation changes/clarifications that have no effect on either the specification schema or the content or structure of a GeoJSON feed file which conforms to the specification.

To view available versions, refer to the tags section of this repository.

License

The WZDx project is in the worldwide public domain (i.e., in the public domain within the United States - copyright and related rights in the work worldwide are waived through the CC0 1.0 Universal public domain dedication). All contributions to this project will be released under the CC0 dedication. By submitting a pull request, you are agreeing to comply with the waiver of copyright interest. see License for more details.