Multi-Season camera operability matrix set up

[Chloe Nouzille]

Hi everyone,

I am trying to create a multi-season camera operability matrix and I had a question about formatting.

I had cameras out for multiple years that were rotated between stations every 30 days approximately.

Should each row in the matrix be a separate deployment (of ~30days)?

e.g.

OR should each row correspond to one station and I create multiple problem_from & problem_to columns for each period where a camera was not at that station?

e.g.

Also, if I had a camera out from say Dec 2019 to february 2020, would it make more sense to list the session as 2019 or 2020?

Thank you!!

[Juergen Niedballa]

Hi, 

the first option is the suggested method, as is demonstrated in the example given in ?camtrapsMultiSeason. I'd suggest sticking with that. So even if the exact same locations are visited in multiple seasons, they should be separate rows. 

The problem with the second suggested method is that you'll end up with many problem columns, can't uniquely assign a deployment to a season, and it would not allow site covariates to change between seasons. 

Regarding the last question, this is really a study design question, no so much one of data management. But it sounds like the season you describe would be most adequately described as "Winter 2019", so in that case I would not split it by calendar year, but consider those three months as one season. But it really depends on the way the data were collected and how it relates to the assumtions of a multi-season model. That should be the main criterion for making this decision, and it is not really possible to give a general answer.

Please also see vignette 3 for a demonstration of the workflow for multi-season occupancy models. 

Best regards,

Jürgen

[Chloe Nouzille]

Thank you so much!

[Chloe Nouzille]

Hi Jürgen,

It looks like I am unable to create my camera operation matrix because I have multiple deployments at the same station per year. Is there a workaround for this?

Thank you!

-Chloe

[Juergen Niedballa]

Hi Chloe,

Two solutions come to mind:

1. Use the "camera" column. So for example within a station A, camera 1 was set up January to March, camera 2 June -August, etc.. How well this works also depends on how many cameras were set up per station at a given time (single / pairs), and if pairs were independent (these thing will affect how effort is calculated).

2. Use the problem columns to indicate periods where cameras were not operational (Problem1_from / Problem1_to, potentially with Problem2 etc). It's a workaround and not a proper solution, but may also work.

Between these 1 sounds better to me, but it's hard to say without seeing the data. Feel free to share a tiny example of the data and what you'd like to achieve, and I may be able to give a better answer.

Best,

Jürgen

--
You received this message because you are subscribed to a topic in the Google Groups "camtrapR" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/camtrapr/NeqJby1Kr1A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to camtrapr+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/camtrapr/832744c9-697b-4291-a7ab-437d9f782b36n%40googlegroups.com.

[Chloe Nouzille]

Thank you Jürgen,

Here is a sample of my CTtable for reference. I have instances like that shown in rows 28 & 29 that are preventing me from making a camera operability matrix and hence and detection history.

 SiteID   utm_y  utm_x Setup_date Retrieval_Date Problem1_from Problem1_to Y_Session
27 WCS0057 3779042 329029 2019-11-09     2020-06-14    2020-02-21  2020-06-14      2019
28 WCS0057 3779042 329029 2020-09-12     2020-10-19                                2020
29 WCS0057 3779042 329029 2020-12-30     2021-02-01                                2020
30 WCS0061 3776188 316479 2021-01-04     2021-02-12                                2021
31 WCS0066 3772923 317472 2020-09-15     2020-10-12                                2020
32 WCS0066 3772923 317472 2021-01-04     2021-02-15                                2021
33 WCS0068 3783905 340233 2020-11-29     2020-12-31                                2020

If I add a cameraID column, can the values in this column be characters? or do they also have to be numeric?

Thank you for your help!

Best,

Chloe

[Chloe Nouzille]

I added DP_Session as my "camera" column. I had one camera at each site for 30 days at a time, hence I have multiple surveys at the same site in a given year.

I ran: 

MYcamop_season <- cameraOperation(CTtable      = CamStatInfo,
                                  stationCol   = "SiteID",
                                  cameraCol    = "DP_Session",
                                  setupCol     = "Setup_date",
                                  sessionCol   = "Y_Session",
                                  retrievalCol = "Retrieval_Date",
                                  hasProblems  = TRUE,
                                  byCamera     = TRUE,
                                  dateFormat   = "%Y-%m-%d"
)

Which seems to work but now when trying to create a detection history, I also run into the error mentioned in other posts: Not all values of stationCol in recordTable are matched by rownames of camOp

When I run: 

unique(myrecordtable2$Station) [!unique(myrecordtable2$Station) %in% rownames(MYcamop_season)]

I get:

  [1] "WCS0003" "WCS0004" "WCS0005" "WCS0013" "WCS0015" "WCS0018" "WCS0019" "WCS0023" "WCS0027" "WCS0029" ...etc

but I don't understand why, for example, WCS0003 is returned when it appears to be listed in both my camtraps table:

head(CamStatInfo)
   SiteID   utm_y  utm_x Setup_date Retrieval_Date Problem1_from Problem1_to    DP_Session Y_Session
1 WCS0003 3772207 331194 2019-08-13     2020-05-29    2020-02-10  2020-05-29    August2019      2019
2 WCS0004 3785235 340582 2020-11-29     2020-12-31                            November2020      2020
3 WCS0005 3769485 324475 2021-02-07     2021-03-13                            February2021      2021
4 WCS0013 3771520 320198 2020-09-11     2020-10-14                           September2020      2020
5 WCS0013 3771520 320198 2021-01-04     2021-02-16                             January2021      2021
6 WCS0013 3771520 320198 2019-07-24     2020-07-17    2019-10-24  2020-07-17      July2019      2019

and my record table: 

> head(myrecordtable)
  Station     Species     DateTimeOriginal      
2 WCS0003    MULEDEER    2019-08-28 18:53:49

3 WCS0003    MULEDEER    2019-08-28 19:11:05 
4 WCS0003    MULEDEER    2019-09-12 00:46:11 
5 WCS0003    MULEDEER    2019-10-01 18:24:46 

[Jürgen Niedballa]

Hi Chloe, 

I forgot to mention that assigning a session changes the row names in the camera operation matrix (which now include a session identifier). The reason is that with multiple sessions, the station ID alone is not sufficient anymore to uniquely identify each row, thus camtrapR makes them unique by adding camera and session information as required. Normally that should be parsed automatically, but something is failing here.  

But I also discovered that the function should have triggered an error, saying "currently detectionHistory does not support camera-specific camera operation matrices when session/seasons are defined. Please run cameraOperation with byCamera = FALSE."  

I don't know why that didn't happen, but it means my previous suggestion was probably wrong and it might not be possible yet. In order to  (hopefully) find a solution I'd need to work with the actual data though (not just the summaries shared here). Please feel free to share a subset of the data to my email (ideally as an R workspace), then I'll try to find a solution. 

Thank you, and apologies for not having thought this through properly.

Jürgen

To view this discussion on the web, visit https://groups.google.com/d/msgid/camtrapr/a33aed9a-ff86-47f8-ad34-36b53511df33n%40googlegroups.com.