Add mobility indicators

[ryantibs]

We should add mobility indicators. I think we were implicitly hesitant here because the causal arrow is completely backwards: it’s a reflection of policy, which itself a reflection of the interpretation of current COVID activity. So we may want to create a new category, just like we have “Official Reports”. Maybe “Mobility Reports” and list estimates both Google and Safegraph? The main point is that it'd just be helpful to have these on the map, to visually compare against the other indicators.

[ryantibs]

(Will assign to Alden and Noah as well, as soon as they accept the invitation to this repo!)

[huisaddison]

Sounds good. I can have basic Safegraph indicators up by end of week (unless we need them sooner).

Google mobility indicators suffer from poor geographical coverage, and Safegraph indicators correlate well with them, so my preferences is to focus on Safegraph and avoid having to maintain an additional set of (in my view, inferior) indicators.

Final logistical points:

• "New category": are we envisioning this as public facing or private facing? @jacobbien and I weren't sure how much transformation of the Safegraph data is considered "enough" to release to the public as our own indicators. As they stand, we are just taking mean over census blocks to aggregate to the county level, and looking at that. More or less their raw data.
• What source folder would we place these in? And more importantly, depending on the answer to the previous question, would we be placing these in a "private API"? @krivard

[ryantibs]

Thanks! End of the week is certainly fine, this is not a priority right now (it's not going in v1.3, maybe v1.4).

[capnrefsmmat]

We should also consider the mobility indicators we have from the Facebook survey, which contains the following questions:

C3: In the past 5 days, have you gone to work outside of your home?

C7: To what extent are you intentionally avoiding contact with other people? (all/most/some/none of the time)

C10: In the past 24 hours, with how many people have you had direct contact, outside of your household? Your best estimate is fine. (broken into at work, shopping, at social gatherings, and other)

Once #20 is done, it should be easier to ingest these. We'll have to consider how we form a mobility summary from these results.

See also #18

[krivard]

@ryantibs iirc the assumption that mobility is a reflection of policy didn't hold up in the US mobility data the forecasting team has looked at so far. Until it becomes clear otherwise, I'm comfortable displaying mobility in the same category as the other indicators, as a signal expected to be predictive of future COVID-19 activity.

@huisaddison On source: If we want to display mobility as a signal coming from a definite source (like SafeGraph or the FB surveys), it should lie under that source. It sounds like a unified mobility signal that integrates multiple sources might be useful, in which case it would go under indicator-combination. On access control: anything we show on the map should be in the public API. If we want to show the SafeGraph data directly, we'd have to make sure that serving that signal publicly does not conflict with the DUA we have with them. If however we want to use the SafeGraph data as a component of a combined mobility signal, we can serve SafeGraph from private and the combined mobility signal from public. The latter is probably optimal, though that would push the ultimate solution out to 1.5 or later (and even then, that's just one release to develop the component signals, and one release to develop the combo, and that may not be enough time)

[huisaddison]

Based on https://delphi-org.slack.com/archives/G013THCUUE4/p1591020473007900 ; I'm going to add this* to my immediate TODO list unless anybody objects

• wip_ mobility indicators to the safegraph source

[huisaddison]

Script and files are ready, but I'm having some trouble getting them into the API: https://delphi-org.slack.com/archives/C012G1F1QAV/p1591317773001300

[krivard]

The process for SafeGraph is not great for automation, because each update comes with a new API key that's only posted to Slack. That said Addison's already completed the bulk of the unknown code.

• [x] prototype code & wip signal
• [ ] code cleaning and review --> indicators repo
• [ ] develop some system for automation (IFTTT? social pressure for a better access method?)

[krivard]

SafeGraph has switched over to longer-term keys (30-day expiration). @huisaddison will contact them to give us a permanent key and CC Ryan, and will move the prototype code over to this repository.

[huisaddison]

I'm in touch with Safegraph, their rep says he'll relay our feedback but can't make any promises.

Forecasting also asked me to produce State-level mobility indicators too; so I'm going to put that in as part of the pipeline.

[huisaddison]

Taylor-style pipeline on branch dev/safegraph. Now includes State-level aggregation (in addition to County-level).

TODOS:

• [x] Documentation in DETAILS.md
• [x] Test cases

[capnrefsmmat]

I was going to suggest you add MSAs and HRRs for completeness (just if we decide to include it on the map, for instance); but for the moment let's actually hold off on that. @jsharpna is working on the DV and hospitalization indicators, and I've asked him to factor out the geographic code into the _delphi_utils_python module, so hopefully when he's done, doing new levels of aggregation will just require calling a function or two in that module.

[huisaddison]

For completeness, mirroring a comment I made on the Slack channel. As-is, this pipeline requires disk capacity of ~3.2GB / month. @korlaxxalrok @capnrefsmmat @krivard