usdot-jpo-ode / wzdx

The Work Zone Data Exchange (WZDx) Specification aims to make harmonized work zone data provided by infrastructure owners and operators (IOOs) available for third party use, making travel on public roads safer and more efficient through ubiquitous access to data on work zone activity.
Creative Commons Zero v1.0 Universal
91 stars 62 forks source link

New event types #139

Closed j-d-b closed 2 years ago

j-d-b commented 3 years ago

Background

The WZDx specification and design goals allow it to be general in use and evolve as needed.

The v2.0 release changed the naming from "work zone activity" to "road event" to begin to open the specification's usage to events on a roadway regardless of if they are a work zone.

The v3.0 release added an event_type field to the RoadEvent object and created an EventType enumerated type. The EventType enumeration contains only two values, work-zone for representing a typical work zone road event, and detour for indicating that a road event is a detour for a work zone.

Detour was just the initial use case for the event_type field. The intention is for this enumerated type to be expanded with more road event types.

Next steps

Discussion of what event types should be added needs to occur—this issue is the place for those discussions.

If a proposed road event type has similar information and impact to travelers as a work zone road event, it is a good candidate to be added. If all the fields on a current RoadEvent object apply to the new event, adding an event type is as simple as adding a new value to the EventType enumerated type.

Example event types

The list of example event types below is taken from MassDOT's legacy event reporting system for inspiration:

Weather
Chemical spill
Special (Road race, parade, VIP visit)

Caveats and other potential changes

A road event was intended to be generic, however it has a few fields which are largely only relevant to a work zone:

Both of these could be made generic by changing to personnel_present (or something similar) and sub_type.

Another option is to create specific objects for each event type which extend the base RoadEvent object with properties that are only relevant to the event type. workers_present and type_of_work would move to the WorkZone object in this case. This allows adding event type specific fields. It is backward compatible as the work-zone RoadEvent details would not change.

yc-uw commented 3 years ago

in WI, we use event types as follows: a. Construction b. Maintenance c. Permit d. Special Event e. Emergency Closure Among them, a., b., and c. are work zone related, and d. Special Event is for lane closures due to parades, festivals, etc., that close the roadway to traffic and e. Emergency Closure is for road closures due to flooding, pavement repairs, etc., since they have similar impacts to travelers.

j-d-b commented 3 years ago

To add to this, "snow and Ice" was recently brought up at a meeting with MassDOT.

j-d-b commented 3 years ago

The spec extension subgroup generated the idea for a restriction-notice road event type. This event type would be used for road events that are intended to represent a section of a roadway with with a specific restriction. A restriction-notice road event can represent a permanent restriction unrelated to road work or a work zone, such as reduced height due to an overhead structure, reduced width on a bridge, etc.

I believe @DeraldDudley is going to create a new issue for the restriction-notice type specifically, which will be referenced here once it is created.

DeraldDudley commented 3 years ago

Created issue #178 to address restriction-notices directly.

j-d-b commented 2 years ago

Closing as the spec has changed significantly since the issue was created and new event types have been partially resolved in #205.