id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
32670	django.contrib.gis.GDALRaster support for vsi filesystems	Jordi Castells	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."	New feature	closed	GIS	4.0	Normal	fixed	raster	Daniel Wiesmann	Ready for checkin	1	0	0	0	0	0