Unumkehrbare ways

Hat da jemand ein Tagging gefunden, dass bisher weitestgehend einheitlich und allgemein akzeptiert war und sucht nun nach einer Möglichkeit alternative Schemata einzuführen?
Muss es für einen Datennutzer ein Vollzeitjob werden auf geänderte Taggingschemata zu reagieren, weil sonst wichtige Funktionen der Anwendungen nicht mehr Funktionieren? Ein Renderer der ocean=left nicht unterstützt, wird keinen Küstenverlauf mehr hinbekommen, ein Router der kein oneway=backward kennt wird mich nicht unbedingt an das Ziel bringen.

Wie gut es klappt ein etabliertes Schema zu ändern sieht man ja bei den Public-Transport Schematas, wo zu allen Versionen und Ausführungen im Wiki noch irgendwelche Beschreibungen vorhanden sind, die wenigsten noch einen Überblick haben, wie nach dem derzeit gültigen Schema was zu taggen ist usw.

Ist es sinnvoll immer weitere Varianten einzuführen? Denn machen wir uns doch nichts vor, nur weil ein neues Schema hier beschlossen wird, wird das doch nicht morgen Flächendeckend umgesetzt sein. Sondern oneway=yes, reverse und -1 werden weiter in der Datenbank rumgeistern.

Bevor so eine Änderung angegangen wird, sollte man sich vielleicht erstmal über aufbereitete Extrakte gedanken machen, in denen alles auf ein Schema vereinheitlicht wird. Wege die dann mit ocean=left getaggt sind, werden umgedreht, oneway=reverse wird zu oneway=-1, building=entrance wird zu entrance=yes, color wird zu colour usw.

Wenn dann zukünftig eine Änderung kommt, wie oneway=-1 heißt nun backward, dann stellt man paralell einen weiteren Extrakt ein, bei dem alle Änderungen zum vereinheitlichten output, in einem changelog zusammengefasst werden.

Denn diese vielzahl von Nebeneinander existierenden Schematas, die sich jederzeit ändern können machen OSM nicht zuverlässiger…

Das ist dann ein Missverständnis. Bei der Idee geht es nur darum, das bisherige Tagging, dass nur auf der Wegrichtung basiert davon ein Stück zu lösen und zu ermöglichen, dass die Objektrichtung auch gegen die Wegrichtung gerichtet sein kann. Im Prinzip nichts anderes als oneway=yes|-1 auf coastline, cliff, waterway, etc. anwenden.

Das ist im Prinzip das, was einige Editoren (allen voran im übrigen josm) anwendet. left|right und forward|backward sind da jetzt auch keine neuen Schlüsselwörter sondern kalter Kaffee.

In einer Welt, in der Objekte “nie” vollständig getaggt sind muss jeder Auswerter sich defaults überlegen. Bspw. wenn ein track kein surface und track_type hat, dann muss der Auswerter etwas draus machen. Das bedeutet aber nicht, dass der Mapper surface oder track_type bei einem bestimmter Wert weglassen soll.

Ehrllich gesagt den Vorschlag kenne ich nicht. Halte ihn aber für sehr schlecht, da es sehr fehleranfällig ist. Bei den coastlines gibt es derzeit eher den Rat, besser nicht anfassen, wenn man kein “Pro” ist. Wenn man das auf alle Flächen ausweitet…

@BFX: Ja, es kann sinnvoll sein, bestehende Schemas zu ändern. Vorallem weil man vor x-Jahren doch nicht an alles denken konnte.

Zu 1/2: Das ist mir schon klar. Es macht aber einen Unterschied, ob ich eine relativ beschränkte Menge von Schlüsseln mit solchen Ausnahmen habe und danach filtern kann (beispielsweise wird yes in oneway auf -1 gedreht und umgekeht, aber nicht bei anderen Schlüsseln) oder ob es ein allgemeines Schema sein soll, in dem ich das generell anwenden kann. Wenn ich das letztens richtig mitverfolgt habe, macht zumindest iD solche Anpassungen nur bei bestimmten Schlüsseln.

Zu 5: Das bezweifelt niemand. Es macht aber einen Unterschied, ob ich (gut dokumentiert) etwas als implizit annehme oder ob die Definition besagt, die explizite Angabe sei notwendig und im Falle des Fehlens muss ich (undokumentiert) raten, was gemeint sein könnte.

Zu 6: http://blog.jochentopf.com/2012-11-26-an-area-datatype-for-osm.html Kein ganz abwegiger Vorschlag. Insbesondere muss man bedenken, dass die Idee ist, dass sich der Editor um die Reihenfolge kümmert - da er ohnehin den Datentyp unterstützen muss, gibt es das Problem nicht, dass Editoren, die das noch nicht kennen etwas kaputt machen. Deshalb ja auch die Frage, ob man auch in so einem Fall ein explizites Tag forden wollen würde oder ob das auch ohne ginge. Und ob sich zumindest der Coastline Teil der Problematik von selbst lösen würde, wenn ein solcher oder anderer Flächentyp in die API integriert und die Coastlines darauf umgestellt werden.

Nimm das auch bitte nicht so konkret, was ich hier schreibe. Das sollen nur in den Raum geworfene Diskussionsansätze sein, damit solche Randfälle nicht unter die Räder geraten. Das heißt ja nicht, dass es da (jetzt sofort) eine Antwort braucht.

Ziel des Vorschlags ist es, nicht umkehrbare Wege umkehrbar zu machen. Dazu sollen Schlüsselwörter verwendet werden, die bspw. von josm aktuell bereits unterstützt werden. Dazu gehören die Wertepaar forward|backward und left|right. Diese Paare sind universell anwendbar. Entweder beeinflusst die Objektrichtung ob die Eigenschaft nur in eine Wegrichtugn gilt (bspw. oneway, waterway) oder ob eine Seite des Weges eine bestimmte Eigenschaft hat (bspw. coastline, cliff). Die Schlüsselwörter werden aktuell in diversen Schemata als solche verwendet und von u.a. josm so genutzt (also mit gedreht). Ob dieses Verhalten (ich erinnere mich bisher an keine Probleme damit) in aller Ewigkeit so funktionieren wird, oder ob der Editor da mehr Gehirnschmalz reinstecken muss, wird sich wohl in der Zukunft zeigen. Aber wie gesagt, dass ist nichts, was durch den Vorschlag neu hinzukommt.

josm macht left zu right, wenn left alleine steht oder mit : abgegrenzt ist. Für die anderen Schlüsselworte analog.

Als Auswerter würde ich mir Wegrichtung==Objektrichtung als Default überlegen. Das entpricht der aktuellen Nutzung und wohl auch der logischen Denkweise bei vielen Objekten. Das “ratet” aktuell auch jeder Auswerter so. Mit dem Vorschlag gehen die Problemfälle (falsch geraten) eher zurück, weil die Objektrichtung geändert werden kann.

Aber gerade das bedeutet ja, dass etwas neues geschaffen werden würde, nämlich eine ganze Menge neuer Tags, mit denen die Richtung dann erfasst wird.

Dann nehmen wir doch mal als anderes Beispiel an, in einem Land mit Rechtsverkehr gibt es eine Straße, die Ausnahmsweise Linksverkehr hat, weil an dieser Stelle gerade die Schiffe so herum anlegen oder was auch immer, und ich möchte das als *=left o.ä. taggen. Dreht nun jemand den Weg um und macht ein *=right daraus, ist das Murks, weil die Straße natürlich immer noch Linksverkehr hat, egal in welcher Richtung man es betrachtet.

Und da es immer Mapper geben wird, die solche Editoren benutzen, schmilzt der Vorteil nicht nur dahin, sondern führt zum Chaos, weil dann verschiedene Editoren verschiedene Taggingschemata benutzen…

Aktuell gibt es eine eindeutige Vorschrift, was der Auswerter zu tun hat: Er benutzt die implizierte Richtung, wie sie im Wiki dokumentiert ist. Wenn eine Richtung weder impliziert noch explizit getaggt ist, gibt es keine solche eindeutige Vorschrift mehr und der Auswerter kann bestenfalls ein “undefiniertes Verhalten” zeigen - also einfach gesagt Murks liefern.

Das ist das aktuelle Verhalten von josm (wie bereits erläutert), was nicht erst seid gestern existiert und hat nichts mit dem Vorschlag zutun. Es ist lediglich ein Hinweis, dass Editoren das bereits länger unterstützen bzw. anwenden. Ob das gut oder schlecht ist solltet ihr mit den Codern besprechen. :wink:

Du vergleichst gerade Äpfel mit Birnen, in dem du davon ausgehst, das aktuell alle Richtungsabhängigkeiten immer korrekt getaggt sind und mit dem neuen System das anders wird. Dann ist es nicht unlogisch, dass es mit dem neuen System schlechter wird.

Was wird meiner Meinung nach (am Beispiel von coastline) passieren:
An den vorhandenen Elementen ändert sich erstmal nichts.
Nun kommt ein Mapper und dreht einen Weg um, der Editor fügt einen Tag <coastline=falsch herum> hinzu, er könnte auch einen Umkehr-Frage-Dialog dazwischen schalten, wie es josm aktuell bei oneway macht. Aktuell würde josm fragen, ob das gewollt ist (ala “Sind sie sicher?”, was jeder Windowsnutzer schon automatisch weg klickt).

Unterschied: Im besten Fall kein Unterschied, im DAU-Fall sehe ich hier einen Vorteil für das neue System, weil der Editor die Objektrichtung anpassen kann.

Der Auswerter kann beim Fehlen einer Objektrichtungsumkehr alles so machen, wie jetzt auch, er kann aber zusätzlich die Richtungsumkehr auswerten, bzw. bei manchen Objekten auch anzeigen, dass die Richtung nicht bekannt ist. Stichwort: Fehlerkarte.

Meiner Meinung nach schließen sich die beiden Vorgehensweisen implizit vs. explizit nicht aus.
Bei allen richtungsabhängen Objekten (forward-backward, up-down, left-right etc) könnte es eine implizite Definition geben, so wie sie bisher vereinbart war. Dann muss kein einziger way umgetaggt werden und das muss die Minimalbasis für jeden Editor und Renderer sein.
Zusätzlich kann es explizite Tags geben, die von Editoren umgedreht werden können, die sie verstehen, bzw. die von Renderen interpretiert werden können.
Alle anderen ignorieren die expliziten Tags. Dann kann es natürlich passieren, dass die eingetragene Richtung entgegengesetzt der impliziten ist, aber dann sieht man das (anders als bisher) wenigstens. Wenn nichts eingetragen wird, bleibt es bei der bisherigen Interpretation und die ist so richtig oder falsch wie bisher auch.

OSM wird immer mit dem Spagat von wenigen erfahrenen und einer Vielzahl von Gelegenheitsmappern leben müssen. Die letzteren braucht es einfach, um die angestrebte Detailliertheit und Aktualität zu erhalten und für sie muss die Zugangsschwelle möglichst niedrig sein. Bei von mir weniger genutzten tags wie cliff oder coastline muss ich jedesmal nachsehen, wie rum es (implizit) gemacht werden muss.

Ein Zusatztag wie
natural=coastline
coastline:water=left

halte ich dabei für unmissverständlicher als z.B.
ocean=left

Implizite Richtungen abzulösen (zu “verbieten”), halte ich bei einem inzwischen so großen Projekt für undurchführbar.
Explizite Richtungen zusätzlich erscheinen mir bei einer begrenzten Zahl von Tags für vertretbar.

Aber der Vorschlag ist doch gerade, Objekte, die bisher eine implizite Richtung haben, nun explizit mit left/right/forward/backward/wwi zu taggen, damit die Editoren durch “einfaches Umdrehen” ein “richtiges” Ergebnis erzeugen, und mein Beispiel soll eben zeigen, dass es in diesem Fall Murks ergibt, wenn man einfach davon ausgeht, dass die Umkehr eines Weges generell einem Austausch von left und right entspricht.

Nein, davon gehe ich nicht aus und das habe ich auch nirgends behauptet. Ich habe nur gesagt, dass es derzeit relativ wenige Fehler in Küstenlinien gibt, bezogen auf ihre gesamte Länge und die Anzahl der involvierten Wege. Und genau deshalb…

Und genau da liegt der Fehler. Wenn jemand Warnungen einfach wegklickt und ignoriert, riskiert er die Produktion von Datenmüll. Ob das nun eine kaputte Küste, ein kaputtes Multipolygon, eine kaputte Routenrelation oder was auch immer ist.

Bei seiner Tätigkeit als Datenmüllproduzent lässt sich ein DAU auch nicht von einem Editor aufhalten, der mal eben die Tags umdreht. Der DAU stellt höchstens verwundert fest, dass aus dem left auf einmal ein right geworden ist, und stellt den “richtigen” Wert wieder her (wobei ich hier natürlich vom wörtlichen DAU ausgehe).

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.

Nicht kann, sondern muss. Jeder Auswerter, der nicht an ein solches neues Schema angepasst ist bzw. die neuen Richtungstags nicht kennt, wird nur noch Murks produzieren, weil er weiter von den impliziten Richtungen ausgeht.

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.

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.