Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
> 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
netcdfgroup archives: