Dear Sebastien and Chris
The various ways to handle forecast times, analysis times and forecast
periods with multiple time axes have been discussed several times before. Since
there are plenty of use-cases, and it's complicated, it would be good if we
could agree on recommended ways to do it, which could be added to the CF
standard document as examples. The last time this was attempted was over two
years ago, in cf-trac.llnl.gov/trac/ticket/117. Perhaps you could have a look
at that and comment if appropriate, and maybe also my earlier summary, over a
decade ago (!), in mailman.cgd.ucar.edu/pipermail/cf-metadata/2006/001008.html.
Best wishes
Jonathan
----- Forwarded message from Chris Barker <chris.barker at noaa.gov> -----
> Date: Tue, 24 Oct 2017 14:12:33 -0700
> From: Chris Barker <chris.barker at noaa.gov>
> To: Sebastien Villaume <sebastien.villaume at ecmwf.int>
> CC: "cf-metadata at cgd.ucar.edu" <cf-metadata at cgd.ucar.edu>
> Subject: Re: [CF-metadata] various "time" in CF
>
> My thoughts:
>
> Example 1:
> >
> > ...
> variables:
>
> >
> > double time(t) ;
> > time:units = "hours since 2010-01-01 00:00:00" ;
> > time:standard_name = "time" ;
> > time:calendar = "gregorian" ;
> > time:axis = "T" ;
> >
> > .... lat/long here ....
> >
> > float data(t, j, i) ;
> > ...
> > data:standard_name = "temperature" ;
> > data:coordinates = "time lat lon" ;
> > ...
> > What is this? Is this an analysis? an observation? or something else?
> >
>
> That should be specified one way or another in the attributes of the data
> variable -- what type of data it is has nothing to do with what time it is
> associated with.
>
> the coordinates attribute specifies that the time axis is described by the
> "time" variable, and the time attributes specify that it is representing
> time, and what units an calendar -- a particular datetime is exactly the
> same regardless of whether it's an analysis or observation, etc.
>
> Indeed, one very might have an analysis and measured data corresponding to
> the same time - in which case having them share a time variable would make
> perfect sense.
>
> Example 2:
> >
> > ...
>
> > variables:
> > double forecast_reference_time(t) ;
> > forecast_reference_time:units = "hours since 2010-01-01 00:00:00" ;
> > forecast_reference_time:standard_name = "forecast_reference_time"
> > ;
> >
>
> again, this is a datetime variable, nothing wrong with using the "time"
> standard name. There is nothing about the fact that it is being used for a
> forecast reference that changes that.
>
>
> > double leadtime(t) ;
> > leadtime:units="hours" ;
> > leadtime:standard_name="forecast_period" ;
> >
>
> This is NOT a datetime -- it is a time-delta (number of hours -- you can't
> map it to a particular date and time) -- not sure what the standard name is
> for that, but it should be different than "time", though the units may make
> that clear enough.
>
>
> float data(t, j, i) ;
> > ...
> > data:standard_name = "temperature" ;
> > data:coordinates = "leadtime forecast_reference_time lat lon" ;
> > ...
> >
>
> here you have a 3D variable with four coordinates -- I think we have a
> problem there.
>
> I _think_ what you want is to have the time coordinates of this variable to
> be forecast_reference.
>
> The leadtime variable would then be a data variable (not a coordinate
> variable) with forecast_reference_time as its coordinate variable.
>
>
> What is this? is it the forecast done back on the 1st January 2010? or is
> > it a hindcast done years later to test the model of today? or is it a
> > forecast from a reanalysis dataset, for instance ERA5? or something else?
> >
>
> There is only so much one can do with standard names, but if you were to
> specify that more, it would be with the attributes of the data variables..
>
> I would tend to think that you'd want to have:
>
> - A time coordinate -- a "Proper" datetime, which is for when the data are
> valid.
> - A data variable for when the forecast (or hindcast) was produced
> - An attribute on the dat variable(s) indicating that it's a hindcast (if
> it is) -- probably the long name.
>
> Proper attributes, probably some on the Dataset, that specify all the rest
> of it.
>
> >
> > extra question for example 2: lets assume it is a hindcast. how will I be
> > able to distinguish this hindcast done today from the hindcast I am going
> > to do in 5 years time to test the model then? or from the hindcast I did 2
> > years ago for that date?
> >
>
> How would you distinguish this hindcast from one done by someone else? or
> with a different model,? or ???? that all has to be elsewhere in the
> metadata somewhere -- none of it has anything to do with the time
> coordinate variable, nor is any of is part of the standard name.
>
> I think of it this way -- as this is my use case:
>
> I want the standard names, coordinate variables, etc to be the information
> I need to use these model results to drive my oil spill model. In that
> case, whether I'm driving it with a forecast or a hindcast, or when it was
> done, or what model it was done with, is all irrelevant. My code does the
> exact same thing with all of those.
>
> HTH,
>
> -Chris
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> 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
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
Received on Wed Oct 25 2017 - 06:50:53 BST
