covidcast::state_census() provides 2019 estimates, whereas geomapper from covidcast-indicators uses 2020 estimates

[huisaddison]

The state_pop provided in this package differs from the state_pop used to construct indicators:

https://github.com/cmu-delphi/covidcast-indicators/blob/main/_delphi_utils_python/delphi_utils/geomap.py#L105

https://github.com/cmu-delphi/covidcast-indicators/blob/main/_delphi_utils_python/delphi_utils/data/2020/state_pop.csv

https://github.com/cmu-delphi/covidcast/blob/main/R-packages/covidcast/data/state_census.rda

This is low-pri because population should change slowly enough year-to-year to make this a rounding error in analysis, but it would be good to make the count-to-rate operation in the construction of indicators invertible using the client-facing packages.

[krivard]

yeah agreed. the population stuff was added to covidcast-R as a convenience that's turning out to be a bigger lift to maintain than i think we were anticipating. recommend we do not pursue this in the client packages and instead direct folks to delphi-utils for the time being (which is public and open-source, but in python).

There has been some side chatter about hosting population information from an epidata endpoint, currently focused on the $1MQ and daytime- vs nighttime-population microdensity, but I can easily imagine more general-purpose populations could become a part of that if people really miss having delphi-confirmed-compatible populations in R.