I don't have more than a few minutes to comment.
I want to say that all the major analytical instrument vendors of
chromatography and mass spectrometry instruments have adopted netCDF
as the global standard for interchange among data systems, using their
own standard "conventions" for data element (netCDF variable) naming.
We are starting to apply it to many other analytical techniques now.
It works very well for our datasets.
In the absence of a public domain standard that can be configured to
support end user domain data models, using conventions it the best we can
hope for to achieve some level of semantic interoperability.
The analytical instrument vendors are quite pleased with conventions for
CDL templates. They use these to generate empty files and then use the
netCDF libraries to fill in the datasets. It works well for us.
I wish we had a mechanism beyond conventions for grouping multiple
netCDF file objects into more complex objects that could be mailed/copied
around the network (a directory type structure would be fine for now).
Tarring files together doesn't let you access what's in the files easily.
Does anyone have a better approach now?
That's all for now.
Rich Lysakowski
Analytical Data Interchange and Storage Standards
(ADISS) Project Director
======================================================================
From: DECWRL::"harry@xxxxxxxxxxxxxxxxxxxx" "Harry Edmon" 23-Oct-92 20:11
To: davidw@xxxxxxxx
CC: netcdfgroup@xxxxxxxxxxxxxxxx
Subj: Re: But will anyone use them?
>
> Hi all,
>
> After following much of this discussion on attribute conventions I am
> left wondering about something.... Many of these conventions would
> be a great idea if standardized. However, what good will they be if noone
> uses them?
>
> In my experience with netCDF data sets, I have NEVER seen a netCDF
> file created by a scientist type with Fortran code that has ANY
> attributes defined not even "UNITS" (computer scientist types working
> on netCDF packages excluded). There's just too many extra subroutine
> calls to do this to be bothered with by most users. (I'm not faulting
> netCDF here, its just that many people usually don't bother with
> attributes.)
>
> The only why I can see all these extra attributes being used is if the
> netCDF files are created by higher level packages that automatically
> add the extra metadata.
And I think one of the best ways to do this is to use "cdl" files and
ncgen to create the file framework (i.e. variables, attributes,
dimensions) and then use netCDF calls to fill in the variable values.
This is exactly how netCDF files are used to store NMC numerical model
results in the Unidata LDM software. It saves you having to make a
lot of netCDF calls, and actually makes it easier to change the netCDF
file definitions without large changes to the program.
--
Harry Edmon INTERNET: harry@xxxxxxxxxxxxxxxxxxxx
(206) 543-0547 UUCP: uw-beaver!atmos.washington.edu!harry
Dept of Atmospheric Sciences, AK-40
University of Washington
% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) =====
% Received: by enet-gw.pa.dec.com; id AA17235; Fri, 23 Oct 1992 17:10:38 -0700
% Received: by crl.dec.com; id AA00525; Fri, 23 Oct 1992 16:59:19 -0400
% Received: by unidata.ucar.edu id AA08795 (5.65c/IDA-1.4.4 for
netcdfgroup-send); Fri, 23 Oct 1992 14:23:52 -0600
% Received: from wet.atmos.washington.edu by unidata.ucar.edu with SMTP id
AA08791 (5.65c/IDA-1.4.4 for <netcdfgroup@xxxxxxxxxxxxxxxx>); Fri, 23 Oct 1992
14:23:51 -0600
% Organization: .
% Keywords: 199210232023.AA08791
% Received: by wet.atmos.washington.edu(5.65/UW-NDC Revision: 2.24 ) id
AA06612; Fri, 23 Oct 1992 13:23:45 -0700
% From: Harry Edmon <harry@xxxxxxxxxxxxxxxxxxxx>
% Message-Id: <9210232023.AA06612@xxxxxxxxxxxxxxxxxxxxxxxx>
% Subject: Re: But will anyone use them?
% To: davidw@xxxxxxxx
% Date: Fri, 23 Oct 1992 13:23:44 -0700 (PDT)
% Cc: netcdfgroup@xxxxxxxxxxxxxxxx
% In-Reply-To: <9210231900.AA19700@xxxxxxxxxxxxxxxxxxxx> from "davidw@xxxxxxxx"
at Oct 23, 1992 02:00:46 pm
% X-Mailer: ELM [version 2.4 PL3]
% Mime-Version: 1.0
% Content-Type: text/plain; charset=US-ASCII
% Content-Length: 1508
