Adapting dsm for camera trap distance sampling

[Maik Henrich]

Dear everyone,

at the moment, I am trying to adapt camera trap distance sampling for density surface modelling. My first goal is to replicate the results of the standard camera trap distance sampling approach with a null model dsm (density.est~1, …) to make sure that everything works as it should.

My first question is about the type of response used in the model. “Abundance” and “density” are clear enough: When predicting densities for the camera trap locations (just using predict(dsm) without new data), the mean density is equal to the mean abundance divided by the area sampled by a camera trap. However, I could not figure out how “count” is related to the other two responses (and why it is used in most examples). For my data, mean predicted density was 3.35, mean abundance 246.5 and mean count 22.7. Since the information that I found online was not enough for me to understand this, I would be thankful for any additional information.

Secondly, I was surprised to find that using the same data for the right truncation distance and detection zone angle, the mean density estimate that I obtained with the standard approach was about double that of the dsm when predicting across camera trap locations with density.est as a response (3.35 instead of 1.675). I therefore wondered if seg.area needs to be calculated somehow differently. If I use half the area defined by the detection angle and right truncation distance, I get the same estimate with both approaches: (right truncation^2*(angle in radians)/2)/2. Does this make sense or is there anything else I am missing?

Finally, I do not understand the offset term when predicting for a whole landscape beyond the camera trap locations. When looking up the offset term, it is explained as the area of the grid cell you are predicting for. I have a regular 20 x 20 m grid of points across the landscape that I am predicting for. However, when using 400 m² or 0.0004 km² as an offset, I get density estimates that make little sense: 1341 and 0.001, respectively. Using an offset of 1 still makes the most sense, with an overall mean predicted density of 3.4 animals/km². I am grateful for any tips of how to correctly choose the offset term.

Thank you!

Best regards,

Maik

[Tiago Marques]

Hi Maik, list,

I will try to answer your questions, but disclaimer first, camera trap distance sampling is not my thing, so I have no idea if there are any peculiarities there, in particular with respect to dsm's from it. I am going to assume the answer is no, and that a camera trap would be treated, for modelling in a dsm, as a point would. But I might be wrong and others might weight in. I am going to assume in this case a point=segment(line transects)=a camera trap(here). The dsm modelling will occur at the level of points.

First question: modelling type "count" just means that instead of the response variable in the underlying GAM being say a continuous variable (as abundance might be, since abundance per segment would be observed counts corrected for detectability), you can model the counts (i.e. use discrete families like the Poisson, but of course you could ry others, but I'd stick to that while investigating these issues, then you can move on to others, e,g, tweedie etc.), where the response is the uncorrected count, and the detectability correction comes into the model as an effective sampling area (segment area times detection probability), and that is included via an offset. The offset is set up underneath the hood for you (as you otherwise need to log it, since modelling a count you will likely use a link function - ignore this if you don't care about it, as I said, dsm does it for you). So doing "count" or "abundance" should be about the same at the end, really. If you use density, there's no offset used, but that means you need to check up there were done the required calculations to get the response to be density (observed count divided by probability of detection and point count area). It seems to me this just complicates you life, so  I'd stick to the other two options.

Second question and third question: these might be related, not sure. It could be that both relate to how you set up units for distances and areas. The mean density should be (about) the same for both methods, but note you need to be careful about how you set things up. I draw you attention to the argument "convert.units = 1" and "segment.area" in dsm, which might be involved in these issues. The fact that one estimate is half the other makes me wonder if there's something to do with the way the area of the points (here camera traps) is set up. Are you assuming 360º view? If not, are you accounting correctly for the FOV angle? The third question I am unsure what the answer is. From the predict.dsm help file, the offset term corresponds to the "area of each of the cells in the prediction grid. Should be in the same units as the segments/distances given to dsm.". Therefore, 1 is certainly NOT the value to be used in your case, unless e.g. your distance units were km and the area was provided in km, and you wanted to predict for cells of 1km2. Hence, I think that either 400m2 would be the correct value IF your distances were  measured in meters.

Can you tell us what was the right truncation distance you were considering? Are the size of the point counts about the size of the prediction cells?

If you can confirm the issues with units used for areas and distances that might help you finding out what is going on.

Hope this helped, let me know on the side if not, and then you can summarize what we find on the list.

Cheers,

T

---

From: distance...@googlegroups.com <distance...@googlegroups.com> on behalf of Maik Henrich <maik.he...@gmail.com>
Sent: Tuesday, June 17, 2025 9:59 AM
To: distance-sampling <distance...@googlegroups.com>
Subject: [distance-sampling] Adapting dsm for camera trap distance sampling

--
You received this message because you are subscribed to the Google Groups "distance-sampling" group.
To unsubscribe from this group and stop receiving emails from it, send an email to distance-sampl...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/distance-sampling/0afca597-c57b-4ef2-8f15-d44eb3656808n%40googlegroups.com.

[Eric Rexstad]

Maik

You might have a look at this paper for some guidance

• Delisle, Z. J., Miller, D. L., & Swihart, R. K. (2023). Modelling density surfaces of intraspecific classes using camera trap distance sampling. Methods in Ecology and Evolution, 14, 1287–1298. https://doi.org/10.1111/2041-210X.14093

They provide code in their supporting information and use count as the response in their gam

---

From: distance...@googlegroups.com <distance...@googlegroups.com> on behalf of Maik Henrich <maik.he...@gmail.com>

Sent: 17 June 2025 09:59

To: distance-sampling <distance...@googlegroups.com>
Subject: [distance-sampling] Adapting dsm for camera trap distance sampling

 

Dear everyone,

--

[Maik Henrich]

Hi Tiago and Eric,

thanks for your quick answers! This paper was actually my starting point. I tried adapting their code and then ran into the issues/ questions I could not answer, which I am describing above.

If count and abundance as responses should result in approximately the same numbers, it is even stranger that my mean predictions using abundance as a response are 10 times higher than using count as a response.

Maybe there is indeed something wrong in the way that I am accounting for the FOV angle. In the tutorial to the paper, it is stated that Effort = spatiotemporal effort of the camera trap, which is denoted by ek in Howe et al. (2017). So, the effort should be defined as Effort<-(angle in radians* deployment time in seconds)/(2*pi* snapshot interval in seconds). However, the definition of seg.area contains information on the FOV again: right truncation^2*(angle in radians)/2. Including this information twice seems a bit strange to me?

All the distances going into the model are measured in metres and my right truncation distance was 17.5 m. When I compute seg.area in the way I described it above, the resulting detection area per camera trap has a size of 174 m², less than half of the 400 m² of the prediction cell.

Any tips and ideas are appreciated.

Best,

Maik

[Tiago Marques]

Hi Maik,

From the help file on dsm, it is stated that "If segment.area is specified it takes precedent." which I interpret to mean that if you do include that argument,  the field "Effort" would not be used. Which actually might mean that all the info about time (deployment time and snapshot time), gets discarded. Could that be causing issues?

I guess the easiest would be to set up the "Effort" field adequately in the segment.data object (that is, including the truncation distance there too) and leave the segment.area as NULL?

Cheers,

T

---

From: distance...@googlegroups.com <distance...@googlegroups.com> on behalf of Maik Henrich <maik.he...@gmail.com>

Sent: Tuesday, June 17, 2025 5:34 PM
To: distance-sampling <distance...@googlegroups.com>
Subject: Re: [distance-sampling] Adapting dsm for camera trap distance sampling

To view this discussion visit https://groups.google.com/d/msgid/distance-sampling/22ed71bf-89bb-45b6-b727-e334cd78153dn%40googlegroups.com.

[Maik Henrich]

Hi Tiago,

 thank you! I tried defining Effort in the segment.data as  (angle in radians* right truncation distance in metres^2 * deployment time in seconds)/(2*snapshot interval in seconds) and not including seg.area.

Mean predicted count and abundance stay the same as in the dsm before (22.73 & 246.50), just the density estimate becomes a lot smaller (2.81e^-9 instead of 1.68). When the truncation distance is instead converted to km, the resulting density estimate is 0.00281.

Please let me know if you have any thoughts on this or any other ideas.

[Maik Henrich]

Hi everyone,

I managed to match the standard distance sampling and dsm approaches. The important point is indeed that "Effort" is ignored as soon as seg.area is defined.  The mistake that I figured out now is that the right truncation distance does not need to be specifed as it is extracted automatically from the detection function object. Segment area is calculated within the function by multiplying the spatio-temporal effort with the truncation distance.

This way, I got the exact same density estimate with standard CTDS as when predicting for the camera trap locations with a null model dsm: 2.653258 animals/km².

While I would just continue with density.est, I am still curious about the count and abundance estimates. For one camera trap location with a spatio-temporal effort of 100405.295, predicted  count is 19.081918 and predicted abundance is 247.09. How do I derive these numbers from the density estimate (seg.area is 0.000147 km² and mean detection probability is 0.1745)?

Thanks again for the help so far, Tiago!