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.