CraigMoore-Sea
commented
3 years ago This is a great idea! Seattle already uses our feed to communicate scheduled events that impact travel such as parades and runs. The necessary data overlaps that of work zones significantly and the end consumers are the same.
I suggest moving the following properties form the WorkZoneEvent to the RoadEvent since each RoadEvent can only represent one GeoJSON feature: beginning_cross_street ending_cross_street beginning_milepost ending_milepost
We may want to consider moving the spatial verification properties as well but I can envision cases where you would want the spatial verification tied to the WorkZoneEvent; such as when the spatial verification is being communicated by an automated device at the work zone.
j-d-b
Establishing a RoadEvent superclass and a WorkZoneEvent subclass
The RoadEvent object in version 3.1 of the Work Zone Data Specification comingles two objects, Road Events and Work Zone Events, in a single class. Comingling different objects in a single class deviates from the well-established best practice of data normalization. Normalization is important in data design because it reduces redundant data storage and exchange.
Normalization is important to the Work Zone Data Working group because it eliminates the unnecessary exchange of unneeded, or unwanted, data and enables the publication of basic road features like named roads or named roads with restrictions. Without normalization the required fields prohibit the specification from being used to publish anything other than a Work Zone Feature or a detour related to a work-zone. Making the specification flexible, enabling it to address nonwork-zone use-cases, maximizes its social benefit.
Normalizing the content of the Road Event object will create two classes; A RoadEvent class and a WorkZoneEvent class. (See model at end of post.) Each object will only contain the properties necessary to exchange information about itself. The RoadEvent class would contain 10 properties; Four of which are required. Similarly, the WorkZoneEvent would contain 25 properties; Eleven of which are required. The WorkZoneEvent would inherit 10 RoadEvent properties and has 15 properties specific to a work zones.
With normalization, a data publisher needs only 4 properties to publish a basic road feature like a named road segment: event_type, source_id, names, and direction. A data publisher needs 11 properties to publish a work-zones.
Positives
Negatives
Draft Normalized Class Model