Closed peterdesmet closed 10 months ago
It would be ideal to somehow use the infared heat detection aspect of the capture event. That is important in the broader community that animals like reptiles aren't readily detected using PIR sensors. If you went with detection then you lose that infared context. It becomes somewhat arbitrary how the animal was detected. A new technology/technique might make its way down the pipeline to camera traps that's distinctly different than infared. Maybe infaredDetection, thermalDetection?
Discussed with @kbubnicki. We want to keep the very broad categorization for this term. More specific (infrared, thermal, etc.) might be harder to provide by users and there is currently no use case for it. Suggested changes:
activityDetection
to express the broad concept of "sensor detected activity through undefined method". This would then also include the audio detection of a non-moving stridulating grasshopper, which is would be excluded by the current term motionDetection
.Predefined duration after detection when further activity is ignored. Expressed in seconds.
We currently allow 2 values for captureMethod:
@dhobern indicated that
timelapse
is pretty straightforward, butmotionDetection
might be a bit too narrow a term to express that the camera automatically detected something, resulting in a trigger that captured the media. PIR sensors use a combination of motion and heat to trigger the camera and if we want to eventually allow audio sensors, then it might just be sound (not motion) that is used to capture a media file.We could rename to:
trigger
: cf. https://docs.gbif-uat.org/camera-trap-guide/en/#trigger, but the term is also used to indicate the series of images captured as result of a triggerdetection
: quite a broad term, but fits nicely with e.g. detectionDistanceactivityDetection
: a bit narrower, while still leaving it open how it was measured.I prefer
detection
.I would also rephrase cameraDelay:
To remove the term
trigger
altogether