Well explained, @mdelgado
@draco: There was a discussion about ramps sone time ago. Please have a look at this post and the few following up: Subsidence map in 3d view
Hello everybody!
Is there any progress regarding the issue with the shifted elevation and topo bands?
I have a similar problem of shifted bands, in the case of processing two ALOS SLC images (26/12/2006 – 31/12/2008, Bperp=255). SRTM 3arc was used in this case.
What drove my attention to check for this potential shift, in the first place, is the fact that before topography removal the interferogram was like that:
And after topo-removal:
Something seemed to have gone wrong with the topography removal tool. I then read @mdelgado post…
So in cases like this what should we do? Just discard the pair?
Please note that for this particular case, the two acquisitions refer to different reception paths. Could this be the problem?
Thank you all in advance
Have you applied ALOS Deskewing before the topographic phase removal?
I wonder if it makes a difference if you do it before or afterwards.
Dear @ABraun,
thank you for your quick response.
No, deskewing was not applied since the images were provided by ESA (Alos-1 DInSAR Deformation Map). ALOS support team confirmed that the products do not need deskewing.
I see. You are right then, of course.
I am also interested in the issue, but it seems to be of technical nature.
Just to exclude this as an error source: Did you compare the results of topo-phase removal performed during the interferogram processing (using the checkbox) with calculating it as a second individual step after the interferogram was written (using the separate module)?
Dear @ABraun,
Unfortunately the problem remains whether topography removal is performed in one step (checked box) or two steps. The following figure is from one step process (only elevation band can be calculated).
In fact, as already discussed in ALOS SLC L1.1 interferometry processing parameters, even trying with higher orbit interpolation degrees, results are awkward, don’t you think? I would have thought that the 5th “orbit interpolation degree” could be safely selected in every processing (results should be more accurate than using for eg 3rd orbit interpolation degree). Now, it seems that a major problem apart from the orbit precision, is related with the topography removal tool… Is this a SNAP processing error or I should try something else?
I totally agree, but based on this, we cannot do much about it from the processing side.
@mengdahl Is this worth to be listed here? https://senbox.atlassian.net/
What is the actual problem - low quality of ALOS-1 orbits or something in SNAP? I’m not sure if going for the highest possible orbit interpolation degree is physically the correct solution. Perhaps this issue requires baseline-refinement, which we plan to add into SNAP in the future.
mdelgado summarized it in the post above. The integration of elevation data for topographic phase removal reduces the quality of the interferogram.
It seems that orbit interpolation degree affects the problem encountered with the shifted bands and the topography removal performance.
Using the highest orbit Interpolation degree 5, in the two- step processing (1st step for subtracting flat-earth phase, 2nd step for topography removal), bands are not shifted and results are like this:
However, would you trust such interferometry results?!
Would you like me to upload the respective images? is it possible to upload here?
I would like to share with you that in every ALOS pair I processed, I noticed that in the case of using 3rd orbit interpolation degree to remove topography (either in one step -checked box- or in two steps), topo-band and elevation band appear shifted with relation to the differential interferogram produced. On the other hand, when using 5th orbit interpolation degree, bands don’t appear shifted. However, when comparing the two differential interferograms produced (one with the 3rd and the other with the 5th degree) should not they appear shifted between each other as well? Because they do not… and they are not yet geocoded. Could this all thing with the shifted bands be just a visualization error of SNAP?
In the following figures, the left images are snapshots of a 2-year differential interferogram after using 5th orbit interpolation degree and the right ones are after using the default 3rd degree, for topography removal.
Is there a way to check if topography is safely removed in either cases? Do these products-especially the 5th degree- look normal to you? Would it be better to wait for future baseline-refinement?
1 Like
@lveci let’s check if this is a bug. Baseline Refinement is in the plans but not for the far future.
I have remember to had tried the highest degree for orbit interpolation together with highest points, and I agree with @mengdahl that physically should not be the right solution.
I will follow the thread as I am curious about which solution will be.
But please note that the DEM shifted issue I have mentioned was not only found in that ALOS inteferogram I posted time ago, but also reported using Sentinel-1 data (comments from people in IGARSS last summer)
Dear @mdelgado,
I have used various combinations with highest degree for orbit interpolation together with highest points too and I totally agree with you, this should not physically be the right solution.
In a random Sentinel pair I processed the issue with the shifted DEM was not present. However, I am not sure whether I should totally ignore interferometry results when there is a shift between InSAR results and topo/elevation bands. Could this be a visualization bug?..
Do you think we should wait for baseline refinement? And until then, use another software?
it doesn’t solve the problem, but as you asked for it: The ISCE2 package was shortly cleared for open access: https://github.com/isce-framework/isce2
It doesn’t provide a GUI but, once compiled and understood, it is a quite powerful tool.
Well… personally I am not changing software. I use it on my daily processing.
I like to check normally what I do, and doing so I may discard if anytime happens (with Sentinel-1 is rare, but it also happens to me, only few cases when topography variation is very low in the scene being flat areas)
I still recommend SNAP, but surely we need to understand whether the issues may be caused by orbit information, low quality DEM, etc… so lets the developers to analyse and solve when possible.
don’t get me wrong, I also fully aggree on SNAP as my first choice and I don’t want to change this. I just remembered that @EJFielding was able to correctly process ALOS interferograms (here) with ISCE and I recently read that it is now open to all users.
But obviously, there is some technical issue which cannot be solved from the user side, and since @epapadak was asking, I mentioned it.