[Tagging] Lanes tag, way forward

[Kytömaa Lauri]

The discussion seems to have died for now, but the wiki doesn't
still give any readers concrete advice on what is the best 
practice. Before I edit it once again, I'll try to summmarize 
the points laid out so far, and (the first) one that didn't get 
mentioned, at least this straight:

* All "editing basics" material has suggested that whenever for 
  example the maxspeed or lane count changes, you split the way
  Ways per se don't describe roads, they describe the properties
  of a section of road.(1)
* Lot's of use cases benefit from the total numbers, described
  as accurately as possible.(2)
* Lanes has been thought to refer to the physical properties of
  a way 
* The number of "through lanes" could be inferred from the total 
  lane counts tagged exhaustively, but not the other way round,
  at least unless users add turninglanes relations to all 
  junctions.(3)
* For a majority of intersections turnlanes relations are not 
  needed (it's unambigous which lanes allow which turns/go 
  where), when the total lane count is tagged exhaustively on 
  all ways approaching and departing from the junction.
* Exluding some lanes intentionally is bound to lead to cases
  where users would argue for different, subjective values, esp.
  when a lane is continuous from a merging onramp to an offramp
  further along the road

* Some find splitting ways possibly multiple times for each 
  block "too much".
* Some find that a two lanes carriageway does not become a three
  lane carriageway when a turning lane starts; compare with the
  first bullet.

And the descriptive vs. prescritive. Even if everybody is free
to tag as they please, some tags have established uses, or they
were defined before they had nearly any uses (like the lanes key
in 2006), and users should be advised not to diminish their 
meaningfulness by intentionally using them to denote something
else. Combined with the "we suck at documentation" issue, in
this case fresh users have not been given an undeniably clear
how-to's in the first place. The instructions were clear, save 
for the word "travel" in "travel lanes".

(1) Other established attributes that change midblock include 
at least maxspeed=*, lit=*, overtaking=*, paved:date=* and 
the parking:lane:*=* "tag family".

(2) So far mentioned was turn-by-turn navigation, rendering, 
traffic simulation (at least for inferring capacity/throughput 
and space for queueing vehicles)

(3) Few days back there were, globally, 721 turnlanes relations 
last edited by only 31 users. Of them only 137 (24 editors) had 
the lanes:extra tag, to denote turning lanes not included in the
lanes tag of the way. Josm search showed that those relations had 
139 ways in the role "from", and of those only 122 have the lanes
tag present. These are the only ones where we _know_ now that the
lanes tag does not include all lanes. I looked at a good number 
of them, but most of the junctions were rejected by the plugin as
the relations had doubled (split) from or to members, or missing 
via-members. On the other hand, one would need to code something 
to analyze how many junctions have the incoming ways split to 
increase the lane count for the length of the turning lanes. And
compare that to the cases where the lanes key has a irrefutably 
wrong value - I found several places with, for example, a four 
lane twoway road tagged as lanes=2.

The turnlanes plugin seems to work splendidly, even when the 
total lane counts are tagged on short sections, and not via 
their, I would say nonestablished lanes:extra tag (used on the 
relation).

Is there any reason, not given above, why a short way tagged with
the total physical lane count should be consider worse data than 
the same way tagged with the turn lanes excluded from that figure?
It's IMO the final state we should aim for - thinking many years 
into the future - and present tagging guidelines should not make 
it harder for us to get there eventually.