Re: Unumkehrbare ways

Das vorgeschlagene „neue“ Schema ist eigentlich nichts Neues. Die Funktionalität der left/right-Umkehr ist in josm bereits seit längerem fest eingebaut, ebenso wie forward/backward. Bei Einbahnstraßen zusätzlich yes/-1. Soweit ich es mitbekommen habe, ist das in Potlach2 und ID auch bereits eingebaut oder zumindest auf der aktuellen Liste.

Wer für was auch immer ein *left- oder *right-tag an die Straße setzen will, das nicht mit umgedreht werden darf, kann das bereits jetzt ganz entspannt machen, denn umgedreht wird - in Key und Value, aber nur _1x_ - nur das erste Auftreten von [^:]xxx[:$] mit xxx = left|right|forward|backward. Das heißt übersetzt, in einem Wertepaar, key=value, wird das erste Auftreten des Begriffs left, egal ob in Key oder Value, alleinstehend oder durch Doppelpunkt abgetrennt, ausgetauscht gegen right (mit Nachfrage). Jede andere Kombination und auch jedes weitere Auftreten der Ausdrücke bleiben unverändert. So wird z.B. aus einem "bright" kein "bleft" und aus einem right_hand_side auch kein left_hand_side.

Das ist aber bereits seit mindestens einem Jahr Stand der Technik, darüber brauchen wir in diesem Zusammenhang nicht zu diskutieren. Ein Chaos ist jedenfalls bisher ausgeblieben.

Es geht jetzt nur darum, dieses bereits bestehende, akzepierte und funktionierende Schema allgemeingültig für alle richtungsabhängigen Tags zu verwenden.

Zu den "halb-rechts"-Tags, die vor allem im Fahrspurmapping bei Abbiegespuren vorkommen, sollte noch ergänzt werden, dass sie, außer in Einbahnstraßen, immer mit einem forward/backward-tag im Key verbunden sein sollten.

turn:lanes:forward=left;straight|straight|slight_right

Da nur einmal das erste erkannte tag umgedreht wird, entsteht bei einer Richtungsumkehr

turn:lanes:backward=left;straight|straight|slight_right

was wiederum korrekt ist. Im Falle von Einbahnstraßen wäre es vermutlich empfehlenswert, ebenfalls immer ein forward mitzuführen.

Das sollte nur aber nur ein Beispiel zur Verdeutlichung sein, sonst wird es arg OT.

MHohmann wrote:

Am Beispiel von Küstenlinien fände ich es dagegen deutlich sinnvoller, wenn z.B. der Validator überprüfen würde, ob aneinandergrenzende Wege / Küstenabschnitte in die gleiche Richtung zeigen, und es zu bemängeln, wenn das nicht der Fall ist.

Der Dau, der die Nachfrage beim Umdrehen wegklickt, wird auch den Validator wegklicken. Außerdem ist es keineswegs sicher, dass die vorhandene Küstenlinie an der Stelle richtig ist. Es kann auch passieren, dass der Anfänger denkt, er habe das Wiki falsch verstanden, und dreht seinen Weg (fälschlich) um, weil der Validator es so will. Ob das Meer jetzt rechts oder links ist, sollte er aber erkennen können.

Ocean war übrigens auf der Mailingliste vorgeschlagen worden, damit es deutlicher wird, dass es sich um eine Meeresküste handelt und nicht Fluss- oder Seeufer so getaggt werden.

Dass das Tagging, besonders in diesem Fall, nicht über Nacht geändert wird und werden kann, ist sowieso klar. Insofern werden alle bisherigen Schemata weiterhin so ausgewertet wie bisher, nur dass im Fall der expliziten Richtungsangabe diese zusätzlich ausgewertet wird. Im Falle eines Widerspruchs könnte der Validator einen Hinweis geben, das würde weitere Fehlerquellen verstopfen, könnte allerdings auch zu Verwirrung von Anfängern führen.

Ein Auswerter muss sich ohnehin regelmäßig auf dem Laufenden halten. Ihm wird das Leben mit den explilziten tags zur Richtung leichter gemacht. Er hat eindlich ein eindeutiges Schema, an dem er die Richtung erkennen kann, ohne jedesmal im Wiki suchen zu müssen. Der Änderungsaufwand ist moderat und abschließend, während er jetzt ständig mit neuen tags rechnen muss, die wieder irgendeine Richtung implizit voraussetzen.