[Talk-at] Neue Idee für's lanes-mapping

[Martin Vonwald]

> Nein, das hab ich mir gerade ausgedacht. Aber es erscheint mir jetzt nicht
> übermäßig kompliziert. Etwas Ähnliches kann ich mir durchaus vorstellen zu
> finden, bspw. um die Geschwindigkeit beim Abbiegen nicht zu stark reduzieren
> zu müssen.

Ich muss zugegeben, dass ich mir im Moment kein Beispiel vorstellen
kann. Wie soll das auf der Straße aussehen?


> Und die Frage bleibt aufrecht: Wollt ihr mit den turn:lanes nur
> die Pfeile auf der Fahrbahn erfassen, um sie fürs Routing verwenden zu
> können oder sollen damit auch die Abbiegerelations (in einfachen Fällen)
> ersetzt werden.

Mit turn:lanes denke ich in erster Linie an die Fahrbahnmarkierungen.
Damit Navis dann auch endlich gute Anweisungen geben können, z.B. an
Autobahnkreuzen. Aber die meisten nicht zu komplizierten
Abbiegemöglichkeiten sollten damit darstellbar sein und wir könnten in
vielen Fällen auf Relationen verzichten, was in meinen Augen die
Lesbarkeit stark erhöht. Wahnsinnskreuzung wie am Matzleinsdorferplatz
in Wien wird man aber nie ohne Relationen darstellen können. (Wer
diese Kreuzung nicht kennt, soll sie sich doch mal am Luftbild
ansehen.)


> Zweiteres halt ich für eher unglücklich weil es ohne Not eine weitere
> Taggingoption für manche, einfache Abbiegebeschränkungen schafft. Wenn ihr
> hingegen sagt "Wir wollen damit nur die Pfeile auf der Straße abbilden",
> dann würd ich das explizit erwähnen um vor Erbsenzählern wie mir sicher zu
> sein.

AbbiegeBESCHRÄNKUNGEN wollen wir sicher damit nicht ersetzen - dafür
gibt es schon die Relation restriction. Aber ein gutes Routing muss
mir sagen können "bleib auf den linken zwei Spuren sonst bist du
plötzlich auf Abbiegespuren wo du nicht hin willst". Und dazu muss es
wissen, dass bestimmte Spuren eben für bestimmte Richtungen gedacht
sind. Das sollte mit turn:lanes=xxx darstellbar sein.

> Das hab ich damit gar nicht gemeint. Wenn wir etwas nur über Relationen
> abbilden können, dann ist es halt so. Lieber eine genau definierte Relation
> die ihre Aufgabe vollständig erfüllt, als ein Taggingschema, dass nur in
> Spezialfällen hilfreich ist und für den allgemeinen Fall erst wieder die
> Relation braucht.

Ich bin für Taggingschemas die alle "Standardfälle" mit möglichst
wenig Relationen abbilden. In Spezialfällen wird man aber nur selten
darauf verzichten können und deshalb ist es wichtig ein Taggingschema
zu finden, welches sich durch Relationen ergänzen lässt aber diesen
nicht widerspricht.

turn:lanes soll hier wirklich nur die Spurrichtung angeben. Die
Verbindung von einem OSM-Way zum nächsten wird dadurch erst einmal
nicht definiert. In einfachen Fälle wie
turn:lanes=through,through,right,right und danach rechts ein Weg mit
lanes=2 sind die Verbindungen der Wege idR klar und sozusagen implizit
definiert und wir brauchen keine Relation extra. Gehen aber zwei Wege
vom selben Punkt weg, dann braucht man Relationen um zu sagen welche
Spur landet auf welcher Spur auf welchem Weg.

Und abschließend noch: die Idee mit <key>:lanes=<value>,<values> soll
nicht nur die Abbiegespuren lösen. Wir können damit für jede Spur
extra Eigenschaften angeben, egal ob das Geschwindigkeitsbegrenzungen,
Fahrbeschränkungen (öffentlicher Verkehr), Fahrbahn-Trennungen, Geh-
und Radwege oder sonstiges ist.


> PS: Ich hoff ich geh dir/euch damit nicht übermäßig am Nerv. Ich find
> *jeden* Lanetagging Vorschlag besser als separates Mappen von parallelen
> Ways, aber wenn sich ein Proposal bei einem derart strittigen Thema
> durchsetzen soll, dann muss es ein paar Pedanten mehr als mich aushalten
> (und wohl auch noch eine Routingapp mitliefern, die aufgrund der Daten auch
> funktioniert, aber das ist eine andere Geschichte).

Du geht's mir nicht auf den Nerv. Das ist ein großes Problem für OSM
und wir brauchen eine gute Lösung. Getrenntes Mappen von Ways KANN
nicht funktionieren, denn das würde ja bedeuten, dass man nicht von
einer Spur auf die andere wechseln kann - es ist ja keine Verbindung
da. Das wäre also nicht nur extrem aufwendig und unübersichtlich
sondern auch schlichtweg falsch.