Hin-/Wegführende Fahrbahnen bei Kreiseln, Routen, Änderung Wiki hierzu

Hallo zusammen

aus dem Feedback zum Thema “Aufräumen von Routen” (https://forum.openstreetmap.org/viewtopic.php?id=63556, danke für die zahlreichen Rückmeldungen dort) möchte ich das Detailthema “Hin-/Wegführende Fahrbahnen bei Kreiseln” extrahieren und separat zur Diskussion stellen. Letztendlich geht es auch um eine Änderung des Wiki, aber ich bin nicht mit den Regularien vertraut wie man so etwas zur Entscheidung bringt und wann man das ändern darf (Hinweise hierzu sind herzlich willkommen). Also erst mal eine Diskussion hier.

Viele Straßen, die in Kreisel münden, werden heutzutage mit Verkehrsinseln versehen, die kurz vor dem Kreisel beginnen und damit getrennte Fahrspuren für die Hin-/Wegfahrt bedeuten. Vielfach sind diese mit komplizierten Fugänger-/Fahrradüberwegen versehen, aber das ist nur am Rande von Bedeutung für diesen Topic. Der Grund, warum das so gebaut ist, ist zumeist Verkehrsberuhigung (auch nicht wichtig für diesen Topic).

Im Wiki (https://wiki.openstreetmap.org/wiki/DE:Tag:junction%3Droundabout) steht hierzu explizit, dass man die Hin-/Wegfahrt getrennt mappen soll, wenn sie getrennt ist. Für Routen bedeutet dies aber erhebliche Komplexität.

Man könnte stattdessen (im Widerspruch zu Wiki) auf die Trennung von Zu- und Abfahrt verzichtet, die Verkehrsinsel als node mit traffic_calming=island oder im Fall eines Überwegs mit highway=crossing, crossing=island modellieren, dann sähe das in der Route sehr simpel aus. Der Vorschlag stammt von jemand anderem, ich weiß aber nicht mehr wer.

In der folgenden Fallunterscheidung wird angenommen, dass eine Straße einen Kreisel passiert, in den sie von Nord einmündet und nach Süden wieder hinausführt. Die Straße nördlich wird “Straße-Nord” genannt, die Straße südlich “Straße-Süd” und wenn getrennte Fahrbahnen für die Richtungen vorliegen, dann heißen die Teile “Straße-X westlich” bzw. Straße-X östlich"

Fall 1.) Kreisel als ein einzelner geschlossener Weg modelliert:

1.1) Dann steht in der Relation bei Wiki-Konformität (Auftrennung Hin-/Rückfahrt):

Straße-Nord
Straße-Nord westlich
Straße-Nord östlich
Kreisel
Straße-Süd westlich
Straße-Süd östlich
Straße Süd

1.2) Bei Nichtauftrennung von Hin-/Wegfahrt sähe das in der Route sehr simpel aus:

Straße Nord
Kreisel
Straße Süd

Fall 2.) Kreisel in separate ways aufgeteilt
Hier ist es unvermeidlich mit der Simplizität zu Ende. Man muss nicht nur auf die richtigen forward/backward roles der Hin-/Wegfahrten achten, sondern auch noch dafür, dass der Kreisel mindestens für die Teile, die von der Straße mitbenutzt werden müssen, geeignete Splittungen von dem nichtbenutzten Rest hat. Man ist also in jedem Fall für die Route im expliziten Handling von forward/backward-Teilen, und ob die Straße selbst dann auch noch beachtet werden muss ist nicht mehr so wichtig, man muss in die Relation einsteigen.

Fall 2.1) Gesplitteter Kreisel, getrennte Fahrbahnen für Hin-/Wegfahrt.

Straße-Nord
Straße-Nord westlich
Kreisel westlich
Straße-Süd westlich
Straße-Nord östlich
Kreisel östlich
Straße-Süd östlich
Straße Süd

Fall 2.2) Gesplitteter Kreisel, eine gemeinsame Fahrbahn für Hin-/Wegfahrt (nicht Wiki-konform).

Straße-Nord
Kreisel westlich
Kreisel östlich
Straße Süd

Ich muss gestehen, dass ich auf den ersten Blick vorschlagen wollte, auf die Auftrennung zugunsten der Einfachheit der Routen zu verzichten (Verkehrsinseln nur als node) und den Wiki zu ändern. Nach etwas Nachdenken glaube ich aber, dass das viele Mapper noch mehr verwirren würde, weil das Modell sich sehr stark vom Satellitenbild oder ihrem local knowledge entfernt. Das sehen die Mapper eher als die abstrakte Route (deren Existenz vermutlich gar nicht allen klar ist). Es wird also nicht durchzuhalten sein, ohne Auftrennung von Hin-/Wegfahrt zu arbeiten. Im Falle von komplizierteren Fuß-/Radwegen und Kreuzungen wird man sowieso splitten. Und zusätzlich: Es wäre die Änderung einer existierenden Regel.

Deshalb möchte ich vorschlagen, in den Wiki explizit aufzunehmen, dass bgei getrennter Hin-/Wegfahrt die Modellierung ohne getrennte Hin-/Wegfahrt und stattdessen mit Insel unerwünscht ist (zumindest bei Änderungen/Neu-Mapping). Grund für diese Festlegung, obwohl Komplexität für Routen erhöht wird: Einheitliches Erscheinungsbild (insbesondere für Unerfahrene); Vermeidung von Diskussion (insbesondere von Diskussion der erfahrenen und damit raren Mapper). Und die existierenden Regeln werden nicht geändert, sondern im Gegenteil präzisiert.

Damit würde Fall 1.1 am häufigsten (zumindest wenn die Entscheidung zur Darstellung von Kreiseln so ausgeht, siehe Topic “Kreisel und Routen, Kreisel in DE:wiki”, https://forum.openstreetmap.org/viewtopic.php?id=63569), Fall 2.1 wird bei komplizierten Kreiseln auftauchen (eher selten).

Eure Meinung?

VG

Bicycle Tourer

Ich verstehe nicht, warum die Rolle

<forward>

gebraucht wird? Ging es nicht um Straßenrelationen?

Es geht um routen (Relationen mit Type=route) für Autos (type=road), Fahrräder (=bicycle), Busse (=bus) und Fußgänger (=hiking). Der Bedarf für forward/backward entsteht, wenn die Route in beiden Richtungen befahren wird und (zumeist wg. Einbahnstraßen) unterschiedliche roads benutzt werden. Es kann in Innenstädten durchaus sein, dass der forward way weit weg vom backward way ist (100m locker, ich kann mir auch 1km vorstellen, ohne ein konkretes Beispiel zu kennen.)

Damit sind Routen für Fahrräder und Routen für Autos betroffen, bei ihnen tritt forward/backward auf. Routen für Fußgänger kennen das nicht, denn Fußgänger berücksichtigen keine Einbahnstraßen. Busse im public transport v2 Schema brauchen es auch nicht, weil die Route immer nur für eine Richtung definiert ist (andere pt-Schemata möchte ich nicht mehr betrachten).

VG

Bicycle Tourer

ja aber warum braucht man Rollen… Bus und Fahrrad müssen sich an die gleichen Regeln halten…

Wenn man die Wegstücke in der Reihenfolgen hinzufügt in der sie benutzt werden hinzufügt in die Relation und diese die mehrmals benutzt werden auch mehrfach hinzufügt… (gibt es auch bei Bus im PTv2) dürfete dann kein Problem entstehen in den man Rollen braucht? Geht meist dann nurnoch mit JOSM als Editor…

Gruß Miche

Wenn eine Route von A nach B geht, dann bedeutet das für Fahrrad oder Auto, dass man diese Route von A nach B, aber auch umgedreht von B nach A befahren kann. Dann kommen all die schönen Themen mit forward/backward.

Wenn die Route von A nach B eine Busroute nach PTv2 ist, dann gilt sie nur für die Richtung A->B. Die Richtung B->A ist (zumindest durch diese Route) nicht definiert. Für B->A gäbe es dann eine zweite Relation. Damit gibt es bei der Busroute nicht das Problem, dass es alternative Straßen zu benutzen gibt für Hin- und Rückweg, denn nur der Hinweg ist beschrieben. Damit kann man vollständig auf Angaben von Rollen verzichten.

Wenn der Bus auf seinem Weg von A nach B jetzt eine Route fährt: A->C->D->C->B, also im laufe seiner Fahrt von C nach D und wieder zurück, dann modelliert man das so, dass die Strecke von C nach D zweimal in der Route ist, nämlich für den Hin- und für den Rückweg. Wenn der Rückweg etwas anders verläuft als der Hinweg (z.B. wg. Einbahnstrassen), dann wird der Rückweg etwas anders gemapped. Damit braucht man auch bei den kompliziertesten Routen kein forward/backward. Gleichzeitig wird aber deutlich, dass die Reihenfolge der Wege in der Relation nicht durcheinandergeraten darf.

VG

Bicycle Tourer

ja da bräuche es zwei Relationen…

Aber ganz ehrlich… mit den Rollen wirst ned froh… da hat sich damals und heute keiner ausgekannt. Selbst ich bei Relationen die ich selbst gemacht hatte…

Relationen sind zum rendern schön und gut… aber Radler braucht dann aber eher ein GPX… kml… oder etwas was er Routen rte-GPX kann… aus eigener Erfahrung . Das aus Relationen zu machen ist eine komplizierte Sache und sehr fehleranfällig

MfG Miche