WZDx Specification Update Subgroup Meeting #2, 2020 11 30 - usdot-jpo-ode/wzdx GitHub Wiki

Virtual Attendees

Arizona Department of Transportation - Adam Carreon
Bentley Systems - Lee Jackson
Booz Allen Hamilton - Eric Ricciardi
Booz Allen Hamilton - Mahsa Ettefagh
Bureau of Transportation Statistics - Derald Dudley
City of Austin - Luke Urie
City of Raleigh - Beth Quinn
General Motors - David Craig
GEWI North America – Eli Sherer
HAAS Alert - Jeremy Agulnek
HERE Technologies – Jingwei Xu
HERE Technologies - Weimin Huang
IBI Group - Jacob Brady
iCone - Ross Sheckler
Institute of Transportation Engineers (ITE) – Siva Narla
Iowa DOT - Sinclair Stolle
Iowa State University - Skylar Knickerbocker
Maryland DOT - Carole Delion
Maryland DOT - Elise Feldpausch
Maryland DOT - Hua Xiang
Massachusetts DOT - Neil Boudreau
Metropolitan Transportation Commission (Bay Area) - Nisar Ahmed
Minnesota DOT - Cathy Huebsch
Missouri DOT - Dan Oesch
Noblis - Justin Anderson
Noblis - Kellen Shain
Oregon DOT - Chad Mann
OZ Engineering - Tomas Guerra
Panasonic - Lauren Cordova
Pennsylvania DOT - Dan Farley
Pennsylvania Turnpike - Mike Davidson
Regional Transportation Commission of Southern Nevada - Eneliko Mulokozi
San Francisco Municipal Transportation Agency - Alex Demisch
Seattle DOT - Craig Moore
Southwest Research Institute - Lynne Randolph
Southwest Research Institute - Sabrina Mosher
Texas DOT - Jianming Ma
TomTom - Rob Hoyler
Trillium - Thomas Craig
Uber ATG - Marysa Myers
University of Wisconsin - Yang Cheng
University of Wisconsin-Madison – Steven Parker
Utah DOT - Chuck Felice
Ver-Mac - Pier Castonguay
Virginia DOT - David Rush
Volpe - Wesley Alford
Washington State DOT - Tom Stidham
Woolpert - Michael Hanowsky
Woolpert - Qassim Abdullah
WSP - Virginia Lingham

Purpose and Intended Outcomes:

Discuss the prioritized list of WZDx Specification 'Issues' on GitHub
- Specifically, Issues tagged as "Release Candidate" and 'Need Discussion"
Identify member advocates for the prioritized issues

Agenda

Sign-in and Welcome
Group discussion - prioritized Issues for teh current cycle of specification development
Action items and next steps

Discussion Summary

PR #138: Refactor repository/documentation to follow an object model
- Walked through ‘Object Diagram’ graphic
- Jacob Brady explained the impact of these changes by pulling up the GitHub repository
- No comments from the subgroup membership on this issue
Issue ##142: Allow GeoJSON Bounding Box on the ‘WZDxFeed’ and ‘RoadEventFeature’ objects
- No comments from the subgroup membership on this issue
Issue #137: Refactor ‘LaneType’ enumeration: remove or deprecate values that reference a side or position on the roadway
- Jacob clarified and answered questions on the current specification’s stance with regards to lane types, specifically as it relates to using ‘LaneType’ to talk about more specific lane type scenarios
  - Jeremy/Lynne/Sabrina within subgroup’s membership posed questions
  - Skylar and David (Subgroup Co-Chairs) jumped in to provide additional clarity – e.g., why we don’t need a left-exit anymore, since the specification mandates that producers provide the number of lanes now (in short)
    - T-intersections or on an interstate were the only exceptions here when talking about right/left lanes
    - Struggled to provide verbiage that support left- or right-turn lanes
    - Describing what the middle lane of a T-intersection is the one use case where we boxed ourselves in to let the ‘right’ and ‘left-turning-lanes’ stay as is
  - What is an exit lane could go left on a freeway-to-freeway interchange?
    - David – say there is no shoulder, all the 1st lane can do is exist, lane #2 can go straight or exit. Towards the end of the meeting, we’ll talk about segmenting.
    - At that point, the ramp becomes an event itself. The ramp becomes two exit lanes, and therefore is another lane type, and therefore another event.
      - When lane count changes, you get a new road segmentation
- Craig – we need more discussion on whether certain use cases are lane types or road restrictions? Road restrictions might make more sense for a specific type of lane as opposed to creating a new lane type (Lynne from SwRI prompted further discussion with questions in the chat pod).
  - Should issues be handled through certain lane types of road restrictions, e.g., like a turn restriction?
  - This issue is focused on the cleanup of existing cases.
    - Make a second issues for other conflicts, e.g., left- or right-turns might be allowed, there’s commonality with issues in existing turns and right turns
    - Lynne agrees with this idea, i.e., making a new issue for it.
    - Action Item: Jacob will make a new issue, discussing what other lane types are needed and how to address certain scenarios that came up in the chat pod
      - We can move further discussion over to that new issue.
Issue #86: Local Access Only
- Background – current specification doesn’t have a ton of information on how to address local access only roadways, e.g., how Seattle DOT has closed certain roadways for only pedestrians during these COVID times, how can we represent this
Issue #6: Recurrent Events
- We need a solution that proposed some type of scheduling (currently proposed JSCalendar) for recurrent work zone activities (that occur over extended period of times/specific hours of work zone operation)
- Discussion isn’t on why we need to address this issue, but more so are folks comfortable with the solution proposed – JSCalendar or something else?
Issue #19: Include explicit licensing information in the metadata
- Derald covered the slide, no comments from the membership
Issue #139: New Event Types
- Background – agencies like New York State would like to see bridge strikes and other events included in the spec. to make travel safer and more efficient.
  - What types of events should be added? How do those impact the specification?
  - Subgroup membership agreed – talking about limiting factors with bridge heights is a good aspect/benefit to include in the specification.
    - There is way to represent/monitor low-bridge-type clearances already, through the ‘RoadRestriction’ enumerated type on ‘LaneEntity’ or ‘Road Event’ through the ‘restrictions’ array (“reduced height”)
    - Jeremy Agulnek (HAAS Alert) volunteered to joining a new subgroup around these specification extensions (like bridge strikes) if it forms.
Issue #140: Ambiguous value of ‘total_num_lanes’
- Lynne from SwRI proposed just deleting the value, Jacob is in agreement, as long as it’s clear that you have to provide values for all lanes if you’re providing it for some (can’t leave out lanes)
- A lot of discussion ensued in the chat around information on the numbering of lanes and how that information can be inferred from other specification values
Issue #128: Content/value of lrs_type is unclear
- Background – provide a little more information, what’s expected in the lrs_type, so as to remove ambiguity around what this “field” actually represents.
Issue #129: Improve machine-usability of location_verify_method
- How can we specify this to data producers? Is there a means/mechanism that producers have to provide centimeter/meter-level accuracy? What is that level of accuracy they can attain?
  - Action Item: Subgroup membership, please go on GitHub to generate discussion on this issue. Tell us what you think would be valuable as data producers or data consumers.
  - Is the level of accuracy that can be produced by data producers enough for data consumers, or the level of precisions that consumers require is different?
  - What are current producers using for a value for this field?
Issue #78: Conditions for breaking a work zone into multiple road events
- David explained the background and pulled up the graphic ‘Scenario 9: Complex Work Zone with Ramp’ on the GitHub Wiki to walkthrough this issue
  - Action Item: Subgroup membership, go to all these scenarios under ‘Discussions’ on the GitHub Wiki, comment on Scenario #9 as well as the other ones.
Next Steps and Action Items
- Ahead of meeting #3 tentatively scheduled for Friday, December 18th, 2020:
  - Review prioritized and additional issues on GitHub
  - Begin creating PRs in coordination with Co-Chairs by December 15th