[Requests] Comments on OGC 10-167, OGC SOS 2.0 - Get Data Availability Extension

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-167, OGC SOS 2.0 - Get Data Availability Extension



PART B.1


1. Requirement: Harmonize UML models and figures with latest O&M
developments 


2. Implementation Specification Section number: General


3. Criticality: Major


4. Comments/justifications for changes: to be compliant with the latest O&M
2.0 UML model as well as future developments, figure 2 should use
"OM_Observation" instead of "Observation" and "GFI_Feature" instead of
"AbstractFeature". Figure 3 should be updated accordingly (there is also a
type in there - "procdure" instead of "procedure").

This type of harmonization should occur throughout the document - especially
the operation's UML models. Some dependencies shown in figure 4 may then no
longer be needed (especially review the dependency on ISO 19136).




PART B.2


1. Requirement: enable retrieval of information on available observations
also per featureOfInterest, procedure and observedProperty


2. Implementation Specification Section number: General


3. Criticality: Major


4. Comments/justifications for changes: while it is useful to investigate
the relationships between feature(s)OfInterest, procedures and
observedProperties that exist in observations provided by a SOS, common use
cases also include queries just to know for which times observation data
exists per a given foi, procedure or obsProp (i.e. without specific
relationship to other observation properties).

The operation should thus allow clients to perform such queries. An approach
would be to have a flag indicate that general observation metadata should
also be provided per foi/procedure/obsProp and modify the operation model
and behavior accordingly. In the model, metadata could be added to the
XXInfo types - similar to how it is done per association between these
types.

The functionality of the GetFeatureOfInterestTime operation from SOS 1.0
could be achieved much more easily this way (also with improved level of
detail). It would thus also be possible to investigate when a certain sensor
generated observations (with a level of detail that is not possible to
achieve with the information provided in the service's capabilities
document).




PART B.3


1. Requirement: Enable observation counter per relationship/metadata
element. 


2. Implementation Specification Section number: General


3. Criticality: Minor


4. Comments/justifications for changes: The XXTemporalRelationship types
currently only contain a list of time primitives to indicate for which
(phenomenon) time observations exist that have the according property
relationship. As the operation allows the generalization of this temporal
information it would be useful to have a property in each
XXTemporalRelationship type that shows the count of the observations that
are part of that relationship.




PART B.4


1. Requirement: Revise version number usage in XML Schemas


2. Implementation Specification Section number: 8 - 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 GDA standard as
well as in the schema (for each import that is made to standards that
already implement that rule - i.e. SWES, 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