Steve et al.,
In GHRSST, Level 4 (L4) products like the OSTIA one mentioned by Jon are often the result of an analysis procedure which accounts to some extent for diurnal variations in the various input sources. The analysis procedure accounts for those diurnal variations and spits out an SST not so much at a specific time of the day, and definitely not a "mean" time, but rather a value at a particular point in the diurnal cycle... typically just before dawn when the actual surface SST is more like what is known as the foundation SST (the SST just below all the diurnal variations). In the case of OSTIA, I think 12:00 Z was just chosen as a convenience.... a better approximation might be 06:00 or something like that. But generally speaking, I think L4 products more or less define an analysis time and the SST given is supposed to be the SST at that time.
I think the issue with GHRSST and times is more likely to arise in Level 3 (products), which can contain averages of overlapping swaths, or averages (or some other blending procedure) of data from different satellites. In these cases, depending on the procedure by which overlapping observations are combined and put into some form of grid, it can be difficult or impossible to give a precise time. If you bin two observations from overlapping orbits, they are separated in time by about 100 minutes (for polar orbiters). Often an average is used... but what is an "average" time? In these cases, the use of bounds you mentioned could be used, but the start and stop time might not be the entire day but the start and stop times of the orbits that went into the L3 product.
Ken
On Jun 2, 2010, at 11:25 AM, Steve Hankin wrote:
> [Ken, Craig -- a quick look please?]
>
> As a general rule level 3 satellite fields are "representative" -- or perhaps "accumulated" would be an alternative term. They are the accumulated result of a number of satellite passes that take place at distinct times, and then perhaps some interpolations, smoothing or other post-processing applied. Arguably more detailed CF conventions are appropriate -- beyond simply "bounds" and cell_methods on the time axis -- in order to capture the timing of the swaths that go into the final field.
>
> The GHRSST project comes to mind as a group that would have dealt with this question. I see that the OSTIA home page says the GHRSST data standards are used. So I've cc'ed a couple of people from the GHRSST project to see if they'd care to comment on treatments of this question.
>
> - Steve
>
> =================
>
> Jonathan Gregory wrote:
>>
>> Dear Jon
>>
>> CF doesn't provide a way to do this except by giving bounds. I think that's
>> the right thing to do, because the length of the interval alone doesn't say
>> when it starts and stops, which applications may need to know.
>>
>> The cell_methods indicates how the value represents the variation within the
>> interval. For an intensive quantity, "point" is the default i.e. instantaneous
>> in time. To indicate a mean, cell_methods of "mean" should be specified. You
>> are saying it is "representative" in some vaguer way than a mean, and it is not
>> instantaneous. That sounds like a different cell_methods. Perhaps it would be
>> a good idea to allow "cell" to be specified in cell_methods for intensive
>> quantities, to indicate a "representative" value in this vague sense. ("cell"
>> is the default cell_methods for an extensive quantity, which relates to the
>> entire cell and depends on its size.) I think this vagueness should in general
>> be discouraged; it would be better to be more precise and specify "mean",
>> "median" etc., but if you can't be precise it'd be nice to be able to say so.
>>
>> What do you think? That would require a small change to the convention.
>>
>> Cheers
>>
>> Jonathan
>>
>>
>>> We have many datasets for which we need to express the precision of the
>>> time axis. For example, the OSTIA sea surface temperature dataset
>>> contains daily fields. The data are considered "representative" of a
>>> particular day, without necessarily being a simple average over the day.
>>> At the moment the data are registered to 12:00Z on each day, but this is
>>> indistinguishable from an instantaneous snapshot at this time.
>>>
>>> I guess it would be possible to express the temporal precision using the
>>> "bounds" attribute for the variable in question
>>> (http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.ht
>>> ml#cell-boundaries), by specifying the start and end of each day as the
>>> bounds. Is there a less verbose way of providing this information,
>>> perhaps by stating the precision as "1 day/24 hours/whatever" as a
>>> single attribute?
>>>
>>> Jon
>>>
>>> --
>>> Dr Jon Blower
>>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
[NOTE: The opinions expressed in this email are those of the author alone and do not necessarily reflect official NOAA, Department of Commerce, or US government policy.]
Kenneth S. Casey, Ph.D.
Technical Director
NOAA National Oceanographic Data Center
1315 East-West Highway
Silver Spring MD 20910
301-713-3272 ext 133
http://www.nodc.noaa.gov/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20100602/3eaf43b0/attachment-0002.html>
Received on Wed Jun 02 2010 - 10:33:03 BST
