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 <caron at unidata.ucar.edu> -----
> Date: Tue, 4 Jun 2013 10:54:45 -0600
> From: John Caron <caron at 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 at 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 at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
Received on Tue Jun 04 2013 - 11:33:30 BST
