Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CF-checker warnings when following example H.11 (Atmospheric sounding profiles) #211

Closed
GeyerB opened this issue Oct 30, 2019 · 4 comments
Closed
Assignees
Labels
question Further information is requested or discussion invited

Comments

@GeyerB
Copy link

GeyerB commented Oct 30, 2019

In the example H.11 (version 1.7) the variable profile is given with

variables:
      int profile(profile) ;
          profile:cf_role = "profile_id";

which is fine with me, but the checker produces warnings - could this be changed in next checker versions to INFO?

Using CF Checker Version 3.1.1
Checking against CF Version CF-1.7
Using Standard Name Table Version 69 (2019-10-15T14:39:18Z)
Using Area Type Table Version 9 (07 August 2018)
Using Standardized Region Name Table Version 4 (18 December 2018)
------------------
Checking variable: profile
------------------
WARN: (3): No standard_name or long_name attribute specified
WARN: (3.1): units attribute should be present
@GeyerB GeyerB added the question Further information is requested or discussion invited label Oct 30, 2019
@RosalynHatcher RosalynHatcher self-assigned this Oct 30, 2019
@RosalynHatcher
Copy link
Contributor

Not entirely sure what's happened here as there appears to be no section 9 in the conformance document to cover checking of discrete geometries although the checker does implement checks. I am happy to take an action to sort this out.

@RosalynHatcher
Copy link
Contributor

Specific to the warnings above as far as I can see the current recommendation is that all variables except boundary, climatology and grid mapping variables specify a long_name or standard_name. So I think that warning is correct. Warnings are just there to flag recommendations, they don't mean that the file fails CF compliance.

@neumannd
Copy link
Contributor

neumannd commented Nov 6, 2019

Chapter 9.5 of the CF Conventions document states:

Where feasible a variable with the attribute cf_role should be included. The only acceptable values of cf_role for Discrete Geometry CF data sets are timeseries_id, profile_id, and trajectory_id. The variable carrying the cf_role attribute may have any data type.

It does not explicitly state that the variable should have no standard_name but I would interprete these sentences in the way that the mentioned variable should have only the attribute cf_role.

However, the variable with attribute cf_role is not mentioned in conformance document chapter 3 (http://cfconventions.org/Data/cf-documents/requirements-recommendations/requirements-recommendations-1.7.html):

Recommendations:

  • All variables should use either the long_name or the standard_name attributes to describe their contents. Exceptions are boundary and climatology variables.

Thus, it should be explicitly stated in chapter 9.5 of the CF conventions document that standard_name and long_name are not needed for the cf_role-variable. Additionally, chapter 3 of the CF conformance document should be extended by this case.

@RosalynHatcher Is explicitly mentioned that the grid mapping variable does not have a standard_name or long_name? I mean: the grid mapping variable should not have these attributes but I cannot find it in the text (neither CF Conventions nor CF conformance). Actually, this information should also be in chapter 3 of the conformance document -- shouldn't it?

Should I submit a new issue on this topic?

@JonathanGregory
Copy link
Contributor

Dear all

Daniel @neumannd's comment reveals some inconsistency in the CF standard and conformance document. Section 3 of the conformance document has the recommendation, which he quoted,

All variables should use either the long_name or the standard_name attributes to describe their contents. Exceptions are boundary and climatology variables.

but that recommendation isn't made in the preamble to Section 3 of the conventions, which says only that CF supports long_name and introduces standard_name. The conformance statement should belong instead Section 3.2, which says

it is highly recommended that either [the long_name] or the standard_name attribute ... be provided to make the file self-describing

Unfortunately this text doesn't say what kinds of variable the statement applies to! To clarify this, I suggest that

  • We delete the existing recommendation at the start of Section 3 of the conformance document.

  • We insert instead a recommendation for Section 3.2: "All data variables and variables containing coordinate data should use either the long_name or the standard_name attributes to describe their contents."

  • We amend the third sentence of Section 3.2 of the conventions document to read "But it is highly recommended that either this or the standard_name attribute defined in the next section be provided for all data variables and variables containing coordinate data, in order to make the file self-describing," where the bold is new.

This is consistent with Appendix A. The long_name and standard_name can also be used for boundary variables, so long as the attribute value is identical to the one on the parent coordinate variable. That's shown by "BI'' in Appendix A, and was clarified in the latest version of CF.

Those statements also answer @neumannd's question about the grid mapping variable. That kind of variable does not have these attributes, according to Appendix A. Hence the checker would not give a warning if they are absent.

Section 9.5, about coordinates and metadata for discrete sampling geometries, says "one of the coordinate or auxiliary coordinate variables of a discrete sampling geometry should have an attribute named cf_role." That is, the cf_role variable is a variable containing coordinate data, so according to Appendix A and Section 3 the cf_role variable is recommended to have either a standard_name or a long_name. That's consistent with what @RosalynHatcher said.

In summary, I don't think there's a problem with the warnings that @GeyerB reported. The checker is correct. But there are some defects in the documents, as outlined above. Therefore I am going to close this issue now, since it was raised as a question and nothing has been said for over four years, with thanks to the contributors, and I will open a new defect ticket. Please reopen this issue or begin a new one if you think the question hasn't been answered.

Jonathan

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested or discussion invited
Projects
None yet
Development

No branches or pull requests

4 participants