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.
Received on Fri May 11 2012 - 12:14:26 BST
