I came across an S1 pair which I was looking to combine for the purpose of interferometry and it is strange that their footprints are exactly the same when viewed in the quicklook footprint window before downloading the image but once opened in SNAP they look something like this,
I am now wondering will it be possible to employ these pairs for InSAR processing with such a skewed overlap and the second question is why are they even looking skewed in the Worldview window when they are supposed to be exactly overlapping?
They indeed are from the same path, however I am concerned about the overlap which is not exact. The datasets are a year apart and I checked the overlap with some recent datasets that exactly matches with each other but I would essentially like to look at the possible displacement over a longer period.
Like you mentioned if the datasets are from the same track we can go ahead with the interferometric processing. In that case can I follow the steps mentioned in the following clip,
If both images have the same track number and slice number, you could follow the processing chains are mentioned within the video, also it’s worth mentioning to take a look at
Thanks @falahfakhri, this means that if the images are not exactly overlapping we only choose the bursts which are common to both the images. What is even more interesting to me is that even though the images are displaced, the bursts pretty much (or rather exactly ) cover the same area.
In case the both track no. and slice, are not match each other as explained in the post I mentioned also the datatset of @ABraun within the post explanation, it’s not possible to match the bursts from both images, because they’re basically have high shift.
I’m afraid it’s not the case, because simply you could choose different slice no. and track, but both frames visually are shifted, in this scenario case the TopSAR-Corr. will gives an error.
The selection of the burst sequence to be combined from the individual scenes (say burst 1 to 8 from image 1 and 2 to 9 from image 2) will be a manual process or does SNAP helps in the selection of the burst sequences.
Which DEM did you select of auto-download DEM’s, Does it SRTM 3 sec? in this case switch to the SRTM 1sec, IF you get same error, Be sure the DEM covers your AOI.
In case you didn’t get any solution of above, then, Would you please to share the identifier names of the both products!
Concerning your steps, after TOPSAR-Deburst, add up Goldenstein Phase Filtering
and then Multilooking.
The question rather is why TOPS Split has to be performed for every S1 image, even if all three swaths are required. Is it simply a matter of reducing the data size or maybe it has radiometric reasons.
The help of the TOPS Merge operator says:
“With the current toolbox, most operators in the TOPS InSAR processing chain operate on split product.”
To me that sounds like it is not entirely necessary but was initially designed to so. But maybe one of the developers can clarify.
By now, you have to split each swath and coregister them separately before you can use Back Geocoding on the result.
) cover the same area.
