OpenData vom Bundesamt für Kartographie und Geodäsie vs. Crowdsourced OpenStreetMap in Deutschland – Ein Vergleich Offener Daten
by Pascal Neis - Published: February 6th, 2022
Nach knapp 1.000 Tagen Abstinenz (endlich?) mal wieder ein Blog Post von mir. Aufgrund des inhaltlichen und räumlichen Bezugs diesmal auf deutsch. English version via Google translate?
Präambel – Im Herbst 2020 entstand beim FOSSGIS e.V. eine Open Data Arbeitsgruppe. Durch verschiedene gemeinsame Aktivitäten von der Arbeitsgruppe und dem Bundesamt für Kartographie und Geodäsie (BKG), wie z.B. einem Workshop, wurden Anfang Dezember 2020 zwei Datensätze von Standorten der Landespolizei und Gesundheitsämtern für die „Pflege und Erweiterung der OpenStreetMap-Datenbank“ freigegeben. Daneben existieren beim BKG noch weitere interessante „Open Data“ Geodaten und Webdienste, die aber aufgrund ihrer Lizenzbedingungen nicht vom OpenStreetMap (OSM) Projekt verwendet werden dürfen.
Ein „offizieller offener“ Datensatz von einer Bundesbehörde? Gut, wie sieht’s im Vergleich zu gemeinsam zusammengetragen Daten aus, z.B. OpenStreetMap? Lassen sich Unterschiede in der Qualität feststellen? Sind die Datensätze womöglich auf Augenhöhe oder existieren gravierende Unterschiede oder wovon könnten alle profitieren?
Um zumindest einen Teil der zuvor genannten Fragen beantworten zu können, liegt es auf der Hand eine klassische Qualitätsanalyse zwischen den zwei Datensätzen durchzuführen. Eine interessante Frage dabei: Welcher Datensatz ist die Referenzquelle? Ist der BKG Datensatz die Referenz oder inzwischen vielleicht der OSM Datensatz? In annähernd allen mir bekannten Qualitätsuntersuchungen wird der „offizielle“ Datensatz als Referenz angenommen, daher wird die folgende Analyse ebenfalls so durchgeführt.
Wie wurde methodisch vorgegangen? Die beiden hier untersuchten Datensätze vom BKG wurden über Github bezogen. Die OSM Elemente für den Vergleich wurden aus einem aktuellen Planetfile mit osmium für Deutschland extrahiert (vielen Dank an dieser Stelle an Jochen als Maintainer für dieses super schnelle Tool und die Unterstützer). Bei der eigentlichen Analyse der Qualität wurden folgende Merkmale untersucht: Vollständigkeit, Logische Konsistenz, Positionsgenauigkeit, Zeitliche Genauigkeit und Thematische Genauigkeit. Dabei kamen verschiedene JAVA Klassen zum Einsatz, die zum größten Teil bei mir auf GitHub gefunden werden können.
Wie sehen die einzelnen Ergebnisse des Vergleichs der Datensätze im Detail aus? Starten wir als erstes mit der Vollständigkeit von den beiden Datensätzen im Vergleich:
- Anzahl Objekte Landespolizei vom BKG: 4,257
- Anzahl Objekte amenity=police OSM: 3,871
Auf den ersten Blick existieren damit rund 10% mehr Standorte im Datensatz vom BKG als wie am 03.02.2022 in OSM eingetragen waren. Die Besonderheit liegt aber im verwendeten OSM-Element und -Tagging, was in der ersten Version dieses Blog Posts zu Abweichungen in den Ergebnissen bei der Vollständigkeit geführt hat.
- Anzahl Objekte Gesundheitsämter vom BKG: 427
- Anzahl Objekte government=healthcare OSM: 271
Hier verfügt der „offizielle“ Datensatz vom BKG um rund 35% mehr Objekte als was in OSM auf die schnelle zu finden ist.
Die logische Konsistenz kann über verschiedene Wege geprüft werden. In meinem Beispiel hier wurde jeweils des BKG und der OSM Datensatz bzgl. des Vorhandensein der Attribute mit sich selbst untersucht. Bedeutet: Der Datensatz der Landespolizei vom BKG besitzt 11 Sachattribute und die Gesundheitsämter verfügen über 12 Sachattribute. Bei der Landespolizei sind bei den Objekten, bis auf Telefax (73%) und E_Mail (52%), die Attribute/Eigenschaften mindestens zu 97% angegeben. Bei den Gesundheitsämtern vom BKG sind, bis auf Telefax (80%) und E_Mail (90%), die Attribute mindestens zu 99% angegeben. Bei den OSM sieht dies anders aus. Vergleichbare Eigenschaften, also Tags (key-value Paare), sind bei den in OSM vorhandenen Standorten der Polizei mit name (86%), addr:street/housenumber/postcode/city (ca. 63%), phone (27%) und fax (8%) mit einem Wert vorhandenen. Bei den Gesundheitsämtern von OSM sieht es ähnlich aus: Hier sind name (100%), addr:street/housenumber/postcode/city (ca. 78%), phone (14%) und fax (7%) mit einem Wert befüllt.
Um die Genauigkeit der Lage (Positionsgenauigkeit) zu vergleichen, wurde jeweils mit einem Puffer im Umkreis von 500m um den Standort einer Landespolizei oder eines Gesundheitsamtes vom BKG nach vergleichbaren Objekten in OSM gesucht. Im genannten Umkreis der Landespolizei-Stellen vom BKG befindet sich bei 87% ein erstelltes Polizei-Element im OSM Datensatz. Bei den Gesundheitsämtern finden sich bei 44% ein Eintrag bei OSM.
Die Prüfung der thematischen Genauigkeit erfolgte nur über einen minimalistischen Ansatz, in dem die Namen der über die Positionsgenauigkeit verknüpften Objekte miteinander verglichen wurden. Hierbei zeigte sich, dass nur 25% (Gesundheitsämter) und 32% (Landespolizei) der Namen zwischen den BKG und OSM Datensätzen exakt übereinstimmen. Die Untersuchung dieses Qualitätsmerkmals könnte oder müsste umfangreicher angegangen werden.
Die Datensätze des BKG wurden im Jahr 2021 veröffentlicht. Bei OpenStreetMap wird für gewöhnlich der Zeitpunkt der letzten Änderung des Elementes für die Aktualität bzw. zeitliche Genauigkeit verwendet.
Zusatzinfo: Die Mitwirkenden beim OSM Projekt – In OpenStreetMap haben bei den Standorten der Polizei insgesamt mind. 1.428 verschiedene Mitglieder an den Daten mitgearbeitet. Bei den Gesundheitsämtern waren es mind. 120 Personen, die die Elemente in irgendeiner Form (Lage oder Sachinformationen) bearbeitet oder ergänzt haben.
Kurzzusammenfassung oder was bringt jetzt dieser „Vergleich“? Dieser Blog Post hat keinen Anspruch auf Richtig- und Vollständigkeit. Es wird dennoch gezeigt, dass neben der Quantität (siehe Vollständigkeit) insbesondere das Augenmerk anscheinend auf die Attribute bzw. enthaltenen Details zu den jeweiligen Einträgen bei OSM gelegt werden sollte. Welche Vorgehensweise hat sich bei OSM in der Vergangenheit etabliert? Zumindest in Deutschland sollten nicht nur meiner Meinung nach keine Datenimporte mehr stattfinden. Vielmehr würde es sich anbieten, und wie in manchen Städten oder Ländern bereits erfolgreich umgesetzt und gelebt, eine Art Datenabgleich angeboten werden, wonach Interessierte und Engagierte die einzelnen Einträge vergleichen können.
Solch freigebende Datensätze, wie die vom BKG, eignen sich hervorragend zur Kontrolle und/oder Erweiterung der gesammelten Daten des OpenStreetMap-Projektes. Um es hier auch erwähnt zu haben: Nicht nur gemeinsam zusammengetragene Daten, sondern auch offizielle Daten, können Fehler oder Abweichungen enthalten. Dadurch sollten nach Möglichkeit diese Daten oder Informationen nicht unreflektiert nach OSM übernommen werden.
PS: Dieser Blog Post hat keinen Anspruch einer Wissenschaftlichen Untersuchung, sondern ist einfach aus einer Laune heraus an einem Sonntagmorgen bei einem Espresso entstanden. Hoffe es waren dennoch ein paar interessante Einblicke für Euch mit dabei?
Vielen Dank, sehr interessant! Danke fürs Teilen.
Eine spannende Frage können wir jetzt anschließen: Was tun wir jetzt mit diesen Daten und der Erkenntnis, dass die Datensätze abweichen?
Den Daten-Update-Prozess für OSM kennen wir: mappen.
Der Daten-Update-Prozess von OpenData ist meist leider “nicht definiert”. Ich habe nicht recherchiert, wie das in diesem Fall ist; aber für uns ist ja auch OSM interessanter.
Bei der Frage zum “mappen” müssen wir verzweigen:
(a) Erlaubt die Lizenz die Daten zu übernehmen? Dann wäre es ideal, wenn aus deiner Analyse ein GeoJSON extrahiert werde könnte, das beschreibt, wo eine Prüfung sinnvoll ist. Bspw. mit properties wie “‘CheckLocation‘: ‘OSM-Daten weichen 10 m von OpenData ID 123 ab.'” oder “‘CheckContact’: ‘OpenData ID 123 (Link) gibt als `street` 123 an, in OSM steht 234′”.
Dieses GeoJSON könnten wir dann in eine Maproulette Challenge packen und dort abarbeiten.
(b) Erlaubt die Lizenz keine Datenübername (inkl OSM-Kompatibilität der Lizenz) (wie leider häufig; ich habe auch das in diesem Fall nicht recherchiert), könnten wir zumindest einen Prüfschritt notieren. Auch das kann wieder ein GeoJSON sein, indem sinngemäß steht “An dieser Stelle gibt OpenData ID 123 an, eine Polizeistation Name X zu haben. Die Daten aus dem Datensatz dürfen nicht kopiert werden, aber nimm diesen Hinweis gerne zum Anlass lokal oder im Netz zu recherchieren.” Auch das könnte wieder eine MapRoulette Challenge sein. Diese vielleicht mit dem Flag “Ortskenntnis nötig”.
Hallo Tobias,
danke für deinen Kommentar.
Deine Fragen sind absolut berechtigt. Ja, die beiden hier untersuchten Datensätze vom BKG dürfen für OSM verwendet werden, siehe [1]. Von Seiten des BKG wurde vorgeschlagen, dass mögliche Fehler in deren Daten als Issue auf Github [2] gemeldet werden könnten.
Zu deiner Frage (a): Ich stelle im ersten Schritt einmal die beiden GeoJSON bereit, in dem die vermeintlich in OSM fehlenden Polizeistationen und Gesundheitsämter drin enthalten sind. Sie sind jetzt ebenfalls auf Github im Repo zu finden [3].
[1] https://github.com/fossgis/open-data/tree/main/bkg
[2] https://github.com/fossgis/open-data/issues
[3] https://github.com/fossgis/open-data/issues/2
Als erstes vielen Dank für deine Analyse und den schönen Artikel @Pascal!
Schön auch, dass das BKG mal etwas in Richtung OpenData tut und das der FOSSGIS dabei wichtige Vermittlungsarbeit zwischen Community und Verwaltung leistet!
Dennoch muss man auch klar sagen, dass das BKG nur “meta” ist, sprich Daten aggregiert und kaum Einblick über deren Qualiät und Aktualität hat.
@Tobias hat wichtige Punkte angesprochen, insb. wie QS realisiert werden kann. Da gibt es leider weder auf Bund/Länder/Kommunen Ebene irgendein etabbliertes Verfahren. Auch mal endlich eine klare Dokumentation was man da an Daten bekommt, würde den Nutzen in meinen Augen total erhöhen. Letztlich aber nur um Flächendeckung in OSM zu verbessern. Entgegen deiner Darstellung würde ich bei OSM eher einen höheren Detailgrad sehen.
Eine überprüfung welche Orte in den amtlichen Daten fehlen hattest du aber nicht, oder?
Ich mache mich mal an die Daten und schaue was mir hier begegnet für mein Bundesland:
https://github.com/fossgis/open-data/tree/main/bkg/gesundheitsaemter
Hallo Matthias,
freut mich wieder mal etwas von dir zu hören.
Ja, bei einigen von dir genannten Punkten hast du absolut Recht.
Die Details (Attribute) sind bei OSM leider nicht so vollständig wie du es erwähnst. Schau dir vlt. nochmals die Ergebnisse der Kategorie “Logische Konsistenz” und so wie es hier geprüft wurde an. Oder hast du mit “Details” nicht Attribute (Sachinformationen) sondern eher Geometrien der Objekte gemeint?
Die umgekehrte von dir erwähnte Prüfung, welche Daten von OSM nicht im BKG Datensatz enthalten sind, habe ich noch nicht gemacht. Sie könnte aber ohne Weiteres durchgeführt werden. Die Tendenz des Ergebnisses ist ja bereits in der “Vollständigkeit” der jetzigen Zahlen erkennbar.
Hi, ich glaube was ich meinte ist, dass viele Daten zwar nicht an den Knoten selbst sind, aber z.B. über Vereinigung mit dem umgebenden Way des Gebäudes angefächert werden können. Auch hat OSM ja eher eine Abneigung sich schnell verändernde Informationen wie Ansprechpartner, Tel., eMail, … direkt in den Geodaten zu erfassen? Für sowas wie wheelchair, level, … hat der Datensatz des BKG wiederum keine Entsprechung 😉
Habe jedenfalls mal die Gelegenheit genutzt hier oben im Norden ein paar Dinge zu kontrollieren und auch anzupassen. GeoJSON wäre halt nett gewesen, dann hätte man direkt über PRs die Fehler der amtlichen Daten melden können.HU55
Hallo Pascal, hallo Matthias,
vielen Dank für den Vergleich unserer POI-Themen Gesundheitsämter und Landespolizei mit OSM!
In Anlehnung an Matthias‘ Anmerkung hins. Qualität und Aktualität habe ich über Katja dem GitHub-Verzeichnis noch eine Datensatzbeschreibung zu den beiden POI-Themen hinzugefügt (https://github.com/fossgis/open-data/tree/main/bkg).
[…] Neis has written a blog post comparing > German Federal Government and OSM data for amenity=police and government=healthcare in […]
please, add osmcha to osm suspicious feed. it is more stable than achavi