⇐ ⇒

[CF-metadata] Getting back to ensembles

From: Bryan Lawrence <b.n.lawrence>
Date: Mon, 20 Nov 2006 20:24:06 +0000

Hi John

> > 4) As an aside at this point it seems we don't need a standard name for
> > "realization" even though we have one ... (although we'd need it for the
> > case where there were no auxillary coordinate variables).
>
> im not clear if you are suggesting we standardize the dimension name to = realization?
> I will assume for now you are not saying that.

No, I wasn't saying that, but by pulling me up on it, you make the whole
thing clearer (to me too!) I'm so glad you've got your thinking head
on ...

> My 7) your:
> let me munge your examples slightly:
> 1)
> float temperature(rdim,time,lat,lon):
      temperature:coordinates = 'realization time lat lon' ;
>
> char realization (rdim, strlen):
>
> assuming that time,lat,lon are the usual CF conventions, then the new thing is that
> I have a string valued coordinate, but i dont know what it is intended to mean.
> But if I unambiguously indicate it as:
>
> char realization (rdim, strlen):
> realization :standard_name="realization"; // or whatever we decide
>
> Now I know its an ensemble dimension, and can present it to the user for slicing and dicing,
> in a way that the user knows for sure what the dimension is used for.

Absolutely. That's put so much more clearly. Thanks.
 
> I would require that the strings are unique, so there is a 1-1 mapping.
> What the string values are doesnt matter to me.

So, that makes sense, at this point you're saying that anything with a
standard name of realization needs to be unique, and we need at least
one of those as a coordinate variable.

> 2) if i understand, you want to deal with the case where you do care what the strings mean,
> sometimes they indicate runs from different institution, or maybe just perturbations from the same run.
> You certainly can add multiple (auxiliary) coordinate variables.
> I still need the standard name on one of them so i know its an ensemble dimension,
> and I need a 1-1 mapping. One possibility would be to consider the variable that has
> the standard name on it to be special, and its values required to be unique.
> Or one could put a standard name on all of them, and assume that the concatentation
> of the values is unique.
>
> float temperature(rdim,time,lat,lon):
> temperature:coordinates = 'metadata1 metadata2 time lat lon' ;
>
> char metadata1(rdim, strlen):
> metadata1:standard_name="institution"; // for instance
>
> char metadata2(rdim, strlen):
> metadata2:standard_name="thing2; // for instance
>
> I assume that you are saying lets not standardize the values of these strings.
> However, I do need to understand that "institution" and "thing2" are types of
> an ensemble dimension, not intended to represent something else, ie a vector.

That's one of the reasons why I presented the idea of a new type of
controlled vocabulary that's *not* a physical quantity, then if the data
producer uses standard_metadata or external_vocabulary, rather than
standard_name, you do have that understanding.

With regard to Brian's point about uniqueness. I think the point about
the use of ensembles is that there had better be *something* which is
unique along the realization dimension.

I think John's contribution boils down to a choice: Either we use
realization in the way he suggests and make a condition of that
particular standard name that the string values are unique, or
that having used a realization coordinate variable, their has to be a
unique concatenation of all the auxillary coordinate variables.

(Either way, that's the special thing about ensembles).

My gut feeling is that the second choice is unnecessarily complex. The
data producer could even use integers as the realization coordinate
variable to ensure uniqueness, and put all the meaning in the coordinate
variables still, and that would make the coding for processing much
easier without any onerous effort for the data producer.

Bryan
Received on Mon Nov 20 2006 - 13:24:06 GMT

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

⇐ ⇒