S1A-S1B coherence of partially overlapping images

Thank you for illustrating that Guido. I’m sure it will be handy soon enough.

Best

even if the images are from the same track I could imagine that the baseline is too large for interferometry. Did you have a look at it in the InsSAR Stack Overview tool?

Thanks for your answer.

I didn’t expect that to be an issue.

I’ve looked at the overview for a couple of pairs, here are the baselines:

S1A 23.09 0
S1B 29.09 101.56

S1A 18.08 0
S1B 24.08 -51.61

S1B 20.05 0
S1A 14.05 19.27

that’s totally within a reasonable range, even if 20m is quite small.

I found the issue to be the coregistration & stacking of the coherence with the backscatter bands of the individual products. Somehow SNAP doesn’t handle that well.

Same orbit track is same orbit track, it does not matter if it’s S1A or S1B.

I agree but woudn’t the baseline become too large if you stack images of same track but ongoing frame? Like it was shown here.

SAR is side-looking, the overlapping area was imaged when the satellite passed by it in both cases. Cutting the full data-take into slices or frames does not change this.

sure, but doesn’t the along-track baseline play a role?

The along-track baseline is effectively zero, as I tried to explain above. The bursts are aligned to start at the same position along the orbit at millisecond-level.

I guess I’ll have to do some reading :innocent:

sorry @Val - in this case forget about my concerns.

I appreciate the discussion, very informative.

I’ll give it some more shots.

Dears,

I would like to start from the original problem description.

The S-1 data are provided in slices. The slices don’t refer to an absolute reference like were the standard frames back to the ERS times.
Instead the slices are defined with respect to the start of the data-take (that can be several minutes long).
THus if S-1A/B data-takes are starting at the same position then the slices will be aligned. IF the S-1A (or B) starts earlier or later then misalignement will start.

This is however a separate issue than burst synchronisaton. The bursts are fully synchronised… always meaning that they they lie on-ground on teh exact same position.

The slices/products should be seen as burst containers. Dependend on the slice start the same burst might found on different slice. This means that several slices might be merged together in order retrieve the sequence of bursts needed.

Kind regards,
Nuno Miranda

1 Like

Hi @nuno.miranda,
Thank you for your explanation, I work on temporal analysis using firstly GRD, and now SLC. The off-timing of the slice start, specifically between 2016 and 2017 for some relative orbits has been a headache. But if I i understand you correctly, burst-ground alignment is more reliable, and i could use this insterad. Where do I find the burst alignment in the file metadata, and will i know if it runs over several slices?

My study area lies in the overlap between those two frames where one includes nearly half of the regularly temporally separated acquisitions from 14 July to 11 November 2016 while the other frame includes acquisitions from 29 November 2016 to 28 May 2017.

The InSAR Stack Overview showed those measures for perpendicular baseline (max was -144m) and automatically chose a reference image (even though I haven’t done coregisteration nor have I applied orbit file yet). Does this make any sense? If I can use this data set, how would I split the overlapping bursts from both frames during the automated pre-processing regarding that the bursts number will differ in both frames.

Shouldn’t they be selected based on the AOI coordinates in the snap2stamps config file automatically?

Yes. But I was afraid that the AOI bounding box might exceed this area of overlap because the latter is relatively small, and hence different non-overlapping bursts may be automatically split from both frames that won’t be coregisterable

The consequence would be to make the AOI smaller so that only these bursts are selected which are actually required.
But SNAP also coregisters data with different numbers of bursts, some remain empty if they are not covered by both inputs. Waste of processing time and data, but should still be possible.

1 Like

The AOI is only set by a bounding box which does not conform to the orientation of Sentinel-1’s burst, and the path of Sentinel-1 isn’t exactly traveling from south to north or vice versa. It’s oblique to the Earth’s perpendicular axis. therefore I cannot set a BBOX coordinates without sacrificing a big part of the burst that I already need. I do not know if I could explain my concern properly.

Can I rotate the BBOX like this in order to subset the most of the burst that includes my study area?

I understand - but this is something everyone of us has to deal with when working with Sentinel-1 data in StaMPS :slight_smile:
You simply make the coordinates of the AOI smaller so they are fully inside the desired burst.