1

I am looking at forest loss in Central and South America within protected and unprotected areas. So I have a binary raster (0 or 1) for forest in 2000 and another raster for forest in 2013. I want to use Zonal Statistics as Table to look at forest loss in each country in protected and unprotected areas (which I have a polygon shapefile for). However, Zonal Stats as Table fails saying it couldn't build attribute table.

When I try to use the Build Raster Attribute Table tool it fails and gives the following error: "Error 000049: Failed to build attribute table." Clicking on the error it says that the rasters need to be integer and single band. But both of my rasters are in GRID format and are single-band, unsigned integer (8 bit).

When I tried clipping the rasters (~500-600MB) into smaller pieces, one for Central America (CA) and one for South America (SA), then the attribute table was automatically built for CA (~60MB), but not SA (~300MB). With the attribute table for CA, I was able to complete my analysis with Zonal Stats as Table. Unfortunately, the Build Raster Attribute Table still fails for the clipped SA raster.

I figured that maybe the raster is still too big, so I clipped the SA raster into two pieces (133MB and 174MB), however the tool still fails on both. I could keep clipping the raster until it is small enough, but that is extremely annoying and inconvenient for the rest of my analysis. Am I doing something wrong with Building the attribute table? There aren't really many options in the tool besides input raster and then overwrite or not (I've tried both ways, doesn't matter).

I've tried turning off Background Geoprocessing, removed and re-added the rasters, tried restarting ArcGIS, and the computer, but same result. Could this be a problem with ArcMap 10.3? I could have sworn that I've dealt with larger rasters than 600MB before in earlier versions, and it was slow but still worked.

Improve this question
5
  • ArcGIS GRID format is either 32-integer of 32-bit float; there is no 1-bit, 8-bit, or 16-bit integer representation (though obviously 32-bit could store those values well compressed).
    – Vince
    Commented Jun 8, 2015 at 20:23
  • When I look at the properties of the raster in ArcGIS it says 8-bit, and says file type is GRID with RLE compression. Also, I didn't change anything for the Central America clipped raster, and it didn't have a problem creating an attribute table.
    – Peter Olsoy
    Commented Jun 8, 2015 at 21:34
  • The values for RAT are long integer (signed), do you have more than 2 billion of one cell value? Is it possible that you're overflowing the numeric type?
    – Michael Stimson
    Commented Jun 8, 2015 at 23:09
  • @MichaelMiles-Stimson - yes, the raster is 235523 x 169987, which gives about 40 billion cells of which there are only 3 options: 0, 1, NoData. It is quite likely that both 0 and 1 have over 2 billion cells. The raster that did build the RAT has 1.45 billion 0 values and 0.77 billion 1 values. So you are saying that the RAT is signed int and can't handle >2 billion?
    – Peter Olsoy
    Commented Jun 9, 2015 at 14:13
  • Yes. Every numeric type has a limit and 2 billion is the limit for this numeric type stackoverflow.com/questions/94591/…
    – Michael Stimson
    Commented Jun 9, 2015 at 21:48

3 Answers 3

Reset to default
3

The problem with building a raster attribute table (RAT) has to do with the format used to store the values. RAT files are stored as .dbf files that support a maximum of 32 bit integers which has a higher limit of 2,147,483,647. If there is a cell value with a count that exceeds this number the RAT cannot be built.

There is no workaround.. Esri only supports integer field types of short int (16 bit) and long int (32 bit) which means Cell Counts cannot exceed 2 billion in any individual raster. If you need this functionality please submit an improvement request with Esri international.

You might be able to tile the raster, build RAT on the tiles and then build a mosaic dataset/VRT with attributes (don't trust count).

Improve this answer
1
  • I think you are correct for GRID type, but I was able to export it as a TIF and create the RAT on that. Each raster is around 40GB (instead of 400MB), but Zonal Statistics now works.
    – Peter Olsoy
    Commented Jun 10, 2015 at 22:38
1

This is a shot in the dark, but I have encountered lots of problems with processing GRID rasters in ArcMap. Whenever I do raster processing, I generally convert to .tif, which seems to be a much more stable format.

Improve this answer
4
  • Do you have any ideas on what compression to use? Uncompressed .tif for the raster is over 37GB. I'm trying RLE right now, which is what the GRID raster was compressed as.
    – Peter Olsoy
    Commented Jun 8, 2015 at 21:33
  • Personally, I don't like compressing raster files. I would recommend working with smaller initial "chunks."
    – Chris Strother
    Commented Jun 9, 2015 at 13:56
  • It didn't compress and ended up being 39GB. However, the RAT did build, though, and shows 6.99 billion with a cell value of 0 and 8.63 billion with a cell value of 1. I'll check to see if Zonal Stats accepts it. If not, I might have to break it up into smaller chunks as you suggest.
    – Peter Olsoy
    Commented Jun 9, 2015 at 14:15
  • @PeterOlsoy did this work for you?
    – sparky
    Commented Mar 1, 2019 at 22:57
0

Ran into this error while running Zonal Histogram. The raster was a subset of a national raster that had thousands of values.

I created a new raster of dominant classes (called combo) using raster calculator (i.e. "raster" == 1234; con(("ne1234" < 1),"ne1234",1234); sum new dominant sub rasters). Zonal Histogram still didn't work.

I reran "raster" == 1234 (which produced values of 0 and 1) and Zonal Histogram worked. So I reclassified combo's unique values to a range of 0 (minor classes) to 16... and Zonal Histogram worked. However...

I reclassified the original raster of ~81 values and Zonal Histogram completed. The output table had all the zones and counts for each zone BUT... there wasn't a column of corresponding raster IDs and there were too many records (256 rows of data). After eliminating all the records filled with zeroes... there were too few rows of data (75 records). ArcGIS let me join the output table to the original raster... but the system joined the raster to the first ~81 records of the output table.

Hope this provides clues to the core issue.

Improve this answer
1
  • Welcome to GIS SE. This answer doesn't really pertain to the question; you're using an entirely different tool to the one asked about, and you don't mention whether or not your input is "large".
    – alphabetasoup
    Commented Oct 1, 2016 at 1:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.