Sf: [Request] support for raster operations

[kendonB]

Does Team sfr plan to also overhaul the raster package? That package has a lot of good features, but there is likely value in having a common interface for all spatial objects that center around data.frames or lists of data.frames.

extract, for example, might go something like this:

Suppose extract(raster_brick, MULTIPOLYGON_list, weights = TRUE) returns a list of data.frames (or tibbles if tibble is loaded) each of which contains a column of extracted values from the RasterBrick (named value), and a column of weights (adding to 1) representing area overlap (named weight).

Then if mp is an sf with a MULTIPOLYGON column named geometry,

mp <- mp %>%
  mutate(raster_band = extract(raster_brick, geometry, weights = TRUE))

would add a column of extracted values as a list of data.frames to mp.

Then, one could do something like this using purrr::map_dbl:

mp <- mp %>%
  mutate(raster_band = extract(raster_brick, geometry, weights = TRUE)) %>%
  mutate(raster_mean = raster_band %>% map_dbl(function(.data){
    sum(.data$weight*.data$value)
  }))

which would add the weighted mean for each row in the original sf object. Alternatively, using tidyr::unnest(), tidyr::nest(), as long as there isn't too much data:

mp <- mp %>%
  mutate(raster_band = extract(raster_brick, geometry, weights = TRUE)) %>%
  unnest(raster_band) %>% 
  group_by(polygon_id) %>% # uniquely identifies polygons
  summarize(raster_mean = sum(weight*value))

would achieve something similar, but would drop some columns.

[edzer]

Kendon, Robert (@rhijmans) and I wrote a short blog about the future of R spatial. It addresses more the complexity and scalability limits of current raster than the user interface aspects that you mention. But I agree, these are important too, and thoughts about this like your above are very welcome.

What I would like to make explicit (and am working on in sf, for polygons) is the issue whether raster cells reflect square polygons with constant value, values at the point location of the cell center, or aggregations over the raster cell. In your extract example you're assuming the first, like raster (always?) does, but this is not what remote sensing imagery or DEMs give us, for instance.

[kendonB]

Everything in the blog plot + attributes reflecting what raster cells represent (point vs average) would be very welcome!

Is the plan to rewrite raster into a new package?

Regarding the UI, I would encourage the use of list columns of data.frames/tibbles where possible for output (usually added to an sf using mutate), as most analysts will be familar with these objects already and will know how to nicely work with them using dplyr/tidyr/purrr.

[edzer]

Closing here, since this not unrelated, but simply beyond simple features for R. See also here.