Und noch besser:
http://wiki.openstreetmap.org/wiki/Lanes_and_complex_intersections_visual_approach
Wann gab es dazu ein proposal?!
Fortführung von: http://forum.openstreetmap.org/viewtopic.php?pid=241981#p241981
Ja, wenn man auf diese Art Spuren mappt, dann finde ich diese Lösung auch besser, da weniger fehleranfällig und man hat
ein paar Duzent TRs gespart.
Edit: Wie ich heute festgestellt habe führt das dazu dass Garmin beim Linksabbiegen überhaupt keine Ansagen mehr macht, was klar ist, da ein Router Ansagen in der Regel nur bei kreuzenden (also verbundenen) Fahrbahnen macht.
Gibt es eigentlich schon (Test-)Karten oder Anwendungen, die solche Spurmappings wie area:highway, turn:lanes und/oder lane_restriction verwenden? Bzw. auch destination-Angaben/destination_sign-Relationen verwenden?
Ich würde *:lanes = * gerne darstellen, wenn dafür auch Spurtypen (Busspur, Parkspur, Radspur, etc.) definiert wären. So ist es zwar ein viel versprechender Ansatz, aber in meinen Augen noch unfertig. Leider scheint der Tatendrang des Proposal-Autors etwas nachgelassen zu haben.
Mal mein experimenteller Beitrag zum Thema Spur- und Verkehrzeichen-/Ampel-Mapping: http://wiki.openstreetmap.org/wiki/User:Fabi2/Generic_lane_model
Evtl. legt man den Spur-Access auch als Relationen ab, aber das macht es sicher einfacher, aber auch noch umständlicher im Moment, denn selbst in JOSM könnte die Unterstützung füt verschachtelte Relationen (z.B. bei Elemente anzeigen) besser sein. Das ist ein PoC und soll nur meine Ideen demonstrieren, war gerade nicht vor Ort um das noch mal 100%ig gegenzuchecken, aber di wichtigen/iteressanten Fälle kommen zumindest einmal vor. noch ein paar oneway=* mehr und dann kann man es auch so machen wie in meinem Vorschlag. 
Im Moment ist das aber nicht wirklich handhabbar, ich wollte aber einfach nur mal checken ob meine Idee überhaupt halbwegs funktioniert.
So, nach mehrmaligem Schieben und Grübeln wage ich es, meinen Ansatz zum lane-mapping hier vertiefend zur Diskussion zu stellen.
Meinen Denkansatz und die Vorgehensweise stelle ich in diesem Dokument vor:
Ein paar Erläuterungen zu meinem lanemapping-Ansatz für OSM
http://ubuntuone.com/4F2YwZNrw18nKASBZPR17U
Darin erkläre ich das warum, wie und womit.
Im Dokument befinden sich weitere links zu:
- einem Lösungsansatz, der als Proposal-Entwurf dienen kann
- einer grafischen Darstellung des Lösungsansatzes an einem einfachen Beispiel
- einer “Freiburglanetest.osm” mit einer etwas komplexeren Umsetzung des Schemas, die in JOSM geöffnet werden kann
- einer “lanestyles.xml” die dazu dient die lanes gut sichtbar orange darzustellen
- zwei Aerowest-Bilder, welche als Hintergrund die Realität zum besseren Verständnis zeigen
Wer Zeit und Lust hat, kann sich das mal ansehen. Kritik und Anregungen sind willkommen. Vielleicht wird ja ein Proposal daraus.
push:
Schade, hat wohl keiner Lust, zu diskutieren.
Und bis dahin geht der “Missbrauch von highway=*” für Spuren fröhlich weiter, sobald bing high res vorliegt 
Ein aktuelles Beispiel:
http://www.openstreetmap.org/?lat=48.353639&lon=7.806424&zoom=18&layers=M
edit:
auch schön:
http://www.openstreetmap.org/?lat=48.359814&lon=7.770861&zoom=18&layers=M
Ich sehe nur eine unstrukturierte Wall of Text ohne Bilder, die mich abschreckt, das zu lesen.
Hilft dir das?
grafischer Ansatz:
http://ubuntuone.com/6HPgoCItJy0WtwKrKpU3H2
Erläuterungen als proposal-Vorstufe:
http://ubuntuone.com/2gFbILhpniHAboIgdE9iea
Auf diese Dokumente und ein “Testgebiet” wird aus der “wall of text” verlinkt.
Ich wollte dir nur eine mögliche Ursache schildern, wieso niemand darauf eingeht.
Super Beispiel für “Malen nach Zahlen”
http://www.openstreetmap.org/?lat=48.37175&lon=7.8203&zoom=17
Keine Straßennamen, kein Gebäudebezeichnungen, keine access-Tags,
aber hübsch sieht es aus. 
Der Tip ist angekommen. Danke.
Ich bau das dann wohl besser neu auf.
+1
Da gehe ich aber erst ran, wenn’s weg ist, weil sich da als Konversionsfläche sowieso dauernd was ändert. Die alten shelter stehen halt noch und werden auch teilweise als Lager genutzt.
Ist aber leicht OT, obwohl man auch hier sieht, wie wichtig vernünftige Lösungen für Spuren und Straßenflächen sind.
edit:
Ich gestehe: einiges dort habe ich vor knapp zwei Jahren selbst hingeklatscht. :ascheaufmeinhaupt:
Zurück zum Thema:
ich habe meinen Vorschlag mal neu sortiert, damit auch Neueinsteiger in’s Thema mitkommen. Der Grund, warum ich mich an die Sache heranwagte, war der “Missbrauch” des highway-tags für die Abbildung von Spuren mit Auswüchsen wie diesen:
http://www.openstreetmap.org/?lat=51.324055&lon=12.291283&zoom=18
oder diesen, den ich für meinen Test verwendete:
http://www.openstreetmap.org/?lat=47.9901266098022&lon=7.84436970949173&zoom=18
Diese Änsätze:
Lösungsansatz grafisch: http://ubuntuone.com/6HPgoCItJy0WtwKrKpU3H2
Lösungsansatz Text: : http://ubuntuone.com/2gFbILhpniHAboIgdE9iea
wurden hier in etwas anderer Form schon mal vorgestellt und diskutiert.
Die Frage war, ob das auch an komplexen Stellen geht, weshalb ich in der hier erläuterten Form:
Testgebiet: http://ubuntuone.com/3qbMn7RH5GJWvndWS76YDg
das ganze mal mit JOSM durchgespielt habe. Dort findet ihr auch die links zu einer osm- und einer xml-Datei sowie zu zwei aerowest-Bildern, womit ihr den Ansatz auf seine Alltagstauglichkeit abklopfen könnt.
Wer also Lust hat, sich da mal rein zu hängen: viel Spaß und Feuer frei.
Mir gefällt der Vorschlag ganz gut, selbst das etwas komplexere Testgebiet sieht durchaus übersichtlich aus.
An einer Stelle verstehe ich’s aber gerade nicht: Die Mattenstraße läuft in zwei lane=residential aus, sollte die nicht der Kompatibilität wegen weiterhin selbst mit der Kronenstraße verbunden sein, zusätzlich zu den lanes?
Außerdem haben deine Kreuzungsflächen nicht immer gemeinsame Nodes mit den einmündenden Highways, wie beschrieben.
Ich hatte den Vorschlag schon mal angeschaut, aber aus meiner Sicht lassen sich deine lane-Ways eben genauso schlecht auswerten wie alle anderen Ansätze, bei denen Ways einfach unverbunden nebeneinander liegen und die Zusammengehörigkeit nur mit einem ordentlichen Schuss menschlicher Intuition erkennbar ist. Von daher ist auch meine Kritik dieselbe: Fehlende maschinenlesbare Struktur der Daten.
Den Ansatz bei den Kreuzungen für sich genommen (mit Fläche und Ways für die Abbiegemöglichkeiten) fände ich im Gegensatz zu der Darstellung entlang der Ways ganz ok.
Danke für dein Adlerauge. ich werde das mit der Mattenstraße nachbessern. Und das mit den gemeinsamen nodes der Kreuzungsflächen mit den highways muss ich vor lauter lanes usw. wohl auch mal übersehen haben, wobei ich mich aber mittlerweile auch frage, ob das wirklich zwingend sein muss oder ob nicht gemeinsame nodes mit den lane=* reichen 
Für das routing wäre es nicht erforderlich.
Ich habe es grob durchgesehen, aber irgendwie keine richtige Meinung dazu, weder ist es für mich ganz schlecht, noch gut genug.
Wenn dein Schema nicht damit klar kommt, das wahlweise Wege/Spuren nicht nur als Linien sondern auch als
Flächen erfasst wurden, dann solltest du es nachbessern, denn die Tendenz geht in der Zukunft ja eher mehr zu Hires-Luftbildern und damit sollte es dann auch noch funktionieren. Ob es dann noch für den Normalmapper handhabbar ist, ist dann wieder nen andere Diskussion.
Soweit ich es gesehen habe, ging das mit erhöhtem Rechenaufwand mit dem Schemas durchaus, auch wenn da höhere höhere Abstraktionsstufen für Fahrbahnen und die Straße fehlen. Passend getaggte nebeneinanderligende Linien geben als Abstraktion schon die Realität ganz gut wieder, wenn man es genauer haben möchte kann muß man dann eben Flächen taggen. Linien sind eben auch immer noch nur ein (detailreduziertes) Modell der Realität. Komisch fand ich auch den Ansatz mit den einheitlichen Kreuzungsflächen zusammen mit den Linien, die man ja zum Verbinden aller möglichen Fahrwege sowieso noch braucht. Dann stelle ich die Kreuzungen wie bei mir geplant, lieber als “magische Quadrate” aus Teilflächen dar. Ja, eraffsungsfreundlich ist was anderers, aber irgendwo muß man immer Kompromisse machen…
Ich wollte mit dem Ansatz eine Alternative zum Missbrauch des highway-tags für Spuren schaffen und primär die Auswertung der Spuren für’s routing ermöglichen. Zusammengehörigkeit wäre durch eine Relation “highway” in der die Spuren zusammengefasst werden, machbar. Da könnten dann auch alle gemeinsamen Eigenschaften der Straße wie name, ref, maxspeed usw. abgebildet werden.
Ich dachte schon mal daran, das die Straßenfläche insgesamt als Fläche erfasst und in die Relation “highway” eingebunden werden kann. Ich denke, dass routing über Flächen mittelfristig nicht vernünftig umsetzbar ist und einen hohen Aufwand des preprocessing erfordert. Routing über Kanten und Knoten ist etabliert und kann über “lane” als way problemlos erfolgen. Für eine detaillierte Karte kann man sich dann je nach Bedarf nur die Straßenfläche aus dem area oder zusätzlich die Spurinformationen mit Richtungspfeilen usw. aus den lanes holen.
edit: Wäre mit waterway vergleichbar. Da erfassen wir ja auch den Verlauf als way und die Fläche als area separat.
Ja, und ich hatte den Normalmapper im Auge, dessen Abstraktionsvermögen auch bei Nachbesserungen/Änderungen nicht überfordert werden soll.
Wurde nachgebessert.