Geometrieänderungen wegen fehlerhafter "destination"-Auswertung

Hallo zusammen,

@9ix begründet die Geometrieänderungen damit, dass das “destination”-Tagging sonst nicht funktioniert. Kann das jemand bestätigen?

U.a. geht es um diese Kreuzung: OpenStreetMap. Vorher trafen beide Richtungsspuren der Schleidener Straße (K 2) im rechten Winkel auf die Hauptstraße (B 258).

Ein anderer Fall ist OpenStreetMap, wo nun ein geradeausfahren aus der Straße Perlenau in die Monschauer Straße (B 399) nahezu unmöglich gemacht wurde.

Gruß

1 Like

Also - Das destination tag wird dann genutzt wenn eine Navigation eine “Ansage” oder “Anzeige” macht über einen Abbiegevorgang.

“Biegen sie in 100m nach links ab Richtung: Dortmund”

Da kommt das Dortmund aus dem destination tag. Das muss dann auf der Straße sein in die abgebogen wird.

Wenn die Straßen einen so spitzen Winkel haben das keine Ansage kommt (Also eher so “Geradeaus”) dann kommt keine Ansage, dementsprechend wird auch das Destination tag nicht ausgewertet. IMHO macht das destination tag da dann auch keinen Sinn.

Flo

1 Like

Insofern käme möglicherweise bei Way: ‪Sankt-Vither-Straße‬ (‪537821265‬) | OpenStreetMap auch keine Ansage mehr, weil man von Norden kommend sich “nur” links halten muss und nicht wirklich abbiegt.

Ich verstehe nicht, was da vorher nicht funktioniert haben soll. Wenn schon die K2 splitten, dann 2x im rechten Winkel direkt auf auf die B 258. OSMR und Graphopper haben noch das alte Routing und das sieht bestens aus. Alles andere ist noch nicht mal Fahrspurmapping sondern Fahrwegmapping. Ein bischen abstrahieren darf man schon!

Solche Kreuzungen finde ich immer extrem schwierig auch geometrisch abzubilden. Im Zweifel hätte ich auf die Aufteilung der Monschauer Str. verzichtet und traffic_island nur als Punkt gesetzt.

Btw: Diese Rechtsabbiegerspur kann m.E. nur secondary_link sein.

So war es auch vorher. Wenn ich sehe wie nun Valhalla dort routet… :roll_eyes:

Vorher lief die Straße Perlenau relativ mittig auf die Trennung zu. Sieht man noch bei GraphHopper und OSRM.

Naja, unter Tag:highway=primary_link - OpenStreetMap Wiki steht:

Therefore, highway=primary_link should be used on a slip road/ramp which connects a highway=primary to a secondary, tertiary, or other minor highway.

6 posts were split to a new topic: *_link höhere oder niedrigere Straßenklassifikation (konkretes Beispiel)

+1, und es ist schlicht und einfach falsch, weil es sich nicht um eine baulich separierte Rechtsabbiegerampe handelt. Zurückbauen und den Kollegen um ein Beispiel bitten, was genau denn an der rechtwinkligen Version nicht funktionieren soll. Ich kann es mir nämlich auch nicht vorstellen. Wenn die Winkel zu flach werden, dann kann es, wie @flohoff schon schrieb, passieren, dass das Navi darin gar keine Abbiegung mehr sieht, sondern es als geradeaus interpretiert. Aber aus 90° Abbiegewinkel sollte nun wirklich auch das dümmste Navi eine Abbiegung erkennen.

2 Likes

Ist ja noch schöner: Die im fraglichen Edit eingebauten Y-Zweige der Schleidener Straße tragen überhaupt kein destination-Tagging. Nur die Bundesstraße hat das. Was soll sich da durch die Verzweigung ändern?

2 Likes

Die erste Kreuzung geht gar nicht, weil hier eine bauliche Trennung vorgegaukelt wird, die es nicht gibt. Ich kann mir auch nicht vorstellen, dass die aktuelle Version irgendeinen Vorteil für’s Routing bringt.
Den aktuellen Zustand:


… würde ich wie folgt ändern:

(und dabei auch am rechten Bildrand die Fahrbahnauftrennung auch ein wenig verkürzen, da nicht die aufgemalten Linien hierfür ausschlaggebend sind sondern die Verkehrsinsel.

Die zweite Kreuzung hält sich wenigstens an die tatsächliche bauliche Trennung, ist aber meiner Meinung nach auch nicht optimal getaggt:


Dieser Nachteil:

lässt sich mit etwas gutem Willen beheben, ohne:

Ich würde diese Kreuzung so modelieren:

5 Likes

Wie gesagt: So waren die Kreuzungen vorher auch gemappt.

1 Like

Wobei der Abbiegewinkel von Süd nach Ost hier schon der Gipfel der Gefühle ist. Ich versuche nie über 90° rauszugehen (außer der tatsächliche Abbiegewinkel ist eindeutig auch überspitz) und verschiebe dafür lieber die Ways etwas. Es braucht niemanden zu stören, wenn die Ways nicht exakt in der Straßenmitte liegen, sondern zwei Meter daneben, wenn dadurch die Geometrie besser abgebildet wird.

Konkret: Den zentralen Kreuzungsnode noch 1 bis 2 Meter nach Osten, dann hättest du mein Modell, und es wäre rechtwinklig :slight_smile:

Das hatten wir ja schon an diversen stellen. ich halte das zusammenführen der wege um die Verkehrsinsel um wieder sich in einem Punkt zu treffen für falsch. Das entspricht einfach nicht der realität.

Es gibt nicht “einen exakten punkt” über den jeglicher Verkehr läuft.

Realistisch müsste man den nördlichen Weg noch aufsplitten für die letzten 3m - So mache ich sowas - Ich finde diese variante das wie eine Pflaume um die Verkehrsinsel zu führen einfach maximal hässlich.

Flo

Was entspricht da denn nicht der Realität, wenn wir Flächen in Linien und Punkten darstellen?

Doch, der Punkt stellt die Kreuzung dar.

Das entspricht eben nicht der Realität, der nördliche Weg eben keine bauliche Trennung hat und somit bis zur Kreuzung als eine Linie dargestellt werden sollte.

Das ist doch Aufgabe des Renderes.

Ich verweise, mal wieder auf placement=*.
Vor nicht all zu langer Zeit, gab es auch einen Vorschlag die “falschen Winkel” am Kreuzungspunkt mit einem neuen Tag festzuhalten. Finde auf die Schnelle leider nicht den Faden und den entsprechenden Beitrag.

2 Likes

“Die Kreuzung” ist das sammelsorium aller elemente die Dazu gehören. Wie “Die Straße” zu der eben die Fahrbahn aber eben auch der Bürgersteig gehört.

Dann mach mal eine statistische Analyse WO die Autos fahren. Als Heatmap darstellen und dann siehst du das DAS die Realität ist.

Der renderer arbeiten nach dem Prinzip “Shit in, Shit out” .

Wenn man also Daten, warum auch immer, vergewaltigt und da solche Eier oder Pflaumen reinphantasiert dann kann der Renderer da auch nichts mehr machen.

Das ist das dingen mit der Tangente an einen Punkt konstruieren.

Flo

nichts anderes hat @skyper geschrieben

Dann mach mal!
Dann ist aber auch die

Realität.
Ebenso ist dann auch diese Variante Realität:

Genau, wenn jetzt keine bauliche Trennung vorliegt ist das ein Punkt in OSM, solange Trottoirs nicht separat eingetragen sind.

Dafür brauche ich keine Heatmap. Schon mein Verstand sagt mir, dass ich beim Linksabbiegen keine Schlenker vor (von Norden) oder nach (von Westen) der Kreuzung mache.

Dies Aussage höre ich von Dir öfter und sie ist zu einfach. Meist ist der Renderer das Problem, da eben nicht alle Information, wie z.B. placement=* oder die type=connectivity-Relationen verwendet werden. Von area:highway=* mal ganz abgesehen.

Deine Formulierung finde ich sehr unpassend. Wenn dann biegen wir hier Daten zurecht, vergewaltigen ist ein anderes Thema.
Deine Variante ist in dieser Sicht noch schlechter oder wie stellst Du dar, dass an dieser Stelle keine baulich Trennung vorliegt? Wie trägst Du dann die Breite der Straße ein? Wie stellst Du dar, dass Schwertransporter die gesamte Fläche zum Abbiegen verwenden können? …

@skyper: Du verteidigst das “Pflaumen-Mapping” mit der Tatsache, dass sich die um die Insel führenden Ways auf der Kreuzung ja wieder ohne bauliche Trennung treffen.

Stimmt, das machen sie.

Aber heißt das nicht, dass wir alle Kreuzungen, die an allen vier Enden Inseln haben, so mappen müssten, weil die sich ja alle auf der Kreuzung ohne bauliche Trennung treffen?

Das kanns nicht sein, oder? Bei so einer Kreuzung abstrahieren wir und führen die Geradeausspuren separat über die Kreuzung, damit gerade Wege gerade bleiben (übrigens auch ein OSM-Grundsatz).

Ich finde schon, es spricht einiges dafür, eine Einmündung als eine Hälfte so einer Kreuzung aufzufassen und die Separierung der Ways entsprechend zu abstrahieren.

5 Likes

Aeh doch - Er sagt “der eine node” ist “Die Kreuzung” - Und nein. Das ist falsch. Es gibt auf den allermeisten Kreuzungen mehrere Kreuzungspunkte der Fahrspuren/Fahrbahnen.

Es gibt nicht diese eine Wahrheit die da reklamiert wird.

Und deshalb sagt ich - Wenn man sich die Bewegungen auf der Kreuzung als ganzes in einer Heatmap ansieht kommt “der eine node” überhaupt nicht vor. Der liegt abseits der statistischen Bewegungen.

Dadurch ist er eben falsch in der realität.

Flo

Das Problem hier ist das es quasi nirgends zu wirklichen “Abbiegevorgängen” kommt weil alles weichgewaschene Winkel sind.

Keine Ansagen im routing, keine destination tags. Alles vergebene Liebesmühe.

Dafür jede menge falsche ansagen bei der Geradeausfahrt von “Links halten” “Rechts halten” obwohl es geradeaus geht.

Ist kaputt.

Flo

Du verwechselt da was.

Die Aussage ist: “Was getrennt ist sollte getrennt gemapped werden”. Eine Aussage bei OSM über das mapping von nicht baulich getrenntem gibt es nicht.

Und hier ist das im sinne der Abstraktion wichtig das getrennt zu mappen auf den letzten 3 Metern weil ansonsten die ansagen im Routing maximal falsch und verwirrend sind.

Flo