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:27 jonathan]: > 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. > * 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. Hello Jonathan I think there are issues with this definition of domain axes and data for the Field. The domain axes mediate the qualified association of field and coordinate. To deliver this effectively they must provide unambiguous mappings between coordinate arrays and the data array. If the domain_axes are only identified by order and some may be omitted, then this is no longer secure. The relationship between a domain axis and a data dimension must be explicit and unambiguous to enable the coordinate relationships to be defined correctly. I think that we have 2 types of domain axis, the ones explicit in the Field's data array, and the ones which are not explicit in the data, which must be of length 1. I do not think that the second type, domain axes not explicit in the Field's data array, should be ordered and I do not think that their number needs to be fixed for a given Field. The Field should be flexible here. For this reason I propose that only the domain axes which are explicit in the Field's data array are declared by the field. Additional to this the Field defines one '''potential domain axis''' of size 1. This provides the idea that the Field's conceptual dimensionality may be more than the dimensionality of the data array, whilst constraining the relationships to be consitent with the data array as defined. I believe that this better represents how CF NetCDF files handle single valued coordinates not bound to NetCDF dimensions than the approach you have defined and I feel that this provides a more flexible approach for other implementations. what do you think? mark -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/95#comment:34> 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.
