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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
