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) @ 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 _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
