Specification Update Subgroup meeting, May 2022 - usdot-jpo-ode/wzdx GitHub Wiki

Specification Update Subgroup

May 5, 2022

Meeting Information

Objectives

  • Conclude discussion of outstanding GitHub issues.
  • Review proposed approaches to modifying the specification through Pull Requests (PRs).

Agenda

  • Sign-in and Welcome
  • Highlight PRs from Other Subgroups and Previously Discussed PRs
  • Review Implementation via PRs
    • Refactor and Clarify Event Status and Start/End Date Verification – PR #294
    • Clarify Usage of Update Date – PR #302
  • Discuss Issues
  • Action Items and Next Steps

Minutes

Highlight PRs from Other Subgroups and Previously Discussed PRs

For those who haven't attended other subgroup meetings, we wanted to highlight the PRs that those groups have discussed in case folks want to join in on discussion.

Smart Work Zone Device Subgroup

Change traffic sensor traffic data properties from Integer to Number value type – PR #228

  • Change the average_speed_kph, occupancy_percent, and volume_vph properties type on the TrafficSensor and TrafficSensorLaneData objects from "integer" to "number"
  • Change adds flexiblity when reporting these values

Add is_moving to FieldDeviceCoreDetails – PR #266

  • Add optional is_moving property to the FieldDeviceCoreDetails object to allow representing if a device is actively moving.
  • is_moving was already a property of arrowboards - deprecate the existing is_moving property as the new is_moving property on the FieldDeviceCoreDetails should be used instead.

Allow lane-level traffic sensor data without a defined road event – PR #267

  • Change the conformance of the road_event_id property on the TrafficSensorLaneData object from Required to Optional.
  • This makes the specification easier to implement by making the road_event_id optional

Add road_direction property to FieldDeviceCoreDetails – PR #273

  • Add optional road_direction property (for named direction of a roadway) to the FieldDeviceCoreDetails object, which applies to every field device
  • Move the "Direction" JSON Schema type definition to it's own JSON file and generalize its description and reference the moved "Direction" type from SwzDeviceFeed and RoadEventFeature schemas

Add notes about HybridSign static_sign_text – PR #292

  • Add notes to the HybridSign static_sign_text property indicating that it is advisable to provide it and it will be required in a future release.

Allow a LocationMarker to represent a device that is worn or carried by a worker – PR #293

  • Add a personal-device value to the MarkedLocationType enumerated type. This value allows using a LocationMarker to represent a connected device that is worn or carried by an individual worker in a work zone.

Rename SwzDeviceFeed to DeviceFeed – Issue #242, PR #TBD

  • Clarity; no acronyms.
  • Shorter when written out.
  • The devices in a SwzDeviceFeed don't have to be in a smart work zone.
  • The term "smart" will become outdated because eventually all devices will be connected.
  • No changes to the specification content or structure, just a documentation change.
  • The feed being under WZDx (that is, the WZDx DeviceFeed) implies the work zone context

Specification Update Subgroup

Recommend Universal Unique IDs for Road Events – PR #278

  • 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
  • Recommend using UUIDs for RoadEventFeature IDs in v4.1, to maintain backward compatibility. Could be required in a future version.
  • Add new property for human-readable road event name to the RoadEventCoreDetails.
    • UUIDs are currently recommended for SwzDeviceFeed IDs
    • UUIDs could be required in a future major version of the spec (i.e. v5.0)

Rename road_event_feed_info for Consistency – PR #268

  • All three feeds in WZDx v4.0 use the FeedInfo object, but it occurs on differently named properties
  • This proposal would deprecate the road_event_feed_info property and add a feed_info property. Both would contain the FeedInfo object.
    • This change is technically not a renaming, since the old property is still available, but functions as such.
  • Remove the road_event_feed_info property in a future major release

Use Boolean Properties for Location Verification – PR #281

  • Since there are only two "useful" EventStatus values and there's nothing else we're likely to add, this PR effectively replaces those properties with Booleans by adding new properties and deprecating the current ones
  • Deprecate the beginning_accuracy and ending_accuracy properties on the WorkZoneRoadEvent.
  • Add new boolean properties to the WorkZoneRoadEvent to indicate if the work zone start and end position (first and last geometric coordinate pair, respectively) are based on actual reported data from a GPS-equipped device.
  • Conditionally require either beginning_accuracy/ending_accuracy or new is_start_position_verified/is_end_position_verified.

Refactor and Clarify Event Status and Start/End Date Verification- PR #294

This PR uses a similar approach to #281 (above) to update how data producers communicate whether events are active and whether such information has been validated.

Changes to WorkZoneRoadEvent and DetourRoadEvent.

  • Deprecate the event_status property.
  • Deprecate the start_date_accuracy and end_date_accuracy properties.
  • Add new boolean properties is_start_date_verified and is_end_date_verified:
    • Indicates if work has been confirmed to have started, such as from a person or device in the field or a report from a traffic management center.

Discussion

Mike Hanowsky: There might be three cases based on whether the data provider intends to indicate whether work has started or doesn't intend to ever provide that information.

  • Skylar: There's currently no way to know the intention of an agency - if that's something people would want, that could be a separate issue.
  • Mike: I deal with a lot of entered data from engineers in the field and the quality is not what we'd like. Someone may enter information expecting someone else to update it later to be more accurate. We have to clean the data to identify those cases, so I'd suggest accommodating that more directly.
  • Skylar: If someone enters the data and there's no verification that work zone started, then this value would remain false if that information isn't verified.
  • Eric: From a consumer standpoint, there are multiple signals that go into closing a segment. One of these events as a signal would be stronger if start/end date verification is provided, but even with a weak signal it would likely be closed.

Adam: the way we've explored this with some agencies, they use two feeds for information that is going to be verified and another for those that aren't.

Clarify Usage of Update Date – PR #302

This PR would update the description of update_date for the RoadEventCoreDetails and FieldDeviceCoreDetails objects

  • The intent is for update_date to apply to everything about the event or device, when any information on the feature was update OR confirmed as up to date
  • If you're a feed producer getting data from multiple sources: you can still update the update_date because you got new data, even if nothing changed.

Refactoring Relationship Object - Issue #197

The relationship object is intended to be used to specify relationships between road events.

  • Currently, it is not well defined how different types of relationships should be specified.
  • This issue looks at options for explicitly definining relationships between road events (i.e. work zones and detours).

Some features of the current proposed model are:

  • The RelatedRoadEventType enumeration below relates road events in a spatial or temporal sequence back to the first road event.
  • There are two options for how these relationships could be used to relate groups of road events to other groups (i.e. a road event with multiple events)
  • See below for full enumeration of relationship types.

New property on RoadEventCoreDetails

Property Name Value Description Conformance Notes
related_road_events Array; [RelatedRoadEvents object] (see below) A list describing one or more road events which are related to this road event, such as a work zone project it is part of or another road event that occurs before or after it in sequence. Optional

The RelatedRoadEvents object is used to identify another road event that is related to a road event.

Property Name Value Description Conformance Notes
type RelatedRoadEventType enumerated type (see below) The type of road event being identifed, such as another sequence of related work zones, a detour, or next road event in sequence. Required
id String An identifier for the related road event by the type property. Required

RelatedRoadEventType Enumerated Type describes a type of related road event, such as a work zone project, recurrent work zone, or detour-type road event.

Value Description
first-in-sequence The first road event in a sequence of road events that together describe a full work zone or detour
next-in-sequence The next (subsequent) road event in a sequence of road events that together describe a full work zone or detour
first-occurrence The first road event of the first occurrence of a recurrent work zone. End users will need to iterate using the first road event to find all relevant road events to a related work zone
next-occurrence The first road event of the next occurrence of a recurrent work zone. End users will need to iterate using the first road event to find all relevant road events to a related work zone
related-work-zone First road event of related work zones (i.e. not part of a sequence of road events or recurrent work zone) that are relevant to the given road event. End users will need to iterate using the first road event to find all relevant road events to a related work zone
related-detour First road event of related detours (i.e. not part of a sequence of road events) that are relevant to the given road event. End users will need to iterate using the first road event to find all relevant road events to a related detour
planned-moving-operation First road event of a related planned moving operation work zones (i.e. not part of a sequence of road events) that are relevant to the given road event. End users will need to iterate using the first road event to find all relevant road events to a related work zone
active-moving-operation First road event of a related active moving operation work zones (i.e. not part of a sequence of road events) that are relevant to the given road event. End users will need to iterate using the first road event to find all relevant road events to a related work zone

Mobile Work Zones - Issue #125

At last meeting we discussed using two events to convey mobile work zones:

  • One WorkZoneRoadEvent showing the planned extent of the mobile operation
  • One WorkZoneRoadEvent showing the current area where work is taking place

Still to discuss: add an attribute / relationship type / event subtype for planned extent vs. active area?

  • Proposed RelatedRoadEvent object with planned-moving-operation and active-moving-operation relation types should identify this in many situations.

Discussion

Mariah: This would be useful for MnDOT since we'll be using vehicles to determine where mobile work zones are.

  • Skylar: So you think the type would be sufficient?

Tony: I've been working with CDOT on moving operations with their Automated Truck Mounted Attenuator. We would use a long event for the planned days work, and then the actual mobile extent for 30 minute increments and use the road events as they're described at the bottom of the page. Is that the intent of this?

  • Skylar: Yes, that's exactly what we're trying to accomplish.
  • Tony: Should the active work area be 15-30 minute segments? Is there thought on best practice for how that would be best built out?
  • Skylar: We might have previously discussed, but no firm solution.
  • Tony: We can be a guinea pig.

Mark: If the mobile event isn't active yet, then we wouldn't be able to use the related road event to make clear it's not a 30-mile one lane closure?

  • Jacob B.: And if you don't know the active area, it'll always look like that. We're essentially talking about knowing the nature of the work that's occurring. That issue exists right now.
  • Eric: At least from a consumer standpoint, if there's no other verification of the actual mobile event, then we'd just publish the left side until there's verification that something has changed.
  • Skylar: Would you want that distinction that it's going to be a mobile event?
  • Eric: It wouldn't make a difference in the navigation event. It could down the line, but we wouldn't differentiate now.
  • Adam: I've seen other navigation providers put warnings out - they'll want to know.
  • Jacob B.: FWIW, the type of work in a work zone is already captured in another field, but it's hard to distinguish that from the type of work zone (i.e. mobile vs full closure). It's more of a question about the latter
  • Adam: If it's a 100km work zone, we want to know whether we want to notify if the striping is down the road.
  • Neil: It's good to know the difference in opinion between some consumers. If you're driving and don't see anything, then driver becomes complacent. If we want the best quality information to a motorist, then we may need a relationship.
  • Adam: Interesting to hear you mention where workers are working. The worker presence element

Jacob B.: It sounds like this needs more discussion about whether it's necessary to be able to know that a planned event is a mobile operation. What we've presented is helpful but maybe not comprehensive.

Handling Undefined Directions - Issue #229

Currently direction is limited to one of four options (north-, south-, east-, or westbound) based on the signed route the event is occurring on, but that limits data producers.

  • Many existing permitting and work zone management systems do not include a direction attribute
  • These events should currently be excluded from the feed
  • Some producers are guessing the direction field
  • Direction is much clearer for large roads and interstates – some local roads do not have a specified direction
  • Could either introduce an unknown direction or make the direction attribute optional

Key questions:

  1. Does the lack of an unknown option potentially lead to poor data accuracy?
  2. Is data without a direction more or less useful than no data at all?

Discussion

Jacob B.: There aren't many required properties of a road event, and direction has always been one of them. So it's kind of a major change in some ways.

John Penuelas: I like the unknown direction

Mariah: Some highways are extremely divided from each other - e.g. a big grassy median - if I were a data consumer I'd be dubious about unknown directionality.

  • Eric: That's true in our case - much of the work we undertake in processing a feed is based on the quality of the line strings. If the event is on a dual carriageway and the provider only has a single linestring - we would struggle with the line string. Most of our matching is automatically done, and that quality would be too low. For us to efficiently process that data, we'd need the line drawn in a way that closely aligns with the road network. We could take the directionality of a line as it's drawn. In this case (dual carriageway) in our own map it's annotated as one direction. If the line goes in the direction of our map segment, then we'd know the intent of the closure.
  • Eric: If you have a local road with no median and a single line that's multiple directions and provider shares a closure along that segment that's only in one direction, that would get tricky if we don't have direction.
  • Adam: What would you expect to see in the direction field for that local road situation? Not all local roads have a stated direction
  • Eric: That's always a struggle - following cardinality is a start and helps us disambiguate. If the road goes in a northeast direction and can provide that direction with the line string drawn in the direction of travel, that would really help.

Skylar: My biggest concern with this is reduced data quality, if everyone plugs in "unknown" because it's too hard to get the actual direction.

  • Adam: I share that concern, but is that concern bigger than filling that field in with a guess?
  • Eric: If the provider is at least being cognizant of drawing linestring in the direction of travel, that can really help.
  • Mark: I'm confused about the utility of adding unknown if you already have to draw the linestring in the direction of travel impacted. To do that would require knowing the direction of impact.
  • Adam: That's where you would know the direction on the map, but not necessarily what direction it ends up in. If the vehicle direction of travel changes as you drive around an S-shaped option.
  • Mark: In that situation I would lean toward undefined rather than unknown given that the spec currently handles direction as the signed direction.
  • Eric: Another approach I've seen providers use in that S-shaped option - if the straightline between the start and end goes north, then you can provide north as direction. That can help with some ambiguity.
  • Jacob B.: If you have a start/end, then providing that summary direction would add more value than unknown.
  • Adam: But then if it's being inferred, is there value in the producer doing that to provide direction the data consumer?
  • Eric: There are a lot of feed providers with a spectrum of linestring quality. It's not easy to automatically match, which is where having more signal can help a consumer disambiguate the provider's intent.
  • Chris: Is there any benefit of adding "local" for those situations to prevent overuse?
  • Eric: I'd have to think about it. Any information is better than unknown - it's not awful, but any information is better than nothing. Off the cuff, local is probably better than unknown.
  • Jacob B.: Another intention is for each direction of travel to be represented as it's own event - unknown opens the door to trying to represent the impact to traffic in both directions with just one event.
  • Jacob B.: Also, the description of direction explicitly doesn't accept directions based on heading right now, just based on signed route regardless of heading angle.
  • Eric: Priority #1 is drawing lines in the direction of the event.
  • Adam: I think we need to either add an unknown or update description for when there is not a standard naming convention.

Representing Bidirectional Passing Lanes - Issue #215

Currently, it is not clearly stated how passing lanes primarily used by traffic in the opposite direction should be included in WZDx

  • In examples posted in Discussion #131, the passing lane (opposing travel lane) is indicated as lane 1 with type general since it can be used for travel in the positive direction
  • But this representation is indistinguishable from a roadway with two lanes in the direction of travel

Key questions:

  • How should passing lanes be represented?
  • What is reasonable for data producers to publish?
  • How do data consumers need the information presented?

Proposal: add a no-passing value to the list of restrictions to indicate that passing is not allowed, and only represent a two-lane, two-direction road from the yellow centerline to the road edge.

Discussion

Chris: If you have passing lanes that are added - would that cause a problem?

  • Skylar: The left most lane is always 1, and generally added on the right side. Lane 2 would add to the right. The biggest thing is that we're not counting an opposite direction as a lane.

Renaming WZDxFeed to WorkZoneFeed - Issue #288

There are several issues with the naming of WZDxFeed, mostly related to the name being confusing and only there for historical reasons:

  • Each of three feed types are WZDx feeds, so when referring to a feed out of context, it would be preceded by "WZDx". Thus, the WZDxFeed is the WZDx WZDxFeed.
  • The RoadRestrictionFeed and SwzDeviceFeed (to be DeviceFeed) provide indication of what the feed includes while the WZDxFeed is unclear.
  • Since the feed name does not appear in a feed, changing the feed’s name does not break backwards compatibility and can be implemented in v4.1.

Proposal: Rename the WZDxFeed to WorkZoneFeed

Discussion

Chris Brookes: Thinking long term, are there going to be other feeds that may come out, and may need a simpler branding?

  • Jacob B.: It needs some name (for the object representing the feed and the feed itself)
  • Chris: If there are other things developed, will we know which work zone feed is being referred to?
  • Jacob B.: That's my thought on the implied prefix - you'd call it a WZDx WorkZoneFeed to give the context. And their won't be two WZDx WorkZoneFeed
  • Chris: WZYx WorkZoneFeed - is that something we'd need to worry about long term?
  • Jacob B.: Personally, I'd say no. the WorkZoneFeed change benefits outweigh covering that scenario

Jacob B.: This is kind of a big change for documentation - agency specifications, etc. But as momentum and use of the spec grows, it's worth making that change before it gets harder.

Participants

Name Organization
Marty Lauber Arizona DOT
Mariah Lynch Castle Rock ITS
Jacob B. Larson* City of Omaha
David Craig^ General Motors
Eli Sherer GEWI
Eric Kolb Google
Jeremy Agulnek HAAS Alert
Pete Krikelis Hill and Smith
Ivo Kushkiev Hill and Smith
Jacob B. Brady* IBI Group
Michelle Boucher IBI Group
Rachel Ostroff ICF
Sinclair Stolle Iowa DOT
Skylar Knickerbocker* Iowa State University
Siva Narla ITE
Brandon Saylor Kentucky Transportation Cabinet
Animesh Balse Leidos
Alexander Lemka Maricopa County DOT
Hua Xiang Maryland DOT
Neil Boudreau Massachusetts DOT
Chris Brookes Michigan DOT
Tony English Neaera
Timothy Fiato New York State DOT
Adam Graham*^ one.network
Chad Mann Oregon DOT
Devorah Henderson QLynx Technologies
John Penuelas RTC of Southern Nevada
John Copple Sanborn
Sabrina Mosher Southwest Research Institute
Jianming Ma Texas DOT
Yaw Adu-Gyamfi University of Missouri
Derald Dudley USDOT Bureau of Transportation Statistics
Todd Peterson USDOT Federal Highway Administration
Mark Mockett USDOT Volpe Center
Molly Behan USDOT Volpe Center
Nate Deshmukh Towery^ USDOT Volpe Center
Logan Arens Ushr Auto
Chuck Felice Utah DOT
Tony Leingang Washington State DOT
Erin Schwark Wisconsin DOT
Qassim Abdullah Woolpert
Michael Hanowsky Woolpert

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