Mit der zunehmenden Verwendung und Popularität sowie der wachsenden wirtschaftlichen Bedeutung von OpenStreetMap über die letzten Jahre haben auch das Interesse und die Versuche, von außen Einfluss auf das Projekt und die an ihm Beteiligten zu nehmen, deutlich zugenommen. Ich möchte hier einen Blick auf die in diesem Zusammenhang manchmal recht unerwarteten Mechanismen werfen.
Ich verwende den Begriff „Social Engineering“ hier im Sinne von Aktivitäten, die das Ziel verfolgen, andere Menschen in dem was sie tun (oder nicht tun) zu beeinflussen, und zwar nicht durch Informationen und Bildung, welche diese befähigt, ihre eigenen Entscheidungen auf Grundlage ihrer eigenen Prioritäten zu fällen, sondern indem man ihre Wahrnehmung beeinflusst, um gewissen Zielen zu dienen, ohne dass dies der Person bewusst ist. Manch einer mag ein solches Verhalten für vertretbar oder sogar für erwünscht halten, falls es höheren Zielen dient, aber ich vertrete hier einen strikt humanistischen Standpunkt.
Man beachte, dass Social Engineering nicht notwendigerweise bedeutet, dass derjenige, der andere beeinflusst sich selbst der Gründe hierfür bewusst ist.
OpenStreetMap ist unter digitalen sozialen Projekten und Internet-Gemeinschaften recht bekannt dafür, dass es wenig feste Regeln hat und das Projekt seinen Beteiligten großen Freiraum lässt, sich zu betätigen. Dies schafft natürlich auch eine Menge Raum für Einflussnahme. Auf der anderen Seite ist die Gemeinschaft der OpenStreetMap-Aktiven zumindest in mancher Hinsicht recht vielseitig und auch stark vernetzt so dass es recht schwierig ist, hier gezielt eine Gruppe von Leuten zu beeinflussen, ohne dass andere davon mitbekommen. Dies bedeutet, dass klassisches Social Engineering im Verborgenen, wo die Leute nicht mitbekommen, dass sie beeinflusst werden, nicht so weit verbreitet ist.
Es gibt jedoch in OpenStreetMap eine ganze Reihe von Aktivitäten, die man als mehr oder weniger offenes Social Engineering bezeichnen könnte, welches auf die Steuerung und Organisation von Mapping-Aktivitäten abzielt. Humanitäres Mapping ist hier das offensichtlichste Beispiel. Es gibt auch eine Reihe von bekannten Werkzeugen wie Maproulette, welche solche Aktivitäten unterstützen können.
Die erhebliche Anzahl von Leuten, die regelmäßig bei der Erfassung von Daten in OpenStreetMap aktiv sind, macht die Einflussnahme auf diese Aktivitäten selbst auf kleinem Rahmen zu einem attraktiven Ziel. Dies ist jedoch meist recht harmlos, denn
- diese Form der Einflussnahme ist recht direkt,
- der Einfluss und oft auch die dahinter stehenden Interessen sind gewöhnlich für den Mapper sichtbar und
- wenn das Ganze aus dem Ruder läuft, können solche Aktivitäten recht einfach durch die Gemeinschaft unterbunden oder reguliert werden.
In anderen Worten: Mapper, die sich an HOT-Projekten beteiligen, werden nicht massiv manipuliert, denn die von ihnen wahrgenommenen Gründe für die Projekte unterscheiden sich nicht sonderlich von den tatsächlichen Gründen. Solche Mapper wissen vielleicht nicht genau in wie weit die Leute in der Gegend wo sie Daten erfassen auch tatsächlich von diesen profitieren und was genau die wirtschaftlichen Interessen der organisierenden Institutionen dabei sind. Im Groben treffen sie jedoch eine informierte Entscheidung, wenn sie sich an so etwas beteiligen.
Trotzdem sind solche organisierten Aktivitäten in OpenStreetMap nicht ohne Probleme, insbesondere dadurch, dass sie die soziale Balance innerhalb des Projektes gefährden können und zum Beispiel individuelle Mapper, die lokal die ihnen bekannten Umgebung erfassen, sich durch organisierte Aktivitäten von außerhalb bevormundet und übergangen fühlen.
Dies ist jedoch nicht das was ich hier hauptsächlich thematisieren möchte. Mit geht es um eine subtilere Form der Einflussnahme, welche ich social self engineering nennen möchte. Ein gutes Beispiel um zu erläutern, was ich damit bei OpenStreetMap meine, ist das was wir Mapping für den Renderer nennen.
Mit Mapping für den Renderer ist in der einfachsten Form gemeint, wenn Leute Daten in die OSM-Datenbank eintragen nicht mit dem Ziel, eine Beobachtung vor Ort in der Realität zu dokumentieren, sondern um in einer Karte auf Basis dieser Daten ein bestimmtes Darstellungsziel zu verwirklichen. Beispiele wären hier:
- Als Namens-Attribute eingetragene Zeichenketten, welche keinen Namen darstellen, sondern zur Platzierung von sonstigen Beschriftungen in der Karte dienen.
- Orts-Knoten, welche so verschoben werden, dass Beschriftungen an einer attraktiveren Position gezeichnet werden
- Abweichende Klassifikationen von Orten oder Straßen, um diese früher und deutlicher in der Karte zu sehen.
- Das Weglassen von Attributen, weil das daraus resultierende Erscheinungsbild in der Karte als unvorteilhaft angesehen wird.
Im Vergleich zu normalem Social Engineering sind die Rollen hier gewissermaßen vertauscht. Diejenigen, deren Verhalten beeinflusst wird, sind auch die, die darüber entscheiden (deshalb auch Self Engineering) und der Einfluss dies zu tun kommt von jemandem (dem Gestalter der Karte), der oft nichts von diesem Einfluss weiß und meist darüber auch gar nicht erfreut ist.
In dieser einfachen Form ist das Phänomen weit verbreitet und diejenigen, die so etwas tun, sind sich zwar im allgemeinen bewusst, dass das was sie machen nicht ganz richtig ist – sie sind sich aber meist nicht wirklich bewusst, was sie eigentlich motiviert, das zu tun, was sie tun und was für Konsequenzen dies auf die Datenqualität hat. In den meisten Fällen wird Mapping für den Renderer einfach als Abkürzung oder methodisches Schummeln angesehen. Die spezifischen Probleme der ganzen Wechselwirkung und Interaktion zwischen Karten-Gestaltern und Mappern habe ich auch schon früher mal diskutiert.
Es gibt aber noch eine andere Variante des Mapping für den Renderer (oder allgemeiner: des Mapping unter spezieller Berücksichtigung einer bestimmten Daten-Nutzung), welche weniger direkt ist und was ich als präventives Mapping für den Renderer bezeichnen möchte. Ein gutes Beispiel hierfür ist das verbreitete is_in-Attribut (oder Varianten wie is_in:country), welche angeben, in was für einem Land oder anderem Gebiet sich ein Objekt (zum Beispiel eine Stadt oder ein Dorf) befindet. Mir sind keine Anwendungen bekannt, für die dieses Attribut tatsächlich benötigt wird. Taginfo nennt Nominatim als einzige Anwendung, welche dieses verwendet. Allein schon die Idee, dass es in einer räumlichen Datenbank sinnvoll sein könnte, die Tatsache, dass sich eine Geometrie innerhalb einer anderen Geometrie befindet, per Hand als Attribut zu dokumentieren, ist absurd. Dennoch gibt es mehr als 2 Millionen Objekte mit diesem Attribut in der OSM-Datenbank.
Warum dies passiert hat eine Menge mit dem Phänomen des Cargo-Kults zu tun. Tatsächlich können recht viele der Tagging-Ideen und -Vorschläge, die in OSM entwickelt und kommuniziert werden, als Cargo-Kult-basiert klassifiziert werden und dies ist einer der Gründe weshalb viele Mapper Tagging-Diskussionen meiden. Eigentlich ist ja auch schon die Idee, dass jeder Dokumentation einer Beobachtung in der Realität in OSM ein universelles Klassifikations-System zugrunde liegen soll, inherent anfällig für Wunschdenken. Manchmal gibt es aufwändige strukturierte Tagging-Systeme, welche mit der Absicht entwickelt werden, es für Entwickler von Anwendungen attraktiv zu machen, sie zu implementieren, was glücklicherweise meist dazu führt, dass weder Mapper noch Daten-Nutzer diese Ideen umsetzen. Die Idee eines importance-Tags, welche alle paar Monate wieder irgendwo auftaucht, gehört auch zu dieser Kategorie. Aus dem Wunsch heraus, dass es einen objektiven und universellen Maßstab gäbe, um die Bedeutung von Dingen zu quantifizieren, erfinden Leute ein importance-Tag und hoffen, dass dessen Existenz allein ausreicht, dass dieser Wunsch Realität wird.
Aber nicht alle derartigen Mapping-Ideen sind ohne Erfolg. Es gibt eine ganze Reihe von Attributen, welche erfunden wurden, weil jemand dachte, dass sie die Datennutzung einfacher machen und Mapper investieren eine Menge Zeit, diese Dinge zu erfassen – wie im genannten Beispiel von is_in. Oder bei der Idee, Dinge als Polygone zu erfassen, welche ebenso präzise mit linearen Geometrien oder Punkten erfasst werden könnten – wie hier.
Das Problem dabei ist nicht nur die Verschwendung von Ressourcen bei der Erfassung und der Pflege der Daten. So etwas hält auch oftmals Datennutzer davon ab, sinnvollere Erfassungs-Methoden zu interpretieren. Präventives Mapping für den Renderer zielt immer, selbst wenn die Überlegungen dahinter gelegentlich sinnvoll sind, auf eine technologisch konservative Daten-Interpretation ab. Auf diese Weise werden echte Innovation und Investitionen in eine intelligente und fortschrittliche Interpretation von für die Mapper optimierten Erfassungs-Methoden behindert. Das is_in-Tag beispielsweise wurde erfunden in der Frühzeit von OpenStreetMap als es noch keine Grenz-Relationen gab, über welche man automatisch hätte ermitteln können, in welchem Land sich ein Objekt befindet. Also hat jemand anstatt eine besser geeignete Lösung zu erfinden den technologisch einfachen Weg gewählt und die Arbeit auf den Mapper abgeladen. Glücklicherweise hat dies in diesem Fall nicht verhindert, dass am Ende doch Grenz-Relationen und und Punkt-in-Polygon-Tests als bessere Lösung entwickelt und etabliert wurden.
Und während Versuche von Datennutzern, direkt Einfluss zu nehmen und Mapper zu überreden, Daten in für sie einfach verwendbarer Form zu erfassen, meist recht leicht zu erkennen und ggf. zurückzuweisen sind, ist die präventive Variante von Seiten der Mapper oft schwieriger zu erkennen. Und auch die Motive, weshalb ein Mapper jetzt ein bestimmtes, problematisches Tagging nutzt oder befürwortet sind meist recht kompliziert und unübersichtlich.
Wer also als Mapper wirklich eine kompetente Nutzung der Daten unterstützen möchte, der sollte besser jegliche Annahmen zu den vermuteten Interessen der Datennutzer ignorieren und sich darauf konzentrieren, wie man seine Beobachtungen vor Ort möglichst effizient in Datenform wiedergibt.