Add Radiant MLHub (REF) Cloud Cover Dataset

[KennSmithDS]

This PR adds the Cloud Cover Detection Challenge dataset which was generated as part of a crowdsourcing competition as hosted on the Radiant MLHub.

Dataset features:

• Sentinel-2 L2A (RGB and NIR bands only)
• 22,728 chips in the training dataset, and 10,980 chips in the test dataset
• Chips represent imagery between 2018 and 2020
• GeoTiff labels represent binary classification if a pixel is labelled as a cloud or not

To Dos:

• Resolve linter errors
• Create new sample data with data.py script

[calebrob6]

Thanks for the contribution @KennSmithDS! I took a pass at reviewing. Other comments:

• Good example for a data.py script I think: https://github.com/microsoft/torchgeo/blob/main/tests/data/agb_live_woody_density/data.py.
• Can you post an example output of the plot function?
• It looks like there are a few lines that aren't covered by the tests, can you look into these?

[adamjstewart]

Still needs a data.py script to generate the fake data. It also looks like some of the tests are failing. You'll need to rebase/merge on top of main to run some of the new required tests. Let me know if I can help with any of this.

[KennSmithDS]

@adamjstewart @calebrob6 thank you for the feedback and recommendations. I've rebased/merged the latest release with my local branch, and fixed the failing tests, as well as implemented the suggestions above. The only thing I still have questions on is the data.py script.

Is this requirement for contributing documented anywhere in the repository? I've been looking at a few different examples to get a sense for what it does, e.g. agb_live_woody_density, naip, and baywide datasets. Each have their own flavor, but the common workflow I see is defining the profile information of a raster file to be written using rasterio. Questions this raises for me are:

• Is it required to use the long form WKT string for the profile["crs"] attribute or can you simply pass in the simpler versions, e.g. CRS.from_epsg(4326) or CRS.from_string("EPSG:4326")?
• Is it necessary/recommended to use a colormap for the geotiffs written to disk?
• Should there be a min/max value for the random values generated for the rasterio dataset writer class output? The above examples in the repo just create a random image np array of any dtype value
• I'm also doing things in a slightly different way with this Dataset to load information from the actual STAC catalog, e.g. collection.json and stac.json so is it necessary to create a GeoJSON file (FeatureCollection) like with agb_live_woody_density?

Thanks again!

[adamjstewart]

Is this requirement for contributing documented anywhere in the repository?

The fact that it's needed is documented at https://torchgeo.readthedocs.io/en/latest/user/contributing.html#datasets. Some tips for writing the script can be found at https://github.com/microsoft/torchgeo/blob/main/tests/data/README.md

For all of your other questions, the answer is that you should try to match the real data from your dataset.

• If your dataset contains raster images with geospatial metadata, you should create fake data using rasterio. If your dataset contains PNG or JPEG images with no geospatial metadata, you should create fake data using PIL.
• For raster datasets, you should use the same CRS and dtype as the real files.
• The random values can range from the min/max value of that dtype, which can be computed using np.iinfo(dtype).min and np.iinfo(dtype).max (or np.ffinfo for float dtypes).
• If your dataset contains labels with a colormap, your fake data should to.

Hope that answers your questions!

[KennSmithDS]

@adamjstewart I had missed the README file nestled under tests/data/README.md so thanks for pointing that out!

[KennSmithDS]

@adamjstewart I'm assuming the answer to this question is yes, but to clarify, should the data.py script also generate the collection.json and stac.json files used by the method I added _load_collections()

[adamjstewart]

Yep! At some point I'm planning to convert these data.py files to pytest fixtures to generate all of our data at test time instead of storing it in the repo. So if the data.py generates those files too that would help a lot.

[adamjstewart]

Thanks for the data.py, that looks like it wasn't easy to write!

Did a more detailed pass through the code and listed mostly minor things to change. I think this is pretty close to completion! Will likely have one last pass once these comments are addressed.

[adamjstewart]

Rebased to fix coverage. Just need to see an example plot and this should be ready to merge.

[KennSmithDS]

@adamjstewart sorry for delay, we've had some high priority projects past 1-2 weeks that have required my attention.

1. Do you have an example of what the plot should look like, or will this do?

2. Is there a standard pixel value normalization for Sentinel 2?

I just modified a single line of code in the .plot(...) method to divide the pixel values by 3000, which is arbitrary but also used in BeninSmallHolderCashews, another MLHub NonGeoDataset which has the added numpy dimension for time series in the data. The np.clip(..) method is also used while normalizing the S2 pixel values.

I'll have to push 1 more commit with the slight modification to the .plot(...) method after I hear back from you. Cheers!

[adamjstewart]

1. Plot looks good, just wanted to make sure the image and label aren't flipped or something like that. You'd be surprised how often that happens.
2. No preference on normalization constant. I used 2000 for Sentinel2 because 3000 made the image a bit too dark. I don't know of a more rigorous way to define how Sentinel imagery should be visualized. You would think there would be an "official" way to plot a true color image...