OpenStreetMap Forum

aighes

Member

From: Shanghai

Registered: 2009-03-29

Posts: 5,383

Website

Re: Unumkehrbare ways

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.

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.

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.

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.

---

Viele Grüße
Henning

seichter

Member

Registered: 2011-05-21

Posts: 3,337

Re: Unumkehrbare ways

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.

Last edited by seichter (2013-05-20 17:42:08)

MHohmann

Member

From: Tartu, Estonia

Registered: 2009-06-07

Posts: 1,600

Website

Re: Unumkehrbare ways

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.

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.

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.

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...

...ist es nicht unlogisch, dass es mit dem neuen System schlechter wird.

...was jeder Windowsnutzer schon automatisch weg klickt).

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.

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.

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.

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.

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.

---

SotM Baltics, 3.-4. August 2013, Tartu, Estonia: amenity=university, mappers=yes

Osmonav

Member

Registered: 2013-05-19

Posts: 33

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.

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.