NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
[NOTE: I'm just catching up on this thread, so this response my be a little redundant or out of step with others] I feel that Ron's earlier email was correct and important: a Feature can have some properties that are constant for the entire feature, while other properties may be spatially or temporally dependent, or dependent on some other axis other than time or space (e.g. spectral wavelength). The idea that there are Features and there are Coverages (or even that there are Coverage Features and Vector Features) is a superficial distinction that has resulted in separate formats and separate services within OGC. Over and over, we have found that this division is very fuzzy and not very useful when we're are trying to obtain interoperability of data. The SWE efforts, encodings, and services highlight that this distinction is false and early attempts in SWE to try to preserve the distinction only led to confusion and clumsy encodings. In SWE we recognize that most of the data that we deal with ultimately originated from observations ... they may have resulted from an insitu sensor that measures one or more observable properties over time while sitting stationary at one location .... they may have resulted from a scanner on a satellite with a rotating mirror that sweeps around taking essentially individual measurements of radiation intensity at multiple spectral frequencies during the sweep while the spacecraft moves along ... they may result from an imager that captures collects individual radiation intensity values on a CCD grid simultaneously ... or they may result from a process (or model) that takes individual measurements and regrids these values according to some spatial-temporal domain or perhaps calculates new observable property values along some regular spatial grid based on some mathematical relationship. The point is these are all really individual measurements that we sometimes perceive as coverages because of spatial, temporal, or spectral patterns that result from the sampling characteristics of the sensor system orpost-measurement process.
Let's take for example a measurement of the atmospheric conditions at a weather station: (1) First, I want to know the conditions right now at that station: so I should expect to get back a data "chunk" (to use a word that doesn't perhaps convey a predefined image) with single values for temperature, pressure, wind speed, ..., latitude, longitude, and altitude, perhaps. In our traditional OGC/ISO mentality we would have no problem thinking of this as a Feature. (2) Next I want to know what the temperature was over the last 12 hours, so I get back data with perhaps a collection of time, temperature pairs, but a single location perhaps because the station hasn't moved. OK, in traditional OGC/ISO mentality, we maybe start to see this as a Coverage through time, or maybe as a Feature with a time-dependent property with a location that's fixed. (3) Now, I have a weather station that is actually mounted on a car involved in storm chasing, so when I want temperature over the last 2 hours, I get back a data chunk where I receive perhaps several tuples that have time (from an onboard clock), latitude, longitude, and altitude (from an on-board GPS) , and temperature from the weather station. Now we start to see some more complications because location is not really some separate metadata about the station, or some definition of a grid ... it is really a measurement itself, just like temperature and time. In traditional OGC/ISO mentality, we struggle a little seeing these Coverages or Features but along a line geometry with a "special" linear coordinate system. (4) Now I have a collection of weather stations scattered around an area and I want the current temperature. Good, back to something that makes sense. Many with traditional "Feature mentality" would see this as a Feature Collection where each Feature has a set property of locaation; "Coverage-oriented" people would see this as a temperature Coverage with an irregular grid. In SWE, we would still see this as a spatially and temporally dependent set of temperature measurements. (5) Finally, I have a process that takes an irregular array of weather measurements and regrids these into a "regular" spatial grid at equal time slices ... ah, finally something that feels like a true gridded Coverage ... but is it really any different form the other cases? So, one question I have ... do we really want to try to have different data formats and different services for these different cases. Do we really want to have to decide that case 1 is a Feature that should be served as GML from a WFS and that case 2 is a coverage that should be packaged in NetCDF and served from a WCS? I could have done a similar breakdown of cases for remote sensors whose products have traditionally fallen under the Cover umbrella. Both looking at a scanner output, it is really just a collection of measurements through time that have no spatial grid component until a sensor model is applied. I may not even be interested in spatial coverage, but rather the spectral response at a given location. We/OGC/ISO needs a better data model. I know that many of you have already been thinking outside of the traditional boxes, but perhaps breaking this illusion of a distinction between features, vectors, grids, and coverages isa good start.
In SWE we have tried to avoid some of the issues by recognizing that all of these (time, location, temperature, etc.) are essentially "equal-partner" observed properties or measurements (whether coming directly from a sensor or through a process). We have also allowed measurements of location and time to be included as part of the the tuples along with other observed properties (e.g. temperature). We do, however, also support the ability to provide location of an Observation within the Feature of Interest, by providing either a single location, a location model (e.g. a grid), or a SensorML process. One last point is that I think the separation of Features into GML and Coverages into formats such as GeoTiff, HDF,and NetCDF have been centered around the need for highly efficient storage mechanism for coverages. I truly feel that the approach taken with SWE Common data definitions provides the best of both worlds: to have the machine understandable, robust description of data provided by XML/GML and to allow the packaging of large amounts of data values in efficient ascii or binary blocks (or streams). Sorry I got carried away here. Thanks. Mike Botts
galeon archives: