Web Service Interface. Dr. Simon Jirka

Transcription

1 1 Web Service Interface Standards Dr. Simon Jirka

2 Overview 2 Providing Access to Observation Data OGC Sensor Observation Service Controlling Sensors OGC Sensor Planning Service Event Notification

3 SOS 3

4 SOS Overview 4 Access to sensor data Consistent interface and data format for all kinds of sensors Returns O&M Contrast to WFS: no generic schemas Interoperability A priori-knowledge SOS 1 0 SOS 1.0 SOS 2.0 latest official version

5 SOS Introduction 5 Pull-based access to observations Mediator between: client data archive / simulation / real-time sensor system Hides the heterogeneous structure of proprietary sensor data formats and protocols Data formats: O&M and SensorML Versions: 1.0 and 2.0

6 6 SOS 1.0 Operation Profiles The SOS 1.0 interface comprises three profiles: Core Profile Mandatory Operations for accessing the sensor data and metadata Transactional Profile Optional Insertion of sensor data and metadata Enhanced Profile Optional Further operations for accessing geometries and observations

7 SOS 2.0 Model 7

8 SOS Core Profile 8 GetCapabilities operation Returns a metadata document describing the SOS instance Spatial, temporal and thematic content offerings Operator Mandatory for every OGC Web Service Structure and syntax from OWS Web Services Common specification

9 GetCapabilities 9 provides access to metadata and detailed information about the operations available by an SOS server. Examples base on XML implementation. Request: es1.xml Response: es1_response.xml Example request encoded as KVP: ies&acceptversions=200 ies&acceptversions=2.0.0

10 SOS Core Profile 10 GetObservation operation Returns sensor data Response format is usually a O&Mdocument Supports comprehensive spatial, temporal and thematic filter criteria

11 SOS Core Profile 11 DescribeSensor operation Returns detailed metadata of the sensors contained in the SOS instance Response format is usually SensorML

12 GetObservation KVP 12 Example service=sos& version=2.0.0& request=getobservation& offering= observedproperty= ctivetemperature& procedure= featureofinterest= d=building1&namespaces=xmlns(sams, ngspatial/2.0),xmlns(om, spatialfilter=om:featureofinterest/*/sams:shape,22.32,11.2,32.32,22.2,urn:ogc:def:crs:epsg::4326& temporalfilter=om:phenomenontime, t10:00:00z/ T11:00:00Z

13 Describe Sensor 13 provides access to detailed information about the sensors and sensor systems available by an SOS server. Request: cribesensor1_soap.xml Example request encoded d as KVP : =2.0.0&request=DescribeSensor&procedure=urn:ogc:obj 0&request=DescribeSensor&procedure=urn:ogc:obj ect:sensor:myorg:thermometer1&proceduredescriptionf ormat= = T18:31:42Z 01T18

14 SOS 2.0 Model 14

15 GetObservationById 15 provides access to observations from an SOS by passing only the ID of an observation. Request: nhancedoperations/getobservationbyid.xml tob Response: net/sos/2 nhancedoperations/getobservationbyid_respo nse.xml

16 GetFeatureOfInterest 16 provides access to the features of interest for which the SOS offers observations. Request / Response examples: GetFOI1.xml net/sos/2 GetFOI1_response.xml GetFOI2.xml GetFOI2_response.xml h t/ /2 / h ti / GetFOI3.xml GetFOI3_response.xml

17 SOS 2.0 Model 17

18 InsertSensor 18 allows registration of new sensors at the SOS. Request: ansactional/insertsensor1.xml Response: ansactional/insertsensor1_response.xmlresponse

19 DeleteSensor 19 allows the deletion of registered sensors and all their associated observations. Request: al/deletesensor1.xml Response: h t/ /2 /t ti al/deletesensor1_response.xml

20 InsertObservation 20.. allows the insertion of observations in an SOS server. Request: p mples/transactional/insertobservation1.x ml Response: net/sos/2 mples/transactional/insertobservation1_ response.xml

21 SOS 2.0 Model 21

22 InsertResult 22 allows the insertion of observation results in an SOS server. Before inserting, it is necessary that a template with observation metadata exists in the server. Request: ing/insertresult1.xml Response: ing/insertresult1_response.xml

23 InsertResultTemplate 23 allows the insertion of an observation template, containing the observation metadata and structure of the results. This operation is necessary for later insertion of observation results. Examples base on XML implementation : Request: ing/insertresulttemplate1.xml Response: ing/insertresulttemplate1_response.xml

24 GetResultTemplate 24 provides access to a template containing the structure of results returned by later invocation of the GetResult operation. Request: etresulttemplate1.xml Response: etresulttemplate1_response.xml l t l Response: etresult1_resultingdataarray.xml lti t l

25 GetResult 25 provides access to an observation result without the observation metadata and without the information about the structure of the results. Request: ing/getresult1.xml Response: ing/getresult1_response.xml

26 SOS 2.0 Model 26

27 Filtering 27 Minimum required filters: BBOX GetObservation1_spatialFilteringProfile.xml spatialfilteringprofile GetObservation1_spatialFilteringProfile_response.xml Temporal filters: TEquals operator in conjunction with the TimeInstant type (e.g. 1_obsProps.xml) TDuring operator in conjunction with the TimePeriod type p p 1_obsProps.xml 1_obsProps_response.xml

28 SOS 2.0 Model 28 XML Encoding KVP Binding SOAP Binding

29 SOS Workflow 29 Sensor 1 RegisterSensor Sensor ID InsertObservation GetCapabilities Capabilities Observation ID RegisterSensor SOS DescribeSensor SensorML Client Sensor 2 Sensor ID InsertObservation Observation ID GetObservation O&M

30 SOS 2.0 Changes 30 Increased interoperability: Minimum set of filter operators and operands Improved spatial filtering of observations Improved metadata provision: Restructuring t of offerings: one sensor/procedure per offering Improved filter functionality in GetFeatureOfInterest Know for which periods of time observations are available for certain observed properties, sensors/procedures, features of interest

31 SOS 2.0 Changes (cont.) 31 Re-use of models, operations and mechanisms defined by SWE Service Model (OGC ) Sensor description management operations Service metadata (contents) section with property inheritance it mechanism (decrease size of Capabilities document)

32 SOS 2.0 Changes 32 Removed operations DescribeResultModel l DescribeFeatureType DescribeObservationType GetFeatureOfInterestTime New Bindings KVP SOAP

33 Implementation North SOS > Live demo today! Open Source CITE Testing ongoing (Reference Impl.) p p g p g resource/products/ byspec

34 Eventing 34

35 Outline 35 Sensor Alert Service Event Pattern Markup Language Sensor Event Service

36 Sensor Alert Service 36

37 SAS Introduction 37 Sensor Alert Service (SAS) Part of the OGC SWE framework Push based delivery of sensor data Filtering of sensor data No event processing concepts Publish/subscribe mechanism relying on XMPP OGC document r3 Best Practice paper Use no longer recommended

38 38 Event Pattern Markup Language

39 EML Introduction 39 Event Pattern Markup Language (EML) OGC pending document Released as an OGC Discussion Paper Used to describe patterns for Complex Event Processing (CEP) and Event Stream Processing (ESP)

40 EML Example 40 Temperature surveillance with treshold Event stream with temperature mesurements Simple filtering (SAS): a warning for every measurement breaking the treshold

41 EML Example 41 Complex processing (EML based): Complex pattern: low temperature followed by high temperature a warning per hot period

42 EML Example 42 Fire detection Hot periods combined with smoke detection

43 Sensor Event Service 43

44 SES Introduction 44 Sensor Event Service (SES) OGC Discussion Paper Document number Based upon OASIS WS-Notification mainstream IT standards are used Enhanced filtering capabilities in order to address the shortcomings of the SAS

45 SES Introduction 45 Sensor side of the interface is optional Sensor side of the interface is optional Client side of the interface is mandatory

46 SES Features 46 Topic and content based filtering Three filter levels: XPath (mandatory) OGC Filter Encoding (optional) EML (optional) Not restricted to a specific transport protocol Default binding: SOAP via HTTP Default binding: SOAP via HTTP Unit conversion

47 Outlook 47 OGC Publish Subscribe Standards OGC Publish Subscribe Standards Working Group

48 SPS 48

49 Need for SPS 49 Tasking sensors so that they deliver the required data (e.g. setting pan, tilt and zoom parameters of a camera) Checking through a standardized interface if sensors will be able to perform certain tasks now or in the future (e.g. investigating if a satellite will cover a certain area during a time period that is of interest)

50 Introduction 50 Standardized interface for tasking sensors and sensor systems Task management Defining tasks Checking tasks Updating/modifying g takss Cancelling tasks Does not archive the data itself points to access points for the data

51 Introduction 51 Usage: Parameterization of: Sensors Simulations Planning and executing of: UAVs Robots Satellites Asynchronous communication with clients that submit tasks via WNS (e.g. notification if a task is completed)

52 Operations 52 Mandatory in SPS 1.0 and 2.0 GetCapabilities: Request a self description of a SPS instance DescribeTasking: Request which information is needed for submitting a task Submit: Submitting tasks DescribeResultAccess: Request information where the data resulting of a task can be retrieved

53 Operations 53 Optional in SPS 1.0 and mandatory in SPS 2.0 GetStatus: Request status information about a task Missing in SPS 1.0 and mandatory in SPS 2.0 DescribeSensor: Retrieving the description of a sensor GetTask: Request complete information about a task

54 Operations 54 Optional GetFeasibility: Check if a task can be executed before submitting it to the SPS Update: Change the parameters of a task Cancel: Cancel a task that was submitted Missing in SPS 1.0 and optional in SPS 2.0 Reserve: Reserving a task Confirm: Execute a reserved task UpdateSensorDescription: Updating the description of a sensor

55 SPS workflow 55

56 Controllable Camera 56 AXIS Pan-Tilt-Zoom Camera SPS for setting the pan, tilt and zoom parameters Additional feature: Block specific parts of the field of view (e.g. for privacy reasons)

57 Controllable Camera 57

58 Thank you for your Attention! 58 Questions? Contact: More information: i h