[Talk-at] Keepright wieder voll aktiv

[Friedrich Volkmann]

On 19.05.2016 23:47, Borut Maricic wrote:
> Bitte um eine kurze Erklärung/Beispiel, was ist mit dem
> "multiple nodes on the same spot" und dem "deprecated tags"
> schlimm, bzw. wurde als nicht stimmig beobachtet.
> 
> Ich kann mich nicht erinnern, dass ein Hinweis auf "multiple
> nodes on the same spot" eigentlich falsch war. Aus meiner
> Sicht war bei allen solchen Fällen, die ich mir angeschaut
> habe, ein Tagging-Fehler vorhanden. Vielleicht ist meine
> Sichtweise falsch?

Der Hinweis an sich ist nicht falsch, es sind bei jedem Hinweis wirklich 2
Nodes an der selben Stelle. Aber falsch ist die Darstellung als Fehler, denn
die deckungsgleichen Nodes sind oft Absicht.

Beispiel 1: auf einem Steinmann (Node 1164573741) steht ein Kreuz (1164573742)
Beispiel 2: ein Kreuz (3185386326) mit einem Namen steht auf einem Gipfel
(1328393372) mit einem anderen Namen
Beispiel 3: Auf vielen Abschnitten der 1. Hochquellenwasserleitung verläuft
genau oberhalb ein track oder path. Ich habe vor ein paar Jahren viel Mühe
investiert um die Wege vom Rohr zu trennen, da sie keinen Kontakt
miteinander haben. (Es ist das gleiche wie bei einer Straßenbrücke über
einen Bach, da macht man ja auch keinen gemeinsamen Node.) D.h. jeder Node
musste verdoppelt werden, so dass kein Node der Wasserleitung zugleich Teil
eines Weges ist. Irgendwann kam dann jemand und hat die Nodes wieder
vereinigt, wahrscheinilch angestiftet durch Keepright. Das ist um so
ärgerlicher, als das Erstellen der deckungsgleichen Nodes viel aufwendiger
war als das Hinmachen. Der einzige Vorteil von Keepright ist jetzt, dass man
es als Kontraindikator nutzen kann: Dort, wo es einen Fehler anzeigt, ist es
richtig gemappt, und umgekehrt.

Die Prüfung wäre brauchbar, wenn sie nur dann anschlüge, wenn die Nodes und
alle Wege, in denen sie vorkommen, den selben Layer haben.

> Dem "deprecated tags" habe ich oft gefolgt, meistens beim
> Taggen von Eingängen. Habe dem Keepright in diesen Fällen
> blind vertraut, muss ich sagen.

Ein grundlegendes Problem einer Prüfung auf "deprecated tags" ist, dass sie
entweder bedeutungsgleich mit neueren Tags sind - dann muss man sich aber
fragen, was an den neueren Tags überhaupt besser sein soll; oder sie sind
nicht bedeutungsgleich, dann ist jedes Umtaggen aber mit einer
Bedeutungsänderung oder sogar mit einem Informationsverlust verbunden. Das
wird klar, wenn man sich einige Tags anschaut, die Keepright für deprecated
hält:

1.) landuse=farm: Das ist in Wahrheit gar nicht deprecated, sondern völlig
gleichbedeutend und gleichwertig mit landuse=farmland. Ich benutze für neue
Objekte grundsätzlich nur landuse=farm, weil es kürzer ist (ich will nicht
unnötig viel tippen) und weil es das schon länger gibt. landuse=farmland kam
nur durch einen Editorbug in Gebrauch, und eigentlich sollte man alle
landuse=farmland auf landuse=farm korrigieren und den Editorbug endlich fixen.

2.) drinkable=*: Die neuere Alternative drinking_water=* hat genau die
gleichen Werte (yes, no) und einen zusätzlichen (conditional), von dem
keiner weiß, was er bedeuten soll. Vorgesehen waren im ursprünglichen
Proposal auch Werte wie "mineral", aber dann ist man in der Diskussion
draufgekommen, dass man keine klare Grenze ziehen kann. Am Ende wurde kein
Elefant, sondern eine Maus geboren. Das Proposal wurde von 13 Leuten
angenommen, die sie sich anscheinend nicht (mehr) bewusst waren, dass der
neue Key gleichbedeutend mit dem alten ist.

3.) building=entrance: Ich muss zugeben, dass ich entrance=* anfangs für
einen großen Fortschritt gehalten habe, aber inzwischen bin ich mir nicht
mehr so sicher. Was ist, wenn ein Tor als Eingang in zwei verschiedene
Objekte fungiert, z.B. in einen Shop und ins Gebäude, in dem sich der Shop
befindet. Dann ist der Eingang vielleicht der Haupteingang in den Shop, aber
nur ein Nebeneingang ins Gebäude. Soll man ihn dann entrance=main taggen?
Dieses Beispiel lässt den Vorteil verschiedener Werte wie ein Kartenhaus
zusammenfallen. Außer diesen Werten bringen aber weder building=entrance
noch entrance=* irgendeine zusätzliche Information zu barrier=*.

4.) highway=ford: Es gab darüber noch nicht mal eine Abstimmung, und
zumindest bei Nodes sehe ich nichts, was an ford=yes besser sein soll.

5.) wood=*: Ich will bei der von Ignoranz und Unwissenheit geprägten
Einführung von leaf_type und leaf_cycle nicht ins Detail gehen. Fest steht,
dass type=* bei Einzelbäumen nicht mal durch eine Kombination aus beiden
neuen Tags ersetzbar ist, weil die Unterscheidbarkeit zwischen Palmen und
anderen immergrünen Taxa verloren geht. Bei einem ganzen Wald sind diese
Tags noch nutzloser, weil ein Wald - von Monokulturen abgesehen - zahlreiche
Arten umfasst, die unterschiedliche Eigenschaften haben. Aus dem selben
Grund finde ich auch wood=* entbehrlich, aber es korrespondiert wenigstens
mit einer landläufigen Einteilung in Laub-/Misch-/Nadelwald. Will man mehr
ins Details gehen, dann empfehle ich, Nägel mit Köpfen zu machen und die
Pflanzengesellschaft zu taggen, z.B. mittels plant_community=*. Keepright
schlägt nun aber dem Faß den Boden aus, indem es als Ersatz für wood=* nur
leaf_type=* vorschlägt.

Genauer gesagt wird das neue Tag nicht nur vorgeschlagen (consider using a
tag like...), sondern als einzige akzeptable Lösung dargestellt ("please use
... instead). Indem der Keepright-Anwender Fall für Fall dieser "deprecated"
Tags durchgeht und in jedem dieser Fälle die befohlene Änderung durchführt,
wird er zum Werkzeug eines Massenedits.

Im Grunde ist jeder Validator ein Meta-Massenedit. Selbst wenn man die Edits
eines einzelnen Users revertiert, kommt irgendwann der nächste und
übernächste. Es ist wie mit der Hydra: Immer wenn man ihr einen Kopf
abschneidet, wachsen 2 neue nach.

Wegen ähnlicher Prüfungen haben auch immer wieder Leute massenhaft
power=sub_station auf substation umgetaggt, und in Wien hat jemand alle
Bäume von type=* auf leave_type=* umgetaggt.

-- 
Friedrich K. Volkmann       http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria