[CF-metadata] Proposal for better handling vector quantities in CF (and the role of libCF)

From: Seth McGinnis <mcginnis>
Date: Tue, 13 Dec 2011 17:28:24 -0700

>I agree with your reasoning. It is worth considering the use of Groups, but
>the approach should be weighed against the best proposals that can be
>generated that stick to the classic model. Fundamentally the need is for 2
>bit of semantics:
>
> 1. associate components together so they form a conceptual N-vector object
> 2. associate metadata with the N-vector object

Having these two bits of semantics would be really valuable because it
also provides a generic method for handling tabular data within netcdf,
which is something I think we need.

If you want to represent a set of events (e.g., earthquakes) in netcdf, I
believe the best way to do it is to have a bunch of variables (e.g., time,
lat, lon, magnitude) with a common "ID" dimension. Having a common
dimension links them together implicitly, but there's currently no good
way to say explicitly "these variables are different features of this set
of entities" or to provide metadata about the collection, like "this is a
catalog of Japanese earthquakes of magnitude 5.0 and greater".

Something simple along the lines of the coordinates attribute would
probably suffice. I'm not sure whether it would be better to attach it
to the ID dimension, and use that as the holding point for metadata
associated with the table, or whether it would be preferable to simply
have a dummy variable, as is used for map_projection metadata.

(I had more conclusions about some of these issues, but lost the
document where I collected all my thoughts in a hard-drive crash...)

This would also provide a stepping-stone to better handling of spatial
categorical data. Currently, CF says to use flag_values and
flag_meanings for categorical data, but that gets really awkward and
human-unfriendly if you have more than a handful of categories. It
would be much more elegant to have the meanings of the numeric
values defined by reference to a table. (This also solves an issue I
posted about a while back: we could have one set of standard
names for use with controlled vocabularies like the Area Type and
Region Names tables, and another for user-provided categorizations,
which would then be enumerated in the same file.)

Cheers,

--Seth
Received on Tue Dec 13 2011 - 17:28:24 GMT