NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hi Jon, Steve, Stefano, John et al., This is a very interesting discussion that the WCS CF-netCDF profile document and the GO-ESSP meeting had triggered! Looking at the two suggestions below for the use of OPeNDAP with WCS, I would suggest that the second is cleaner and simpler. In effect, this adds OPeNDAP as extra operation (in addition to GetCapabilities, DescribeCoverage and GetCoverage), and keeps the details of the GetCoverage request completely separate. This picks up on a theme discussed earlier, which was that one of the key benefits of the WCS was the metadata capability...whilst OPeNDAP provides a powerful but fairly straightforward data access 'request format'. It does mean that the client has to generate all the 'subsetting constraints', but... Using GetCoverage to return an OPeNDAP URL implies that the server has to map the WCS GetCoverage arguments (e.g. BBOX, CRS, INTERPOLATION, FORMAT, etc) onto the OPeNDAP constraints. Our experience (at the Met Office) trying to map WFS filtering arguments onto an OPeNDAP call (a similar issues) suggest that this is not likely to be straightforward and that you may loose the benefits of the two approaches due to mismatches in capability. On a related matter, is there a version of the WCS extension for JPIP available for viewing? - it would be nice to see how OPeNDAP might be handled. Regards, Bruce
-----Original Message----- From: galeon-bounces@xxxxxxxxxxxxxxxx [mailto:galeon-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Jon Blower Sent: 29 September 2008 10:43 To: Steve Hankin Cc: Unidata GALEON Subject: Re: [galeon] WCS CF-netCDF profile document Hi Steve, Stefano, John et al., This looks like a good starting point for harmonization. John Caron described one method of bridging between WCS and OPeNDAP: 1) Client discovers Coverage somehow 2) Client gets description of coverage via DescribeCoverage() 3) Client calls GetCoverage() 4) Server returns OPeNDAP URL to the result Another alternative (to complement, not replace, the above) might be to bypass GetCoverage() altogether: 1) Client discovers Coverage somehow 2) Client gets description of coverage via DescribeCoverage(). Description includes OPeNDAP URL to entire Coverage. 3) Client opts to use OPeNDAP to access subsets, without calling GetCoverage() at all. A client might choose this so that it can access more precise subsets, accepting the extra complexity. What do others think of this? Cheers, Jon
galeon archives: