Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
I think that it would be OK to require the same data type as well the same value. In fact I slightly prefer identity of both type and value, because to me it seems that providing something which is _exactly_ redundant is more like providing nothing at all, which is what we want. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/265*issuecomment-940993397__;Iw!!G2kpM7uM-TzIFchu!jZAyaRU-S8sBqamYWqw_Ih02zKC4bhC9qeTg4MYapUz8EyCSVF7P7_LTKZKur5GTwSh6wb3JPu4$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
Hi all, I'm still re-assimilating what went on here, but it occurs to me that allowing data type equivalence (rather than equality) is problematic: * The `missing_value` and `_FillValue` (and the `valid_*` attributes) must be of the same data type as the data to which they apply, so if they these attributes are inherited, then the bounds must be of the same data type. * If the bounds are strings and the coordinates chars, then the bounds will _not_ have the extra dimension, as is currently required: "_A boundary variable will have one more dimension than its associated coordinate or auxiliary coordinate variable._". (This is easily dealt with via a caveat, of course.) * Although most software does support type casting, it is not always done in the same way (for example, in Python the default type casting rules of numpy have recently changed), and even if it is done as expected, the recast numbers may produce undesired results in ways that may be hard to detect. Thanks, David -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/265*issuecomment-939966466__;Iw!!G2kpM7uM-TzIFchu!hnUIyIO55kD9aTWBt8vQMiLX4Cc2aQHed6RzK22VzsJrxhE9viK8P6udDYy8tmspEpQy0b7NHUE$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
@davidhassell , @sethmcg : I think it may be possible to have auxiliary coordinate bounds for a cell which is missing it's central value, but I don't think the question if really relevant here in either case. The `missing_value` and the `_FillValue` should apply to both the auxiliary coordinate and to the bounds, and be specified as attributes of the auxiliary coordinate variable. I don't think this requires any modification of Jonathan's suggested text, or is there some objection that I am missing? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/265*issuecomment-938021471__;Iw!!G2kpM7uM-TzIFchu!k_fRJ-CvltbEZGSZxuiVezMV6_bzeVv6dOKJ-3YXibePawMyl8YKsnOqb5g81by2d2oeKhWaIzg$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
Hi @sethmcg, you are right that missing data is disallowed in coordinate variables, but it is for auxiliary coordinate variables. The bounds may have missing data where the parent auxiliary coordinates do not (_grid cells with a varying number of cell bounds_ #163). Is it possible for the opposite to occur, i.e. the auxiliary coordinate is missing but the (some of) its bounds are not? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-745131644 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
Missing data is disallowed in coordinate variables. (First paragraph of section 2.5.1.) Do bounds variables inherit that restriction as well? I would presume so, but maybe someone has a counter-example. Either way, it may be worth spelling out explicitly. In any case, I think there shouldn't be any `missing_value` and `_FillValue` attributes on coordinate variables to inherit, since they would be superfluous at best. Is that something that should be mentioned as a best practice? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-744765821 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
Dear @JonathanGregory , Thanks - I like you suggested text. The other attributes you mention might suggest different wording, though. My initial thoughts on those attributes: I would say that `add_offset`, `scale_factor`, `valid _*`, `missing_value`, and `_FillValue` should **not** be inherited from a parent coordinate variable, because they relate only to packing and encoding choices which do not affect the physical interpretation of the bounds. These might reasonably be different to the parent coordinate variable, as the bounds can be much larger. `compress` is trickier still, as whether or not it should be inherited depends on whether or not the bounds variable is compressed by gathering, or not (which reminds of https://github.com/cf-convention/cf-conventions/issues/147). I would say that it is also not inherited, so if the bounds variable are compressed by gathering then it carries its own `compress` attribute. I reckon `cf_role` is inheritable, and should have the same value as the parent, if provided. `bounds` and `nodes` are also non-inheritable, as all they do is name the bounds variable itself. I think `geometry` is only specially defined for data variables (and so Appendix A has defect in suggesting otherwise!) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-744471479 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
Thank you both for your comments. @Dave-Allured asks whether "such as" with examples is "acceptable". It feels harsh to say "No, it's unacceptable", but I'd really prefer us to specify them. You do have text which describes the characteristics of the variables concerned, and that's fine, but it's safer for the convention also to say explicitly which ones they are, since people using the convention would probably not always make the same decision. As @davidhassell shows, it doesn't make the text more complicated. If anything, it's a simplification. I'd like to suggest a further rewording, to avoid introducing "active" as a CF jargon word, and put things in a slightly different order: > Since a boundary variable is considered to be part of a coordinate variable's > metadata it is generally not necessary to provide it with attributes, because > the boundary variable is assumed to inherit all of the attributes of its > parent coordinate variable (with the exception of the `formula_terms > attribute`, which may be required, as described in the next paragraph). It is > recommended not to include any attribute on a bounds variable which affects > the interpretation of values (such as `units` and `standard_name`, see > Appendix A for the complete list of such attributes), and it is permitted to > include such an attribute only if its string or numeric value is exactly the > same as the parent variable's attribute. The data types do not need to match, > but must be compatible for comparing values. If any other attribute is > provided on a bounds variable, it takes precedence over any corresponding > attribute of the parent variable. Which are the attributes concerned, apart from `units` `standard_name` `axis` `positive` `calendar` `leap_month` `leap_year` `month_lengths`, which @Dave-Allured has identified? Looking at Appendix A, I am unsure, so I think we do need to decide. Probably `computed_standard_name` should be in that list as well. Is it required that bounds must be packed in the same way as their parents with `add_offset` and `scale_factor`? Must they have the same valid range, `missing_value` and `_FillValue`? Do `cf_role` `compress` `geometry` `nodes` have any CF meaning for a bounds variable? Looking at all these, I incline more strongly than before to thinking we should add this to Appendix A. In the existing *Use* column, we could add an indicator for those coordinate variable attributes (marked as C) which are allowed but deprecated and must agree with the coordinate variable, and those which are allowed and may be different from the coordinate variable, such as `long_name`. It would be clearest if every C attribute was put in one of these two categories, except `formula_terms`, which has special rules. Jonathan -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-743275895 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
Hello @Dave-Allured, @JonathanGregory and all,
I agree with @JonathanGregory - spelling out the "active" attributes in the
appendix A table is a good idea. As long as it's permissable, software
providers and data creators will need to be able to unambiguously know the
exact list of active attributes, and the "such as" list in the text doesn't
really do that, I feel. If we don't know what they are, it is likely that
others won't, either! I suspect readers would see the "such as" list, but not
then check the rest of the conventions for any other attributes they're not
aware of that might be active.
If this is flagged in appendix A, then it is guaranteed that any new attributes
will be considered for activeness, as when they are added to table in Appendix
A, the author will see the "Active" column, and be forced to put in a value. It
is more likely that a list embedded in the text (like we had in 1.8) would be
overlooked.
I propose this rewording:
Since a boundary variable is considered to be part of a coordinate variable's
metadata it is generally not necessary to provide it with attributes, as the
boundary variable is assumed to inherit all of the attributes of its parent
coordinate variable (with the exception of the **`formula_terms`** attribute).
When a bounds variable attribute is provided, it takes precedence over any
inherited value. However, when duplicating "active" attributes which affect the
interpretation of values (such as **`units`** and **`standard_name`**, see
Appendix A for the complete list of active attributes described by this
standard), their string or numeric values must be exactly the same as the
parent variable attributes. Data types of these duplicated attributes do not
need to match, but must be compatible for comparing values. Duplication of such
active attributes on the boundary variable is permissible but not recommended.
Then the next short paragraph ("Purely descriptive attributes which do __not__
affect interpretation ...") is not needed.
Thanks,
David
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-743068067
This list forwards relevant notifications from Github. It is distinct from
cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the
UCAR list will result in a subscription to this list.
To unsubscribe from this list only, send a message to
cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
@JonathanGregory, I don't agree. You are asking for robust enumeration for a redundant data feature that is recommended against using. This has already been cumbersome for building the current draft. There will be extra work to examine the several dozen other possible cases in Appendix A. Then there will be added future responsibility to check for boundary attribute conflicts whenever a coordinate attribute is newly added or adjusted. I also think adding a new notation in Appendix A is not appropriate. So I think a new precedent is needed. I think we need to explain these potentially conflicting duplicate attributes by description, not by enumeration. As a start, I wonder whether you find acceptable my current wording, using the device of "such as" to generalize and convert the following into simply a list of examples. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-742826763 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
Dear @Dave-Allured Which other attributes are "active"? It would be best to spell them out. I don't think it's too much to be cumbersome. Another way (but more work for you) would be to add some indication to the relevant attributes in Appendix A, instead of listing them explicitly here. That would make the text more future-proof, probably. I'm still definitely in favour of this proposal! Thanks Jonathan -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-742492341 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
On review I found other attributes that are missing from that list of CF active attributes. This is getting cumbersome. So I generalized the list by adding the fuzzy prefix "such as", so that unpredicted cases would be included: https://github.com/Dave-Allured/cf-conventions/commit/ea5994bf15786e9dc81ccfbb013830698ccd65ca I figure this is not controversial, but who knows. Call for votes is still active, unless there are further change requests. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-742129213 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
**Summary and request for consensus.** I propose to move [this pull request](https://github.com/Dave-Allured/cf-conventions/pull/3) forward under [Rules for CF Conventions Changes](http://cfconventions.org/rules.html). Here is a summary of the current proposal. See the PR itself for full text of changes. - Changes to the first part of [CF section 7.1, Cell Boundaries.](http://cfconventions.org/cf-conventions/cf-conventions.html#cell-boundaries) - On boundary variables, require exact value match with the parent coordinate variables, for CF defined attributes which affect the interpretation of values. - Also clarify requirements for data types of such attributes. For full consensus, support is needed from at least two members of the conventions committee, and at least one other contributor. Please indicate your vote for support or dissent at this time, until we have the minimum necessary votes. The vote is open to all interested persons. I vote +1 in support. If there is full support and no dissent or new change requests, I will finalize the pull request and send it to [CF master](https://github.com/cf-convention/cf-conventions) after the three week waiting period. Votes and further comments should be sent to this CF issue #265. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-742084428 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
@Dave-Allured : OK, thanks for the clarification on [data types](https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-738965653) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-739824557 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
Fixed, thanks. Also one other minor grammatical improvement. https://github.com/Dave-Allured/cf-conventions/commit/f8d7a28a66ac4c4ac33a47bdd7462e4e68b5e434 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-739028681 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
Dear @Dave-Allured I think think this is fine, thanks very much, except there shouldn't be a comma between the parenthesis and "should be inherited". Best wishes Jonathan -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-739015861 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
@martinjuckes asked: > This looks likely to cause confusion, as some software may consider them as > different. Wouldn't it be better to at least recommend that they have the > same data type? I actually had exact type match in one of my drafts, then thought about it and changed to simple compatibility. If type match is either required or recommended, this adds responsibility and complexity on both data creators and conformance checkers. Much existing software provides easy comparison between mixed types. Some software goes a step further and reads netcdf input to generalized types, such as ingesting both `string` and `character` as undistinguished internal strings. E.g. NCAR's own NCL language, ever since the addition of the new netcdf type `string`. I think the cost of exact type match exceeds any benefit. Also I think this draft statement of type compatibility merely clarifies the status quo for CF policy on data type of boundary var attributes. Further thoughts? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-738965653 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
@martinjuckes, yes, `string` vs. `character`, that is a good example of what I mean by compatible. > Data types of the duplicated attributes do not need to match, but must be > compatible for comparing values. I think this is needed for a complete answer to the original question of agreement between coordinate and boundary attributes. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-738949818 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
@Dave-Allured : Sorry, I misunderstood that bit about data types. You mean that the convention should accept having, for instance, `calendar` as a string variable on the main variable and a character array on the bounds variable? This looks likely to cause confusion, as some software may consider them as different. Wouldn't it be better to at least recommend that they have the same data type? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-738654003 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
Sorry, wrong link. Further simplification of third paragraph: https://github.com/Dave-Allured/cf-conventions/commit/31ca211f6e21dcea6082912eb67897511f55d725 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-738240837 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
Further simplification of third paragraph: https://github.com/Dave-Allured/cf-conventions/commit/ad27ae4febd4f6bb9aaa6e72ebd223cb55b03efe -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-738237416 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
Dear @Dave-Allured I would like this wording which you suggested, "Boundary variable attributes which are significant to CF interpretation (units, standard_name, axis, positive, calendar, leap_month, leap_year and month_lengths) must always agree exactly with the same ...". I think that's a good definition of why we're concerned with them, and I don't see a need to distinguish the groups. I like your `long_name` paragraph, but I think it would be better after the `formula_terms` paragraph. I feel we should say, "These ones must be like this, these other ones like that, and all the rest it doesn't matter" rather than putting all the rest in the middle. Best wishes and thanks Jonathan -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-738006781 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
@martinjuckes said: > ... the last sentence in the 2nd paragraph (line 14) of your text reads > "Their data types do not need to be an exact match." I think that "Their" > refers to the parent variable and the bounds variable, but grammatically, as > written, it appears to refer to the attributes. It might be clearer if placed > at the end of line 12? Okay, how about this? I like the flow of concepts as it is now, but this fixes the improper pronoun. https://github.com/Dave-Allured/cf-conventions/commit/4268d30fd3fbd2f39e548c3d8dcf4542528c917a -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-737545718 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
@JonathanGregory said: * You mention `long_name` as an example but it's not one of the attributes "controlled" by this restriction. The reader might wonder about it. Perhaps it would be better not to mention `long_name` in this paragraph. We could add a final paragraph, after `formula_terms`, to say something like, "Other attributes not mentioned above, such as `long_name`, may have different values for the coordinate and boundary variable, if present on both." I added a new short paragraph for this, and expanded a little. Check out this commit: https://github.com/Dave-Allured/cf-conventions/commit/44fcdb128860d963a5ed1ccb0cf8fca1f345d98e I preserved the opening sentence because it was a general introduction to the concept, and also it was inherited like this from the original in CF-1.8. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-737454409 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
@JonathanGregory, thanks for the feedback. Your help with the wording is appreciated. I thought the term "functional attributes" might be understood from context. I was looking for a short collective term that means "attributes that are functionally active in the CF interpretation of the variable". On review, I notice that the original sentence in CF-1.8 is kind of puzzling in its own way. > Boundary variable attributes which determine the coordinate type (units, > standard_name, axis and positive) or those which affect the interpretation of > the array values (units, calendar, leap_month, leap_year and month_lengths) > must always agree exactly with the same ... Is it appropriate here to explain distinction between the first and second groups? What is the best way to describe the general intention here, yet try to remain concise? For the purpose of this section, I think we only care about indicating which attributes are significant in some way to CF interpretation and processing. Let me tentatively merge the two groups, because the distinction may not be locally relevant, and try this simplified wording without "functional": > Boundary variable attributes which are significant to CF interpretation > (units, standard_name, axis, positive, calendar, leap_month, leap_year and > month_lengths) must always agree exactly with the same ... Do you like this, or have another suggestion? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-737437164 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
Hi @Dave-Allured , @JonathanGregory : Dave is right, the main motivation for raising this was to see if something of the form: ``` double time(time) ; time:bounds = "time_bnds" ; time: calendar = "noleap" ; double time_bnds(time,nb) ; time_bnds: calendar = "365_day" ; ``` should be considered as valid. My interpretation of the status quo is that the convention is ambiguous, so I don't personally think that a clarification would break with backward compatibility. The strict interpretation, treating the above as an error, is in line with the current behavior of the `cf-checker`, which is how I became aware of the CMIP6 files which contain this syntax. @Dave-Allured : the last sentence in the 2nd paragraph (line 14) of your text reads "Their data types do not need to be an exact match." I think that "Their" refers to the parent variable and the bounds variable, but grammatically, as written, it appears to refer to the attributes. It might be clearer if placed at the end of line 12? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-737436214 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
Um, @martinjuckes **did** literally say there are existing files with this conflict. First paragraph under **Status Quo** above: "Some CMIP6 data, for example, has been provided with time coordinates using one form and the bounds variable using the other." Presumably such files are labeled as `Conventions = CF-1.8` or earlier. So I agree, they are technically conformant because of this label, but would be non-conformant if re-labeled to a later CF version. My strict wording of this requirement was intentional, based on the discussion up to this point. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-737384125 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
I assume that @martinjuckes meant that some CMIP files might say `noleap` and others `365_day`. I don't think he meant that there are existing files in which `noleap` was used on the coordinate variable and `365_day` on the bounds, for example, but he was concerned that this might currently be allowed. This proposal would disallow it. If there are any such datasets, they would be invalidated by the next version of the conventions, but not by the version they were written with, of course. In general we don't like even this sort of backward-incompatibility but I think it's harmless in this case. If software chose to rely on the new convention and assume that the bounds had the same calendar as the coordinates without checking, the outcome would still be OK if it's equivalent although not exactly the same string. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-737372464 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
To be sure, is the change in text backward compatible or will it make some datasets that were considered conformant with CF now non-conformant? (nb. It is stated in https://github.com/cf-convention/cf-conventions/issues/265#issue-614215549 that "Some CMIP6 data, for example, has been provided with time coordinates using one form and the bounds variable using the other.") -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-737363723 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
Apologies, I made a github newbie mistake and failed to squash my commits. Please review changes in the next PR to follow. They will be easier to read. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-736944864 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
There seems to be a consensus. Please review my suggested changes in the above PR. Note that for consistency, I expanded this to all functional attributes on boundary variables, not just `calendar`. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-736940477 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
Hello @JonathanGregory and all, I don't have a use case for allowing a different string that means the same, and agree that providing exactly the same string is the nearest thing to not providing any string. Therefore, I'm happy to agree with the the "exact string match" interpretation. Thanks, David -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-631577522 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
@davidhassell, please consider that bounds variables are unique in relation to ordinary data variables, thus the analogy to instruments with equivalent unit strings is not a very good comparison. A bounds variable should be nothing more than a close extension of the parent coordinate variable. Its only purpose is to provide explicit cell boundary values for each coordinate value. A better analogy would be to actual_range attributes. By their structure alone, these can not have their own independent interpretive attributes, and always inherit from the parent. I see bounds variables in the same light. IMO the practice of varying attribute string values on bounds should be discouraged or prohibited, thus I favor the original intent to prohibit non-exact string values. The message to dataset creators should be simply, "Don't do this." -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-630974973 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
Dear @davidhassell I agree that exact string match is unlike the rest of CF. It seems OK and appropriate to me in this case because providing exactly the same string is the nearest thing to not providing any string, and thus taking the default i.e. the value on the coordinate variable. It is transparent and easy to check that the attribute on the bounds is giving the same information if it must be the same or absent. I think that we would be better off if we had not allowed attributes on bounds variables. However, you could argue there was a purpose or advantage in allowing a different string that meant the same. That would be an enhancement, as you say, for which we need a convincing use-case. Best wishes Jonathan -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-630821774 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
I don't particularly like the idea of insisting on "exact string match", because it is contrary to how the rest of CF works. For example, if output from one instrument has a data variable with units of `'watt'` and the output from a model has a comparable data variable, in the same netCDF file, with units of `'meter^2-kilogram-second^-3'`, then that is fine, even though it may lack clarity for the user. I think that it would useful to _recommend_ that exact string matches are used, for clarity, but not to insist on it. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-630704524 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
@davidhassell : David A. and Jonathon are both in favour of requiring an exact string match (my [option (B)](https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-627193357), your [option (ii)](https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-627276400)). Are you happy with this interpretation? I agree with Jonathon that this is preferable in order to preserve clarity in the file metadata. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-630594127 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
OK - are these the three choices, then (in no particular order)? **i)** Drop the word _exactly_ from _"must always agree exactly with the same attributes of its associated coordinate, scalar coordinate or auxiliary coordinate variable"_ (7.1) as rectifying a **defect**. **ii)** Keep the word _exactly_ but clarify it to mean "exact string match". This is also rectifying (a different) **defect**. **iii)** Drop the word _exactly_ from the sentence as an **enhancement**. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-627276400 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
Evidently we didn't think of this problem. As far as I remember, I had in mind that the strings would have to be exactly the same (B), because it's simpler to check and consistent with them not being needed anyway, which is why they're deprecated in general. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-627229947 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
Hi @davidhassell : thanks. There is a use case for providing attributes on bounds variables in the Trac ticket which you cited ([140](https://cf-trac.llnl.gov/trac/ticket/140)) : @taylor13 describes a usage where the user needs to know the `units` of the bounds variable and does not make use of the parent coordinate variable. However, the more important point, I think, is that the status quo is clearly that use of these attributes on the bounds variables is clearly deprecated and not forbidden. Changing that would, as you say, be a discussion for another issue. @JonathanGregory , @taylor13 : can you help with the interpretation of the intention of the discussion in [Trac 140](https://cf-trac.llnl.gov/trac/ticket/140) on the precise rule for `calendar` attributes on bounds variables? In particular, if a variable has `calendar = noleap`, would `calendar = 365_day` on the bounds be: - (A) deprecated as being the same but redundant or - (B) forbidden as being a different string (not exactly the same, even though it has exactly the same meaning)? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-627193357 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
The original discussions took place on Trac ticket 140 (https://cf-trac.llnl.gov/trac/ticket/140), which was accepted for inclusion into CF-1.7. I'll mark this issue as a defect for now. Deprecating (rather than banning) these attributes is, of course, possible, but I don't feel there is a use case for it at this time. I wonder if there _are_ use cases for bounds variables having, for example, different but equivalent units, or for bounds variables being used independently of their parent coordinate variables (in which case having units, names, etc could be useful). In any event, that perhaps is a discussion for a separate issue, if anyone wants it. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-626705909 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
@davidhassell : OK, I'd be happy to treat this as a `defect` issue -- do you recall where the intention you refer to was discussed? Or who was involved? @Dave-Allured : I'm not sure why the original choice was made. It would certainly be simpler to ban these attributes on bounds variables, but doubt that it justifies changing the status-quo. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-626692580 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of requirements on calendar attribute of a bounds variable (#265)
Hello Martin, The intention, as I recall, was for agreement in meaning, rather agreement in the the exact strings, but that intent clearly didn't make it into the text. If people agree, I would suggest the addition of some suitable wording to make this clear would make this a defect, rather than an enhancement. Thanks, David -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-625387982 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
