Specification Update Subgroup meeting, June 2022 - usdot-jpo-ode/wzdx GitHub Wiki
Specification Update Subgroup
June 7, 2022
Meeting Information
Objectives
- Review proposed approaches to modifying the specification through Pull Requests (PRs).
- Review and discuss issues not being resolved this cycle.
Agenda
- Sign-in and Welcome
- Highlight Pull Requests (PRs) from Other Subgroups
- Review Previously Discussed PRs
- Discuss New PRs
- Updating Examples on GitHub
- Review Issues Not Resolved This Cycle
- 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
Allow providing a field device without providing a road name – PR #309
- Change the conformance of the road_names property on the FieldDeviceCoreDetails from “Required” to “Optional”.
- This allows producers of a SwzDeviceFeed to provide a field device without having to try to determine the name of the road it is deployed on, simplifying manual entry or internal processes for producers.
Allow a LocationMarker to mark any delineation point in a work zone – PR #311
- Add a delineator value to the MarkedLocationType enumerated type.
- Use for a generic delineation point in a work zone. This value can be used for most types of marked locations that don't match any of the other values.
- Add a ramp-closure value to the MarkedLocationType enumerated type.
- The start of a closed ramp onto or off a main road or highway.
- Add a road-closure value to the MarkedLocationType enumerated type.
- The start of a closed road.
Enable the DeviceFeed to describe temporary traffic signals - PR #313
- Create a new TrafficSignal field device object that allows representing a traffic signal in a WZDx DeviceFeed as its own object with specific properties that apply to it.
- Has "core_details" and "mode" properties
- Create a new TrafficSignalMode enumerated type, used by the TrafficSignal
- Deprecate the "temporary-traffic-signal" value on the MarkedLocationType enumerated type.
Previous meeting notes highlight other subgroup PRs here.
Specification Update Subgroup
Refactor and clarify event status and start/end date verification – PR #294
- This PR follows a similar approach to #281
- Changes to WorkZoneRoadEvent and DetourRoadEvent.
- Deprecate the event_status, 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.
Clarify usage of update_date - PR #302
| \ | RoadEventCoreDetails update_date | FieldDeviceCoreDetails update_date |
|---|---|---|
| Current | The UTC time and date when the activity or event was updated. | The UTC time and date when the field device information was updated. |
| Proposed | The UTC date and time when any information in the RoadEventFeature (including child objects) that the RoadEventCoreDetails applies to was most recently updated or confirmed as up to date. | The UTC date and time when any information in the FieldDeviceFeature (including child objects) that the FieldDeviceCoreDetails applies to was most recently updated or confirmed as up to date. |
Previous meeting notes highlight other Specification Update Subgroup PRs here.
Refactoring Relationship Object - PR #322
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.
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 |
|---|---|---|---|---|
| Array; [RelatedRoadEvent] | A list describing road events which are related to this road event. Examples of related road event include but are not limited to the sequence along the roadway, recurring work zones, related detours or other road events that encompass a similar work area. | 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 | The type of relationship with the 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. The value of this property should correspond to the id of a RoadEventFeature within the same WZDx feed. |
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 in the first occurrence in time of a recurrent work zone. |
next-occurrence |
The first road event in the next occurrence in time of a recurrent work zone. |
related-work-zone |
The first road event of related work zones (i.e. not part of a sequence of road events or recurrent work zone) |
related-detour |
The first road event of related detours (i.e. not part of a sequence of road events) |
planned-moving-operation |
The first road event of a related planned moving operation work zones (i.e. not part of a sequence of road events) |
active-moving-operation |
The first road event of a related active moving operation work zones (i.e. not part of a sequence of road events) |
This issue also partially resolves the Mobile Work Zones issue
- Proposed RelatedRoadEvent object with
planned-moving-operationandactive-moving-operationrelation types - Unable to identify that a future road event is going to be a moving operation because there would be no active moving operation to be related to
Adding 'undefined' and 'unknown' for event direction - PR #304
- 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
directionattribute - New values would allow for data consumers to produce more accurate depictions of data
Proposed additional enumerations:
| Value | Description |
|---|---|
northbound |
Road flow is in the northbound direction |
eastbound |
Road flow is in the eastbound direction |
southbound |
Road flow is in the southbound direction |
westbound |
Road flow is in the westbound direction |
NEW undefined |
Road flow does not have a signed direction. For a RoadEventFeature, the first and last coordinates in the feature's geometry represent the beginning and end of the road event in the direction of travel it impacts. |
NEW unknown |
Road flow may have a signed direction, but the affected direction of travel is not known |
Passing Lanes - PR #306
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
generalsince it can be used for travel in the positive direction
Proposal: add a no-passing restriction and represent only lanes used for primary travel direction (i.e. from the yellow centerline to the road edge on a two-direction road)
Description based from MUTCD
no-passing: Crossing the center line markings for passing is prohibited.
Rename center-left-turn-lane to accommodate left-side driving - PR #314
- Deprecate the center-left-turn-lane value on the LaneType enumerated type.
- Add two-way-center-turn-lane value to the LaneType enumerated type.
- Makes the spec extensible to areas with left-side driving
Updating Examples on GitHub
WZDx GitHub has a section for examples here
Adding graphics: The examples on GitHub currently reference an old discussion post about lane configurations that is now out of date. The co-chairs are planning to add annotated diagrams corresponding to the example within the README, and storing the originals on GitHub for future changes
Co-chairs will also add new examples demonstrating proposed updates to the spec:
- Mobile work zones
- Other new relationship types
Are there other situations that should be included?
Discussion
Dan: As long as you've got the basic blocks, then you should be able to represent anything. Chris B.: When you have a double lane closure and then go to a single lane closure, or have a lane drop. Sometimes lane numbers change and work zone ties in to that (i.e. drop work zone but not pick up another lane). Moreso the double lane closure to single lane closure.
- Dan: We coordinate the lane drop at a ramp - is that what you're talking about? Because that would definitely renumber things.
- Chris: I think this example is in number 6, where you go back to a single lane closure
- Dan: i.e. a long term closure for the top lane, and then an additional closure overnight for the second lane.
- Skylar: We could add a couple different examples related to this. And then introduce other concepts from WZDx to show a complete example of all the functionality. Most of what we've show up to this point is relatively simple - it would be good to show these more complex scenarios.
- Chris B.: An actual split merge with express and local lanes would be good. The interesting thing to show with that - exits that can be accessed vs. not accessed.
- Sinclair: I have another one, where you send traffic across to a lane used for the opposite direction.
Participants
| Name | Organization |
|---|---|
| Marty Lauber | Arizona DOT |
| Lee Jackson | Bentley Systems |
| Mahsa Ettefagh | Booz Allen Hamilton |
| Ben Fischer | Butterfly Junction Technologies |
| Jacob Larson* | City of Omaha |
| Weimin Huang | HERE |
| Todd Hartnett | Hill and Smith |
| Pete Krikelis | Hill and Smith |
| Jacob Brady* | IBI Group |
| Michelle Boucher | IBI Group |
| Sinclair Stolle | Iowa DOT |
| Dan Sprengeler | Iowa DOT |
| Skylar Knickerbocker* | Iowa State University |
| Siva Narla | ITE |
| William Martin | Leidos |
| Samer Rajab | Locomation |
| Alexander Lemka | Maricopa County DOT |
| Neil Boudreau | Massachusetts DOT |
| Chris Brookes | Michigan DOT |
| Justin Anderson | Noblis |
| Kellen Shain | Noblis |
| Chad Mann | Oregon DOT |
| Yang Cheng | University of Wisconsin-Madison |
| Deb Curtis | USDOT Federal Highway Administration |
| Mark Mockett | USDOT Volpe Center |
| Molly Behan | USDOT Volpe Center |
| Nate Deshmukh Towery^ | USDOT Volpe Center |
| Chuck Felice | Utah DOT |
| Erin Schwark | Wisconsin DOT |
| Michael Hanowsky | Woolpert |
* Co-Chair of Spec Update Subgroup
^ Co-Chair of Work Zone Data Working Group