Jeff Painter tells me that "Standard names have been moved to Github along with
the CF Conventions document and most of what it references. See
If the grib tables are reasonably up to date, I think we should retain links to
them; it would help some users correctly identify data of interest outside of
CF.
--
Reply to this email directly or view it on GitHub:
Doing a quick search of our (PCMDI's) latest website, I haven't found these
pages (yet). Doing a web search, I came across a [2014
I can't come up with anything completely objective. Perhaps folks who think
they're deserving should nominate themselves (or others could nominate), and if
the CF committee chair or anyone on the governance board supports the
nomination, the person would be included. It would be nice to
I support this proposal too (for the same reasons).
--
Reply to this email directly or view it on GitHub:
Another example for observations might be something like ``source = "the MSU
(Microwave Sounding Unit) instrument flown on the XXX satellite produced
radiances that were converted into lower tropospheric temperature estimates
using the YYY algorithm"``. Not sure that's a great example, but it
I don't think we should limit source information in this attribute, but leave
it up to the user to decide how much detail is provided, including back to the
initial source if they like.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
I hadn't thought of that being necessary. On reflection, I don't really see a
need to allow the parenthetical information to appear anywhere except at the
end of any phrase specifying a method (but of course each method phrase could
have parenthetical information, so multiple parenthetical
To be sure, in CF an alias is a standard_name that might have been used in the
past, but is now deprecated. So as David says, the standard_name you should
use is ``surface_temperature``, and you should include the ``cell_methods``
attribute, which in the simplest case might be set to
Yes, thanks for your prompt review. Much appreciated since I wouldn't be able
to get to it for some time.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Editorial suggestion:
In the statement,
```
To ensure that the results of the coordinate reconstitution process are
reproducible and of
predictable accuracy, the creator of the compressed dataset may specify the
floating-point
arithmetic precision to be used in the interpolation method
Thanks, Jonathan. Seems clear and close now. With these changes we'll be able
to close both 298 and 319! Real progress.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
>From the above, it's not clear to me whether or not a strict_gregorian
>calenadar is or is not being proposed. I think it would be a mistake to
>include it, and I don't think "strict" is optimal as a descriptor. I'll
>provide reasoning if it *is* in fact being proposed here.
--
You are
I have a preference for "optional" because I suspect in most cases 32-bit will
be sufficient and this would relieve data writers from including this
attribute. There may be good reasons for making it mandatory; what are they?
Not sure about this, but I think "should" rather than "shall" is
Wouldn't the statement be correct as is (perhaps rewritten slightly; see
below), if we indicated that if the computational_precision attribute is *not*
specified, a default precision of "32" should be assumed? I would think
that almost always the default precision would suffice, so for most
looks good to me. Can we omit "base-2" from the descriptions, or is that
essential? Might even reduce description to, for example:
```
"32": 32-bit floating-point arithmetic
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
I don't understand the difference between decimal64 and binary64 or what they
precisely mean. If these terms specify things beyond precision, it's probably
not appropriate to use them here, so I would support defining our own
vocabulary, which would not confuse precision with anything else.
yes, ``calculational_precision`` was a mistake; I prefer
``computational_precision``. Also I'd be happy with not referring to an
external standard, and for now, just suggesting that two values, "decimal32"
and "decimal64", are supported, unless someone thinks others are needed at this
time.
Thanks @AndersMS for the care taken to address my concern, and thanks
@davidhassell for the proposed revision. A few minor comments:
1. I wonder if users could be given the freedom to do their interpolation at a
_higher_ precision than specified by ``interpolation_precision``. I would hate
I like Martin's restructuring of the information. Two further suggestions:
In section 4.1 the ``no_leap`` or ``365_day`` calendar is defined as a
"Gregorian calendar without leap years, i.e., all years are 365 days long." I
don't think we want to exclude 0 or negative years for this calendar,
I am in favor of the intent of the changes. With respect to the wording, I
offer two general suggestions:
- I think in reference to dates and calendars, we should avoid the terms
"real-world", and, rather, say exactly what we mean by it.
- I think the references to and description of the
And while we're at it, what about the ``julian`` calendar? Should we, for
consistency, deprecate its use for dates after 1582? Perhaps not, since there
are probably some models with simplified calendars defined in which leap years
invariably occur every 4 years.
--
You are receiving this
I agree with Jonathan that we should avoid making changes that make illegal
something that is currently legal in C. I would therefore favor his suggestion
to deprecate ``gregorian`` when dates precede 1582. Users who want to use the
gregorian algorithm to compute dates before 1582 should
Likewise, I have put off commenting, as the two of you have made good progress.
Now that things are clearly getting serious, I would suggest to
1. Avoid any comment about "synchronization" with the civil calendar (which I
think already is recognized in
I agree. It's o.k.
Thanks.
--
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/304#issuecomment-789802835
This list forwards relevant notifications from Github. It is
My proposed definition ("weighted-mean of ...") could easily be misinterpreted
in a way that in computing the mean, specific humidity would be used rather
than the water vapor mixing ratio (referred to as "humidity ratio" in the
above). So a second attempt:
definition: the enthalpy of air
"and related to the mass fraction of the dry air" seems vague to me. I
understand that the enthalpy of air will depend on the relative amounts of
various constituents (e.g., N2, O2, and trace species), which would often be
assumed to be fixed, and that it also depends on the water vapor
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
I would agree that it would be nice if any variable name found in a
CF-compliant file were able to be adopted without modification in the
programming languages used in climate science. This would facilitate code
documentation and generally make it easier for users, I think. So I support
the
Mmmm do you mean the suggested edit "seems fine to me" or do you mean the
document as it now stands seems fine. Like @neumannd I think all the entries
in the List of Examples at the top of the conventions document should be
consistent and *not* repeat the table number.
I would note that
I would not like to introduce these new names because, we can already store the
variables as we have done historically. In support of CMIP over more than two
decades, we have stored these variables with the accepted standard names and
with a scalar coordinate variable providing the height
Yes, count me as a supporter. Thanks.
--
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/222#issuecomment-657604753
This list forwards relevant notifications from Github.
I didn't examine every sentence too carefully this time, but my reading is this
covers everything and is clearly written. I support it.
thanks to all contributors and David for moderating.
Karl
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
Oh, I just saw that the crossed out "is". Sorry.
--
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/222#issuecomment-656300980
This list forwards relevant notifications
@snowman2 My poor brain can't seem to detect what exactly was tweaked. Could
you please point to the specific change made?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yes, I think the intent of this is fine.
I don't recall the text that precedes the revised text, but should the first
sentence read:
"If, *for a given property,* both crs_wkt and grid mapping attributes exist,
the attributes must be the same and grid mapping parameters should always be
Regarding the recent revisions to the "principles", I like the revisions you've
made in
https://github.com/cf-convention/cf-conventions/issues/273#issuecomment-649396973
, and I think there are no references to "files" now (only to "datasets"),
unless I've missed something. The suggestion by
I might reorder the first sentence (so that the parenthetical statement at the
end directly follows the phrase it modifies): "In defining some of the
descriptors that make CF-netCDF files self-describing, CF-netCDF relies on
controlled vocabularies containing terms that are chosen as far as
Which parts of the sentence:
"If both crs_wkt and grid mapping attributes exist, the attributes must be the
same and grid mapping parameters should always be completed as fully as
possible."
should trigger an error (warning?) in a compliance checker? Is the file
compliant if the two are
I agree that informing the data provider of conflicts when found is good
practice. But what behavior should software have? Should it just stop, or can
we tell it which of the two conflicting pieces of information it should rely on
(until the conflict has been resolved)?
My general ignorance
Yes, to me [that](https://github.com/JonathanGregory) seems like a good
solution. If a user wants to assume that when there are conflicts, the WKT
values take precedence, then that's o.k. But, if the user wants to check the
values for consistency, then when they conflict, the user should
I think I prefer having the optional (and sometimes non-standard) parenthetical
information coming at the "end of the phrase identifying the method"; breaking
up the main elements of the method seems unnecessary. I would prefer, for
example "mean where sea_ice (and in the immediate vicinity of
thanks to @mathiasbockwoldt for pointing this out and to @JonathanGregory for
proposed wording, which I support.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Just curious and maybe I should know this, but what does "WIP" stand for in the
issue title?
--
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/pull/259#issuecomment-617324452
Yes, thanks for moderating, 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/174#issuecomment-598784783
This list forwards relevant notifications from Github. It
I vote to forbid string x(x), consistent with my earlier view on this:
https://github.com/cf-convention/cf-conventions/issues/174#issuecomment-517316061
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I *was* indeed confused, but I probably shouldn't have been. Thanks for going
to the trouble of explaining. I think your original diagram should be clear
enough to those thinking clearly.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
I'm either confused, or I agree with @davidhassell
(https://github.com/cf-convention/cf-conventions/issues/193#issuecomment-525778635)
that in the lower figure the abscissa and ordinate axes are mislabeled.
Don't the dashed lines in the figure represent lines of latitude and longitude,
not
I haven't been following this, but what about tripolar grids, which are often
used in ocean models?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
As a user of data, I usually like the names of my variables (in my codes) to be
the same as their names in the netCDF file. With the current naming convention
for CF, this is always possible, I think. If, however certain restrictions
were removed, as suggested above, this would no longer be
I must be missing something, but if a variable is named, for example, "a-b",
and one uses that in a computer code, how is it interpreted? How is that
variable distinguished from the operation: subtract variable "b" from variable
"a"? Don't "+", "-", "/", "*", " " all have this problem?
--
likewise, I think this correction should be made.
--
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/226#issuecomment-573759928
This list forwards relevant notifications
I support keeping the conformance and standards documents separate (and I
support the rest of above too).
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/221#issuecomment-567571663
Hi all,
I am told that PCMDI's maintenance of the Trac site here at LLNL is becoming
more fragile for a number of technical reasons and our scarce resources to
invest in it also make it problematic, so from a practical perspective our
systems folks here would favor moving to github (although it
Yes. It's fixed.
--
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/8#issuecomment-380218022
Could we discuss this at the meeting in Reading in June?
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/127#issuecomment-380216568
perhaps a ping here will work: @painter1 , please see above.
--
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/124#issuecomment-376208207
57 matches
Mail list logo
