-
Notifications
You must be signed in to change notification settings - Fork 62
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
84 changed files
with
4,093 additions
and
6,051 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,57 @@ | ||
| # 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](https://geojson.org/) specification. The output of a WZDx feed is a GeoJSON document (a `.geojson` file) that contains a single [GeoJSON FeatureCollection](https://datatracker.ietf.org/doc/html/rfc7946#section-3.3) which includes information about the feed (see the [FeedInfo Object](/spec-content/objects/FeedInfo.md)) and a list of [GeoJSON Feature](https://datatracker.ietf.org/doc/html/rfc7946#section-3.2)s 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](/spec-content/objects/WZDxFeed.md): 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](https://github.com/usdot-jpo-ode/wzdx/releases/tag/v4.0). | ||
| - [RoadRestrictionFeed Object](/spec-content/objects/RoadRestrictionFeed.md): describes the location and details of restrictions on roadways. | ||
| - [SwzDeviceFeed Object](/spec-content/objects/SwzDeviceFeed.md): describes information (location, status, live data) about field devices deployed on the roadway in work zones. | ||
|
|
||
| *See the [/spec-content/README.md](/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](https://tools.ietf.org/html/rfc7946#page-7) for a [RoadEventFeature](/spec-content/objects/RoadEventFeature.md) 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](/spec-content/objects/RoadEvent.md) of type (i.e. with `event_type` of) `detour` and its containing [RoadEventFeature](/spec-content/objects/RoadEventFeature.md) 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](/spec-content/objects/WorkZoneRoadEvent.md), [DetourRoadEvent](/spec-content/objects/DetourRoadEvent.md), or [RestrictionRoadEvent](/spec-content/objects/RestrictionRoadEvent.md) 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](/schemas) directory. The repository contains schemas for the following feeds: | ||
|
|
||
| #### Current Version (4.0) | ||
| - [WZDx v4.0 WZDxFeed](/schemas/4.0/WZDxFeed.json) | ||
| - [WZDx v4.0 SwzDeviceFeed](/schemas/4.0/SwzDeviceFeed.json) | ||
| - [WZDx v4.0 RoadRestrictionFeed](/schemas/4.0/RoadRestrictionFeed.json) | ||
|
|
||
| #### Previous Versions | ||
| - [WZDx v2.0 WZDxFeed](/schemas/2.0/WZDxFeed.json) | ||
| - [WZDx v3.0 WZDxFeed](/schemas/3.0/WZDxFeed.json) | ||
| - [WZDx v3.1 WZDxFeed](/schemas/3.1/WZDxFeed.json) | ||
|
|
||
| ### 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](/documents/WZDx_Data_Feed_Self-Validation_Checklist.docx). | ||
|
|
||
| ### 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](https://github.com/18F/usdot-jpo-ode-workzone-data-exchange/wiki). |
Oops, something went wrong.