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>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
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
--
Dr. M. Benno Blumenthal 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20091028/57756af2/attachment-0002.html>
Received on Wed Oct 28 2009 - 12:58:42 GMT
