Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate using covidData to get versioned truth data #532

Open
Bisaloo opened this issue Jun 15, 2021 · 3 comments
Open

Investigate using covidData to get versioned truth data #532

Bisaloo opened this issue Jun 15, 2021 · 3 comments
Assignees
Labels
on hold This issue cannot be resolved at the moment because it depends on other issues question Further information is requested

Comments

@Bisaloo
Copy link
Member

Bisaloo commented Jun 15, 2021

https://github.com/reichlab/covidData

This might be a good direction to get rid of the data-truth folder here.

@kathsherratt kathsherratt moved this from Analysis to Infrastructure in First phase of hub development Jun 15, 2021
@Bisaloo Bisaloo self-assigned this Jun 17, 2021
@Bisaloo
Copy link
Member Author

Bisaloo commented Jun 17, 2021

First step is to translate prepare_truth_data.py to R so we can nicely drop the package in place of the custom folder.

@Bisaloo
Copy link
Member Author

Bisaloo commented Jun 18, 2021

I have a working version of this for viz/prepare_truth_data (I would still need to make it work with load_truth() used in reports) but I'm suddenly not sure it's the way to go. Switching to covidData introduces a hard dependency to Covid-19 and I don't see a nice way to specify this in a config file.

Instead, we should probably aim at loading the versioned truth from zoltar (and it can then work with any truth source). See this related issue in covidHubUtils: reichlab/covidHubUtils#246.

In case we need it the future, the first steps to switch to covidData are in https://github.com/epiforecasts/covid19-forecast-hub-europe/tree/covidData.

@Bisaloo Bisaloo added the question Further information is requested label Jun 18, 2021
@sbfnk
Copy link
Contributor

sbfnk commented Jun 18, 2021

Yes, this makes sense to me.

@Bisaloo Bisaloo added the on hold This issue cannot be resolved at the moment because it depends on other issues label Jun 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
on hold This issue cannot be resolved at the moment because it depends on other issues question Further information is requested
Projects
No open projects
Development

No branches or pull requests

2 participants