Location data in ZoonModel

[timcdlucas]

I'm finally getting around to write an INLA module for zoon. However, I now realise that ZoonModel only passes on newdata.

I would either have to do some hack so that locations get passed in as covaraites (which doesn't generally work because it would rely on all output modules to be able to do the same) or change ZoonModel to be able to take some extra data.

Any thoughts? I'll probably get a PR ready and see what people think.

This is turning into a bigger job than I expected...

[goldingn]

To be able to predict across the whole grid, the latitude and longitude will have to be added as covariates in the RasterStack right? So it would make sense to me to make a Process module to create those covariates first.

Then the INLA Model module could find those covariates by name (searching the 'covCols' attribute of the dataframe), use those covariate columns to build the mesh, then use other covariates in the regression part.

Then the predict code would have to either build a new mesh, or a projection matrix based on the coordinates of all grid cells.

Would that work?

It would be tricky to do comparisons with aspatial models within a single workflow I guess, but it seems the most zoonish approach, and wouldn't require a change to the package.

On Mon, 17 Apr 2017, 00:26 Tim Lucas, [email protected] wrote:

I'm finally getting around to write an INLA module for zoon. However, I now realise that ZoonModel only passes on newdata.

I would either have to do some hack so that locations get passed in as covaraites (which doesn't generally work because it would rely on all output modules to be able to do the same) or change ZoonModel to be able to take some extra data.

Any thoughts? I'll probably get a PR ready and see what people think.

This is turning into a bigger job than I expected...

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/zoonproject/zoon/issues/379, or mute the thread https://github.com/notifications/unsubscribe-auth/AEPpqyc1ZLq3QlTdq9mCvY8C5aIfep2wks5rwiUegaJpZM4M-o8T .

[timcdlucas]

Man so much more complicated than i thought.

Not sure this works because a module like "PredictToNewArea" would need to go through the process module that turns lat long into covariates.

In general, the predict to new area or new time output modules are a bit awkward. If transforms have been applied to the covariates they generally won't work. So maybe your solution is as easy and unbreaky as any other. Maybe something that needs thinking about more generally. Probably getting the full extent at the offset is the better plan in general.

The alternative i was thinking about was to add a latlong argument to ZoonPredict. It's more argument creep and probably require going back and changing old modules. But perhaps with it.

I think unless there's a ground swell of more spatial models, I'll start looking at your approach.

[goldingn]

Yeah, it's a good point. I think we discussed the PredictToNewArea module and processing of covariates before. We settled on leaving it to the user to apply those processes outside of the workflow.

Since there's now a call path attribute, another option would be for those types of output modules to apply the same processes to the new rasters. I.e. find out what process modules and arguments were applied to .ras then apply the same to new_raster (or whatever it is called).

Which of those two behaviours to use could be an argument to the output module.

On Mon, 17 Apr 2017, 23:16 Tim Lucas, [email protected] wrote:

Man so much more complicated than i thought.

Not sure this works because a module like "PredictToNewArea" would need to go through the process module that turns lat long into covariates.

In general, the predict to new area or new time output modules are a bit awkward. If transforms have been applied to the covariates they generally won't work. So maybe your solution is as easy and unbreaky as any other. Maybe something that needs thinking about more generally. Probably getting the full extent at the offset is the better plan in general.

The alternative i was thinking about was to add a latlong argument to ZoonPredict. It's more argument creep and probably require going back and changing old modules. But perhaps with it.

I think unless there's a ground swell of more spatial models, I'll start looking at your approach.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/zoonproject/zoon/issues/379#issuecomment-294483667, or mute the thread https://github.com/notifications/unsubscribe-auth/AEPpq0TxXUXRN6UkGnp4lDZf79sU_9KXks5rw2YcgaJpZM4M-o8T .

[timcdlucas]

OK.

Leaving Predict outside the workflow is ok, but worth making clear that it is easy to predict as long as a large extent is set at the beginning.

The output modules applying the processes sounds doable but difficult. Would probably need to be written by someone fairly invested in zoon and then not expect everyone else to do it. I guess we could build a helperfunction that does that and document it so that hopefully anyone writing similar modules would know to use it...

But, this has all gotten off topic. Short version: I'll write a latlongtocovariate module (it's a useful module anyway and I'm surprised something similar isn't used more often in SDMs). Then most things should work fine.