> > 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: [email protected] Website: www.metoffice.gov.uk _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
