Review LaneStatus descriptions and the relationship between lane status, type, and "open for travel"

[j-d-b]

Background

The WZDx Lane object and the LaneType enumerated type which defines the options for a lane's type have been progressively refactored throughout the development of the WZDx specification.

One thing that I still don't think is well-defined is the relationship between the lane's type, status and whether is it "open for travel".

For example, say a lane has a type of parking and a status of open. In WZDx, the open lane status is defined as "The lane is open for travel". Consequently, one might think that if the parking lane is just open for parking (not travel), it should be given a lane status of closed. With that approach, we lose the ability to describe if the lane is closed to parking due to road work. The WZDx documentation doesn't discuss how to handle this scenario.

Potential solution

A simple change that may add clarity is to change the LaneStatus descriptions from "open/closed for travel" to "open/closed to normal usage". That puts the decision of whether or not it is "open for travel" to the base roadway configuration which is managed by the producers and consumers (WZDx describes the changes due to a road event, not the base information).

For example, the parking lane with a status of open would just not be impacted by the road work and open for normal function, which in the case of the parking lane is not for travel (as noted in the LaneType description for parking lane).

However, give the current definition of the LaneStatus values, this change would cause WZDx to lose the ability to say that a lane of a type that isn't typically able to be traveled in (e.g. shoulder) can be traveled in (via the LaneStatus, at least—one could represent its type with general, but this may be confusing to consumers). Adding something like an open-for-travel restriction would resolve this, but is inelegant because open-for-travel isn't a "restriction", just a "change".

Next steps

• Discuss the relationship between lane type and openness to travel / modality.
• Expand on the potential solution above and/or provide alternative solutions.
• Get input from WZDx feed consumers about how they take the lane information in a WZDx feed and figure out what lanes on their base map each WZDx lane correspond to to see what changes are valuable.

[jlarsonOmahaNE]

One example is a parking lane could show a status of open if it is being used as a travel lane due to an adjacent travel lane being closed.

I think there should be an additional LaneStatus of no stopping : stopping, loading/unloading and parking are all prohibited. This would help identify a closed parking lane and other non-travel lanes.

I also think there should be a LaneStatus for lanes that are not considered "travel" lanes. A normal open parking, bike-lane, sidewalk, etc could have a status of expected: The lane is open for normal use, not a typical travel lane.

[j-d-b]

Notes from co-chairs discussion on 2022-09-23:

• It may be helpful and a minor documentation change to do the change of the the description of open and closed from "open for travel" to "open to normal/intended use" as proposed in the first comment.
• There are are related issues that we can't fully resolve, such as that LaneType doesn't necessarily indicate modality or what normal usage is, so not implementing any changes for v4.2 until there is more in depth design and discussion about lane type and lane status could be reasonable.

[jlarsonOmahaNE]

@j-d-b For the LaneType issue, what about breaking up into two classifications of local and highway? And then expand on the types of lanes.

We could then give a more accurate status if the descriptions are updated as well.

[j-d-b]

Resolved in v4.2.