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 <edavis at unidata.ucar.edu
> <mailto:edavis at 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 at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
>
>
> --
> Dr. M. Benno Blumenthal benno at iri.columbia.edu
> <mailto:benno at 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 at 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: edavis at ucar.edu
P.O. Box 3000
Boulder, CO 80307-3000 http://www.unidata.ucar.edu/
---------------------------------------------------------------------------
Received on Thu Oct 29 2009 - 17:00:53 GMT
