Navigator 10 free von Mapfactor ... nutzt OSM-Daten

Damit hast du wohl Recht.
Menschen sind wohl doch noch intelligenter als Programme.

Der Fall des ‘verzögerten’ Abbiegens bei getrennten Fahrwegen der Querstraße wird in keiner der “turn” Seiten behandelt und ist wohl bisher nicht bedacht worden. Von daher gibt dafür auch keinen Lösungsansatz.

Ich habe selber keine Idee, wie man die Angabe von turn:lanes und die Markierungen bzw. die Schilder auf/neben der Straße miteinander in Einklang bringen kann. Bei Menschen als Fahrzeugführer wird einfach davon ausgegangen, dass sie die Situation per se richtig interpretieren.

Edbert (EvanE)

Du meinst bestimmt hier oder dort. Das ist mir auch schon so gegangen bei schlechtem Gps-Empfang oder wenn auf Straßen wie in Dippoldiswalde jede einzelne Spur als way gemappt sind.

Also nur das letzte Spurtagging drin lassen, damit es keine Missverständnisse gibt?

Gruß Thomas

Liegt das nun an den ways? Bestimmt nicht, da graphhopper und auch MapQuest richtig routen.

Das ist das was ich testen kann und als Mensch aus der Karte lesen kann.

Und hier wurde mit lanes korrigiert - ist aber als Auto verboten. Oder von B nach Oberbärenburg oder von A nach Altenberg - verboten. Mit den getrennten ways hat es funktioniert - da hat man auch gesehen, dass es getrennte Fahrbahnen sind.

Nein, es liegt am Empfang des Smartphones, weil es nicht 100-prozentig weiß auf welcher Spur er sich befindet und dann erstmal eine Ansage kommt: “Route wird neu berechnet” und er dich von hinten durch die Brust ins Auge schicken will.

Gruß Thomas

Und der Parkplatz nord-östlich der B 170 ist immer noch nicht an das Straßennetz angeschlossen.
Ein Link auf Bing oder auf die OSM-Karte wäre nützlich, um sich diese Situation aus der Ferne ansehen und damit einschätzen zu können.

Gegen falsches Überqueren (der B 170) helfen nur Abbiege-Restriktionen. Also von A zur B 170 restriction=only_right in der Abbiege-Relation. Welche Router Abbiege-Relation beachten und ihren Routing-Graph zügig aktualisieren ist natürlich eine andere Frage.

Edbert (EvanE)

Es ist jetzt einfach mal geändert.
Wenn du in Josm den Map paint style “lane and road atributes” aktivierst, wird die Straße auch entsprechend dargestellt.
rab

Jepp, es kommen dann völlig wirre Ansagen raus, wie “weiter gerade aus fahren”, oder “leicht rechts halten und dann weiter gerade aus”… (weiß gerade nicht ob das wirklich der Navigator war). Aber Ortseingang von Dipps von DD aus ist das schon die Kreuzung die du gefunden hast. Aber das zieht sich durchs die ganze Stadt. Eine normale Straße die als zwei gegenläufige Einbahnstraßen, noch dazu mit separaten Fußwegen die eigentlich an der Straße sind gemappt wurde, ist schon sehr falsch. Ich habe mich an das Chaos noch nicht gewagt. :confused:

Das GPS (mit Glonass) im Note 2 ist schon recht empfindlich, so das u.U. beim Überholen oder auf gerader Strecke die Route spontan neu berechnet wird. :roll_eyes:

lg

Für mich sieht das so aus, als ob Navigator free die fehlende Möglichkeit des Abbiegens in den südl. Teil der Hamburger Straße nicht erkennt oder ignoriert. Da müsste der Algorismus dahingehend geändert werden, dass turn:lanes immer im Bezug auf die nächste Abbiegemöglichkeit in die entsprechende Richtung angezeigt werden.

Eine Änderung unserer Daten, indem wir die turn:lanes südlich der “unteren” Hamburger Straße weglassen, wäre gegen die Realität, die wir ja nun mappen, und ist somit abzulehnen.

Ich habe Mapfactor mal ein Mail deswegen geschickt und gefragt, ob die Programmlogik entsprechend geändert werden kann.

Für uns Menschen ist bei obiger Kreuzung alles klar, da wir sie als eine Einheit wahrnehmen. Allerdings wird dieser Zusammenhang durch unsere Mapping-Praxis aufgelöst, sobald wir getrennte Richtungsfahrbahnen verwenden. Von daher ist es für Routing-Programme schwierig, solche Situationen im Sinne der menschlichen Wahrnehmung zu interpretieren.

Es wäre natürlich wünschenswert, wenn Routing-Programme diese Situation wie ein Mensch interpretieren könnte. Allerdings stellt sich die Frage, wie ein Routing-Programm die Situation Großkreuzung bei getrennten Richtungsfahrbahnen erkennen kann, da wir in der OSM Daten-Realität diesen Zusammenhang durch getrennte OSM-Wege ja gerade aufgelöst haben.

Es stellt sich nun die Frage, ob wir für die Realität dort draußen unsere Daten erfassen, oder ob wir unser Lanes-Tagging an der Realität, wie sie durch die OSM-Daten gegeben ist, ausrichten. Solange wir große Kreuzungen nicht auf eine allseits akzeptierten Weise als eine Einheit abbilden können, würde ich zweiteres vorschlagen.

Edbert (EvanE)

Vielen Dank dafür.

Dann bleibt es erstmal wie es ist, ist ja bestimmt nicht die einzige Kreuzung. Hoffen wir mal das Mapfactor das hinkriegt. Ist das bei OSMAnd eigentlich besser gelöst?

Wie meinste das jetzt?

Gruß Thomas

Auch wenn ich eim Fan dieser Routing-Software bin: Ich lehne es ab, Ausnahmen vom Erfassen der Realität auch in diesem Fall zuzulassen. Durchgängige Eigenschaften von getrennten Wegstücken muss eine Auswertung wieder zusammensetzen können. Außerdem wäre bei deinem Vorschlag das verbleibende turn:lanes viel zu kurz, um noch mit Spurwechsel reagieren zu können.
Warten wir doch ab, ob Mapfactor das lösen kann.
Unabhängig davon kann man ja schon mal nachdenken, ob ein Zusatz-Tag oder eine Relation in diesen Fällen helfen könnte.

Hallo Thomas

Das Problem ist darin begründet, dass ein Mensch eine Kreuzung als eine Einheit wahrnimmt. Die Daten bei OSM enthalten bei getrennten Richtungsfahrbahnen diese Einheit als ein Objekt Kreuzung nicht mehr. Daraus resultieren die Probleme.

Es gibt nun drei Mögliche Ansätze für eine Lösung:

  • Ein allseits akzeptiertes Konzept für einen Kreuzungsbereich in OSM einführen.
    Ansätze dazu gibt es, allerdings hat sich (geringe Akzeptanz!) noch nichts durchgesetzt.
    Durch turn:lanes=* gibt es jetzt ein Problem, das von einer Lösung real profitieren würde.
  • Routing-Programme müssen aus den vorhandenen OSM-Daten Kreuzungsbereiche
    selber finden. Das dürfte sehr schwierig sein und ob Programm-Autoren sich auf dieses
    unklare Gebiet begeben, ist durchaus fraglich. (Mit Punkt 1 sähe das evtl. anders aus)
  • Wir passen unser Lanes-Tagging an die in OSM existierende Datenstruktur an.
    Sprich, wir erledigen die Arbeit bei Kreuzungen mit getrennten Richtungsfahrbahnen
    das Lane-Tagging so zu gestalten, dass ein Router bessere Spur-Hinweise erzeugen kann.

Punkt drei meinte ich mit der zitierten Aussage.
Klar wäre Punkt 2 in Verbindung mit Punkt 1 die bessere Lösung, aber das wird noch lange dauern.
Von daher ist Punkt drei in der reinen Lehre unschön, aber lässt sich heute ohne weitere Voraussetzungen realisieren.

Edbert (EvanE)

Muss ein Router nicht aber so oder so den Zusammenhang zwischen Zufahrt und dem Teilstück innerhalb der Kreuzung herstellen? Angenommen man würde das so wie von Dir vorgeschlagen taggen und möchte dann z.B. nicht links abbiegen, sondern geradeaus fahren. Der Router würde mich dann doch möglicherweise erst auf die rechte Spur lotsen, wenn es schon viel zu spät ist, nämlich im Kreuzungsbereich selbst, oder?

Was ist denn genau die Realität für Linksabbiegen im Falle von getrennten Richtungsfahrbahnen?

  • Die Markierung auf der Straße / das Schild neben der Straße?
  • Die Tatsache, dass man am ersten Kreuzungspunkt nicht gegen die
    Einbahnstraße links abbiegen darf, also gerade aus fahren muss?

Wie gesagt, die Verkehrsteilnehmer betrachten eine Kreuzung als eine Einheit, In den OSM-Daten existiert bei getrennten Fahrbahnen dieses Einheit schlicht nicht mehr.

Da wir die Gesamtheit einer Kreuzung nicht als eine Einheit in unseren Daten haben, sollten wir nach meiner Meinung das Lanes-Tagging der Abbildung in den OSM-Daten anpassen.

PS:
Eine Möglichkeit zur Lösung des Problems, die ich noch nicht erwähnt hatte, wäre es, bei den turn:lanes Werte für ‘verzögertes’ Abbiegen einzuführen. Die Angabe bezieht sich nicht auf den nächsten Kreuzungspunkt sondern erst auf den übernächsten. Keine Ahnung wie man das nennen soll. Etwas wie left_postponed käme mir in den Sinn, aber bei den Werte-Namen bin ich flexibel.

Edbert (EvanE)

Richtig und falsch zugleich.
Das augenblickliche Problem beruht gerade darauf, dass aus Sicht des Routers die beiden linken Spuren erst im Kreuzungsbereich laut den OSM-Daten für die geplanten Route geeignet sind. Sagt man vor der Kreuzung “Alle Spuren geradeaus”, dann kann man schon vorab die zwei ‘günstigen’ Spuren auswählen. Umgekehrt gilt das für den Fall der Geradeausfahrt genauso.

Inwieweit Router Spurvorschläge über mehrere Kreuzungspunkte optimieren (oder vielleicht auch nicht), dazu habe ich keine Erkenntnisse. Insoweit wäre ein Wert für “später links abbiegen” wahrscheinlich eine gute Lösung.

Edbert (EvanE)

Da man wohl davon ausgehen kann das die Strassenbauer keine Idioten sind, wuerde ich mal annehmen das es (nahezu) keine Faelle gibt wo Linksabbiegerspuren existieren die einem direkt entgegen einer Einbahnstrasse (oder sonstwie unerlaubte) Einfahrt leiten. Man duerfte also nahzu 100% richtig liegen wenn man die Links(und Rechts)abbiegerspuren dahin interpretiert das sie fuer die naechste erlaubte Abbiegung gilt. (Wenn dann ist es wohl eher das sie fuer die uebernaechste erlaubte Abbiegung gelten als fuer eine nicht erlaubte)

Insofern muss man zwar im Konvertierungsprogram diese Faelle wohl separat behandeln (mit mir unbekannten Aufwand fuer den Programmierer), es sollte aber kein Fall sein das es uneindeutig waere und man “menschliche Intelligenz” dafuer benoetigen wuerde. Man braucht auch keine Grosskreuzungen erkennen. Diese Inteligenz und Uebersicht duerfte der Strassenbauer fuer einem gehabt haben.

Also wenn man jetzt (nur weil ein Navi noch nicht schlau genug ist) das Tagging ändert, dann kann man den OSM
Spurassistenten wohl vergessen.

Du hast ja aus deiner menschlichen Sicht völlig Recht.
Aber, das in Algorithmen für Programme zu gießen, ist ein ganz andere - wahrscheinlich nicht triviale - Frage.

Es ist immer leicht (sinnvolle) Forderungen zu stellen, die andere letztlich realisieren müss(t)en. Von daher sollte man sich schon fragen, ob es nicht andere Lösungen gibt, die man selber realisieren kann. Ich habe ja mehrere Ansätze dafür beschrieben.

Edbert (EvanE)

Ich habe auch nachgedacht. Mein Ansatz:
relation=restriction
restriction=only_left_turn
from=40550100 (way)
via=25841643 (way)
to=150287843 (way)
Für das obige Beispiel aus Dresden: http://www.openstreetmap.org/#map=19/51.06153/13.69004
Router könnte so klar erkennen, auf welchen abgehenden Weg sich die entsprechenden turn:lanes beziehen.

So könnte man auch Fallen Fälle wie diese http://www.openstreetmap.org/#map=19/48.33386/7.82718 lösen, in denen eine Abbiegespur vor einer Brücke beginnt und erst hinter der Brücke endet, weshalb die turn:lanes-tags auf drei Teil-ways liegen müssen. Gemäß Wiki sind ja mehrere via-ways möglich: http://wiki.openstreetmap.org/wiki/DE:Relation:restriction#Mindestanforderung

P.S.: Eigentlich darf im Dresdener Beispiel so gar nicht gefahren werden, da auf der Kreuzung deutliche Markierungen für eine diagonale Führung des Verkehrs erkennbar sind. Auch hierfür könnte ich mir eine Lösung vorstellen, die aber die Einführung eines neuen “unsichtbaren” Verbindungsweges (nenne ihn mal “junction=via”) bedingt.
und:
Diese lanes-Diskussion geht weit über den Thread-Titel hinaus und gehört eigentlich in den spurmapping-thread http://forum.openstreetmap.org/viewtopic.php?id=14710 , aber dazu ist es wohl zu spät :roll_eyes:

Gerade habe ich mal die history von way 25841643 gecheckt: http://www.openstreetmap.org/browse/way/25841643/history
:schuppen_von den_augen_fallen:
Die turn:lanes wurden erst am 17.09. ergänzt. Da meines Wissens Mapfactor den Planet immer am Monatsanfang zieht, um dann die Daten zu bearbeiten und gegen Monatsende in ihrem Kartenformat zu veröffentlichen, muss die Abbiegeinformation in deren Datenbasis an diesem Weg fehlen. Somit kann der Router den Bezug für das Abbiegen nicht auf den tatsächlich gemeinten Zielweg herstellen.