Das Problem mit mechanischen Edits in OpenStreetMap

Foto, welches vier Industrieroboter bei der Aufnahme von Glasscheiben zeigt

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"

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.

Screenshot JOSM doppeltes Gebäude

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.

Screenshot JOSM Haus auf Straße

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.

Screenshot JOSM Nodes mit Building=yes

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

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.

Frederik

Frederik Ramm ist altgedienter Mapper, Mitautor des deutschen OpenStreetMap-Buchs und einer der Geschäftsführer der Geofabrik in Karlsruhe. In der 'Data Working Group' der OSM Foundation geht er Vandalismus und Urheberrechtsverletzungen nach.

Kategorie: Artikel, OSMBlog

  1. Ich verstehe den Ansatz, aber: Zumindest in dem genannten Beispiel (Oskar) war ja tatsächlich die Datenbank fehlerhaft. Und “nur, weil der Nutzer das nicht direkt sieht” Fehler in der Datenbank zu belassen halte ich für problematisch. Vielleicht bin ich da (Software-Entwickler-Background) etwas rabiat eingestellt, aber imho sind Fehler, die offen zutage treten (→ behoben werden können) immernoch besser als invalide Datenbruchstücke, die eigentlich nichts tun, außer dass sie halt da sind…
    Insofern ein Plädoyer für automatische Edits, die zwingen zu Struktur und Korrektheit.

    Aber klar: So etwas sollte _vorher_ ausdisktutiert werden, da stimme ich dir (und dem Code of Conduct) uneingeschränkt zu.

    • gormo

      Nach Oskars edit sind andere Fehler in der Datenbank: nodes, die building=yes tragen beispielsweise. Außerdem wird – wie Frederik ja sagt – maskiert, dass das Gebiet dringend einer Überarbeitung bedarf. Stell dir deinen Code vor, den du in einem VCS (z.B. git) hast. Jetzt entscheidet jemand, das tabs viel toller sind als spaces, und ändert mal eben den Einrückungsstil deiner Datei. Guckst du jetzt mit blame auf deinen Code, sieht es so aus als sei alles vor kurzem bearbeitet worden, dabei ist die letzte Codeänderung potenziell mehrere Jahre her. Es wird schwrere für dich, die Stellen zu finden, die tatsächlich alt sind. So ists auch mit OSM.

  2. R0bst3r

    Meines Erachtens treibt es die DWG zu weit mit ihren “automatischen Edits”. Ich Stimme dem oben genannten Beispielen zu, ABER wenn z.B. in einer Region bestimmte Häuser immer gleich gemappt werden und es ein DWG Mitglied anders gemacht hätte, hat das nichts mit einem Automatischen Edit zu tun, weil man für die Änderung auch erst mal recherchieren muss. Genauso, sind wir alle Menschen. Wenn ein Mapper 1 Edit von 1000 falsch einschätzt, dann kann man schon mal den Mapper freundlich drauf hin weisen, muss sich aber nicht ihr unbedingt über ihn auf öffentlichen Kanälen lustig machen … Dass die Arbeit in der DWG nicht leicht ist kann schon sein, aber man sollte trotzdem nicht abstumpfen.

  3. reneman

    Hallo Frederik, vielen Dank für deinen Beitrag. Die Situation wird von dir sehr gut beschrieben, die Beispiele sind hervorragend und verständlich. Ich hoffe das möglichst viele User vor Ihrem Massenedit den Text lesen und beachten. Würde Jeder die Spielregeln beachten, so haben alle User mehr freude an OSM und die DWG weniger arbeit. Besten Gruß René :o)

  4. Ziltoidium

    Vorschlag: Im Text noch bitte die dementsprechenden Mailingslisten, wiki- und Forenseiten oder Ansprechpartner verlinken. Sozusagen als Starthilfe, damit man überhaupt eine Diskussion starten kann. (Nicht jeder kennt alle Kommunikationskanäle). z.B. http://wiki.openstreetmap.org/wiki/DE:Mailing_lists

    Danke und Grüße

  5. Ich wollte gerade auch eienen Kommentar schreiben. Aber dann hat es Philipp Bielefeldt schon genau auf den Punkt gebracht. Danke dafür.

  6. Es gibt ja schon jede Menge Schrott in der Datenbank, den man relativ problemlos automatisch entsorgen könnte. Gestern ist mir bei der Arbeit an meinem Interantionalisierungscode aufgefallen, dass es 533 Gebäude gibt, die mit name=building getaggt sind.

    Auch wenn ich keine local knowledge habe wage ich zu behaupten, dass es sich hierbei bei keinem der Objekte um ein Gebäude namens building handelt.

  7. HalverHahn

    Die ersten beiden Kommentare (von Philipp Bielefeldt und R0bst3r) gefallen mir schon recht gut.

    Insgesammt ein guter und vor allem sehr sinvoller Artikel!
    Bei dem mechanischen Edit “Building=yes” finde ich die Begründung der Kritik schlecht. In keinem Fall wurden die Daten verschlechtert. Zum Beispiel wären die Fehler in Kolumbien ohne den mechanischen Edit genauso unentdeckt geblieben. Hingegen zeigt das Beispiel mit den Strassen in der Schweiz das Problem viel deutlicher. Statt jeder in der Datenbank mechanisch herumfuhrwerkt und dabei ggf. Fehler macht, wäre es meiner Ansicht nach besser, dies würde von einer kleineren erfahrenen Gruppe gemacht. Alles würde über einen Kanal mit der Comunity besprochen und abgestimmt. Es könnten Vorschläge für die Verbesserung der Datenbank geliefert werden. Beispiel: Fehler in Schreibweise width=6,25 -> 6.25 oder ersetzen alter durch neuer Tags building=entrance -> entrance=yes. Bei komplexeren Problemen (z.B. barrier=* direkt neben statt auf einem Weg, oder genau auf einer Kreuzungen von Wegen) könnten diese auf einem zentralen Qualitätsüberwachungstool visualisiert werden und von Mappern händisch verbessert werden. Momentan gibt es eine vielzahl unterschiedlicher Tools, zu verstreut wie ich finde. Manchmal schlafen diese Tools wieder ein oder behalten ihre Fehler, weil der eine betreffende Programierer sich nicht mehr mit OSM beschäftigt. Eine offizielle Arbeitsgruppe würde die Regeln viel besser kennen und einhalten, könnte eine mechanische Aufgabe auch wiederkehrend anstoßen.

    Ich denke die Zeit der Mapper ist begrenzt. Da sollte man Hilfsmittel nutzen um die Datenqualität zu verbessern.