netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
Ed, > Russ, John, Robert, and I had a meeting here yesterday. From that > meeting, and other sources, here is my understanding of the feature > set of netCDF 4, in approximate order of priority. > > * All features of netCDF 3.6 > * Use of HDF5 for file storage > * Backward file-format compatibility > * Backward API compatibility > * Each var to have independent unlimited dimension > * Anonymous dimensions > * Bit packing > * Chunking > * Parallel I/O > * (Unicode/ASCII) String data type > * User-defined structs in data > * Upgrades to ncgen/ncdump/NCL to reflect new features > > Is there anything missing? Anything that should be removed? Anything > that should be reprioritized? This is a good summary, but I have a few suggestions. "Large file support" is a feature, even if it doesn't require any additional work on our part. It's just a benefit inherited from using HDF5 as the storage layer. Some readers of this list may not know what netCDF 3.6 refers to. That's the "final release" of netCDF 3 that has better autoconf/automake/libtool support, bug fixes, and improved documentation, but no new features or APIs. It's just a cleaned up 3.5.1-beta11. I would put "Parallel I/O" higher on the priority list, as that is the main reason we're getting support from the modeling community for this project. Also, I would rephrase > * Each var to have independent unlimited dimension as just "Multiple unlimited dimensions", although it currently appears that users needs would be satisfied by limiting each variable to at most one unlimited dimension. I would also lower the priority of anonymous dimensions to below String data type, since it wasn't mentioned in the proposal, and I think the proposed enhancements should take priority over other enhancements. The "User-defined structs in data" could be divided into two independent enhancements: * Support for structs * User-defined data types with that priority. The reason a user would define a data type might be to define a name for a struct that would be used in other structs, but I can imagine other uses as well ... --Russ