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

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.

Das war ich auch noch selber :roll_eyes: . Ich muss mal ne ähnliche Stelle suchen und testen

bei mir gibts keine Updates mehr. Das letzte war vor über zwei Monaten :frowning:

Sicher? Bei mir
Germany East 201309150
Germany North 201309160
Germany South 201309240
Germany West 201309010
Achso und ich hab earlymaps eingestellt.

Ich auch, aber die war heute morgen noch nicht da. :slight_smile: Jetzt kann ich mir meine Turn lanes auch mal anschauen

Adresssuche: Schade, dass man nur nach Straßen aber nicht nach Hausnummern suchen kann, so kommt man nie genau ans Ziel sondern eben nur irgendwo auf der Straße raus und darf dann selbst suchen oder muss auf eine andere App umschalten, welche Hausnummern auf OSM-Karten anzeigt. Wirklich schade, denn einige Gegenden sind schon gut mit Hausnummern bestückt. Außerdem quatscht einen die App ganz schön zu, z.B.: “in 2km Ziel erreicht”, “in 1km links abbiegen” und dann noch 3x kurz vor dem bzw. während des Abbiegens. Sowas müßte man fein einstellen können, ganz abschalten ist auch nicht immer eine Lösung, vor allem wenn man sich auf den Verkehr konzentrieren muss und nicht ständig auf das Display schauen möchte. Aber für jedes mal Abbiegen bis zu 4x angequatscht zu werden, … naja? :roll_eyes:

Ansonsten: Eine wirklich gute App zum günstigen Preis :D, die mir endlich auch etwas Nutzen bringt für meine eingegebenen OSM-Daten. Außerdem kann man sich so endlich mal an die Verbesserung von Abbiegerelation etc. machen.

Die Antwort:
The status with lanes is that I asked MapFactor for extra time (2-3days) to make a small progress there (as a work for MapFactor) and I quite soon hit the wall again. I added “blue signposts” on some roads, but immediately saw problems on couple testing examples. Now I see some comments no forum, so I will try to answer all togerther -
done http://forum.mapfactor.com/discussion/comment/4410#Comment_4410 (link durch hurdygurdyman korrigiert)
Extra details - the info about lanes is already “hard coded” in MCA, as a list of “ways”, and if this list matches with your route you will get the display notice. I would like to make the step forward, but I am not sure if I will manage it in time (i.e. October planet).

*thanks for your help & keeping contact with OSM world :slight_smile:
M.
p.s. more difficult problem is with signposts (blue signs, and SunCobalt described now at
http://forum.mapfactor.com/discussion/3683/destinationlanes-issue … I will add comment there soon …)
*

Guggdu http://forum.mapfactor.com/discussion/1315/partially-disable-spoken-messages
oder http://forum.mapfactor.com/discussion/1275/roundabout-messages#Item_7

Zur Adresssuche:
Bei uns mögen Hausnummern recht umfassend erfasst sein, aber wie sieht es im Rest der Welt aus? Deshalb hat man bei MF den Kompromiss gewählt und navigiert zur “Mitte” der Straße und wenn Hausnummern eingepflegt sind, zu den Hausnummernblöcken zwischen abzweigenden Straßen (z.B. 25-33). Ist doch besser als “Kann die Hausnummer nicht finden”.