search

WCRP-CORDEX / cordex-cmip6-cmor-tables

JSON Tables for CMOR3 to create CORDEX-CMIP6 datasets
https://wcrp-cordex.github.io/cordex-cmip6-cmor-tables
BSD 3-Clause "New" or "Revised" License
1 stars 1 forks source link

Why do the tables assign an axis to the coordinates ? #54

Closed aulemahal closed 10 months ago

aulemahal commented 10 months ago

In the coordinate table here, an axis is assigned to the spatial coordinates. For example, here for "latitude" : https://github.com/WCRP-CORDEX/cordex-cmip6-cmor-tables/blob/822053f8b686522187010aa3610a04da659b15e0/Tables/CORDEX_coordinate.json#L190

And same for "longitude". However, in most CORDEX datasets, "latitude" is not the Y axis. Rather it is the "rlat", which contains the "Y" information, the "grid_latitude".

Currently, this makes xcmor fail because it tries here to add the full attribute dict as the attributes of the "latitude" coord. And then the next call of da.cf.coords fails because the mapping to "Y" is not unique anymore, both "rlat" and "lat" pretend to be the "Y" axis.

So my question is, what does the "axis" in the "latitude" "axis_entry" represent ?

larsbuntemeyer commented 10 months ago

Yeah, that's basically right! xcmor does not really support this yet (https://github.com/larsbuntemeyer/xcmor/issues/16), however, the tables should be right. The coordinates table should only be involved with what CF conventions call coordinate variables (i think xarray calls this a dimension coordinate)

The way the cmor library handles grid mappings is via the grids_table and not the coordinates table. There you would find the correct meta data for a non-dimension, e.g., 2D, latitude/longitude coordinate.

aulemahal commented 10 months ago

Ah! I see, so it's almost just a matter of making xcmor use the "coordinate" table if ds.dims == (ds[dim].name,) and the "grids" table otherwise. Thanks!

larsbuntemeyer commented 10 months ago

Yes! The rules of how these tables are used by the original cmor implementation are not quite straight-forward. I guess, it's because that was primarily developed for CMIP6, so there is also some hardcoded stuff concerning certain global attributes, e.g., institution_id, source_id, etc.. I think there is a little less flexibilty because it has to support C and Fortran interfaces. I'll try to lay out some of the "rules" in xcmor issues (that should support like the original table structure, however, when i get some time to work on that, urgh.. )