2022 03 07 Specification Extension Subgroup - usdot-jpo-ode/wzdx GitHub Wiki

Specification Extension Subgroup

March 4, 2022

Meeting Information

Purpose

  • Introduce the co-chairs for the Spec Extension Subgroup
  • Discuss subgroup’s charter and planned activities for this cycle
  • Propose additions to the feed for member feedback

Agenda

  • Welcome and Co-Chairs Introduction
  • Charter Scope and Activities
  • Proposed Extensions
  • Questions & Discussion

Minutes

Co-chair Introductions

  • Brandon Patocka - City of Omaha Parking and Mobility Division
    • Manages GIS for the division, includes leases and loading zones.
    • Omaha does a lot of closures for events, and are interested in using WZDx for resurfacing.
  • Eric Kolb - Google
    • Maps team GIS Team Manager - basemap freshness updates (POIs, geocodes, roads).
    • Goal is to freshly update coverage of base map - road restrictions and work zones cover that.
  • Frank Winters - New York State GIO
    • History with GIS, previous president of National States Geographic Information Council
    • Frank: I don't expect people to come to our GIS website to download data. They're going to use the things they're already connected with, and the role of govt is going to change. We have authoritative data and that plays a role in the ecosystem.
  • Weimin Huang - HERE Technologies
    • Researcher. Looking to expand data collection with WZDx feeds and to introduce their imports to the data sets

Charter Scope and Activities

Purpose

Serve as the lead steward in identifying, drafting, and recommending potential extensions to the WZDx Specification.

  • An “extension” is defined as any change to the specification that includes functionality outside of delivering data specifically for work zones.

Scope

Identify Data Needs

  • Work with the community to identify other feature types that would improve the WZDx Specification.

Evaluate Feasibility

  • How many Infrastructure Owner Operators (IOOs) already produce the data?
  • How difficult would it be for more to produce it?
  • Determine whether extending the specification to include such data would be useful to the community.

Draft Specification Extension

  • Obtain a sample dataset from an IOO or other party currently producing the respective data.
  • In collaboration with data producers and data users, draft an extension to the WZDx Specification that includes the dataset.

Make Recommendations

  • Provide feedback on the respective data to the Specification Update Subgroup and the broader community, including a demonstration of how to incorporate the new data into the existing specification.
  • Obtain feedback from the working groups (e.g., the WZDWG and/or respective subgroups) to determine if the extension is useful and appropriate for the WZDx Specification.

Timeline

Topic Activity / Milestone Tentative Date
Administration Finalize subgroup participants Jan 2022
Administration Review and approve charter Jan 2022
Administration Gain co-chair consensus on feature(s) to develop during sprint Jan 2022
Extension Development Draft Specification Update Recommendation (content, object model, business rules) March 2022
Extension Development Socialize development plan with the WZDx subgroup chairs March 2022
Extension Development Finalize Specification Update Recommendation (content, object model, business rules) June 2022
Extension Development Make end-of-cycle recommendation of including optional feature(s) at Semi Annual Meeting WZDx WG July 2022
Candidate Feature Development Draft list of potential road events January 2022
Candidate Feature Development Socialize list among the community (Ask for additions, ask for rankings) March 2022
Candidate Feature Development Adjudicate collected remarks March 2022
Candidate Feature Development Finalize list April 2022
Candidate Feature Development Suggest a feature(s) to develop on during the next update/specification development cycle July 2022

Frank: This group started focused on work zone safety and information. We talk about extending what we've learned about safety to other highway matters. How do we do that without burdening the work zone component? And how do we ensure what we've developed with work zones is translatable?

  • One of NYSDOT's top priorities is protecting people and facilities from bridge strikes, and because they were interested in that they're also now interested in work zones.
  • The community and technology we build is repeatable across applications.

Proposed Extensions

  • The extensions we're talking about are attributes of vehicle interacting with the attributes of the roadway - that thread (started last cycle with bridge heights) is continued here
  • We're talking about adding new enumerated types but don't have a comprehensive list of values to add to the extension

Vehicle Impact

Add enumerated type VehicleImpact to RestrictionRoadEvent

  • VehicleImpact already exists and is used by the WorkZoneRoadEvent in the main WZDx feed

Proposed New Restrictions

Value Example Use
Closure Crash, emergency, weather, special events, etc
Seasonal-use Winter use only, summer use only
Road-limitation Four-wheel drive required, weight restriction
Moving-events Line striping, oversized load, etc.
  • Frank: We debated whether seasonal use only is a type of closure. It could be done as a closure - and say every spring that the road is closed. The data exists as "this is a seasonal road" and knowing the time of year allows you to know if the road is closed.
  • Frank: For the road limitation, this could be a road that's only accessible to four-wheel drive, even if the road is fully open.
  • Frank: Moving events like a striping work, or an oversized load

Cause

Add the property "cause" to the Restriction object

  • Used to describe why a restriction occurs
  • Field would remain optional

Could be an enumerated Type containing:

  • Natural event (flood, wildfire, etc.)
  • Crash
  • Special event (marathon, street festival, etc.)

Frank: We thought the cause of the restriction is good for consumers to know. Maybe more useful for humans. Could be an enumerated type to explain why a closure is taking place

Polygons

Frank: Right now, RoadEvents can only be start/end point or a full line. It may be more appropriate to allow Polygons, especially for special events.

  • If we don't add polygons, then the author would have to make linear events for all those events. With polygons, then it puts the onus on the

Discussion

  • Jeremy: How do you balance the spec getting bloated, overstepping its purpose and trying to do too much with one thing?

    • Frank: That's a discussion we had with bridge clearance. Work zones were unchanged, and the restrictions were added along side it but without impacting it. We're adding more lanes to the specification, rather than make the existing lanes wider.
  • Jeremy: Don't mapping companies already collect this static data?

    • Frank: Even if you fit with a truck under a bridge, if you're truck is taller than the sign is you're breaking the law.
  • Ben: Does the restriction road event handle reduced width?

    • Derald: Yes
    • Frank: We're not trying to replace permitting for oversize/overweight. But a lot of the data is available and can be expressed here for vehicles that don't
  • Should we add ground clearance?

    • Frank: Yeah
    • Maaza: Ground clearance - we don't have anything to let people know. Being given best information of what to expect. Or availability of being able to cross the desert. From sources that know information very well.
  • Craig Moore: Where do we draw the line between something inherent to the network, and a specific temporal restriction? Ice roads and marathons are definitely temporal, but lane width doesn't have a start and end. Do we want to cross that threshold? If we do, where do we stop?

    • Frank: We already crossed that line with bridge clearance, though we do replace 50 bridges every year so there is some temporal component. Those restrictions became a highlight because it was a key safety issue, particulary bridges low enough to impede legal trucks.
    • Craig: I get the safety thing but don't understand how we differentiate the authoritative source. Describing the base network muddies the mission. Key to include that definition of what should be found in WZDx. Esp. when there's no temporal end.
    • Derald: In my mind, the boundary should be wherever we can improve safety. Bridge clearance is a key safety issue. I don't want to water down the work zone data spec. As far as the temporal aspect - if a driver is traversing a segment of road, they just need the information needed to be safe on that segment. Doesn't matter if it's a day, month, or yearlong - that's a temporal scale.
    • Jeremy: I'd love to hear from map providers on this, since it encroaches on their area.
    • Eric Kolb: From a consumer aspect, this data (structures, from authoritative providers) is extremely useful. We spend a lot of resources collecting road conditions for the network, but we can't keep it at the highest fidelity needed. We rely on authoritative data to augment and sometimes supersede what we collect ourselves - we analyze/arbitrate the authority/fidelity of our data vs. outside.
    • Weimin: HERE uses a similar approach. We rely on provider input - 511, other exiting data sources. Then we have our sensor data and compare to determine which is more accurate, and put it out on the road and analytical data for routing. The quality we get from high functional classes is in much better shape than lower functional classes. We can make improvements.
    • Rob Hoyler: We follow what Google and HERE are doing and emphasize the collaboration and authoritative data to supplement our own activities. Legal aspects of height vs. what we see. Freshness - there's a lot of data to be collected and more that goes into navigation than what some people think. Collaboration is important for when changes occur to get appropriate data to the public as quickly as possible. A push from authoritative providers is critical.
    • Frank: Govt. brings the crystal ball to know when a change is coming.
    • Craig: I think adding railroad crossings would improve safety but doesn't belong in the spec
  • Neil: How about truck excluded roads or HazMat excluded roads?

    • Mark: Truck-excluded roads can already be represented in the current RoadRestrictionFeed
    • Neil: When you have a well thought out traffic plan, you think about where trucks can't go. If a bridge joint pops without a planned traffic alternate - if mapping providers offer an alternate route that a truck shouldn't go down, that's an issue we should know.
  • Stan Young: A last verified date might be useful for tracking data freshness

  • Frank: Are there more types? What about the list of causes?

  • Chris: We may want to look at expanding what's in part 6 in the work zones spec. Intermediate term, mobile, and etc could be considered a work zone?

    • We don't want people cutting into a moving event - if there are several vehicles in the event, we need a line string to represent where the whole thing is.
    • Crash is a good one for special events
  • Craig: Would it be better to define seasonal use as a type of closure rather than a separate restrictions value?

    • Weimin: Seasonal closure doesn't require updates as often as an incident closure.
    • Rob: That's one of the fuzzy closures - we know it happens the same time each year (roughly). You loose some of the dynamic capabilities

Frank: The chairs will do more work on this online

Participants

Name Organization
Mahsa Ettefagh Booz Allen Hamilton
Brandon Patocka* City of Omaha
Jacob Larson City of Omaha
Hannah Adeponu City of Omaha
Craig Moore City of Seattle
Ben Acimovic Colorado DOT
David Craig^ General Motors
John Ehlen Gistic Research
Eric Kolb* Google
Jeremy Agulnek HAAS Alert
Jeremy Agulnek HAAS Alert
Maaza Mekuria Hawaii DOT
Weimin Huang* HERE
Pete Krikelis Hill and Smith
Todd Hartnett Hill and Smith
William Twaite Hillsorough County
Casey Inoue Houston Radar
Michelle Boucher IBI Group
Jacob Brady IBI Group
Juan Pava Illinois DOT
Pete Stresino Illinois DOT
Mischa Kachler Indiana DOT
Clayton Burke Iowa DOT
Brandon Saylor Kentucky Transportation Cabinet
William Martin Leidos
Laura Huizinga Lindsay
Alexander Lemka Maricopa County DOT
Neil Boudreau Massachusetts DOT
Nisar Ahmed Metropolitan Transportation Commission (Bay Area)
Chris Brookes Michigan DOT
Ted Ulven Minnesota DOT
Daniel Rowe Minnesota DOT
Dan Smith Missouri DOT
Stan Young National Renewable Energy Lab
Tony English Neaera
Tim Fiato New York State DOT
Frank Winters* New York State Office of Information Technology Service
Justin Anderson Noblis
Tim Johnson North Carolina Department of Information Technology
John Copple Sanborn
Lynne Randolph Southwest Research Institute
Rob Hoyler TomTom
Yaw Adu-Gyamfi University of Missouri
Elizabeth McCartney US Geological Survey
Derald Dudley USDOT Bureau of Transportation Statistics
Martha Kapitanov USDOT Federal Highway Administration
Molly Behan USDOT Volpe Center
Hadrian Merced USDOT Volpe Center
Nate Deshmukh Towery^ USDOT Volpe Center
Mark Mockett USDOT Volpe Center
Logan Arens Ushr Auto
Armando Lagunas Ushr Auto
Chuck Felice Utah DOT
Pier Castonguay Ver-Mac
Justin Belk Washington State DOT
Erin Schwark Wisconsin DOT
Qassim Abdullah Woolpert
Michael Hanowsky Woolpert

* Co-Chair of Specification Extension Subgroup
^ Co-Chair of Work Zone Data Working Group