Sentinel 1 preprocessing spatial resolution change

Hi,
I did sentinel 1 GRD preprocessing steps as follows:
1.Subset
2.Orbit file
3.Thermal noise removal
4.Speckle filtering (refined lee, 5*5 window size)
5.Calibration
6.Terrain Correction
But final product spatial resolution is 7 meters and not 10 meters ( Raw product is 10 meters spatial resolution). I want to know why it happens? If I want to keep the resolution as 10 meters which step should have been done differently?
Thank you

how exactly did you determine the spatial resolution? Can you please share a screenshot of the range doppler terrain correction operator?

Thank you for your reply. I calculated the distance with ‘range finder tool’ as you can see in the picture.


For Terrain correction I used the following configuration:

Please manually calibrate and then open the Range Doppler Terrain Correction operator with the calibrated image as.an.input for a test. It should then show you the actual resolution produces. Measuring is not the best choice, especially when you select WGS84 as target rference system.

Thank you. I did the calibration first and for terrain correction after that the operator measure the source resolution 10 * 10 meters. I am wondering what is the best way to check the resolution of the TC output? I can use snappy as well if it helps.

If this operater says it’s 10 m you can trust it. What makes you think it is different?

You can also select UTM as output coordinate system to get the image resolution in meters (instead of degrees) displayed in the band properites. I wonder why you create these processing graphs instead of directly calling the operators.

Thank you for your response. you are right I could just show you the operator. But since I am using graphs with gpt and I am used to making graphs and configure it from graph builder, So I naturally showed you the image on graph builder.
Bests,

all fine, I just wondered. But you can trust the 10m from the operator.

1 Like

Maybe related to this thread. Now, I want to stack S1 and S2 after preprocessing the products:
S1 Subset, Orbit file - Thermal noise removal, Speckle filtering, Calibration, Terrain Correction
S2 Subset bands, Resampling 10 meters, Subset region
Now I want to crop the images with shapefiles in the same region. But, the results of subsetting are not at the same size as you can see in the following pictures:
S1
S2
So I tried to co-register the images first, but I get following warning saying the the pixel spacing in the products are not the same ( which was my question in this thread).


it seems actually the S1 product pixel spacing seems to be 7 meters and not 10 meters. All the products are geocoded on WGS84, also my shapefile.
P.S: I looked at all the stacking S1 and S2 questions here , nothing was my answer.
P.S: Even without coregistration, subsetting is almost in the same place as you can see in the following image:
subset

what makes you think that?

Even if both datasets have 10 pixel spacing it is possible that their grids are not identical before the coregistration (this caused the blue message), and you need to resample the secondary image. But there is nothing wrong with that. After stacking, you can apply the shapefile to clip it.
You can also try the Collocation module instead of stacking, both do the same.

but if I ignore the warning at stacking. with this configuration:




The results would be written at the destination but when I want to open it the result is not shown. I get errors like this when I want to open any band from the final product:
error_ms

All fine with this configuration. The error is caused by something different. Please open the band properties of the S2 bands and remove whatever is written in the pixel value expression. Then save the product.

So, I did that. coregistration module takes lots of time to calculate and at the end I do not get error by opening the final product’s band. But all the pixels in bands are NAN. no information is written in any band. (I checked pixel values with pixel info, NAN for all the pixels).
But interestingly, collocate operator works fine and fast without any need for adjustment in S2 bands. I was thinking this two operators should act similarly. Do you know what would be the possible reason?
P.S: my problem probably solved by collocate operator . I am just wondering.
Thank you for your help

Coregistration it’s designed for radar products which were acquired from the same track (relative orbit). An empty result means that no matching patterns were found.
Stack and collocation are similar, but offer different settings. Especially when your data is geocoded and projected Collocation should be the best choice.

1 Like