Dear Jonathan,
Both methods seem reasonable to me. The first method has the advantage of explicitly recording the ranges, which can be helpful for verifying that one understands what was done. The second method has the advantage of encoding it all in a second line, which is a bit harder to read, but may generalize better.
My only suggestion: if we go with your first method then I suggest we change the name of old_time to something else, since this suggests to me that it is old data that could or should be ignored. Alternatives I can think of are kernel_time, average_time, and preprocess_time.
Best wishes,
Philip
-----------------------------------------------------------------------
Dr Philip Cameron-Smith, pjc at llnl.gov, Lawrence Livermore National Lab.
-----------------------------------------------------------------------
> -----Original Message-----
> From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-
> bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory
> Sent: Sunday, October 23, 2011 5:30 PM
> To: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] daily maximum of running 8-hour means
>
> Dear Martin and Philip
>
> Thank you for your use-cases showing the need for standardised metadata
> for
> daily maxima of 8-hour running means. I expect that similar cases will
> arise
> in other areas and actually it is quite surprising they haven't
> already, I
> think.
>
> What you want to describe involves two cell_methods processing
> operations: (1)
> Calculate an 8-hour running mean for consecutive hours, (2) Calculate a
> maximum of these within days. We could record this explicitly and
> completely
> if we had different time coordinates for the two operations. For the
> first
> operation, the cell_method is a mean, and we have time coordinates at
> hourly
> intervals, each with bounds specifying an 8-hour period. The cell
> bounds
> overlap, but that's no problem. E.g. they could be [0:00, 8:00], [1:00,
> 9:00],
> [2:00, 10:00], ... (just the time, omitting the date). For the second
> operation, the cell_method is a maximum, the bounds indicate periods of
> days,
> spaced at daily intervals i.e. not overlapping.
>
> One possibility would be to extend CF to allow you to preserve the
> original
> time axis to which the first operation applied, even though it is no
> longer
> provides the time coordinates once the second operation has been
> carried
> out. For instance, we could allow:
>
> float air_quality(time);
> air_quality:cell_methods="old_time: mean time: maximum";
> double old_time;
> old_time:units="hours since 2011-10-23 0:00";
> old_time:bounds="old_time_bounds";
> double old_time_bounds(old_time,two);
> double time(time);
> time:units="hours since 2011-10-23 0:00";
> time:bounds="time_bounds";
> double time_bounds(time,two);
>
> old_time=0.5, 1.5, 2.5, ...;
> old_time_bounds=-3.5,4.5, -2.5,5,5, -1.5,6.5, ...;
> time=12, 36, 60, ...
> time_bounds=0,24, 24,48, 48,72, ...;
>
> This is not currently legal because old_time is not a dimension of
> air_quality,
> but it seems a reasonable extension to me.
>
> For climatological time, we have a similar issue of multiple time
> processing,
> and in that case we do not find it necessary to keep old time
> coordinates.
> Instead, we use a special interpretation for the time bounds (CF sect
> 7.4).
> However, this doesn't seem to be easy to adapt for the general case,
> because
> of the overlapping periods. Climatological time doesn't allow that.
>
> Another possibility would be to define new kinds of standardised
> metadata,
> following Philip's categories, to describe the superseded time
> coordinate e.g.
> cell_methods="time: mean (period: 8 hours offset: -15.5 hours) time:
> maximum
> (interval: 1 hour)". The second entry is standard, and records that
> hourly
> values were input to the calculation of the daily maximum. The first
> entry
> records that those values were themselves means calculated over periods
> of 8
> hours, and the first such period began 15.5 hours before the first time
> coordinate (12 - 15.5 = -3.5, the lower bound of the first old_time
> cell).
>
> I am sure there are plenty of other possibilities, but I wonder what
> you think
> of either of these as a start?
>
> Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Mon Oct 24 2011 - 14:40:54 BST
