[CF-metadata] COARDS name for a time offset

John Caron caron at unidata.ucar.edu
Mon Jan 8 18:33:11 MST 2007



Ed Armstrong wrote:
> 
> Hi John,
> 
> Thanks for the reply. Some comments below.
> 
> At 2:06 PM -0800 2006/12/27, John Caron wrote:
> 
>> Sorry my previous post was incomplete (trying to finish it as I walked 
>> out the door).
>> Try it again:
>>
>> heres a Grid with 1D coordinates (list coordinates explicitly for 
>> clarity):
>>
>> 1)   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:
>>
>> 2)    short sea_surface_temperature( time, nj, ni) ;
>>            sea_surface_temperature:coordinates = "lon lat time" ;
>>       float lat(nj, ni) ;
>>       float lon(nj, ni) ;
>>       int time(time) ;
>>
>> we were thinking that this is a Swath:
>>
>> 3)    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 Swaths have a 2D time coordinate.
>>
>> Now consider
>>
>>       short sea_surface_temperature( timeRef, nj, ni) ;
>>               sea_surface_temperature:coordinates = "lon lat" ;
>>
>>       int timeRef(timeRef) ;
>>                timeRef:long_name = "reference time of sst file" ;
>>
>>       short sst_dtime(time, nj, ni) ;
>>                sst_dtime:long_name = "time difference from reference 
>> time" ;
>>
>>       float lat(nj, ni) ;
>>       float lon(nj, ni) ;
>>
>> As it is written, the coordinate system for sea_surface_temperature is 
>> (lat, lon, timeRef). This looks like a Grid with 2D lat/lon 
>> coordinates (case 2 above). There is no reference to sst_dtime
>>
>> But I suppose its more accurate to see it as a swath:
>>
>>     short sea_surface_temperature( nj, ni) ;
>>            sea_surface_temperature:coordinates = "lon lat sst_dtime" ;
>>
>>       short sst_dtime(time, nj, ni) ;
>>            sst_dtime:long_name = "time difference from reference time"
>>            sst_dtime:formula = "timeRef + sst_dtime" ;
>>
>> where I have imagined that we have come up with some convention for 
>> calculating the time coordinate values.
>>
>> Im guessing it is useful to see it as a Grid (ignore 2D time) or a 
>> Swath (ignore 1D time). Because the lat/lon coordinates are the same 
>> for each timeRef coordinate, it seems to me to really be a hybrid of 
>> the 2.
>>
>>     short sea_surface_temperature( timeRef, nj, ni) ;
>>               sea_surface_temperature:coordinates = "lon lat timeRef 
>> sst_dtime" ;
>>
>>       int timeRef(timeRef) ;
>>                timeRef:long_name = "reference time of sst file" ;
>>
>>       short sst_dtime(time, nj, ni) ;
>>                sst_dtime:long_name = "time difference from reference 
>> time" ;
>>                sst_dtime:formula = "timeRef + sst_dtime" ;
>>
>> It would seem that there are 2 time coordinates, an approximate time 
>> for showing the data as a Grid, and an actual "pixel-by-pixel" time.
>>
>> Ed, can you tell us more about this dataset? Its derived from Swath 
>> data, and resampled? to a fixed lat/lon array? What causes the 
>> constant offsets of different variables? Does each variable have a 
>> different offset?
> 
> 
> 
> 
> The GHRSST L2P dataset is swath data, not resampled.  There is a unique 
> lat/lon for each pixel, thus a 2D array for both lat and lon. The 
> offsets in time are caused by non-satellite ancillary fields (wind, 
> aerosols, solar insolation, sea ice) in the file that have different 
> observation times  (or prediction times if model forecast fields) from 
> the SST satellite data (which are are referenced to the sst_dtime 
> array).  Each of the ancillary variable could have a different time offset.
> 
> I like the solution proposed by Johanthen with a 'time_offset' standard 
> name that can then be used with the relative time from array sst_dtime 
> to calculated a new relative time from the absolute time specified in 
> array 'time' . Not quite an elegant solution, but within the framework 
> of the current file format it will work.

thanks for the additional info. my main point is that there are 2 time variables here. this brings up a number of issues, for example, to which should the time_offset be added?


More information about the CF-metadata mailing list