> I think keeping hdf and netcdf most separate is the correct
> solution.
Yes, it's looking that way. Though still s good idea for them to be
the same where it makes sense.
> A couple of points.
> 1. A group can be a dictionary with the following keys:
> dimensions, types, attributes (group level), variables, and data.
> 2. Ordering matters in netcdf, so each of the group pieces
> (dimensions, etc) needs to be a list.
Really? Wow. So the order you put the dimensions in matters? Why? I'm
thinking it may be left over implementation detail from netcdf3 -- if
so, maybe we don't need to preserve it in JSON?
> 2. Variables have a number of unordered parts that are best
> represented as a dictionary containing:
> name, type, attributes.
Yup.
> 3. A set of attributes could be represented as a dictionary
> with the attribute names serving as keys. But remember
> that each attribute has a number of parts: type, name, and
> a list of values.
It does? Maybe 'cause I've mostly worked with version 3 compatible
files, but I thought attributes were simply strings.
> 4. In netcdf, there are several kinds of user-defined types:
Is this much different than HDF?
> 2. compound type (a structure in C terms): consisting of a name
> and an ORDERED list of fields. Each field is a variable
> (see above).
Wouldn't each field be a type?
Thanks for the notes!
Pedro, will you be able to set up a gitHub project ( or similar )? It
would be good to capture this conversation.
I'd be glad to set one up if you like. Either in the NOAA-ORR-ERD
organization or create a new organization for this.
-CHB
