Fahrspuren mit Richtungspfeilen erfassen; Wochenaufgabe in KW 47/48

Aber das Navi weiss ja nach dem tagging auch nur, dass beide Spuren zur übernächsten Kreuzung führen und wird sie dementsprechend anbieten.
Mit Destination ist auch so eine Sache, selbst wenn es beschildert wäre, steht u.U. an der 2. Stelle auf dem Wegweiser für die gleiche Spur etwas anderes (z.B. ein Stadtname mehr), als auf dem ersten. Das kann man imho von einem Router nicht erwarten, das zu erkennen.

Das slight_right der mittleren Spur bezieht sich hier wohl auf die Busspur, die zur Mittelinsel der Kurt-Schumacher-Straße führt.

Die durchgezogene Linie existiert wohl auch nur in meinem Kopf. Vielleicht war da früher mal eine. Oder ich hab es falsch in Erinnerung, weil es immer zu Problemen führt, wenn jemand von ganz rechts rüberzieht, um doch nach Norden zu kommen.

Ja, dort habe ich gestern erst die lanes eingetragen, da ich dachte, man müsste hier die lanes weiterführen.

Kenn ich noch gar nicht das tag, muss ich mich mal einlesen. Aber das Problem bleibt, dass ich mein tagging nicht testen kann. Schön dass es für JOSM einen Zeichenstil gibt, der mir die lanes sofort visualisiert, aber was ein Router daraus macht (machen kann), kann ich nur vermuten.

So wie es im Augenblick aussieht könnte ich für ein rechts abbiegen nach “Am Windmühlenberg” beide Spuren verwenden (through;right|right).
Zum “John-F.-Kennedy-Platz” müsste ich die linke Spur (t h r o u g h;right) fahren. Der Weg müsste deshalb eigentlich mit (through|through;right) getagt sein.
Falls das entprechend ausgeschildert ist könntest du eventuell mit destination:lanes arbeiten.
“|Kurt-Schumacher-Straße” für das zweispurige Stück und dann “|||Kurt-Schumacher-Straße|Kurt-Schumacher-Straße”.

Das funktioniert natürlich nicht, wenn der Router/Spurassistent nur eine simple Vorwärtssuche macht. Er müsste dann schon zumindest ein lokales backtracking machen, was deutlich intelligenter, aber auch aufwendiger ist. Das wären dann die Spurempfehlungen, die das Verhalten eines Fahrers mit Ortskenntnis nachempfinden.

Über Tagging lässt sich das nur schwer realisieren (siehe die posts). Das müsste man dann schon lange vor der Kreuzung und vor der Beschilderung durchführen. Auf Autobahnen ist diese Vorwegweisung bei Autobahnkreuzen/-dreiecken meist realisiert, in Städten wäre der Autofahrer mit einem Schilderwald wegen der Kreuzungsdichte überfordert. Die Datenbank ist da tolerabler - bei Routern bin ich mir da allerdings nicht so sicher.

Ich habe mir die Kreuzung jetzt noch einige Male angesehen, und da sind einige neue Fragen und Erkenntnisse aufgekommen.

btw, ich möchte hier keineswegs den Wochenaufgabenthread kapern, sondern diese Kreuzung zur Veranschaulichung von grundsätzlichen Fragen nutzen.

Also nochmal kurz zur Kreuzung:

Völlig richtig, und inzwischen meine ich auch, dass er anders getaggt gehört. Ich war fälschlicherweise davon ausgegangen, dass Markierungen auf dem Augusttorwall (die Ausgangsstraße) sich schon auf die nächste Kreuzung beziehen. Sprich, halblinks heisst Richtung Norden/Auguststraße, rechts heisst Osten/Kurt-Schumacher-Straße.
Das ist natürlich falsch. Es bezieht sich nur auf die Kreuzung Augusttorwall/Wolfenbüttelerstraße. Und rechts auf der mittleren Spur heisst rechts ab auf die Wolfenbütteler.

Trotzdem, um jetzt zum Grundsätzlichen zu kommen, müsste man dem Router die Information an die Hand geben können, wie sinnvoll die Lanes zu nutzen sind.
Ich möchte nicht, wenn ich vom Augusttorwall komme und zur Auguststraße möchte, dass der Router mir die linke und mittlere Spur anbietet (auch wenn es erlaubt ist). Da ich ja auf dem kurzen Stück John-F-Kennedy-Platz eine Spur kreuzen müsste, auf der sich nur Rechtsabbieger in Richtung Kurt-Schumacher-Straße befinden.

Ich bin mir nicht sicher, ob dort Schilder stehen, die eine Benennung der Destination haben. Aber warum kann ich das nur bei Kreuzungen mit Schildern?
Wie wäre es, bei Destination den Ziel-Straßennamen einzugeben? Also würde ich (unter anderem) auf dem Augusttorwall eintragen: destination:lanes= Auguststraße|Kurt-Schumacher-Straße;Wolfenbüttelerstraße|Wolfenbüttelerstraße.
Aus dieser Information wüsste der Router, die mittlere Spur führt nicht zur Auguststraße.
Oder richtung Osten könnte er daraus generieren: Nehmen Sie die mittlere Spur auf/über John-F-Kennedyplatz in Richtung Kurt-Schumacher-Straße.

Wenn ich mal mitkapern darf, da ich grad meine erste Destination gemalt hab:

Klingt sinnvoll und genau so hab ich das gerade hier auch gemacht. Sinn dahinter ist, dass normal nicht vorgesehen ist, in den Frauenplan einzubiegen (Einbahnstrasse läuft da normal auch andersrum, und grad is zusätzlich Baustelle).
Kann sich das mal wer mit Plan anschauen und mir sagen, ob ich es richtig hab?

destination ist keine Angabe für Router, die festlegt, wohin ein Weg führt oder nicht führt. destination ist nur eine grobe Richtungsangabe wie sie auf Wegweisern zu finden ist. Das angegebene Ziel kann dabei auch mehrere hundert Kilometer entfernt sein. Überspitzt gesagt könnte mit der Angabe auch die Auguststraße in irgendeiner anderen Stadt oder einem anderen Land gemeint sein.

http://wiki.openstreetmap.org/wiki/Key:destination

http://wiki.openstreetmap.org/wiki/DE:Key:destination

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 :roll_eyes:
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 :slight_smile: :slight_smile: :slight_smile: .
Habe das ganze mal überarbeitet.

Mir ging es aber hauptsächlich um die Nutzung des Taggingschemas turnlanes ( bicht zu verwechseln mit turn:lanes ) :sunglasses: :sunglasses: :sunglasses: .
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.