Routing / Spurmapping

@aighes:
Ich gebe dir recht, was die Kombatibilität und die Anwendbarkeit betrifft. Durch die Nummerierung ist das auch für den Otto-Normal-Mapper durchschaubar. Allerdings sollten wir auf zusätzliche forward/backward verzichten und dafür je Fahrtrichtung auch ohne Trennung (Insel, Doppellinie) einen eigenen way als oneway in Erwägung ziehen, weil sich das sonst wieder als fehleranfälliger Moloch entwickelt und Mapper abschrecken könnte. Mindestens auf Autobahnen und großen primary ist die Trennung ja sowieso vorhanden. Eine durchgezogene Linie als Mittellinie zwischen den gegenläufigen Richtungen oder eine Schraffur dürfte in den anderen Fällen auch ein Überfahren derselben verbieten.

So einfach ist es nicht. Die erste Kreuzung ist nämlich aufgeteilt. Da kann der rechtsabbieger nur in die rechte Spur und der Linksabbieger von Norden nur in die linke Spur. Das ist auch durch eine durchgezogene weiße Linie gut erkennbar.
Bei der zweiten Kreuzung sieht es schon anders aus. Wenn ich von der Fritz Reuter straße in die B170 nordwärts einbiege, habe ich drei Spuren zur Auswahl. Wenn man keine Unterscheidung trifft sortiert das Navi auch hier links/rechts und die Mitte bleibt frei.

Die Dritte Kreuzung ist insofern interessant, dass hier aus Westen auf der Schweriner Straße kommend 3 Spuren sind. Die Rechtsabbieger sind am rechten Rand. Danach kommen die Linksabbieger in der Mitte und ganz Links sind wieder die Rechtsabbieger Straßenbahn und Bus.

Wie wollt ihr denn so eine Stele mappen?
http://maps.google.de/maps?q=Kesselsdorfer+Stra%C3%9Fe,+Dresden&hl=de&ie=UTF8&ll=51.043247,13.6961&spn=0.0014,0.002411&sll=50.994743,13.701324&sspn=0.358701,0.617294&oq=dresden+kess&vpsrc=6&hnear=Kesselsdorfer+Stra%C3%9Fe,+Dresden,+Sachsen&t=h&z=19&layer=c&cbll=51.043211,13.69579&panoid=0tCtonLtG6ehNnHPNueicw&cbp=12,285.01,0,-6.11
Es kommt auf den Pfeil an, welcher dazu auffordert den Überholvorgang abzuschließen. Das ist nicht das Ende der Spur, sondern so war die Straße über längere Abschnitte markiert. Man soll das Gleis also nur zum Überholen benutzen nicht zum im Stau stehen.

Hm. Vielleicht beim Weg, der zu dem Weg mit dieser Spur führt für die rechte Spur ‘merge’ angeben, und bei dem Weg selbst auch auf der rechten Spur ‘merge’. Sprich, wenn merge getaggt ist, die Spur dann aber noch da ist und auch merge hat, heisst es, dass es eine Spur nur zum Überholen ist.
Klingt ziemlich kompliziert, oder?
Oder noch n Tag ‘nur zum Überholen’.

Es fehlt auch komplett, welcher Verkehrsteilnehmer welche Spur nutzen darf…

Stimmt die Straßenbahn wird sich nicht rechts einordnen. Aber alle anderen Verkehrsteilnehmer (die auf der Straße unterwegs sein dürfen) dürften schon dort fahren.

Das war nicht auf die Strasse bezogen. Gibt ja auch Strassen, wo LKW nur die rechte Spur benutzen dürfen.

Wie solls denn jetzt weitergehen? Das Proposal wird niedergestimmt, und das wars erstmal mit lanes? BTW, wie ist das eigentlich bei so nem Proposal, wie muss die Abstimmung ausgehen, damits durchkommt? Auf der deuschen Wiki-Seite steht da nix drüber…

Ich denke, Spurentagging MUSS kommen. Die Frage ist nur das wie. Vielleicht sollte man versuchen, hier auf einen Konsens zu kommen, um dann nochmal was zu starten.

Man sollte vielleicht nochmal einen Schritt zurückgehen, und sich nicht in irgendwelchen Tag-Bezeichnungen verlieren.
-Was soll Spurtagging darstellen bzw. wer soll einen Nutzen davon haben?
-Soll es nur Abbiegeregeln beschreiben? Oder auch die Nutzung? Also PKW, LKW, auch Strassenbahn fällt unter Verkehrsteilnehmer. Die Gleise wiederrum… Gehören Gleise in das gleiche Tag wie Linksabbiegen? Oder in ein (evt.) weiteres Tag, das halt die Nutzung beschreibt? Oder vielleicht sogar in surface?
-Soll so etwas nur die Motorvehikel-Spuren beschreiben, oder auch Fuß- und Radwege?
-Wie könnte ein leicht zu verstehendes Tagging-Schema aussehen?
-Wie ‘verbindet’ man einzelne Spuren von Start- und Zielstrasse?
-Wie muss es aussehen, damit es für einen Router verwertbar ist?
-Wie sehen denn die Daten der ‘Profis’ aus, mit denen Spurassistenten möglich sind?

Vielleicht führt das ja noch mal zu einer Diskussion, oder wir leben halt weiter ohne Spuren…

Kraftfahrzeuge + Radwege: ja
Fußwege: eher nein (bei Fußwegen gibt es selten Abbiegespuren oder ähnliches)
Bus-Spuren usw wieder ja

Hier eine erste (noch sehr unreife) Idee für ein Mapping anhand einer spiegelsym. Straße.

lanes:backward=4
lanes:forward=4
lanes:single=nynn;nnyn
lanes:bicycle=nynn;nnyn
lanes:bus=… + lanes:tram=…
lanes:straight=nyyy;yyyn
lanes:turnleft=nnny;ynnn
lanes:turnright=yynn;nnyy
lanes:maxspeed=30,30,50,30;30,50,30,30
lanes:width=2.8,1.2,2.8,2.8;2.8,2.8,1.2,2.8
u.s.w.

Wenn ich’s jetzt erklären muss, ist es bereits zu kompliziert.
Das Schema muss von jedem verstanden werden,
ohne stundenlang die Wiki-Seite studieren zu müssen.

Walter

Von mir aus soll das alles elends kompliziert gemacht werden, ist an und für sich kein Problem. Aber im Endeffekt muss es eine optische Visualisierung in JOSM werden, dann wirds auch genutzt. Spuren kann man per Drag&Drop anordnen und dann LKW-Verbote taggen, Busspuren, Fahrradspuren machen o.ä. und alles optisch sichtbar. Sowas händisch einzugeben wird keine ausreichende Menge an Leuten kapieren oder auf der anderen Seite die Taggingmöglichkeiten stark begrenzen und Fehler geradezu provozieren. Die erste Version wird aber nicht perfekt werden, was auch wieder klar ist und man sollte nicht alles wegen jeder Rollerspur aufhalten.

Zusatzfrage: Brauchen wir noch eine Kennzeichnung für Links-/Rechtsverkehr?
z.B. drive_on=left bzw. drive_on=right
oder ist das über das Land bereits implizit definiert.

Walter

@monotar: Sehe ich ähnlich. Daher sollte man es evtl. so taggen (lassen), dass eine Auswertung einfach ist.

@Walter: gefällt mir ganz gut, is evtl. auch besser als meins, wenn man es mit einer GUI mappt. drive_on=left|right braucht man nicht, dass ergibt sich aus den Grenzen und den darin geltenden Gesetzen.

Wow, das hat mich gerade richtig überrascht. Da dachte ich, ich wäre in den gut 3 Jahren Diskussion zu Spurmapping schon allen denkbaren Konzepten mal begegnet. Aber so eins hatten wir wohl noch nicht.

Wenn ich so darüber nachdenke, vermeidet der Vorschlag wirklich die Probleme der Alternativen:

  • Man kann den einzelnen Spuren theoretisch beliebige Tags verpassen.

  • Die Anzahl der Schüssel ist fix.

  • Man braucht keine Relationen.

  • Die Menge der Tags pro Weg ist erträglich.

Die einzige ungelöste Herausforderung, die mir bei dem Vorschlag momentan einfällt, ist der Übergang der Spuren von einem Wegstück aufs nächste. Trotzdem, in diese Richtung sollte man mal weiterdenken!

Und ja, ein wenig hässlich ist es schon - aber es könnte glatt die am wenigsten hässliche Umsetzung von Spuren als Attribute sein, die ich bisher gesehen habe. :slight_smile:

In eine GUI verpacken geht immer, solange das Datenmodell die Informationen prinzipiell aufnehmen kann. Für Walters Vorschlag ein JOSM-Plugin zu schreiben wäre z.B. ziemlich einfach.

Hallo Walter

Gute Arbeit, die meisten Fälle können so abgedeckt werden.

Zwei Bemerkingen von mir dazu:

  • Die Zahl der Spuren ist auf zwei Taggs verteilt.
    Warum nicht als ein Tagg lanes:direction=4;4
  • Verwende nicht das Strichkomma zum Trennen der Richtungen.
    Das wird meist für die Trennung von Werten genutzt und ist
    entsprechend unbeliebt. Mein Vorschlag wäre der senkrechte
    Strich, da der Doppelpunkt ja auch bereits belegt ist.

(Edit) Beides sind Kleinigkeiten, die den Wert der Idee nicht schmälern. (/Edit)

Für die meisten, die sich mit dem Thema mal beschäftigt haben und sei es nur durch das Lesen dieses Threads, wird das weitgehend selbsterklärend sein. Auch insofern: Gute Arbeit

Edbert (EvanE)

Rein von der Konsequenz her, muessten bei den yes/no Werten auch jeweils ein Komma dazwischen, dann könnte man sich auch das Abkuerzen sparen.

Was bei diesem Ansatz verloren geht, ist der schnelle Blick, welche Informationen denn nun eigentlich fuer eine bestimmte Spur gelten. Das muss man sich muehsam aus den einzelnen Werten raussuchen, entsprechend fehleranfaellig koennte das Schema dann auch sein. (Wenn ein Komma vergessen oder versehentlich geloescht wird, sind gleich alle Spuren betroffen, da die Zuordnung verlorengegangen ist.)
Auf der anderen Seite wird sowas aber auch keiner mehr von Hand editieren wollen, insofern ist dieser Nachteil vielleicht gar nicht mal so entscheident. (Aber was macht ein Editor, wenn die Anzahl der Werte nicht bei allen Tags gleich ist?)

Was ein Spurmappingschema auch braucht, ist die Information, wie von einer Spur zur nächsten gewechselt werden kann und wie die Trennung zwischen den Spuren aussieht. Die absolute Pest fuer bestehendes Routing ist es nämlich, wenn jeweils eigenstaendige Linien erfasst werden. In meiner Region gibt es Mapper, die bei jeder Kleinigkeit (z.B. Verkehrsinsel) gleich die Strassen aufspalten. Das ist zwar im Prinzip nicht falsch, sorgt aber dafuer, dass die automatisch generierten Routingansagen kommplett unbrauchbar werden.

Fuers Routing muss der Routing-Graph erstmal so einfach wie moeglich gehalten werden, fuer einen Renderer gelten da leider andere Anforderungen. Vielleicht muss man da dann ueberlegen, ob es ueberhaupt sinnvoll ist, fuer beide Zwecke gemeinsam erfassen zu wollen.

Gruss
Torsten

Ich halte -wie oben schon mal erwähnt - gar nichts von forward/backward. Das bezieht sich nicht auf die Realität draußen, sondern nur auf die Abbildung in OSM und zu schnell ist so eine Weg mal versehentlich gedreht :roll_eyes:
Die wichtige Masse der in Frage kommenden Fälle für Spurtagging fällt auf motorways und trunks an, wo die gegenläufigen Fahrtrichtungen sowieso getrennt als oneway angelegt sind. In diesen Fällen erübricht sich auch eine Lösung für Rechts- oder Linksverkehr.
Auch wichtige Durchgangsstraßen innerorts haben in der Regel eine räumliche Trennung. Auf Kraftfahrstraßen ist das Wenden gemäß §18 StVO unabhängig von der Trennlinien nicht erlaubt, weshalb hier eigentlich die Fahrtrichtungen auch als einzelne Ways anzulegen wären.

Bleiben fast nur noch innerörtliche Straßen mit Abbiegespuren ohne doppelte Linie aber meist einer Linie zwischen den Fahrtrichtungen. Was spricht eigentlich dagegen, diese auch für die hier in Frage kommenden Fälle auch je Richtung als way anzulegen?

Den Einwand von de_muur “Die absolute Pest fuer bestehendes Routing ist es nämlich, wenn jeweils eigenstaendige Linien erfasst werden.” verstehe ich nicht, da mir Erfahrungswerte fehlen.

Ich gebe dir recht, dass es wohl primär an geteilten Fahrbahnen getaggt werden wird. Aber eben nicht nur. Das drehen von Wegen sehe ich nicht als gravierend an. Editoren können das erkennen und eine Warnung ausgeben.
Was mir bei Walter noch fehlt, ist eine Zuordnung zwischen linker und rechter Seite zu forward und backward. Ebenso fehlt noch eine Darstellung für Einrichtungswege. Und was mir sehr wichtig ist, dass lanes:surface nicht surface ersetzt (etc.). Ein Auswerter soll sich mit dem komplizierten Spurzeug nicht auseinandersetzen müssen, wenn es ihn nicht interessiert.

Router basteln sich aus den Daten einen Routinggraph für eine Straße, der alle Infos enthalten sollte. Daraus kann er dann das Gewicht des Weges ermitteln. Gliedert man Wege zu weit auf, gehen manche Infos unweigerlich verloren, wenn man sie nicht doppelt einträgt. Ebenso verkompliziert sich der Routinggraph natürlich ordentlich.

Nehmen wir mal eine kleine Nebenstrasse, die auf eine Durchgangsstrasse führt. Am Ende hat die Nebenstrasse eine Rechtsabbiegerspur. Dann müsste ich ja ab dem Beginn der Abbiegespur die Fahrtrichtungen aufteilen, um dann für dei Forwardspur geradeaus und rechts zu taggen.

In einer kleiner Zoomstufe, die keine Lanes darstellt würde es dann wohl so aussehen, als hätten wir die Geradeausspuren und eine abzweigende Rechtsabbiegerspur, in Wahrheit ist in dem Abzweig auch die forward Geradeausspur.

Beim Routing kommt es ja nicht nur darauf an, dass eine moeglichst gute Strecke gefunden wird, sondern es geht ja auch darum, durch (automatisch generierte) Ansagen jemanden entlang dieser Strecke zu leiten.

Bei einer einfach erfassten Kreuzung (zwei Strassen kreuzen sich) hat man im Routinggraph einen Knoten, an dem vier Kanten aneinander stossen. Da ist es fuer den Router dann nicht all zu schwer, auf Grund der Geometrie der Kannten zu entscheiden, ob ueberhaupt eine Ansage notwendig ist und wie diese dann zu lauten hat.
Wenn man aber die gleiche Kreuzungen mit getrennten Fahr- und Abbiegespuren erfasst hat, dann hat es der Router mit einer Vielzahl von Knotenpunkten zu tun mit wesentlich komplexeren Geometrien (wobei auch noch die Winkelverhaeltnisse von einzeln erfassten Spuren deutlich ausgepraegter sind, als was man in der Wirklichkeit vorfindet). Da kommt dann ganz schnell nur noch Quark raus, so dass man je nach Router entweder mit unsinnigen Kommandos zugemuellt wird oder wichtige Kommandos nicht mehr generiert werden.

Gruss
Torsten

Um so öfter ichs mir anschaue, umso besser gefällts mir.

Hat man keine Strassenbahn, kommt sie nicht vor. ansonsten

lanes:tram=ynnn

Und das mit den Abbegespuren mal weitergedacht: Hab ich eine vielspurige Strasse, ist sie oft eh für die Fahrtrichtungen getrennt getaggt. Dann einfach:

lanes:forward=4
lanes:straight=yyyy

Die Nebenstrasse mit Abbieger hat insgesamt auch selten mehr als 4 lanes. Hier taggt an also beide Fahrtrichtungen.

lanes:backward=1
lanes:forward=2
lanes:straight=y;yn
lanes:right=n;ny

Vorteil:
Es müssen keine Strassen anders eingezeichnet werden als bisher, nur um Spuren zu taggen.
Und beide Fälle bleiben übersichtlich. Leider beissen sich jetzt noch die beiden tagging-Schemen für lanes:forward EDIT: lanes:straight, aber da lässt sich bestimmt ne Lösung finden.

Dann noch defaults, um so wenig wie möglich taggen zu müssen.
Z.B. an 3-spurigen Strassen sind alle geradeaus, vor Kreuzungen die rechte auch rechts.

Wir taggen zwar nicht für Garmin, aber dort kommt hinzu, dass das Garmin-Format nur eine begrenzte
Auflösung hat und somit bei einer engen Punktfolge eine gezackte Linie heraus kommt:

Der Garmin-Routing Algorithmus sieht eine Penalty für spitze Abbiegungen vor, er bevorzugt also
Routen mit wenigen Biegungen.

Chris