Alignment with USDOT Connected Work Zones

[schnuerle]

Links:

• WZDx
• CDS

Discussed in https://github.com/openmobilityfoundation/curb-data-specification/discussions/53

^{Originally posted by **schnuerle** December 20, 2021} How could CDS align with the USDOT's Work Zone Data Exchange (WZDx)? This came up in a discussion of lane types around a curb, vehicles that could be double parking or blocking curbs, and where and how to specify or align with WZDx IDs. https://github.com/openmobilityfoundation/curb-data-specification/discussions/37#discussioncomment-1671646

[jlarsonOmahaNE]

Going through the WZDx specs, A great start would be looking into the WorkZoneRoadEvent Object and RoadEventFeature Object. I think that vehicle_impact and event_status would be of interest to the curb zone. Also, adding a curb lane to the LaneType would help with the overall alignment. I will tag some co-chairs over on the WZDx GitHub.

[jlarsonOmahaNE]

In order to tie together I think another Activity called closure that states all vehicle interactions are prohibited. Would this then also reflect into the Curb Space available field?

[schnuerle]

From @bhamlinSDOT in #53:

I recently had some discussions with SDOT staff that are involved with the WZDx and there seems to be a number of areas where CDS could align with the WZDx.

• WZDx is currently using GeoJSON polyline and multi-point features rather than polygons mostly due to the fact that most agencies don’t have polygon data for their roads yet. WZDx doesn’t exclude polygon data since it’s just using a GeoJSON feature.
• Look at how WZDx road events that would close curbspaces and understand how an agency can build a streamlined workflow to communicate these closures in both feeds.
• Explore is scheduling, which by nature is quite built out in CDS, but where WZDx is still struggling to define how it will communicate these; particularly is cases where one part of a complex schedule changes… how is that communicated?
• WZDx has a lot of working ongoing surrounding communication of worker present and other ‘live’ data directly from field devices. It looks like CDS has thought this through with the Event object, much of which could translate to WZDx.

[schnuerle]

See this discussion for possibly aligning lane types in #37.

https://github.com/openmobilityfoundation/curb-data-specification/discussions/37#discussioncomment-1653357

[schnuerle]

Idea for cross referencing WZDx and CDS by unique identifiers, eg CDS curb_zone_id or curb_area_id and WZDx id.

Added to the public CDS Curbs feed in the curb and area objects could be the following fields in an array:

• wzdx_feed_url - required if linking to WZDx feed
• wzdx_id - required if linking to WZDx feed

which would simply reference any active or upcoming WZDx feeds and ids that impact the defined CDS locations.

E.g. "wzdx_feeds":[{"wzdx_feed_url":"http://www.url.com/path","wzdx_id":"####"},{"wzdx_feed_url":"http://www.url.com/path","wzdx_id":"####"}]

And added to public WZDxFeed feed in one of the RoadEvent properties under their CoreDetails could be the following fields in an array:

• cds_feed_url - required if linking to CDS feed
• cds_curb_id - optional, but one curb or area id required
• cds_area_id - optional, but one curb or area id required

that reference any CDS curbs or areas from the public Curbs API feed that are impacted by this workzone. Maybe these can be wrapped and grouped under a cds_impacts field so an array of these items could be defined without much direct impact to the spec.

This would allow producers of WZDx to check then include a reference to any overlapping CDS feeds for their consumers, and the producers of any CDS feeds to check then include a reference to any overlapping WZDx feeds for their consumers.

[jlarsonOmahaNE]

I know that for most providers at the state level, introducing a required field for CDS may be hard as they do not necessarily work with loading/unloading. I think it may also break compatibility with their current spec but would love to see what Nate or Mark from Volpe have to say.

In the WZDx feed, I think some new LaneType values could be added. These could be loading, bus-lane and street-car along with others.

For another direct connection, I think that RestrictionType could include the addition: no loading/unloading.

[schnuerle]

I created a pull request #96 to discuss how this could be implemented on the CDS side.

See this view for what is new/changed.

[jlarsonOmahaNE]

@schnuerle After previous discussions with WZDx members, I think it would be best for the WZDx feed to have an optional CDS reference point so that agencies would be able to track how many workzones are affecting different types of curb zones at a given time. This could be done internally without a new field in WZDx by looking at intersecting data. A new field would allow for a management system to actively tie the workzone to a curb zone without having to run a spatial analysis but still could be ran for verification.

[schnuerle]

There is now a PR in WZDx to add references to CDS here https://github.com/usdot-jpo-ode/wzdx/pull/326

[jlarsonOmahaNE]

The PR #326 has been approved by the WZDWG and will allow for curb zones to be referenced in v4.2 which will be released this month!