SWSL @ ifgi retreat 2011
•
0 likes•816 views
The SWSL @ retreat 2011 presentation summarized the Sensor Web, Web-based geoprocessing & Simulation Lab group. The group has 6 working members, 1 postdoc, and 10 assistants. Their research focuses on enabling live geoinformation through efficient origin, integration, and communication of sensor data. This includes work on sensor semantics, processing data streams, crowd-sourcing platforms, and approaches like a RESTful SOS proxy and ifgiCopter project. The group has ongoing collaborations and publications advancing work on live geoinformation systems.
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to SWSL @ ifgi retreat 2011
Similar to SWSL @ ifgi retreat 2011 (20)
More from Theodor Foerster
More from Theodor Foerster (6)
Recently uploaded
Recently uploaded (20)
SWSL @ ifgi retreat 2011
- 1. SWSL @ retreat 2011 - Sensor web, Web-based geoprocessing & Simulation Lab Arne, Bastian, Benjamin, Christoph, Matthes, Theodor & Thomas
- 2. The faces
- 5. Towards Live Geoinformation Origin of Geodata Integration of Geodata and Processes Communication of Geodata
- 11. Research Projects Origin Integration Communication ifgiCopter Crowd-sourcing platforms Data Models & schemas Sensors & semantics Processing & clouds
- 14. Sensors & Semantics (contd.) Arne Broering - [email_address] RESTful SOS Proxy for Linked Sensor Data
- 17. ifgiCopter
- 22. Discussion Towards Live Geoinformation Origin of Geodata Integration of Geodata and Processes Communication of Geodata
Editor's Notes
- SOA, Design, Programming,
- This research enables the semantically-enabled plug & play of sensors This means ensuring the semantic matchings between certain concepts of the Sensor Web when adding new sensors. In general, plug & play aims at reducing or avoiding any manual configuration when plugging new components into a system. With respect to Sensor Observation Services, it should be possible to select and register sensors with minimal human interaction. General procedure: As aforementioned, a new sensor can be added to the Sensor Web by using the RegisterSensor operation of a Sensor Observation Service. The metadata description of the sensor is passed along with the operation in a SensorML file. It defines input and output of the sensor. An example for a necessary matching is that those inputs and outputs of sensors have to match the observed property of the features of interest, the computational representation of a real world entity residing on the Sensor Web. The symbol and the semantics of the output produced by a sensor (and stated in its SensorML) have to comply with the symbol and semantics of the property of the feature of interest. Currently, the SOS operator has to ensure manually that sensor output and feature property match. E.g.: WindDirection matches prevailing_direction The example of wind direction shows that answering this question can be challenging. Wind direction can be defined as the direction from which the wind blows, or as the direction the wind is blowing to.
- We developed an SOS Proxy application which applies the RESTful communication paradigm. As shown in the figure here, our RESTful SOS proxy encapsulates the SOS and transforms data coming from the SOS to RDF. While requesting data from the SOS requires complex Web Service procedure calls (the GetObservation operation has to be exectued), the RESTful SOS enables access to sensor data via a simple HTTP GET call – i.e. by following a URL. Then the RESTful SOS transforms the received HTTP GET call to the appropriate SOS query and transofmrs the data from the SOS (e.g. observations encoded in O&M) to RDF Hence the RESTful SOS can make sensor data available on the Linked Data Web LINKS: URIs for observations are used to provide links from sensor and feature descriptions to their related observations. This ability to collect observations by following links offered by the RESTful SOS proxy replaces the extensive filtering capabilities of the original SOS interface.