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.
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 >
netcdfgroup archives: