-
Notifications
You must be signed in to change notification settings - Fork 62
2022 10 31 Specification Update Subgroup meeting
October 31, 2022
- Review proposed approaches to modifying the specification through Pull Requests (PRs).
- Sign-in and Welcome
- Discuss v4.2 PRs
- Action Items and Next Steps
Activity | Subgroup Meetings | Deadline |
---|---|---|
Start-up – Introductions, charter review, backlog grooming | October 3 | N/A |
Review and Prioritize Issues | October 3 | |
Modify Specification Through PRs | October 3 October 31 |
All PRs finished: October 24 |
Review and Finalize Next Version | N/A | All PRs through QA/QC: October 31 |
Present and Vote on Changes | November 21 | Voting period: Tentatively 11/22-12/7 |
Release New Version of Specification | N/A | Specification released: mid-December |
Link to Curb Data Specification – PR #326
- The Open Mobility Foundation released CDS v1.0 in early May
- The spec allows for agencies to create curb zones and attach policies for users to ingest into transportation software
- We are proposing an intersection between WZDx and CDS
- With the proposed optional reference, a work zone event would be able to define curb zone(s) that it would impact.
- Impacted zones will be listed in an array on the new CdsCurbZonesReference to limit the number of objects required
Add Loops to Direction Enumeration – PR #356
Inner and outer loop directions are included in TMDD but not in WZDx for an unknown reason
Adding these to the Direction enumeration would limit need to translate between inner/outer loop and N/S/E/W directions, or to not communicate direction altogether.
Value | Description |
---|---|
inner-loop |
Road flow is in the clockwise direction of a ring road or beltway. |
outer-loop |
Road flow is in the counter-clockwise direction of a ring road or beltway. |
Discussion:
- Lynne Randolph pointed out that TMDD uses inner loop and outer loop
- Jeremy Agulnek was concerned that we may not want to describe where the lanes are physically if we're dealing with temporary changes
- Adam Graham pointed out that the current definition (tied to clockwise/counter-clockwise) would make adoption in the UK difficult.
- Mark Mockett agreed and noted that the co-chairs would work out better wording.
Add Work Zone Type for Moving Work Zones – PR #351
This issue was partly resolved in v4.1 by introducing new relationship type for mobile work zones to reference a planned extent or active work area
- But this solution doesn’t help in situations where only one event is available (either a planned extent or an active work area)
Proposed resolution:
- Add an optional property to the WorkZoneRoadEvent object to provide information about the specific type of the work zone, such as the planned extent of a mobile operation, using a new enumerated type.
New property on WorkZoneRoadEvent object:
Name | Type | Description | Conformance |
---|---|---|---|
work_zone_type | WorkZoneType (see above) | The type of work zone road event, if applicable. | Optional |
New WorkZoneType enumerated type:
Value | Description |
---|---|
static | The road event statically placed — not moving. |
moving | The road event is actively moving on the roadway. As opposed to planned-moving-area , the road event geometry changes as the operation moves. |
planned-moving-area | The planned extent of a moving operation. The active work area will be somewhere within this road event. As opposed to moving , the road event geometry typically does not actively change. |
Clarify Geometry Requirements – PR #358
Current WZDx geometry requirements are vague:
- The geometry of the road event. The Geometry object's type property MUST be LineString or MultiPoint. LineString allows specifying the entire road event path and should be preferred. MultiPoint should be used when only the start and end coordinates are known.
Proposed resolution: Add additional notes to geometry
description and implementation guidance:
- The order of coordinates is meaningful: the first coordinate is the first (furthest upstream) point a traveler encounters when traveling through the road event.
- If a data producer has three or more coordinates that are on the road event path, LineString should be used because it indicates the points are ordered.
- Use a higher density of points points for sections of roadways with curves so a data consumer can more easily match to a their road network.
Discussion:
- Jeremy Agulnek noted that the guidance will be helpful if data producers adhere to it
Improve Lane Status Description - PR #357
The lane status enums for open and closed are:
-
open
: The lane is open to travel. -
closed
: The lane is closed to travel.
This is confusing for lanes that are not typically used for travel. In the current spec, consider an open parking lane:
- lane 'type’ = parking and ‘status’ = open.
- Someone could read this as the lane is open for parking but the ‘open’ status description is the lane is open for travel.
Proposed resolution: Update the LaneStatus description for open and closed:
- Change
open
definition to "the lane is open for normal usage" - Change
closed
definition to "the lane is open to normal usage"
- Review and comment on pull requests on GitHub related to the WZDx Specification with feedback and potential fixes.
- Attend Work Zone Data Working Group meeting on November 21st.
- Vote on PRs for v4.2 after WZDWG meeting.
- Participate in Connected Work Zones standardization effort! Email standards@ite.org with subject line “CWZ Standard Working Group” to get involved.
Name | Affiliation |
---|---|
Petter Lemack | Applied Geographics |
Marty Lauber | Arizona DOT |
Adam Carreon | Arizona DOT |
Mahsa Ettefagh | Booz Allen Hamilton |
Ben Fischer | Butterfly Junction Technologies |
David Aylesworth | CeVe |
Jacob Larson* | City of Omaha |
David Craig | General Motors |
Jeremy Agulnek | HAAS Alert |
Pete Krikelis | Hill and Smith |
Jacob Brady* | IBI Group |
Michelle Boucher | IBI Group |
Jim Williams | INRIX |
Dan Sprengeler | Iowa DOT |
Sinclair Stolle | Iowa DOT |
Skylar Knickerbocker* | Iowa State University |
Will Martin | Leidos |
Samer Rajab | Locomation |
Alexander Lemka | Maricopa County DOT |
Neil Boudreau | Massachusetts DOT |
Nisar Ahmed | Metropolitan Transportation Commission (SF Bay Area) |
Chris Brookes | Michigan DOT |
Tony English | Neaera |
Timothy Fiato | New York State DOT |
Devorah Henderson | Qlynx Technologies |
Nick Boltralik | SwRI |
Lynne Randolph | SwRI |
Jianming Ma | Texas DOT |
Steven Parker | University of Wisconsin TOPS Lab |
Mark Mockett | USDOT Volpe Center |
Molly Behan | USDOT Volpe Center |
Nate Deshmukh-Towery | USDOT Volpe Center |
Chuck Felice | Utah DOT |
Pier Castonguay | Ver-Mac |
Todd Hartnett | Woolpert |
Saman Jabari |
* Co-Chair of the Specification Update Subgroup
Wiki
Work Zone Data Working Group [Archive]
- 2020-08-05: WZDWG semi-annual meeting: minutes, recording
- 2020-02-05: WZDWG semi-annual meeting: minutes, recording
- 2019-12-12: WZDWG semi-annual meeting: minutes, recording
- 2019-07-25: WZDWG kick-off meeting: minutes, recording
Specification Update Subgroup [Archive]
Technical Assistance Subgroup [Archive]
- 2021-02-09: WZDx Technical Assistance Meeting #2: minutes, recording
- 2020-11-19: WZDx Technical Assistance Subgroup Meeting #1 (kickoff): minutes, recording
- 2020-04-06: Technical Assistance Subgroup meeting #1: minutes, recording
Technical Assistance Subgroup Archive
Worker Presence Subgroup