Unumkehrbare ways

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

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.

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.

aighes wrote:

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.

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

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.

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

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

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.

Jimmy_K wrote:

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

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

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

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

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.

chris66 wrote:

Wegen eines unausgereiften Editors alteingesessene Tags umändern?

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

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.

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.

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

fx99 wrote:

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

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.

Tordanik wrote:

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

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

Tordanik wrote:

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.

Klingt vernünftig.

fx99 wrote:

Meiner Meinung ist die implizierte Richtungsabhängigkeit ein einziger Schmarrn .....

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! )

Zecke wrote:

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

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?

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)?

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

Zu2: position=left klingt wie "english for runaways" 😉

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

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.

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.

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

errt wrote:

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.

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.

errt wrote:

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.

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.

errt wrote:

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.

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.

errt wrote:

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.

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-a … r-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.

errt wrote:

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.

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.

errt wrote:

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.

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.

aighes wrote:

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

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.

Zu2: position=left klingt wie "english for runaways" 😉

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.

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.

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

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

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.

MHohmann wrote:

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

MHohmann wrote:

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.

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.

aighes wrote:

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.

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.