Open jthielen opened 2 years ago
Well, probably either way we're writing 90% of the same code. So I'd say we could inquire upstream (either before learning how to integrate in there or with a draft PR), and then add it here if they decline.
I mean, the project is called "cf" grib, so it would seem to be this should be part of the core functionality.
What should we add?
When reading in a GRIB file using
engine='cfgrib'
, we don't get xarray data structures conforming to CF with respect togrid_mapping
, instead, the variables have a list of attributes like the following:Given the prevalence of use of GRIB files and cfgrib to read them (based on user survey and number of comments on posts like https://github.com/Unidata/MetPy/issues/1004), I think this is one of our most common "non-compliant" data sources we'd at least have a hope of handling automatically. Whether this takes the form of a new accessor method (like
parse_cfgrib
orparse_special('cfgrib')
) or a separate helper inio
to use withinassign_crs
(i.e., a cfgrib to CF convention converter), I think this would be a good thing to include....that is, unless we can just get cfgrib to give CF compliant grid mappings in the first place? (UPDATE: there is an issue for this upstream: https://github.com/ecmwf/cfgrib/issues/251, so yeah, that'd be the route to go)
Reference
No response