I am new to CF-netCDF as compared most people in the mailing list. As I
understand it, CF-netCDF should have no problem at all taking care of point
observation. The CF-netCDF uses two arrays, x and y, to indicate the
locations of a variable array. In regular grid case, both x and y arrays
are usually two dimensional. From example, for a grid data array whose
data cover longitude from -180 to +180 degrees at 1.0 degree resolution and
latitude from -90 to +90 degrees at 1 degree resolution, one can use two
ways to record the locations of the grid points. One is to use two 1D x
and y arrays with x=(-180, -179, ..., +180) and y=(-90, -89, ...,
+90). The other is a redundant way. That is, use 2D x and y arrays. Both
x and y arrays in this case will have 181 rows and 361 columns. The
redundant way is usually not needed because all values in the same column
in the 2D x array are the same and similarly all values in the same row in
the 2D y array are the same.
If a data grid array is irregular grid, or point observations, then it is
necessary to record each grid point's position in x and y arrays. This is
similar to the second (redundant) approach in the above example, except
that recording each point is not redundant but necessary in this case. For
example, for three temperature values measured at (lon,lat): (-100, 30),
(-90,31), and (-70,40), the x array is 1-dimensional and contains three
values (-100,-90,-70) and the y array contains three values (30,31,40). I
think that the satellite swath data is recorded in this way in
CF-netCDF. BTW, the coordinate system can be any kind of CRS supported by
the CF convention, not necessarily WGS84.
For data of three or more dimensions, additional coordinate axes such as
time and elevation (pressure) can be added. They will not affect the x and
y locations array in most cases, unless the (x,y) location changes at
different elevations (or times). In the later case, each data point at
different x, y, and z (and t) must be individually located in not only the
x/y space but also in z (and t) space.
The difficulty for the current WCS, which only supports regular grid, to
support point or irregular grid is that WCS uses bounding box and
resolution to declare its x/y spatial values. It is similar to the above
global 1-degree resolution example in that it records just the 181
longitude values and 91 latitude values, rather then the 2D redundant case
of recording each x/y values (181x361 pairs). In fact, WCS uses a more
compact form. That is, it does not even record (declare) the 181 y values
and 361 x values. Instead, it records (declares) the start and end x/y
values and the resolutions, i.e., x/y starts at lower corner of (-180,-90)
and ends at upper corner of (+180,+90) and resolutions are (1,1). This is
a bounding box plus resolution format. It is difficult to use this format
for irregular grid and point observations. I think that we can extend WCS
to cover irregular grid coverage or point observation by assuming that the
bounding box can be used to declare that a client needs all points located
in the bounding box. The current way of using bounding box is assuming
that grid values are available at each grid point from lower corner to
upper corner at interval of a resolution. In the above three-point grid
example, (-100, 30), (-90,31), and (-70,40), the lower corner is (-100,30)
and upper corner is (-70,40). There is no way to use resolutions because
the x/y intervals between the three points are different. Even if the
intervals are the same (e.g., the 2nd point is exactly in the middle
between the 1st and the 3rd points), using resolution will result in
declaring 3x3=9 data points but not just 3 data points. The easiest way
seems to allow the WCS interface to have a choice, either a bounding box
plus resolution for regular grid or a series of x/y pairs for irregular and
point grids.
Wenli
At 09:43 AM 11/1/2007, John Graybeal wrote:
Unless I am mistaken, there is already a project that is looking into this
from a CF standpoint, at least for a small segment: 'point observation'
data. I guess it doesn't hit the target directly, but I think some of the
discussions may be relevant.
