2022 10 03 Specification Update Subgroup meeting

Meeting Information

Date

October 3, 2022

1:00pm EDT

Objectives

• Discuss the approach to a final round of specification updates
• Review outstanding issues and possible resolutions
• Outline next steps and action items

Agenda

• Sign-in and Welcome
• WZDx v4.1 and TDx v1.1
• About the Short Specification Development Cycle
• Review Closed Issues
• Discuss Outstanding Issues
• Action Items and Next Steps

Minutes

Co-Chair Introductioins

• Adam Graham – Chief Product Officer, one.network
• Skylar Knickerbocker – Research Engineer, Iowa State University Institute for Transportation
• Jacob Brady – Software Developer, Intelligent Systems Development, IBI Group
• Jacob Larson – Applications Analyst, City of Omaha Parking and Mobility Division

WZDx v4.1 and TDx v1.1

The new version of the WZDx specification is out now, and work is now hosted on two different GitHub sites:

Work Zone Data Exchange v4.1

Feed Specifications

• Work Zone Feed
• Device Feed

Specifications are to be standardized under Connected Work Zones effort

URL: https://github.com/usdot-jpo-ode/wzdx/

Transportation Data Exchange v1.1

Feed Specifications

• Road Restriction Feed
• Road Incident Feed

Specifications will be maintained by new incarnation of Work Zone Data Working Group

URL: https://github.com/usdot-jpo-ode/tdx/

About the Short Specification Development Cycle

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 Early November	All PRs finished: October 24
Review and Finalize Next Version	N/A	All PRs through QA/QC: October 31
Present and Vote on Changes	Mid-November	Voting period: Tentatively 11/22-12/7
Release New Version of Specification	N/A	Specification released: mid-December

Review Closed Issues

Add Update Date for Location Info - Issue #236

• Discussed adding a property to capture when location of a road event was last updated because current update_date property doesn’t describe what properties changed
• Closed due to lack of interest from data consumers and improvements to definition of when RoadEventCoreDetails update_date should be updated

Accuracy of Intermediate Points - Issue #232

• Issue created to discuss including accuracy/verification parameters for more than just for the beginning and ending points
• Would have added complexity to the spec and was unlikely to be used by data producers
• Issue closed due to lack of interest in intermediate verification

Refactor Positional Accuracy - Issue #233

• Issue created to discuss moving all spatial accuracy/verification properties to a new object
• Closed due to lack of interest

Allow Point for Road Event Feature - Issue #297

• WZDx has always required at least a start and end point for any road event, though the specification can’t test well for edge cases (like a feed providing the same start and end point)
• This issue was opened earlier in 2022 to
• After further discussion, co-chairs support current implementation which emphasizes that road events should have at least a start and an end point.
  • It is valid to include an event with a single lat/lon pair but is not recommended.

Discuss Outstanding Issues

Link to Curb Data Specification - Issue #241, 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

Discussion

• Jeremy addended the workshop about CDS at ITS World Congress and think the linkage is great

Add Loops to Direction Enumeration - Issue #324

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:

• Nisar (MTC) asked about including both as a Direction enumerated type. MTC's system deals with a lot of local road events, on roads that don't have dividers but a single pavement where traffic moves in both directions, closed from intersection to intersection.
  • Skylar: The most challenging aspect of using both would be: how do we define which roadway types are allowed to use "both" as a direction and which are not?
  • Nisar: The practice of duplicating road events to apply to both directions seems like a practice that should clearly be stated in the specification. For local roads, it's too much work.
  • Jeremy: What about a software fix? Is there some way that the software could duplicate it?
  • Nisar: These are really small cities that maintain information manually with limited resources
  • Adam: We can help change this over to a compliant feed
  • Nisar: We have larger cities that produce WZDx, which we pull and convert. Smaller cities will use a tool that we're developing for them.

Mobile Work Zones - Issue #125

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)

Possible 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.

Discussion:

• Why does the current proposal use "mobile" and "moving" work zone?
  • Moving would be the preferred word to be consistent between this enumeration and previous use.
• Do we want a generic work zone, just so that the purpose of the enumeration is clear?
  • A "general" enumerated value has no value compared to not including the property
  • If we don't have any other types of enumerations - reframe around moving work zones.

Clarify Geometry Requirements - Issue #194

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.

Some questions:

• Is there a minimum number of points that can go in a LineString or MultiPoint? The spec references begin/end points but schema doesn’t require them
• Does a LineString need to follow road curvature?
• How do we draw a LineString if basing points primarily on GPS waypoints?
• If a producer only has the start and end point, can they use LineString? Or should they only use MultiPoint?
• Data consumers prefer having multiple points along a curve to match an event up with their road network. How many are needed?

Discussion:

• Kali Fogel: Supplying the road network in addition to where the event is occurring - this is the method used for LRMS. GeoJSON is good

Improve Lane Status Description - Issue #237

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.

Possible resolution: Update the LaneStatus description from "the lane is open/closed for travel" to "the lane is open/closed to normal usage"

Also note: LaneType also doesn’t indicate what normal usage is for the type of mode

Action Items and Next Steps

• Review and comment on existing issues and pull requests on GitHub related to the WZDx Specification with feedback and potential fixes.

Participants

Name	Affiliation
Adam Carreon	Arizona DOT
Jacob Larson	City of Omaha
Brandon Patocka	City of Omaha
David Craig	General Motors
Eli Sherer	GEWI
Jeremy Agulnek	HAAS Alert
Weimin Huang	HERE
Pete Krikelis	Hill and Smith
Jacob Brady	IBI Group
Skylar Knickerbocker	Iowa State University
Will Martin	Leidos
Kali Fogel	Los Angeles County Metropolitan Transportation Authority
Alexander Lemka	Maricopa County DOT
Nisar Ahmed	Metropolitan Transportation Commission (SF Bay Area)
Tony English	Neaera
Jacob Frye	Neaera
Tim Fiato	New York State DOT
Kellen Shain	Noblis
Adam Graham	one.network
Chad Mann	Oregon DOT
John Copple	Sanborn Mapping Company
Nick Boltralik	Southwest Research Institute
Sabrina Mosher	Southwest Research Institute
Donald Funk	University of Maryland
Yang Cheng	University of Wisconsin-Madison
Derald Dudley	USDOT Bureau of Transportation Statistics
Todd Peterson	USDOT Federal Highway Administration
Murat Omay	USDOT ITS Joint Program Office
Mark Mockett	USDOT Volpe Center
Molly Behan	USDOT Volpe Center
Chuck Felice	Utah DOT
Pier Castonguay	Ver-Mac
Tony Leingang	Washington State DOT
Erin Schwark	Wisconsin DOT
Michael Hanowsky	Woolpert