[CF-metadata] COARDS name for a time offset

[Ed Armstrong]

HI Johnathen,

Thank  you for the reply. Sorry for the Christmas hiatus, but I am 
getting my brain in gear.

I like your idea of a new standard name 'time_offset', that is a the 
relative difference from a predefined time. This is what I had in 
mind from the beginning.  What is the process of proposing a 
registering a new  CF standard name ?

At 3:47 PM +0000 2006/12/23, Jonathan Gregory wrote:
>Dear Ed
>
>Thanks for the further information and example.
>
>>  I would like to specify
>>  a time offset such that for a certain wind pixel:
>geographical indices j,i
>>  time[0] + sst_dtime[0,j,i]  + this_offset = time of observation of
>>  the wind pixel.
>
>I presume that this_offset is dimensioned [nj,ni] and that 0 is an 
>example of a
>time-index. From the example I understand that the point of this is to specify
>2D time arrays (nj,ni) for SST, wind etc. rather than 3D (nt,nj,ni). This can
>be done because the time-offset from time(t) of each variable at each location
>is the same for all values of time index t.
>
>I agree with you that there is no existing CF convention which would be able
>to indicate this procedure. However, most CF features are optional anyway so
>CF compliance is a fairly minimal requirement. I suspect that yours is quite a
>specialised requirement, so maybe we can approach it with a combination of CF
>conventions, and your own GHRSST conventions.
>
>For instance, we could introduce a new standard name of time_offset, which has
>time units but is for a time-difference rather than an absolute time. We have
>a standard name of forecast_period with the same characteristics, but that
>would not be appropriate here. You could give the sst_dtime variable this
>standard name, and indicate it as an auxiliary coordinate variable of the SST
>variable, by listing it in the coordinates attribute. You then 
>require a GHRSST
>convention that if a data variable has a 1D coordinate variable of 
>time, and an
>auxiliary coordinate variable with the time dimension and a standard_name of
>time_offset, the absolute time of datum(t,j,i) is
>time(t)+t_dependent_time_offset(t,j,i).
>
>Then for each non-SST variables such as wind speed, you need another 2D
>variable e.g. wind_dtime, again with standard_name of time_offset. You can
>indicate both the sst_dtime and the wind_dtime as auxiliary coordinate vars
>of the wind_speed variable, and extend the GHRSST convention to say that if
>there are is also an auxiliary coordinate variable with standard_name of
>time_offset but which does not have the time dimension, that should 
>be added as
>well, so that the absolute time of datum(t,j,i) is
>time(t)+t_dependent_time_offset(t,j,i)+t_independent_time_offset(j,i)
>
>I wonder why you store time(t) at all? t could just be an index dimension,
>and the sst_dtime could be an absolute time(t,j,i) rather than an offset. That
>would simplify this a bit.


Some comments here: If we were to reengineer the file format, we 
might make this change. But as it stands we have a stick to sst_dtime 
to be an relative (offset) time

>
>Best wishes
>
>Jonathan


-- 

    ~ed

Edward M. Armstrong
Physical Oceanography DAAC		Tel: 818 393-6710
Jet Propulsion Laboratory		Fax: 818 393-2710
	edward.armstrong at jpl.nasa.gov