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: richard.hattersley at metoffice.gov.uk Website:
www.metoffice.gov.uk
> -----Original Message-----
> From: cf-metadata-bounces at cgd.ucar.edu
> [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of John Caron
> Sent: 11 May 2012 19:14
> To: cf-metadata at cgd.ucar.edu
> 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
> > CF-metadata at cgd.ucar.edu
> > 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
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
Received on Mon May 14 2012 - 23:53:25 BST
