DataWiki

User Tools

Site Tools

Trace: • samdat • samdat_project_website • samdat_project_test-environment • software
osm:start

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
osm:start [2014/01/09 13:20]
cbraune [Open Street Map] 		osm:start [2014/02/14 08:53] (current)
cbraune [Dunkle Materie - Objekte ohne Tags]
Line 3: Line 3:
 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. 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.
  
-Kontakt:  +Christopher Braune (GFZ/Cegit): cbraune@gfz-potsdam.de
-Christopher Braune (GFZ/Cegit) +
-cbraune@gfz-potsdam.de+
 ====== Allgemeines ====== ====== Allgemeines ======
  
Line 200: Line 198:
  
 Angestrebte Auswertungsverfahren: Angestrebte Auswertungsverfahren:
-  - Überlagerung beider Rasterdatensätze mit GRASS +  - Erzeugung des OSM-Objektdichterasters mit der GRASS-Funktion: "v.kernel" 
-  - Räumlicher Vergleich+    * Notwendige Parameter müssen ermittelt werden: Einflussradius, Rasterausdehnung und Rasterauflösung 
 +    * {{:osm:v.kernel_raster_brandenburg.png?direct&300|}} 
 +  - Ü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: 
 +    * {{:osm:pop_vs_osm_brb_test.jpeg?300|}} 
 +  - Weiterführende, potentielle Verfahren:
     * Klassifizierung beider Rasterdatensätze >> Bildung von Aggregaten     * Klassifizierung beider Rasterdatensätze >> Bildung von Aggregaten
     * Überlagerung der jeweils aggregierten Flächen     * Überlagerung der jeweils aggregierten Flächen
Line 212: Line 217:
   * 01.10.2013: Erste Server-Versuche bezüglich des Punktdichterasters mit direktem Bezug aus der PostGIS-Datenbank   * 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   * 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
-====== Festgestellte Probleme/Fragestellungen: ====== +  * 08.01.2014: Die relevanten Tabellen innerhalb der Datenbank wurden mit einer neuen "oid"-Spalte als Schlüssel erweitert 
- +  * 29.01.2014: Parameter der "v.kernel"-Funktion: Radius=0,25 (entsprechend der Map-Einheit), Rasterausdehnung und -auflösung entsprechend des Bevölkerungsrasters, die Rasterberechnung (500x500 Rasterzellen) benötigte ~ 170 Minuten (167 min 56 sec) 
-  * In welchem Datenformat kann die Analyse überhaupt durchgeführt werden? Können die „originalen“ OSM-Daten (XML) überhaupt verwendet werden? +  * 05.01.2014: Erfolgreiche Tests mit dem "Bivariate Scatterplot Tool"
-    * 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 +
- +
- +
-__Differenzierte Betrachtungsansätze:__ +
-  * Getrennte Betrachtung von semantischen Attributen (tags mit key=value Kombinationen) gegenüber den geometrischen Eigenschaften? +
-  * Untersuchung der Nutzbarkeit für verschiedene Anwendungen/Anwender oder Trennung aufgrund verschiedener Objektklassen (z. B. separaierter Untersuchung von Staatsgrenzen) +
- +
- +
  
 +====== Untersuchung der OSM-tags ======
  
 ===== "Dunkle Materie" - Objekte ohne Tags ===== ===== "Dunkle Materie" - Objekte ohne Tags =====
 +
  
  
Line 299: Line 286:
       * Anzahl der node_tags: 357089 (gruppiert aufgrund der node_id)       * Anzahl der node_tags: 357089 (gruppiert aufgrund der node_id)
       * Anzahl der nodes ohne tags: 6210058       * Anzahl der nodes ohne tags: 6210058
 +  * 11.12.13: Das QGIS-Plugin wurde genauer untersucht (Analyse des verwendeten Phython-Script). ERGEBNIS: Die Daten werden anhand bekannter tags untersucht/ausgewertet. Unbekannte tags entfallen dadurch. Es besteht weiterhin der Verdacht, dass trotz systematischer Fehler (durch die Nutzung des QGIS-Plugins) Objekte ohne Tags in OSM vorhanden sind.
 +  * 05.02.14: Datenbankanfragen laufen auf dem globalen Datensatz
 +  * 14.02.14: Datenbankanfragen wurden nach 21 Tagen unerklärlich abgebrochen, die nodes-Tabelle ist nicht mehr abrufbar!!
 +
 +====== Bewertung der Nutzbarkeit von OSM ======
 +
 +Untersuchung der Nutzbarkeit für verschiedene Anwendungen/Anwender oder Trennung aufgrund verschiedener Objektklassen (z. B. separaierter Untersuchung von Staatsgrenzen)
 +
 +
 +====== Festgestellte Probleme/Fragestellungen: ======
 +
 +  * 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
 +
  
  
Line 317: Line 329:
 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. 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.
  
-OpenStreetMap: Die freie Weltkarte nutzen und mitgestalten, F. Ramm, J. Topf, 2010+F. Ramm, J. Topf, 2010, OpenStreetMap: Die freie Weltkarte nutzen und mitgestalten
  
  
osm/start.1389273649.txt.gz · Last modified: 2014/01/09 13:20 by cbraune

Page Tools

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki