Software • 15. September 2021

Der Weg zum optimalen GeoTIFF

GeoTIFF als Datenformat für Rasterdaten ist weitverbreitet. Als einer der ältesten Standards im Bereich der Geodaten wird dieses Format von praktisch jeder verwendeten GIS-Software unterstützt.

Doch GeoTIFF ist nicht gleich GeoTIFF. Es gibt eine Vielzahl von Features und Konfigurationen, die es ermöglichen das Format maßgeschneidert für jeden Anwendungsfall anzupassen. Die hier vorgestellten Aspekte sollen dabei helfen und sind mit der freien Software GDAL – und damit auch in darauf aufbauenden Anwendungen wie QGIS – anwendbar.

Was zeichnet das TIFF-Format aus?

TIFF ist, ganz salopp gesagt, ein tolles, vielseitiges Dateiformat für Rasterdaten. Es wird seit Jahrzehnten für unterschiedlichste Anwendungsfälle eingesetzt – vom Fax bis zu medizinischen Scans oder in der Astronomie.

Ein solcher Rasterdatensatz ist üblicherweise ein rechteckiges, aus Pixeln aufgebautes Bild. Ein Pixel ist im Grunde nichts anderes als ein in einem Raster verorteter Wert (z. B. (255, 255, 0)), welcher eine Farbe (z. B. Gelb), also ein visuelles Merkmal, repräsentieren soll. Betrachtet man die Werte in einem Rasterbild als reine Datenwerte, dann ist es naheliegend, dass beliebige Merkmale, etwa Geländehöhen oder andere Messwerte, strukturiert gespeichert werden können.

Einige Besonderheiten des TIFF-Formats machen es besonders attraktiv für die Verwendung im GIS-Bereich. Grundlegend für die Eignung sind der hohe mögliche Wertebereich je Rasterzelle sowie die Tags:

  • In TIFF können Bilder mit einer sehr hohen Farbtiefe bzw. mit einem sehr großen, hoch aufgelösten Wertebereich je Pixel bzw. je Rasterzelle gespeichert werden. Die originären Messwerte müssen also nicht auf eine kleinere, limitierte Skala umgerechnet werden.
  • Ein TIFF kann mit Metadaten versehen werden, den sogenannten Tags. Über die Angabe einer Georeferenzierung wird ein einfaches TIFF hiermit zu einem GeoTIFF. Der GeoTIFF-Standard ist im Grunde nichts anderes als eine standardisierte Menge vorgegebener Tags.

Zusätzlich können die Daten in einem GeoTIFF speziell vor- bzw. aufbereitet werden, um die bestmögliche Effizienz für einen Anwendungsfall zu gewährleisten. Im Folgenden schauen wir uns die wichtigsten Aspekte einmal an.

Kompression macht aus "Big Data" Kleinholz

TIFF ist standardmäßig unkomprimiert, Geodaten sind aber oft sehr umfangreich... Eine reduzierte Dateigröße vereinfacht sowohl den Zugriff (z. B. beim Download) als auch die Speicherung der Daten. Nur in den seltensten Fällen ist der Verzicht auf Komprimierung sinnvoll. Für die Entscheidung wie komprimiert werden soll, kann folgendes Flowchart helfen:

Wann kann eine verlustbehaftete Komprimierung gewählt werden?

Werden die Daten eher "nur" angesehen oder auf Basis ihrer visuellen Merkmale bewertet, etwa Luft- oder Satellitenbilder, dann ist eine verlustbehaftete Komprimierung angemessen. Diese wirft zwar Informationen weg, das Ergebnis sieht aber – sinnvoll gewählte Qualitäts- und Kompressionseinstellungen vorausgesetzt, siehe Paul Ramseys Artikel zur Best Practise – noch genauso aus wie vorher und wird entsprechend von Mensch und Maschine auch weiter so interpretiert. Besonders zu bewerten ist hier natürlich eine Nutzung zur (Langzeit)-Archivierung. Dazu ist meist eine verlustfreie Komprimierung angemessener.

Algorithmen für die verlustfreie Kompression von GeoTIFF

Daten, bei denen die exakten Werte von Bedeutung sind, sollten dagegen verlustfrei komprimiert werden. Für die verlustfreie Kompression gibt es eine Vielzahl von Optionen. Zu den Vor- und Nachteilen der einzelnen Algorithmen gibt es viele, sich teilweise leicht widersprechende Übersichten (1, 2, 3, 4, 5, 6). Ihre jeweilige Sinnhaftigkeit, Performanz und Effizienz hängt stark von den verwendeten Daten und Anwendungsszenarien ab. Daher sind im Rahmen größerer Projekte eigene Tests und Benchmarks unvermeidbar. Dennoch ist es möglich, einige einfache Faustregeln zu formulieren, denn (fast) jede Kompression ist besser als keine.

  • Der LZW-Algorithmus ist heutzutage nur noch sinnvoll, wenn es einen besonderen Grund gibt, genau dieses Format zu nutzen, etwa durch externe Vorgaben. Er ist verhältnismäßig schnell beim Schreiben und langsam beim Lesen, die Kompressionsraten sind nichts besonderes.
  • Der LZMA-Algorithmus ist in seiner Effizienz und Langsamkeit vielen vom 7z-Format bekannt. Sowohl beim Schreiben als auch beim Lesen ist er sehr langsam, bietet aber höhere Kompressionsraten als andere Algorithmen. Damit ist dieser Algorithmus am ehesten für die Langzeitarchivierung geeignet.
  • DEFLATE bietet gute Kompression mit vertretbarer Langsamkeit beim Schreiben und schneller Dekompression. DEFLATE wird zum Beispiel auch bei ZIP-Dateien oder PNG-Bildern eingesetzt. In fast jedem Fall eine gute Standardwahl.
  • Der noch relativ junge Zstandard-Algorithmus bietet ähnliche Kompressionsraten wie DEFLATE, ist aber meist sehr viel schneller. Sofern sämtliche relevanten Systeme die ZSTD-Kompression unterstützen, ist sie aktuell wohl die beste Wahl.
  • PACKBITS ist sehr schnell, aber nur für wenige Anwendungsfälle relevant. Nur wenn die Datenwerte extrem homogen sind, ist dieser Algorithmus einen Gedanken wert.
  • Die Möglichkeit mit LERC zu komprimieren, ist bisher noch wenig Software vorbehalten. Daher sei hier nur kurz gesagt, dass dieser Algorithmus sehr interessant und unter Umständen extrem effizient ist. Probieren Sie ihn mal aus (ein GDAL mit entsprechender Unterstützung vorausgesetzt) und berichten Sie uns gerne von Ihren Erfahrungen!

Fazit: Mit DEFLATE und ZSTD existieren zwei sehr effiziente, verlustfreie Komprimierungsalgorithmen, welche die Dateigröße eines TIFFs enorm verringern können. Nutzen Sie sie! 

Prädiktoren erhöhen die Effizienz der Komprimierung

Um die Effizienz der Kompression weiter zu erhöhen, bietet TIFF bei bestimmten Algorithmen die Möglichkeit, sogenannte Prädiktoren einzusetzen. Damit werden dem Kompressor nicht mehr die eigentlichen Pixelwerte übergeben, sondern jeweils die Wertunterschiede zu den vorherigen Pixeln. Wenn die Daten also eine räumliche Autokorrelation haben – und das ist gemäß Tobler's erstem Gesetz der Geographie bei Geodaten meistens der Fall – sind diese Wertunterschiede meist sehr klein, insgesamt ähnlich zueinander und damit besser zu komprimieren als die ursprünglichen Rohdaten. Die Verwendung eines Prädiktors ist also fast immer sinnvoll.

Kachelung für schnellen Zugriff auf Teilausschnitte

Geodaten werden häufig nur in Teilausschnitten betrachtet, z. B. in interaktiven Kartenansichten oder für zonale Analysen. In diesen Fällen ist es eigentlich nicht nötig, dass sämtliche Daten einer möglicherweise gigantischen Datei eingelesen werden, es reichen die des relevanten Ausschnitts.

TIFF bietet praktischerweise die Möglichkeit, Daten in den datei-internen Datenstrukturen in sogenannten Kacheln zu verwalten. Statt alle Rasterzellen ganz schlicht Spalte für Spalte, Zeile für Zeile zu speichern ("striped"), werden einzelne rechteckige Teilbereiche jeweils für sich in einem zusammenhängenden Datenblock gesteckt ("tiled"). Wo welche Teile zu finden sind, wird in Metainformationen hinterlegt. So ist es möglich, nur noch die tatsächlich relevanten Teilausschnitte eines Rasters einzulesen. Eine Kachelung der Daten ist für praktisch alle relevanten Anwendungsfälle optimal und daher immer anzuraten.

Pyramiden für schnellen Zugriff auf verkleinerte Ansichten

Große Rasterdateien stellen ein Problem dar, wenn sie in einer Anwendung geladen werden, welche sie in verkleinerten Zoomstufen darstellen soll. Selbst wenn der Datensatz nur in Briefmarkengröße dargestellt wird, müssen die meisten Anwendungen sämtliche Daten der Datei einlesen, um diese skalierte Ansicht zu berechnen. Und das gegebenenfalls bei jeder Interaktion der Nutzer*innen.

Um diesen Anwendungsfall effizienter zu gestalten, kann eine herausgezoomte Sicht vorberechnet und zusammen mit in der Datei abgespeichert werden. Wird dies für mehrere Skalierungsfaktoren wiederholt, z. B. für die Auflösungen 1/2, 1/4, 1/8 und so weiter, dann entstehen die sogenannten Pyramiden bzw. Overviews. Dieser Prozess dauert bei der Erstellung der Datei einmal etwas länger und kostet rund ein Drittel zusätzliche Dateigröße, aber anschließend kommen alle in den Genuss einer schnellen Zoom-Interaktion.

Cloud Optimized GeoTIFF ist die optimale Basis

Werden die genannten Empfehlungen befolgt, entsteht ein sowohl für Analysen und Speicherung als auch für das bloße Ansehen optimal aufbereiteter Datensatz. So verwundert es nicht, dass eine Community-Initiative einen GeoTIFF-Standard entwickelt hat, der mehrere dieser Aspekte festschreibt: Cloud Optimized GeoTIFF

Dieses neue und rapide aufstrebende Format ist nichts anderes als ein GeoTIFF mit Pyramiden, einer gekachelten Datenstruktur und der Regel, dass die Metadaten, welche die Struktur der Daten beschreiben, direkt am Anfang der Datei abgespeichert sein müssen. Damit kann eine Anwendung schnell, einfach und mit minimalen Datenverkehr zuerst die Bits und Bytes mit den Metadaten abfragen. Anschließend können für jeden in der Anwendung gerade angeforderten Ausschnitt und/oder Skalierungsfaktor nur die benötigten Teile der Datei vom Speicherort geladen werden. Das geht im Falle einer im Netz gehosteten Datei dank HTTP mit praktisch jedem Webserver out-of-the-box. So kann selbst eine Webanwendung theoretisch Exabyte große GeoTIFFs einbinden und bekommt – praktisch wie bei einer Geodatenbank – immer nur die gerade benötigten Daten.

Weiterführende Informationen

Weiterführenden Informationen sind in der Dokumentation zum GeoTIFF-Format des GDAL-Projekts oder auf https://www.cogeo.org/ zu finden.

 

Weitere Beiträge, die Dich interessieren könnten:

Hannes Kroeger

Johannes Kröger

Nach einem Abschluss als Master of Science Geomatik an der HafenCity Universität Hamburg arbeitete Johannes Kröger mehrere Jahre als Wissenschaftlicher Mitarbeiter im dortigen Lab for Geoinformatics and Geovisualization (g2lab) in der Lehre und Forschung. Seit März 2020 ist er als GIS-Entwickler und -berater bei der WhereGroup tätig. Johannes Kröger ist auch privat im Umfeld von Kartografie, Open-Data und FOSSGIS aktiv.

Artikel teilen: