Hi all,
Thanks for the considered responses. It looks like we have a consensus
on a change to remove "increasing" from the trajectory feature type. As
things stand, I plan to raise a defect ticket in a couple of days.
You may also have spotted the "increasing" requirement in the
descriptions for the "timeSeries" and "timeSeriesProfile" feature types.
I don't have a use case which might suggest the removal of "increasing"
from these feature types, but perhaps it should be done anyway (and at
this relatively early stage in the lifecycle of section 9) to keep them
consistent?
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 Steve Hankin
> Sent: 02 May 2012 05:25
> To: Jonathan Gregory
> Cc: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] Reverse-time trajectory
>
> Jonathan, David,
>
> I probably sounded more negative than I intended. I was just raising
> the concerns that should be balanced against an easy "yes".
> In public,
> group discussions the forces of "no" are inherently weakened by the
> social dynamics. That, and imho CF has long had an
> imbalance between
> the perspectives of those creating data, and the perspectives
> of those
> writing the applications that will read it.
>
> You convinced me -- "yes" is probably the right answer in this case.
>
> - Steve (the Blue Meanie)
>
> ============================================
>
> On 5/1/2012 2:23 PM, Jonathan Gregory wrote:
> > Dear Steve
> >
> >> 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.
> > I think that's too negative myself. CF is successful partly
> because it tries
> > to accommodate what people want to do, by and large,
> usually with existing
> > mechanisms, sometimes with new ones. This is more effective
> for encouraging
> > take-up of a standard than it would be to tell people what
> they have to do.
> > I agree that "No" is the starting-point when we have a
> proposal to add or
> > change conventions; there has to be a good reason for
> adding more complexity,
> > and even more for breaking backward compatibility. However,
> what is already
> > permitted by the standard is surely OK, isn't it, even if
> it is unusual. CF
> > has always permitted coordinate axes to run in either
> sense, and never said
> > anything special about time in that respect. I see no
> reason why a time
> > coordinate axis shouldn't run backwards, just as a latitude
> axis could be
> > N-S or S-N. Apart from Richard's example, paleoclimate
> timeseries often have
> > backward time axes.
> >
> > Richard asked about discrete sampling geometries in
> particular. Here, there
> > is a question whether we really need to require time to run
> forwards in the
> > new representations (orthogonal multidimensional and ragged
> representations).
> > It would be interesting to know what John thinks, since his
> software is
> > probably the most widely used implementation of sect 9.
> >
> > 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
>
Received on Thu May 10 2012 - 08:17:10 BST
