Unumkehrbare ways

Communities Deutschland (Germany)
1

Hi,
auf talk-de lief eine Diskussion über den neuen ID. Beim Thema way umdrehen sind wir darauf gekommen, dass es sinnvoll ist, die ganzen richtungsabhänigen tags so zu verändern/ergänzen, dass sie richtungsunabhängig werden.

Konkret:

Aus
oneway = yes/reverse/1/-1
wird
oneway = forward/backward

Aus
natural = coastline
wird
natural = coastline
ocean = left/right

Aus
natural = cliff
wird
natural = cliff
cliff:downside = left/right

Ebenso embankment, retaining_wall

Damit wird zwar fast überall ein tag mehr benötigt, gleichzeitig aber eine Fehlerquelle bei Mappen, Auswerten und in den Editoren abgestellt.

Die Resonanz auf talk-de war positiv, wenn auch die genauen subtags noch in der Diskussion sind.

Meinungen?

2

Wegen eines unausgereiften Editors alteingesessene Tags umändern?
-1

3

Sehe ich genau so - das Taggingschema hat sich bewährt und funktioniert gut. Wenn ein Editor damit Probleme hat, gehört der Editor verbessert, nicht das Schema.

4

Funktioniert gut??? Die Küstenlinie ist regelmäßig kaputt, weil irgendwer einen Weg mal umdreht und das auch schon vor iD. Der Mapper könnte endlich mitteilen, dass er sich bei der Richtung etwas gedacht hat. Von diversen importierten Objekten, die in der falschen Richtung sind möchte ich nicht reden.

5

naja, aber die eingangs erwähnte Lösung ist ja auch keine. Nehmen wir mal einen Oneway. Ob nun yes oder forward ist doch egal, man muss eine Richtung definieren. Man kann keine richtungsabhängigen Tags richtungsunabhängig beschreiben. Wo ist denn links wenn der Weg keine bestimmte Richtung hat. Wie soll das gehen ausser oneway=261grad oder embarkment=NE, wo es dann egal wäre wohin der Weg zeigt

6

Das Problem ist doch nicht, dass der Weg gerichtet ist, sondern dass es manche Tags gibt, dessen Richtungsbedeutung man nicht umkehren kann. Bei oneway kann ich sagen, dass die Einbahnstraßenrichtung gegen die Wegrichtung verläuft. Bei natural=coastline bspw. geht das nicht.

7

Ich verstehe nicht, worin da die Lösung liegt.

Wo ist der Unterschied, ob von oneway = yes auf -1 geändert wird, oder oneway = forward auf backward?

Zur coastline muss ich sagen, wäre es definitiv die leichtere Variante, wenn iD das Drehen verbieten würde.

8

… oder die Datenbank die falsche Richtung nicht akzeptiert. Damit hätte man alle aktuellen und zukünftigen Editoren abgedeckt.

9

Das ist kein iD-Problem. Auch mit josm kann man die coastline drehen :wink:

10

Ich finde die Fehlerquote bei der Coastline ( die ja immerhin einige Millionen 356.000 Kilometer lang ist ) relativ gering. :stuck_out_tongue:

11

Es geht nicht darum, das Umkehren eines Weges für Editoren zu erlauben oder zu verbieten.

Beim Mappen wie beim Auswerten muss sich der Betroffene erst einmal durch xx Seiten von Wikis kämpfen, bis er die korrekte Richtung aller Wege festgestellt hat. Das ist fehleranfällig und verkompliziert Mapping und Auswertung unnötig.

Hinzu kommt, dass durch Umdrehen des Weges Fehler entstehen. Das Umdrehen verbieten zu wollen, ist letztlich ein Wettlauf der Editor-Versionen gegen immer neue unumdrehbare tags. Das führt früher oder später dazu, dass die Editoren dem Mapper immer mehr Beschränkungen auferlegen. Das ist aber gerade der Weg, den wir bei OSM nicht wollen.

Die betroffenen tags sind historisch gewachsen zu einer Zeit, als sich noch niemand Gedanken gemacht hat. Oneway mit yes ist noch ganz gut verständlich. Die coastlline galt immer als Sonderfall. Das cliff kam dann dazu, dann weitere, immer als Sonderfall. Wenn OSM nicht als undurchdringlicher Sonderfall enden soll, müssen wir rechtzeitig handeln.

Im Moment sind es noch weniger als 10 tags. Natürlich könnte man für oneway den Sonderfall yes lassen, aber warum? Nur weil es das solange gibt? Weil man sich das noch merken kann? Bei coastline kann man wenigstens noch nachsehen, in welche Richtung die bestehende Linie läuft. Aber auch das kann bereits falsch sein. Anfänger ahnen nicht einmal, dass die tags richtungsabhängig sind.

Forward/backward bzw. right/left ist mindestens genauso logisch und einfach verständlich. Es hat aber den Vorteil, dass einfach jeder Editor diese Wertepaare austauschen kann. Nur sie werden beim Umdrehen getauscht, alle anderen nicht. Eine einfache Regel für alle Anwendungsfälle und kein Irrgarten aus Verboten und Beschränkungen, die letztlich nie vollständig sein werden.

Für bestehende Software gibt es nur die Veränderung, dass die Linie vor der Verarbeitung intern umgedreht werden muss, falls sie in die Gegenrichtung zeigt. Das kann die Software an den tags problemlos erkennen.

Das Muster zum Austausch ist recht einfach. Immer wenn diese tags durch Doppelpunkte getrennt (oder einzeln/am Ende) stehen, wird ausgetausch, sonst nicht. Auch josm macht „bright“ nicht mehr zu „bleft“ (getestet).

Das wird nicht über Nacht geändert, aber mit etwas gutem Willen sollte es möglich sein, eine Fehlerquelle und unnötiges Nachschlagen im Wiki zu eliminieren, was das Mappen für alle einfacher und schneller macht.

Für neue Mapper wird es einfacher, und die erfahrenen Mapper werden sich nach ein paar Wochen daran gewöhnt haben.

12

Nein: Anlässlich der Einführung eines neuen Editors feststellen, dass die “alteingesessenen” Tags eigentlich ganz unabhängig vom Editor ziemlich verbesserungswürdig sind. :wink:

Die Idee von der Mailingliste ist:

  1. Man hat keine implizit richtungsabhängigen Tags mehr.
  2. Bei explizit richtungsabhängigen Tags beschränkt man sich auf die Werte forward/backward/left/right.

Dadurch wäre es sehr einfach, auch unbekannte richtungsabhängige Tags korrekt zu behandeln. JOSM tut das ja bereits, eben auf Grundlage der Annahme, dass ein alleinstehendes Wort aus der o.g. Liste Richtungsabhängigkeit signalisiert. Auch Mappern wäre die Richtungsabhängigkeit klarer, wenn sie durch ein gesondertes Tag verdeutlicht würde - es ist ja nicht offensichtlich, dass cliff oder coastline niemals bedeutungserhaltend umgedreht werden können.

Als Bonus würde man das nicht wirklich verständliche “-1” los. Und bei manchen Werten - nämlich bei Rolltreppen, Flüssen oder wo man sonst Sonderwerte wie ‘wechselnd’ hat - braucht man nicht einmal einen neuen Schlüssel, denn das ist implizit gar nicht ausdrückbar.

Von daher finde ich den Vorschlag gar nicht so doof und wäre dafür zu haben.

13

Ich denke, man sollte sich einfach von Anfang an, vor dem Editieren, bewusst darüber sein, dass ein Weg im OSM-Datenmodell eine gerichtete Abfolge von Knoten ist, und dass seine Richtung damit per Definitionem eine Bedeutung hat - und man ihn folglich nicht einfach umdrehen darf, ohne damit seine Bedeutung zu verändern. Editoren wie JOSM warnen ja immerhin, wenn man die Richtung einer Linie umkehrt, die bestimmte Tags hat - vielleicht sollte man generell bei einem solchen Vorgang eine Warnung anzeigen, auch wenn keine solchen Tags vorhanden sind.

Ich sehe das genau wie chris66 und Jimmy_K: Bezogen auf ihre Länge sind die Küstenlinien erstaunlich selten “kaputt” - und es gibt damit seltener Probleme als mit Multipolygonen. Und davor, dass ein unwissender Mapper einen Weg mit einem Editor umdreht, der von :left und :right nichts weiß, schützt ein solches Tagging auch nicht. Das würde einige Softwareupdates erfordern, und ob bei so einem großflächigen Update jede Software mitkommt, ist eine ganz andere Frage. Ich denke, da würde die Umstellung eher zu Chaos führen.

Das vorgeschlagene Tagging mag durchaus etwas intuitiver ausdrücken, welcher Richtung welche Bedeutung zugeordnet ist. Allerdings ist Intuition nicht das einzige (und vermutlich nicht einmal das primäre) Kriterium bei der Wahl eines Taggingschemas - letztlich sollte es möglichst “einfach” sein, und man mag darüber streiten, ob es “einfacher” ist, die Richtung explizit zu taggen oder sie bereits implizit im getaggten Objekt (coastline, embankment, oneway) einzubauen. Von der Datenstruktur her finde ich letzteres simpler, weil man nur ein Tag braucht und nicht zwei.

Sicher mag es ein Vorteil sein, wenn man die Bedeutung der Richtung nicht im Wiki nachlesen muss - aber letztlich muss man die Bedeutung der Tags (nicht nur der richtungsabhängigen, sondern aller Tags) doch ohnehin einer Quelle wie dem Wiki entnehmen. Woher soll man sonst wissen, was für Wege ein tracktype=grade3 umfasst oder wie man Busrouten nach Public Transport Schema erfasst?

Ich will damit nicht sagen, dass ein Mapper sämtliche Tags und ihre Bedeutung auswendig kennen muss. Aber zumindest sollte er die Tags der Objekte kennen, die er bearbeitet, und sich dessen bewusst sein, dass die Richtung der Wege genau so eine Bedeutung hat wie ihre Tags.

14

Meiner Meinung ist die implizierte Richtungsabhängigkeit ein einziger Schmarrn …
es gibt noch viele weitere Beispiele, wo sich die Richtung eines Weges nicht ohne Sinnänderung umdrehen lässt, wie z.B. Parking:right/left, bicycle lanes.
Warum kann man in einen geographischen Projekt nicht auf die absoluten Himmelrichtungen umsteigen?
Für Leute, die nicht wissen, wo Norden ist, bieten sich die normalerweise identischen Richtungen auf dem Bildschirm an: oben=top=Norden, links=left=Westen, …

15

Weil Wege auch Kurven haben können und nicht immer in eine bestimmte Himmelsrichtung gehen! Sorry aber hier würde statt eindeutiger Festlegung plötzlich Spekulation ins Spiel kommen.

16

Grundlegende Taggingschemata ändern? Du mußt ein Idealist sein! :slight_smile:

Klingt vernünftig.

Und zwar (IMO ausschließlich) deshalb, weil sie nicht selbsterklärend ist und dadurch zu Tagging-Fehlern führt.

Das Umdrehen der Richtung eines Weges kann und sollte ein Editor bei richtigungsabhängigen Features von sich aus mit einer Warnung quittieren, bei der man angeben kann, ob das bedeutungsneutral erfolgen soll (reine Kosmetik, dann würden left/right und forward/backward beim Umdrehen angepasst) oder mit Wirkung (dann bleiben die Tags unverändert).
Editoren sollten eigentlich alle Wege (spätestens, sobald das erste richtungsabhängige tag dranhängt) mit Richtungspfeilen o.ä. darstellen, damit auch der unerfahrenste Mapper merkt, daß hier die Richtung eine Rolle spielt.

Gruß,
Zecke

…oO ( träum vielleicht bekommen wir dann ja sogar eine zeitnahe Darstellung von Küstenedits! )

17

Und genau dafür braucht es einen Tag, den der Editor ändern kann.

Zu Editor beschränken: Das finde ich eine eher schlechte Idee. Erstens ist unsere Tagbasis unbeschränkt. Das bedeutet, ein Editor wird nicht 100% der Tags kennen, die gedreht werden müssen. In Neuseeland gab es vor kurzem bspw. einen größeren Import von Klippen. Hier stellt sich mir dann bspw. die Frage ob die alle nach der Richtungsnotation eingetragen sind. Dito bei so manchem Fluss.
Ist es in so einem Fall überhaupt sinnvoll, einen Weg automatisch zu drehen? Braucht es nicht auch bei der Richtungsabhängigkeit eine Möglichkeit zu sagen, die Richtung ist nicht erfasst worden?

18

Ich sehe prinzipiell vor allem diese Probleme:

  1. Tags, die sich nicht in dieses Schema pressen lassen. Das könnte beispielsweise daran liegen, dass mehr Richtungen benötigt werden (z.B. halb-rechts) oder dass der richtungsabhängige Wert im Schlüssel steht (cycleway:left/right). Zugegebenermaßen verschlechtert sich die Situation bei der ersten Klasse nicht und für die zweite muss die Definition eben noch auf Schlüsselbestandteile ausgeweitet werden.
  2. Tags, die diese Werte verwenden, aber nicht richtungsabhängig sind. Oder deren richtungsabhängigkeit implizit, aber nicht von der Wegrichtung ist. Mir fällt kein sinnvolles Beispiel ein, aber nehmen wir mal hypothetisch an, ich würde Parteizentralen mit der politischen Ausrichtung taggen (party=spd, position=left), dann sollte das der Editor ja nicht umdrehen.
  3. Was ist mit Implikationen auf anderer Ebene? highway=motorway impliziert oneway=yes. Soll diese Implikation ebenfalls wegfallen und alle highway=motorway mit oneway=forward versehen werden?
  4. Auf welcher Ebene soll hier reagiert werden? Soll die API sich darum kümmern oder die Editoren? Wenn die Editoren dafür verantwortlich sind, wird es immer Editoren geben, die das vergessen oder nicht komplett umsetzen.
  5. Wie reagiert man auf Mapper, die sich nicht bewusst sind, das ein explizites Tag notwendig ist und es weglassen? Auch hier die Frage: Soll die API eingreifen oder doch der Editor?
  6. Es gab mal einen Vorschlag für einen Flächendatentyp (der mir recht gut gefallen hat), der vorsah, dass die Frage, was innen und was außen ist, wie bei coastline, durch die Wegrichtung bestimmt wird. Sollte auch hier auf das explizite Tag ausgewichen werden, was zu einem Haufen relativ irrelevanter Daten führen würd, oder würde man für einen solchen Spezialfall (da ein neuer Datentyp ohnehin vom Editor unterstützt werden müsste) beim impliziten Verfahren bleiben?
  7. So wie ich den Vorschlag verstehe soll für praktisch jedes richtungsabhängige Tag ein eigenes Zusatztag eingeführt werden. Das ist einerseits sinnvoll, weil man sich so nicht in die Quere kommt, wirft aber auch Fragen auf. Wer definiert wann und wo für alle bisherigen und zukünftigen richtungsabhängigen Tags das Zusatztag? Könnte man das vielleicht in ein Schema pressen (z.B. oneway:direction=, coastline:direction=, etc.)? Wie konkret müssen die Zusatzschlüssel sein (‘ocean’ sagt nichts darüber aus, dass hier eine Seite erwartet wird, also würden wahrscheinlich bald Leute anfangen, ocean=Nordsee zu taggen)?
19

Zu1: Es geht nicht darum etwas neues zu schaffen, sondern darum, eine bestehende Implizierung in ein Tag auszulagern, sodass die Bedeutung der Implizierung an die Wegrichtung angepasst werden kann. Bei einem Weg gibt es nur zwei Richtungen. Halb-“irgendwas” hat eine Wegrichtung nicht. :wink:

Zu2: position=left klingt wie “english for runaways” :wink:

Zu4: Auf ebene der Editoren. Ja, es kann immer Editoren geben, die sagen “Juckt mich nicht”, genauso wie es aktuell Mapper gibt, die sagen “wird schon passen”, wenn josm bspw. fragt, ob man die coastline wirklich umdrehen möchte. Der Vorteil ist aber, dass ein Editor darauf reagieren kann und das man ihm das einmal beibringen muss und nicht für jedes neue Tagging, dass auf eine Richtung baut.

Zu5: Wenn der Mapper keinen Einfluss auf die Richtungsbedeutung nimmt, kommt auch keine in die Daten. Es ist dann Sache des Editors evtl. eine Nachfrage zu machen, was der Mapper meint oder nicht. Die Auswerter werden solche Wege wohl behandeln wie es aktuell der Fall ist. Irgendwas müssen sie ja machen. :wink:

Zu6: Bei einer geschlossenen Fläche (aktuell: Polygon oder Multipolygon) ist doch klar, was “ausgemalt” werden soll und was nicht. Das hat mit dieser Sache nichts zutun.

Zu7: Die Gefahr das Mapper Unsinn taggen besteht immer. Wegen die “wie” des Schemas diskutieren wir ja. Mir würde ein oneway:forward=yes oder ocean:left=yes am besten gefallen. coastline:direction=forward fände ich jetzt nicht unbedingt selbsterklärend.

20

Zu 1: Oben wurde angesprochen, damit auch künftige Spezialfälle erschlagen zu wollen. Und es ist durchaus möglich, dass ein künftiges Tag Dinge, die teilweise in Wegrichtung liegen erfassen möchte, zumal solche Tags z.B. für Abbiegespuren meines Wissens schon existieren. Selbst wenn man solche Tags hier nicht meint, rutscht man damit in Kategorie 2, weil man dann manche Werte (nämlich z.B. left, right) umkehren würde, andere (eben z.B. half-left) aber nicht.

Zu 2: Wie gesagt, kein besonders gutes Beispiel, aber ich hoffe es zeigt, was ich meine. Im Übrigen heißt es in der englischen Wikipedia zur SPD political position: Centre-left, so abwegig ist das also nicht.

Zu 5: Wenn die Auswerter es behandeln, wie es aktuell der Fall ist, haben wir aber weiterhin implizite Standards - nur dass sie dann wohl nicht mehr richtig dokumentiert werden würden.

Zu 6: So klar ist das durchaus nicht. Wir nehmen aktuell für geschlossene Wege die kleinere der beiden dadurch definierten Flächen. Aber darauf habe ich mich ja auch nicht bezogen, sondern auf den Vorschlag (den ich gerade nicht mehr finde), in dem das implizit wäre - was durchaus Sinn macht, dann braucht man nämlich nicht alle zur Fläche gehörenden Wege zum Rendern eines Ausschnitts. Genau deshalb sind ja die coastlines, wie sie bisher sind. Insofern sehe ich durchaus einen Zusammenhang.

Zu 7: Genau deshalb sprech ich das an. Wobei das mit Unsinn taggenden Mappern wenig zu tun hat - mehr mit der Frage, wie so ein Schlüssel aussehen müsste - wie du sagts, ist natürlich ein coastline:direction eben auch nicht selbsterklärend.