Additional vehicle_impact to enable real time field data

[sergebeaudry]

Issue name: “[Clarification / New feature / Question] — Summarize topic”

Summary

Current version does not enable work zone data exchange on important real-time work zone events. EX: a lane closure just been deployed, nothing can tell if the merge is to the right or left unless lane level is provided which is not realist. The following is to add a few new road-impact enumeration to exchange such data elements.

Background

The current roadevent structure has been developed to address a very detailed level of information that could be capture during the planning phase and which can help the data user such as mapping companies and CAV/ADS to figure out the impact of the planned works on their maps. Thus could help them sending resources to digitize the road layout during and after the works.

Real time active work zones

Technologies exists that can reports some real-time field information. Smart Arrow Board can publish their GPS location and the type of merging arrow presented to the motorist (left/right). Temporary traffic light and Flagging operation can also be reported in real-time. Today WZDx cannot be used to exchange that real-time information because that level of detail is only reported inside lane-level elements. It is not realist to expect an arrow board to report such level of lane-level information.

Such level of basic real-time road impact is important for many reasons:

• When correlated with the planned information it could help to change in real-time the date and location accuracy from estimated to verified. It could be used as the enabler to start publishing or to stop publishing a work zone events in real-time.
• It provides an easy way to detect any unplanned work such as the short-term maintenance/utility works.
• Use alone it help to inform the general public that a lane is merging and to which side
• When correlated with a CAV/ADS onboard sensors it can help an autonomous car to safely merge ahead of the merging point. EX: car is on a 2 lanes freeway, with solely the “merge left” road impact the car driving on the right lane knowns that it will need to merge left prior to that location.

Some DOT already started developing their own API to receive such work zone information because WZDx can't support it today.

Proposed changes

I recommend to add to the Vehicle Impact enumerated type the following (current = already in the specification):

Status	Value	Description
Current	all-lanes-closed	All lanes are closed
Current	some-lanes-closed	Some lanes are closed
Current	all-lanes-open	All lanes are open
Current	alternating-one-way	The roadway is alternating one way
Current	unknown	The vehicle impact is unknown
New	some-lanes-closed-merge-left	Some lanes merge to the left
New	some-lanes-closed-merge-right	Some lanes merge to the right
New	some-lanes-closed-split	Some lanes end and split & merge to the right and left
New	flagging	A flagging operation is in affect. For ADS this is more precise than the alternating-one-way. EX: look for human with flag or an AFAD
New	temporary-traffic-signal	A temporary traffic signal is installed. For ADS this is more precise than the alternating-one-way. EX: look for a traffic signal not on the map

[sknick-iastate]

At the last subgroup meeting we discussed adding all-lanes-open-shift-left and all-lanes-open-shift-left. This would then cover all of the lane level statuses that can be provide but at the vehicle impact level.

There was also discussion on whether the alternating-one-way was redundant for flagging and temporary-traffic-signal and could potentially be removed. It sounded like there may be other potential use cases for the alternating-one-way and should be retained for now unless there are additional comments.

Also from the subgroup meeting was a discussion about coordinating with the worker presence subgroup related to flaggers. Since the flagging in @sergebeaudry list also includes AFAD I think there should be a distinction from what the worker presence subgroup is discussing at this point but may require further coordination.

[sknick-iastate]

@sergebeaudry - Would you be able to put a pull request together with the changes you suggested as well as adding the all-lanes-open-shift-left and all-lanes-open-shift-left?

[sergebeaudry]

@sknick-iastate sorry I'm late on this. Yes I'll do a pull request

[sergebeaudry]

@sknick-iastate Regarding your comment

Also from the subgroup meeting was a discussion about coordinating with the worker presence subgroup related to flaggers. Since the flagging in @sergebeaudry list also includes AFAD I think there should be a distinction from what the worker presence subgroup is discussing at this point but may require further coordination.

I don't think AFAD or human flagger are really different from the Worker Presence perspective. In both case worker(s) are present. An AFAD has to be operated by a flagger per MUTCD. Next revision is also proposing to clarify further by precluding any sort of automation

[j-d-b]

Completed in #196.