Multi-species *multi-season* communityModel?

[Jarrad Barnes]

Hi Jurgen,

Really love the implementation of communityModel - still learning it, but ticks a lot of boxes. Something I'm particularly interested in doing, that, as far as I know, isn't available in the packages I'm familiar with, is to have a multi-species multi-season occupancy model. I have a 13 month dataset across 9 sampling periods, and I want to look at how occupancy of the community as a whole changes by including observation covariates (as you would for modelling variation in detection probability, but for changes across seasons). I'm familiar with implementing multi-species and multi-season separately in unmarked, but I'm hopeful that there's a way to tackle this in the latest camtrapR update. Am I just missing this capability, or am I being too hopeful?

Thanks,

Jarrad

[Jürgen Niedballa]

Hi Jarrad,

Thank you for the kind words. Glad you're enjoying the workflow. It is however currently limited to single season models and cannot create multi-season models (in the sense of dynamic models, with colonization/extinction probabilities between seasons). 

There are some possible workarounds though to include seasonal information in models:

1. You could stack the seasons (in the input data) and then include season as a covariate in the model (with fixed or random effect). That would allow variation between seasons, but without being a dynamic multi-season model.

2. An alternative would be to use the model code provided by communityModel() as a starting point for manual model modifications to turn it into a multi-season model. But that would not be compatible with the rest of the workflow (predict, plot*) and hence defeats the purpose.

3. Another solution may be available in the spOccupancy package:

https://www.jeffdoser.com/files/spoccupancy-web/reference/tmspgocc

But from the documentation it also doesn't seem to estimate colonization and extinction probabilities, so it also doesn't seem to be a dynamic model like colext() in unmarked or ubms. I haven't run it myself yet, so can't provide any further insights and may miss finer points.

The hmecology Google group may also be helpful in finding a solution. Sorry I can't provide the full solution currently. Feel free to update when you made progress.

Best regards,

Jürgen 

--
You received this message because you are subscribed to the Google Groups "camtrapR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to camtrapr+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/camtrapr/8e86dc34-a004-4cc6-a3c1-ebfda2cba63bn%40googlegroups.com.

[Jarrad Barnes]

Hi Juergen, thanks for having a think about this. I suspected that was the case, and somehow working to include season/sampling period as a covariate was the best alternative I could come up with, too - I'll see how I go with implementing that. I've had a look at spOccupancy and there seems to be quite a steep learning curve with the parameters involved, and no worked examples with real datasets, so it's an uphill battle with that at the moment. I'll see how I get on with a simpler approach in camtrapR first. 

Thanks for your thoughts,

Jarrad

[Jürgen Niedballa]

Hello Jarrad,

sorry that wasn't clear. What I meant is you can combine the data from multiple seasons in a way that keeps the same camera trap locations (stations) in different seasons as independent rows in the camera trap table (as if they are different cameras). It's basically like cbind() the camera trap tables from all seasons. So let's say you have 10 camera trap locations (stations) with 2 seasons of data each. That gives you 20 rows of data in the camera trap table, with two entries per location / station. Likewise, the record tables are combined.

I am not sure right now (no test data at hand, sorry) if you need to rename the station names to differentiate between seasons. If yes that would need to be done in both the camera trap table and the record table. but it may not be necessary, I just don't have the time to test it right now.

In modelling you can then use the "season" site covariate in various ways; fixed effects, random effect, nested random effects, on detection or occupancy probability or both. What's important though is to make the season column a factor so the model doesn't use it as a continuous covariate (unless that is really what you want to do).

Best,

Jürgen

Am Mi., 27. März 2024 um 21:13 Uhr schrieb Jarrad Barnes <jarrad...@gmail.com>:

Hi Juergen,

I've looked over your answer again and I notice you've mentioned stacking the seasons in the input data. I'm not entirely certain I understand what you mean by that - any chance you could clarify/expand on how that would work within the workflow?

Thanks,

Jarrad

On Thursday 21 March 2024 at 16:26:04 UTC+10 Jürgen Niedballa wrote:

To view this discussion on the web, visit https://groups.google.com/d/msgid/camtrapr/70aee050-6686-40fe-980d-9388b1853f29n%40googlegroups.com.

[Jürgen Niedballa]

Hi,

Sorry for the late reply. Each station/ season combo has its own detection history, so there is potential for different occupancy estimates between seasons at the same locations. It will also affect the estimates of effect sizes of occupancy covariates if the detection histories didfer between surveys.

In addition, detection covariates (e.g. effort, weather or whatever) may differ between seasons, which may indirectly affect occupancy estimates.

So I would expect that combining multiple seasons will affect occupancy estimates. I haven't tested this, but it should ve possible to build a test scenario using simulated community data (using AHMbook package, see camtrapR vignette 5).

Best regards,

Jürgen

On Wed, Apr 3, 2024, 18:12 Jarrad Barnes <jarrad...@gmail.com> wrote:

Hi Juergen,

One other query about this - as each station will be technically replicated in the site covariates matrix 9 times (9 sampling periods) is this likely to have any effect on the occupancy estimates based on site covariates? I assume not, as each station/survey combo will be identical regardless of survey, but thought that was pertinent to check. And, if t is likely to be a problem, can you think of a way to deal with that issue?

Thanks,

Jarrad

To view this discussion on the web, visit https://groups.google.com/d/msgid/camtrapr/7b17b806-b0fd-4c07-9570-814847883690n%40googlegroups.com.