Tim,
You can use netCDF-4 without "classic" format, but for true, full CF
compliance you can't use any new features.
Personal opinion alert!!! The following is just my personal opinion. I'm
not trying to stir up trouble. I'm just sharing my observations on my
experiences. Please don't hate me.
The official CF community position is that for backwards-compatibility
reasons, they would rather not adopt new features unless there is no
"good" workaround using the old feature set. Contention can arise over
the question of whether you view the workaround as "good" or not, but
that seems to be roughly how the thought goes. The CF community also do
not view themselves as developers of new features that aren't driven by
present needs. They are also interested in maximizing the ability of
(sometimes theoretical) existing CF-aware analysis packages to properly
handle all CF-compliant files.
In previous conversations I've been given to understand that the
effective process for bringing new netCDF features into CF will be for
someone to use them in a dataset, doing their best to interpret CF in
the light of the new features. If it is a popular dataset, it will push
the CF community towards adopting some form of those new features.
In a case where I was developing a new dataset that would have been
particularly unwieldy (in my opinion) without groups, I went ahead and
used them, applying a hierarchical scope approach to file and group
attributes. As my dataset is not likely to be widely used by any
analysis packages, it will not likely cause anyone grief or drive the
adoption of new netCDF features into CF.
Grace and peace,
Jim
On 9/10/14, 9:53 AM, Timothy Patterson wrote:
> Is it correct to say that, although they don't explicitly state it, the CF conventions (1.6 and the draft 1.7) restrict compliant netCDF products to be either netCDF-3 or netCDF-4 in classic format? There are no conventions for the enhanced features such as groups and user-defined types like enumerated variables, and Section 2.2, as an example, bars the use of unsigned integer variables or string variables (which are even stated not to exist, again implying classic-model only).
>
> There are some features of the enhanced model we want to use for our future datasets (such as groups) and some features which would make life easier but could be worked around if it led to CF compliance (enumerated types, unsigned integers, string types, etc.). Are there any plans to introduce conventions for the use of these enhanced features at some point in the future or would non-classic model datasets always be seen as non-compliant?
>
> Thanks for your insights on this issue!
>
> Regards,
>
> Tim Patterson
>
>
>
> ---------------------
>
> Dr. Timothy Patterson
> Instrument Data Simulation
> Product Format Specification
>
> EUMETSAT, Eumetsatallee 1, D-64295 Darmstadt, Germany
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA's National Climatic Data Center <http://ncdc.noaa.gov/>
151 Patton Ave, Asheville, NC 28801
e: jbiard at cicsnc.org
o: +1 828 271 4900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140910/95ec0b55/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cjefaccd.png
Type: image/png
Size: 11847 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140910/95ec0b55/attachment-0001.png>
Received on Wed Sep 10 2014 - 09:25:22 BST
