Rasterfile
Ermöglicht den Zugriff auf georeferenzierte, dateibasierte Rasterdaten. Zurzeit ist der Zugriff auf Tiff und ECW Dateien(1) implementiert.
Argumente
Typname: rasterFiles
- fileName: Ein oder mehrere Pfadnamen zu den Raster-Dateien. Mehrere können durch ein Stern - * - getrennt angegeben werden, schließt sich mit folder aus
... oder ...
folder: Der Pfadname eines Ordner mit den Rasterdateien (absolut oder relativ), schließt sich mit fileName aus
filePattern (*.tif): Das Suchmuster für Dateien, die in folder gesucht werden sollen.
recursiv: Gibt an, ob der in folder angegebene Ordner rekursiv nach Dateien durchsucht werden soll oder nur direkt in diesem Verzeichnis
Für Beide:
epsgCode (-1): wenn definiert (d.h. > 0), dann wird dieser wie angegeben übernommen, ansonsten wird eine automatische Ermittlung anhand der Ausdehnung der ersten Datei versucht (andere Mitglieder des Layers können abweichende Epsg-Codes haben).
forceGridType (false): versucht die Ebene als Grid-Layer zu interpretieren, auch wenn es vom Typ her nicht automatisch als solches klassifiziert wurde. Siehe auch Beschreibung zu Gridfiles
Beachte: Geht nicht in Verbindung mit dem Argument folder (also nur bei Einzelbildern vom Typ Tiff)
style|cssFile: hier immer vom Typ Raster CSS.
forceLogicalRenderImageSize (false): siehe Beschreibung hier
Ladevorgang
Es wird geprüft, ob zu der (jeweiligen) Datei ein Handler vorhanden ist. Dieser wird anhand der Dateierweiterung ermittelt. Derzeit ist für das TIFF Format ein Handler vorhanden, die Dateierweiterung .tif oder .tiff wird dabei vorausgesetzt.
Beispiel
Alle gru*.tif Dateien direkt im Ordner Tk25, Darstellungsqualität "Hoch".
{
"Tk25": {
"type": "RasterFiles",
"folder": "D:\\Temp\\Tk25",
"filePattern":"gru*.tif",
"recursive":false,
"epsgCode": 31469,
"style": "special-raster-properties { render-quality: high ; }"
}
}
Implementierungsdetails
TIFF
Folgende Photometric-Typen werden unterstützt:
PHOTOMETRIC_RGB (8 oder 16 Bit/Kanal)
PHOTOMETRIC_PALETTE (1, 4 oder 8 Bit/Kanal)
PHOTOMETRIC_MINISBLACK
PHOTOMETRIC_MINISWHITE
PHOTOMETRIC_MINISBLACK oder PHOTOMETRIC_MINISWHITE in Kombination mit SamplesPerPixel = 1 und 32 oder 64 Bit pro Kanal wird dann als "Grid" interpretiert
Es werden auch transparente TIFF Dateien unterstützt die mindestens einen extra Kanal vom Typ 2 (Unassociated alpha) haben. Typ 1 (Associated alpha) wird nicht unterstützt.
Handelt es sich um ein GeoTIFF, wird die Georeferenzierung aus der Datei verwendet, ansonsten wird ein "Worldfile" nach folgendem Schema gesucht (in dieser Reihenfolge):
- .tfw
- .tifw
- .wld
Das Speicher-Layout Tiles und Stripes wird unterstützt.
Zum schnellen Zeichnen werden Strips bzw. Tiles gecached. Dafür wird je Anfrage maximal die Hälfte des freien Speichers verwendet bzw. maximal 4 GB je nachdem was kleiner ist.
Ebenso werden Translation und Rotation der Georeferenzierung unterstützt.
Es werden sowohl externe (*.ovr Dateien) als auch eingebettete Vorschaubilder unterstützt, was das Zeichnen großer Dateien stark beschleunigt, falls vorhanden.
Bei Vorschaubildern wird immer dasjenige ausgewählt, dass die kleinste Bildauflösung, die größer oder gleich der Bildschirmauflösung ist, hat.
Unklarheiten
Bei einigen Tiff (hier konkret beobachtet bei aus ArcGIS exportierten Dateien) kommen einige Formate zustande, deren Interpretation nicht klar ist. Da scheinbar ArcGIS die Gdal verwendet, werden diese Raster auch in bspw. QGis dargestellt.
Wenn ein NoData Wert > 8 Bit definiert ist, dann wird das Bild in 16 Bit / Pixel ausgegeben, allerdings ist der tatsächlich belegte Wertebereich nur im 8 Bit Raum (0..255). Das führt dazu, dass diese Bilder schwarz dargestellt werden (übrigens: auch in jedem anderen Anzeigeprogramm was wir bisher probiert haben.)
Dazu kommt noch, dass als Photometric-Typ MinIsBlack angegeben wird, statt RGB (was unserer Meinung nach hier das Richtige wäre).
Leider ist die Dokumentation zu diesem Thema sehr spärlich. Keines der in Tif / Aux etc. verfügbaren Attribute erlaubt hier eine eindeutige Zuweisung über dieses Verhalten.
Ab Version 7.2.1.5 gilt folgendes:
Wenn Photometrietyp MinIsBlack oder MinIsWhite ist Anzahl und SamplesPerPixel >=3 ist, dann behandle es als RGB Darstellung.
Wenn BitPerSample > 8 ist dann ...
- Auswerten der Band-Statistik in der Aux-Xml Datei (wenn vorhanden)
- wenn der Maximalwert aller Kanäle <= 255 ist, dann nimm statt der 16/32 Bit Farbtiefe nur 8Bit
- wenn der Maximalwert aller Kanäle <= 65535 ist, dann nimm statt der 32 Bit Farbtiefe nur 16Bit
Bei Übersichten (Pyramiden) "erbe" die Einstellungen der logischen Pixel (siehe 2.) von der Statistik der Haupt-Tiff Datei.
Na, da drücken wir mal die Daumen, dass das passt. Falls ein Leser hierzu mehr Informationen liefern kann, freuen wir uns auf Hinweise dazu.
TIFF - Empfehlungen / Aufbereitungen
Die Verwendung von TIFF Dateien kann recht performant sein, wenn einige Dinge beachtet werden:
- Reduktion der Anzahl der Dateien (d.h. Einzelbilder wenn möglich als Mosaik zusammenfassen)
- Komprimierung der Daten (z.B. LZW für TK Bilder, JPEG für Luftbilder)
- Erstellung von "Übersichten" (Pyramiden)
Für die Aufbereitung können wir Ihnen die Werkzeuge aus der GDAL empfehlen.
Hier eine Mini-Anleitung für das Zusammenfassen von Tiffs als ein Mosaik und der Erstellung der Übersichten:
Die Anleitung hier handelt sich um "Bilddaten", wenn Sie andere Formate, bspw. Grid-Daten konvertieren, dann finden Sie unter Gridfiles weitere Hinweise dazu.
REM Alle Dateien im Ordner als einen virtuellen Layer (mosaic_alpha.vrt) definieren
gdalbuildvrt.exe -addalpha "M:\tiffs\out\mosaic_alpha.vrt" "M:\tiffs\in\*.tif"
REM Aus dem virtuellen Layer die physische Datei gesamt.tif erstellen
gdal_translate.exe -of GTiff --config GDAL_CACHE_MAX 128 -co PHOTOMETRIC=RGB -co COMPRESS=JPEG -co TILED=YES "M:\tiffs\out\mosaic_alpha.vrt" "M:\tiffs\out\gesamt.tif"
REM Dann für das Gesamtbild die Übersichten erstellen
REM (Achtung - potentiell langsam. Siehe Hinweis und weitere Ausführungen)
gdaladdo.exe --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW RGB --config INTERLEAVE_OVERVIEW PIXEL -r average "M:\tiffs\out\gesamt.tif" 2 4 8 16
Hinweis: Bei großen TIFF-Dateien kann die Erstellung der Pyramide mit den Übersichtsbildern
(gdaladdo.exe)
auf die oben skizzierte Weise enorm lange dauern (Wochen). Um Größenordnungen schneller ist dann die Erstellung einzelner Pyramiden-Level und anschließende Verschmelzung zu einer Ergebnisdatei (siehe unten für detaillierte Hinweise).
Beachten Sie bitte: Wenn unterschiedliche NoData Werte pro Kanal gesetzt werden, dann erfolgt keine transparente Darstellung. Das liegt daran, dass nur einer der gesetzten NoData Werte (also nur für ein Band) aus der Tiff Datei ausgelesen wird (bzw. dort nur einer enthalten ist). Verwenden Sie in diesem Fall die Stilanweisung "transparent-colors:..." des Raster-CSS.
QGis scheint übrigens die Pixel transparent darzustellen, wenn in irgendeinem Band der NoData Wert vorkommt. Wir gehen davon aus, dass dieser Wert in allen Bändern identisch sein muss.
Optimierung der Pyramidenerstellung
In der 'libtiff' gibt es eine bekannte Einschränkung, dass beim wechselseitigen Lesen und Schreiben aus/in der/die gleiche(n) Datei durch den fortwährenden Kontext-Wechsel ein enorm großer Overhead entsteht, der den Prozess dramatisch verlangsamt. Dieses Problem kann umgangen werden, indem jedes Übersichts-Level zunächst in eine eigene separate Datei erstellt wird und final die Übersichts-Level bzw. die Übersichtslevel und das Ausgangsbild wieder in eine Datei zusammengeführt werden.
Das Prinzipi ist dann wie folgend skizziert. Die Pyramiden-Level werden dabei immer wieder als Halbierung des vorhergehenden Levels als separate Datei erzeugt. gdaladdo
hängt jedem Ergebnisbild immer wieder die Endung .ovr
an, wodurch sich eine Kaskade dieser Dateiendungen ergibt.
gdaladdo.exe -ro --config COMPRESS_OVERVIEW JPEG ... ... -r average orthofoto.tif 2
gdaladdo.exe -ro --config COMPRESS_OVERVIEW JPEG ... ... -r average orthofoto.tif.ovr 2
gdaladdo.exe -ro --config COMPRESS_OVERVIEW JPEG ... ... -r average orthofoto.tif.ovr.ovr 2
gdaladdo.exe -ro --config COMPRESS_OVERVIEW JPEG ... ... -r average orthofoto.tif.ovr.ovr.ovr 2
gdal_translate orthofoto.tif orthofoto_mit_Pyramide.tif -co COPY_SRC_OVERVIEWS=YES -co COMPRESS=JPEG -co BIGTIFF=YES -co TILED=YES
Unter dem folgenden Link können Sie Batchdateien herunterladen, die eine Pyramiden-Erstellung nach der optimierten Verfahrensweise durchführen: GDAL_Pyramiden_fuer_GeoTiff_erstellen_Batchdateien.zip
Vor der Ausführung einer der Batch-Dateien müssen Sie diese mit einem Texteditor öffnen und die Variablen mit den Pfaden zur GDAL-Installation sowie zur Tif-Datei und den Dateinamen anpassen.
Das Zip enthält 2 Batch-Datei, jeweils für eine Variante:
Separate Übersichtsdatei (empfohlen): Diese Batchdatei erzeugt eine Datei Dateiname.tif.ovr
, die dann parallel zu Dateiname.tif
mit abzulegen ist. Im Vergleich zur anderen Variante wird weniger Festplattenspeicher beim Erstellungsvorgang benötigt und die Dauer ist kürzer.
Benötigter freier Festplattenspeicher bei der Erstellung ist ungefähr die Größe des Ausgangsbildes (2x die Größe der Übersichten, wobei eine Übersichtspyramide mit ca. 30-50% der Größe des Ausgangsbildes angenommen wird).
Übersichten zusammen mit Ausgangsbild in einer Datei: Diese Batchdatei erzeugt eine GeoTIFF-Datei, in der das Ausgangsbild und die Pyramide mit den Übersichtsbildern vereint abgelegt sind.
Benötigter freier Festplattenspeicher bei der Erstellung ist ungefähr 2x die Größe des Ausgangsbildes (2x die Größe der Übersichten plus eine Kopie des Ausgangsbildes, wobei eine Übersichtspyramide mit ca. 30-50% der Größe des Ausgangsbildes angenommen wird).
Beispielhafte Zeiten auf einem Intel Xeon E5-1630 3.7 GHz
für ein 103 GB großes TIF (RGB, photometric, tiled, JPEG)
optimiert, separate OVR-Datei | optimiert, Einzeldatei | nicht optimiert |
---|---|---|
3.5 h Level 2 1.5 h Level 4 0.5 h Level 8 0.25 h restliche Levels 3.5 h zusammenfassen |
3.5 h Level 2 1.5 h Level 4 0.5 h Level 8 0.25 h restliche Levels 11 h zusammenfassen |
|
9.25 h | 16.75 h | mehrere Wochen |
(1) Die Verwendung des ECW Formats erfolgt nur in der UWP Desktop Anwendung. Für die Servernutzung muss eine Lizenz von der Firma Hexagon erworben werden.
Zuletzt geändert: 20.09.2024 07:22:06 (erstmals erstellt 02.04.2017)