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 [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
