[Import EnMAP L2A product] support L2A Analysis Ready Data from Geoservice / EOLAB

[jakimowb]

Requested by Emiliano Carmona via Email.

I tried to use EnMAP box import tool to load the L2A data from the geoservice and that does not work. With the filenames as downloaded from geoservice, the tool can’t find the Spectral file corresponding to the metadata file. That happens because in Geoservice the names of the TIF files have been modified and they add the suffix “_COG” at the end of the filename and change the extension from “.TIF” to “.tiff”. I am not sure but, I suspect that “COG” means “cloud optimized geotiff”, which is different from the normal Geotiff used in the standard products. I thought that perhaps renaming the files manually will fix the issue. In that case , there is no error, but the import is like 100 times slower. I had to kill QGIS, when it was at 4% of importing of the “COG” file after ~20 minutes running in my laptop. Perhaps it works, but it is not very practical.

What did work in the end (as I suspected) was to use gdal_translate and rename manually the files. The gdal translate command is as simple as:

_gdal_translate -f GTiff ENMAP01-____L2A-DT0000071543_20240502T105133Z_003_V010402_20240505T210636Z-SPECTRAL_IMAGE_COG.tiff ENMAP01-___L2A-DT0000071543_20240502T105133Z_003_V010402_20240505T210636Z-SPECTRAL_IMAGE.TIF

so it shall be not difficult to incorporate this into the import tool of EnMAP Box.

reported in follow-up mail:

And while you discuss with them, perhaps you can also mention that perhaps a similar issue will happen with the DESIS ARD dataset to be added to the Geoservice. In this case however, I have not tested anything because they are still preparing the DESIS data.

And please, do not forget to mention that this is for the ARD dataset, for the standard processing all works as usual. The difference is that they will have to maintain 2 types of input.

[jakimowb]

relates to OSGeo/gdal#10859