number of lanes over-stated for two-way OSM links

[yuqiww]

Background:
OSM data has link attributes "lanes", 'lanes:backward', 'lanes:forward', 'lanes:both_ways'. OSM represents two-way street in one row of data, with "oneWay=False". For oneWay==False, and if lanes data exists, "lanes = lanes:backward + lanes:forward", with "lanes" for the number of lanes of both directions. For oneWay==True, only "lanes" has data, "lanes:backward" and "lanes:forward" are na.
In our Standard Networks, each row of the link table represents a one-way link, so a two-way street is always represented by two links, with same shstGeometryID, but different shstReferenceID, different link_id.

Current Pipeline methodology:
So, in "step3_join_shst_extraction_with_osm", the method "add_two_way_osm" creates the reversed links for all two-way OSM segments and add them to the raw link table. Say, if the network has 1 two-way roads and 2 one-way roads, the initial OSM link data would have 3 rows, and the updated link table would have 1*2+2 = 4 rows. However, in doing so, the method also assigns the "lanes" of both directions to each direction's link, therefore over-representing the number of lanes.

The attached screenshot provides an example:

• table 1 is the OSM data before creating reversed links - the two two-way links have 5 lanes in both directions, and 2 lanes/3 lanes in each direction.
• table 2 is after adding reversed links - it becomes 4 links, each only representing one direction. (I think the right method is to assign 2 and 3 to "lanes" respectively.)
• table 3 is these links in V12 Standard Networks, they are shown as having 5 lanes, which appears to be wrong.
  

Below is Google street view showing wayid/osmid392680114, South Norfolk Street, near the Fashion Island Blvd, in San Mateo. Here's the 2015 Google Street View. South bound has 3 lanes (2 through, one left-turn), North bound has 2 lanes (both are through).

In the model network (v12.03), it's A=1500000 and B=1532497 (and vice versa). The model network thinks it's 5 lanes in each direction. This is based on Heuristic 11, because the link is not in San Francisco and it's only an Undivided Arterial (FT=5) so no PeMS count. The heuristic used OSM as the data source.

Maybe this is why there are so many cases where the number of lanes in the networks is larger than what we think there should be in 2015, hence the many Project Cards that try to correct 2015 lane_num.

@DavidOry @i-am-sijia: we are planning to fix this for our own network, but thought it might be good to keep you in the loop.

Asana task.