Both_ways aufgelöst

Gestern abend fiel mir an der B 3 zwischen Marburg und Kassel so was auf: Way: ‪B 3‬ (‪431071406‬) | OpenStreetMap

Auf dem kurzen Stück B 3 zwischen den zwei kreuzenden Ärmchen teilen sich die Linksabbieger aus beiden Richtungen die mittlere Spur (und biegen real natürlich voreinander ab). Das habe ich bislang mit both_ways getaggt, und auch hier war das vor der letzten Bearbeitung so. Dann wurde das both_ways aufgelöst in zwei halb lange Linksabbiegespuren, die demnach nicht mehr ganz an ihren Abbiege-Node heranreichen. Im CS wird als Quelle “Hinweis in Geofabrik OSM Inspector” genannt.

Ist dieses Mapping so üblich, oder wurde hier einfach nur eine Fehlermeldung dieses Inspectors “weggetaggt”? Datenlogisch finde ich persönlich es am “richtigsten”, eine Linksabbiegespur bis an den Abbiege-Node zu führen und in solchen Fällen both_ways zu nutzen. Denn so, wie es jetzt gemappt ist, muss der Router davon ausgehen, dass Linksabbieger kurz vor dem Abbiegevorgang nochmal auf die ganz rechte Spur wechseln müssen (wegen lanes:*=1). Was schlicht falsch ist. Auch wenn real schon vor dem Node abgebogen wird, um dem Gegenverkehr Platz zu lassen. Ersatzweise könnte man kurze schräge Abbiegeways ergänzen, aber auch das wäre nicht ganz richtig …

Was mir spontan einfällt ist das das “falsch” ist. Physisch enden die beiden Spuren voreinander.

Ich habe da gerade nochmal nach gegoogelt. Bis 1992 sind wir ja beim links abbiegen umeinander abgebogen. Da wäre es ja fast richtig wenn die spuren umeinander herum gehen.

Seit 1992 gibts das nicht mehr. Damit enden die Spuren “Kopf-an-Kopf” und die Fahrzeuge biegen voreinander ab.

Aber nur so aus dem Gefühl.

Flo

FraukeLeo, ich sehe die aktuelle Lösung auch als problematisch an. Denn sie entspricht nicht der Realität.

Entweder endet die Linksabbiegespur dort, wo die Markierungen aufhören, also an den Haltelinien. So sehe ich das bislang und tagge den unmarkierten Abschnitt im Kreuzungsbereich ohne jegliche Spurangaben (es gibt ja hier auch keine markierten Fahrspuren). Aber damit sind wir bei einem anderen Thema, zu dem es noch keinen Konsens gibt: Was sind lanes? Sind damit ausschließlich markierte Fahrspurgen gemeint oder wird auch in Bereichen, in denen keine Fahrspuren markiert sind, mit lanes-Werten gearbeitet, was zu anderen Konflikten führt. Innerorts wird inzwischen bei vielen Straßen, die breit genug für Begegnungsverkehr sind, auf die Markierung von Fahrspuren verzichtet. Man könnte solche Straßen also mit lanes=2 taggen. Doch ab welcher Breite ist eine solche Straße tatsächlich mit dem Wert lanes=2 zu versehen? Müssen dazu zwei LKW mit ordentlich Abstand aneinander vorbeikommen? Vor allem bei Wohngebietsstraßen ändert sich die Breite der Straße zudem oft mehrfach. Dort immer wieder wechseln von lanes=1 auf lanes= 2 und wieder auf lanes=1, oder vielleicht auf einem besonders breitem Abschnitt auch lanes=3? Jedoch was von der Fahrbahnbreite ist dann tatsächlich als Fahrspur anzusehen und was als Parkraum? Ich würde es daher sehr begrüßen, man würde sich darauf einigen, dass sich lanes ausschließlich auf markierte Fahrspurgen bezieht und alles andere über width abbilden.

Veranschaulichung der von mir favorisierten Handhabung:

Oder die Linksabbiegespur endet dort, wor die abzweigende Straße beginnt, womit man dann bei der Lösung wäre, die Du bislang gehandhabt hattest mit “both”. Denn der Abbiegende springt ja nicht von der Kreuzungsmitte aus bis zu dem Punkt, an dem die abzweigende Straßenlinie beginnt:

Wollte man demnach die Abbiegesituation unter Vermeindung eines Abschnitts, in dem es entweder keine lanes-Angabe gibt oder ohne die Verwendung eines both-Wertes arbeiten, müsste man an den Straßenlinien rumpfuschen:
Firefox_Screenshot_2023-12-31T09-42-34.250Z
oder


… aber es gibt gute Gründe, das nicht zu tun.

Das sehe ich auch so. :+1:

Ich will mich gar nicht auf eine Position festlegen, mir gehts um Klärung :slight_smile: Bis jetzt habe ich immer die Abbiegespuren weiter"gedacht" bis zum Abbiege-Node und so getaggt. Das scheint mir “datenlogisch” richtiger, denn man biegt ja von der Abbiegespur aus auf die neue Straße ab, und in den Daten erfolgt die Abbiegung über den fraglichen Node, auch wenn man tatsächlich anders fährt. Aber die Lösung “nur da lanes taggen, wo auch wirklich welche aufgemalt sind” klingt auch nicht falsch :slight_smile:

1 Like

Datentechnisch korrekt ist es das zu erfassen, was in der Realität vorhanden ist. Hier sind es die Fahrspurmarkierungen. Wo keine Markierungen sind sollten auch keine “herbei interpoliert” werden. Sowas führt dann zu solchen Diskussionen. Jede:r hat da eigene Vorstellungen.

1 Like

Nachdem wir die Straßen abstrakt auf eine Linie “verengen” müssen wir die lanes analog abstrahieren. (sonst sind wir am luftbildkopieren.) Sprich: ja, Dein Weg ist vom Grundsatz her richtig und ich würde zur Version 2 von Galbinus neigen.

Was die Haltelinien betrifft: Die kann man unabhängig davon erfassen (wenn man unbedingt will: https://wiki.openstreetmap.org/wiki/Key:road_marking ). [Sarkasmus ein] Persönlich vermisse ich das aber wirklich nicht und kann mir höchstens eine Anwendung vorstellen, die versucht ein Luftbild nachzumalen - anstatt eines zu nutzen :speak_no_evil: [Sarkasmus aus]

Und für das Zwischenstück “lanes:both_ways” zu nutzen klingt zwar interessant, hat aber den datenlogischen Fehler, dass (z.B.) der Autofahrer, der von Osten kommend nach Süden abbiegt keinesfalls zwei weiterführende Spuren nach Süden vorfindet :scream: Damit ist etwas ganz anderes gemeint. Gibt es in den USA öfter ( File:Jewel Lake Road looking south towards Strawberry Road, Anchorage, Alaska.jpg - OpenStreetMap Wiki ), bei uns seltener ( z. B. Way: ‪Leyher Straße‬ (‪488483721‬) | OpenStreetMap )
Kreuzungsgeometrien in allen Details zu erfassen ist bei gleichzeitiger Abstraktion schlicht nicht möglich. Irgendeinen Tod muss man sterben: Bei o. g. Version 3 müsste man die Verkehrsinseln an Stelle der getrennten Fahrspuren erfassen. Sonst stimmen zum Beispiel die Abbiegewinkel gar nicht mehr mit der Realität überein.