Routing / Spurmapping

Solche “Abkuerzungen” funktionieren aber nur, wenn man fest definierte, abgeschlossene Alphabete hat. Wie du spaeter ja aber selber anfeuhrts, ist OSM so aufgebaut, dass Schluessel und Werte beliebig wachsen koennen. Das vetraegt sich mit Abkuerzungen gar nicht. Und zum Glueck sind Abkuerzungen bei OSM ja auch alles andere als ueblich, selbst die Boolean-Werte yes und no werden ja standardmaesisg ausgeschrieben. Da sollte wir jetzt mit dieser Unsitte bestimmt nicht anfangen.

Genau das meinte ich, nur hatte ich die Zeichen verwechselt :frowning:

Um so entscheidender ist es, dass man da nicht noch verschiedene Bedeutungen mit rein kodiert.

Vieleicht waere der Strich | ein guter Kandidat, um die einzelnen Spuren zu trennen?

Ganz meine Meinung.

Im Prinzip koennte ich mit beiden Leben. Bei einer Abstimmung wuerde ich allerdings die zweite Variante bevorzugen, um die Aehnlichkeit von
lanes:maxspeed=10,20,30
und
lanes:maxspeed:3=30
zu betonen.

Aber das sind Syntax-Kleinigkeiten. Interessanter ist erstmal, wie man ein Spur-Mapping ueberhaupt aufziehen will.

Gruss
Torsten

Ich finde das schreit dann geradezu nach
lanes[6]:maxspeed=100
lanes[6]:maxspeed:hgv=80
Dann wäre sogar
lanes[5;6]:maxspeed=100
lanes[6]:maxspeed:hgv=80
denkbar.

Ok, meiner ist “Alternative B”.

BTW: Was heißt Sperrfläche auf Englisch? (Steht nicht mal im Langenscheidt-Wälzer.)

Ob man “slightleft” abkürzt oder ausschreibt, ein lexikalisches Token ist es so oder so. Entweder der Parser kennt es, dann kann er was damit anfangen, oder er kennt es nicht, dann kann er nichts damit anfangen. Auf die Erweiterbarkeit hat das Abkürzen also keinen Einfluss.

Mir persönlich wär’s recht, aber diese Schreibweise wäre in OSM neu.

Klar ist das mit den Abkuerzungen dem Parser egal (solange es eindeutig ist). Es geht dabei allein um die Lesbarkeit fuer den Mapper. Schau dir doch mal mit einem Meter Abstand auf der Uebersichtsseite Alternative B Example 2 an. Das versteht doch kein (menschliches) Schwein mehr, einschliesslich des Mappers selber auch nur 3 Minuten nach dem Eintragen.
Und erzaehl mir nicht, dass das Tagging des Beispiel dank der Abkuerzungen schoen uebersichtlich waere :wink:

Gruss
Torsten

Alternative 3 ist auch drinnen.

Hallo fkv,

du solltest bei deiner Alternative nicht lanes=* verwenden, das ist bereits 2249668x anderweitig genutzt.
Es spricht sicher nichts dagegen, lanes:layout nochmals zu nehmen, oder auch einfach etwas anderes.

Walter

@de_muur: Dann lass mal deine Variante sehen.

Im Vergleich zu den linken Spalten sieht Alternative B in Example 2 natürlich kompliziert aus, weil die nur die Hälfte der Informationen enthalten.

@Walter: lanes=* hab ich vom Vorgängerproposal übernommen. Natürlich kann man es auch lanes:layout nennen, aber ich spare mir gern Schreibarbeit. Dass lanes= schon oft vorkommt, stört nicht. Ich nehme an, dass Anwendungen diesen Tag bisher sowieso ignoriert haben, da sich mit der Gesamtspurenzahl nicht viel anfangen lässt. Und zukünftige Anwendungen können leicht erkennen, ob der Wert nur eine Zahl enthält oder was anderes.

Eben, es ist unter Zuhilfenahme der Fahrtrichtung intuitiver. Und ich würde deshalb noch weiter gehen und ein solches Mapping nicht nur erlauben, sondern es direkt zur Vorgabe machen, dass die Fortsetzung in (einer der) Fahrtrichtung(en) anzugeben ist.

Die Regel sähe dann so aus:

  • lanes:continuation:forward/backward gibt an, wohin man gelangt, wenn man sich auf der Spur in/entgegen Wegrichtung bewegt
  • bei Spuren für beide Richtungen kann man eins weglassen, wenn das Ziel in der einen Richtung mit der Herkunft bei der anderen Richtung übereinstimmt.

Dazu auch mal eine Detailfrage: Wie handhabst du mit deinem Vorschlag Spuren, bei denen mein Zusatz “wenn das Ziel in der einen Richtung mit der Herkunft bei der anderen Richtung übereinstimmt” nicht gilt? Also z.B. eine “two-way left turn lane” für Linksabbieger in beide Richtungen? Skizze siehe unteres Diagramm http://www.mto.gov.on.ca/english/dandv/driver/handbook/section2.6.5.shtml hier.

Wenn man sich - wie ich hier vorschlage - darauf festlegt, die Fahrtrichtung als Kriterium ins Tagging einzubeziehen, dann wird man dort einfach …:forward und …:backward passend für die jeweilige Fahrtrichtung setzen.

Die Linksabbiegespur ist nicht der häufigste Fall, aber insgesamt gesehen doch allgegenwärtig. Es sollte schon eine Möglichkeit geben, eine Spur als Linksabbiegerspur zu markieren. (Das ist nicht dasselbe wie ein “left” bei der Continuation, denn eine Linksabbiegerspur beginnt schon ein ganzes Stück vor der Kreuzung und ist auch dann eine Linksabbiegerspur, wenn man den Way in ihrem Verlauf auftrennen muss.) Das fehlt in deinem Vorschlag leider noch.

Darf man fragen warum? Ich finde es ähnlich gut lesbar wie deinen Vorschlag, aber es vermeidet gleichzeitig das leidige Thema Zahlen in Schlüsseln.

Es ist normalerweise aber möglich, eine endliche Liste von Schlüsseln zu erstellen, die für die eigene Anwendung relevant sind. Das erleichtert z.B. die Erstellung von Filtern.

Und dann schlägst du so was vor?

lanes=c.l+s,s,s+r,r||N.N,Cp

Vielleicht ist das auch wieder eine Geschmacksfrage, aber das finde ich schwer zu lesen, schwer zu schreiben und schwer zu parsen. Ohne Editorunterstützung fasse ich diesen Wert nicht mal mit der Kneifzange an. :wink:

Das ist das, was ich lane_matching genannt habe, weil mir kein besserer Keyname eingefallen ist. Vielleicht ist …continuation besser, keine Ahnung.

Indem ein Teil des Schlüssels in den Wert verschoben wird. Genauso könnte man lanes=surface:6:unpaved draus machen.

Wir leben im 3. Jahrtausend. Heute gibt es regular expressions.

Wenn du die Doku (http://wiki.openstreetmap.org/wiki/User:Fkv/lane_mapping_draft) anschaust, geht das schon. Dafür, was in dem Wert alles drinsteckt, ist er doch relativ übersichtlich. Wenn man das anders macht, wird es noch komplizierter.

Fein, das werde ich gleich in die Vergleichsseite einbauen. EDIT: Doch noch nicht, weil in dem Beispiel keine Kreuzung ist und weil mir die Regeln noch nicht ganz klar sind. Verstehe ich das richtig, dass eine center turn lane für Linksabbieger von beiden Seiten eine Abbiegespur ist, zugleich für Linksabbieger von der Querstraße so eine Art Beschleunigungsstreifen?

Meinst du beim ersten Punkt in der Regel jetzt “Wegrichtung” oder “Fahrtrichtung”?

Das Problem bei der Fahrtrichtung ist halt die vollstaendige Listendarstellung lanes:continutaion:forward=left|straight|straight|right
Bei den Spuren mit lanes:direction=forward wird hier die Kreuzung an dem einen Ende des Weges beschrieben, bei den Spuren mit lanes:direction=backward wird hier eine ganz andere Kreuzung am anderen Ende des Weges beschrieben.
Diese Vermischung halte ich fuer ziemlich verwirrend. Mir schient es da sinnvoller zu sein, dass man unter EINEM Schluessel die Verbindungen der Spuren an EINEM Ende des Weges sammelt.

Vielleicht waere als Schluessel lanes:connection passender, da dieser Begriff bezgl. der Richtung neutraler ist. Es wird einfach angegeben, wie eine Spur an diesem Kreuzungspunkt mit den anderen Richtungen verbunden ist.

Ich muss gestehen, dass ich weder deinen Zusatz noch das Beispiel in deinem Link wirklich verstehe.

Nach meinem Konzept sollte in einem Schlüssel erfasst werden, wie die jewielige Spur an einem Knotenpunkt mit den angrenzenden Wegen verbunden ist. Das wird ueber den entsprechenden Wert abgebildet, wobei auch eine Liste von Werten moeglich ist.
Die gaengigsten Werte duerften straight, left und right sein dazu kommt sicherlich noch ein Wert fürs Wenden u_turn oder backward vielleicht sowie Zwischenwerte fuer kompliziertere Kreuzungstopologien wie slight_left oder sharp_right und vielleicht braucht man auch noch ein up oder down, wobei solche vertikalen Wegtrennungen eigentlich immer auch in der Ebene beschrieben werden koennen.

Bei naeheren ueberlegen habe ich deine Frage jetzt, glaube ich, doch verstanden. Meinst du: Wie wuerde mein Konzept es abbilden, wenn die Verbindungen zwischen den Spuren nicht symmetrisch sind? D.h. solche Faelle, wo eine Spur in beide Richtungen befahrbar ist, sie ueber die Kreuzung aber mit Spuren verbunden ist, die nur in eine Richtung befahren werden darf.
Bei meinem Konzept wuerde sich daraus ergeben, dass lanes:connection:forward des eines Weges nicht genau dem lanes:connection:backward entspricht. Da hatte ich bisher noch nicht drueber nachgedacht, scheint mir aber letztendlich kein Problem zu sein, denn am Ende sollte sich ja trotzdem ein widerspruchsfreies Gesamtbild ergeben.

Das ist die von mir noch offen gelassene Frage, ob man bei der Bezeichnung der einzelnen Spuren zwischen Abbiegespur und “normaler” Fahrspur unterscheiden muss oder nicht. Fuer das Routing (im Sinne von: Bestimmung der optimalen Spur) oder für eine schoene Kartendarstellung braucht man das eigentlich nicht. Aber fuer die Sprachausgabe koennte das hilfreich sein. Oder verwirrt diese Zusatzinformation eher? Ich habe weiss es nicht. Ab wann ist eine “normale” Fahrspur eine Abbiegespur? Sobald da Pfeile aufgemalt sind, schaetze ich mal.

Weil dabei Schluessel und Wert vermischt werden. Bei dieser Loesung muss man auch die rechte Seite der Gleichung auswerten, ehe man entscheiden kann, ob das Tag fuer einen von Belang ist oder nicht.

Bezueglich der Zahlen in Schluesseln sehe ich nicht so das grosse Problem. Klar, die Auswerteprogramme muessen eine Nummer schlauer werden, wenn sie diese Informationen auswerten wollen. Das gilt aber auch fuer die angedachte Listendarstellung auf der rechten Seite des Gleichheitszeichens. Das Spurmapping stellt nun mal hoehere Anforderungen an die Auswertung, liefert aber dafuer zusaetzliche Informationen, die bislang nicht erfasst werden koennen.

Mit dem lanes=* stimme ich mit fkv ueberein. Es besteht keine Gefahr, dass lanes=* und lanes= bei der Auswertung verwechselt werden. Und ich sehe keinen Sinn darin, fuer einen Weg die Beschreibung von lanes= und lanes:layout=* parallel vorzusehen/zuzulassen. Das wuerde nur zusaetzliche Komplikationen mit sich bringen.

@fkv: Ja, ich sollte wohl mein Konzept auch als Variante in die Uebersicht mit aufnehmen. Allerdings habe ich damit zwei Probleme: Zum einen legt das fuer meinen Geschmack den Schwerpunkt zu sehr auf die Syntax, welche ich als eher zweitrangig ansehe. Zum anderen sind die Beispiele so unvollstaendig, dass die konzeptionellen Unterschiede zwischen den einzelnen Varianten gar nicht klar werden. Solange z.B. nicht der OSM-Weg-Graph fuer die Beispiele mit angegeben wird, kann man einen Unterschied zwischen einer Erfassung enstprechend der Wegrichtung und einer Erfassung entsprechend der Fahrtrichung gar nicht erkennen.

Gruss
Torsten

Ich habe meinen Vorschlag mal praezisiert und dann als Alternative E in die Tabelle aufgenommen. Das faellt bei den Beispielen aber echt schwer. Denn das Verfahren soll ja auch das detailierte Mapping erlauben, nur leider kann man halt die Details auf den Photos nicht erkennen. Entweder man faengt dann an zu raten, oder man kann kaum was als Beispiel erfassen.

Gruss
Torsten

wieso nicht lanes gleich als eigenständige ways mappen? http://wiki.openstreetmap.org/w/images/8/83/Highway_lanes.png

ist genauso kompliziert, dafür aber exakter.

Weil in deinem Beispiel zwei wesentliche Dinge fehlen:

  • ca. 30 - 50 turn restrictions müssten noch ergänzt werden.
    ==> wesentlich komplexer
  • wo darf man die Spuren wechseln und wo nicht?
    Erhöht ebenfalls die Komplexität.

Ganz nebenbei, wer soll so etwas noch in Ordnung halten?
Edit: Abbiegen auf eine reine Busspur ist irgendwie auch nicht optimal oder so vorgesehen.

Edbert (EvanE)

Nicht im Bild: Die Relationen / Spurwechselstellen / anderen Kleinigkeiten zum Zusammenbinden der Ways, die das Bearbeiten zur Hölle machen. :wink:

Es gibt zwei zentrale Gründe, warum das Spurmapping mit eigenständigen Ways ein Problem ist:

Der erste ist die Auswertbarkeit. Während eine Straßenflächen-Darstellung aus Spurtags leicht erstellt werden kann - die einzige Herausforderung für mich wäre dort die Darstellung von Übergängen zwischen zwei Ways - wüsste ich keinen befriedigenden Ansatz, dasselbe Ergebnis aus losen Ways zu errechnen. Eine Kreuzung wie die im Bild ist für einen Menschen noch einigermaßen gut visuell zu interpretieren, vor allem mit dem Luftbild darunter. Für einen Computer ist sie eine größere Herausforderung.

Der zweite Problemkreis ist das Mapping. Es muss irgendein Mechanismus existieren, um zusammengehörige Ways als solche zu identifizieren. Der gängige Vorschlag sind Relationen, aber dann ist das (nur) “genauso kompliziert” nicht einmal mehr ansatzweise wahr. Ein anderer Ansatz wären Straßenflächen um das Linienbündel herum. So etwas fände ich auch nicht unsympathisch, aber der Teufel steckt dort wieder im Detail.

Ich will so etwas nicht fundamental ablehnen, aber ich bleibe sehr skeptisch, solange die Praktikabilität beim Editieren und auch in der Auswertung nicht demonstriert wurde. Mir erscheinen die Vorschläge auf Tag-Basis, die in diesem Thread bisher vorgebracht wurden, allesamt realistischer. Dort habe ich keinen Zweifel an der prinzipiellen Machbarkeit.

Weil der Routinggraph schlicht und einfach falsch ist. Du kannst in der Realität mit Deinem Fahrzeug beliebig die
Spuren wechseln (zumindest bei gestrichelter Linie), der Router kann das nicht, er ist auf der Spur gefangen.

Nun kommt hinzu, dass GPS nur begrenzte Genauigkeit hat, und somit die Gefahr groß ist, dass er die
falsche Spur trifft. Des weiteren wird die Komplexität der Daten und damit die Fehlerquote erhöht.

Also: Für’s Routing ist das absoluter Käse.

Chris

Da muss ich an Plätze denken, in die nicht existierende Fußwege eingezeichnet werden, um Fußgängerrouting zu ermöglichen. Auch so ein Missstand. Kann ein Router eigentlich nicht 2 an einen Platz mündende Fußwege miteinander verbinden?

ja und? dann berechnet er die route halt neu, genauso wie wenn er jetzt schon neu berechnet, wenn du abbiegst obwohl der router sagt du sollst gerade aus fahren.

wir mappen nicht für die karte/router. nur weil deine aktuelle technologie das nicht kann, heißt das nicht, dass zukünftige (galileo) dass dann nicht schaffen. und komplizierter als krampfhaft so ein komplexes thema wie spuren in einen einzigen way zu quetschen ist es auch nicht.

Ne, aber wir mappen, um Daten zu sammeln, die man nutzen kann…

Abgesehen davon, dass es schlichtweg falsch ist. Es ist eine Strasse, dies mehrere Spuren enthält.
Und Spuren in einen einzigen way zu quetschen ist ziemlich genau so kompliziert und krampfhaft, wie Spuren auf einer einzigen Strasse unterzubringen.

Man befinde sich in einigem Abstand zu der Kreuzung. Die Route geht an der Kreuzung nach links. Alles ok soweit. Man nähert sich der Kreuzung, ordnet sich brav ein, dummerweise ist der Empfang aber zu schlecht und der Router vermutet einen auf der Rechtsabbiegerspur und kann dann natürlich nicht mehr nach links abbiegen. Folge: Neue Anweisung rechts abiegen. Autofahrer schummelt sich auf die Rechtsabbiegespur biegt ab und wird dann mit bitte wenden in die andere Richtung geschickt.

Eine SUPER Verbesserung für das Routing, kann man nicht anders sagen… :wink:

Ebenso fehlt bei dir noch die eine Linie, die die gesamte Straße symbolisiert und die alle die nutzen können, denen Spuren vollkommen egal sind.

Ja, wir mappen nicht für die Router. Aber wenn man schon extra für das Routing Daten sehr komplex erfassen will, dann sollte man es doch auch so erfassen, dass es sinnvoll nutzbar ist, oder? Denn wenn kein Router damit etwas anfangen kann, dann kann man die Eintragung auch lassen. :wink:

wer sagt, dass die lanes die jetzigen ways komplett ersetzen? die bestehenden highways bleiben bestehen und in kreuzungsbereichen werden die lanes separat hinzerfasst um mehr details darzustellen und werden einfach mit dem bestehenden highways verknüpft. alte routingprogramme ignorieren diese dann sowieso, weil sie die neuen tags nicht kennen; somit auch kein kompatibilitätsproblem.

Ich wollte nur Anmerken, dass das Liniengewirr auf deinem Bild noch nicht alles ist, was der Mapper dann im Editor zu sehen bekommt, sondern dass noch der allgemeine highway=* fehlt.

Du glaubst aber nciht ernsthaft, dass ein Neueinsteiger da dann noch durchblickt wo er was eintragen muss und welche Objekte er nun verschieben muss, oder?