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, ...)
```

## 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: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-`like()`

model.If we obtain a function, apply the function to the data object

If we obtain an object supported by

`eval_spatial()`

, extract the values of that data frame at the point locationsElse 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 `like()`

`data`

parameter.
The function needs to know what parts of the data to use to construct the
needed output. For example,

## 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 `like()`

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

For more precise control, use the the `layer`

and `selector`

arguments (see `component()`

),
or call `eval_spatial()`

directly, e.g.:

## 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 `like()`

. The code for
this would look as follows:

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

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