1. Weather prediction& Flooding: Practical issues of Sensor Web services implementation and gridification Prof. Natalia Kussul, NSAU WGISS-25, Sanya

2. Outline Sensor Web: overview Test case: floodings SensorML: experience Sensor Observation Service: experience Sensor Web: gridification Our plans

3. Sensor Web: the purpose Integration of heterogeneous sensors into the information infrastructure Sensors discovery and data access Composition of dataflows between system components Events triggering by sensors conditions

4. OGC O&MObservations & MeasurementsApproved SensorMLSensor Model LanguageApproved TransducerMLTransducer Model LanguageApproved OGC SOSSensor Observations ServiceApproved OGC SPSSensor Planning ServiceApproved OGC SASSensor Alert ServiceIn progress OGC WNSWeb Notification ServicesIn progress OpenGIS Standards SW Enablement working group at OGC have developed a number of standards governing different aspects of Sensor Web

5. Test Case The task under study is flooding in different regions of world Particular test case is floodings in Mozambique

6. Test Case: Weather Prediction data flow

7. Test case: Flood Monitoring data flow

8. Test Case: data sources ASAR MODIS MERIS LandSat DEM

9. Test Case: SW perspective

10. Test Case: Mozambique http://floods.ikd.kiev.ua

11. SensorML Sensor modeling language is the cornerstone of all SW services It provides comprehensive description of sensor parameters and capabilities It can be used for describing different kind of sensors: –Stationary or dynamic –Remote or in-situ –Physical measurements or simulations

12. SensorML: example.............. <swe:Quantity definition= "urn:ogc:def:phenomenon:temperature"/> <swe:Quantity definition= "urn:ogc:def:phenomenon:pressure"/> <swe:Quantity definition= "urn:ogc:def:phenomenon:windSpeed"/>........................... <swe:Time definition="urn:ogc:def:phenomenon:time uom="urn:ogc:def:unit:iso8601"/> <swe:Quantity definition="urn:ogc:def:phenomenon:temperature uom="urn:ogc:def:unit:celsius"/> <swe:Quantity definition="urn:ogc:def:phenomenon:pressure uom="urn:ogc:def:unit:bar" scale="1e-3"/> <swe:Quantity definition="urn:ogc:def:phenomenon:windSpeed uom="urn:ogc:def:unit:meterPerSecond"/>.............

13. SensorML: WRF model Modeling and simulation are very important parts of environmental monitoring Sensor Web infrastructure should be able to integrate modeling data in convenient way We have tried to describe weather modeling process using WRF numerical model in terms of SensorML

14. SensorML: WRF model An example of single model input in SensorML: 1 30 202 219

15. SensorML: WRF model There are nearly 50 inputs and 20 outputs for basic WRF configuration Each of them requires quite significant amount of XML code to be properly described It would be great if next revision of SensorML will include some elements for simpler description of multidimensional data Another negative issue is inconsistency between SML specification, published XML schemas and educational materials

16. Sensor Observation Service We have studied two possible implementations of Sensor Observation Service (SOS) for serving temperature sensors data Implementations under study were: –UMN Mapserver v5 (http://mapserver.gis.umn.edu/) –52North SOS (http://52north.org/) Lesson learnt: there isnt (yet) really good and reliable solution for serving data through SOS protocol However for some cases 52Norths implementation provides good experience

17. Sensor Observation Service UMN Mapserver (as SOS server) –Pros: Very good and reliable abstraction for different data sources (raster files, spatial databases, WFS, etc) Simple application model (CGI executable) Wide set of features beside SOS Open software –Cons: SOS support is declared but far from being working Poor documentation on SOS topic Strange plans for future development (automatic SensorML generation)

18. Sensor Observation Service 52North SOS –Pros: SOS implementation is stable and complete Platform-independent (Java-based) A part of wider SW implementations stack (SPS, SAS) Open software Source code is clean and easily reusable –Cons: No data abstraction: the only data source is relational database of specific structure Database structure is far from optimal (strings as primary keys, missed indexes, etc) Complex application model (Java web application)

19. Sensor Observation Service We have used 52North implementation for building a testbed SOS server: –http://web.ikd.kiev.ua:8080/52nsos/soshttp://web.ikd.kiev.ua:8080/52nsos/sos Server is providing data of temperature sensors over Ukraine and South Africa region Data comes from PostGIS database with some tweaks to make is compatible with 52North database structure (VIEWS, index tables, etc) Performance is quite good for our DB. Yet, for other DBs such adaptations could lead to unacceptable drops in performance

20. Sensor Observation Service

21. Example of single SOS measurement... 2005-04-14T04:00:00+04 WMO33506 34.55 49.6 10.9

22. Sensor Observation Service... and the whole time serie of observations 2005-03-14T21:00:00+03,33506,-5@@2005-03- 15T00:00:00+03,33506,-5.2@@2005-03-15T03:00:00+03,33506,- 5.5@@2005-03-15T06:00:00+03,33506,-4.6@@2005-03- 15T09:00:00+03,33506,-2.2@@2005-03- 15T12:00:00+03,33506,1.7@@2005-03- 15T15:00:00+03,33506,1.7@@2005-03- 15T18:00:00+03,33506,2.4@@2005-03-15T21:00:00+03,33506,- 0.7@@2005-03-16T00:00:00+03,33506,-1.4@@2005-03- 16T03:00:00+03,33506,-1.1@@2005-03-16T06:00:00+03,33506,- 1.1@@2005-03-16T09:00:00+03,33506,-1.3@@2005-03- 16T12:00:00+03,33506,0.5@@2005-03- 16T15:00:00+03,33506,1.7@@2005-03- 16T18:00:00+03,33506,1.5@@

23. Gridification: rationale Sensor Web services like SOS, SPS and SAS can benefit from integration with Grid platform like Globus Toolkit Advantages includes: –Sensors discovery through Index Service –High-level access to XML description –Convenient way for implementation of notifications and event triggering –Reliable data transfer for large datasets –Enforcement of data and services access policies

24. Gridification: implementation We have developed a testbed SOS service using the Globus Toolkit platform For now, service works as proxy translating and redirecting user request to usual SOS-server

25. Gridification: implementation We have developed a testbed SOS service using the Globus Toolkit platform For now, service works as proxy translating and redirecting user request to usual SOS-server Next version should have in-service implementation of SOS-server functionality

26. Gridification: problems The main problem of implementation of OGC Grid service lies in complexity of XML schema used According to OGC SOAP Interoperability Experiment, none of available SOAP binding tools were able to parse OGC schemas completely (year 2003) Situation havent improved significantly till now The main problem of complexity is GML data types

27. Gridification: problems This problems could be solved by using custom serializers for services XML data However this way is complex in implementation and debugging Lets hope that the situation will improve from both sides

28. Out plans Our future works include: Implementation of Mozambique test case in terms of Sensor Web To participate in IC "Space and Major Disasters with architectural proposals To provide stable Grid-based implementation of Sensor Web services To collaborate with International Red Cross organization within its tasks

29. Our plans: Red Cross tasks

31. Thank you!