Merge branch 'v4.0-release' of https://github.com/usdot-jpo-ode/wzdx …

…into v4.0-release

Creating_a_WZDx_Feed.md

@@ -33,7 +33,7 @@ The following business rules help assure a standardized and interpretable use of
 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 [RoadEvent](/spec-content/objects/RoadEvent.md) object 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.
+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
 
@@ -46,9 +46,9 @@ The WZDx Specification defines a JSON schema for each feed (WZDx v2.0 and later)
 - [WZDx v4.0 RoadRestrictionFeed](/schemas/4.0/RoadRestrictionFeed.json)
 
 #### Previous Versions
-- [WZDx v2.0 WZDxFeed](/schemas/wzdx_v2.0_feed.json)
-- [WZDx v3.0 WZDxFeed](/schemas/wzdx_v3.0_feed.json)
-- [WZDx v3.1 WZDxFeed](/schemas/wzdx_v3.1_feed.json)
+- [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).

README.md

@@ -13,7 +13,7 @@ Specifically, WZDx defines the structure and content of several [GeoJSON](https:
 - [Project Description](#project-description)
 - [Contact Information](#contact-information)
 - [Release Notes](#release-notes)
-    - [Release v3.1 (Apr 2021)]
+    - [Release v4.0 (Dec 2021)](#wzdx-v40-december-2021)
 - [Getting Started](#getting-started)
 - [JSON Schemas](#json-schemas)
 - [Contributions](#contributions)
@@ -37,8 +37,8 @@ The WZDx Specification repository contains several files and subdirectories.
 1. [documents](/documents): supplementary PDF and Word documents such as the WZDx Early Adopter's Guide and WZDx Data Feed Self Validation Checklist.
 2. [examples](/examples): example GeoJSON documents from WZDx data feeds. [examples/README.md](/examples/README.md) describes the content of this directory in detail.
 3. [images](/images): the images that are referenced by other Markdown files in the repository.
-4. [spec-content](/spec-content): details the data content of the WZDx specification, including objects, property names and types, and enumerated types. [spec-content/README.md](/spec-content/README.md) describes the content of this directory in detail.
-5. [schemas](/schemas): contains [JSON Schema](https://json-schema.org/)s for each of the feeds defined by WZDx for feed validation.
+4. [schemas](/schemas): contains [JSON Schema](https://json-schema.org/)s for each of the feeds defined by WZDx for feed validation.
+5. [spec-content](/spec-content): details the data content of the WZDx specification, including objects, property names and types, and enumerated types. [spec-content/README.md](/spec-content/README.md) describes the content of this directory in detail.
 
 ### Files
 1. [Creating_a_WZDx_Feed.md](/Creating_a_WZDx_Feed.md): information to assist in creating a WZDx data feed, such as the feed format, business rules, and validation tools.
@@ -83,33 +83,41 @@ Contact Information: [avdx@dot.gov](mailto:avdx@dot.gov?subject=Submission%20of%
 
 ## Release Notes
 
-### Release v3.1 (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 spec 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. 
-
-#### Features
-* Add `local-access-only` restriction
-* Add `license` property to the `RoadEventFeedInfo` object
-
-#### Refactoring
-* Refactor `LaneType` enumerated type to deprecate values that can be determined from other properties of the Lane object, such as `order`, `status`, and `lane_restrictions`
-* Add value `alternating-flow` to `LaneStatus` enumerated type and deprecate `alternating-one-way`
-* Add `road_names` property to the `RoadEvent` object and deprecate `road_name` and `road_number`
-* Deprecate the `total_num_lanes` property on the `RoadEvent` object as the `RoadEvent`'s `lanes` array can be used to determine the number of lanes
-
-#### Fixes
-* Add optional `bbox` property to allow providing a [GeoJSON Bounding Box](https://tools.ietf.org/html/rfc7946#section-5) for the `WZDxFeed` and `RoadEventFeature` objects
-* Add an `id` property to the `RoadEventFeature` object for providing the a road event's identifier to better follow [GeoJSON ID recommendations](https://tools.ietf.org/html/rfc7946#section-3.2)
+### WZDx v4.0 (December 2021)
+WZDx version 4.0 implements clean up and small additions in functionality to the WZDx feed and adds definitions for two new feeds, the [SwzDeviceFeed](/spec-content/objects/SwzDeviceFeed.md) and [RoadRestrictionFeed](/spec-content/objects/RoadRestrictionFeed.md). Until version 4.0, the WZDx specification defined only one feed, the [WZDxFeed](/spec-content/objects/WZDxFeed.md).
+
+*For detailed release information, see [RELEASES.md](/RELEASES.md)*
+
+## Features
+- Add values to the [VehicleImpact](/spec-content/enumerated-types/VehicleImpact.md) enumerated type.
+- Allow restrictions with a value and unit to be provided at the road event level.
+- Add values to the [LaneType](/spec-content/enumerated-types/LaneType.md) enumerated type.
+- Define a new data feed, the [RoadRestrictionFeed](/spec-content/objects/RoadRestrictionFeed.md), to enable providing a feed of restrictions on roadways, such as bridge clearances.
+- Define a new data feed, the [SwzDeviceFeed](/spec-content/objects/SwzDeviceFeed.md), to enable equipment vendors and manufacturers to provide high-level information about deployed field devices in work zones.
+- Rename the `workers_present` property on the [WorkZoneRoadEvent](/spec-content/objects/WorkZoneRoadEvent.md) object to  `worker_presence`; change the type from "boolean" to a new [WorkerPresence](/spec-content/objects/WorkerPresence.md) object which enables providing more nuanced information about worker presence in work zones.
+
+## Refactoring
+- Separate the v3.1 RoadEvent object into [RoadEventCoreDetails](/spec-content/objects/RoadEventCoreDetails.md) (details that are shared by all specific types of road events) and specific types of road events ([WorkZoneRoadEvent](/spec-content/objects/WorkZoneRoadEvent.md), [DetourRoadEvent](/spec-content/objects/DetourRoadEvent.md), and [RestrictionRoadEvent](/spec-content/objects/RestrictionRoadEvent.md)) which each contain the `RoadEventCoreDetails` via a `core_details` property; update the [RoadEventFeature](/spec-content/objects/RoadEventFeature.md) `properties` property to be one of the specific road events types.
+- Move the `location_method` property from the [FeedDataSource](/spec-content/objects/FeedDataSource.md) object to the [WorkZoneRoadEvent](/spec-content/objects/WorkZoneRoadEvent.md) object.
+- Change the `reduced_speed_limit` property on the [WorkZoneRoadEvent](/spec-content/objects/WorkZoneRoadEvent.md) to `reduced_speed_limit_kph`; change its type from "integer" to "number" and clarify that the value should be in kilometers per hour.
+- Deprecate the `lane_number` property on the [Lane](/spec-content/objects/Lane.md) object.
+- Deprecate the `lrs_type` and `lrs_url` properties on the [FeedDataSource](/spec-content/objects/FeedDataSource.md) object.
+- Remove the deprecated value `alternating-one-way` from the [LaneStatus](/spec-content/enumerated-types/LaneStatus.md) enumerated type.
+- Remove all deprecated properties from the road event (RoadEvent in previous versions; [WorkZoneRoadEvent](/spec-content/objects/WorkZoneRoadEvent.md) and [RoadEventCoreDetails](/spec-content/objects/RoadEventCoreDetails.md) in 4.0).
+- Require the `road_names` property on the [RoadEventCoreDetails](/spec-content/objects/RoadEventCoreDetails.md).
+- Require the `id` property on the [RoadEventFeature](/spec-content/objects/RoadEventFeature.md).
+- Refine the [LaneType](/spec-content/enumerated-types/LaneType.md) enumerated type.
+- Deprecate the `location_verify_method` property on the [FeedDataSource](/spec-content/objects/FeedDataSource.md).
+- Update the [SpatialVerification](/spec-content/enumerated-types/SpatialVerification.md) enumerated type value descriptions to clarify that verified work zone locations should use a GPS enabled device.
 
 ## Getting Started
 
-The WZDWG welcomes feedback and comments on the WZDx 3.1 Specification. Comments can be made by posting a GitHub [Issues](https://github.com/usdot-jpo-ode/wzdx/issues) or [Discussions](https://github.com/usdot-jpo-ode/wzdx/discussions), while suggested changes can be made using a [Pull Request](https://github.com/usdot-jpo-ode/wzdx/pulls).
+The WZDWG welcomes feedback and comments on the WZDx v4.0 Specification. Comments can be made by posting a GitHub [Issue](https://github.com/usdot-jpo-ode/wzdx/issues) or [Discussion](https://github.com/usdot-jpo-ode/wzdx/discussions), while suggested changes can be made using a [Pull Request](https://github.com/usdot-jpo-ode/wzdx/pulls).
 
-1. Read about WZDWG activities [Wiki](https://github.com/usdot-jpo-ode/wzdx/wiki) and the [WZDx Early Adopter's Guide](/documents/WZDx_Early_Adopters_Guide.pdf)
+1. Read about WZDWG activities [Wiki](https://github.com/usdot-jpo-ode/wzdx/wiki) and the [WZDx Early Adopter's Guide](/documents/WZDx_Early_Adopters_Guide.pdf).
 2. Learn about using GitHub as a [tool for collaboration and support](/create-feed/README.md#collaborate-via-github).
-3. Use [Specification Content](/spec-content) page to understand the data components of the specification.
-4. [Create your own feed](/create-feed) using example feeds and follow the business rules.
+3. Read [Creating a WZDx feed](/Creating_a_WZDx_Feed.md) which contains information about creating a WZDx data feed, such as the feed format, business rules, and validation tools.
+4. Use the [Specification Content](/spec-content) page to understand the data components of the specification.
 5. Validate your feed output using the respective [JSON Schema](#json-schemas).
 6. Publish your feed and tell us about it via avdx@dot.gov.
 
@@ -122,9 +130,9 @@ The WZDx Specification defines a JSON schema for each feed within the [schemas](
 - [WZDx v4.0 RoadRestrictionFeed](/schemas/4.0/RoadRestrictionFeed.json)
 
 ### Previous Version
-- [WZDx v2.0 WZDxFeed](/schemas/wzdx_v2.0_feed.json)
-- [WZDx v3.0 WZDxFeed](/schemas/wzdx_v3.0_feed.json)
-- [WZDx v3.1 WZDxFeed](/schemas/wzdx_v3.1_feed.json)
+- [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)
 
 ## Contributions
 

RELEASES.md

@@ -1,3 +1,82 @@
+# WZDx Specification v4.0
+Released December 2021
+
+WZDx version 4.0 implements clean up and small additions in functionality to the WZDx feed and adds definitions for two new feeds, the [SwzDeviceFeed](/spec-content/objects/SwzDeviceFeed.md) and [RoadRestrictionFeed](/spec-content/objects/RoadRestrictionFeed.md). Until version 4.0, the WZDx specification defined only one feed, the [WZDxFeed](/spec-content/objects/WZDxFeed.md).
+
+## Features
+- Add the following values to the [VehicleImpact](/spec-content/enumerated-types/VehicleImpact.md) enumerated type:
+    - `some-lanes-closed-merge-left`
+    - `some-lanes-closed-merge-right`
+    - `all-lanes-open-shift-left`
+    - `all-lanes-open-shift-right`
+    - `some-lanes-closed-split`
+    - `flagging`
+    - `temporary-traffic-signal`
+- Allow restrictions with a value and unit to be provided at the road event level; specifically:
+    - Rename the LaneRestrictionUnit enumerated type to [UnitOfMeasurement](/spec-content/enumerated-types/UnitOfMeasurement.md).
+    - Rename the RoadRestriction enumerated type to [RestrictionType](/spec-content/enumerated-types/RestrictionType.md).
+    - Rename the LaneRestriction object to [Restriction](/spec-content/objects/Restriction.md) and remove the `lane_restriction_` prefix from its properties.
+    - Rename the [Restriction](/spec-content/objects/Restriction.md) object `units` property to `unit`.
+- Add values `parking` and `median` to the [LaneType](/spec-content/enumerated-types/LaneType.md) enumerated type.
+- Define a new data feed, the [RoadRestrictionFeed](/spec-content/objects/RoadRestrictionFeed.md) and [RestrictionRoadEvent](/spec-content/objects/RestrictionRoadEvent.md) to enable providing a feed of restrictions on roadways, such as bridge clearances.
+- Define a new data feed, the [SwzDeviceFeed](/spec-content/objects/SwzDeviceFeed.md), to enable equipment vendors and manufacturers to provide high-level information about deployed field devices in work zones. A `SwzDeviceFeed` contains a new feature type, the [FieldDeviceFeature](/spec-content/objects/FieldDeviceFeature.md), which contains information about a specific type of field device. The following field devices are defined in WZDx v4.0:
+    - `ArrowBoard`: An electronic, connected arrow board which can display an arrow pattern to direct traffic.
+    - `Camera`: A camera device deployed in the field, capable of capturing still images.
+    - `DynamicMessageSign`: An electronic traffic sign deployed on the roadway, used to provide information to travelers.
+    - `FlashingBeacon`: A flashing beacon light of any form (e.g. trailer-mounted, vehicle), used to indicate something or capture driver attention.
+    - `HybridSign`: A hybrid sign that contains static text (e.g. on an aluminum sign) along with a single electronic message display, used to provide information to travelers.
+    - `LocationMarker`: Describes any GPS-enabled ITS device that is placed at a point on a roadway to dynamically know the location of something (often the beginning or end of a work zone).
+    - `TrafficSensor`: A traffic sensor deployed on a roadway which captures traffic metrics (e.g. speed, volume, occupancy) over a collection interval.
+- Rename the `workers_present` property on the [WorkZoneRoadEvent](/spec-content/objects/WorkZoneRoadEvent.md) object to  `worker_presence`; change the type from "boolean" to a new [WorkerPresence](/spec-content/objects/WorkerPresence.md) object which enables providing more nuanced information about worker presence in work zones.
+
+## Refactoring
+- Separate the v3.1 RoadEvent object into [RoadEventCoreDetails](/spec-content/objects/RoadEventCoreDetails.md) (details that are shared by all specific types of road events) and specific types of road events ([WorkZoneRoadEvent](/spec-content/objects/WorkZoneRoadEvent.md), [DetourRoadEvent](/spec-content/objects/DetourRoadEvent.md), and [RestrictionRoadEvent](/spec-content/objects/RestrictionRoadEvent.md)) which each contain the `RoadEventCoreDetails` via a `core_details` property; update the [RoadEventFeature](/spec-content/objects/RoadEventFeature.md) `properties` property to be one of the specific road events types.
+- Move the `location_method` property from the [FeedDataSource](/spec-content/objects/FeedDataSource.md) object to the [WorkZoneRoadEvent](/spec-content/objects/WorkZoneRoadEvent.md) object.
+- Change the `reduced_speed_limit` property on the [WorkZoneRoadEvent](/spec-content/objects/WorkZoneRoadEvent.md) to `reduced_speed_limit_kph`; change its type from "integer" to "number" and clarify that the value should be in kilometers per hour.
+- Deprecate the `lane_number` property on the [Lane](/spec-content/objects/Lane.md) object.
+- Deprecate the `lrs_type` and `lrs_url` properties on the [FeedDataSource](/spec-content/objects/FeedDataSource.md) object.
+- Remove the deprecated value `alternating-one-way` from the [LaneStatus](/spec-content/enumerated-types/LaneStatus.md) enumerated type.
+- Remove the following deprecated properties from the road event (RoadEvent in previous versions; [WorkZoneRoadEvent](/spec-content/objects/WorkZoneRoadEvent.md) and [RoadEventCoreDetails](/spec-content/objects/RoadEventCoreDetails.md) in 4.0):
+    - `road_event_id`
+    - `road_number`
+    - `road_name`
+    - `total_num_lanes`
+- Remove the following deprecated values from the [LaneType](/spec-content/enumerated-types/LaneType.md) enumerated type: 
+    - `left-lane`
+    - `right-lane`
+    - `middle-lane`
+    - `center-lane`
+    - `right-shoulder`
+    - `left-shoulder`
+    - `right-second-exit-ramp`
+    - `left-second-exit-ramp`
+    - `right-entrance-exit-ramp`
+    - `left-entrance-exit-ramp`
+    - `hov-lane`
+    - `alternating-flow-lane`
+    - `reversible-lane`
+    - `right-entrance-lane`
+    - `left-entrance-lane`
+    - `left-entrance-ramp`
+    - `right-merging-lane`
+    - `left-merging-lane`
+    - `right-second-entrance-ramp`
+    - `left-second-entrance-ramp`
+- Require the `road_names` property on the [RoadEventCoreDetails](/spec-content/objects/RoadEventCoreDetails.md).
+- Require the `id` property on the [RoadEventFeature](/spec-content/objects/RoadEventFeature.md).
+- Refine the [LaneType](/spec-content/enumerated-types/LaneType.md) enumerated type; specifically:
+    - Rename `lane` to `general`.
+    - Remove `right-turning-lane` and `left-turning-lane`.
+    - Remove `right-exit-lane` and `left-exit-lane`.
+    - Add `exit-lane`.
+    - Remove `right-exit-ramp` and `left-exit-ramp`.
+    - Add `exit-ramp`.
+    - Remove `right-entrance-ramp` and `left-exit-ramp`.
+    - Add `entrance-ramp`.
+    - Add `entrance-lane`.
+- Deprecate the `location_verify_method` property on the [FeedDataSource](/spec-content/objects/FeedDataSource.md).
+- Update the [SpatialVerification](/spec-content/enumerated-types/SpatialVerification.md) enumerated type value descriptions to clarify that verified work zone locations should use a GPS enabled device.
+
 # WZDx Specification v3.1
 Released April 2021