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.
Keith Davidson wrote:
Hi John, Thanks for your reply."An early design decision was to make Attributes immutable." - do you mean only for the Java API? Or are you saying that NetCDF Attributes are inherently immutable, and that the C API achieves it by rewriting the entire file?But yes, the ability to modify Attributes in Java would be useful to us.This would be useful because we use various Attributes to flag certain information about the data in the file. As the data is modified, the info about the data changes. In some cases we should perhaps be using Variables instead of Attributes, but it is too expensive to change due to the amount of software we have that expects this format. And this software was written in C, Fortran, PVWave etc which allowed modification of Attributes. But now we are writing most new software in Java and finding the lack of being able to modify Attributes a pain.cheers, Keith.
Here are some dirty details from Russ Rew: <quote> In the C, C++, and Fortran interfaces (and probably perl and Python too), attributes are completely mutable, in that you can rewrite them, rename them, delete them, change their type, or change whether they are scalar or vector-valued. That's because, unlike variables and dimensions, their is no separation between the declaration of attributes and giving them a value. It's all done in a single function call such as nc_put_att_text (ncid, varid, name, len, string_val) Furthermore, it's possible to change the value of an existing attribute without being in "define mode", which just overwrites the existing value just as with variable values, as long as the space required for storing the attribute does not increase. But if the space required for the attribute value or name increases, you have to be in "define mode", and the file may get rewritten when you leave define mode either to access data values or to close the file. Before netCDF 3.5, the file always got rewritten on leaving define mode if the space for an attribute changed, even if it shrank or was deleted. With version 3.5, the file only gets rewritten if there isn't space in the header for the new expanded attribute values (or longer name). Space can be reserved in the header for attribute expansion with a call in the C library to one of the "underbar underbar" functions such as nc__create(), or by creating a large attribute and deleting it. This latter is kind of a kludge, but was deemed necessary to support conventions such as the ever expanding "History" global attribute. When we did Java, the argument was that attributes should be used for things like "units" that don't change. If you wanted something that changed, such as the average, max, and min of a variable, that should instead be stored in a variable instead of an attribute. Harvey Davies has argued that you should not even use attributes, just use variables for everything and use a naming convention for the attributes associated with a variable or with another attribute, e.g. the variable "temperature.units" for the units of temperature. </quote>Anyway, we will consider how to improve the situation, but for now Im afraid that in the Java library you have to get all the attributes right at file creation time.
netcdf-java
archives: