Jim,
Hmm, good question. Looking at the examples in section 7.4 in more
detail, I'm no longer certain about my proposed cell_methods string.
If you were using option 3, I do think 'point' would be the method to go
in the 'over days' slot. That method describes how values are
aggregated over days and months, and it says in Appendix E that the
'point' method indicates that the values are "representative of points
in time and space", which I take to mean that at that scale they are not
aggregated at all.
However, I think your description of how the option 1 case would work
makes a lot of sense, also.
I guess the ambiguity creeps in because there are two natural cycles
that we can construct climatologies over: the daily cycle and the annual
cycle. Option 1 is for annual-cycle climatologies, option 2 is for the
daily cycle, and option 3 is for both. You're dealing with both cycles,
but since you're averaging over the entire day, your climatology is
degenerate in the daily cycle. So it's analogous to having a singleton
dimension, and the question is, do you leave it in as a placeholder
(option 3), or drop it (option 1)?
My opinion is that it would probably be valid to do it either way, but
when in doubt, one should go for the simpler option. So I'll abandon my
previous recommendation and say use option 1 as you have described it
here. That seems like it is the mostly likely to be interpreted
correctly anyway.
Cheers,
--Seth
On 6/2/14 1:15 PM, Jim Biard wrote:
> Seth,
>
> I missed the fact that I must fit one of the listed options for
> climatology cell_methods. So, if I must try to fit in the third
> option:
>
> time: mean within days time: point over days time: mean over years
>
> is "point" the right answer for the second method? Since the starting
> and ending month values are identical in the climatology bounds,
> doesn't that imply that the point operation is applied over a full
> year? Is there some place in the Conventions where this use for point
> is defined/explained?
>
> Or, should I use the first option:
>
> time: mean within years time: mean over years
>
> since my first time interval (for the first cell) is specified to be
> Jan 1 00:00:00 to Jan 2 00:00:00, which is applied within each
> individual year, and then the set of means for Jan 1 for each year
> are averaged.
>
> Grace and peace,
>
> Jim
>
> On 6/2/14, 2:32 PM, Seth McGinnis wrote:
>> Jim--
>>
>> Section 7.4 covers climatologies. My understanding of it is:
>>
>>
>> 1) Those are the right bounds values, but you should reference them
>> using a "climatology" attribute instead of a "bounds" attribute.
>>
>> I would think the cell_methods string for a daily climatology
>> ought to be "time: mean within days time: mean over years", but
>> that doesn't follow one of the three allowed forms for
>> climatologies. I guess the way to make it fit the schema is to use
>> "point" to indicate a no-op for how you're aggregating days within
>> the annual cycle, which gives you:
>>
>> "time: mean within days time: point over days time: mean over
>> years"
>>
>>
>> 2) Quite a conundrum, isn't it? Probably why we don't see more
>> daily climatologies... My inclination would be to simply discard
>> the leap days and use a noleap calendar for your climatology.
>>
>> (Another approach is to normalize time by multiplying it by
>> 360/yearlength, so that you're basically working with orbital
>> position instead of days since some starting point. I find that
>> useful for comparisons across different calendars, but it's a bit
>> unorthodox, and would likely be confusing in a published data
>> product.)
>>
>> In any case, I don't think there's really a standard "best"
>> answer, so the most important thing is to document your choice
>> thoroughly. As long as the end-user can easily figure out how you
>> handled leap days, I think it's reasonable for you to deal with the
>> issue in whatever way you find most convenient.
>>
>> Cheers,
>>
>> --Seth
>>
>> ---- Seth McGinnis mcginnis at ucar.edu NARCCAP Data Manager RISC /
>> IMAGe / NCAR ----
>>
>> On 6/2/14 8:20 AM, Jim Biard wrote:
>>> Hi.
>>>
>>> We have a dataset that contains a climatology giving the daily
>>> average temperature over 30 years. (So, it has the average
>>> temperature for January 1 over the period from 1981 - 2010.) I
>>> have two questions about this.
>>>
>>> 1) How exactly should that be represented, both with the bounds
>>> and with the cell_methods? Should the bounds be (for example)
>>> 00:00:00, Jan 1, 1981 and 00:00:00 Jan 2, 2010? Should the
>>> cell_methods be "time: mean over days time: mean over years"?
>>>
>>> 2) How should we handle February 29?
>>>
>>> Grace and peace,
>>>
>>> Jim
>>>
>>> -- CICS-NC <http://www.cicsnc.org/> Visit us on Facebook
>>> <http://www.facebook.com/cicsnc> *Jim Biard* *Research Scholar*
>>> Cooperative Institute for Climate and Satellites NC
>>> <http://cicsnc.org/> North Carolina State University
>>> <http://ncsu.edu/> NOAA's National Climatic Data Center
>>> <http://ncdc.noaa.gov/> 151 Patton Ave, Asheville, NC 28801 e:
>>> jbiard at cicsnc.org o: +1 828 271 4900
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________ 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
>
> -- CICS-NC <http://www.cicsnc.org/> Visit us on Facebook
> <http://www.facebook.com/cicsnc> *Jim Biard* *Research Scholar*
> Cooperative Institute for Climate and Satellites NC
> <http://cicsnc.org/> North Carolina State University
> <http://ncsu.edu/> NOAA's National Climatic Data Center
> <http://ncdc.noaa.gov/> 151 Patton Ave, Asheville, NC 28801 e:
> jbiard at cicsnc.org o: +1 828 271 4900
>
>
>
>
Received on Mon Jun 02 2014 - 15:52:05 BST
