Open athowes opened 1 month ago
Agree - in addition may want to consider what is the best time point to use for comparison, e.g. EpiEstim provides an estimate over a period from start_date to end_date so the best comparison point may be to use the midpoint of this when comparing to methods such as EpiNow2 which (I think) provide a single point estimate
An issue to consider is for methods like EpiNow2 the shifting above should be made to match the incubation period etc that were used as inputs to the EpiNow2 call, whilst in EpiEstim for example this will need to be an external input
so to recap: summary of the issues are: 1) how to properly align dates across the 4 packages - currently all are ok except I think EpiEstim should be using the midpoint between t_start and t_end instead of t_end 2) for the packages which do not account for delays in reporting and incubation, we should have an easy way to shift the estimates in time by the appropriate amount for comparability with packages such as EpiNow2 which do account for these and therefore provide Rt estimates by date of infection. This means adding options for EpiLPS, EpiNow2 and RtEstim to shift all estimates by 1 mean delay (mean incub + mean delay between symptoms and reporting) - this should be an external input though as not considered as input of those packages
In @cmilando's code he does work to change the dates using
INCUBATION_SHIFT
andREPORTINGDELAY_SHIFT
. Do we need to be doing that here to make the dates line up for the different packages?