Dear John
Happy New Year!
Thanks for your lengthy contribution to our discussion about representing
contracted axes for time coordinates. You raise some useful points about what
information we need to record.
The main difference between your approach and ours is that you have chosen to
attach information about the contracted axis to another axis, whereas we
proposed to store it as a singleton axis of its own. For instance, in the first
example of a timeseries of 12 monthly average temperatures derived from daily
means,
* you have Tavg(avgtime,lat,lon), where avgtime is a 12-element time axis, and
has attributes describing how each month was derived from days, whereas
* we have Tavg(day,month,lat,lon), where month has a dimension of 12 and day a
dimension of 1, the latter recording the information about the contraction of
daily means into a monthly mean.
One reason for adopting your approach is that you say that existing software
would not be able to handle our approach, with its two (or more) time
axes. That would be undeniably an obstacle to adopting our scheme - what is the
problem, in fact (generically)? Apart from this problem, you argue that our
approach is more difficult to understand. I would like to argue that it has
important advantages of flexibility and consistency.
* It is flexible because it can easily be extended. In your system, you can
describe a timeseries of 12 monthly means, each derived from daily means; and
you can describe a timeseries of climatological daily means for particular days
of the year, each derived from a mean of corresponding days from several
years. But I do not see how you can describe a combination of these two
e.g. the climatological maximum daily mean for each month of the year, i.e. (1)
for each day, calculate the mean; (2) within each month, find the maximum daily
mean; (3) compute the mean of these maxima for corresponding months over
several years. This is represented in our scheme by three time axes
(day,month,year), where both day and year are contracted singleton axes. I
think your inclusion of the attribute contraction_itemiscontraction indicates
that you recognise a need for contractions within contractions; but I would
argue that information of the same detail and kind needs to be recorded for
each one, and it is simplest to use the same structures to do it.
* It is consistent because it is the same as the approach we propose for
contracted spatial axes. In our scheme, from a two-dimensional variable
(lat,lon) with lat=72, lon=96, we derive a zonal-mean field (lat,con_lon), with
con_lon=1 as a contracted axis recording information about the range and
spacing of longitudes over which the average is formed. This is exactly the
same as our treatment of a time contraction. In your example 5, you have
treated a contraction of a pressure axis in just this way, leaving a contracted
singleton axis. But in your treatment of time contractions, you don't do this:
you record the contraction using attributes on the remaining uncontracted time
axis, not using a contracted singleton axis.
