I recently obtained precipitation normals from the PRISM dataset online. I'm trying to import the ASCII files into ArcMap, but have stumbled across a few issues.
- I converted the ASCII to raster. I did it first as float, then as integer.
- The two rasters (float vs integer) had identical values, except the float raster values went to the hundredth decimal place, while the integer raster was just whole numbers. Not a problem; the ASCII is floating point anyway.
My problem then comes in with the attribute table. The float raster does not have an attribute table, while the integer raster does.
Can someone help me understand why the float raster didn't create an attribute table, and how I can build one?
My GIS knowledge is rather limited. I'm using ArcMap 10.2.
Best Answer
The idea behind integer rasters is that the value(s) are associated with some finite discrete entity. Processes such as soil, landcover or binary processes are well represented as integer rasters. The attribute table is intended to be associated with group of pixels associated with a discrete value. This is why the attributes contain value and count fields. Additionally, these pixel aggregates (classes) can be associated with additional attributes (eg., soil type associated with texture).
A floating point raster is intended to represent continuous processes such as elevation. Floating point rasters do not have attribute tables because you would have to have an attribute entry (row) for every unique value, which buys you nothing and would necessitate storing the values twice. This does not mean that they do not have values associated with the raster, just that the values are not aggregated into a table.
One exception with integer rasters is that sometimes you have a continuous process that is stored as integer values (climate, elevation). In this instance you would define output as an integer raster because the resulting raster would be notably smaller and the decimal point values would be useless. However, even in this case sometimes it is desirable to store whole numbers as floating point. On example where storing integer as float is that some of the models associated with deriving metrics from elevation data assume a floating point input and yield undesirable results with the input is integer. This is because the data is forced into integer during processing where the results should be float. This truncating of values during application of operators (i.e., division) results in bias in the results.
In your case you should certainly be importing the data as floating point. You do not have a need for an attribute table. Any operations you perform on the raster would just be on the float values stored in the raster and not on an attribute table.