OGC Engineering Report OGC 13-053r1
21 RVICE=SOSoffering=WATER_LEVELfeatureOfInterest=ca.gc.ec.station.05NG021
observedProperty=urn:ogc:def:phenomenon:OGC:1.0.30:waterlevel XML-encoded example:
sos:GetObservation service=SOS
version=2.0.0 xmlns:sos=http:www.opengis.netsos2.0
xmlns:fes=http:www.opengis.netfes2.0 xmlns:gml=http:www.opengis.netgml3.2
xmlns:swe=http:www.opengis.netswe2.0 xmlns:swes=http:www.opengis.netswes2.0
xmlns:xlink=http:www.w3.org1999xlink xmlns:xsi=http:www.w3.org2001XMLSchema-instance
xsi:schemaLocation=http:www.opengis.netsos2.0 http:schemas.opengis.netsos2.0sos.xsd
http:www.opengis.netgml3.2 http:schemas.opengis.netgml3.2.1gml.xsd
sos:offeringWATER_LEVELsos:offering sos:observedPropertyurn:ogc:def:phenomenon:OGC:1.0.30:waterlevelsos
:observedProperty sos:featureOfInterestca.gc.ec.station.05NG021sos:featureOfInterest
sos:GetObservation
4.3.4.6 GetDataAvailability profile 4.3.4.6.1 Introduction
For the NRCan profile is it mandatory to implement the GetDataAvailability request that plays an important role in this project because it provides the means by which the last
value of a procedure can be monitored by the notification system.
This clause discusses various aspects of the GetDataAvailabilty operation including why the profile makes the offering parameter mandatory and how to use the operation to
extract the last value.
4.3.4.6.2 Offering parameter
For CHISP, it is proposed that the offering be a mandatory item in the request. The reason for this is illustrated in the following example:
The NRCan SOS service see 5.3.3.2 provides the same observed property and procedure in two different offerings, WATER_FLOW and WATER_FLOW_LIVE. The
only difference between them is the time span and the features of interest.
Offering: WATER_FLOW_LIVE
OGC Engineering Report OGC 13-053r1
22 WATER_FLOW_LIVE has only 10 features of interest and values from around
2011 to now Observed property : water flow
urn:ogc:def:phenomenon:OGC:1.0.30:waterflow procedure : Water flow process
urn:ogc:object:Sensor::EC_WaterFlowProcess Offering: WATER_FLOW
WATER FLOW has historical data for a large number of features of interest, including the 10 present in LIVE, but the observation are all BEFORE 2011.
Observed property : water flow urn:ogc:def:phenomenon:OGC:1.0.30:waterflow
procedure : Water flow process urn:ogc:object:Sensor::EC_WaterFlowProcess
Because some features of interest actually appear in both offerings 05NB036 is an example, a GetDataAvailability response will be ambiguous if the request does not
specify an offering the service considers all offerings to be in scope - WATER_FLOW and WATER_FLOW_LIVE. This might further encourage the omission of an offering
from an SOS GetObservation request, which could result in only one value returned instead of two.
Although not clearly stated in the SOS specification see OGC 12-006, the time span should probably be an aggregation of both time spans from both offerings.
4.3.4.6.3 Extracting the last value
This clause discusses how the GetDataAvailability operation may be used to determine the request parameters for a GetObservation request that may be used to extract the last
observed value for an offering of a feature of interest.
Consider the following KVP-encoded request is an example of the GetDataAvailability operation.
http:198.103.103.7GinServicesos?REQUEST=GetDataAvailabilityVERSION=2.0.0 SERVICE=SOSfeatureOfInterest=ca.gc.ec.station.01AJ013offering=WATER_FL
OW
OGC Engineering Report OGC 13-053r1
23 The GetDataAvailability operation can includes parameters to specify a procedure, an
observation, a feature of interest, the offering and a time range. By default, if a value is not specified for a parameter, then the entire range of values for that parameter is
included in the response.
Consider the following example which is requesting all procedures and observations related to feature of interest 05NB036 for offering WATER_FLOW_LIVE during 1900-
01-01T12:00:00 to 2013-12-12T23:59:59.
o
procedure = ? response will include all matching procedures
o
observation = ? response will include all matching observations
o
featureOfInterest = 05NB036
o
offering = WATER_FLOW_LIVE
o
time range = 1900-01-01T12:00:00 to 2013-12-12T23:59:59 Because we did not specify an observed property or a procedure in the request, the
response will return all observed properties and procedures in the context of that offering, feature of interest and time span. Here is the request encoded as XML:
gda:GetDataAvailability version=2.0.0
service=SOS xmlns:gml=http:www.opengis.netgml3.2
xmlns:gda=http:www.opengis.netsosgda1.0 xmlns:xsi=http:www.w3.org2001XMLSchema-instance
xsi:schemaLocation=http:www.opengis.netsosgda1.0 file:W:LCNPNormesSOSSOS2GetDataAvailability_ExtensionxsdsosGe
tDataAvailability.xsd gda:availabilityTimeframe
gml:TimePeriod gml:id=x gml:beginPosition1900-01-01T12:00:00gml:beginPosition
gml:endPosition2013-12-12T23:59:59gml:endPosition gml:TimePeriod
gda:availabilityTimeframe gda:featureOfInterest05NB036gda:featureOfInterest
gda:offeringWATER_FLOW_LIVEgda:offering gda:GetDataAvailability
Notice, that as per the NRCan profile the request includes a mandatory offering. A minimal response to this request might be:
?xml version=1.0 encoding=UTF-8? gda:GetDataAvailabilityResponse
xmlns:swes=http:www.opengis.netswes2.0 xmlns:gml=http:www.opengis.netgml3.2
xmlns:xlink=http:www.w3.org1999xlink xmlns:gda=http:www.opengis.netsosgda1.0
OGC Engineering Report OGC 13-053r1
24
xmlns:xsi=http:www.w3.org2001XMLSchema-instance xsi:schemaLocation=http:www.opengis.netsosgda1.0
file:W:LCNPNormesSOSSOS2GetDataAvailability_ExtensionxsdsosGe tDataAvailability.xsd
gda:featurePropertyRelationship gda:FeaturePropertyTemporalRelationship
xmlns:gml=http:www.opengis.netgml3.2 gda:phenomenonTime
gml:TimePeriod gml:id=x1 gml:beginPosition2011-05-
15T23:16:00gml:beginPosition gml:endPosition2013-01-14T14:00:00gml:endPosition
gml:TimePeriod gda:phenomenonTime
gda:targetFeature xlink:href=foi_05NB036 gda:targetProperty xlink:href=water_flow
gda:FeaturePropertyTemporalRelationship gda:featurePropertyRelationship
gda:propertyEntryPoint gda:ObservedPropertyInfo swes:id=water_flow
gda:propertyurn:ogc:def:phenomenon:OGC:1.0.30:waterflowgda:proper ty
gda:ObservedPropertyInfo gda:propertyEntryPoint
gda:featureOfInterestEntryPoint gda:FeatureOfInterestInfo swes:id=foi_05NB036
gda:feature05NB036gda:feature gda:relatedProperty xlink:href=water_flow
gda:FeatureOfInterestInfo gda:featureOfInterestEntryPoint
gda:GetDataAvailabilityResponse
The salient fragment from this response is:
gda:FeaturePropertyTemporalRelationship xmlns:gml=http:www.opengis.netgml3.2
gda:phenomenonTime gml:TimePeriod gml:id=x1
gml:beginPosition2011-05-15T23:16:00gml:beginPosition gml:endPosition2013-01-14T14:00:00gml:endPosition
gml:TimePeriod gda:phenomenonTime
gda:targetFeature xlink:href=foi_05NB036 gda:targetProperty xlink:href=water_flow
gda:FeaturePropertyTemporalRelationship
which essentially says that the feature of interest is related to water flow observation over the time period 2011-05-15 to 2013-01-14. Given this fragment, the two methods that
may be employed to extract the last observed water flow value for the feature of interest 05NB036:
OGC Engineering Report OGC 13-053r1
25 1. Because we know the time period from the fragment above, we now have all the
information necessary to formulate a GetObservation request to obtain the last value.
2. Alternatively, we could take advantage of the fact that the specification for the GetDataAvailability operation supports an extension point that could be exploited
to allow us to include the last value in question in the response above without forcing a second request from the client application as proposed by
option 1.
In order to avoid the use of an extension point in an ad-hoc manner the NRCan profile proposed to use the first method i.e. formulate a GetObservation request.
5. Use cases