On 12/13/2011 4:28 PM, Seth McGinnis wrote:
>> 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".
Have you had a look at the CF Discrete Geometries Point collection
Feature type
(
http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#idp8294224)?
>
> 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 Wed Dec 14 2011 - 18:57:45 GMT
