Warum haben die als oneway=yes getagged Routen-Elemente der Route “L 1152” nicht jeweils die Rollen forward und forward? Oder leitet das ein Router automatisch aus oneway=yes ab? Wären dann die Rollen forward/backward nicht obsolet?
Es gibt zwei Arten von Routen beim öffentlichen Verkehr. “forward” und “backward” gab es nur im alten Routenschema und die da benutzten Routen sehen eher nach dem neuen aus. “forward” und “backward” gehören da also nicht rein.
Hej! Für den öffentlichen Nahverkehr ist mir das klar. Wie sieht aber die Situation bei gewöhnlichen Straßen für Individualverkehr aus? Z.B. eine Landstraße wie die L1187 aus dem Kartenausschnitt oben. Sollte den Einbahnstraßen hier nicht zusätzlich jeweils die Rollen forward zugewiesen werden?
Nicht alle Routenrelationen unterscheiden pro Richtung. Eine normale Landesstraße hat wohl meist nur eine Relation und bei einer Auftrennung erscheint forward/backward sinnvoll. Eine Ausnahme für Einbahnstraßen ist diskussionswürdig. Was ist z.B. wenn die Gegenrichtung für Radfahrer frei ist?
Ein route=hiking Relation orientiert sich eher selten an einer Einbahnstraßenregelung, da sie in beide Richtungen begangen werden kann. Gibt es aber eine festgelegte Laufrichtung (z.B. um Tafeln nacheinander aufzusuchen), dann benötige ich die Rollen forward/backward und die kann dann sogar gegen die Einbahnstraße laufen, also ein oneway=yes mit der role backward in der Relation.
Der Relationstitel in deinem Beispiel “Vom Schloß zum Schlößle” gibt auch den Hinweis auf die Wanderrichtung.
Frohes Mai-Wander-Mappen!
Cepesko
Dass ist eine sehr missverständliche Definition, da du nicht erwähnt hast, dass es sich um den Start/End-Node des Weges handelt und nicht um diejenigen der Route. Allerdings ist die Routenrichtung bei denjeniden Routen, die diese Rollen verwenden sollen, nicht oder zumindest unzureichend definiert.
Für viele Anwendungen wäre es praktischer, die Richtungen in Bezug auf die Routen-Richtung anzugeben. Dazu müßte man dann natürlich andere Rollen verwenden wie z.B. “normal_route”" und “reverse_route”. Dazu müsste natürlich die Routenrichtung definiert sein. Die Verwendung dieser Rollen würde schon automatisch zu einer Richtungsdefinition für die Route führen, aber in diesem Fall ist die Konsitenz dieser Richtungsdefinition über lange Routen möglicherweise problematisch.
In Nordamerika werden in ähnlicher Weise die Rollen north, south, east, west verwendet, die aber wohl nicht allgemein übertragbar sind, da nur dort ausgeschildert.
Für den Benutzer ist es je nach Arbeitsweise einfacher, Vorgaben in der forward/backward-Form oder der normal_route/reverse_route-Form zu machen. Daher wäre es sinnvoll diese Werte automatisch zu einem Wertepaar wie “forward:reverse_route” als Rolle zu expandieren, sobald dies möglich ist, das heißt sobald die Route intakt ist.
Wenn die Route wieder beschädigt wird, kann diese in der Rolle erfasste Information bei der Korrektur hilfreich sein.
Auch wenn nicht ausgeschildert, kann man jeder linearen Route eine Himmelsrichtung zuordnen. Bei Kreisrouten erhält man mit
“clockwise” und “anticlockwise” eine eindeutige Richtung, unabhängig von irgendwelchen Definitionen.
Auf die Idee mit letzterem war ich nicht gekommen. Sie funktioniert auch nicht immer. Wenn bei einer O-förmigen Linie mit waagrechtem Querstrich in der Mitte an dem Querstrich “forward” steht, dann nützt die Information garnichts, dass der Hinweg von unten nach oben geht.