NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Just one note, quickly added: Wright, Bruce wrote:
1. Coverages and features are different...WFS and WCS evolved as two distinct services to meet different requirements for accessing data and metadata.
this is past and presence, IMHO.
2. A coverage is a feature...features and coverages are different 'cross-sections' through the information - Simon Cox presents this nicely by considering the information as tabular, with a row represents a feature (a series of individual property values) and a column representing a coverage (different values of the same property) - and the WFS and WCS should be harmonised.
hm, that seems like adding a third, radically new concept to unify the two others. Why not simply say "a coverage is a feature which enjoys special treatment, as laid down in the WCS".
3. A feature is a coverage...coverages are already effectively being encoded in GML for some WFS requests that need to return the variation of a set of parameters over space/time (normally small data volumes); again, this suggests that the WFS and WCS should be harmonised.
well, I have nothing against GML as one _additional_ data format (and a proof that something is possible). All the mapping people I have talked to, however, want to first webify their vector material and then their rasters - current practice, alas, has made WFS the first-born son ;-)
4. Coverage is a property of a feature... WCS is a convenience interface, which should eventually replaced by an enhanced WFS, which adds a GetCoverage request (or an OPeNDAP request!)
oops, that sounds complex - just a property (aka attribute) of a feature? We might adopt #2 and come to the same conclusion.
Personally, I think these are all true to some extent (not sure 3. above is a good thing though!). However, which viewpoint you take determines how you develop and implement these web services going forward (e.g. my explicit 'conclusion' on 4. above!).
I very much agree, this is determined by history and current practice. Nice discussion! nite, Peter
galeon archives: