⇐ ⇒

[CF-metadata] Proposal for better handling vector quantities in CF

From: Jonathan Gregory <j.m.gregory>
Date: Tue, 13 Dec 2011 18:40:39 +0000

Dear John

> >* I think it would be very inconvenient, and would break a lot of existing
> >software, if the coordinates were not what they appeared to be, because an
> >offset had to be added. Also, in general, the component fields of a staggered
> >grid do not have the same dimensions, as well as differing in the coordinates.
> Im not sure what "an offset had to be added" means.

Perhaps I misunderstood you. I thought you meant that, for instance, the u-
and v-components on an Arakawa C-grid might be stored in the same data
variable. They don't have the same coordinates, but since they are in the
same data variable they must share coordinate variables. Hence there would
need to be rules for deriving the coordinates of the u-grid and v-grid, by
adding offsets, I presumed. That sort of approach seems awkward and complex to
me, and not like the familiar netCDF treatment of coordinate variables.

> >* It avoids the need to define a convention for labelling vector/tensor
> >components.
> I think this convention would be about as complex as the one you
> will need for Thomas' proposal.

For Thomas's proposal, no new convention would be needed to label the
components, since they are in separate data variables and can be given the
standard names for components which are already defined.

> OTOH, if we start thinking in terms of the extended model, a
> Structure ("compound type" in HDF5 parlance) might be useful. What
> do you think about starting to think about possible uses of extended
> data model?

Thomas suggested groups. We could put the component data variables of a
vector or tensor in a netCDF-4 group, and I guess we could allow a group
to have a generic standard_name, like we are proposing the umbrella would
have one. This is neat, and the main objection is that it's not the classic
model! Therefore lots of existing software would not be able to read the
components any more. It is not backward-compatible. There has to be a strong
reason for breaking backward compatibility. What do you think? What are the
relative advantages of groups and compound types?

Best wishes and thanks

Jonathan
Received on Tue Dec 13 2011 - 11:40:39 GMT

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:41 BST

⇐ ⇒