[Requests] Comments on OGC 10-037, OGC SOS 2.0 Interface Standard

Johannes Echterhoff johannes.echterhoff at igsi.eu
Mon Nov 29 11:15:02 EST 2010


PART A


1. Evaluator: 

Johannes Echterhoff, 
International Geospatial Services Institute GmbH


2. Submission: OGC 10-037, OGC SOS 2.0 Interface Standard




PART B.1


1. Requirement: state requirement 11 more precisely

2. Implementation Specification Section number: Req 11


3. Criticality: Major


4. Comments/justifications for changes: Requirement 11 does not clearly
specify which conformance classes are to be listed in the service's
Capabilities document. Suggest to list only the conformance class
identifiers (URIs) that are at the bottom of the dependency hierarchy, and
omit all those that are implied through dependencies. That a server shall
pass the tests associated with certain conformance classes is implied.




PART B.2


1. Requirement: describe requirement regarding an offering's
phenomenonTime/resultTime more precisely


2. Implementation Specification Section number: 8.1.2.2


3. Criticality: Major


4. Comments/justifications for changes: Instead of saying "is omitted if the
offering has no observations associated to it" (in the "Multiplicity and
use" column) it would be more precise to say "omit only if the offering ..."
- suggest to change the description in the table accordingly. 

Table 17 should extend the footnote to explain in more detail the special
situation in which phenomenonTime/resultTime can be zero.

Furthermore, should the "Definition" of the phenomenonTime and resultTime
not state that the property value is expected to be the temporal bounding
box of the according observations' property values? At the moment the
definition is a bit imprecise, but maybe that is the intention (if so, the
specification should clearly state the reasons).




PART B.3


1. Requirement: Harmonize UML Model with GFI package described in O&M 2.0


2. Implementation Specification Section number: General


3. Criticality: Major


4. Comments/justifications for changes: In order to harmonize with the
conceptual model of O&M, each AbstractFeature (a helper type defined in ISO
19136) should be replaced with GFI_Feature throughout the specification. The
XSD encoding should not be affected by this change as in both cases the type
is encoded using gml:AbstractFeature.




PART B.4


1. Requirement: Clarify subsetting of observation data 


2. Implementation Specification Section number: 8.3 - GetObservation
operation


3. Criticality: Major


4. Comments/justifications for changes: In SOS 1.0, the GetObservation
operation was sometimes used to not only retrieve observations that match
the request criteria but also to subset the observation result, only listing
the (SWE Common) components that match the observedProperty values provided
in the request. Clause 8.3 in SOS 2.0 does not seem to explain in sufficient
detail if this behavior is still allowed. As the SOS 2.0 is not tied to a
specific result format, it should not perform such subsetting. According
functionality should be defined in separate conformance classes. Some
explanation should be added to section 8.3 to discuss how observation
subsetting functionality can be added to the GetObservation operation via
extensions. 




PART B.5


1. Requirement: Specify filter context in more detail 


2. Implementation Specification Section number: General


3. Criticality: Major


4. Comments/justifications for changes: Whenever some data is selected based
upon certain criteria - for example property values or filter expressions -
the exact context of such filters should clearly be defined. Especially for
value references in filter expressions this is of interest.

For example, in clause 9.1.1 (GetFeatureOfInterest operation) the context
for the spatialFilter is different than that of procedure and
observableProperty. Their context is a given observation while the
spatialFilter context is the featureOfInterest of that observation (example
14 shows this). Also, the featureOfInterest is given as identifier/pointer
and as such it should be looked up in the featureOfInterest object itself,
i.e. om:featureOfInterest/*/gml:identifier.
For the GetFOI operation this could be simplified by having the observation
as context every time (so revising requirement 40) and explaining that the
GetFOI operation is like GetResult in the sense that it only returns a
certain property of selected observations: the feature of interest.




PART B.6


1. Requirement: Explain Result Retrieval Implications 


2. Implementation Specification Section number: General


3. Criticality: Major


4. Comments/justifications for changes: If the result retrieval conformance
class is realized by the service (so GetResultTemplate and GetResult
operations are implemented) then does that mean that only observations with
SWE Common encoded results are provided by the service? If so then this
implication should clearly be stated as such in the standard. If that is not
the case, what happens if a client requests template information for an
offering/property combination that does not have observations with SWE
Common encoded result values?




PART B.7


1. Requirement: Usage of namespace prefixes for value references


2. Implementation Specification Section number: General


3. Criticality: Major


4. Comments/justifications for changes: Example 29 shows a KVP encoded
GetObservation request. It contains a spatialFilter where the value
reference uses an XPath that contains namespace prefixes "om" and "sams". A
service receiving such a request can only guess to which namespace a given
prefix refers to. While this is easier for the mentioned ones, consider the
case of a namespace prefix "ns1". It therefore appears to be better to omit
the namespace prefixes completely in value references - maybe also in case
of filters encoded in XML requests. Filter Encoding 2.0 appears to also
favour XPath expressions without namespace prefixes - however in some
examples prefixes appear.




PART B.8


1. Requirement: Revise version number usage in XML Schemas


2. Implementation Specification Section number: 13.1 - XML Encoding


3. Criticality: Minor


4. Comments/justifications for changes: According to 06-135r9 the URL for
the schema repository of a standard shall not include the bugfix version.
This needs to be updated accordingly in both the text of the SOS standard as
well as in the schema (for each import that is made to standards that
already implement that rule - e.g. SWES, FilterEncoding 2.0 etc. but not GML
3.2.1). The schema itself needs to include a version attribute with a value
that includes the bugfix number.



More information about the Requests mailing list