[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 20050919: netCDF for cell-oriented data

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.

  • Subject: Re: 20050919: netCDF for cell-oriented data
  • Date: Mon, 19 Sep 2005 17:35:57 -0600
>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