django.contrib.gis.GDALRaster support for driver configuration options

[Jordi Castells]

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 :-)

[Sarah Boyce]

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

[Jordi Castells]

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 apath
• bytes -> Assume in memory raster
• dict -> 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.