Challenges translating my data architecture to Camelot

[Michael Walsh]

Hi All, I'm new to this group and to Camelot, so apologies if my question is a bit rudimentary. I'm having some difficulty in how best to structure my camera trap data given my understanding of the architecture of Camelot. My camera trap data are organised by site and then deployment in my home directory, and this seems to be where I am having some trouble in translating how best to represent this in Camelot. I will use a hypothetical example to illustrate.
Let's say I have 4 sites, and at each of two of these sites (say, A and B) I have a camera set up for a 2-week deployment.
At the end of the 2 weeks the two cameras are pulled and deployed at the other 2 sites (C and D) for a 2-week deployment.
At the end of that 2 weeks, the two cameras are pulled and re-deployed at the first 2 sites, A and B, for another 2-week deployment. And so on, cycling between the sites for several 2-week deployments for each site over the course of six months.
The directory structure for the camera images on my hard drive then looks something likes this:
/Home/CamerSurvey/SiteA/Date_deployed_1/
/Home/CamerSurvey/SiteA/Date_deployed_2/
/Home/CamerSurvey/SiteB/Date_deployed_1/
/Home/CamerSurvey/SiteB/Date_deployed_2/ ...etc...

The problem I'm having with Camelot is how best to represent these deployments, which are critical for the detection histories at each site. After reading through all the documentation, my best understanding is that Camelot structures its "stations" as deployments since, when you add a station to a camera, the activity of the station is specifically organised around its deployment dates and any subsequent "camera checks" until the date at which the station is no longer "active in the field" and the camera again becomes "available for use" to assign to another station. This is the first approach I have tried such that I have included each deployment at a specific site as a new (i.e. distinct) station in Camelot. The problem that I then have is that in exported data (specifically, the "Camera Trap Export" table and the "Record Table" for use with CamtrapR as derived from the Reports facility of the software) end up with the deployments as the units of the analysis rather than the sites since I have included each deployment (within-site) as its own station. So, for example, I'm getting detection histories by deployment rather than site, and so too in reports I'm getting species richness, or individual species occupancy, by deployment rather than by site, when what I really need is those deployments for determining detection histories for each site so I can get occupancy, etc. by site. As an alternative second approach, I tried including the site itself as the station instead of each deployment, and simply repeating most of the information for the station (e.g. station name, geographic coordinates, etc) but with different deployment dates for each instance of the same station. The problem here is that the exported camera trap table then has multiple entries (i.e. each deployment) for each station since, in this scenario, "station" represents the site and so the station name is repeated for each deployment, i.e. non-unique stations in the table.
I've read through the software documentation at (https://camelot-project.readthedocs.io) several times, but I can't seem to find a clear path for the best approach to take in structuring the data. This particular line in the "Manage camera trap stations" section is what led me to believe that my deployments had to be considered as the "stations" in the software (i.e. my first approach described above):
"If a check was submitted where there are now no cameras at a trap station, that trap station is no longer active and will no longer be available for management. If this happens there’s nothing stopping you from adding a new camera trap station at that location later on, but right now, Camelot knows photos aren’t being taken, and will take care of
finishing it up for you.".

Also, a huge thanks to the Camelot development team for creating and supporting such a wonderful piece of open source software! Camelot is truly well-crafted with tremendous utility and flexibility. And the data export options are invaluable.
Best wishes,
Mike

[Heidi Hendry]

Hi Mike,

Apologies for the very slow response on this. Did you sort this out for yourself?

And on behalf of Chris and myself, thank you for the praise too!

Regards

Heidi