CRS Projections affect on the model estimation and interpolation?

[何博文]

Hi,

Does the coordinates of the spatial prediction location from different CRS projection can lead to different model output? For example, the UTM projection, the Alber Equal Area Projection and the latlong coordinates without projection? If so, what is usually preferred when doing the mesh on the real world data?

Thanks,

Bowen

[Finn Lindgren]

Hi,

This depends on how you define your mesh and link the data to the
mesh, and also if the range of the coordinate values is badly scaled
(e.g. default UTM projects are in metres, which behaves badly when
working on large areas where kilometres are more reasonably sized).

If you build your mesh without specifying a crs, the model will be
built in whatever coordinate system your input values are, and you
have to make sure all input points are provided in the same coordinate
system.
If you do specify a crs when building the mesh, it will automatically
map your inputs to that coordinate system when calling
inla.spde.make.A().
It's not the crs itself that affects the mesh; it's just used to map
input locations to the coordinate system.

The coordinate system in which the mesh is built is the system used to
define the model, and anything that depends on distances (such as the
correlation range and areas) will be in that metric.
This means that unless you're modelling near the equator, longlat
meshes will lead to anisotropic models, so UTM (preferably in
kilometres instead of metres) or similar area preserving and locally
shape preserving is preferable. For a close to global model, building
the mesh _on_ the sphere is a much better option. In this case, the
standard code and examples uses a radius 1 sphere, so the length unit
is in radians (and the total globe area is 4\pi).

The most up-to-date crs helpers are in the inlabru package (most of
the crs code in INLA should work the same, but there may be some minor
improvements in inlabru). Use inlabru::fm_CRS("sphere") to define the
radius-1 sphere geocentric CRS if needed, and
inlabru::fm_spTransform() to convert between crs:es. Also see
?inlabru::fm_crs_set_lengthunit() for modifying a CRS (in particular
UTM) to kilometres (often, manually dividing by 1000 also works as an
alternative to formal transformation, as long as the CRS information
is then removed or not used).

Finn

> --
> You received this message because you are subscribed to the Google Groups "R-inla discussion group" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to r-inla-discussion...@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/r-inla-discussion-group/e84d8625-576d-48b7-9ce8-348e00b7fbd2n%40googlegroups.com.



--
Finn Lindgren
email: finn.l...@gmail.com

[Bowen He]

Thanks Finn!

Another question is that my verbose = TRUE generates the following messages and then freeze for days with no further actions

"Optimise using DEFAULT METHOD"

"Smart optimize part I: estimate gradient using forward differences"

And this could freeze for days without proceeding with no further messages being shown in the console.

Any ideas on how to fix the problem?

Thanks,

BH