> 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. _______________________________________________ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at