Für Routing optimieren?

Offtopic: Für seltene Fälle uneindeutiger Geometrien der Einbahn Abbiegeverläufe wo man aber eindeutige Ansage braucht gibt es (nicht in der OSM) spezielle Punkte die diese Ansage beinhalten. Ist so ein Punkt vorhanden, wird die Geometrie/Kurvigkeit etc nicht untersucht. Die Angabe an einem solchen Punkt hat den Vorrang.

Ja, hab ich mir schon gedacht, dass die Profis mit solchen Hints arbeiten.

Nach und nach ist auch OSM ein Profi Projekt… :wink: Überleg mal wie sowas in OSM aussehen könnte…
Und klar - es wäre ein klarer Fall vom Mappen für den Routing :slight_smile:

Da gab es auf der SOTM in Japan einen Vortrag von Leuten von Bosch, die Routing betreiben und gerne solches Tagging hätten. Stichwort “Complex Junctions”.

Na, dann werde ich nicht erschossen für den Verrat wichtiger Betriebsgeheimnisse. :smiley:
Wenn die Katze also aus dem Sack ist, könnten wir auch dieses Thema anpacken.
So kompliziert ist es auch nicht.

Das mit dem Punkt ist ja schön und gut, nur denke ich, dass es nicht Sinn und Zweck von OSM ist, der Navi-Industrie blind hinterher zu dackeln. Es ist nun mal der komplette Weg, der die Auffahrt mit der direction bildet. Diesen sollte man so auch taggen. Wenn nun ein Auswerter meint, nur einen Punkt zu brauchen, ist es ein leichtes, einen Punkt des Weges zu wählen und die Tags entsprechend zu setzen.

Stimmt ja auch. Das Wichtigste ist der allgemeine Mehrwert einer Lösung.
Es bleibt zu prüfen welche praktische Vorteile hätte man, wenn man dem Vorschlag von Bosh folgte und ob es auch nicht anders geht.

Ist “Bosch” dann auch die Auflösung des Preisrätsels, mit wem sich eine Abordnung des OSMF-Vorstands vor einigen Monaten getroffen hat?

Marek, das Problem ist doch, dass es keinen Standard gibt, der alle glücklich macht. Garmin braucht bspw. die Info am Weg hinter dem *_link, Bosch hätte es gerne an einem Knoten irgendwo und wieder ein anderer Hersteller hätte es gerne an einem weiteren Ort. Damit hab ich kein Problem, ist halt deren Entscheidung, dass jeder sein eigenes Format haben möchte.

Meines Erachtens sollte OSM sich hier nicht einem Hersteller an den Hals schmeißen und sagen, dein System ist super, sonder bei der Realität bleiben. Die Realität ist nun mal, dass die Auffahrt die Eigenschaft hat, in welche Richtung sie führt und dementsprechend sollte auch der way das Tag direction=* bekommen. Ob man dann daraus einen Punkt erezugt oder die Infos auf den folgenden Weg überträgt oder was auch immer damit macht ist dann Sache des Auswerters.

+1

Mittlerweile haben wir x Diskussionen, welche ergebnislos irgendwie dieses Thema behandelten:
http://forum.openstreetmap.org/viewtopic.php?id=14710&p=1
http://forum.openstreetmap.org/viewtopic.php?id=18265
http://forum.openstreetmap.org/viewtopic.php?id=17795&p=1
http://forum.openstreetmap.org/viewtopic.php?pid=168643#p168643
http://forum.openstreetmap.org/viewtopic.php?id=14664
http://forum.openstreetmap.org/viewtopic.php?id=12554
http://forum.openstreetmap.org/viewtopic.php?pid=138705#p138705
http://forum.openstreetmap.org/viewtopic.php?id=11008
http://forum.openstreetmap.org/viewtopic.php?pid=33730#p33730
(Die Liste erhebt keinen Anspruch auf Vollständigkeit)
Wäre schön, wenn jetzt mal eine Lösung dabei herauskommt, mit der Erfasser, Renderer und Router leben könnten.

Die meisten Probleme kommen vermutlich vom “spurnahen” Mappen. Wenn ich das Ursprungsbeispiel nehme, wäre das bei der Kreuzung Hamburger Straße / Kasseler Straße so.
Die Abbiegespur ist ja eine eigene kurze Linie. Wie wäre es, wenn man diese mit einem einzuführugenden Tag von der Winkelberechnung ausnimmt? Oder ählichen dem motorway_link ein secondary/…/residential_junction einführt.

Liebe Freunde,
ich bin zur Zeit leider gesundheitlich angeschlagen daher habe ich noch keine Einladung nach Garching verschickt. Trotzdem, wie Hurdygurdyman denke ich dass wir uns endlich auf ein Schema einigen sollen. Wollen wir erste Novemberhälfte zwecks Treffen in Garching anpeilen und bis dato einige Lösungsansätze vorbereiten?

Ja das funktioniert, sehe nun bei ca. 30% aller AB-Kreuze die destination. Auf der mkgmap-dev hatte ich das Preprocessing bereits als Vorschlag gemeldet.
Wer’s mal testen möchte, die DACH+ Karte für’s Nüvi steht in Kürze auf meine Wikiseite zum download zur Verfügung.

Das Lanes-Schema http://wiki.openstreetmap.org/wiki/DE:Lanes wurde jetzt am komplexen Kreuzungsbereich der Kronenbrücke in Freiburg
http://www.openstreetmap.org/?lat=47.9902419447899&lon=7.84459501504898&way=19905457&zoom=18
getestet. Die wesentliche Arbeit hat hierbei dankenswerterweise der österreichische Kollege imagic http://wiki.openstreetmap.org/wiki/User:Imagic geleistet, der auch das proposal sowie die Wiki-Seite zum Schema verfasst hat.

Herausgekommen ist dabei dies:
http://ubuntuone.com/7ZD8chqc8HMyBqeqAy23IM
Wenn ihr die Datei in JOSM öffnet, könnt ihr diesen Hintergrund von Aerowest verwenden:
http://ubuntuone.com/4yMyNVBfX1UqCQrjQkkLNB

Es wurden nur die Straßen bzw. Fahrspuren im Bereich der Brücke erfasst. Die Kreuzungsflächen wurden als highway=junction angelegt und sind gelb und grün markiert. Auf dieser Fläche sich kreuzende highway=* müssen keine gemeinsamen nodes haben, wenn dort ein Wechsel auf den anderen highway nicht möglich ist, um relation=restriction weitestgehend zu vermeiden.

Mein Fazit:
Das Schema eignet sich in der Hand von erfahrenen Mappern auch für komplexe Kreuzungsbereiche und sollte auch bevorzugt dort angewendet werden, damit Router diese Spur-Informationen auswerten und anzeigen können, denn gerade an diesen Kreuzungen werden sie vom Autofahrer dringend benötigt.
Ich werde das Schema in meinen Bearbeitungen ab sofort einsetzen und meine Ideen zum Spurmapping
http://forum.openstreetmap.org/viewtopic.php?pid=277786#p277786
so nicht weiter verfolgen.

Exkurs:
Die Idee mit highway=junction zur Vermeidung von restriction sollte allerdings weiter verfolgt werden. Es wäre dabei zu prüfen, ob die Informationen aus turn:lanes=left|through|right usw. als Alternative oder anstelle von relation=restriction verwertbar sind, um diese mittelfristig zu ersetzen. Dann könnte auch auf highway=junction verzichtet werden.

Ich freue mich, dass diese Arbeit weiter geht.
Wir werden in Garching hoffentlich den letzten Schliff besprechen können, etwa den Gedanken mit den Lan dividers die dem Schema Hinzugefügt werden können.

Idee 1 (geht auf Immagic zurück):

crossable=yes - gestrichelt
crossable=no - durchgezogen
crossable=no,no - Doppellinie
crossable=no,yes - solid,dashed
crossable=yes,no - dashed,solid

getaggt mit etwa:

destination:lanes=A|A|B|B
crossable=no|yes|no,no|yes|no

für eine einfache Straße mit 4 Fahrspuren und einer Doppellinie in der Mitte.

Idee 2:

alle Tags in einer Reihe:

destination:lanes=no|A|yes|A|no,no|B|yes|B |no

Idee 3:

alle Tags in einer Reihe, leicht verständliche Tags:

destination:lanes=solid|A|dashed|A|double_solid|B|dashed|B |solid

Nachteil der Idee 2 und 3:

Die Vermischung der Angabe von Destination mit Spurtrennern.

Nachteil der Idee 1:

Ich muß bei komplexen Abschnitten richtig die die gezeichnete Richtung der Straße erkennen, damit der User nicht in die verkehrte Richtung taggt.
Man kann leichter Durcheinander beim Taggen kommen, da man sich leicht verzählen kann.

Schwierig :confused: vier Spuren mit drei Trennern und fünf Trennlinien mit vier Trennern. Wie soll das der Renderer zusammenbringen?
Wenn wir uns entschließen könnten, mindestens in den Fällen der Erfassung von :lanes auch die durchgezogene Linie als Trennung von Fahrspuren ohne Wechselmöglichkeit zu akzeptieren, könnten wir auf crossable= oder ähnliches verzichten, weil dann der Spurwechsel innerhalb einer Fahrspur beliebig möglich wäre.

Geht, wir haben Tests gemacht. einfacher geht´s mit einer Zeile, da weniger Fehler befürchtet. Am einfachsten ginge es mit einem WYSIWYG http://de.wikipedia.org/wiki/WYSIWYG Editor, wo man gleich Ergebnisse seht und nicht schreiben muss. Nur drag and drop.

Die Syntax der Tagging weiß man zwar in einem solchen Fall und natürlich wäre das auch manuell veränderbar.
Wie gesagt, es existiert berets eien Entwicklerversion von einem JOSM PlugIn, ich diskutierte es mit imagic, er wies darauf hin, dass es auch Arbeiten zu diesem Thema gibt daher wäre die Implementierung relativ zügig gemacht. Danach könnten wir es testen und Entscheidungen treffen.

Überzeugt mich nicht. Für einfache Fälle, ok. Aber mangels zusätzlicher Geometrie können komplexere Gegebenheiten nicht dargestellt werden. Fußgängerrouting und Rendering in sehr hohen Zoomstufen werden auch nicht bzw. kaum verbessert. Und: Meiner Meinung nach ist das deutlich fehleranfälliger. Eigenständige lanes fallen dem Bearbeiter sofort auf, aber die Tags können leicht übersehen werden, wenn Wege geteilt oder - schlimmer - vereinigt werden. Letztendlich hat man nicht weniger Komplexität, man verschiebt sie nur von einfachen Geometrien zu komplexen Tagsystemen. Diese sind unintuitiv (z.B. warum und auf welche Weise genau werden Radspuren von Kfz-Spuren getrennt) und stark voneinander abhängig (was soll ein Auswerter aus einem Weg machen, der lanes=x, aber y verschiedene Werte in :lanes Erweiterungen hat - oder gar unterschiedlich viele je Schlüssel).

Btw.: Wenn schon, dann wäre ich eindeutig für Idee 3. Reduziert Abhängigkeiten zwischen Tags und ist halbwegs intuitiv. Wobei ich es logischer fände, crossable mit access zu kombinieren, nicht mit destination.

Das stimmt ja alles, errt. Macht mir ja auch ziemlich Kopfzerbrechen. Ich verbinde es aber mit Straße als Fläche und denke, dass dies nur mit einem guten Editor möglich wäre, sonst lieber die Ffinger davon lassen denn die einfachen Fälle sind ausgerechnet die, die am wenigsten gebraucht werden.
Ich bereite nun für Garching eine Präsentation mit einigen Alternativen sowie dem möglichen User Interface von einem solchen Editor.