Require providing lane-level information?

[j-d-b]

Starting off with some history, WZDx v1.0 and v1.1 did not allow specifying lane-level information, only indicating the number of lanes closed. WZDx v2.0 added the ability to provide details about each specific lane within a road event, but kept the higher-level indication of if there were lanes closed through the addition of the vehicle_impact property on the RoadEvent object, intended to be used by producers who could not specify lane-level information. v3.0 further refined lane details, but did not change vehicle_impact or require lane-level information. When lane-level information is provided, vehicle_impact has no value.

All current WZDx producers are specifying lane-level information.

Thus, a question for current and upcoming producers:

Are there any cases where the lane information for a road event (work zone) is not know, but there is still enough other information known to include it in a WZDx feed?

The WZDx specification should be easy to adopt but also as simple and clear as possible. If in most cases when there is enough information known about a work zone or road event to include it in a WZDx feed (i.e. fill out all required fields), lane-level information is know, vehicle_impact should be removed and lanes required.

[j-d-b]

In addition, if providing lane-level information were required, the restrictions array on the RoadEvent object could be removed as the restrictions can be provided via the individual lanes. This avoids having to duplicate information between the lane restrictions and road event level restrictions. There is possibly value in road event level restrictions, though most of the restriction types now apply more clearly to a lane, where they can also be accompanied by a value.

[TranspoShef]

I think there is value in publishing a WZDx feed (or a RoadEvent within a feed) that does not have lane-level information and I would hesitate to require lane-level information for that reason. Current and upcoming producers may be overwhelmed with a lane-level requirement and it could be a participation barrier. Nevertheless, I believe that requiring lane-level information is the only acceptable long-term solution so it also makes sense to require lane-level information and spur the WZDx effort towards the ideal feed. On a related note, I would promote the addition of the following two Road/Lane Restrictions: "no restriction" and "unknown."

[Dunge]

We at Ver-Mac act as WZDx feed producer. We are a roadside traffic control equipment provider and have information related to active work zone locations of all over the country. Our goal is to automate in real time the work zone locations reporting as the equipment are deployed. For example we have small simple sensor which is quick to deploy and can report the start and end location of a work zone. We have digital speed limit signs that are used to reduce the speed of a stretch of road when worker are present and smart arrow boards that can report that a road has one of the lane that is impacted by a changing direction.

We also need to deal with the reality of the field that deploy cones, barrel, signs and others traffic devices days after day. It is not realist that every small work zone maintenance changes lasting few hours requires manual data entry by skilled people to describe those precise lanes definitions and/or splitting the work zone into different RoadEvent based on roadway configuration changes (#78).

According to the recent worker presence survey, only 50% of the respondents are tracking active work zones. Most of that is accomplished by human radio/phone call to report an active work zone with the latency expected by such process. Would it not be important to report a lane closure at the moment an arrow board is activated to shift car while deployment is in process versus 2 hours later when the last sign placed and supervisor verified everything?

This ticket requiring providing lane-level information would effectively prevent us from publishing WZDx feeds and will prevent any type of technology that could automatically detect live the deployment of a work zone and report in a standard way that information to the market.

The spec should keep the base road impact elements to satisfy the current needs of simply knowing where are the work zone (start and end) with some elements that could come from automated system (speed reduction, some lane impacted) to make it very easy to implement so all work zone location can be known in real time. From there additional layers of information can be injected to enrich the feed. WZDx should cover all the various needs and support tiered usage where different layers of resources have different level of information and the aggregation create the ultimate work zone data set.

Of course precise lane-level information is important for the standard, especially for automated vehicles feed consumers. I also agree that having the information in duplicate (general properties on the RoadEvent level versus on the lane-level) is confusing.

My suggestion would be to have different type of RoadEvent. Maybe one RoadEventSimple structure containing the vehicle_impact and restrictions properties, while having the advanced RoadEvent without those two properties but with the lanes array instead.

We even think that the current vehicle_impact enumeration shall be enriched. Today it is not even possible to report that the road is impacted and the vehicle will have to move to the left of the right. Example: An arrowboard will show a right arrow in a lane, but it will never know if this is a merge or shift right. A smart arrowboard can report the location and the arrow pattern but WZdx can’t consume such details. Adding few more arguments to the spec would provide such flexibility and would help the adoption of the standard versus today where DOT needs to develop their own API to collect such data from the field. We will come with a specific issue on that topic later.

[j-d-b]

On a related note, I would promote the addition of the following two Road/Lane Restrictions: "no restriction" and "unknown."

This is a tangent but a good reminder of something to add to the spec documentation, as both "no restrictions" and "unknown" are able to be specified in the spec currently. This is only documented in past issue threads.

"no restrictions" is specified by including the restrictions property on the road event with an empty array as it's value. "unknown" is specified by not including the optional restrictions property on the road event at all. This is a quick addition—I will get this added asap.

[j-d-b]

Our goal is to automate in real time the work zone locations reporting as the equipment are deployed.

That is the ideal scenario, great to hear it.

This ticket requiring providing lane-level information would effectively prevent us from publishing WZDx feeds and will prevent any type of technology that could automatically detect live the deployment of a work zone and report in a standard way that information to the market.

To be clear, this issue was created to hear these kind of things from data producers to find the limitations of requiring lane-level information, not because it is the planned approach. Your scenario supports keeping lane information optional. To confirm, you're saying that you'd like to be able to have the WZ go into the WZDx feed immediately when the start/end location is known (minimum information possible) and then update it with lane information once that is known? So having the lane-level information required delays how long it will take for the WZ to be able to be included in a WZDx feed.

We even think that the current vehicle_impact enumeration shall be enriched.

@Dunge I think enriching this enumerated type has value and encourage you to create an issue for that specifically, to continue the discussion there.

[sergebeaudry]

@j-d-b We would like to send some information like the start/end location and even the lane closure information as soon as they are active. We are not planning to send any accurate lane-level information because the technology does not provide such accuracy today from stationary object. Maybe in some years after the GPS III techno will be fully in place.

I would think that even a CAV could still benefits from the non-lane level information and be able to derive some elements. if it knows in advance that a lane closure to the left is coming on, it can merge before even been at the taper.

So to your question, the lane level information may exist later and maybe will never exist. That is why the road event shall remains possible to be report as light as possible.

I will post another issue on the enriching the vehicle_impact enumeration shortly.

[j-d-b]

Based on today's (2021-05-27) spec update kickoff meeting along with the discussion so far in this issue, it is clear that making lane level info required would be too prohibitive, at least in the near future.