Specification Update Subgroup meeting, Feb 2022

February 23, 2022

Meeting Information

Objectives

• Review and discuss outstanding and new GitHub issues
• Identify member advocates for the prioritized issues

Agenda

• Sign-in and Welcome
• Discuss Issues
  • Univerally Unique IDs for Road Events - #207
  • Rename road_event_feed_info for consistency - #222
  • Mobile Work Zones - #125
  • Location Verification - #201, #213, #233
  • Clarify Usage of RoadEvent update_date - #184
  • Streamlining EventStatus Values - #189
• Action Items and Next Steps

Materials

• Meeting presentation

Minutes

#207 - Universally Unique IDs for Road Events

• Currently, WZDx RoadEventFeature id is allowed to be any string. This makes it difficult to relate two road events or a road event with a field device because IDs may not be unique.
• A Universally Unique Identifier (UUID) is a 128-bit ID that guarantees uniqueness across time and space.
  • Example: 6ba7b810-9dad-11d1-80b4-00c04fd430c8
• To maintain backward compatibility, v4.1 would recommend using UUIDs for RoadEventFeature IDs.
  • UUIDs are currently recommended for SwzDeviceFeed IDs
  • UUIDs could be required in a future major version of the spec (i.e. v5.0)
• UUIDs will make it easier to combine feeds without worrying about duplicate IDs
• Use description or other fields to add human readable information - there other ways to build in alternate ids or names if desired

#222 - Rename road_event_feed_info for Consistency

• All three feeds in WZDx v4.0 both use the FeedInfo object, but it occurs on differently named properties
• In v4.1, deprecate the road_event_feed_info property and add a feed_info property (to maintain backward compatibiity). Both could contain the FeedInfo object.
• Remove the road_event_feed_info property in a future major release

#125 - Mobile Work Zones

At the last meeting we started talking about mobile work zones, so the co-chairs put together some materials on the discussion, especially how two related WZDx events could be used to reflect the planned extent of the mobile work zone and the active area.

• The active area event would have:
  • Verified begin and end locations
  • Verified start date (which would stay the same for the duration of the mobile operation)
  • update_date could be used to indicate the last time data (including locations) is updated, though this could also reflect another property being changed
  • Needs relationship object to associate with the planned extent of the operation
  • Outside of the relationship, nothing currently identifies this as a mobile operation
• The planned extent event would have:
  • Estimated begin and end locations
  • Associated with an active area event by the Relationship object
  • Would the status stay as planned or should it be active?
  • How would this be distinguished from other planned or estimated events? currently nothing proposed to do that

The actual event area could be updated more/less frequently based on whatever a data producer can provide

For data consumers, do we need a way to differentiate this from a static work zone, especially if there's no current active area?

• Could use the type of work

Discussion

Jeremy: Would the live mobile event supersede the planned extent for data consumers once the former is live?

• Skylar: I'll let data consumers speak up if they have more thoughts, but the ability to know where it could be is likely still useful to data consumers.
• Jeremy: Planned extent could be used for "forecasting" but actual would be used for real-time alerting.

Tony English: I'm working on an ATMA project for Colorado so I'm interested in this idea. We were looking at using a planned event for the extent before it starts, but then moving to an active event once it starts. If over the day there's a 10 or 15 mile stretch of roadway and we know where the attenuator is, and know that over the next 30 minutes it will be in a geofenced area based on the speed. Interested in best practices for how to represent this, and will be taking a first swing at it over the next several months

Dan: I see a critical need for the planned event to schedule properly. Once that mobile operation starts, I don't know how critical it is to show the planned extent unless you're going to be back there tomorrow.

• Skylar: My original thought would be to just have the planned extent, but based on the consumer thought we thought it'd be good to have both.
• Dan: It could be useful for others but that's not what I'd use it for.
• Skylar: If we had a big long work zone that's going to be around for a long time, the planned road event could be updated with confirmed locations once it's started. But for this, we'd recommend keeping the planned event and creating a new event with the actual live attenuator.

Eric: I like this idea in that the planned extent gives information when routing an entire trip - could be useful for travel time, for example. And the actual mobile extent. I assume the event status would be used to discriminate between them.

• Skylar: Yes, the mobile one would definitely be active. But the whole planned extent is more of a question - what's needed to indicate to a user what's going on? Currently most events that have passed their start date are shown as "active."
• Eric: With UUIDs and relationships, we could create logic around them. But it'd be useful to get validation that the mobile devices reporting changes on the ground - additional field with an expected update cadence? If it's every 5 but we only get one every 15 minutes...
• Skylar: That's one thing we heard last week - having indication of how active the signal should be updated.
• Eric: That'd be helpful to determine which we should stay with.

Jeremy: Could we move to a planned vs. active feed? A higher delineation between planned events and active events.

• Eric: I agree, that'd be easier to distinguish between them.
• Jeremy: And then we could pipe the real-time, active feed into our safety cloud and use the planned feed for different purposes.
• Eric: There are also different possible update cadences.

Skylar: Right now, there's no way to distinguish between the planned and mobile work zone. Should that be added?

• Eric: I'd prefer an explicit marking. But if we go to a separate feed for active events, that's something that could be used for logic.
• Jeremy: But that starts to open the can of worms of what is a mobile work zone
• Jacob: What additional value that's knowing that it's mobile give?
• Dan: As a work zone traffic control engineer, it's helpful for people to know what people should be looking for. They need to know the difference
• Eric: I agree as we move to having more ADAS systems. More fidelity = important

Skylar: What we've talked through today would just be guidance, not requiring any change to the specification. Some of the changes that could be made are the update date frequency/cadence.

#201, #213, #233 - Location Verification

All versions of WZDx have allowed a data producer to identify whether the coordinates of the work zone start or end point are verified by a field device or estimated.

• Since moving to GeoJSON, data producers can provide intermediate points but do not have an option to specify whether those points are verified.
• WZDx has never added a third option beyond “estimated” and “verified” for point accuracy.

There are several open issues related to verification/accuracy of begin, end, and potentially intermediate locations * #201 proposes replacing the existing beginning_accuracy and ending_accuracy with a new PositionalAccuracy object, including new accuracy property * #213 proposes replacing the existing beginning_accuracy and ending_accuracy fields with equivalent Boolean (true/false) properties is_begin_location_verified and is_end_location_verified * #233 proposes moving the beginning_accuracy and ending_accuracy properties to a new PositionalAccuracy object with no further additions

• Not being discussed today but also related:
  • #194 Geometry requirements
  • #232 Represent accuracy of intermediate points

Skylar: Separate beginning and ending accuracies are still important. We can provide good information about where the work zone starts, but can't guarantee a verified end location. So that's an argument against #201

• Jeremy: Wouldn't there be situations where the intermediate accuracy is not verified even though the beginning and end are?
• Skylar: Yes, we probably will leave #201 behind then

For #213, we only have two options: estimated and verified. Are those the only two that we could have? If so, let's add them. If not, we could change the properties to Boolean (true/false)

Jacob: #233 would be cleaning and organizing of objects that have similar properties. Could be more easily applied to another event that could have verified

#189 - Streamlining EventStatus values

EventStatus has five enumerated values right now, but most DOTs only use planned and active.

• Cancelled/completed are odd as they suggest past events be kept in the feed

Questions

• Should the definitions of planned and active be modified?
• Do we need those additional values pending, cancelled, or completed?

Jeremy: If an event is ending early, then the onus would be on the producer to reflect that accurately.

• Skylar: If the producer just uses the start/end date, they could remove it from the feed or switch the status to completed. Is leaving it in and identifying as completed a preferred approach, assuming the end_date is accurate?
• Jeremy: Depends on whether data consumers are leaving events in the feed for historical purposes.
• Skylar: Based on early deployment, we view this as a real-time feed. Whenever event is done we remove it
• Jeremy: And that speaks to the active vs. planned feeds.

Participants

Name	Organization
Marty Lauber	Arizona DOT
Jackie Beckwith	Association of Unmanned Vehicle Systems International
Mahsa Ettefagh	Booz Allen Hamilton
Jacob Larson*	City of Omaha
David Craig^	General Motors
Eli Sherer	GEWI North America
Eric Kolb	Google
Jeremy Agulnek	HAAS Alert
Weimin Huang	HERE
Casey Inoue	Houston Radar
Jacob Brady*	IBI Group
Michelle Boucher	IBI Group
Dan Sprengeler	Iowa DOT
Skylar Knickerbocker*	Iowa State University
Brandon Saylor	Kentucky Transportion Cabinet
Will Martin	Leidos
Alexander Lemka	Maricopa County
Hua Xiang	Maryland DOT
Neil Boudreau	Massachusetts DOT
Siva Narla	Metropolitan Transportation Commission (CA)
Tony English	Neaera
Bruno Fernandez-Ruiz	Nexar
Kellen Shain	Noblis
Justin Anderson	Noblis
John Copple	Sanborn
Pieter van der Werf	TomTom
Yaw Adu-Gyamfi	U. of Missouri
Yang Cheng	U. of Wisconsin-Madison
Mark Mockett	USDOT Volpe Center
Molly Behan	USDOT Volpe Center
Hadrian Merced	USDOT Volpe Center
Nate Deshmukh Towery	USDOT Volpe Center
Logan Arens	Ushr Auto
Chuck Felice	Utah DOT
Pier Castonguay	Ver-Mac
Tony Leingang	Washington State DOT

* Co-Chair of Spec Update Subgroup
^ Co-Chair of Work Zone Data Working Group