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 are some comments and a new proposal for the text about the coordinate constructs. Regarding the definition of "cell", I have the same instinct as Mark about what this means, but if Martin finds additional description helpful as clarification, then I imagine it's likely to be useful to others as well if we include it. Regarding the statement of the purpose of an auxiliary coord construct, I think that "An auxiliary coordinate construct provides information for interpreting one or more domain axes", while correct, is not informative enough. I would now propose "An auxiliary coordinate construct provides physical coordinates to locate the cells along one or more domain axes." That is, the information it provides is physical coordinates which locate the cells. The fact that it's an ordered list of domain axes can be postponed to the description of the data array. I have to say that I don't find Mark's restatement of purposes in comment 24 makes things clearer for me. I agree that one has to read the description of both the field and the coordinates to get the ideas, but since in total it's not very long, that shouldn't be an obstacle. I also do not agree that ordered versus unordered is the principal distinction between dimension and auxiliary coordinate constructs. Dimension coordinates are ordered in CF, I think, because monotonicity makes uniqueness easier to enforce, and because it's useful for doing calculations with the coordinate variable. In my view the principal distinction is that dimension coordinate uniquely locate the cells (or points) along the domain axes, while auxiliary coordinate supply information to locate the cells in optional alternative ways. Auxiliary coordinates can be and often are also monotonic. Regarding the requirement for latitude and longitude auxiliary coordinates, I would argue that since it's in CF-netCDF and not something which is a feature specifically of the netCDF file format (like, for instance, the `Coordinates` attribute is), it must be part of the CF data model. This is the complement of the argument whereby we are omitting features from the CF data model if they are not currently in CF-netCDF, even though they may be logically obvious. This requirement for auxiliary coordinates could subsequently be dropped at a later version of CF-netCDF, and then we would also remove it from the CF data model. Here's a new proposed version of the text for dimension and auxiliary coordinate constructs, bearing in mind all the above. I have changed the terminology for bounds to call them "boundary arrays" instead of "boundary coordinate arrays", because that allows us to make a convenient distinction between "coordinate arrays" and "boundary arrays". We also need text for domain axis constructs, not previously debated, so I've included that too. '''Domain axis construct''' A domain axis construct declares a dimension of the field. It must contain * A '''size''', which is an integer that must be greater than zero, but could be equal to one. '''Dimension coordinate construct''' A dimension coordinate construct provides physical coordinates to locate the cells at unique positions along a single domain axis. A dimension coordinate construct may contain: * A one-dimensional numerical '''coordinate array''' of the size specified for the domain axis. If the size is one, the single coordinate value may be a scalar instead of an array. If the size is greater than one, the elements of the coordinate array must all be of the same numeric data type, they must all have different non-missing values, and they must be monotonically increasing or decreasing. Dimension coordinate constructs cannot have string-valued coordinates. * A two-dimensional numerical '''boundary array''', whose slow-varying dimension (first in CDL, second in Fortran) equals the size specified by the domain axis construct, and whose fast-varying dimension is two, indicating the extent of the cell. For climatological time dimensions, the bounds are interpreted in a special way indicated by the cell methods. Sometimes the bounds are the important information for locating the cell, and the coordinates are notional, especially for extensive quantities. * Properties (in the same sense as for the field construct) serving to describe the coordinates. In this data model, a CF-netCDF string-valued coordinate variable or string-valued scalar coordinate variable corresponds to an auxiliary coordinate construct (not a dimension coordinate construct), with a domain axis that is not associated with any dimension coordinate construct. In this data model we permit a domain axis construct not to have a dimension coordinate construct if there is no appropriate numeric monotonic coordinate. That is the case for a dimension that runs over ocean basins or area types, for example, or for a domain axis that indexes timeseries at scattered points. Such domain axes do not correspond to a continuous physical quantity. (They will be called '''index dimensions''' in CF version 1.6.) '''Auxiliary coordinate construct''' An auxiliary coordinate construct provides physical coordinates to locate the cells along one or more domain axes. An auxiliary coordinate construct must contain: * A coordinate array whose shape is determined by the domain axes in the order listed, optionally omitting any domain axes of size one. If all domain axes are of size one, the single coordinate value may be a scalar instead of an array. If the array has more than one element, they must all be of the same data type (numeric, character or string), but they do not have to be distinct or monotonic. Missing values are not allowed (in CF version 1.5). In CF-netCDF, a string-valued auxiliary coordinate construct can be stored either as a character array with an additional dimension (last dimension in CDL) for maximum string length, or represented by a numerical auxiliary coordinate variable with a `flag_meanings` attribute to supply the translation to strings. and may also contain * A boundary array with all the dimensions, in the same order, as the coordinate array, and an additional dimension (following the coordinate array dimensions in CDL, preceding them in Fortran) equal to the number of vertices of each cell. * Properties (in the same sense as for the field construct) serving to describe the coordinates. Auxiliary coordinate constructs correspond to auxiliary coordinate variables named by the coordinates attribute of a data variable in a CF- netCDF file. CF requires there to be auxiliary coordinate constructs of latitude and longitude if there is two-dimensional horizontal variation but the horizontal coordinates are not latitude and longitude. Cheers Jonathan -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/95#comment:28> 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.
