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 caron): Hi all: > I would argue that it ''is'' possible, according to this ticket, to store the data with the interpretation you prefer, that it's one timeseries from a DSG. That is what it means if we use auxiliary coordinates i.e. > > {{{ > dimensions: > station=1; > time=NNN; > variables: > float lat(station); > float lon(station); > float time(time); > float temp(station,time); > temp:coordinates="lat lon"; > }}} > > In this case, the `station` dimension is a discrete axis. CF section 4.5 says a discrete axis "indicates either an ordered list or an unordered collection, and does not correspond to any continuous coordinate variable." So it is a netCDF dimension, but it doesn't correspond to any independent physical dimension. It's just an index; only `time` is an independent physical dimension. Isn't that what you want? > > Consider the case with `station=2` but otherwise the same. Now you have two 1D timeseries, each with a single independent physical dimension of time. The other netCDF dimension is just an index to bundle them up. You could put exactly the same data in a one of the chapter 9 ragged representations. Then the data array would have only one netCDF dimension, but the station dimension would still exist, and you would still have `lat(station)` and `lon(station)` just as above. Again, the `station` dimension is simply an index. Would you agree that this does not add any physical dimensions to the individual timeseries? I agree with your interpretation and that this is a possible way to represent 1D data. > > It is formally an auxiliary coordinate variable, but not logically so. That's a point that Steve made and is included in the motivation for this ticket - now a long way back in [https://cf- pcmdi.llnl.gov/trac/ticket/104#comment:28 comment 28]: > > 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. There is, however, a key difference between the interpretation of scalar coordinate variables and auxiliary coordinate variables. Scalar coordinates have the same status in a CF file as (conventional, Unidata, COARDS) coordinates in which the dimension name and the variable name match. These coordinates define the independent variables (spatiotemporal and others) for the data variable. Auxiliary coordinate variables provide extra information as a function of these independent variables, as alternative numeric values (which don't have to be unique or monotonic along a given dimension), or string-valued labels. To indicate that a variable is intended to be an auxiliary coordinate variable, it is necessary to give it a dimension, in order to show which coordinate variable(s) it belongs to. Numeric scalar coordinate variables are not to be interpreted as auxiliary coordinate variables. I dont see the motivation in this comment, it appears to be a statement of the proposal. Also this statement of the purpose of auxiliary coordinates misses the critical point of that they can represent the embedding of the data domain into a higher dimensional space (think of 2D radar in 3D cartesion space). Here's why I think scalar coordinates need to be understood as auxiliary coordinates. Suppose you want to add a length=1 coordinate, and you now get to decide if its dependent or independent. If independent, you must add a new dimension to the data, and if you want it to be a dependent variable, you must not add a new dimension to the data. In the independent case, you can use a standard coordinate variable lat (lat=1). But in the dependent case, you cant use anything other than the scalar form. So we need to leave that form as indicating an auxiliary coordinate. The example that ive been using to illustrate this is: {{{ 1D data: dimensions: time=23236727; float data(time); data:coordinates = "lat lon time" float time(time); float lat; float lon 3D data: dimensions: lat=1; lon=1; time=23236727; float data(time, lat, lon); data:coordinates = "lat lon time" float time(time); float lat(lat); float lon(lon) }}} The dimensionality of the data, indicates the dimensionality of the domain. The number of coordinates represents the dimensionality of the range. If you lose track of that then none of this really matters. Regards John -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/104#comment:60> 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.
