NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
All,Jon has done an excellent job of expressing the fundamental concerns that I also see. I ask your indulgence at for tossing yet-more radical ideas into the ring.
It remains imperative that our "fluid earth science" community continue to explore all useful angles of connection with the OGC community. The contributions that GALEON has already made in this regard are enormous, and from all that I have observed are very broadly recognized and appreciated. For myself, I cannot thank you enough. Finding this much time and energy to devote to community standards while also meeting "day job" demands is extraordinary.
I would like to pose this question: is GALEON at a point where it should take stock, re-evaluate goals, and possibly make a significant course change? That is a very hard thing for an individual to do, and a much harder thing for an organization to do. With the WCS 1.2 "core plus extensions" approach, we have effectively seen the broader OGC community reject involvement in the level of complexity that our community requires in order to conduct its internal business. As Jon says, arguably the central goal of GALEON _*was*_ to explore WCS as an OGC-accepted vehicle for interoperability *between* our community and others. It is not clear that embedding netCDF into WCS any longer holds promise of contributing to that goal.
If this interpretation of recent decisions is correct, then how should we adapt? What approaches will best meet our community's needs? With the combination of netCDF, CF, and OPeNDAP we have a powerful and effective vehicle for interoperability that has already gained quite broad acceptance within much of our community. The use of OGC-accepted solutions is, however, mandated for many of our partners, and that has created a schism. A true fusion of OPeNDAP and OGC could mend that schism and lead to a huge interoperability success story for our community. How can we best blend the virtues of netCDF/CF/OPeNDAP with the OGC process? Is there work that GALEON could pursue to "bless" OPeNDAP transport under an OGC/WCS banner? Can we envision, for example, a community extension to WCS that returns an unconstrained OPeNDAP URL as the payload of a WCS data request? This would essentially provide an OGC-accepted segue from WCS into OPeNDAP. With relatively minor effort at relinking, any application that can read netCDF can read OPeNDAP, so this is not far from what GALEON is currently exploring using netCDF-CF files as a WCS payload.
And how to approach interoperability with users outside of our own community? Jon's suggestion of "the WCS specification considerably simplified" seems very sensible. And this approach would dovetail well with the recent work on server-side regridding through OPeNDAP. It is easy to envision OPeNDAP servers as gateways -- providing simple lat-long versions of our gridded data that are then formatted as geoTIFF files and delivered through the simplest WCS syntax.
2 cents (or maybe 4) - Steve ============================================= Jon Blower wrote:
Dear Stefano and Galeon participants, Thanks for putting together a very valuable document, it must have been a lot of work! Mapping CF-NetCDF to WCS is clearly non-trivial. If I may, I'd like to step back a little and ask a couple of wider (perhaps philosophical) questions. I hope this is an appropriate place to do this - please let me know if not. I have always regarded the OGC standards as a way in which the met-ocean community can communicate its data to other communities. Personally I do not look to OGC standards for providing methods for exchanging data within our community. We already have well-established tools, standards, protocols, data models and software for doing this. When communicating outside ones own community, one often has to accept that a certain amount of information will be lost. I wonder if it is realistic to expect that we might use WCS in future to communicate our data in all its subtlety? My other concern is that the WCS world is changing extremely rapidly, with at least four versions of the specification in existence (1.0, 1.1, 1.2 and "plus"). This contrasts with the relatively small numbers of real WCS servers "out there" in the wild (GALEON has done a great job in encouraging people to stand up real systems but in general, uptake of WCS is rather low). The ISO19123 Coverage model is also likely to be revised as it is broken in places. Can we keep up with this evolution? Thirdly, the WCS1.2 "core plus extensions" model worries me a bit. I understand that the "core" is small, implying that the different community "extensions" will have little interoperability with each other. Effectively, we'll end up with a lot of mutually-incompatible versions of WCS that share some extremely limited features (perhaps only their terminology). The "core plus extensions" model implies that WCS has a desire to encompass all data, a scope that is arguably too wide to be useful or realistic. Personally I would like to see the WCS specification considerably simplified, with a defined list of things that it's good for and things that it isn't good for. For the sake of argument, let's imagine a WCS that only serves data as GeoTIFFs in a lat-lon coordinate reference system (or lat-lon-elevation-time in 4D). Sure, a lot of information would be lost across this interface (e.g. the original data's grid) and certain specialist use cases could not be satisfied (e.g. calculating heat transports). However, it would be much simpler to implement (client and server) and would still satisfy a large number of use cases in which met-ocean data is needed outside our community. I guess I'm saying that I don't think it's realistic or desirable to develop a WCS specification to serve all kinds of geographic data, which is the way things seem to be headed in the OGC world. The effort required to support a small number of specialist use cases (in the specification, in servers and in clients) is fearsome. I think WCS should aim to complement, not replace, technologies such as OPeNDAP by satisfying a different class of user. I think more clarity is needed about the use cases that WCS is thought to satisfy. Best regards, Jon
galeon archives: