[CF-metadata] various "time" in CF

Chris Barker chris.barker at noaa.gov
Wed Oct 25 13:25:57 MDT 2017

On Wed, Oct 25, 2017 at 8:57 AM, Sebastien Villaume <
sebastien.villaume at ecmwf.int> wrote:

> @Chris, thanks for your contribution to the discussion. very interesting
> I don't agree with your comment regarding 3D data variable with 4
> coordinates being wrong. I have 3 physical axes and 4 coordinates, yes, but
> leadtime is a coordinates associated to the same time axis than the
> forecast_reference_time coordinate.
> In other words, I have 2 coordinates sharing the same physical axis. I
> don't have multiple Time, I have multiple descriptions/partitioning of Time.

I understand what you are trying to do, but:

1) does CF allow multiple coordinates for a single axis???
2) how does the user (or even more so, software) know which axes has dual

But also -- as you say: "I have multiple descriptions/partitioning of Time."

I think that only ONE of those is the coordinate variable -- a given
forecast is "good" for one particular datetime. That is the time
coordinate. If it ALSO is, say 24 hours after the initialization, that is
additional meta data, not a coordinate. I don't understand what that can't
be a new variable, with shape (1,) and time as it's coordinate axis...

among other things, I'm pretty sure a time coordinate has to be a full
datetime (and monotonic??)

> I am doing this because I want to associate 2 informations for each time:

you can associate any amount of information with the time coordinate --
each variable that uses the time coordinate in more information associated
with that time.

the reference time and the elapsed time since that reference time (instead
> of only providing the valid time which is simply the composite of the two
> with a loss of information).

As Jonathan pointed it out, this is discussed in detail in trac ticket 117
> and on this mailing list. I have also looked at the discussions from the
> early 90's on the unidata netCDF mailing list. It took a while to go
> through, it seems to be a recurrent problem and nobody really solved it so
> far.

that maybe so -- I haven't had any trouble storing multiple forecast runs
with the additional info about when the run was initialized, etc all in
meta data, but I can see why you might want a more "standardized" way to do

But I think that would require maybe a couple new standard names? rather
than multiple time coordinates -- I really don't think your additional
"times" are really time coordinates.

> We have a fundamental disagreement: I don't see this as a "multiple time
> axes" problem, I see it as a "single time axis with multiple time
> coordinates defined on it" problem. Our preferred solution (so far) is in
> fact to use all three standard names (time, forecast_reference_time and
> forecast_period) in

ah -- so those standard names do exist!

> the same file but only "time" has the attribute "axis = T". One can see
> the two other coordinates as "auxiliary coordinates" of the same physical
> axis. It means having redundant informations (only 2 are needed, the 3rd
> one can be derived from these 2) but it makes the data files compatible
> with more tools.

so what is the problem??

I think the "trick" here is that something like forecast_reference_time is
NOT a time coordinate -- it is data associated with an index of the time
axes of your data. IIUC, you might have a bunch of indexes in the data
array that are the forecast at different datetimes (say, hourly), but all
have the same forecast_reference_time -- which means it is not a time
coordinate, it is data -- what is the reference time for this particular
point in the array? similar to "that is the temperature at this particular

Think of it this way -- if you wanted to plot the change of some parameter
at one location over time from this model run, what would you put on the
X-axis? I don't think you'd put the forecast_reference_time.

> I see two options to move forward:
> 1) expand the available list of standard names to be able to describe
> accurately any type of forecasts, analysis, hindcast, etc.

That makes sense to me -- I think that would be required in any case if we
want to capture more of that info with standard names.

> 2) recognise that time and processes are decoupled information, deprecates
> "forecast_reference_time" and "forecast_period" for something more generic
> like "reference_time" and "time_interval", and finally design a mechanism
> to describe forecast, hindcast, analysis, etc.

there are some standard names that have more and less specific versions --
to a "reference_time" name (and others) might make sense



Christopher Barker, Ph.D.

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20171025/2aff2ea2/attachment-0001.html>

More information about the CF-metadata mailing list