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 markh): Replying to [comment:28 jonathan]: > 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. Hello Jonathan On this point, the perspective I am trying to investigate is whether the typing of the construct is the important factor; I am currently of the view that it is not. As such, I have suggested that the description of the role does not belong with the construct, rather with the Field which references it. A dimcoord/orderedcoord does not know what it does, it only knows what it is ( a constrained (1d, strictly monotonic) coord/auxcoord/unorderedcoord). The Field is responsible for the role of each of its coords. I think that, in the current text, the Field is too much of an unaware container of clever constructs; I think this perspective should be reversed, with the Field being a smart container of simple constructs. This makes it easier for more emergent propeties to be developed over time. So, using your terminology, I advocate that > '''Field construct''' > > ... > > * An unordered collection of '''dimension coordinate constructs'''. is changed to say '''Field construct''' ... * attributes: * dimension_coordinates * this attribute defines the domain axes of the Field * each domain_axis may reference 1 '''dimension coordiante construct''', defining the meaning of this domain_axis * Each '''dimension coordinate construct''' provides physical coordinates to locate the cells at unique positions along a single domain axis of the Field. '''Dimension coordinate construct''' A dimension coordinate construct may contain: * A one-dimensional numerical coordinate array .... This lead me to suggest the change of name, to make it clear where the responsibility lies. The role is the important factor for me, I'm not wedded to the name change or the 'ordered' naming. When applying this to a NetCDF file, the NetCDF file creates the Field's domain_axes (the NetCDF dimensions) and the dimension_coordiantes attribute (the collection of coordinate variables) for a data variable. The dimcoord/orderedcoord construct is only the contents of the coordiante variable (points, bounds, standard_name) and nothing else: no contextual awareness. This perspective is really valuable when working with CF fields dynamically (in models, post processing etc). I think it is consistent with CF for NetCDF and more powerful and flexible than the proposed description of roles. e.g.: A monotonic coordinate may be explicitly placed in the Field's auxiliary_coordinates collection, then later be used to defined a newly explicit domain axis as the Field grows in size and shape. -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/95#comment:30> 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.
