Copernicus DEM complications when coregistering S1

I have been debugging Copernicus DEM usage for S1 processing. I have been mostly stuck in either null pointer exceptions, java heap space or Garbage collector errors. Not a problem at first, increase RAM to 20 GB out of the 30 available, close other applications etc. Then still no avail. Next step, decrease the area to be processed, for example to couple of bursts only. Managed to squeeze some products, but still quite often stumble upon same problems.

I also ran the latest build, which is built straight from the source (latest 9.x branch for all components), same happens.

Trying to find answers I have noticed that in the Run windows of IntelliJ a lot of Copernicus DEM tile names are printed to stdout. This happens in the Copernicus30mFile and Copernicus90mFile method called getRemoteFile(). Area selected should need 4 tiles only, for full 3 subswaths this could increase to 12 tiles maximum (3 x 4 tiles).

Moreover when debugging the coregistration itself, backgeocoding part of it to be specific, I think there are some implementation details missing. For getElevation() method a init() call is done in order to recalculate the virtual grid based on the latitude, since Copernicus DEM tiles differ in width hence member variables should be adjusted, which is not needed for SRTM3 for example. Such thing is missing for getIndex(), getIndexX(), getIndexY and getGeoPos(). For getIndexY() and getGeoPos() this would not be even sensible/impossible to do. I’d implement some exception there if it is not called via some proxy, like getElevation() does when calling init() before getIndexX|Y calls. For getIndex(), it is not overriden, but could be done easily, by providing init() call before continuing with getIndexX|Y. Backgeocoding calls getIndex() directly for pixel positions between reference and secondary scenes for example.

Based on that I think things get messy when scenes that cross DEM tiles with different widths are processed. For scenes where DEM tiles’ width remain identical, such a scenario cannot be exploited. Below is an illustration of detectable strip of pixels on the border of N50_E005 and N49_E005 tiles of a product that was coregistered, coherence calculated and terrain corrected. This is from Set1 IW2, bursts 7-9.

Some reference scenes that cover an area where DEM tile widths differ (crossing N49…N51 and S50…S52).
Set 1:

  • S1B_IW_SLC__1SDV_20210615T054959_20210615T055026_027363_0344A0_83FE.SAFE
  • S1B_IW_SLC__1SDV_20210721T055001_20210721T055028_027888_0353E2_E1B5.SAFE

Bonus Set 2 (I could not get anything processed, IW3 covers DEM tiles with different width):

  • S1A_IW_SLC__1SDV_20220222T235614_20220222T235642_042032_0501C3_D852
  • S1A_IW_SLC__1SDV_20220306T235614_20220306T235642_042207_0507B2_2270

Just for the clarity I’ve only used 30m one, but I believe same problems pop out for 90m as well since the implementation models are tightly coupled. For latter problems might be hidden, since tiles are smaller in terms of bytes.

I checked SNAP’s auxdata copernicus 30 m data folder. There are 252 tiles, out of which max 30 are actually considerable ones and cover the scenes I’ve processed.

The glitch on the DEM boundaries with different width comes from terrain correction step (seen on pictures on initial post).

@lveci and @jun_lu can you have a look at this, please?

We will look into it. A Jira ticket ([SNAP-3471] - JIRA) has been created to keep track of the problem. Thank you for reporting the issue

Awesome, we currently solved this for our GPU based tool by resampling DEM tiles, with customized method, see - DEM handling functionality for Sentinel 1 processors · cgi-estonia-space/ALUs Wiki · GitHub Not perfect, but we believe, sufficient.


Great work and thank you for sharing it! Resampling is also the solution that we are considering now. We’ll do some analysis and get it implemented soon. Thanks again for reporting the problem and for sharing your solution with us.

The problem has been fixed and the fix will be available in the next release. Please give it a try and let us know if the problem still stands. Thank you

1 Like


But honestly speaking I do not think that the bilinear is the best resample method and resampling the tiles to the widest tile width by default is the most optimal choice. But it works for sure.