Routing / Spurmapping

Nein :smiley:
Wenn du mal das Shape-Format vom großen Kartenhersteller gesehen hast, weißt du das alles über Relationen läuft :sunglasses:
Aber das ist ja nicht gewünscht :rage:

Man kann aber nicht Objekte auf Relationen reduzieren, wo die Abbildung der Geometrie und relativen Lage zu anderen Objekten unbedingt nötig ist. Die Geometrie bildet man meiner Meinung nach am besten mit Flächen ab, die ganzen restlichen Eigenschaften dann über Relationen.

Edit: Ach ja, und nachsehen können ersetzt nicht das selbst nachdenken und heißt auch noch lange nicht, das so ein Modell auch gut für OSM sein muß.

Für das rendering mag das stimmen. Hier geht es aber primär um routing. Und solange noch keine Möglichkeit in Sicht ist, die routing über Flächen ermöglicht, bringt ein Flächenmodell zu diesem Problemkreis nichts. Somit ist es hier auch müßig, über den Sinn zu diskutieren, Straßen usw. als Fläche abzubilden. Da beißen sich nun mal zwei Ansprüche an OSM. :confused:

Das verstehe ich nicht. Es ist doch bei einfachen Flächen kein Problem eine Mittelline zu finden. Da nimmt man sich einfach die beiden Seiten und teilt den Abstand zwischen ihnen durch zwei. Schwierig ist das nur bei komischen Flächengebilden, wo die rechte und Linke Seite mit Oben und Unten verwechselbar ist. Und fürs Routing braucht es dann einen Vorverabrbeitungsschritt.
Aber 3D Grafik in Spielen sind ja auch nicht auf dem C64 entstanden.

Klar geht das irgendwie mit entsprechendem preprocessing. Die Frage ist nur wann. Und wie soll man der Fläche etwa bei oneway eine Richtung geben?

Zumndest ist es leichter ein paar einfache Richtungen für den Router als Metadaten anzugeben, als wie bisher oft versucht wurde, eine komplexe Objektgeometrie in ein paar Tags zu fassen.
Man kann ja zum Beispiel eine Relation type=oneway mit den Rollen from und to an die passenden Punkte der Fläche taggen, dann geht das Routing auch mit Fläche. Zusätzlich würde ich es auch so machen, das die Relation für die Fahrbahn (z.B. type=carriageway), sowohl flächige als auch Linienobjekte als generische Spur (Spurobjekt für alle Fahr-/Gehwege, von mir bisher mit lane=yes vorgeschlagen) enthalten kann, so kann man je nach Datenlage wie z.B. Luftbilder, die Spuren als Linen oder als Flächen taggen. Aus Rückwärtskompatibilitätsgründen kann man dann noch (vielleicht als Rolle highway) den alten highway=, da wo er noch, an Stelle der Einzelspuren, existiert, mit in die Relation für die Fahrbahn packen und die neuen Spuren an evtl. vorhandenen highwy=-Reste anschließen. Das nur mal so als schnelle Idee.

Es ginge beispielsweise so: Man definiere die Fläche als Menge ihrer Kanten. Dann definiere man für jede Kante, ob man die Fläche über diese Kante betreten kann oder nicht und ob man die Fläche über diese Kante verlassen kann oder nicht. Mit zusätzlichen Relationen könnte man eventuell noch Dinge ausdrücken wie ‘wenn man die Fläche durch Kante A betreten hat, kann man sie durch Kante B nicht verlassen’, aber theoretisch sollte das durch Aufbrechen der Fläche auch direkt möglich sein. Routing würde dann im Prinzip wie jetzt erfolgen, nur dass statt Knoten Flächen genommen werden (was aber keinerlei Unterschied macht) und die Kanten zwischen den Knoten der Beziehung ‘die Flächen teilen sich mindestens eine Kante von der aus man die erste Fläche verlassen und die zweite betreten kann’ (was ohne Preprocessing aufwendig ist - mit Preprocessing kann man daraus aber einen Routinggraphen erstellen, der dem jetzigen absolut identisch ist).

Ja, mir ist klar, das so ein System absolut unerfassbar wäre. Es geht nur um die grundsätzliche Möglichkeit, das durch Flächen auszudrücken. In dem Fall sogar mit dem angenehmen Nebeneffekt, dass der Oneway nur der Spezialfall ist, dass man durch die Ausgangskanten nicht rein kommt (und theoretisch durch die Eingangskanten nicht raus).

Das scheint mir soweit ich das sehe die einzig sinnvolle Lösung zu sein. Weil meine schenlle Idee scheitert ja schon am nächsten Kreisverkehr. Durch Auftrennen der Flächen kann man kein oneway=yes darstellen, da braucht man immer eine Relation. Die Routingleute müssen ja eh eine Vorverarbeitung machen, sei es weil sie maxspeed=, surface= oder die Zahl der Spuren/Ampeln in eine passende Metrik für die Kante umrechenen müssen. Von daher kann vorher auch noch der Routinggraph mit erstellt werden.

So unerfassbar ist das gar nicht, mal abgesehen vom allgemeinen Problem, wie man die ganze Komplexität durch Software ein passende Daten und am besten noch Wizards vom Durchschnittsmapper abschirmt.
Das automatische Erstellen der Realtionen sollte im Normalfall kein großes Problem darstellen. Spontan fallen mir da folgende Fälle ein:

  1. Die Flächen können beidseitig betreten oder verlassen werden, dieser Fall sollte der angenommene Standardfall sein und tritt üblicherweise auf wenn zum Beispiel landuse=grass an einen Fußweg angrenzt.
  2. Ein building=* grenzt an die Spur an, dann kann automatisch eine Relation erstellt werden, das man die Fläche nicht in das Haus building=* verlassen kann erstellt werden. Außerdem müßte man aber noch zusätzlich eine Relation dafür erstellen, daß man üeber den Eingang (building=entrance mit auf der Schnittlinie) doch ins Haus kommt.
  3. Spur A grenzt an Spur B. Da Fragt man den Mapper, ob man nur von A nach B oder nur von B nach A kommt, oder ob beides möglicht ist und erstellt automatisch eine Relation.

Ja, ich habe auch nochmal drüber nachgedacht und bin zu dem Schluss gekommen, dass es durchaus erfassbar wäre (ohne zusätzliche Editorunterstützung nur mit heutigen Mitteln allerdings schwer). Theoretisch bräuchte man übrigens keine Relation für den building=entrance. Denn eigentlich gehört der in einer Flächendarstellung als Linie und nicht als Punkt repräsentiert und schon ist das Problem gelöst (Alternativ kann man für bestimmte Dinge wie building=entrance auch einfach direkt festlegen, dass das auch als node wie eine Zu- und Ausgangskante gilt zu allen Flächen die den Punkt enthalten). Problematischer ist, dass man den Punkt über die Flächenrelation der Fläche zwangsweise zuordnen muss, denn er wird theoretisch ja in den Außenlinien von mindestens zwei Flächen liegen, gehört logisch aber nur zu einer.

Mal eine Frage zum “Leipziger Stern-Modell”:

Wozu dient dieses seconday-link-Quadrat (layer=-5) in der Mitte der Kreuzung, welches nicht mit dem Rest
verbunden ist und somit zu Routing-Fehlern führt, wenn der Start-oder-Zielpunkt zufällig dort
liegt :


?

http://www.openstreetmap.org/?lat=51.324055&lon=12.291283&zoom=18

Chris

Wenn ich das sehe, denke ich nur an:
“Erwarte nichts und werde dennoch enttäuscht…”
Wer kommt auf solch eine Idee?! Und wie findest du das immer wieder :wink:

Naja, die “Diskussion” auf der Mailingliste (welche eigentlich aus einem Monolog einer gegen alle bestand) stellte die Frage nach diesen Wegen auch, aber auch wenn ich nicht alles durchgelesen habe, kam da keine klare Antwort. Gibt auch noch andere Fragen zu diesem Modell, aber der Erfinder dieses Schemas macht halt sein Ding, hat er auch damals mit dem Länderdreieck Sachsen, Sachsen-Anhalt und Thüringen gemacht, welches aber inzwischen wieder gelöscht wurde.

Oh, mein Namensvetter schreibt es ja selber als Note rein:

*note:EN = drop this, if you strictly do notwant to tag for renderers *
:laughing:
http://www.openstreetmap.org/browse/way/152931728

Und noch besser:
http://wiki.openstreetmap.org/wiki/Lanes_and_complex_intersections_visual_approach
Wann gab es dazu ein proposal?!

Fortführung von: http://forum.openstreetmap.org/viewtopic.php?pid=241981#p241981

Ja, wenn man auf diese Art Spuren mappt, dann finde ich diese Lösung auch besser, da weniger fehleranfällig und man hat
ein paar Duzent TRs gespart.

Edit: Wie ich heute festgestellt habe führt das dazu dass Garmin beim Linksabbiegen überhaupt keine Ansagen mehr macht, was klar ist, da ein Router Ansagen in der Regel nur bei kreuzenden (also verbundenen) Fahrbahnen macht.

Gibt es eigentlich schon (Test-)Karten oder Anwendungen, die solche Spurmappings wie area:highway, turn:lanes und/oder lane_restriction verwenden? Bzw. auch destination-Angaben/destination_sign-Relationen verwenden?

Ich würde *:lanes = * gerne darstellen, wenn dafür auch Spurtypen (Busspur, Parkspur, Radspur, etc.) definiert wären. So ist es zwar ein viel versprechender Ansatz, aber in meinen Augen noch unfertig. Leider scheint der Tatendrang des Proposal-Autors etwas nachgelassen zu haben.

Mal mein experimenteller Beitrag zum Thema Spur- und Verkehrzeichen-/Ampel-Mapping: http://wiki.openstreetmap.org/wiki/User:Fabi2/Generic_lane_model
Evtl. legt man den Spur-Access auch als Relationen ab, aber das macht es sicher einfacher, aber auch noch umständlicher im Moment, denn selbst in JOSM könnte die Unterstützung füt verschachtelte Relationen (z.B. bei Elemente anzeigen) besser sein. Das ist ein PoC und soll nur meine Ideen demonstrieren, war gerade nicht vor Ort um das noch mal 100%ig gegenzuchecken, aber di wichtigen/iteressanten Fälle kommen zumindest einmal vor. noch ein paar oneway=* mehr und dann kann man es auch so machen wie in meinem Vorschlag. :slight_smile: Im Moment ist das aber nicht wirklich handhabbar, ich wollte aber einfach nur mal checken ob meine Idee überhaupt halbwegs funktioniert.

So, nach mehrmaligem Schieben und Grübeln wage ich es, meinen Ansatz zum lane-mapping hier vertiefend zur Diskussion zu stellen.

Meinen Denkansatz und die Vorgehensweise stelle ich in diesem Dokument vor:
Ein paar Erläuterungen zu meinem lanemapping-Ansatz für OSM
http://ubuntuone.com/4F2YwZNrw18nKASBZPR17U
Darin erkläre ich das warum, wie und womit.
Im Dokument befinden sich weitere links zu:

  • einem Lösungsansatz, der als Proposal-Entwurf dienen kann
  • einer grafischen Darstellung des Lösungsansatzes an einem einfachen Beispiel
  • einer “Freiburglanetest.osm” mit einer etwas komplexeren Umsetzung des Schemas, die in JOSM geöffnet werden kann
  • einer “lanestyles.xml” die dazu dient die lanes gut sichtbar orange darzustellen
  • zwei Aerowest-Bilder, welche als Hintergrund die Realität zum besseren Verständnis zeigen

Wer Zeit und Lust hat, kann sich das mal ansehen. Kritik und Anregungen sind willkommen. Vielleicht wird ja ein Proposal daraus.

push:
Schade, hat wohl keiner Lust, zu diskutieren.
Und bis dahin geht der “Missbrauch von highway=*” für Spuren fröhlich weiter, sobald bing high res vorliegt :frowning:
Ein aktuelles Beispiel:
http://www.openstreetmap.org/?lat=48.353639&lon=7.806424&zoom=18&layers=M
edit:
auch schön:
http://www.openstreetmap.org/?lat=48.359814&lon=7.770861&zoom=18&layers=M