Artefacts in CopDEM 30m Auto Download

Hi all. I’ve noticed some errors in processing S1 coming from the Terrain Flattening and Terrain Correction operators in SNAP 10.

I believe I’ve narrowed it down to incorrect pixel values at the edges of CopDEM 30m tiles from the Auto Download option (I’m not quite sure of the actual source of this data).

This seems to have been introduced in SNAP 10, and hasn’t occurred in SNAP 9 with the same/similar graph.

Has the location of the auto-downloaded tiles changed that might have introduced these problems? They might need re-processing to remove the band of incorrect pixels.

It also seems that the old DEM GeoTiffs were “deflate” compressed, whereas the new ones are not compressed at all.

Sample images over the UK, but looks like a regular problem that could affect all CopDEM tiles.


Incorrect Output from SNAP 10


Expected Output of the same scene, previously processed in SNAP 9

The auto-downloaded “Copernicus 30m Global DEM” tiles in SNAP’s auxdata folder, showing a band of low value pixels at the border (specifically, 2 pixels at the top border, and 1 pixel on the left) at the location of the backscatter artefacts.

@djagula can you have a look? Thanks

I’ve had a look into the SNAP source code. It seems to me that CopDEM tiles are still gathered from https://copernicus-dem-30m.s3.eu-central-1.amazonaws.com, so no changes there.

These lines have been introduced since SNAP 9 and might be the cause of the issue, as the tiles are being resampled and modified in some way upon download.

A Jira ticket ([SNAP-3689] - JIRA) has been created. We will look into it and thank you for pointing out the issue.

The problem has been fixed and the code has been checked in. The fix should be available with the next patch release. Thank you.

1 Like

Just for back tracking, this problem has been caused by this fix Copernicus DEM complications when coregistering S1 Again I think there could be even more optimal way to handle this, but I hope this works :slight_smile: