Dear All,
Ken?s right, of course. I should add that the time information itself
in L2P is fine. Mine was a small and not entirely relevant technical
point about the implementation of time as a coordinate in CF, and I
know that CF is currently taking an interest in this aspect.
Regards,
Tim.
On 07/06/2010 11:46, "Kenneth S. Casey" <Kenneth.Casey at noaa.gov> wrote:
> 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
>> <x-msg://423/tim.nightingale at stfc.ac.uk>
>> ------------------------------------------------------------------------
>>
>>
>>
>>
>> On 02/06/2010 16:25, "Steve Hankin" <Steven.C.Hankin at noaa.gov
>> <x-msg://423/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 <x-msg://423/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 <x-msg://423/CF-metadata at cgd.ucar.edu>
>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Scanned by iCritical.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20100607/df8bae6b/attachment-0002.html>
Received on Mon Jun 07 2010 - 07:15:21 BST
