I'm in favor of a generalized system for automatically constructing new
standard names by applying quantifiers to established ones. In fact, when I
first encountered the Guidelines for Construction of CF Standard Names, I
thought that's what it *was*, and it took me a while to understand that you
still had to actually propose the standard name and have it accepted.
Obviously there are potential complications if chaining together multiple
quantifiers is allowed, but for simple derived names, I think it sounds like a
great idea.
Case in point: I've been meaning to propose two new standard names myself, and
hadn't gotten around to writing the email about it yet:
histogram_of_spell_length_of_days_with_lwe_thickness_of_precipitation_amount_above_threshold
histogram_of_spell_length_of_days_with_lwe_thickness_of_precipitation_amount_below_threshold
(I've simply applied the "histogram_of" modifier to two existing names here, so
that we can record the climatological distributions of wet and dry spells.)
This seems like exactly the kind of thing that could be automated away with
some general rules, no? Or is my proposal more controversial than I think it
is?
Cheers,
--Seth
On Mon, 28 Feb 2011 17:15:13 +0000
Jonathan Gregory <j.m.gregory at reading.ac.uk> wrote:
>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, since it's a
>derived quantity. (A combination of quantities would be more difficult to
>deal with, as we have discussed.) I feel that opinions from others on whether
>we should make this change would be helpful.
>
>Best wishes
>
>Jonathan
>
>On Mon, Feb 28, 2011 at 09:14:18AM +0100, Schultz, Martin wrote:
>
>> 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 users will ask "why is there an
>anomaly defined for temperature, but nor for precipitation?", ii) past
>experience has shown that it takes time to get new standard names adopted, and
>if new use cases come up (as they are bound to be for something as essential
>as anomalies) it may discourage people to even go for standard names for these
>variables. Why not try to make the system as systematic as possible? I don't
>want to argue against a pragmatic approach, but if you decide to change the
>anomalies from individual standard names to a modifier in three years, the
>effort might be much larger, the confusion will be greater and other
>"operators" with similar problems will come along. So, my suggestion would be
>to
> deprecate the use of air_pressure_anomaly, air_temperature_anomaly,
>geopotential_height_anomaly and surface_temperature_anomaly now and introduce
>"anomaly" as a modifier. It's only replacing an underescore by a blank anyhow
>;-)
>>
>> As we just developed some tools to compute multi-model means and model
>anomalies for the TFHTAP data sets, I would otherwise have to come up with a
>list of ~20 new "_anomaly" standard names. So, besides what I see a rational
>argument (above), I have a personal reason for arguing so vehemently.
>_______________________________________________
>CF-metadata mailing list
>CF-metadata at cgd.ucar.edu
>http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Tue Mar 01 2011 - 14:07:41 GMT
