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.
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)
Thank you for sharing. @jun_lu is this a known behaviour?
We have noticed this problem and are currently working on it. We will keep you updated. Thank you
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.
The problem has been solved and the fix should be in the next patch release. Thank you
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?
If your SNAP is built from source code, then you can simply update the code and build SNAP again. The fix should be there.
I have also same issue any suggestion for this so please reply.
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.
Sorry to dig this up: Terrain Correction with Copernicus results in fine results:
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.
After Multilooking (second below) the error remains, but when I increase the Oversampling to 4, it is nearly gone (third below):
Does this make sense? And what is the role of oversampling?
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.
Thank you for the response.
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.
absolutely, same thought.
This would explain a lot. I thought the Copernicus DEM was already referenced to EGM?
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.
Unfortunately, the results are still behind the expectations
top left: original
top right: TF with SRTM
bottom left: TF with C30 (external) without EGM
bottom right: TF with C30 (external) with EGM
sorry for the quality.
As you see, flattening with SRTM is still better than with the Copernicus DEM. I checked its quality and heights in the area, they look alright.
Copernicus AutoDownload leads to the mentioned stripes.
I’d like to run your image. Please send the ID and a lat/long location.
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.
You’re right, might be worth a check. But I would be surprised if the Copernicus DEM had such an offset.