Sentinel 1 input spec and retrieval

[lillythomas]

For sentinel 1, we've decided to source the 20 meter RTC product (VV and VH), filtering out scenes where only one of the two polarizations are available.

@weiji14 has started this work in #17

[weiji14]

Just to clarify, the Sentinel-1 product we're refering to are those captured using Interferometric Swath Mode (IW) at a resolution of 5 x 20m (yes, rectangular). After lots of processing, the Sentinel-1 Radiometrically Terrain Corrected (RTC) product at https://planetarycomputer.microsoft.com/dataset/sentinel-1-rtc has an effective Ground Sampling Distance (GSD) of about 20m. Specifically:

• Range Resolution: 20m (across track or perpendicular to the sensor antenna direction)
• Azimuth Resolution: 22m (along track of the sensor antenna)

But the data is actually provided at a pixel resolution of 10m by Planetary Computer. I think we decided to stick today to stick to this 10m resolution product, rather than resampling back to 20m, because it's not really recommended to resample Polarimetric SAR data using bilinear or nearest neighbour (since there's speckle noise).

[weiji14]

One more thing, since @srmsoumya is working on the datacube branch. Sentinel-1 SAR data is collected off-nadir (specifically, right-pointing) at an incidence angle of 29.1° - 46.0°, so ascending and descending passes will look different.

Imagine that you're flying in a plane, and always sit on the right-side window seat. The view you get of a mountain range will look different depending on whether you're flying North or South, and this is the same with Sentinel-1.

So for the example that was shown over Portugal, with the orange box being the Sentinel-2 MGRS tile, and green boxes being Sentinel-1.

Two of the green tiles would represent the ascending pass, and the other two would be the descending pass. We'll need to be careful when building the datacube to merge these carefully. It's ok to mosaic two ascending passes for example, but don't combine or take the average of an ascending and descending pass together.

We could also debate on whether to add the ascending/descending pass information as an encoding to the embedding 🙂

[weiji14]

Closing as implemented in #27, feel free to comment further or reopen if we want to modify the data specification further.

[weiji14]

Originally posted by @MaxLenormand in #200

Why use the RTC Sentinel 1 product? I see from the MPC docs that it uses the PlanetDEM product, which according to this is from the ALOS World 3D-30m + NASADEM. I hadn't compared this one to Copernicus DEM before but there might be difference in the two (ALOS is SAR, and Cop DEM is a downsampled version of Airbus's WorldDEM made from TerraSAR-X if I recall correctly, so there would at least be some similarities). This might lead to some inconsistency between the SAR corrected imagery & the DEM used? That being said I also understand this is probably a lot faster to implement with an off-the-shelf SAR dataset :D

You are correct @MaxLenormand that Microsoft Planetary Computer's Sentinel-1 RTC product which is derived from ALOS (L-band) data is different to the TerraSAR-X (X-band) derived Copernicus DEM. L-band being a longer wavelength than X-band, would measure a more bare-earth surface compared to X-band that measures more canopy-level heights. The main reason we went with MPC's Sentinel-1 RTC product is because we the Radiometric Terrain Correction processing is computationally expensive to do (it can take hours for one Sentinel-1 scene), and Copernicus DEM is 30m, so we wouldn't even be able to do the RTC processing to 20m globally ourselves, having no access to PlanetDEM. Off-the shelf is more practical in this sense.

[MaxLenormand]

I figured that was probably the reason, thanks for taking the time to answer!