Insofern richtig: destination in der momentanen Definition im Wiki ist an die Wegweiser gebunden.
Die Frage ist, ob man zur Unterstützung von Routern in der Innenstadt die Bedeutung von destination erweitert (wäre abwärtskompatibel) oder einen neuen subtag einführen muss.
Aus den Bildern die ich weiter oben verlinkt habe könnte man für den 5 spurigen Teil “destination:lanes=Cityring Süd|Cityring West|Cityring West||” ableiten.
Davor wäre dann “turn:lanes=through|through;right” + “destination:lanes=Cityring Süd;Cityring West|”.
Das anschließende Stück bekäme destination:lanes=Cityring Süd|Cityring Süd|Cityring West|Cityring West + eventuell destination=Cityring Süd;Cityring West.
Ich habe noch etwas an meinen Tipps gebastelt und denke, das sie jetzt für den Start der Wochenendaufgabe reichen zumal von euch außer dem Tip für die Autobahnbilder als Quelle zu destination:lanes keine Anmerkungen und Kritiken kamen.
Der link zur aktuellen Version: https://drive.google.com/file/d/0B_3PJBM5cOz5dUlXSUt1d29FXzg/view?usp=sharing
Ich gebe das dann mal so als Vorschlag zur Wochenaufgabe (für zwei Wochen?) weiter.
Edit: Done https://wiki.openstreetmap.org/wiki/Wochenaufgabe#Erfassen_von_Fahrspuren
Und dann noch eine Anmerkung zu den Problem-Detail-Diskussionen hier:
Ich habe kein Problem damit, wenn wir uns hier darüber austauschen. Gehört ja irgendwie dazu und trägt zur richtigen Erfassung bei.
Ich halte übrigens nichts davon, Dinge zur Unterstützung von Routern zu erfassen, die nicht in der Realität vorhanden sind. Ich denke, Router können und sollen “forward-routing” (so nenne ich das hier mal) lernen, indem sie zum Beispiel bei zwei Fahrspuren einer Richtung, von denen sich die rechte später in eine Geradeaus- und Rechtsabbieger-Spur teilt, so früh wie möglich den Wechsel auf die rechte Spur empfehlen.
Hallo Mapper,
wegen dem Mappen von Fahrspuren mit Ziel-/ Richtungsweisung über Kreuzungen will ich mal das JOSM-Plugin turnlanes ( http://wiki.openstreetmap.org/wiki/Relations/Proposed/turn_lanes#Plugin)) noch ins Spiel bringen.
Ich hatte mal in 2013 einige Kreuzungen in Erfurt damit bearbeitet (zum Bsp. hier http://www.openstreetmap.org/#map=19/50.98509/11.03645 ) , nach dem ich dann über die Thüringer Mailingliste den Hinweis bekommen habe dass ich damit zwar nichts kaputt mache aber es auch keinem nützen würde weil das Tagg turnlanes nirgends unterstütz wird habe ich davon abgelassen.
Fahrspuren zu erfassen ist meiner Meinung nach aber auch ein Ringelspiel, öffters kommen andere Mapper und zerlegen die Straßen wieder in spurweise Einbahnstraßen nur weil da eine Verkehrsinsel oder ein Fusgängerüberweg mit Mittelinsel ist.
@sennewald63
in meinen Tipps weise ich darauf hin, turnlanes aus dem entsprechenden proposal besser nicht zu verwenden. Die damit erzeugten Relationen wertet niemand aus.
Das Straßen zwischen Fahrbahnen wegen dazwischenliegender Hindernisse gesplittet werden, ist allgegenwärtig. Deshalb erfasse ich physische Fahrbahntrennungen gleich entsprechend mit.
In diesem Beispiel ist mir aufgefallen, dass sich nach dem eingetragenen Tagging von Norden kommend die Rechtsabbieger auf der Friedrich-Engels-Straße links einordnen sollen und die Linksabbieger rechts. Ist das so richtig mit der Reihenfolge der Bezeichnungen im key turn:lanes?
Laut Wiki sollen wir bei turn:lanes die Spuren in OSM-Wegesrichtung von links begonnen angeben (hier wäre das dann turn:lanes=left|left|through|through;right).
Auch die Liebknechtstraße von Süd-Osten kommend ist anders eingetragen (turn:lanes:backward=left|through;right), als auf dem Bing-Luftbild zu sehen (turn:lanes:backward=left;through|right).
Franz
Als erlaubte Quelle könntest du noch Mapillary aufnehmen.
Die Eintragungen der Spurenerfolgen immer von links nach rechts in Richtung des ways, mit dem die Straße erfasst wurde. Am einfachsten checkst du das mit dem JOSM-Plugin
https://josm.openstreetmap.de/wiki/De%3AStyles/Lane_and_Road_Attributes
Solche Fehler können entstehen, wenn die Richtung des ways gedreht wird.
Wird morgen erledigt.
Danke für den Tip
Immer in Fahrtrichtung. Bei *:backward dem Way entgegengesetzt.
Asche auf mein Haupt. Du hast natürlich recht, rab. War wohl geistig nicht mehr ganz auf der Höhe gestern abend 
Ich präzisiere:
turn:lanes=* werden in Fahrtrichtung gesehen von links nach rechts erfasst Die Trennung zwischen den Fahrspuren erfolgt durch den senkrechten Strich “|”. turn:lanes:forward und turn:lanes:backward beziehen sich auf die Richtung des ways, durch den die jeweilige Straße in OSM erfasst ist.
Gebe ich dir grundsätzlich recht, aber mit unseren derzeitigen tags können wir keine eindeutigen Daten liefern, die das ermöglichen.
Folgendes Beispiel: (die bekannte Kreuzung)
https://www.dropbox.com/s/9gl6u601wlmquy7/Kreuzung%20orginal.png?dl=0
Von der rechten Spur kommt man nach Osten weiter, von der linken nach Osten oder Norden.
Was wäre denn, wenn die Fahrbahnmarkierungen wie folgt wären? (Entschuldigt die Qualität, ist auf die schnelle gemacht, aber fürs Verständnis sollte es reichen):
https://www.dropbox.com/s/p826uhg3blwefgb/Kreuzung%20alternativ.jpg?dl=0
Dann wäre es, rechte Spur für nach Osten und Norden, linke nur nach Norden.
Das Tagging wär hier in beiden Fällen gleich. Also kann der Router nur raten, bzw. er wird gar nichts machen.
Destination ist derzeit wohl wirklich nicht dafür geeignet, nach Definition im Wiki soll es ja die Wegweiser wiedergeben. Macht auch Sinn, so kann der Router auf dem Bildschirm zur Orientierung virtuelle Wegweiser generieren, daher sollte man das nicht mit Zielstraßen vermischen.
Aber man könnte ja ‘destination:street’ oder so etwas taggen.
Die Frage ist nur, würde ein Router mit so einer Information etwas anfangen wollen? Die ganze Idee hier ist ja aufgrund der Aussage eines Scout Mitarbeiters gewachsen, die derzeitigen Daten würden keinen Spurassistenten ermöglichen. Wie wäre es, mal Kontakt aufzunehmen mit den Kollegen (oder auch anderen Routern), um zu sehen, was uns aus deren Sicht noch fehlt?
Hallo,
als ich mein genanntes Beispiel in Erfurt erfasst hatte war ich wohl definitiv nicht auf der Höhe meiner geistigen Leistungsfähigkeit 
.
Habe das ganze mal überarbeitet.
Mir ging es aber hauptsächlich um die Nutzung des Taggingschemas turnlanes ( bicht zu verwechseln mit turn:lanes ) 
.
Mit turnlanes und dem zugehöhrigen JOSM-Plugin könnten Richtungsfahrbahnen über mehrere Kreuzungspunkte gemappt werden.
Auch wenn ich mich wiederhole. Nach meinem Wissen wertet keine Anwendung nach turnlanes-Plugin erfasste Relationen aus. Außerdem basiert das auf einem Proposal ohne irgendeine Abstimmung. Ich empfehle, die Finger davon zu lassen. Irgendwann wurde darüber auch schon mal diskutiert. Ohne das Plugin sind die erzeugten Relationen für mich recht undurchsichtig und schwer wartbar. Ich kann mir auch nicht vorstellen, wie ein Router vom ZIelpunkt der Spur wieder über die erfasste Länge der Spur, bzw mehrere verschiedene Längen mehrerer Spuren rückwärts rechnet, um den Spurbeginn anzeigen zu können.
Zu deinen beiden Varianten:
Auch jetzt schon bieten Router alle Spuren an, welche für die Richtung möglich sind. In diesen Fällen wären das je nach Fall einmal die beiden linken oder die beiden rechten Spuren. Inwieweit in Deutschland u.a. noch das Rechtsfahrgebot zu beachten wäre, hängt vom Fahrer und der aktuellen Situation ab.
Ergo: das genannte Problem besteht nicht für den Router.
Zu destination:street:
Ich kann mir nicht vorstellen, wie der Router aus dieser verbalen Information in eine grafische Auswertung umwandeln sollen.
hatte deinen post #28 überlesen, turnlanes sind damit aus dem Rennen.
@all
Das Straßen zwischen Fahrbahnen wegen dazwischenliegender Hindernisse gesplittet werden ist für mich nicht verständlich, dafür gibt es Tags wie traffic_calming=island und crossing=island.
Deshalb lösche ich physische Fahrbahntrennungen beim Erfassen von Fahrspuren wenn ich darauf treffe meistens.
Senni
Gemeint sind nicht die kurzen schmalen Inseln, wie sie etwa unter http://wiki.openstreetmap.org/wiki/Tag:traffic_calming%3Disland
mit gewöhnlich unter 5 Meter beschrieben werden, und vergleichbares als Überquerungshilfe für Fußgänger, sondern z.B.:
http://www.unser38.de/braunschweig-innenstadt/natur/bluehende-mittelstreifen-in-der-hamburger-strasse-m8793,8137.html
oder
http://www.waz-online.de/var/storage/images/waz-az/wolfsburg/wolfsburg/stadt-wolfsburg/59-baeume-auf-dem-mittelstreifen/144475417-1-ger-DE/59-Baeume-auf-dem-Mittelstreifen_ArtikelQuer.jpg
Auch das
http://bc01.rp-online.de/polopoly_fs/blick-bleichpfad-richtung-ostwall-links-abbiegen-1.3995729.1391074505!httpImage/3661557537.jpg_gen/derivatives/d950x950/3661557537.jpg
und
http://www.gruene-blomberg.de/herrentrup-strasseneinmuendung.jpg
würde ich wegen der Dimensionen schon mit getrennten Fahrbahnen erfassen.
Genau diese Inseln (http://www.gruene-blomberg.de/herrentrup-strasseneinmuendung.jpg ), die typischer Weise an Autobahnanschlüssen oder Kreuzungen vorkommen
sind es, die ich beim erfassen von Fahrspuren lösche.
Durch die 2 Einbahnstraßen die da meißtens gemappt werden endstehen auch 2 Kreuzungspunkte die in der Realität nicht vorhanden sind.
An so gemappten Autobahnanschlüssen habe ich bisher noch sehr weinige turn:lanse - Einträge gefunden.
Aus einfachen Kreuzungen von 2 Straßen mit jeweils einer Links- und einer gemeinsamen Geradeaus- und Rechtsabbiegerspur werden dann 4 Kreuzungspunkte
generiert die es so nicht gibt aber die Erfassung der turn:lanes und destination:lanes erschweren.
Warum sind da wohl bisher keine Fahrspuren gemappt worden ?
Man könnte ja behaupten die Luftbilder waren bisher zu undeutlich 
.
werden die turn:lanes tags in irgendeiner karte bereits dargestellt, auch nur zum test? die darstellung in Josm ist zu unbefriedigend, wohl zum eintragen ja, aber nicht um sich das mal vorzustellen. vorallem die übergänge von z.b. 2 spuren auf 3 mit der stufe (fahrbahnbreite) die irgendwie von einem programm automatisch einen fließenden übergang darstellen muss.
Mappaint-stile → Fahrspur und Strassenattribute auch aktiv? Finde ich recht befriedigend.