Closed EOGrady21 closed 2 years ago
Going through the code on this issue, the reason we started using time in hours instead of milliseconds was because of plotting and interpolation. When time is in milliseconds the interpolation functions won't work (scale of milliseconds vs salinity, temp, etc are too dissimilar). I've left time in hours throughout, although it shouldn't be REQUIRED at any point by a function. I will go through and try to account for this. I renamed 'avg_hr' to 'time_hr' for naming consistency and have also added time_ms back to the binned vpr object so a user could choose to consistently use time in milliseconds if they wanted. I will also need to go through the vignette once these changes are complete.
Through the development of VPR Viewer (VPRv), it was discovered that there was some unnecessary time re-calculation and processing happening internally to the vprr binning functions. When this processing was also done manually in the workflow, it was causing some alignment issues between data sources.
Time data is collected by the VPR in milliseconds, but during processing it is converted to hours for plotting and readability. Time is also 'zeroed' so that when plotted, the time axis represents time since the VPR was deployed rather than actual time of day (for readability). This processing has been typically done in the workflow but was also happening inside some of the binning functions.
bin_calculate
:avg_hr
variable is calculated from time in milliseconds and then binned with the rest of the databin_cast
:avg_hr
variable is zeroed based on minimum time value in binned dataZeroing the time data based on the minimum binned time value creates an offset when plotting the binned data along the original 'all data' CTD path. This is what we were seeing in VPRv.
Apologies for this convoluted attempt at a summary. There are some suggested edits to vprr to remove these issues.
Thanks to @kevinsorochan for talking this through with me and suggesting appropriate edits