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

Dave Welch dwelch at urthecast.com
Thu Feb 18 09:52:45 PST 2016


Thanks for the help!  

When you mention refactoring, that was in regards to GDAL not my script, yes?  (Remember, GDAL n00b here…)
______________________________________________
Dave Welch Software Engineer
URTHECAST




On 2/18/16, 10:32 AM, "gdal-dev on behalf of Even Rouault" <gdal-dev-bounces at lists.osgeo.org on behalf of even.rouault at spatialys.com> wrote:

>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 at lists.osgeo.org
>http://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4493 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160218/596e71ef/attachment-0001.bin>


More information about the gdal-dev mailing list