Skip to content

Produce helpful error on invalid geo_values in Epidata$covidcast #641

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

Closed
brookslogan opened this issue Jul 15, 2021 · 5 comments
Closed
Assignees

Comments

@brookslogan
Copy link
Contributor

brookslogan commented Jul 15, 2021

The following requests produce "no results":

Epidata$covidcast("jhu-csse","confirmed_incidence_num","day","county",20210101,"ca")
Epidata$covidcast("jhu-csse","confirmed_incidence_num","day","county",20210101,"86824") # bogus county FIPS code
Epidata$covidcast("jhu-csse","confirmed_incidence_num","day","state",20210101,"bg") # bogus state code

These could all produce errors like "invalid geo_value for the requested geo_type". Alternatively, the first one could instead produce data for all counties in CA instead and the other two could produce this error message.

@krivard
Copy link
Contributor

krivard commented Jul 15, 2021

@dshemetov is this related to the intended eventual behavior for nans, or did we discard that option?

@dshemetov
Copy link
Contributor

@krivard I think the difficulty we ran into here with nans is the need to maintain valid geo value lists. Since indicators rarely give us geo value lists with intention to serve, we have to derive these from their actual data history. This makes determining the exact boundary of unreported-because-no-data and unreported-because-unsupported-geo-value, not just hard but intractable, especially for incomplete coverage indicators (like surveys), since we never know whether a geo value will never be reported or just hasn't been reported yet.

That said, clearly invalid geos, like supplying "ca" or "86824" into county or "bg" into state, can be plausibly filtered out with a single valid and very inclusive geo list. I just wouldn't expect it to be precision-perfect, e.g. an indicator that doesn't actually serve Puerto Rico counties will still produce "no results" for Puerto Rico counties since they present valid geo values.

@krivard
Copy link
Contributor

krivard commented Jul 15, 2021

excellent. sounds like we could address the "clearly invalid geos" case pretty easily then, since we're already using delphi_utils for nan codes. may as well use the same GeoMapper implementation everywhere.

also @zhuoran-Cheng16 this might be related to what you're working on with #542, since that one should be using the delphi_utils GeoMapper too.

@krivard
Copy link
Contributor

krivard commented Dec 15, 2022

Requires:

Source code for delphi_utils

@melange396
Copy link
Collaborator

#1905 took care of this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

6 participants