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
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Thu Apr 12 2012 - 08:09:11 BST
