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
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
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).
Bonus Set 2 (I could not get anything processed, IW3 covers DEM tiles with different width):
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.