EnMAP data reader fails with latest L2A products

Hello,
I just downloaded a couple of EnMAP L2A data and SNAP (10.0.0 with integrated EnMAP reader) cannot open them anymore. Same behaviour on the command line, when opening ZIP or XML files in the GUI:

reading file ./ENMAP01-____L2A-DT0000001164_20220617T210651Z_001_V010402_20240713T151027Z.ZIP
error: I/O error while reading input product: Cannot read product

Previously downloaded EnMAP L2A data is still read in properly.
For example this file works:
ENMAP01-____L2A-DT0000070024_20240421T105905Z_001_V010402_20240430T082322Z.ZIP

but this one doesnt:
ENMAP01-____L2A-DT0000001164_20220617T210651Z_001_V010402_20240713T151027Z.ZIP

However SNAP reads the newly downloaded corresponding L1B scene without problems:
ENMAP01-____L1B-DT0000001164_20220617T210651Z_001_V010402_20240713T155043Z.ZIP

I’m not sure if this is a problem with SNAPs EnMAP reader, because both products indicate the same EnMAP processor version V010402 and I wouldnt expect any substantial changes in data/metadata.

Any idea what causes the issue?

thanks & all the best
Daniel

Could it be that the download of one file is corrupt? I just tried two products, both work.

  • ENMAP01-____L2A-DT0000079715_20240626T111046Z_006_V010402_20240715T220730Z.ZIP
  • ENMAP01-____L2A-DT0000081338_20240708T112128Z_006_V010402_20240715T215627Z.ZIP

Hi Marco,
thanks for your reply. However, its not only one file, its a bunch of 27 L1B and 27 L2A files of which all 27 L2 files fail. Probably something went wrong with this L2 processing at DLR? Maybe, but all datasets look complete and OK. There are some differences in the XML metadata though, compared to L2 downloaded a while ago. The datasets are from 2022 and with the latest from August 2023, Northern Canada. I’ll download some other data and check that.
best
Daniel

Can you provide one the products which is not working, e.g., via WeTransfer.
You can send the link as DM

Oh no! It is my fault! :flushed:

The reason is that the UTM zone for the data from Canada has only one digit.
In the code I originally implemented I expect the code to consist of two digits, 08 instead of 8.

I’ve created a patch for this problem and sent a pull-request to the current dev team
Add test cases and fix UTM zone parsing in EnmapProductReader by eomasters-repos · Pull Request #63 · senbox-org/optical-toolbox (github.com)

Sorry, for this. If you want, you can modify the METADATA.XML file. After the modification SNAP should read the products.

Change this

<ortho>
  <projection>UTM_Zone8_North</projection>
  <resolution>30</resolution>
  <resampling>bilinear</resampling>
</ortho>

to this

<ortho>
  <projection>UTM_Zone08_North</projection>
  <resolution>30</resolution>
  <resampling>bilinear</resampling>
</ortho>

@TomBlock Can you integrate the patch?

great, thanks for the quick fix!

Will be fixed in SNAP 11, merged PR63.

Cheers,
Tom

1 Like