Routing / Spurmapping

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

@aiges, things-change, de_muur:
danke für die Informationen. Die routing-Geschichte kenne ich bisher nur als Anwender. Aber ich bin lernwillig und werde auf Basis eurer Aussagen mal in mich gehen, erst mal nachdenken und dann meinen frischen Mist dazu hier ausschütten :slight_smile:

Bis auf das lanes:single ist es eigentlich sehr einleuchtend, ich vermute, dass das mit durchgezogener / gestrichelter Linie zu tun hat? Ist damit auch überholen / nicht überholen und einseitige Fahrstreifenbegrenzung abgedeckt?

Der Logik des Taggingschemas müssten Spurtrennungen und -markierungen so getaggt werden: (natürlich auf englisch, aber da bin ich dann doch überfordert :slight_smile: )

lanes:trennungen=Bordsteinkante, durchgezogene Linie, Verkehrsinsel, gestrichelte Linie, Bordsteinkante

Wobei hier zwangsläufig ein tag mehr als Anzahl der Spuren vorhanden ist, und durchgezogene Linien und Inseln usw. Spurwechselverbote implizieren sollten.
EDIT: Vielleicht sogar besser ohne Bordstein, sprich ein tag weniger als Anzahl der Spuren.

Hallo Henning, eine Zuordnung zwischen backward und forward ist implizit gegeben,
da je nach Land bekannt ist, auf welcher Seite gefahren wird,
und die Spuren immer von links nach rechts bezeichnet werden (in Pfeilrichtung des Weges).

Hallo GeoCounter, mit lanes:single sind (einpurige) Radstreifen gemeint, also Spuren, die für’s Auto-Routing nicht zur Verfügung stehen.

Hallo Torsten, die Trennung zwischen den Spuren könnte doch genau mit den von dir vorgeschlagenen Trennzeichen erfolgen.
Kein Trennzeichen bedeutet, Spurwechsel möglich, Komma bedeutet, Spurwechsel nicht möglich, und für Spurwechsel in nur einer Richtung
müssen wir uns noch etwas einfallen lassen (z.B. < und > ) also für 4 Spuren dann z.B. y,yy<y
Für die Kante und die Insel könnte man sich ja noch ein Symbol ausdenken, wenn es wirklich notwendig erscheint.
Für’s reine Routing ist es eigentlich egal, ob ich die Spur wegen einer Sperrlinie, Kante oder Insel nicht wechseln kann.

Hallo Tordanik, der Übergang von einem Wegstück aufs nächste ist wohl noch eine wichtige Frage.
Was hältst du davon, am Übergang einen Punkt zu setzen, und in diesem zu beschreiben, welche Spuren enden und welche neuen entstehen.

i … Spur geht weiter
x … Spur endet
v … Spur spaltet sich auf (neue Spur entsteht)

Beispiel: eine 4-spurige Straße, bei der die linke Spur endet und rechts eine neue Spur entsteht: lanes:merge=xiiv
Hier muss man aber verdammt aufpassen, dass man die backward-Richtung korrekt erfasst. (schade, dass wir kein Lambda-Zeichen haben)

Irgendwer hat noch geschrieben, dass man die beiden Richtungen besser getrennt erfassen sollte.
Das kann ich natürlich unterschreiben, da dann weniger Fehler passieren. Trotzdem sollte das Schema aber beides beherrschen.

Walter

Hier fehlt aber die Information, mit welcher Spur die Endene verschmilzt bzw. ob sie sich nach links oder rechts aufteilt. Wie wärs mit:

lanes:merge=/|,|,|,|/

Wenn Abkürzungen und Sonderzeichen vermieden werden sollen, dann halt:

lanes:merge=merge_to_right, no, no, split_to_right

Naja und jetzt bin ich einfach mal fies. Wie machst du dort den Spurwechsel der Straßenbahn? Wenn die pkw Spuren geradeaus gehen aber die Straßenbahn nach rechts oder links rückt?

Und wie machst du ihn in deinem Beispiel? sorry, gar nicht gesehen, dass der Post von wem anders kam…

Wenn man das alles abbilden will, braucht man für die Bahn ein genauso komplexes Tagging-Schema wie fürs Auto. Also zu jedem lanes:xxx= ein lanes:tram:xxx=

EDIT:

Ausserdem bin ich der Meinung, wenn auf einer Straße 2 Bahnspuren getaggt sind, und auf dem nächsten Teilstück die Bahnspuren um eine Spur versetzt sind, dann ist eindeutig, dass beide Bahnspuren geschwenkt haben und so sollte man es dann rendern.

Manchmal muss man ein Proposal erst zur Abstimmung bringen, damit sich die Leute damit beschäftigen. Das ist aktuell bestens gelungen. Die Ereignisse überschlagen sich, immer mehr Vorschläge werden veröffentlicht. Ich hab auch welche.

Den Ansatz für width und maxspeed finde ich gut.

Die starre Trennung nach Fahrtrichtungen ist aber nicht flexibel genug. In den USA gibt es angeblich Abbiegespuren, die in beiden Fahrtrichtungen befahren werden dürfen. Außerdem sind Bus- und Radstreifen auf der “linken” Seite denkbar möglich.

Ich habe in der Mailingliste Talk-AT ein Konzept vorgestellt, das ich hier noch genauer ausführen möchte.

Anforderungen:

  • Es sollen alle Spuren, Trennstreifen usw. abgebildet werden.
  • Es soll Routing in allen Fällen und für alle Verkehrsteilnehmer funktionieren. (Außer Fußgänger, die klammere ich mal aus.)
  • Auf vielfachen Wunsch sollen Spurassistenten möglich sein, d.h. ein Navi soll ansagen können, welche Spur die richtige ist, um mehrere Kreuzungen später richtig abbiegen zu können.
  • Das ganze soll mit möglichst wenig Relationen und möglichst wenig + verständlichen Tags gehen.

Ich bin zur Ansicht gelangt, dass man die Spurendefinition von den Routinginformationen trennen muss. Bisher wurde das oft in einen Topf geworfen, darum waren die Taggingschemas wirr und deckten nicht alle Fälle ab.

1.) lanes=* - Spuren- und Spurentrennerdefinition, für beide Fahrtrichtungen

2.) lane_matching=* - Von welcher Spur kommt man auf welche Anschlussspur auf welchem anschließenden Way. In diesem Tag werden nur die in Fahrtrichtung zu benutzenden Spuren berücksichtigt.

3.) Spureigenschaften:
lanes:maxspeed=*
lanes:width=*
lanes:surface=*
usw.
Wie von Walter vorgeschlagen, aber mit lauter Kommas, keine Strichpunkte. Strichpunkte sind nicht nötig, weil die Fahrtrichtung schon in lanes=* definiert wird. Außerdem werden Strichpunkte üblicherweise benutzt um unabhängige Werte aneinanderzureihen. Hier sind sie nicht unabhängig, sondern sie stehen in einer definierten Reihenfolge.

Die Spuren werden immer von links nach rechts angegeben (in Way-Richtung schauend).

ad 1:
Die Syntax ist von http://wiki.openstreetmap.org/wiki/Proposed_features/Lanes_ex abgeleitet, aber viel ist davon nicht mehr über.

lanes=<Spuren von links nach rechts, jeweils mit mind. 1 Trenner dazwischen>
= [“+” …]
= l | sl | s | sr | r | c | b | t | w … left/slightleft/streight/slightright/right/(bi)cycle/bus/taxi/railway(oder tramway)

  • kann auch uppercase sein, heißt dann engegen der Wayrichtung.
    Beispiele: w+l … Linksabbiegespur mit Schienen; b+c … Bus und Fahrrad; L+l … in beiden Richtungen befahrbare Abbiegespur (s.o.)
    = folgende:
    , … Leitl- oder Warnlinie, Spurwechsel/Überholen erlaubt
    | … Sperrlinie
    ,| … Sperrlinie, Überholen von linker Seite erlaubt
    |, … Sperrlinie, Überholen von rechter Seite erlaubt
    || … doppelte Sperrlinie
    <> … undefinierte bauliche Trennung
    … durch Grasfläche baulich getrennt, die Klammern sind hier Literale, statt grass sind auch alle anderen Werte von barrier=* und surface=* erlaubt

ad 2:
lane_matching=<Spuren von links nach rechts, durch je 1 Komma getrennt>
= [][“.” [“+” …]]
… 0=umkehren, 1=linkester Anschlussway, 2=zweitlinkester usw., Default ist 1
… 1=linkeste Spur, 2=zweitlinkeste usw., Default ist alle

lane_matching:backward=* … genauso, aber Blick entgegen der Wayrichtung, für die Anschlüsse am rückwärtigen Ende des Ways

Beispiel 1:
lanes=R,C,S,SLsl,s,c,r für beidseitig Linksabbiegeundgradaus-Spur, Gradausspur, Radfahrstreifen und Rechtsabbiegespur, in der Mitte eine bauliche Trennung mit Hecke.
dazu zusätzlich:
lane_matching=0+1+2.1, 2.2, 2.3, 3

  • d.h. von der linkesten Spur darf man umkehren (0), links abbiegen auf beliebige Spur (1) und geradeaus fahren auf linke Spur (2.1);
    von der zweitlinkesten Spur darf man geradeaus auf die zweitlinkeste fahren (2.2);
    von der drittlinkesten auf die drittlinkeste (d.h. auf den Radfahrstreifen bleiben);
    von der rechten darf man rechts abbiegen auf eine beliebige Spur (3).

Beispiel 2:
3 Spuren, mittlere teilt sich:
lane_matching=.1, .2+3, .4

Beispiel 3:
3 Spuren, linke hört auf:
lane_matching=.1, .1, .2

Zusammenfassung: Die Syntaxbeschreibung wirkt ein bisschen kompliziert, aber wie die Beispiele zeigen, ist das Tagging sehr kurz und halb so wild. Relationen sind keine nötig, die Abbiegerelationen erübrigen sich auch. Bei Way-Splits muss man aufpassen, aber das gilt für die alternativen Proposals genauso.