Add restriction-notice to the EventType Enumerated Type

[DeraldDudley]

Add New Event Type: restriction-notice

Adding a restriction-notice to the EventType Enumerated Type enables State DOTs to warn drivers of hazardous restrictions such as low-clearances beneath bridges.

Benefits

• Helps mitigate loss of life, personal injury, infrastructure damage, lost time and money, unnecessary emissions, and all the other ill effects of bridge and tunnel strikes.
• Fosters in-vehicle warnings about hazards to navigation.
• Establishes the WZDx specification can be leveraged to make transportation safer by extending it beyond its original purpose.
• Extending the specification may draw more agencies into using the Work Zone components of the specification.

Costs

• Diversifying the specification is off scope.

Support

• The New York State DOT has committed to developing a prototype feed.
• Other State DOTs have expressed interests.
• Google and Here have committed to consuming and testing NYSDOT's feed
• The National States Geographic Information Council endorses the project.

Example

• An example of the restriction-notice EventType.

[j-d-b]

I like this addition. It is simple, backwards compatible, flexible, and allows using the WZDx model to represent any kind of restriction on the roadway.

Note 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.

[sergebeaudry]

What would be qualified as a source of restriction-notice? everything in road restriction

[j-d-b]

After the creation of #191 and spec extension subgroup meeting, it was decided that the restriction notice is better addressed in a new feed rather than the WZDxFeed, which should stay focused on work zones and similar or related road events (e.g. detour).

[DeraldDudley]

The question of how to coordinate the maturation of the specification remains unanswered.

The second objective of the WZD Working Group, as stated in the WZD WG Charter, is to...

2. Ensure the Work Zone Data Specification is scalable and accommodates multiple missions by employing object-oriented development strategies.

When implementing object oriented development strategies, we must recognize that the work-zone Event Type is a subclass of a Road Event superclass. (See Draft RoadEvent Inheritance Model below.) The RoadEvent superclass uses the minimum content needed to describe a Road Event. A work-zone subclass uses the superclass' content plus specialized content to describe a unique instance of a Road Event.

We can separate Restriction feeds, from Work-Zone feeds, from Smart Work Zone feeds but it is everyone's best interest to coordinate the development of the specification's object model. Not coordinating its development will result in diverging specifications which is contrary to this groups larger mission.

Some recommendations...

1. Rename the specification from the Work Zone Specification to something that more accurately reflects its larger purpose. Consider Road Data Exchange Specification or Transportation Data Exchange Specification.
2. Restriction feeds, Smart Work Zone feeds, and any derivative feeds are managed as part of this GitHub repository to mitigate divergent content.
3. The Work Zone Data WG remains focused on work zones.
4. Other subgroups remain focused on coordinating the maturation of the specification with the update subgroup.

Draft RoadEvent Inheritance Model

[DeraldDudley]

After today's extension meeting I'm providing a nested model...

Draft RoadEvent Nesting Model

[DeraldDudley]

This should be contingent on issue #203

[j-d-b]

Completed by adding the RoadRestrictionFeed and RestrictionRoadEvent in #205 (WZDx v4.0).