Technical Assistance Subgroup Meeting #2 (February 9, 2021)

Presenters

• Shane Zumpf, Trihydro
• Chuck Felice, Utah DOT
• Curtis Hay, General Motors

Participants

• Eneliko Mulokozi, RTC of Southern Nevada
• Faisel Saleem, Maricopa County DOT
• Jainming Ma, Texas DOT
• Luke Urie, Austin Transportation Department
• Mahsa Ettefagh, Booz Allen Hamilton
• Todd Peterson, FHWA
• Skylar Knickerbocker, Iowa State
• David Craig, General Motors
• Wesley Alford, Volpe
• Nate Deshmukh Towery, Volpe
• Mark Mockett, Volpe
• Molly Behan, Volpe

Notes:

Demonstration Grants

Shane Zumpf presented a brief overview of the recently awarded WZDx demonstration grants. More information on the grants and projects can be found here. The following organizations received an award:

• County of Maricopa, AZ
• Metropolitan Transportation Commission, CA
• Colorado DOT
• Georgia DOT
• Iowa DOT
• Maryland State Highway Administration
• Massachusetts DOT
• Minnesota DOT
• St. Charles County, MO
• Utah DOT
• Virginia DOT
• Washington DOT
• Wisconsin DOT

Business Rules

Existing business rules which accompany the WZDx specification can be found on GitHub. Proposed new business rules will be voted on by WZDx members following the semi-annual meeting in March 2021. They are as follows:

1. The purpose of local access only can vary from jurisdiction to jurisdiction. For WZDx, local access only is intended to identify road segments where traffic whose final destination is outside of the road segment would treat the segment the same as a closure. Add local-access-only restriction PR#152
2. If lane information is provided (i.e. the lanes property on the RoadEvent is used), there must be an entry in the lanes array for every lane in the road event, not just a subset. Deprecate the total_num_lanes property on the RoadEvent object PR#148
3. A work zone is not inherently a single road event. If any property (restrictions, number of lanes, etc.) changes over the course of a work zone it can be segmented into multiple road events to enable geometries that display changes in the underlying work zone. A work zone must be segmented into separate road events when a required property of road event or lane object changes. A complex work zone can be linked together using the relationship property. Conditions for breaking a work zone into multiple road events #78
4. is_architectural_change is used to denote if the road event will cause an alignment change of greater than one meter in the geometry or architecture of the underlying road segment. Technical Support for is_architectural_change issue#96
5. The relationship property of the road event object has two uses when using multiple road events to denote a complex work zone.
   • The first road event should use the next relationship value and include an array of road_event_id(s) for all road events occurring after it. Each following road event in the complex work zone should have the relationship value first and include an array of road_events_id(s) that occur before it.
   • A road_event with a detour should have the child value and should include the road_event_id of the detour(s). A detour road event should include the relationship parent and include an array of road_event_id(s) that include or road events for which it serves as a detour.
6. The order property of the lanes object must serve as a unique identifier for lanes including non-driving lanes, e.g. shoulders. Lane number is an optional field that can be used to identify a subset of lanes such as driving lanes.

Please email [email protected] or [email protected] with any feedback on proposed business rules.

Resources

Chuck Felice presented several resources which can be found on the GitHub.

• The new Early Adopters’ Guide presents case studies from three early adopters and includes lessons learned to assist future spec adopters.
• The new Self-Validation Checklist allows data producers to verify that their feed is accurate and complete before submitting their feed to be included in the WZDx Feed Registry.
• The existing Annotated Examples document is available on GitHub and provides detailed diagrams of complex work zones and how to include them in a data feed.

Future Activities

Curtis Hay described the accomplishments completed by the subgroup this cycle.

• Publish early adopter implementation guides.
• Review current business rules and identify areas of the specification that could be enhanced by adopting new rules.
• Develop a self-validation checklist for new data feeds. He also described GM’s motivation for participating in the WZDx specification development process. As GM expanded their SuperCruise technology, it found work zones to be a key operational challenge. When a SuperCruise vehicle enters a work zone, it facilitates the handover of vehicle control from automated to manual. WZDx data will allow GM to anticipate where a work zone will occur and reduce the need to rely on work zone detection. Furthermore, WZDx data will inform GM of where it needs to perform private Lidar surveys to update maps of state and local roads.

Participants were polled on areas that the Technical Assistance Subgroup could provide help to their organizations.

Where does your organization need assistance (i.e., tools or guidance)?

• Incorporating data from lane closure permits (0%)
• Incorporating real-time data from contractors (17%)
• Collecting data for short-term work zones (or mobile work zones) (17%)
• Handling recurring work zones (17%)
• Creating complex work zones (17%)
• Getting institutional buy-in (33%)

Questions

The floor was opened for questions or feedback but none were received.