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 mcgin...@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: >>> jbi...@cicsnc.org o: +1 828 271 4900 >>> >>> >>> >>> >>> >>> >>> _______________________________________________ CF-metadata >>> mailing list CF-metadata@cgd.ucar.edu >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>> >> _______________________________________________ CF-metadata >> mailing list CF-metadata@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: > jbi...@cicsnc.org o: +1 828 271 4900 > > > > _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata