Add CanadianBuildingFootprints dataset

[adamjstewart]

Closes #3

[calebrob6]

Added a notebook showing that the constructor takes 3 minutes and the __getitem__ method takes 1 minute for a moderately sized query. This may be unavoidable with GeoJSON files, but, as-is, this will not be directly useable for training models.

@adamjstewart, can you try converting the inputs to shapefile or geopackage and see if that helps?

[adamjstewart]

Let me see if I can get conda to play nicely so I can actually run a notebook in AML.

[calebrob6]

If you want to iterate quickly you can just use the same query:

bounds = BoundingBox(-79.69096183776855,-79.68220710754395,43.78839898848133,43.79482711775757,0,1)

which is in Ontario.geojson

[adamjstewart]

Good news! Things seem to be a lot faster with ESRI Shapefile.

GeoJSON

$ ipython
In [1]: from torchgeo.datasets import BoundingBox, CanadianBuildingFootprints as CBF
In [2]: bounds = BoundingBox(-79.69096183776855,-79.68220710754395,43.78839898848133,43.79482711775757,0,1)
In [3]: %time ds = CBF('/mnt/blobfuse/adam-scratch/cbf')
CPU times: user 3min 27s, sys: 1.68 s, total: 3min 29s
Wall time: 3min 38s
In [4]: %time ds[bounds]
CPU times: user 1min 7s, sys: 508 ms, total: 1min 7s
Wall time: 1min 9s

ESRI Shapefile

$ ipython
In [1]: from torchgeo.datasets import BoundingBox, CanadianBuildingFootprints as CBF
In [2]: bounds = BoundingBox(-79.69096183776855,-79.68220710754395,43.78839898848133,43.79482711775757,0,1)
In [3]: %time ds = CBF('/mnt/blobfuse/adam-scratch/cbf-shp')
CPU times: user 203 ms, sys: 68.9 ms, total: 272 ms
Wall time: 9.47 s
In [4]: %time ds[bounds]
CPU times: user 1.28 s, sys: 456 ms, total: 1.74 s
Wall time: 1.74 s

This raises the question of how we want to support arbitrary file formats. Right now, things are hard-coded to search for *.geojson files. We could make this search for any file, but directories tend to contain many file types (*.zip, *.shp, *.dbf, etc.). We could search for all files, try to open with fiona/rasterio, and catch any exceptions.

We should also do some benchmarking for different file types and add that to the paper.

[calebrob6]

I think the reason that shapefiles (or geopackages) will be fast is because they will have internal spatial indices. I don't think we should try to support geojson files as it will cause the same problems.

[adamjstewart]

Ideally, I would like to allow users to download their own data and transform it in any way. This includes:

• Changing file format
• Changing projection/transform
• Changing resolution (for rasters)

We can certainly recommend certain file formats like COGs or Shapefiles for speed, or even issue warnings when users are using file formats with slow random access.

For now, let's merge as is. When I do a RasterDataset/VectorDataset refactor, we can allow them to work with any file extension.