Spatial Analyst - Zonal Statistics error related to 9.3 SP 1?

4594
6
04-22-2010 07:45 AM
JanOtto
New Contributor
Hi,
I have the following problem using Zonal Statistics in SA, 9.3 SP1:
When calculating zonal statistics for a polygon, the resulting table misses some values. Consequently the joined tables (zone dataset and output table) do not match and some field are populated with <Null>.
I have used an simple numbering (1-8400) for the zone field, but some number in the output table are left out.

The problem is especially annoying, because I use this function in a GIS course that I teach. I prepared the exercise on my laptop using the single use license of Arc GIS desktop 9.3 without service pack (SP) 1. However during the course at Uni and on my office computer this error occurs. So, I believe that this has to do with SP1.
Did anyone come across this issue as well?
I feel pretty bad as a teacher, with these things occurring in my courses.
Any help is gratefully appreciated!
Jan
0 Kudos
6 Replies
JanOtto
New Contributor
I have to correct my observations.
The problems also occurs on ArcGIS 9.3 without SP1.
However, as the occurence of missing fields in the table is completely random, I did not notice them before.
Now I have recalculated the zonal statistics 5 times, getting different missing values each time.

Could there be a limit for the zonal stats?
I have more than 8000 features and use a raster of 20x20m. The number of missing values is between 500 and 650...

Cheers,
Jan
0 Kudos
DanPatterson_Retired
MVP Emeritus
As Bill has suggested, this and other issues have been discussed in the past.  Many of the solutions are the result of not specifying a working directory/source directory that doesn't contain spaces etc, grid names which exceed 13 characters and/or begin with a number.  If you comply with these and set your analysis properties in ArcToolbox or with the SA toolbar options explicitly, then many of the errors "go away".  SA has not been updated to reflect newer programming environments in a number of years (ie numeric precision of floating point grids) so the user has to be cautious.  Good luck
0 Kudos
CedricWannaz
New Contributor II
I agree with Bill about small polygons that are "not rasterized sufficiently precisely".

I just had this problem an hour ago. I have a multi-scale grid and I want to compute the flow of a wind field (I have rasters of components) through the edges of grid cells. I am using zonal stat. based on a polygon feature class made of buffers around each edge. When these buffers become comparable in size with pixels of the rasters of wind field components, I have missing entries in the output of the zonal stat.

It is not the first time that it happens to me, and my explanation has always been (don't know if it is correct though): when the zone input data is a feature class, the zonal statistics tool converts the feature class into a raster (polygons are I guess somehow "rounded" to the closest set of pixels). Then it certainly performs a significant amount of raster-raster operations. When (zonal-) polygons are of comparable size as pixels of the input raster, the rounding is first inaccurate and ultimately even cancelling polygons.

It seems to me that pixels of the raster generated by conversion of the polygon feature class are not exactly similar in size as pixels of the input raster though. I performed a test by copying some features that were skipped by the zonal stat. into a new feature class. When I used this reduced feature class as a zone input data, zonal stat. worked well. So my guess is that the pixel size when converting the zone input data into a raster is based on both the input raster and the extent of the zone input data.

To end this "story", my wind field components rasters are obtained by Kriging interpolation from a point feature class (coming from another model). When I observe that the output of the zonal stat. is smaller than the zonal feature class, I reduce the output cell size of my interpolation (until the size of the output of zonal stat. matches the feature class).

Best regards,

Cedric
0 Kudos
CedricWannaz
New Contributor II
Thank you for the information, Bill ! Does ArcGIS Desktop (toolbox, geoprocessor) handle Kriging with output in regions defined as polygon feature class or raster? Actually I am going to start a new thread with this, because it would solve a lot of issues on my side. I will update this post with a link as soon as it is created => http://forums.arcgis.com/threads/3321-Geostatistical-Analyst-Kriging-with-output-in-regions-defined-...

""I wrote a Python method (attached) in the last hour (see below) just to test an idea. It was written too fast, there is no error control, but I attached it in case someone is interested. Its purpose is to complete the zonal stat. output table with rough estimates for missing zones. For using it, you just have to create a class that has a property named "gp" that is the geoprocessor (or you can transform this method into a basic function). The rest is similar to the ZonalStatisticsAsTable().

Don't use this method actually. What it is doing is taking missing polygon's centroids, extracting values to points at these centroids locations, and merging the output with the zonal stat. output. I programmed it just because I didn't know the tool "Extract Values to Points" mentioned by Bill below.

Best regards,

Cedric
0 Kudos
JanOtto
New Contributor
Dear All,
thank you for your valuable comments and the background information on the zonal tool.
I have played around with the hints on the cell size you gave, Cedric and Bill, and this really seems to be one solution. In my case I can reduce the number of missing features quite substantially, using a cell size of 2 m (in the options dialogue). Smaller cell size does not work and returns a "Error in opening VAT". Probably a memory problem.
The conversion into raster did not make much difference, but allowed to reduce the cell size to 1m and the number of failures to just a few. A result I can live with.
I did not try to split the data, but this will certainly remove the errors.

The working directory settings did not make any influence on the calculation.


Many Thanks and best regards,
Jan
0 Kudos
robertcolombo
New Contributor
the sad thing is that ArcView3.2 is giving the exact result when doing a summarize by zone (ak in Arcgis9.3 as Zonal statistics ...or extract values to pints...
sad but true...now..can we believe the ArcGIS results? what happens in emergency sistuations , during preparedness....
0 Kudos