Prediction raster from `train()` does not spatially conform with `distribution()` background

[jeffreyhanson]

Prediction raster from `train()` does not spatially conform with `distribution()` background

[mhesselbarth]

This is related to the mesh that INLA/INLABRU uses to predict into space. For all (most?) other engines the spatial dimensions are exactly the same.

Not sure it's possible to force INLA/INLABRU to use a mesh with exactly the same characteristics...

[jeffreyhanson]

Ah, I see - thanks for explaining that! To ensure that I can get model predictions at a particular resolution and spatial extent, would you recommend resampling the data to a finer resolution prior to model fitting? Or manually specifying the mesh?

[jeffreyhanson]

Just to follow up, I've found that using something like this (see code below) tends to produce rasters with approximately the correct the spatial resolution so that I can subsequently resample the output prediction raster to match the original background raster.

ibis.iSDM::engine_inlabru(x, proj_stepsize = max(terra::res(bg_data)) * 0.85)

Although this increases the overall computatio time quite a bit, does this seem like a reasonable solution?

[Martin-Jung]

INLA does not use the predictor covariates to create the prediction output frame, but makes predictions on the created (if parameters are supplied) or provided (if directly passed on) mesh. A gridded prediction is only created afterwards by essentially turning each mesh node back into a gridded surface (linearly interpolating per unit stepsize). This unfortunately can result to mismatches with the original covariate spatial resolution.

Changing the stepsize can be a way but I would guess this is quite problem/dataset dependent and hard to find a golden rule there... Generally you would want a fine mesh with many nodes particular where your data is distributed which unfortunately is almost always linked to higher computational effort.
The mesh can be checked via plot( model$engine$data$mesh ) and I think there was also an in INLA function to build meshes (INLA::INLA::meshbuilder()).
Note: The denseness and location of mesh nodes has been shown to affect predictions, so the choice of creating a mesh is ultimately a parameter choice and left to users. See Dambly et al.

My recommendation if INLA is heavily used would be to create a 'default' reasonably fine mesh a priori and then supply this mesh to all predictions via engine_inlabru(optional_mesh = mymesh).

There is also build-in convenience functions for aligning/resampling grids which in cases where the prediction is larger might help sometimes (alignRasters(layer, templater) )).

[jeffreyhanson]

Ah I see - thank you very much for explaining all that @Martin-Jung!