[Esip-documentation] ACDD comments --

Mon Sep 22 19:46:29 EDT 2014

Hello group:

Looking through CF featureTypes I can't find anything that describes a satellite “swath”  (or a level 3 grid for that matter).

Am I correct in this assessment ?

On Sep 22, 2014, at 11:55 AM, Signell,	Richard via Esip-documentation <esip-documentation at lists.esipfed.org> wrote:

> Nan,
> Excellent point.   I think all CF datasets that don't have a
> `featureType` identified would be treated as `grid`.   That would be
> okay, wouldn't it?
> 
> On Mon, Sep 22, 2014 at 2:48 PM, Nan Galbraith via Esip-documentation
> <esip-documentation at lists.esipfed.org> wrote:
>> Hi All -
>> 
>> I mostly agree with Rich;  the 2 sets of terms are redundant - at
>> best.
>> 
>>> Reading this, I think we should just modify ncISO to read featureType
>>> rather than cdm_data_time and deprecate its use in favor of
>>> featureType
>> 
>> 
>> But! My concern is that by using the featureType attribute you
>> are identifying your file as a discrete sampling geometry file,
>> and there are still MANY data sets that don't fit that. Lots of
>> data is published as data(T,Z,Y,X) - not permitted in DSG files.
>> Here's a CF email from Jonathan on the subject:
>> 
>> 
>> 
>> -------- Original Message --------
>> Subject:        [CF-metadata] featureType attribute (was CF-1.6 DSG
>> clarification: time series & lat/lon coordinates)
>> Date:   Tue, 3 Dec 2013 21:06:03 +0000
>> From:   Jonathan Gregory <j.m.gregory at reading.ac.uk>
>> To:     cf-metadata at cgd.ucar.edu
>> 
>> 
>>> Dear Nan
>>>> 
>>>>> 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?
>>> 
>>> featureType can have only those values which are shown in Table 9.1. Each
>>> value means that the data has a particular geometry, as shown in the
>>> table.
>>> Your data
>>>> 
>>>>> float seatemp(time, depth, lat, lon)
>>> 
>>> does not have one of those geometries. In words, it isn't apparently a set
>>> of timeseries, or a set of profiles, or any other of the possibilities.
>>> It's
>>> a variable with four independent spatiotemporal axes. This is the "usual"
>>> type of gridded domain which CF has always supported. In the discrete
>>> sampling geometries the spatiotemporal axes aren't all independent.
>>> Therefore I
>>> don't think you can use the featureType attribute with your data as it
>>> stands.
>> 
>> 
>> Cheers -
>> Nan
>> 
>> 
>>> On Fri, Sep 19, 2014 at 5:16 PM, John Graybeal via Esip-documentation
>>> <esip-documentation at lists.esipfed.org>  wrote:
>>>> 
>>>> I'm going to start replying to some of these on separate threads.
>>>> 
>>>> I'm consolidating the issues into the Google spreadsheet as we discussed
>>>> on
>>>> the call, will publish that 'shortly' (when done).
>>>> 
>>>> By the way, sorry for the delayed post of my mail responding to Bob, that
>>>> mail was written yesterday and got hung up.
>>>> 
>>>> On Sep 18, 2014, at 11:50, Bob Simons - NOAA Federal<bob.simons at noaa.gov>
>>>> wrote:
>>>> 
>>>> cdm_data_type should not be tied to
>>>> 
>>>> 
>>>> http://www.unidata.ucar.edu/software/thredds/current/tds/catalog/InvCatalogSpec.html#dataType
>>>> which is out-of-date and obsolete
>>>> 
>>>> Are you sure? I thought several on this list were still using it.
>>>> 
>>>> They probably are. That doesn't make it right. Unidata has created
>>>> several
>>>> sets of terms over the years. They haven't retracted the old versions.
>>>> I'm
>>>> not saying what the right list of terms is, just that that list is
>>>> out-of-date. Until Unidata and CF get their act together, it is better
>>>> for
>>>> ACDD to not pick a winner.
>>>> Please read this entire exchange:
>>>> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2010/048519.html
>>>> which clearly indicates the John Caron (if he is in practice the decider)
>>>> says about cdm_data_type, which clearly goes beyond the list ACDD is
>>>> seeking
>>>> to enshrine.
>>>> 
>>>> 
>>>> ACDD picked that winner in a previous version, and I reviewed the CF
>>>> thread
>>>> a year ago while trying fix this issue. Because there are many data sets
>>>> that followed ACDD then (and some still use the cdm_data_type, per Rich),
>>>> we
>>>> didn't deprecate the existing attribute. But we did clarify in the
>>>> definition that there is another attribute called featureType in CF
>>>> (which
>>>> is the outcome of the thread you cited, I believe).
>>>> 
>>>> I'd be happy to move cdm_data_type to Suggested instead of Recommended, I
>>>> think it should no longer be recommended. And maybe that wording needs to
>>>> be
>>>> improved, and the featureType attribute explicitly added? But I don't
>>>> think
>>>> we should redefine its meaning in a way that would break the previous
>>>> uses.
>>>> 
>>>> John
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Esip-documentation mailing list
>>>> Esip-documentation at lists.esipfed.org
>>>> http://www.lists.esipfed.org/mailman/listinfo/esip-documentation
>>>> 
>>> 
>>> 
>> 
>> 
>> --
>> *******************************************************
>> * Nan Galbraith                        (508) 289-2444 *
>> * Upper Ocean Processes Group            Mail Stop 29 *
>> * Woods Hole Oceanographic Institution                *
>> * Woods Hole, MA 02543                                *
>> *******************************************************
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Esip-documentation mailing list
>> Esip-documentation at lists.esipfed.org
>> http://www.lists.esipfed.org/mailman/listinfo/esip-documentation
> 
> 
> 
> -- 
> Dr. Richard P. Signell   (508) 457-2229
> USGS, 384 Woods Hole Rd.
> Woods Hole, MA 02543-1598
> _______________________________________________
> Esip-documentation mailing list
> Esip-documentation at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-documentation

-ed

Ed Armstrong
JPL Physical Oceanography DAAC
818 519-7607