Hi all,
I don't have too much more to say about time in CF for any product level, but I suppose I should add that while I have heard data managers like ourselves talk about the less-than-optimal way it is done now, I have not in four and a half years of serving GHRSST data to the public received a complaint about the time aspect of GHRSST files. I am not sure what that means, and please don't take that statement to be at all defensive. We do gets lots of good feedback from users, but when it comes to the way time is encoded there has been no "chatter".
One thing that comes to mind is that in many of the applications I've helped people with over the years, the need for highly precise time just wasn't there. Quite often then other parameters being used in the application are so much less precise than what GHRSST provides that in comparison the GHRSST data seem just fine. That doesn't mean GHRSST shouldn't try to be even better, but might help explain why no one is complaining about it.
Ken
On Jun 2, 2010, at 12:33 PM, tjn98 wrote:
> Hi Jon,
>
> I think it?s fair to say that GHRSST hasn?t attempted to codify
> this yet. Indeed, getting any sort of a time field into L2P in
> particular hasn?t been entirely satisfactory as the CF convention
> hasn?t yet evolved far enough to cope well with satellite swaths.
>
> Ken or Craig may have a (different?) opinion about some of the other
> product levels.
>
> Regards,
>
> Tim.
>
> ------------------------------------------------------------------------
> Tim Nightingale
> Space Science and Technology Department
> Rutherford Appleton Laboratory
> Chilton, Didcot Phone: +44/0 1235 445914
> Oxon OX11 0QX Fax: +44/0 1235 445848
> United Kingdom Email: tim.nightingale at stfc.ac.uk
> ------------------------------------------------------------------------
>
>
>
>
> On 02/06/2010 16:25, "Steve Hankin" <Steven.C.Hankin at noaa.gov> 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
>>>
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> --
> Scanned by iCritical.
>
[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/20100607/53e96227/attachment-0002.html>
Received on Mon Jun 07 2010 - 04:46:23 BST
