handle numpy dtypes for scalar values such as in SetNoDataValue() #330
Description
As noted in natcap/invest#992, GDAL does not consider numpy Float32/Float64 objects as valid doubles. And that can lead to exceptions like this:
File "natcap\invest\coastal_vulnerability.py", line 2216, in warp_and_mask_bathymetry
File "pygeoprocessing\geoprocessing.py", line 426, in raster_calculator
File "osgeo\gdal.py", line 3847, in SetNoDataValue
TypeError: in method 'Band_SetNoDataValue', argument 2 of type 'double'
I think it would be nice for pygeoprocessing to handle this instead of forcing the user to remember the details of GDAL and its C implementation. pygeoprocessing encourages users to pair it with numpy in all sorts of ways, so I think we can do a bit better here.
There are a few places where we already handle this in pygeoprocessing. There are 5 instances of calling SetNoDataValue and a few different ways of handling things.
raster_calculator:
value is passed as-is from a function argument
new_raster_from_base: (I propose adopting this solution for all the rest)
uses item() to return a Python scalar representation https://numpy.org/doc/stable/reference/generated/numpy.ndarray.item.html
try:
target_band.SetNoDataValue(nodata_value.item())
except AttributeError:
target_band.SetNoDataValue(nodata_value)
create_raster_from_bounding_box:
always does band.SetNoDataValue(float(target_nodata)) regardless of the target datatype for the raster
convolve_2d:
value is passed as-is from a function argument unless it is None, then casts to Python float, regardless of target datatype.
numpy_array_to_raster:
value is passed as-is from a function argument
Are there any other cases of numpy Float types being rejected by GDAL, besides SetNoDataValue() that we should consider?