Dear Seth
I think we can devise systems which will develop *proposed* standard names
that conform to existing patterns and lexicon. If they do, they are often
uncontroversial and usually accepted. However we still need a manual approval
process because there are sometimes choices about how a
Sent: Wednesday, March 02, 2011 5:37 AM
To: Seth McGinnis
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] standard_name modifiers
Dear Seth
I think we can devise systems which will develop *proposed* standard
names
that conform to existing patterns and lexicon. If they do
Dear All,
I've made a couple of fixes to the CF checker:
1) If the variable is deemed unitless, then the checker will not flag an
error if either units=1 or the units attribute is omitted.
2) Fix bug where the checker was incorrectly complaining about a missing
units attribute on some
Can we please resurrect the topic of a grammar for standard names, which
Jonathan and I have raised in the past? - see
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2010/007093.html for
an entry point.This discussion illustrates as clearly as can be that
the time has come to really get
Dear Jonathan et al.,
maybe I am fighting a lost battle here, but let me try to argue once more
for a generalized solution, i.e. the addition of anomaly as a standard name
modifier. I don't like the idea of adding a new standard name for each new
anomaly: i) this seems illogical and new
Of Schultz, Martin
Sent: 28 February 2011 08:14
To: Jonathan Gregory
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] standard_name modifiers
Dear Jonathan et al.,
maybe I am fighting a lost battle here, but let me try to argue once more
for a generalized solution, i.e. the addition of anomaly
I agree units should be set to 1 and I am currently in the process of
fixing the error in the CF Checker.
Regards,
Ros.
On 27/02/11 17:27, Steven Emmerson wrote:
Cristina,
I recommend the unit 1 for that use.
If the CF checker doesn't like that unit, then it should be fixed,
IMO, because
Dear Rosalyn,
thanks so much for your reply and your works that is so important for
me. Infact my data are produced within MYOCEAN (european) project
and thay are going to test them! so it is important they do not failed
the CF checker test.
Best regards.
cristina
p.s.
Sorry if sometime
+1
This is a case where clearly the pragmatic approach is to do the systematic
approach.
Probably can't formally deprecate the terms as Roy points out, but one could
put in all of their definitions a pointer to the currently recommended
practice.
John
On Feb 28, 2011, at 00:14, Schultz,
Dear Rosalyn,
I assume the checker will also not complain if the units attribute is
simply omitted when the variable is unitless (i.e., either units=1 or
the attribute is omitted result in the same behavior by the checker).
best regards,
Karl
On 2/28/11 4:28 AM,
Dear Martin
Even 24 such cases wouldn't be really a problem. However, I don't feel strongly
about this myself. This is not quite the original use of standard_name
modifiers, which is to describe variables containing ancillary quantities.
However, it seems to be a reasonable use of the mechanism,
Dear Karl,
That is correct. If the variable is deemed unitless, then the checker
will not flag an error if either units=1 or the units attribute is omitted.
If the units attribute is missing, it will, however, produce an
information message suggesting that the units attribute is added for
I agree with Roy.
Karl
On 2/26/11 12:19 PM, Lowry, Roy K. wrote:
Hi Cristina,
Looks like my worries were unfounded concerning the meaning of 'count'. From
the discussion thread my understanding is that the units you have are OK and
that the issue is with the CF checker.
Cheers, Roy.
Cristina,
I recommend the unit 1 for that use.
If the CF checker doesn't like that unit, then it should be fixed, IMO,
because that unit is supported by both the US NIST and the BIPM.
Regards,
Steve Emmerson
UDUNITS developer
On 2/26/2011 12:30 PM, cristina.tronc...@artov.isac.cnr.it wrote:
...@cgd.ucar.edu] On Behalf Of Jonathan Gregory
Sent: 24 February 2011 18:08
To: Schultz, Martin
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] standard_name modifiers
Dear Martin
The idea of the modifiers was to provide standard names for ancillary data,
such as count of obs, standard error
: Thursday, February 24, 2011 7:08 PM
To: Schultz, Martin
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] standard_name modifiers
Dear Martin
The idea of the modifiers was to provide standard names for
ancillary data, such as count of obs, standard error, and so
on. The other kinds of thing
Dear Jonathan,
I don't quite agree with the implication you derive from : In general, CF
metadata describes what a quantity *is* and not how it was calculated from
other quantities. -- a temperature difference is a temperature, but you don't
want to confuse it with a temperature (pun
I agree that it's misleading (even to humans, who might not
be as thorough as some software) to use a common standard
name for a quantity that's not actually the measurement of that
observable, as in your example of a temperature anomaly.
The term derived_quantity doesn't seem especially helpful
Dear Martin
The case of anomaly is a good use case. It could be indicated by a standard
name modifier, as you say, but I agree with Nan that it should be a specific
one i.e. anomaly rather than generic. However in that case we have so far
been adding new standard_names instead of using a
Dear Martin
The idea of the modifiers was to provide standard names for ancillary data,
such as count of obs, standard error, and so on. The other kinds of thing you
mention, such as means over periods and other statistics, can often be
described by cell_methods, which is more flexible because it
20 matches
Mail list logo
