[gdal-dev] Mask value data type in Python wrappings

[Even Rouault]

Le jeudi 18 février 2016 17:20:14, Even Rouault a écrit :
> Dave,
> 
> > >>> band.SetNoDataValue(0)                     # Set the NODATA value to
> > >>> zero print "Nodata:", band.GetNoDataValue(),
> > >>> type(band.GetNoDataValue())
> > 
> > Nodata: 0.0 <type 'float’>
> > 
> > >>> mb = band.GetMaskBand()
> > >>> ma = mb.ReadAsArray()
> > >>> 
> > >>> 
> > >>> print "Origin:", ma[0, 0], type(ma[0, 0])  # *** SHOULD BE ZERO!!!
> > >>> ***
> 
> --> (Implicit) mask bands (such as the one generated for mask flag =
> GMF_ALL_VALID or GMF_NODATA), once fetched a first time, are no longer
> influenced by later actions. Re-opening the file should expose an updated
> mask band.

Looking at the code, I think that this could be fixed to behave as you'd expect 
with some refactoring : using an intermediate mask band class that would 
dynamically select the appropriate method, instead of returning directly a 
specialize instance of one of GDALNoDataValuesMaskBand / GDALNoDataMaskBand / 
GDALAllValidMaskBand

> 
> > Origin: 255 <type 'numpy.uint8'>
> > 
> > >>> print "(5, 5):", ma[5, 5], type(ma[5, 5])  # Correct
> > 
> > (5, 5): 255 <type 'numpy.uint8'>
> > 
> > >>> print np.any(ma==0)                        # Mask band is entirely
> > >>> 255
> > 
> > False
> > 
> > As you can see, the mask covers the entire image and not the zeros on the
> > edge.
> > 
> > The band.GetNoDataValue() is returning a Python float()
> 
> The C++ method always return a double, whatever the raster data type, hence
> the same for the Python bindings.
> 
> > which leads me to
> > suspect that there is incorrect type handling within GDAL’s Python
> > wrapping such that the mask generation is trying to compare the band’s
> > raster values (GDAL_UInt16) to whatever the NoDataValue type is stored
> > internally.
> 
> See my first explanation
> 
> Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com