Dear John
We have never got round to putting more information about time coordinates
into the standard, as we should have. There is a summary of this at
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2006/001008.html
which itself refers to a discussion in 2003! However, your case here is none
of those cases exactly. You have a single analysis time and multiple forecast
times which depend on time-bounds to distinguish them (since the time coord
is insufficient to distinguish them).
I agree that the rule about monotonic coords doesn't seem to make sense in
this case. The forecast time axis is actually *not* a progression in that
sense. The values don't have to be in any particular order, because it would
not make sense to do an operation which depended on their being in order, like
taking the difference between consecutive elements. Therefore the forecast time
should not be a coordinate variable, I would say. Although you don't have two
different time coordinates, I would suggest that this could be handled by (b)
in that earlier posting. That is, make time an index dimension, and make the
time coord an auxiliary rather than an Unidata coord variable. Then it doesn't
have to be monotonic.
> float Total_precipitation(time=50, y=428, x=614);
> :units = "kg m-2";
> :long_name = "Total_precipitation_Accumulation (Accumulation for
> Mixed Intervals) _at_ surface";
> :cell_methods = "time: sum";
> :coordinates="forecast_time";
>
> int forecast_time(time=50);
> :long_name = "forecast time for (mixed intervals)";
> :units = "hour since 2010-09-14T00:00:00Z";
> :bounds = "forecast_time_bounds";
>
> int forecast_time_bounds(time=50, bounds_dim=2);
> :long_name = "bounds for time";
> :units = "hour since 2010-09-14T00:00:00Z";
Cheers
Jonathan
Received on Tue Sep 21 2010 - 10:32:58 BST
