Data Ignore Values and Masking

[Benjamin Jakimow]

[Mail M.D. 2017-05-23]

(3) haltet ihr es für sinnvoll, dass es ein globales NoData-Value für die gesamte Box gibt? Oder zumindest einen Default-Wert? Aktuell ist es so, dass manche Apps keinen NoData-Value in den Header speichern, deshalb brauche ich in meinen Skrips immer die Variablen „NoData-In“ und „NoData-Out“ und das führt oft zu Verwirrung. Allerdings finde ich auch, dass ENVI mit NoData nicht sonderlich hilfreich umgeht.

(5): Ein Feld zur Maskierung macht in fast allen Apps Sinn, denke ich. In Potsdam habe ich das Problem angesprochen, das ich bei der Support Vector Regression in der EnMAP-Box 2 habe: beim Parametrisieren der SVR kann man keine Maske eingeben. Ich muss deshalb vorher von Hand mithilfe des ImageMathCalculators eine Maske bauen und auf das spektrale Bild anwenden. Beim Anwenden des SVR-Modells kann ich hingegen eine Maske angeben, dort ist es aber für mich gar nicht notwendig. Jeder Entwickler nutzt Masken anders und darum fände ich es schön, wenn wir im ECST eine gemeinsame Marschrichtung hätten.

[Andreas Janz]

(3) QGIS und GDAL setzen den NoDataValue eines Images an verschiedenen Stellen in Wert. Jeder Algorithmus sollte die „NoData-In“ und „NoData-Out“ Information sehr sorgfältig behandeln. Noch ein paar Gedanken:

• ein globaler NoData-Value ist nicht sinnvoll, da je nach Applikation und DataType des Output-Images immer individuell entschieden werden muss, welcher NoData-Value Sinn macht

• Algorithmen sollten davon ausgehen, dass der NoData-Value in den Inputs korrekt gesetzt ist (Konsistenzprüfung durchführen, wenn nötig!)

• die EnMAP-Box wird einen GeoAlgorithm enthalten, mit dem man den NoData-Value für ein Bild setzen kann

(5) Auch die Maskierung ist applikationsabhängig. Das Einbinden einer Maske ist ja auch nur ein Einzeiler im Code. PS: bei der SVR Param. ist das Label Image die Maske.