Obtain component inputs

Usage

input_eval(...)

# S3 method for class 'component'
input_eval(component, data, ...)

# S3 method for class 'component_list'
input_eval(components, data, ...)

# S3 method for class 'bru_input'
input_eval(input, data, env = NULL, null.on.fail = FALSE, ...)

Arguments

...: Unused.
component: A component.
data: A data.frame, tibble, sf, list, or Spatial* object of covariates and/or point locations. If NULL, return the component's map.

Value

An list of mapper input values, formatted for the full component mapper (of type bru_mapper_pipe)

Methods (by class)

input_eval(bru_input): Attempts to evaluate a component input (e.g. main, group, replicate, or weight), and process the results:
1. If eval() failed, return NULL or map everything to 1 (see the null.on.fail argument). This should normally not happen, unless the component use logic is incorrect, (e.g. via include/exclude) leading to missing columns for a certain likelihood in a multi-bru_obs() model.
2. If we obtain a function, apply the function to the data object
3. If we obtain an object supported by eval_spatial(), extract the values of that data frame at the point locations
4. Else we obtain a vector and return as-is. This happens when input references a column of the data points, or some other complete expression

Simple covariates and the map parameter

It is not unusual for a random effect act on a transformation of a covariate. In other frameworks this would mean that the transformed covariate would have to be calculated in advance and added to the data frame that is usually provided via the data parameter. inlabru provides the option to do this transformation automatically. For instance, one might be interested in the effect of a covariate \(x^2\). In inla and other frameworks this would require to add a column xsquared to the input data frame and use the formula

formula = y ~ f(xsquared, model = "linear"),

In inlabru this can be achieved in several ways of using the main parameter (map in version 2.1.13 and earlier), which does not need to be named.

components = y ~ psi(main = x^2, model = "linear")
components = y ~ psi(x^2, model = "linear")
components = y ~ psi(mySquareFun(x), model = "linear"),
components = y ~ psi(myOtherSquareFun, model = "linear"),

In the first example inlabru will interpret the map parameter as an expression to be evaluated within the data provided. Since \(x\) is a known covariate it will know how to calculate it. The second example is an expression as well but it uses a function called mySquareFun. This function is defined by user but has to be accessible within the work space when setting up the components. The third example provides the function myOtherSquareFun. In this case, inlabru will call the function as myOtherSquareFun(.data.), where .data. is the data provided via the bru_obs() data parameter. The function needs to know what parts of the data to use to construct the needed output. For example,

myOtherSquareFun <- function(data) {
  data[ ,"x"]^2
}

Spatial Covariates

When fitting spatial models it is common to work with covariates that depend on space, e.g. sea surface temperature or elevation. Although it is straightforward to add this data to the input data frame or write a covariate function like in the previous section there is an even more convenient way in inlabru. Spatial covariates are often stored as SpatialPixelsDataFrame, SpatialPixelsDataFrame or RasterLayer objects. These can be provided directly via the input expressions if they are supported by eval_spatial(), and the bru_obs() data is an sf or SpatialPointsDataFrame object. inlabru will then automatically evaluate and/or interpolate the covariate at your data locations when using code like

components = y ~ psi(mySpatialPixels, model = "linear")

For more precise control, use the the layer and selector arguments (see bru_component()), or call eval_spatial() directly, e.g.:

components = y ~ psi(eval_spatial(mySpatialPixels, where = .data.),
                     model = "linear")

Coordinates

A common spatial modelling component when using inla are SPDE models. An important feature of inlabru is that it will automatically calculate the so called A-matrix (a component model matrix) which maps SPDE values at the mesh vertices to values at the data locations. For this purpose, the input can be set to coordinates, which is the sp package function that extracts point coordinates from the SpatialPointsDataFrame that was provided as input to bru_obs(). The code for this would look as follows:

components = y ~ field(coordinates, model = inla.spde2.matern(...))

Since coordinates is a function from the sp package, this results in evaluation of sp::coordinates(.data.), which loses any CRS information from the data object.

For sf data with a geometry column (by default named geometry), use

components = y ~ field(geometry, model = inla.spde2.matern(...))

Since the CRS information is part of the geometry column of the sf object, this retains CRS information, so this is more robust, and allows the model to be built on a different CRS than the observation data.

Author

Fabian E. Bachl bachlfab@gmail.com, Finn Lindgren finn.lindgren@gmail.com