Closed brookslogan closed 1 month ago
@dshemetov is this related to the intended eventual behavior for nans, or did we discard that option?
@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.
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.
Requires:
delphi_utils
library's geo type lookup routines to make sure requested geo values are valid for the requested geo type
The following requests produce "no results":
These could all produce errors like "invalid
geo_value
for the requestedgeo_type
". Alternatively, the first one could instead produce data for all counties in CA instead and the other two could produce this error message.