`setup` and `pickup` as observationType

[peterdesmet]

trafficstars

Originally reported by @PatrickAJansen at https://github.com/inbo/camtraptor/issues/96#issue-1178267448 and split into 3 issues.

It would be logical and practical for users to adopt three additional values of observationType in observations.csv (2 of 3):

(2) "setup" and "pickup", for sequences that mark the start and end of the deployment. Currently, these are recorded as observationType="unclassified" with cameraSetup="TRUE". If we make this simple change, there is no longer any need for a separate variable cameraSetup.

[peterdesmet]

I think the original suggestion was to have those values included in observationType (#38), but it was decided to have a separate field because setup/pickup can be annotated further (see https://github.com/tdwg/camtrap-dp/issues/77#issuecomment-796756074) e.g. as human or vehicle.

Personally, I agree with @PatrickAJansen and I'm not entirely convinced by the annotating further argument, i.e. is it necessary/desirable to be able to distinguish between setup/pickup with human, vehicle or no further info? And if so, why can't the image then contain two observations? One with setup/pickup and one with human? Note that that is probably also what would happen for images with a human and a vehicle.

One issue might be that "All categories in [observationType] have to be understandable from an AI point of view." I'm not sure setup/pickup can be assessed by AI. @kbubnicki can you confirm this?

Note: if we add a value, I would opt for a single value and make no distinction between setup and pickup, cf. the current definition for cameraSetup: "true if the observation is part of the camera setup process (camera deployment, pickup, maintenance).

[kbubnicki]

I am against this proposal as it would mix two different concepts in one field. The observationType, as it is defined now, describes the content of media i.e. a type of observed objects (+ unclassified helper tag), while new proposed categories setup, pickup and calibration describe the process of managing a camera trap (or other sensor).

I do not think we can easily use AI to distinguish between setup and pickup and other human or vehicles observations.

If really needed I would suggest to change cameraSetup from boolean to a list of multiple categories describing camera management process (and probably also renaming this field).

Personally, I agree with @PatrickAJansen and I'm not entirely convinced by the annotating further argument, i.e. is it necessary/desirable to be able to distinguish between setup/pickup with human, vehicle or no further info? And if so, why can't the image then contain two observations?

I disagree. The annotation logic should be consistent for all types of observations, no matter if it is camera setup or not, if there is human or vehicle on an image this should be annotated. Of course you can have multiple observations per media (you have 2 species or 2 sexes on the same image etc) but I believe that mixing two different concepts as described above is a wrong idea.

[ben-norton]

Why is it necessary to distinguish between human, animal, and vehicle in a separate "type of" field? Couldn't I just look at the scientific name field to determine whether or not its a human or animal? I understand the additional implications for human (such as setup), but that should be defined elsewhere. A human might just walk in front of the camera in the middle of deployment. I think we should drop all of the fields regarding setup and pickup. All you need for data publishing purposes is the start and end of a deployment. All of the setup and pickup observations fall under one category of "don't use this for modelling".

[kbubnicki]

I still believe observationType is a very useful field to have, especially for AI applications (I stage classification).

I again propose to change cameraSetup from boolean to a list of multiple categories describing camera management process (and probably also renaming this field).

[peterdesmet]

@kbubnicki @yliefting cf. how captureMethod (time lapse, motion triggered) is associated with the media file, would it make sense to associate the camera management properties (setup, pickup, calibration) with the media file as well? I see some value in that. Or do you consider those properties open to (human) interpretation and thus better reserved for observations?

[lrdijkhuis]

As a frequent user of camtrap-dp exports from several agouit projects, I would like to propose a different category rather than "unclassified" for the observationType field in relation to a TRUE value for the cameraSetup field. Eventhough the process might refer to a setup, pickup, or calibration -action, the triggers are motion detection and the sensor is triggered by a human, and thus also should be defined as a human observation.

The annotation logic should be consistent for all types of observations, no matter if it is camera setup or not, if there is human or vehicle on an image this should be annotated.

This quote of @kbubnicki would be impossible after checking the switch for setup/pickup in the annotation process and additional annotation as human would be superfluously since these are in essence triggers made by humans. This argues in favour of assigning cameraSetup process actions to the human observationType. Secondly, observationType is a very useful field in filtering unviewed or unannotated photo sequences on the data-side of camtrap-dp without any knowledge of the annotation process. In the current situation calculating the fraction annotated will never return 1, and filtering sequences without any form of annotation will always return the sequences which are annotated as pickupSetup. In conclusion, the observationType "unclassified" for a cameraSetup value of TRUE is not correct and counter intuitive, since these are observations of a human in front of the camera trap.

[peterdesmet]

I discussed this with @kbubnicki:

1. We will retain the current definition and controlled vocbulary for observationType (comment by @kbubnicki) and not mix this with camera management information.

2. We will change cameraSetup from a boolean field to a controlled text field. The field is either:

• empty for images/events that are not the result of camera setup
• calibration for images/events that are used for camera (distance) calibration
• placement (suggested by @yliefting) for images/events that are the result of placing the camera, retrieving the SD card etc. As many systems do not differentiate between setup vs pickup (that can be derived from their timestamp in a deployment) we are looking for a single term. management sounded too vague, but placement might be too specific. setupPickup is also an option. Suggestions welcome.

The name of the field cameraSetup could be kept likely be kept, it aligns nicely with deployments.setupBy. That latter field could also be renamed to deployments.deployedBy.

3. @PatrickAJansen @lrdijkhuis we understand the frustration regarding this being clunky for filtering relevant observations (note also that e.g. filtering on motion detection vs time lapse required another field yet). We think however that easier filtering here could be implemented via camtraptor (ping @damianooldoni) rather than in the Camtrap DP model.

[peterdesmet]

Further discussed with @kbubnicki to better align terms names by using the word "management"

Deployments.setupBy

• [x] Keep name deployments.setupBy

• [x] Change definition from:

  Name or unique identifier of the person that deployed the camera.

  To:

  Name or identifier of the person or organization that deployed the camera.

observations.cameraSetup

• [x] Change from boolean to string

• [x] Rename from observations.cameraSetup to observations.cameraSetupType

• [x] Use the controlled vocabulary:

  setup
  calibration
  

• [x] Change definition from:

  true if the observation is part of the camera setup process (camera deployment, pickup, maintenance).

  To

  Type of the camera setup action (if any) associated with the observation.