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. _______________________________________________ Tagging mailing list [email protected] http://lists.openstreetmap.org/listinfo/tagging
