Detection Efficiency Function

[jdpye]

In GitLab by @benjaminhlina on Feb 22, 2021, 15:04

Hi Chris and Jon,

I recently was going though some of my detection range data from this past year and realized I had a function built to be able to quickly use either a third order polynomial, probit, or logit model to calculate distance from a receiver per predicted detection efficiency e.g. distance at which a tag is heard 50 % of the time. The function relies on the output of vemco's detection range software from a preliminary range test and range testing methods similar to Brownscombe et al. 2020. Would something like this be of interest to the package?

Cheers,
Ben

[jdpye]

In GitLab by @benjaminhlina on Feb 22, 2021, 15:05

changed the description

[jdpye]

In GitLab by @benjaminhlina on Feb 22, 2021, 15:05

changed the description

[jdpye]

In GitLab by @chrisholbrook on Feb 23, 2021, 17:47

@benjaminhlina Functions to support detection range analysis have been proposed in the past, but haven't been added yet because of lack of standard inputs and consensus best practices. @thayden et al have taught a workshop on the topic (material available here). I like that you are using a standard input format and connecting it to a published method. Send some code (post or email me) and we can take a look.

[jdpye]

In GitLab by @benjaminhlina on Feb 24, 2021, 12:06

@chrisholbrook Thanks for the link to the workshop which goes through things very well. I've made snippet 232 to share this with you. Please let me know what you think. Cheers

[jdpye]

In GitLab by @chrisholbrook on Mar 2, 2021, 18:28

@benjaminhlina This would be a welcome new feature. If you are up for it, start a new feature branch off dev, add your function as a new file to /R, example data to /data (or /inst/extdata and /data-raw to include a raw data file), and tests to /tests/testthat. A short vignette in /vignettes would also be helpful. Submit a merge request and we'll review and release with next minor version. Any questions, let me know.

[jdpye]

In GitLab by @benjaminhlina on Mar 3, 2021, 10:12

@chrisholbrook Awesome, thanks sounds good to me. I'll start a new branch and work on this in the upcoming days.

[jdpye]

In GitLab by @benjaminhlina on Mar 3, 2021, 14:45

@chrisholbrook I know functions, argument, and data naming conventions are as such ex. walleye_detections. Is there any particular name for the example preliminary range finding data that would be preferred? In the snippet I had the object named total_de for my own scripts, but that doesn't really make sense for the package. For the package would something like preliminary_detection_efficiency work or is this too long. Open to suggestions. Thank you for inviting me to contribute to the package.

[jdpye]

In GitLab by @chrisholbrook on Mar 3, 2021, 15:23

@benjaminhlina I'm not too concerned with length, but 'preliminary' might be misinterpreted, so consider 'sample_' or some other prefix that represents its purpose or source. Also, please document the data set in /R/data.r.

[jdpye]

In GitLab by @benjaminhlina on Mar 3, 2021, 15:39

sounds good to me and will do.

[jdpye]

In GitLab by @benjaminhlina on Mar 15, 2021, 23:56

@chrisholbrook I pushed last week the new function, dataset, tests, and manuals to the branch I started. I am still working on the vignette which I hope to have done by the end of this week. I'll then submit a merge request if things all look fine.