Force use of stated nodata value and float32 dtype in pollination
#1636
Conversation
There was a problem hiding this comment.
@phargogh the pollination changes make sense to me! In the parts of the model that expect that specific nodata value, I wonder if it might also make sense to instead read the nodata value from the raster properties? Rather than relying on the previously-set value.
There's also some changes in here in convert-requirements-to-conda-yml.py and urban_nature_access.py that may be unrelated?
The build issues I was experiencing had nothing to do with the contents of this file. RE:natcap#1635
…llination-inf-values-in-outputs
|
OK! I just pulled in the latest changes from |
…635-pollination-inf-values-in-outputs
…635-pollination-inf-values-in-outputs Conflicts: HISTORY.rst
…b.com:phargogh/invest into bugfix/1635-pollination-inf-values-in-outputs
|
@emlys yeah, that was my fault, I think I removed that line in a slightly botched merge conflict resolution! It should be all addressed now, pending your review and the builds passing. |
This PR updates all calls to
pygeoprocessing.raster_mapto use the pollination-defined nodata constant value, and also updates the dtype to force the output dtype to float32, resulting in smaller filesizes.Some parts of the model expected a specific nodata value, which meant that
raster_map's calculation of a reasonable nodata value was resulting in near-inf outputs in some rasters.Likely because of the use of convolutions in the pollination model (which create float64 rasters), most of the model outputs were also being created as float64 rasters, which probably isn't strictly necessary. This change just reverts back to float32 precision, which saves some disk space in the output workspace.
Fixes #1635
Checklist
- [ ] Updated the user's guide (if needed)- [ ] Tested the Workbench UI (if relevant)