I want to highlight an issue with the Terrain Flattening operator when using an external DEM.
The external DEM I’m using here is created from the same Copernicus 30m Global DEM tiles that SNAP uses when selecting the ‘auto-download’ option, which are stored locally in the /.snap/auxdata/dem/Copernicus 30m Global DEM directory. I created a VRT file of the relevant tiles first and used the following command to create the DEM with WGS84 ellipsoidal heights:
In the following comparison of processing results, I used exactly the same workflow and parameters, except for using the auto-downloaded Copernicus 30m Global DEM in one and the external DEM with externalDEMApplyEGM=false in the other for the Terrain Flattening and Terrain-Correction operators.
Terrain effects are clearly visible in the results processed using the external DEM:
Created another external DEM without the correction to WGS84 ellipsoidal heights and used it in SNAP with externalDEMApplyEGM=true. The results are almost identical.
Played around with the additionalOverlap and oversamplingMultiple parameters. Again, the results were almost identical.
Furthermore, I selected the option to output the DEM in the Terrain-Correction step. Comparing the hillshade of both results shows a pixel shift, which might be related to this problem:
In the last months a few other reports have pointed to issues that might be related:
First off EPSG:4326 is only a horizontal reference, so your gdalwarp command may not be correctly converting the elevations. -t_srs EPSG:4979 is 3D and should convert EGM2008 vertical references to WGS84. Regardless, the small elevation difference between EGM2008 and WGS84 is not causing this issue, and may not have any effect on Terrain Flattening.
The posts that you reference are similar. One key issue that @jun_lu noted is that lower resolution external DEMs must be oversampled to the output image resolution (or greater resolution). I believe this may be automatically done for autodownloaded DEMs.
There are a number of small issues with Terrain Flattening, Terrain Correction, and output DEMs: 1/2 pixel/line shifts, single pixel/line shifts, etc.
you’re right that EPSG:4979 would be a more suitable CRS in this case but I made sure that vertical heights were actually corrected. We use the MGRS tiling system in the project GitHub - SAR-ARD/S1_NRB and reproject to UTM zones, which are also 2D.
One key issue that @jun_lu noted is that lower resolution external DEMs must be oversampled to the output image resolution (or greater resolution). I believe this may be automatically done for autodownloaded DEMs.
Our external DEMs are resampled to the pixel spacing of the output image (10 m) before processing starts. I wanted to keep the example above simple but also noted that I changed the oversamplingMultiple parameter without any improvements.
I just did some experiments myself geocoding to UTM with a spacing of 100 m. DEM used is Copernicus 30m. I considered three DEM input scenarios:
external DEM in LatLon in original resolution, WGS84 heights
external DEM in UTM and 100 m resolution, WGS84 heights
auto-download
The UTM DEM is definitely inferior. SNAP performs an internal resampling step (which is unnecessary since the DEM is already in the target projection and spacing) causing some additional smoothing.
The LatLon external DEM performs much better so it is actually better to keep the DEM in the original CRS and resolution saving some reprojection time and in this case also ingesting a DEM in higher resolution than the target SAR pixel spacing into the workflow.
The auto-download option performs even better. The comparison of the output DEMs confirms @maawoo’s findings. The pixels do align but there is a clear shift in values likely causing the lower RTC quality using the second DEM.
