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