Hi @jun_lu !
As for my previous post, I think the issue is on how SNAP handles that DEM. I got some tiles of the CopDEM30 and the original DEM do not seem to have such stripes, at least on the area I have downloaded.
Could you please check it out and post a picture of the DEM as is, without any Terrain Correction operation?
Hi @mdelgado:
Below is how I validate one tile of the Copernicus 30m DEM:
- Open the original Copernicus_DSM_COG_10_N52_00_W004_00_DEM.tif in SNAP;
- Create a (1001x1001) subset of the DEM tile with x0 = 2000 and y0 = 2000;
- Create another (1001x1001) subset of the DEM tile with x0 = 2001 and y0 = 2000. This subset is one column to the right of the previous subset;
- Subtract the two subsets using BandMath. Here we basically subtract each column of the DEM tile from its adjacent column.
- Display the result, then we see columns of zeros separated by two non-zeros columns. This means that the DEM repeats its value at every third column.
2 Likes
Thank you very much for that extra information.
Much clearer now.
Interesting… 
Could someone download the tile manually and check whether the error in the source-tile?
The DEM is a Copernicus Core Dataset so the user support email address is the one mentioned.
Users Support Service - CSCDA (Copernicus Space Component Data Access)
If the problem is on the SNAP-side we’ll fix it.
This issue is very likely due to the fact that lon spacing of Copernicus DEM changes with latitude and the tile at this latitude is of size 2400P x 3600L and not 3600P x 3600L. I don’t think there is a problem with the DEM at source but with the way metadata is being interpreted within SNAP and tile size being forced to 3600 and the resulting stretch with some sort of nearest neighbor algorithm in the I/O modules.
Answer courtesy of Gustavo Shiroma.
2 Likes
It should be vertical as lon spacing changes (west to east) and lat spacing is the same. Seems consistent with the observations. Confusion possibly because I reported dimensions in (pixels, lines) or (P, L). The stretch is only occurring the lon direction.
1 Like
This issue of how the Copernicus data in northern regions is handled has been located within SNAP and a temporary fix has been made locally. I’m planning on finishing testing on the change on Monday, and having this issue corrected with the next snap-engine module update if it passes testing.
2 Likes
Hello all,
I’ve just noticed this issue again after processing with the Copernicus 10m EEA DEM downloaded from the official ESA data access platform Panda (described here).
Is it possible that this issue has only specifically been fixed with the Copernicus 30m Global DEM in mind, which is auto-downloaded by SNAP from a different data repository?
See also here: Stripes in Local Incidence Angle and Gamma-Sigma-Ratio · Issue #41 · SAR-ARD/S1_NRB · GitHub
Best regards