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.
NOTE: The netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
Thanks Russ and Ed,I had thought of doing something along these lines but I must say, Russ, your example makes it much simpler than I was thinking it would be. Thank-you.
Is something like this likely to be 'officially' sanctioned as a NUG recommendation at some stage?
regards Simon Wood Russ Rew wrote:
Hi Simon, You asked:Has anybody else been thinking about metadata for compound types? How is metadata expected to be represented for individual fields?and Ed Hartnett wrote:We have also considered that one could create an attribute of compound type, in which each element was a unit for an element of the data compound type.Just to expand on this a bit, I think this is an adequate way to provide attributes to members of a compound type, because attributes in netCDF-4 can be of user-defined types, not just of primitive types. As an example, consider a user-defined compound type "obs_type" and a 1D variable "obs_var" of that type: types: compound obs_type { // a user-defined compound type int station_id; double time; float temperature; float pressure; }; variables: obs_type obs_var(n); // a 1D variable of type obs_type To assign units to all the members of the obs_var variable (and any other variables of that type), just define a related type named "obs_atts", for example, and declare a variable attribute "units" of that type for the obs_var variable:types: ...compound obs_atts { // a user-defined compound type string station_id; string time; string temperature; string pressure; } variables: ... obs_atts obs_var:units = { // a units attribute of type obs_atts time = "hours since 2000-01-01 00:00"; temperature = "degreesC"; pressure = "hPa"; }; Notice that since the station_id member of the obs_type has no units, we do not include a station_id member in the associated obs_var:units attribute. Strictly speaking, there's no need to even use the same order for the members in the obs_atts type, since an association can be made by using the same member names. Also if you wanted to associate a "standard_name" attribute string with each member of the obs_type, you would need to define another variable attribute named "standard_name" for the obs_var variable, but you wouldn't need another type: variables: ... obs_atts obs_var:standard_name = { // another attribute of type obs_atts temperature = "air_temperature"; pressure = "air_pressure"; }; There is a convention implicit in the above, that identity of member names between attribute compound types and variable compound types can be used to associate attributes with members of compound types, but I think this convention is natural and easy to understand. --Russ _____________________________________________________________________ Russ Rew UCAR Unidata Program russ@xxxxxxxxxxxxxxxx http://www.unidata.ucar.edu ============================================================================== To unsubscribe netcdf-hdf, visit: http://www.unidata.ucar.edu/mailing-list-delete-form.html ==============================================================================
-- Simon Wood Meteorology & Remote Sensing Scientific Programmer NIWA simon.wood@xxxxxxxxxx http://www.niwa.co.nz ============================================================================== To unsubscribe netcdf-hdf, visit: http://www.unidata.ucar.edu/mailing-list-delete-form.html ==============================================================================
netcdf-hdf archives: