OpenStreetMap als Fallbeispiel einer Datenanalyse

OSM ist kein gewöhnliches Datenbanksystem. Es verwendet ein flexibles Modell, bei dem die Bedeutung eines Objekts nicht durch feste Tabellenspalten definiert wird, sondern durch freie Schlüssel-Wert-Paare. Schlüssel-Wert-Paare werden Tags genannt. Das macht OSM zu einem interessanten Fallbeispiel für die Datenanalyse, weil es grundlegende Fragen der Datenverwaltung aufwirft:

Dieser Kurs hat folgenden Ablauf: Wir starten bei der realen Welt und arbeiten uns Schritt für Schritt bis zur automatisierten Qualitätsprüfung und Visualisierung vor.

Die Kernidee: Reale Objekte fallen nicht automatisch in saubere Tabellen. Erst durch bewusste Modellierungsentscheidungen entstehen aus flexiblen Tags und Geometrien abfragbare Datenbankstrukturen.

Für jeden Schritt gibt es eine Lerneinheit, die jeweils offene Aufgabenstellungen enthalten, teilweise gefolgt von einem Tipp.

Bevor wir über Datenbanken sprechen können, müssen wir klären, was wir eigentlich erfassen wollen. In einem Quartier gibt es unzählige Dinge: Wandmalereien, Restaurants, Strassen, Bäume, Briefkästen. In der Datenbanksprache nennt man solche eindeutig abgrenzbaren Dinge Entitäten.

Eine Entität ist ein eindeutig identifizierbares Objekt der realen Welt, das uns interessiert und über das wir Daten speichern wollen. Beispiel: ein Wandbild an der Hausfassade an der Seefeldstrasse in Zürich.

Ein Attribut ist eine Eigenschaft dieser Entität. Beispiel: Das Wandbild hat einen Titel, einen Standort und einen bekannten Künstler. Jede Entität ist einmalig und wird durch eine eindeutige ID unterschieden – auch wenn zwei Kunstwerke identische Attribute hätten.

OSM kennt drei Grundtypen für die Geometrie eines Objekts: Punkte, Linien und Flächen. Die Wahl hängt davon ab, wie gross und wie ausgedehnt das Objekt in der Realität ist.

Restaurants sind in OSM also entweder als Punkt oder als Fläche erfasst – das müssen wir bei der Abfrage beachten. Es kann aber auch dazu führen, dass Restaurants doppelt erfasst werden, ein typisches Datenqualitätsproblem, das wir in Lerneinheit 5 untersuchen.

Öffnet openstreetmap.org und navigiert zum Seefeld oder zu einem euch bekannten Quartier.

In OSM wird jedes Objekt über Tags beschrieben – einfache Schlüssel-Wert-Paare der Form key=value. Ein Street-Art-Objekt könnte zum Beispiel – nebst der Lage – folgende Tags tragen:

Es gibt keine Pflicht, bestimmte Tags zu setzen – ausser dem Haupttag, der das Objekt grundsätzlich klassifiziert (hier: tourism=artwork). Alle weiteren Tags sind optional (Nebentags) und hängen davon ab, ob jemand die Zeit und das Wissen hatte, sie einzutragen.

In einer klassischen relationalen Datenbank legt man das Schema vor der Dateneingabe fest: Man definiert Tabellen und Spalten, und jede Zeile muss sich an diese Struktur halten. Das nennt man Schema-on-write.

OSM hingegen folgt dem Prinzip Schema-on-read: Es gibt kein fixes Spaltenschema. Die Bedeutung eines Objekts ergibt sich erst beim Lesen – durch die Interpretation der Tags. Das macht OSM extrem flexibel, aber auch weniger konsistent.

Ein wichtiger Unterschied: Wenn ein Street-Art-Objekt kein Tag artist_name trägt, bedeutet das nicht, dass der Künstler unbekannt ist. Es bedeutet: Diese Information wurde noch nicht erfasst. Bei Datenqualitätsanalysen ist dieser Unterschied entscheidend.

Street Art sind Kunstwerke an Hausfassaden, "Kunst am Bau", und gehören zur zeitgenössischen Kunst (vgl. Zürich: https://www.zuerich.com/de/kunst-kultur/kunst-im-oeffentlichen-raum/street-art). Sie sind eine spezielle Form von Kunst im öffentlichen Raum.

Untersucht auf openstreetmap.org mehrere Restaurants im Seefeld oder in einem anderen Quartier:

OSM-Rohdaten liegen im XML- oder PBF-Format vor und bestehen aus Nodes, Ways und Relations mit beliebig vielen Tags. Dieses Format eignet sich schlecht für analytische Fragen wie "Welche Restaurants ohne cuisine-Tag gibt es im Seefeld?".

Wir brauchen deshalb einen Datenbank-Transfer: Die OSM-Daten werden in eine relationale Datenbank importiert, wo wir sie mit SQL abfragen können. Genau das macht Postpass: Es importiert laufend aktuelle OSM-Daten in eine Datenbank (PostgreSQL/PostGIS) und macht sie über SQL zugänglich. Tags werden dabei als jsonb-Feld gespeichert.

Wie bilden wir die flexiblen OSM-Tags auf eine strukturierte Datenbank ab? In technischen Worten: Wie ist die Schema-Abbildung?

OSM speichert alles in drei Elementtypen (Node, Way, Relation) mit beliebigen Tags. Eine GIS-Tabelle erwartet aber feste Spalten und einen klaren Geometrietyp. Die Schema-Abbildung muss unter anderem drei Fragen beantworten:

Es gibt mindestens drei grundsätzliche Ansätze. Postpass hat sich für Ansatz 3 (Hybridmodell) entschieden. Wer diese Diskussion abkürzen möchte, kann direkt zu Ansatz 3 und dann zu Lerneinheit 4 springen.

Ihr habt soeben drei verschiedene Arten kennengelernt, OSM-Daten in einer Datenbank zu speichern. Ziel dieser Aufgabe ist es, die Ansätze anhand eines konkreten Beispiels zu vergleichen und zu beurteilen.

Ausgangssituation: Im Quartier Seefeld gibt es ein Restaurant mit folgenden OSM-Tags:

Postpass stellt unter anderem folgende Tabellen und Views (vorbereitete, kombinierte Tabellen) bereit:

Das vollständige Postpass-Schema findet sich unter diesem Link.

Postpass-Abfragen werden durch eine Kopfzeile eingeleitet, die den SQL-Server festlegt. Dann folgt die eigentliche SQL-Abfrage – ohne Strichpunkt am Schluss, wie es oft üblich ist.

Die Kopfzeile {{data:sql,server=…​}} muss immer auf der ersten Zeile stehen. Sie ist eine Anweisung an overpass-turbo, die nachfolgende SQL-Abfrage an den Postpass-Server weiterzuleiten.

Der Operator && in PostGIS prüft, ob sich zwei Geometrien in ihren Bounding Boxes überlappen. Er ist sehr schnell, weil PostGIS dafür einen räumlichen Index verwendet. ST_MakeEnvelope(west, süd, ost, nord, srid) erstellt ein Rechteck aus den vier Eckkoordinaten.

Wenn der Tag name bei einem Objekt fehlt, liefert tags→>'name' den Wert NULL zurück – kein Fehler, sondern fehlende Information.

Restaurants kommen in OSM sowohl als Punkte als auch als Flächen vor. Deshalb verwenden wir den View postpass_pointpolygon, der beide vereint.

Die Spalte osm_type zeigt, ob ein Restaurant als Node ('node') oder als Flächenway ('way') erfasst wurde. Kommen beide für dasselbe Gebäude vor, liegt eine Dublette vor.

Trottoirs können auf zwei Arten in OSM modelliert sein: als eigene Linie mit footway=sidewalk oder als Attribut sidewalk=* an der Strasse selbst. Beide Varianten sollte die Abfrage erfassen.

Der Operator ? 'key' gibt TRUE zurück, wenn der JSON-Schlüssel im Tags-Objekt vorhanden ist – unabhängig davon, welchen Wert er hat. Das ist nützlich, wenn wir nur wissen wollen, ob eine Information erfasst wurde.

Schreibt auf overpass-turbo.eu eine eigene Postpass-SQL-Abfrage, die folgende Frage beantwortet: Welche Restaurants im Seefeld haben sowohl einen Namen als auch eine angegebene Küche (cuisine)?

Vorlage:

Bonusfrage: Wie viele Restaurants liefert eure Abfrage zurück? Vergleicht das Ergebnis mit der Gesamtzahl aller Restaurants aus Abfrage 2.

Datenqualität beschreibt, wie gut Daten ihren beabsichtigten Zweck erfüllen. Wir unterscheiden vier Dimensionen:

NOT tags ? 'name' ist wahr, wenn der Schlüssel name im Tags-Objekt fehlt. Das ist ein strikter Vollständigkeitscheck: Kein leerer String, kein NULL – der Key existiert schlicht nicht.

Aus dem Ergebnis lässt sich ablesen, wie viele Trottoirs als eigene Linien modelliert sind und wie viele nur als Attribut an einer Strasse hängen. Diese Inkonsistenz erschwert Auswertungen erheblich, weil man beide Varianten immer parallel mitdenken muss.

COUNT(*) FILTER (WHERE …​) ist eine PostgreSQL-Kurzschreibweise für eine bedingte Zählung: Es wird nur gezählt, wenn die Bedingung wahr ist. Das Ergebnis gibt auf einen Blick einen Qualitätsüberblick über alle Kategorien.

Am Ende dieser Einheit erstellt ihr einen strukturierten Qualitätsbericht. Füllt die folgende Vorlage mit den Ergebnissen eurer Abfragen aus und präsentiert eure Ergebnisse in fünf Minuten der Klasse.

Gebiet: [Quartier / Ort] Abfragedatum: [Datum]

Führt die vier Qualitätsprüfungen für ein Quartier eurer Wahl durch. Passt dazu die ST_MakeEnvelope-Koordinaten entsprechend an. Beantwortet in eurer Präsentation:

overpass-turbo bietet nach einer erfolgreichen Abfrage verschiedene Exportmöglichkeiten. Über den Button Export oben links lässt sich das Ergebnis als GeoJSON herunterladen. GeoJSON ist ein offenes Format für geografische Daten, das von den meisten Visualisierungswerkzeugen unterstützt wird.

Für tabellarische Auswertungen (z.B. Qualitätsberichte) können die Ergebnisse aus der Tabellenansicht von overpass-turbo als CSV kopiert oder direkt in eine Tabellenkalkulation übertragen werden.

uMap ist ein kostenloses Online-Werkzeug zum Erstellen von Karten auf Basis von OSM. Es erlaubt den direkten Import von GeoJSON-Dateien.

Vorgehensweise:

QGIS ist ein kostenloses Desktop-GIS-Programm für komplexere Visualisierungen und räumliche Analysen.

Visualisiert die Ergebnisse aus Lerneinheit 5 auf einer Karte:

In diesem Workshop haben wir OpenStreetMap nicht nur als Karte, sondern als Datenbank kennengelernt. Wir haben gesehen, wie reale Objekte – Street Art, Restaurants, Trottoirs – als Nodes, Ways und Tags modelliert werden, und warum diese flexible Struktur sowohl eine Stärke als auch eine Herausforderung ist. Mit SQL und Postpass konnten wir gezielt Abfragen stellen, Qualitätsprobleme aufdecken und die Ergebnisse visualisieren.

Die wichtigsten Erkenntnisse: Daten entstehen nicht einfach – sie werden von Menschen erfasst, und das sieht man ihnen an. Vollständigkeit, Konsistenz und Aktualität sind keine Selbstverständlichkeit, sondern das Ergebnis kollektiver Arbeit. Und: Mit den richtigen Werkzeugen lassen sich auch grosse, unstrukturierte Datensätze systematisch analysieren.

Bei Street Art bzw. Kunst im öffentlichen Raum, die in OSM erfasst ist, wäre es schön, wenn man zu den Objekten auch Fotos und Bilder verwalten kann. In OSM selbst werden keine Bilder gespeichert, aber OSM kann auf Bilder verweisen. Solche Bilder können zum Beispiel mit der Commons App in Wikimedia Commons hochgeladen werden, sofern die Urheberrechte und Lizenzen dies erlauben. In OSM kann man danach mit dem Tag wikimedia_commons=* auf die passende Commons-Kategorie oder Datei verlinken, zum Beispiel wikimedia_commons=Category:Street art in Zürich oder wikimedia_commons=File:Beispielbild.jpg. Für einzelne direkte Bild-URLs wird zusätzlich häufig image=_ verwendet (wiki.openstreetmap.org).

Wer selbst zur Verbesserung der OSM-Daten beitragen möchte, kann an einem Mapathon teilnehmen. Bei einem Mapathon arbeiten Gruppen gemeinsam daran, ein bestimmtes Gebiet in OSM zu vervollständigen – zum Beispiel fehlende Street-Art-Objekte, Restaurants ohne cuisine-Tag oder Trottoirs ohne Belagsangabe zu ergänzen. Mapathons werden regelmässig von lokalen OSM-Communities, Hochschulen und NGOs organisiert.

Ein guter Einstieg ist die Webseite openstreetmap.org/about, wo lokale Gruppen und Veranstaltungen aufgelistet sind wie zum Beispiel die OSM.ch. Wer lieber im eigenen Quartier kartieren möchte, kann direkt den im OSM.org eingebauten Editor (iD-Editor) nutzen oder zum Beispiel die mobile App StreetComplete (Android) oder die mobile Webapp MapComplete verwenden, die beide gezielte Aufgaben zum Ergänzen fehlender Tags anbieten.

LearnOSM (learnosm.org) ist das offizielle Lernportal der OSM-Community und erklärt Schritt für Schritt, wie man Daten erfasst, den JOSM-Editor bedient und an Mapping-Projekten teilnimmt.

Das OSM-Wiki (wiki.openstreetmap.org) ist die umfassendste Referenz für alle Tagging-Konventionen und eignet sich, um nachzuschauen, wie ein bestimmtes Objekt korrekt erfasst wird.

OpenSchoolMaps (openschoolmaps.ch) bietet eine Sammlung von Unterrichtsmaterialien rund um OSM und Geodaten, speziell für den Schulunterricht aufbereitet. Die Themen reichen von der einfachen Kartennutzung von OpenStreetMap über die Datenanalyse mit QGIS bis zu weiteren Informatikthemen.

Auf OpenSchoolMaps gibt es ein spezielles Tutorial für das OpenStreetMap-Daten extrahieren mit SQL und Postpass. Und es lohnt sich ein Blick auf die Postpass-Beispielsammlung im OSM-Wiki (wiki.openstreetmap.org/wiki/Postpass/Examples).