⇐ ⇒

[CF-metadata] Use of Standard Names and Coordinate Variables (relevant to the aerosol discussion)

From: Bryan Lawrence <b.n.lawrence>
Date: Wed, 27 Sep 2006 17:30:58 +0100

Hi Jonathan

Time for us to agree vociferously then, and hand the baton back. So this
email is in two parts. Some specific recommendations for this case, and
some more general comments below :-)

I was hesitant about RH, lifetimes, optical depths at wavelengths, and
particle sizes being used as coordinate variables.

- I think the thing about optical depths is that they can be at any
wavelength, and so that makes sense for optical depth to be a
coordinate.
- I strongly think the particle size is a naming thing ... and it
shouldn't be in a coordinate ... pm10 is fine ...
- lifetimes, well, in other tracer experiments we tend to take things
back for many different periods ... I think this feels more like a
coordinate for me.
 - With respect to RH, I think the argument should go back to the
aerosol community. Is there any likelihood of folk wanting to exploit
the coordinate behaviour? If not, it feels like a name to me.

Ok: general points.


I think it's probably a bad idea in general to have multiple ways of
doing the same thing, but we do ...

... but I also don't think we should hold back the use of these things
because we're afraid of the size of the vocab. Roy has 10,000 items in
his vocab, and no one, probably not even Roy, holds it in his head. What
he does have is a set of rules about how to use them ... and ways of
interrogation.

So for me, where the answer isn't obvious, the defining choice should be
about whether the primary uses are more as names or more as indexes. If
the latter (as is the case with the land surface (where the index is
tied to properties in the model) ... then fine, it's a coordinate
variable.

Christiane is making the point in her email that it is *useful* to have
things in the name. I think this is my point about how we construct plot
labels ... so that too is part of the defining choice, but I think we
shouldn't allow the same information in the label and a coordinate
variable, so a choice has to be made.

Bryan


On Wed, 2006-09-27 at 16:03 +0100, Jonathan Gregory wrote:
> Dear Bryan
>
> Actually I agree with you. This is quite ironic, because my preference is
> generally to put as much as possible in one attribute with as little hierarchy
> as we can get away with, because it makes searching easier, and it means that
> decisions about how to structure a hierarchy (which are generally hard and
> often cause problems later, since any choice is arbitrary) can be avoided.
> However in previous discussions I have felt myself to be a minority in arguing
> against splitting up names. For instance, I think that special surfaces
> (surface, TOA, tropopause, etc.) should be in the standard name, because there
> are not many of them, and it would only make things more complicated to split
> them off into a separate attribute.
>
> I feel that parts of the description should appears as coordinates if there
> are many possible values they could take, to avoid the vocabulary expanding
> too much. If aerosol size can only foreseeably take a very small number of
> values, it doesn't need to be a coordinate. On the other hand, we have provided
> ways to make land surface type a coordinate, since it can take a lot of values
> and every type has the same kind of quantities which need to be named. More-
> over, in that case the answer to
> > Do we ever expect people to use these variables as coordinates per se?
> is Yes. Land surface type is a coordinate (a tile index) in models.
>
> > I'm not even convinced by the argument that wavelength and
> > RH should disappear off into coordinate variables either.
> It depends principally on whether there are many possible values, I think.
> Of course, if there is only possible value, it does not even need to be stated
> in the standard name. It can just be part of the definition. The fact of
> wanting to state it in the name itself implies that other values are possible.
>
> Cheers
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Wed Sep 27 2006 - 10:30:58 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:40 BST

⇐ ⇒