Remove read_wi() from camtraptor

[Rafnuss]

I'm still a bit confused about the different between camtrapdp and camtraptor` or more precisely, why are the underlying data package object in R not the same object in both R package.

For instance, I'm using read_wi() to read my wildlife insight dataset, and I would like to create a Camera Trap Data Package. How can I do this? In. camtraptor, I only have write_dwc() and write_eml().

I also really like the filter functions (e.g. filter_deployments()) from camtrapdp, how can I use them?

Overall, it seems like read_wi() should actually belong to camtrapdp in my opinon as the core aim of this function (at least in my sense) is to convert a wildlide insight dataset to the camtrap data package standard. I would then love to be able to use the datapacakge object in R also with the functionality of camtraptor, but that's more of a secondary aim.

[damianooldoni]

Indeed, in my opinion as well: read_wi() should belong to camtrapdp. @peterdesmet, @sannegovaert?

We are also moving camtraptor to read Camtrap DP version 1.0 (see the dev branch version-1.0. At the moment, camtraptor is still downconverting to v 0.1.6. So, we are going towards a major changing release of camtraptor, from 0.x to 1.0. It's a big refactoring, which indeed is taking a lot of time, but I hope to complete before spring 2025. One of the most important aspects is that we will reexport (some) camtrapdp R package functions, such as the filter_*() and the read_camtrapdp() functions. In this way camtraptor users do not need to explicitly load camtrapdp as well. Of course, camtrapdp will be a dependency of camtraptor. Notice that this is already implemented in dev branch version-1.0.

In this way:

1. camtrapdp R package will focus on implementing reading and manipulation core functions = light package which GBIF also can use to support camtrapDP as data format.
2. camtraptor R package will remain the R reference package for users and it is build upon camtrapdp, i.e. will includes the camtrapdp's functions which are relevant for the users, together with many other functions which are not necessarily basic core functions for camtrapdp. An example, already implemented in version-1.0 branch: the filter_out_timelapse() function.

@Rafnuss: I understand this can be quite complex: if you want, we can have an online meeting? Please, contact me at damiano.oldoni@inbo.be. I will be happy to meet you.

[peterdesmet]

to convert a wildlide insight dataset to the camtrap data package standard

@kbubnicki and I had a call with Jorge Ahumada from Wildlife Insights late October. He said that a Camtrap DP export is still on the roadmap for Wildlife Insights. It also makes much more sense that that functionality is controlled by them, so they can adapt it if necessary. So a read_wi() is neither in scope for camtrapdp or camtraptor.

[damianooldoni]

Thank you @peterdesmet for the announcement. I will remove the function in dev version of camtraptor then.

[Rafnuss]

Thanks @damianooldoni for the explaination! It all makes perfect sense, looking forward to this v1.0. I probably should have use the branch version-1.0, but I managed to get around with converting my dataset back and forth... Not ideal, but this is a side project of holiday/weekend.

@peterdesmet , great to hear about the plan to possibility export WI as Camtrap-DP!