NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
If memory server, the ordering is the result of coordinate variables, and hdf5 dimension scales. Netcdf-3 had no such limitation. Also, your aversion to using lists seems odd to me; it is just another modelling mechanism. > but I thought attributes were simply strings. No, both hdf5 and netcdf allow typed attribute value. netcdf goes farther in allowing the type of attributes to be user defined types like compound/structure objects. > Wouldn't each field be a type? No, I note I forgot to mention that you need to store the dimensions of variables, and fields can have dimensions. Another point about netcdf types vs hdf5 types. I think it is the case that in hdf5, the types need to be defined repeatedly, whereas in netcdf, a user-defined type is only defined once. I infer it from the netcdf implementation and looking at the output of h5dump. Can any hdf5 experts out there verify this? =Dennis Heimbigner Unidata On 10/20/2016 7:54 PM, Stephan Hoyer wrote:
I think it would be a mistake to use lists instead of dictionaries in JSON output, even if it means we lose order. Technically, netCDF preserves variable order, but only broken applications should depend on it, and it would make the resulting JSON much less usable. I can definitely see value in having such a spec, so please keep me in the loop. In particular, it would be nice to have integrated write/read support in xarray. On Thu, Oct 20, 2016 at 6:07 PM, Chris Barker - NOAA Federal <chris.barker@xxxxxxxx <mailto:chris.barker@xxxxxxxx>> wrote: > 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 _______________________________________________ NOTE: All exchanges posted to Unidata maintained email lists are recorded in the Unidata inquiry tracking system and made publicly available through the web. Users who post to any of the lists we maintain are reminded to remove any personal information that they do not want to be made public. netcdfgroup mailing list netcdfgroup@xxxxxxxxxxxxxxxx <mailto:netcdfgroup@xxxxxxxxxxxxxxxx> For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/ <http://www.unidata.ucar.edu/mailing_lists/>
netcdfgroup archives: