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.
There is still an issue with auto download Copernicus DEMs: Copernicus Auto Download DEMs introduce 1/2 pixel and line shift
@jun_lu SNAP 8.0.9/S1TBX 8.0.6 garbage Terrain-Flattening results are still an issue with Auto Downloaded DEMs. The affect can be best observed when using NEAREST_NEIGHBOUR resampling.
TF produced with Copernicus GLO30 auto download:
TF produced with SRTM 1sec auto download:
TF produced with Copernicus GLO30 External DEM.
A JIRA ticket ([SITBX-916] - JIRA) has been created to track the issue. We will look into it and keep you updated. Thank you
Can you share the product name and detailed processing steps so that we can reproduce the problem? Thank you! One thing I want to mention is that the old Copernicus DEM tiles downloaded before our fix should be removed from your DEM repository. Otherwise no new DEM tiles for the same area will be downloaded and the old incorrect DEM tiles are still used in the processing.