Offering parameter Extracting the last value

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