Weather prediction

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

• ..............
• ltinputsgt
• ltInputListgt
• ltinput name"ambiantTemperature"gt
• ltsweQuantity definition
• "urnogcdefphenomenontemperature"/gt
• lt/inputgt
• ltinput name"atmosphericPressure"gt
• ltsweQuantity definition
• "urnogcdefphenomenonpressure"/gt
• lt/inputgt
• ltinput name"windSpeed"gt
• ltsweQuantity definition
• "urnogcdefphenomenonwindSpeed"/gt
• lt/inputgt
• lt/InputListgt
• lt/inputsgt
• ..............

............. ltoutputsgt ltOutputListgt ltoutput
name"weatherMeasurements"gt ltsweDataGroupgt
ltswecomponent name"time"gt ltsweTime
definition"urnogcdefphenomenontime
uom"urnogcdefunitiso8601"/gt
lt/swecomponentgt ltswecomponent
name"temperature"gt ltsweQuantity definition
"urnogcdefphenomenontemperature
uom"urnogcdefunitcelsius"/gt
lt/swecomponentgt ltswecomponent
name"barometricPressure"gt ltsweQuantity
definition"urnogcdefphenomenonpressure
uom"urnogcdefunitbar" scale"1e-3"/gt
lt/swecomponentgt ltswecomponent
name"windSpeed"gt ltsweQuantity
definition"urnogcdefphenomenonwindSpeed
uom"urnogcdefunitmeterPerSecond"/gt
lt/swecomponentgt lt/sweDataGroupgt
lt/outputgt lt/OutputListgt lt/outputsgt .............
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
• ltsmlinput name"QVAPOR"gt
• ltsweDataArray definition"urnogcdefphenomenon
  time"gt
• ltsweelementCountgt
• ltsweCount definition"urnogcdefpropertyOGC
  numberOfPixels"gtltswevaluegt1lt/swevaluegtlt/sweCou
  ntgt
• lt/sweelementCountgt
• ltsweelementType name""gt
• ltsweDataArray definition"urnogcdefphenomen
  onaltitude"gt
• ltsweelementCountgt
• ltsweCount definition"urnogcdefpropertyO
  GCnumberOfPixels"gtltswevaluegt30lt/swevaluegtlt/swe
  Countgt
• lt/sweelementCountgt
• ltsweelementType name""gt
• ltsweDataArray definition"urnogcdefphenom
  enonlatitude"gt
• ltsweelementCountgt
• ltsweCount definition"urnogcdefproperty
  OGCnumberOfPixels"gtltswevaluegt202lt/swevaluegtlt/s
  weCountgt
• lt/sweelementCountgt
• ltsweelementType name""gt
• ltsweDataArray definition"urnogcdefphen
  omenonlongtitude"gt

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.ua8080/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
Sensor Observation Service

• Example of single SOS measurement...
• ltomMeasurement gmlid"o255136"gt
• ltomsamplingTimegt
• ltgmlTimeInstant xsitype"gmlTimeInstantTyp
  e"gt
• ltgmltimePositiongt2005-04-14T04000004lt/gm
  ltimePositiongt
• lt/gmlTimeInstantgt
• lt/omsamplingTimegt
• ltomprocedure xlinkhref"urnogcobjectfeatu
  reSensorWMO33506"/gt
• ltomobservedProperty xlinkhref"urnogcdefp
  henomenonOGC1.0.30temperature"/gt
• ltomfeatureOfInterestgt
• ltsaStation gmlid"33506"gt
• ltgmlnamegtWMO33506lt/gmlnamegt
• ltsasampledFeature xlinkhref""/gt
• ltsapositiongt
• ltgmlPointgt
• ltgmlpos srsName"urnogccrsepsg4326"gt3
  4.55 49.6lt/gmlposgt
• lt/gmlPointgt
• lt/sapositiongt

22
Sensor Observation Service

• ... and the whole time serie of observations
• ltomresultgt2005-03-14T21000003,33506,-5_at__at_200
  5-03-15T00000003,33506,-5.2_at__at_2005-03-15T03000
  003,33506,-5.5_at__at_2005-03-15T06000003,33506,-4.6
  _at__at_2005-03-15T09000003,33506,-2.2_at__at_2005-03-15T12
  000003,33506,1.7_at__at_2005-03-15T15000003,33506,
  1.7_at__at_2005-03-15T18000003,33506,2.4_at__at_2005-03-15T
  21000003,33506,-0.7_at__at_2005-03-16T00000003,335
  06,-1.4_at__at_2005-03-16T03000003,33506,-1.1_at__at_2005-0
  3-16T06000003,33506,-1.1_at__at_2005-03-16T0900000
  3,33506,-1.3_at__at_2005-03-16T12000003,33506,0.5_at__at_20
  05-03-16T15000003,33506,1.7_at__at_2005-03-16T18000
  003,33506,1.5_at__at_lt/omresultgt

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
30
(No Transcript)
31

• Thank you!