Trap operation in oSCR

[Greta Schmidt]

Hi all,

I have a simple question about accounting for trap operation that I am struggling with. I have created my scrFrame which includes the $trapopp list of trap operation information. When running oSCR.fit, how do I include this trap operation? I first thought that it was included automatically, but when I run two null models with my data - one with the correct trap operation information, and one with fake trap operation information (just all traps open all the time), the outputs are exactly the same (though maybe this is not unexpected?) Should I be including trap operation in $trapcovs instead? Is there something I need to specify in the p0~ model formula?

Any insight would be appreciated, thanks!

Greta 

[Daniel Linden]

Hi Greta, can you share the code you used to generate your scrFrames?  The oSCR.fit function will incorporate trap deployment automatically, so it sounds like your data processing workflow might have an error.

--
You received this message because you are subscribed to the Google Groups "oSCR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to oscr_package...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/oscr_package/e90668e5-912b-4679-a08d-0d5645199e3en%40googlegroups.com.

[Greta Schmidt]

Yes, thank you! Attached are my code and data. Please let me know if you need anything else.

Greta  

To view this discussion on the web visit https://groups.google.com/d/msgid/oscr_package/CAFWOE74Jo6GX36KngekVKwLfpZY4BddiZvS1nS%3Dgmq6%2BxeFCFw%40mail.gmail.com.

[Jeffrey Royle]

hi Greta,

 I see what you mean... this suggests an error that we missed along the way....

regards

andy

To view this discussion on the web visit https://groups.google.com/d/msgid/oscr_package/CA%2B4kahCPfdumuoaEc_0RyaVXRGnF52OpVOp76b1RM7Ec714H8A%40mail.gmail.com.

[Chris Sutherland]

Hi Greta, and all,

 

This *is* an error!! TO give everyone a sense of when this happens, it is worth nothing that:

 

• Not specifying a trimS has been ignoring trap operation information
• Specifying a trimS properly deals with trap operation information
• I have fixed this issue and pushed it to the github repository, and I recommend installing the package again:

 

remotes::install_github("jaroyle/oSCR")

 

I’m really sorry about this!

 

Chris 

To view this discussion on the web visit https://groups.google.com/d/msgid/oscr_package/CAE%2BwgF1pzaTNdd9ror9RFErMW-aBY06eJpu0pD2ne_wvOdaA6A%40mail.gmail.com.

[PABLO PALENCIA MAYORDOMO]

Hi folks,

I have a problem understanding the difference in  "tdf" and "K" arguments of "data2oscr" function.

In tdf we should include a list of the operation days of each detector (in my case, cameras), right?

In K we should include a vector of the number of occasions (i.e. the sum of operation days) of each camera?

If I'm right, I don't understand why we should provide two times the same information to the function data2oscr
Additionally, when I get the summary of the scrFrame, I note that the number of occasions parameter is just one number (the first one of the vector). In my case (and I think that this is quite habitual), the number of occasions are not the same for all the detectors.

My data:

data<-data2oscr(edf = edf, # the encounter data file
                sess.col = 1, # session col NUMBER (edf)
                id.col = 2, # ind ID col NUMBER (edf)
                trap.col = 3, # detector col NUMBER (edf)
                occ.col = 4, # occasion col NUMBER (edf)
                tdf = list(tdf), # **list** containing the trap deployment file
                K = K_tot, # occasion vector
                ntraps = nrow(tdf)) # the number of traps

str(tdf) 'data.frame': 63 obs. of 65 variables:

$ Trap_id : int 1 2 3 4 5 6 7 8 9 10 ...

$ X : num 429702 429494 429907 430719 430721 ...

$ Y : num 7048106 7047927 7048092 7050417 7050217 ...

$ X01.07.2017: int 1 1 1 1 1 1 1 1 1 1 ...

$ X02.07.2017: int 1 1 1 1 1 1 1 1 1 1 ...

K_tot [1] 37 37 37 37 37 37 31 31 34 34 34 32 32 32 31 31 31 31 31 31 37 14 31 31 32 38 38 38 38 38 24 24 24 24 [35] 24 24 30 30 30 27 27 27 27 30 30 31 31 31 31 31 31 24 24 24 29 29 29 23 23 29 23 23 23

> data$scrFrame 

                        S1

n individuals 14

n traps 63

n occasions 37

                     S1

avg caps 2.57

avg spatial caps 1.86

mmdm 3650.54

Thank you very much for your help

Best

Pablo

[Daniel Linden]

Hi Pablo,

There should only be a single K per session, which is the maximum number of occasions for a given session.  This allows the dimensions of the capture histories to be known for that session (among other things), and then the trap operation is specified when needed in the tdf.  All of this is to facilitate efficient matrix algebra in the code.

To view this discussion on the web visit https://groups.google.com/d/msgid/oscr_package/5f959833-4eac-492d-9e27-23f80ded317fn%40googlegroups.com.

[Ursa Flezar]

Hi everyone,

thanks for this important discussion.

I have a follow-up on the trap operability issue; J.Royle posted a caution message a while ago about using trimS argument in case you're including covariates on the detection probability (e.g. p0~sex), advising not to use trimS in this case. Does that mean that the trap operation data will be ignored in these models? If so, how are the null model (using the trimS argument, thus incorporating trap operation information) and the models with covariates on p0 (not using trimS argument) comparable?

I think trap operability is important information to be cosidered, as it reflects the samling effort accurately.

Also, I noticed that it seems to be important for the columns defining occasions in tdf to be in the correct order, e.g. if I have in total 245 occasions, then the column names should be 1,2,3,4,...245 (instead of 1,10,100,101,...245) for the model to link the trap operability per occasion defined in tdf with occasion of capture per individual defined in edf. Am I correct?

In case my questions are not totally clear, please let me know.

Thanks in advance!

Urša

[PABLO PALENCIA MAYORDOMO]

Hi,

Thanks for your response Daniel!

After reading the questions of Ursa, I'm concerned about the operability codes...

In my case, I used a rotating survey (i.e. change camera trap locations), and I'm concerned with the occasion values in edf.

Let's suppose that I started my survey 1st of June, and on15th of June I changed the locations of all the cameras to a new deployment. In one of the camera I recorded an animal on 16th June. In this case, the value occasion for this encounter is "2" (second day in which the camera was on this point), or "16" (16th day since the survey started)??

I've been always worried about how occasions should be considered; from the survey beginning, or from the first day in which each trap was operative.

Best

Pablo

[Daniel Linden]

Hi Urša and Pablo,

The trimS function should work fine now, what Chris found was that not using trimS was causing an error with trap operability.  In most real world applications of these models, both the trimS function is needed for speed (due to state space extent, etc.) and trap operability is variable and thus required to model explicitly.  When we explore and present toy examples neither of these components is needed so sometimes they are missing as steps in the illustrated process.

The order of occasions should definitely be organized.  One struggle we've witnessed with workflows in oSCR is the recognition of data types in R and what happens when there is a deviation from best practices regarding data organization.  Most of that is specific to R, not oSCR, but there are times when we take for granted that a user will take certain steps to wrangle their data.  When those steps are not taken and the oSCR code is not general enough, errors can happen.  For example, whether the names of animal IDs, trap IDs, occasions, etc. are characters, factors, or numeric.  We've tried to chip away at all the possible ways someone will organize their data, but surprises happen.

Pablo, your question regarding occasion organization is very interesting and applies to many capture-recapture contexts beyond SCR and oSCR.  The quick answer is that it is up to you.  Unfortunately, I cannot expand much on a longer answer at the moment but I would say that occasions can be made trap specific, in addition to covariates associated with them.  Whether that encounter is considered the 2nd or 16th day only matters in so much as the covariates match up (e.g., temperature or ordinal day for the trap on that occasion).  It will definitely affect the speed though – the fewer occasions the better.  If you have removals of individuals, the occasions cannot be collapsed by trap.

Hope this helps!

To view this discussion on the web visit https://groups.google.com/d/msgid/oscr_package/8d8a5f76-19e4-4958-95ea-b2972cd98157n%40googlegroups.com.

[PABLO PALENCIA MAYORDOMO]

Ok, thank you very much Daniel!