FAQ

How to describe bounding boxes of detected objects?

In Camtrap DP, in the observations table there are four terms used to describe bounding boxes: bboxX, bboxY, bboxWidth, and bboxHeight. The values for all these fields are numbers between 0 and 1, relative to the image size.

The bboxX and bboxY fields represent the coordinates of the top-left corner of the bounding box. bboxX is measured from the left edge of the image, while bboxY is measured from the top edge. bboxWidth represents the width of the bounding box, measured from its left edge to its right edge. Similarly, bboxHeight represents the height of the bounding box, measured from its top edge to its bottom edge.

How to describe multiple events related to a single resource?

Multiple records in the observations table can reference the same media. See this GitHub issue.

How to handle multi-camera deployments?

See this GitHub issue.

Can I describe plant or fungus observations using camtrap-dp?

Currently, possible values for the observationType field in the observations table are: animal, human, vehicle, blank, unknown and unclassified. This definition does not allow for observations of plants or fungi.

If you have a use case for describing non-animal observations using camtrap-dp, please let us know in this GitHub issue.

How to include measurements in a data package?

There are two ways to include additional information (values not covered by the standard fields) in a camtrap-dp data package:

Using tags

Deployment and observation tables include deploymentTags and observationTags fields. These fields can be used to store additional information as pipe-delimited key:value pairs. For example, this is how temperature and snow cover information could be represented in the deployment table:

There are some drawbacks to using this method. Storing additional information in the media table is not possible, since it does not contain a tags field. Additionally, data represented this way is difficult to parse.

Using a custom table

A custom table can be added to the data package to store additional information. This requires providing a schema for the additional table. The schema must include a foreign key to the referenced table (deploymentID, observationID, or mediaID) and the additional fields. Here is an example schema for the deployment measurement table:

{
    "name": "deployment-measurements",
    "title": "Deployment measurements",
    "description": "Table with weather measurements for deployments. Associated with deployments (`deploymentID`).",
    "fields": [
        {
            "name": "deploymentID",
            "description": "Identifier of the deployment. Foreign key to `deployments.deploymentID`.",
            "skos:broadMatch": "http://rs.tdwg.org/dwc/terms/parentEventID",
            "type": "string",
            "constraints": {
                "required": true
            },
            "example": "dep1"
        },
        {
            "name": "temperature",
            "description": "Temperature (in Celsius) at the time of the observation.)",
            "type": "number",
            "constraints": {
                "required": false,
                "minimum": -50,
                "maximum": 100
            },
            "example": 19.5
        },
        {
            "name": "snowCover",
            "description": "Snow cover present at the time of the observation.",
            "type": "boolean",
            "constraints": {
                "required": false
            },
            "example": true
        }
    ],
    "foreignKeys": [
        {
            "fields": "deploymentID",
            "reference": {
                "resource": "deployments",
                "fields": "deploymentID"
            }
        }
    ]
}

The schema has to be added to the datapackage.json file in the resources field.

This is an example table following the schema above:

We recommend this approach for storing additional information. It allows for easier parsing and merging of tables and is more flexible than using tags.

For more details, see this GitHub issue.

How to merge data packages describing different projects?

By design, a single camtrap-dp data package describes a single project. However, there are some use cases (for example, a meta-analysis) where merging multiple data packages could be beneficial.

We provide an R package to read and manipulate camtrap-dp data packages. The R package includes the merge function, which can be used to merge two data packages into one. The resulting data package will be in a valid camtrap-dp format and can be published.

Refer to the merge function documentation to understand how specific fields are merged to avoid information loss. Please note that when merging data packages x and y, the project$samplingDesign field in the resulting package will be set to the value of project$samplingDesign from data package x. Therefore, we recommend merging data packages only for projects that use the same sampling design.