traps with no detection / absence

[Gilles Maurer]

Hi all, 

I have the following message when running data2oscr :

some trap names in EDF not in TDF

I checked as follows :

> trap_ids_edf <- unique(lao_edf$trapID)
> trap_ids_tdf <- unique(lao_tdf$trapID)
> missing_trapIDs <- setdiff(trap_ids_edf, trap_ids_tdf)

character (empty)

Both are set as character 

I do have 53 trapID in EDF and 2386 in TDF. 

Where could be the problem ? Any clue ? 
I am wondering if the issue may come from traps that never detect any individual ( absence only). Shall I discard them from the dataset ? 

Thank you in advance for your help
Gilles

[Gilles Maurer]

Sorry, I did not provide sufficient details

I have one session only.
Here are data2oscr arguments :
 data <-
  data2oscr(edf = edf,
            tdf =list(tdf),
            sess.col = 1,
            id.col =2,
            occ.col = 3,
            trap.col = 4,
            sex.col = 5,
            sex.nacode = "U",
            K = 7,   # 7 occasions / only 1 session
            ntraps =  nrow(trap_operation),  #number of capture traps per session
            trapcov.names = c("habitat_class", "ob"),
            tdf.sep = "/")


Apparently when running the function data2oscr,  all trap names (53) that are in edf are not found in tdf 
> class(edf)
[1] "data.frame"
> head(edf)
  Session    ID occasion trapID sex
1       1 18UG1        1  24845   U
2       1 18UG2        1  24845   M
3       1 18UG3        1  24845   U

> head(tdf)
# A tibble: 6 × 13
  trapID       X        Y   O.1   O.2   O.3   O.4   O.5   O.6   O.7 sep   habitat_class ob
  <chr>    <dbl>    <dbl> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl> <chr> <fct>             <dbl>
1 20699  487482. 1969720.     0     0     0     0     0     0     1 /     Trees            0.0259
2 20854  487576. 1969545.     0     0     0     0     0     0     1 /     Trees            0.0234
3 21166  487775. 1969538.     0     0     0     0     0     0     1 /     Trees            0.0238


thank you

[Daniel Linden]

Hi Giles, you might need to send me your files so that I can try to replicate.

[Chris Sutherland]

Can you try again, but convert the tdf to a data frame rather than a Ribble 

--
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 visit https://groups.google.com/d/msgid/oscr_package/c812bac0-8a31-4b70-84ab-b9481c13d69bn%40googlegroups.com.

[Gilles Maurer]

Indeed, my tdf was a tibble, I just found the answer in previous messages a minute ago. Sorry to bothered you

 I am now on my way to the sSpace ;-) that is a bit tricky because of the presence of a lake (artificial reservoir with a tricky shape and varying levels of water ). Traps are indeed visited cells were feces have been collected and genotyped.  While feces cannot be found in the water, they can be collected along the banks. And animals can cross the lake ...
 

Thks again

Gilles

[PABLO PALENCIA MAYORDOMO]

Dear list,

When using the 'data2oscr' function, I get the following error:

"some trap names in EDF not in TDF"

I know this is a known issue, for example in the discussion I’m responding to, as well as in other threads (e.g. Problems reading my edf and tdf with data2oSCR()).

In general, besides checking that all traps are included in the TDF, it is also recommended that both EDF and TDF are data.frame objects when passed to data2oscr. I have verified both points, but the error still persists.

I would greatly appreciate any help. I am sharing my data and code. As you will see at the end of the code, I included a small loop to try to identify any “missing” traps, but it does not seem to return any specific cases.

Thank you very much in advance for your assistance.

Best regards,
Pablo

[Daniel Linden]

Hi Pablo, there are 2 things going on.  One is that your tdfs are tibbles, which causes an error.  Yes, they are also data.frames so the check you did is deceptive.  You need to make sure the tdfs are data.frames only (you can use as.data.frame to achieve that).

The second problem is that you have named your occasions in the tdf files with dates, while they are referenced as numbers in the edf.  Making them both appear as integers would be better.

To view this discussion visit https://groups.google.com/d/msgid/oscr_package/02727909-e700-4c87-96b0-bc4e863433e2n%40googlegroups.com.

[PABLO PALENCIA MAYORDOMO]

Hi Daniel,

Thank you very much for your help!

Regarding the harmonization of occasions using numeric nomenclature (instead of dates), I was wondering how best to do this. In my case, there is a lot of variability in the start and end periods of each trap, as not all of them started or ended at the same time. Because of this, I am unsure whether occasion 1 should correspond to the first day when any trap was activated, or the first day when each individual trap was activated.

A few years ago I asked this question in the group (see here), but I was wondering whether there have been any advances in the last five years. I copy the previous questions and answers below in case they are useful:

- Question:
I used a rotating survey (i.e., changing camera trap locations), and I am concerned about how the occasion values should be defined in the edf.

Let’s suppose that I started my survey on the 1st of June, and on the 15th of June I moved all the cameras to a new deployment. In one of the cameras, I recorded an animal on the 16th of June. In this case, should the occasion value for this encounter be "2" (the second day the camera was operating at that location), or "16" (the 16th day since the survey started)?

I have always been concerned about how occasions should be defined: from the beginning of the survey, or from the first day on which each trap was operative.

- Answer: 

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.

Thanks very much,
Pablo

[Daniel Linden]

Hi Pablo, I'm not aware of advances that would automatically solve this problem.  What you are describing is a sampling design where sacrifices had to be made.  The ideal sampling design has all cameras operating at the same time.  Any deviation from that requires some assumptions.  The realities of field sampling result in logical challenges that are faced by everyone attempting to make observations in the wild.  Such is life!

Since these models are not employing any Markovian concepts to the processes being estimated, there is no functional difference between occasion 1 and occasion 17 and occasion 99.  If those occasions occurred during times when environmental features (e.g., temperature, season) might explain variation in your process, you could be motivated to include covariate values.  But again, if trap A has occasion 17 on the same date that trap B has occasion 1, the only thing that matters is that the relevant covariate value for date is correctly specified in the trap-specific occasions.

To view this discussion visit https://groups.google.com/d/msgid/oscr_package/2aef9945-efb6-4ac7-a840-4b7e5d0a2140n%40googlegroups.com.

[PABLO PALENCIA MAYORDOMO]

Hi Daniel,
Thanks a lot! Your explanation clarifies things a lot.