This message came from the CF Trac system. Do not reply. Instead, enter your comments in the CF Trac system at https://cf-pcmdi.llnl.gov/trac/.
#95: Development of CF 1.5 Data Model -----------------------------+---------------------------------------------- Reporter: markh | Owner: [email protected] Type: task | Status: new Priority: medium | Milestone: Component: cf-conventions | Version: Resolution: | Keywords: -----------------------------+---------------------------------------------- Comment (by jonathan): Dear all Here's a new proposal for the text about the field construct. This is based on the version Mark posted from David's document, incorporating suggestions from Martin. Following Mark's suggestion to make a clearer separation between the logical data model and the netCDF format, I have moved most of the netCDF-specific comments to the end. Regarding the point about omitting domain axes of size one, I wouldn't say it's an implementation detail. It's more of an explanatory note, so I've put it in brackets. Regarding the remarks about domain consistency, I think we should keep these because they arose from an earlier quite lengthy debate on the issue, in which the agreement was to spell it out like this. I'm going to post separately about the coordinate constructs. Note that we still have to deal with cell measures, cell methods, properties (which I hope should all be easy to agree) and transforms (which need most thought). Please see http://www.met.reading.ac.uk/~david/cfdm_recast.html for the proposals David and I have made for these. '''Field construct''' The central concept of the data model is a '''field construct'''. A field construct corresponds to exactly one data array together with associated information about the domain in which the data resides (defined by spatio- temporal and other coordinates) and other metadata. This data model makes a central assumption that each field construct is independent. Each field construct may contain the following, all of which are optional. * An ordered list of '''domain axis constructs'''. * A '''data array''' whose shape is determined by the domain axes in the order listed, optionally omitting any domain axes of size one. (It is possible to omit domain axes of size one because their position in the order of domain axes makes no difference to the order of data elements in the array.) If there are no domain axes of greater size than one, the single datum may be a scalar instead of an array. If the data array has more than one element, they must all be of the same data type, which may be numeric, character or string. * An unordered collection of '''dimension coordinate constructs'''. * An unordered collection of '''auxiliary coordinate constructs'''. * An unordered collection of '''cell measure constructs'''. * A '''cell methods construct''', which refers to the domain axes (but not their sizes). * An optional unordered collection of '''transform constructs''' (corresponding to CF-netCDF `formula_terms` and `grid_mapping`). * Other '''properties''', which are metadata that do not refer to the domain axes, and serve to describe the data the field contains. Properties may be of any data type (numeric, character or string) and can be scalars or arrays. These properties correspond to attributes in the netCDF file, but we use the term "property" instead because not all CF-netCDF attributes are properties in this sense. * A list of '''ancillary fields''' (corresponding to the CF-netCDF `ancillary_variables` attribute, which identifies other data variables that provide metadata). Collectively, the domain axis, dimension coordinate, auxiliary coordinate, cell measure and cell method constructs describe the domain in which the data resides. Thus a field construct can be regarded as a domain with data in that domain. The CF-netCDF `formula_terms` (see also Transform constructs) and `ancillary_variables` attributes make links between field constructs. These links are fragile and it might not always be possible for data processing software to maintain a consistent set of such links when writing fields to files or manipulating them in memory. CF-netCDF considers fields which are contained in single netCDF files. In a dataset contained in a single netCDF file, each data variable corresponds to one field construct. This data model has a broader scope. It applies also to data contained in memory and to datasets comprising several netCDF files. A field construct may span data variables in more than one file, for instance from different ranges of a time coordinate. Rules for aggregating data variables from several files into a single field construct are needed but are not defined by CF version 1.5; such rules are regarded as the concern of data processing software. Technically, data variables stored in CF-netCDF files are often not independent, because they share coordinate variables. However, we view this solely as a means of saving disk space, and we assume that software will be able to alter any field construct in memory without affecting other field constructs. For instance, if the coordinates of one field construct are modified by averaging the field values over one dimension, it will not affect any other field construct. Explicit tests of domain consistency will be required to establish whether two data variables have the same coordinates or share a subset of these coordinates. Such tests are necessary in general if CF is applied to a dataset comprising more than one file, because different variables may then reside in different files, with their own coordinate variables. Within a netCDF file, tests for the equality of coordinates between different data variables may be simplified if the data variables refer to the same coordinate variable. Best wishes Jonathan -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/95#comment:27> CF Metadata <http://cf-pcmdi.llnl.gov/> CF Metadata This message came from the CF Trac system. To unsubscribe, without unsubscribing to the regular cf-metadata list, send a message to "[email protected]" with "unsubscribe cf-metadata" in the body of your message.
