[Esip-documentation] ACDD comments -- featureType

[John Graybeal via Esip-documentation]

On Sep 22, 2014, at 12:59, Bob Simons - NOAA Federal via Esip-documentation <esip-documentation at lists.esipfed.org> wrote:

>> So I claim the existing content is appropriate, and propose that we move cdm_data_type down to the Suggested section as a way to reflect current thinking about its importance. 
> But leaving the definition as is leaves in place the link to THREDDS "dataType" 
> http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType 
> which is out-of-date.

Right, I take your point. I know the situation is messy. Until Unidata weighs in to say that code is not authoritative, then I would tend to keep referencing it, to match historical use. 

On the other hand, I found https://github.com/Unidata/thredds/blob/target-4.3.22/cdm/src/main/java/ucar/nc2/constants/FeatureType.java some time ago, it has more types (see http://kitt.llnl.gov/trac/ticket/113#comment:11 for brief discussion). If everyone wants to point to the github code instead that also works for me; then we would want to change the list of compatible terms.

If that is not authoritative either, then we are in a bind.

I'd appreciate hearing more from the community about how we should think of this attribute:(a)  no longer recommended at all and therefore deprecated; (b) Suggested for historical compatibility reasons; or (c) Recommended and in need of a current definition and citation.

> And leaving the definition as is leaves in place the link to NODC guidance
>  http://www.nodc.noaa.gov/data/formats/netcdf/
> which (although currently probably correct) is a TERRIBLE idea. This is a CF term, not an NODC term. If there is to be a definition (and changes in the future), then now and in the future it should only point to the CF definition.
> If NODC wants their guidance listed, then have them work to add it to the CF definition.

The reference was not for featureType, but for cdm_data_type. Sorry, awkward phrasing in the definition, I will fix. 

The reason for the pointer to NODC guidance (which more broadly will be outdated wrt ACDD 1.3)  is that I was told ACDD was developed in alignment with NODC's feature templates, and in this case the guidance seemed relevant. But it's the group's call whether to reference this external guidance or not from ACDD.

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20140922/1cc140c8/attachment.html>