Iceye has distributed a free data set for dark ship detection. This data set provides two files in .tif+.xml format.
Using the SNAP GUI interface, I converted the original .tif to the required BEAM-DIMAP before then saving (specifically ‘exporting’) that product to .h5. This gives me three files: the original .tif, the saved BEAM-DIMAP, and the exported .h5 file.
The SNAP GUI will properly read the original .tif and the BEAM-DIMAP but not the .h5 file.
Python throws the RuntimeError of:
“SEVERE: com.iceye.esa.snap.dataio.IceyeProductReader: No netCDF variables found which could be interpreted as remote sensing bands.”
when trying to read the product with ProductIO.readProduct().
The Iceye reader is intended to read original Iceye products, not ones that have been converted into .h5.
Yes, I understand that.
The process here is:
-
Take a provided Iceye product - in this case a GRD .tif file (with an associated .xml)
-
Convert the GRD .tif file into a .dim file (+.data directory) to have the SNAP GUI desired BEAM-DIMAP file format
-
Write a .h5 file from the SNAP GUI
Neither python nor the SNAP GUI is able to read the resulting .h5 back in as a product.
In this case, I open the SNAP GUI, select “open file”, select the .h5 file I just generated and it fails. I use python to try to read it, the SNAPPY interface selects the reader, and fails with the error in the discussion. Is that how this is supposed to work?
The original .tif file is ingested properly in the SNAP GUI when the appropriate reader is selected from a list - although it is .tif and appears as a GeoTiff format, the Iceye reader must be used. I have a separate thread discussing difficulty in having the snappy python code read the original .tif GRD file (thus this discussion as I try to make other file formats that python will read in without error or issue).
The BEAM-DIMAP product works absolutely fine in both the SNAP GUI and in the snappy python.
You should use the BEAM-DIMAP internal format while doing processing SNAP/snappy and export to an external format only as the last step.
It feels like we are talking past each other. Suppose I make a ‘product’ that I am happy with after the BEAM-DIMAP conversion and write my ‘final’; out in .h5. I send that to a colleague who then wants to open it or do something further to it. In this example case, my colleague would not be able to see my result unless I send them the BEAM-DIMAP instead of the ,h5 because the .h5 is basically unreadable. That seems like a problem to me - not just something to be avoided. Unless there is a step I am doing improperly, I should be able to use SNAP to import its own exported file - any format, any processing point.
That is not how SNAP works as metadata (which is different for each satellite product that is supported) is not fully preserved in conversions to and from generic data formats. @lveci has more details about the restrictions.
I see now - going through the Git repository of code, most of the file type checks to select the reader are based off the name, not the content. If a .h5 file is named right, the Iceye reader will be applied - even if the .h5 file was generated by SNAP - causing a disconnect in content, placement, and information. Good to know.