OpenStreetMap (OSM) ist ein freier Geodatensatz der durch eine global agierende Community gehalten, verwaltet und aktualisiert wird. Der Datensatz ist semantisch, geometrisch und räumlich sehr heterogen. Ursprünglich als “freies Straßennetz” gedacht, umfasst OSM heute Daten aus einer Vielzahl thematischer Bereiche auf der ganzen Welt. In diesem Projekt wird der gesamte OSM-Datensatz auf seine Eigenschaften untersucht. Ziel ist es Aussagen über die Qualität und vor allem über die Nutzbarkeit im Zusammenhang mit Anwendungsgebiet und eingesetzter Software treffen zu können.

Christopher Braune (GFZ/Cegit): cbraune@gfz-potsdam.de

Aufgaben/Ziele:

• Untersuchung des globalen OSM-Datensatzes
• Feststellung der Datenqualität ohne Referenzdaten
• Untersuchung der räumlichen Heterogenität der Daten
• Einfluss der Einwohnerzahl auf Datenmenge und Qualität
• Räumliche Untersuchung aufgrund administrativer Grenzen und frei definierter Raster
• Vor- und Nachteile bezüglich der Verwendung von OSM-Daten (für verschiedene Aufgabenstellungen)

Verwendete Software:

• Linux Plattform (Distribution: Ubuntu 11.10)
• R statistics (verschiedene packages: u.A. osmar, sp)
• Quantum GIS
• GoogleEarth
• Online Geodaten Konverter: http://converter.mygeodata.eu/
• PostGIS
• PgAdmin III
• Osmosis
• GRASS GIS
• … (Weitere in Zukunft möglich)

Allgemeine Informationen zum OpenStreetMap-Projekt

• frei zugängliche Geodaten (Vektordaten)
• Einpflegen neuer Daten erfolgt über die Mitglieder der Community
• keine Kontrollinstanz in Bezug auf Konsistenz und semantischer Richtigkeit der Daten
• der größte Teil der Daten wird durch wenige Mitglieder („poweruser“) erfasst

Allgemeine Information zu den OSM-Daten

• Speicherung im XML-Format
• Drei Objekttypen: nodes, ways und relations
• Semantische Bedeutung wird durch frei wählbare Tags definiert
• Mögliche Datenquellen: Primärerfassung mit GPS-Geräten, Sekundärerfassung aus freien Satellitenbildern (z.B. Landsatdaten), zusätzlich bereit gestellte lokale Geodaten öffentlicher Stellen

Datenquellen (Links):

• OSM-Daten:
  • http://planet.openstreetmap.org/
  • http://download.geofabrik.de/
  • … (Weitere in Zukunft möglich)
• GADM (database of Global Administrative Areas): http://www.gadm.org/
• SEDAC (Socioeconomic Data and Applications Center)

Datenqualität ohne die Berücksichtigung der Lagegenauigkeit

Die qualitative Untersuchung soll unabhängig von der Lagegenauigkeit vorgenommen werden. Diese Herangehensweise erscheint ungewöhlich für raumbezogene Daten. Beispielsweise ist aber die Lageganauigkeit für die Nutzung in Navigationsgeräten weniger relavant. In diesem Bereich muss ohnehin die Standortgenauigkeit des eigenen GPS-Signals beachtet und Ungenauigkeiten automatisiert ausgeglichen werden. Hinzu kommt, dass kein vergleichenbaren Datensatz existiert. Es ist daher lediglich möglich Ausschnitte aus dem OSM-Datensatz auf die Lagegenauigkeit vergleichend zu untersuchen (z. B. das Starßennetz). Objekte die ausschließlich in OSM erfasst sind, bleiben somit unberücksichtigt.

• Untersuchungsparameter:
  • Objektdichte in Abhängigkeit von der Bevölkerung
  • Objektdichte pro Fläche
  • Fehler in der Geometrie (speziell für Objekte, welche als Polygone definiert sind)
  • Nutzbare (allgemein bekannte) tags - HINWEIS: http://tagwatch.stoecker.eu/

Feststellung und Dokumentation der Qualität von Geodaten

Um die Qualität von Daten im Allgemeinen und die von Geodaten im Speziellen festzustellen, müssen eindeutige und aussagekräftige Kriterien definiert werden. Die ISO 19113 (2002) „Geographic information – Quality principles“ als auch die PAS 1071 (PAS… Publicly Available Specification) „Qualitätsmodell für die Beschreibung von Geodaten“ wurden zu diesem Zweck verfasst.

Ziel dieses Abschnitts ist es, Kriterien zu finden und zu definieren um die OSM-Daten bewerten zu können.

Der Vergleich zwischen der ISO 19113 (oder allgemeiner ISO 19xxx-Famile) und der PAS 1071 zeigt, dass beide Dokumente eine andere Zielstellung verfolgen. Die International Organization for Standardization (ISO) richtet den Fokus auf die Beschreibung von Geodaten und die Art und Weise der Dokumentation von Datenqualität. Die Formulierungen sind abstrakt, wenig anwendungsbezogen aber allgemein gültig. In der PAS 1071 wird der Inhalt der ISO 19113 aufgegriffen. Jedoch liegt der Fokus etwas mehr auf die Anwendung bestimmter Richtlinien. Die PAS enthält ein Schema für den Umgang mit Geodatenqualität. Als Resultat dieses Schemas wird eine Art von Geodatenqualitätskatalog definiert. Dieser hat das Ziel eine einheitliche Basis sowohl für den Nutzer als auch für den Hersteller der Geodaten zur Verfügung zu stellen. Die PAS 1071 kann als praktische Ergänzung zur ISO 19113 angesehen werden.

ANMERKUNG: Eine PAS wird durch das Deutsche Institut für Normung verabschiedet. Es handelt sich aber nicht um eine Norm! Für den Inhalt ist daher nicht das DIN sondern lediglich der Verfasser verantwortlich (im Falle der PAS 1071: CEGI Center for Geoinformation GmbH, Dortmund).

Das GDI-NI (Geodateninfrastruktur-Niedersachsen) nennt fünf Qualitätsmerkmale welche objektiv messbar sind:

• Aktualität der Daten
• geometrische Genauigkeit
• Richtigkeit und Vollständigkeit der Daten
• Umfang der Attributierung / Sachinformationen
• Konsistenz der Datenmodellierung und logische Gültigkeit

FRAGE: Wie kann eine Untersuchung eines kompletten OSM-planetfiles (XML-Daten) erfolgen?

ANSATZ: osmar-package für GNU R → Definition einer bounding box nötig! Potentielle Verwendung für die Betrachtung von einzelnen Rasterzellen.

• sp-package: Schnittstelle für Objektklassen und Funktionen verschiedener anderer R-Pakete
• rgdal-package: Schnittstelle zu GDAL (Geospatial Data Abstraction Library)→ Voraussetzung OGR (Simple Features Library) installiert
• Liste unterstützter Vectordatenformate von OGR siehe: http://www.gdal.org/ogr/ogr_formats.html

• gadm-Daten können direkt in R (bzw. sp-package) kompatiblen Format bezogen werden (“RData”)

PROBLEME:

• Die bereits genannte und zwingend notwendige Definition von bounding-boxes
• Weiterhin ist die Untersuchung von XML-Daten zwar prinzipiell möglich aber sehr speicherintensiv und träge

• Konvertierung und Verarbeitung der Daten innerhalb einer Datenbank bietet einen potentiellen Ausweg

Die XML-Daten sollen mit Hilfe einer relationalen Datenbank effizienter verarbeitet, gespeichert und untersucht werden. Es wird ebenfalls möglich sein die Daten effizient zu aktualisieren.

Ziel ist eine Host-Client-Infrastruktur zu realisieren die genügend Performance für eine effiziente Analyse bietet. Die Wahl viel auf eine PostgreSQL-Datenbank mit PostGIS-Erweiterung. Diese ist frei verfügbar und unterstützt die spezifischen Eigenschaften von Geodaten (wie Geometrie und SRS).

Hardware:

• Datenbankserver:
  • Virtuelle Maschine mit der aktuelle simulierten Hardwarekonfiguration - 16 CPU Kerne, 64 GB RAM, HDD 50 GB (System) und 500 GB (Daten)
  • Darunterliegende Maschinen: Zwei Rechner mit je 4 CPUs mit 16 Kernen, 256 GB RAM (CPU Takt: erster Rechner: 2,1 GHz, zweiter Rechner: 2,3 GHz)

• Client-Rechner: einfacher Laptop (OS: Ubuntu 11.10)

Notwendige Software-Pakete - Host:

• PostgreSQL und PostGIS-Erweitertung
• OSM2PGSQL oder OSMOSIS zur Überführung der XML-Daten in die Datenbank

Notwendige Software-Pakete – Client:

• PostgreSQL (mindestens Client-Version) und PostGIS-Erweiterung
• OSM2PGSQL oder OSMOSIS zur Überführung der XML-Daten in die Datenbank

Optionale Software-Pakete – Client:

• pgAdminIII (GUI für den Zugriff auf die Datenbank)
• QGIS (enthält bereits ein Interface zu einer PostgreSQL-DB)
• R mit dem RPostgreSQL-Paket (zur Datenanalyse in R)

osm2pgsql vs. osmosis Beide Tools bieten die Möglichkeit die OSM-Daten aus einem planet-file heraus in eine relationale Datenbank zu überführen. Zu diesem Zweck beinhalten beide Tools Vorlagen für Relationenschemata die zuvor in einer erstellten Datenbank erzeugt werden müssen.

• Datenbankschema von osm2pgsql:
  • geometry_columns
  • planet_osm_line
  • planet_osm_point
  • planet_osm_polygon
  • planet_osm_roads
  • spatial_ref_sys

• Dantenbankschema von osmosis - Variante 1 (hstore):
  • geometry_columns
  • nodes
  • relation_members
  • relations
  • schema_info
  • spatial_ref_sys
  • users
  • way_nodes
  • ways

• Dantenbankschema von osmosis - Variante 2(simple):
  • geometry_columns
  • node_tags
  • nodes
  • relation_members
  • relation_tags
  • relations
  • schema_info
  • spatial_ref_sys
  • users
  • way_nodes
  • way_tags
  • ways

Beide Tools wurden getestet. Obwohl osm2pgsql gewisse Vorteile bietet, fiel die Entscheidung zugunsten von osmosis. Die Relationenschemata von osm2pgsql wirken sich nachteilig auf den angestrebten Untersuchungsprozess aus. Eigenschaften wie user und timestamp entfallen vollständig. Dem gegenüber steht osmosis. Dieses Tool bietet insgesamt mehr Optionen und deutlich stärker normalisierte Relatinenschemata. Außerdem lehnen sich diese Schemata stärker an die Struktur der originalen OSM-Daten an, nodes, ways und relations bleiben als Typen erhalten.

Ein weiterer wichtiger Faktor ist der Umgang mit den tags. Bei osm2pgsql können die tags lediglich im sogenannten hstore Datenformat gespeichert (aktuelle Version von osm2pgsql vorrausgestzt!). Damit wird ein entsprechendes Attribut mit key⇒value-Verkettungen gefüllt. Diese Möglichkeit steht auch in osmosis zur Verfügung (erste Variante). Da jedoch die SQL-Operatoren für das hstore-Datenformat äußerst begrenzt sind, ist die zweite Variante von osmosis am besten geeignet. Die tags werden in separaten Tabellen und getrennten Attributen im string-Datenformat gespeichert. Über die osm_id können diese den eigentlichen Objekten zugeordnet werden. Nachteilig ist dadurch, dass Datenbankanfragen verschachtelter und somit komplexer formuliert werden müssen.

Stand:

• 30.05.13: Testphase auf einem Laptop mit Host und Client in einer Maschine mit allen notwendigen und optionalen Paketen.

• 21.06.13: Der Linux-Server steht zur Verfügung. Die notwendige Software wurde installiert und die Verbindung zum Client wurde eingerichtet. Außerdem wurden bereits Versuchdatenbanken angelegt und erste Datenbankanfragen gestestet.

• 13.08.13: Der Datenbank-Server funktioniert uneingeschränkt. Es wurde ein Script zur automatisierten Datenbankerstellung und zum Datenimport erstellt.

• 22.11.13: Zur Nutzung der Daten in GRASS GIS kann keine ID mit dem Datentyp bigint (big integer) verwendet werden. Die Erzeugung einer neuen ID-Spalte des Typs int (integer) schlug beim globalen Datensatz fehl. Die Fehlermeldung weist auf fehlenden Festplattenspeicher hin (obwohl der Speicher genügend Reserven bieten sollte).

Es wird nach einer vermuteten Korrelation zwischen der Bevölkerungsdichte und der OSM-Punktdichte gesucht. Die Bevölkerungsinformationen der SEDEC liegen im Rasterdatenformat vor. Sowohl die Bevölkerungsdichte als auch die absoluten Bevölkerungszahlen (Stand 2000) sind verfügbar. Mit Hilfe einer Rasterdatenverschneidung sollte es möglich sein einen Zusammenhang zwischen diesen beiden Größen herzustellen.

Um die Untersuchung durchzuführen, ist notwendig die OSM-Daten in Rasterdaten umzuwandeln. Demnach muss ein Punktdichte-Raster erzeugt werden. Die OSM-Daten werden dafür aus der PostGIS-Datenbank bezogen. Das Tabellenschema von Osmosis (Variante 2 - simple) enthält als Geometrietyp lediglich Punkte. Diese Punkte erzeugen über Relations alle anderen Geometrietypen. Für Untersuchung der möglichen Korrelation zwischen Bevölkerung und OSM-Objektdichte genügen demnach die Punkte aus der Postgis-Datenbank.

Die Rasterberechnungen sollen auf auf dem Cluster-Rechner durchgeführt werden. Als Software für diese Berechnungen wird GRASS GIS angestrebt.

Angestrebte Auswertungsverfahren:

1. Überlagerung beider Rasterdatensätze mit GRASS und räumlicher Vergleich:
   • GRASS-Funktion: “Analyze map” » “Bivariate Scatterplot Tool”
   • Ein Streudiagramm erbringt im bestem Fall den Nachweis der erwartete Korrelation
   • Ein erster Test für den Bereich Berlin-Brandenburg:

1. Weiterführende, potentielle Verfahren:
   • Klassifizierung beider Rasterdatensätze » Bildung von Aggregaten
   • Überlagerung der jeweils aggregierten Flächen
   • Resultat: Raster- oder Vektordaten zur räumlichen Darstellung korrelierender Gebiete

Stand:

• 13.08.2013: Derzeit gibt es noch Probleme wie das Punktdichteraster mit GRASS erzeugt werden kann.
• 30.09.2013: Punktdichteraster mit Hilfe der Funktion “v.kernel”
• 01.10.2013: Erste Server-Versuche bezüglich des Punktdichterasters mit direktem Bezug aus der PostGIS-Datenbank
• 22.11.2013: Die genannten Probleme von GRASS GIS mit dem bigint-Datentyp für die ID's erlauben bisher keine Prozessierung der Daten in GRASS
• 08.01.2014: Die relevanten Tabellen innerhalb der Datenbank wurden mit einer neuen “oid”-Spalte als Schlüssel erweitert

Was ist die “Dunkle Materie” ungetagter Geometrielemente? Wie verändert sich Diese über die Zeit? Die Bezeichnung “ungetagt” bezieht sich dabei auf die semantischen Eigenschaften von Objekten!

  Datenstand: xx.02.2013 (nicht genau datiert)
  * OSM-points 
    * 24,3% der Punkte enthalten keine Tags (Gesamtanzahl für Berlin-Brandenburg: 224044)
  * OSM-lines 
    * 1,5% der Linien enthalten keine Tags (Gesamtanzahl für Berlin-Brandenburg: 365100)
  * OSM-polygons (geschlossener Linienzug)
    * 1,0% der Polygone enthalten keine Tags (Gesamtanzahl für Berlin-Brandenburg: 525744)

• Die Punkte unterliegen (erwartungsgemäß) den größten Veränderungen aufgrund der einfachen Erfassung.

  Datenstand: 18.03.2013
  * OSM-points
    * 52,7% der Punkte enthalten keine Tags (Gesamtanzahl für Berlin-Brandenburg: 356010)
  * OSM-lines
    * 1,5% der Linien enthalten keine Tags (Gesamtanzahl für Berlin-Brandenburg: 361003)
  * OSM-polygons (geschlossener Linienzug)
    * 1,1% der Polygone enthalten keine Tags (Gesamtanzahl für Berlin-Brandenburg: 522141)

Export der “dunklen Materie” in KML/KMZ.

• Konvertierung der OSM-Daten mit Hilfe von Quantum GIS und dem online Geodaten Konverter (converter.mygeodata.eu)
• Quantum GIS: Konvertierung der OSM-Daten in Shapefiles
• Online Konverter: Konvertierung der zuvor gepackten Shapefiles (.zip) ins KML-Format

• Über GoogleEarth erkannte Punkt-Objekte: erfasste Einzelbäume, markierte Standgewässer, Gebäude-Eckpunkte (speziell Wohnhäuser → Privat?), Wege und Flurkanten
• Über GoogleEarth erkannte Linien-Objekte: meist flächenhafte Objekte wie Ackerflächen, Siedlungsflächen, Industriegebäude. ABER: eher weniger Verkehrsinfrastruktur!
  • Problem bzw. Qualitätsmangel → unsauber digitalisierte Flächen zeigen sich
• Über GoogleEarth erkannte Flächen-Objekte: Grünanlagen, Waldgebiete, Grundstücke (inkl. Freiflächen und Gebäude), Standgewässer, Brücken
• Räumlich und geometrisch nicht zuzuordnende Objekte sind vorhanden aber selten (immer in Bezug auf die Google-Daten!)

  Datenstand: 12.04.2013
  * OSM-points
    * 69,3% der Punkte enthalten keine Tags (Gesamtanzahl für Berlin-Brandenburg: 547411) -> Große Veränderung über die Zeit
  * OSM-lines
    * 1,5% der Linien enthalten keine Tags (Gesamtanzahl für Berlin-Brandenburg: 356026) -> Anteile nahezu identisch
  * OSM-polygons (geschlossener Linienzug)
    * 1,1% der Polygone enthalten keine Tags (Gesamtanzahl für Berlin-Brandenburg: 518480) -> Anteile nahezu identisch

• Vermutete Trends:
  1. Prozentuale Abnahme der ungetaggten Objekte mit Zunahme der Gesamtanzahl. → Das Gegenteil bildet sich ab. Zwischen Frebruar und April zeigt sich, dass sich die Anzahl der OSM-points mehr als verdoppelt hat. Dabei hat sich der prozentuale Anteil ungetaggter OSM-points sogar fast verdreifacht.
  2. Prozentuale Abnahme der ungetaggten Objekte zwischen den geometrischen Objekttypen - von points (viel) über lines nach polygons (wenig). → Das Verhältnis zwischen den Objektklassen ist relativ statisch. Die OSM-points unterliegen großer Fluktuationen. OSM-lines und -polygons schwanken weniger in ihrer Gesamtanzahl und auch beim prozentualen Anteil ungetaggter Objekte.

Mögliche Ursachen für die “Dunkle Materie”

Aufgrund der hohen Anzahl dieser Objekte liegt die Vermutung nahe, dass es sich um einen systematischen Fehler bei der Untersuchung handelt. Die XML-Daten konnten nicht direkt untersucht werden. Daher wurden sie in ein relationales Schema überführt. Es ist möglich, dass bei dieser Konvertierung tags ignoriert wurden. Die Nutzung des QGIS Plugins erlaubt die konkatenierte Übernahme der tags in ein relationales Attribut des Typs string. Bei der Recherche bezüglich des Tools osm2pgsql wurde deutlich, dass unbekannte tags ignoriert und folglich nicht übernommen werden. Im Falle von osm2pgsql führt dies sogar zum Ausschluss des Objekts. Dieses Verhalten des QGIS Plugins konnte bisher nicht durch eine Dokumentation belegt werden.

Stand:

• 30.05.2013: Aufgrund der möglichweise auftretenden Probleme mit dem QGIS Plugin wird für die weitere Untersuchung die erstellte PostGIS Datenbank genutzt. Diese wurde mit osmosis in der Variante 2 erstellt.
  • Anzahl der node_tags: 357089 (gruppiert aufgrund der node_id)
  • Anzahl der nodes ohne tags: 6210058

Untersuchung der Nutzbarkeit für verschiedene Anwendungen/Anwender oder Trennung aufgrund verschiedener Objektklassen (z. B. separaierter Untersuchung von Staatsgrenzen)

• In welchem Datenformat kann die Analyse überhaupt durchgeführt werden? Können die „originalen“ OSM-Daten (XML) überhaupt verwendet werden?
  • XML-Daten sind für eine effiziente, großräumige Analyse ungeeignet (siehe XML-Datenverarbeitung in R)
  • Mögliche Abhilfe durch ein Datenbanksystem (siehe Datenverarbeitung in einem Datenbanksystem)

• Sehr viele überlappende Flächen. Meist aufgrund der semantischen Bedeutung wie z.B. administrative Grenzen. Folge: Analyse nach Tags/Bedeutung gliedern? Aber: Problematik der frei wählbaren Tags. Wonach könnte eine sinnvolle Klassifizierung überhaupt erfolgen?

• Problematik der Unterscheidung zwischen Polygonen und einfachen geschlossenen Linienzügen: Linien (Ways) werden durch Zuweisung bestimmter Tags und durch einen gemeinsamen Anfangs- und Endpunkt definiert. Die Tags stellen dabei das Problem dar, dass keine einheitliche Nomenklatur existiert. Folge: die entsprechenden Tags sind global unterschiedlich!

• Polygone die aus mehreren geschlossenen Linien bestehen (z.B. Waldfläche mit Lichtung) müssten auf die Korrektheit der Relation hin untersucht werden > Ortskenntnis oder Vergleichsdaten erforderlich!
  • Detailfrage die vermutlich im globalen Maßstab nicht beantwortet werden kann

PAS 1071 (2007), Qualitätsmodell für die Beschreibung von Geodaten, CEGI Center for Geoinformation GmbH, Dortmund sowie Deutsches Institut für Normung (DIN)

ISO 19113 (2002) International Standard - Geographic information - Quality principles

GDI-NI (Geodateninfrastruktur-Niedersachsen), abgerufen: November 2013 http://www.geodaten.niedersachsen.de/portal/live.php?navigation_id=27216&article_id=91941&_psmand=28

Neis, P., D. Zielstra, and A. Zipf (2011), The Street Network Evolution of Crowdsourced Maps: OpenStreetMap in Germany 2007–2011, Future Internet, 4(1), 1–21, doi:10.3390/fi4010001. [online] Available from: http://www.mdpi.com/1999-5903/4/1/1 (Accessed 9 January 2012)

Thomas Schlesinger and Manuel J. A. Eugster, osmar: OpenStreetMap and R, September 10, 2012, preprint of the article “osmar: OpenStreetMap and R” accepted for publication on 2012-08-14 by the R-Journal.

F. Ramm, J. Topf, 2010, OpenStreetMap: Die freie Weltkarte nutzen und mitgestalten

Quantum GIS - Benutzerhandbuch, Version 1.5.0 ’Tethys’, Link: http://download.osgeo.org/qgis/doc/manual/qgis-1.5.0_user_guide_de.pdf

Zurück zur Startseite