eco4cast / neon4cast-beetles Goto Github PK

Follow-ups from July 21 meeting

• Performance metrics @carl
• Add error to random walk and average baseline null forecasts for richness @taddallas
• Build random walk and average baseline null forecasts for count @annaspiers
• Pool subspecies to species @annaspiers
• Data correction ( e.g., for trapnight, something about sampling effort) @brettmelbourne

Hi team, I'm still worried about our formulation of 'counts / trap-nights'. Sampling effort is not as clean as we've assumed (i.e. 40 traps per site up to 2017, then 30 traps after). That's the protocol, but the actual number of traps set varies a bit more than that, as we can tell from the field data table, e.g.

bet_fielddata %>% count(siteID, collectDate) 

shows a given collectDate usually collects the expected 40 traps prior to 2018 and 30 traps after, but might also collect far less, i.e. here's how many traps are returned:

 bet_fielddata %>% count(siteID, collectDate) %>% rename(n_traps = n) %>% count(n_traps, sort=TRUE)
# A tibble: 40 x 2
   n_traps     n
     <int> <int>
 1      30   999
 2      40   879
 3      15    65
 4      36    61
 5      29    55
 6       1    49

So to count up "trap-nights" at a given site for a given collection date, we need to use the fielddata table to add up the number of days each individual trap was set at each site,

bet_fielddata %>% group_by(siteID, collectDate) %>% summarize(trapnights = sum(trappingDays))

Also note this cannot be done directly from the bet_sorting table, even though we have collectDate and setDate, because that table does not include any traps that were set and collected but wound up being empty on that bout.

I think this number from the fielddata for trap nights is better, though there may still be improved ways to adjust for effort.

Visualize time series of:

• abundance
• number of traps per site
• range of number of nights per trap per site

Create:

• Spatial richness accumulation curves
• Temporal richness accumulation curves
• Chao's index