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
Received on Mon Jan 08 2007 - 16:48:06 GMT
