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
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:
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:
or these 2:
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.
Thanks for the suggestion, that could indeed be the problem. How can I check if the bursts are NOT synchronized between the 2 passes?
Bursts are always synchronised but perhaps SNAP is picking the wrong ones(?).
I agree with @mengdahl - that is the likely cause