create file similar to camtrapR's recordTable

[jimcasaer]

An important feature of camtrapR is that it creates a detection history that can be used as an input for occupancy modelling in the unmarked package.

To do this the detectionHistory command is used in camtrapR
This command uses two objects

• the recordTable (having information on the recorded observations of animals (in our case sequences ))
• the camOp (matrix containing information on the daily camera station operability) and is created based on cameraOperation command in camtrapR

=> given this functionality and the use of camtrapR by many users it would be good to create two function in camtrapdp

• one to create a table having all columns found in the recoredTable
• one to create a matrix based on the format of camOp

all information can be found here: https://cran.r-project.org/web/packages/camtrapR/index.html

[damianooldoni]

I think it would be better to write a function which transforms a camtrap datapackage in a camtrapR-like input (recordTable and camOp). See jniedballa/camtrapR#14

In this way you can continue to work with camtrapR, which is the eind goal of this work in this package: developing something, testing it thouroughly and then trying to adding it in an existing package, ideally camtrapR.

[jimcasaer]

@damianooldoni : isn't that the same as what I was saying? write one (or two) functions in camtrapdp to create a recordTable and camOp like object for further use in camtrapR ?

[damianooldoni]

If recordTable and camOp are all we need to fully map a camtrap datapackage to be used in camtrapR, then yes, it's the same. 👍

[damianooldoni]

Based on https://jniedballa.github.io/camtrapR/articles/camtrapr3.html, I will document here the mapping of the output of camtrapdp::recordTable() based on camtrap datapackage standard.

column	content	camtrapdp standard (observations df)
Station	the station the image is from	location_name
Species	species name	scientific_name
DateTimeOriginal	Date and time of record in R-readable format	timestamp
Date	record date	lubridate::date(timestamp)
Time	record time of day	hms::as_hms(timestamp)
delta.time.secs	time difference between record and last (independent) record of same species at same station / camera* (in seconds)	derived from observations, see below
delta.time.mins	time difference between record and last (independent) record of same species at same station / camera* (in minutes)	derived from observations, see below
delta.time.hours	time difference between record and last (independent) record of same species at same station / camera* (in hours)	derived from observations, see below
delta.time.days	time difference between record and last (independent) record of same species at same station / camera* (in days)	derived from observations, see below
Directory	directory the image is in	multimedia$file_path without multimedia$file_name
FileName		multimedia$file_name

To derive delta.time.* columns, first derive a duration column, we call it delta.time

library(dplyr)
obs <- camtrapdp$observations 
obs <- obs %>% 
  filter(!is.na(scientific_name)) %>%
  group_by(scientific_name, location_name) %>%
  arrange(timestamp) %>%
  mutate(delta.time = lead(timestamp) - timestamp)

Once we have delta.time, it's easy to get all the delta.time.* columns:

obs <- obs %>% 
  mutate(delta.time.secs = as.numeric(delta.time)) %>%
  mutate(delta.time.minutes = delta.time.secs/60) %>%
  mutate(delta.time.hours = delta.time.minutes/60) %>%
  mutate(delta.time.days = delta.time.hours/24) %>%
  select(delta.time.days)

@peterdesmet: could you please give a look, I think this mapping it's quite smooth, but maybe I am missing something. In the meantime I will go further studying the mapping of camOp.

[jimcasaer]

@damianooldoni
the station is not the deployment ID but the location_name / or part of the location_name (depending on the project)

[damianooldoni]

Thanks @jimcasaer. I have just replaced deployment_idwith location_name in the mapping table above.
Could be a way to flag when station is the location_name and when it's a part of it? Can you give me an example of stations which are only a part of the location_name?

[damianooldoni]

@peterdesmet: while calculating the camera operation matrix, camtrapR package makes a distinction among camera(s) not set up (value NA) and camera(s) not operational (value 0). I wonder whether we have such a distinction in cameratrap datapackage standard.

[peterdesmet]

@jimcasaer are there ever deployments created that did not result in photos (i.e. because the camera turned out to be defunct). Are there deployments were the camera malfunctioned halfway?

@damianooldoni the short answer I think is that we have no structured or unstructured information on malfunctioning cameras.

[peterdesmet]

Some remarks:

• Note that the delta.time is per species and location, so you need to `group_by(scientific_name, location_name)
• Directory could be a single value, but FileName will contain a 10+ list of names. Neither values will be super useful to the user. A list of full URLs might.

[damianooldoni]

About delta.time: thanks, @peterdesmet. I updated the chunk code above adding location_name to the group_by().

I will check further what best for fields directory and filename. The main difference is that we store URLs, while camtrapR thinks in directories with files within.

[jimcasaer]

Thanks @jimcasaer. I have just replaced deployment_idwith location_name in the mapping table above.
Could be a way to flag when station is the location_name and when it's a part of it? Can you give me an example of stations that are only a part of the location_name?

in the GMU 8 project, the same 'location'/'gridcel' is visited twice a year, however, the exact location can change between surveys, therefore, the location_id changes (cameras are moved - 6 months interval). The location_name in this project includes both the year, the survey and the grid cell (e.g. 2018_4_1062). For detection histories and multiseason occupancy models revisiting the same grid cell is the issue - therefore location, in this case, equals the grid cell and we often first create a new column called 'grid'.

In many other projects (surely if camera's do not move between deployments) -- location_name does reflect the location of the camera and can be used to specify the 'station'.

I would suggest to use as a default in this function the location_name but allow users to specify another column.

[peterdesmet]

@jimcasaer so it is by design (and a bit of an exception) in GMU8 that locations that are revisited do not get the same location_name?

[damianooldoni]

Any discussion about camOps should be posted in the new issue #44. This issue will be reserved for recordTable.

[damianooldoni]

This issue can be closed as a record table can be generated now via this package. For any improvement, please open a new issue.