2022 03 07 Specification Extension Subgroup

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