Technical Assistance Subgroup

June 3, 2021

Technical Assistance Subgroup Co-chairs

• Chuck Felice, Utah DOT
• Curtis Hay, General Motors
• Shane Zumpf, Trihydro
• Ryan Blake, Panasonic - Cirrus

Notes

Purpose

• The Technical Assistance Subgroup will be the lead steward in identifying and prioritizing the technical assistance needs of WZDx data producers and users, and sharing best practices to assist in WZDx adoption.
• This subgroup is open to all Work Zone Data Working Group (WZDWG) members.

Scope

• Facilitate Institutional Buy-In – There has been lingering doubt among some stakeholders as to how WZDx data might be used. The co-chairs would like to focus efforts for this work cycle on material to tell the story of why this data is so important and how it can benefit public safety.
  • Collect feedback from WZDWG members on what has been helpful to gain institutional buy-in and determine what additional materials could be useful.
  • Develop a document (e.g., one-pager, PowerPoint, webpage, video, etc.) which describes the impact and importance of WZDx to allow organizations to gain leadership buy-in.
• Support Technical Implementation of the WZDx Specification
  • Identify challenge areas such as data collection, translation, or aggregation that could benefit from the development of a tool. Work with the community to develop and share such a tool.
  • Evaluate different mechanisms for sharing WZDx data (e.g., clearinghouse or registry) and make suggestions to the larger WZDWG.
• Support Grant Awardees and other Adopters - continue providing support for WZDx adopters who have received grants to minimize friction and ease the process of standing up feeds.
  • Host meetings for active WZDx adopters, including the cohort of grant awardees, to maximize knowledge sharing and identify challenge areas.
• Cultivate Shared Understanding
  • Work collaboratively with the Specification Update Subgroup to identify and develop business rules for publication with specification updates.
  • Identify, document, and justify any variations between WZDx and other similar standardization efforts (TMDD, V2X, SAE J2945/4).
    • Siva Narla: Consider RSU 1.0 sponsored by USDOT. (Technically complete, but going through ballot)
  • Coordinate efforts with the Smart Work Zone Devices Subgroup, which is considering developing V2X standards.

Activities and Milestones - see charter

GitHub tutorial - Shane

All WZDx project developments are stored at the GitHub repository.

• GitHub is used for most open source projects to help with version control.
• GitHub can be used to document issues with the specification and develop pull requests to change the specification.
• Subgroup members should be able to navigate through GitHub to participate in discussions about issues, pull requests, and general specification questions.
• Issues are used to track to-dos, bugs, features requests, and more.
• Pull requests represent a modification in any of the project files or documentation. Changes are made by pulling a version out, making changes, then submitting a pull request to add those changes to the specification.
  • A pull request requires a conversation about the implementation of an idea in the code/files.
• Discussions are used to brainstorm ideas, help new users understand what the WZDx spec is about, and how to implement the specification. Less directly related to the specification than an issue.

Discussion

How important to you/your organization is backwards compatibility of future versions of the spec?

• Curtis Hay: We've looked through the spec and don't see a ton of issues for the people implementing WZDx, but we don't know every situation.
• Chuck Felice: We're aware there are some feeds available, but maybe not enough to get a lot of discussion on this call.
• Michelle: IBI Group and MassDOT recently implemented v3.1. I've heard from software development team that they want it to be backwards compatible.
• Joe Hunt: Backwards compatibility is key as it will be nigh on impossible to keep all implementations across the country up to date with the latest version.
• Jacob: Agree, though I want to stress that the deprecated values/fields in v3.1 should not be used by any agencies implementing feeds now. Thus the tentative plan for the next release of removing these deprecated values does break backwards compatibility, but should not be problematic for new producers and those currently working on implementing a WZDx feed, as new producers should not use the deprecated values in their initial implementation. The deprecated values do not add any functionality—they were deprecated because the functionality was captured in a different area of the spec.

How are IOOs handling division of responsibilities? Do state DOTs anticipate collecting data from divisions, counties, cities, and incorporating them * into a single feed? How could this impact processes for data consumers?

• Chuck: I'm leading UDOT's feed development. Cities don't have the resources that a state DOT has. The WZDx Demo Grant is a pilot project for UDOT, but we want to move forward with it and facilitate other states implementing the spec.
• Justin Belk (WSDOT): We're tackling similar issues with overlapping jurisdictions and beginning to have those conversations. Our current WZ database is only scoped for state roads, but we're looking into how to incorporate local agencies into that foundational database and conversations with larger jurisdictions (Seattle) about how to communicate/publish info. Cities and counties use different linear reference systems/localization techniques, which makes integration difficult. Larger agencies are more able to handle their own data, and all jurisdictions have tracking for WZ permits but not necessarily in real-time. WSDOT will lead from the top about real-time devices in construction contracts, but local agencies will need to track their work zones before it gets to us.
• Chuck Felice: Also thinking about differences between East and Western states, and cooperation across jurisdictions for interstates.
• Frank Winters: I'm not in the DOT but there is the I-95 Corridor Coalition. They'll have some thoughts and I can get our traffic safety folks at DOT to talk with them. We have owner/operators at several different levels (village, tribal, etc) but drivers don't care about what jurisdiction it is. Where the work zone is on any given day is frequently the purview of a private contractor.

What value would developing a WZDx API create?

• Frank Winters: If an API could be queried for changes, data modifications, other dynamic changes, that would be useful.
• Maaza Mekuria: Yes, it would be a great value for communicating with external parties who want to know what data is available. It shouldn't be a big investment - putting it on a web/cloud platform, there should be some way to access and query data. An API is the best way to go.
• Chuck Felice: Software for WZDx is an investment, but we're interested in what would be helpful as feeds get developed and folks start ingesting.

Are there any technical areas of the spec that you or your organization would like more guidance on?

• Frank Winters: I have a pretty good handle on how to make data feeds in our GIS environment. It would be helpful if there were sample Python code to help pick out the GeoJSON code for data that starts in GIS to generate a WZDx feed.
• Chuck Felice: That's one of the things we hope to get out of the Demonstration Grants - what software was used, etc., to help other IOOs.
• Shane Zumpf: There might be some code in Tony English's tool that could be helpful.

Are there any other obstacles or roadblocks to creating a WZDx data feed we can help with?

• Maaza Mekuria: Is it possible to provide a repository where people could post their data? (Read and write into a shared repository.)
• Chuck Felice: FHWA has a site that ingests some WZDx feeds.
• Shane Zumpf: Trihydro has built the Situational Data Exchange (SDX) to push feeds into one aggregated data storage system allowing 3rd parties to pull data more easily. This originated with USDOT and Wyoming's connected vehicle pilot, and we're trying to get as many states on board as possible.

Next Steps

• Share feedback about what aspects of WZDx your organization would like assistance with, or documentation on.
• Provide suggestions / ideas for tool development.
• Actively participate in spec development on GitHub.

Links shared:

GitHub demonstration: https://connectdot.connectsolutions.com/pa2qjvla77fc/

WZDx Feed Registry: https://datahub.transportation.gov/Roadways-and-Bridges/Work-Zone-Data-Exchange-WZDx-Feed-Registry/69qe-yiui

Attendees

• Mark Mockett, USDOT Volpe
• Siva Narla, San Francisco Metropolitan Transportation Commission
• Praveen Edara, University of Missouri
• Sabrina Mosher, SwRI
• Justin Healey, Navjoy
• Deepanshu Girdhar, Colorado
• Abdul Zinnedin, USDOT FHWA
• Maaza Mekuria, Hawaii DOT
• Qassim Abdullah, Woolpert, Inc.
• Molly Behan, USDOT Volpe
• Justin Belk, WA DOT
• Neil Boudreau, MA DOT
• Lauri Brady
• Clayton Burke, IA DOT
• John Copple, The Sanborn Map Company, Inc.
• David Craig, GM
• Dean Deeter
• Nate Deshmukh-Towery, USDOT Volpe
• Eli Sherer, OneNetwork
• Eric Kolb, Google
• Ethan Alexander, Navjoy Inc.
• Faisal Saleem, MCDOT
• Michael Hanowsky, Woolpert, Inc.
• Catherine Huebsch, MN DOT
• Jacob Brady, IBI Group
• Jeremy A., HAAS Alert
• Jianming Ma
• Joseph Hunt, TxDOT
• Martha Kapitanov, USDOT FHWA
• Tony Leingang, WA DOT
• Virginia Lingham
• Jennifer Little, USDOT Volpe
• Marc Russell, Navjoy Inc.
• Mariah Lynch, Castle Rock
• Matt Weatherford
• Hadrian Merced Hernandez, USDOT Volpe
• Nicholas Merrick
• Michael Schnuerle, OMF
• Michelle Boucher, IBI Group
• Michelle Moser
• Meredith Nelson, MI DOT
• Christopher Restrepo, NC DOT
• Rick Bukowski
• David Rush
• Garrett Schreiner, MN DOT
• Kellen Shain
• Stewart LaPan, Navjoy Inc.
• Thomas Stidham
• Todd Foster
• William Twaite
• Milford Ulven, MN DOT
• Luke Urie, Austin Transportation Department
• Frank Winters, NY ITS
• Jingwei Xu
• Patrick Zelinski, AASHTO