[Requests] Comment to SOS 2.0 (OGC 10-037) from GWIE

Boisvert, Eric Eric.Boisvert at RNCan-NRCan.gc.ca
Tue Nov 30 06:30:52 EST 2010


Part A to be completed once.  Iterate Part B as needed.


PART A


1. Evaluator:
        Eric Boisvert (on behalf of the GWIE)
 Geological Survey of Canada
 eboisver at nrcan.gc.ca
 +01 418 654-3705

2. Submission: OGC® SOS 2.0 Interface Standard, OGC 10-037, 2010-09-02

 

PART B


1. Requirement: General


2. Implementation Specification Section number: General


3. Criticality: Major


4. Comments/justifications for changes: [Comments]


Filtering on the result requires the client to have some mechanism to discover the properties that can be filtered. A use case that this IE tries to address is to request all Observations that have a water level above or below some threshold.  This requires the filter expression to be written against the content of the result element (which is a time series containing pairs of water levels and time stamps).  


SOS 1 provides two operations that allow a client to introspect the structure of a response.  DescribeObservationType and DescribeResultModel (OGC 06-009r6 sections 10.6 and 10.7).  The second operation is what would normally provide the structure of the response as a W3C XSD schema.  The XSD schema of the expected result is not sufficient for several reasons:


* The SOS service can provide the result using multiple SWE encodings. Since the filtering encoding uses ogc:Filter, it assumes that the target property can be expressed using XPath. A result using SWE encoding does not express structure in XSD, but rather using a SWE meta schema.  This meta-schema is not expressed in the schema, but rather in the instance of a dataset. 
* The SOS service can serialize the result using many encodings (XML or Block or gml:Coverage or any other GML domain model) for the same observed property. The current specification does not provide a way to tell the client which "schema" it should use to express the filter.   We feel that the user should not have to adapt the way he expresses the filter based on the serialization of the output. 
* Even if the result is expressed in explicit GML XSD (as opposed to SWE), and even if the schema is actually known, the wide usage of polymorphism and substitutions in the result model can lead to multiple options.
* Observable properties are actually advertised as SWE common which does not have a direct mapping to GML/XML elements.  When parsing the SWE description of the observed property, we don't explicitly know how this would materialize in the filter expression, i.e. which observation element matches with which GML element.
While it is possible to extract the property definition in SWE and even get the details about units of measurement used by the service, it is not possible to craft an XPath representation of the structure of this property, simply because there are no systematic mapping between the SWE structure and the GML structure.   


Proposed Solution


We therefore propose that result queries SHALL be written against SWE meta schema instead of GML XSD schema.  It is possible in both SOS 1 and SOS 2 to discover the properties that are serialized (in one way or the other) in the result and write a filter that unambiguously expresses the filtering condition to the service.  The client SHALL use the identifier (the name of the field in the swe:DataRecord) of the property as a proxy for the property to filter, regardless of the result serialization.
The service should have internal mechanism to do what "makes sense" in this particular case. It should also handle the cases when the structure of the value can be complex (range instead of single value) and remove the complexity of writing a filter for the user. 
This pattern has several benefits:
* It provides a way to document and advertise properties that are part of the result set at the phenomenon level. 
* Properties are advertised using a conformant OGC approach.
* Properties are well described (SWE provides a certain level of metadata that XSD does not have).
* Query structure is decoupled from the result encoding, which is consistent with CSW pattern and proposed "stored query" mechanism of WFS (ISO-19142). The client can rely on a consistent way to get the parameters, whatever the response encoding. 
* This mechanism can be used by both SOS 1.0 and SOS 2.0 clients.  The only difference are the steps required to access to the bit of SWE required to build the query.


The GWIE recognizes that more work needs to be done to achieve a coherent pattern.


A third option would be to explicitly propose a list of "queryable" properties right into the Offering. 
<sos:ResultParameters>
   <sos:Parameter identification="urn:x-ogc:parameter:depth" uom="urn:ogc:def:uom:UCUM:m" type="xs:double">
      <sos:name xml:lang="fr">Profondeur de la nappe</sos:name>
      <sos:name xml:lang="eng">Aquifer depth</sos:name>
   </sos:Parameter>
   <sos:Parameter>
identification="urn:ogc:parameter:time" uom=" urn:ogc:property:time:iso8601" type="xs:DateTime">
      <sos:name xml:lang="fr">Date de la mesure</sos:name>
      <sos:name xml:lang="eng">Measurement date</sos:name>
   </sos:Parameter>
</sos:ResultParameters>


Proposed Specification Modification: SOS 2   


We therefore propose the following modifications to the SOS specification:
* A SOS service SHALL take SWE references as proxies for property names in a result filter expression.
* A SOS service SHALL handle numerical representation and perform the necessary adjustment internally for complex numbers.  Therefore, if the result is made of numerical values that are Range, or have uncertainties, it should handle comparison with input parameters that are single values automatically.
* A SOS service COULD explicitly provide a list of queryable properties in the Offering section.  This means that the offering tag SHALL be modified to include the Result parameters.
<sos:observedProperty>
<sos:name>urn:ogc:def:property:OGC:GroundWaterLevel</sos:name>
<sos:ResultParameters>
   <sos:Parameter identification="urn:x-ogc:parameter:depth" uom="urn:ogc:def:uom:UCUM:m" type="xs:double">
      <sos:name xml:lang="fr">Profondeur de la nappe</sos:name>
      <sos:name xml:lang="eng">Aquifer depth</sos:name>
   </sos:Parameter>
   <sos:Parameter>
identification="urn:ogc:parameter:time" uom=" urn:ogc:property:time:iso8601" type="xs:DateTime">
      <sos:name xml:lang="fr">Date de la mesure</sos:name>
      <sos:name xml:lang="eng">Measurement date</sos:name>
   </sos:Parameter>
</sos:ResultParameters>
</sos:observedProperty>


 


More information about the Requests mailing list