NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Dear Jon, Thank you for the valuable and stimulating comments.I am in serious agreement with several of the points you touched. I particularly agree that "more clarity is needed about the use cases that WCS is thought to satisfy". As matter of fact, Ben and I are working on a position paper with the temporary title: "Which coverage access services do we really need ?".
For me, the Web Coverage Service(s) is/are important for enabling cross-disciplinary interoperability.
IMHO, this extension profile draft contributes to clarify this question. In fact, mapping CF-NetCDF to WCS data model should provide a useful indication of the complexity and rewards that we are going to face. In fact, this exercise was done to support interoperability and cross-disciplinary research/applications. This is important to enable the CF-netCDF use in multi-disciplinary contexts.
From my perspective, WCS 1.1.x is a rather complex specification; it will be replaced by WCS 1.2 which is trying to solve the complexity problems. Thus, this extension specification must be considered as propedeutic for the WCS 1.2 CF-netCDF extension.
I will try to provide more discussion points inline.
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?
Due to multiple Community specifications and conventions, I think that a certain amount of information is often lost even when communicating inside ones own community. In my opinion, the real question is about the interoperability level required by applications to run.
For example, GEOSS is working on cross-disciplinary applications for serving many SBAs (Societal Benefit Areas); in this case, what is the exact meaning of "communicating outside ones Community"?
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?
I completely share your concerns. I made similar comments to the WCS RWG.In my opinion, ISO 19123 Coverage model is best instrument we have now to confront the different "disciplinary coverage models" and design interoperability specifications for coverages.
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.
You raised an important issue that must be carefully addressed by the SWG for WCS 1.2.
Actually, the WCS 1.2 "core" specification use case is very close to the one you describe in your following comment (i.e. a WCS specification considerably simplified, with a defined list of things that it's good for and things that it isn't good for).
The question Ben and I are posing in our position paper, is about how to decide the "list of things that it's good for". In fact, that means to decide how "general purpose" the service will be to the detriment of its effectiveness (i.e. semantic meaningfulness). The latter was one of the main drawback outlined for the WCS 1.0.
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.
This is very close to an enhanced WMS; in my opinion you presented a valuable use case. However, the coverage concept and its types are quite different from the map concept and its types. Thus, for the sake of cross-disciplinary interoperability we must still wonder whether this is the only service we need, or if we need "proper" coverage access service(s), too.
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.
In my opinion, to provide access to CF-netCDF data model and encoding formats through "non-traditional" protocols should be a valuable asset for the FES community.
Best regards, Stefano
galeon archives: