The 3 requirements of the new color palette would be:

• [x] look nice to as many humans as possible
• [ ] be colorblind friendly
• [ ] correspond to categorical variables

Quite a bit of thinking on these has been done by the viridis package: https://cran.r-project.org/web/packages/viridis/vignettes/intro-to-viridis.html

As well, these very good resources:

• https://personal.sron.nl/~pault/#sec:qualitative
• https://www.osapublishing.org/oe/abstract.cfm?uri=oe-21-8-9862

I suggest we use this issue to propose palettes. Ideally put them to a vote at some point.

at I'm mostly just curious, but what is the reasoning behind the design decision to copy over the code from {incidence} initially instead of importing? From my perspective, if there's a bug in the future, then there are two places where it needs to be fixed.

Hey - not a must have but might be nice to have option to add a moving average line. This pretty commonly used on messy epi data. Should be quite easy to implement now that {slider} has been released. See r4epi discussion

Maybe should just be left for users to so separately (i.e. add to plot themselves after)?

Hello! Great improvements on the original package - thank you very much! I really like the ability to facet and to use count data.

I would like to ask if the plotting functions can allow a width argument or otherwise an option for the there to be no gap between bars. At the US CDC and it seems in Europe as well (see ref below) there is a traditional guideline that epidemic curves (when large enough that cases are not shown as boxes) should be histograms and not bar charts - or at least that there be no spaces between the bars. If this option can be offered I think it would also offer a solution to the varying width and frequency of "white lines"/gaps between bars, which appear for example in the github readme (below).

From the vignette - "white lines"/bar gaps appearing at different frequencies across the plot

From the vignette - "white lines"/bar gaps of varying thickness across the plot

I tried to include a width argument in plot() but it was not accepted. When I tried to add a geom_col() to plot() and specify width that also did not work. While experimenting, I tried to use geom_col alone directly on a weekly incidence2 object. When I specified width = 7 I was able to achieve non-overlapping bars without any gaps. This makes sense given that it was a weekly incidence object and according to this ggplot2 issue discussion which says that geom_col width is interpreted in absolute units (days in this case).

Here is that example - the outbreaks ebola_sim_clean linelist

pacman::p_load(incidence2, tidyverse, outbreaks)
b <- incidence2::incidence(outbreaks::ebola_sim_clean$linelist, date_index = date_of_onset, groups = gender, interval = "week")
plot(b, fill = gender) # weird varying white "gaps" between bars
ggplot(data = b)+geom_col(aes(x = bin_date, y = count, fill = gender), width = 7) # no gaps

I just wanted to chime in and see if this was something that is possible. Perhaps at the least the width argument could be allowed to pass to the underlying geom_col? Then the user could tinker and find the correct width?

Thanks very much for considering!

ECDC guidelines for presentation of surveillance data

There has been debates in the past on where dates should appear on the x-axis. I will try to sum up views / things to take into account below, and maybe some will add thoughts to it.

Original incidence package

• epicurves were treated as histograms; bars represent case counts between 2 time points, so that e.g. for monthly incidence, a date on the x-axis marks the left hand-side of the bin (label to the left)
• for fitting, a single date needs to be associated to a case count; thus we were using the middle of the time interval (label in the middle)
• we did not have options for plotting epicurves as points / lines
• several users complained that label in the middle was more intuitive

Current considerations

• I suspect most epis do not read epicurves as histograms, so label in the middle would make sense
• if we add geom_point and geom_line as options for plot and facet_plot, it is preferrable to have a consistent label positioning, which works the same for all geoms; label in the middle seems better for this: it still makes sense with geom_bar
• model predictions will probably work better with label in the middle
• devel-wise, it is safer to go with the least-amount of fiddling with ggplot2 handing of the x-axis

hi - like the idea of moving this to cleaner syntax!

Just thought I would suggest using tsibble to do some of the underlying legwork. There are yearweek and year* functions and all works pretty clean.

The advantage over aweek is that is recognised as a date automatically. The disadvantage over aweek is that cannot (as of yet) set a different start day for a week.

Actually just posted issues this morning on {aweek} and {tsibble} about this.

As a sidenote - while in the process of redoing everything might be worth considering renaming just to make certain epis happy and avoid semantic discussions around incidence vs incidence rate vs prevalence (see)

A maybe not very frequent use case: define limits between two time intervals defined by grate, e.g. to visually delineate epochs in a graph using a vertical line.

Currently the following will error on purpose:

> as_yrwk("2021-W03") + 1
[1] "2021-W04"

> as_yrwk("2021-W03") + 1.5
Error: Can only add whole numbers to <yrwk> objects

But unsure if we want to change this or not.

@nsbatra - the following requires the dev (GitHub main/master branches) of incidence2 and grates but hopefully works as you were hoping. Let me know what you think:

library(outbreaks)
library(incidence2)

dat <- ebola_sim_clean$linelist
x <- incidence(dat, date_of_onset, interval = "month")
x
#> An incidence2 object: 13 x 2
#> 5829 cases from 2014-Apr to 2015-Apr
#> interval: 1 month
#> cumulative: FALSE
#> 
#>    date_index count
#>    <month>    <int>
#>  1 2014-Apr       7
#>  2 2014-May      67
#>  3 2014-Jun     102
#>  4 2014-Jul     228
#>  5 2014-Aug     540
#>  6 2014-Sep    1144
#>  7 2014-Oct    1199
#>  8 2014-Nov     779
#>  9 2014-Dec     567
#> 10 2015-Jan     427
#> 11 2015-Feb     307
#> 12 2015-Mar     277
#> 13 2015-Apr     185
 
# centred dates (default for yearweek, single months, quarters and years)
plot(x, color = "white")

# histogram-esque dates on the breaks (defaults to "%Y-%m-%d")
plot(x, color = "white", centre_dates = FALSE)

# can specify a different format
plot(x, color = "white", centre_dates = FALSE, date_format = "%d-%m-%Y")

^{Created on 2021-05-19 by the reprex package (v2.0.0)}

For instance, pool may be better named regroup, and I guess there could be more cases like this. Generally speaking, renaming things from the original incidence poses some trade-offs. There are several strategies we may consider:

Stick to the old

We keep old names as much as possible, and only use new names for new features.

Scrap the old

As this is a reboot, we can do away with old names, and rely on documentation for people to find out correspondence. A softer version would be to have incidence2::pool merely return NULL (or an error) and throw a message saying that this feature is now called regroup in incidence2.

Aliases

We could have incidence2::regroup <- incidence2::pool. If so, do we want to:

• keep aliases going forward (I think not)
• mark old names as deprecated and eventually remove them? It might make sense in terms of transition, but it is weird to develop a new package with already deprecated functions, with a schedule that explicitely plans breaking backward compatibility fruther down the line.

Subsetting objects by given time windows may be one of the only things made slightly easier in the original incidence package. For instance, x[1:5] would get you the first 5 time steps (days / weeks / months) of the object, which is a little trickier to do now. It would be useful to have some functions helping with this - see some proposed example uses below.

Filter first / last days / weeks / months etc.

Filter the data to retain the first or last data points, predicated on a duration. There is a question here, as to how duration can be specified:

1. simplest form: duration is provided as integer days
2. other simple form: duration is provided as integer time intervals (as specified by the bins of the object)
3. interpreted like the 'interval' argument of incidence2::incidence, so we could do things like "3 months" to have the first 3 months of data (possibly months 1 and 3 not being complete)

Examples would be (depending on the option above we retain):

• filter_first(x, 30): retain the first 30 days of data, or all of it if there are less than 30 days
• filter_first(x, "1 month"): retain the first month of data; may not be a full month, only data from the first reported month
• filter_last(x, "4 weeks"): retain the last 4 weeks of data; the last week may not be complete e.g. if the last date is a Thursday, so this may not be 28 days of data
• filter_last(x, 28): filters the first 28 days data (irrespective of week definition)

Subset

We could re-implement the features of incidence::subset(), but possibly renaming the function. It would merely be a wrapper for filter on dates.

Some thoughts on how facetting may work, esp with regards to using groups for facetting and/or color-filling. Nothing hard-set, more for discussion purpose. It would be useful to have a facet argument handling which grouping variables are used for facetting. Together with fill, this should give more flexibility to the user for designing plots with different grouping variables displayed.

Here are some proposed behaviours:

• facet_plot(x): plot the incidence object using all grouping variables for facetting
• facet_plot(x, facet = "foo"): same, using only variable foo for facetting
• facet_plot(x, facet = c(foo, bar)): same, using variables foo and bar
• facet_plot(x, facet = "foo", fill = bar): use foo for facetting and bar for filling
• facet_plot(x, facet = c("foo", "bar"), fill = bar): use foo and bar for facetting, and bar for filling; redundant, but that's okay, the user asked for it

What do you think?

Currently using only data.table for aggregation which means we cannot support non-atomic columns (see https://github.com/Rdatatable/data.table/issues?q=is%3Aopen+is%3Aissue+label%3A%22non-atomic+column%22 for further discussion). Previously I switched behaviour based on the input and dispatched to either data.table or dplyr accordingly. Need to think about whether I do the same thing going forward or error on known problematic inputs.

I want to avoid changing user inputs so if I do not go with the dual use I'd like to error on POSIXlt input .

Please place an "x" in all the boxes that apply

• [x] I have the most recent version of incidence2 and R
• [x] I have found a bug
• [x] I have a reproducible example

If a column is stored as POSIXt / datetime rather than a plain Date, incidence() will have an inconsistent behaviour and work when interval = "week" but interval = "day".

library(dplyr)
#> 
#> Attaching package: 'dplyr'
#> The following objects are masked from 'package:stats':
#> 
#>     filter, lag
#> The following objects are masked from 'package:base':
#> 
#>     intersect, setdiff, setequal, union
library(incidence2)

# Create a dataset with Dates stored as datetimes / POSIXt
data("covid19_england_nhscalls_2020", package = "outbreaks")

d <- covid19_england_nhscalls_2020 %>% 
  mutate(across(where(lubridate::is.Date), as.POSIXct, tz = "UTC"))

# Convert this dataset to incidence2

# WORKS
d %>%
  incidence("date",
            interval = "week",
            counts = "count"
  )
#> An incidence object: 27 x 2
#> date range: [2020-W12] to [2020-W38]
#> cases: 4101446
#> interval: 1 (Monday) week 
#> cumulative: FALSE
#> 
#>    date_index  count
#>        <yrwk>  <int>
#>  1   2020-W12 677547
#>  2   2020-W13 866757
#>  3   2020-W14 522298
#>  4   2020-W15 331617
#>  5   2020-W16 212969
#>  6   2020-W17 156984
#>  7   2020-W18 154765
#>  8   2020-W19 117314
#>  9   2020-W20 107629
#> 10   2020-W21  88949
#> # … with 17 more rows

# DOESN'T WORK
d %>%
  incidence("date",
            interval = "day",
            counts = "count"
  )
#> Error in `create_interval_string()`:
#> ! Not implemented for class POSIXct, POSIXt

#> Backtrace:
#>     ▆
#>  1. ├─d %>% incidence("date", interval = "day", counts = "count")
#>  2. └─incidence2::incidence(., "date", interval = "day", counts = "count")
#>  3.   ├─incidence2:::create_interval_string(dat$date_index)
#>  4.   └─incidence2:::create_interval_string.default(dat$date_index)
#>  5.     └─rlang::abort(...)

^{Created on 2022-11-21 with reprex v2.0.2.9000}

Please place an "x" in all the boxes that apply

• [x] I have the most recent version of incidence2 and R
• [x] I have found a bug
• [x] I have a reproducible example

Please include a brief description of the problem with a code example:

library(incidence2)

data(ebola_sim_clean, package = "outbreaks")
dat <- ebola_sim_clean$linelist

inci <- incidence(dat,
                  date_index = date_of_onset,
                  interval = 7,
                  groups = hospital)

green_grey <- "#5E7E80"

facet_plot(inci, fill = green_grey)
#> Warning: Using an external vector in selections was deprecated in tidyselect 1.1.0.
#> ℹ Please use `all_of()` or `any_of()` instead.
#>   # Was:
#>   data %>% select(green_grey)
#> 
#>   # Now:
#>   data %>% select(all_of(green_grey))
#> 
#> See <https://tidyselect.r-lib.org/reference/faq-external-vector.html>.

^{Created on 2022-10-26 with reprex v2.0.2.9000}

Looking at the full error stack, this is caused by

https://github.com/reconverse/incidence2/blob/6d527d1f2d5e0de682a435643d2f6d193f3f734e/R/plot.R#L212-L218

Related: #78

Currently build_incidence() does not mention that it cannot be used with the built in plotting functionality. This should be documented, and potentially we should create a plot methods that warns when called directly.