[CF-metadata] Reverse-time trajectory

From: Hattersley, Richard <richard.hattersley>
Date: Tue, 22 May 2012 11:16:00 +0100

> > So somewhat contrary to my previous statement, my current
> thinking is
> > table 9.1 should keep the "monotonically" and "ordered"
> descriptions,
> > and these should be clarified by further rules stating their ordered
> > nature even when expressed as an aux coord var.
>
> I think it would be possible make such a restriction if you
> use the featureType
> attribute, which indicates that the rules of sect 9 apply.
> But the use of
> auxiliary coordinate variables for time already existed
> before sect 9 was
> written, in what sect 9 refers to as the orthogonal multidimensional
> representation, and that can be used without the featureType
> attribute.
>
> Why not sort the data into monotonic order of time before using it?

>From one perspective I don't really mind either approach - the logical
view presented by software can be in time order irrespective of the
encoding. But having to sort the data wastes time and makes the file
less human-readable. Why put the onus on the consumer if there are very
few/no producers who would find it hard to comply with the
in-order-within-a-single-time-series constraint?

It's analogous to the strictly-monotonic constraint on coordinate
variables. CF could just state that they have to be logically monotonic
and leave it to the consumer to sort.

I'd love to see more feedback from the people who write real-time
data-logging systems...


Richard Hattersley AVD Iris Technical Lead
Met Office FitzRoy Road Exeter Devon EX1 3PB United Kingdom
Tel: +44 (0)1392 885702 Fax: +44 (0)1392 885681
Email: richard.hattersley at metoffice.gov.uk Website:
www.metoffice.gov.uk
Received on Tue May 22 2012 - 04:16:00 BST