Dear Steve,
> Having CF time axes that run backwards will break a lot of software.
> It will be a net disruption to interoperability.
It seems to me that it will only break the software if that software
is used, and that CF-netCDF is being excluded from a valid use. I
wonder if it is better to use CF and cherry pick your software than
otherwise? Afterall, I suspect that discrete sampling geometries
themselves will also break a lot of current software ... :-)
All the best,
David
---- Original message from Steve Hankin (11AM 01 May 12)
> Date: Tue, 1 May 2012 11:15:54 -0700
> From: Steve Hankin <steven.c.hankin at noaa.gov>
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420
> Thunderbird/12.0
> To: Jonathan Gregory <j.m.gregory at reading.ac.uk>
> CC: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] Reverse-time trajectory
>
> Richard, Jonathan, et. al.,
>
> As the famed Henning piece on CORBA stated -- in standards
> committees "no" is a preferable answer to "yes" all other things
> considered. More generality can often lead to less
> interoperability in CF or other data standards.
>
> Having CF time axes that run backwards will break a lot of software.
> It will be a net disruption to interoperability. So the question:
> "is there a sufficiently compelling use case for admitting it?",
> where we interpret "compelling" in the context of balancing the
> general loss of interoperability against the gains to particular
> datasets from adding this bit of flexibility.
>
> - Steve
>
> ========================================================
>
> On 5/1/2012 8:02 AM, Jonathan Gregory wrote:
> >Dear Richard
> >
> >>The CF definitions of discrete sampling geometries define the "trajectory" feature type as "a series of data points along a path through space with monotonically increasing times". This is a stricter stance than the usual CF coordinate definition of "ordered monotonically". What was the reason behind the addition of the "increasing" constraint, and can it be relaxed? We have data sets where a model is run backwards in time.
> >Good point. I would think that "monotonically" would be enough, not necessarily
> >increasing. I can't remember a reason for "increasing"; I assume it's just
> >because sect 9 was conceived for observations in the first place. However, John
> >Caron may well have a comment. I don't think anything prevents your storing
> >the data in the orthogonal multidimensional representation, which existed
> >before sect 9 did and doesn't require increasing coordinates.
> >
> >Best wishes
> >
> >Jonathan
> >_______________________________________________
> >CF-metadata mailing list
> >CF-metadata at cgd.ucar.edu
> >http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
David Hassell
National Centre for Atmospheric Science (NCAS)
Department of Meteorology, University of Reading,
Earley Gate, PO Box 243,
Reading RG6 6BB, U.K.
Tel : 0118 3785613
Fax : 0118 3788316
E-mail: d.c.hassell at reading.ac.uk
Received on Tue May 01 2012 - 17:03:28 BST
