django.contrib.gis.GDALRaster support for vsi filesystems

[Jordi Castells]

The GDAL library has out of the box support for different kinds of virtual filesystems (directly accessing data on ZIP, or networked filesystems).

​https://gdal.org/user/virtual_file_systems.html

Those specific filesystems are enabled with a string prefix to the path sent to GDAL when instantiating a new raster.

django.contrib.gis.GDALRaster does not support any of this special cases since it forces any string to either be an in memory gdal vsi path (strating with /vsimem) or an existing path in the filesystem.

So for example, gdal will happily open /vsizip//tmp/raster.zip but django.contrib.gis.GDALRaster will refuse to do so even though the underlying library supports it.

There are other specific cases that might benefit from it, for example a Cloud Optimized GeoTiff (COG) stored in an S3 file service. To read that raster into Django one has to download it first to the filesystem (or memory) and then pass it to GDALRaster beating the purpose of the COG in S3, while a /vsis3 path can instantiate that COG file and just retrieve the data as needed thus reducing network usage.

This could probably be a whole other discussion here on how to treat those kind of files in a less "gdaly" way (for example with specific django.contrib.gis.GDALRaster driver option, similar to the current driver=MEM). But a first straightforward step that would open those functionalities to djangogis is simply to let those /vsi* paths through instead of failing.

[Mariusz Felisiak]

​PR

[Mariusz Felisiak <felisiak.mariusz@…>]

In 205c36b5:

Fixed #32670 -- Allowed GDALRasters to use any GDAL virtual filesystem.