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

Change History (4)

comment:1 by Jordi Castells, 9 days ago

Description: modified (diff)

comment:2 by Sarah Boyce, 8 days ago

Cc: Daniel Wiesmann Mariusz Felisiak added
Triage Stage: UnreviewedAccepted

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

comment:3 by Jacob Walls, 7 days ago

Owner: set to Jordi Castells
Status: newassigned

comment:4 by Jordi Castells, 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 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.

Note: See TracTickets for help on using tickets.
Back to Top