Lane Type enumerated type allows values that don't make sense given the context it is used in

[j-d-b]

Simplify the Lane Type enumeration

Background

Currently, the Lane Type Enumerated Type allows values that don't make sense given the context it is used. This type is used by the lane_type field on the lane table--each entry in the table represents a single lane. Many of the allowed types are plural and leftover from WZDx v1 when this enumeration was used on the activity/road event level. Examples: middle-two-lanes, left-3-lanes, etc.

Quick Solution

A quick solution would be to disallow the values that no longer apply. This should have been done for the v2 release but was likely not caught in review.

Simplifying the Lane Type enumeration

While the quick solution solves the biggest issue with the current enumeration, this is a good opportunity to think about what type of lane information we want to get from the lane_type field and thus simplify the enumerations of the Lane Type Enumerated Type.

If we just disallowed the plural/non-applicable values, we'd still have several enumerations which are redundant given information from other fields on the lane object.

An example of a redundant lane type is middle-lane. This value indicates if a lane is the "center most lane where are a total of an odd number of lanes". Since a lane also a lane_number and the road event has total_num_lanes, you could already determine if the lane was in the center.

Thelane_number isn't required, but if a producer could provide the lane_type as middle_lane, they could also give the lane_number for the lane.

Conclusion

An update needs to be made to the Lane Type Enumerated Type and I'm hoping this issue thread can start the discussion on what route we should take to do that, as there is potential to simplify the enumeration as part of the change.

[j-d-b]

Please also see #5, which may be related

[lynnerandolph]

I will say that we have these same issues when suggesting messages for display on DMS signs in response to closed lanes. Many roadways have very complex geometry which may include HOV, express vs local, multiple exit or entrance ramps, etc. Even determining if the "right" lane is closed becomes complicated.

[j-d-b]

As I was going through I found more examples worth referencing here for easy access.

• The value both appears twice in the list of allowed values with different descriptions, but it's impossible to clarify which both one is intending to use and also this value doesn't make sense in describing a single lane, alike to all other plural values
• The values outside and inside are intended for use for shoulders only which is unclear and they should probably be outside-shoulder and inside-shoulder.
• The value none with the corresponding description "No lanes (open or closed)" doesn't make any sense as this enumerated type is used to describe a single lane

I thought the inclusion of these nonsensical values in v2 was reviewer error, but heard in one of the subgroup meetings that intention was to keep the plural types for backwards compatibility. I don't feel like this should have been a good reason to keep them for v2 as the field which this enumerated types was used on was different than in v1. Either way this enumerated type needs to be discussed and edited for v3, whether through removing nonsensical types or deprecating them.

[CraigMoore-Sea]

Deprecating obsolete values make sense in this case to not break backwards compatibility, unless no one is using these.

[j-d-b]

@CraigMoore-Sea I'm not sure how anyone could be using them with a v2 feed as they don't make sense.

It's effectively like v2 deprecated (unofficially) these values so in v3 we could remove them. This is my preferred approach as it leads to a much cleaner v3 spec.

[j-d-b]

Based on co-chairs discussion mid-may, please see #94 with a proposal.

[j-d-b]

Fixed in #94