NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Roy and Ron, Much of the earlier discussion was spawned by AGU talks by Andrew Woolf (on CSML "scientific feature types") and Simon Cox (on sampling feature classes -- among many other things). These bear a strong resemblance to John Caron's Common Data Model "scientific data types." For me, the use case that really makes this interesting is the collections of point/station observations over time that are common in atmospheric science (weather stations), oceanography (buoys, etc.), and hydrology (river gaging stations). It should be noted that work is currently underway to provide netCDF conventions for such observations. See: http://www.unidata.ucar.edu/software/netcdf-java/formats/UnidataObsConvention.html Assuming the simplest case of a fixed set of observing stations taking measurements over time, one can argue that those are classic examples of "traditional" point FEATURES. On the other hand, if you view the collection as a whole as a "dataset," it has many similarities to the gridded datasets we normally think of as COVERAGES. It's just that, for the station observation collections, the locations of the points are completely irregular and are specified in a table of some sort rather than via a geometric algorithm or an indexed vector. Given such an observation convention for netCDF, this becomes an important issue in GALEON. Should such collections of station observations be delivered as coverages? Or should they be delivered via WFS or SOS? My answer to those questions is an emphatic "yes!" In other words, I don't see it as an either/or question. If the datasets are available via all three protocols, then the clients for all those protocols have access to the data. Moreover, from the server side, if we at Unidata use the THREDDS Data Server to provide the data as netCDF-encoded coverages via WCS, the experts in WFS and SOS can provide services that transform those datasets into the appropriate form for their client community. Using web services and standards in this manner, it means we can all focus on the components where we have the expertise. Isn't that the idea behind web services interoperability? -- Ben On 5/8/07, Ron Lake <rlake@xxxxxxxxxxxxx> wrote:
HI Roy: I would say you are both "right" You are thinking of feature as a vector object - this is not the definition in the OGC nor in the ISO. I think we need a word for this vector feature or conventional feature - but we currently don't have one. Feature in OGC and ISO means the object of interest in the domain. It is in this sense that a coverage is a feature. Now in the sense of features as vector objects (the more restricted meaning you are using) one might have properties which are coverage valued or which varying over some geometry of the feature. Cheers Ron
galeon archives: