Topographic Phase removal of S-1 stack for StaMPS export has some problem

Microwave Toolbox Problem Reports
#1

Dear colleagues,
It seems that Topographic Phase removal of S-1 stack for StaMPS export does not work properly. The interferograms (after topo remove) in a stack differ from those of single pairs. Other people have the same problem How to prepare Sentinel-1 images stack for PSI/SBAS in SNAP 5. Thus, all our results are wrong…
Could you, please, check this.
Thank you,
Katherine

4 Likes
Subsetted area is shifted
How to prepare ERS/ENVISAT images stack for PSI in SNAP5
#2

I´m following this issue to try a Stamps processing. Any information related to this will be helpful.

Thank you

Joaquin

#3

Dear katherine,

I’m still verifying all the data, but yes it seems that some DInSAR files are erroneous. When I can confirm it I show an example here.

So for now, if we make a listing ot the issues during the Stamps pre-processing, we have:

  • DInSAR on stacks seems to not work properly
  • Wrong heading inthe output from Snap to StaMPS
  • (Topographic phase removal does not work for Cosmo-Skymed data)

Am I wrong?

Thank you,
Christophe

#4

Dear Christophe,
1/ Topographic phase removal does not seem to work properly with Stack. It works OK with separate pairs.
2/ Heading is OK.
3/I used SNAP only for S-1 images. Images from other sattellites is easier to process with Doris as StaMPS is well adjusted to Doris.
All the best,
Katherine

1 Like
#5

1 - Well, I confirm what you say, separately it’s ok, in stacks the values seems wrong.
2 - For Heading I still have an issue with a different value for heading between SNAP and the output. @annamaria, do you confirm?
(3 - For this I was using the parenthesis, it was more to indicate this fact which is not as much an issue, and which was already noticed in another thread)

#6

2 - For Heading I still have an issue with a different value for heading between SNAP and the output. @annamaria, do you confirm?

@cfatras Heading, in my case, is correct if I use layers withouth TC, is “incorrect” if i use layers with TC. So, the problem is the shift of images, not heading angles.
The only (big) problem is wrong result obtained by topographic phase removal with stack.

#7

Any news regarding this issue?

1 Like
#8

I have just read in description of Snap 6.0 beta version that

Topo Phase Removal handles multiple slave images correctly.
https://github.com/senbox-org/s1tbx/blob/master/ReleaseNotes.md

It is the solution of our problem with multiple ifg stack? @katherine @FeiLiu @krasny2k5 @cfatras .

#9

I am currently testing that, I hope to tell you what I found soon as it would make the whole process so much faster and easier…

1 Like
#10

Well the first results seem correct compared to what I had previously, so the issue for me is solved for the SNAP 6 beta under MACOSX environment. I still have to go deeper in the details but the InSAR/DInSAR process for stacks works for me.

Someone else can confirm that?

2 Likes
#11

@cfatras thank you for your post. It is encouraging.
I’ll test SNAP 6 beta version under linux next week. I will let you know. :slight_smile:

#12

I still see issues with the georeferencing, with an approximate 2km shift. Applying the TC tool corrects the effects though… like previously.

#13

I confirm, the problem with Topo Phase removal tool with stack is solved in Snap 6.0 beta version. :relaxed:

#14

Dear Annamaria,
I also managed to get reasonable (althogh noisy) results with Snap 6 beta version. Topophase removal now seems to work properly. But I am still pussled with the problem of geocoding. If I export to Stamps ifgs without terrain correction (Stack_ifg_dinsar) PSs are shifted considerably. If I export to Stamps terrain corrected ifgs (Stack_ifg_dinsar_TC) there is no shift but the heading value is wrong (180deg). How do you solve this problem?
All the best
Katherine

#15

Dear @katherine, I solved my shift problems with TC correction.
I read the stamps code: it seems that heading angle is used only during the union of patches: in my particular application, I don’t use multiple patches, so I hadn’t problems related to heading angle. I didn’t check the case with multiple patches.

1 Like
#16

Dear Katherine,

One possible workaround is to impose the heading angle value. This is what I do for now.
In ps_load_initial_gamma_snap.m, replace (line 64):

% setparm(‘heading’,heading,1);

with

setparm(‘heading’,yourheadingvalue);

Maybe that will help you…

3 Likes