Wie steht es um die Qualität von OpenStreetMap (OSM)?

Diskussionen zu Geoinformationen
1

Ich werde immer wieder auf die Qualität von OpenStreetMap (OSM) angesprochen und ein typischer Vorbehalt „dagegen“ ist „die Qualität“. Die Situation ist vergleichbar wie bei Wikipedia vor 10 Jahren, wo sich die „Qualitätsdiskussion“ inzwischen geklärt hat.

Zu oft wird unreflektiert einerseits von «qualitativ hochwertigen» und andererseits von «vertrauenswürdigen Daten» gesprochen. Dabei werden oft Behördendaten (Open Government Data, OGD) und Organisationsdaten (wie z.B. Mobility) mit qualitativ hochwertigen Daten gleichgesetzt - was nicht immer stimmt. Z.B. können sie veraltet sein oder haben ungenaue Koordinaten. Und der Begriff «vertrauenswürdige Daten» wird missverstanden.

Ich möchte betonen, dass erstens statt von «hochqualitativen» Daten besser von «qualitativ definierten» Daten gesprochen werden sollte, die «fit-for-use» sind (wie von der ISO definiert, siehe Wikipedia zu „Qualität“).

Und zweitens möchte ich darauf hinweisen, dass, wenn von vertrauenswürdigen Datenräumen («Trusted Data Spaces») die Rede ist, nicht die Daten gemeint sind, sondern deren Verwaltung und Verbreitung. Manche meinen, dass (amtliche?) Geodaten gar nicht selber einen Datenraum bilden, sondern eine Basisinfrastruktur, also die Grundlage sind für andere vertrauenswürdige Datenräume.

OpenStreetMap (OSM) ist schon seit einiger Zeit erstens fit-for-use und zweitens kann es auch Teil von Trusted Data Spaces sein. Leider kommt das in der Studie zu „Geodaten als Basis für vertrauenswürdige Datenräume“ zu wenig zum Ausdruck.

Bereits 2012 wurde festgestellt, dass OSM eine Ergänzung und Teil der NGDI ist (Heuel 2012). Bei dieser Gelegenheit erwähne ich auch gerne, dass OSM alle Kriterien von GeoCommons erfüllt.

Das setzt voraus, dass man ein Grundverständnis von OSM hat, wie man es sich mit Hilfe von beispielsweise OpenSchoolMaps.ch selbst erarbeiten kann. Was tatsächlich noch verbesserungswürdig ist, ist die Qualitätsbewertung von OSM. Dafür gibt es inzwischnen mit dem «ohsome Dashboard» ein Tool von der Universität Heidelberg.

Ich selbst beschäftige mich an meinem Institut an der FH OST mit der Qualitätsbewertung im Forschungsprojekt «OSM Completeness». Über dieses noch in der Entwicklung befindliche Projekt gebe ich auf Anfrage gerne Auskunft. Und sobald ich dazu komme, möchte ich auch den Leitfaden für Datenhalter zu „Daten in OpenStreetMap integrieren“ aus dem Jahr 2021 um die inzwischen verfügbaren Werkzeuge ergänzen.

2

Vielen Dank für diesen interessanten Einblick.

Das mit der Qualitätsbewertung ist uns als Feuerwehr leider auch schon aufgefallen, bzw. waren wir direkt betroffen.
So waren anhand von „falschen“ OSM Daten Strassennamen falsch oder ein Privathaus ein Hotel. Das ist in Notfällen eine Herausforderung und bei uns bereits vorgekommen.
Ein Reviewprozess (4-Augen Prinzip) vor einer Veröffentlichung wäre aus unserer Sicht wünschenswert und hilfreich für diesen Aspekt.
Die Thematik scheint auch nicht neu zu sein, wie diese Fragen hier zeigen:

3

Lieber loeti82

Vielen Dank für deine Anmerkungen.

Ein Reviewprozess (4-Augen Prinzip) vor einer Veröffentlichung wäre aus unserer Sicht wünschenswert

Ich meinte oben vorallem, dass man den Ist-Zustand beurteilen können sollte. Man unterscheidet bei den Qualitäts-Tools u.a. 1. zur Beurteilung, 2. zur Beobachtung, 3. zur Integration (Import in OSM) und 4. zur Nutzung (Import in eigene Anwendungen, bzw. Apps). Siehe diese lange Liste auf der OSM Wiki-Seite zu „Quality assurance“.

Dieses Zwei-Augen-Prinzip gibt es bei OSM tatsächlich schon lange, bzw. von Anfang an, wo Mapper ein Gebiet und/oder ein Thema „monitoren“ und bei Bedarf nachfragen, korrigieren. Im Gegensatz zu anderen Datenprojekten gibt es in OSM einen „Feedback-Loop“ und es ist direkt möglich zu ändern, auch wenn es je nach Anwendung/App Wochen dauern kann, bis die Änderung sichtbar wird.

Trotz dieses Mehr-Augen-Prinzips wird es immer Fehler oder „Qualitäts-Erwartungs-Differenzen“ geben - nicht nur bei OSM. So war beispielsweise Knies Zauberhut im Kinderzoo Rapperswil auf der Landeskarte jahrelang nicht aktualisiert. Und bei Google Maps überlappen in Altstadt-Gebieten wie Rapperswil (SG) Gebäude fälschlicherweise die Strassen.

Wenn es um die das Monitoring und die Nachführung geht, spreche ich gerne von der „Commons-, bzw. GeoCommons“-Situation". Dabei vergleiche ich die Situation von Crowdsourcing wie OpenStreetMap mit einem Clubhaus, in dem jede:r mitmachen kann. Jede:r kann dort essen (d.h. die Daten nutzen) und kochen. Dort wird auch geregelt, dass das Haus und die Küche sauber und der Küchenbestand (d.h. die rohen OSM-Daten) aktuell bleiben. Dabei kann jede:r mithelfen - und sei es nur, indem er einen Fehler meldet. Es können auch Küchenverantwortliche bestimmt werden, die sich um einen Bereich und/oder ein Thema kümmern.

Wer erwartet, dass man die Vorräte direkt essen (d.h. nutzen) kann, der muss sich etwas auskennen, denn nicht alle Esswaren sind „genussfertig“ (d.h. nicht alle OSM-Daten sind „daten-analyse-ready“).

Wer erwartet, dass ein Caterer alles organisiert, der muss ihn auch bezahlen - und der Caterer muss sich an die Club-Regeln halten, z.B. im Umgang mit den Essaren und Vorräten. Bei professionellen Organisationen wie Gemeinden oder eben Feuerwehren, wäre könnten z.B. Mitarbeiter:innen die Funktion eines OSM-Community-Beauftragten übernehmen.

Ich helfe gerne weiter bei solchen Fragen, wie z.B. Fehler melden, Gebiet monitoren, OSM-Community-Beauftragten bestimmen inkl. entsprechende Tools.

4

Vor genau einem Jahr habe ich im „alten“ GEOWebforum ein Essay geschrieben, das versucht, das Wesen von OpenStreetMap zu beschreiben. Dabei beziehe ich mich auf eine wegweisende Diskussion über Closed Source versus Open Source Software und versuche damit u.a. folgende Punkte zu klären:

  1. Es ist wichtig, zwischen „qualitativ definiert“ („fit for purpose“) und Pauschalurteilen (Behördendaten=„qualitativ ausreichend“ und Crowdsourced=„qualitativ fragwürdig“) und unrealistischen Ansprüchen („nur beste Qualität“) zu unterscheiden.
  2. Crowdsourcing- oder Citizen Science-Initiativen sind nicht top-down, sondern bottom-up organisiert.
  3. Wer Daten in Crowdsourcing- oder Citizen Science-Initiativen einbringt, gibt die Kontrolle über „seine“ Daten ein Stück weit ab, was aber nicht bedeutet, dass keine Kontrolle stattfindet - im Gegenteil.

Behördendaten vs. Crowdsourcing-Daten, „Die Kathedrale und der Basar“ und was das mit GeoCommons zu tun hat.

Ein 25 Jahre alter Aufsatz mit dem Titel „The Cathedral and the Bazaar“ [1] stellt zwei Modelle der Softwareentwicklung gegenüber: Einerseits die zentralisierte und (abends) geschlossene Kathedrale, in welcher der Quellcode nur einer exklusiven Gruppe von Softwareentwicklern zur Verfügung steht, und 2. der dezentralisierte und offene Basar, der die Open-Source-Entwicklung fördert, in der der Code von jedermann eingesehen, verändert und weitergegeben werden kann. Eine zentrale These, die für das Basar-Modell spricht, lautet: „Given enough eyeballs, all bugs are shallow“ („Wenn es genug Augen gibt, kommen alle Bugs an die Oberfläche“, sog. Mehraugenprinzip). Der wegweisende Aufsatz trug dazu bei, die Philosophie und die Praktiken der Open-Source-Entwicklung zu popularisieren, was grosse Unternehmen dazu ermutigte, Open-Source-Software zu unterstützen und zu übernehmen. Der berühmte Aufsatz ist auch heute noch relevant, da er als Inspiration für alle dient, die die Vorteile einer offenen Zusammenarbeit nutzen wollen.

Diese Analogie lässt sich auch auf zentralisierte Behördendaten (= Kathedrale) und dezentrale, von der Gemeinschaft getragene Crowdsourcing- oder Citizen Science-Initiativen wie Wikipedia oder OpenStreetMap anwenden. Diese etablierten Crowdsourcing-Projekte (= der Basar) basieren auf dem Prinzip der offenen Zusammenarbeit und der Beteiligung eines breiten Netzwerks von Freiwilligen. Dies ermöglicht vielfältigere und oft aktuellere Informationen, wenn auch in unterschiedlicher Vollständigkeit und Qualität. Diese Analogie verdeutlicht die Stärken und Schwächen beider Modelle: die Verlässlichkeit und Autorität zentralisierter Daten gegenüber der Innovationskraft und Aktualität kollaborativer, dezentral-heterogener Datensammlungen.

[1] Raymond, E. (1999). The Cathedral and the Bazaar. Knowledge, Technology & Policy, 12(3), 23-49. Die Kathedrale und der Basar – Wikipedia