On 3/17/2011 12:19 PM, Steve Hankin wrote:
>
>
> On 3/17/2011 9:50 AM, Christopher Barker wrote:
>> On 3/16/11 8:47 AM, John Caron wrote:
>>
>>> 1. time instants vs time duration
>>> - one must distinguish between dimensional time ("time duration",
>>> units="secs"), and calendar time ("time instant", or "point on the time
>>> continuum") *which is not dimensional. *
>>
>> yup -- key clarification in all this.
>
> I think we are leading ourselves astray here. _A point in time has a
> dimension._ It has dimensions of "time". Whether the units happen to
> be days, months, years or whatever depends upon the encoding. But it
> definitely has dimensions of time. The date-time string loses its
> meaning if we see it as detached from the axis that gives it a
> dimensionality.
in "dimensional units", "secs" is a base dimensional unit, and it means
"duration", eg watts = joules/sec, the sec is a time duration, not an
instant of time.
"time" is not a dimensional unit, it refers to a point on the time
continuum. it does not have dimensional units of "secs", that is, it
cannot be converted to a duration in "secs".
however it can be represented as "duration since calendar time", and
the machinery of dimensional units can be used for the duration part.
but theres still that "calendar time" part of udunits "time unit"
handling, and udunits does the very simplest handling it can.
hmm, can i add any more "quotes" ??
anyway this is why udunits cant be incrementally extended to do more
better time unit handling, we need more sophisticated calendar handling.
im sure there are other libraries that have some or most of this solved
(cdtime has some), and i think we should find those and build a
reference library. We could, for sure, add this new stuff into udunits,
but the point is that we need new stuff.
currently CF references udunits as the reference library for time, and
while reference libraries are not strictly needed, in practice they are
Very Good.
>
> There are two ways in which dimensions (positions and intervals) can
> be handled. Each of them is self-consistent:
>
> 1. *represent positions as strings*.
> * Then create special functions to compute the implied
> distance between those string representations. In this
> outlook units must be specified when the interval is
> computed.
> 2. *represent positions with a zero reference, and an offset value.*
> * Then create special functions to generate formatted
> strings representing positions along the axis. In this
> outlook units must be stored with the representation.
>
> Udunits consistently follows approach #2. It is a complete and
> self-consistent outlook that is capable (with additional API
> functions) of handling formatted strings for all dimensions. It is
> very well suited to numerical analysis tasks.
>
> GIS systems have advanced approach #1, because they primarily treat Z
> and time as metadata tags (strings). In general approach #1 is best
> suited to situations where you are working primarily with metadata.
>
> What do we gain by mixing the two approaches together and what do we
> lose? I'd argue that consistency, simplicity, elegance etc. should be
> the primary bases of this debate.
From my POV, the problem is that users need more expressiveness for the
calendar time. I certainly do. For yearly data, "years since base_date
by calendar field" (or whatever) is consistent, simple and elegant.
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20110317/38974f4d/attachment-0001.html>
Received on Thu Mar 17 2011 - 18:20:37 GMT
