Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alignment with USDOT WZDx #74

Open
schnuerle opened this issue Feb 8, 2022 Discussed in #53 · 10 comments · May be fixed by #96
Open

Alignment with USDOT WZDx #74

schnuerle opened this issue Feb 8, 2022 Discussed in #53 · 10 comments · May be fixed by #96
Milestone

Comments

@schnuerle
Copy link
Member

schnuerle commented Feb 8, 2022

Links:

Discussed in #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.

#37 (reply in thread)

@jlarsonOmahaNE
Copy link
Collaborator

jlarsonOmahaNE commented Feb 8, 2022

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
Copy link
Collaborator

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 schnuerle added this to the Future milestone Feb 9, 2022
@schnuerle
Copy link
Member Author

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
Copy link
Member Author

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

#37 (comment)

@schnuerle
Copy link
Member Author

schnuerle commented Mar 7, 2022

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
Copy link
Collaborator

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 schnuerle linked a pull request Jun 14, 2022 that will close this issue
@schnuerle
Copy link
Member Author

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
Copy link
Collaborator

@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 schnuerle linked a pull request Jul 8, 2022 that will close this issue
@schnuerle
Copy link
Member Author

There is now a PR in WZDx to add references to CDS here usdot-jpo-ode/wzdx#326

@jlarsonOmahaNE
Copy link
Collaborator

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!

@schnuerle schnuerle modified the milestones: Future, 1.1 May 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants