0

I am trying to read a tif in R. This tif has 4 columns in its attribute table as you can see in the image. However I am only interested in column 4 (WF) to plot and work in R. My problem is that when I call the raster in R, automatically it plots and works on the Value column (according to values of the scale bar). The dbf of this raster is also attached here. Do you know how can I do to specify the column WF I want to work in?

enter image description here

enter image description here

2
  • You can use the read.dbf in the foreign package to read the attribute table. The VALUE column will correspond with the values in your raster. Please read the help document for ratify in the raster package. This will allow you to associate the data.frame, resulting form read.dbf, to your raster data. A simpler approach is to just use the data.frame for query purposes and then associate the results to the raster at the code level. I rarely find it necessary to ratify my raster (only for plotting) to access attributes stored in a data.frame. Mar 3 '20 at 19:55
  • This post may help you understand working with raster attributes. gis.stackexchange.com/questions/347311/… Mar 3 '20 at 19:56
1

We can't see for sure that your data in R corresponds to your image, but if it does you probably want either of

## load just one band, the 3rd
library(raster)
r <- raster("myfile.tif", band = 3)

or

## load all bands, but select only the 3rd
r <- brick("myfile.tif")[[3]]

I'm assuming there's three bands, and by position WF is the third. The first column is the cell index (presumably) and is only implicit in the file and in this raster format.

EDIT: it's not clear from the OP that this is the case, it doesn't mention software or include any example files, but from comments looks like a loose connection between a DBF (simple database table file) and the values of the raster.

If so, read the DBF with read.dbf() and index it with the values of the raster:

## WARNING: untested
dd <- read.dbf("myfile.dbf")[raster::values(raster::raster("myfile.tif")), ] 

## to put the WF value (assuming there is one) onto the raster 
rr <- raster::setValues(raster::raster("myfile.tif"), dd$WF)

That last construct assumes there's no missing values and all indexes are sensible given nrow(dd). To really answer this needs a real world example to check this stuff.

5
  • Thank you for your answer, I am really new in R and I can't see the attribute table of this raster in R, can you help me with that? I was sure that the values shown in the R plot corresponded to the column of the image I showed because of the values of the scale bar, however to be sure I would like to know how to access to the attribute table. Mar 3 '20 at 13:59
  • @mdsumner I believe that the OP has a single band raster with an associated attribute table stored in a dbf. This would be a raster::ratify solution and they just do not understand how to work with this type of data in R. I see this issue often, particularly with data such as NLCD. The screen capture shows an attribute table associated with a single raster in ArcGIS. When exported to a tiff format the attribute table is stored as a dbf with the VALUE field corresponding to the raster values. Mar 3 '20 at 19:47
  • Then: dd <- read.dbf("myfile.dbf")[raster::values(raster::raster("myfile.tif")), ] ## (untested)
    – mdsumner
    Mar 3 '20 at 20:07
  • This would be assuming a 1-to-1 match between the number of cells and the number of rows in the dbf. It is doubtful that this is the case. Often nominal rasters indicate zones and the association would be number of unique values being the same as number of rows in the attribute table. To clarify, a dbf could plausibly have only four rows, indicating the four unique values in the associated raster. This is a standard ESRI convention with integer rasters and associated attribute tables. It is functionally a many-to-one relationship. Mar 3 '20 at 23:22
  • No it's the cell values, not their position. Or you are saying it's a join-task? If you have an example it would be better rather than this theoretical pseudocode and pure guesswork. I caveated with "untested" for precisely this reason.
    – mdsumner
    Mar 4 '20 at 1:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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