Dear Jonathan and John, It's not my intention to call for a new coordinate variant. I'm just trying to reconcile the description of time series given in 9.1: "a series ... with monotonically increasing times" with the prose in H.2.1.
What does 9.1 actually mean by "monotonically increasing" if the data can be stored in non-monotonic order? Regards, 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 > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of John Caron > Sent: 11 May 2012 19:14 > To: [email protected] > Subject: Re: [CF-metadata] Reverse-time trajectory > > On 5/11/2012 10:39 AM, Jonathan Gregory wrote: > > Dear Richard > > > > Auxiliary coordinate variables don't have to be monotonic. > That's the usual > > rule for them, and the reason for what it says in H.2.1. To > require them to > > be monotonic would be a new rule. I think it would be a > specific requirement > > for sect 9. That is, you could say, if it's a timeseries > feature type, the time > > coordinate must be monotonic, even if it's an aux coord > var. However, I don't > > think you'd want to require other aux coord vars to be > monotonic, such as lat, > > lon and alt in the same example. So this extra requirement > of monotonicity > > would be for particular coordinate types in particular > feature types. > > > > Is this necessary? Also, is it desirable? Currently, it is > possible for the > > times to be stored disordered in the index ragged array > representation, for > > instance. That might be convenient, since that > representation is expected to > > be used when data is written as it arrives, and it might > not arrive in the > > right order. Would you want to prohibit this by requiring > time to be monotonic > > in H.2.5, for example? > > > > Best wishes > > > > Jonathan > > _______________________________________________ > > CF-metadata mailing list > > [email protected] > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > Yes, I agree. Writers cant always guarentee that time data is > ordered; > if they can they should use a coordinate variable. Otherwise, > its up to > higher level access services to add this kind of > functionality, similar > to an SQL SORT. > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
