Refactor LaneType enumeration to deprecate values that can be determined from other properties, such as order, status, and restrictions

[j-d-b]

This PR resolves #137.

The changes were made following the most recent proposal in that issue, that is

1. Deprecate left-lane, right-lane, middle-lane, center-lane and use lane (which is already in the spec) instead
2. Deprecate left-shoulder, right-shoulder and use shoulder (which is already in the spec) instead
3. Change description for right-turning-lane, left-turning-lane to clarify the lane's position can be anywhere (specified by order) and that the "left" and "right" only refer to the direction of the turn
4. Change description for right-exit-lane, left-exit-lane to clarify the lane's position can be anywhere (specified by order) that the "left" and "right" only refer to the direction of the exit. Additionally, note this lane can be a "ramp".
5. Deprecate right-exit-ramp, right-second-exit-ramp, left-exit-ramp, left-second-exit-ramp; these are encompassed by the changes in 4.
6. Add new right-entrance-lane and left-entrance-lane types. Clarify in the to clarify the lane's position can be anywhere (specified by order) that the "left" and "right" only refer to the direction of ingress. Additionally, note this lane can be a "ramp"
7. Deprecate right-entrance-ramp, right-second-entrance-ramp, left-entrance-ramp, left-second-entrance-ramp; these are encompassed by the changes in 6.
8. Deprecate right-merging-lane, left-merging-lane; these can be specified by with the LaneStatus of a lane (merge-left or merge-right)

Edit: see below for the updated proposal based on discussion since the first draft PR was made.

[chuehlien]

@chuehlien The deprecated values should not be removed as they are still allowable values. There isn't a way to indicate a value of an enum is deprecated in JSON Schema. There isn't a way for properties either (in JSON Schema draft 7 which we're using; there is in the newest version) but at least then I can write in the description.

Got it - thanks for clarifying this! I added the ramps/merging lanes that I had removed back in.

[j-d-b]

Thinking about this more, as part of this cleanup it may be worthwhile to remove the "lane" suffix from many of the lane types. This suffix is implied in all cases and is already not used on shoulder and sidewalk. See below for the changes:

This was inspired by #149 as this change would remove having to define the difference between a "ramp" and "lane" or choose one of the terms for the lane type.

1. lane -> generic (or general). Taking inspiration from @semosher comment in #149, this could also split to main and other or main and generic, to allow specifiying a main travel lane distinctly from the generic lane type.
2. right-exit-lane and left-exit-lane -> right-exit and left-exit
3. right-turning-lane and left-turning-lane -> right-turning and left-turning (or turn, open to comments here but want consistency with center-left-turn, so that should change to turning or these should be turn)
4. hov-lane -> hov
5. right-entrance-lane and left-entrance-lane -> right-entrance and left-entrance
6. center-left-turn-lane -> center-left-turning (see comment in 3.)
7. alternating-flow-lane -> alternating-flow
8. reversible-lane -> reversible

The list of non-deprecated lane types would then be:

main (see comment on 1. above)
generic
shoulder
sidewalk
right-exit
left-exit
right-turning (or "right-turn")
left-turning (or "left-turn")
hov
bike (this is the only one that sounds weird—thoughts on changing this to "bicycle" for clarity?)
right-entrance
left-entrance
center-left-turning (or "center-left-turn")
alternating-flow
reversible

All types in v3.0 except shoulder and sidewalk would be deprecated as the rest are new.

We would also remove the connection to the TMDD (which is already on its way out) which would clean up the table and allow for consistency with the rest of the specification enumerated types.

All, let me know thoughts on this. If we are going to make this kind of change, doing it sooner when we only have a few producers and are already deprecating many of the types is advisable.

[j-d-b]

@sknick-iastate @DeraldDudley @CraigMoore-Sea check out the above proposal and let me know your thoughts. I'll wait for some feedback before making any changes to the PR

[daylesworth]

@j-d-b, is there a goal to align these with SAE J2735 lane types (I guess this question could apply across all of WZDx, and other ITS standards)? If so, does DOT have permission from SAE to share relevant parts of their standards in this forum? Do we need permission to simply align the lexicon without sharing implementation details of the standards? If someone can answer these questions then I'm happy to provide feedback regarding alignment with J2735 (including lane types and attributes), but I only have access to published SAE standards and not WIP.

[j-d-b]

@daylesworth it is a goal is to align with existing standards where it is logical and matches the intended use of the standard.

The lane types were based on TMDD but that became less relevant as we are no longer using the lane types to describe the lane's location.

I don't have access to the SAE J2735 document. If its possible for you to post the lane types here, that would be helpful.

[daylesworth]

@j-d-b, I have a personally-licensed copy of the standard but it has a copyright notice that restricts any reproduction without permission from SAE, so I think DOT should request permission for this effort. Instructions can be found here... [https://www.sae.org/about/legal-policies?tab=4]

That said, here are the key differences...

• treats HOV as an attribute/restriction of a "vehicle" lane type (other attributes include bus, taxi, etc.)
• treats allowed maneuvers (left, right, u-turn, etc.) independently from lane types and attributes
• has several lane types not proposed here, including crosswalk, median, striping, tracked vehicle (trains/trolleys), and parking

[j-d-b]

@daylesworth thanks for enumerating the key differences. My comments below:

* treats HOV as an attribute/restriction of a "vehicle" lane type (other attributes include bus, taxi, etc.)

I like that approach. In fact, in WZDx there are already HOV-related restrictions in the RoadRestriction enumerated type. Is there any value in the hov-lane lane type?

More generally, what are producers using these lane types for? I can answer for MassDOT, where the lane type string is used to render a lane graphic for human use.

* treats allowed maneuvers (left, right, u-turn, etc.) independently from lane types and attributes

Separating the allowed maneuver from the lane type is similar logic as treating the "hov" designation as a restriction rather than a lane "type". I support this as well. I'm hoping to make the lane type enumeration as minimal as possible. Many of the current lanes types could be removed and the functionality moved to either a restriction or the status. E.g. exit-lane, could be indicated by a lane type of lane with a restriction of exit-only.

* has several lane types not proposed here, including crosswalk, median, striping, tracked vehicle (trains/trolleys), and parking

This one might tie into being able to offer lane-level geometry, which is not something. Thus it is assumed that all lanes are parallel, which may mean crosswalk, striping don't have value here yet. I don't feel like tracked vehicle fits in as well. parking I think should be added.

[natedeshmukhtowery]

Re. access to J2735, USDOT is looking into access to the relevant sections for this PR - thanks for raising, and stay tuned!

[j-d-b]

I feel that more discussion needs to happen regarding lane types—see #149 as well. Once we decide how we want to handle lane types in WZDx, then we can make a clear change and go with that going forward.

[j-d-b]

The co-chairs have reviewed SAE J2735 and though we are not going to implement lane types as done in that standard, it is useful to see allowed maneuvers and restrictions like "hov" being treated separately from the lane's type.

We next discussed what the value of the lane type is in WZDx—what is the utility of this field? Is it used to distinguish which modes of transportation are allowed (e.g. bike-lane, sidewalk, vehicle-lane)? Does it indicate if vehicles (e.g. cars, trucks) are allowed on it?

What was clear is that there needs to be more discussion before we can propose a final solution for describing lanes. Thus this PR will address the simple changes of removing the "sides" of the roadway from the list of lane types and values that are addressed by either the lane's status or restrictions. I recognize that this leaves an ambiguous and incomplete list, which will be addressed in a future release once it is decided what the unique value of the lane type should be.

Thus the changes are now as follows:

1. Deprecate left-lane, right-lane, middle-lane, center-lane and use lane (which is already in the spec) instead
2. Deprecate left-shoulder, right-shoulder and use shoulder (which is already in the spec) instead
3. Change description for right-turning-lane, left-turning-lane to clarify the lane's position can be anywhere (specified by order) and that the "left" and "right" only refer to the direction of the turn
4. Change description for right-exit-lane, left-exit-lane, right-exit-ramp, left-exit-ramp to clarify the lane's position can be anywhere (specified by order) that the "left" and "right" only refer to the direction of the exit.
5. Deprecate right-second-exit-ramp, left-second-exit-ramp; these are encompassed by the changes in 4.
6. Change description for right-entrance-ramp, left-entrance-ramp to clarify the lane's position can be anywhere (specified by order) that the "left" and "right" only refer to the direction of the entrance.
7. Deprecate right-second-entrance-ramp, left-second-entrance-ramp; these are encompassed by the changes in 6.
8. Deprecate right-merging-lane, left-merging-lane; these can be specified by with the status (see LaneStatus) of a lane (merge-left or merge-right)
9. Deprecate hov-lane lane type. This can be specified by the restrictions property on the lane (see RoadRestriction, using hov-2 or hov-3
10. Add new LaneStatus alternating-flow meant to replace the existing alternating-one-way but have a broader usage, covering any scenario where a single lane is used for traffic in both directions with the direction depending on certain conditions. This covers reversible lanes.
11. Deprecate LaneStatus alternating-one-way, use alternating-flow instead.
12. Deprecate alternating-flow-lane. This can be specified by the status (see LaneStatus) of a lane (alternating-flow)
13. Deprecate reversible-lane. Like merging-lane and alternating-flow-lane, reversible lanes are better addressed by the lane's status, using alternating-flow.

In summary, this PR currently results in the following non-deprecated lane types:

lane
right-turning-lane
left-turning-lane
right-exit-lane
left-exit-lane
right-exit-ramp
left-exit-ramp
right-entrance-ramp
left-entrance-ramp
sidewalk
bike-lane
shoulder
center-left-turn-lane

[j-d-b]

Here is an incomplete proposal for even simpler lane types, for discussion:

General/Normal/Travel/Main/Vehicle (need to choose one term)
Sidewalk
Bike lane
Exit ramp/lane
Entrance ramp/lane
Shoulder
Parking (new functionality)
Median (new functionality)
Center left turn lane

Compared to the list in the above comment, this list drops the ability to tell the direction of egress/ingress of an exit/entrance ramp/lane from the lane type (maybe this doesn't matter). It also drops the turning lanes, which are incomplete and not too helpful anyway as there is a lot of functionality missing ("left turn only", "straight only", "right or left turns" etc.). As done in SAE J2735, perhaps the turns (what maneuvers are allowed) should not be part of the lane type. Then the question is whether we want to address that in WZDx at all...