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.

  1. I converted the ASCII to raster. I did it first as float, then as integer.
  2. 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.

1 Answer 1


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.

  • Thanks for the detailed answer; I appreciate it. I inherited some old GIS files, and then created new files for the current decade. The old precipitation raster DID have an attribute table associated with it (and had integer pixel type), so I assumed there should be an attribute table with the new raster I created. It makes sense why there isn't.
    – KKL234
    Commented May 28, 2015 at 15:56
  • If you are planning on analyzing the historic data with the current data, I would highly recommended coercing the historic data to floating point. The rule is that if float and integer rasters are analyzed together the output will be integer. Commented May 28, 2015 at 16:05
  • So I just ran into an issue with using just the float raster. I need to calculate zonal statistics (Tabulate Area) on the raster, but I can only do so with an integer raster. Any thoughts on how to work around this?
    – KKL234
    Commented May 28, 2015 at 20:13
  • I do not understand why you would need to calculate area on a continuous process. If you had say, categorized precipitation (low, med, high) this would make scene. Using zonal statistics, you would be interested in the distributional moments of the process (eg., min, max, mean, sdtv). Please put some serious though into your analysis and modeling objectives and how your data processing will support your objectives. Then take a look at any associated statistical assumptions to make sure that your specified analysis is correct. Commented May 28, 2015 at 20:41
  • This may lead into a new question. I used the precipitation (float raster), slope, and hillshade raster to build a logit model, and then created a new raster (call it Logit Probabilities for example). I'd like to figure out the number of pixels in the Logit layer in each of my probability ranges (0-10%, 10-20%, etc.). That is what I tried to calculate using zonal stats. If there's another tool I'm not aware of, or if my assumptions are incorrect, I'd like to fix them, but as of right now I'm not sure where/if I made an error.
    – KKL234
    Commented May 29, 2015 at 11:14

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.