-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nodata count includes non-overlapping cells #105
Comments
i would track each type and then let the user decide how they are returned. group them by default with an option to return them separately |
Implementation is a little trickier than expected, deferring this to the 0.12 milestone |
looks like the non overlapping areas get lumped into nodata due to the the boundless options ( this seems to be when it was introduced for arrays, rasters were probably earlier |
this might work: if the user wants no_overlap count returned, they need to provide a second, unused "fake" nodata value. this value is passed to rasterio as the raster's nodata value which results in the true nodata value being treated as just another value. we then have distinct values for no_overlap vs nodata and just need to update our mask accordingly in the case when the user does not request the no_overlap field, it just behaves exactly as it currently does should be able to tweak the boundless_array func to do the same thing for np arrays |
PR #146 adds 'nan' stat option |
rasterio issue on shapes extending beyond raster extent |
@perrygeo almost done with a no overlap stat proof of concept that works with array rasters. but i think there may be some limitations to getting it working with rasters opened via rasterio |
Mine shapefile polygon is not snapped with raster when i run zonal_stats results are not exactly matching with Arc GIS result. I am using Python 3.7 and pygeoprocessing 1.5. |
For each feature, there are three types of cells: data, nodata, and non-overlapping. Nodata and non-overlapping get lumped together in the
nodata
statistic.Was this always the case? Was the bug introduced in an attempt to optimize?
The text was updated successfully, but these errors were encountered: