I Source of Acquisition I NASA Goddard Space Flight Center

Sensor Web Interoperability Testbed Results Incorporating Earth Observation Satellites

Stuart Frye Dan Mandl Nadine Alameh, Ph.D. Myra Bambacus NASA EO-1 Mission NASA EO-1 Mission MobiLaps /NASA GI0 . NASA GI0

Stuart. fiye@gs fc .nasa. gov daniel .j .mandl@gs fc .nasa. gov nadines. alameh@nasa. gov myra.j .bambacus@nasa.gov

Pat Cappelaere . Stefan Falke Linda Derezinski Peisheng Zhao

pat@cappelaere.com stefan@wustl. edu linda@i-sol.biz pzhao@gmu.edu I

Vightel Inc. Wash University S t. Louis Integrated Business Solutions George Mason University

Greenbelt, Maryland, USA

Abstract-This paper describes an Earth Observation Sensor Web scenario based on the Open Geospatial Consortium’s Sensor Web Enablement and Web Services interoperability standards. The scenario demonstrates the application of standards in de- scribing, discovering, accessing and tasking satellites and ground- based sensor installations in a sequence of analysis activities that deliver information required by decision makers in response to national, regional or local emergencies.

Index Term-NASA, Geoscience, Services, Interoperability, Earth Science, Architecture, Sensor Web

I OVERVIEW

N A S A has been experinienting with autonomous sensor webs to improve science return on its earth observing capabili- ties [l]. Over the last five years, significant research has been performed in this area includes a wide range of scientific ap- plications and national priorities [2 ] .

In support of the Open Geospatial Consortium’s (OGC) Web Services testbed Phase 4 (OWS-4), a team of researchers and technologists in the Eai-th observing field got together to apply the OGC services and sensor web standards in a scenario involving interoperable discoveiy, access and integration of geoscience data and sensor results. The goal was to showcase the applications of OGC standards within the Earth Observa- tion community and to demonstrate the value of interoperabil- ity in that environment [3].

The team consisted of the NASA Goddard Space Flight Center (GSFC) Geoscience Interoperability Office (GIO) and the Real-time Software Branch, Washington University at St. Louis (WUSTL), Vightel Corporation, Noblis (formerly Mi- tretek), Innovative Solutions Inc., the Jet Propulsion Labora- tory (JPL), and George Mason University (GMU).

The scenario aimed at providing Geographic Information

System (GIs)-ready sensor and other inftastructure data to support a response to a simulated emergency. The particular subset of OWS-4 results accomplished by the Earth Observa- tion team used standard web services to task remote sensing satellites and to deliver hyperspectral data of the target area as user-customized classifier outputs. To find out more about the overall OWS-4 results, go to the http://www.opengeospatial.org website.

The following suite of OGC standards were implemented

- Sensor Observation Service (SOS) - Sensor Planning Service (SPS) - Sensor Alert Service (SAS) - Web Processing Service (WPS) - - Web Coverage Service (WCS) - Web Feature Service (WFS) - Web Map Service (WMS)

by the various components of the scenario

Catalog Service for the Web (CSW)

The scenario demonstrated the value of interoperability in - Quickly discovering relevant and up-to-date assets,

services and sensors Ordering real-time custom products with guaranteed delivery to any location in the world Subscribing to data/service/sensor feeds and getting real-time notifications when information is available Integrating needed data on the web for fiee (using a special click-through license for trusted identity pro- viders)

-

-

-

II. USER/OPERATIONS CONCEPT

The NASA-centric scenario linked the sensor services capa- bilities by taslung multiple satellites to image the target site based on a request from an emergency response analyst [4]. One of the satellites used in the scenario demonstration was

NASA’s Earth Observing-1 (EO-1; http://eol .gsfc.nasa.gov) satellite which, due to having the nearest next in-view time for the target, resulted in being the satellite that was tasked.

The scenario (Figure 1) began by allowing the user to iden- tLfy the target location on a web map client selecting the area of interest and then automatically using the latitude and longi- tude returned by the map to generate a tasking request for tlie EO-1 satellite. The satellite images of the target were taken on the first available overflight opportunity as determined by the Sensor Planning Service for each of the satellites. Data proc- essing activities were then chained together as a sequence of processing steps into a workflow: that retrieved the Level 1G image data from the satellite Sensor Observation Service, sub-

, setted it, re-projected the subset into a different grid required by an algorithm, ran the algoritlm against the data, and dis- played the output on a web map client.

All data, services and analysis outputs used in the process were discovered by querying the NASA Earth Science Gate- way (ESG) [ 5 ] . ESG facilitates discovery and access of NASA’s extensive Earth Scieiice information systems and re- search results. In doing so, ESG suppoits the science cornniu- nity and NASA’s partners. ESG and the other elements of the

ESG in particular provides local and distributed search and harvest; visualization of remote data via Web services; pub- lishing of data and services, and user personalization. In order to €unction as a GEOSS interoperability platform, ESG is in- corporating standards-based technologies to support the ob- serving, processing, and dissemination methods provided by various parties while retaining their ownership and operational

es for such purposes.

111. SATELLITE TASKING AND MONITORING

The EO-1 satellite tasking and data delivery part of the testbed was based on the OGC standard Geobliki data node providing tasking access and data delivery of EO-1 hyperspectral data to a sequence of processing nodes that run a flood classifier thumbnail generator. The Geobliki data node (developed by Vightel and Innovative Solutions) [7] contains a Sensor Ob- sei-vation Service (SOS), a Sensor Processing Service (SPS), and a Sensor Alert Service (SAS).

The Geobliki SPS allowed users to query the EO-1 orbital predictions to determine tasking opportunities for acquiring the target location on an upcoming orbit. The lat/lon values sup- plied by the map query to the EO-1 planning web site returned

. NASA Earth Sciences Gateway

Publishlng to SAS

E01 GEOBLIKI

Figure 1 OWS-4 Earth Observing Demo Scenario

testbed implement consensus-based, publicly accessible stan- the next 5 in-views for the satellite. In addition, another satel- dards for maximum interoperability, and employ web services lite SPS provided by the SPOT mission participants in support of Service Oriented Architectures. As such, they can (http://services.eoportal.org) in the OWS-4 testbed also re- contribute to larger System-of-Systems concepts such as the turned tasking opportunities. The second SPS demonstrated Global Earth Observing System of Systems (GEOSS) [GI. the ability of discovering taskable assets across the earth ob-

serving domain. In the OWS-4 demonstration, the next EO-1

in-view happened sooner than that of the SPOT satellite for the target area, so as a result, a tasking request was generated and submitted to the EO-1 priority replacement web page.

Geobliki monitored the EO-1 operations status web site to determine when the submittal changed fi-om "pending" to "exe- cuted" and then submitted a request to the USGS data process- ing center to order the EO-1 Level 1G data product resulting from that acquisition. When the Level 1G product became available, an Eniail was sent to the Geobliki client. The Geob- liki retrieves the data product and supplies that data to the workflow engine to start the classifier run.

w. WORKFLOW AND WEB PROCESSING SERVICE

The flood classifier algorithm was wrapped in a standard proc- essing service by the WUSTL developers providing standard OGC Web Processing Service (WPS) interfaces for GetCapa- bilities, Describeprocess, and Execute (http://webapps.datafed.net). The WPS capabilities were documented in an XML foilnatted package that was published and harvested by sensor web registries (Le., the ESG). Input sources for the detection algorithm, were also identified in the WPS description so that users could search for the data nodes that supply that type of data and and in addition, could request additional runs on-demand. In addition, those capabilities could be imported and modified to create new outputs. In this workflow, the WPS is a binary grid processing service. The binary operator service conibiiied two grids as inputs, per- formed a calculation on them, and generated an output grid.

The Business Processing Execution Language (BPEL) was used as the workflow engine in the testbed, which required that interfaces to the processing service must use SOAP/WSDL protocols. As a result, the execution of the classifier algorithm processing service was conducted thsough SOAP/WSDL inter- faces rather than the OGC WPS Execute interface.

The processing service chain was controlled by the GMU BPEL engine that retrieved 2 selected bands from the Level 1G Hyperion data product provided by the Geobliki data node (http://geobrain.laits.gmu.edu). Those two single band GEOTIFF files were i-un through a Web Coordinate Transfor- mation Service (WCTS) to convert them from Universal Transverse Mercator (UTM) projection to WMS-84 projection needed by the algorithm, which then were fed into a flood de- tection algorithm processing service. This process resulted in a final output product which was cataloged.

Figure 2 outlines the steps of the BPEL workflow execution, . whch were translated into a pseudo-code script that executed the desired workflow. In addition, a WPS capabilities docu- ment was cataloged and contained the location of the open source algorithm, the description of the output feature, and the

description of the input sensors.

Pamer Unkr Putnar unit

Figure 2 BPEL Workflow Diagram

v. CONCLUSIONS

The demonstration proved to be successful in showing how disparate systems and components can come together meaning- fully and on-demand in order to accomplish scenario objec- tives and to assist the decision makers in getting the data that they need rapidly. The demonstration success is attributed to the fact that each systedcomponent participating in the sce- nario implemented consensus-based open standards and ser- vices. Interoperability and web services enabled the disparate systems/component to work together to exchange data and infomation.

In terms of future work, the demonstration highlighted the

Geospatial Digital Management standards in the sen- sor tasking step in order to make sure that only au- thorized users are able to task and control the sensors Further decouple services in the BPEL engine in or- der to create a more flexible and extensible overall system

- ' Efficient methods to task sensors in parallel to sup- port further international collaboration Better understanding of requirements for data access of "raw" and "processed" sensor data, including the

need for the following: -

-

-

relationship between OGC SOS, WCS and WPS specificajions Continued work on standards-based web service ori- ented infraslnictures to provide on-demand data to decision makers

-

VI. FUTURE WORK

During the Spring and3mnmer of 2007, the sensor web test- bed will be expanded to link satellites, an unmanned aerial vehicle (UAV), and in-situ ground sensors in an ad hoc virtual observatory casting evely node as a web service that complies with OGC standards. The next scenario is in support of wild- fire management.

The scenario will start with a set of large wildfxes of na- tional impoi-tance being selected for sensor web coverage in the Western United States. The selected fires will fall within an upcoming UAV flight path. Local weather data for the demo will be provided by Remote Access Weather Station (RAWS) sensors installed in field locations along the UAV flight line. The Terra satellite Moderate Resolution Imaging Spectroradiometer (MODIS) and Advanced Spaceborne Thermal Emission and Reflection Radiometer (ASTER) in- struments direct readouts of hot pixels within the flight path near the selected wildfires will be used to identify the most recent fire locations. EO-1 and UAV data acquisitions of se- lected targets will be requested based on the most recent fire locations and data products will be automatically deliveted according to user-customized subsetting and classification specifications.

Wildfires will be selected from the National Interagency Fire Center (http://www.nifc.gov/) daily situation postings.' At this website, each fire is identified by fire name, origination point latitude/longitude, and reported start time. The originat- ing location for each of the fires will be retrieved by a web client. The originating fire locations within the UAV flight path *ll serve as the starting point for constructloll of se- quences of activities that identify the most recent location of each wildfire and then blanket those locations with autono- mously triggered follow-up acquisitions by the higher resolu- tion assets.

MODIS direct readout hot pixel detections will be provided by the direct readout antenna in Salt Lake City at the Forest Service Remote Sensing Applications Center (RSAC). ASTER classifier outputs will be available at the Jet Propul- sion Laboratory (EL) ASTER website and will be used to provide thermal detection data of particular targets at 30 me- ters per pixel instead of 250 meters per pixel that is provided by MODIS.

The calculated locations and pixel values from ASTER and

MODIS will be collected by a web client based on a query for wildfires. The hot pixel data will be rendered as multi-colored JPG files and overlaid on a map.

The recent fire locations will be fed into SPS's for EO-$ and the UAV and the exact targeting opportunities will be calcu- lated based on the MODIS and ASTER detection results. Tasking requests will be constructed and submitted to the SOS's for EO-1 and the UAV to trigger the nearest available data collection opportunity of those targets based on the in- formation provided by the SPS. The tasking requests will con- tain the location and timing of the future targets of opportunity relative to the flight lines of each platfonn and in addition will contain requests to run on-board classifiers that will execute on EO-1 and the UAV immediately after the data collection has occurred.

The EO-1 and UAV websites will be monitored until con- firmation that the image requests have been executed. Auto- mated retrieval of the thumbnails produced on-board EO-1 and the UAV will be performed by the client as soon as those prod- ucts are available on their respective data nodes. On-board classifier results will be retrieved by the client based on identi- fying that the target acquisition has been executed. If the on- board results indicate detection of a phenomena, an alert will be set autonomously by the EO-1 and UAV SOS's. The on- board thermal thumbnail will be cowertearendered ihto a .jpg file with a legend by a web rendering service so the results can be displayed on a map by the client.

Automated delivery of full Level 1R and Level 1G data products, high resolution browse imagery, and other detection classifier outputs from WPSDVCTS implementations on the ground will also be chained together in workflow sequences. Those results will be made available for retrieval or automati- cally delivered, depending on the size of the likely transfer (large files retrieved, small files delivered).

The UAV is an Ikhana class (civilian version of the General Atomics Predator-B) that will fly out of Dryden with instru- inents from Ames Research Center (see littp://suborbital.nasa.gov/platfo~/aircraft/.html for more information).

EO-1 and UAV Level 1G data will be retrieved by a work- flow chain which will run web processing services and deliver classifier results consisting of entire images, not just the thumbnails for target area.

The RAWS outputs fiom any installations near the fire are displayed on the web map client along with all the overlaid data products (on-board outputs, browse images, level 1 prod- ucts, classifier outputs, etc ...) from EO-1 and the UAV.

EO-1 alerts will be used to trigger the UAV and UAV alerts will be used to trigger EO-1 acquisitions. This will be in addition to the use of MODIS and ASTER to trigger EO-1 and the UAV. All of this will occui- in the same 20 hour block.

Cloud cover predictions from the Draper Lab EPOS server will be used to distinguish between multiple potential fire tar- gets along the same flight line as part of a decision support tool used to create the automated workflow service chain. Other geoprocessing models will be added to provide a richer envi- ronment for triggering sensor web observation scenarios.

ACKNOWLEDGEMENTS

Implementation of the scenario would not have been possible without the support and contxibutions of the following indi- viduals: Steve Chien (NASA JPL), Daimy Tran (NASA JF'L), Liping Di (GMU), Kari Hoijaivi (WUSTL), Didier Giacobbo (SPOT).

REFERENCES "Using Autonomy Flight Sofhvare to Improve Science Return on Earth Observing One", Journal of Aerospace Computing, Information, and Communication, Vol. 2, April 2005. "An Autonomous Earth Observing Sensorweb", IEEE Intelligent Sys- tems Journal, May/June 2005. "A Service Oriented Architecture to Enable Senor Webs", presented at the Fall 2006 meeting of the American Geophysical Union, San Fran- cisco CA, December 2006. "An Updated Status of Experiments with Sensor Webs and an OGC- based Service Oriented Architecture to Enable Global Earth Observing System of Systems", Mandl D., Frye S., Chien S., Sohlberg R., Cappe- laere P., Ungar S., Ames T., presented at Ground System Architecture Workshop 2007, Manhattan Beach CA, March 2007. Alameh, Nadine; Bambacus, Myra & a]. ''Leveraging Open Standard Interfaces in Providing Efficient Discovery, Retrieval and Integration of NASA-Sponsored Observations and Predictions, 2006 AGU Spring As- sembly proceedings (Baltimore, May 2006). Alameh, Nadine; Bambacus, Myfa & al. "NASA's Earth Science Gate- way: A Platform for Interoperable Services in Support of the GEOSS Vision", 2006 IGARSS conference proceedings (Denver, Aug. 2006). "GEOBLIKI. Geo-Data + Blog $. Wiki, An OGC Sensor Web Enabled Data Node -- A Data Publisher for Community Collaboration around Geo-Spatial Data", Cappelaere P., Frye S., Mandl D., Derezinski L., pre- sented at the Free and Open Source Software and Geoinformatics (FOSS4G2006) conference in Lausanne, Switzerland, September 2006.