Re: [galeon] WCS CF-netCDF profile document

NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.

Hi all,
Many important topics have come up in these discussions. In this note, I'm
going to try to confine my remarks to the OPeNDAP question.

Within the WCS, the JPEG2000 community has proposed both a JPEG2000
extension standard and one for JPIP.  I am not an expert on JPEG or JPIP but
my understanding is that JPEG2000 is similar to our CF-netCDF extension in
that it is an encoding specification whereas JPIP is actually an access
protocol and as such it is similar to OPeNDAP.  I had been thinking of that
dual approach as a model for what we might eventually do for netCDF and
OPeNDAP in the WCS world.

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?

-- Ben

On Wed, Sep 24, 2008 at 4:57 AM, Jon Blower <j.d.blower@xxxxxxxxxxxxx>wrote:

Hi Ben,

The idea is that, with CF-netCDF as a WCS extension standard, any group that
wants access to our FES (or metocean) data will have a standard,
carefully-defined interface through which to access that data.  The fact
that it won't be part of the core is irrelevant.

I don't really see the difference between using (say) OPeNDAP and
using an "extended" WCS.  Both are likely to be foreign to a user that
only understands "core" WCS.  I admit that an extended WCS is likely
to be closer to core WCS than OPeNDAP is.  But OPeNDAP has a massive
head start in terms of tooling, so the actual effort required to talk
to an OPeNDAP server is not likely to be any greater than the effort
required to talk to an extended WCS (in fact, I think talking to
OPeNDAP will be considerably easier).  I cite as an example Roy's
Environmental Data Connector which reads data from THREDDS servers
(via OPeNDAP) into ArcGIS.  It works, it already exists, and it does
the job (apparently anyway, I haven't tried it myself! ;-).

To emphasize the point, I'll call your attention to the fact that no
encoding formats will be part of the WCS core.  They will all be extensions.

OK - but I'd like to explore this a little.  The purpose of a standard
is to reduce the total amount of code that needs to be developed and
tested.  To get data from any kind of web service a client has to (1)
formulate a request, and (2) understand the response.  If the request
syntax and semantics are always the same (in WCS core and all
extensions) then we can save money by reusing the code needed to
formulate the request.  However, if the extensions define a modified
syntax or semantics, we have to develop new code for each extension.
I'm ignorant here - do you think that the request syntax will be
modified by WCS extensions?

In terms of understanding the response (2) the core-plus-extension
model hasn't helped at all.  Every client will need the means to
understand the file format coming from the extension in question - we
are unable to reuse any code.  (Also, note that if a client has the
means to understand a NetCDF file, it probably also has the means to
talk to OPeNDAP.)

WMS has been (relatively) successful partly because it's an easier
problem, but I would argue that a large part of its success is down to
the fact that there are a smallish number of very widely-used image
formats (PNG, GIF, JPEG) that almost everyone can interpret.  In other
words, the interoperability is largely enabled by its adoption of
standard output formats.  The same can't be said of WCS and this
worries me a bit.  Formulating the request isn't usually the hard part
- it's usually much harder to understand a new file format (in my
experience).

I should conclude by stating that none of this is a criticism of
Galeon - in fact, without Galeon we wouldn't be able to have any kind
of informed conversation about this.  I am more worried about the WCS
world in general.

Best wishes,
Jon



  • 2008 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the galeon archives: