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 2 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 L Location of AIRS profiles @ 09Z NAM analysis @ 06Z L Example: 14 Feb 2007 Surface Weather @ 12Z L Retain bulk of observations in this region Retain less observations in this region H H H

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 (O&M) – 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. 6 Use Case 1: Near Real Time AIRS Assimilation Integrated with SPoRT Processes NAM 00Z 6h forecast completed at NCEP WRF Model Forecast @ T2 Data Assimilation and Forecasting SensorML Process SAS Listener AIRS Pre- process AIRS Preprocessing SensorML Process SOS Client PEA Event Filters SAS Client SAS SOS adapter Satellite Intersect SensorML SOS Event Identification Data Server AIRS Observations SOS Data Server NAM forecast @ T1 SOS WRF prep and forecast for background SOS Client Advanced Regional Prediction System Data Analysis System Notify modelers analysis available AIRS overpasses available from U Wisc External data sources, models Processing components SWE Interface components

7. 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 DatasetRandom SubsampleSMART SubsetCombined Thinning Methods

8. 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 http://smartdev.itsc.uah.edu/documents/wsdl/AlertSearchService.wsdl

9. 9 Case Study Visualization

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