2021 06 30 Specification Update Subgroup meeting

Purpose

• Review and discuss outstanding and new GitHub issues
• Identify member advocates for the prioritized issues

Agenda

• Sign-in and Welcome
• Review and Discuss Open Issues
• Discuss Issue Prioritization
• Action Items and Next Steps

Minutes

Review and Discuss Open Issues

15 current open issues:

• Lanes issues: #5, #149, #153 [closed: #154, #156]
• Restrictions and Impacts: #155, #159, #169
• Verification: #128, #129
• Recurring Events: #6, #125
• Being Addressed by Other Subgroups: #39, #78, #96, #139, #173

Don't need discussion

#	Description	Proposed Resolution
#128	Content/value of lrs_type unclear – could refactor into an object or retire if unused	Deprecate property
#153	Deprecating lane_number due to redundancy with order in Lane object	Deprecate property
#154	Require providing lane level info?	Closed issue - Not all feed producers not able to provide lane level info
#156	Specifying lane width on lane object as optional property	Closed issue – Lane width belongs in an “asset” layer. Could be addressed by Spec. Extension Subgroup.

Lanes

#5 - Exit Lane Types

• It is not clear if the lane types related to exit lanes/ramps should only be used when the roadway is a ramp or is this to be used for dedicated exit lanes (i.e. not through lanes).
• It is not clarified how an exit-ramp differs from an exit-lane, and some DOTs don't differentiate between them.
• Does the direction of egress matter to consumers? Lane order can be used to determine position, so is there value in left and right as part of those names?

#149 - Further simplification of lane types

• Lane type is an attribute of the base lane that doesn’t change, whereas lane status is the current status of the lane. Which types need clarification?
• Potential simplified lane types:
  • General/Normal/Travel/Main/Vehicle (need to choose one term)
  • Sidewalk
  • Bike lane
  • Exit ramp/lane (simplified)
  • Entrance ramp/lane (simplified)
  • Shoulder
  • Center left turn lane
  • Parking (new)
  • Median (new)
• Discussion:
  • Adding parking could be useful for specifying when travel can happen through a lane that is normally for parking
  • Median and parking lane is based on the SAE standard reviewed during lane types last time (J2735).
  • Craig: this cuts to the core of what the usage of the lanes is. We're often conveying mode and connectivity for past lane values - would be interesting to hear from consumers what they're using the info for (like how HOV lanes are restrictions). That's a battle with all specifications
  • Todd: The descriptions here are roadway specific - what about off-roadway bike lane or shared use path?

Restrictions and Impacts

#155 - Allowing restriction value and units for road event level restrictions

• Currently, restrictions at road event level only specify a type of restriction (such as “Reduced height”), but restrictions at the lane level allow specifying the value of the restriction (such as “Reduced height to 14 feet”)
• Proposal is to replace restriction property in road event with renamed Restriction object and rename the properties in the object to generalize.
• Discussion
  • Derald: The Spec. Extension Subgroup is talking about how to leverage WZDx to clearances, narrow widths, etc. This prepares the model for those changes as well.
  • Jacob: It doesn't require different information, just different formatting. Especially if we make restriction value and units optional.

#159 - Additional vehicle_impact enumerations to enable real time field data

• This issue proposes adding new values to the vehicle impact enumerated type to include some information reflected in lane status (shifts, merges), as well as additional info on the type of alternating flow (flagging, temp traffic signal).
• Discussion
  • Jacob: This provides options to expand the use of vehicle impact to relay some info about lane status even if lane information isn’t provided.
  • Skylar: The only other status that isn't here is "shift," which we should consider adding. Shifts can happen with lanes closed or all lanes open. If we go to all use cases then what's keeping them from providing lane level?
  • Weimin: The proposed addition to vehicle impacts is valuable to navigation applications (driver maneuver instructions)
  • Erin: We've been looking at mobile work zones? Might need to think about rolling closures. Also could remove alternating-one-way and do flagging and temp-traffic-signal as the only options.
  • Switching by time of day isn't here – consider adding a third new option for alternating by time of day.
  • Vinod: Flagging is being considered as part of worker presence - they're planning on changes to make it more granular, potentially in two places.
  • Todd: I recommend keeping alternating one-way because it's an operating paradigm not necessarily covered by flagging or temp traffic signal

#169 - Clarify units for reduced_speed_limit

• Potential solutions
  1. Require a certain unit (likely MPH based on discussion so far) for reduced_speed_limit specifically.
  2. Require a certain unit for all speed values in WZDx (which is only reduced_speed_limit now).
  3. Allow specifying the units for speed in the RoadEventFeedInfo (header) which applies to all information in the feed. This allows producers to indicate at the top-level what unit their used in the feed information. An example implementation of this would be adding a new property speed_units to the RoadEventFeedInfo.

Verification

#129 - Improve machine-usability of location_verify_method

• Intended for producers to indicate how the geometry of the road event was “verified” (if beginning or ending accuracy is marked as “verified”)
• What are producers using for this value now?
• Should this property be conditional: required if a road event’s spatial accuracy is marked as “verified”?
• Is there value in a “precision” property for specifying just the precision of the geometry (e.g. 0.1cm in the above example)?

Recurring Events

#6 - Recurrent events

• Last cycle the co-Chairs evaluated JSCalendar, which would require refactoring WZDx to adopt
• As an alternative, WZDx could take “inspiration” for specification and integrate some components of JSCalendar
  • JSCalendar utilizes a duration instead of an end date which may not be appropriate
• To consider:
  • How do you show active/verified work zone along with planned? Likely need two records
  • How do we utilize the start and end dates for planned work zones?
• Setting up a task force with data consumers from WZDx Extension Subgroup

Mobile work zones

• Need to add a field indicating mobile work zone?
• Indicate speed of work zone or periodically update location?
• Discussion:
  • There's no way good way represent mobile work zones right now. DOTs often make a road event for a long stretch of roadway where workers might be, even though the work zone only impacts a short segment
  • Ross: A mobile work zone could update on a 2-5 minute cycle, and include a location update time for the last time this specific work zone was updated. The advantage of an position update time is that you can specify when the position was updated separate from other information about the work zone.
  • Dave C: I think we want a boolean of a mobile work zone to tell you to look at the update time, and maybe a velocity of expected speed.
  • Vinod: I also think we should have another field to specify what is being done with the mobile work zone – maybe expanding type_of_work
  • Ross: Work changing the status of the road is important to know. Need more granularity in what is meant by an architectural change. Removing pavement markings, putting down temporary markings, removing those, putting down permanent markings…
  • Dave: We should make progress on this this cycle and discuss more next time. Start with a boolean?
  • Jacob: Or make a new event type for mobile work zones.
  • SWZ may need a different re-factoring of the specification

Issues being addressed by other subgroups

#	Description	Responsible Subgroup
#39	Modifying or creating new fields to best identify worker presence	Worker Presence Subgroup
#78	Conditions and guidance for how to partition complex work zones into multiple road events	Technical Assistance Subgroup
#96	Defining the parameters for is_architectural_change	Technical Assistance Subgroup
#139	What new event types to add to WZDx beyond work zone and detour	Specification Extension Subgroup
#173	Worker Presence: humans, equipment, both? Balancing reporting worker presence with trackable equipment	Worker Presence Subgroup

Next Steps

Next meeting tentatively scheduled for:

• Thursday, July 29, 2021

Action items before next meeting:

1. Participate in discussion on existing issues on GitHub related to the WZDx Specification and add suggested updates, comments, and any other feedback
2. Draft suggested specification changes on new branches
3. Create pull requests to discuss draft changes

Participants

Name	Organization
Jacob Brady*	IBI Group
David Craig*	GM
Skylar Knickerbocker*	Iowa State
Jingwei Xu*	HERE
Marysa Myers	Aurora Innovation
Mahsa Ettefagh	Booz Allen Hamilton
David Aylesworth	CeVe
Deepanshu Girdhar	Colorado DOT
Eli Sherer	GEWI
Weimin Huang	HERE
Michelle Boucher	IBI Group
Ross Sheckler	iCone
Sinclair Stolle	Iowa DOT
Hua Xiang	Maryland SHA
Neil Boudreau	Massachusetts DOT
Vinod Chandran	NavJoy
Frank Winters	New York State Geographic Information Office
Justin Anderson	Noblis
Kellen Shain	Noblis
Chris Parker	Pennsylvania Turnpike
Craig Moore	Seattle DOT
Jianming Ma	Texas DOT
Yaw Adu-Gyamfi	University of Missouri
Yang Cheng	University of Wisconsin-Madison
Derald Dudley	USDOT Bureau of Transportation Statistics
Molly Behan	USDOT Volpe Center
Nate Deshmukh Towery	USDOT Volpe Center
Hadrian Merced	USDOT Volpe Center
Chuck Felice	Utah DOT
Pier Castonguay	Ver-Mac
Ken Earnest	Virginia DOT
Tony Leingang	Washington State DOT
Kumaran Murugesan	Washington State DOT
Tom Stidham	Washington State DOT
Erin Schwark	Wisconsin DOT
Qassim Abdullah	Woolpert
Michael Hanowsky	Woolpert