WZDx Specification Update Subgroup Meeting #2, 2020 11 30

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