Kreuzende Fahrbahnen ohne gemeinsamen Node

Hallo,

Ich repariere grade die (einfacheren) Restriction Relations aus dem Relation Check von Gary68 und bin da auf diese Kreuzung(en) gestoßen (Line 193 im aktuellen Relation Check):
http://www.openstreetmap.org/?minlon=7.8447624&minlat=47.9907935&maxlon=7.845057&maxlat=47.9908537

Hier kreuzen viele Fahrspuren andere Fahrspuren, in die man sowieso nicht einbiegen darf, ohne gemeinsamen Node (keine Brücke, kein Tunnel), aber dort steht wohl ein only_straight_on-Verkehrszeichen für das Überqueren mehrerer Fahrspuren - deshalb diese Relation.

Sollten hier noch gemeinsame Nodes eingefügt werden und dann für jeden Node ein eigenes Verkehrszeichen, wo nicht abgebogen werden darf oder lieber, wenn man zwei Spuren kreuzt, den ganzen Way zwischen diesen Spuren als via verwenden - wie es ja beim no_u_turn erlaubt ist? Sonst entstehen hier mehr Verkehrszeichen in der Karte, als am Straßenrand stehen.

Gruß,
Franz

Also, wenn es eine richtige Kreuzung ist, und man theoretisch abbiegen kann, dann braucht es auch gemeinsame Nodes. Was man dann tatsächlich darf, regelt dann die Relation. Ohne gemeinsamen Node kann man ja auch garnicht die Relation ordentlich eintragen (from, via, to).

Außerdem ist es ja Fußgängern sicherlich möglich dort abzubiegen, oder?

Wenn sich die Fahrspuren auf gleicher Höhe kreuzen, man also rein theoretisch ohne Beachtung von Schildern, Pfeilen, dem Verkehr, etc. dort abbiegen/wechseln könnte, sollte meiner Meinung nach ein gemeinsamer Node eingezeichnet sein (sehe ich also genauso wie aighes). Dies führt zumeist tatsächlich dazu, dass fast inflationär viele Restriktionen notwendig werden. Zum Erstellen der from/via/to-Elemente müssen die einzelnen Fahrspuren im Regelfall zusätzlich noch an den gemeinsamen Nodes geteilt werden.

Ein Beispiel: bei in OSM getrennt eingezeichnenten Rechts-, Geradeaus- und Linksabbiegerspuren braucht man z.B. bei der Geradeausspur beim Kreuzen des Querverkehrs von links eine “only_straight_on”-Relation, beim Kreuzen der anderen Querverkehrs auch, usw. Trotz dieses Aufwandes würde ich die Lösung mit gemeinsamen Nodes wählen.

Die Restriktionen geben das wieder, was die Verkehrsregeln/-zeichen aussagen (und die “Pfeile” auf den Fahrspuren, ich habe deren offizielle Bezeichnung gerade vergessen. Fahrtrichtungsanzeiger? Sind jene rechtlich auch direkt unter den Verkehrszeichen eingruppiert? Oder haben sie irgendeine extra “Bezeichnungsgruppe”?). Bevor man die Restriktionen einträgt, sollte man noch einmal prüfen, ob dort an den Fahrspuren, wo erforderlich, auch “oneway” ergänzt worden ist. Denn Verkehr entgegen der Fahrtrichtung ist natürlich automatisch verboten.

Meiner Meinung nach müssen Restriktionen auch nicht immer nur durch Verkehrszeichen bedingt sein, sondern es kann andere, z.B. straßenbauliche Gründe geben, welche das Ergänzen einer Restriktion sinnvoll machen, da sonst in OpenStreetMap etwas möglich wäre, was real nicht machbar ist.

Interessant würde es sicher werden, wenn man auch noch die Radwege (cycleway=yes oder am besten cycleway=opposite) berücksichtigen wollte. Aber jene muss man bei den Restriktionen wohl außen vor lassen, damit es überhaupt umsetzbar bleibt (meine ich, obwohl ich selbst mehr Rad als Auto fahre).

Haha
Bei dieser Kreuzung habe ich auch kapituliert, da kann ich dem Straßenverlauf nichtmal im Editor folgen.
Da bastele ich lieber weiter an den Grenzrelationsfehlern rum :slight_smile:

Es gibt noch so eine “schlimme” Kreuzung :
http://www.openstreetmap.org/?lat=51.19109&lon=6.442388&zoom=18&layers=B000FTFT&relation=174672

Matthias

Hallo Matthias

Ein typisches Beispiel, bei dem man klar die Notwendigkeit von
highway=service + service=junction
sieht.

Aber das gibt es nicht.

Edbert (EvanE)

Damit es dünner gemalt wird, oder wieso?
chris

Ich denke, die vom OP bezeichnete Freiburger Kreuzung könnte man mit den vorhandenen Möglichkeiten reparieren, ohne auf neue Konstrukte wie service=junction zurückgreifen zu müssen. Notwendig wäre ein wenig Abstraktion: Nicht überall, wo man Fahrspuren für verschiedene Richtungen hat, muss man gleich dafür verschiedene Ways einzeichnen. Wenn man überall, wo es vertretbar ist, ways zusammenlegt, reduziert sich auch die Anzahl der Kreuzungspunkte dramatisch, und man kann sie ohne weiteres alle explizit setzen. Ich würde vorschlagen, wenn hier Freiburger mitlesen, dass einer von ihnen sich meldet und erklärt, dass er die Kreuzung bereinigt. So wie sie ist kann sie jedenfalls nicht bleiben.

Karl

Hallo chris

Das wäre ein (durchaus erwünschter) Nebeneffekt.
Der entspricht in vielen Fällen ja auch der Realität

  • Zwei Spuren für Geradeaus (1x je Richtung)
  • Eine Spur für die Rechtsabbieger

Der wirkliche Grund, ist die Überlegung, dass so eine Abbiegespur eigentlich
nicht dem Status der Straße entspricht, sondern eher vergleichbar ist z.B. zu
einem highway=service für die Zufahrt zu einem Grundstücken/Parkplatz, …

Ein weiterer erwünschter Effekt ist, dass man nicht mehr winzige Straßenstücke
mit einem Namen versehen muss, nur weil die zugrundeliegende Straße einen
Namen erfordert. In der Realität haben die Abbiegespuren bzw. der geasmte
Kreuzungsbereich keinen zugewiesen Namen.
Es heißt einfach Kreuzung der Straße A mit der Straße B.

Für motorway, trunk, primary und secondary ist durch *_link eine ähnliche
Konstruktion ja bereits eingeführt. Insofern wäre highway=link vielleicht der
bessere Begriff für alle anderen Straßen.

Edbert (EvanE)

Hallo Karl

Bei dem Beispiel aus Freiburg wäre eher highway=primary_link angebracht.
An dem Knäuel, das die Renderer produzieren, würde das aber wenig ändern.
— Zoomlevel=19 NOW! (SCNR)

Du hast natürlich Recht mit deiner Bemerkung, dass so eine Kreuzung
besser vereinfacht dargestellt wird. G* und Y* machen das so.

Ein schönes Beispiel aus Bonn:
http://www.openstreetmap.org/?lat=50.690617&lon=7.148953&zoom=18&layers=B000FTF

Um das zu verstehen, muss man sich klar machen, dass dort drei Ebenen mit
Straßen, eine Ebene für die Stadtbahn plus eine Ebene für die Eisenbahn sind.
Ein paar Stadtteil-Grenzen sind auch noch dazwischen.

Edbert (EvanE)