Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spatio-temporal example for georeferenced data #121

Open
vnminin opened this issue Sep 28, 2021 · 3 comments
Open

Spatio-temporal example for georeferenced data #121

vnminin opened this issue Sep 28, 2021 · 3 comments

Comments

@vnminin
Copy link

vnminin commented Sep 28, 2021

Hello inlabru team,

I was wondering if you have an updated version of the "08_spatio_temporal.html" example from the old website.

It looks like all current vignettes are about LGCP. It would be nice to have a vignette corresponding to the Section "GEOREFERENCED DATA FROM A CONTINUOUS SPATIAL FIELD" of the inlabru paper and even better if there is an example with multiple years and/or multiple observations per location.

I know it is easy to ask and totally understand if the team has no bandwidth for this.

We appreciate your work!

@finnlindgren
Copy link
Collaborator

Hi!
Yes, most of the vignettes on https://inlabru-org.github.io/inlabru/articles/ were initially developed as workshop exercises for a course in distance sampling methods in ecology, which is why most are about LGCP models. The "Random fields in ..." vignettes at the end of the list, and in particular the "... in 2D" one, are more directed to the much easier georeferenced data case. The old spatio-temporal vignette never really worked as intended, and we haven't made our way around it to make an updated version. The workshops were also intended for peope who were already a bit familiar with "plain" INLA, so things that worked the same in both interfaces didn't need to be discussed in much detail.

The main difference between the LGCP examples and ordinary georeferenced problems is that for the LGCP model the inputs and predictor expressions need to be written so that inlabru can construct and supply new spatial locations to the expressions in order to construct the observation likelihood. This leads to things like the spatial covariate evaluator functions (or now usually automated evaluation of spatial grids) that can still be used for georeferenced models, but are not needed as often.

For separable covariance models using "group", it by default works the same as in plain INLA, but there are a few more options available. If the data is stored as a SpatialPointsDataFrame, with one row per observation (so a location may occur more than once), a component definition can be as simple as this, if time contains integers from 1 to some nT:

~ field(coordinates, model=spde, group=time)

For plain data.frame input, the sp::coordinates function isn't available, but one can construct the coordinates explicitly:

~ field(cbind(easting, northing), model=spde, group=time, control.group = ...)

If time isn't already stored as a plain 1-based integer index, one can construct a mapper object to map the values to an index. This always happens behind the scene for all inlabru model components, which is how it knows how to map the coordinate input to the spde mesh, but the default can be overridden:

~ field(cbind(easting, northing), model=spde,
      group=year,
      group_mapper = bru_mapper(inla.mesh.1d(1995:2005), indexed = TRUE),
      control.group = ...
)

This maps the years 1995 through 2005 to the indices 1 through 11. This approach also allows interpolation for fractional years; it's even possible to apply the group model to the weights of 2nd degree B-spline basis functions, with e.g. inla.mesh.1d(1995:2005, degree = 2) as the underlying basis function definition.

We're currently working on a paper on non-separable space-time models, which will come as single model objects and can be defined with syntax like

~ field(list(space = cbind(east, north), time = year), model=modelobject,
      main_mapper = bru_mapper_multi(list(space=..., time = ...)))

(If we package the code nicely, the mapper information may already be pre-defined, just as for the plain spde models that contain the mesh information that inlabru uses to construct the mapper)

Since the existing vignettes were meant essentially as a sequence of computer labs, there is definitely room for some shorter vignettes about simper but more common aspects; one issue is usually access to small (but not too small and shareable example data sets; a lot of the 2D random field vignette is taken up by code for sampling synthetic data, before one gets to the actual estimation part.

@finnlindgren
Copy link
Collaborator

(I always hope to collect answers like this into more findable vignette formats, but never seem to find the time to do that... Vignette/documentation contributions would be welcome!)

@vnminin
Copy link
Author

vnminin commented Sep 28, 2021

Thanks for the quick response, @finnlindgren!

If we can our model to work, we would be happy to contribute it as a vignette, probably with simulated data to avoid upsetting collaborators in case they are not ready to share yet

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants