Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
John, I see you're on ncdigest rather than the netcdfgroup mailing list, so you wouldn't see the appended posting until next Monday morning, since it doesn't get digested until later tonight. I'm taking the liberty of forwarding it to you today, since I think it might be of more immediate interest ... --Russ ======================================================================== Cc: Jonathan Gregory <jmgregory@xxxxxxxxxxx> Reply-to: russ@xxxxxxxxxxxxxxxx Hi, Independently of our recent discussion of netCDF coordinate conventions and the merits of "multidimensional coordinate variables" vs. "referential attributes", Jonathan Gregory, Bob Drach and Simon Tett have just published a draft of "Proposed netCDF conventions for climate data", available for review at http://www-pcmdi.llnl.gov/drach/netCDF.html or in PostScript form from http://www-pcmdi.llnl.gov/drach/netCDF.ps.Z This document extends the COARDS conventions, and in particular provides a good specification for the meaning and use of multidimensional coordinate variables. I've created a link to the document from the netCDF Conventions page at http://www.unidata.ucar.edu/packages/netcdf/conventions.html The authors have asked for feedback: Our principal interest in proposing this convention is to facilitate the exchange of data among climate centres. NetCDF offers an appropriate format for this purpose, and these conventions aim to standardise the representation of metadata sufficiently that data from different sources can be easily compared. We recognise that there are limits to what a standard can practically cover; we restrict ourselves to issues which we believe to be of common and frequent concern in the design of climate metadata. Our convention is mostly compatible with the existing COARDS convention, but we have extended the scope and detail. We are aware that some climate centres are already using netCDF as their archive format. We would be very interested to have comments from them, for instance on how our suggestions differ from what they do, and on what lessons they have learned from experience. We would welcome feedback from anyone on these conventions, such as on what has been omitted, what could be improved, and how we should carry this proposal forward. The exercise will only be useful if it has the support of a number of climate centres, of course. One application which will adopt this standard is the LATS software distributed by the Program for Climate Model Diagnosis and Intercomparison (PCMDI), sponsor of AMIP II. LATS will have an option to generate netCDF files which conform to this standard. Our second interest in developing this standard is its relation to a logical model of the data and metadata. Describing how the data should be stored in netCDF inevitably involves considering how it is organised logically. We hope to be make a proposal for a language-independent data model, which could be implemented in various programming languages as a method of handling data either in memory or in files. If this were done, it would offer a way of making analysis programs more easily portable. Please send any comments you may have on the proposed standard or any of the above to any of us. Feel free to circulate it further if you know others who would be interested. Thank you. Jonathan Gregory jmgregory@xxxxxxxxxxx Bob Drach drach@xxxxxxxx Simon Tett sfbtett@xxxxxxxxxxx --Russ _____________________________________________________________________ Russ Rew UCAR Unidata Program russ@xxxxxxxxxxxxxxxx http://www.unidata.ucar.edu ======================================================================== Hi, Among other interesting points, John Caron wrote: > The point is, until we can embed functions (methods) in our netcdf > files, we cant really represent the above formula in the way it is > written. What we can do now, however, is to compute the field > Pressure(x,y,z) and store it in the netcdf file, and it becomes a > perfectly good coordinate function for the "altitude" coordinate of a > georeferencing coordinate system. So the cost is that we have to store a > 3D field, when all the info is really available in 2 1D fields (a and b) > and 1 2D field (SurfacePressure). > > Which is just a long example to say that we currently have only arrays > to represent functions. This is one of the great promises of "executable content", using Java, for example. Data that is stored as an object can map itself to a canonical coordinate system using a data-specific method, or interpolate to return the data at a particular location and time. The necessary functions may be stored with the data as portable byte codes that could be loaded into a convenient Java Virtual Machine running where the data is used, or could reference a remote method that is transparently downloaded and executed when needed to transform the data. There is then no need for applications to support elaborate conventions for parameterizing dozens of coordinate systems. Instead, applications would assume a simple Interface (in the Java sense) for georeferencing the data, and the data Class would implement the Interface. But this requires something beyond netCDF. Unidata is planning to make available, with help from external developers, the interfaces necessary to make practical such a division of responsibilities between data and applications. In the meantime, well-designed conventions can limit the number of representations for coordinate systems that applications must understand. So, we have to get by with arrays until we have functions ... --Russ _____________________________________________________________________ Russ Rew UCAR Unidata Program russ@xxxxxxxxxxxxxxxx http://www.unidata.ucar.edu
netcdfgroup archives: