Select to view content in your preferred language

ERROR 010423 on Reclassify of Raster Dataset only with installed SP1 and SP2

8400
14
07-24-2011 09:15 AM
MartinBernhardt
New Contributor
Hello,

i am using Arc GIS 10 and i have the following problem:
When i start the tool "Reclassify" with a Raster DataSet i get the error massage :"ERROR 010423[...]does not have valid statistics as required by the operation."
So i tried to fix it with "calculat Statistics" for the Raster Dataset. But even after doing this, i got the same Error
I use Reclassify inside a modell and i know that it worked before i installed Service Pack 1 and 2 so i tried to remove the two servicepacks and now the Reclassify works.
I think its a bug in SP 1 because i first removed SP2 and tested , with no succes und than i removed SP1 and the failure was gone.
0 Kudos
14 Replies
GerardBourke
Emerging Contributor
Thanks Jeff, I'll keep that in mind the next time I do this 🙂

On the 010423 Error though, after I'd read this post and went back to work and I changed up my method.  Instead of stopping once I got the error, I split up the remaining polygons and forced them through in multiple batches, processing the largest of the left-overs first and then the smaller ones.. this time with no error.

This is different from before where if they were too small, the process would carry on and simply not return the results (what you were saying, Jeff).  If you encountered the error it wouldn't process at all, but by splitting them up they would all go through eventually with no error. 

Why would it decide that it couldn't calculate the statistics for a group of polygons but it will for multiple smaller groups of the same polygons?

I'm working with a 25m cell size (which has been checked and rechecked for missing values) and it is failing on polygons up to ~1700m2, where it is working fine on 10,000's of other polygons of the same size and smaller.. so I think there is still something to the process failing if it has to 'share' a cell... will test further
0 Kudos
JeffreySwain
Esri Regular Contributor
Did you ever convert your data to a raster and look at where it put the pixels?  I would process that and then look at the problematic errors.  It should explain what the tool is doing when considering the zones.
0 Kudos
GerardBourke
Emerging Contributor
So I converted my polygon layer into a raster, set the cell sizes to be the same as the raster I want stats from (25m).  Then I converted that back into polygons to run zonal stats to see what was going on.

The first run I did when reconverting back to polygons I allowed it to simplify the polygons, thinking I'd get more 'organic' shapes and maybe a but closer to the original.  Ran zonal stats and again was coming back with a bunch of empty fields.  Typically they were all small, which was expected, some a bit smaller than the raster cell size (because they were simplified).  Even so, many of these undersized ones could still be calculated.  Flicking through them I noticed that many of the unsuccessful ones were 'sharing' cells and mustn't have had the largest portion compared to their neighbour.  However, there were cases where they weren't sharing cells or were even little islands away from other polygons, some just would not calculate.

I did this again but this time I unchecked the simplify polygon box to see if that made a difference.  This essentially halved the failure rate, but still had some left overs, same as before.  Only this time, since no polygon could be smaller than a cell, even the smallest polygons had to be over greater portion of a cell (except in cases where it would be perfectly aligned over four cells, but that would be very rare).

When I tried to run zonal stats with the left overs (as I had done successfully many times with my orginal shapefiles), it would not run - error 10423.  Tried trimming the groups, still nothing.

So, why is it breaking?  If you have a square over a grid with cells the same size as your square, unless the corners are perfectly aligned with the centres of each cell, you must have a greater portion of one of the cells and the centroid of a cell within the boundary of your square.  So how is it deciding which cells to include?

Definately, very small polygons won't work, but I still think cell sharing can explain part of it.  Perhaps the order they are done?  I can't see one though, failed cases can appear at random; it doesn't matter if the neighbour cells are left, right, up, down or before or after their object ID number.  I can't see a pattern.  Even so, that doesn't explain the failed cases where there are no neighbours.

So I conclude that I can't work it out and am going to get back to work now 🙂
JeffreySwain
Esri Regular Contributor
When you converted it, did you use the snap raster environment setting to align the pixels?  Or make it match the extent of the raster via the Output Extent?  From what it sounds like, pixel registration is causing issues. Since you are choosing to match the cell size, I would complete it and then use the snap raster and processing extent.
0 Kudos
GerardBourke
Emerging Contributor
Yeah, tried that.  Snap to raster isn't working (I've seen your comment one of those troubleshooting forums too, Jeff).  Turned off background processing, tried doing it in ArcCatalogue, it just won't snap.  Keeps coming out the same... of course that's another problem for another forum... Though apparently that one's been fixed? hmmm...
0 Kudos