Hi Jonathan: If we use the time series featureType as example
(from http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#idp8307552) AFAIU, the orthogonal multidimensional representation would be: float humidity(station,time) not float humidity(lat, lon, time) Regards, John On 6/4/2013 11:33 AM, Jonathan Gregory wrote: > Dear John C > > I think the two questions are linked actually. There is nothing wrong with > the size-1 dimensions in general, I would say. You could see it as a single > point extracted from a larger gridded field (time,atl,lat,lon) in which all > the dimensions were originally greater than one. It's legal in the orthogonal > multidimensional representation, which is the one representation which has > always existed in CF. When we added ch9, we brought that representation into > the same chapter. > > If the CDM doesn't like the orthogonal multidimensional representation for > DSG, we could disallow featureType if that representation is used. Then the > CDM wouldn't attempt to process it as a DSG. It would be a pity to lose the > extra metadata that the featureType provides, though. > > Best wishes > > Jonathan > > > ----- Forwarded message from John Caron <ca...@unidata.ucar.edu> ----- > >> Date: Tue, 4 Jun 2013 10:54:45 -0600 >> From: John Caron <ca...@unidata.ucar.edu> >> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 >> Thunderbird/17.0.6 >> To: cf-metadata@cgd.ucar.edu >> Subject: Re: [CF-metadata] CF-1.6 DSG clarification: time series & lat/lon >> coordinates >> >> Hi Jonathan: >> >> On 6/4/2013 4:17 AM, Jonathan Gregory wrote: >>> Dear John Caron and John Maurer >>> >>> I agree with John C that the problem arises when the coordinate variables >>> are not size one. John M's example >>> >>>>> float lon(lon) ; >>>>> float lat(lat) ; >>>>> float alt(alt) ; >>>>> float temp(time, alt, lat, lon) ; >>>>> temp:standard_name = ?air_temperature? ; >>>>> temp:units = "Celsius" ; >>>>> temp:coordinates = "time lat lon alt" ; >>>>> temp:_FillValue = -999.9; >>> >>> with alt=lat=lon=1 is legal in CF. In fact the coordinates attribute is not >>> needed, because these are all (Unidata) coordinate variables (1D, with name >>> of the variable equal to the name of the dimension). Ignoring the >>> coordinates >>> attribute, this example is fine in COARDS as well. In the data model, lon >>> lat >>> alt time are all dimension coordinate constructs with separate domain axes. >>> >>> But when there are *two* timeseries, you would not have alt=lat=lon=2. That >>> would mean three independent size-2 dimensions. This would also be legal in >>> CF and COARDS, but it means timeseries at a grid of 8 points, not two >>> points. >>> To deal with this situation, we introduce an index dimension of size 2, and >>> make alt lat lon auxiliary coordinate variables of this single dimension. In >>> the data model, there is then only one domain axis for alt lat lon. >>> >>> Back to the case of one timeseries: Example H4 shows scalar coordinate >>> variables for alt lat lon. That is, these size-1 dimensions have been >>> omitted. >>> In this case, the coordinates attribute is needed; that's how scalar >>> coordinate >>> variables are attached to the data variable. In the data model (in my >>> opinion) >>> this is logically equivalent including the size-1 dimensions. >> >> Lets see, its currently not legal as a DSG file, according to the >> spec. The CDM will barf on it, though I could put in a workaround. >> >> Should it be legal? That is, should people be "allowed" to put in >> extraneous dimensions that only make sense for some values of the >> dimension length (eg 1 but not >1) ? I think it would be a rather >> ugly wart, and you would gain no new functionality. >> >> I also think it would confuse dimensions with coordinates (which has >> already happened because the distinction isnt obvious). I think we >> should try to be clear about the use of dimensions because it makes >> the data model more powerful. So I would prefer not. >> >>> >>> Maybe this question raises an issue for chapter 9 and Example H4. The >>> example >>> is following Section 9.2: >>> >>> "If there is only a single feature to be stored in a data variable, there >>> is no >>> need for an instance dimension and it is permitted to omit it. The data will >>> then be one-dimensional, which is a special (degenerate) case of the >>> multidimensional array representation. The instance variables will be >>> scalar >>> coordinate variables; the data variable and other auxiliary coordinate >>> variables will have only an element dimension and not have an instance >>> dimension, e.g. data(o) and t(o) for a single timeSeries." >>> >>> In the multidimensional array representation, featureType doesn't have to be >>> coded, because this representation has always existed in CF. We could say >>> that >>> *if* you encode featureType, there *must* be an instance dimension (of size >>> 1 >>> if appropriate) and that alt lat lon must be auxiliary coordinate variables >>> with this dimension. That would be a restriction we don't have in CF 1.6, so >>> it would be a change to CF. What do you think, John C? >> >> I think this is a seperate question yes? >> >> From my POV, its just a practical question to make things clear >> between data producer and consumer. I think we allowed the scalar >> instance coordinates because it was a natural way for producers to >> think when there was only one feature in the file, ie "why do you >> want me to add this extra dimension?" As long as the "featureType" >> attribute is present, as well as the "coordinates" attribute I think >> the meaning is unambiguous. Requiring a dimension=1 is maybe a bit >> simpler, but i would still have to deal with the scalar case for >> versions before we change, so its not really better for me. >> >> John Caron >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata@cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > ----- End forwarded message ----- > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
