BR is just a variable, defined on the first line as the output of `str_get_nl()`
--
Reply to this email directly or view it on GitHub:
It's noteworthy that ncdump renders an embedded newline as '\n' followed by an
actual newline. I'm not sure how this relates to the way that Julia works, but
when I'm adding embedded newline characters to long strings in NCL, I just add
a newline, not an escape sequence. So I write code like
Thanks for the clarification! If we get version-level DOIs for free from
Zenodo, that's fine, I see no reason to go out of our way to avoid them. That
also means that there are likely to be future solutions for maintaining them,
since there will be a large community of users in the same boat.
I agree that it makes sense to have a top-level DOI for CF, and then
lower-level ones for cf-conventions and the standard names. I think level C is
too granular and complex, and that we would be asking the community to commit
to maintaining a large number of DOIs in perpetuity for
2 is not valid. The `coordinates` attribute should reference variables that
give actual coordinate values for the data variable, not information about the
coordinate system.
For examples, the most common contents of the `coordinates` attribute that I've
run across are references to
I support this proposal and favor pushing forward on #148 rather than adding
more about leap seconds here.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
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
I will also second @MaartenSneepKNMI's recommendation to restrict legal CF
variable names to ones that could be used as variable names in important
programming languages. It enables some very useful programming paradigms. I
think it would also be good to mention that reasoning explicitly in
I also agree. This would be a significant break in backwards compatibility for
a very large number of data products.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Looks good to me! I approve.
--
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/273#issuecomment-656791529
This list forwards relevant notifications from Github. It is
@JonathanGregory It does, but in that case, I think the current wording is too
strong. I don't think zero external references is achievable. Much as we try
to make them intuitively obvious and self-explanatory, it's not uncommon to
have to look up the precise definitions of controlled
There's a subtle point here that I just got tripped up by (I wrote and then
deleted a long but erroneous comment), which is that the first principle of
self-description is talking about the *metadata* being self-describing, not the
*entire file contents*. Is that correct?
Which is to say, in
For me, Ryan's suggestion of a cf-prefix on attributes would be too large a
break in backwards-compatibility; I don't think I could support it. Karl's
suggestion of listing cf attributes somewhere seems more reasonable. Though
maybe it would be better to put it in a separate global attribute
A use case for cell_methods involving climatology:
We have an archive of regional climate model outputs. To improve their
usability for impacts users, we generate various aggregations at different
frequencies. We provide daily, monthly, and seasonal timeseries data, as well
as monthly and
I think the proposed change sounds good, and I support 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/260#issuecomment-617927988
This list forwards relevant
@martinjuckes Good point. The auxiliary coordinate is indeed a better fit than
flag constructions. That being the case, I think I have to side with
@JimBiardCics that `string x(x)` strikes me as the most straightforward and
user-friendly way to construct that auxiliary coordinate, and it
I can offer a clear-cut use case: the ensemble dimension. If you have output
from multiple simulations that you want to combine into a single block of data
for analysis, you can easily do so with NCO's ncecat operator. However, if you
want to label the members of the ensemble in a
17 matches
Mail list logo
