num_lanes comprises of GP, HOV, ML, etc

[lmz]

See asana task

num_lanes should be a physical measure, and therefore not one that changes by time period.

However, let's have some per-time period tallies of lane types:

• GP = general purpose
• HOV = high occupancy vehicle
• ML = managed, e.g. priced
• park = parking (e.g. used for parking, not travel, in this time period)
• bus = bus-only
• taxi = taxi-only? Do we need this?
• aux = auxiliary, could be on freeway typically between two interchanges to facilititate merging, but could also be merge lane segment on arterial; has less capacity than a full GP lane
• lturn = left turn lanes
• rturn = right turn lanes

While the static assignment model doesn't care about left and right turn lanes, they could be useful to understand in the future if we develop a DTA model. Also, it looks like left and right turn lanes are included in the OSM network (see https://wiki.openstreetmap.org/wiki/Key:lanes and https://wiki.openstreetmap.org/wiki/Key:turn so adding this information should be straightforward and possibly make the OSM data make more sense...)

Where

lanes = sum of lane_[type]_AM 
      = sum of lane_[type]_MD 
      = sum of lane_[type]_PM 
      = sum of lane_[type]_EV 
      = sum of lane_[type]_EA

[FlaviaTsang]

Comment from RMWG: this needs to be flexible enough to address edge cases e.g. Richmond-San Rafael Bridge east bound has a shoulder lane that becomes available part of the day; and reversible lanes on Golden Gate Bridge.

[lmz]

Another tricky issue: how to handle left turn lanes that are used for both directions (e.g. center lane on Valencia street); it seems like maybe lane_lturn = 0.5 in that instance so they sum when you look at both directions...