Nodata value not excluded when computing GDALBand min/max values

[Daniel Wiesmann]

The min and max properties of GDALBand objects only return the "true" min or max value when the underlying band has statistics calculated, otherwise they return the min/max of the datatype will be returned.

This is expected behavior of the gdal C function but should be different for the GDALBand properties. The property should return the true min/max.

​http://www.gdal.org/classGDALRasterBand.html#aaabf419931d0f505428f91cff54085cc

The propsed solution for this is to add the "GDALComputeRasterStatistics" function to the prototypes and use that instead of the "GDALGetRasterMinimum/Maximum" functions.

​http://www.gdal.org/gdal_8h.html#aa93b6b6ea6e71017ce25524e1a9ef1e3

[Daniel Wiesmann]

I made a pull request that fixes the problem, but I am not sure how this can be integrated in earlier versions because it adds one or two properties, maybe it has to be done differently.

[Tim Graham]

I'm not sure it's a critical fix that needs to be backported (however, I'm not a GIS user). See our ​Supported Versions policy.

[Daniel Wiesmann]

That's right, I agree that its probably not critical. An alternative simple way of "backporting" this would be to change the 1.8 documentation on the min/max attributes. The documentation could state that the methods might not return the true value if they are not already stored internally in the raster or in a metatdata file. However I am not sure if that would be good practice either.

[Tim Graham <timograham@…>]

In 8f59045:

Fixed #25734 -- Made GDALBand min and max properties use GDALComputeRasterStatistics.

Thanks Sergey Fedoseev and Tim Graham for the review.

[Baptiste Mispelon]

I'm getting a test failure on my local machine (Python 3.5.0, not sure what other versions would be relevant):

======================================================================
FAIL: test_band_data (gis_tests.gdal_tests.test_raster.GDALBandTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./django/tests/gis_tests/gdal_tests/test_raster.py", line 323, in test_band_data
    (0.0, 9.0, 2.842331288343558, 2.3965567248965356)
AssertionError: Tuples differ: (0.0, 9.0, 2.8423312883435643, 2.396556724896537) != (0.0, 9.0, 2.842331288343558, 2.3965567248965356)
 
First differing element 2:
2.8423312883435643
2.842331288343558
 
- (0.0, 9.0, 2.8423312883435643, 2.396556724896537)
?                           ^^^                  ^
 
+ (0.0, 9.0, 2.842331288343558, 2.3965567248965356)
?                           ^^                  ^^
 
 
----------------------------------------------------------------------
Ran 5 tests in 0.039s

[Daniel Wiesmann]

That could also be related to differences in GDAL, could you please also post the GDAL version you are using for me to reproduce the failure? Thanks.

[Tim Graham]

Baptiste, please provide:

>>> from django.contrib.gis.gdal import gdal_version
>>> gdal_version()

[Claude Paroz]

We might have to resort to variants of assertAlmostEqual here (AFAIK, the default assertAlmostEqual doesn't work on tuples).

[Daniel Wiesmann]

Made a pull request with a patch that hopefully solve the test failure due to small numerical differences like the one reported.

​https://github.com/django/django/pull/5763

I remain curious about the reason for the difference though, so if possible I would still be interested to get the GDAL version on the system with the failed test.

[Baptiste Mispelon]

My version of GDAL is 2.0.1.

The linked pull request fixes the broken test on my machine.

Thanks.

[Tim Graham]

I guess this is good to go unless you want to do any further investigate, Daniel?

[Daniel Wiesmann]

No that's fine, its good to go for me as well.

[Tim Graham <timograham@…>]

In 0e7d59d:

Refs #25734 -- Relaxed GDALRaster statistics test to use assertAlmostEqual.

Some versions of GDAL give slightly different results.