Closed amandalbradford closed 3 months ago
I added the rounding action as a precaution in case Beaufort values were entered into data as non-integers (e.g., one portion of viewshet is Bft 3, another is Bft 4, so entered Bft is 3.5). But there is no such instance in all the 1986 - 2020 Pacific NOAA survey data, so I take your point that this precaution is currently not needed and the unexpected column names (bftr
instead of bft
) are confusing and inconvenient.
I will remove this feature (super easy to implement again if we ever need). This should only affect the function summarize_bft()
, which had a bftr
column but now has a Bft
column. This change will become live in release of version 1.2.
The
summarize_bft
function leads to the rounding of non-integer Beaufort values, but I am curious why. I don't think I took that approach when assessing effort by Beaufort. Each part of effort was coded by its assigned Beaufort state, and then the proportion of effort by integer state was assessed, so I don't recall dealing with non-integer values.