Output file formats

[Benjamin Jakimow]

[Mail von Andreas am 14.11.2016] als Input akzeptieren wir ja alles, was GDAL fressen kann :-). Aber als Output sollten wir uns auf ein paar sinnvolle Optionen beschränken, für die wir die CreationOptions in den Settings verwalten können.

Ich halte folgende Formate für sehr sinnvoll:

VRT (wenn möglich, dann Default-Option)

GTiff (Default-Option wenn VRT nicht möglich) - default Creation Options: LZW, tiled 256x256, BSQ

ENVI (wegen ENVI-Legacy ein must-have) - default Creation Options: BSQ

[Benjamin Jakimow]

siehe http://www.gdal.org/formats_list.html

[Benjamin Jakimow]

Meiner Ansicht soll der User das selbst entscheiden. Bei QGIS kann er das, dort besteht die Möglichkeit die Driver spezifischen Optionen selbst zu setzen. Dahinter sollte die EnMAP-Box nicht zurückfallen.

Als Default sind die obigen Einstellungen gut, der User sollte das prinzipiell aber auch selbst anpassen können.

[Andreas Janz]

Nein, das können wir doch auf der Output-Seite gar nicht leisten alle Formate von http://www.gdal.org/formats_list.html zu untersützen! Wir hatten dazu bereits gesprochen und festgestellt, dass wir unmöglich zu allen Formaten die Creation Options überblicken können, geschweige denn graphische Dialoge dafür basteln wollen. Ich glaube wir reden da gerade aneinander vorbei!

Oder meinst du wirklich, dass der Nutzer in der QGIS Processing Toolbox z.B. das imageSVM Classification Result z.B. im Intergraph Raster Format (http://www.gdal.org/frmt_intergraphraster.html) oder irgendeinem beliebigen anderen exotischen Format abspeichern darf?

[Andreas Janz]

Oh, in QGIS kann ich die Optionen pro Driver setzen? Wie geht das??? Wenn das sichergestellt ist, können wir über den omnipotenten Suppert aller Formate nochmal reden!

[Benjamin Jakimow]

Es geht auch nicht um alle Formate, sonder die in der lokalen Installation verfügbaren die ein schreiben von Rasterdaten zulassen. Es ist ein Kinderspiel diese Formate zu unterstützen, die kann man Eingangs filtern. Create oder CreateCopy benötigen nur den DriverCode und die Options, die der User bei Bedarf selbst definieren darf.

Der User soll eine Liste an möglichen Output-Formaten bekommen, in der ENVI, GTIFF, VRT ganz oben stehen. Die optionalen Argumente sollten dabei frei wählbar sein, denn der User weiß das am besten was für ihn sinnvoll ist und ob er die default options überschreiben mag.

[Benjamin Jakimow]

Treiber-spezifische Options: - in den Anwendung gibt es meist eine checkable "Create Options" QgsGroupBox - global über QGIS -> Preferences -> GDAL

[Andreas Janz]

Ok Benjamin, das kannst du mir gerne mal an einem geeigneten Beispiel zeigen, wie das funktioniert. Wichtig für mich wäre, dass es in den folgenden Kontexten gut funktioniert: GDAL API, GDAL Utils, RIOS

[Benjamin Jakimow]

Anbei: https://bitbucket.org/snippets/jakimowb/55o6A Deswegen gibt es bei den GDAL utilities auch immer die parameter -of und -co, welche dem format und dem options parameter in der API entsprechen.

Ob RIOS das kann musst Du mal überprüfen. Würde mich wundern wenn nicht. Wie gesagt, meiner Ansicht nach sollten wir VRT, GTiff und ENVI als "default" anbieten, aber alles andere auch zulassen. Der User muss sich dann selbst drum kümmern das keywords etc. korrekt gesetzt sind. Das muss er aber für VRT, ENVI und GTiff ja auch schon machen wenn er etwas spezifizieren möchte.

[Andreas Janz]

Ja, bei RIOS kann man das auch für jedes Output-Image individuell setzen!

Ok, dann werde ich mal versuchen das konzeptionell für das QGIS Processing und die EnMAP-Box API hinzubekommen, dass da für jeden Algo immer alle Formate möglich sind. Für GTiff und ENVI gibt es dann lediglich Convinience-Methoden, mit denen man sehr einfach die Creation Options zusammenbasteln kann.

[Benjamin Jakimow]

Für die creation options könnten hierarchisch abgeleitet werden. Zuerst die Settings von QGIS, diese werden ggf. von EnMAP-box Settings überschrieben, wie etwa den Defaults für VRT, ENVI und GTiff

[Andreas Janz]

Also ich habe jetzt nochmal länger darüber nachgedacht und tendiere doch wieder zu einer vereinfachten Lösung, wo wir nicht für jeden Algorithmus alle Output-Formate verfügbar machen. Ich denke es ist ok, wenn wir ausschließlich mit VRT und GTiff arbeiten. So wäre mein Vorgehen:

1. Alles was man als VRT erzeugen kann, wird als VRT erzeugt (oder evtl. gibt es eine CheckBox VRT: ja/nein; bei nein wird GTiff geschrieben)
2. Alles was hart rausgeschrieben werden muss, wird als GTiff erzeugt (creation options sind immer LZW compressed, tiled 256x256, BSQ)
3. Es gibt einen Converter Algo für das Processing Framework und ein interaktives, sehr komfortables Tool im EnMAP Viewer mit denen man in alle GDAL Formate konvertieren kann.

Vorteile:

• alle Dialoge sind viel schlanker, weil man nicht das Format auswählen darf

• ist konzeptionell viel simpler und weniger fehleranfällig

• für unsere Zwecke ist das GTiff Format einfach das am besten geeignete und eigentlich immer eine gute Wahl

• da ich immer einen ENVI Header (.hdr) zum GTiff (.tif) lege, sind wir komplett ENVI konform

[Benjamin Jakimow]

ongoing diskussion

[Andreas Janz]

Unterstützt werden nun GTiff, ENVI und Erdas in allen GeoAlgos. Die Unterscheidung findet anhand der FileExtension statt.

[Andreas Janz]

New or overhauled processing algorithms usually create GTiffs and in some cases VRTs. The only two algorithms that allow to store the result as ENVI format are "Translate raster layer" and "Save raster layer as".