I have tested various different DEMs and all work correctly (including SRTM auto download) except for “Copernicus 30m Global DEM (Auto Download)”. The “garbage” results contain zeros in a regular pattern in the Terrain-Flattened product. A very small subset is shown below. ![image|352x355]
The solution I found is to copy the auto downloaded compressed TIFF files to remove the compression. I replace the compressed TIFF files in my local cache directory, and then auto download uses my uncompressed versions and produces a correct result.
This may not be an issue for Windows users since compressed TIFF files have worked elsewhere. Linux users have had to use uncompressed TIFFs (particularly for DEMs).
This is on Linux running SNAP v 8.0.8, using: S1B_IW_GRDH_1SDV_20210211T010234_20210211T010259_025552_030B70_3977_Cal with Copernicus 30m Global DEM (Auto Download)
There is a flaw in my tests: I am now not able to reproduce good results with the uncompressed DEMs. Something else I did solved the problem. Back tracking now.
Can the fix be installed manually into an existing SNAP 8 version by downloading some code from Github? If so how? What is the ETA for the next patch release that includes the fix?
Take the downloaded DEMs in your local SNAP cache …/auxdata/dem/Copernicus 30m Global DEM/ or other DEM, and mosaic them together. You can then use the mosaicked DEM as an external DEM. Remember to select Apply EGM and the DEM file probably cannot be compressed.
But Terrain Flattening using Copernicus DEM 30m (AutoDownload) makes weird results with stripes and lots of nodata areas. I used Sentinel-1 SLC, applied Split, calibrated to Beta0, Deburst, then Terrain Flattening. Tested different oversampling values, no change.
This is a known bug. The fix was supposed to be included in the last patch release in Dec. 2021, but was not included. Using an external DEM created from the Copernicus DEMs is a work around. I expect the fix will be included in the next patch release.
Oversampling just averages the zeros with the surrounding pixels which suppresses the effect: visually less apparent, but the values are altered and not correct.
We tested that and it technically works, but less effectiv as expected.
left: without flattening
middle: TF with SRTM 30m
right: TF with Copernicus 30m as local DEM
The right image is not what I would expect. TF with Copernicus DEM should be better than SRTM, and should suppress some finer topographic details. You will need “apply EGM” when using external/local Copernicus DEM.
Use of EGM can be confusing. Almost all elevation models are created with a vertical reference to WGS84, but for general use they are converted to MSL using EGM 96 or 2008.
All satellite to ground computations need WGS84 so the DEMs need to be converted from MSL, back to ellipsoidal using EGM. However, I’m not sure this entirely explains the difference in your image.
The last results were stripmap products of COSMO-SkyMed. Do you think this matters because the resolution is finer?
Maybe I can summarize our experiences:
we tested SRTM and Copernicus DEM as external DEMs in both integer and float
Looks like the Copernicus DEM download for TF has a bug, because Terrain Flattening with an external DEM does not produce these empty patterns
somehow the Copernicus DEM does not provide as accurate flattening as SRTM (despite of higher quality). Applying EGM does not make up for these differences.
Maybe perform a check of the registration between SRTM and Copernicus DEMs (create a difference image?). TF for CSM appears to be operating correctly because of the results using SRTM. So there must be some other difference in the DEMs. Is it possible this area of the Copernicus DEM could have been void filled from a different source? A small misalignment (geometric shift) of the the DEM can cause fine topographic features to not be TF, similar to what is shown with your results.
![image|352x355]
