Macht doch einige Unterschiede. Während bei der ersten Kreuzung vorgeschrieben ist von welchem Fahrstreifen auf welchen abgebogen werden muss (durchgezogenen Linie beim Abbiegen) ist bei der zweiten Kreuzung alles freigestellt. Ich kann frei wählen zwischen dem ersten oder zweiten Fahrstreifen.
Bitte bedenkt bei allen Konstrukten auch daran was passiert wenn jemand einfach eine Straße hinzufügt oder löscht ohne explizit Abbieger zu berücksichtigen. Da sind Relationen denke ich im Vorteil. Weil die gehen kaput und sind dann unbrauchbar. Eine generische Zuweisung zu Straße 1, 2 oder 3 kann zu falschen Ergebnissen führen.
Hier wäre das Modell mit eigenen Wegen wohl am ehesten im Vorteil, denn die kann man kaum übersehen und wird sich dann wohl drum kümmern. Selbst wenn man das nicht tut, sollte zumindest das, was schon da ist, problemlos weiter funktionieren.
Das Modell mit den eigenen Wegen sieht auf den ersten Blick sehr lukrativ aus. Das Problem ist nur wie macht man dem Router den möglichen Spurwechsel begreifbar? Wie verhält sich ein Router wenn man gerade losfährt? Es gibt ja keine Möglichkeit per GPS zu erkennen auf welcher Spur man sich gerade befindet?
Zu Fall 1:
Wenndie Karcherallee als way in OSM mit der Richtung nach oben angelegt ist, wäre ein Schlüsselpaar turn:lanes=|through|right_right_lane denkbar, um die linke Spur der Winterbergstraße auszuschließen.
Zu Fall 2:
Nichts besonderes.
Zum Schillerplatz:
Durch Schatten und abgenutzte Markierungen ist die Situation so schwer einschätzbar
Die Straßenbahn sind keine Herausforderung, da sie als separater way in geografisch korrekter Lage gemappt werden könnten. Es geht hier um routing für Straßenverkehrsteilnehmer und deren Verkehrsführung durch Verkehrszeichen oder Markierungen. In der Tolkewitzer Straße sehe ich eine Sperrfläche, weshalb hier die beiden gegenläufigen Fahrbahnen sowieso als separate ways anzulehgen wären. http://www.openstreetmap.org/?lat=51.0519084334373&lon=13.8068452477455&zoom=18
Wenn die Linie dort durchgezogen ist, taggen wir sie als durchgezogene Linie. Damit ist das Aussehen definiert. Außerdem wird erstmal für alle Verkehrsmittel angenommen, dass sie nicht überfahrbar ist.
Da nun Busse doch drüberfahren dürfen, tragen wir diese Ausnahme zusätzlich explizit ein als “überfahrbar”:bus = yes
Dann haben aber crossable und crossable:* völlig unterschiedliche Semantik und auch Syntax, nämlich ersteres Linienarten und letztere Zulässigkeit des Spurwechsels. Scheint mir wirklich keine gute Idee zu sein. Dann doch lieber bei beiden die Funktion getaggt. Oder, wie wäre es denn hiermit: Ein Tag für’s Aussehen und eines (+ Spezifizierungen) für Funktion. Dann haben wir beides und müssen uns für keinen Fall auf irgendwelche Defaults verlassen. Natürlich entsteht dann eine gewisse Redundanz, aber die würde zumindest Fehlersuchtools helfen, potenzielle Fehler zu finden, wenn die Werte nicht zusammenzupassen scheinen.
Ich weiß nicht, woher das Missverständnis kommt, ich wolle “crossable” für Linienarten benutzen.
Mein Vorschlag ist ein Tag für Linienarten (für das ich in meinem vorletzten Post keinen Namen vorgeschlagen hatte) einzuführen. Zusätzlich sollte es ein Tag wie “crossable” geben, das bei Bedarf auch mit angehängtem Verkehrsmittel oder sonstigen “Conditional restrictions” verwendet werden kann und einen Teil der Funktion des Spurtrenners abbildet.
Das ist letztlich dasselbe wie ich vorschlage, mit dem einzigen Unterschied, dass bei dir der Mapper immer die ganze Palette an Spurtrenner-Funktionstags angeben muss. Meine Idee wäre, dass er diese nur dort zusätzlich zur Linienart angeben muss, wo die Bedeutung vom Normalfall abweicht - und sie anderswo lediglich “zur Sicherheit” angeben kann.
Naja, ich schließe aus deinen Posts #66, wo du sagtst, das Eintragen des Aussehens sei der einzige gangbare Weg und dass Mapper die Bedeutung dessen nicht kennen müssten (also nicht eintragen könnten), sowie #74, wo du von crossable, Linienmustern und Defaultwerten für selbige sprichst. Von beidem hab ich jetzt nirgends was finden können. Ansonsten ist ja alles schön, wenn alles nur Missverständnisse sind. Ich wäre trotzdem dafür, die Funktion im Allgemeinen und abweichendes Aussehen nur wenn nötig anzugeben und abgesehen davon sowieso dafür, die Spuren über einzelne Wege abzubilden.
@viw: Kein Nachteil zum Modell ohne eigenständige Spuren. Es gibt ja trotzdem noch den normalen highway Weg, also kann der Router zunächst allgemein annehmen, dass man sich auf diesem Weg befindet und dann zum nächstmöglichen Zeitpunkt eine Spur vorschlagen. Mehr bleibt ihm ohne Spurwege ja auch nicht übrig.
Das turn:lanes=left|through|right sollte sich immer auf das Ende des Weges beziehen. Wenn man es immer auf den nächsten Knoten beziehen würde, hätte man erstens probleme mit anschließenden Fusswegen etc… Wenn es sich auf den Knoten beziehen würde, bräuchte man z.B. eine Abbiegespur hinter dem Knoten normalerweise nicht mehr und müßte den Weg daher ohnehin in diesem knoten aufteilen.
Häufig dürfte es jedoch vorkommen, dass sich die turn:lanes Werte nicht auf das Ende des aktuellen Weges sondern erst auf das Ende des nächsten, übernächsten, etc. Weges beziehen, weil eine Abbiegespur entsprechend lang ist.
Hier kann man dann mit turn:physical:lanes=through|through|through oder kurz turn:physical=through die Wirkung für das Ende des ersten Weges übersteuern.
Hier ist es aber eine eindeutige Regel, wie der Weg vom Router auszuwählen ist. Sollte dabei die Tags eben so setzen, das auch bei leichten Geometrieveränderungen noch das gewünschte Ergebnis sicher herauskommt.
Wenn man jeden Router seine eigene Heuristik verwenden lassen , die dann nur manchmal funktioniert, wäre es natürlich problematisch.
Eine gewisse Fehleranfälligkeit bei Veränderungen bleibt natürlich, aber ist diese bei Relationen nicht durch mangelnde Sichtbarkeit noch höher?
Wenn am nächsten Kreuzungspunkt mit einem highway das Abbiegen in der am way beschriebenen Form nicht möglich ist, darf dort kein gemeinsamer node sein. Sollte an diesem Punkt aber z.B. nur eine von mehreren Abzweigmöglichkeiten machbar sein, müsste es natürlich einen gemeinsamen Knoten geben und wir kämem um eine relation=restriction hier nicht herum.
Da sich turn auf das Wegende beziehen muss, stört gemeinsame Punkt stört erst dann, wenn dort auch der Weg endet. Aber auch in diesem Fall stört er nur geringfügig, da mit turn:physical=through dem Router mitgeteilt werden kann, dass die Fahrspuren in diesem Knoten noch geradeaus weiterlaufen, auch wenn sie schon anders markiert sind, wie durch turn:lanes beschrieben wird.
Eine Relation brauchen wird dafür noch lange nicht.
Beispiel: eine Einbahnstraße kreuzt eine Straße mit baulich getrennten Fahrbahnen. Wir haben einen also zwei Kreuzungsknoten.
Nehmen wir weiter an, die Einbahnstraße hat vor dem ersten Kreuzungsknoten drei Spuren mit turn:lanes=left|through|right. Man kann dabei natürlich im ersten Kreuzungsknoten nur nach rechts und im zweiten Knoten nur nach links abbiegen. Das können wir dem Router wie folgt mitteilen:
Die Einbahnstraße wird durch drei separate Wege dargestellt werden:
bis zum ersten Kreuzungsknoten
lanes=3
turn:lanes=left|through|right
turn:physical:lanes=through|through|right
zwischen den beiden Kreuzungsknoten
lanes=2
turn:lanes=left|through
nach dem zweiten Kreuzungsknoten
lanes=1
Das
turn:physical:lanes=through|through|right
im ersten Abschnitt könnte natürlich auch als
turn:physical:lanes=through||
geschrieben werden, da dann für die anderen Spuren die Werte aus turn:lanes zu übernehmen wären. Insgesamt hat dieses turn:physical:lanes die Aufgabe, dem Router mitzuteilen, dass die linke Spur zwar mit einem Linksabbieger-Pfeil gekennzeichnet ist, jedoch im ersten Kreuzungsknoten dennoch geradeaus weiterführt.
In diesem einfachen Fall könnten wir auch so abwandeln, dass aus den beiden kreuzenden Fahrbahnen zwei eigenständige Straßen jeweils mit Gegenverkehr werden. Nehmen wir dann an, dass die Abbiegemöglichkeiten unverändert bleiben, so können die Tags der Einbahnstraße unverändert bleiben.
Im ursprüglichen einfachen Fall wäre es das turn:physical:lanes prinzipiell redundant, wenn der Router die oneway Eigenschaft der kreuzenden Fahrbahnen auswertet. Dann ist im ersten Kreuzungspunkt die am besten zum turn value left passende in abgehender Richtung befahrbare Weg ohnehin der geradeaus zum zweiten Kreuzungspunkt führende Weg.
Ein Router sollte so arbeiten, dass er in diesem Fall auch ohne turn:physical:lanes auskommt, jedoch sollte ein Inspektor dies besser als Fehler melden.
Die Tags sollten so gesetzt werden, dass man ohne Ausnutzung der oneway-Eigenschaft zum richtigen Ergebnis kommt. Andernfalls kann es leicht zum Chaos führen, wenn Einschränkungen der Oneway Eigenschaft hinzukommen (bespielsweise Fahrräder in Gegenrichtung frei).
Im ersten Fall könnte der von mir vor einigen Tagen vorgeschlagene Key
turn:input:lanes=left|right eingesetzt werden, um zu kennzeichnen, in welcher Form in die
Spuren der abgehenden Winterbergstraße (dort zu taggen) eingefahren werden kann.
Dies ist auch keine schlechte Idee, allerdings wird es mit der Bezeichnung in der Form
_right_lane schwierig, wenn dort sehr viele Spuren vorhanden sind.
Vieleicht sollten wir ein Tag zu Benennung von Spuren einführen. Wenn man z.B. die Winterbergstraße mit
lanename:lanes=WBS_F1|WBS_F2
taggt, könnte in der Karcherallee mit
turn:lanes=|through|right:WBS_F2
das Rechsabbiegen in die linke Spur ausgeschlossen werden.
Die Namen für die Lanes sind natürlich frei wählbar. Meine Idee bei WBS_F1 war Abkürzung des Straßennamens + Fahrtrichtung (forward) + Nummerierung der Spur.
Alternativ zu lanename:lanes könnte auch folgende Keys verwendet werden:
lamelabel:lanes
label:lanes
name:lanes
lane:lanes
Die Benennung der Lanes würde uns auch erlauben, zu definieren, dass die Abzweigung bereits vor dem Ende des Weges erfolgt, wenn die passend benannte weiterführende Spur nicht an dem Endknoten, sondern an einer früheren Interconnection des Weges vorhanden ist. Wenn dann alle
turn Möglichkeiten einer Spur abgezweigt sind, sollte dies bedeuten, dass die betreffende Spur vorzeitig endet. Damit können wir uns viele Aufteilungen von Wegen und den zugehörigen Aufwand, um deren Spuren wieder richtig zu verknüpfen, ersparen.
Mittlerweile erfolgreich getestet, und in den letzten Tagen täglich ein AK destiniert.
(An der Stelle nochmal Danke an den Master von autobahn-bilder.de)
Edit: Ab V2372 ist die Option im Standard mkgmap drin.
