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 <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 -----
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
Received on Tue Jun 04 2013 - 17:23:55 BST
