HDF5 allows user-defined types to be used in attributes.
A user-defined type can either be defined in the Dataset (variable) or
attribute that uses it, or defined separately (known as a “committed datatype”)
so that multiple objects can use it.
John
On 10/20/16, 7:52 PM, "netcdfgroup-bounces@xxxxxxxxxxxxxxxx on behalf of
dmh@xxxxxxxx" <netcdfgroup-bounces@xxxxxxxxxxxxxxxx on behalf of dmh@xxxxxxxx>
wrote:
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/>
>
>
_______________________________________________
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
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
