Welches Format und welche Einstellungen müssen für Luftbilder in QGIS verwendet werden?

10

Folgende Frage zum Umgang mit Antennen mit ArcGIS:

Das effektivste Format zum Verwalten von Luftbildern nur zum Anzeigen

Es scheint, dass es zwei Hauptoptionen zum Speichern / Resampling / Reprojektieren usw. von Antennen gibt:

  1. JP2000 / JP2 / JPEG 2000 (kürzlich 5 Codes für die GDAL-Behandlung)
  2. ECW (ERDAS Compressed Wavelets (.ecw))
  3. andere, die ich verpasst habe?

gdal verfügbare Formate

Was ich je nach QGIS-Version für beide verstanden habe, müssen in der Regel einige zusätzliche Bibliotheken installiert werden. ECW hat einige Einschränkungen - für die Komprimierung muss eine Lizenz gekauft werden?

Ich habe JPEG getestet, das ich nicht für große Dateien verwenden kann (maximale Dimensionsbeschränkung), und es ist auch bei größeren Dimensionen langsam.

Die Antwort sollte enthalten:

  1. Was ist standardmäßig mit QGIS 2.0.1 Desktop und / oder OSGEO verfügbar?
  2. Wie funktioniert es mit großen Dateien - Vergrößern / Verkleinern (Pyramiden)?
    • ist Erstellungsoptionen - AUFLÖSUNGEN für JP2-Pyramiden?
Miro
quelle
1
Nur der andere Ansatz: Große Serien von Orthofotos werden häufig als OGC-Dienst WMS / WMTS mit einem Backend-Anbieter wie GeoServer oder MapServer bereitgestellt.
Jakob
2
GeoTIFF und NITF sind für Satellitenbilder üblich. Wird auch in GDAL unterstützt, ist sich jedoch nicht sicher, ob QGIS NITF unterstützt.
BradHards
@ Jakob - Ich verstehe den Punkt. Trotzdem müssen Bilder irgendwie auf dem Server gespeichert werden (in einem bestimmten Format), oder?
Miro
@BradHards - Tiff war eigentlich meine erste Wahl, aber die einzige Möglichkeit, es effektiv komprimiert zu speichern, ist die JPEG-Komprimierung, die mich auf die gleiche maximale Dimensionsbeschränkung bringt, als ob es direkt in JPEG gespeichert würde. Die Sache ist, dass für Satellitenbilder meistens eine verlustfreie Komprimierung benötigt wird. Diese Frage konzentriert sich jedoch mehr auf Luftbilder, die einige Verluste aushalten können, um eine enorme Datenspeicherung / -übertragung zu sparen.
Miro

Antworten:

8

Basierend auf huckfinn Antworten, wenigen anderen Kommentaren und zusammen mit meinen Erkenntnissen:

Das Gewinnerformat ist JPEG2000 (warum und welche Version wird unten erwähnt? Warum nicht andere ? )

Warum nicht andere:

  1. JPEG
    • Größenbeschränkung sowohl der Datengröße als auch der Abmessungen (4 GB und 65500 x 65500)
    • Keine (interne) Pyramidenmöglichkeit = Je größer das Bild, desto länger dauert die Anzeige beim Schwenken / Vergrößern / Verkleinern
  2. GeoTIFF
    • Gut für Raster, aber für Rasterbilder gibt es keine effektive verlustbehaftete Komprimierung außer JPEG = das gleiche Problem wie JPEG
  3. ECW und Mr. SID
    • Sie benötigen eine spezielle Lizenz, um in ECW und Mr. SID speichern zu können - dies ist mit GDAL (QGIS) standardmäßig nicht möglich. Wenn Sie über eine spezielle Lizenz verfügen, müssen Sie diese Antwort wahrscheinlich nicht lesen, da die Verarbeitung von Bildern Ihr tägliches Brot ist (unser Unternehmen erhält normalerweise Bilder im ECW-Format von unseren Kunden).
  4. Datenbank- / Kartenserver
    • Es ist definitiv eine gute Option, wenn Sie bereits einen Datenbank- / Kartenserver ausgeführt haben oder zumindest wissen, wie dies einfach und schnell zu tun ist. In diesem Fall können Daten in GeoTIFF oder was auch immer gespeichert werden und werden normalerweise als JPEG an Ihren Client gesendet - Webbrowser oder Desktop-Software wie QGIS. Wenn Sie jedoch keinen Server haben und möchten, dass Bilder in QGIS einfach geladen / angezeigt werden können, ist dies zu kompliziert.

WARUM JPEG2000:

Wie ich in meiner Frage gepostet habe, bietet GDAL mehr Optionen zum Speichern im JPEG2000-Format, aber wie auf der GDAL-Website aufgeführt, sollte keines davon in der Standardversion von GDAL bereitgestellt werden. Ich habe beim Testen wahrscheinlich 6 verschiedene Versionen von QGIS ausprobiert und alle hatten mindestens eine JPEG2000-Option (unter Windows 7). Um sicherzustellen, dass ich vorschlage, die OSGeo4W-Version (32 oder 64 Bit) von QGIS zu installieren und in der OSGeo4W-Shell zu überprüfen, ob JPEG2000-Code verfügbar ist. (Führen Sie unter Windows einfach die OSGeo4W-Shell über das Startmenü / die Startprogramme aus und schreiben Sie dort den Befehl gdal_translate --formatsoder gdalwarp --formats).

In allen Versionen von QGIS, die ich ausprobiert habe, war JP2OpenJPEG- Code (OpenJPEG-Bibliothek (v2)) verfügbar. Und nach einigen längeren Tests, einschließlich anderer, fand ich das am praktischsten.

Vorteile von JP2OpenJPEG

  • kostenlos zum öffnen / speichern verwenden
  • keine "kleine" Größenbeschränkung (kann definitiv weit über 65500x65500 gehen)
  • sehr effektive Komprimierung (möglich,% einzustellen)
  • Enthält Pyramiden (Vorschaubilder) zur schnellen Anzeige (auch einstellbar)

(Optionen zum Festlegen der Komprimierung ( -co QUALITY ), Pyramiden ( -co RESOLUTIONS ) und einige mehr - http://www.gdal.org/frmt_jp2openjpeg.html )

Einfaches Beispiel für die Konvertierung in QGIS mit gdal_translate (gehen Sie in QGIS zu Raster / Konvertierung / Übersetzen , stellen Sie alles ein, was Sie benötigen, und klicken Sie möglicherweise auf die Schaltfläche Bearbeiten, um den Befehl an Ihre Bedürfnisse anzupassen):

gdal_translate -of JP2OpenJPEG -co QUALITY=10 srcGridOrImage image.jp2  
Miro
quelle
6

Zu Thema 2: Hier ist eine längere Untersuchung von JP2, da ich auch daran interessiert war, eine effizientere Komprimierung zu verwenden. Und das Ergebnis IMO ist: In GDAL / QGIS (als QgsRastrerDataProvider) können Sie die richtige jpeg2000-Komprimierung und schnelle Caching-Optionen wie Kachelsätze und Blockstrukturen nicht auf einfache Weise kombinieren.

Normalerweise bevorzuge ich GeoTiff für Raster-DBs, es wird seit langer Zeit von GDAL gut unterstützt und verfügt über viele Funktionen, die das Leben erleichtern.

Die Funktionen des Datentreibers JP2 finden Sie auf der GDAL-Seite. Für Ihre Anforderungen jp2k ist das JPEG2000 (libjasper-Abhängigkeiten) auf dieser Seite aufgeführt: http://www.gdal.org/frmt_jpeg2000.html . Wie auf http://www.gdal.org/formats_list.html aufgeführt, unterstützt der "Treiber" Lesen, Schreiben, ist auf 2 GB beschränkt und seit GDAL Version 1.9 integriert und verfügt über einige Blockoptionen ...

Um sicherzugehen, was mit JP2 möglich ist, habe ich ein Test-Set erstellt.

Ich benutze große Luftbilder, um Seevögel in der Ostsee mit einer Größe von ca. 12000 x 10000 Pixel (RGB) und eine Bodenauflösung von 2 cm (ich hoffe, es ist groß genug). Ich habe momentan 270 Dateien mit einer Kapazität von ungefähr 130 GiB in meinem QGIS-Projekt. Und es funktioniert fließend und gut auf einem 64-Bit-Linux-Betriebssystem von Debian 7.0 mit 8 GB und 4xAMD Opteron-Kernen. ... aber mit GeoTiff.

Um einen schnellen Zugriff im GIS-Tool zu erhalten, werden die Bilder mit den folgenden Schritten und Optionen referenziert und mit GDAL neu abgetastet (..sorry für den Bash-Skriptstil):

Referenzieren des Bildes mit Datensätzen aus dem GPS-Protokoll:

    gdal_translate \
    -of GTiff \
    -gcp   0     0 $ulx   $uly \
    -gcp   0   $hg $llx   $lly \
    -gcp $cwd $chg $cpx   $cpy \
    -gcp $wd     0 $urx   $ury \
    -gcp $wd   $hg $lrx   $lry \
    -a_srs epsg:32632 \ 
    $raw_tif $ref_tif

Die Variablen $ [u | o] [l | r] [x | y] sind die Ecken des Bildes, die durch den photogrammetischen Kalkül gegeben sind, und die Variable $ wd ist die Bildbreite, $ hg die Bildhöhe und $ cwd $ chg die Mittelpunkt.

Verzerren Sie das Bild mit Kachelsatzoptionen in die reale Welt:

    gdalwarp \
    --config GDAL_CACHEMAX 2000 -wm 2000 -wo NUM_THREADS=4 \
    -r bilinear -dstnodata '0 0 0' \
    -of GTiff \
    -t_srs epsg:32632 \
    -tr 0.02 0.02 \
    -co COMPRESS=LZW \
    -co TILED=YES \
    -co BLOCKXSIZE=512 \
    -co BLOCKYSIZE=512 \
    $ref_tif $geo_tif

Die Parameter: --config GDAL_CACHEMAX 2000 -wm 2000 -wo NUM_THREADS = 4 weisen das Eisen an, viel Cache und vier Prozessorthreads zu verwenden, um das Material zu berechnen. Das Resampling erfolgt bilinear und das Koordinatensystem ist UTM-32. Aber ich möchte 512x512 Blockkacheln, um Navigationsvorgänge (Zoom, Schwenken, Zeigen) schnell und flüssig zu machen. Dies erfolgt über die Optionen -co TILED = YES -co BLOCKXSIZE = 512 -co BLOCKYSIZE = 512.

Schreiben Sie Pyramiden mit den Zoomstufen 2,4,8 und 16 in den GeoTiff:

    gdaladdo -r gauss $geo_tif 2 4 8 16

Das resultierende GeoTiff von gdalinfo ist:

 Driver: GTiff/GeoTIFF
 Files: CF006135.TIF
 Size is 12419, 9900
 Coordinate System is:
 PROJCS["WGS 84 / UTM zone 32N",
    GEOGCS["WGS 84",
        DATUM["WGS_1984",
             SPHEROID["WGS 84",6378137,298.257223563,
                 AUTHORITY["EPSG","7030"]],
             AUTHORITY["EPSG","6326"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4326"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",9],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AUTHORITY["EPSG","32632"]]
Origin = (656099.007276594405994,5998980.139660121873021)
Pixel Size = (0.020000000000000,-0.020000000000000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
  Upper Left  (  656099.007, 5998980.140) ( 11d23'17.54"E, 54d 6'54.87"N)
  Lower Left  (  656099.007, 5998782.140) ( 11d23'17.17"E, 54d 6'48.47"N)
  Upper Right (  656347.387, 5998980.140) ( 11d23'31.21"E, 54d 6'54.60"N)
  Lower Right (  656347.387, 5998782.140) ( 11d23'30.84"E, 54d 6'48.20"N)
  Center      (  656223.197, 5998881.140) ( 11d23'24.19"E, 54d 6'51.54"N)
Band 1 Block=512x512 Type=Byte, ColorInterp=Red
 NoData Value=0
 Overviews: 6210x4950, 3105x2475, 1553x1238, 777x619
Band 2 Block=512x512 Type=Byte, ColorInterp=Green
 NoData Value=0
 Overviews: 6210x4950, 3105x2475, 1553x1238, 777x619
Band 3 Block=512x512 Type=Byte, ColorInterp=Blue
 NoData Value=0
 Overviews: 6210x4950, 3105x2475, 1553x1238, 777x619

In GeoTiff ist also alles in Ordnung! Wenn ich versuche, eine JP2 mit einem direkten Konversationsschritt zu erstellen:

 gdalwarp -of jpeg2000 -co TILED=YES -co BLOCKSIZEX=512 -co BLOCKSIZEY=512 CF006135.TIF CF006135.jp2 
 Output driver `jpeg2000' not recognised or does not support
 direct output file creation.  The following format drivers are configured
 and support direct output:
   VRT: Virtual Raster
   GTiff: GeoTIFF
   NITF: National Imagery Transmission Format
   HFA: Erdas Imagine Images (.img)
   ELAS: ELAS
   MEM: In Memory Raster
   BMP: MS Windows Device Independent Bitmap
   PCIDSK: PCIDSK Database File
   ILWIS: ILWIS Raster Map
   SGI: SGI Image File Format 1.0
   Leveller: Leveller heightfield
   Terragen: Terragen heightfield
   netCDF: Network Common Data Format
   HDF4Image: HDF4 Dataset
   ISIS2: USGS Astrogeology ISIS cube (Version 2)
   ERS: ERMapper .ers Labelled
   RMF: Raster Matrix Format
   RST: Idrisi Raster A.1
   INGR: Intergraph Raster
   GSBG: Golden Software Binary Grid (.grd)
   PNM: Portable Pixmap Format (netpbm)
   ENVI: ENVI .hdr Labelled
   EHdr: ESRI .hdr Labelled
   PAux: PCI .aux Labelled
   MFF: Vexcel MFF Raster
   MFF2: Vexcel MFF2 (HKV) Raster
   BT: VTP .bt (Binary Terrain) 1.3 Format
   LAN: Erdas .LAN/.GIS
   IDA: Image Data and Analysis
   GTX: NOAA Vertical Datum .GTX
   NTv2: NTv2 Datum Grid Shift
   ADRG: ARC Digitized Raster Graphics
   SAGA: SAGA GIS Binary Grid (.sdat)

und es schlägt fehl. Möglicherweise gibt Ihnen die Fehlermeldung einen Hinweis oder ein anderes Format, das Sie verwenden können.

Der Versuch mit dem Tool gdal_translate gibt Ihnen eine richtige JP2000

 gdal_translate -of jpeg2000\
    -co TILED=YES -co BLOCKSIZEX=512 -co BLOCKSIZEY=512\
    CF006135.TIF CF006135.jp2

 ls -l 
 -rw-r--r-- 1 huckfinn huckfinn  63538529 Jan 28 23:55 CF006135.jp2
 -rw-r--r-- 1 huckfinn huckfinn       388 Jan 28 23:04 CF006135.jp2.aux.xml
 -rw-r--r-- 1 huckfinn huckfinn 519882980 Sep 30 21:01 CF006135.TIF

und die Komprimierungsrate ist 1: 8, aber wir verlieren die Block- und Kachelsatz-Eigenschaften, wie von gdalinfo gezeigt:

 gdalinfo CF006135.jp2 
 Driver: JPEG2000/JPEG-2000 part 1 (ISO/IEC 15444-1)
 Files: CF006135.jp2
        CF006135.jp2.aux.xml
 Size is 12419, 9900
 Coordinate System is:
 PROJCS["WGS 84 / UTM zone 32N",
     GEOGCS["WGS 84",
         DATUM["WGS_1984",
             SPHEROID["WGS 84",6378137,298.257223563,
                 AUTHORITY["EPSG","7030"]],
             AUTHORITY["EPSG","6326"]],
         PRIMEM["Greenwich",0],
         UNIT["degree",0.0174532925199433],
         AUTHORITY["EPSG","4326"]],
     PROJECTION["Transverse_Mercator"],
     PARAMETER["latitude_of_origin",0],
     PARAMETER["central_meridian",9],
     PARAMETER["scale_factor",0.9996],
     PARAMETER["false_easting",500000],
     PARAMETER["false_northing",0],
     UNIT["metre",1,
         AUTHORITY["EPSG","9001"]],
     AUTHORITY["EPSG","32632"]]
 Origin = (656099.007276594405994,5998980.139660121873021)
 Pixel Size = (0.020000000000000,-0.020000000000000)
 Metadata:
   AREA_OR_POINT=Area
 Corner Coordinates:
 Upper Left  (  656099.007, 5998980.140) ( 11d23'17.54"E, 54d 6'54.87"N)
 Lower Left  (  656099.007, 5998782.140) ( 11d23'17.17"E, 54d 6'48.47"N)
 Upper Right (  656347.387, 5998980.140) ( 11d23'31.21"E, 54d 6'54.60"N)
 Lower Right (  656347.387, 5998782.140) ( 11d23'30.84"E, 54d 6'48.20"N)
 Center      (  656223.197, 5998881.140) ( 11d23'24.19"E, 54d 6'51.54"N)

Der letzte Test bestand darin, GeoTiff mit einer internen JPEG-Komprimierung zu verwenden, aber wir erhalten:

 gdalwarp -of GTiff \
  -co COMPRESS=JPEG \
  -co TILED=YES -co BLOCKSIZEX=512 -co BLOCKSIZEY=512\
  CF006135.TIF CF006135_IJPG.TIF
  Creating output file that is 12419P x 9900L.
  Warning 6: Driver GTiff does not support BLOCKSIZEX creation option
  Warning 6: Driver GTiff does not support BLOCKSIZEY creation option
  Processing input file CF006135.TIF.
  ....

Also, wohin von hier aus gehen. Auf der JP2000 Jasper-Treiberbibliothekseite von GDAL sind einige Parameter zum Erstellen des JP2000-Images mit Blockoptionen aufgeführt:

 Encoding parameters, directly delivered to the JasPer library described in the JasPer documentation. Quoted from the docs:

``The following options are supported by the encoder:
imgareatlx=x    Set the x-coordinate of the top-left corner of the image area to x.
imgareatly=y    Set the y-coordinate of the top-left corner of the image area to y.
tilegrdtlx=x    Set the x-coordinate of the top-left corner of the tiling grid to x.
tilegrdtly=y    Set the y-coordinate of the top-left corner of the tiling grid to y.
tilewidth=w     Set the nominal tile width to w.
tileheight=h    Set the nominal tile height to h.
prcwidth=w  Set the precinct width to w. The argument w must be an integer  power of two. The default value is 32768.
prcheight=h     Set the precinct height to h. The argument h must be an integer power of two. The default value is 32768.
cblkwidth=w     Set the nominal code block width to w. The argument w must be an integer power of two. The default value is 64.
cblkheight=h    Set the nominal code block height to h. The argument h must be an integer power of two. The default value is 64.

aber die frage ist, welche man verwenden wird.

Huckfinn
quelle
1
Vielen Dank, wirklich zu schätzen. Inzwischen habe ich auch meine eigenen Tests gemacht. Wie ich sehe, ist JPEG2000 das richtige Format. Wie bereits erwähnt, darf TIFF nicht verwendet werden, da ich nur die JPEG-Komprimierung (nicht JP2000) verwenden kann, sodass die Größe begrenzt ist. Ich habe den Treiber (Code) JP2OpenJPEG verwendet, der in meiner QGIS / GDAL-Version verfügbar ist und keine Größenbeschränkung aufweist. Und vor allem bietet es gute Erstellungsoptionen - unter anderem Auflösungen und BLOCK * SIZE (beide auf angemessene Standardwerte eingestellt).
Miro
Danke, das sind gute Nachrichten. Leider unterstützt Debian wheezy diesen Treiber im Moment nicht. Aber gut zu wissen, welches der vielen jp2000'ends das richtige ist. -
Huckfinn
5

Zu Thema 1. QGIS verwendet GDAL als QgsRasterdataProvider. Die Funktionen zum Lesen und Schreiben eines Rasterformats werden also von der GDAL lib implementiert. Ein unterstütztes Format finden Sie unter folgendem Link: http://www.gdal.org/formats_list.html . Der Befehl gdal-config --formats gibt Ihnen einen Überblick darüber, welches Format in Ihre Bibliothek oder Edition integriert ist. Was von Ihrer Edition bereitgestellt wird, hängt von Ihrem Paket, Betriebssystem usw. ab. Weitere Informationen finden Sie unter http://trac.osgeo.org/gdal/wiki/BuildHints .

Huckfinn
quelle
Vielen Dank für gdal-config --formats. Erster Teil des Puzzles fertig.
Miro
1
gdal-config --formats ist nur für Unix-Systeme. Unter Windows ist es möglich, gdal_translate --formats oder gdalwarp --formats auszuführen, um zu sehen, was verfügbar ist.
Miro
Hm, das ist wahr, gdal-config gibt den Unix-Compilern einen Hinweis auf die Bibliotheksabhängigkeiten. OK, das macht unter Windows keinen Sinn (Cygwin oder Mingw ausgenommen). Aber gdalinfo --format $ DRIVERNAME gibt Ihnen die Infos.
Huckfinn