Add Sentinel-1 dataset

[adamjstewart]

I've never worked with Sentinel-1 or SAR data before, so I have a ton of questions. Maybe @isaaccorley can help?

1. The files have no CRS/transform, what's up with that?
2. How do I plot SAR data?

[isaaccorley]

1. That doesn't seem right. Where are you getting the data from? PC?

2. Normally the bands are plotted as a false color image. So you would make some combination of 3 bands like (VV, VH, ratio of VV/VH) and then plot it as if it's RGB. Of course this will likely be noisy since the data is typically heavily preprocessed.

[adamjstewart]

1. Data is from Copernicus, haven't looked at PC data yet

[adamjstewart]

2. There are 3 VV and 3 VH. What's the difference? Should I plot all 3 combos?

[adamjstewart]

I'm not sure if I'm the right person for this PR, I don't even know the difference between:

• S1A/S1B: I guess there's just 2 satellites
• SLC/GRD/OCN/RAW
• HH/VV/VH/HV/HH+HV/VV+VH
• SM/IW/EW/WV

[adamjstewart]

According to https://docs.terradue.com/geohazards-tep/tutorials/s1-grd-rgb-composite.html, we want GRD, not SLC, and we want VV (red), HH (green), and VV / VH (blue)

[adamjstewart]

According to https://sentinels.copernicus.eu/web/sentinel/user-guides/sentinel-1-sar/product-overview/polarimetry, we want VV (red), VH (green), and |VV| / |VH| (blue)

[RitwikGupta]

I'd recommend making two different classes: one for Sentinel-1 SLCs, and one for Sentinel-1 GRDs. Punt on the first one for now since that involves dealing with non-georeferenced (kind of), complex-valued data. GRD should be easy to integrate. Plot the VV/VH bands separately as 2x1 subplot.

[RitwikGupta]

@adamjstewart

S1A/S1B: I guess there's just 2 satellites

Yes. S1B is broken and will not be fixed. You'll only see S1A after Dec 2021.

SLC/GRD/OCN/RAW

SLC = single look, complex
GRD = ground range detected
OCN = ocean
RAW = literally raw radar data

We only care about GRD and SLC, in that order.

HH/VV/VH/HV/HH+HV/VV+VH

Just like how EO can be captured at different wavelengths, SAR is captured at various polarizations. The first letter tells us which polarization was transmitted, the second one tells us which polarization was received. HH = H transmit, H receive. HH+HV is just a literal sum.

SM/IW/EW/WV

These are different acquisition modes for the Sentinel-1 satellites. They trade-off capture area and resolution based on different desired characteristics. Regardless of mode, you'll still have SLC/GRD products (besides WV. That only has SLC and OCN).

[adamjstewart]

I downloaded S1A_IW_GRDH_1SDV_20221204T210847_20221204T210912_046187_0587AD_F19F.SAFE and S1A_IW_SLC__1SDV_20221006T133300_20221006T133327_045322_056B2B_84A7.SAFE but neither have a crs value when opened with rasterio. Is there something I'm missing? I'm just downloading random images from Copernicus in hopes of finding one that I can visualize.

[adamjstewart]

This seems relevant: https://gis.stackexchange.com/questions/233375/sentinel-1-data-opened-with-rasterio-has-no-affine-transform-crs

[adamjstewart]

Yep, these files use ground control points, not CRS. This is a fun hiccup.

[adamjstewart]

If anyone wants to follow along, the exact files I'm trying to use are https://scihub.copernicus.eu/dhus/odata/v1/Products('d3b5c561-ac0a-4617-a040-75708c0d28b8')/$value

Not sure if that URL will work for others though.

[adamjstewart]

Alright, found some decent image parameters! These are scenes over the big island of Hawai'i:

Happy to tweak these parameters if anyone has better suggestions.

[adamjstewart]

@RitwikGupta it would be good to get your review of this since you're the SAR expert (at least among us). We can always expand this in future PRs, especially if you're focusing on better ML for SAR!

[RitwikGupta]

The limitations on what kinds of files can be in one Dataset instance are currently wrong.

I don't think there's any reason why we need to limit the kinds of bands available within the dataset at a time. Also, we need to be mindful that cross polarization is reciprocal.

We need to limit that a dataset can either be $\gamma_0$ or $\beta_0$, and image scales need to be normalized to one choice, power by default.

[RitwikGupta]

Why are these not just set(["HH", "HV"]) and set(["VV", "VH"])?

[adamjstewart]

For our MSI datasets, we want to be able to optionally select a subset of bands (RGB-only, RGB+NIR, etc.). I was following the same approach here, but I'm not actually sure if that makes sense for SAR. Is there any reason why someone might want to only use a single band and not both? If not, I can simplify the code quite a bit.

[RitwikGupta]

Why not? Is this limitation solely for plotting purposes? It is totally valid for multiple passes over the same area to be of different polarizations. It's also valid for consecutive captures from the satellite to be of different transmit/receive pairings. Additionally, the intensities for VH and HV are equal due to Helmholtz reciprocity!

[adamjstewart]

This limitation is inherent in our current RasterDataset implementation. Basically, every GeoDataset has an R-tree index containing a single filename for each spatiotemporal location. We populate this R-tree during __init__ using a filename glob, which has to contain a single band name (can't be both HH and VV). Then, during __getitem__, we loop over all bands and swap the band in the filename to load the data. If all bands aren't present for every spatiotemporal location, then loading will fail. This was designed for MSI and HSI imagery without any thought towards (or knowledge of) SAR data.

There are a few options to deal with this:

1. Leave it up to the user

This is our current approach. The user can create two datasets and compute the union themselves.

Pro: simple
Con: users may have to do extra work

2. Compute the union for them

We could subclass UnionDataset instead of RasterDataset and create two RasterDatasets for the user. This is actually a very elegant solution and shouldn't be that difficult.

Pro: users don't have to do any extra work
Con: it would not be possible to change bands. You could create a dataset containing all 4 bands, but it would not be possible to create a dataset with only 2 bands

I assume horizontal transmit and vertical transmit are fundamentally different and some users may want to work with only one or the other but not both? This would not be possible with this idea. A workaround to support this would be to create 3 datasets:

• Sentinel1Horizontal: [HH, HV]: RasterDataset
• Sentinel1Vertical: [VV, VH]: RasterData
• Sentinel1: [HH, HV, VV, VH]: UnionDataset

3. Override __init__ and __getitem__ in Sentinel1

We could replace the default logic for populating the R-tree and loading the data to search for both HH and VV and to load [HH, HV] and [VV, VH].

Pro: would support 4 bands or 2 bands
Con: mostly duplicate code, more difficult to maintain, need to do this for every bi-pole SAR instrument

4. Modify RasterDataset to support optional bands

Instead of populating the R-tree with a single band for each spatiotemporal location, we could load all bands we can find. Then, at loading time, we only load the bands that were found.

Pro: supports both SAR as well as MSI/HSI where the user might not have downloaded all bands but forgot to change bands
Con: significantly slower since R-tree lookup will go from $\mathcal{O}(\log N)$ to $\mathcal{O}(\log CN)$ and memory will go from $\mathcal{O}(N)$ to $\mathcal{O}(CN)$ for all datasets. Even slower would be loading and grabbing the CRS and bounding box of every file from disk. Also, if some downloads have different numbers of bands, this will break when loading data. Easy fix for this would be to specify a subset of bands when instantiating the dataset, but the error message would not be clear and this may be difficult to figure out for an inexperienced user

Let me know how you feel about 1–4. I'm leaning towards 1 or 2. I'm hesitant to go with 3 because duplicate code == evil, and 4 would require a separate PR and longer discussion.

[calebrob6]

I prefer 1 -- until we have someone who is actively using SAR imagery with TorchGeo let's not spend too much time making this class perfect

[RitwikGupta]

Is there any reason to plot these images as RGB? The case to plot RGB images is rare as the third band ratio choice is extremely dependent on application. Why not just present an Nx1 subplot with all bands plotted in grayscale?

[adamjstewart]

Because RGB looks cooler 😄

Seriously though, I only went with RGB cuz that's how we plot MSI datasets. When I view thumbnails of these images on Copernicus, they also choose to display an RGB image. What other third band ratio choices are common? We could add an option to select one or the other when plotting. Of course, users can always implement their own plotting code, this is just supposed to be a reasonable default.

[RitwikGupta]

I'm not tied to displaying an image one way or another, but if it makes the code easier, then displaying N grayscale bands would be infinitely easier than dealing with all these combinations/ratios for RGB imagery.