Consider changing JHU indicator to not report incidence zeros

[krivard]

Zeros appear in JHU incidence signals when the cumulative number of cases or deaths remains the same between one day and the next. This does not necessarily mean that zero new cases or deaths occurred on that day: many regions have downgraded their reporting cadence, so that all the new cases or deaths that occurred in a week are collected together and reported in a batch on e.g. Thursdays.

Alas, this also does not necessarily mean that zero new cases or deaths did not occur on that day: small regions often go many weeks between new actual cases or deaths, so many/most/all of those zeros are true zeros.

It seems like a maintenance nightmare to try and keep accurate track of which regions are expected to report on which days so that we can suppress reporting of zeros on other days. It also seems like it would be difficult to consistently decide whether a region was "small enough" that their zeros were true zeros.

We should switch to never reporting zeros in incidence signals from JHU. It is much less harmful for a researcher to misinterpret the days before a small count in a small region as "not reported" days than for that researcher to misinterpret a large region going from zero cases to a large number in a single day.

This change will require:

• [ ] changing the jhu indicator code to drop the zero rows in incidence data frames before writing output
• [ ] updating the documentation to describe this behavior
• [ ] a one-off modification to the database to remove the zero rows in incidence signals for JHU

[krivard]

@dshemetov thoughts on this idea? It came up while Roni and I were talking about the coding of non-numerics.

[dshemetov]

@krivard A few initial thoughts (sorry for the delay):

• The db space savings could range from small to large, a bit hard to say. COVID is endemic, so we will continue to have reports, but at a slower cadence. So theoretically we could get a 7x reduction in storage (assuming all geos move to a weekly reporting cadence), but probably less than that.
• This would make some non-numeric values in our database a bit inconsistent, since some non-numerics would be present and coded, while others would simply be absent and the user would have to infer what that means
  • From my experience working on modeling, having a dataset give me an annotated non-numeric value isn't very useful; in model building those are usually just dropped or filled with a simple strategy
  • Similarly, if a signal is mostly unreliable zeros (due to known reporting delays), on the modeling side that is not much better than receiving data on an irregular time index, zero-filling yourself, and using a smoothing strategy to spread the counts; so as a user I wouldn't be heavily affected
• JIT could adapt to this, but using the JIT incidence signal the database savings would vanish
• Also there may be a nice advantage in sending fewer rows in API results to users, rows that they can easily fill in themselves client-side
• One final point that's a bit more involved: iirc, a big reason we serve the smoothed and incidence signals directly is because we don't want to / can't do time series processing in JavaScript in the dashboard; with this change, we would need to do time series processing to zero-fill incidence signals for the dashboard, which may be difficult

[krivard]

we would need to do time series processing to zero-fill incidence signals for the dashboard

i think we can actually ignore this; wouldn't just leaving those points out be more consistent with this change?

[dshemetov]

It probably depends on how bad the plots look without gap-fills (and how we're handling it currently). It would be very convenient code-wise to just plot nothing in the gaps.

[nmdefries]

I thought we were essentially reporting JHU data as-is and doing minimal processing. So doing this seems like it would be adding unnecessary post-processing to the data.