parse_cf issues with NCEP precip data

[dcamron]

In supporting users, I came across two roadblocks trying to parse some NCEP precip mosaic data. Initially, it can not be parsed as the x, y coordinates have a units attribute of 'Meter' (capital 'M') which is not in the unit registry (#1362). Once modified, you can successfully parse individual data variable DataArrays. However, if you try to parse the entire DataSet, it will fail with a MergeError. The precip data variables have grid_mapping attributes pointing to an existing crs data variable (non-coordinate.) parse_cf will look for this provided crs data variable but then try to assign its own crs. Do we want to seek some sort of naming or organization solution here? It does behave as expected if I set the original crs data variable as a coordinate.

[jthielen]

The "Meter" issue is indeed just a manifestation #1362 (our general issue for tracking unit support for UDUNITS/CF conventions versus what Pint provides out-of-the-box). I'll add a note there.

The second is definitely an interesting one. It overlaps with #965, and seems to come down to avoiding a name conflict with the CRS coordinate (where we rely exclusively on the crs name). Given that it has now shown up in two different situations (existing variable named crs and multiple grid mappings), it might be time to implement another fix (such as searching through coordinates for a scalar coordinate of our CRS type, which is currently CFProjection, but may become pyproj.CRS soon).

Just to confirm, does the following workaround also fix it?

ds = ds.metpy.parse_cf([var for var in ds.data_vars if var != 'crs'])

[dcamron]

Yep! Using the list of non-crs data variables works as expected and attaches the CFProjection to a new crs coordinate.

[dopplershift]

I wonder if the way to handle the crs conflict issue is to rename to metpy_crs and issue a warning if we find a dataset that has one that isn't our CFProjection object.

[jthielen]

I wonder if the way to handle the crs conflict issue is to rename to metpy_crs and issue a warning if we find a dataset that has one that isn't our CFProjection object.

That should definitely fix the issue here, but doesn't on its own help with #965.

[dopplershift]

Sure. I don't have a good way to fix #965 off the top of my head.

[jthielen]

Sure. I don't have a good way to fix #965 off the top of my head.

Yeah, and that being said my idea for it (adding a sequential postfix for unique CRSs from the dataset if multiple identified when looping through the data vars before merging) doesn't really change whether the base name is crs or metpy_crs, so it can still be considered a separate issue.