Add the EnviroAtlas dataset

[calebrob6]

Adds one of the datasets used in https://openreview.net/forum?id=AEa_UepnMDX

[calebrob6]

Note my data.py is a very rough stab at something that can digest patches/tiles from the original dataset and replace them with fake data. I think a better way to do this would be to save a JSON file or something that had pairs of (filename in the dataset, the current metadata I have pasted in the script).

[calebrob6]

[calebrob6]

[adamjstewart]

This dataset has the same problems as ChesapeakeCVPR. If we find a way to improve sampling speed for RasterDataset, these datasets won't benefit. Also, I'm not sure if these datasets can be combined with any other GeoDataset, which violates a lot of the fundamental assumptions we make about GeoDataset instances and nullifies the whole point of using GeoDataset instead of VisionDataset. I'm fine with merging this as is because we already have a similarly broken dataset in TorchGeo, but we need to seriously consider how to handle these kinds of datasets in the future.

[calebrob6]

If we find a way to improve sampling speed for RasterDataset, these datasets won't benefit.

This dataset extends GeoDataset, not RasterDataset, so this much is obvious. Whether it should extend RasterDataset is a different question all together.

Also, I'm not sure if these datasets can be combined with any other GeoDataset

Why not? Does it not correctly extend GeoDataset? If there are some assumptions that GeoDataset is making then we need to enforce them.

similarly broken dataset

Do you have anything else in mind besides the above points?

[adamjstewart]

Why not? Does it not correctly extend GeoDataset? If there are some assumptions that GeoDataset is making then we need to enforce them.

If I'm reading things correctly, this dataset doesn't doesn't warp things into a common CRS, correct? This is incompatible with other GeoDatasets. GeoDataset makes the assumption that the index and the data returned by __getitem__ are in a single CRS. If we need to change that in GeoDataset, we can, but it requires a lot of thought (what to do when bbox in different CRS overlap).

[adamjstewart]

Inconsistencies between GeoDataset and ChesapeakeCVPR/EnviroAtlas and refactoring so that RasterDataset code can be shared with these datasets can be done in a follow-up PR, I vote we merge this if everything else looks good.

[calebrob6]

The index is in a single CRS (EPSG:3857), but the problem is that __getitem__ will return imagery from the warped extent of a query bounding box in EPSG:3857. E.g. you query with a square bounding box, this bounding box will be warped into some off-axis rectangle (in the CRS of some tile in the dataset -- not EPSG:3857), then the rectangular bounding box of that will be used to get data.

The assumption that this (and ChesapeakeCVPR) breaks is that __getitem__ should return data warped to the CRS of the dataset. It would be relatively simple to change these datasets to follow that (although it would slow down sampling).

[calebrob6]

Any thoughts on how to clean up data.py / do it differently (or do we not care too much about those)?

[adamjstewart]

I'm not worried about data.py at the moment. Once we have more examples we could try to standardize things, but since it isn't installed with the library I don't want to be very strict about it.