Add parse_cfgrib() or other helper for interpretting cfgrib/eccodes's GRIB map projection attributes

[jthielen]

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 to grid_mapping, instead, the variables have a list of attributes like the following:

{
 ...,
 'GRIB_numberOfPoints': 1905141,
 'GRIB_gridType': 'lambert',
 'GRIB_DxInMetres': 3000.0,
 'GRIB_DyInMetres': 3000.0,
 'GRIB_LaDInDegrees': 38.5,
 'GRIB_Latin1InDegrees': 38.5,
 'GRIB_Latin2InDegrees': 38.5,
 'GRIB_LoVInDegrees': 262.5,
 'GRIB_NV': 0,
 'GRIB_Nx': 1799,
 'GRIB_Ny': 1059,
 'GRIB_gridDefinitionDescription': 'Lambert Conformal can be secant or tangent, conical or bipolar',
 'GRIB_latitudeOfFirstGridPointInDegrees': 21.138,
 'GRIB_latitudeOfSouthernPoleInDegrees': -90.0,
 'GRIB_longitudeOfFirstGridPointInDegrees': 237.28,
 'GRIB_longitudeOfSouthernPoleInDegrees': 0.0,
 ...
}

Given the prevalence of use of GRIB files and cfgrib to read them (based on user survey and number of comments on posts like #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 or parse_special('cfgrib')) or a separate helper in io to use within assign_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: ecmwf/cfgrib#251, so yeah, that'd be the route to go)

Reference

No response

[dopplershift]

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.