NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hi all, let me chime in, as one of the WCS guys: Roy Mendelssohn wrote:
Hi Ben:If the netcdf encoding is just an extension (rather than at the core of WCS), and if it is not supported by the larger WCS or OGC community (ie. if most WCS clients or servers do not support it), then it is not serving the purpose of providing interoperability between communities, which would seem to be the purpose of this effort.
hm, WCS serves a range of communities, including remote sensing, sensory, and metocean. I understand that each of these communities sees their part in the core, but is this really necessary? why is it necessary for netcdf folks that some pure remote sensing WCS instance supports netcdf, even if not used? My naive understanding was that interoperability is relevant for functionality that is used among the relevant players. I'm open to getting educated...
The GALEON effort has been very strong, and a lot of great work has been done. But is this viewpoint supported by the larger WCS or OGC community?
Just to mention, we have introduced a special "galeon corner" in our telecon meetings where every month special time and attention is devoted to galeon issues. Notably this is not the case for any other community, such as remote sensing - and none of these complains. Further, we greatly appreciate contributions like the netcdf encoding, which will form an important part of the WCS core/extension cloud (and contributes to coming up with generic data format encoding templates), and we have really fruitful exchange on these issues (see our mailing list backlog). The real issue IMHO is one about participation - we always invite stakeholders to actively bring in their ideas, sometimes with success. Galeon is one such focused initiative, with clear impact.
Recent decisions about WCS would seem to suggest not.
which one do you have in mind?
would return to my email of last week. Where in OGC land is there something that is close in viewpoint to that of the metocean community? IMO it is CSML - the mapping between CSML Feature Types and Datatypes in the proposed CDM is very close. Rather than try to force a harmonization on the WCS level,
The alternative is to end up with several incompatible standards. Yes, one of them might fit metocean purposes perfectly - and then they will not be interoperable with EO stuff, for example. I like the idea of having a common service which unifies all coverage-related communities and will allow to be interoperable not only within, but between communities. That said, it certainly is a nontrivial task, and we still have some considerable way to go to achieve that Holy Grail.
where the larger WCS community does not appear to be interested,
If it appears like that, let me know how we have caused this impression - the WCS.SWG definitely has a high (and documented) interest in the metocean domain.
why not work for closer harmonization with CSML, with gateways and translators, and since the CSML folk are heavily involved in OGC, use whatever OGC transport layers/ service requests they develop for CSML as the ones that will provide the bridge.
well, again a straight and (maybe too) naive thought: why not liaise with CSML people to achieve some broader consensus and interoperability? I'm not talking about merging all into one pot, but some coherence can't be wrong...
my 0.02, Peter
galeon archives: