Grundsätzlich zu Plugins: Ich finde es gefährlich, dass hier schon Implementierungen entwickelt werden, obwohl das Taggingschema noch gar nicht ausgereift ist. Sobald es ein Plugin gibt, finden sich Leute, die es benutzen, und dann kommt gerade beim Spurtagging ein Wildwuchs im Datenbestand heraus.
Naja, zumindest führt es zu einem klar definierten Ergebnis, dass sich bei einer Entscheidung leicht (halb-)automatisch anpassen ließe. Dagegen kann man nicht jede von irgendjemandem privat beschlossene Variante aufspüren.
Dann sag doch mal, was du von diesem Lösungsansatz hältst. Oder hast du vielleicht sogar einen viel besseren Vorschlag. Für mich ist dieses proposal und plugin erst einmal ein guter Ansatz mit Entwicklungspotential. Was daraus wird, entscheidet die Masse auch durch Akzeptanz.
Nichts. Es deckt nur einen kleinen Teil der Anforderungen ab, benötigt trotzdem Relationen, und Spurlängen in m anzugeben ist albern. Soll man mit dem Maßband auf der Straße herumgehen? Was ist, wenn der Way geteilt wird (z.B. Brücke, Geschwindigkeitsbeschränkung)?
Siehe weiter vorn im Tread. Nochmal der Link: http://wiki.openstreetmap.org/wiki/User:Fkv/lane_mapping_draft.
Ich habe mir die verschiedenen Ansätze in diesem Thread und den verschiedenen Proposals zum Thema genauer angeschaut. Dazu gehört auch deins.
Im Wesentlichen besteht Einigkeit, dass die lanes als Bestandteil der ways abgebildet werden sollen. Es existieren jedoch verschiedene Vorschläge über die Gestaltung der key-value-Paare. Bevorzugt wird nach meiner Beobachtung der Ansatz, welcher die betroffenen lanes mit Trennzeichen dazwischen einem Key entsprechender Eigenschaft zugeordnet.
Dies gilt auch für den Vorschlag von benshu. Zusätzlich werden darin aber Relationen eingesetzt, wodurch erkennbar und auswertbar wird, wie es bei Verwendung der entsprechenden Spur nach dem Kreuzungs- bzw. Abzweigpunkt weitergeht. Außerdem hat dies den Vorteil, dass die lanes unabhängig von der way-Richtung abgebildet sind, was die Konstruktion robust gegen zufällige oder gewollte Drehungen der way-Richtung macht.
Zu deinem Einwand wegen der Spurlängen in Metern vom Kreuzungspunkt aus:
Bei hinreichender Auflösung von bing/Aerowest etc. brauchst du kein Maßband, denn in JOSM kann man messen. Wenn der Weg geteilt ist wie z.B. in meinem Fall 3 http://www.openstreetmap.org/browse/node/265549774 , kann das plugin vom Abbiege-/Kreuzungspunkt rückwärts über mehrere Wegteile arbeiten, sofern diese angaben zu lanes=* haben, was man auch im ersten Video des Proposals gut sieht.
Für mich ist diese anwenderfreundliche Erfassung von Straßenspuren kein „nur kleiner Teil der Anforderungen", auch wenn Radfahrer und Fußgänger noch nicht berücksichtigt sind. Mir stellt sich die Frage, ob es nicht besser ist, ein Tool zu haben mit dem wir zumindest Spuren für motorisierten Verkehr einfach erfassen können, oder ob wir weiter nur von einer eierlegenden Wollmilchsau träumen wollen.
Gerne bin ich bereit, auch andere Lösungsansätze auszuprobieren, wenn sie ein Mindestmaß an Anwenderfreundlichkeit bei der Eingabe erfüllen, was ich leider bei der Masse der vorliegenden Proposals noch nicht erkenne.
Außeerdem bewegen wir uns solange im spekulativen Bereich, wie wir nicht wissen, ob Auswertungen wie Renderer oder Router überhaupt mit diesen Daten etwas vernünftiges anfangen können. Bei einem derartig komplexen Bereich müssen wir dies in unsere Überlegungen einbeziehen.
Ich denke, dass laesst sich mit den verschiedenen Lanes-Vorschlaegen schon ganz gut beschreiben (mit einigen besser, mit anderen weniger). Aber man darf hier nicht aus den Augen verlieren, dass die Lanes in erster Linie eine funktionelle Beschreibung sein sollen. Die koennen und sollen keinen Ersatz fuer das hochaufloesende Luftbildabmalen sein. Umgekehrt kann letzteres aber auch nicht die funktionelle Beschreibung ersetzen.
Mit den Lanes-Vorschlaegen kannst du im Prinzip ja fuer jeden Abschnitt angeben, welche Spuren sich dort befinden, wie breit diese Spuren sind und wie die Trennung zwischen den Spuren aussieht. Der stationaere Zustand ist damit eigentlich hinreichend beschrieben. Beim Uebergang von einem Abschnitt zum anderen sehen die Vorschlaege zwar vor, dass man erfasst, welche Spur vom ersten Abschnitt zu welcher Spur im zweiten Abschnitt fuehrt, daraus wird ein Renderer aber sicherlich kein Pseudo-Luftbild konstruieren koennen.
Gruss
Torsten
Sicher, dass dadurch die Werte richtungsinvariant werden? Eigentlich haengt die Abfolge der Lane-Erfassung immer von der Richtung des Weges ab. (Hast du noch mal einen Link zu benshus Vorschlag?)
Das bestimmt nicht. Aber nur, weil es fuer einen Vorschlag schon mal ein JOSM-Plugin gibt, ist der Vorschlag damit bestimmt nicht automatisch anwenderfreundlicher als andere. Oder soll das hier mal wieder das JOSM-Diktat fuer eine suboptimale Entscheidung sorgen?
Sprach der Mensch, der nicht mal ohne spezielles Eingabe-Tool ueber die Moeglichkeiten der Datenerfassung werten kann 
Scherz beiseite: Niemand wird fuer die verschiedenen Vorschlaege mal eben so einen Beispielrouter mit Spurrouting zaubern. Das gibt es zur Zeit nicht fertig und das wird auch erst irgendwann in der Zukunft entstehen, wenn dafuer geeignete Daten als Grundlage existieren.
Fuer die automatische Auswertung waere es sicherlich einfacher, wenn die Verbindungen der Spuren zu den anderen Wegen ueber Relationen erfasst wuerden, als ueber Tags wie left, right oder so. Letztendlich muss sich die Auswertung daraus naemlich die Relation selber zusammen basteln, indem sie sucht, welche Weg jeweils gemeint ist. Das ist nicht unmoeglich, erhoeht aber den Aufwand fuer die Auswertung. Auf der anderen Seite erleichtert das aber die Erfassung, verlagert die Arbeit also vom Mapper zur Auswertung.
Eigentlich denke ich nicht, dass das ein geschickter Ansatz ist. Auf der anderen Seite halte ich den massiven Einsatz von Relationen auch fuer suboptimal. Und ich denke auch nicht, dass ein auf Relationen basierender Vorschlag mehrheitsfaehig ist. Denn aufgrund der Anzahl wird OSM doch von den Mappern getrieben.
Aber mal was anderes:
Wie kommen wir bei dem Thema weiter voran? Bisher haben wie nur Ideen und Vorschlaege gesammelt.
Gruss
Torsten
Da muss ich mich nochmal wiederholen: Ich behaupte mal, dass in 90%+ die Verbindung der Spuren eindeutig ist. Vielleicht sogar 95 oder noch mehr. Z.B. wenn die Spuren der Zielstrasse gleich der Ursprungsstrasse sind. Oder wenn 2 Rechtsabbiegerspuren in die beiden rechtesten Spuren der mehrspurigen Zielstrasse münden. Es macht keinen Sinn Relationen zwingend zu erfordern, wenn es nicht nötig ist.
Verbleibt die Minderheit der Kreuzungen, die wohl nicht ohne Relationen auskommen. Z.B. bei Abbiegung rechts und halbrechts.
Wenn ein Router damit nicht umgehen kann, können wir es gleich ganz lassen.
Das Plugin legt Relationen genau wie bei restrictions als from-via-to an. Hier der link zum proposal:
http://wiki.openstreetmap.org/wiki/Relations/Proposed/turn_lanes
Sicher nicht. Weiter oben habe ich gesagt:
Mein Fazit:
Ein tolles Plugin und eine gute Möglichkeit, Abbiegespuren zu erfassen, die man weiter verfolgen sollte. Danke benshu. Ob Auswertungen damit umgehen können, muss aber noch getestet werden. Für weitere Überlegungen in diese Richtung ist es nun erforderlich, dass die Auswertungsfraktion beteiligt wird und deren Bedürfnisse einfließen.
Mir gefällt die für diesen Fall bewusst gewählte Rolle als DAU. 
http://de.wiktionary.org/wiki/DAU
http://www.sprueche-ueber-sprueche.de/index.php?page=indianersprueche&sprueche-id=1 (die ersten drei )
An der Grundlage arbeiten wir.
Das Thema ist nicht trivial zu lösen. Die Frage für mich ist generell, wie wir - trotz und entgegen dem Mantra - den Spagat zwischen anwenderfreundlicher Erfassung und einem auswertungsfreundlichem Datenschema schaffen.
http://www.sprueche-ueber-sprueche.de/index.php?page=indianersprueche&sprueche-id=1 (zweiter Spruch)
Wir haben soviel subopimales in OSM, über das wir hier wiederholt ergebnislos raufen. Ich bin offen für jede überzeugende Alternative.
Das sehe ich auch so, die Leute hier, die meinen Spurrouting zu brauchen sollen erst einmal ein vom Menschen benutzbares Taggingschema entwickeln und es eine Weile testen, bevor man über Tools oder Plugins nachdenkt. Man darf nämlich nicht vergessen, das die Daten letztendlich vom Menschen verwaltet werden müssen!
Ich frage mich eh, was der wirkliche Nutzen des Spurroutings sein soll, bis darauf, das das Rendering noch realitätsnäher ist? Es ist ja nicht so, das die Naviansage im Moment wie folgt ist:
“Wenn sie jetzt beim Autofahren aufmerksam aus dem Fenster sehen und auf den Verkehr achten sollten, werden sie erkennen, das da vorne im 200 m eine Ampelkreuung ist. Da sie sich auf einer mehrspurigen Straße befinden, sollten sie, wenn sie links abbiegen wollen, davon ausgehen, das sie sich evtl. in die Linksabbiegespur einordnen müssen.”
Ach ja, und dann sind da ja auch noch die Mapper, die meinen, der highway=footway + footway=sidewalk wäre kein getrenntes Objekt, was man neben der Straße zusätzlich mappen sollte. Weil schließlich ist die GPS-Genauigkeit ja viel zu schlecht… …ja, aber bei Abbiegespuren, wo im Unterschied zum footway/cycleway, nicht einmal eine Abgrenzung über die gewählte Verhersmittelart möglich ist, soll das dann gehen?
Ich weiss nicht, ob ich dich jetzt missverstehe. Denn die Vorschlaege fuers Spur-Mapping hier zielen ja gerade darauf ab, dass man NICHT eigenstaendige Wege fuer die einzelnen Spuren eintraegt, weil genau das auch das Routing mit den bereits existierenden Navis verschlechtert/unbrauchbar macht.
Man kann die Flaechen bei OSM so detailliert erfassen, wie man lustig ist. Aber beim Routinggraphen ist es nun mal so, dass uebertriebene Details echt schaedlich sind. In meinen Augen geht es bei dieser Diskussion also darum, wie man den Mappern eine Loesung fuer die Detailerfassung bieten kann, die A) fuer eine automatische Auswertung (Spurrouting) in Zukunft vorbereitet und B) die bestehenden Navigationsloesungen nicht behindert sondern so gut wie moeglich unterstuetzt.
Wie ich es schon vermutet hatte: Die Reihenfolge bei der Spurnummerierung haengt natuerlich von den Richtung des Weges ab, also kann man auch hier nicht beliebig die Wegrichtung aendern.
Ob man die Verbindungen der Spuren von einem Weg zum naechsten besser per Tags oder besser per Relation erfasst, bin ich mir nicht sicher. Aber der Vorschlag von benschu, die Laengen der Spuren in eine Relation zu packen, ist echt ganz schoen daneben.
Aber noch mal die Frage: Wie kommen wir bei den verschiedenen Vorschlaegen jetzt weiter voran, am besten zu einer gemeinsamen Loesung?
Gruss
Torsten
Neben dem turnlane-plugin gibt es noch zwei weitere, die in den Weiten der Wiki schlummern:
http://wiki.openstreetmap.org/wiki/User:%C3%96mmes/Wayparts
zeigt einen Ansatz am Beispiel einer kreuzungsfreien Autobahn-Auf-/Abfahrt.
http://wiki.openstreetmap.org/wiki/Proposed_features/lane_and_lane_group
ist ein Versuch, Straßenspuren mit Rad- und Fußwegen unter einen Hut zu bringen.
Auch sie entstanden aus der Erkenntnis, dass mapping von Spuren für den normalen OSM-Mapper nicht ohne Eingabehilfe attraktiv wird bzw. überhaupt umsetzbar ist. Ich habe beide noch nicht getestet und kann sie deshalb auch nicht beurteilen. Aber deshalb muss man die Plugins ja nicht gleich verurteilen. Schließlich haben da Menschen Hirnschmalz und Zeit investiert um OSM voran zu bringen.
Eine Vision wäre, die Vorteile der verschiedenen Erfassungshilfen zu kombinieren, um dann ein anwenderfreundliches Tool für die Erfassung von Spuren bzw. Linienbündeln zu haben, welches die Daten robust und auswertungsfähig speichert.
Hier noch einige weitere links zum Thema:
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Lane
http://wiki.openstreetmap.org/wiki/Proposed_features/Lanes_as_Relations
http://wiki.openstreetmap.org/wiki/Users:cmuelle8/multiple_way_tagging_on_single_geometry
http://wiki.openstreetmap.org/wiki/Vorschlag_Mittelstreifen_und_Seitenbereiche
http://wiki.openstreetmap.org/wiki/DE:Lane_Assist
Vielleicht bieten die auch noch ein paar gute Ideen 
Aber es wäre doch z.B. hier
http://maps.google.de/maps?saddr=St%C3%BClerstra%C3%9Fe&daddr=Spreeweg&hl=de&ie=UTF8&ll=52.508572,13.350325&spn=0.002563,0.004812&sll=52.508136,13.349888&sspn=0.001282,0.002406&geocode=FYE1IQMdPLHLAA%3BFSpSIQMdz7nLAA&mra=mift&mrsp=0&sz=19&t=h&z=18
hilfreich, wenn ich als Ortsfremder im tosenden Verkehr folgende Ansage bekäme:
„In hundert Metern auf die zweite Spur von links einordnen, dann nach hundert Metern links abbiegen und der zweiten Spur von links geradeaus bis zum Kreisverkehr folgen."
Richtungsabhängige Fahrspuren sind genauso Realität wie footways oder Hundekottütenspender, weshalb deren exklusive Erfassung in OSM durchaus berechtigt ist. Solange Spurwechsel möglich ist, sollten sie aber nicht als eigenständiger way angelegt werden, denn sie sind dann Bestandteil des highway.
Auch dieser thread enthält einige interessante Ansätze zur Problemlösung. Lasst uns doch die „best of" bündeln und daraus etwas Vernünftiges machen.
Unser Problem entsteht auch durch Linienbündel. Da wurde schon vor vier Jahren in einem Workshop dran gearbeitet.
http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Workshops/Linienb%C3%BCndel
Die Erkenntnisse treffen heute noch zu. Leider sind wir immer noch nicht weiter. Das lanetool-plugin entstand übrigens infolge dieses Workshops.
Genau, denn es gilt:
„Wo kämen wir hin, wenn jeder sagte, wo kämen wir hin und keiner ginge, um zu sehen, wohin wir kämen, wenn wir gingen." (Kurt Marti)
Sehe ich nicht so
Schau dir mal diese Test-Relation an: http://www.openstreetmap.org/browse/relation/2006310
Die Information zur zusätzlichen Abbiegespur nach links steckt in der Relation als “lanes:extra” und bezieht sich nur auf die Fahrt in Richtung zum Abbiegepunkt “via”. Siehe auch http://wiki.openstreetmap.org/wiki/Relations/Proposed/turn_lanes#Allowed_Turns
und im Beispiel http://wiki.openstreetmap.org/wiki/Relations/Proposed/turn_lanes#Example_2 mit einer Rechtsabbiegespur.
Das ganze ist genauso robust wie die turn-restrictions , da from-via-to die Richtung bestimmt.
Hast du einen besseren? Diese Ansatz hat den “Vorteil”, dass man ways nicht für Abbiegespuren zusätzlich teilen muss und dass bei ways, die wegen bridge, embankment usw schon geteilt sind, die zusätzlichen lanes nicht über alle Wegteile anlegen muss, wenn man die Spurlänge will, was aber aus Sicht des routing sinnvoll ist. ich sehe den Vorteil darin, dass man mit Ausnahme der “Standard-lanes” an den beteiligten ways selbst nicht weiter herumbasteln muss.
- edit: Dreckfuhlerberüchtigung*
Ist zwar neben der “Spur” - aber trifft auch hierzu.
Ich hatte als Neuling vor einem Jahr schon einmal einen Vorschlag zu den vielen, viel zu vielen “Eigenständigkeiten des Taggen”.
Es gibt ein “TEAM”. Besetzt mit den “Urgesteinen von OSM”. Diese treffen nach Diskussionen auch eine “Entscheidung”. Und warum soll eine “Entscheidung” nicht auch noch einmal diskutiert werden, wenn neue Erkenntnisse es erfordern.
Etwas “Demokratie” unter die “Anarchie”.
So wie bei der Lizenzdiskussion? “Sag ja oder verschwinde!”
weissnich,
ajoessen
OT on:
Unter http://forum.openstreetmap.org/viewtopic.php?pid=209019#p209019
habe ich mich unter anderem auch schon mal darüber ausgelassen 
OT off:
Mindestens dieses Thema hier erfordert einfach die Zusammenarbeit von Mappern, Datenbank-Gurus und Entwicklern von Routern und ein gesundes Maß an Kompromissbereitschaft mit Fokus auf eine für alle praktikable Lösung.
Sollst auch mal recht haben, das hatte ich nicht ordentlich gelesen.
Wenn wir aus allen anderen Gruenden jeweils die Wege teilen, dann halte ich es fuer eine ziemlich dumme Idee, bei einer weiteren Wegeigenschaft dieses Verfahren aufzugeben und ploetzlich etwas voellig neues einzufuehren. Alle anderen Tags koennte man auch per Relation an die Wege haengen. Aber wuerde dann da noch irgend jemand durchblicken?
Das ganze soll ja auch nicht nur per JOSM-Plugin bedienbar sein, sondern muss auch ohne spezielle Benutzeroberflaeche noch verstanden werden koennen.
=> Ein Grund mehr, warum man nicht ein Beispiel-JOSM-Plugin fuer die Bewertung eines Tagging-Schemas heranziehen sollte.
Gruss
Torsten
Die Idee, Menschen und Güter mit Hilfe von damp- oder motorbetriebenen Fahrzeugen zu befördern , wurde anfangs auch als dumme Idee abgetan und hat sich doch durchgesetzt
Welches Relationskonstrukt in OSM wird ohne Hilfmittel in Potlatch, JOSM usw. angelegt und von allen verstanden?
Das Tagging-Schema ergibt sich aus dem proposal und wird anhand dessen bewertet. Das Plugin setzt das Tagging-Schema anwenderfreundlich um. Beides ist sicher ausbaufähig, kann aber auch in Folge einer genaueren Betrachtung verworfen werden. Kommen wir zu dem Ergebnis, dass das Proposal unbrauchbar ist, macht das Plugin auch so keinen Sinn mehr.
Für mich zeigen alle drei oben genannten und mit Plugins hinterlegten Proposals lediglich, dass für die verschiedenen Ansätze eine technische Unterstützung des Mappers bei der Eingabe möglich ist (und auch bei der Komplexität Sinn macht).
Und fuer mich zeigt das, dass diese Vorschlage einfach schon von sich aus zu kompliziert sind. Wenn die Laenge der Spuren nicht in einer Relation versteckt werden, dann braucht man dafuer auch kein extra Hilfswerkzeug.
Die exakte Beschreibung einer Kreuzung mit 7 Strassen mit jeweils 9 Spuren wird zwar immer kompliziert werden, ist zum Glueck ja aber nicht der Normalfall. Wenn in 99% der Faelle ein Konstrukt von einem durchschnittlichen Mapper nicht mehr ohne Hilfsmittel ueberblickt werden kann, dann ist das fuer OSM kein brauchbarer Ansatz.
Gruss
Torsten
Die Welt ist nun einmal kompliziert. Nur weil dein Gehirn ständig vereinfacht und filtert kannst du dich überhaupt auf das wesentliche konzentieren. Das andere Personen andere Dinge wesentlich finden unterscheidet die Menschen. Damit wird das Modell dann aber leider auch kompliziert. Wenn es aber ein Hilfsmittel gibt mit dem man das ganze visuell drastellen kann, so kann man wie bei OSM 3D entweder probieren oder besser gleich noch wysiwyg zusammenklicken. Wer sagt denn das ÖPNV Relationen mit den ganzen Metarelationen einfach sind? Dennoch gibt es eine Gruppe von Mappern die sich damit beschäftigen und das auch auswerten.
Gleiches gilt übrigens für TMC.