NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hi Steve, Steve Hankin wrote:
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 technologiesHi 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.
Good point. I had forgotten about the European WCS angle.
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. 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.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 aremote host through OPeNDAP (with a relinking of the code at most). Bringing netCDF and OPeNDAP together (under a WCS umbrella orelsewhere) 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 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.
The desire and need to read a NetCDF file does not imply interest in using the OpenDAP protocol. While in practice they have frequently been used together, reading a NetCDF file is different than making an OpenDAP request. I can tell you unequivocally that I will be reading NetCDF files from a WCS server, but I will not be making OpenDAP requests. Why make a specification that joins both? OpenDAP is a protocol stack on top of NetCDF. I could see building an OpenDAP extension profile on topof the NetCDF one, but to me the two are logically separate things. There are a host of NetCDF utilities that can read NetCDF files but
cannot deal with OpenDAP URLs. I can see both sides of this argument to some degree, especially if one is trying to minimize the work of standardization. Perhaps it is from my experience with the OGC standards process, but overall I do prefer to segregate logically separate entities when generating specifications rather than generating a bigger document and telling people to ignore the parts that don't apply to them.
galeon archives: