Data Assimilation Decision Making Using Sensor Web Enablement

1
Data Assimilation Decision Making Using Sensor
Web Enablement

• M. Goodman, G. Berthiau, H. Conover,
• X. Li, Y. Lu, M. Maskey, K. Regner, B. Zavodsky,
• R. Blakeslee, M. Botts, G. Jedlovec
• NASA Marshall Space Flight Center and
• The University of Alabama in Huntsville
• 5 May 2009
• SPoRT Data Assimilation Workshop

2
Motivation

• Where and when satellite data are assimilated can
  be dependent on a number of factors
• Swath location, coverage, and time
• Position of storms relative to swath location
• Data availability and volume
• It may not be computationally cost-effective to
  assimilate all observations if some are not in
  meteorologically significant areas
• Retain a bulk of the observations for data
  assimilation in meteorologically-significant
  regions (e.g., low pressure systems) to conserve
  computational resources

Retain less observations in this region
Example 14 Feb 2007
H
H
H
Retain bulk of observations in this region
3
Technology Introduction

• The Open Geospatial Consortium, Inc (OGC) is an
  international industry consortium of 380
  companies, government agencies and universities
  participating in a common effort to develop
  publicly available interface specifications and
  encodings for geospatial data.
• Open Standards development by consensus process
• Interoperability Programs provide end-to-end
  implementation and testing before spec approval
• Reason for Sensor Web Enablement thousands of
  sensors (in-situ or remote sensing, fixed or
  mobile) out in the world which data can be of
  interest to researchers, companies, and to the
  general public. For that, those data need to be
  accessible through the web in a standard way.

4
Basic Needs for SWE

• Quickly discover sensors and sensor data (secure
  or public) that can meet my needs location,
  observables, quality, ability to task
• Obtain sensor information in a standard encoding
  that is understandable to everybody
• Readily access sensor observations in a common
  manner, and in a form specific to my needs
• Task sensors, when possible, to meet my specific
  needs
• Subscribe to and receive alerts when a sensor
  measures a particular phenomenon

5
SWE Specifications

• Set of standard XML-based open-source
  technologies for multi-sources data processing
  and integration.
• Information Models and Schema
• Sensor Model Language (SensorML) for In-situ and
  Remote Sensors - Core models and schema for
  observation processes support for sensor
  components, geo-registration, response models,
  post measurement processing
• Observations and Measurements (OM) Core models
  and schema for observations
• SWE Common Data Model Self-describing data
  model for transferring data in an unambiguous
  fashion, support xml, ascii and binary encodings,
  as well as encryption and compression, support
  native formats, common to all encodings and
  services.
• Web Services
• Sensor Observation Service - Request time series
  of observations from a sensor or sensor
  constellation based on the features of interests,
  the observed properties
• Sensor Alert Service Subscribe to alerts based
  upon sensor observations
• Sensor Planning Service Request collection
  feasibility and task sensor system for desired
  observations
• Web Notification Service Manage message dialogue
  between client and Web service(s) for long
  duration (asynchronous) processes
• Sensor Registries Discover sensors and sensor
  observations

6
Use Case 1 Near Real Time AIRS Assimilation
Integrated with SPoRT Processes
AIRS overpasses available from U Wisc
AIRS Preprocessing
Event Identification
SensorML Process
Data Server
SensorML Process
Data Server
Event Filters
Satellite Intersect
PEA
SOS Client
SAS Listener
SOS Client
NAM forecast _at_ T1
SAS Client
SensorML
SOS
AIRS Pre-process
SOS
Notify modelers analysis available
NAM 00Z 6h forecast completed at NCEP
Data Assimilation and Forecasting
Advanced Regional Prediction System Data Analysis
System
WRF Model Forecast _at_ T2
WRF prep and forecast for background
7
Scientific Evaluation Plan

• One aspect of the project is to create a set of
  thinned observation data to improve analysis
  computation runtimes
• Lazarus et al. (in preparation) show that only
  retaining observations in meteorologically
  significant areas is not sufficient to reproduce
  the analysis from a full satellite data set
• Homogeneous regions also must be sampled
• Combination of SMART and random/sub-sampling
• Compare intelligent approach (SMART) to an
  operational approach (e.g., simple sub-sampling)
• Verification with RMSE and Squared Analysis
  Increment of each approach against analyses with
  the full data set

Full AIRS Dataset
Random Subsample
SMART Subset
Combined Thinning Methods
7
8
Case Study Visualization

• Real time process populates the database with
  alerts and events including the layer information
  for the phenomena
• Case Study Tool uses Web Service
• Searches for Phenomena Alerts
• Search for Corresponding AIRS intersection alerts
• Inputs Run date, Run hour, and Phenomenon Type
• Overlays Alert information on a Map
• Layer used of Phenomenon detection is also
  overlaid.
• Uses Web Service
• Tool available for use at
• http//smartdev.itsc.uah.edu/casestudy/
• Web Service available for use at

8
9
Case Study Visualization
9
10
Conclusions

• The SMART group is using SWE protocols to solve
  the science problem of assimilating satellite
  data only at times and in regions where the data
  can aid in the DA process
• Swath location, coverage, and time
• Position of storms relative to swath location
• Data availability and volume
• SWE protocols allow standard and publically
  accessible data to be made available via the web
  for researchers in various industries
• Case study tool allows researchers to select
  appropriate case study dates that may lead to
  best success based on location of satellite data
  compared to the location of significant weather
  events