Introduce 'unknown' for event Direction

[adam-graham-one-network]

Issue name: “Introduce an 'unknown' for event Direction”

Summary

Not all existing permit systems provide a direction. There will be a number of events where the direction will be unknown and difficult to infer based on the data. Adding an unknown rather than an 'educated guess' is likely to be better for the data consumer.

Motivation

At the moment a direction HAS to be included - even if it is wrong. By being explicit where the direction is unknown the data consumer can make their own assessment and truly trust the data where the direction is defined.

Proposed changes

Introduce a new option of 'Unknown'

[j-d-b]

I agree with allowing road events to be provided even when the direction is not know. The direction property (on the RoadEventCoreDetails used by all types of road events) is currently defined as:

The digitization direction of the road that is impacted by the event. This value is based on the standard naming for US roadways and indicates the direction of the traffic flow regardless of the real heading angle.

This doesn't apply to local roads and thus limits the WZDxFeed from being used cleanly for representing road events on these roadways.

As for implementation, I propose an alternative approach that is more consistent with how the rest of the specification represents information that is unknown—rather than add unknown to the Direction enumerated type:

• Change the conformance of the direction property of the RoadEventCoreDetails to Optional.

[j-d-b]

I think we should consider renaming the property to road_direction to clarify that it refers to the direction of the roadway, not the real direction of the road event.

[j-d-b]

An issue with changing direction to optional is that it allows a single road event to represent an impact to multiple directions of travel. The business rules clarify that a work zone with impact to both directions on a bidirectional roadways should have a road event for each direction of travel, but the requirement of the direction property clarified that.

[sergebeaudry]

One of the important reason of WZDx is to help CAV and general public to know where are the workzones. if we can't tell which direction is impacted we don't achieving one of the goal. Imagine if GoogleMap, Waze would calculate impact based on all roadwork regardless of the direction. On the other hand I understand that some solution may not have such data. I would keep the directionas required and add the unknown value. Then the data consumer could decide if they want to use or not that info. EX: a Waze or google may opt to just drop such value as not enough precise and another user may find it enough useful Keeping is required will force the data provider to select something.

[eli104]

My caution here is twofold.

1. Making the Direction an optional selection would invite guessing more than anything. For a work zone, even one on an undivided roadway, NOT having a direction might lead to confusion on the part of the end-user, and thinking ahead, avoidance of the entire area by automated vehicles. (If they don't know the direction of a closure, you may as well avoid the entire roadway since either direction could be affected).
2. Having said that, I will echo back something I mentioned in another thread about the purpose of WZDx. If the focus is on Work Zones, then I would imagine a significant percentage will be permitted and planned out. Even in emergency work (i.e. pothole repairs on a highway, or similar), someone, somewhere knows where the crews will be working. The only time an event would require the use of a location of Unknown Direction would be if someone called in a problem and there was an emergency crew responding to confirm it. THAT is not a Work Zone event, that is an unplanned Traffic Event.

So the caution is allowing too much Scope Creep into the scenarios WZDx is being built for... just sayin'.

[rdsheckler]

I am sorry Eli but based upon our experiences the majority of our deployments do not correlate to a planned project in the state database. Yes, they may be in another database but until we have access to all of the planning we have to expect that 85% of the device data will not correlate to the permit/planned work.

[eli104]

I won't say you are wrong Ross... but I think we should be looking at creating a standard that asks for a higher level of detail to increase its value, rather than finding ways to let whoever uses it (let's assume a public agency), provide less detail than would satisfy the end-users of the data, such as Navigation systems and Automated driving.

If we agree that the standard provides a method for an agency to create useful and actionable data, then then the standard should incentivize the agency to provide the location, including the direction, even if their work plans do not have it. (If they don't know the location and direction of the work zone on their own roadways, that's a very different issue).

I am NOT saying that there might be a case where someone creates a work zone event and is missing some detail... But at the same time, I am concerned that the utility of the WZDx standard will be diminished if it regularly allows someone to skip over important details on a regular basis.

What I AM saying is that if the standard requires the agency to fill the direction field, they may have to do a bit more work and find out the direction before completing the Event entry. OR, they may also simply guess at the direction and then go back and change it if the initial guess is wrong. But if the standard allows them to skip the direction field entirely, then they may skip it and not bother to fill it in later on. At which point the value of the data goes down significantly, and the value of the WZDx standard goes down with it.

[j-d-b]

@eli104, I think your last paragraph above is great reasoning for keeping direction required and not adding unknown—that is, no specification change. That is my preference given the discussion up to this point.

The only change I would propose is changing the name of the property to road_direction, because that is what it is describing.

[adam-graham-one-network]

I think there has been some really good discussion on this. I think it comes down to a judgement call on what is likely to give data consumers the most reliable and trustworthy data.

If we continue to have direction being a mandatory field then road agencies who do not have a direction field have two choices:

1. Do not engage with WZDx until they have an improved system - this means that we are excluding the agency and reducing the amount of data consumers get access to (man would be able to infer the direction or at least use it as a signal to cross validate with other data)
2. Submit their work zone data and submit a potentially incorrect direction. This will reduce the confidence in the direction field for data consumers as there is a higher chance that an incorrect value has been entered.

On the flip side having this as mandatory may push data producers to improve their systems, my concern is with WZDx being optional and not mandated it may be easier to ignore WZDx than engage positively.

I believe introducing an 'unknown' option would allow the direction data that is included to be 'clean'. Also, the types of organisations who are engaging with WZDx at this relatively early stage are doing so to be industry leaders and as such are likely to pursue excellence and work towards full direction compliance where available.

On a final note, for cities and counties the road direction may only be related to the bearing, local roads do not always have a specified direction and therefore selecting a direction rather than snapping to the network using the start and end point bearing is less helpful based on our conversations with consumers.

[sergebeaudry]

I'm in support with @adam-graham-one-network

I believe introducing an 'unknown' option would allow the direction data that is included to be 'clean'. Also, the types of organisations who are engaging with WZDx at this relatively early stage are doing so to be industry leaders and as such are likely to pursue excellence and work towards full direction compliance where available

Let the data provider tell if their data is complete or not and the data consumer to figure action based on that information

[mark-mockett]

Based on discussion among the Spec. Update co-chairs, it would be best "unknown" and "undefined" to the enumerated type with two different use cases:

Value	Use case
undefined	Used if a data producer has start and end location for a road, but the road doesn't have a direction. Allows data consumers to assume that first coordinate is the start of an actual work zone.
unknown	Used if a data producer doesn't know for sure which direction of travel is affected (including on a roadway with signed directions). Create an event for each direction and use the unknown enumeration. The data consumer cannot safely assume that work is affecting this direction of travel.

[j-d-b]

Resolved in #304.