Opened 9 years ago

Closed 8 years ago

#26592 closed New feature (fixed)

Add support for GDAL 2.1

Reported by: Daniel Wiesmann Owned by: nobody
Component: GIS Version: dev
Severity: Normal Keywords:
Cc: 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 Tim Graham)

GDAL 2.1 has been released a few days ago.

https://trac.osgeo.org/gdal/wiki/Release/2.1.0-News

The "delete-nodata" feature on GDALBand objects depends on this, see #26415.

https://github.com/django/django/pull/6350#issuecomment-202610506

Change History (10)

comment:1 by Daniel Wiesmann, 9 years ago

I am happy to work on this, but I am not sure what the process is.

comment:2 by Tim Graham, 9 years ago

Description: modified (diff)
Triage Stage: UnreviewedAccepted

Here's a sample commit from GDAL 1.10 support 3cea917e3e8a26b5b701c160f4f6e03b1b85cf84. If you have any other questions, please be more specific.

comment:3 by Claude Paroz <claude@…>, 9 years ago

In 72ff70f:

Made GDAL proj test less fragile

The WGS84 proj string can differ depending on installed libs.
Refs #26592.

comment:4 by Claude Paroz, 9 years ago

Here's the failing test I'm getting with GDAL 2.1:

FAIL: test_band_statistics_empty_band (gis_tests.gdal_tests.test_raster.GDALBandTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/claude/checkouts/django-git/tests/gis_tests/gdal_tests/test_raster.py", line 479, in test_band_statistics_empty_band
    self.assertEqual(rsmem.bands[0].statistics(), (None, None, None, None))
AssertionError: Tuples differ: (0.0, 0.0, 0.0, 0.0) != (None, None, None, None)

First differing element 0:
0.0
None

- (0.0, 0.0, 0.0, 0.0)
+ (None, None, None, None)

comment:5 by Daniel Wiesmann, 8 years ago

For empty bands, the statistics computation raises a GDALError. Before GDAL 2.1, the function returned null values. In 2.1 the input c_double values remain unchanged, so there is not way to know if the values are true values when the default is returned. Therefore try/except might be necessary. This is what is implemented in the current pull request.

An alternative would be to write a custom error-checking function in the gdal errcheck module for this case.

https://github.com/django/django/blob/master/django/contrib/gis/gdal/prototypes/errcheck.py

Please advise on what makes more sense architecture-wise.

comment:6 by Claude Paroz, 8 years ago

I'm fine with that approach!

comment:7 by Claude Paroz, 8 years ago

I've tested this, and I'm unfortunately still getting the test failure. It seems that no GDALException is raised with the empty band.

comment:8 by Daniel Wiesmann, 8 years ago

I had forgotten to re-activate error checking on the get_band_statistics function, it was only active on the compute_band_statistics. I changed that, seems ok now on jenkins.

comment:9 by Claude Paroz <claude@…>, 8 years ago

In 078eb876:

Refs #26592 -- Fixed band statistics for empty bands and GDAL 2.1

comment:10 by Claude Paroz <claude@…>, 8 years ago

Resolution: fixed
Status: newclosed

In ebaa2fef:

Fixed #26592 -- Confirmed support for GDAL 2.1

Thanks Daniel Wiesmann for the report and the appropriate fixes.

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