Redesign the BeginLocation and EndLocation Data Frames to facilitate translating the WZDx specification into the geoJson specification.

[DeraldDudley]

Issue name: “Redesign the BeginLocation and EndLocation Data Frames to facilitate translating the WZDx specification into the geoJson specification.”

Work Zone Examples:
https://gist.github.com/DeraldDudley/ae492b090fdddca6574e72f804d9a2f5

Begin & End Location Examples: https://gist.github.com/DeraldDudley/d1155539e31467e5725eb9f6f7f0b3cf

Maricopa County WZD as a geoJson feed:
https://maps.bts.dot.gov/.well-known/wzd/maricopa_county_wzd.geojson

Maricopa County WZD feed Mapped as a geoJson Feature Collection:
https://gist.github.com/DeraldDudley/1c686933be7fbb99b96d7205f5ff79d9

Summary

The BeginLocation and EndLocation Data Frames in Version 1.0 of WZDx specification are difficult to translate into the geoJson specification because the fields are not normalized. Specifically, latitude-est, latitude-ver, longitude-ver, milepost-est, milepost-ver all contain data elements in the field name. To normalize the data, and thus ease the translation from WZDx to geoJson, I suggest the changes below.

Motivation

Work Zone Data is inherently spatial and temporal. By facilitating the use of the geoJson format publishers and consumers can leverage Geographic Information Systems and spatially enabled applications to quickly and easily visualize WZD information.

Proposed changes

Work Zone Feature

• Convert the Common Core Table to a spatial feature called WorkZone by adding a geometryType field and a geometry field.
• The geometryType field holds the kind of geometry being used to represent the work zone and is optional. Geometry types are enumerated in the geoJson specification.
• The geometry field holds the coordinates, or an array of coordinates, used to spatially define the work zone. This field is required if geometryType is not null.
• Add a demarcationMethod field in the common core table.
• demarcationMethod is required if the geometryType field is not null and represented as an Enumeration with the values of Verified or Estimated.
• Add a wzFeatureType field to the common core table
• wzFeatureTypes is required and represented as an Enumeration with the values of Work Zone, BeginLocation/Entry Point, and EndLocation/Exit Point. Work Zone feature types may be added to the specification as needed.

Work Zone Feature

Data Name	Data Type	Description	Conformance	Notes
geometryType	Enum: Point, Multipoint, LineString, MultiLineString, Polygon, or MultiPolygon	May be represented as any geometry type defined in the GeoJson Specification or a null value	Optional
geometry	coordinate(s)	A single coordinate or an array of coordinates.	Required if geometry type is not null	Coordinate strings and arrays formatted according to the geoJson spec
demarcationMethod	Enum: Estimated or Verified	Indicates how the geometry was defined.	Required if geometry type is not null
wzFeatureType	Enum	A description of the Work Zone Feature Type	Required
Identifier	Data Element	A unique identifier issued by the data feed provider to identify the work zone project or activity	Required	Request that this be a standardized identifier for a future version
Subidentifier	Data Element	A unique identifier issued by data feed provider that provides additional references to project or activity	Optional	This identifier may be used in more than one feed as a reference to an agency project number or permit ID
startDateTime	Data Element	The time and date when a work zone is established	Required	All date/time formats shall use ISO 8601 Data elements and interchange formats – Information interchange
startDateTimeAccuracy	Enum: Estimated or Verified	A measure of how accurate the start Date Time is.	Required
endDateTime	Data Element	The time and date when a work zone is removed	Required	All date/time formats shall use ISO 8601 Data elements and interchange formats – Information interchange
endDateTimeAccuracy	Enumeration: Estimated or Verified	A measure of how accurate the end Date Time is.	Required
wzStatus	Enum	The status of the work zone	Optional	See Enumerated Type Definitions
totalLanes	Data Element	The total number of lanes associated with the road segment designated by the workzone geometry	Optional	A segment is a part of a roadway in a single direction designated the work zone geometry
openLanes	Enum	The laneType that is opened on the road segment designated by the work zone geometry	Optional
closedLanes	Enum	The laneType that is closed due to the work zone on the road segment designated by the work zone geometry		More detailed lane impacts / status will be described in Version 2 of the specification
closedShoulders	Enum	An enumerated type identifying the shoulder lanes that are closed	Optional	To explicitly state that no shoulders are closed, use none
workersPresent	Data Element	A flag indicating that there are workers present in the work zone	Optional
reducedSpdPosted	Data Element	The reduced speed limit posted in the work zone	Optional
RoadRestrictions	Enum	One or more roadRestriction flags indicating restrictions apply to the work zone road segment associated with the work zone bounded by the work zone geometry	Optional	More details may be added to future WZDx versions; these are included as flags rather than detailed restrictions
Description	Data Element	Short free text description of work zone	Optional	This will be populated with formal phrases in a later WZDx version
issuingOrganization	Data Element	The organization issuing the data feed	Optional	Will create a list in a future version
timestampEventCreation	Data Element	The time and date when the activity or event was created	Optional
timestampEventUpdate	Data Element	The time and date when the activity or event was updated	Optional

• Provide TMDD Example
• Provide XML Example
• geoJson Example: https://gist.github.com/DeraldDudley/ae492b090fdddca6574e72f804d9a2f5

BeginLocation Feature

• Consider changing the feature name from BeginLocaton to wzEntryPoint because the BeginLocation descriptor maybe become ambiguous as the specification adds more spatial features.
• Extract the BeginLocation Data Frame from the common core to a spatial feature by adding a geometryType field and a geometry field.
• The geometryType field holds the kind of geometry being used to represent the BeginingLocation and is optional. Geometry types are enumerated in the geoJson specification.
• The geometry field holds coordinates, or an array of coordinates, used to spatially define the BeginLocation. This field is required if geometryType is not null.
• Add a demarcationMethod field in the common core table.
• demarcationMethod is required if the geometryType field is not null and represented as an Enumeration with the values of Verified or Estimated.
• Add a wzFeatureType field to the common core table
• wzFeatureTypes is required and represented as an Enumeration with the values of Work Zone, BeginLocation/Entry Point, and EndLocation/Exit Point. Work Zone feature types may be added to the specification as needed.
• Add an identifier field
• The identifier field serves as a foreign key and relates the BeginLocation feature to the WorkZone feature.
• Normalize the Milepost field by splitting it into two parts.
• The milepost field holds the milepost value.
• The mpDemarcationMethod field indicates how the milepost value was defined.

BeginLocation Feature

Data Name	Data Type	Data Description	Conformance	Notes
geometryType	Enum: Point, Multipoint, LineString, MultiLineString, Polygon, or MultiPolygon	May be represented as any geometry type defined in the GeoJson Specification or a null value	Optional
geometry	coordinate(s)	A single coordinate or an array of coordinates.	Required if geometry type is not null	Coordinate strings and arrays formatted according to the geoJson spec
demarcationMethod	Enum: Estimated or Verified	Indicates how the geometry was defined.	Required if geometry type is not null
wzFeatureType	Enum	A description of the Work Zone Feature Type	required
Identifier	Data Element	A unique identifier issued by the data feed provider to identify the work zone project or activity	Required	Request that this be a standardized identifier for a future version
roadName	Data Element	The name of the road on which the work zone applies which is known by the public	Required	Add a business rule that pulls data from a specified list or formal naming conventions, for example, (1) arterials comply with the USPS Street Suffix Abbreviations (USPS Pub 28); (2) all Interstates will be abbreviated as I-#, state route with the state abbreviation and then the number, etc.
roadNum	Data Element	The road number designated by a jurisdiction such as a county, state or interstate	Optional	Examples I-5, VT 133
roadDirection	Data Element	The designated direction of the roadName that is impacted by the work zone activity	Required	Example North (for I-5 North)
Milepost	Data Element	The linear distance measured against a milepost marker along a roadway where the work zone begins		A milepost or mile marker is a surveyed distance posted along a roadway measuring the length (in miles or tenth of a mile) from the south west to the north east. These markers are typically notated on State and local government digital road networks. Provide link to description of milepost method in metadata file (see Section 2.7).
mpDemarcationMethod	Enum: Estimated or Verified	indicates how the milepost value was defined
crossStreet	Data Element	The cross street along the roadway where the work zone area begins		Required when Road Classification is arterial

• Provide TMDD Example
• Provide XML Example
• geoJson Example: https://gist.github.com/DeraldDudley/d1155539e31467e5725eb9f6f7f0b3cf

EndLocation Feature

• Consider changing the feature name from EndLocaton to wzExitPoint because the EndLocation descriptor maybe become ambiguous as the specification adds more spatial features.
• Extract the EndLocation Data Frame from the common core to a spatial feature by adding a geometryType field and a geometry field.
• The geometryType field holds the kind of geometry being used to represent the EndLocation and is optional. Geometry types are enumerated in the geoJson specification.
• The geometry field holds coordinates, or an array of coordinates, used to spatially define the EndLocation. This field is required if geometryType is not null.
• Add a demarcationMethod field in the common core table.
• demarcationMethod is required if the geometryType field is not null and represented as an Enumeration with the values of Verified or Estimated.
• Add a wzFeatureType field to the common core table
• wzFeatureTypes is required and represented as an Enumeration with the values of Work Zone, BeginLocation/Entry Point, and EndLocation/Exit Point. Work Zone feature types may be added to the specification as needed.
• Add an identifier field
• The identifier field serves as a foreign key and relates the EndLocation feature to the WorkZone feature.
• Normalize the Milepost field by splitting it into two parts.
• The milepost field holds the milepost value.
• The mpDemarcationMethod field indicates how the milepost value was defined.

End Location Feature

Data Name	Data Type	Data Description	Conformance	Notes
geometryType	Enum: Point, Multipoint, LineString, MultiLineString, Polygon, or MultiPolygon	May be represented as any geometry type defined in the GeoJson Specification or a null value	Optional
geometry	coordinate(s)	A single coordinate or an array of coordinates.	Required if geometry type is not null	Coordinate strings and arrays formatted according to the geoJson spec
demarcationMethod	Enum: Estimated or Verified	Indicates how the geometry was defined.	Required if geometry type is not null
wzFeatureType	Enum	A description of the Work Zone Feature Type	required
Identifier	Data Element	A unique identifier issued by the data feed provider to identify the work zone project or activity	required	Request that this be a standardized identifier for a future version
Milepost	Data Element	The linear distance measured against a milepost marker along a roadway where the work zone begins		A milepost or mile marker is a surveyed distance posted along a roadway measuring the length (in miles or tenth of a mile) from the south west to the north east. These markers are typically notated on State and local government digital road networks. Provide link to description of milepost method in metadata file (see Section 2.7).
mpDemarcationMethod	Enum: Estimated or Verified	indicates how the milepost value was defined
crossStreet	Data Element	The cross street along the roadway where the work zone area begins		Required when Road Classification is arterial

• Provide TMDD Example
• Provide XML Example
• geoJson Example: https://gist.github.com/DeraldDudley/d1155539e31467e5725eb9f6f7f0b3cf

[DeraldDudley]

Updated the issue with a suggested data structure. Its normalized and should serves as a neutral specification that can be translated to and from multiple formats. Will update with TMDD, XML, and geoJson examples.

[Polly-Okunieff]

The WZDD attached estimated and verified to a point to distinguish how the location was measured, not specifically "accuracy". Most locations are currently assigned a location when placed on a map or located relative to a mile marker if designated in the field. Some were assigned during the planning process (and the actual placement may be different). An appropriate translation may be a flag that indicates that a location is verified using an accurate measuring method. Additionally, lat/long may have a different verification method than elevation. In most cases this won't be a problem except when a work zone snakes along a mountain or is on hilly terrain.

In addition, confidence was included as a statistical measure of accuracy. I did not see confidence in the list of attributes. This measure was recommended during the initial discussions on the WZDx 1.1.

wZFeatureType works to describe different spatial feature types. The MUTCD includes naming conventions for specific zones. The WZDD associates point and polyline features based on the zones. The WZDD used these zones to drive feature naming conventions (begin/end zone). See diagram below.

Polly Okunieff (ICF) on behalf of the FHWA Work Zone Data Initiative (WZDI)

[tfoster-vm]

Interesting information on the WZ spatial features diagram from MUTCD, in that most customers we have spoke with actually call the “Begin Location” the Taper Point and call the “Advanced Warning Location” the Start of the WZ. From: Polly-Okunieff <[email protected]> Sent: Thursday, October 3, 2019 7:32 AM To: usdot-jpo-ode/jpo-wzdx <[email protected]> Cc: Subscribed <[email protected]> Subject: Re: [usdot-jpo-ode/jpo-wzdx] Redesign the BeginLocation and EndLocation Data Frames to facilitate translating the WZDx specification into the geoJson specification. (#41) The WZDD attached estimated and verified to a point to distinguish how the location was measured, not specifically "accuracy". Most locations are currently assigned a location when placed on a map or located relative to a mile marker if designated in the field. Some were assigned during the planning process (and the actual placement may be different). An appropriate translation may be a flag that indicates that a location is verified using an accurate measuring method. Additionally, lat/long may have a different verification method than elevation. In most cases this won't be a problem except when a work zone snakes along a mountain or is on hilly terrain. In addition, confidence was included as a statistical measure of accuracy. I did not see confidence in the list of attributes. This measure was recommended during the initial discussions on the WZDx 1.1. wZFeatureType works to describe different spatial feature types. The MUTCD includes naming conventions for specific zones. The WZDD associates point and polyline features based on the zones. The WZDD used these zones to drive feature naming conventions (begin/end zone). See diagram below. [image]<https://user-images.githubusercontent.com/54638091/66126310-2be95a80-e5b7-11e9-8ec0-6d83f256a760.png> Polly Okunieff (ICF) on behalf of the FHWA Work Zone Data Initiative (WZDI) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#41>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AMWYPBTR22KWTSPIYGENXUTQMXQ5LANCNFSM4IWTPZCA>. F. TODD FOSTER, P.E. T: 888.488.7446 C: 651.263.8603 F: 418.654.0517 VER-MAC.COM<http://VER-MAC.COM>

[DeraldDudley]

The WZDD attached estimated and verified to a point to distinguish how the location was measured, not specifically "accuracy". Most locations are currently assigned a location when placed on a map or located relative to a mile marker if designated in the field. Some were assigned during the planning process (and the actual placement may be different). An appropriate translation may be a flag that indicates that a location is verified using an accurate measuring method. Additionally, lat/long may have a different verification method than elevation. In most cases this won't be a problem except when a work zone snakes along a mountain or is on hilly terrain.

In addition, confidence was included as a statistical measure of accuracy. I did not see confidence in the list of attributes. This measure was recommended during the initial discussions on the WZDx 1.1.

wZFeatureType works to describe different spatial feature types. The MUTCD includes naming conventions for specific zones. The WZDD associates point and polyline features based on the zones. The WZDD used these zones to drive feature naming conventions (begin/end zone). See diagram below.

Polly Okunieff (ICF) on behalf of the FHWA Work Zone Data Initiative (WZDI)

Would demarcationMethod enumerated with "Verified" and "Estimated" be a more accurate descriptor?

[DeraldDudley]

Updated the post.
Split the geometry field into geometryType and geometry.
Changed spatialAccuracy to demarcationMethod
Changed milepostAccuracy to mpDemarcationMethod
Dropped Feature Collection class.

[DeraldDudley]

geoJSon Work Zone Feature examples
https://gist.github.com/DeraldDudley/ae492b090fdddca6574e72f804d9a2f5

geoJson BeginLocation and EndLocation Features
https://gist.github.com/DeraldDudley/d1155539e31467e5725eb9f6f7f0b3cf

[DeraldDudley]

Updated the Post
Added links to geojson examples for Work Zone Features, Begin Location Features, and End Location Features.

[sknick-iastate]

If I am understanding this correctly, if I want to provide the begin and end locations I must include both as separate features? So in your begin and end location example (https://gist.github.com/DeraldDudley/d1155539e31467e5725eb9f6f7f0b3cf) I would just be replicating the data associated to each point?

[DeraldDudley]

If I am understanding this correctly, if I want to provide the begin and end locations I must include both as separate features? So in your begin and end location example (https://gist.github.com/DeraldDudley/d1155539e31467e5725eb9f6f7f0b3cf) I would just be replicating the data associated to each point?

Yes. Beginning and Ending Locations have different attributes and would therefor be different features.

[DeraldDudley]

Updated the post with a Maricopa County Example...

Maricopa County WZD as a geoJson feed:
https://maps.bts.dot.gov/.well-known/wzd/maricopa_county_wzd.geojson

Maricopa County WZD feed Mapped:
https://gist.github.com/DeraldDudley/1c686933be7fbb99b96d7205f5ff79d9

[Polly-Okunieff]

Begin/End Location is a point feature that includes lat/long, road name and/or number, roadDirection (cardinal value of the road direction). Sometimes the feature location is ambiguous due to the accuracy of the spherical coordinates, or two roads are too close together. The WZDD includes city/jurisdiction and state in the definition for geometric features particularly if the WZ starts in one state and ends in another; we did not include that in WZDx 1.1. From: Derald Dudley <[email protected]> Sent: Tuesday, October 8, 2019 11:21 AM To: usdot-jpo-ode/jpo-wzdx <[email protected]> Cc: Okunieff, Polly <[email protected]>; Comment <[email protected]> Subject: Re: [usdot-jpo-ode/jpo-wzdx] Redesign the BeginLocation and EndLocation Data Frames to facilitate translating the WZDx specification into the geoJson specification. (#41) If I am understanding this correctly, if I want to provide the begin and end locations I must include both as separate features? So in your begin and end location example (https://gist.github.com/DeraldDudley/d1155539e31467e5725eb9f6f7f0b3cf) I would just be replicating the data associated to each point? Yes. Beginning and Ending Locations have different attributes and would therefor be different features. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#41>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ANA3MCZP3JJAFJ3OR6LJK7DQNSQPDANCNFSM4IWTPZCA>.

[j-d-b]

This is resolved in the GeoJSON formatting (#53) and Relational Data Model (#54) implemented for the v2 release.