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.
- 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:
- 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
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.
Hi Marcus (@mengdahl).
yes I agree with you but the weird thing is that if I used the lat lon of a pixel belonging to the sea and then I calculate the difference N between geoid and ellipsoid
using this calculator
https://earth-info.nga.mil/GandG/update/index.php?dir=wgs84&action=egm96-geoid-calc
the value is 43m and not 55m, as visualized here
So, in my opinion, it should be very useful to understand which reference is used in SNAP and which Vertical Datum is adopted (not EGM96 I guess…).
S Savastano
Sorry Savastano, I didn’t fully understand your question before and wasted your time. Yes, you are right that EGM96 based SRTM DEM is converted to ellipsoid based DEM in SNAP and used for all position related calculation. The DEM output in Terrain Correction operator is not the original EGM96 based DEM, instead it is the ellipsoid based DEM. It is our fault that we didn’t make it clear. Hope my explanation above answers your question.
2 Likes
No problem at all @jun_lu.
your explanation is perfect and thanks to you again for your support. I appreciate that a lot!
For @mengdahl:
Marcus you were right, I forgot to consider the latitude in negative being in W and so recalculating the geoid for that pixel belonging to the sea, we have
exactly the value 55m more or less.
Thank you again to all of you!
S Savastano
1 Like
Nice explanation Jun_lu.
So, we can compare GNSS (WGS84) vertical component to PS-InSAR LOS component right. Because both have the same DEM.