Specification Update Subgroup meeting, June 2022

Specification Update Subgroup

June 7, 2022

Meeting Information

Objectives

• Review proposed approaches to modifying the specification through Pull Requests (PRs).
• Review and discuss issues not being resolved this cycle.

Agenda

• Sign-in and Welcome
• Highlight Pull Requests (PRs) from Other Subgroups
• Review Previously Discussed PRs
• Discuss New PRs
  • Refactor Relationships & Mobile Work Zones – PR #322
  • Add Undefined and Unknown Directions– PR #304
  • Add No Passing Restriction– PR #306
  • Rename center-left-turn-lane – PR #314
• Updating Examples on GitHub
• Review Issues Not Resolved This Cycle
• Action Items and Next Steps

Minutes

Highlight PRs from Other Subgroups and Previously Discussed PRs

For those who haven't attended other subgroup meetings, we wanted to highlight the PRs that those groups have discussed in case folks want to join in on discussion.

Smart Work Zone Device Subgroup

Allow providing a field device without providing a road name  – PR #309

• Change the conformance of the road_names property on the FieldDeviceCoreDetails from “Required” to “Optional”.
• This allows producers of a SwzDeviceFeed to provide a field device without having to try to determine the name of the road it is deployed on, simplifying manual entry or internal processes for producers.

Allow a LocationMarker to mark any delineation point in a work zone – PR #311

• Add a delineator value to the MarkedLocationType enumerated type.
• Use for a generic delineation point in a work zone. This value can be used for most types of marked locations that don't match any of the other values.
• Add a ramp-closure value to the MarkedLocationType enumerated type.
  • The start of a closed ramp onto or off a main road or highway.
• Add a road-closure value to the MarkedLocationType enumerated type.
  • The start of a closed road.

Enable the DeviceFeed to describe temporary traffic signals - PR #313

• Create a new TrafficSignal field device object that allows representing a traffic signal in a WZDx DeviceFeed as its own object with specific properties that apply to it.
  • Has "core_details" and "mode" properties
• Create a new TrafficSignalMode enumerated type, used by the TrafficSignal
• Deprecate the "temporary-traffic-signal" value on the MarkedLocationType enumerated type.

Previous meeting notes highlight other subgroup PRs here.

Specification Update Subgroup

Refactor and clarify event status and start/end date verification – PR #294

• This PR follows a similar approach to #281
• Changes to WorkZoneRoadEvent and DetourRoadEvent.
• Deprecate the event_status, start_date_accuracy and end_date_accuracy properties.
• Add new boolean properties is_start_date_verified and is_end_date_verified
  • Indicates if work has been confirmed to have started, such as from a person or device in the field or a report from a traffic management center.

Clarify usage of update_date - PR #302

\	RoadEventCoreDetails update_date	FieldDeviceCoreDetails update_date
Current	The UTC time and date when the activity or event was updated.	The UTC time and date when the field device information was updated.
Proposed	The UTC date and time when any information in the RoadEventFeature (including child objects) that the RoadEventCoreDetails applies to was most recently updated or confirmed as up to date.	The UTC date and time when any information in the FieldDeviceFeature (including child objects) that the FieldDeviceCoreDetails applies to was most recently updated or confirmed as up to date.

Previous meeting notes highlight other Specification Update Subgroup PRs here.

Refactoring Relationship Object - PR #322

The relationship object is intended to be used to specify relationships between road events. Currently, it is not well defined how different types of relationships should be specified.

Some features of the current proposed model are:

• The RelatedRoadEventType enumeration below relates road events in a spatial or temporal sequence back to the first road event.
• There are two options for how these relationships could be used to relate groups of road events to other groups (i.e. a road event with multiple events)
• See below for full enumeration of relationship types.

New property on RoadEventCoreDetails

Property Name	Value	Description	Conformance	Notes
Array; [RelatedRoadEvent]	A list describing road events which are related to this road event. Examples of related road event include but are not limited to the sequence along the roadway, recurring work zones, related detours or other road events that encompass a similar work area.	Optional

The RelatedRoadEvents object is used to identify another road event that is related to a road event.

Property Name	Value	Description	Conformance	Notes
type	RelatedRoadEventType	The type of relationship with the road event being identifed, such as another sequence of related work zones, a detour, or next road event in sequence.	Required
id	String	An identifier for the related road event by the type property. The value of this property should correspond to the id of a RoadEventFeature within the same WZDx feed.	Required

RelatedRoadEventType Enumerated Type describes a type of related road event, such as a work zone project, recurrent work zone, or detour-type road event.

Value	Description
first-in-sequence	The first road event in a sequence of road events that together describe a full work zone or detour
next-in-sequence	The next (subsequent) road event in a sequence of road events that together describe a full work zone or detour
first-occurrence	The first road event in the first occurrence in time of a recurrent work zone.
next-occurrence	The first road event in the next occurrence in time of a recurrent work zone.
related-work-zone	The first road event of related work zones (i.e. not part of a sequence of road events or recurrent work zone)
related-detour	The first road event of related detours (i.e. not part of a sequence of road events)
planned-moving-operation	The first road event of a related planned moving operation work zones (i.e. not part of a sequence of road events)
active-moving-operation	The first road event of a related active moving operation work zones (i.e. not part of a sequence of road events)

This issue also partially resolves the Mobile Work Zones issue

• Proposed RelatedRoadEvent object with planned-moving-operation and active-moving-operation relation types
• Unable to identify that a future road event is going to be a moving operation because there would be no active moving operation to be related to

Adding 'undefined' and 'unknown' for event direction - PR #304

• Currently direction is limited to one of four options (north-, south-, east-, or westbound) based on the signed route the event is occurring on, but that limits data producers.
• Many existing permitting and work zone management systems do not include a direction attribute
• New values would allow for data consumers to produce more accurate depictions of data

Proposed additional enumerations:

Value	Description
northbound	Road flow is in the northbound direction
eastbound	Road flow is in the eastbound direction
southbound	Road flow is in the southbound direction
westbound	Road flow is in the westbound direction
NEW undefined	Road flow does not have a signed direction. For a RoadEventFeature, the first and last coordinates in the feature's geometry represent the beginning and end of the road event in the direction of travel it impacts.
NEW unknown	Road flow may have a signed direction, but the affected direction of travel is not known

Passing Lanes - PR #306

Currently, it is not clearly stated how passing lanes primarily used by traffic in the opposite direction should be included in WZDx

• In examples posted in Discussion #131, the passing lane (opposing travel lane) is indicated as lane 1 with type general since it can be used for travel in the positive direction

Proposal: add a no-passing restriction and represent only lanes used for primary travel direction (i.e. from the yellow centerline to the road edge on a two-direction road) Description based from MUTCD

• no-passing: Crossing the center line markings for passing is prohibited.

Rename center-left-turn-lane to accommodate left-side driving - PR #314

• Deprecate the center-left-turn-lane value on the LaneType enumerated type.
• Add two-way-center-turn-lane value to the LaneType enumerated type.
• Makes the spec extensible to areas with left-side driving

Updating Examples on GitHub

WZDx GitHub has a section for examples here

Adding graphics: The examples on GitHub currently reference an old discussion post about lane configurations that is now out of date. The co-chairs are planning to add annotated diagrams corresponding to the example within the README, and storing the originals on GitHub for future changes

Co-chairs will also add new examples demonstrating proposed updates to the spec:

• Mobile work zones
• Other new relationship types

Are there other situations that should be included?

Discussion

Dan: As long as you've got the basic blocks, then you should be able to represent anything. Chris B.: When you have a double lane closure and then go to a single lane closure, or have a lane drop. Sometimes lane numbers change and work zone ties in to that (i.e. drop work zone but not pick up another lane). Moreso the double lane closure to single lane closure.

• Dan: We coordinate the lane drop at a ramp - is that what you're talking about? Because that would definitely renumber things.
• Chris: I think this example is in number 6, where you go back to a single lane closure
• Dan: i.e. a long term closure for the top lane, and then an additional closure overnight for the second lane.
• Skylar: We could add a couple different examples related to this. And then introduce other concepts from WZDx to show a complete example of all the functionality. Most of what we've show up to this point is relatively simple - it would be good to show these more complex scenarios.
• Chris B.: An actual split merge with express and local lanes would be good. The interesting thing to show with that - exits that can be accessed vs. not accessed.
• Sinclair: I have another one, where you send traffic across to a lane used for the opposite direction.

Participants

Name	Organization
Marty Lauber	Arizona DOT
Lee Jackson	Bentley Systems
Mahsa Ettefagh	Booz Allen Hamilton
Ben Fischer	Butterfly Junction Technologies
Jacob Larson*	City of Omaha
Weimin Huang	HERE
Todd Hartnett	Hill and Smith
Pete Krikelis	Hill and Smith
Jacob Brady*	IBI Group
Michelle Boucher	IBI Group
Sinclair Stolle	Iowa DOT
Dan Sprengeler	Iowa DOT
Skylar Knickerbocker*	Iowa State University
Siva Narla	ITE
William Martin	Leidos
Samer Rajab	Locomation
Alexander Lemka	Maricopa County DOT
Neil Boudreau	Massachusetts DOT
Chris Brookes	Michigan DOT
Justin Anderson	Noblis
Kellen Shain	Noblis
Chad Mann	Oregon DOT
Yang Cheng	University of Wisconsin-Madison
Deb Curtis	USDOT Federal Highway Administration
Mark Mockett	USDOT Volpe Center
Molly Behan	USDOT Volpe Center
Nate Deshmukh Towery^	USDOT Volpe Center
Chuck Felice	Utah DOT
Erin Schwark	Wisconsin DOT
Michael Hanowsky	Woolpert

* Co-Chair of Spec Update Subgroup
^ Co-Chair of Work Zone Data Working Group