Add columns for unmarked population density estimation using video-recording camera traps

[kfukasawa37]

I propose some optional columns that enable us to apply a unmarked population density estimator using video-recording camera traps, REST model (Nakashima et al. 2018 J Appl Ecol doi.org/10.1111/1365-2664.13059).
This method is based on observations of staying time within a detection zone where all the individuals are certain
to be detected by the camera trap.
Adding the following columns in the deployments.csv and observations.csv is sufficient for applying REST models.

• detectionZoneArea in deployments.csv: Area (m^2, > 0) of the detection zone.
• stayingTime in observations.csv: Staying time (seconds, >= 0) associated with an observation. The value zero means that the observed individual did not enter the detection zone.
• stayingTimeCensoringtype in observations.csv: Censoring type of staying time complete; right; left; both. This column describes censoring due to specification of video recording that automatically stop filming after a designated time and cannot restart immediately even when the animals remain in front of the camera.

Similar to individualPositionAngle and individualSpeed for random encounter models, stayingTime and stayingTimeCensoringtype are defined for the observed individual identified by individualID. REST model is applicable to both event-based and media-based observations.

I'm preparing a more detailed explanation for description of staying time observations with an toy example. I'll post it later.

[kfukasawa37]

Thank you for adding it to a 1.1 milestone!
In this post I explain about the details for the proposed columns in detections.csv for media- and event-based data.

• Media-based observations

The figure below is a diagram of an example set of observations in which the X-axes are timeline, and Y-axis is individuals observed. The horizontal blue lines are periods when the individuals were in a detection zone. The bold and thin segments of blue line are recorded and non-recorded range, respectively. Observed staying time of each observation was also shown.

I assumed that ID2 stayed in a detection zone from the start of Obs2 to the end of Obs3 and it was reasonably determined as a continuous stay in the detection zone.
Different individualIDs can be given if the two consecutive detections can not be surely determined as the same individual. In such a case, we do not use a left-censored observation when we evaluate mean staying time.

I also assumed that ID2 exited a detection zone at the end of Obs3 and immediately re-entered. It would be a rare case.

The corresponding table is as follows (selected columns were shown).

observationID	mediaID	individualID	stayingTime	stayingTimeCensoringtype
Obs1	Video1	ID1	28	right
Obs2	Video1	ID2	20	right
Obs3	Video2	ID2	8	left
Obs4	Video2	ID2	5	complete
Obs5	Video2	ID3	30	both

• event-based observation
  Consecutive media-based observations (Obs2 and Obs3 in media-based obs) are merged into an event (Obs23) if they can be determined as a continous stay in a detection zone.

The table of event-based data would be simpler than the media-based data.

observationID	eventID	individualID	stayingTime	stayingTimeCensoringtype
Obs1	Obs1	ID1	28	right
Obs23	Obs23	ID2	43	complete
Obs4	Obs4	ID2	5	complete
Obs5	Obs5	ID3	30	both

• Missing values in stayingTime
  For both media-based and event-based data, missing values in stayingTime at random can be dealt with by REST models. However, a zero value (i.e. an observation that an individual was recorded but never entered into a detection zone) must not be missing, because we have to omit it from the number of encounters to estimate population density. Another possible option would be further adding a binary column whether an individual entered into a detection zone if someone considers that this missing value rule is too complicated.

(Figures in this post were made through discussions with Dr. Yoshihiro Nakashima.)

[peterdesmet]

Thanks for the clear explanation. Regarding the use case where stayingTime = 0: how would the observer know an individual is there if it did not enter the detection zone? Is this a common use case?

[peterdesmet]

I understand the use case and the proposed fields. I have some suggestions on naming, but I'm wondering if this information could not be expressed as timestamps for entry and exit:

With Video1 lasting from T0 to T1 and Video2 from T2 to T3

Alt 1: Two extra timestamp fields

observationID	mediaID	eventStart	eventEnd	individualID	stayingStart	stayingEnd
Obs1	Video1	T0	T1	ID1	T0.2	T1
Obs2	Video1	T0	T1	ID2	T0.4	T1
Obs3	Video2	T2	T3	ID2	T2	T2.3
Obs4	Video2	T2	T3	ID2	T2.6	T2.9
Obs5	Video2	T2	T3	ID3	T2	T3

observationID	eventID	eventStart	eventEnd	individualID	stayingStart	stayingEnd
Obs1	Obs1	T0	T1	ID1	T0.2	T1
Obs23	Obs23	T0	T3	ID2	T0.4	T2.3
Obs4	Obs4	T2	T3	ID2	T2.6	T2.9
Obs5	Obs5	T2	T3	ID3	T2	T3

• More intuitive
• Arguably easier
• Allows to calculate seconds as stayingEnd - stayingStart
• Allows to calculate censor as:
  • both: stayingStart == eventStart && stayingEnd == eventEnd
  • left: stayingStart == eventStart
  • right: stayingEnd == eventEnd
  • complete: stayingStart > eventStart && stayingEnd < eventEnd

Alt 2: Using eventStart/eventEnd + censoringtype

And while we are using start and end timestamps to express stays, we might as well use eventStart and eventEnd: they are designed to capture temporal windows, so they don't necessarily need to align with the video start and video end. They can be used to capture the specific time an individual was seen. If we use those fields, we likely need to reintroduce the censor field (as just one extra observations field in Camtrap DP). The presence of values in that field would also indicate that eventStart and eventEnd are restricted to the staying time of an individual.

observationID	mediaID	eventStart	eventEnd	individualID	stayingTimeCensoringtype
Obs1	Video1	T0.2	T1	ID1	right
Obs2	Video1	T0.4	T1	ID2	right
Obs3	Video2	T2	T2.3	ID2	left
Obs4	Video2	T2.6	T2.9	ID2	complete
Obs5	Video2	T2	T3	ID3	both

observationID	eventID	eventStart	eventEnd	individualID	stayingTimeCensoringtype
Obs1	Obs1	T0.2	T1	ID1	right
Obs23	Obs23	T0.4	T2.3	ID2	complete
Obs4	Obs4	T2.6	T2.9	ID2	complete
Obs5	Obs5	T2	T3	ID3	both

The stayingTime can be still be captured as:

IF stayingTimeCensoringtype NOT NULL:
  eventEnd - eventStart

Would that cover the use cases you have?

[kfukasawa37]

Thank you for your consideration about my proposal!

Regarding the use case where stayingTime = 0: how would the observer know an individual is there if it did not enter the detection zone? Is this a common use case?

Yes, it is a common use case. A detection zone is an area where an animal is certainly detected and smaller than the viewshed of the camera trap in general. An animal walking outside a detection zone can be captured by a camera trap by chance with probability less than 1.
This figure is an example of animal path which is captured by a camera trap but the staying time is 0.

Alt 1:
Alt 2:

I understood that it is preferable to record entry and exit times rather than a staying time.
Alt 1 can describe entry and exit times in a detection zone additional to eventStart and eventEnd. It can cope with the situation that a recorded individual passed outside the detection zone if stayingStart and stayingEnd are left blank. However, it can lead a malfunction of a density estimation program if significant digits of time values regarding "event" and "staying" are not equal.
Alt 2 is robust to significant digits because stayingTimeCensoringtype defines the procedure to each row of data in the population density estimation. However, eventStart and eventEnd are difficult to be defined for a record that an individual passed outside the detection zone if we consider them as the time of entry and exit of a detection zone.

For both alternatives, I want to include information to distinguish whether the staying time is missing or the individual passed outside the detection zone. It is because we can define staying time as 0 for such a record but can not define the time of entry and exit.

To solve these issues, could you consider the following modifications to Alt 1?

• Adding stayingTimeCensoringtype

• Allowing stayingTimeCensoringtype to have a value missing for a record with unobserved staying time. We can leave it blank for a record that an individual passed outside the detection zone.

Alternatively, if you want to avoid adding a more column type,
allowing stayingTimeCensoringtype to have a value missing in Alt2 also works for a population density estimation.
However, it can not solve the difficulty in defining eventEnd and eventStart for a record that an individual passed outside the detection zone within viewshed of camera.

If I have misunderstood your intent, please let me know.