Opened 9 days ago
Last modified 5 days ago
#36196 assigned New feature
django.contrib.gis.GDALRaster support for driver configuration options
Reported by: | Jordi Castells | Owned by: | Jordi Castells |
---|---|---|---|
Component: | GIS | Version: | 5.1 |
Severity: | Normal | Keywords: | |
Cc: | Jordi Castells, Daniel Wiesmann, Mariusz Felisiak | Triage Stage: | Accepted |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
Some raster files will refuse to open when using newer versions of GDAL (for example 3.8).
GDAL behaves as expected, although it is not always as desired. It brought to my attention that there is no support for driver specific open options when calling contrib.gis.GDALRaster
There is driver option support via papsz_options
when creating GDALRaster from scratch (https://docs.djangoproject.com/en/5.1/ref/contrib/gis/gdal/#creating-rasters-from-data) but not when opening an existing raster file (https://docs.djangoproject.com/en/5.1/ref/contrib/gis/gdal/#gdalraster).
The example that I can come up now is opening a COG
directly with contrib.gis.GDALRaster
and requiring the option IGNORE_COG_LAYOUT_BREAK
, but I imagine that other drivers would benefit from this capability.
.. note: I can prepare this patch myself but first I would like opinion from the maintainers :-)
Change History (4)
comment:1 by , 9 days ago
Description: | modified (diff) |
---|
comment:2 by , 8 days ago
Cc: | added |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:3 by , 7 days ago
Owner: | set to |
---|---|
Status: | new → assigned |
comment:4 by , 5 days ago
I see some possible inconsistencies rising from this:
GDALRaster(ds_input, mode)
My first instinct was to extend this to be more akin to a GDAL OpenEx
-> GdalRaster(ds_input, mode, papsz_open_options=None)
But, ds_input
can be one of the following
string
-> Assume apathbytes
-> Assume in memory rasterdict
-> Definition to create a raster from scratch
We already have possibility to pass papsz_options
to the ds_input
when it is a dict
.
So that would clash with my original intent.
I think what makes more sense is to remove that dict["papsz_open_options"]
and all calls to GDALRaster
could use the different open options available. Open an existing raster file could provide extra open options, and creating a raster from scratch could provide the current dict + pass some extra information via the optional parameter. Although that would mean breaking the current use of creating a new raster
.
We could also go with the two options (dict["papsz_*"]
and optional papsz_*
parameter) but that could make creating rasters from scratch more confusing since there are two places where to define papsz
and only one right one.
This sounds reasonable to me and so tentatively accepting
I don't have much experience in this space and so cc-ing some folks in case they have opinions