Actually, this reminded me of a few things about netCDF import in DX from many years ago:
1. There is some support of metadata import (attributes in both the DX and netCDF sense), but it is limited. There is more in CDF import, for example. This is an area that if someone is interested could use enhancement. In particular, there are some conventions that have been established among different sets of netCDF users for metdata to help with data exchange and applications building.. A netCDF following that convention can be dentified by having the global attribute, "Conventions" with the value of "COARDS", for example. These conventions are essentially semantics for higher-order constructs beyond multi-dimensional arrays, which are handled natively within DX. Thus, it's a clear match. Essentially, there is a mechanism to describe coordinates/mesh as a product specification (e.g., lat, lon, pressure), fill and missing values, array ordering, time, units, etc. Currently, Import can read such a netCDF, but cannot associate the positions information with the data, and the attributes are not Import'd at all. If one looks at the netCDF independently of DX, one can extract the metadata and construct the fields appropriately by hand (or by writing a custom program or script which can imports the information separately). Unidata, the purveyor of netCDF, maintains a repository of such conventions. Since DX has a useful set of netCDF conventions, they can be included in this repository by simply supporting the global "Conventions" attribute with a value of "DX". Once this is done, Unidata should be contacted. so they can reference the DX conventions for their users. They do point to OpenDX for their users currently. 2. Along the lines of 1., being able to import netCDF attributes without the data would be useful to create metadata-driven applications with the overhead of reading data. 3. netCDF import was designed around a nearly-decade-old version. There has been some enhancement since from Unidata. 4. netCDFs often go by the extension of .nc or occasionally .ncdf, but the former is the preferred one. Import doesn't know about that extension. 5. There was a bug reported in netCDF import that it duplicates positions, connections and neighbors in groups. I don't know if it was ever fixed, but it sounds like the problem that was reported earlier this week. Chris Pelkie <[EMAIL PROTECTED]>@opendx.watson.ibm.com on 07/18/2001 07:29:51 AM Please respond to [email protected] Sent by: [EMAIL PROTECTED] To: [email protected] cc: Subject: Re: [opendx-dev] netCDF import of time series data I don't used netCDF so won't be looking at the patch (which does come through to me), but a thought. DX supports an arbitrary number of almost arbitrarily named attributes per object (like a series group, or each field, etc.). ("almost" as there are a few keyword attributes). So you might consider creating a metadata set instead of truncating. The first attribute would declare the number of attributes to follow, then as many as you need to transfer the needed info from netCDF to DX. You can retrieve these within DX with the Attribute module for display. Your decision on how to cut the long string up. Chris Pelkie Vice President/Scientific Visualization Producer Conceptual Reality Presentations, Inc. 30 West Meadow Drive Ithaca, NY 14850 [EMAIL PROTECTED]
