Including lane_edge_reference on every lane in a road event is confusing

[j-d-b]

Including lane_edge_reference on every lane in a road event is confusing

Background

The lane_edge_reference property defines the start side (either left or right) for identifying the lanes within a road event by lane_number index. For example, if the lane_edge_reference is left, the lane_number 0 refers to the leftmost lane.

Issue

Including the lane_edge_reference is a simple and effective technique for clarifying the often confusing indexing of lanes. lane_edge_reference only needs to be defined once for each road event, rather than for every lane in the road event as is currently done. Defining it for every lane:

• Is confusing, as you could use right for some and left for others within the same road event
• Requires more code to parse the feed, as you must check the field for every lane
• Adds unneeded fields and leads to larger files

Currently (possible scenario)

{
  "road_event": {
    "total_num_lanes": 2,
    "lanes": [
      { 
        "lane_edge_reference": "left",
        "lane_number": 0
      },
      {
        "lane_edge_reference": "right",
        "lane_number": 0
     }
    ]
  }
}

Note the above is pseudocode

Solution

Moving the lane_edge_reference as a conditional field (required if using "lanes") in the road_events table would be a simple solution.

Example

{
  "road_event": {
    "total_num_lanes": 2,
    "lane_edge_reference": "left",
    "lanes": [
      { 
        "lane_number": 0
      },
      {
        "lane_number": 1
     }
    ]
  }
}

Note the above is pseudocode

[j-d-b]

Along with standardizing the starting lane number in #67, instead of moving lane_edge_reference to the road event entity, we could standardize this value and remove the field (i.e. require left or right as part of the spec).

This would solve the original issue and simplify the spec, as it removes an enumerated type as well as a field. Unless the option to specify the direction of count greatly lowers the effort for feed producers (please chime in), I think standardizing the counting edge reference and removing the field is the better approach to resolve this issue.

[CraigMoore-Sea]

This makes sense. Keeping this as an option lowers the barrier to entry since both left and right standards are in use.
After we adopt a more complete standard for defining lanes we can reconsider this, likely not something that will happen in v3.

[j-d-b]

@CraigMoore-Sea by "this makes sense", are you referring to moving the lane_edge_reference to the road event?

[CraigMoore-Sea]

Yes, moving the lane_edge_reference to the road event.

[Mahsa-Ettefagh]

Comments received during the V3 Specification Update Subgroup meeting on 4/29/2020:

• Lynne Randolph: if we standardize the lane numbering, we shouldn't really need this field (Including lane_edge_reference on every lane in a road event is confusing #66 issue)
• Sabrina Mosher: We would need it but just once. The default is from the right but we number from the left
• Lynne Randolph: that's fine too, but direction of the event is already there. We standardize the lanes from the inside out or outside in or whichever is decided
• Carole Delion (MDOT SHA): from right tends to be the practice, I believe some of it also aligns with HPMS submissions (from traffic counts)
• Jim Williams (INRIX): The conformist in me likes option 2 but option 1 give more flexibility to end users.
• Chris Brookes MDOT: yes pick one and keep it that way.
• Lynne Randolph: I'd rather everyone's feeds are consistent
• Neil Boudreau, MassDOT: Doesn't the TIMS side of the house establish a standard lane naming convention
• Lynne Randolph: we translate things all the time depending on the end use
• Neil Boudreau, MassDOT: I am pretty sure that they do. I can ask Paul Jodoin
• Jim Williams (INRIX): No issues with standardizing.
• Carole Delion (MDOT SHA): no issues with standardizing
• David Craig @ GM: I prefer standardization.
• Jianming Ma (TxDOT): i would support standardizing lane numbering convention.
• Lynne Randolph: no issues, I was trying to see if the C2C/NTCIP spec had it in there
• Jianming Ma (TxDOT): Please note that in the lane shifting situations, shoulders could be used as one of travel lanes.
• Craig Moore: The spec currently states lanes are counted from the first improved surface, which would be the shoulder in most cases.
• Dan Sprengeler IOWA DOT: It is conceivable that an existing traffic lane needs to be shifted beyond the existing shoulder line on to temporary pavement. What are the lane assignments now?
• Craig Moore: First improved surface would be lane 1, in this case it would be the temporary pavement.
• David Craig @ GM: Does it fix this ambiguity if we start numbering from the left?

[j-d-b]

Resolved in #94