Hello all -
Although we have not had any more input on the best way to
declare a community profile in a CF-compliant file, I still have a
question. I think this also relates to the namespace ticket (#27)
on the trac system.
The trac ticket mentions that using comma-separated conventions is the
method suggested in the NetCDF documentation, although the page
referenced,
http://www.unidata.ucar.edu/software/netcdf/guidef/guidef-13.html,
is not a working link.
The CF compliance checker chokes on a compound conventions
attribute, like Conventions = "CF-1.4, OceanSITES-1.0" - is this the
accepted
method of declaring multiple conventions, or do I need to stick with
a pristine "CF-1.4" and declare the OceanSITES compliance in a separate
attribute, perhaps, as Derrick suggested, using a "profile" attribute?
Since most of the OceanSITES participants are now generating data in
this format, and since we are requesting that they check their files for
CF compliance, I'd really like to know the preferred way to do this.
Again, the OceanSITES spec is completely CF compliant, it just imposes
more restrictions, essentially simplifying CF for use with in situ data
(although,
IMHO, it's probably quite a bit more rigid than is really necessary).
Thanks -
Nan
John Caron wrote:
> Derrick Snowden wrote:
>> ... My question is, how does one go about developing a community
>> profile? Does this end up being another convention or is it distinct
>> in its representation in the file. For example, would the global
>> attributes look like
>>
>> .Conventions = "CF-1.4, XBT-1.0" or
>>
>> .Conventions = "CF-1.4"
>> .Profile = "XBT-1.0" or .Community_Profile or whatever?
>>
>> Clearly anything can be done, my question is does anyone care to
>> comment on what should be done? I know other communities such as
>> Argo and OceanSITES have made some choices but I'm not sure if
>> they're the right ones.
>>
> Hi Derrick:
>
> ...
>
> The CF Conventions try to constrain the storage choices to a
> reasonable balance between efficiency for the writers and
> interoperability for the readers. We havent seen too much profiling
> within it, and the less the better. However, as the CF specification
> grows and covers more types of data, no doubt we will see some of this.
>
> With regard to
>
> Conventions = "CF-1.4, XBT-1.0"
>
> I'd ask, what semantics does "XBT-1.0" imply that "CF-1.4" doesnt ?
> Because something not in CF means that its not interoperable with CF
> clients.
>
> We are doing something like this for OceanSITES, and yes, the
> extra information in the Conventions attribute is important to us.
>
> The files are CF compliant, so 'CF-1.4' in this attribute tells the
> user he can use any code that reads CF to read them. The
> 'OceanSITES 1.1' in the attribute tells the user about some additional
> restrictions and assumptions he can make.
>
> For better or worse, we hard-wire some features (e.g. reference date),
> and add some restrictions (e.g. units) , in order to simplify the code
> that
> reads these files. This makes NetCDF a little less daunting for people
> who haven't used it before, or who might find its flexibility a problem
> rather than a feature.
>
> - Nan
--
*******************************************************
* Nan Galbraith (508) 289-2444 *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 *
*******************************************************
Received on Tue Sep 01 2009 - 07:46:56 BST
