detection_range_model function #162
Conversation
…ument calls, and examples
…st tests for warnings and errors
…lied to detection_range_model
# Conflicts: # DESCRIPTION
…ng documentation. Vignette is in the works for this.
…+ bx^2 + cx +d = 0 does not follow namming conventions in R as c should not be used. Replaced c with d and d with f.
|
@benjaminhlina is looking to revamp this a bit before he officially submits it to glatos. |
Merge branch 'main' of https://github.com/benjaminhlina/glatos into main # Conflicts: # DESCRIPTION
| map(~ st_buffer(dist = .x$distance, rcv_osc_sf_12)) %>% | ||
| bind_rows(.id = "distance") %>% | ||
| st_cast("LINESTRING") %>% | ||
| dplyr::select(distance, glatos_array, station_no, ins_serial_no, geometry) |
There was a problem hiding this comment.
Warning message:
In st_cast.sf(., "LINESTRING") :
repeating attributes for all sub-geometries for which they may not be constant
There was a problem hiding this comment.
This is a common warning with st_cast() when geometry lengths differ.
There was a problem hiding this comment.
I agree this is lower priority than other warnings I've flagged here (so OK releasing in this form with intent to clean up later), but readers not familiar with sf will appreciate you explaining to them what this means. In this particular case, this warning tells you that you are making an assumption that all geometries have the same attributes--there are consequences if this is not true. If we intend to show/teach best practices here, this should be cleaned up in the code (set attributes constant among geometries; or run the operation separately on each geometry) so that the warning isn't generated.
| #| title: transform, view and filter | ||
|
|
||
| buffer_rings_pts <- buffer_rings %>% | ||
| st_cast("POINT") %>% |
There was a problem hiding this comment.
Warning message:
In st_cast.sf(., "POINT") :
repeating attributes for all sub-geometries for which they may not be constant
There was a problem hiding this comment.
This is a common warning with st_cast() when geometry lengths differ.
| #| title: save excel and gpx file | ||
|
|
||
| # save as excel | ||
| openxlsx::write.xlsx(deploy_sites, "YOUR_FILE_PATH.xlsx") |
There was a problem hiding this comment.
Error in is.nan(tmp) : default method not implemented for type 'list'
There was a problem hiding this comment.
So if this chunk is meant to be as an example of what someone could use, the chunk has echo = TRUE and eval = FALSE so that when it knits the rmd it doesn't actual run but when running each chunk I found it also to produce the error. I can remove this all together if you'd like but originally wanted to demonstrate how to export these objects.
There was a problem hiding this comment.
Your reader doesn't know that eval = FALSE; that just prevents it from running/breaking on build. All code chunks should run, in order encountered in the document, without error. If not, it should be made very clear to the reader why not and give them some pointers on what to do about it. If that can't be done here, then I suggest just remove the code block and joint point the reader to openxlsx::write.xlsx() (in text, not code) as a function they might be able to use.
| openxlsx::write.xlsx(deploy_sites, "YOUR_FILE_PATH.xlsx") | ||
|
|
||
| # save as gpx | ||
| st_write(deploy_sites, "YOUR_FILE_PATH", driver = "GPX") |
There was a problem hiding this comment.
Error: Layer creation failed.
In addition: Warning message:
In CPL_write_ogr(obj, dsn, layer, driver, as.character(dataset_options), :
GDAL Error 6: Field of name 'id' is not supported in GPX schema. Use GPX_USE_EXTENSIONS creation option to allow use of the element.
There was a problem hiding this comment.
The same goes for this chunk as well.
| #| title: plot models | ||
| #| fig-height: 5 | ||
| #| fig-width: 7 | ||
| ggplot() + |
There was a problem hiding this comment.
Warning message:
In predictor + offset :
longer object length is not a multiple of shorter object length
There was a problem hiding this comment.
I'm not sure what is causing this warning message as I cannot produce it on my end. I'll dig into it some more
|
|
||
| ```{r, warning = FALSE} | ||
| #| title: create redployment ring | ||
| redeploy_loc <- st_buffer(dist = 370, rcv_osc_sf_12) %>% |
There was a problem hiding this comment.
Error: object 'rcv_osc_sf_12' not found
If you start a new R script in Section 3 (see first text block in that section) then this object doesn't exist. This object either needs to be attached to the session or re-run the script in Section 2.
There was a problem hiding this comment.
I have amended the vignette to reload and create this object
|
|
||
| # Analysis | ||
|
|
||
| For the analysis you will want to start a new R script, hence why I have left load packages below. |
There was a problem hiding this comment.
If you truly start a new R script, then later in this section code fails with error:
Error: object 'rcv_osc_sf_12' not found
There was a problem hiding this comment.
I have amended the vignette to reload and create this object so that it does not error considering the object cannot be found considering it isn't brought in.
| ```{r, warning = FALSE} | ||
| #| title: create redployment ring | ||
| redeploy_loc <- st_buffer(dist = 370, rcv_osc_sf_12) %>% | ||
| st_cast("LINESTRING") %>% |
There was a problem hiding this comment.
Warning message:
In st_cast.sf(., "LINESTRING") :
repeating attributes for all sub-geometries for which they may not be constant
There was a problem hiding this comment.
This is a common warning with st_cast() when geometry lengths differ.
| #| title: tranform, view and filter | ||
|
|
||
| redeploy_loc_pts <- redeploy_loc %>% | ||
| st_cast("POINT") %>% |
There was a problem hiding this comment.
Warning message:
In st_cast.sf(., "POINT") :
repeating attributes for all sub-geometries for which they may not be constant
There was a problem hiding this comment.
This is a common warning with st_cast() when geometry lengths differ.
| ## Select redeployment location | ||
| Then filter out the points we want, this will change depending on your study site and what locations you want. We will transform the projection back to WGS 84 as this is likely what your gps or sonar will want. We will also add in a few columns to conform to GLATOS and OTN data standards and rearrange the column order. | ||
| ```{r, results = 'hide'} | ||
| redeploy_sites <- buffer_rings_pts %>% |
There was a problem hiding this comment.
Error: object 'buffer_rings_pts' not found
It's unclear if you intended to use 'buffer_rings_pts' from earlier script (Section 2) or if you meant to use 'redeploy_loc_pts' here; but this needs to be fixed.
There was a problem hiding this comment.
I have updated this to redeploy_loc_pts as that is what the correct object should be - sorry about that.
| title: "Estimate Detection Range for | ||
| Acoustic Telemetry Receivers" | ||
| author: Benjamin L. Hlina | ||
| date: "Updated: `r Sys.Date()`" |
There was a problem hiding this comment.
I suggest hardcoding the date here to reflect when this document was actually edited. Otherwise, it simply reflects the installation date.
There was a problem hiding this comment.
I have added the hard coded the date here
…of deployment of range transmitters is exported as a xlsx and csv.
…on section discusses starting a new script but does not discuss that you will need to bring in the same receiver data.
Detection range model fixes
release version 0.8.0
|
completed in commit 6525afd |
|
@benjaminhlina This is now live in 0.8.0. Thanks for the contribution! I took the liberty of making a few edits to code chunks that were throwing warnings and errors (mentioned in review) that I thought should be resolved. Feel free to submit another PR if you'd like to correct any of those changes. Also, note some overlap between your vignette and 'detection_range_handout.html'. I will be encouraging you and others to revisit the topic of detection range analysis with the goal of identifying some consensus best practice. Even as separate vignettes, though, these are valuable contributions. |
|
Thanks @chrisholbrook, I have pulled the changes you have made to this that you merged with dev and agree that all the warnings need to be explained to the user. I also a agree that the save steps need to actually save and not error as the end-user will not know why it's erroring and appreciate you amending those steps as well as correcting the warnings. |
In GitLab by @benjaminhlina on Nov 26, 2021, 11:30
detection_range_model uses a third-order polynomial, logit, or, probit model to determine detection range based on a expected percentage of detections for acoustic telemetry receivers. This function is to be used after a preliminary range test which uses multiple distances away from a representative receiver. Preliminary detection efficiency is to be determined in Vemco's Range Testing software and exported as a csv. Vignette on the use of the function is being written.