Ok, ich hab das als Strassen-mittel-linie verstanden. Nehme alles zurück und behaupte das Gegenteil - da:
bin ich davon ausgegangen, dass Du allgemein und im Speziellen geri-ocs Aufgedrösel begrüssen würdest.
Mit change:lanes beschreibt die Konnektivität zwischen den Spuren eines einzelnen OSM-Weges. Das Problem liegt eher in der Konnektivität zwischen zwei oder mehr aufeinandertreffenden OSM-Wegen.
Beispiel: Einbahnstraße, 2 Spuren gehen in 3 über. Wie unterscheiden wir die 6 möglichen Fälle:
-
Neue Spur kommt links hinzu (nur über Spurwechsel erreichbar)
-
Neue Spur kommt in der Mitte hinzu (nur über Spurwechsel erreichbar)
-
Neu Spur kommt rechts hinzu (nur über Spurwechsel erreichbar)
-
linke Spur teilt sich auf zwei Spuren auf
-
rechte Spur teilt sich in zwei Spuren auf
-
Übergang ohne Spurmarkierung im Kreuzungsbereich (mittlere Spur ist von beiden Spuren des vorangegangenen OSM-Weges ohne Spurwechsel erreichbar)
Bezogen auf die Anzahl von Verbindungspunkten von OSM-Wegen sind es tatsächlich wenig Zweifelsfälle, in absoluten Zahlen jedoch extrem viele.
Das Proposal ist schon ein Ansatz, der in die richtige Richtung geht, um das Konnektivitäsproblem zu lösen. Allerdings halte ich dies weder für etabliert noch für ausgereift.
Ich halte dies Proposal für unnötig kompliziert und funktional für zu eingeschränkt (siehe dazu auch meine schon etwas älteren Kommentare im Wiki).
Da man für Key placement ohnehin eine Numerierung der Fahrspuren eingeführt hat, kann man diese auch gleich zur Angabe der Konnektivität nutzen.
Das sollte eine deutlich einfacher verständliche Beschreibung und eine erhöhte Funktionalität ergeben. Für die oben genannten Beispielfälle könnte das Tagging dann wie folgt aussehen.
-
transit:lanes=2|3
-
transit:lanes=1|3
-
transit:lanes=1|2
-
transit:lanes=1;2|3
-
transit:lanes=1|2;3
-
transit:lanes=1;2|2;3
Nochmal zum Mitmeißeln:
Wir haben eine dreistreifige Straße (also mit 3 Spuren, wie man das ja meist nennt, sprich insgesamt 4 Begrenzungslinien, keine baulichen Trennungen).
Es gibt jetzt zwei Möglichkeiten:
a) Es wird 1 Way “gemalt” und mit entsprechenden Tags versehen.
b) Es werden 3 Ways “gemalt” und separat mit Tags versehen.
Ich bin immernoch im a)-Team unterwegs, bin mir aber bei MKnight und slhh nicht mehr ganz sicher 
Könnte man in manchen Fällen, allerdings: für placement bezieht man sich immer auf die Spuren desselben Weges, das ist einfach überschaubar und auch automatisch kontrollierbar. Für transit bezieht man sich auf die Spuren eines anderen Weges. Und wenn sich die Straße aufteilt hat man zwei Zielwege jeder mit einer Spur Nummer 1. Die Wege kann man nicht durchnummerieren, sonst gibt es ein großes Chaos wenn doch mal jemand noch einen zusätzlichen Trampelpfad zwischen zwei Straßen einträgt.
Aber wir schweifen wohl etwas vom Thema ab.
Das funktioniert vermutlich für weit mehr als 90% der Straßenlänge gut, und zwar überall dort, wo die Fahrbahn- und Fahrspurbreiten entlang des des OSM-Weges konstant bleiben. Der Rest schaft die Geometrieprobleme. In der Realität ändert sich die Fahrbahn- oder Fahrspurbreite selten sprunghaft, sondern meist kontinuierlich. Die OSM-Wege in infinitesimal kurze Abschnitte zu zerlegen, würde zwar eine hinreichend genaue Geometriebeschreibung ermöglichen, ist aber sicher nicht als praktikable Lösung anzusehen.
Gewisse Verbesserungen der Geometriebeschreibung sind noch durch erweitertes Tagging möglich. So könnte z.B. mittels width:lanes:start und width:lanes:end die Spurbreite am Anfang und Ende des OSM Weges separat spezifiziert werden. Derartiges sollte man auch nutzen, zumal das für viele Anwendungen schon hinreichend sein mag.
In Bereichen wo man sehr hoch auflösende Karten erzeugen möchte, wird dies aber nicht alle Ansprüche an die Qualität der Straßengeometrie befriedigen können. Um diese befriedigen zu können, wäre es sinnvoll Ergänzungen zum bisherigen System zu entwickeln.
Prinzipiell sollte es bei a) bleiben. An Stellen wo dies die Geometrie nicht hinreichend beschreibt, sollte es jedoch zulässig sein, zusätzlich die 4 Begrenzungslinien mit zu malen, soweit Ihre Lage nicht vom Tagging des Hauptweges korrekt beschrieben wird. In der Realität wären wohl meist ein oder zwei zu malende Begrenzungslinien ausreichend.
Anwendungen, die die zusätzliche Geometrieinformation der Begrenzungslinien nicht benötigen, können diese einfach ausfiltern. Dann liegt für diese wieder rein a) vor.
Nur einmal diese** Kreuzung in Dresden**
Meines Erachtens:
Nach der Darstellung in OSM "umfahren sich die Linksabbieger - entspricht aber nicht der Realität und kann somit auch nicht “real” angezeigt werden. Auch Router können das nicht “berechnen”, da es in lanes und turn:lanes falsch erfasst ist.
Man sollte vielleicht einmal die Kreuzung (die bei Mapillary in Bildern für alle zugänglich ist - auf Luftbild umschalten) mappen (nicht hochladen - aber den Datensatz zur Diskussion stellen). Eventuell mit neuen/anderen tags und Text, warum so … Vielleicht kann die “Varianten” auch jemand visualisieren - (Meinetwegen auch eine andere Kreuzung).
Kannst Du da etwas konkreter werden?
http://map.project-osrm.org/ routet mir alle möglichen Sachen auf der Kreuzung so wie ich es erwarte. An den Lanes und turn:lanes sehe ich auch keine Fehler.
(Ich geb zu, dass das alles nicht exakt mit der Realität übereinstimmt, aber abstrahiert funktioniert es nahezu genauso)
Es geht um detaillierteres Mappen bzw. Erfassen (HERE HD maps mit einzelnen Fahrspuren) - abstrahiert funktioniert auch ein Kreuzungspunkt. Das war vor 10 Jahren - heute etwas detailreicher - in 10 Jahren …
Deswegen der “Vorschlag” - einmal unabhängig andere Ideen aufzuzeigen, die es eventuell zukünftig geben kann (area:highway; keinen gemeinsamen node, wenn ich den Weg dort nicht verlassen kann; highway=lane in Kreuzungsbereichen, die in größeren Zoomstufen detailieren können; getrennte ways für Fuß und Rad.)
Solche Kreuzungen (diese kenne ich zufällig selber) gibt es aber etliche, und sie sind unterschiedlich getaggt worden. Ich selbst halte mich in solchen Fällen eher an den Ansatz, dass man den Inhalt darstellt, sehe es aus, wie es wolle (“Man taggt nicht für den Renderer.”), was in diesem Falle heißt, dass die Übergänge eben wirklich separat getaggt werden. Mal gucken, ob ich ein Beispiel finde … stimmt, hier in Schwerin zum Beispiel oder hier in Köln.
In deinem Schwerin-Beispiel stellt sich mir die Frage, warum die beiden Fahrtrichtungen westlich der Kreuzung getrennt erfasst sind - dort gibt es keine bauliche Trennung.
Das Köln-Beispiel ist ein absolutes Negativbeispiel - die Kanelstraße hat nirgends eine bauliche Trennung und trotzdem sind da drei getrennte Highways erfasst, die über lange Strecken parallel verlaufen - auch da wo man Spuren noch wechseln darf. Das führt zu vielen falschen Anweisungen bei Navis, da keine heute verfügbare Navi-Hardware (spezielle professionelle differentielle GPS-Geräte ausgenommen) eine so hohe Genauigkeit hat um zu bestimmen, auf welcher Spur man gerade ist.
Wenn man direkt auf der Kreuzung solche Abbiegespuren getrennt von den Hauptfahrbahnen mappt, werden die wenigsten widersprechen. Wirkliche Probleme gibt es erst, wenn die Spuren über längere Strecken getrennt sind, z.B. in Bereichen wo die Spur noch gewechselt werden darf.
a) Linksabbieger von hier über hier und hier fahren lassen durch turn restrictions und oneway-Änderung.
oder b) Ein “Kreuz” in das Quadrat der Kreuzung eintragen, die lanes mappen und http://wiki.openstreetmap.org/wiki/Key:driving_side =left setzen. Bei anderen Kreuzungen wo sich die Spuren geteilt werden (nicht gleichzeitig fahren) mit :both_lanes arbeiten.
Hatte ich vorhin schonmal im Kopf. Also, das Gegenteil von der area:highway-Krücke; speziell in Deinem Beispiel - anstatt einer way-umwidmung wäre es vielleicht vernünftig (ich hab das noch nicht zu Ende gedacht) einen Node als Area (mit width und height etc.) umzuwidmen.
Also wenn ich mir das jetzt im Editor “denke”, dass ich dort einen Node habe, der nich 1px gross ist, sondern eben die Kreuzung einnimmt. Probleme bringt das auch etliche (nord-west-etc-Ausdehnung), aber man könnte auch sagen, dieser “Super”-node verbindet räumlich alle Zubringer.
Also zurück in die “Steinzeit” … - Es sollte m.E. auch Nicht-Spezialisten Spaß machen bei OSM mitzuarbeiten, und das ist das “erfassen der Wirklichkeit” - ohne sich Abstraktionen “auszudenken”. Abstrahieren kann der Daten-Auswerter, wenn er es möchte (Zusammenfassen, Vereinfachen, …)
Die Daten einer Spur lassen sich nicht immer (z.B. Kreuzung) an einem hw=* erfassen. Auf einen längeren Straßenabschnitt lanes=* zu verwenden, halte ich ja auch für richtig, aber nicht, wenn es nur über zig-Zusatztags (eventuell) möglich ist, obwohl es einfacher geht.
Warum gehen HERE und Automobilbauer den Weg der Spurdarstellung?
Gut - bei OSM vielleicht in 10 Jahren …
Mach Dir mal in JOSM den Fahrspuren-Stil aktiv. Da sieht man recht schön, dass sich unser Modell von dem Screenshot nur unwesentlich unterscheidet.
Nett den Stil kannte ich noch gar nicht. Ist aber im Gegensatz zu Here nur schematisch und nicht flächentreu.
Wenn Strassen- und/oder Spurbreiten angegeben sind, sieht das recht genau aus.
Edit: ich berichtige: auf jeder 2. Zoomstufe, irgendwas is da bugig.
Edit²: https://josm.openstreetmap.de/attachment/wiki/Styles/Lane_and_Road_Attributes/Screenshot_Style_Lane_and_Road_Attributes.jpeg man vergleiche das oberste Beispiel mit dem here-screenshot
Die Frage ist, welche Zoomstufe ist die richtige, ansonsten könnte man ja nach dem Satllitenbild die Spurweite zumindest ungefähr eintragen.
Einfach messen: Zeichne einen way quer zur Fahrbahn, JOSM zeigt dir die Länge an. Weg wieder löschen und Breite eintragen. In DE sind übliche Spurbreiten je nach Straßenart 3, 3.5 und 3.75 Meter. Innerorts auch mal 2.5. Da gab es irgendwo online ein paar Bilder mit typischen Straßenquerschnitten.
RAS-Q und alles, was danach folgte: https://de.wikipedia.org/wiki/Richtlinien_f%C3%BCr_die_Anlage_von_Stra%C3%9Fen_%E2%80%93_Querschnitt
Bei uns im Ort hat das Ordnungsamt übrigens kürzlich festgestellt, dass ALLE Radverkehrsanlagen ungültig sind, weil sie durchweg nicht die Mindestanforderungen erfüllen 