Collocating is not covering the same geographic area

snap
#1

Hi,

I have a question regarding collocating different datatypes in SNAP, and wondering if someone can help me in the right direction. In short, my collocated images aren’t covering the same geographical area.

-I have processed a Sentinel-1 GRD product (geo subset, thermal noise removal, calibration, terrain correction, converted to dB).
-I have a processed Sentinel-3 SL_1_RBT product(reprojected, band subset)

I have then tried to collocate my processed S3 image(slave) onto my processed S1 image(master) using the Nearest nabour method.

When I am doing this, I am “loosing” some of the S3 image, see images below:

In this image, we see the extend of the Sentinel-3 image:

s3_img
s3_img972×1032 319 KB

in the image below, we see that my Sentinel-1 subset(Product1) is clearly within the Sentinel-3 image. The problem is, that when I collocate S3 onto S1, the result is a smaller S3 image(Product 3) than my S1 image.

s3_collocate
s3_collocate1050×742 654 KB

I have tried to subsample my S3 image before collocating, but same problem arrises. Anyone know how I can collocate such that the images are covering the same geographic area?

Best,
Kristian

#2

are the Sentinel-3 data stored in the same coordinate reference sytem as S1 (the one selected during the Terrain Correction)?

#3

Hi,

They are both projected onto the WGS84 CRS.

For the S1 this was done using the Terrain correction step,
for the S3 this was done using the reproject step.

#4

just for clarification: The output after collocation is smaller than the S1 extent?
So none of the water areas in the east of the S1 images are contained in the collocated stack?

How does the collocated product look like in terms of pixel size and dimensions compared to the input S1 data?

#5

Yes. That is correct.

I have tried to do it once again. Same problem, see figure (product 6 is the S3, and product 7 is the S1)
s1s3_collocating

… considering the processing steps meantioned above, am I missing some other processing step??

Collocated master input:
S1 samples: 25488
S1 lines: 10226

Collocated output:
S3 samples:13316
S3 lines: 8085

best,
Kristian

#6

Hi Kristian,

somehow this problem sounds familiar to me. But I can’t find any reference, neither in the forum nor in our issue tracker.
I wonder if you have installed the latest updates?
Also could you tell the names of the products you use?
Then it would be possible to reproduce this issue.

Thanks

#7

Hi Marco,

I have installed the latest updates.

I have tried with several products (tho from the same source.). These are the names of the products I used for the first images:

S3:
S3A_SL_1_RBT____20180723T092851_20180723T093151_20180724T140918_0179_033_364_1980_LN2_O_NT_003
S1:
S1A_IW_GRDH_1SDV_20180723T051419_20180723T051444_022917_027C74_673F

#8

I tried it myself.
I couldn’t get the same S1 product from 2018. I’ve used one from 2019 instead.
S1B_IW_GRDH_1SDV_20190724T051343_20190724T051408_017271_0207BA_CADD
Also, I skipped some processing steps. I only did subset and terrain correction.

On the S3 product I did reprojection and subset.

The image shows the bounds of the two input products:
image

After collocating, which took 4-5 hours (this should speed up with the next release)
I got following results. Because of oblique and nadir view it might seam that data is missing.
Maybe you have been confused by this fact, as I was initially.
In the end all data is present. The S1 image not covered to higher latitudes because there is not more data in the SLSTR product in this region, despite the boundary says so.
The bluish data is nadir, the green is oblique and in the back the S1 data is visible.

image
image1554×1017 538 KB

Could you check which setting you have for SLSTR GeoCoding?
image
If it is enabled and you use the pixel-based geo-coding it might be worth to trie the tie-point based geo-coding.

1 Like