> Does the presence of a featureType attribute indicate that a file uses the DSG "machinery" and should therefore follow the guidelines of limited axes that are spelled out in chapter 9?
This was the reason I favored creating a new ACDD term. It was clear in the documentation that featureType implied a DSG-compliant file -- but I didn't see any reason I had to create a DSG-compliant file to make the file CF-1.6 compliant. As Nan says, it implicitly overloads the term.
Happy to be educated if I missed something. (But if it is true that all CF-1.6 compliant files have to be DSG, than there is no reason for featureType to mention DSG, since every file will already be DSG.)
John
On Dec 3, 2013, at 06:31, Nan Galbraith <ngalbraith at whoi.edu> wrote:
> Sorry to drag this out again, but I need to restate my question; it's more or
> less the opposite of the question that was answered.
>
> Does the presence of a featureType attribute indicate that a file uses the DSG
> "machinery" and should therefore follow the guidelines of limited axes that
> are spelled out in chapter 9?
>
> Can I use this attribute and NOT have an instance (or station) dimension,
> but stick with my current encoding:
> float seatemp(time, depth, lat, lon)
> rather than changing to:
> float seatemp(station, time)
>
> We need an attribute in oceansites files that indicates the type of feature in the file -
> multiple-depth moored instruments, single-depth moored instruments, profiles ...
> We'd like to use this attribute to fill that role, but if it is overloaded in the sense that
> it indicates something else about the file, we'll need to use another term.
>
> Thanks -
> Nan
>
> On 8/29/13 9:55 AM, Jonathan Gregory wrote:
>> Dear Nan
>>
>> It is allowed to use the new "machinery" of ch9 only if the featureType att
>> is included. Perhaps we should put this in Appendix A - is that your
>> suggestion? The new machinery is the incomplete multidimensional representation
>> and the two ragged representations (which collapse the data variable into 1D)
>> It is allowed to use the orthogonal rep (the data variable is samples*features)
>> because that existed anyway, before ch9 was introduced, and there were already
>> examples of it in the document.
>>
>> Best wishes
>>
>> Jonathan
>>
>> ----- Forwarded message from Nan Galbraith <ngalbraith at whoi.edu> -----
>>
>>> Date: Thu, 29 Aug 2013 09:46:14 -0400
>>> From: Nan Galbraith <ngalbraith at whoi.edu>
>>> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0)
>>> Gecko/20130801 Thunderbird/17.0.8
>>> To: cf-metadata at cgd.ucar.edu
>>> Subject: [CF-metadata] featureType attribute (was CF-1.6 DSG clarification:
>>> time series & lat/lon coordinates)
>>>
>>> Hi all -
>>>
>>> Quick question on the featureType attribute.
>>>
>>> Back in June, Jonathan Gregory said:
>>>
>>>> for a DSG (which is indicated by the presence of featureType)
>>> I don't think this is stated clearly in the CF 1.6 manual, and as a
>>> result, some
>>> people have taken 'featureType' to be the equivalent of the 'cdm_data_type'
>>> attribute.
>>>
>>> I'm not using discrete sampling geometries yet, and am not
>>> completely familiar
>>> with the details of this part of CF 1.6, but I understand that the
>>> rules for allowed
>>> coordinate variables (dimensions) are quite different from those of non-DSG
>>> files.
>>>
>>> If the use of a single attribute changes the rules that much, I
>>> think we need to
>>> spell it out *very* clearly in the description of the featureType
>>> attribute in the
>>> CF document.
>>>
>>> Regards - Nan
>>>
>>>
>>> On 6/5/13 9:08 AM, Jonathan Gregory wrote:
>>>> Dear John
>>>>
>>>>> 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)
>>>> You are quite right, sorry. I was taking a step too far! The point is not only
>>>> that the coordinates are size-1, but there is more than one of them. You are
>>>> right that (lat,lon,time) can't be a timeseries discrete sampling geometry
>>>> because it's got more than one spatial dimension. A timeseries DSG can have
>>>> only one station (instance) dimension, and it is required to have both x and y
>>>> coordinates. So these current rules mean that 2D field e.g. (lat,time) can't
>>>> be a timeseries DSG.
>>>>
>>>> Like Mark, I saw the relevance of this to the discussion of scalar coordinates
>>>> but I reached a different conclusion about it! At the moment, we are talking
>>>> about the CF data model for version 1.5. DSGs were introduced in version 1.6.
>>>> As a result of this discussion, it seems me that for a DSG (which is indicated
>>>> by the presence of featureType), scalar coordinate variables have to be
>>>> interpreted as auxiliary coordinate variables of an omitted size-one instance
>>>> dimension. That is what is implied by section 9.2. It's different from the
>>>> interpretation that is implied by section 5.7, which should exclude DSGs (and
>>>> predates DSGs). I see no problem with having different interpretations for
>>>> different purposes.
>>>>
>>>> Cheers
>>>>
>>>> Jonathan
>>>>
>
>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
------------------------------------
John Graybeal
Sr. Data Manager, Metadata & Semantics
M +1 408 675-5445
skype: graybealski
Marinexplore
920 Stewart Drive
Sunnyvale 94085
California, USA
www.marinexplore.com
Received on Tue Dec 03 2013 - 13:10:11 GMT
