This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>To: address@hidden >cc: address@hidden >From: Beth Ebert <address@hidden> >Subject: netCDF for cell-oriented data >Organization: UCAR/Unidata >Keywords: 200509191129.j8JBTvnX027301 Hi Beth, > My name is Beth Ebert and I am a research scientist at the Bureau of > Meteorology Research Centre in Melbourne, Australia. I am involved in a > nowcasting project that involves representing forecast data in several > spatial forms: > > 1. Grids (easy!) > 2. Cells (center lat/lon, ellipse axes, cell speed and direction, > intensity, etc.) - these are "blobs" or "objects" on a map > 3. Threat areas (polygons) > 4. Points (also easy!) > > We are trying to decide on a format that is flexible enough to handle all > of these types of data. Various formats have been suggested, including > netCDF, XML, and BUFR. I am wondering whether netCDF format has been used > to represent cell or area data, and if so, if you might be able to point > me to an example of this. If you aren't aware of any examples of these, > would you forsee any problems with using netCDF to represent cells and/or > areas? We already use netCDF at the Bureau for our gridded NWP model > output. You might want to look at the CF Conventions chapter on "Data Representative of Cells": http://www.cgd.ucar.edu/cms/eaton/cf-metadata/CF-1.0.html#int Although it refers to rectangular cells in a grid, much of the description can be generalized to cells of other shapes, such as elliptical. For example, the discussion of "Cell measures" includes specification of a "cell_measures" attribute that can name a "cell_area" variable, as in the example provided in that section. For polygon representations, you might consider storing vertices in a large array "heap" containing lists of vertices for each polygon, with a separate variable that contains an index in the heap for the first vertex of each polygon. You might also consider using linked lists in a way similar to the conventions John Caron has developed for representing "soundings", which can have a variable number of variable-length lists of data, much like polygons: http://www.unidata.ucar.edu/software/netcdf-java/formats/RecordsInNetcdf3.html If none of these work for you, another possibility is using HDF5 instead of netCDF. HDF5 has a more general and powerful data model with "vlens", which is a type of variable-length data. Or wait until early next year, when our netCDF-4 software will be available that uses HDF5 storage in support of a netCDF-like API. --Russ