NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hi Folks Like most, I'm watching this with interest.I don't believe INSPIRE will mandate us to use WCS with SOAP, but if it does, as already explained, that will apply to national infrastructure, not community infrastructure ... the line we are taking within NERC is that we will support INSPIRE because it will improve our ability to do science, both within our communities and between! If there really is a clash between these, there is no doubt that community expediency will win, with only lip-service paid to compliance. However, if only one or two communities are out on a limb, then they might well wither ...
So, from a technology point of view: What's more interesting for me is fusing metadata, with semantic subsetting (i.e by lat/lon etc not array index stride). It would appear that WCS provides that in a way that is more interoperable (although far from perfect)... but is stuffed by having to deliver non-interoperable payloads (in that regard, from some perspective, *all* parochial formats are non-interoperable). Opendap per se, doesn't change that argument - although it might simplify the construction of useful WCS servers that exploit existing infrastructure (assuming netcdf clients). More useful IMHO are tools that describe coverages in useful ways so that clients and/or servers can work out whether they can map a coverage in one format to another that they understand as part of the user workflow. Hence without CSML, or the Unidata CDM, or some equivalent, I think we're all arguing about a form of interoperability that doesn't really exist. Then, once we talk about coverages conforming to some data model, we're really talking about features ... and feature servers can deliver coverages. Me, while I think the WCS is temporarily important, it's not going to be important for long!
Bryan
-----Original Message----- From: galeon-bounces@xxxxxxxxxxxxxxxx on behalf of stefano nativi Sent: Mon 06/10/2008 10:26 To: Jon Blower; Steve Hankin Cc: Unidata GALEON; Peter Baumann Subject: Re: [galeon] WCS CF-netCDF profile document Hi Jon, As for INSPIRE, the European Directive asks Member States in article 11(1) (c) to establish and operate a network of "download services, enabling copies of spatial data sets, or parts of such sets, to be downloaded and, where practicable, accessed directly". According to the last version of the INSPIRE Service Architecture, a download service supports: download of a complete dataset or datasets, or a part of a dataset or datasets, and where, practicable, provides direct access to complete datasets or parts of datasets. Thus, it is clear the need for "access" services as far as Feature and Coverage-based datastes are concerned. As the INSPIRE directive advises to utilize existing standards, "OGC service bindings are taken as a guidance". Moreover, and more important for our discussion about OPeNDAP, the draft IRs states that "taking all requirements, opportunities and riscs into account, the default communication-protocol and binding technology for INSPIRE services should be SOAP (document/literal)". Therefore, OGC WFS, and WCS with SOAP bindings seem to be a natural choice. Specifications maturity will be considered, indeed. However, the INSPIRE technical WGs are still analyzing whether the SOAP based approach is feasible for the INSPIRE network services. In fact, they recognize that the "usage of REST APIs and related technologies may help open up INSPIRE resources to mass market information infrastructures". A possible solution might be to see the INSPIRE Network Services "as a mediator between the services provided by the member states or offered by third parties and their EU-level usage for example via the INSPIRE geoportal.... Therefore services in the member states are not required to be changed because of INSPIRE. INSPIRE just requires that data and services in the member states are made available through INSPIRE conformant network services". A valuable case in point would be the OPeNDAP-WCS/CF-netCDF extension specification, we have been discussing about.It's certainly true that there's a feeling amongst many people that OGC=interoperability and therefore any OGC-accepted solution is politically correct.ISO TC211/OGC deal with interoperability solutions for "Geo-spatial Information" communities; this information domain is a multi-disciplinary one, indeed. Thus, if we consider the FES information domain as part of the geo-spatial domain, OGC/ISO specifications should be considered as "general" interoperability solutions to interconnect FES to the other Geo-spatial information domains (e.g. GIS, Biodiversity/Ecosystems, etc.). Questions are about how general they should be, and which "common" semantic and structural level they should consider. The present ongoing discussion on WCS/CF-netCDF Vs OPeNDAP has been providing many valuable arguments to better understand Communities interoperability. In fact, FES information domain is characterized by well-accepted, specific and effective disciplinary specifications; while, the GIS domain models and protocols are really close to the OGC ones. Other interesting examples are represented by Earth Observation and Biodiversity Communities. Cheers, --Stefano
galeon archives: