finnlindgren
commented
3 years ago An interface design challenge for this is how to distinguish between "evaluate gridded data input at locations and use those to evaluate the component effect, which is then accessible in the predictor expression" from "evaluate the component at all the grid locations and then use the predictor expression to do some complex nonlinear evaluation of the values". Each component might need a new option to control this behaviour. It's a non-trivial problem.
@finnlindgren wonder if to avoid confusion like this lgcp could accept two data objects? One for points and one for covariates?
Originally posted by @ASeatonSpatial in https://github.com/inlabru-org/inlabru/issues/118#issuecomment-862413649
@ASeatonSpatial Yes, depending on the details of how the predictor model inputs can be separated from the response variable, that should be doable. The current setup is based on the common assumption that the "data" input contains the response variable, and any values associated with the individual points, such as marks for marked point processes. But by allowing a more general separation between "component and formula inputs" and "response variable information", the data argument to like() would more naturally take on the "component and formula inputs" interpretation, and a separate argument would be needed for the response variable information. I plan to work on the design and implementation for this later this summer; it's needed for a broad range of models, e.g. models that integrate over regions (including point transect count models).
This is also needed for the special
inla.survandinla.mdataresponse objects.