Skip to content

Latest commit

 

History

History
57 lines (43 loc) · 5.92 KB

Creating_a_WZDx_Feed.md

File metadata and controls

57 lines (43 loc) · 5.92 KB
Raw

Creating a WZDx Feed

This documents contains information to assist in creating a WZDx data feed, such as the feed format, business rules, and validation tools.

Feed Format and File Type

WZDx feeds are formatted according to the GeoJSON specification. The output of a WZDx feed is a GeoJSON document (a .geojson file) that contains a single GeoJSON FeatureCollection which includes information about the feed (see the FeedInfo Object) and a list of GeoJSON Features describing entities specific to the type of feed, such as work zones.

Why GeoJSON?

GeoJSON is the file format of choice because:

  • It is a lightweight data exchange format.
  • It is easy for humans to read and write.
  • It is easy for machines to parse and generate.
  • The format is designed to exchange spatial data, which is a primary goal of the Work Zone Data Working Group.
  • It is an open specification and does not carry licensing burdens.
  • GeoJSON formatted-data is published as text files, so there is a low technological burden of entry.
  • GeoJSON validation, mapping, and visualization tools already exist and will ease adoption by producers and consumers.

Feed Content

WZDx defines the content and structure of several data feeds. Each feed is described by a single root object with many child objects. The output of a WZDx data feed is a GeoJSON file containing the feed object. WZDx defines the following feed objects:

  • WZDxFeed Object: describes high-level information about work zone events ocurring on roadways (called "road events") that impact the characteristics of the roadway and involve a change from the default state (such as a lane closure). This is the original work zone data exchange feed and the only feed that WZDx defined until version 4.0.
  • RoadRestrictionFeed Object: describes the location and details of restrictions on roadways.
  • SwzDeviceFeed Object: describes information (location, status, live data) about field devices deployed on the roadway in work zones.

See the /spec-content/README.md for detailed information on all objects defined by WZDx.

Business Rules

The following business rules help assure a standardized and interpretable use of the WZDx specification. The specification describes the required structure and data fields to describe a work zone, whereas business rules are additional requirements for using the WZDx specification in a standard manner. Note that business rules are distinct from best practices in that the latter are suggestions and business rules are requirements.

WZDxFeed (Work Zones) Business Rules

  1. Each direction of travel must be represented by a separate road event. For example, if there is a work zone on a roadway with two lanes, each in an opposite travel direction (↑↓), each direction must be a separate road event.
  2. Construction which requires alternating traffic flows within a lane must be represented with at least one road event in each direction. Similarly, roadways that during normal operation have an alternating flow of traffic direction based on time of day must be represented by at least one road event in each direction.
  3. The preferred GeoJSON Geometry for a RoadEventFeature is LineString, which allows indicating the full path of the road event. In cases where only the beginning and ending coordinates are available, the MultiPoint can be used.
  4. A cascading multi-lane closure should consider the speed of vehicles traveling through the work zone. If the distance between lane closures is short enough that time in a to-be-closed lane is not significant, which is common, the to-be-closed lane should be represented as closed to avoid traffic delays and potential crashes.
  5. A detour must be represented with a RoadEvent of type (i.e. with event_type of) detour and its containing RoadEventFeature should have a geometry of type LineString to represent the full detour route. The detour road event should be connected to the work zone road event using the relationship property on the detour road event.
  6. If the lanes property on the WorkZoneRoadEvent, DetourRoadEvent, or RestrictionRoadEvent is provided, it must include one entry for every lane in the road event. Providing lane information for only some of the lanes in a road event is not allowed.

Data Validation

JSON Schemas

The WZDx Specification defines a JSON schema for each feed (WZDx v2.0 and later) within the schemas directory. The repository contains schemas for the following feeds:

Current Version (4.0)

Previous Versions

Self-Validation Checklist

For a list of steps to take to make sure your data feed conforms to the specification and is ready to publish, follow the Self-Validation Checklist.

WZDx v1.1

To validate data feeds and measure compliance with the v1.1 specification, the GSA/18F team developed a prototype data validation tool.