Trap night callendar and deployements

[CrocutaLupus]

Hi,
I would like to start a discussion to find out what methods have been developed to track the effort within monitoring using camera traps.

Deployments are currently used to indicate that a camera trap is operating from a certain date (and time) to a later date (and time). If a camera trap has a technical or other problem (such as running out of battery or being covered in snow), it is possible to divide a deployment into several deployments. The result is a timeline with gaps. These gaps indicate that the capture effort was not 100% for this camera trap.

Because there's no deployment to save a comment or a variable, it is not possible to record information for these gaps. I personally use an additional trap night calendar. This calendar is a table with each camera trap having a line. Each cell is a trap night and can be working (1) or not (0). If not working I can indicate why.

A non-functioning camera trap can influence the observations taken in the study area. Models often take into account whether the camera trap was working (deployed) or not. The reason why a camera trap was not working can be interesting if it affects the estimation of a population size estimation for example. A broader confidence interval during a snowy winter for example.

How do you keep track of these camera trap problems (non-deployed time)?

Thanks in advance =)

[ben-norton]

@CrocutaLupus
For the purposes of data publishing, the rigid definition of a deployment is critical. It has its drawbacks, and you do an excellent job identifying a few of these (which we appreciate). There are ways to capture the information you describe using deployment groups without sacrificing the classes that make large-scale interoperability possible.
They were designed for a situation like this. Your criteria and objectives are clear, which is the prerequisite for the effective use of deployment groups. If you would be willing to assess the viability of deployment groups as a solution to your use case, then circle back with feedback, we'd greatly appreciate it.

[peterdesmet]

Hi @CrocutaLupus, thanks for submitting your use case. It is quite similar to the one mentioned in #354. I have commented there how you could potentially express failure times: #354 (comment).

I'm copying my answer here for easier reference:

I think we will stick with the requirement that a deployment has a single start and end, and not a more complicated start/end+start/end (for e.g. snow cover) or a start/end+a non-recording duration (for e.g. tree, failure).

Suggestions to express your use cases:

• Splitting deployments to duration when the camera was operational (for e.g. snow cover)
• Moving forward the deploymentEnd to when the camera was operational (for e.g. tree, failure)
• Creating extra deployments to cover the times a camera was not operational. Those would not have media files, but you can indicate failure type in e.g. deploymentTags or deploymentComments
• Using deploymentGroups to group split deployments together, which would then allow to calculate the full time a camera was out
• Using deploymentTags key value pairs to indicate failure time, e.g. failureDuration: 2020-02-03T08:03:00Z/2020-04-07T18:09:00Z | failureType: snow

Let me know if that works for you!