WIE wird Tagging Bereinigung nach Software Change durchgeführt?

Hallo zusammen,

ich würde gerne wissen, WIE man eine größere, fachlich einfache, Tagging Bereinigung praktisch durchführt ohne Regeln zu verletzen? Gibt es ein Best Practice? Gibt es einen Konsens in der Community?

Hintergrund meiner Frage ist, dass eine JOSM Vorlage korrigiert wurde, ein ja/nein-Tag wurde durch ein anderes ja/nein-Tag ersetzt. Und da JOSM Vorlagen rege verwendet werden, gibt es in der Datenbank etliche Taggings, die bereinigt werden sollten.

WAS gemacht werden soll ist fachlich-inhaltlich simpel: Ersetze das alte ja/nein-Tagging durch das neue ja/nein-Tagging gemäß der JOSM Vorlage, konkret: ersetze lock=yes/no durch lockable=yes/no für amenity=hunting_stand.

WIE aber führt man eine solche Tagging Bereinigung nun praktisch durch? Welcher Weg ist ok? Welcher Weg ist nicht ok? Manuell nach und nach umsetzen? Eine Art Hackday organisieren? In Jochen Topfs Datenbereinigung als ToDo eintragen? Was ganz anderes?

Ich freue mich auf praktische Tipps bzw. eine konstruktive und sachliche Diskussion.

Hallo sperlingskauz,

ich verstehe Deine Frage bzgl. Verletzung von Regeln nicht.

Du hast doch schon großflächige Änderungen zu dem Sachverhalt vorgenommen und bestätigt, dass Du diese vorher diskutiert hast:

https://www.openstreetmap.org/changeset/50893751#map=8/54.310/9.789

Gruß

Svalbard

Unabhängig von der Diskussionsfrage scheint mir das nach seiner Beschreibung dort im CS kein automated edit gewesen zu sein, da er sich demnach gebietsweise jedes Objekt auf Plausibilität angeschaut hat. Erleichtert wahrscheinlich durch die Überlegung, dass lock=yes das Vorhandensein eines Wasserweges voraussetzt.

So habe ich auch die großen „landuse=farm“-Flächen in England beseitigt: landuse=farm aus overpass-turbo in JOSM exportiert, dann Quadratmeile für Quadratmeile alles markiert, was auf Bing oder der Größe nach (Gehöfte nehmen im Allgemeinen keine 20 ha ein) offenbar Anbaufläche ist, aus der so gesammelten Auswahl kollektiv landuse=farmland gemacht, der Rest war dann (wieder nach Einzelprüfung) farmyard. Ging erstaunlich schnell.

–ks

Im Zusammenhang mit amenity=hunting_stand ist es sogar ein Fehler - da lock=* eine Schleuse "Wasserstraße) beschreibt

nicht verwenden:
“lock=yes/no, Hochsitz versperrbar (mit Schloss) — es gibt Überschneidungen zu Key:lock für Schleusen”

So eine Änderung ist m.E. eine Richtigstellung von Fehlern.

Wenn es ein eindeutiger Fehler in JOSM war, dann sollte das IMHO auch in JOSM in die Liste der automatisch zu korrigierenden Tags rein.

Nein. never. ever.

Hallo,

die Grenzen zwischen einem mechanischen Edit, der ohne vorherige Diskussion eine Regelverletzung wäre, und einer Umtaggingaktion sind nicht ganz scharf.

Offensichtlich ist es, wenn jemand mit einem Skript/Programm (d.h. richtig automatisiert) oder gar einem Bot rangeht. Dann gilt der Automated Edits Code of Conduct.

Wenn jemand hingegen sich von der Overpass-API Objekte mit einem bestimmten Tagging in JOSM lädt und dann viele Objekte auf einmal editiert, kommt es auf die Umstände an. Es ist ein mechanischer Edit, wenn die Objekte nicht weiter manuell geprüft wurden. Das kann man nachweisen, indem man gezielt nach Fehlern des Automatismus sucht.

Wenn die Objekte einzeln geprüft werden, ist es kein mechanischer Edit mehr, eine Diskussion ist aber in vielen Fällen angebracht. Eine feste Regel gibt es dafür nicht [1]. Wenn z.B. jemand manuell alle Straßenbahngleise (railway=tram) einer Stadt in railway=light_rail umtaggt, ist es zwar kein mechanischer Edit, wenn er dabei noch diverse Fehler entdeckt und ausbügelt, aber ein massenhaftes Umtaggen, bei dem Höflichkeit es gebietet, die anderen Mapper in der Gegend vorher zu fragen (Forum, Talk-de oder regionale Mailingliste).

Wenn jemand den Fehler eine Vorlage eines Editors wie JOSM korrigiert und es sich um einen offensichtlichen Fehler handelt, kommt es auf den Anzahl der geänderten Objekte und die Schwere der Änderung an. Wenn eine Vorlage z.B. einen Tippfehler in einem Tag enthält, aber an allen anderen Stellen (Wiki, Tagging-Diskussionen über das Tag, …) die fehlerfreie Variante verwendet wurde, ist IMHO keine Diskussion erforderlich, sofern es keine Bedeutungskonflikte gibt.

Im hier diskutierten Fall stellt sich mir die Frage, wer zuerst da war. Wurde das Tag erst im Wiki dokumentiert, nachdem es in den JOSM-Vorlagen gelandet ist? Dann wäre das Wiki anzupassen oder eine richtige Diskussion auf internationaler Ebene angemessen. Die JOSM-Vorlage ist hier im JOSM-SVN-Repository zu finden. amenity=hunting_stand mit lock=yes wurde am 9. November 2008 von Christoph Eckert in SVN-Revision 1069 hinzugefügt. Der Erzählung nach soll das mal eine Spaßidee des Karlsruher Stammtisch gewesen sein (der damalige JOSM-Maintainer kommt aus Karlsruhe). Hier das von ihm eingefügte Stück Code:


		<item name="Hunting Stand" icon="presets/hunting_stand.png">
			<label text="Edit a Hunting Stand" />
			<key key="amenity" value="hunting_stand" />
			<check key="shelter" text="Shelter" default="off" delete_if_empty="true" />
			<check key="hide" text="Hide" default="off" delete_if_empty="true" />
			<check key="lock" text="Lock" default="off" delete_if_empty="true" />
			<combo key="height" text="Height" values="low,half,full,5,10,15,20" default="" delete_if_empty="true" />
		</item>

Die englische Wiki-Seite ist im Jahr 2010 angelegt worden, die deutsche im Jahr 2009.

Auf der Seite Map_Features werden nur die Haupttags, nicht die zusätzlichen Tags wie lock=yes erfasst. Deshalb habe ich noch in DE:How_to_map_A angesehen. Die Ergänzung dort ist neuer, sie stammt vom Februar 2010. Eine englische Version gibt es erst seit ein paar Jahren, zudem ist diese der deutschen um sieben bis zehn Jahre hinterher (wenn man nur auf die Länge schaut).

Aufgrund dieser Recherchen lautet meine Meinung: Wenn es hierzu keine Diskussion auf der Tagging-Mailingliste gegeben hat, sollte die kürzlich im JOSM-Default-Template erfolgte Änderung sollte zurückgesetzt werden und der “mechanische” Edit ebenso.

Viele Grüße

Michael

[1] OSM hat nur wenige feste Regeln, die dokumentiert sind. Die meisten werden in Foren- und Mailinglistendiskussionen “mündlich” überliefert.

Echt jetzt?! :roll_eyes:

Dann müsste aber auch in Konsequenz dessen sämtliche mit lock=yes getaggten Schleusen überarbeitet werden…was aber auch nicht sein kann, da lock bereits im Januar 2009 angelegt wurde! gut, die josm vorlage ja anscheinend ohne vorherige wiki-dokumentation im November 2008 … und das fällt jetzt erst jetzt, 8-9 Jahre später auf?!

Sorry, aber ich sehe es auch so wie die anderen: lock=yes an einem amenity=hunting_stand ist Quatsch, also ist die Korrektur der JOSM Vorlage von lock->lockable berechtigt, genauso auch der “massenhafte” Korrektur-Edit dazu.

Vielen Dank für die Eröffnung des Threads. Grund dafür war meine Bitte in folgendem Changeset:
https://www.openstreetmap.org/changeset/51242732

Die gleiche Diskussion gab es bereits letztes Jahr schon einmal:
https://www.openstreetmap.org/changeset/43559124

Vor neun Monaten wurde in JOSM übrigens auch das Preset angepasst.

lockable wurde 2012 im deutschen Wiki und 2016 im englischen Wiki eingeführt.

Bezüglich “mechanischer Bearbeitung”: Ich sehe das grenzwertig und habe es deswegen auch angesprochen. Man muss auf jeden Fall berücksichtigen, dass nicht alle Objekte auf einmal bearbeitet wurden. Ich glaube schon, dass zumindest ein Großteil davon kurz überprüft wurde, aber halt nicht vor Ort. Hochsitze werden schnell morsch und nicht immer ersetzt oder werden verlegt. Ich halte es für sinnvoller, wenn die Editoren eine Warnung anzeigen (was ja bereits der Fall ist), wenn man das Objekt bearbeitet. Andererseits bearbeitet man auch ansonsten “nebenbei” Objekte, die man gar nicht vor Ort überprüft hat (z.B. beim besseren Ausrichten von Wegen).

Vor kurzem stand mal der Vorschlag einer Arbeitsgruppe für offensichtliche Fehler im Raum, die sich sowas offiziell annimmt und Lösungen diskutiert, ohne die Themen tot zu diskutieren. Das wäre ein Traum …
Ansonsten, siehe Fußzeile.

Hochsitze gehören, da sie mit nichts verbunden sind, wohl eher zu den Objekten, die seltener “nebenbei” bearbeitet werden. Wenn ein Objekt in JOSM nicht editiert wird, wird der Validator das Objekt auch nicht ohne explizite Aufforderung prüfen (es werden dann nur geänderte Objekte geprüft).

Hallo zusammen,
erst einmal Danke für die vielen Informationen. Ich habe einiges gelernt :wink:

Mein Interesse liegt im Kartieren und an einer guten Datenqualität incl. guter Wiki Dokumentation. Bei diesen Themen gibt es noch einiges zu tun! Ich suche praktisch umsetzbare Lösungen für Nicht-Techniker.

Was ich bemerkenswert finde, ist, dass es in allen Ländern außerhalb Deutschlands keine einzige Change Diskussion während der Tagging Bereinigungsaktion gab. Nur in .DE gab es Change Diskussionen, jedes Mal mit Mechanical Edit als Thema. Die jüngste Change Diskussion war dann besonders heftig, s.o. Warum??? Deshalb dieser Thread in diesem Forum.

Es geht hier NUR um die Bereinigung einer jahrelang von niemandem erkannten Doppelnutzung eines Tags, nachdem eine der beiden Ursachen bereinigt wurde. Die Änderungskomplexität ist einfach und die Komplexität der betroffenen Objekte ist einfach (99% Nodes mit <4 Tags). Die betroffenen Objekte bei Tagging Bereinigungen sind rund um den Globus verstreut.

Fazit für mich aus der bisherigen Diskussion:
1.) Die Verwendung von Suchfunktionen mit anschließenden rein manuellen Änderungen incl. Qualitätsprüfungen ohne Datenimport/-export wird von der deutschen Community nicht als Mechanical Edit bewertet.
2.) Warum die Anzahl der Objekte ein Kriterium ist verstehe ich nicht. Die Komplexität der Änderung und die Komplexität der betroffenen Objekte ist meines Erachtens viel wichtiger.

Gruß,
sperlingskauz

Wenn der Hochsitz vorher nördlich des Weges war und ich den Weg Richtung Norden korrigiere, dann verschiebe ich den Hochsitz in der Regel auch nach Norden.

Das Thema “Hochsitze” ist meines Erachtens sehr speziell. In der Regel wollen die Besitzer gar nicht, dass die Daten in OSM auftauchen (wohl wegen Vandalismus). Auf der anderen Seite sind die Positionen für Rettungsdienste wiederum interessant, da sie mögliche Aufenthaltsorte für vermißte / suizidgefährdete Personen darstellen.

Fazit: Bei der Erfassung sollte man auch den Typ des Hochsitzes erfassen. Dies gilt insbesondere für Leitern an Bäumen.

+1
Bei diesem Sub-Tag und dieser Relevanz und Bedeutung wäre das Bürokratismus in Reinkultur.

+1
Man kann es sich - oder Anderen - auch unnötig schwer machen …

+1

Leicht OT: wenn man hunting_stand dann manuell vor Ort prüft, kann man auch gleich noch direction angeben, z.B. wie hier im Vorarlberg :wink: