S1 Pair Skewed Footprint

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?

Are both images from the same track (requirement for interferometry to work)?

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

S-1 dataset selections

Source of the post

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 :thinking:) 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 assume in the following case the conditions of Slice & Track (Relative Orbit) numbers are completely obeyed,

However, the selection of bursts still remains a manual process by visual inspection of features. Please correct me if I am wrong.

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.

I meant that an image pair having the same track and slice number if not exactly overlapping like the following case,

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.

Yes, this case it’s not possible to corr. same burst no. form both images, it should be,

I am receiving an error while building a graph that says,

Error: [NodeId: Back-Geocoding] Split product is expected

I am wondering why can’t I process the full scene at once without splitting the sub-swaths or the bursts. Here is my flow,

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.

I don’t think this relates to the problem.

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.

Source: Coregistrating more than two Sentinel-1 SLC IW products

Yes, this comment is out of the problem and causes the error, I only suggested to add up these two operators to the processing chains.

To me I think the entire two images within the three swaths should be processed at once I agree with

your point, But might be, I guess the corr. backgeocoding isn’t design to corr. the whole swaths of both images!.