Closed PatrickAJansen closed 5 months 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 :-)
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.
@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.
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.
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
@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). ☺️
@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.
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?