Raster datasets that contain attribute tables typically have cell values that represent or define a class, group, category, or membership. For example, a satellite image may have undergone a classification analysis to create a raster dataset that defines land uses. Some of the classes in the land-use classification may be forestland, wetland, cropland, and urban. The numbers below could represent which cell value in the raster dataset would define the land use:
1 Forestland
2 Wetland
3 Cropland
4 Urban
By building a raster attribute table, you can maintain this table's attribute information with this classified raster dataset as well as define additional fields to be stored in it. For example, there may be specific codes associated with those classes or further descriptions of what those classes represent. You might also want to perform calculations on the information in the table. For example, you might want to keep records of the total area represented by those classes by calculating the number of cells multiplied by the area each cell represents. You can also join the raster attribute table to other tables.
The graphic below illustrates a raster dataset with attribute table. You can see that the NoData values are not calculated in the raster attribute table. You can also see the three columns that are calculated by default; the other columns can be added individually or by using a join operation.
Learn about adding and deleting fields in a table
When a raster attribute table is generated, there are three default fields created in the table: OID, VALUE, and COUNT. It is not possible to edit the content in these fields. The ObjectID (OID) is a unique, system-defined, object identifier number for each row in the table. VALUE is a list of each unique cell value in the raster datasets (in a grid, this is an integer). COUNT represents the number of cells in the raster dataset with the cell value in the VALUE column. Cell values represented by NoData are not calculated in the raster attribute table.
Learn more about ObjectID fields in tables
Outside a geodatabase, for a file-based raster dataset, the raster attribute table is saved in the same folder or at the same directory level as the raster, using the same name as the raster and appending a .vat.dbf extension. For example, for raster SanDiego.tif, the raster attribute table will be SanDiego.tif.vat.dbf. Within a geodatabase, the raster attribute table is saved within the raster dataset and hidden from the user. Within a grid, the raster attribute table is saved as a vat.sdf file inside the grid folder.
For grids, a raster attribute table is built by default for any integer grid that results from an expression if the range of values in the raster is less than 100,000 or if the number of unique values in the raster is fewer than 500. If the range is less than 100,000, the number of unique values in the raster can be as large as 100,000. If the range is greater than 100,000, a raster attribute table will still be built if the number of unique values is fewer than 500. If the range of values is greater than 100,000 and the number of unique values is greater than 500, a raster attribute table is not automatically built.
By default, the size of a raster attribute table is limited to 65,535 unique values. You can increase this number on the Options dialog box by clicking the Raster Attribute Table tab on the Raster tab.
If you make a copy of a raster dataset with a raster attribute table, the raster attribute table will be maintained in the copied raster dataset. Therefore, if you copy a grid containing an attribute table, it will be copied to the new raster dataset, such as an .img file.
You can work with raster attribute tables similarly to regular tables, such as previewing them in ArcCatalog and editing them in ArcMap. You can join other tables to them, calculate fields, sort fields, and export them.
Raster attribute table for raster datasets in a raster catalog
Each raster dataset in a raster catalog can have its own attribute table. The method of storage is simple and easy to manage; however, you could end up with many tables in the database, some of which may be identical (for example, if raster datasets in the catalog have the same attributes).
