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" <[email protected]> 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: [email protected] >> <x-msg://423/[email protected]> >> ------------------------------------------------------------------------ >> >> >> >> >> On 02/06/2010 16:25, "Steve Hankin" <[email protected] >> <x-msg://423/[email protected]> > 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 >>>> [email protected] <x-msg://423/[email protected]> >>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>>> >>> >>> >>> _______________________________________________ >>> CF-metadata mailing list >>> [email protected] <x-msg://423/[email protected]> >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Scanned by iCritical.
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
