We are pleased to announce that the 52 ° North SOS 4.0.0 implementation supports two new features: the SOS 2.0 Spatial Filtering Profile and the support for the optional validTime parameter in DescribeSensor requests. Both features will facilitate the modelling, storage and retrieval of mobile sensor data from SOS.

Spatial Filtering Profile

The Spatial Filtering Profile is specified in clause 12 of the SOS 2.0 specification (OGC 12-006). This profile restricts observations to spatial observations which provide a well-defined parameter for the observation location. This parameter carries the sampling geometry of the observation which represents the spatial extent where the observation result applies to and can be targeted by spatial filters. The “Spatial Observation” is defined in the Observation & Measurement 2.0 specification (OGC 10-025) subclause 7.13 and can contain any gml:AbstractGeometry type, such as points, lines or polygons.

Here is an example of a parameter with a point as the sampling geometry:

<om:parameter>
    <om:NamedValue>
        <om:name xlink:href="http://www.opengis.net/def/param-name/OGC-OM/2.0/samplingGeometry" />
        <om:value>
            <gml:Point gml:id="SamplingPoint1">
                <gml:pos srsName="http://www.opengis.net/def/crs/EPSG/0/4326">52.9 7.52</gml:pos>
            </gml:Point>
        </om:value>
    </om:NamedValue>
</om:parameter>

The xlink:href attribute value http://www.opengis.net/def/param-name/OGC-OM/2.0/samplingGeometry in the om:name indicates that this parameter carries the sampling geometry.

If the SOS supports the Spatial Filtering Profile, the observedArea of ObservationOfferings provided in the Contents section of the Capabilities represents the minimum bounding box of the sampling geometries, not the bounding box of the features of interests. So client can detect whether the SOS supports the Spatial Filtering Profile by checking if the Profile http://www.opengis.net/spec/SOS/2.0/conf/spatialFilteringProfile appears in the ServiceIdentification section of the Capabilities.

For filtering the sampling geometry in the GetObservation and GetRequests, the valueReference element should contain the value http://www.opengis.net/req/omxml/2.0/data/samplingGeometry. If this value is set, the spatial filter is targeted to the sampling geometries of the observations instead of the featureOfInterest geometries. Here is an example for a spatial filter:

<sos:spatialFilter>
    <fes:BBOX>
        <fes:ValueReference>http://www.opengis.net/req/omxml/2.0/data/samplingGeometry</fes:ValueReference>
        <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
            <gml:lowerCorner>0 0</gml:lowerCorner>
            <gml:upperCorner>60 60</gml:upperCorner>
        </gml:Envelope>
    </fes:BBOX>
</sos:spatialFilter>

The Spatial Filtering Profile restricts the observations to OM_SpatialObservation. This means that all observations must contain the well-defined parameter which carries the sampling geometry. Since this is not always wanted, the 52°North SOS 4.0.0 provides the ability to use the Spatial Filtering Profile less restrictive. In this case an observation must not contain a sampling geometry. This behaviour can be activated via a property (Service-Settings -> Should this SOS support strict Spatial Filtering Profile?) in the admin backend.

The Spatial Filtering Profile was the last missing definition of the SOS 2.0 specification. More information about the 52°North SOS 4.0.0 Spatial Filtering Profile implementation can be found in the SOS wiki.

DescribeSensor validTime parameter

The DescribeSensor operation is defined in subclause 11 of the SWE Service Model Implementation Standard (OGC 09-001) and describes two mandatory parameter (procedure, procedureDescriptionFormat) and the optional validTime parameter which is now supported by the 52°North SOS 4.o.o. This parameter allows to query all sensor descriptions for a procedure in the requested format which are valid at the requested time (TimeInstant) or in the requested period of time (TimePeriod). The response contains all valid sensor descriptions with the respective validity period or no sensor description if the requested validTime do not match. Here are some examples for the supported validTime.

The first example returns all sensor descriptions that match the specific date.

<swes:validTime>
    <gml:TimeInstant gml:id="validTime">
        <gml:timePosition>2013-08-14T15:02:43.219</gml:timePosition>
    </gml:TimeInstant>
</swes:validTime>

The second example returns all sensor descriptions that are valid after the specific date, but several relative operators are possible. Valid indeterminatePosition values are:

• before
• after
• now
• unknown

<swes:validTime>
    <gml:TimeInstant gml:id="validTime">
        <gml:timePosition indeterminatePosition="after">2013-08-14T15:00:00</gml:timePosition>
    </gml:TimeInstant>
</swes:validTime>

This example returns all sensor descrptions that match the specific period of time.

<swes:validTime>
    <gml:TimePeriod gml:id="validTime">
        <gml:beginPosition>2013-08-14T15:02:43.219</gml:beginPosition>
        <gml:endPosition>2013-08-14t15:02:47</gml:endPosition>
    </gml:TimePeriod>
</swes:validTime>

For more details about the temporal relationships between validTime and exiting sensor descriptions read the subclause 11.1 of the SWE Service Model Implementation Standard (OGC 09-001). All possible cases, such as a query interval overlapping the valid time interval, or merely touching the valid time interval of a sensors, are covered in the specification.

How can you create sensor descriptions for a specific period of time?

The SWE service model defines quite complex rules how to handle sensor description updates with respect to the validTime contained in the updated sensor descriptions (see requirements 38 to 42). For the sake of simplicity we implemented only the behaviour of requirement 43 so far: if a sensor description is updated at point in time t1 then the validTime interval of the existing sensor description is updated to end at t1, and the new sensor description is valid from t1 on.

If an update sensor operation does contain a validTime element then the service currently throws and exception.

Some information about the 52°North SOS 4.0.0 implementation can be found in the SOS wiki.