Hi all,
I am encountering an issue when applying terrain correction (range-Doppler) to S1 scenes around northern Greenland using the Copernicus 90m DEM (same for 30m though). I’ve noticed it when switching the DEM for operational processing of S1 scenes from GETASSE30 to Copernicus 90m. What’s really confusing is that some scenes process just fine, but others fail mid-process with this error message:
Cannot invoke "java.awt.image.Raster.getDataBuffer()" because "tile" is null
and succinctly:
Error: no product reader for band \'null\'
The issue appears to be independent from:
- input band
- output resolution
- output map projection
Mask out areas without elevation option- SNAP Desktop or via graph processing tool
gpt
- overall scene size
- processing resources (limited to 16 threads and 16GB of RAM on my machine)
When I say this happens only for northern Greenland I need to specify: I only know for sure for all scenes covering the Arctic and Antarctic, as this is what is processed on a daily routine. No clear geographical pattern emerges when looking at what scenes fail and which do not. The amount of intersection with land does not seem to matter. Repeat-passes however do seem to all be affected (tested only one time). The terrain-correction with GETASSE30 works just fine. Creating a merged tif from the downloaded Copernicus tiles and passing it via external DEM option also works.
I would dislike going back to GETASSE on these scenes now that I’ve seen the accuracy that the Copernicus DEMs bring along. Also I am stumped by the very specific conditions of this - do you have an idea on what could be the issue?
An example scene that does not work: S1C_EW_GRDM_1SDH_20250525T202405_20250525T202505_002492_005321_764B.SAFE.zip
An example scene that does work (close-by): S1C_EW_GRDM_1SDH_20250525T121628_20250525T121728_002487_005303_F1FA.SAFE.zip
@jun_lu can you have a look?
I don’t seem to be able to reproduce the issue. Below are the terrain correction results of the two products. I think it could be an memory issue. The reason that you have no problem in terrain correcting the second product is probably because a large area of the image is over the ocean. The first image, on the other hand, is completely over the land. You can try to process the first image again and set the Pixel Spacing (m) to 80.0 to see if you still have the problem.
Thanks @jun_lu for having a look. I forgot to mention that I’m using EPSG:3413 as a target CRS. Can you reproduce the error when setting the “Polar Stereographic” projection as map projection? For me both selecting it from the list for “custom CRS” as well as selecting it via EPSG:3413 code in the “Predefined CRS” has the same outcome.
I hadn’t tried many different projections yet - for me processing to “WGS84(DD)” works, as does processing to an automatic UTM zone. But setting another polar stereographic projection (EPSG:3995) via “Predefined CRS” fails.
Regarding the other points you mentioned: It appears to me that the error occurs independent of the output pixel sampling. I’ve tried 640m and 4000m resolution, to no avail.
For the land/water coverage, I’m attaching a map with scenes that do and don’t work. The darker frames outline scenes where terrain correction to EPSG:3413 with Cop90 DEM does not work. Lighter frames indicate no issues. Many scenes with little land in them fail during processing:
Edit: Time frame of the map is about five days of data.
Yes, we can reproduce the error when EPSG:3413 is selected as map projection and Cop90 DEM is used in terrain correction. A Jira ticket (Jira) has been created to track the issue. We will look into it. Thank you.
No, thank you!
For now it might be interesting to mention the workaround: Downloading the DEM tiles manually, merge them into a tif and supply that tif as an “External DEM”, which works just fine.
