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 <[email protected]> > User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 > Thunderbird/12.0 > To: Jonathan Gregory <[email protected]> > CC: [email protected] > 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 > >[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 -- 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: [email protected] _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
