[Requests] SOS (RFPC 32) Response

Alexandre Robin robin at nsstc.uah.edu
Fri May 5 16:00:03 EDT 2006

Part A is to be completed once per evaluator per comment submission.  Please
iterate over Part B as needed. 


 1. Evaluator: Alexandre ROBIN - robin at nsstc.uah.edu - (256) 468-7043 

 2. Submission: OGC Request 32: OpenGISR Sensor Observation Service (SOS):
Request for Public Comments  


 1. Specification Section number: 8.1.3 & 8.3.2  

 2. Criticality: MAJOR 

 3. Comments/justifications for changes: Clarification on using Phenomenon
ID vs. URN in GetObservation

Clarification is needed for the use of Phenomenon ID vs. complete URNs in
In an ObservationOffering (capabilities document), "observedProperty" can be
listed in two different ways as illustrated in the next XML snippets:

Case1: Inline definition of a Phenomenon


  <swe:ConstrainedPhenomenon gml:id="AirTemperature">
    <gml:name>Air Temperature</gml:name>
    <swe:base xlink:href="urn:ogc:def:phenomenon:temperature"/>



  <swe:ConstrainedPhenomenon gml:id="AtmosphericTemperature">
    <gml:name>Atmospheric Temperature</gml:name>
    <swe:base xlink:href="urn:ogc:def:phenomenon:pressure"/>


Case2: Reference to a Phenomenon already defined in a dictionary

<sos:observedProperty xlink:href="urn:ogc:def:phenomenon:AirTemperature"/>

This situation is ambiguous when requesting this observation data and
filtering by "observedProperty":

In case 1, the local "gml:id" needs to be used since no URI is given.
In case 2, the "xlink" URI needs to be used since there is no ID

I believe that this situation needs to be clarified in the documentation.

Here is a (non exhaustive!) list of possible solutions:

- Force Phenomena to be defined inline, and thus always use local IDs
- Force Phenomena to be defined externally, and thus always use URIs (not
that each SOS could host a local dictionary)
- Force transformation of IDs by using the complete URL of the capabilities
doc: http://domain/serviceEndpoint + # + ID
- Support both IDs and URNs in the request (server should be smart about it)


 1. Specification Section number: 8.3.2 GetObservation Request

 2. Criticality: MINOR 

 3. Comments/justifications for changes: Clarification on 'responseMode'

The different choices available for responseMode should be clarified in the
The spec states at least 4 different useful values: [template, inline,
out-of-band, attached]

There is more work to be done on defining these different modes, especially
the "attached" mode which might need more information to better defined what
kind of attachment. Furthermore, I am not sure these modes apply to all
"result models", even though they certainly apply to CommonObservation.

The last thing is that since the "GetResult" operation requires more complex
(state based) logic on the server side, it would be helpful to add a
response mode for getting only the result data, without the XML envelope.
(i.e. a response mode called data-only)


 1. Specification Section number: 8.1.3 Capabilities Document

 2. Criticality: MINOR 

 3. Comments/justifications for changes: Concerning the better support of
Sensor grids and arrays

I think the support of multiple sensor (procedures) in an offering was
primarily added for the support of large arrays/grids of sensors.
While requesting data from a sensor grid, it should be possible to filter by
sensor ID; however the full list of IDs cannot be provided if the array is
too large.
A well defined procedure to generate a unique sensor ID based on array ID +
sensor number (between 1 and size of array) needs to be described in the
Additionally we need to make sure that the om:ProcedureArray contains enough
information to support this.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mail.opengeospatial.org/mailman/private/requests/attachments/20060505/fb1618c4/attachment-0001.html

More information about the Requests mailing list