Subsidence map in 3d view

So sorry for my careless,thanks!!!

I am reading this conversation but how we can know our orbit is precise or not?

you can check in the Processing_Graph which option was selected

and you have an entry in the Abstracted Metadata

Hi

I was following this conversation to understand after unwrapping, what equation can I use for converting unwrapped phase to elevation (deriving DEM) but I did not find any answer. Because this formula that you mentioned is for unwrapping to displacement and nothing for elevation.

I even asked my question here but nobody answer me.

Can you help me to know what should I use after unwrapping to derive elevation (DEM), if I want to use MATLAB or band math?

Thank you Sir.

You can have a look at the source code of the phase to elevation module: s1tbx/PhaseToElevationOp.java at master · senbox-org/s1tbx · GitHub

According to copernicus.eu, Sentinel 1 operates on C-Band whose wavelength ranges from 37.5 to 75 mm. Also I have noticed using the value 31.1 mm in displacement equation according to this thread

And another user in the same thread is seemingly operating on Sentinel 1 data , has typed the wavelength value 5.6 cm into the equation

So which is exact wavelength value should I manually type?
I hope I am not asking a repetitive question

31 mm refers to TerraSAR-X which has shorter wavelengths.
You can get the frequency from the metadata and convert to length Frequency to Wavelength Calculator - everything RF

Should br around 56 mm

1 Like

I am working with TanDEM-X data, so I found this phase ramp too. As I know this ramp is automatically remove by using GAMMA software but SNAP does not have option to remove it (I understood by reading this post)…is not it?
So I tried to do it by myself but I applied it over my final DEM (without terrain correction), not over unwrapped result.
I got average for any column and then I made a fitting line over that, then I subtracted what I had from fitting life and the answer is here:

But then my DEM result is not real DEM data (I mean their elevation is not correct), as you can see above.

  1. Any idea?
    I also found this study that they used a method to removing phase ramp
    https://www.researchgate.net/publication/273877305_Monitoring_spruce_volume_and_biomass_with_InSAR_data_from_TanDEM-X

Then I think I need 30 Ground Control Points (GCPs) over my AOI to do it (actually I do not know this method is in Gamma or is it only a method that we can apply in any software) but as my AOI is a glacier, then I do not know from where I should get them?
2. Is it enough to look at a DEM (for example Copernicus) and find 20 pixels that is over land (off-glacier areas but around the glacier that I am working on it) and then get their elevation. After that back to my DEM over glacier, then…???
Thanks in advance.

Sorry, I don’t get this point.

Ops…I modified it now…I mean for example, the glacier height should be between 10 to 1000 meter (almost) but now by this method, it is not.
Yes, ramp is removed but results are not correct.

I think that is because the trend includes the absolute heights. If you remove it, you end up with an average height of 0 (as shown in the last plot). Instead, you have to calculate a difference between a reference height (e.g. Copernicus DEM) and your TanDEM-X elevations, extract the trend of this difference and remove it. Then, what remains should be close to the reference heights.

Dear @ABraun . Thanks for reply.
I did what you suggested me but it did not work. The reason is my AOI is glacier, so one side (accumulation area) is upper than another side (ablation area). So, even over Copernicus DEM, we still have this trend.
The below result is average of every column for TanDEM-X DEM, Copernicus DEM and you can find their difference with yellow color.

I added DEM result and Copernicus DEM images here as will.

Figure 1. TanDEM-X dem


Figure 2. Copernicus dem

Then the East-West trend is not fully representing the faulty orientation of your TanDEM-X DEM.
Another option is to extract the differences at multiple points in the image and create an interpolated difference map. This can then be subtracted from the DEM.
We did this in our study in Vietnam: https://doi.org/10.1080/22797254.2019.1604083

I do appreciate your effort. However, shouldn’t this entry be applied to the resulted displacement image from step 1?

My comment is older than 5 years - so things might have changed in the meanwhile :slight_smile:
I think it strongly depends on what your data looks like, what you need and when you do the masking. Plesae check this discussion here:

1 Like

I understand. I still notice a debate which is quite interesting, I am waiting for Berno to show us his results.

Although what genuinely confused me is that masking out low coherence would have been done to the unwrapped phase image before creating the displacement image, so that when we create the displacement image from the edited uwp. image, we would be able see the effect of removing low coherence on the displacement values.
Then from the latter we determine what the “x” value is, where there’s no surface changes expected, substract “x” from the uwp. image and then re-create the displacement map after the changes. Or simply substract that x value from the displacement image created earlier.

Could you point out what the roughly phase ramp looks like? I have already searched this term in “Guidelines for SAR Interferometry Processing and Interpretation” but I couldn’t find clues. I’ve found this material
(PDF) Slope deformation prior to Zhouqu, China landslide from InSAR time series analysis, however the ramp they have mentioned is quite different to what you have commented at.

It does not affect the result if the masking is done to the unwrapped phase or the displacement image. This only removes areas with insecure patterns (e.g. if you have local peaks and don’t know if these come from atmosphere or actual displacement)
It does affect the result when you mask out low coherence areas before unwrapping. But it depends on the size and distribution of these areas and their fraction of the overall image.

Yes, the ramps in the study you mentioned are highly systematic and determined by bad orbit quality, false flat-earth estimation, ionospheric patterns…
What I meant in terms of ramps caused by unwrapping of noisy phase is shown here, for example:

grafik
Souce: Displacement from Sentinel1 - #35 by chronomanz
As you see, none of the unwrapped patterns relate to actual displacement. They are a result of the random phase in the interferogram which sums up during the unwrapping in unexpectable directions. Using such results would not be credible.
More examples on ramps here: Phase unwrapping and low coherence - #2 by ABraun

I read this paper but it did not mention to the ramp directly. I think it can be found in this paragraph:

Derivation of surface heights and built-up areas?

Actually it is not clear to me that where was the ramp in this work and which method you used.

Anyway I did what you suggested me (although I thought this would not work):

I divided all columns in nine columns and I selected 3 points on any of them (1 in below figure), then I got average from them (2 in below figure) and made a fitting line on them and continue as previous approach but as you can see results are not real (4 in below figure)….

Sorry for the misunderstanding. Instead of averages per column I was talking of a trend surface to be subtracted from the TanDEM-X DEM. The part in the study is “Vertical adjustment of both images”

This may be a primitive question but If I may ask,
is there a difference in meaning between “Phase jump” and phase “ramp” terminologies? I understand that path following-phase unwrapping process can be erroneous if phase jumps occur when the interferogram fringes are distorted by discontinuities resulted from cases such as layover or the presence of water bodies. I couldn’t find descriptions for such terminologies in Ferretti’s guide (InSAR Principles: Guidelines for SAR Interferometry Processing and Interpretation) So, if possible, can you highlight those phenomena in the figure provided by the author of this post under discussion