SECR with unpaired cameras

This was based on simulations with just one set of parameter values, but it does suggest that projects with limited resources should consider using unpaired cameras, as this allows more locations to be sampled.

Analysing unpaired data

Let's look at a practical example. Wang and Macdonald (2009) used unpaired cameras to collect data on leopards and tigers in Bhutan. For leopards, they identified 25 left flanks and 23 right flanks; separate analyses with program capture gave very similar estimates of the population. For tigers, they got 14 left and only 3 right flanks; they analyzed only the left flank data, discarding the right flanks.

A more immediate example is an ongoing study of clouded leopards in Nepal. The objective is to estimate occupancy, so unpaired cameras are deployed. But it may be possible to use SECR to estimate density too if enough recaptures are obtained.

We should be able to combine the data for the 2 flanks into a single analysis as we know that the density of left and right flanks must be equal, and can assume that the capture probabilities are also equal. But we can't just lump all the data into a single capture history, as that would involve an unknown degree of double-counting.

A straightforward solution with the secr package is to treat the left and right flanks as separate "sessions", but to estimate common values for D , g0 and sigma across sessions. Some animals will occur in both data sets, and I wasn't sure if this could cause problems; the main purpose of these simulations was to find out. The R code is on Github as a gist .

I think I know how to enforce the equal-density constraint in a JAGS model using data augmentation, but want to run simulations to check.

The simulations

I used the same general layout as in a previous post , where we looked at different designs for estimating small populations of tigers. That used an irregular habitat patch of 2000 km ² with approx 80 camera traps in systematic-randomly distributed clusters. This time I used a larger population of 20 animals, 1 animal per 100 km ² . I used the same values for the capture parameters g0 and sigma .

I considered 4 designs. The first 3 used clusters of up to 8 traps with a total of around 85 (numbers differed among simulations as clusters near the edge had fewer traps).

A: "Toss out" - unpaired cameras, separate capture histories for left and right flanks; analyze only the data for the flank with most individuals captured.

B: "Two sessions" - as above, but data for left and right combined in a single analysis as 2 sessions.

C: "Many pairs" - all traps (ca. 85) have paired cameras; not feasible as would require twice the funding, but a useful benchmark.

D: "Few pairs" - ca. 85 cameras, but now deployed in pairs, so only ca. 42 traps in clusters of up to 4.

I did 300 iterations of each (300 gives a nice beeswarm plot) which took just over 1 hr using 7 cores in parallel on my desktop. The resulting beeswarm plots are below:

Each dot in the plot represents the result of one simulation. The red dots are "dead bees", simulations where the data could not be analysed as there were no recaptures or all recaptures were at the same location. The true density is indicated by the dotted red line.

The key points from these results:

• Both Toss-out and Few-pairs designs had dead bees.
  
• The Two-session analysis had low bias and RMSE, almost as good as the Many-pairs.
  
• The Few-pairs design was bad, with larger RMSE than the others, several dead bees and several outliers.

That suggests that if you have only a small number of cameras available, an unpaired design may be better.