Differences in SRTM data

Hi Marpet,

The elevation values from SRTM 1arc sec HGT auto downloaded DEM in SNAP are different from downloaded SRTM DEM. How is that possible? I have created elevation band for a product. There is lot of deviation in the elevation values from created band and the downloaded SRTM product for the same area? Which one is correct…
Should I write it in separate post?
Thank you…

Not necessary to create a new thread. I do it.
But it would be good if you can tell how big the differences are. Maybe it’s a different version? has the other DEM you have downloaded also a resolution of 1 arc sec?

Thank you…
The differences are around 3-6m in elevation band, created for product in snap and 50-70m in downloaded SRTM DEM. Yes, the resolution of the downloaded DEM is 1arc sec too. I am attaching the screenshots of pixel values for both the products here.

For the location you highlighted the value of 53 meters is more reasonable.
At lest when comparing with Google Earth

What’s the download location of the external DEM?
Maybe it is a later version as SNAP is using.

@lveci @jun_lu Do you have an idea why there are such big differences?

Yes, When I overlayed on google earth I found elevations around 50m.
The DEM covers, Assam state in north eastern part of India and bit of Bhutan.

Is the definition for “elevation” different for the two products? For example over the reference ellipsoid or alternatively over the geoid?

Hi mengdahl,

I have downloaded SRTM 1arc sec DEM which is having the product specifications with vertical datum as EGM96 which I think is using reference ellipsoid. In SNAP while adding the elevation band I have added SRTM 1arc sec HGT. How can I visualize the reference system of that band? Correct me if I need to know some information. Thanks…

Hi @samlee,
have you solved this issue?
I am experiencing the same problem and I would like to find a way to compare both DEMs.
Dear Marcus (@mengdahl), could you help to understand how it is possible to do that? Is it possible to change in SNAP the reference (ellipsoid or geoid)?
Thank you in advance.

S Savastano

can you please specify what DEMs exactly you want to compare and how they are different at the moment?

Dear Andreas (@ABraun),
thank you always for your help. My question is again related to this other my post Sentinel 1 data : terrain correction but now I am interested in comparison of a DEM downloaded and the one obtained after the Terrain Correction.
Briefly, I have downloaded a tile for SRTM1sec from https://dwtkns.com/srtm30m/ including my ROI and then I have imported it in SNAP.

  1. SRTM downloaded

Relatively to my ROI, the height is between 1 and 16 m (and 0 is associated with the sea).

Then I have applied all the steps for InSAR DEM and in the tool Terrain Correction, I have ticked the box “DEM” and to have the same resolution of the DEM downloaded I have put as Pixel spacing (m) the value 30.
The band “elevation” in the final product is shown here:

  1. SRTM1sec DEM from SNAP

The problem is that now the range of height values in my ROI is completely changed (from 57 to 67 m) and at the pixels belonging to the sea is associated values around 55m.
This happens also if I use as external DEM, the one that I have downloaded.

Now I have read that probably this difference is due to the different system reference used as reported here Problem with Elevation Band.
So my questions are:

  • Is this an explanation for these different height values?
  • If it is true, also the DEM generated by InSAR technique is referenced to the ellipsoid?
  • Is there a way also in QGIS to change this reference to the geoid?

Thank you for your support and guidance.

S Savastano

could it be a matter of resampling?

What happens if you select nearest neighbor resampling for the DEM during terrain correction?

Thank you for your quick reply, as always.
No, also using a different resampling method there is again the same problem.
Reading in the forum, I have found this your post

Is it possible that in Snap all the DEMs are evaluated in Ellipsoid reference and instead the one downloaded is in geoid (vertical datum EGM96)?
This could explain the different height value in the two DEMs.

I’m not sure about that - maybe a developer can answer this

1 Like

Dear @mengdahl,
could you help me to clarify this my doubt about the reference of DEMs in SNAP? Are they in ellipsoid reference?
Thank you so much for your support.

S Savastano

Dear S Savastano, I need to pass this question to @jun_lu for technical details.

  • Marcus
1 Like

The SRTM 1s DEM used in SNAP is downloaded from CGIAR. Also the DEM is EGM96 referenced. You can download the SRTM 1s DEM tile for the same location of your ROI and compare it with the tile you’ve downloaded from https://dwtkns.com/srtm30m to see if there is any difference

1 Like

Dear @jun_lu,
thank you for your reply.
Indeed, that’s the problem. If I open in SNAP the DEM downloaded from https://dwtkns.com/srtm30m, I can see for example that for the pixels belonging to the sea the elevation is 0 (in according to the EGM96 reference). On the other side if I use the option “add elevation band” in the terrain correction tool, considering SRTM1sec as a reference, the band “elevation” that represents the used DEM, shows completely different values from the DEM downloaded: for example, looking again to the sea, all the pixels are not anymore 0 but a variable value around 55m.
Now my question is: when I use “add elevation band”, the SRT1sec DEM in EGM96 reference is in some way transformed in a new reference system (ellipsoid I guess)? Why the sea pixels are so different in elevation values, considering that the DEM is the same (SRTM1sec)?
Thank you again for your help.

PS Just to be sure, it is the same happened in this post

S Savastano

You can try to run Terrain Correction with the external DEM option and use the DEM tile you downloaded as the external file. And do not select “Apply Earth Gravitation Model”, but select output DEM band. See if you get zero height for the ocean pixels.

We will look into the issue to see if it is a bug in the code. Thank you for your post

Dear @jun_lu,
I have repeated the Terrain correction following your indications and I can confirm that all sea pixels have an elevation of 55 m ish.
Moreover, also in my ROI, the pixels have different values from the ones in the SRTM downloaded (55-68m vs 1-12m).
I thought that this difference was due to a different reference (ellipsoid) used in SNAP, as reported by @mengdahl in
Problem with Elevation Band

or by @marpet in
Differences in SRTM data

I think that’s important to highlight that this issue affects also the Phase to Elevation tool, because I have masked out all the sea pixels and despite their phase and unwrapped phase is 0.0000, their elevation is completely wrong (101 m ish).
Let me know if you need some other tests or some other images.

S Savastano

55m is a plausible distance between the ellipsoid and the geoid.