Metainformationen zur Seite

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung		Vorhergehende Überarbeitung
qgis:advanced:c_fortgeschrittene_rasterverarbeitung:lektion-5 [2022/01/20 11:56] – ↷ Seite von qgis:advanced:lernpfad-c:lektion-5 nach qgis:advanced:c_fortgeschrittene_rasterverarbeitung:lektion-5 verschoben mapqgis:advanced:c_fortgeschrittene_rasterverarbeitung:lektion-5 [2022/09/10 00:07] (aktuell) – Externe Bearbeitung 127.0.0.1
Zeile 1: Zeile 1:
-=====Umgang mit großen bzw. vielen Raster-Daten =====+======Umgang mit großen bzw. vielen Raster-Daten ======
  
 Häufig ist es erforderlich, große und/oder viele Rasterdaten in QGIS zu laden oder zu verarbeiten. Zum Beispiel, wenn wir Reliefanalysen an einem Höhenmodell durchführen möchten, von Orthofotos abdigitalisieren wollen oder schlicht eine lokale Basishintergrundkarte benötigen. Die räumliche Auflösung der verfügbaren Daten wird immer besser und die Datenmengen entsprechend größer (denken wir z.B. an die LiDAR Höhenmodelle, welche uns seit wenigen jahren zur Verfügung stehen oder die vielerorts erhältlichen Orthofotos mit 1x1m Auflösung!), Wir müssen dann mit den begrenzten Ressourcen unseren PCs vernünftig haushalten. Hier einige Methoden und Tipps. Häufig ist es erforderlich, große und/oder viele Rasterdaten in QGIS zu laden oder zu verarbeiten. Zum Beispiel, wenn wir Reliefanalysen an einem Höhenmodell durchführen möchten, von Orthofotos abdigitalisieren wollen oder schlicht eine lokale Basishintergrundkarte benötigen. Die räumliche Auflösung der verfügbaren Daten wird immer besser und die Datenmengen entsprechend größer (denken wir z.B. an die LiDAR Höhenmodelle, welche uns seit wenigen jahren zur Verfügung stehen oder die vielerorts erhältlichen Orthofotos mit 1x1m Auflösung!), Wir müssen dann mit den begrenzten Ressourcen unseren PCs vernünftig haushalten. Hier einige Methoden und Tipps.
  
-==== Wiederholung: Rasterdaten ====+===== Wiederholung: Rasterdaten =====
  
 Rasterdaten sind aufgrund ihres Speichereigenschaften häufig groß und rechenintensiv. Die Verarbeitung von großen oder vielen Rasterdaten kann daher sehr langwierig sein oder an mangelnden Hardware-Ressourcen scheitern. Es gibt aber **Funktionen und Methoden**, die einem Helfen, auch mit **wenig Ressourcen und Zeit, große Datenmengen zu verarbeiten** oder diese zumindest **//häppchenweise// zu servieren**. Rasterdaten sind aufgrund ihres Speichereigenschaften häufig groß und rechenintensiv. Die Verarbeitung von großen oder vielen Rasterdaten kann daher sehr langwierig sein oder an mangelnden Hardware-Ressourcen scheitern. Es gibt aber **Funktionen und Methoden**, die einem Helfen, auch mit **wenig Ressourcen und Zeit, große Datenmengen zu verarbeiten** oder diese zumindest **//häppchenweise// zu servieren**.
  
-==== Das richtige Format  ====+===== Das richtige Format  =====
  
 Es gibt viele verschiedene Raster-Speicherformate(([[https://gdal.org/drivers/raster/index.html|GDAL Raster Format List]])). Die einen resultieren in kleinen Dateien, die anderen in großen. Doch worin unterscheiden sie sich? Es gibt viele verschiedene Raster-Speicherformate(([[https://gdal.org/drivers/raster/index.html|GDAL Raster Format List]])). Die einen resultieren in kleinen Dateien, die anderen in großen. Doch worin unterscheiden sie sich?
Zeile 13: Zeile 13:
 Ein Rasterbild ist eine Matrix in welchem **jede Zelle einen Wert** (Farbwert, Höhe, Lärmpegel, CO²-Gehalt) besitzt und **eindeutig zur Nachbarzelle abgegrenzt** (diskret) ist. Speichert man eine Matrix genau so, also //Roh bzw. RAW// ([[wpde>GeoTIFF]], ASC, XYZ etc.), so wird es in einer relativ großen Datei resultieren - eben unkomprimiert. Wählt man hingegen ein komprimierendes Speicherformat  wie [[wpde>JPEG_2000|JP2000]], [[wpde>Portable_Network_Graphics|PNG]] etc., welches nicht jede einzelne Zelle diskret abspeichert, sondern nur "einige" während die dazwischen liegenden Zelle //interpoliert// werden, so resultiert das in einer kleinen und vergleichsmäßig schnellen Datei. **ABER** die kleine Datei ist zwar //optisch// einwandfrei, doch tatsächlich sind die einzelnen Zellen nicht mehr diskret von einander getrennt, **sondern miteinander //vermischt//**. Das ist Okay bei Orthofotos, digitalen topographischen Karten oder ggf. bei Satellitenbildern, da diese uns oft nur zur Orientierung dienen, für **wissenschaftliche Aufgaben und Analysen sind sie** jedoch **unbedingt zu meiden**! Bei Relief-Analysen verwenden wir Digitale Gelände Modelle (DGM, DEM) welche unbedingt in einem rohen Format gespeichert sein müssen, sonst werden unsere Analysen und Ableitungen (z.B. Höhenlinien, Exposition, Lokale Maxima und Minima etc.) falsche Ergebnisse liefern! Ein Rasterbild ist eine Matrix in welchem **jede Zelle einen Wert** (Farbwert, Höhe, Lärmpegel, CO²-Gehalt) besitzt und **eindeutig zur Nachbarzelle abgegrenzt** (diskret) ist. Speichert man eine Matrix genau so, also //Roh bzw. RAW// ([[wpde>GeoTIFF]], ASC, XYZ etc.), so wird es in einer relativ großen Datei resultieren - eben unkomprimiert. Wählt man hingegen ein komprimierendes Speicherformat  wie [[wpde>JPEG_2000|JP2000]], [[wpde>Portable_Network_Graphics|PNG]] etc., welches nicht jede einzelne Zelle diskret abspeichert, sondern nur "einige" während die dazwischen liegenden Zelle //interpoliert// werden, so resultiert das in einer kleinen und vergleichsmäßig schnellen Datei. **ABER** die kleine Datei ist zwar //optisch// einwandfrei, doch tatsächlich sind die einzelnen Zellen nicht mehr diskret von einander getrennt, **sondern miteinander //vermischt//**. Das ist Okay bei Orthofotos, digitalen topographischen Karten oder ggf. bei Satellitenbildern, da diese uns oft nur zur Orientierung dienen, für **wissenschaftliche Aufgaben und Analysen sind sie** jedoch **unbedingt zu meiden**! Bei Relief-Analysen verwenden wir Digitale Gelände Modelle (DGM, DEM) welche unbedingt in einem rohen Format gespeichert sein müssen, sonst werden unsere Analysen und Ableitungen (z.B. Höhenlinien, Exposition, Lokale Maxima und Minima etc.) falsche Ergebnisse liefern!
  
-==== Ein einzelnes großes Raster-Bild schnell darstellen (rendern) ====+===== Ein einzelnes großes Raster-Bild schnell darstellen (rendern) =====
 [{{ :qgis:advanced:images:qgis_layereigenschaften_pyramiden_38.png?450&direct|**Abb. X:** Pyramiden in den Eigenschaften des Rasterlayers erzeugen}}] [{{ :qgis:advanced:images:qgis_layereigenschaften_pyramiden_38.png?450&direct|**Abb. X:** Pyramiden in den Eigenschaften des Rasterlayers erzeugen}}]
  
Zeile 23: Zeile 23:
  
  
-==== Große Gebiete mit hoch aufgelösten Bildern wiedergeben ====+===== Große Gebiete mit hoch aufgelösten Bildern wiedergeben =====
  
 Hochaufgelöste Orthofots für ganze Bundesländer sind auch in einem kleinen Speicherformat wir JP2 immer noch riesig und rechenintensiv. Nehmen wir folgendes Beispiel: Der Regierungsbezirks Aachen wird mit 136 hochaufgelösten Orthofots abgedeckt, was in insgesamt 10GB Speicherbedarf resultiert [[https://www.opengeodata.nrw.de/produkte/geobasis/dop/dop/dop_05334002_Aachen_EPSG25832_JPEG2000.zip|Download Aachen DOP (10GB!!!)]]. Fügen wir alle zusammen (mit ''merge'') so erhalten wir ein einzelnes 10GB-großes Bild, dessen Erzeugung mehr als 14GB RAM benötigt (weshalb meine Hardware nicht in der Lage war, es zu generieren). Alternativ können wir aber auch ein sogenanntes **virtuelles Raster** erzeugen, welches die einzelnen Szenen nicht physisch zusammenfügt, sondern einen Katalog mit Verlinkungen zu jedem einzelnen Bild erzeugt. Das Erzeugen eines solchen Virtuellen Raster dauert zwar auch einige Minuten, die dafür benötigte Rechenleistung ist aber überschaubar. Es resultiert eine winzige-Indexdatei von 0,5 MB. Hochaufgelöste Orthofots für ganze Bundesländer sind auch in einem kleinen Speicherformat wir JP2 immer noch riesig und rechenintensiv. Nehmen wir folgendes Beispiel: Der Regierungsbezirks Aachen wird mit 136 hochaufgelösten Orthofots abgedeckt, was in insgesamt 10GB Speicherbedarf resultiert [[https://www.opengeodata.nrw.de/produkte/geobasis/dop/dop/dop_05334002_Aachen_EPSG25832_JPEG2000.zip|Download Aachen DOP (10GB!!!)]]. Fügen wir alle zusammen (mit ''merge'') so erhalten wir ein einzelnes 10GB-großes Bild, dessen Erzeugung mehr als 14GB RAM benötigt (weshalb meine Hardware nicht in der Lage war, es zu generieren). Alternativ können wir aber auch ein sogenanntes **virtuelles Raster** erzeugen, welches die einzelnen Szenen nicht physisch zusammenfügt, sondern einen Katalog mit Verlinkungen zu jedem einzelnen Bild erzeugt. Das Erzeugen eines solchen Virtuellen Raster dauert zwar auch einige Minuten, die dafür benötigte Rechenleistung ist aber überschaubar. Es resultiert eine winzige-Indexdatei von 0,5 MB.
Zeile 29: Zeile 29:
 Laden wir nun das virtuelle Raster, so werden alle verlinkten Kacheln geladen. Auch dieser Vorgang dauert lange, denn es werden immerhin 40.800.000.000 Bildpunkte geladen. Um auch dies zu beschleunigen, könnten wir wieder Pyramiden für das Virtuelle Raster erzeugen, da dieses jedoch sich auf JP2000-Dateien bezieht, ist das leider nicht möglich. Wir müssen alle Dateien in z.B. TIF umwandeln und damit weiterarbeiten.... Laden wir nun das virtuelle Raster, so werden alle verlinkten Kacheln geladen. Auch dieser Vorgang dauert lange, denn es werden immerhin 40.800.000.000 Bildpunkte geladen. Um auch dies zu beschleunigen, könnten wir wieder Pyramiden für das Virtuelle Raster erzeugen, da dieses jedoch sich auf JP2000-Dateien bezieht, ist das leider nicht möglich. Wir müssen alle Dateien in z.B. TIF umwandeln und damit weiterarbeiten....
  
-==== Raster-Indexdatei erzeugen ====+===== Raster-Indexdatei erzeugen =====
 [{{ :qgis:advanced:images:qgis_kachelindex_menu_38.png?350&direct|**Abb. X:** Die Funktion "Kachelindex erzeugen" aus der GDAL bibliothek}}] [{{ :qgis:advanced:images:qgis_kachelindex_menu_38.png?350&direct|**Abb. X:** Die Funktion "Kachelindex erzeugen" aus der GDAL bibliothek}}]
 In der Regel ist es gar nicht nötig, alle Kacheln zu laden oder zu einem Bild zusammen zu fügen. Meistens genügt es uns, **die Bilder zu laden, welche für die Ausdehnung unseren Projekts von Relevanz sind**. Hierzu müsste man aber wissen, welches Bild (Dateiname) an welcher Stelle sich befindet (und das geht aus dem Dateinamen oft nicht hervor!). Hier hilf ein **Kachel-Index**! Diesen erzeugen wir mit dem Befehl ''Kachel-Index erzeugen'' oder über das Menü ''Raster -> Verschiedenes -> Kachel Index...''. Es wird eine Shapedatei erstellt, in welcher für jede Bildkachel ein Polygon (Rechteck) erzeugt wird. In den Attributen der einzelnen Kachel-Polygone finden wir dann den Pfad und Dateinamen zur ursprünglichen Raster-Kachel (siehe Abb. X). In der Regel ist es gar nicht nötig, alle Kacheln zu laden oder zu einem Bild zusammen zu fügen. Meistens genügt es uns, **die Bilder zu laden, welche für die Ausdehnung unseren Projekts von Relevanz sind**. Hierzu müsste man aber wissen, welches Bild (Dateiname) an welcher Stelle sich befindet (und das geht aus dem Dateinamen oft nicht hervor!). Hier hilf ein **Kachel-Index**! Diesen erzeugen wir mit dem Befehl ''Kachel-Index erzeugen'' oder über das Menü ''Raster -> Verschiedenes -> Kachel Index...''. Es wird eine Shapedatei erstellt, in welcher für jede Bildkachel ein Polygon (Rechteck) erzeugt wird. In den Attributen der einzelnen Kachel-Polygone finden wir dann den Pfad und Dateinamen zur ursprünglichen Raster-Kachel (siehe Abb. X).