Specification Update Subgroup

October 31, 2022

Meeting Information

Objectives

• Review proposed approaches to modifying the specification through Pull Requests (PRs).

Agenda

• Sign-in and Welcome
• Discuss v4.2 PRs
  • Link to Curb Data Specification – PR #326
  • Add Loops to Direction Enumeration – PR #356
  • Add Work Zone Type for Moving Work Zones – PR #351
  • Clarify Geometry Requirements – PR #358
  • Improve Lane Status Description - PR #357
• Action Items and Next Steps

Minutes

Review Timeline

Activity	Subgroup Meetings	Deadline
Start-up – Introductions, charter review, backlog grooming	October 3	N/A
Review and Prioritize Issues	October 3
Modify Specification Through PRs	October 3 October 31	All PRs finished: October 24
Review and Finalize Next Version	N/A	All PRs through QA/QC: October 31
Present and Vote on Changes	November 21	Voting period: Tentatively 11/22-12/7
Release New Version of Specification	N/A	Specification released: mid-December

Review v4.2 Pull Requests

Link to Curb Data Specification – PR #326

• The Open Mobility Foundation released CDS v1.0 in early May
• The spec allows for agencies to create curb zones and attach policies for users to ingest into transportation software
• We are proposing an intersection between WZDx and CDS
• With the proposed optional reference, a work zone event would be able to define curb zone(s) that it would impact.
  • Impacted zones will be listed in an array on the new CdsCurbZonesReference to limit the number of objects required

Add Loops to Direction Enumeration – PR #356

Inner and outer loop directions are included in TMDD but not in WZDx for an unknown reason

Adding these to the Direction enumeration would limit need to translate between inner/outer loop and N/S/E/W directions, or to not communicate direction altogether.

Value	Description
inner-loop	Road flow is in the clockwise direction of a ring road or beltway.
outer-loop	Road flow is in the counter-clockwise direction of a ring road or beltway.

Discussion:

• Lynne Randolph pointed out that TMDD uses inner loop and outer loop
• Jeremy Agulnek was concerned that we may not want to describe where the lanes are physically if we're dealing with temporary changes
• Adam Graham pointed out that the current definition (tied to clockwise/counter-clockwise) would make adoption in the UK difficult.
  • Mark Mockett agreed and noted that the co-chairs would work out better wording.

Add Work Zone Type for Moving Work Zones – PR #351

This issue was partly resolved in v4.1 by introducing new relationship type for mobile work zones to reference a planned extent or active work area

• But this solution doesn’t help in situations where only one event is available (either a planned extent or an active work area)

Proposed resolution:

• Add an optional property to the WorkZoneRoadEvent object to provide information about the specific type of the work zone, such as the planned extent of a mobile operation, using a new enumerated type.

New property on WorkZoneRoadEvent object:

Name	Type	Description	Conformance
work_zone_type	WorkZoneType (see above)	The type of work zone road event, if applicable.	Optional

New WorkZoneType enumerated type:

Value	Description
static	The road event statically placed — not moving.
moving	The road event is actively moving on the roadway. As opposed to planned-moving-area, the road event geometry changes as the operation moves.
planned-moving-area	The planned extent of a moving operation. The active work area will be somewhere within this road event. As opposed to moving, the road event geometry typically does not actively change.

Clarify Geometry Requirements – PR #358

Current WZDx geometry requirements are vague:

• The geometry of the road event. The Geometry object's type property MUST be LineString or MultiPoint. LineString allows specifying the entire road event path and should be preferred. MultiPoint should be used when only the start and end coordinates are known.

Proposed resolution: Add additional notes to geometry description and implementation guidance:

• The order of coordinates is meaningful: the first coordinate is the first (furthest upstream) point a traveler encounters when traveling through the road event.
• If a data producer has three or more coordinates that are on the road event path, LineString should be used because it indicates the points are ordered.
• Use a higher density of points points for sections of roadways with curves so a data consumer can more easily match to a their road network.

Discussion:

• Jeremy Agulnek noted that the guidance will be helpful if data producers adhere to it

Improve Lane Status Description - PR #357

The lane status enums for open and closed are:

• open: The lane is open to travel.
• closed: The lane is closed to travel.

This is confusing for lanes that are not typically used for travel. In the current spec, consider an open parking lane:

• lane 'type’ = parking and ‘status’ = open.
• Someone could read this as the lane is open for parking but the ‘open’ status description is the lane is open for travel.

Proposed resolution: Update the LaneStatus description for open and closed:

• Change open definition to "the lane is open for normal usage"
• Change closed definition to "the lane is open to normal usage"

Action Items and Next Steps

• Review and comment on pull requests on GitHub related to the WZDx Specification with feedback and potential fixes.
• Attend Work Zone Data Working Group meeting on November 21st.
• Vote on PRs for v4.2 after WZDWG meeting.
• Participate in Connected Work Zones standardization effort! Email [email protected] with subject line “CWZ Standard Working Group” to get involved.

Participants

Name	Affiliation
Petter Lemack	Applied Geographics
Marty Lauber	Arizona DOT
Adam Carreon	Arizona DOT
Mahsa Ettefagh	Booz Allen Hamilton
Ben Fischer	Butterfly Junction Technologies
David Aylesworth	CeVe
Jacob Larson*	City of Omaha
David Craig	General Motors
Jeremy Agulnek	HAAS Alert
Pete Krikelis	Hill and Smith
Jacob Brady*	IBI Group
Michelle Boucher	IBI Group
Jim Williams	INRIX
Dan Sprengeler	Iowa DOT
Sinclair Stolle	Iowa DOT
Skylar Knickerbocker*	Iowa State University
Will Martin	Leidos
Samer Rajab	Locomation
Alexander Lemka	Maricopa County DOT
Neil Boudreau	Massachusetts DOT
Nisar Ahmed	Metropolitan Transportation Commission (SF Bay Area)
Chris Brookes	Michigan DOT
Tony English	Neaera
Timothy Fiato	New York State DOT
Devorah Henderson	Qlynx Technologies
Nick Boltralik	SwRI
Lynne Randolph	SwRI
Jianming Ma	Texas DOT
Steven Parker	University of Wisconsin TOPS Lab
Mark Mockett	USDOT Volpe Center
Molly Behan	USDOT Volpe Center
Nate Deshmukh-Towery	USDOT Volpe Center
Chuck Felice	Utah DOT
Pier Castonguay	Ver-Mac
Todd Hartnett	Woolpert
Saman Jabari

* Co-Chair of the Specification Update Subgroup