Mein Lösungsansatz zum lane-tagging ist fertig und hier abgelegt:
http://wiki.openstreetmap.org/wiki/File:Lane-Tagging-L%C3%B6sungsansatz.pdf
Gedanken,Vorschläge und Wünsche dazu nehme ich gern entgegen.
Also: Feuer frei (aber bitte nichts verbrennen)
Das ist übrigens eine super Beispiel-Kreuzung.
Nehmen wir einen Autofahrer, der von “unten-links” geradeaus nach “oben-rechts” will und sich auf der rechten
Spur befindet. Wenn ich’s richtig sehe, dürfen Busse auf der Spur gerade fahren, während Autos
rechts abbiegen müssen. Der Autofahrer muss also eine Spur nach links. Im Routinggraph geht dass nur wenn
er im Bereich der Kreuzungsfläche einmal 90 Grad links und dann 90 Grad rechts abbiegt. 
Das habe ich mir auch schon gedacht. Ich würde die gerne mal als Beispiel für lane-tagging verwenden, wenn die Grundsätze dafür klar sind.
Es wäre aber sehr aufwändig, diese grafisch nachzubilden 
Wo ist diese Stelle und kann ich bing einfach als Hintergrund für eine Foliensammlung zum Thema verwenden, wenn ich die Quelle angebe?
Unten steht, footway und cycleway bleiben unberücksichtigt, oben gibt es aber einen Ausnahme von oneway=yes für lane=footway. Passt finde ich nicht ganz zusammen. Außerdem frage ich mich, ob es mehr straßenbegleitende Fahrradwege (solche würde man ja dann wohl mit lane=cycleway darstellen) gibt, die oneway=yes sind oder oneway no. Da sollte man einen vernünftigen Standard wählen.
Die Beschränkung auf Kreuzungssituationen ist zwar nett gedacht, aber IMO unrealistisch. Wenn es ein vernünftiges Schema gibt, wird es auch an gerader Strecke eingesetzt werden. Aber ich sehe da auch kein Problem, da ja die bisherige highway Struktur erhalten bleibt, ist es doch auch nicht schädlich, wenn die lane Informationen auch an gerader Strecke vorliegen.
Ansonsten erstmal Zustimmung, gefällt mir.
Beim footway habe ich schon weiter gedacht. Taggen sol ja schon möglich sein. ich werde das konkreter fassen, indem ich den Fokus im ersten Schritt auf “spurabhängiges routing für motorisierten Verkehr” ändere.
cycleway werde ich im Auge behalten und deine Bemerkungen berücksichtigen.
Das Schema wird imo primär an komplexen Kreuzungen benötigt. Natürlich können Mikromapper das dann auch woanders verwenden. Dazu muss es nur entsprechend angelegt werden.
Deine Zustimmung ermutigt mich zum Weitermachen. Danke.
Ich habe mittlerweile hier eine Version 0.2 hochgeladen.
http://wiki.openstreetmap.org/wiki/File:Lane-Tagging-L%C3%B6sungsansatz.pdf
direkt ins Dokument:
http://wiki.openstreetmap.org/w/images/e/eb/Lane-Tagging-L%C3%B6sungsansatz.pdf
Einige Textverbesserungen und genauere Formulierungen wurden eingefügt und das Dokument bekommt jetzt eine Versionsnummer mit Datum, damit alle, die lieber Ausdrucke lesen, die Aktualität ihres Papiers vergleichen können.
Hilfääh!!
Irgendwie hat das Aktualisieren in einigen Versuchen nicht nach meinen Wünschen geklappt, weshalb einiges an Müll unter dem Link liegt. Wie kriege ich alte Uploads gelöscht ? 
Eigentlich will ich auch im interesse des Speicherplatzes dort nur die aktuellste Variante vorhalten.
Gar nicht. In einem Wiki kann man keine Versionen löschen, das ist Teil des Konzepts.
Man kann die ganze Datei mit allen Versionen von einem Admin “löschen” lassen und dann mit einer neuen Versionsgeschichte neu anfangen. Speicherplatz spart man aber auch so nicht - die Versionen bleiben für Admins trotzdem einsehbar.
Wenn du Dateien sowieso nur selber bearbeiten willst und Wert darauf legst, selbst entscheiden zu können, was gespeichert bleibt, dann ist eigener Webspace, ein öffentlicher Dropbox-Ordner o.ä. wohl die bessere Wahl.
Zum Thema selbst. Dein Lösungsansatz leidet unter demselben Dilemma wie alle Spuren-Als-Ways-Ansätze:
Wenn man die Ways einfach nur ohne Relationen nebeneinander liegen hat, sind die Daten für die maschinelle Auswertung schwer zu nutzen. Wenn man hinggen fordert, dass die Spur-Ways mit Relationen zusammengefasst werden, ist das Bearbeiten nicht mehr so einfach.
Ich befürchte, die Attraktivität dieses Ansatzes beruht zu einem großen Teil darauf, dass die Bedeutung von nebeneinander verlaufenden lane-Ways für den menschlichen Betrachter intuitiv verständlich ist, was über die mangelnde Auswertbarkeit hinwegtäuscht.
Wie gesagt da erstellt man dann eine abstrakte Straßenrelation über die Einzelspuren und das Problem ist auch nicht mehr größer, als das Problem der nicht per gemeinsamen Knotenpunkt verbundenen Wege jetzt schon. Wichtig aus dem Vorschlag ist eigentlich nur die Information, das die Art des Gesamtweges mit an die Einzelspuren muß, was dann auf Kosten von mehr Redundanz und evtl. Widersprüchen eine Relation für den highway=* einspart, so dam man nur noch die für die Gesamtstraße (highway + sidewalks, etc.) braucht.
Somit sind wir wieder beim Grundproblem angelangt
Die bisherigen Ansätze scheiterten auch in dieser Diskussionrunde genau an diesen Problemen. Das kann auch meinem Ansatz passieren, der eher auf die optischen Fähigkeiten des Mappers aufbaut.
Wir können nicht das eine wollen ohne auf das andere zu verzichten. Ich sehe da wenigstens keinen Weg.
Wir brauchen den engagierten Laien zum Erfassen mit einfachen Mitteln. Aber wir brauchen auch eine Datenbank zur professionellen Auswertung. Beides gleichzeitig wird mit dem OSM-Datenmodell immer schwieriger, wenn nicht sogar unmöglich 
Ich will noch gar nicht daran denken, was mit meinem Ansatz passiert, wenn Brücken ins Spiel kommen. Bei railway und separated cycleway ist da die renderer-Fraktion schon höchst unzufrieden. Wie wollen wir die Realität darstellen, wenn wir in diesen Fällen viele Brücken statt einer real existierenden zeigen ?
Aber jetzt hier bitte keine OT-Brückendiskussion einbauen.
Da habe ich noch den Ansatz eines abgerüsteten Schemas für Anfänger anzubieten, das ist zwar dann nicht semantisch korrekt, aber da kommt dann hoffentlich ein erfahrenerer Mapper vorbei und setzt die passende Relation auf die Einzelobjekte. Gut, eine wirkliche Lösung ist das auch nicht, eher eine Übergangslösung, außerdem entstehen da evtl. widersprüchliche Redundanzen bzw. muß extra Aufwand zur Löschung an den Einzelobjekten betrieben werden.
Das funktioniert dann so, das der Anfänger-Mapper z.B. eine Brücke mit bridge=yes + layer=1 an jedem Weg mappt und dann mal jemand hoffentlich die betroffenen einzelnen Brückenteilwege in eine gemeinsame Relation, für die Darstellung, das das nur eine Brücke ist, packt.
Da die letzten Abschweifungen in Richtung Spuren-Als-Einzelne-Wege-Erfassen nichts neues zum Thema Routing erbracht haben, moechte ich noch mal die Variante Spuren-Als-Tags-Des-Weges-Erfassen hervorbringen.
Ein Punkt ist dabei, wie man die Verbindung der Spuren ueber eine Kreuzung hinweg am besten erfassen kann. Die meisten der letzten Vorschlaege (auch meiner) sehen vor, dass das ueber Tags geschehen soll aehnlich wie die Spurerfassung selber. Inzwischen bin ich der Meinung, dass dafuer doch Relationen das geeigentere Mittel sind:
Die meisten der letzten Vorschlaege sehen fuer die Erfassung eine Listennotation vor, bei der die Spuren mittels eines definierten Trennzeichens aufgezahelt werden. Daneben gab es haeufig auch eine Notation, mit der man auch einzelen Werte nur fuer eine bestimmte Spur setzen konnte. Aufgrund meiner Erfahrung mit den Beispielen auf der Uebersichtseite denke ich nun, dass man dazwischen auch noch teilweise gefuellte Listen zulassen sollte. D.h., wenn man fuer eine Spur keinen entsprechenden Wert setzen will, dann folgt da einfach Trennzeichen auf Trennzeichen. (Dieser Vorschlag ist auch schon von anderen gekommen, nur habe ich das bislang noch nie irgendwo ausformuliert/angewendet gesehen).
Die meisten der letzten Vorschlaege sehen fuer die Listennotation ein einfaches Aufzaehlen der Spuren von links nach rechts vor. Im Moment denke ich, dass es besser waere, wenn man die (logische) Strassenmitte dabei besonders hervorhebt. Bei den allermeisten Strassen trennt diese logische Mitte die Fahrtrichtungen oder wird von einer Spur gebildet die die Fahrt in beide Richtungen erlaubt (z.B. auf einspurigen Strassen). Wenn man diese Mitte besonders betont, erleichtert sich erstens die Erfassung der Fahrtrichtung der einzelnen Spuren (fast alle Faelle sind per Default erledigt). Zum anderen duerfte das die Auswertung erleichtern, wenn man z.B. wissen will, ob eine Strasse einen rechtsseitigen Radweg hat. realisieren liesse sich so eine Betonung, indem man in der Listennotation ein weiteres Trennzeichen einfuehrt und bei der einzelnen Identifikation der Spuren mit Vorzeichen arbeitet: Spuren mit negativem Vorzeichen sind links der Mitte, Spuren mit positiven Vorzeichen sind rechts der Mitte.
Gruss
Torsten
Gut, ich halte diesen Ansatz derzeit mindestens kurz- bis mittelfristig für aussichtsreicher. Dass unter den tag-basierten Ansätzen die Listenvarianten am meisten versprechen, zeichnet sich allmählich auch ab.
Das ist eine naheliegende und sinnvolle Ergänzung.
Ja, es könnte wirklich vorteilhaft sein, die Straßenmitte gesondert zu betonen. Die Defaults für die Fahrtrichtungen und die bessere Auswertbarkeit für Datennutzer, die z.B. nur an Radwegen interessiert sind, sind sehr gute Argumente.
Ich möchte allerdings auf einen alternativen Vorschlag für die praktische Umsetzung hinweisen. In Mailinglisten-Diskussionen wurde vorgeschlagen, man könnte für die beiden Straßen"hälften" zwei getrennte Listen anlegen (also so etwas wie lanes:direction:right = … , … , …). Dadurch hätte man weiterhin nur eine Art von Trennzeichen und der Bedarf für “Vorzeichen” von Spuren würde ebenfalls wegfallen. Allerdings hat man dann doppelt so viele, wenn auch kürzere, Tags.
Das mit denn Zusatztags wird bestimmt interessant, bei teilweise markierten Radspuren zum Beispiel, wie dem separated=yes-Radweg, der dann als Radspur auf die Straße mündet und an der nächsten Einengung der Straße ganz aufhört… 
Da hatte ich auch dran gedacht, auf die Art ist das auch machbar. Im Moment scheint mir das aber die schlechterer Loesung zu sein, da es ja doch genug Faelle gibt, wo die Aufteilung in Rechts und Links alleine nicht ausreichend ist (z.B. alle Strassen mit nur einer Fahrspur). Das koennte man dann allerdings ueber eine dritte Kategorie (wie in etwa lanes:direction:middle=…) erfassen, was aber zu einer noch groessere Zergliederung führt. Ich denke, da wäre eine einzelne Liste uebersichtlicher. Wobei uebersichtlich da allgemein sehr relativ ist, a schoensten ist natuerlich eine graphische Eingabehilfe, so dass der Mapper von den daunter liegenden Datenstrukturen gar nichts mitbekommt.
Das Thema, wie detailliert man mappen will, hat man immer, unabhaengig vom gewaehlten Tagging-Schema. Oben genanntes Beispiel wird bei kleinlichem Tagging zu einer extremen Zerstueckelung der Strasse fuehren. Aber was waere die Alternative? Wenn man das als einzelne Wege erfassen wuerde, dann muesste man das doch genauso zerstueckeln und dann die Einzelteile jedes Abschnittes jeweils in einer Relation wieder zusammen fassen.
Gruss
Torsten
Da Bilder mehr als 1000 Worte sagen habe ich zu meinem Lösungsansatz aus post http://forum.openstreetmap.org/viewtopic.php?pid=221552#p221552, den ich hier http://wiki.openstreetmap.org/w/images/e/eb/Lane-Tagging-L%C3%B6sungsansatz.pdf als Text beschrieben habe noch eine grafische Darstellung gebastelt:
http://wiki.openstreetmap.org/w/images/c/c0/Lane-Tagging-L%C3%B6sungsansatz-grafisch.pdf
Vielleicht wird zu meinem Ansatz so einiges klarer im Bezug auf die Verwendung/Auswertung zum routen. Ich halte nichts vom Aufzählungen/Listen in values wegen der Intransparenz und Nachbearbeitung. Nach wie vor ist mir nicht klar, wie das ein router verarbeiten soll.
Da der Mensch ein optisch orientiertes Wesen ist, halte ich das mappen einzelner Spuren für die bessere Lösung. Ich habe vesucht, ein Schema zu entwickeln, dass ähnlich arbeitet wie Relationen, aber noch ohne diese auskommt. Das Problem dabei sind die Linienbündel, für die man dann aber den (ungeliebten) Weg über Relationen verwenden könnte
Ich bitte um Meinungen zur Verwendbarkeit als Mapper und zum routing. Auch Änderungsvorschläge sind willkommen. Sollte sich herausstellen, dass das schon im Ansatz alles nur Mist ist, werde ich mich wohl von der Idee verabschieden.
wozu sind die lane_restrictions auf Seite 5 in der graphischen Darstellung, wenn Du auf Seite 6 das gleiche mit dem Spinnennetz im Kreuzungsbereich darstellst?
Ich weiß, dass ist doppelt gemoppelt. Aber einerseits dient es dem Renderer, um für das entsprechende lane die Richtungspfeile oder das entsprechende Verkehrschild einzublenden, andererseits denke ich, dass es für vorausschauendes routing Sinn macht. Weiterhin könnte eine automatisierte Qualitätskontrolle checken, ob die vom entsprechenden lane ausgehenden lane=junction vollständig und richtig sind. Ich befürchte nämlich, dass von den lane=junction je nach Komplexität schnell mal eins vergessen wird, weil die ja in der Realität nicht sichtbar sind und nur benötigt werden, weil routing über Flächen nicht möglich ist.
Ich hatte auch mal kurz daran gedacht, die lane=junction wegzulassen und dann dem router die Aufgabe zu überlassen, automatisiert die Möglichkeiten der Verbindungen über die lane_junction-Fläche zu generieren, was mapping natürlich vereinfachen würde. Aber dann habe ich mich entschlossen, dem router die Arbeit zu erleichtern.
ich sag mal so. Das ganze sieht ziemlich unübersichtlich aus, was aber wohl nicht zu vermeiden ist. Daher würde ich es gut finden, wenn alle nur für diesen Zweck benötigten Objekte einen identischen Tag haben. Damit kann man das auf Knopfdruck ausblenden wenns einen stört.
Als Extrembeispiel könntest Du ja das hier nehmen
https://maps.google.de/maps?q=Gro%C3%9Fer+Stern,+Berlin&hl=de&ie=UTF8&ll=52.514784,13.351597&spn=0.003317,0.009645&sll=51.151786,10.415039&sspn=14.021423,39.506836&oq=berlin+gro%C3%9Fer+stern&hnear=Gro%C3%9Fer+Stern&t=k&z=17
Mir gefällt Deine Art, die Dinge zu visualisieren 
Da kann man sich gleich mehr drunter vorstellen als bei einem ellenlangen Text
Deswegen habe ich für alle expliziten ways oder nodes als key “lane” gewählt ( siehe http://wiki.openstreetmap.org/w/images/e/eb/Lane-Tagging-L%C3%B6sungsansatz.pdf , Seite 3). Ausnahme ist lane_junction für die Kreuzungsfläche. Das dürfte aber auch kein Problem geben.
Gute Idee. Da lege ich dann aber ein bing-Bild in den Hintergrund. Irgendwo habe ich auch mal eine recht komplexe Kreuzung in Wien gesehen, die sich eignen könnte. Und ein Autobahnkreuz oder so will ich mir auch noch vornehmen, an dem man mit lane_direction probieren könnte.
Danke für das Kompliment. Macht zwar erst mal Arbeit, spart dann aber tausend Erklärungen.