Back geocoding producing empty stripes in slave product

In one and only one of the 3 sub-swaths, i.e. sub-swath 1, the image S1B_IW_SLC__1SDV_20191017T205036_20191017T205104_018520_022E57_724A (used as either master or slave) leads to a slave product that contains empty stripes.

I tested back geocoding it in combination with
S1A_IW_SLC__1SDV_20191011T205131_20191011T205159_029416_035879_2222

Does this happen every time you run Back Geocoding on this sub-swath?
You could slightly change some of the parameters.
Do all sub-swaths look alright before this step?

Back geocoding works perfectly well in SNAP when using these 2 inputs:
S1A_IW_SLC__1SDV_20190929T205131_20190929T205159_029241_035277_6F56
and
S1A_IW_SLC__1SDV_20191011T205131_20191011T205159_029416_035879_2222
which have a longer temporal baseline

I am using these parameters

The sub-swaths looks ok before back-geocoding: is there a way to check for specific issues?

Sorry I was confused earlier. Both 6- and 12-day pairs can be from the same track. Have you opened the bands of the problematic product to see if they are filled with data normally?

please give it another try with SRTM 1Sec

I tried with SRTM 1sec and the stripes are still there in the slave product

Does the secondary image have full bands in it? Or is the data missing already in the beginning.

The inputs seem to be both ok


I encountered the same problem when trying back geocoding with these 2 images:

S1A_IW_SLC__1SDV_20191006T204258_20191006T204325_029343_0355EA_0238
S1B_IW_SLC__1SDV_20191012T204154_20191012T204223_018447_022C0C_FFF7

or these 2:

S1A_IW_SLC__1SDV_20191006T204258_20191006T204325_029343_0355EA_0238
S1B_IW_SLC__1SDV_20191012T204221_20191012T204249_018447_022C0C_9351H

In 2 of the 3 sub-swaths, i.e. sub-swath 2 and 3, the image taken on date 20191012 (used as either master or slave) leads to a slave product that contains empty stripes.

Actually, as you can see in the image below, I first assemble subswath 2 of the two images taken on date 20191012 (the e are needed to cover the area of the image taken 6 days before) and then do back geocoding with the image on 20191006. The same for subswath 3. And now I am wondering if I might do something wrong in the step that assemble the 2 subswaths.

I work for WASDI and we have a client who is looking for a product map based on these images. Is there any support that ESA can give us, perhaps in reproducing our steps?

Can some one help us please?
We really need to understand what happens…

This looks like the wrong bursts are possibly being paired together for some part of the swath. The mapping of corresponding bursts between reference scene and secondary scene seems to be changing by 1 - and you are essentially seeing burst overlap regions.

1 Like

Thanks for the suggestion, that could indeed be the problem. How can I check if the bursts are NOT synchronized between the 2 passes?
https://sentinels.copernicus.eu/web/sentinel/user-guides/sentinel-1-sar/acquisition-modes/interferometric-wide-swath

Bursts are always synchronised but perhaps SNAP is picking the wrong ones(?).

I agree with @mengdahl - that is the likely cause