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. 
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 
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 
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 )
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