Prof. Natalia Kussul, NSAU WGISS-25, Sanya

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. 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: SW perspective

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

10. 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

11. SensorML: example .............. <inputs> <InputList> <input name="ambiantTemperature"> <swe:Quantity definition= "urn:ogc:def:phenomenon:temperature"/> </input> <input name="atmosphericPressure"> <swe:Quantity definition= "urn:ogc:def:phenomenon:pressure"/> </input> <input name="windSpeed"> <swe:Quantity definition= "urn:ogc:def:phenomenon:windSpeed"/> </input> </InputList> </inputs> .............. ............. <outputs> <OutputList> <output name="weatherMeasurements"> <swe:DataGroup> <swe:component name="time"> <swe:Time definition="urn:ogc:def:phenomenon:time“ uom="urn:ogc:def:unit:iso8601"/> </swe:component> <swe:component name="temperature"> <swe:Quantity definition="urn:ogc:def:phenomenon:temperature uom="urn:ogc:def:unit:celsius"/> </swe:component> <swe:component name="barometricPressure"> <swe:Quantity definition="urn:ogc:def:phenomenon:pressure“ uom="urn:ogc:def:unit:bar" scale="1e-3"/> </swe:component> <swe:component name="windSpeed"> <swe:Quantity definition="urn:ogc:def:phenomenon:windSpeed“ uom="urn:ogc:def:unit:meterPerSecond"/> </swe:component> </swe:DataGroup> </output> </OutputList> </outputs> .............

12. 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

13. SensorML: WRF model An example of single model input in SensorML: <sml:input name="QVAPOR"> <swe:DataArray definition="urn:ogc:def:phenomenon:time"> <swe:elementCount> <swe:Count definition="urn:ogc:def:property:OGC:numberOfPixels"><swe:value>1</swe:value></swe:Count> </swe:elementCount> <swe:elementType name=""> <swe:DataArray definition="urn:ogc:def:phenomenon:altitude"> <swe:elementCount> <swe:Count definition="urn:ogc:def:property:OGC:numberOfPixels"><swe:value>30</swe:value></swe:Count> </swe:elementCount> <swe:elementType name=""> <swe:DataArray definition="urn:ogc:def:phenomenon:latitude"> <swe:elementCount> <swe:Count definition="urn:ogc:def:property:OGC:numberOfPixels"><swe:value>202</swe:value></swe:Count> </swe:elementCount> <swe:elementType name=""> <swe:DataArray definition="urn:ogc:def:phenomenon:longtitude"> <swe:elementCount> <swe:Count definition="urn:ogc:def:property:OGC:numberOfPixels"><swe:value>219</swe:value></swe:Count> </swe:elementCount> <swe:elementType name=""> <swe:Quantity definition="urn:ogc:def:phenomenon:QVAPOR"><swe:uom code="kg_kg-1"/></swe:Quantity> </swe:elementType> </swe:DataArray> </swe:elementType> </swe:DataArray> </swe:elementType> </swe:DataArray> </swe:elementType> </swe:DataArray> </sml:input>

14. 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

15. 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 isn’t (yet) really good and reliable solution for serving data through SOS protocol • However for some cases 52North’s implementation provides good experience

16. 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)

17. 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)

18. Sensor Observation Service • We have used 52North implementation for building a testbed SOS server: • http://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

19. Sensor Observation Service

20. Sensor Observation Service • Example of single SOS measurement... <om:Measurement gml:id="o255136"> <om:samplingTime> <gml:TimeInstant xsi:type="gml:TimeInstantType"> <gml:timePosition>2005-04-14T04:00:00+04</gml:timePosition> </gml:TimeInstant> </om:samplingTime> <om:procedure xlink:href="urn:ogc:object:feature:Sensor:WMO:33506"/> <om:observedProperty xlink:href="urn:ogc:def:phenomenon:OGC:1.0.30:temperature"/> <om:featureOfInterest> <sa:Station gml:id="33506"> <gml:name>WMO33506</gml:name> <sa:sampledFeature xlink:href=""/> <sa:position> <gml:Point> <gml:pos srsName="urn:ogc:crs:epsg:4326">34.55 49.6</gml:pos> </gml:Point> </sa:position> </sa:Station> </om:featureOfInterest> <om:result uom="celsius">10.9</om:result> </om:Measurement>

21. Sensor Observation Service • ... and the whole time serie of observations <om:result>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@@</om:result>

22. 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

23. 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

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 • Next version should have in-service implementation of SOS-server functionality

25. 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 haven’t improved significantly till now • The main problem of complexity is GML data types

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

27. 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 it’s tasks

28. Our plans: Red Cross tasks

30. Thank you!