Compliance checker is not handling CF 1.9 files correctly, and is complaining about CF 1.8 issues that are not correct

[mjbrodzik]

Version of compliance checker running: 5.0.0

Describe the checker this affects: CF

Attach a minimal CDL or NetCDF file which is able to reproduce the issue

To Reproduce: Uploaded attached file, and ran the checker NSIDC0630_GRD_EASE2_N25km_GCOMW1_AMSR2_E_10.7H_20230627_v2.0.nc.gz using CF-1.8, since it is the most recent one to select.

Describe the issue below: A number of the reported issues are complaining about issues that should be updated for CF 1.9, specifically:

1) "??2.2 Data Types

• The variable TB failed because the datatype is uint16
• The variable TB_num_samples failed because the datatype is uint8
• The variable TB_std_dev failed because the datatype is uint16"

CF 1.9 now allows unsigned types.

2) "??3.5 Flags

• TB_num_samples's flag_values must be an array of values not <class 'numpy.uint8'>"

We only included a single flag value, and we are not sure why the checker is requiring this to be a list and not allowing it to be a single value. (This doesn't appear to be a difference between CF 1.8 and CF 1.9)

3) "??5.6 Horizontal Coordinate Reference Systems, Grid Mappings, Projections

• Incidence_angle's coordinate variable "y" is not one of the variables identifying true latitude/longitude and its dimensions are not a subset of Incidence_angle's dimensions
• Incidence_angle's coordinate variable "x" is not one of the variables identifying true latitude/longitude and its dimensions are not a subset of Incidence_angle's dimensions
• TB's coordinate variable "y" is not one of the variables identifying true latitude/longitude and its dimensions are not a subset of TB's dimensions
• TB's coordinate variable "x" is not one of the variables identifying true latitude/longitude and its dimensions are not a subset of TB's dimensions
• TB_std_dev's coordinate variable "y" is not one of the variables identifying true latitude/longitude and its dimensions are not a subset of TB_std_dev's dimensions
• TB_std_dev's coordinate variable "x" is not one of the variables identifying true latitude/longitude and its dimensions are not a subset of TB_std_dev's dimensions"

We note that CF1.8 and CF1.8 both say: "To geo-reference data horizontally with respect to
the Earth, a grid mapping variable may be provided by the data variable, using
the grid_mapping attribute. If the coordinate variables for a horizontal grid
are not longitude and latitude, then a grid_mapping variable provides the
information required to derive longitude and latitude values for each grid
location. If no grid mapping variable is referenced by a data variable, then
longitude and latitude coordinate values shall be supplied in addition to the
required coordinates. For example, the Cartesian coordinates of a map projection
may be supplied as coordinate variables and, in addition, two-dimensional
latitude and longitude variables may be supplied via the coordinates attribute
on a data variable."

Since our data are projected, we interpreted this to mean that we could include x
and y as the coordinate variables (in projected meters), and together with the
"grid_mapping" attribute on each variable, this precluded the requirement to
also include 2D latitude/longitude coordinate variables. We think the checker is
not correctly interpreting the convention in this case.

4) "??2.6 Attributes

• ??2.6.2 references global attribute should be a non-empty string "

Our references global attribute contains a non-empty string, so we think this
might be a bug in the checker.

5) "??4.1 Latitude Coordinate

• latitude variable 'y' should define valid units for latitude
  ??4.2 Longitude Coordinate
• longitude variable 'x' should define valid units for longitude"

We think this is a further misunderstanding on the checker's understanding of the convention on horizontal
geo-referencing. Since the data are projected, the y(x) variable units have nothing to do with latitude(longitude) units.

6) "??8.1 Packed Data

• Variable TB and add_offset must be equivalent data types or TB must be of type byte, short, or int and add_offset must be float or double
• Variable TB_std_dev and add_offset must be equivalent data types or TB_std_dev must be of type byte, short, or int and add_offset must be float or double
• Variable Incidence_angle and add_offset must be equivalent data types or Incidence_angle must be of type byte, short, or int and add_offset must be float or double
• Variable TB_time and add_offset must be equivalent data types or TB_time must be of type byte, short, or int and add_offset must be float or double
• Variable TB and scale_factor must be equivalent data types or TB must be of type byte, short, or int and scale_factor must be float or double
• Variable TB_std_dev and scale_factor must be equivalent data types or TB_std_dev must be of type byte, short, or int and scale_factor must be float or double
• Variable Incidence_angle and scale_factor must be equivalent data types or Incidence_angle must be of type byte, short, or int and scale_factor must be float or double
• Variable TB_time and scale_factor must be equivalent data types or TB_time
  must be of type byte, short, or int and scale_factor must be float or double "

We think this is a problem with the checker expecting not to find unsigned
types, which is legitimate for CF1.8. See above, CF1.9 allows unsigned types.

[hot007]

Related to this, I found https://github.com/ioos/compliance-checker/issues/972 which indicated support for CF1-9 and 1-10 was on the horizon back in March 2023 but the current checker version (v5.1.1) still stops at CF1-8, can any of the devs give us a hint when support for the newer CF versions might be available, please? We have some files being written now to CF1-10 and even 1-11 standard and we can't check them.
Thanks!