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

Boisvert, Eric Eric.Boisvert at RNCan-NRCan.gc.ca
Tue Nov 30 06:34:43 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: Annex B

3. Criticality: Major

4. Comments/justifications for changes: [Comments]

Of all the OGC Filter Encodings, only the <Distance> element has a @units attribute. This is a problem for clients since physical quantities need units to be meaningful. The client is unable to create the proper Filter Encoding without knowing the implicit units associated to the numbers in the filter encoding. Furthermore, even if the client knows the proper units, it must do the conversion to the units on the server. The philosophy of OGC in the past is that it is the responsibility of the client to perform any unit conversion. We think there are two problems with this philosophy:
* The responsibility of units conversion is with the client. Even if the service wanted to provide units conversion functionality, it cannot do so.
* There does not exist an easy way for the client to discover which fields are measured in what units so as to properly construct the Filter Encoding.  
The only available method to discover units of measure is to parse the SWE definition of the property.
 
Proposed Solution
 
We propose that the unit description be explicitly referenced in the offering as a SWE dataset. The suggestion below accomplishes the goal of allowing the service to share the responsibility of units conversion. Furthermore, it has an additional beneficial side effect of making the Filter Encoding request more self-contained.  Existing Filter Encoding requests make use of implicit units, so may return different kinds of results when submitted to different service implementations. 

Proposed Specification Modification: SOS 2, Filter Encoding
 
* Add a <ConversionCapabilities> section to the GetCapabilities response. The service uses this section to announce all the unit conversions it supports. 
<ConversionCapabilities> 
     <ConversionGroup name="urn:ogc:def:length"> 
         <uom default="true"defaultUnits id="urn:ogc:def:uom:UCUM:ft">feet</unitsuom>
<units uom id="http://usgs.gov/mile">miles</unitsuom> 
         <units uom id="http://nrcan.gc.ca/murn:ogc:def:uom:UCUM:m">meters</unitsuom> 
     </ConversionGroup> 
     <ConversionGroup name="urn:ogc:def:surface"> 
         <uomnits id="urn:ogc:def:uom:UCUM:sqfhttp://usgs.gov/sqfoot">square feet</uomnits> 
         <uomnits id="urn:ogc:def:uom:UCUM:sqmhttp://usgs.gov/sqmile">square miles</uomnits> 
         <uomnits id="urn:ogc:def:uom:UCUM:m2http://nrcan.gc.ca/sqm">square meters</uomnits> 
    </ConversionGroup> 
</ConversionCapabilities> 
 Furthermore, the units of the same dimension are grouped in ConversionGroup elements. A ConversionGroup may have at most one optional <defaultUnits>.

* For each <Offering>/<observedProperty> in GetCapabilities, the server announces the SWE description of the dataset for the observedProperty via a @structure attribute. If no property-specific default unit is declared in observedProperty, then the default unit is assumed to be the default unit of the appropriate ConversionGroup, if there is one: 
 
<sos:observedProperty xlink:href="urn:ogc:def:property:OGC:GroundWaterLevel" structure="http://usgs.gov/sos/gwie/datastructure.xml"/> 
The structure references points to a document compliant to SWE describing the actual structure of the observed property:
<swe:DataArray gml:id="GroundwaterLevel">
            <swe:elementCount>
                        <swe:Count>
                                   <swe:constraint>
                                               <swe:AllowedValues>
                                                           <swe:min>0</swe:min>
                                               </swe:AllowedValues>
                                   </swe:constraint>
                        </swe:Count>
            </swe:elementCount>
            <swe:elementType name="Components">
                        <swe:SimpleDataRecord>
                                   <swe:field name="time">
                                               <swe:Time definition="urn:ogc:property:time:iso8601"/>
                                   </swe:field>
                                    <swe:field name="depth">
                                               <swe:Quantity definition="urn:x-ogc:def:phenomenon:OGC:Depth">
                                                           <swe:uom code="m"/>
                                               </swe:Quantity>
                                   </swe:field>
                        </swe:SimpleDataRecord>
            </swe:elementType>
            <swe:values/>
</swe:DataArray>
* For all the Filter Encoding set of Comparison Operators, PropertyIsEqualTo, ...PropertyIsBetween, add an optional @uom attribute. If in a filter request, no value is given for @uom, then the numeric value is assumed to be measured in the default units for the property. 
        
<PropertyIsLessThan units="urn:ogc:def:uom:UCUM:ft"> 
       <PropertyName>DEPTH</PropertyName> 
       <Literal>30</Literal> 
</PropertyIsLessThan> 
        
* When the service receives a request with a Filter Encoding component with a units value that it either does not recognize or that is unwilling to perform the conversion for, it throws a UnitNotSupportedException with a message identifying:
* the property at question,
* the acceptable units for that property.
This exception allows the client to easily adjust the Filter Encoding in case of a units error without having to parse through a heavy GetCapabilities section. 
       



More information about the Requests mailing list