Terrain-Flattening results in garbage when using Copernicus 30m (Auto Download)

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.

1 Like

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.

@jun_lu @lveci has the fix for this already been implemented?

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.

I just confirmed the same behavior on Windows. My other tests were on CentOS 7. This graph contains all the details:
TF_only_autoSRTM.xml (3.4 KB)

Below is the terrain flattening result of product S1B_IW_GRDH_1SDV_20211104T233557_20211104T233622_029444_03838B_F65D using SRTM1s DEM (left image) and Copernicus 30m DEM (right image):

The processing was done with the following graph in SNAP 8.0.9:


Can you provide the name of the Copernicus tile that you used as external DEM? Thank you

Looks very similar to mine. Every ~other pixel is 0, particularly if the resampling is NN. The result should be a continuous image. For an external DEM that partially covers the image I used: Copernicus_DSM_COG_10_S04_00_W079_00_DEM.tif

The pixel spacing of S1 product is 10m and the resolution of SRTM 1s and Copernicus 30m DEM is 30m. The terrain flattening algorithm requires that the DEM resolution should be higher than the image pixel spacing. Therefore, applying the terrain flattening algorithm directly to the original S1 product is not encouraged. Normally the S1 product is multilooked first before applying terrain flattening. For example, 60m pixel spacing vs 30m DEM resolution. If we just want the image in its original pixel spacing, current code will perform upsampling of the DEM so that the resolution is higher. In this case, we should try to use good interpolation method. Nearest Neighbor is the worst choice. Even with the upsampling of the DEM, the terrain flattening result is still not as good as applying multilook.

That makes sense, since the 10m upsampled DEM would be stepped. But we have observed similar results with bilinear interpolation that we normally use. The only reason I suggested using NN is because a similar affect is more easily observed. Let’s not use NN, and you might want to remove NN as an option for TF. I’ll run a couple more bilinear tests to verify the issue still exists.

Cursor at pixel/line: 15018, 4854
Autodownload Copernicus with bilinear

External DEM Copernicus with bilinear

1 Like

@jun_lu I am able to reproduce the autodownloaded DEM artifact with a special External DEM. It is an unusual sequence but relates to your clue about nearest neighbor resampling, and my guess that autodownload uses gdalbuildvrt to mosaic the DEMs, or a different process similar to gdalwarp or gdal_translate with nearest neighbor. My process creates a nearest neighbor 20m vrt file from the Copernicus 30m DEMs (0.0001796630568239043 arcmin). Since SNAP does not read vrt files (not sure why) I use gdal_translate to convert the vrt to a tiff. I then use the tiff as the external DEM for TF. I tried 10m based on your note about same resolution, but the result was not comparable to auto downloaded DEM.
The result below using my 20m nearest neighbor DEM with bilinear in TF is very similar to the autodownload result on my previous post.
@mengdahl We already know that the data processing path is different between External and Autodownload DEMs from my posts. This may help identify what may be happening differently with Autodownload DEM. This is approximately the same area as the previous post.

Any update on this issue?

The reason that the TF result obtained using auto downloaded Copernicus 30m DEM is different from that obtained using external Copernicus 30m DEM file is that the DEM oversampling factor is computed differently. The oversampling factor is computed using the DEM resolution and the image pixel spacing. In the former case, the DEM resolution is given while in the latter case the DEM resolution is computed using Earth model. We have updated the oversampling factor calculation so that it is the same for both cases. The fix will be available in the next release.


The new version is out: