NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hi Norman, Thanks very much indeed for this. A penny has just dropped in my mind thanks to your email (and Ben's emails before it). I had always seen WCS as a data subsetting service (with getCoverage() being the most important method). I was struggling to see its value, given that we already have a data subsetting service for NetCDF and many other file formats (i.e. OPeNDAP). *However*, if we see WCS primarily as a mechanism for exposing coverage *metadata* in a standard way (with describeCoverage() being the most important method) then things start making a lot more sense to me. Coverages are described, harvested and then discovered. The process of discovery reveals a method for grabbing actual data. If the client understands this method (which could be OPeNDAP or a JPIP stream) then data transfer can take place. The WCS-NetCDF mapping is then needed to show how NetCDF coverages can be described. Have I understood this correctly? If I've understood this correctly, there are a few implications: 1) There are now two methods for getting data, the in-band getCoverage() and the out-of-band community protocol (OPeNDAP or JPIP). Perhaps getCoverage() is the fallback method providing data subsets as self-contained files and the community protocol gives specialist features (e.g. streaming, bandwidth management)? 2) We need a MIME type for an OPeNDAP endpoint (analogous to application/x-jpip-xml or whatever)? (Perhaps there is one already.) Assuming, that is, that the MIME type is the basis for establishing whether the client and server can exchange data. 3) The output of the describeCoverage() operation should be (at least partly) comprehensible to all WCS clients. That is to say, the extension model can't change this operation so much that its output is totally community-specific. 4) I was just about to write about transferring data as streams versus standalone file objects but Roy has beaten me to it. Anyway, we clearly need to address the "large data" problem and the scalability of servers. Cheers, Jon On Wed, Sep 24, 2008 at 3:43 PM, Norman Barker <nbarker@xxxxxxxxxx> wrote:
Jon, as it happens I am now the editor of the jpip extension for WCS (and am no longer in the UK either!) :-) JPIP is just a protocol, OPeNDAP is just a protocol, current thinking (from Max Martinez - Erdas, Steven Keans - PCI) and others is that the protocol is not so important, the WCS returns an identified mime type that indicates the protocol being used, so in the case of jpip this is image/jpp-stream (well I think they are leaning towards application/x-jpip-xml). The fact that JPIP manages the bandwidth does not enhance the coverage encoding, they are unrelated. The describecoverage etc. are useful operations for generic wcs clients and particularly for harvesting. To me this is very similar to an ebRIM catalog, where you register an object with the catalog and then associate access protocol with this piece of metadata. It certainly moves the focus away from the access protocol (traditional wcs, opendap, jpip etc.) to the coverage encoding which is netCDF, jpeg2000 etc. I think Max made a good comment in one of the RWG meetings where he said if the protocol does not add to the coverage encoding then the extension document is just acknowledgment of the protocol (paraphrased) so in the JPIP extension for WCS I could just reference the ISO standard. However in this document we make many clarifications, and explain the geographic to Cartesian mapping so it is a bit more involved than that. Does this clarify things, if not happy to contribute some more. Norman
galeon archives: