Da ist die Frage, was der derzeit bei 100,100,60 lesen würde. Den ersten Wert? Dann wär alles gut. Oder ‘kenn ich nicht’=none. Dann wärs ne Verschlechterung. Notfalls müsste man ein neues Tag nehmen, z.B. maxspeed:lanes
Da kein router die genaue Spur erkennen kann, wird er die maxspeed auch nicht anzeigen können, es ei denn, er blendet ein Schild mit den jeweiligen Geschwindigkeiten nebeneinander ein. Eine optisch/akustische Warnung wird er nur beim höchsten Wert können.
momentan würde er bei 100,100,60 wohl sagen kenn ich nicht… daher finde ich es richtig, dass es mit 100 getaggt ist, da dies die maximale geschwindigkeit ist, mit der auf der strecke gefahren werden darf.
@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.
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.
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…
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.
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.
@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.
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
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.
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.