2022 01 27 Specification Update Subgroup kickoff meeting - usdot-jpo-ode/wzdx GitHub Wiki

Specification Update Subgroup

January 27, 2022

Meeting Information

Purpose

  • Formally re-launch the Specification Update Subgroup and introduce co-chairs
  • Discuss subgroup’s planned activities for this cycle and clarify member roles and opportunities for involvement
  • Begin discussion and prioritization of outstanding GitHub issues

Agenda

  • Sign-in and Welcome
  • Introduce Co-Chairs and Review Subgroup Charter
  • Review GitHub Best Practices
  • Review and Discuss Issues
  • Action Items and Next Steps

Materials

  • Current Specification Update Subgroup roster
  • Updated Specification Update Subgroup charter
  • Meeting presentation

Minutes

Co-chair Introductions

  • Jacob Brady - Software Developer, Intelligent Systems Development, IBI Group
  • Adam Graham - Chief Product Officer, one.network
  • Skylar Knickerbocker - Research Engineer, Iowa State University
  • Jacob Larson -

Subgroup Charter

See January 2022 version of the subgroup charter

GitHub Best Practices

GitHub is a collaboration platform for open source projects

  • Powerful source-code control
  • Features such as issues and pull requests

How to participate

  • Sign up for a free GitHub account here
  • Select 'Watch' on the GitHub repository to be notified of any new issues, pull requests, and comments
  • 'Star' the repository to raise awareness

GitHub includes four main tabs:

  • Code - this is hwere you can find the WZDx Specification and older versions of it
  • Issues - discuss opportunities to improve the specification
  • Pull Requests - proposed modifications to the repository with discussion
  • Discussions - discuss topics related to WZDx that don't involve modifications to the specification

Issue Backlog

As of January 27, there are 20 open issues assigned to the Spec. Update Subgroup: Issues include:

  • Geometry and Positional Accuracy:
    • #194 - Clarify geometry requirements
    • #201 - Replace beginning_accuracy and ending_accuracy with positional accuracy
    • #213 - Refactor RoadEvent beginning_accuracy and ending_accuracy to new Boolean properties
    • #232 - Add option to specify accuracy of intermediate points
    • #233 - Refactor beginning_accuracy and ending_accuracy to new PositionalAccuracy object
  • Dates and Statuses:
    • #184 - Clarify usage of RoadEvent update_date property
    • #189 - Remove unneeded values from EventStatus enumerated type
    • #211 - Add optional property for probability of start/end time
    • #236 - Add update date for location info
  • Lanes:
    • #215 - Improve representation of bidirectional passing lanes
    • #237 - Review LaneStatus enum for conveying lane’s normal and current use
  • Generalization:
    • #231 - Allow both Imperial and metric speed units throughout spec
    • #234 - Rename center-left-turn-lane to accommodate left-side driving
  • Standalone issues:
    • #125 - Mobile work zones
    • #197 - Refactor the Relationship object for flexibility
    • #207 - Use Unique Universal IDs for all feature IDs
    • #222 - Rename WZDxFeed road_event_feed_info property for consistency
    • #229 - Improve RoadEvent direction for situations when direction isn't available
  • Questions/admin:
    • #214 - Question on responsibility for RoadEvent and Lane objects
    • #235 - Add/maintain object diagrams for new feeds

Open discussion on #125 - Mobile work zones:

  • Jeremy: Data consumers would want to know about the frequency to pick up a location for a work zone event, based on the feedback we've been hearing. Obligation should be on the data producer to update more often as the location changes
  • Jacob B: If there's a work zone moving you could just put out a new feed every few minutes with the precise location, but most folks don't have tech to do that and as a result would flag a long stretch of location
  • Ross: That difference is important, so we need to define the accuracy by saying a work zone is mobile and here's when we last updated it
  • Adam: We'd like to have the total extent of the work zone as well as the current location where work is active
  • Russell: Lots of devices can move, but there are unique work zones that are mobile (striping). But we don't want to make it any more complex than we have to
  • Ross: Build in a way to specify when the next update should be expected. Data consumers should put some thought into when they want
  • Dan: From a motorists standpoint, we want to be able to separate a static-daily work zone from a mobile work zone. Mobile doesn't have a well-defined start/end location
  • Neil: The SWZ device feed has the ability to more frequently update location. That's coming up in our discussion - location on a moving piece of equipment can be pulled as often as possible
  • Skylar: Static work zones with confirmed locations can be represented in WZDx right now, and the WZDx feed can be updated when a device moves within a static work zone. Translating that over to mobile work zones, we use the best information to say that there's a verified location - is there anything else a data consumer should have to know that it's mobile or is just a frequently updated work zone location enough?
    • #236 could be useful for this conversation - we have an update date for the whole work zone - should it be clarified with another update_date for location?
  • Adam: The planned aspect/extent of a mobile work zone is still important from a coordination perspective
  • Weimin: HERE is doing work to identify moving bottlenecks from road speeds. Moving work zones would be good to be higher than every minute
  • Russell: MUTCD doesn't have a definition of what a mobile work zone is
  • Jacob: We want to have a way to represent a mobile work zone without start/end points, because there are already ways to represent a work zone that's moving
    • Weimin: Moving speed would be good, to be able to forecast location
    • Knowing where a work zone might it be two hours from now would require knowing the planned extent
  • David: Also need to know which lane the mobile work zone is impacting - there are different impacts of shoulder work vs. lane work
    • Moving every 4 hours with different cones, that's just a new static work zone. Deployment of traffic control devices as it moves down the road is still important.
  • Ben: Mobile work zones are both simple and complicated. Mobile cars that stop unpredictably - that's not construction but it is a work zone.

Participants

Name Organization
Jackie Beckwith Association of Unmanned Vehicle Systems International
Melissa Clark CalTrans
David Aylesworth CeVe
Jacob Larson City of Omaha
Derek White Civiltronics
Ben Acimovic Colorado DOT
Hahne, Frederick Connecticut DOT
Jennifer Petrario Connecticut DOT
Curtis Hay General Motors
David Craig General Motors
Eli Sherer GEWI
John Ehlen Gistic Research
Nazih Fino Global Nomad GIS
Kristine Breide Google
Jenny Gashasy Google
Jeremy Agulnek HAAS Alert
Weimin Huang HERE
Jingwei Xu HERE
Pete Krikelis Hill and Smith
Ivo Kushkiev Hill and Smith
William Twaite Hillsborough County
Amos Castillo Hillsorough County
Jorge Uy HNTB
Fabillo Capillo Houston Public Works
Michelle Boucher IBI Group
Jacob Brady IBI Group
Ross Sheckler iCone
Juan Pava Illinois DOT
Pete Stresino Illinois DOT
Mischa Kachler Indiana State Police
Ted Trepanier INRIX
Amy Lopez INRIX
Siva Narla Institute of Transportation Engineers
Stolle, Sinclair Iowa Department of Transportation
Dan Sprengeler Iowa DOT
Clayton Burke Iowa DOT
Skylar Knickerbocker Iowa State University
Satyam Patel Kyra Solutions
Travis Parsons Laborers' Health and Safety Fund of North America
Will Martin Leidos
Jeff Jenq Maricopa Association of Governments
Corey O'Connor Massachusetts DOT
Neil Boudreau Massachusetts DOT
Carrie McInerney Massachusetts DOT
Michelle Moser Minnesota DOT
Cathy Huebsch Minnesota DOT
Christopher Poe Mixon Hill
David Fosbroke National Institute for Occupational Safety and Health
Ethan Alexander Navjoy
Timothy Fiato New York State DOT
Frank Winters New York State Office of Information Technology Service
Bruno Fernandez-Ruiz Nexar
Justin Anderson Noblis
Tim Johnson North Carolina Department of Information Technology
Navin Nageli NueGOV
Stephanie Marik Ohio DOT
Adam Graham one.network
Michael Schnuerle Open Mobility Foundation
Chad Mann Oregon DOT
Devorah Henderson QLynx
Devorah Henderson QLynx
Russell Holt Rhode Island DOT
Muyi Zhou San Francisco Municipal Transportation Agency
John Copple Sanborn Mapping
Darryl Keeton Sensagrate
Ben Towne Society of Automotive Engineers
Lynne Randolph Southwest Research Institute
Sabrina Mosher Southwest Research Institute
Shane Zumpf Trihydro
Piotr Gajewski U.S. Virgin Islands Department of Public Works
Yang Cheng University of Wisconsin-Madison
Derald Dudley USDOT Bureau of Transportation Statistics
Jeff Purdy USDOT Federal Highway Administration
Deb Curtis USDOT Federal Highway Administration
John Berg USDOT Federal Highway Administration
Todd Peterson USDOT Federal Highway Administration
Murat Omay USDOT ITS Joint Program Office
Mark Mockett USDOT Volpe Center
Molly Behan USDOT Volpe Center
Hadrian Merced USDOT Volpe Center
Robert Hoffman Ushr Auto
Armando Lagunas Ushr Auto
Aaron Bolton Ushr Auto
Logan Arens Ushr Auto
Chuck Felice Utah DOT
Pier Castonguay Ver-Mac
Todd Foster Ver-Mac
David Rush Virginia DOT
Steve Haapala Washington State DOT
Tony Leingang Washington State DOT
Justin Belk Washington State DOT
Qassim Abdullah Woolpert
David Blackstone Woolpert
Unwanna Dabney Woolpert
Michael Hanowsky Woolpert
Don Shupp WP Signal