Open dsweber2 opened 1 month ago
@lcbrooks @nmdefries would like your opinion at some point on whether we ought to do this/rough priority
My thoughts:
time_value
column: sounds reasonable; not sure if this should be based on names or classes or both though. cli_inform
ing sounds good.geo_value
: less sure about this one. We won't know which nation to guess, so I'd imagine it'd need to be some other special value like "unspecified" [and same sort of thing with geo_type
, maybe "custom"?]. Plus we should check for unique time values to make sure we're not just missing some key vars. Really, I think we should be checking epikey-times are unique identifiers all the time, but especially in this case.geo_value = some_col, time_value = date
interface, we should use the tidyselect package. We should match whatever our decision is here in #186 / #446 (though that needs to accommodate 0 / >1 selections as well, but that is probably possible just by using a common tidyselect command and removing a length check on the result).Priority: seems like one of many individually-low- to medium- priority papercuts that keep being neglected. If it's been annoying you recently, seems like a good time to handle it.
A couple of things I realized would be convenient when trying to use
as_epi_df
:time_value
aliases. E.g. ifdate
or anything containing that is present and unique, just assume that the user means that that column should be used as thetime_value
. Maybeinfo
that it's happening.geo_value
is present, assume that all values have the same geo_value at a national scalealias
argument that allows the user to input e.g.geo_value = some_col, time_value = date
. This is basically just allowing them to skip writing arename
immediately beforeas_epi_df