[Esip-documentation] ACDD comments --

Nan Galbraith via Esip-documentation esip-documentation at lists.esipfed.org
Mon Sep 22 14:48:21 EDT 2014


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                                *
*******************************************************





More information about the Esip-documentation mailing list