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