Michael,
For the core file structure for netcdf-3, please focus on the BNF spec. CF
is a higher level convention for the usage and scientific meaning of the
file metadata, and it is not at all relevant for the core file structure.
I have previously found the BNF spec to be 100% consistent. I recommend
that you familiarize yourself by comparing the BNF spec side by side with
both the binary contents of one of the simpler netcdf-3 examples from the
link that you provided earlier, and the output of ncdump -h for the same
file.
Be careful with the hierarchical nature of much of the BNF spec. For
example, the att_list structure is used in two different places, once for
global attributes, then again for each variable within the var_list.
"nelems" is used in multiple contexts. It is used precisely as an item
counter for the immediately following set of zero or more elements. In
each such context, an element might be a primitive data type (such as the
bytes in a string), or another structure defined in the spec.
It's almost cute that ABSENT does not mean just what you would think, but
rather a sequence of precisely eight bytes of zeros.
--Dave
On Mon, May 11, 2015 at 12:29 PM, Michael Powell <mwpowellhtx@xxxxxxxxx>
wrote:
> On Mon, May 11, 2015 at 2:02 PM, Michael Powell <mwpowellhtx@xxxxxxxxx>
> wrote:
> > It seems to me that possibly I am looking at a dialect of netCDF,
> > literally "Convention" = "CF-1.0":
> >
> > i.e. http://www.cgd.ucar.edu/cms/eaton/netcdf/CF-20010629.htm
> >
> > Which has a ton of theoretical, this field, that field, this, that,
> > and the other attribute name, purpose, etc.
>
> AH! I believe I see what it is.
>
> The Attribute nc_type is 'NC_CHAR', which is not a 'char' in the sense
> that there is a single character, but rather a string, with the usual
> size+text+padding conventions going on.
>
> Now I see...
>
> Thank you...
>
> > However, what I am interested in finding are apparent deviations from
> > the core netCDF file structure. I am 99% positive that the file format
> > as described in the VERSION \x01 format specification is not being
> > adhered to where gatt_list (more generally, att_list). The first
> > attribute has a type associated with it that I can find, but ones
> > thereafter seem to ignore this field. But even that is inconsistent.
> >
> > Even taking the separation between header (meta description) and data
> > (fixed, followed by record, data), it is possible i am misinterpreting
> > the relationship between attributes, dimensions, etc, but not if I
> > read straight from the BNF and work it out like according to its
> > logical AST outworking.
> >
> > Is there no one on this list who has any knowledge of this, or where
> > else I might be likely to find these details?
> >
> > Thank you...
> >
> >
> > ---------- Forwarded message ----------
> > From: Michael Powell <mwpowellhtx@xxxxxxxxx>
> > Date: Sun, May 10, 2015 at 11:26 PM
> > Subject: Help with reading cdf attr_list attr
> > To: netcdfgroup@xxxxxxxxxxxxxxxx
> >
> >
> > Hello,
> >
> > I could be reading the file format wrong, but I am reading the parts
> > as specified in the BNF. Possibly (POSSIBLY), I need to wait for
> > fixed-length data until after reading the header, but even with that,
> > I fail to account for the attr::nelems or the corresponding nc_type,
> > before what looks like the next attr finds its way into the header, at
> > least in a couple of the examples I am trying to read.
> >
> >
> http://www.unidata.ucar.edu/software/netcdf/docs_rc/file_format_specifications.html
> > http://www.unidata.ucar.edu/software/netcdf/examples/files.html
> >
> > att_list = ABSENT | NC_ATTRIBUTE nelems [attr ...]
> > attr = name nc_type nelems [values ...]
> >
> > I am new (refreshing) with CDF, so I am likely not interpreting
> > something quite right, or it's an undocumented gotcha.
> >
> > Would someone kindly look into this and let me know? I'm sure there's
> > some nuance about the format versus the BNF that I am failing to
> > comprehend somehow.
> >
> > Thank you...
> >
> > Best regards,
> >
> > Michael
>
