SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 177 of 233
instance or if the catalogue information is not sufficiently current for the user‟s purpose, they may retrieve the capabilities directly from the SOS instance by issuing a
getCapabilities operation request to the SOS instance. The capabilities document of the
SOS instance usually provides more detailed information about the service such as possible result models and the procedures used to get the values of an observation. Based
on this information the user now selects one or more SOS instances from which they want to get observations.
3. The user gets the observations by issuing a getObservation operation request to the SOS instance. It is important to note that the user does not get the observations from the
catalogue. The user finally decides which observations will be used in the application. Possible criteria for this decision are contained in the attributes of the observation, such
as quality attributes.
Depending on prior knowledge the user may skip parts of the sequence. As an example, the user may directly start with step 2, the search for an SOS instance, without having previously
searched an FOI in step 1. In this case the user may replace the ID of the FOI with a condition for the spatial context in the search SOS request to the catalogue.
10.2.3.2 Discovery of Procedures
The sequence diagram in Figure 10-2 explains the discovery of procedures. For this scenario, it is assumed that the user is already using a selected SOS instance to get observations. Now, the
user wants to find procedures that are similar or identical to the one that produces the value for an observation. The user then decides to configure this procedure using the Sensor Planning
Service SPS see section 8.2.3.
This scenario may be realised as follows: 1. The user gets detailed information about the procedures available in a given SOS service
instance by invoking getCapabilites in order to get the information about the involved procedures. By means of the describeSensor operation of the SOS the user then retrieves
information about the procedure, here in the form of SensorML documents. These documents may then be parsed in order to retrieve the required information subset.
2. The user provides parts of this information as search condition to the catalogue to retrieve a list of similar or identical procedures that are known by the catalogue. Examples are
the type of the procedure e.g. image-delivering sensors, the types of the output values produced by the procedure, or a spatial condition e.g. all sensors located within a circle
of 10km of the currently used sensor.
3. After having selected one or more procedures the user searches for an instance of the Sensor Planning Service in the catalogue and finally uses this service to configure the
procedure by calling the describeTasking and submit operations of the selected SPS.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 178 of 233
Figure 10-2: Discovery of Procedures 10.2.4 Harvesting of SOS Capabilities
This section describes how meta-information can be automatically created from domain specific resources and stored into a SensorSA catalogue. This procedure is usually called harvesting. As
an example, the Austrian Federal Environment Agency Umweltbundesamt needs to provide INSPIRE-compliant meta-information for their air quality data resources in accordance with the
CAFE Directive CAFÉ, 2008. This data is provided via an Sensor Observation Service SOS
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 179 of 233
section 8.2.2. The goal is to reuse the capabilities provided by the SOS for the creation and publication of INSPIRE related meta-information and store them in an OGC Catalogue Services
supporting the ISO 19115 and ISO19119 metadata schema in order to fulfill the INSPIRE duties. Such a catalogue service is, for instance, embedded into the prototypical INSPIRE geo-portal
1
. Besides the INSPIRE requirements there is the need for additional meta-information
elements:
-
CAFE is concerned with air quality data. For a CAFE meta-information document, specific validation information is needed, such that users of the meta-information can
precisely decide to which level they can trust the resource data. The means CAFE requires additional information regarding data quality, including quality assurance levels
and completeness of measurements. The required validation information exceeds the basic description dictated by INSPIRE.
-
The SensorSA formulates the need for the realization of information discovery in the sensor related domain as SensorSA users search for services, sensors, features of interest
and observable properties. To support these specific requirements the SensorSA has extended the INSPIRE and ISO 1911519119 meta-information schemata as described in
section 7.7.
In the following it is described how the meta-information elements of the SOS services that may be retrieved through the operations GetCapabilities and DescribeSensor can be mapped to
INSPIRE metadata resources:
-
The SOS service itself can be described in a metadata document describing a service.
-
Data provided by the Umweltbundesamt via the SOS needs to be described in metadata documents describing datasets. Each offering of the SOS is interpreted as a single dataset.
-
Common resource information like title, abstract and resource location can be found in the capabilities of the SOS.
-
The Geographic location and temporal extent can be provided in the descriptions of the SOS offerings in the capabilities of the SOS.
-
Access constraints can be provided in the SOS capabilities.
-
A responsible party can be described in the SOS capabilities.
-
Quality and validity information can be described via the means of SensorML and therefore included into responses of the DescribeSensor operation.
The gathered metadata is used to create ISO 19115 for datasets or ISO 19119 for services documents, following the INSPIRE Technical Guidelines. ISO 19115 and ISO 19119
contain some mandatory metadata elements, which are not mandatory for INSPIRE. These elements also need to be included into the resulting metadata documents. This results in metadata
documents conformant to both: INSPIRE and ISO.
1
http:www.inspire-geoportal.eu
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 180 of 233
However, two issues remain when following this approach: 1. The SOS supports the provision of the above mentioned information, but many elements
are not mandatory for an SOS to be compliant to its specification. Thus, if an SOS shall be used for the creation of INSPIRE related metadata, one must make sure that the
metadata required for INSPIRE is provided by the SOS.
2. Even if all possibilities in the current SOS schemas are used, some metadata required by INSPIRE remains which is not provided by the SOS. Some of these metadata elements
are to be picked from fixed keyword lists provided by the INSPIRE Commission Regulation. A schema was defined gathering all missing metadata elements. It is possible
and conformant to the current SOS specification to include links into the GetCapabilities response of a SOS. A link to an online resource can be defined in the ServiceProvider
section of the capabilities
1
. This link can lead to an external document that is structured according to the defined schema and containing the missing metadata elements.
Using the defined mapping and the additional information provided for gap-filling, it is possible to create INSPIRE related metadata as well as SANY meta-information from SOS
resources. Figure 10-3 shows an implementation architecture and the interactions between the system components for this harvesting task Hilbring and Schleidt, 2009.
Figure 10-3: Creation and publication of INSPIRE and SANY related meta-information
The Catalogue Harvester calls the operations GetCapabilities and DescribeSensor of the SOS and uses the retrieved information for the metadata mapping. For the creation of INSPIRE
related metadata the mapping described in the section “Mapping Solution” is used. The results are metadata documents structured according to the ISO 19115 or ISO 19119 schemas. They can
1
sos:Capabilitiesows:ServiceProviderows:ServiceContactows:ContactInfoows:OnlineResource
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 181 of 233
be included into an OGC Catalogue Service 2.0.2 supporting the ISO Metadata application profile. This catalogue could be accessed directly from users or it could be included into a
cascading catalogue realized by the INSPIRE geo-portal.
The architecture also shows the integration with a SANY Catalogue Server according to the SensorSA Catalogue Service see section 8.4.1. A different mapping is performed in the
Catalogue Harvester to create the SANY metadata documents according to the SensorSA Application Schema for Meta-information AS-MI schema see section 7.7. These documents
can be published via the publication interface of the Catalogue Service.
10.2.5 Event-based Harvesting
