NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Aaron Braeckel wrote:
IMHO OpenDAP and WCS should be kept largely separate. As stated elsewhere, the intra-community needs are largely being met with existing technologies
Hi Aaron,I'm afraid that this statement over-simplifies the situation. Our European colleagues ARE (emphatically) part of our community. But many of them feel that they are mandated to use only OGC-accepted solutions. So we have a well-defined barrier to intra-community data exchange that is in need of a solution: one part of the community using OPeNDAP and another part using WCS. Bringing WCS and OPeNDAP together by carrying an OPeNDAP URL as a payload in WCS is a remarkably simple and elegant solution to this problem.
and the real strength of WCS is the broader community. Standards are always riding a fine balance between flexibility and standardization, and sacrifices are made to balance on that line.My apologies, but I cannot see the logic of this argument. NetCDF and OPeNDAP in fact already are very closely coupled and have been so for many years. Basically (only a slight over-simplification) any application that can read a netCDF file can read the same data from a remote host through OPeNDAP (with a relinking of the code at most). Bringing netCDF and OPeNDAP together (under a WCS umbrella or elsewhere) does not mandate that both are used by any given community. If you have reasons to want to avoid the use of OPeNDAP in your community you can achieve that goal by simply ignoring it.I would also like to see that NetCDF and OpenDAP be kept separate, as there are communities of use (including my group) that want to work with NetCDF but not OpenDAP. Therefore I'm not in favor of a joint NetCDF and OpenDAP extension profile.
I think it is worth examining the deeper issues of where data interoperability barriers come from. It is that we have too many, narrowly defined standards that cannot talk to one another -- netCDF-CF, HDF-EOS, geoTIFF, shapefiles, tab-delimited format description or what have you. Community stovepipes. The heart and sole of the interoperability effort has to be doing the work necessary to make standards inter-operate.
The "core plus extensions" philosophy of WCS is fundamentally weak, in that it solves only the problem of metadata interoperability, data interoperability remains a collection of stovepipes. Your concerns above reflect an inevitable consequence that this weakness of WCS has on clients -- client software must become more complex in order to address interoperability. Unfortunately this aspect of WCS is a given -- it is out of our scope to change it.
- Steve
galeon archives: