COUNT field in raster attribute table

[johnpolo]

I had a vegetation raster that had several classifications that I wanted simplified. I used Reclass by ASCII and it appears to work. When I look at the attribute table of the new raster, the values in the Count field appear far less than what I was expecting. The sum for Count in the original raster is 1,956,736. The new raster has a sum of 19568. What does the Count field represent? Why is it so different between the two files? I realize this may be a basic question, but really, I have no idea what's going here.

[DarrenWiens2]

You probably noticed that 1956736 ~ 100 x 19568. Is your cell size the same between the two rasters, or perhaps 10x larger (10*10=100)?

To directly answer your question the COUNT column is the count of cells for each value. For slightly more information, see here.

[johnpolo]

Darren, I did notice the relationship. The spatial reference stayed the same, so the unit of measure stayed 1 m. The cell size stayed at 100 x 100. I looked at the visible and full extents and they are the same. Just visually assessing the rasters, they appear the same. I am kind of stumped what could have changed.

Thanks for the link. I was trying to find something like that, but got lost in the terminology.

You and Dan both took care of the main question, which confirmed what I was thinking about cells and their sizes. But now it begs a different question. If the cells are 100 x 100 m, or 1 ha, and there is a total of ~1,900,000 cells in the starting raster, doesn't that mean that the raster represents the same number of ha? That doesn't seem right, since the area of interest is not more than 25,000 ha.

Can Pixel Depth cause a difference? In the first raster it's 16 bit and in the reclassified raster, it's 8 bit. Is it possible that my ASCII table didn't actually reclassify all of the entries that I wanted it to, thus leaving those out? For example, I combined all tree types into one category for trees and there were 15 or 16 tree types. If it missed a bunch of those, that would seem to change the total number of cells. How would I verify the reclassify by ASCII worked properly?

[DanPatterson_Retired]

The count field represents the number of cells of a particular class.  The extent of the raster in cells, will give the total number of cells in the raster.  Since there is no count for nodata values, compare the counts of the cells that have data, the total count derived from the raster width and height and assess the difference.  Also, sometimes the count fields differ, if people aren't paying attention to raster functions/operations that produce new rasters.  You may have a particular raster then you do "X" with it and you end up with a new count for the same classes.  In such instances, either one or both of the cell size and/or the extent may have changed.  It is imperative that you pay attention to both the cell size and extent when working with raster functions that produce new rasters to ensure that you can compare the before to the after operation.  So re-examine what you did, see if the cell sizes or extents are different and whether one or both of the rasters have nodata values and whether more nodata values were produced during the operation.

[johnpolo]

Dan,

The spatial reference stayed the same, so the unit of measure stayed 1 m. The cell size stayed at 100 x 100. I looked at the number of rows and number of columns and visible and full extents and they are all the same. Just visually assessing the rasters, they appear the same. Both of the properties tab has a nodata value, but neither of the attribute table have any nodata rows.

Thanks a lot for explaining the cells. It was as I guessed.

You and Darren both seem to have gotten to the core of my question, but now I am curious about something else: If the cells are 100 x 100 m, or 1 ha, and there is a total of ~1,900,000 cells in the starting raster, doesn't that mean that the raster represents the same number of ha? That doesn't seem correct, the area I am working with isn't more than 25,000 ha.

Can Pixel Depth cause a difference? In the first raster it's 16 bit and in the reclassified raster, it's 8 bit. Is it possible that my ASCII table didn't actually reclassify all of the entries that I wanted it to, thus leaving those out? For example, I combined all tree types into one category for trees and there were 15 or 16 tree types. If it missed a bunch of those, that would seem to change the total number of cells. How would I verify the reclassify by ASCII worked properly?

[DanPatterson_Retired · Accepted solution]

there will be no nodata row in the table, you have to determine it from the extents.  Consider the following image.  I converted a 4 km x 4 km area of interest file using a cell size of 1 m^2, hence a cell count of 16,000,000 or 16 km^2.  You will notice I goofed, by not explicitly setting the output extent during the process (I goofed intentially btw).  This resulted in the number of rows and columns being waaayy bigger than the 4000 x 4000 that one would expect.  You will notice that there is no nodata row in the raster table.  Now if I had rotated that polygon and specified the extent to just that of the input extent of the polygon, I would still have issues with the product of the number of rows and columns not matching the area where there is data...that difference is the area of nodata.  Assess your situation in light of this.

[johnpolo]

Dan, thank you. I have looked at all of the information you mentioned and considered the values. Some of it still doesn't add up, but I did find a couple of areas needing attention and took care of them.

[GabrielUpchurch1]

Try the Build Raster Attribute Table tool with the "Overwrite" option disabled.  Raster attribute tables are not always updated after changes are made to the data so sometimes it is necessary to use this tool to obtain accurate COUNT values.  Here is the help resource for the tool:  Build Raster Attribute Table—Help | ArcGIS for Desktop

[johnpolo]

Thanks, Gabriel. I have been going through all the rasters I've been working with for this project and checking the tables. That tool has been useful a couple of times. Some of my rasters still don't make sense to me, but I think I've got most of it under control.