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/.
#104: Clarify the interpretation of scalar coordinate variables -----------------------------+---------------------------------------------- Reporter: jonathan | Owner: [email protected] Type: enhancement | Status: new Priority: medium | Milestone: Component: cf-conventions | Version: Resolution: | Keywords: -----------------------------+---------------------------------------------- Comment (by jonathan): Dear Steve and John Thanks for your additions. Yes, as Steve says, this discussion is entirely about interpretation and the data model. The current text can be seen as contradictory. This ticket proposes to remove the ambiguity by following the text, "Scalar coordinate variables have the same information content and can be used in the same contexts as a size one coordinate variable." That follows what Steve said earlier, and I quoted: "Scalar coordinate variables provide a convenient way to encode coordinate variables of size one. They do so by borrowing the syntax that is otherwise used for auxiliary coordinate variables." I think that the definition appears to be ambiguous because there are two kinds of scalar coordinate variable mentioned in the CF document. There are numeric scalar coordinate variables, which were introduced to mean the same thing as size-one numeric coordinate variables, and there are string- valued scalar coordinate variables, and they have to be logically regarded auxiliary coordinate variables because string-valued coordinate variables are not possible in netCDF. This ticket proposes to clarify that as well. We do not think that ambiguity is desirable or necessary and was not intended. We could retain the ambiguity by creating a third class of coordinate (not dimension coordinate, not auxiliary coordinate) in the data model, as Mark argues in ticket 105. David and I think that's an unnecessary complexity which has not been envisaged in the design of CF up to now, and that it's better for data-writers to indicate what their data mean. I'd like to understand John's point but it looks like I'll have to wait for a week. :-) The problem I'm having with it is shown by the example implied in my last posting: {{{ dimensions: station=2; time=NNN; variables: float lat(station); float lon(station); float time(time); float temp(station,time); temp:coordinates="lat lon"; }}} This is a discrete sampling geometry with two timeseries. The data variable has two dimensions. John writes, "The dimensionality of the data indicates the dimensionality of the domain. The number of coordinates represents the dimensionality of the range." So what is the dimensionality of the data here? I think, by expressing it as a DSG, we are saying the data is physically one-dimensional (time). The other netCDF dimension is just an index, a discrete axis. If you like, you can regard lat and lon as a function of this index. It's like an ensemble axis, which is also not a physical coordinate. If this is not true, I do not understand how chapter 9 can possibly meet John's requirement that timeseries should be regarded as physically one-dimensional. In my opinion, if `station=1` in the above example, we have the same interpretation of it. The data is still physically one-dimensional, though formally two-dimensional. In order to decide about this ticket, the CF committee has been asked to vote on it. So far, Nan, Roy, Russ, Martin, Rich, Karl and I have given support. It would be good to hear from Balaji, Philip, Bryan and Alison, as well as more from John and Steve, when possible. Best wishes Jonathan -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/104#comment:63> 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.
