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/>
