Robotized Float Glass Unloading von ICAPlants auf Wikimedia Commons, CC-BY-SA 3.0
Dieser Beitrag ist eine Ausformulierung von Teilen von Frederik Ramms Vortrag Automatische Edits und Importe in OSM, der auf der FOSSGIS-Konferenz in Salzburg gehalten wurde. Auf der State of the Map in Brüssel soll es einen ähnlichen Vortrag geben. Frederik freut sich über Kommentare zu diesem Beitrag, die er ggf. in den SotM-Vortrag einfließen lassen kann.
In OSM-Diskussionen taucht oft der Begriff eines „automatischen Edits“ auf. Dabei denkt man dann gleich an ein Skript, ein Programm, einen „Bot“ – Software, die OSM-Daten auf Basis eines Algorithmus verändert.
Deswegen spreche ich lieber von „mechanischen Edits“. Das sind alle Änderungen in OSM, bei denen ein Mensch eine Änderung ohne Ansicht des Einzelfalles durchführt. Diese Definition trifft zwar auf Programme auch zu, umfasst aber noch viel mehr.
Jeder, der zu Studienzeiten mal am Kopierer stand und ein Buch kopieren musste, weiß, dass auch eine von Hand getane Arbeit stupide und ohne Betrachtung des Einzelfalls passieren kann. Wer 100 Edits mit JOSM hintereinander macht und sich für jeden nur zwei Sekunden Zeit nimmt, der fällt vielleicht auch schon unter diese Definition. Wer sich mit Overpass ein paar Objekte anhand eines Tags aussucht und diesen dann mit JOSM gesammelt ein anderes Tag verpasst, ist auch ein mechanischer Editierer.
Weil solche mechanischen Edits das Potential haben, einigen Schaden anzurichten und für Missstimmung zu sorgen, wird erwartet, dass man in der Community diskutiert, bevor man sie ausführt. Dabei wird man dann hoffentlich auch auf mögliche Probleme hingewiesen.
Aber was kann denn schon schiefgehen?
Der aufstrebende Mapper Oskar S. entdeckt zufällig beim Bearbeiten seiner Heimatstadt ein Objekt, das mit Building=yes getaggt ist. „Halt mal,“ denkt sich Oskar, „OSM ist doch case-sensitiv – das wird ja gar nicht als Gebäude erkannt!“ Schnell ändert er es auf building=yes, und alles ist gut.
Gebäude mit großgeschriebenem „Building=yes“
Der Vorfall lässt Oskar keine Ruhe. Wie viele Gebäude kann er noch auf diese Weise aus dem Orkus retten? Mit Overpass lädt er alle Objekte in JOSM, die mit Building=yes getaggt sind. Es handelt sich ja hier ganz offensichtlich um einen Fehler, da muss man nicht groß mit irgendwem diskutieren. Ein paar Tastendrücke, und schon sind die 127 Objekte auf building=yes korrigiert und zu OSM hochgeladen.
Am Tag darauf kommentiert jemand von der Data Working Group Oskars Changeset und macht ihn auf einige Probleme aufmerksam.
Doppeltes Gebäude
An einer Stelle war ein Haus doppelt gemappt worden. Der Mapper hatte den ersten Versuch mit Building=yes getaggt, den zweiten dann korrekt mit building=yes, aber das erste war stehen geblieben. Durch Oskars Edit stehen hier nun zwei Häuser ganz leicht versetzt aufeinander. Hätte Oskar hingeschaut, hätte er das Duplikat entfernen können.
Haus auf Straße
Anderswo war ein Rechteck mit Building=yes getaggt und lag mitten auf einer Straße. Durch Oskars Edit wurde aus dem von jeder Software ignorierten Rechteck nun ein Haus. Ein Blick auf das Luftbild hätte Oskar geholfen, hier wirklich die Karte zu verbessern – so war sein Edit nicht hilfreich.
Nodes mit Building=yes
Wieder woanders hatte ein Neuling aus Versehen sämtliche Eck-Nodes eines Hauses mit Building=yes versehen. Hätte Oskar sich das angeschaut, hätte er das Tag einfach entfernen können. So tragen die Nodes nun alle ein stolzes building=yes, was kein bisschen richtiger ist als vorher.
Der vierte Ort, der von Oskars Edit erwischt wurde, war ein kleines Dorf in Kolumbien, in dem vor fünf Jahren ein Neuling einige Edits gemacht hat, von denen die Hälfte im JOSM-Validator aufleuchten. Das Building=yes war hier nur die Spitze des Eisbergs, und eigentlich hätte sich dringend mal jemand mit Ortskenntnis des ganzen Dorfs annehmen müssen. Nun sieht es oberflächlich betrachtet so aus, als ob sich bereits jemand der Sache angenommen hat – aber Oskar weiß nicht einmal, dass er überhaupt in Kolumbien editiert hat. Auf der Changeset-Übersichtsseite bei openstreetmap.org hat sein Changeset ohnehin ein Rechteck, das über alle Kontinente geht … man kann nur hoffen, dass der Mapper in Peking, der Oskar eine Frage zu seinem Edit in China stellen möchte, Deutsch kann, denn Oskar hat es nicht so mit Englisch, und mit Mandarin schon gar nicht.
Motivationen für mechanische Edits
Viele mechanische Edits sind von Ordnungssinn motiviert – vom „Gärtnern“, wie das bei der Wikipedia heißt. Wie unser Oskar oben findet ein Mapper ein paar Fehler und denkt sich nach anfänglichen manuellen Edits: „Das müsste man alles in größerem Stil machen.“ Man kann oft an der Edit-Historie sehen, wie die Leute sich zu immer gewagteren Edits hocharbeiten, die immer noch mehr Ordnung bringen sollen.
Zen-Garten (Shitennō-ji-Honbo-Garten, Wikimedia Commons, 663highland, CC-BY-SA 2.5)
Es gibt auch Mapper mit einem starken IT-Background, die gewohnt sind, mit Software anderen Leuten viel Arbeit abzunehmen und dann als Held gefeiert zu werden. Nicht selten stoßen Leute zu OSM, die gleich als ersten Edit eine mechanische Massenänderung machen – vermutlich haben die irgendwo eine OSM-Einführung gehört und sich gedacht „die Armen, die machen alles von Hand, da sind meine Super-Skillz gefragt!“
Aber die Handarbeit ist eine wesentliche Stärke von OSM (und übrigens auch vom Zen-Garten). Die Daten sind dann gut, wenn sie von Leuten mit Ortskenntnis eingetragen wurden. Dadurch, dass jemand mit dem Rasenmäher über unsere Datenbank fährt und einen – oftmals nur vermeintlichen – Fehler verbessert, werden die Daten nicht besser.
Mechanische Edits und Alternativen
Natürlich gibt es legitime Anwendungsfälle für mechanische Edits – daher ja auch kein komplettes Verbot, sondern nur einige im Vergleich zum normalen Editieren verschärfte Regeln (Automated Edits Code of Conduct im Wiki).
In Deutschland wurden beispielsweise nach gründlicher Diskussion alle abgekürzten Straßennamen („Blumenstr.“) in ihre Langform geändert. Aber auch das verlief nicht ohne Schwierigkeiten – in den ersten Anläufen wurde zum Beispiel nicht bedacht, dass ein paar zufällig mit erwischte Straßen in der grenznahmen Schweiz eben nicht „Straße“ heißen, sondern „Strasse“.
Auch zum Aufräumen nach Importen werden gern mechanische Edits durchgeführt. Hier ist allerdings größte Vorsicht angebracht, denn allzuoft maskiert man durch die automatische Korrektur der
offensichtlichen Fehler zahlreiche weniger offensichtliche Probleme, die ein schlampiger Import ebenfalls mit sich gebracht hat. (Der Autor selbst hat in einem mechanischen Edit über 140 Millionen Nodes in den USA von Überbleibseln eines Imports bereinigt; auch diesem Edit ging eine lange Diskussion auf der amerikanischen Mailingliste samt Abschätzung des Effekts auf die Datenbank-Größe und der Laufzeit des Edits – 4 Monate – voraus.)
Ein mechanischer Edit sollte nur die letzte Wahl sein, wenn keine der Alternativen in Frage kommt. Wer ein Problem entdeckt, sollte es zunächst analyisieren: Wie oft kommt es vor? Sind es bestimmte Leute oder bestimmte Programme, die vielleicht einen systematischen Fehler machen? Das sollte auf einer geeigneten Mailingliste oder im Forum diskutiert werden.
Wenn sich das Problem nicht von einer Person alleine reparieren lässt, ohne dabei zum mechanischen Edit greifen zu müssen, dann könnte man vielleicht über eine „Wochenaufgabe“ oder eine „MapRoulette“-Challenge eine größere Zahl von Menschen zum Aufräumen gewinnen.
Nur, wenn das alles nicht in Frage kommt und wenn die Idee ausreichend diskutiert wurde, sollte man einen mechanischen Edit in Betracht ziehen.
