-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark Rivers wrote:
| Hi,
|
|
|>I believe this is not a good idea to set something different
|>as scalars as attributes. There is no dimension information stored
about attribut
|>sizes and what kind of coordination parameter should be used.
|>
|>
|>At the moment I don't know if it's a bug or a feature.
|
|
| It is definitely not a bug. Here is some info from the netCDF
documentation:
|
****************************************************************************
| A netCDF attribute has a netCDF variable to which it is assigned, a
name, a type, a length, and a sequence of one or more values. An
attribute is designated by its variable ID and name. When an attribute
name is not known, it may be designated by its variable ID and number in
order to determine its name, using the function nc_inq_attname.
|
| The attributes associated with a variable are typically defined
immediately after the variable is created, while still in define mode.
The data type, length, and value of an attribute may be changed even
when in data mode, as long as the changed attribute requires no more
space than the attribute as originally defined.
|
****************************************************************************
|
| Note that a netCDF attribute has a "length" and "sequence of one or
more values". One very good reason for this is simply to support
strings. netCDF does not have a string data type, only an array of
chars. Thus to support the very common attribute "units" requires an
array of chars. Attribute arrays can only be one-dimensional.
|
| The following section of the documentation explains the difference
between attributes and variables.
|
****************************************************************************
| 2.5 Differences between Attributes and Variables
|
|
-
--------------------------------------------------------------------------------
|
| In contrast to variables, which are intended for bulk data, attributes
are intended for ancillary data, or information about the data. The
total amount of ancillary data associated with a netCDF object, and
stored in its attributes, is typically small enough to be
memory-resident. However variables are often too large to entirely fit
in memory and must be split into sections for processing.
|
| Another difference between attributes and variables is that variables
may be multidimensional. Attributes are all either scalars
(single-valued) or vectors (a single, fixed dimension).
|
| Variables are created with a name, type, and shape before they are
assigned data values, so a variable may exist with no values. The value
of an attribute must be specified when it is created, so no attribute
ever exists without a value.
|
| A variable may have attributes, but an attribute cannot have
attributes. Attributes assigned to variables may have the same units as
the variable (for example, valid_range) or have no units (for example,
scale_factor). If you want to store data that requires units different
from those of the associated variable, it is better to use a variable
than an attribute. More generally, if data require ancillary data to
describe them, are multidimensional, require any of the defined netCDF
dimensions to index their values, or require a significant amount of
storage, that data should be represented using variables rather than
attributes.
|
|
***************************************************************************
|
|
Ok it is no bug but if someone is using this then the resulting data
file is'nt described by the standard rules of netCDF.
Reimar
- --
Reimar Bauer
Institut fuer Stratosphaerische Chemie (ICG-I)
Forschungszentrum Juelich
email: R.Bauer@xxxxxxxxxxxxx
- -------------------------------------------------------------------
~ a IDL library at ForschungsZentrum Juelich
~ http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_lib_intro.html
==================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE+xRC/5aOc3Q9hk/kRAgStAJ9nddddoHzykPg5+g1fU3zS8kPv6gCgk6Sp
anVR0XKz50gSpZRscc3tmLU
=Iekb
-----END PGP SIGNATURE-----
