[CF-metadata] Getting back to ensembles

From: Kettleborough, Jamie <jamie.kettleborough>
Date: Tue, 05 Dec 2006 15:42:36 +0000

Hello,

sorry to have gone so quiet on this. I'm not sure I have anything to
add to make a lot of progress, certainly few concrete suggestions...

1) Originally we added realization and realization_weight* as standard
name and a standard name modifier to help support a representation of
probability distributions (such as those generated by Monte-Carlo
methods). The extension appears as a minor addition - which is probably
why it didn't attract too much attention when proposed - though it does
break the '4D COARDS/CF nut' by introducing the explicit recognition of
a 5th (the realization) dimension into the CF standard.

The current version of the standard name table has realization units as
1 (not string as I and others have implied in examples) - though I
imagine it is not too late to change this. I think there may be good
reason to keep this as it is. Since the realization dimension is so
hard to label maybe we should say the simplest (default) thing to do is
leave the realization coordinate as an integer index. I think this
helps with the uniqueness issue that John and others have talked about.

Bryan raised the issue that the standard name realization is not always
needed. That's true - though I think we need it in there as there are
cases where it is needed to help recognition of which is the realization
dimension - for instance if you want to apply the realization weights
and you can not infer the which is the realization dimension from other
information you have (this may be pretty rare - but it could happen if
you have another non spatial-temporal dimension of the same length as
realization).

Maybe we should strongly recommend that if you have a variable in a file
that has a standard name modifier 'realization weight' then the
realization coordinate variable should be included in the file and have
the standard name 'realization'? (Of course, if we stick with
realization as units '1', this may be a bit space wasteful in some cases
as the coordinate variable will just be filled with the indices
1:realization.)
  
2) A related (but maybe should be separated) issue is then how to label
the process's used to generate the individual realizations. At the
moment we have two proposals - one is to identify particular realization
label coordinates by standard names, the other is to recognise them by
introducing a new cf attribute which is 'standard metadata'. Bryan's
interpretation of standard names referring to physical quantities seems
to fit well with how standard names are introduced in section 3.3 of CF.
But as Jonathan points out its not that clear cut.

One of the values of having standard names is that it tells you what
quantities you can compare. If I have numerical physical quantities
then in order to do a comparison I need to check they are referring to
the same thing (standard_name, cell_methods) and make adjustments to
make sure I'm on the same scale (units, offset, scale factor type
things). For string's there is an analogous process - but its
definitely a different process. For string valued 'things' I need to
make sure they are the same thing (say 'region' or 'surface_cover') and
from the same vocabulary, and if not do a translation between vocabs.
Is this difference sufficient to say that we should disallow string
valued standard_names and allow only 'standard_metadata' to be string
valued? (OK there are backwards compatibility problems there as we
already have a couple of string valued standard_names). This is maybe
what Bryan has been driving at for a while?

(I'm not really sure what cell_methods mean for string valued
standard_names either)

Jamie
Received on Tue Dec 05 2006 - 08:42:36 GMT