NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
This is a multi-part message in MIME format. While there are many different understandings/view points/etc of feature and coverage, I would like to point out that the main reason for "coverage" service is to provide "GRID coverage" whose data values are "regularly" aligned with some axes/dimensions so that one can specify low/up limits and an interval along each axis/dimension and get an array of (many) coverage data points. By "regularly" I mean that the coverage data points have the same interval along each axis/dimension. If an axis is a well defined coordinate axis, such as geographic longitude, then the data points are said to be rectified along this axis. If an axis is something like a satellite track, the data points may still be considered rectified along this axis, but since a satellite track usually does not align with any geographic/projected coordinate axis, the data points are thus usually considered un-rectified (with regard to well defined earth coordinate reference systems). Whether rectified or not, a grid coverage data is a n-D data array with all data points having the same data type. In case a coverage contains multiple "range sets" such as temperature, humidity, and land surface type, a coverage will have multiple arrays each having the same data type. This well maps to the variable array(s) in a netCDF file.This spatial (or geometry) property of coverage is fundamentally different from most feature types. I consider a road feature a typical feature type. To describe a road feature, we usually use discrete pairs of coordinates (x,y) to indicate its spatial location and use attribute values such as pavement type, route number, and road width. The attributes may or may not have the same data type and a feature usually has relatively fewer values for each attribute as compared to data point values in a grid coverage's range set. The data structure of a feature is thus usually different from a grid coverage.
Due to such major differences, it is inevitable that WCS interface will be different from WFS interface. There are, of course, cases where feature and grid coverage are more similar, such as John Blower's point time series profile case. When considered as a grid coverage, it has only 1-dimension and the intervals of data points along this dimension may often be irregular (e.g., 50mb, 100mb, 200mb). When considered as a feature, the data structure can be equally efficient. However, in general n-D (n>1) cases, I there are significant differences among WCS (for GRID or rater type) and WFS (for vector data type). -- Wenli
Hi Ben & Jon & all, interesting to notice that your community requires coverage types beyond what's listed in ISO 19123. This nicely coincides with the general feeling that ISO 19123 (== OGC Abstract Spec Topic 6) deserves an update - we might bring in your types on that occasion. The best way for this probably would be if someone wrote a change request to add a section about this your new coverage type. The WCS group certainly is more than open to have a close look at such a description. -Peter
galeon archives: