Hi Steve:
Sorry, I see that my thinking isnt very clear. Thanks for reformulating the question as
"the case where the boundaries of cell values is clearly understood, but it is
unclear what coordinate value best to use for the grid point."
I think Seth's argument to keep the time coordinates the same for model output is correct. So my statement
that "time coordinates want to use the end-point" is misleading, the KISS principle is that
variables on the same time grid should have the same time coordinate. In model output, the time grid is
"forecast time", not "midpoint of calculation period". The CDM's Forecast Model Run
Collection (FMRC) processing, for example, depends on this. This may be much ado about nothing - we probably
would agree on what to do about any specific example.
(It was probably a mistake to bring in other data types like point obs - they
just use the time of measurement, end of story.)
"If one has a mixture of model variables to output and the interpretations of their
time coordinates needs to be different, then placing two different time axes into the
file is the only way to eliminate the confusion."
I think another possibility is to put the bounds information on the "continuous integral" data variables, rather than on the time coordinate. Otherwise we have this proliferation of time coordinates, which confuses things.
Steve Hankin wrote:
John Caron wrote:
1. The CDM library uses the bounds if they are present. If only the
coordinate values are present, the CDM generates bounds. These grids
bounds are used by ncWMS and other visualization software to draw
color filled images. The IDV (I think) uses a contouring algorithm
with just the coordinate values.
2. Spatial coordinates probably want to use midpoint values.
3. I think theres a good argument that time coordinates want to use
the end-point. Seth makes the argument for numerical models. In this
case, all the output variables should have the same time coordinate.
Im trying to think of a case where thats not true (point observations,
radar data etc), and im not thinking of any.
Hi John,
I'm not understanding the logic that suggests using midpoints for
spatial coordinates, but endpoints for times. Whenever an applications
sees a particular reason to place the grid point at something other than
the midpoint (on whatever axis) of course it should do so. That may
lead to placing the grid point at the start, middle or end of the
interval. But the question that is before us is to say what the default
should be for the case where the boundaries of cell values is clearly
understood, but it is unclear what coordinate value best to use for the
grid point.
All other things being equal using a consistent strategy for space and
time is the simpler, "KISS", approach. Both instantaneous and
time-interval-averaged values are most naturally encoded using midpoint
representation (disagreeing with both Seth's conclusion and your
speculation. Are we using terms differently?). The compelling case for
a time endpoint may be continuous integrals (e.g. accumulated
precipitation). If one has a mixture of model variables to output and
the interpretations of their time coordinates needs to be different,
then placing two different time axes into the file is the only way to
eliminate the confusion. Arbitrarily shifting the grid point locations
by 1/2 time cell will not eliminate confusion, will it? It seems like
it would merely hide the confusion and increase the chances of
misinterpretation.
(To be frank, although I have seen many CF datasets using both midpoint
and start-point times, I have never encountered one previously that uses
the end point of the time interval. It seems possible that as a
practical matter this choice may introduce confusion rather than reduce
it.)
- Steve
=====================
Seth's argument about confusion remains the same if one
4. Perhaps "interval of accumulation" is different enough that one
should just encode it in a separate attribute or auxiliary coordinate
on the data variable. Numerical models can have different variables
with different intervals, possibly overlapping. This is perhaps not
really the same as the bounds on the coordinate, they just share the
same codomain (time). An advantage of this approach is that you dont
have to create new coordinate variables for each data variable, which
seems like more trouble than its worth.
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
