Zonal Statistics SUM pixels excluded

[IvanLucena1]

I got administrative maps level 1 shapefile from GADM [gad,.org] and Agriculture production Geotiffs from SPAM [mapspam.info] and run Zonal Statistics as Table SUM

The picture shows that for region VEN.15_1 the calculate sum is much smaller than the value in the indicated pixel, which centroid is within the region.

That problem repeats throughout the whole world producing results that differ from other tools that does include pixels like this one.

Is there are parameter that need to changed in order for the tool to change the behavior.

Thanks for any suggestion.

[DavidPike]

I'd make sure that everything is in the same projection initially.  I'm guessing that's not a stretched pixel value (It looks like the unstretched value - I only ask because i'm not that familiar with Pro tbh).

You're probably going to have a lot of edge effects since your pixels are very large relative to the zones (I believe the pixel is only counted if its centre intersects the zone) but that's not the issue obviously.

[DanPatterson]

check the input shapefile to see if it is a multipart shape.  Run MultipartToSinglepart on it if it is

[SarmisthaChatterjee]

Hi Ivan,

I am looking at your post, and I would like to know more about it before I try to explain the result.

Can you please let me know:

• What version of the software you are using?
• What is the cell size of the value raster?
• Are you executing the tool with a default environment or specifying anything such as extent, cell size, snap raster or output coordinate system, or a combination?

If you are interested to share the data with me for further investigation, let me know. I look forward to your response.

Thanks,

Sarmistha

[IvanLucena1]

Hi Sarmistha,

1 - I am using ArcPro 2.6.3

2 - Raster cell size is 0.083333 x 0.083333 

3 - No. I didn't change any environment option because I wanted to compare what would be the results without other software that do it with default parameters.

3.A - After posting this screenshot I tried some other options. I reduced the cell size in half and I also tried to rasterize the feature layer and use it as the input zona data. The results were not good.

The data is freely available and it shouldn't take much time to get it.

The GADM Level 1 (States/Provinces administrative borders) can be downloaded as Shapefile from gadm.org/download_world.html

Using the link "shapefiles" after "download this version as six separate layers" and 

The Level 1 layer have the file name "gadm36_1.shp"

For the raster value file, I am using is the SPAM Palm Oil global production map from 2010.

It can be downloaded from mapspam.info/data/

Search for "SPAM 2010 v2.0 Global Data (Updated 2020-07-15)" and "Production" Geotiff

The Palm Oil Geotiff goes file name is "spam2010V2r0_global_P_OILP_A.tif"

Thank you so very much and my regards to the team.

Ivan

[SarmisthaChatterjee · Accepted solution]

Hi Ivan,

Thank you for the data and the details. I used your data in Zonal Statistics as Table with zone field = GID_1, and statistics type = Sum, and by keeping the Geoprocessing environment default, and got the correct output in ArcGIS Pro 2.6.3.

However, if I change the cell size or the snap raster, the output will be different as expected due to the resampling happening with the values in the value raster during the zonal analysis.

We need to make sure that you are using the default environment. Please send me all the parameters that you have used in the Zonal Statistics as Table tool, and the environment values of cell size, output coordinate system, extent and snap raster, so that I can investigate further.

Thank you,

Sarmistha

[IvanLucena1]

Hi Sarmistha,

I think it all comes down to my interpretation of  what "ignore NoData in calculations" means.

I unchecked that parameter thinking "I don't want the tool to ignore the existence of the NoData tag in that GeoTiff and I certainly don't want the values to be part of the computation".

But that is the complete opposite meaning. It might by my programmer's bias or I might be have been influenced by other software. Sorry. 

Since the NoData in that case is -1 and there is a lot of it in that area, the result might have been diminished because of it. If leave it as checked I get the same result as you.  

Thank you for your time,

Ivan