⇐ ⇒

[CF-metadata] udunits handling of fuzzy time units

From: Steve Hankin <Steven.C.Hankin>
Date: Thu, 17 Mar 2011 11:19:07 -0700

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.

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.

      - Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20110317/11e3280b/attachment-0001.html>
Received on Thu Mar 17 2011 - 12:19:07 GMT

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:41 BST

⇐ ⇒