Hello all:
We have recently been thinking about Grid vs Swath datatypes.
heres a Grid with orthogonal coordinates (list coordinates explicitly
for clarity):
* *short *sea_surface_temperature*(time, lat, lon) ;
sea_surface_temperature:*coordinates *= "lon lat time" ;
float *lat*(lat) ;
float *lon*(lon) ;
int *time*(time) ;
heres a Grid with 2D lat/lon coordinates:
* short sea_surface_temperature*( nj, ni) ;
sea_surface_temperature:*coordinates *= "lon lat time" ;
float *lat*(nj, ni) ;
float *lon*(nj, ni) ;
int *time*(nj, ni) ;
we were thinking that this is a Swath:
* short sea_surface_temperature*( nj, ni) ;
sea_surface_temperature:*coordinates *= "lon lat time" ;
float *lat*(nj, ni) ;
float *lon*(nj, ni) ;
int *time*(nj, ni) ;
the difference being that Grids have an orthogonal time coordinate.
Now you are proposing
* short sea_surface_temperature*( timeRef, nj, ni) ;
sea_surface_temperature:*coordinates *= "lon lat time
timeRef" ;
float *lat*(nj, ni) ;
float *lon*(nj, ni) ;
int *time*(timeRef, nj, ni) ;
*time*:long_name = "actual time of each pixel" ;
int *timeRef(*timeRef*) *;
*timeRef*:long_name = "reference time of sst file" ;
I think the general swath situation is that lat,lon doesnt have a
repeating pattern (i could be wrong), so this ends up as some kind of
hybrid between the two. It can be displayed as a Grid using the timeRef
orthogonal coordinate, but presumably more detailed work needs to know
the actual time of each pixel.
So we need some new standard name to be able to distinguish these 2
kinds of time.
I realize most of the conversation is about efficiently storing the time
coordinate, which I agree we should try. . One thing that is surprising
is that those time offsets are so regular that they dont need to be 3D.
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.
>
>Best wishes
>
>Jonathan
>_______________________________________________
>CF-metadata mailing list
>CF-metadata at cgd.ucar.edu
>http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
Received on Sat Dec 23 2006 - 11:05:51 GMT
