NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
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
-----Original Message----- From: galeon-bounces@xxxxxxxxxxxxxxxx on behalf of Jon Blower Sent: Wed 9/24/2008 8:14 AM To: Ben Domenico Cc: galeon@xxxxxxxxxxxxxxxx; Roy Mendelssohn; Steve Hankin Subject: Re: [galeon] WCS CF-netCDF profile document Hi Ben, The analogy with JPEG2000 and JPIP is a good one (although I'm not an expert either). My experience of applications that use JPIP streaming (e.g. accessing high-res satellite data from an Antarctic research ship with very low bandwidth) is that these applications depend upon the advanced features of the protocol to function correctly (e.g. to manage bandwidth). A WCS approach might effectively remove some of these features: a client doesn't know exactly how much data to expect in response to a request so it can't manage bandwidth. In other words, I see WCS as providing a common baseline, not as a protocol that attempts to support all of these features. Does anyone know how the JPEG2000/JPIP community feel about WCS?But my impression is that others think that we should abandon the CF-netCDF encoding spec. and ONLY be proposing CF-OPeNDAP. Is that the heart of the suggestion that's on the table in terms of the OPeNDAP part of the discussion?My personal opinion is that if I want to use the internet to access FES data losslessly, and my application understands the NetCDF data model and the CF conventions, I should use OPeNDAP as it gives me (very nearly) all the information I need and tools are readily available.* I see no need for WCS to satisfy this use case. If, on the other hand, I have a GIS application that has a map-based data model and understands GeoTIFFs, I might well want to access FES data through a WCS - but it's no good returning me a NetCDF file because I won't be able to understand it. Instead it would be much more useful to have a WCS that reads CF-NetCDF data and produces GeoTIFFs. A mapping of CF-NetCDF to WCS concepts is still necessary to understand how this mapping actually takes place - what information is preserved, what is lost and so forth. Best wishes, Jon * The issue of asynchronous access to large-volume data still needs to be solved however... The WCSplus team are experimenting with asynchronous access and OPeNDAP doesn't support this. However, I think there's an OPeNDAP working group addressing this. This one is still up in the air.
galeon archives: