Dear Francisco
The metadata you propose for describing experiments is the kind of information
that can be stored in the attributes institution, source etc. (in CF 2.6.2),
especially if you standardised them for your purposes. There have been
previous postings about standardising discovery metadata of this kind. If
you can use these attributes, you do not need standard names for them.
However, is it your intention to have data variables with experiment, centre
etc. as dimensions? In that case you may need standard names for them, I agree.
Such variables would have a lot of dimensions.
I would advise against codes for forecast_system_version_number and
forecast_method_number. Even with online lookup tables, we avoid codes in
the CF convention because they are not self-describing. Could you not make
these strings as well?
> - We use the variables "forecast_period" and "forecast_reference_time"
> as independent time variables employed to define the two time axes of a
> forecast dataset with several start dates, ie, both "forecast_period"
> and "forecast_reference_time" are multivalued. We believe that
> "forecast_period" cannot have time units referenced to a specific date
> as "forecast_reference_time" does. This is to prevent having in the file
> forecasts with the same verifying date but produced from a different
> start date (and, hence, intrinsically different). An alternative would
> consist in introducing an index dimension and make two one-dimensional
> auxiliary time coordinate variables with this dimension, as suggested by
> Jonathan Gregory in the thread "file with both run time and forecast
> (valid) time coordinates".
In the earlier discussion which led to my posting
http://www.cgd.ucar.edu/pipermail/cf-metadata/2006/001008.html
we decided we did not need to have two-dimensional time. It is true that
you could have separate axes for forecast_reference_time and forecast_period
(case iv in that posting), if all combinations exist, but is it necessary?
The argument is that it is simpler for the CF standard to use 1D auxiliary
coord variables, because then one structure can handle many different cases.
Best wishes
Jonathan
Received on Mon Oct 16 2006 - 10:43:12 BST
