DistanceDevelopment / spatial-workshops

Distance sampling workshop content
http://distancesampling.org/workshops/
2 stars 0 forks source link

Predictions on raster data #18

Closed dill closed 8 years ago

dill commented 8 years ago

As discussed in Woods Hole, the way to get predictions from data in a raster object is prety neat when only environmental (and not x and y) are included in the model, e.g.

predictorStack <- stack(c("Covariates_for_Study_Area/Depth.img", 
"Covariates_for_Study_Area/GLOB/CMC/CMC0.2deg/analysed_sst/2004/20040601-CMC-L4SSTfnd-GLOB-v02-fv02.0-CMC0.2deg-analysed_sst.img",
"Covariates_for_Study_Area/VGPM/Rasters/vgpm.2004153.hdf.gz.img"))
names(predictorStack) <- c("Depth","SST","NPP")
pp <- predict(predictorStack, model, const=data.frame(off.set=(10*1000)^2))

Which nicely passes the predictors onto predict.dsm and makes the predictions we want.

But when we need to use location as a predictor, we need to use interpolate:

pp <- interpolate(predictorStack, model, const=data.frame(off.set=(10*1000)^2), xyOnly=FALSE)

This is not very appealling from a teaching perspective, since we're going to be saying "interpolation is bad" and in general all other R models use a method called predict to make predictions.

An additional issue is that this won't work with dsm.var.gam and dsm.var.prop used to estimate prediction variance as they make calls to predict to get the $L_p$ matrix.

So, is it possible to create a generic "workflow" (graphical model) in ArcGIS that they can use to export the data to a CSV that they can then read into R?

jjrob commented 8 years ago

So the core problem here is that, after all, you want to have a data frame where each row corresponds to a raster cell, so that you can call your own predict functions / dsm.var.* rather than the raster library's predict or the more-inconveniently-named interpolate?

That is ok, but the best way to do this is not to have GIS export CSV files. Instead, you should use the raster library to read the data in its original format (the rasters, which are the proper storage structure in GIS for gridded data) and then produce a data frame from within R. The raster package has convenient methods for producing matrices, data frames, etc.

Sorry to keep pushing the raster package on you, but this is really the direction you should go if you want dsm / Distance to offer convenient means for producing density surface predictions from environmental data. If you want to punt on the whole thing and only accept data frames for now, that is ok, but R has moved beyond using CSV as an interchange format for gridded data. We'll look kind of lame if we push grids back and forth as CSVs.

dill commented 8 years ago

Okay, I agree. I should have looked at raster-based solutions first. Seems like this is actually trivial using raster::as.data.frame(..., xy=TRUE).

On 21/09/2015 15:23, Jason J Roberts wrote:

So the core problem here is that, after all, you want to have a data frame where each row corresponds to a raster cell, so that you can call your own predict functions / |dsm.var.*| rather than the raster library's |predict| or the more-inconveniently-named |interpolate|?

That is ok, but the best way to do this is not to have GIS export CSV files. Instead, you should use the raster library to read the data in its original format (the rasters, which are the proper storage structure in GIS for gridded data) and then produce a data frame from within R. The raster package has convenient methods for producing matrices, data frames, etc.

Sorry to keep pushing the raster package on you, but this is really the direction you should go if you want |dsm| / |Distance| to offer convenient means for producing density surface predictions from environmental data. If you want to punt on the whole thing and only accept data frames for now, that is ok, but R has moved beyond using CSV as an interchange format for gridded data. We'll look kind of lame if we push grids back and forth as CSVs.

— Reply to this email directly or view it on GitHub https://github.com/DistanceDevelopment/spatial-workshops/issues/18#issuecomment-142084429.