2023 growing season anomalies

[teixeirak]

@jenajordan asked today about the dendroband anomalies. It looks like we have some that require fixing. Let's get these resolved before the 2023 spring measurement.

I'm hoping @jess-shue or @rudeboybert can help you with the protocol for fixing these.

Below is the latest image and my recommendation for each:

• 120781- remove the obvious anomaly, or perhaps fix by adding a 1 in front (it looks like the error was missing that 1)
• 121374- remove anomaly (last record) - replace with NA
• 171348 - band replaced.
• 62224- Here, the band must have slipped in the early summer. It was adjusted in fall, resulting in apparent shrinkage. We need to adjust code such that a band adjustment registers the same as a new band.
• 72210- Throw out the obvious 1st ourlier. The 2nd is probably okay (unless it still shows up as outlier).
• 72324- remove anomaly (low record before the one flagged as an anomaly) - replace with NA
• 91486- remove anomaly (2nd to last record) - replace with NA

We also have errors to fix from the spring and fall surveys: https://github.com/SCBI-ForestGEO/Dendrobands/blob/master/testthat/reports/requires_field_fix/require_field_fix_error_file.csv.

[teixeirak]

@jess-shue , here's a case (stem 171348) where the old band was removed, and perhaps a new band installed? The anomalous new measurement may be a new band. I'm not sure how to fix the record such that this doesn't show up as an anomaly.

[teixeirak]

@jess-shue , do you know what the code "CH" might mean? You entered it a couple times in the fall census, and it's undefined (codes here).

[teixeirak]

We have some cases here of band replacements or adjustments.

[jess-shue]

@teixeirak Sorry, I must have gone into autopilot for the 'CH' code - that's what I use at SERC to note that the measurement was 'checked'. I removed those two instances and added 'verified' to the notes column in the fall biannual survey data and the 2022_ALL file.

For 171348, we need to add that to mutliple files as a new band. A replacement was installed during the fall biannual survey - so that measurement isn't an anomaly, but a new band. I'll work on updating the files in the next few days.

[teixeirak]

Thanks, @jess-shue!

The status of all this then is that all true anomalies from biweekly measurements are resolved. We have a couple remaining because of band replacement/adjustment, and it looks like a lot of the anomalies in the fall census were also from this. My sense is that you also checked a lot (all?) of the supposed anomalies. That means a lot of these errors will be solved by record keeping or maybe coding.