While decoding NCEP forecast model output in GRIB2, and converting to
CF-NetCDF, we have run across time coordinates that are actually
intervals, not points. The time intervals are unique, but sometimes the
forecast time coordinate values are not.
For example, below is the "Total_precipitation" variable and its time
coordinates, from the NAM Conus 12km model run on 2010-09-14T00:00:00Z,
coming over the conduit data feed:
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";
int time(time=50);
:long_name = "forecast time for (mixed intervals)";
:units = "hour since 2010-09-14T00:00:00Z";
:bounds = "time_bounds";
data:
{0, 3, 6, 6, 9, 9, 12, 12, 15, 18, 18, 21, 21, 24, 24, 27, 30, 30,
33, 33, 36, 36, 39, 42, 42, 45, 45, 48, 48, 51, 54, 54, 57, 57, 60, 60,
63, 66, 66, 69, 69, 72, 72, 75, 78, 78, 81, 81, 84, 84}
int time_bounds(time=50, bounds_dim=2);
:long_name = "bounds for time";
:units = "hour since 2010-09-14T00:00:00Z";
data:
{
{0, 0},
{0, 3},
{0, 6},
{3, 6},
{0, 9},
{6, 9},
{0, 12},
{9, 12},
{12, 15},
{12, 18},
{15, 18},
{12, 21},
{18, 21},
{12, 24},
{21, 24},
{24, 27},
{24, 30},
{27, 30},
{24, 33},
{30, 33},
{24, 36},
{33, 36},
{36, 39},
{36, 42},
{39, 42},
{36, 45},
{42, 45},
{36, 48},
{45, 48},
{48, 51},
{48, 54},
{51, 54},
{48, 57},
{54, 57},
{48, 60},
{57, 60},
{60, 63},
{60, 66},
{63, 66},
{60, 69},
{66, 69},
{60, 72},
{69, 72},
{72, 75},
{72, 78},
{75, 78},
{72, 81},
{78, 81},
{72, 84},
{81, 84}
}
So these are accumulations of total precipitation at the surface, and
for whatever reason the data producers want to output multiple
accumulation intervals with the same forecast time. Note that the
forecast time coordinate is always the end of the interval, and is not
unique.
My thought is that since the bounds are unique, this is a reasonable way
to encode this, even though it violates the rule for unique, monotonic
coordinates. My argument is that the "unique, monotonic coordinates"
rule covers the common case for coordinate variables, but is sometimes
not appropriate, as in this case. Thus would require a client to make
coordinate bounds (when they exist) an integral part of coordinate
processing, however.
Comments are solicited.
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
