Idee 2 und 3 haben trotz der oberflächlichen Ähnlichkeit wenig mit dem akzeptierten lanes-Proposal zu tun, wo man ein Tag pro Schlüssel erstellt und eben nicht alles in einen Wert packt Die Idee ist schließlich, mehrere Tags mit *:lanes versehen zu können - also z.B: noch turn:lanes und width:lanes. Die Divider will man aber nur einmal nennen, also sind die Werte der *:lanes-Tags eher nicht der richtige Ort dafür.
Idee 1 hingegen lässt nicht genug Spurtrenner zu, um alle in der Realität vorkommenden Variationen abbilden zu können. Das könnte man mit den sprechenden Werten aus Idee 3 problemlos beheben.
Für mich daher die naheliegendste Variante: Analog zu :lanes noch :divider einführen und dort sprechende Werte verwenden. Also:
So bekommt man die Flexibilität, mit der das :lanes-Tagging für sich wirbt - inklusive z.B. der Möglichkeit, dividers weitere Tags zu geben (Beispiel: colour:divider zur Unterscheidung zwischen gelben und weißen Fahrbahnmarkierungen).
Technisch sehe da jetzt keinen Unterschied. Bei Mareks Idee würde ich das no,no durch ein einfaches no ersetzen. Das reicht aus. Diese Variante kann ohne Probleme weiter detailliert werden, wenn es Unterschiede gibt, ob man als Radfahrer oder als Autofahrer etc. unterwegs ist. Bspw. durch ein crossable:bicycle=… etc.
Beim Vorschlag von Tordanik sehe ich das Problem, dass in den Daten dann zwar steht, dass da eine durchgezogene Linie ist, doch es sagt nichts über dessen Bedeutung aus. Bspw. wäre es denkbar, dass dort zwar eine gestrichelte Linie ist, eine bestimmte Fahrzeuggruppe aber dennoch nicht die Spur wechseln darf. Ebenso wäre auch der umgekehrte Fall denkbar (durchgezogene Linie, die von einer Gruppe überfahren werden darf).
Die Idee ist vom Immagic.
Wie auch immer: ich denke es reicht nicht aus, weil es eine andere Straßenbesichlderung ist, die wir auch uunterschiedlich rendern wollen. Wenn schon, dann schon
Naja…ich denke man müsste zu einer generellen Lösung kommen, die Routing und Rendering trennt. Für das Routing braucht man Daten in einem Routinggraph-ähnlichem Objekt (way) und für das Rendering geht die Reise eher in Richtung Flächen.
Das hat natürlich zur Folge, dass man Sachen doppelt eintragen muss, weil sie für beide Bereiche wichtig sind, aber jeweils in einer anderen Weise. Sprich man wird in der Darstellung für den Renderer die Info platzieren müssen, dass dort eine durchgezogene Linie ist und in der Darstellung für den Router muss man die Info platzieren, dass der LKW nur auf der rechten Spur fahren darf.
Von daher sollte man meiner Meinung nach die Gedanken in Richtung Flächenmapping und Linienmapping nicht allzu isoliert sehen, sondern eher als gemeinsame Lösung betrachten und überlegen, in welcher Darstellungsform welche Informationen benötigt werden.
Wenn es eine andere Lösung statt highway=junction gibt, um kreuzende highways ohne gemeinsamen node bzw. relation=restriction zu ermöglichen, können wir darauf verzichten.
Erste Idee:
junction:lanes=yes als zusätzlicher tag bedeutet, dass der highway mit diesem tag andere highway=* kreuzen darf, ohne mit diesem einen gemeinsamen node zu haben. QA-tools (OSMI, keepright! usw.) werten dies dann nicht als Fehler aus.
GaussKrüger 3 hatte ich als "Allgemeinbildung für Aerowest-Bilder vorausgesetzt
Mir wäre das egal. Allerdings hat sich das Lanes-Proposal für width:lanes, destination:lanes, maxspeed:lanes, … entschieden, und nicht etwa lanes:width etc.
Daher passt es dann irgendwie besser, auch colour:divider (oder :dividers?) und so weiter zu nehmen.
Da die abweichende Anzahl von Dividern und Lanes eventuell einige Mapper verwirren wird, wäre es vielleicht besser statt der Trennlinie die Spurwechselmöglichkeit anzugeben, z.B.:
change:lanes=right|both|left|right|both|left
Da bei right und left noch zu definieren wäre, ob ich dieses auf den Weg oder die tatsächliche Fahrtrichtung bezieht, wäre vielleicht auch
change:lanes=>|<>|<|>|<>|<
oder
change:lange=+1|-1,+1|-1|+1|-1,+1|-1
eine Alternative.
Insbesondere für Straßen mit Gegenverkehr könnte man auch die Werte “in” und “out” (Spurwechsel zur Straßenmitte bzw. von dieser weg) als alternative zu “left” und “right” zulassen.
Man hätte auch, den Vorteil, dass die Tags die Funktion wiedergeben und nicht nur das Aussehen der Trennlinie. Man sollte auch daran denken dass es landesspezifische Abweichungen in der Bedeutung der Linientypen geben kann.
GaussKrüger, ja…aber die Nummer variiert schon innerhalb Deutschlands
Wenn es bei der highway=junction-Fläche nur um Fehlertools geht, dann sollte man diese weglassen, bzw. das normale Tagging für flächige Straßen verwenden.
+1. Gute Idee. Entspricht dem bewährten Schema des “sprechenden” value. Sonderzeichen sind zwar schneller getippt, abstrahieren aber. Ebenso erscheint mir +1 usw. zu abstrakt.
Hi erstmal - ich gebe hier auch mal meinen Senf dazu.
Nope - keine gute Idee! Der Schlüssel turn ist wirklich nur dazu gedacht anzuzeigen, was man auf der Straße oder auf einem Schild sieht. Das hat nicht zwangsweise etwas damit zu tun, was man dann machen darf/muß.
So war das nicht gedacht. Mit crossable:lanes wollte ich die legalen Beschränkungen des Spurwechsels angeben. Also immer zwei pro Spur, wobei man auf den äußeren Spuren darauf verzichten könnte.
Spur 4 (am weitesten links): nur Wechsel nach rechts erlaubt (links würde die Fahrbahn verlassen, könnte man weglassen)
Spur 3: nach links erlaubt, nicht nach rechts
Spur 2: nach links erlaubt, nicht nach rechts
Spur 1: kein Spurwechsel erlaubt
Kann man sich so vorstellen: | 4 : 3 |: 2 | 1 |
Der Grund warum ich das so andachte damals war, dass ich bei allen :lanes-Schlüsseln die selbe Anzahl an Werte haben will.
Die Idee mit den unterschiedlichen Zeichen kam schon mehrmals auf, hat nur zwei Nachteile:
Kaum intuitiv, vor allem wenn dann noch so Zeichen wie # dazu kommen. (Kann mich nicht mehr erinnern wofür das gedacht war).
Bei welchen :lanes-Schlüssel sollen sie verwendet werden? Es können beliebige viele sein.
Der Schlüssel ist egal. Ob highway=junction oder area:highway macht keinen Unterschied. Der Punkt ist, dass der Editor wissen muss, dass er bei xxx=yyy keinen Fehler wegen überschneidender Wege anzeigen darf, wenn diese (am selben Layer) innerhalb der Fläche sind.
Diese Idee gefällt mir prinzipiell gut, nur bin ich noch nicht 100% davon überzeugt, a) dass wir wirklich das Aussehen taggen müssen und b) dass wir einen zweiten Suffix einführen sollen/müssen. Auch der Schlüssel type:divider ist irgendwie … naja… aber ich habe auch nichts besseres bei der Hand. Trotzdem: gefällt mir.
Eines der Grundprinzipien von OSM sind lesbare Tags. Ob das hier zutrifft?
Das ist jetzt genau das selbe wie crossable:lanes. Mit left/right/both gefällt es mir aber sogar besser!
Deswegen bin ich eher dafür den Effekt zu mappen als das Aussehen.
Das hätte den Nachteil, dass man das auf jeden Weg draufgeben muss und es sich z.B. wenn jemand Wege kombiniert und kopiert leicht “fortpflanzt”. Bei einer Fläche passiert dir das nicht so schnell. Denke an Leute die keine Ahnung von diesen Tags haben. Bei einer Fläche erkennen sie schnell: ok, das ist wohl die Kreuzung. Bei junction:lanes=yes haben sie keine Ahnung und ignorieren den Tag. Langer Rede kurzer Sinn: ist fehleranfälliger.
Aber warum soll man nicht darüber nachdenken, ob der Schlüssel nicht auch noch einen anderen Zweck erfüllen kann Auswertungen könnten doch aus dem key/value erkennen, wohin man am nächsten Kreuzungspunkt mit anderen highway=+ abzweigen kann
area:highway kann überall auch außerhalb von Kreuzungsbereichen verwendet werden, wenn man eine Straßenfläche darstellen will. Da kann dann kein Router/Renderer/QA unterscheiden, ob es ein Fehler ist oder nicht.
Die Gefahr des falschen “Fortpflanzens” hat man schon jetzt bei x Fällen. Ich denke, dass Leute ohne Ahnung sich an komplexe Kreuzungen eher noch nicht rantrauen. Da sollte dann die Wiki ein klares how to anbieten, um Fehleranfälligkeit zu minimieren, wobei erst einfache Fälle und dann komplexere Beispiele auch bildhaft vorgestellt werden sollten.
Auch wenn ich mal bei meinem Versuch, Einzelspuren zu erfassen, die Idee mit der junction-Fläche propagierte, sehe ich in der Lösung junction:lane=yes oder ähnlichem mittlerweile auch Vorteile bei der Auswertung durch QA und Router.
QA müssen nicht erst prüfen, ob ein Kreuzungspunkt von zwei highways in einer Fläche junction liegt, sondern erkennen gleich am way: "Der ist junction:lane=yes, also kann ‘gemeinsamer Kreuzungspunkt ja/nein-Prüfung’ entfallen.
Für Router entfallen Kreuzungspunkte, an denen sie prüfen müssen, ob eine restriction vorliegt.
Jetzt müssen wir uns nur noch entscheiden, was uns lieber ist…
Der Vorteil ist also klar. Weniger Relationen = weniger potentielle Fehler. Die gemeinsamen Punkte bestehen trotzdem, also können wir anzeigen, dass sich Straßen schneiden und das auf einem Display beliebiger Navigation anzeigen.
Auswertungen könnten doch aus dem key/value erkennen, wohin man am nächsten Kreuzungspunkt mit anderen highway=+ abzweigen kann