Sentinel 1 data : terrain correction

The vector geometry you imported has a topological error, you can delete it before RD Terrain Correction and save the product and run again.

Got it sir…!!
Terrain corrected properly.
Thank you very much.

Hi, @sugandh_2791 and @ABraun,
sorry to use this old post but I am having the same issue reported by @sugandh_2791 about the change of height in the external dem after terrain correction.
Have you found a solution for that?
Thank you in advance.

S Savastano

Please let us know what kind input data you terrain corrected, what external DEM you used and how much the values changed.

Dear @ABraun,
thank you always for your quick response.
I’m working on a small area around Rosslare in Ireland. I have a dem with 5m resolution and my idea is to use this dem to terrain correct elevation image obtained with “DEM generation with Sentinel-1” and finally to compare the obtained results.
The input data are:

  1. S1B_IW_SLC__1SDV_20191021T181343_20191021T181411_018577_023005_9181

  2. S1A_IW_SLC__1SDV_20191027T181425_20191027T181453_029648_036060_F64C

and their perpendicular baseline is 200m ish.
So, following the several steps in your tutorial and subsetting a small portion of the image I have created this interferogram and this coherence map

As already discussed with you in a previous post, to reduce the incoherence due to the presence of the sea, I have applied a land/sea mask using SRTM3sec

obtaining this result

then the result of the unwrapped phase obtained with SNAPHU is reported here

and then the output of phase to elevation is

Now if I try to use for the terrain correction my external dem that is

with these values…

the DEM used becomes

with different range values

while the DEM obtained with S1 will be

with range values

Now my question is: why after the terrain correction there is this change in the values of the used external DEM?
Thank you in advance for your help, as always.

S Savastano

good job on creating the interferogram!

Is the external DEM referenced to WGS84 and stored as a Geotiff?

I don’t see the common area between your InSAR result and the DEM, to be honest.

You can include the external DEM in the output product by selecting it in the Terrain Correction model. Then you can look at the DEM and the InSAR DEM at the same time, for example by a scatter plot (example here) and also calculate a differene image.

Hi @ABraun,
yes the external dem is referenced to WGS84 using the warp reprojection in QGIS as you suggested in the past and it is stored as geotiff.
Indeed the last two images are elevation_VV and elevation coming from terrain correction (dem used covers only a part of the scene processes).
The weird thing is the change of range values from the external dem used as you can see above.
Have you any idea about this change?

S Savastano

oh, now I see.

I think the InSAR DEM is well representing the overall topography in your area, but not the distinct height differences in the (probably very small) subset you use. As you see it contains noise from low coherence areas and artefacts from the unwrapping.
What kind of information do you expect from the analysis? I don’t think the external DEM is the problem here. Please try SRTM as well and you will largely get the same InSAR elevations.

Yes, exactly that’s my point.
I don’t understand why using my external dem in the terrain correction tool, the height of the terrain changes passing from an initial range (-1.26m to 12.27m) to the new one (from 53.54m to 69.49).
Is this a possible bug to report to developers @marpet or @mengdahl for a next release?
I don’t think the problem is my external dem and indeed, as you say, if I use for example SRTM 3sec I will have the same problem with a similar change in the values of heights.
What I want to do is to compare the results of InSAR DEM with my external dem and I don’t expect to have better results with S1 due to well know issues about the incoherence, etc., but at least comparable values.

S Savastano

I can’t judge this. Sar processing is not my domain. Probably @jun_lu or @lveci can.

Thank you @marpet,
I hope @jun_lu or @Iveci, or someone else that has dealt with this issue, will read this post.

S Savastano

I’m not clear why you think it could be a bug?
The output of the “phase to elevation” module is simply not representing the topographic conditions in every part of the image. If the InSAR elevation contains weird patterns the terrain correction module won’t fix it either, nor will it adjust the heights to the used input DEM.

Please correct me if I’m wrong or missing a point, but I think if you compare the value range of the InSAR elevation product before and terrain correction, I expect them to be widely similar.

Hi @ABraun,
you’re perfectly right. My point is not on the range of InSAR dem values because they could be due to several factors (incoherence, atmospheric condition and so on).
I don’t understand why there is a change in the range of values of the used external dem. This last has a range of values between -1.26m and 12.27m as you can see by this plot

After the terrain correction, the used external dem has a range of values between 53.54m and 69.49m, as you can see on this plot

Now my question is: why this change?
I expect to have the same values as my external dem before the terrain correction.
And in the end, it is the same situation shown by @sugandh_2791 in one of the above replies.
So, is this change due to a bug? Moreover, it is important to highlight that this situation happens also if I use another DEM as SRTM 3sec: the range of values of SRTM 3sec changes after the terrain correction.
I hope to have clarified your doubt about my point.

S Savastano

1 Like

sorry, now I got your point - the external DEM has been changed, not the InSAR elevations…

Yes, that is likely to be a bug. @lveci - do you have an idea why the value range of the external DEM is altered so drastically by terrain correction? I think this is no longer a matter of resampling.

just to go sure: @s.savastano you did not select this box, right?
grafik

Thank you @ABraun!
Where is included this box (Apply Earth Gravitational Model)?

S Savastano

it is part of the Range Doppler Terrain Correction operator

@ABraun, sorry I have found when you select the external dem…
No, I can confirm that I haven’t selected it.

okay. This would have been an explanation for the changed values at least :smirk:

1 Like

@ABraun, waiting to have help from @lveci or @jun_lu, there are also other two questions and I hope you can help me with them.

  1. as said, to cut off the sea I have used Land/Sea tool considering the SRTM 3sec dem. The obtained interferogram is

now to all the pixels belonging to the sea is assigned the value 0.0 as phase and not NaN. After the unwrapping step, also to the corresponding pixels, the unwrapped phase is assigned 0.0 and not NaN. So my question:
All these values (0.0) could interfere in some way during the unwrapping analysis?
Moreover, when I apply the phase to elevation to create the InSAR dem, it assigns to all those pixels with unwapped phase equal to 0.0 a height values between 93 and 94 m.

  1. If I try to mask the image with Terrain-Mask tool and I use my external dem to cut the image only in that area and to process it with SNAPHU, none mask is applied and I have another band Terrain_Mask completely black.

Do you any idea about that and if there is another way to select only the area covered by my external dem?

Thank you in advance.

S Savastano

I don’t think so. The idea behind is to avoid that irregular patterns over the sea will distort the unwrapping of coastal land areas. So if the Phase To Elevation operator then imputes the elevation values of the external DEM, this is just a mathematical process, but not affecting the quality of the land area.

I think newer versions of snaphu allow the integration of better masks, but I have never tried it so foar. The SNAP terrain mask only uses SRTM 3Sec and my last try with it also produced a black image.
But you can add SRTM 1Sec data to any product (right-click > add elevation band) and use sea pixels for masking using the valid pixel expression of the band properties.

1 Like