Hi Benno,
Benno Blumenthal wrote:
Also, it is not particularly natural to use the end point as the
label
for the data, certainly not so natural that a program would assume
that
not knowing anything else about the data. It makes sense from a
data
collection point of view, maybe, but stops there. Most of us use
center of interval as default, particularly since our semantics are
not
good enough to detect accumulation (which is the only case where end
of
interval is natural).
The accumulated precipitation data from these models is currently
labeled by the end points of the accumulation intervals (i.e., they
are
all on the forecast time dimension). I'm trying to add the semantics
to
make it possible to detect that this data is an accumulation without
breaking backwards compatibility.
Since, as you say, accumulation "is the only case where the end of
interval is natural", adding the cell bounds information while using
the
same forecast time dimension seems natural for this case.
Ethan
Benno Blumenthal wrote:
I have to vote for multiple dimensions here -- these are different,
parallel dimensions which happen to have the same number of points.
Also, it is not true that a generic program cannot use the bounds.
Ingrid, in fact, prints time almost always as an interval, e.g. Jan
1980
if the time cell goes from 0000 1 Jan 1980 to 0000 1 Feb 1980, so
that
cell boundaries are critical for time, much more important that
spacially. This is because in common usage when we specify a time
we
almost always implicitly specify an interval.
Also, it is not particularly natural to use the end point as the
label
for the data, certainly not so natural that a program would assume
that
not knowing anything else about the data. It makes sense from a
data
collection point of view, maybe, but stops there. Most of us use
center of interval as default, particularly since our semantics are
not
good enough to detect accumulation (which is the only case where end
of
interval is natural).
Benno
On Thu, Oct 22, 2009 at 6:08 PM, Ethan Davis
<eda...@unidata.ucar.edu
<mailto:eda...@unidata.ucar.edu>> wrote:
Hi John,
John Caron wrote:
>
> The time coordinate here means forecast time, and you are
trying to
> capture "interval of accumulation".
I'm not sure I understand your point here. The forecast time is
the only
time dimension we have. What other time coordinate would the
"interval
of accumulation" be over?
> As jonathan says, you would have to create separate time
coordinates for
> each variable which has a distinct bounds.
Yes, CF is currently written so only one boundary variable can
be
associate with one coordinate variable so this situation would
require
multiple time coordinates. I'm wondering if CF should be
extended to
allow multiple boundary variables to be associated with a
single
coordinate variable.
> theoretically theres no
> problem with that, practically it may be more confusing than
just
> documenting the bounds on the variable in a non-standard but
> human-readable way. it seems unlikely that a generic program
could do
> anything useful with those coordinate bounds.
I agree that multiple time coordinates would do nothing for
clarity.
Which is why I'm wondering about extending CF to allow for a
clearer,
programmatically useful representation of this data.
Ethan
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu <mailto:CF-metadata@cgd.ucar.edu>
http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Dr. M. Benno Blumenthal be...@iri.columbia.edu
<mailto:be...@iri.columbia.edu>
International Research Institute for climate and society
The Earth Institute at Columbia University
Lamont Campus, Palisades NY 10964-8000 (845) 680-4450
------------------------------------------------------------------------
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Ethan R. Davis Telephone: (303)
497-8155
Software Engineer Fax: (303)
497-8690
UCAR Unidata Program Center E-mail:
eda...@ucar.edu
P.O. Box 3000
Boulder, CO 80307-3000
http://*www.*unidata.ucar.edu/
---------------------------------------------------------------------------
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
