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 Jonathan: I think the core of the disagreement might be alternative ways to understand what the domain is of the variable. We agree that the dimensionality of the domain is the number of independent coordinates. So lets just clarify how we each interpret the number of independent coordinates in a few example cases. First, let me use radar data to illustrate the difference between domain and range dimensionality. Im guessing you may not disagree here, but i think it may help others to follow along. Consider a sweep from a scanning radar mounted on an airplane. This might look like: {{{ float elev(y, x); float azimuth(y, x); float radius(y, x); float data(y, x); coordinates: "azimuth elev radius"; }}} I think of the data as 2 dimensional, embedded in 3 dimensional space. So the number of independent coordinates is 2, and the total number of coordinates is 3. Ok, so whats the dimensionality of a trajectory? In the CDM data model, its considered one dimensional, because it can be represented as: {{{ float lat(sample); float lon(sample); float alt(sample); float time(sample); float data(sample); coordinates: "lat lon alt time"; }}} The idea is that it looks like a 1D line embedded in 4D space/time. Since time is almost always monotonic, its nice to use: {{{ float lat(time); float lon(time); float alt(time); float time(time); float data(time); coordinates: "lat lon alt time"; }}} What about time series data? Well, it could also look like: {{{ float lat(time); float lon(time); float alt(time); float time(time); float data(time); coordinates: "lat lon alt time"; }}} although {{{ float lat; float lon; float alt; float time(time); float data(time); coordinates: "lat lon alt time"; }}} is really nice in making it clear from the structural metadata alone that all the data is at one point. Note that under propsal #104, if you want to preserve the idea that time series have only one degree of freedom, it would be difficult since scalar coordinates imply that they are independent. Your only choice would be to the one above that looks just like a trajectory. When there "really is" another degree of freedom, then adding another explicit dimension seems natural, as we agree with height coordinates for gridded data. Replying to [comment:48 jonathan]: > Dear John > > If you have a coordinate variable `lat(time)`, I think it must be a trajectory - is that right? In Table 9.1, we define a trajectory as "a series of data points along a path through space with monotonically increasing times", so it is natural to record time as the independent coordinate, and latitude depends on it. In that situation, according to this ticket, you would ''not'' replace `lat(time)` with a scalar `lat`, even if the latitude were unchanging all the way along the trajectory, because doing so would incorrectly imply that latitude is independent. You have to keep `lat(time)` and fill it with repeated values. Actually, I think that is better anyway in this case, precisely because latitude really is a function of time. I think it would be strange to use a different way of storing a trajectory if the latitude values were [51, 51, 51, 51] on the one hand, or [51, 51.001, 51, 51] on the other. > > For timeseries data, the latitude and time coordinates are independent. If it's a single timeseries, it will have only one latitude, and in that situation, according to this ticket, it would be fine to replace the size- one coordinate variable `lat(lat)` with the scalar `lat`, and omit the dimension `lat=1`. > > If you have data on multiple vertical levels with a physical coordinate, it might have dimensions `data(pressure,lat,lon)`. When you extract a single level, you reduce the dimension to `pressure=1`. The size-one `pressure(pressure)` is an independent coordinate. In this situation, CF permits you to replace it with a scalar `pressure` and omit the size-one dimension. You don't have to do this; it's a convenience feature, as the standard document says. According to this ticket, replacing `pressure(pressure)` with `pressure` does not alter the interpretation. It is still a size-one independent coordinate. This ticket says that the scalar coordinate implies the existence of a size-one dimension. > > I agree that you do not add a vertical dimension for temperature at the tropopause, because tropopause doesn't have a numerical coordinate to define it. CF provides standard_names for quantities that exist on special physically defined leves, for this reason. CF does not provide standard names for levels which can be specified with coordinate values. There isn't a standard name for temperature at 2.0 m height, because that can be specified with a size-one `height` coordinate. It could be either `height(height)` with dimension `height=1`, or a scalar `height`. According to this ticket, they both logically describe an independent size-one dimension. > > CF has this convenience feature because it allows you to have many size- one independent coordinates without having to create netCDF dimensions for them. This ticket says that the domain logically has these size-one dimensions anyway. > > Is that all right? > > Cheers > > Jonathan -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/104#comment:52> 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.
