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

Boisvert, Eric Eric.Boisvert at RNCan-NRCan.gc.ca
Tue Nov 30 06:32:03 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: http://www.opengis.net/spec/SOS/2.0/req/spatialFilteringProfile (Req 91?)

2. Implementation Specification Section number: 12

3. Criticality: Minor

4. Comments/justifications for changes: [Comments]
 To perform a spatial filter, it must be done on the feature-of-interest. SOS 1 spec allows spatial filter on the featureOfInterest parameter (and only spatial filters). A proper spatial filter requires a PropertyName to identify the geometry property which might not be readily or unambiguously extracted from the schema.  Even if the SOS actually provides a schema location for the domain of interest, the following issues must still be dealt with:
* The service might refer to a heterogeneous collection of feature-of-interest types, therefore not a single property but multiple spatial property must be identified (forcing a complex OR expression)
* The service might refer to a feature type that is the head of a substitution group where the spatial property is implemented by derived types (SF_SamplingFeatureType is a good example), forcing an "OR" expression.
* The spatial property might not be unique for a feature type.  Either forcing an "OR" expression or resulting in incoherent filter expressions.
* The spatial property might not be conveniently at the root of the feature-of-interest type and force a deep analysis of the schema to locate this property, with the risk of finding more that one property, again forcing an "OR" or incoherent expressions.
Several implementations have chosen to ignore the property name and apply the spatial query in a way that makes sense for the service (similar to WFS 1.0.0 KVP BBOX parameter that did not require explicit naming of the geometry property).   One proposal is to systematically use gml:boundedBy property, but it essentially forces all spatial operations to be expressed on an envelope.
SOS 2.0 (OGC 10-037, clause 12.1) proposes a Spatial Filtering Profile to exposes a geometry as a parameter of the Observation. They therefore suggest a unique identifier shall represent this parameter (OGC 10-025r1 sub clause 7.13 states that the identifier of this parameter SHALL be http://www.opengis.net/req/omxml/2.0/data/samplingGeometry). This profile requires that the client uses this syntax as a property name:
om:parameter/om:NamedValue[om:name/@xlink:href='http://www.opengis.net/req/omxml/2.0/data/samplingGeometry']/om:value

Proposed Solution

We propose that long XPath, which essentially is a constant to represent a spatial property, be replaced by the HTTP URI identifier alone.  This is the same HTTP URI as proposed in OGC 10-025r1: http://www.opengis.net/req/omxml/2.0/data/samplingGeometry.  We feel this could be a more generic way to represent a "well known property" or a relevant samplingGeometry.  The proposal is similar to ISSUE2 as it hides the schematic details and potential heterogeneity of the feature(s) of interest and does not bind its meaning to an encoding artifact of O&M.   We also feel that this approach is more portable to other OGC APIs.

Proposed Specification Modification: SOS2

A SOS service SHALL consider "http://www.opengis.net/req/omxml/2.0/data/samplingGeometry" as a proxy to a sampling geometry property of the feature-of-interest in a spatial filter expression.



More information about the Requests mailing list