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 _______________________________________________ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at