Re: [wcsplus] [galeon] WCS 1.0 Plus philosophy and objectives

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.

See enclosed email/links.

John