I agree with Heiko's comment. Jonathan, are you thinking that CF disallows packing of coordinates because we neglected to explicitly include them in Table A.1? I think this was just an oversight. I don't have any recollection that we intended to disallow packing coordinates, and I don't find anything in the convention document itself that leads to this conclusion (although I'm not as familiar with it as I used to be :)
Brian On Thu, Apr 12, 2012 at 12:51:18PM +0200, Heiko Klein wrote: > On 2012-04-12 11:35, Jonathan Gregory wrote: > >Dear John > > > >>Well, the netcdf-Java library will unpack coordinate variables, so > >>any applications built with it will also. > > > >OK, well done! I retract my comment. > > > >Still, I expect that there is software in use to analyse netCDF data (on the > >whole not specifically for CF) which knows about coordinate variables > >(because > >that is a Unidata convention) but wouldn't expect to unpack them. We could > >change the convention, but there would have to be a compelling reason, I > >think. > >Can anyone remember if there was a compelling reason for excluding packing of > >coordinates in the first place? I have a recollection it was a deliberate > >decision. > > > > Aren't the scale_factor and add_offset part of netcdf > http://www.unidata.ucar.edu/software/netcdf/docs/netcdf/Attribute-Conventions.html, > rather than CF. So, all software handling netcdf-files should unpack > all variables independently of CF. > > This leaves some place for software only reading opendap or similar > in CF, but not netcdf, but I consider the netcdf attributes > convention as basis for CF. > > Heiko > _______________________________________________ > 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
