Clarify lane types and usage of lanes table

[j-d-b]

This PR resolves #72 by updating the Lane Type Enumerated Type as well as clarifying the usage of a "lane" and the meaning of lane types. As part of that process, it addresses other lane-related issues, such as ordering. Three sets of sequential changes were made; each depends on the previous. I can refactor the code changes in this PR to address either just 1, 1 and 2, or all 1, 2, and 3:

1: Clarify usage of lanes table and clean up lane types

The following changes are proposed to cleanup and clarity the ambiguity in v2.0:

1. Clarify that an entry in the lanes table represents a single lane
2. Remove all plural values from the Lane Type Enumerated Type, such as both, none, left-two-lanes, middle-two-lanes... etc.
3. Rename lane type values outside and inside, which were ambiguous but intended (by description) for shoulders, to be left-shoulder and right-shoulder, which then matches the TMDD LaneRoadway enumeration values.
4. Change middle-lane description to note it can be used for any lane that is not the right- or left-most lane, not just the "center lane when the total number of lanes is odd", and added a new type center-lane to capture the former middle-lane functionality. This is more appropriate as the TMDD LaneRoadway has a specific "center lane" type, which is different from middle-lane.
5. Note that WZDx lane type bike-lane relates to the TMDD LaneRoadway cycle-lane (these were not connected before)
6. Clean up the Lane Type Enumerated Type file by moving unused TMDD LaneRoadway types to their own list, to not clutter the table with values used in WZDx
7. Add new lane types center-left-turn-lane, reversible-lane, and hov-lane to cover missing functionality.

Note the spec still doesn't require including any lane information or a lane entry for every lane. The key breaking change is that it disallows having an entry in the "lanes" table represent more than one lane. This change doesn't increase the lane information required to produce the feed output, as if one was using right-two-lanes as the lane_type for an entry in the "lanes" table, they would just split that into to two entries.

2: Add order property to the lane to indicate position/index and leave flexibility in lane_number

This PR originally proposed requiring lane_number for all lanes, as that was intended to be used as an index to identify the position of the lane on the roadway. Currently (in v2.0) with lane_number as optional one must depend on the lane_type to determine the location of the lane. From subgroup meeting discussions it became clear that lane_number was being used differently by various parties. Thus this PR now proposes adding a new required field to the lane entity, order, which should be used to indicate the lane's position in sequence on the roadway. lane_number will remain optional and openly defined as it was in v2.0. The addition of order greatly simplifies parsing the lanes array on the feed as a consumer doesn't need to check the lane_type and implement logic to determine the location of a "lane" in this array.

The changes are specifically as follows:

1. Add new required order property to the lane entity. This must be an integer value and a value of 1 must be used to indicate the lane (used generally, can be shoulder, bike lane, sidewalk, etc) closest to the roadway edge indicated by the lane_edge_reference. An increase in 1 of the order value must represent moving one lane over away from the reference edge.
2. Rename lane_type to type, lane_status to status. This is to not cause confusion from the abstract use of the word "lane" (as a "lane" here can be a shoulder or a sidewalk), as well as to give distinction to lane_number, which is often used for a regular, driveable lane, and because the prefix is not needed anyways given the entity/object name of "lane".
3. Move the lane_edge_reference field from the lane to the road event (see Including lane_edge_reference on every lane in a road event is confusing #66)
4. Add new shoulder lane type, to be used when the shoulder isn't clearly left or right (e.g. between HOV lane and main roadway), or just in place of left-shoulder and right-shoulder, as whether it is right or left is able to be determined from the order value. A future version of WZDx will likely see the deprecation of all lane types that reference a side.
5. Add new generic lane lane type, used when a more specific value is unsuitable (or, like shoulder, in place of right-lane, left-lane etc as the location of the lane is able to be determined by the order)

Note: the lane_edge_reference change is the same as #97, and will override #97 if it is approved.

3: Standardize lane counting to begin from the left side of the roadway and remove lane_edge_reference.

The confusion of allowing the producer to choose the side of the roadway to count from is not worth the minor convenience of not having to translate their numbering when creating a WZDx feed. Having the edge reference consistent in all WZDx feeds limits parsing logic as well as making it easier to consistently talk about lanes.

The left side was chosen as this is what is used by:

• Open Street Map (OSM)
• AASHTO NTIMC document, "Traffic Incident Response - Lane Designation Terminology"
• @davidcraig4300
• Everyone who spoke up at subgroup meetings

The changes here are simple:

1. Remove the lane_edge_reference field from the lane entity
2. State in the business rules that lane_number and order counting must begin from the left side of the roadway.

Note: this resolves #98. Also, this will override the changes to lane_edge_reference mentioned in 2. above, as well as overriding #97.

[j-d-b]

Looking into the TMDD LaneRoadway enumeration, it appears that the TMDD values are not dash-delinated. See here. Thus we should update the TMDD references (not the WZDx values) to reflect these.

Also, the IDs given here don't match TMDD 3.1 (current version, I believe)

[j-d-b]

@sknick-iastate @davidcraig4300, how about the term reversible-lane (inspired by this page) instead of bidirectional for indication the zipper/suicide lanes or center turn lanes?

Per today's subgroup meeting, this will be updated to add two new types, reversible-lane, for the zipper/suicide lane scenario, and center-left-turn-lane for the center turn lane scenario.

Edit: completed in 1b78aaa

[j-d-b]

Per today's subgroup meeting, the conformance of the total_num_lanes field on the road event needs to be updated to be conditional—required if there are lanes associated with the road event.

Edit: completed in 16df4e1

[j-d-b]

PR description has been completely redone, though I have not yet made the changes described in the code.

[j-d-b]

Changes implemented for all three parts.

[chuehlien]

Looks great! Just need to make sure the updated table in spec-content/data-tables/lanes.md will show up correctly (GitHub seems to be interpreting the table border as bullet point). Also added minor comments/suggestions.

[sbma44]

Apologies for coming in late. It looks like 2 and 3 propose contrasting lane-counting schemes--one from the edge, one from the left. Is this correct, or am I misunderstanding? If so, could we standardize on a single counting system?

The consensus and prior art around counting from the left makes me think there's probably a good reason for it, but I will note that counting from the centerline allows for more consistency over time even if road geometry changes. One can imagine a basemap getting out of date as a new lane is added, then applying a WZDx alert against the now-stale data. Counting from the centerline would allow for the data about lanes present in both copies to remain correct (and potentially be a signal that an update is necessary).

[j-d-b]

Apologies for coming in late. It looks like 2 and 3 propose contrasting lane-counting schemes--one from the edge, one from the left. Is this correct, or am I misunderstanding?

This is correct. If all three levels of changes are approved as implemented here, the ability to provide the reference edge for counting as discussed in Part 2. will be removed (no lane_edge_reference field).