Specification Update Subgroup meeting 05 27 2021 - usdot-jpo-ode/wzdx GitHub Wiki

Specification Update Subgroup meeting
May 27, 2021 at 1:00 pm ET

Purpose

  • Formally re-launch the Specification Update Subgroup and introduce co-chairs
  • Discuss subgroup’s updated charter and planned activities for this cycle
  • Clarify member roles and opportunities for involvement
  • Review GitHub best practices and backlog grooming
  • Outline next steps and action items

Agenda

  • Sign-in and Welcome
  • Introduce Co-Chairs and Review Subgroup Roles, Responsibilities, and Objectives
  • Review Issue/Pull Request Creation and Best Practices on GitHub
  • Prioritization of issues and open discussion
  • Action Items and Next Steps

Notes

Co-chair introductions

  • Skylar Knickerbocker – Research Engineer, Iowa State University Institute for Transportation
  • Jingwei Xu – Principal Architect, HERE Technologies
  • David Craig – Chief of Maps, General Motors Vehicle Engineering Center
  • Jacob Brady – Software Developer, Intelligent Systems Development, IBI Group

Charter Scope and Activities

Purpose

  • Chartered under the broader WZDWG, the WZDx Specification Update Subgroup is the lead steward in making changes to version 3.1 of the WZDx Specification and managing the future development of the specification.

Scope

  1. Review version 3.1 of the WZDx Specification
  2. Identify how the specification may be expanded/narrowed to better meet stakeholder needs
  3. Recommend specification changes to the broader WZDWG
  4. Grooming the backlog for potential, future changes to the specification

Objectives

  1. Provide opportunities for WZDWG members to propose improvements to the specification.
  2. Review the current WZDx Specification and any comments made on the specification on GitHub or received via email from data producers/users.
  3. Recommend incremental changes to the current WZDx Specification that will better meet the current and future needs of the data producers/users of work zone activity data.
  4. Groom the backlog of potential future changes and sources of technical input.
  5. Refine the WZDWG process for updating, testing, and publishing future versions of the WZDx Specification.
  6. Support open scalable standards that accommodate diverse mission needs for the creation, consumption, mapping, publication, and analysis of work zone event information.

Prioritization of issues and open discussion

Lanes issues

  • Exit lane type enumerations - #5
    When and how to use the exit ramp laneType enumerations
  • New lane types - #149
    What new lane types should be added
  • Utility of lane_number: time to deprecate? - #153
    Is there a reason to keep lane_number?
  • Require providing lane-level information? - #154
    Value in requiring lane-level information
  • Allow specifying lane width via an optional width property on the Lane object - #156
    Include lane width as optional property
  • Additional vehicle_impact to enable real time field data - #159
    New road level impacts to communicate better road information

Verification issues

  • Content/value of lrs_type is unclear - #128
    LRS info could be refactored into an LRS object with three properties
  • Improve machine-usability of location_verify_method - #129
    Information could be added to the road_event_data_source to make it more machine readable

Recurring Events

  • Recurrent Events - #6
    Proposals for how to include recurring events
  • Mobile Work Zones - #125
    Determining the approach to integrating mobile work zones

Being Addressed by Other Subgroups

  • Workers Present Data Field - #39
    Modifiying or creating new fields to best identify worker presence
  • Conditions for breaking a work zone into multiple road events - #78
    Guidance for how to partition complex work zones
  • Technical Support for is_architectural_change - #96
    Defining the paramaters for is_architectural_change

Other issues

  • New event types #139 What new event types to add to WZDx beyond work zone and detour
  • Allow restriction value and units for road event level restrictions - #155
    Incorporating restriction values affecting all lanes
  • Clarify units for reduced_speed_limit - #169
    Approaches for adding units to reduced_speed_limit at RoadEvent level

Discussion

  • Vinod: I just joined the group. We have a small team looking to implement this on our platform. This is a really good spec The biggest thing I’m seeing is that WZDx has a lot of useful data points, but it’s an overwhelming ops-heavy piece. It would be nice to include things like lifecycle upfront so that DOTs can plan and use WZDx before things get into motion. Connected to that: the number of required fields seems high and could deter users. Google/GM probably need a smaller subset of the data while people planning the work zones might need all the fields.
  • Skylar: We do have the ability to indicate whether a work zone is “planned” or “active” but most of the spec is meant to translate what is active on the roadway.
  • Dave: We’ve been talking about a calendar, and the recurring events fall into this. We’ve been struggling to find a good way to implement. We’d love to have your input on this to see how we could do a calendar and integrate scheduling ahead of time.
  • Vinod: Everything in the spec is needed, but if you don’t get engagement upfront people won’t engage or use the spec well.
  • Skylar: We’re struggling in Iowa to get planned information so that it doesn’t need to be inputted as the work zone is closed.
  • Paul Jodoin: FHWA has been working on some TIM data efforts for a while that aligns a lot with WZDx. Having managed operations I couldn’t agree more: the more complex the spec is, the less successful it will be. I’m surprised there won’t be identification of lanes?
  • Skylar: Lane level details are optional. We’ve tried to be conscious of what agencies are able to provide at this point. We’re discussing making lane level information required.
  • Paul: That could be complicated since lanes change during construction.

Action Items

Next meeting tentatively scheduled for Thursday, June 24, 2021
Action items before next meeting:

  1. Review existing issues on GitHub related to the WZDx Specification and add suggested updates, comments, and any other feedback
  2. Create new issues on GitHub to be considered in the next version of the Specification

Attendees

Name Organization
Dave Craig* GM
Skylar Knickerbocker* Iowa State University
Jacob Brady* IBI Group
Jingwei Xu* HERE
Pat Zelinski AASHTO
Adam Carreon Arizona DOT
Joe D'Ginto Aurora Innovation
Luke Urie Austin Transportation Department
Mahsa Ettefagh Booz Allen Hamilton
Eric Kolb Google
Jeremy Agulnek HAAS Alert
Todd Hartnett Hill and Smith
Michelle Boucher IBI Group
Ross Sheckler iCone
Avery Ash Inrix
Jim Williams Inrix
Dan Sprengeler Iowa DOT
Neil Boudreau Massachusetts DOT
Vinod Chandran Navjoy
Frank Winters New York State Geographic Information Office, NSGIC President
Justin Anderson Noblis
Kellen Shain Noblis
Adam Graham one.network
Chad Mann Oregon DOT
Ryan Blake Panasonic Cirrus
Sabrina Mosher Southwest Research Institute
Rob Hoyler TomTom
Joe Hunt TxDOT
Yang Cheng Univeristy of Wisconsin-Madison
Derald Dudley USDOT Bureau of Transportation Statistics
Paul Jodoin USDOT Federal Highway Administration
David Johnson USDOT Federal Highway Administration
Mark Mockett USDOT Volpe Center
Molly Behan USDOT Volpe Center
David Rush Virginia DOT
Tony Leingang Washington State DOT
Tom Stidham Washington State DOT
Erin Schwark Wisconsin DOT