Verwendung von gdal2tiles für ein benutzerdefiniertes TIFF-Image, das von Anbietern zum Generieren von Kacheln erhalten wurde


10

Ich habe ein bisschen Mühe gehabt, Kacheln für ein hochauflösendes Bild zu erzeugen, das wir haben. Das aktuelle Bild ist ein sehr großes (+ 20 GB) Bild, das als GeoTiff-Datei gespeichert wird.Großes GTiff-Bild

Ich möchte die Kacheln mit dem Befehlszeilenprogramm gdal2tiles generieren und sie dann in Cäsium öffnen und anzeigen, wobei der TMS-Bildanbieter die Kacheln bereitstellt. Bei Verwendung von gdalinfo sind hier einige Details des Bildes:

Driver: GTiff/GeoTIFF
Files: image.tif
Size is 52250, 56119
Coordinate System is:
PROJCS["WGS 84 / UTM zone 35S",
    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",27],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",10000000],
    UNIT["meters",1],
    AUTHORITY["EPSG","32735"]]
Origin = (606276.000000000000000,7197873.000000000000000)
Pixel Size = (0.500000000000000,-0.500000000000000)
Metadata:
  AREA_OR_POINT=Area
  TIFFTAG_MAXSAMPLEVALUE=13165
  TIFFTAG_MINSAMPLEVALUE=1
  TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
  TIFFTAG_SOFTWARE=ERDAS IMAGINE
  TIFFTAG_XRESOLUTION=1
  TIFFTAG_YRESOLUTION=1
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (  606276.000, 7197873.000) ( 28d 3'21.59"E, 25d19'55.12"S)
Lower Left  (  606276.000, 7169813.500) ( 28d 3'29.55"E, 25d35' 7.17"S)
Upper Right (  632401.000, 7197873.000) ( 28d18'55.92"E, 25d19'47.60"S)
Lower Right (  632401.000, 7169813.500) ( 28d19' 5.85"E, 25d34'59.57"S)
Center      (  619338.500, 7183843.250) ( 28d11'13.23"E, 25d27'27.58"S)
Band 1 Block=512x512 Type=UInt16, ColorInterp=Gray
Band 2 Block=512x512 Type=UInt16, ColorInterp=Undefined
Band 3 Block=512x512 Type=UInt16, ColorInterp=Undefined
Band 4 Block=512x512 Type=UInt16, ColorInterp=Undefined

Mein erster Versuch war, das Bild mit gdal_translate zu georeferenzieren und dann mit gdalwarp die Projektion in EPSG: 3857 zu ändern, wie von Cäsium gefordert (siehe API-Referenz).

gdal_translate -of VRT -a_srs EPSG:4326 -gcp 606275 7197875 28.055987 -25.331974 -gcp 606275 7169814 28.058200 -25.585326 -gcp 632400.5 7197875 28.31553 -25.329876 -gcp 632400.5 7169814 28.318286 -25.583209 image.tif newImage1.vrt
gdalwarp -of VRT -t_srs EPSG:3857 newImage1.vrt newImage2.vrt

Ich erhalte jedoch viele der folgenden Fehler:

FEHLER 1: Breiten- oder Längengrad haben die Grenzwerte überschritten

Eine andere Methode, die ich versuchte, war, gdal2tiles direkt zu verwenden und die Kacheln zu generieren:

gdal2tiles.py image.tif

Dadurch wurde ein Ordner erstellt, wobei ein Unterordner (mit 18 gekennzeichnet) die einzige Zoomstufe ist, bei der Kacheln erstellt wurden. Die Bilder, die ich hier bekomme, sind jedoch völlig "falsch" und "verschwommen".

Ein Beispiel für eine der Kacheln:

Geben Sie hier die Bildbeschreibung ein

Irgendwelche Vorschläge zum Generieren von Kacheln für dieses Bild Großes Bild eines bestimmten Bereichs mit gdal2tiles, damit ich es in Cäsium laden und anzeigen kann?

Aktualisieren

Nachdem ich den Vorschlag von @ iant ausprobiert hatte, verwendete ich die folgenden Befehle:

gdalwarp -co TILED=YES -co COMPRESS=DEFLATE -co BIGTIFF=YES -t_srs EPSG:3857 image.tif newImage.tif

Dieser Befehl funktionierte einwandfrei bis zum Ende, wo ich den folgenden Fehler bekam:

FEHLER 1: TIFFFillTile: Lesefehler in Zeile 43520, Spalte 47104; bekam 35788250 Bytes, erwartet 37421449

Ich bin mir nicht sicher, was dieser Fehler bedeutete. Ich habe ihn für den Moment verlassen und trotzdem ein endgültiges Bild "newImage.tif" erhalten, das vom gdalwarp-Schritt erstellt wurde. Damit habe ich gdal2tiles.py aufgerufen

gdal2tiles.py newImage.tif

Dies erzeugte einen Ordner mit den Unterordnern 10-18 (und nicht nur einer Zoomstufe 18, wie ich sie zuvor erhalten habe). Es liest sich auch perfekt in Cäsium, ohne Konsolenfehler, aber das Bild sieht immer noch "falsch" aus:

Bild in Cäsium geladen

Ich denke, mein Problem könnte sein, wie @ user30184 vorgeschlagen hat "... Quelldaten passen nicht gut für gdal2tiles." Bis unser Anbieter uns jedoch etwas zur Verwendung mit gdal zur Verfügung stellen kann, ist dies alles, was ich habe.

Ich dachte darüber nach, vielleicht eine der Bands zu entfernen, um zu vermeiden, dass gdal die letzte Band als Alpha-Kanal unterbricht. Irgendwelche Vorschläge?


Warum möchten Sie das Bild georeferenzieren? Es enthält bereits alle CRS-Informationen.
AndreJ

Antworten:


7

Ich denke, alles was Sie tun müssen, ist es neu zu projizieren mit:

gdalwarp -co TILED=YES -co COMPRESS=DEFLATE -t_srs EPSG:3857 newImage.tif image.tif

und dann kacheln:

gdal2tiles.py newImage.tif

Wenn Ihre Datei sehr groß ist, dauert es eine Weile.


Sie können die Zoomstufen mit dem Parameter -z steuern. Haben Sie es bereits versucht? Beachten Sie auch, dass Ihr Bild 4 Bänder aufweist, was zu unerwarteten Ergebnissen führen kann, insbesondere weil Sie mit 16-Bit-Daten arbeiten. Einige Vorverarbeitung kann zuerst erforderlich sein
user30184

Vielen Dank für Ihre Antwort @iant. Ich werde es versuchen und sehen, was passiert. Könnten Sie in Ihrer Antwort vielleicht etwas näher erläutern, was die von Ihnen ausgewählten Optionen bedeuten? Gemäß der Dokumentation übergibt die Option -co "eine Erstellungsoption an den Treiber für das Ausgabeformat". Fügen Sie der TIFF-Datei tatsächlich weitere Eigenschaften hinzu?
Anstrengung

@ user30184 Ich habe das noch nicht ausprobiert nein. Wie würde ich wissen, wie hoch die Zoomstufen sein sollten? Oder kann ich sie nach Belieben angeben? Ich dachte, wenn ich diese Option weglasse, würde ich das Skript die Zoomstufe basierend auf dem ausgewählten Bereich bestimmen lassen.
Anstrengung

@ user30184 Sie haben auch erwähnt, dass ich mit einem 4-Band-Bild und 16-Bit-Daten unerwartete Ergebnisse erzielen könnte. Warum genau? Ist es nicht im richtigen Format für die Verarbeitung von GDAL-Kacheln? Wenn ja, wurde das Bild direkt vom Anbieter bezogen. Was wären die Schritte, um die Datei im richtigen Format zu erhalten? Nämlich eine GDAL-TIFF-Datei? (Wenn ich so etwas sagen kann)
Anstrengung

Ich habe die folgenden Probleme beim Ausführen von gdalwarp, wie Sie @iant vorgeschlagen haben: >>>>>>>>>>>> FEHLER 1: TIFFFillTile: Lesefehler in Zeile 43520, Spalte 47104; 35788250 Bytes erhalten, erwartet 37421449 FEHLER 1: TIFFReadEncodedTile () fehlgeschlagen. FEHLER 1: pleiades_merge05m_2015-06-19.tif, Band 1: IReadBlock fehlgeschlagen bei X-Offset 86, Y-Offset 109 FEHLER 1: GetBlockRef fehlgeschlagen bei X-Block-Offset 86, Y-Block-Offset 109 >>>>>>>>>> > Irgendwelche Vorschläge, um dies zu beheben?
Anstrengung

2

Ich nehme an, Ihr Image ist eines der 4-Band-Produkte von Airbus DS:

http://www.intelligence-airbusds.com/de/4951-which-spectral-mode-do-i-choose

Gdal2tiles dient zum Aufteilen gängiger visueller Bilder in PNG-Kacheln. Solche Bilder verwenden 8 Bits pro Band und haben ein Band (Graustufen), 3 Bänder (Rot-Grün-Blau) von 4 Bändern (Reg-Grün-Blau + Alpha).

Ich würde sagen, dass Ihre Frage weitgehend irrelevant ist, da Ihre Quelldaten nicht gut für gdal2tiles geeignet sind. Sie können die unmittelbaren Probleme umgehen, die Sie gerade haben, aber das Endergebnis wird immer noch nicht gut sein, wenn Sie Ihre Daten nicht erneut verarbeiten.

Der Grund für eine nicht gut aussehende Kachel, die Sie Ihrer Frage beigefügt haben, kann sein, dass das vierte Datenband als Alphakanal interpretiert wird.


Vielen Dank an user30184. Ich habe einige Ressourcen gelesen und bin zu einem ähnlichen Gedanken gekommen. Ich denke, es wäre am besten, unsere Anbieter zu bitten, uns "GDAL-kompatible" TIFF-Dateien zur Verfügung zu stellen, aber bis sie sich bei uns melden, ist dies alles, was wir haben. Ich dachte darüber nach, vielleicht eine der Bands zu entfernen, um zu vermeiden, dass gdal die letzte Band als Alpha-Kanal unterbricht. Irgendwelche Vorschläge?
Anstrengung

Verwenden Sie gdal_translate, um eine kleine Teilmenge aus dem Bild gdal_translate -srcwin 20000 20000 1000 1000 original.tif sample.tifauszuschneiden (große Offsets, um die Knotenbereiche zu vermeiden). Öffnen Sie dieses kleine Bild mit QGIS und Sie sollten in der Lage sein, schnell mit den Anzeigeeinstellungen zu spielen. Meine Vermutung über den Alphakanal ist wahrscheinlich falsch, sonst sollte das Ergebnis bunt und nicht grau aussehen.
user30184

Danke @ user30184, ich habe getan, was Sie vorgeschlagen haben, und es erfolgreich in QGIS geöffnet. Siehe diesen Link: drive.google.com/open?id=0B97NtaPJrVz-anRYQmxjZFludk0 Wie kann ich jetzt mein Problem "debuggen"? Verwenden Sie QGIS, um gdalwarp und gdal2tiles auszuführen?
Anstrengung
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.