NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hi all, This thread has been one of the most fun and informative GALEON discussions for me to date. But because it has covered so many important topics, I fear we may some of them may fall through the cracks in the wide-ranging conversation. So here's my attempt at the short list of key topics that would benefit from continued discussion -- probably in separate threads: 1. WCS-netCDF extension standard. As the subject of the email indicates, the main topic that got this going is the WCS CF-netCDF profile document. As I see it, the main issue here is how to incorporate an OPeNDAP option. I sense agreement that there should be an OPeNDAP option in WCS, but it could be done in terms of a small addition to the proposed CF-netCDF extension standard or it could be done as a separate extension spec that leverages and builds on the CF-netCDF proposal. To me, this is still the top priority issue and it would be good if it could be resolved so the resulting WCS extension standard(s?) can be formally submitted to the WCS1.2.SWG before the next OGC TC meeting which is the first week in December. 2. Non-gridded coverages. The issue here is what we do in both the CF community AND the OGC community about the types of data that do not fit the current WCS definition of regular grids. This includes the types of datasets (and collections thereof) that have been listed and discussed as CDM (Common Data Model) scientific data types and as CSML scientific feature types. I put this as the second highest priority because it encompasses important work for both communities: -- the CF community must extend the conventions to include these data types -- with special care to explicitly Coordinate Reference System (CRS) information whereas -- the OGC community has to come to grips the fact that these data types can be seen as features and/or coverages and that some harmonization -- or at least better understanding -- is needed among alternative delivery protocols (WFS, WCS, SOS, WMS?). I'd will attempt to spawn separate discussions of these issues because the CF work should be undertaken sooner rather than later and the OGC issues are on the agenda for the December TC meeting in a special joint session the afternoon of Monday Dec. 1. 3. WCS Core and Extensions. A couple topics have come up here. One is the more general question of whether there is anything in the current WCS 1.2 draft that prevents the GALEON community from addressing its standardization needs in the extension standard(s) for CF-neCDF (with an OPeNDAP option either as a part of the CF-netCDF extension or as a separate extension standard built on the CF-netCDF foundation). The second issue that came up in the email discussion is more specific: namely whether having the WCS 1.2 core include only 2D coverages is an obstacle to the service of 4D FES (metocean) data to the traditional GIS community. In this regard, it has been noted that, while the current draft WCS 1.2 core spec allows clients to be compliant even though they cannot work with 3D or 4D datasets, forcing those clients to deal with a 4D WCS would not mean that they would be able to analyze and display those datasets. On the other hand, any client developer whose user community is interest in GALEON 4D datasets would implement the CF-netCDF extension. I plan to start a separate email discussion on this topic to give people a chance to respond to my obvious prejudice. 4. The Need for Catalog Services. This was really only touched on in the discussion thread, but I think it warrants an item in this list because the discussion of a wider variety of data types along with the possibility of multiple access protocols (WMS, WCS, SOS) places additional emphasis on the importance of standards-based catalog services (CS-W) which was one of the issues that the GALEON phase 1 brought out. Getting CS-W discovery systems working together with WCS (or other OGC) access systems is a substantial interoperability challenge when the clients and servers are developed independently. This item is mainly just a reminder that more thought and experimentation is needed in this area. Please speak up if I've missed important issues in this list. -- Ben Wright, Bruce wrote:
Hi Peter, I think this 'features vs. coverages' (or WFS vs. WCS) is an interesting issue; I've seen a number of different, but not necessarily exclusive, viewpoints: 1. Coverages and features are different...WFS and WCS evolved as two distinct services to meet different requirements for accessing data and metadata. 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. 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. 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!) 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!). Regards, Bruce
galeon archives: