inbo / camtraptor

Camtraptor is an R package to read, explore and visualize Camera Trap Data Packages (Camtrap DP)
https://inbo.github.io/camtraptor/
MIT License
10 stars 2 forks source link

Add a separate locations table to the camtrapdp #203

Closed PatrickAJansen closed 5 months ago

PatrickAJansen commented 1 year ago

I would prefer to see a separate "locations" table in the camtrapdp, like implemented by Henjo de Knegt. See https://wec.wur.nl/r/ctdp/. Is there any particular reason why we do not have one?

jimcasaer commented 1 year ago

Patrick,

As far as concerns camtrap-DP I leave it to Peter and others to give comments

For our own projects we prefer to determine ourselves the "location" that we use for the analyses (such as creating effort-analyses, creating observations per location or doing occupancy analyses and Nmixture), given that in some projects where cameras do not move the location stays the same between deployments (and equals the coordination of the camera as included in the deployments in Agouti right now) but for other projects where the same grid cell (location) is visited several times the exact camera location coordinates (as saved now in the deployments) does not fully equals the "location" - being the grid cell in this case -- looks to me there is still to much ecological difference in the way location is defined in the subsequent analyses to have a seperate standardised tabel of locations that suits all projets - open to discussion the next time we hangout :-)

damianooldoni commented 1 year ago

Thanks @PatrickAJansen. Your question seems basically a question related to the format, i.e. camtrap DP, so probably it's better to move it to https://github.com/tdwg/camtrap-dp/issues. I leave @peterdesmet to choose about it. Still, important to have this investigated.

peterdesmet commented 1 year ago

@PatrickAJansen In Camtrap DP, we decided to "flatten" deployment info, location and duration into one deployments.csv for simplicity. Flattening is quite common in data transfer formats. As @jimcasaer indicates, it allows flexibility for the data user and typically leads to less questions for the data producer, such as "should we assign habitat to the location or deployment. What if it changes over time?"

That said, camtraptor (the software) could provide functionality to pull unique locations from the deployments.csv, optionally based on user settings.

damianooldoni commented 1 year ago

Indeed, if needed, we could add a get_locations() function. This would return the unique locations. Eventually the centroid of the lat-lon values of all deployments sharing the same location can be returned as well. And all lat-lon of the deployments within same location could be returned as well as a list. We could discuss about it.

PatrickAJansen commented 1 year ago

I do not recognize the problem of point properties changing over time. I do see the problem that location info gets replicated when deployments are repeated at fixed point as happens in monitoring programs. Such replications is against the principles of database design.

Anyway, Henjo de Knegt already wrote a function to extract the locations in his package ctdp.

It

peterdesmet commented 1 year ago

@PatrickAJansen I agree this is against the principles of good database design, where data are managed. It is not against the principles of a data exchange format, where data are filtered and used (similar to a database view). ☺️

peterdesmet commented 5 months ago

@PatrickAJansen the package camtrapdp now has a function (cf. ctdp) that extractions locations: https://inbo.github.io/camtrapdp/reference/locations.html It might be ported to camtraptor as well.