Hi Steve,
Thanks for your input. I did not receive any mail directly from
Jonathan, perhaps because I am not the on CF mailist ?
Anyway, let me try to describe more of what we (as GHRSST) are
trying to do. Below is a more complete dump of a typical GHRSST L2P
netCDF file (but still a subset, we can have 20 fields or so). The
field 'sst_dtime' is the actual observation of the sea surface
temperature pixels made by the satellite when you add 'time'
(reference time in seconds). For other measurements such as wind,
which could be measured at a different time, I would like to specify
a time offset such that for a certain wind pixel:
time[0] + sst_dtime[0, nj,ni] + this_offset = time of observation of
the wind pixel.
I think Steve's solution of having another time array (TIME2) to
describe the offset is too complex, and will be too confusing to
users. Besides are
TIME2: data_offset = 1; TIME2: data_link = TIME;
valid COARDS attributes? I've never seen them before. If we did
implement Steves second suggestion we would have up to 5 time arrays
for the SST and ancillary fields:
Time (baseline reference)
Time2( offset for wind)
Time2( offset for solar insolation)
Time3( offset for aerosol optical depth)
Time 4( offset for sea ice)
I think this would be to confusing to users and unnecessarily
complicate the file. The drivers here are certainly space and well as
user friendliness. The GHRSST L2P specification actually allows for
a separate pixel-by-pixel time array for fields like wind (full 3 d
array like 'sst_dtime') but we are trying to eliminate them in the
interest of saving space. Why store a full 3 d array when a simple
offset to an existing array (sst_dtime) will suffice.?? That is why
I proposed some simple new attributes for the ancillary arrays
themselves to specify this offset in my first email.
But we want to remain CF compliant as well, so perhaps some
compromise can be reached.
If you reply please make sure my email is visible
~~~~~~~~~ GHRSST L2P netCDF ~~~~~~~~~~~~~~~~
netcdf 20061118-MODIS_A-JPL-L2P-A2006322173000.L2_LAC_GHRSST-v01 {
dimensions:
time = 1 ;
nj = 2040 ;
ni = 1354 ;
variables:
float lat(nj, ni) ;
lat:units = "degrees_north" ;
lat:long_name = "latitude" ;
lat:_FillValue = -999.f ;
float lon(nj, ni) ;
lon:units = "degrees_east" ;
lon:long_name = "longitude" ;
lon:_FillValue = -639.f ;
int time(time) ;
time:long_name = "reference time of sst file" ;
time:units = "seconds since 1981-01-01 00:00:00" ;
short sea_surface_temperature(time, nj, ni) ;
sea_surface_temperature:long_name = "sea surface temperature" ;
sea_surface_temperature:_FillValue = -32767s ;
sea_surface_temperature:valid_min = -1000s ;
sea_surface_temperature:valid_max = 8000s ;
sea_surface_temperature:scale_factor = 0.005f ;
sea_surface_temperature:add_offset = 273.15f ;
sea_surface_temperature:units = "kelvin" ;
sea_surface_temperature:coordinates = "lon lat" ;
sea_surface_temperature:source = "NASA and University
of Miami" ;
sea_surface_temperature:comment = "sea surface
temperature from thermal IR (11 um) channels" ;
short sst_dtime(time, nj, ni) ;
sst_dtime:long_name = "time difference from reference time" ;
sst_dtime:_FillValue = -32768s ;
sst_dtime:valid_min = -32767s ;
sst_dtime:valid_max = 32767s ;
sst_dtime:scale_factor = 1.f ;
sst_dtime:add_offset = 0.f ;
sst_dtime:units = "second" ;
sst_dtime:coordinates = "lon lat" ;
byte wind_speed(time, nj, ni) ;
wind_speed:long_name = "wind speed" ;
wind_speed:units = "m s-1" ;
wind_speed:_FillValue = -128b ;
wind_speed:add_offset = 0.f ;
wind_speed:scale_factor = 1.f ;
wind_speed:valid_min = -127b ;
wind_speed:valid_max = 127b ;
wind_speed:coordinates = "lon lat" ;
At 2:55 PM -0800 2006/12/22, Steve Hankin wrote:
>Hi Ed,
>
>It sounds like NASA's situation is that they want a single CF file
>(or dataset) to contain multiple variables that are each on
>different time axes. But the time axes differ only by a constant
>offset. In this case they would not like to physically store
>multiple time axes in the file. Storing multiple time axes would
>lead to 1) wasted space, 2) clouding the close relationship between
>the time axes.
>
>I cannot think of existing machinery that can do this. Such an
>attribute would need to preserve the assumption made by clients that
>shared use of a coordinate variable means shared coordinates. So
>it would need to introduce a new coordinate variable without
>duplicating the coordinates, themselves. Something like the
>following:
>
>dimensions:
> dummy = 1;
> TIME = UNLIMITED ;
>variables:
> double TIME(TIME) ;
> TIME:units = "hour since 0000-01-01 00:00:00" ;
> float SST(TIME, Y, X) ;
> SST:long_name = "SEA SURFACE TEMPERATURE" ;
> double TIME2(dummy);
> TIME2: offset = 1; // 1 hour offset
> TIME2: data_link = TIME; // <==!! re-use of
>values from another
> float SLH(TIME, Y, X) ;
> SLH:long_name = "SEA LEVEL HEIGHT" ;
> SLH:coordinates= "X, Y, TIME2";
>
>The client application would need to synthesize the coordinates of
>TIME2 based upon the guidance in the file. Unfortunately this file
>would not be intelligible to existing CF applications. That could
>be overcome using this alternative:
>
>dimensions:
> TIME = UNLIMITED ;
>variables:
> double TIME(TIME) ;
> TIME:units = "hour since 0000-01-01 00:00:00" ;
> float SST(TIME, Y, X) ;
> SST:long_name = "SEA SURFACE TEMPERATURE" ;
> double TIME2(TIME); /// values are offset by 1 hour from TIME
> TIME2: data_offset = 1;
> TIME2: data_link = TIME;
> float SLH(TIME, Y, X) ;
> SLH:long_name = "SEA LEVEL HEIGHT" ;
> SLH:coordinates= "X, Y, TIME2";
>
>In this version existing CF applications will find the file fully
>intelligible. Application that understand "data_link" and
>"data_offset" will immediately understand the inter-relationships
>(these may be standardized in the NASA community, only). But we
>*do* require two sets of coordinates to be stored.
>
>Ed, is this latter satisfactory? If not can you supply some
>discussion on how much the overall size of the file would be
>impacted by the existence of multiple coordinates. Or are there
>other drivers?
>
> - Steve
>
>================================
>
>Jonathan Gregory wrote:
>
>>Dear Ed
>>
>>I wonder why this you need to store the time-offset. If the time of the wind
>>and the time of the SST are different, but both are stored in time units of
>>seconds since the same reference, it is easy to work out the offset as the
>>difference of the two times, isn't it?
>>
>>Best wishes
>>
>>Jonathan
>>_______________________________________________
>>CF-metadata mailing list
>><mailto:CF-metadata at cgd.ucar.edu>CF-metadata at cgd.ucar.edu
>><http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata>http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>>
>
>--
>--
>
>Steve Hankin, NOAA/PMEL --
><mailto:Steven.C.Hankin at noaa.gov>Steven.C.Hankin at noaa.gov
>7600 Sand Point Way NE, Seattle, WA 98115-0070
>ph. (206) 526-6080, FAX (206) 526-6744
--
~ed
Edward M. Armstrong
Physical Oceanography DAAC Tel: 818 393-6710
Jet Propulsion Laboratory Fax: 818 393-2710
edward.armstrong at jpl.nasa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20061222/ecc39db8/attachment-0002.html>
Received on Fri Dec 22 2006 - 17:18:28 GMT
