Hello,
I’ve been trying to estimate the coherence between a 6day S1A/B image pair. Unfortunately there’s only a slim sliver of those images actually overlapping as seen in this image:
So my question is if there’s a way in SNAP of estimating the coherence of the overlap and afterwards stacking it with the backscatter of the 2 S1 images (with an RGB being the ultimate goal).
Thank you.
Val
Are you sure that the acquisition ends/starts there? Perhaps there’s more overlapping data in the adjacent slices?
In any case S-1 single bursts are independent images and can be co-registered even without any adjacent bursts.
There’s one more slice on the top, but that doesn’t give me an additional overlap.
RE bursts, is there a way to subset down to the single burst? I’ve managed to get the coherence, but all area with no overlap is no data. With the nodata part, I didn’t manage to stack the three products.
I was hoping there’s a way to “crop” the image down to the overlapping area.
EDIT: Figured out how to get a single burst
This is unfortunately the case for many scenes, i.e. the S1B frame straddles 2 adjacent S1A frames of vice versa. Somehow, the frame bounds are not synchronized so that they more or less cover a similar geographical area.
I basically generate coherence for both combinations and then merge the result.
Guido,
thanks for your answer.
I’m not sure I understand correctly what you mean.
Here’s another image which shows how the slices are in this area:
So I’m actually only after the intersection area between A and B, here in yellow. Not sure what combinations there are.
Val,
Sorry, I misunderstood myself. Looks like the lower S1A is a truncated frame (probably end of orbit). In this case, I would just generate coherence for the sliver and combine with the geocoded GRDs for both S1A and S1B.
My situation is usually this (in this case the S1B covers my site, but 2 S1A’s are required)
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.
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 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
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?
