Feature request: `append_activity_data`

[MartijnUH]

@damianooldoni in my opinion it would be nice to have a function that takes the output from get_record_table and adds two additional columns "clock" (clock time of the observation in radians) and "sun" (sun time of the observation in radians) that are frequently used by users of camera trap data to calculate daily activity levels, using the function activity::fitact. This would extend the possible workflows of camtraptor, which is now compatible with the unmarked package for analyses of occupancy and abundance-estimation, towards analyses of activity patterns using the activity package.

get_activity_data.zip: contains a minimal data example.

Things we need to decide are:

• adjust get_record_table such that it automatically, or after calling a new boolean argument, appends clock and solar (Note: I refer to this as get_activity_data, but I thinkt it would be better to retain the name get_record_table for this) OR a new function append_activity_data that appends these columns after first calling get_record_table and another (potentially new) function get_coordinates.
• always append columns longitude, latitude, clock and solar OR let the user choose which cols (e.g. only solar)
• potentially, but this is on a more thecnical note, let users decide which type of function (overlap::sunTime or activity::solartime), and anchoring they would like to use for the computations of solar

@damianooldoni, @jimcasaer any other thoughts on this?

[damianooldoni]

About using overlap::sunTime or activity::solartime, the question is technically important: if we allow the users to choose, it means we have to add two dependencies to the package instead of one. I would avoid it, unless there is a real major benefit. @MartijnUH: can you help me about this? Is there a way to choose between the two? Is there a conceptual difference between the two?

After briefly discussing all the options with @peterdesmet, we think that the best way would be to add the 4 new columns directly in the output of get_record_table() unless using the returned record table in other functions will return errors. If this is the case, we could add a boolean argument where the columns are not added by default. But I am not a big fan of flags 🎏 @MartijnUH: can you help me about this?

[MartijnUH]

About using overlap::sunTime or activity::solartime, the question is technically important: if we allow the users to choose, it means we have to add two dependencies to the package instead of one. I would avoid it, unless there is a real major benefit. @MartijnUH: can you help me about this? Is there a way to choose between the two? Is there a conceptual difference between the two?

The difference is not so much technical, but rather methodological in nature. The overlap::sunTime essentially uses an approach which is described in Nouvellet et al. (2012), while the activity::solartime uses approaches developped by Vazquez et al. (2019) (who critized the Nouvellet et al. approach). @jimcasaer and I have repeatedly discussed this, and do not see the need to adopt the Vazquez et al. approach. But our end-users might be of a different opinion, which is why I suggested to implement both. For in-house usage, I think sticking to the overlap::sunTime functionality would be just fine.

After briefly discussing all the options with @peterdesmet, we think that the best way would be to add the 4 new columns directly in the output of get_record_table() unless using the returned record table in other functions will return errors. If this is the case, we could add a boolean argument where the columns are not added by default. But I am not a big fan of flags 🎏 @MartijnUH: can you help me about this?

I absolutely agree with this. Just adding the 4 new columns would be the way forward I beleive.

[MartijnUH]

@damianooldoni I just had a meeting with @jimcasaer. He agreed that you can go forward with the overlap::sunTime approach.

[damianooldoni]

Thank you. I was indeed planning to do that and mention it in the documentation of the function. I will also mention that we are open to use other methods, e.g. Vazquez 2019, if somebody justifies the need to do so. I will try to handle this feature request on Wednesday, Nov 20.