2021 07 29 WZDx Specification Update Subgroup meeting

Meeting Information

July 29, 2021, 1:00-2:00pm EDT

Purpose

• Continue discussion of potential approaches to address outstanding GitHub issues
• Review proposed approaches to modifying the specification through Pull Requests (PRs)
• Identify members to draft PRs for prioritized issues

Agenda

• Sign-in and Welcome
• Review Open PRs
• Discuss Other Outstanding Issues
• Action Items and Next Steps

Minutes

Open Pull Requests

#174 – reduced_speed_limit in MPH

• Resolves issue #169.
• Adds clarifying text to the description for the reduced_speed_limit property on the RoadEvent object indicating that the value should be in miles per hour.
• Clarifies that reduced_speed_limit only needs to be supplied if speed limit within road event is lower than the posted speed limit.

Discussion:

• Mike Hanowsky: Speed limits and speed guidance are different. Is there no way of indicating that speeds are reduced without knowing the value?
• Jacob: Those are good points but should be new issues to consider for next cycle. The purpose of this issue was just specifying units

#175 – Deprecate lane_number

• Resolves issue #153.
• Marks the lane_number property on the RoadEvent object as deprecated. This was discussed during the last cycle but didn’t make it into v3.1

#176 – Remove previously deprecated values

• Not connected to an issue
• Removes all object properties and enumerated type values that were marked as deprecated in the WZDx v3.1 release.
  • It was noted at the time of release and in the documentation that the deprecated elements would be removed in a future major WZDx version
  • Since the fall 2021 release will be v4.0 (major version change), WZDx is still in the earlier adoption phase, and there has been no objection during any subgroup meetings in the v4.0 development cycle to removing the deprecated fields, this change will happen for v4.0.
• For review: we don't expect objections to removing given small number of producers right now. If you have thoughts or the history of why they were deprecated, that's available on GitHub via reference.

#177 – Deprecate lrs_type and lrs_url

• Resolves issue #128.
• Deprecates the lrs_type and lrs_url properties from the RoadEventDataSource object.
• Original issue proposed adding enumerated types to make the field more useful, but previous discussions didn't generate any options and the field is not currently used.

Open Issues

#5 - exit lane types & #149 refactoring lane types

• #5 is about lane vs. ramp and whether direction of egress matters to consumers. Left/right isn't for the position, but the direction of egress - no one has expressed interest in keeping the egress direction
• #149 is more expansive and would drop. Lane types are not really to indicate position, and status is used for any real-time impacts on a lane
• Type would be used to represent the lane's function:
  • General
  • Sidewalk
  • Bike-lane
  • Exit-ramp
  • Entrance-ramp
  • Shoulder
  • Center-left-turn-lane
  • Parking (new)
  • Painted-median (new)
    • If a median is raised or grass used to separate roadway would indicate a separate roadway which should not be included in the same road event

Discussion:

• Opposition to dropping left and right?
• Opposition to dropping exit lane?
  • Neil: Massachusetts would use exit lane to represent an auxillary lane (exit-only or an entrance lane after it's been added). Ramp is after the gore point
  • Jianming: +1 to Neil's comment. Ramps and lanes are different.
  • Skylar: We also use entrance lane in Iowa but that's not in the spec - could we add that?
  • Neil: Point about NH having a high-speed interchange
• General or normal?
  • Jeremy: I like general
  • Neil: We use "general purpose lane" in traffic engineering
• Turning lanes would also be removed from lane types
• Reasons for limiting options?
  • Kali: The National ITS Architecture has the ability to add localized definitions. Is there a reason we're being so specific? In SoCal we call it SigAlerts and may have localized names that we use. Why not include that in WZDx?
  • Jacob: The specification should define a set of types and how they are used, and convert to WZDx for the purpose of dissemination
  • Eli: We can find a way to conform to this using other tools, this is about code for navigation providers and the standard can make them more interchangeable rather than focusing on vocabulary.
• Inclusion of sidewalk and bike lanes
  • Dave: A large amount of our consumers are mapping companies, which give directions for walking and biking as well. If we're closing off lanes and can also report that we're closing sidewalks or bike lanes, then we should because that's important to them. We don't want to imply that cars can drive on sidewalks, but if a road is torn up and a bike lane is torn up, then we should annotate that.
• Multiple lane types for a single lane
  • Vinod: Could we allow multiselect to allow for multiple uses?

#155 Add values to event-level restrictions

• The RoadEvent level restrictions currently only consist of a type, but no value. This issue details an option for reformulating the LaneRestriction object to be more general and use it for the restrictions property on a RoadEvent object
• Values in the Restriction object are still optional, so no additional information is necessary for a RoadEvent

#159 Vehicle impact

• Will create a PR with the additional enumerations proposed in the issue as well as:
  • all-lanes-open-shift-left and all-lanes-open-shift-right
• This should capture almost all lane level impacts available
  • Some vehicle impacts may be missing but should cover majority of situations

#129 Improve machine usability of location_verify_method

• Propose adding a verification method enumeration
  • Using GPS equipped devices
  • Using GPS equipped devices with continuous reporting
  • Field staff
  • Camera

#5 Recurring events

• Subgroup members discussed the best way to handle recurring events on Monday (July 26)
• Concluded that adding a “schedule” object to a road event would likely lead to worse accuracy in WZDx feeds b/c work zone properties frequently change each day (location, lanes closed, etc)
• Develop business rules formalizing using multiple road events for a recurring work zone
• Develop business rule with options to indicate relationship between recurring work zone events using ID and relationship properties

#125 Mobile work zones

• Co-chairs haven’t moved this issue forward much, but there are a few potential solutions:
• Add Boolean to RoadEvent indicate mobile work zone?
• Add business rules about updating location and using update_date?
• Issue overlaps with SWZ Subgroup – likely to hold a follow on meeting to get into this issue with both groups members

#184 Requiring update_date property

• Currently update_date is required on the feed-level RoadEventFeedInfo but optional on both the RoadEventDataSource and RoadEvent.
• Feed-level update_date doesn’t provide enough info to know whether RoadEvent info has been recently updated or confirmed.
• At a recent co-chairs meeting, the co-chairs realized it’s necessary to define when producers should to use this field. It’s unclear if the date should be when the information was last updated, when the feed was accessed, etc
• Probably can't be in the next release

Action Items

Next meeting tentatively scheduled for Thursday, August 19, 2021 Action items before next meeting:

1. Participate in discussion on issues and pull requests on GitHub related to the WZDx Specification and add suggested updates, comments, and any other feedback
2. Contribute to resolving issues by creating pull requests

The current deadline for finalizing pull requests for v4.0 is August 19, 2021.

Participants

Name	Organization
Jingwei Xu*	HERE Technologies
David Craig*	General Motors
Jacob Brady*	IBI Group
Skylar Knickerbocker*	Iowa State University
Lee Jackson	Bentley Systems
Mahsa Ettefagh	Booz Allen Hamilton
Eli Sherer	GEWI NA
Eric Kolb	Google
Jeremy Agulnek	HAAS Alert
Peter Krikelis	Hill and Smith
Ivo Kushkiev	Hill and Smith
Ross Sheckler	iCone
Jim Williams	INRIX
Sinclair Stolle	Iowa DOT
Hua Xiang	Maryland SHA
Neil Boudreau	Massachusetts DOT
Vinod Chandran	Navjoy Inc.
Navin Nageli	Navjoy Inc.
Frank Winters	New York State/NSGIC
Kellen Shain	Noblis
Kali Fogel	RIITS
Eneliko Mulokozi	RTC of Southern Nevada
Jianming Ma	Texas DOT
Rob Hoyler	TomTom
Yang Cheng	University of Wisconsin-Madison
Molly Behan	USDOT Volpe Center
Nate Deshmukh Towery	USDOT Volpe Center
Hadrian Merced Hernandez	USDOT Volpe Center
Mark Mockett	USDOT Volpe Center
Chuck Felice	Utah DOT
Tony Leingang	Washington State DOT
Qassim Abdullah	Woolpert
Michael Hanowsky	Woolpert

* Co-chair of the Specification Update Subgroup