NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
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: