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.