Climatological

[dajmcdon]

Checklist

Please:

• Make sure this PR is against "dev", not "main".
• Request a review from one of the current epipredict main reviewers:
  dajmcdon.
• Make sure to bump the version number in DESCRIPTION and NEWS.md.
  Always increment the patch version number (the third number), unless you are
  making a release PR from dev to main, in which case increment the minor
  version number (the second number).
• Describe changes made in NEWS.md, making sure breaking changes
  (backwards-incompatible changes to the documented interface) are noted.
  Collect the changes under the next release number (e.g. if you are on
  0.7.2, then write your changes under the 0.8 heading).

Change explanations for reviewer

1. Adds a canned forecaster that creates "climate" forecasts.
2. Adds a step to create climate point predictions and (by default) include them as a predictor in a model.

[dajmcdon]

@dsweber2 I added the print method and some ugly hacks to get autoplot to work, but I'm not super satisfied by the hackiness. So big-picture ideas there would be appreciated.

[dsweber2]

Generally pretty happy with this, took a bit to understand what was going on, but that's most b/c there's a lot.

I'm making a PR onto this with some of the smaller recommendations and my annotations in the process of understanding.

Backcasting: if we're supporting this, shouldn't we be filtering epi_data to be on or before that date? Otherwise we're using truth data for forecasting

[brookslogan]

Just skimming convo on phone, wanted to point out that in past we found holiday effects around weeks 52 (53) 1 were important so to prevent weird stuff from happening from confusing/grouping them we had the concept of season week 31 to 82/83 of season "S2016” aka ”2016/2017" to corresponding to epi weeks 31 to end of 2016 plus 1 to 30 of 2017, or something similar to enable representing entire years. So any weird stuff dropping or conflating whatever would happen in off season where it presumably would not matter, near weeks 31/82/83.

[dajmcdon]

The season-week arithmetic is pretty challenging to get right. And I agree that the convention of having "Week 1" in the summer is probably the easiest change. The same problem potentially impacts the leap year + daily case (only worse).

Perhaps a "for now" solution is to (?)

1. move week 1 to the summer (and document), for both week and epiweek cases.
2. Daily use 365 as the modulus always, with the effect that Dec 31 will map to Day 1 in leap years.
3. Have a more careful discussion at some point about how to carefully handle the boundaries.

[dsweber2]

Yeah, throwing the problem into the part of the dataset that's mostly irrelevant seems like a good first pass.