An automatic SWILC classification andextraction for the AntSDI under a Sensor Web

environment

Nengcheng Chen, Deren Li, Liping Di, and Jianya Gong

Abstract. How to update spatial information in real time or near real time has become a bottleneck in the construction of

the Antarctica Spatial Data Infrastructure (AntSDI). An automatic sensor processing workflow (SPW) approach

consisting of sensor discovery and retrieval service; snow, water, ice, land and cloud (SWILC) Web processing service

(WPS); and an SPW engine under the Sensor Web environment is used in this paper to generate live SWILC maps

dynamically. A prototype consisting of a sensor processing model designer, a model instantiation service, and an SPW

engine is presented. A scenario of an Earth Observing-1 (EO-1) Sensor Web data service for SWILC classification and

feature extraction in Antarctica is used to test the feasibility of the proposed framework. The integration of SPW with

Google Earth and updating of the spatial information for AntSDI using the Transactional Web Feature Service (WFS-T)

are evaluated. The results show that the proposed approach is feasible for the update of spatial data in Antarctica.

Resume. La problematique quant a la facon de mettre a jour l’information spatiale en temps reel ou en temps quasi reel est

devenue une entrave a l’elaboration de l’Infrastructure des donnees spatiales antarctiques (AntSDI). Dans cet article, on

utilise une approche automatique de gestion des donnees (SPW, « sensor processing workflow ») comportant un service de

decouverte de capteurs et d’extraction des donnees, un service Web de traitement (WPS) des donnees sur la neige, l’eau, la

glace, les terres et les nuages (SWILC) et un moteur SPW dans un environnement de reseau de capteurs Web pour generer

de facon dynamique des cartes de SWILC en temps reel. On presente un prototype compose d’un concepteur de modele de

traitement de donnees capteur, d’un service d’instanciation de modele et d’un moteur SPW. On utilise un scenario de

service de capteurs Web d’EO-1 pour la classification et l’extraction des caracteristiques de SWILC en Antarctique pour

tester la faisabilite du cadre propose. On evalue l’integration de SPW avec Google Earth et la mise a jour de l’information

spatiale pour AntSDI utilisant le service WFS-T (« Transactional Web Feature Service »). Les resultats montrent que

l’approche proposee est efficace pour la mise a jour des donnees spatiales en Antarctique.

[Traduit par la Redaction]

Introduction

Antarctica Spatial Data Infrastructure (AntSDI)

Antarctica is the coldest, driest, and most inaccessible

continent on Earth. The extreme climate, remoteness, and

sparse human population distinguish the ‘‘white continent’’

from the rest of the world. Antarctica plays a key role in

many scientific questions, many of which are related to

global climate change. In most of these research activities,

the spatial component is crucial. The AntSDI sponsored by

the Scientific Committee on Antarctic Research (SCAR)

Standing Committee on Antarctic Geographic Information

(SC-AGI) is responsible for maintaining spatial data for

Antarctica and sharing it through the application of Open

Geospatial Consortium (OGC) specifications. One of the

main features of Antarctica spatial data is the coverage of

snow, ice, water, and land. A digital terrain model (DTM)

generated using differential global positioning system (GPS)

surveys, a satellite image map from a Systeme pour

l’Observation de la Terre (SPOT) satellite image mosaic,

and topographic information from the Antarctic digital

database (ADD) can be combined to generate a new

topographic database for King George Island (Braun et

al., 2001). Scambos et al. (2007) present digital image

mosaics of surface morphology and optical snow grain size

for the Antarctic continent and surrounding islands,

assembled from 260 Moderate-Resolution Imaging Spectro-

radiometer (MODIS) images. A new digital elevation model

(DEM) (Drews et al., 2009) based on differential interfero-

metric synthetic aperture radar (SAR) from the European

Remote Sensing 1 and 2 (ERS-1, ERS-2) satellites in

Received 28 June 2009. Accepted 28 December 2009. Published on the Web at http://pubservices.nrc-cnrc.ca/cjrs on 16 July 2010.

N. Chen,1 D. Li, and J. Gong. State Key Laboratory of Information Engineering in Surveying, Mapping and Remote Sensing (LIESMARS),Wuhan University, 129 Luoyu Road, Wuhan, Hubei 430079, China.

L. Di. Center for Spatial Information Science and Systems (CSISS), George Mason University, 6301 Ivy Lane, Suite 620, Greenbelt, MD20770, USA.

1Corresponding author (e-mail: cnc_dhy@hotmail.com).

Can. J. Remote Sensing, Vol. 36, Suppl. 1, pp. S1–S12, 2010

E 2010 CASI S1

combination with the ICESat Geoscience Laser Altimeter

System (GLAS) is derived for the ice sheet in western

Dronning Maud Land, Antarctica. However, the processes

are complex and manual.

The OGC is a nonprofit, international, voluntary con-

sensus standards organization that is leading the develop-

ment of standards for geospatial and location-based

services. With the catalogue service (Nebert et al., 2007), a

great number of OGC services (e.g., Web Map Service

(WMS; De la Beaujardiere, 2004), Web Feature Service

(WFS; Vretanos, 2005), Web Coverage Service (WCS;

Whiteside and Evans, 2008), and Web Processing Service

(WPS; Schut, 2007)) that are used under AntSDI can be

identified and retrieved (Chen et al., 2007). However,

finding a method to instantly and automatically update

snow, ice, water, and land information is a major challenge

for AntSDI-based applications.

OGC Sensor Web Enablement (SWE)

In the past 6 years, the OGC and the International

Organization for Standardization (ISO) have been for-

mulating standards and protocols for the geospatial Sensor

Web. The OGC Sensor Web Enablement (SWE) initia-

tives have developed three information models, namely

SensorML (Botts and Robin, 2007), Observations and

Measurements (O&M) (Cox, 2007a; 2007b), and Trans-

ducer Markup Language (TML) (Havens, 2007). The SWE

initiatives have also developed four service implementation

specifications for sensors connected to the Web, namely the

Sensor Planning Service (SPS) (Simonis, 2007), the Web

Notification Service (WNS) (Simonis and Wytzisk, 2003),

the Sensor Alert Service (SAS), and the Sensor Observation

Service (SOS) (Na and Priest, 2007). When these three

information models and four services work together, it is

possible to use Web services to discover, access, and control

sensors or sensor data on a large scale in real time or near

real time.

Sensor processing workflow

In the last decade, hyperspectral imaging has rapidly

become an effective remote-sensing technology for many

different applications. In particular, hyperspectral scanners

allow one to discriminate species with very similar spectral

signatures. Kernel-based methods (KMs) have proven to be

an effective tool for addressing hyperspectral image classi-

fication (Camps-Valls and Bruzzone, 2005). Supervised

kernel classifiers (e.g., support vector machines (SVMs);

Cristianini and Shawe-Taylor, 2000) are generally preferred

to unsupervised kernel classifiers (e.g., support vector data

description; Tax and Duin, 2004).

The Autonomous Sciencecraft Experiment (ASE) is a

National Aeronautics and Space Administration (NASA)

New Millennium Program mission containing new techno-

logy in the form of software flown on the Earth Observing-1

(EO-1) satellite since 2003. Among the ASE flight software

is a set of onboard science algorithms designed for auto-

nomous data processing, primarily based on change detec-

tion from observation to observation. The onboard science

algorithms (Chien et al., 2005) include a snow, water, ice,

and land (SWIL) classifier, a thermally hot pixel detector,

and flood scene classification. Thus, ASE enables the

spacecraft to autonomously detect and respond to dynamic

scientifically interesting events observed from EO-1. The

next challenges for image classification and feature extrac-

tion are how to use a sensor process workflow to chain the

live data and the application of useful algorithms in a

Sensor Web.

The OGC Web Service 5 (OWS-5, the fifth phase of the

OGC interoperability testbed series on Web services) SWE

focussed on demonstrating the ability of SWE specifica-

tions to support operational needs by integrating the SWE

interfaces and encodings into complex scenarios and work-

flows. The georeferenceable imagery and Earth observation

workflow was presented in OWS-5. The OWS-6 SWE

focussed on georeferenceable imagery workflow, the unified

modelling language (UML) based information model for

SWE, security architecture, CCSI sensors, and event

architecture.

The business process execution language (BPEL) and its

extension for Web Services (BPEL4WS) (Curbera et al.,

2006) are based on technologies like the Web Service

Description Language (WSDL), extensible markup lan-

guage (XML) Schema, and XPath. The OWS-4 Workflow

Interoperability Program Reports (IPRs) (Keens, 2007)

contain some BPEL use cases related to the OGC Geo

Processing Workflow.

Problems

Many SOS prototypes have been developed in the

worldwide Sensor Web community, for example 52u North

SOS, GeoBliki, VisAnalysis Systems Technologies Team

(VAST), and Deegree SOS. Chen et al. (2009a) proposed a

service-oriented framework to integrate and assimilate

sensor observations and measurements under a multi-

purpose SOS in combination with other standard services,

i.e., the CSW, the Transaction WFS (WFS-T), and the

Transaction WCS (WCS-T). The proposed method was

successfully tested using three typical sensor observation

datasets, namely EO-1 observations, weather observations,

and water height gauge observations. Moreover, Chen et al.

(2009b) proposed a method for using SOS, CSW, and

registry service middleware to develop a system, enabled by

the Sensor Web, for the registry of remote-sensing Sensor

Web data. However, how to organize the SPS, SOS, WCS,

WPS, and WFS as a Sensor Process Workflow (SPW) to

achieve a real-time or near-real-time sensor map has become

a challenge in the update of spatial information for AntSDI.

This paper tries mainly to explain how to design, implement,

and use SPW to process dynamic real-time remote-sensing

observations and generate instant spatial information.

Vol. 36, Suppl. 1, 2010

S2 E 2010 CASI

Organization

The rest of this paper presents a workflow-driven

approach for using the SWE and OGC transactional sensor

data services to generate live geospatial Sensor Web data

service chains. The architecture of the SPW-based SWILC

classification and extraction service is presented, and the

design and implementation of the SWILC classification

based on WPS specification are described. The use of Sensor

Web design, instantiation, and execution to implement the

SPW is discussed, as are experiments to evaluate the

feasibility of using the SWILC SPW for EO-1 Hyperion

sensor data and visualization of the SWILC classification in

Google Earth. On-demand, near-real-time and automatic

update of the SWILC spatial data for AntSDI is discussed,

followed by a summarization of the conclusions and a

discussion of the next steps that are needed.

SPW-based SWILC classification andextraction

The architecture of the SPW-driven SWILC classification

and extraction system under the Sensor Web environment

consists of the following five components: Sensor Web

service, Data Discovery and Retrieval Service, WPS-based

SWILC classification and extraction Service, SPW-driven

SWILC engine, and SWILC portal (Figure 1).

The Sensor Web service is the real-time or near-real-time

data source of the system. The data requirement is

scheduled by the SPS, the sensor information is encoded

using SensorML, and the observational data are encoded

using the O&M standard as accessed by the SOS. This paper

describes the use of the NASA EO-1 Sensor Web services

(Ip et al., 2006). NASA has implemented these services as

an OGC testing project, mainly used to verify whether or

not the Sensor Web standard could be used for earth

observation satellite sensors. The large-scale and low-

resolution observations are used to obtain incident location.

The high-resolution satellite images of the incident can then

be obtained, and the system can plan services, schedule

data, and empower satellites using the OGC SPS and SOS.

The data discovery and retrieval services (DDRS)

component is responsible for observational data obtained

through the uniform standard interface and operation. The

two standard interfaces and operations are connected to

the outside by the WPS-based SWILC classification service:

the ‘‘GetRecords’’ operation in the Catalogue Service for

the Web (CSW) (Nebert et al., 2007) service and the

‘‘GetCoverage’’ operation in the WCS service. Built-in WCS

and CSW services are deployed in the middleware, and

many data service conversions are implemented in the

middleware.

The WPS-based SWILC classification and extraction

service operates in the following way. OGC WPS is a

standardized interface for providing computational func-

tions for processing geospatial data, such as image

classification to clients. Clients can use WPS to access

preprogrammed calculations and (or) computation models

that operate on spatially referenced data. The calculations

can be simple or complicated. The image data required by

WPS can be available locally or on a network. The SWILC

classification service based on WPS 1.0.0 specification

(SWILC WPS) runs on a trained support vector machine

to classify and extract snow, water, ice, land, and cloud.

The SPW-driven SWILC engine is in charge of construc-

tion, instantiation, and execution for SPW. WSDL-based

Web services and BPEL-based Web services chains can be

deployed and executed dynamically in the engine, where

their validity is checked. HTTP POST/GET and SOAP

invocations are supported.

The SWILC portal is the presentation logic. It interacts

directly with the SPW-driven SWILC classification engine,

which consists of user authentication, service search, con-

tents management, and data visualization modules. Client

applications invoke a core service component through the

portal to achieve the user authentication, search, manage-

ment, and visualization functions.

Implementation of the SWILC WPS

The implemented SWILC WPS is deployed in the http://

HOST/wps/(HOST5 ‘‘swe.whu.edu.cn:9000’’) and supports

Figure 1. Architecture of automatic SWILC classification and extraction service.

Canadian Journal of Remote Sensing / Journal canadien de teledetection

E 2010 CASI S3

three mandatory operations, namely GetCapabilities,

DescribeProcess, and Execute.

The ‘‘GetCapabilities’’ operation of SWILC WPS gives

the clients a detailed description of the WPS service. The

schema of a SWILC WPS Capabilities response contains

four main elements, namely ServiceIdentification, Service-

Provider, OperationsMetadata, and ProcessingOfferings.

The ‘‘ProcessingOfferings’’ element contains one or more

‘‘Process’’ elements containing functions that the SWILC

WPS server provides. A ‘‘Process’’ element contains

‘‘Identifier,’’ ‘‘Title,’’ and ‘‘Abstract’’ elements and a

‘‘ProcessVersion’’ attribute. In this paper, the ‘‘Identifier’’

of ‘‘Process’’ is ‘‘SWILC,’’ and the ‘‘ProcessVersion’’ of

‘‘SWILC’’ process is 1.0.0. Clients can get the XML-based

service metadata documents for the SWILC process and

determine the specification version for client–server inter-

actions from the results of a ‘‘GetCapabilities’’ request

(http://HOST/wps?request5GetCapabilities&service5WPS

&version51.0.0).

The ‘‘DescribeProcess’’ operation of SWILC WPS (http://

HOST/wps?request5DescribeProcess&service5WPS&

version51.0.0&Identifier5SWILC) gives the clients a

detailed description of the parameters of the inputs and

outputs of the ‘‘SWILC’’ process. Three kinds of ‘‘Data-

Inputs’’ parameters and five kinds of ‘‘ProcessOutputs’’

results are concerned in the description of the ‘‘SWILC’’

process (Figure 2). ‘‘DataInputs’’ parameters are sza, doy,

and bands required. The input value of the ‘‘sza’’ parameter

is the solar zenith angle encoded by degrees on band inputs.

The input value of the ‘‘doy’’ parameter is the calendar day

starting from 1 January. The names of the ‘‘bands’’ input

parameters are band8, band21, band34, band41, band51,

band85, band110, band150, band210, and band213. The

input values are EO-1 Hyperion level 1G images, encoded in

‘‘image/tiff’’ mime type. The five kinds of ‘‘ProcessOutputs’’

results are the snow, water, ice, land, and cloud polygons

encoded in geography markup language (GML) 3.1.1.

The ‘‘Execute’’ operation of SWILC WPS (http://host/

wps?service5WPS&version51.0.0&request5execute&

identifier5SWILC&datainputs5band858.tif; band21521.

tif; band31531.tif; band34534.tif; band41541.tif; band51

551.tif; band85585.tif; band1105110.tif; band1505150.tif;

band2105210.tif; band2135213.tif; sza558.34374; doy5

22&status5false&store5true) carries out the ‘‘SWILC’’

process triggered by the clients. The returning results are

the snow, water, ice, land, and cloud polygons encoded as

GML 3.1.1 whose location is given by a series of URLs

(Figure 2). The ‘‘status’’ parameter indicates if the

‘‘Execute’’ operation response can be returned quickly

with status information. The ‘‘store’’ parameter indicates

whether it is possible to request that complex data output(s)

from this process be stored by the WPS server as Web-

accessible resources.

Implementation of SWILC SPW

Chaining of WPS processes facilitates the creation of

repeatable workflows. WPS processes can be incorporated

into service chains in a number of ways: A BPEL engine can

be used to construct a service chain that includes one or

more WPS processes; a WPS process can be designed to call

a sequence of Web services including other WPS processes,

thus acting as the service chaining engine; and simple service

chains can be encoded as part of the execute query. Such

Figure 2. Description of SWILC classification process in SWILC WPS.

Vol. 36, Suppl. 1, 2010

S4 E 2010 CASI

cascading service chains can be executed even via the GET

interface. This section describes the BPEL engine approach

to chaining SOS, CSW, WCS, WPS, and WFS.

Defining the WSDLs for SOS, CSW, WCS, WPS, and WFS

WSDL provides a model and an XML format for

describing Web services. WSDL enables one to separate

the description of the abstract functionality offered by a

service from the concrete details of a service description,

such as ‘‘how’’ and ‘‘where’’ that functionality is offered.

We have defined the WSDL for SPS, SOS, WCS, WPS, and

WFS and set up services such as EO-1 SPS, EO-1 SOS

(Chen et al., 2009b), CSISS WCS, WHU SWILC WPS, and

WHU WFS.

There are two HTTP transportation port types (GET and

POST) in the WSDL of EO-1 SPS, EO-1 SOS, CSISS WCS,

WHU WPS, and WHU WFS. There are nine operations

(GetCapabilities, DescribeGetFeasibility, GetFeasibility,

DescribeSubmit, Submit, GetStatus, DescribeResultAccess,

Update, and Cancel) in the WSDL of EO-1 SPS, three

mandatory operations (GetCapabilities, DescribeSensor,

and GetObservation) in the WSDL of EO-1 SOS, three

mandatory operations (GetCapabilities, DescribeCoverage,

and GetCoverage) in the WSDL of CSISS WCS, three

mandatory operations (GetCapabilities, DescribeProcess,

and Execute) in the WSDL of WHU WPS, and six

operations (GetCapabilities, DescribeFeatureType, GetFea-

ture, GetFeatureWithLock, GetGMLObject, and Trans-

action) in the WSDL of WHU WFS. The WHU Sensor

Web project hosts the XML document for the aforemen-

tioned Web services (http://swe.whu.edu.cn:9000/swilc/wsdl/).

Design of the SWILC workflow

The concrete BPEL workflow can be created by Oracle

BPEL Process Manager. Oracle BPEL Process Manager

enables enterprises to orchestrate and execute Web services

and business processes. The BPEL workflow includes

processes. One process may contain partnerLinks, variables,

assign activities, invoke activities, flow activities, sequence

activities, and while activities. The partnerLinks define the

external services with which the BPEL process interacts; the

variables provide the means for holding messages that

constitute a part of the state of a business process; an assign

activity provides a method for simple data manipulation,

such as copying the contents of one variable to another; an

invoke activity enables a user to specify the operation to be

invoked for the service; a flow activity is used to specify one

or more activities to be performed concurrently; a sequence

activity defines a collection of activities to be performed

sequentially in lexical order; and a while activity specifies

that the child activity is to be repeated as long as a given

condition is true.

Figure 3 shows the SWILC workflow. The SWILC pro-

cedure can be expressed as a ‘‘WHU_GMU_EO1_SWILC’’

process element. The ‘‘WHU_GMU_EO1_SWILC’’ process

contains ‘‘client,’’ ‘‘EO1_SPS,’’ ‘‘EO1_SOS,’’ ‘‘CSISS_

WCS,’’ ‘‘WHU_WPS,’’ and ‘‘WHU_WFS’’ partnerLink

elements. The process contains ‘‘EO-1_Hyperion_Sensor_

Capability_By_SPS_GetFeasibility,’’ ‘‘EO-1_Hyperion_

Sensor_Tasking_By_SPS_Submit,’’ ‘‘EO-1_Hyperion_L1G_

By_SOS_GetObervation,’’ ‘‘Band8_GetCoverage,’’ ‘‘Band21_

GetCoverage,’’ ‘‘Band31_GetCoverage,’’ ‘‘Band34_

GetCoverage,’’ ‘‘Band41_GetCoverage,’’ ‘‘Band51_

GetCoverage,’’ ‘‘Band85_GetCoverage,’’ ‘‘Band110_

GetCoverage,’’ ‘‘Band150_GetCoverage,’’ ‘‘Band210_

GetCoverage,’’ ‘‘Band213_GetCoverage,’’ ‘‘SWILC_

ClassificationandExtraction_By_WPS_Execute,’’ and

‘‘SWILC_Extraction_Result_Add_By_WFS_Transaction’’

invoke activities and corresponding assign activities. The

input and output variables are also defined for the

aforementioned invoke activities.

For example, the ‘‘SWILC_ClassificationandExtraction_

By_WPS_Execute’’ invoke activity element contains

‘‘SWILC_Classification_Execute_InputVariable,’’ ‘‘SWILC_

Classification_Execute_OutputVariable,’’ and ‘‘swilc_

sequence’’ sequence elements; the ‘‘swilc_sequence’’

sequence element contains the ‘‘swilc_receive’’ element (it

is of the ‘‘receive’’ type), ‘‘SWILC_Classification_Execute_

Input,’’ and ‘‘SWILC_Classification_Execute_Output’’ ele-

ments (they are of the ‘‘assign’’ type); and the ‘‘SWILC_

Classification _Execute_Input’’ assign activity contains one

or more ‘‘copy’’ elements.

Deployment and execution of the SWILC SPW usingBPELPower

A geospatial service chain is executed in this phase to

derive the desired data products. For this purpose, the

BPELPower workflow engine has been developed and the

geospatial service chain packaged as a workflow. Figure 4

shows the user interface. The WHU_GMU_EO1_SWILC

workflow can be deployed and executed in the engine.

As shown in Figure 4, the input parameters of the SWILC

workflow are the solar zenith angle (sza), the calendar day

(doy), and the geographic latitude and longitude (LowerX,

LowerY; UpX, UpY).

EO-1 Hyperion case study

EO-1 is the first satellite in the NASA New Millennium

Program Earth Observing series. The primary focus of EO-1

is to develop and test a set of advanced technology land

imaging instruments. EO-1 was launched on a Delta 7320

from Vandenberg Air Force Base on 21 November 2000.

The SWILC classification service described in this paper

uses hyperspectral data from the Hyperion instrument. The

Hyperion is a high-resolution imager capable of resolving

220 spectral bands (from 0.4 to 2.5 mm) with a 30 m spatial

resolution. Each image shows a 7.5 km by 42.0 km land

area. Detailed spectral mapping is provided with high

radiometric accuracy for all 220 channels.

Canadian Journal of Remote Sensing / Journal canadien de teledetection

E 2010 CASI S5

Dataset

The main objective of the EO-1 Sensor Web project (http://

eo1.gsfc.nasa.gov/new/extended/sensorWeb/sensorWeb.

html) is to use software to create an interoperable environ-

ment for a diverse set of satellite sensors. The EO-1 Sensor

Web project provides SOS (http://eo1.geobliki.com/sos/) and

SPS (http://eo1.geobliki.com/sps/). Observations can be

scheduled by SPS, and the basic service information and

‘‘offering’’ capability can be acquired through the SOS

‘‘GetCapabilities’’ operation. The high spectral resolution

image data of the Hyperion instrument can be obtained

through the SOS ‘‘GetObservation’’ operation, accepting onlydata more recent than 2005–10–18T15:19:39.000Z.

Approach

Figure 5 shows an SWILC classification scenario using

near-real-time Hyperion data. The workflow retrieves data

from the eleven EO-1 SOS bands (the band names are 8, 21,

31, 34, 41, 51, 85, 110, 150, 210, and 213) and generates the

SWILC map shown in Figure 5 by the following five steps:

(1) SWILC model design — The expert designs a sensor

processing model for SWILC using the SensorModel

Figure 3. Concrete SWILC workflow.

Vol. 36, Suppl. 1, 2010

S6 E 2010 CASI

tool developed by the Sensor Web team at Wuhan

University (WHU). The sensor processing model

includes an EO-1 Hyperion physical component, an

SWILC classification algorithm, and an SWILC feature

extraction algorithm.

(2) SWILC workflow instantiation — The SWILC portal

discovers the model using the ‘‘SWILC’’ keywords,

instantiates the model, and generates the concrete

sensor processing workflow using the BPEL script

language (Figure 3).

(3) SWILC workflow deployment and execution — The

workflow is deployed and executed by BPELPower

(http://swe.whu.edu.cn:9000/bpel/). The near-real-time

encoded observational data are retrieved from EO-1

SOS using the ‘‘GetObservation’’ operation with the

data described by the O&M specification, registered as

Figure 5. SWILC scenario using near-real-time EO-1 Hyperion data.

Figure 4. User interface of SWILC workflow engine.

Canadian Journal of Remote Sensing / Journal canadien de teledetection

E 2010 CASI S7

a WCS coverage using the LAITS CSW (http://laits.

gmu.edu:8099/LAITSCSWVM2/discovery) server

through the ‘‘publish’’ operation and fed from the

transactional WCS to the SWILC WPS (http://swe.

whu.edu.cn:9000/wps/swilc).

(4) SWILC feature data store — The process results are

snow, water, ice, land, and cloud polygons encoded in

GML and stored as geometry objects in a MySQL

database by a WFS-T.

(5) SWILC Keyhole Markup Language (KML) map

generation — KML is an XML-compliant markup

language. The snow, water, ice, land, and cloud

polygons are input to a Web Map Service (WMS). A

user can retrieve the KML map by giving its geographic

extent and overlay the data in Google Earth.

Results

An end user initiates the execution of the model work-

flow, which waits for the data received through EO-1 SPS

and EO-1 SOS. Once the data are available in SOS, they

are fetched and ingested into a WCS through an SOS

registration operation. The BPEL engine passes the data

to a WHU WPS for extracting classified SWILC image

information (Figure 6a). The resulting vector data

(Figure 6b) are ingested to a WFS, and the data or desired

subset are ready for the end users in a specified format and

projection. All these processes are completed automatically.

This avoids time being spent due to human delay in passing

around data and information.

SWILC classification visualizationdemonstration

Since 2006, Google Earth has been used in many fields,

including climate change, natural disasters, the environ-

ment, education, and cross-platform view sharing. KML

can be used to store, manage, serve, and visualize two-

and three-dimensional geospatial data in Google Earth.

Any overlays, images, icons, and models cited in KML

can be expressed optionally as network-linked KML files.

General users can easily integrate and publish their

geospatial data of personal interest in Google Earth. Data

providers can also release their data products via KML in

Google Earth.

We use two approaches to overlay the results in Google

Earth. One is classified SWILC image visualization in

Google Earth using WMS Link in a KML file, and the other

is the featured SWILC Geometry visualization in Google

Earth using Geometry Placemark in KML file.

SWILC visualization using WMS Link

For the WMS Link style, a WMS (http://swe.whu.edu.

cn:9000/geoserver/wms?) NetworkLink is included in the

KML file (Figure 7a). The standard WMS interface

comprises three operations: (i) GetCapabilities for request-

ing metadata; (ii) GetMap for requesting a map image;

and (iii) GetFeatureInfo for requesting more information

about a specific map pixel. In the WMS NetworkLink, the

classified SWILC map image is requested with the specified

width and height by the WMS GetMap operation. The map

Figure 6. Results of SWILC workflow using near-real-time EO-1 Hyperion data.

Vol. 36, Suppl. 1, 2010

S8 E 2010 CASI

image can be packaged as a ‘‘TitledImage’’ layer and

overlaid in Google Earth (Figure 7b).

SWILC visualization using Geometry Placemark

For the Geometry Placemark style, a series of LineString

and Polygon Geometry objects are encoded in the KML file

(Figure 8a). A Placemark is a feature with associated

geometry. A LineString defines a connected set of line

segments and usesLineStyle to specify the color, color

mode, and width of the line. A Polygon is defined by an

outer boundary and zero or more inner boundaries. The

boundaries, in turn, are defined by LinearRings. Linear-

Rings is a closed line string, typically the outer boundary of

a polygon. The SWILC LineString and Polygon Geometry

featured from the SWILC workflow can be packaged as five

kinds of Placemark (id 5 snow, water, ice, land, or cloud

plus geometry id) and overlaid in Google Earth (Figure 8b).

Discussion

The Antarctic Digital Database (ADD) is a compilation

of medium-scale topographic data for the continent of

Figure 7. Classified SWILC image visualization in Google Earth using WMS Link style.

Figure 8. Featured SWILC Geometry visualization in Google Earth using Placemark style.

Canadian Journal of Remote Sensing / Journal canadien de teledetection

E 2010 CASI S9

Antarctica. It is derived from a wide variety of sources and

aims to provide the best currently available data in all areas.

However, users should note that the resolution of the data

varies widely. The most detailed information is taken from

maps compiled at a scale of 1 : 10 000 (i.e., a resolution of

approximately 5 m), and the least detailed from sources with

a resolution of at best 5 km. The lowest resolution data are,

however, from the great ice sheets where the relief is very

low and where higher resolution data would not be useful.

Compared to the ADD method, the proposed SWILC

workflow method has the benefits of being on-demand,

automatic, and near real time and able to be reused with

different satellites and spatial and temporal extents by

different applications.

On-demand service of the proposed method

The proposed SWILC workflow is a more on-demand

update method than the existing ADD topographic

information update method. The SWILC workflow adopts

OGC-compliant service interfaces and information models

for services for packaging, processing, and presenting data.

The observations can be made and retrieved by the EO-1

SOS with the specified offering and the temporal scales.

The observational data in EO-1 SOS have been registered

in CSW as a WCSCoverage (Chen et al., 2009a). The

WCSCoverage can be subset with the requested geograph-

ical scope. The snow, water, ice, land, and cloud vector

data can be fed to the ADD by the WFS-T server. Thus, an

on-demand observation data classification and extraction

service for the spatial information can be implemented by

reusing the SWILC workflow with variable spatial and

temporal scales.

Automation of the proposed method

The proposed SWILC workflow is an update method

that is more automatic than the existing ADD method. The

existing ADD spatial data update method requires consid-

erable manual involvement in the individual steps. To

implement automatic spatial data updates is a major

challenge. The SWILC workflow chains EO-1 SPS, EO-1

SOS, GMU WCS, WHU WPS, and WHU WFS-T. The

proposed method can be deployed in the BPELPower

workflow engine, invoked as a Web service, and executed

dynamically to automatically achieve EO-1 observational

data acquisition, SWILC classification and feature extrac-

tion processing, and live sensor map generation, unlike the

ADD spatial data update method. Thus, an automatic

topographic information updating service for the AntSDI

can be implemented by the SWILC workflow.

Near-real-time update of the proposed method

The proposed SWILC workflow is an update method that

is more near real time than the existing ADD method.

Spatial information is important when studying environ-

mental change in Antarctica; real-time update information

especially can help scientists quickly understand the

dynamics of the environment in Antarctica. High-resolution

satellite images of the area of interest could be obtained

while the proposed SWILC workflow is planning services,

scheduling data, and empowering satellites using the EO-1

sensor planning and observation services. Thus, near-real-

time EO-1 sensor planning and observation services for the

AntSDI can be implemented by the SWILC workflow.

Reusability of the proposed method

The proposed SWILC workflow can be used with

different spatial and temporal extents. For example, ‘‘–50,

–20, 50, 20’’ can be the spatial extent and ‘‘2009–08–

01T00:00:00, 2009–08–31T24:00:00’’ can be the temporal

extent in the proposed SWILC workflow. The proposed

SWILC workflow has been designed using Oracle 11g

Jdeveloper IDE and registered in CSW as a ‘‘serviceType’’

object. It can be discovered with the ‘‘GetRecords’’ interface

of the CSW server and reused by other OGC data services.

The components of the SWILC workflow are exposed to

clients as a series of Web services using WSDL, which can

be reused by many applications.

Conclusions and outlook

Achieving on-demand, automatic, and real-time or near-

real-time spatial information updates for the construction

of the Antarctica Spatial Data Infrastructure (AntSDI) in

the Sensor Web environment is a major challenge. An

automatic sensor processing workflow (SPW) approach

can be used to chain EO-1 SPS, EO-1 SOS, GMU WCS,

WHU WPS, and WHU WFS-T as an automatic snow,

water, ice, land, and cloud (SWILC) classification and

extraction service. The SPW prototype, including the sensor

processing model designer SensorModel and the SPW

engine BPELPower, is designed and implemented. Eleven

bands of Hyperion data from the EO-1 Sensor Web node

and Web Processing Service are adopted for SWILC

classification. Feature extraction is used to test the

feasibility of the spatial data update for the Antarctic

digital database (ADD). Two kinds of approaches, namely

WMS NetworkLink and Geometry Placemark, are used to

evaluate the visualization of results from SPW with Google

Earth. The results show that the proposed approach is

feasible for the update of spatial data and dynamic mapping

in Antarctica.

The next step is to study how to evaluate and improve the

quality of the sensor processing workflow and interoper-

ability among three heterogeneous sensor processing work-

flows by using SensorML to process chain mode, BPEL to

service chain mode, and XML Process Definition Language

(XPDL) to resource chain mode.

Vol. 36, Suppl. 1, 2010

S10 E 2010 CASI

Acknowledgements

This work was supported by grants from the Chinese 863program (grant 2007AA12Z230 to Dr. Nengcheng Chen),

the National Nature Science Foundation of China (NSFC)

program (grant 40721001 to Dr. Jianya Gong and

grant 40501059 to Dr. Nengcheng Chen), the US NASA

ESTO/AIST Sensor Web program (grant NNX06AG04G

to Dr. Liping Di), and the Chinese IPV6 program (grant 126

to Dr. Deren Li). We sincerely thank our colleague, Dr.

Barry Schlesinger, for proof reading the manuscript. Theauthors would like to thank the editors and anonymous

reviewer for their valuable comments and insightful ideas.

References

Botts, M., and Robin, A. 2007. OpenGISH sensor model language

implementation specification (version 1.0.0). Open Geospatial Consor-

tium (OGC), Inc., Wayland, Mass. Report 07-000.

Braun, M., Simoes, J.C., Vogt, S., Bremer, U.F., Blindow, N., Pfender, M.,

Saurer, H., Aquino, F.E., and Ferron, F.A. 2001. An improved

topographic database for King George Island: compilation, application

and outlook. Antarctica Science, Vol. 13, No. 1, pp. 41–52.

Camps-Valls, G., and Bruzzone, L. 2005. Kernel-based methods for

hyperspectral image classification. IEEE Transactions on Geoscience and

Remote Sensing, Vol. 43, No. 6, pp. 1351–1362.

Chen, N., E, D., Di, L., Gong, J., and Chen, Z. 2007. Global polar

geospatial information service retrieval based on search engine and

ontology reasoning. In Proceedings of the the10th International

Symposium on Antarctic Earth Sciences (10th ISAES), 26–31 August

2007, Santa Barbara, Calif. Edited by C. Alan, R. Carol, and the 10th

ISAES editorial team. The National Academies Press, Washington, D.C.

pp. 1–4.

Chen, N., Di, L., Yu, G., Gong, J., and Wei, Y. 2009a. Use of ebRIM-

based CSW with sensor observation services for registry and discovery

of remote-sensing observations. Computers and Geosciences, Vol. 35,

No. 2, pp. 360–372.

Chen, N., Di, L., Yu, G., and Min, M. 2009b. A flexible geospatial sensor

observation service for diverse sensor data based on Web service. ISPRS

Journal of Photogrammetry and Remote Sensing, Vol. 64, No. 2, pp. 234–

242.

Chien, S., Sherwood, R., Tran, D., Cichy, B., Rabideau, G., Castano, R.,

Davies, A., Mandl, D., Frye, S., Trout, B., Shulman, S., and Boyer, D.

2005. Using autonomy flight software to improve science return on

Earth Observing One. Journal of Aerospace Computing, Information, and

Communication, Vol. 2, pp. 196–216.

Cox, S. 2007a. Observations and measurements: Part 1 — observation

schema (version 1.0). Open Geospatial Consortium (OGC), Inc.,

Wayland, Mass. Report 07-022r1.

Cox, S. 2007b. Observations and measurements: Part 2 — sampling features

(version 1.0). Open Geospatial Consortium (OGC), Inc., Wayland,

Mass. Report 07-022r3.

Cristianini, N., and Shawe-Taylor, J. (Editors). 2000. An introduction to

support vector machines. Cambridge University Press, Cambridge, Mass.

Curbera, F., Khalaf, R., Nagy, WA., and Weerawarana, S. 2006. Imple-

menting BPEL4WS: the architecture of a BPEL4WS implementation.

Concurrency and Computation: Practice and Experience, Vol. 18, No. 10,

pp. 1219–1228.

De la Beaujardiere, J. 2004. OGC web map service interface (version 1.3.0).

Open Geospatial Consortium (OGC), Inc., Wayland, Mass. Report 03-

109r1.

Drews, R., Rack, W., Wesche, C., and Helm, V. 2009. A spatially adjusted

elevation model in Dronning Maud Land, Antarctica, based on

differential SAR interferometry. IEEE Transactions on Geoscience and

Remote Sensing, Vol. 47, No. 8, pp. 2501–2509.

Havens, S. 2007. OpenGISH transducer markup language implementation

specification (version 1.0.0). Open Geospatial Consortium (OGC), Inc.,

Wayland, Mass. Report 06-010r2.

Ip, F., Dohm, J.M., Baker, V.R., Doggett, T., Davies, A.G., Castano, R.,

Chien, S., Cichy, B., Greeley, R., Sherwood, R., Tran, D., and

Rabideau, G. 2006. Flood detection and monitoring with the

autonomous sciencecraft experiment onboard EO-1. Remote Sensing of

Environment, Vol. 101, No. 4, pp. 463–481.

Keens, S. 2007. OWS-4 workflow IPR, workflow descriptions and lessons

learned (version 0.09). Open Geospatial Consortium (OGC), Inc.,

Wayland, Mass. Report 06-187r1.

Na, A., and Priest, M. 2007. OpenGISH sensor observation service

implementation specification (version 1.0). Open Geospatial Consortium

(OGC), Inc., Wayland, Mass. Report 06-009r6.

Nebert, D., Whiteside, A., and Vretanos, P. 2007. OGCTM catalogue

services specification (version 2.0.2). Open Geospatial Consortium

(OGC), Inc., Wayland, Mass. Report 07-006r1.

Scambos, T.A., Haran, T.M., Fahnestock, M.A., Painter, T.H., and

Bohlander, J. 2007. MODIS-based mosaic of Antarctica (MOA) data

sets: Continent-wide surface morphology and snow grain size. Remote

Sensing of Environment, Vol. 111, No. 2, pp. 242–257.

Schut, P. 2007. OpenGISH web processing service (version 1.0.0). Open

Geospatial Consortium (OGC), Inc., Wayland, Mass. Report 05-007r7.

Simonis, I. 2007. OpenGISH sensor planning service implementation

specification (version 1.0). Open Geospatial Consortium (OGC), Inc.,

Wayland, Mass. Report 07-014r3.

Simonis, I., and Wytzisk, A. 2003. Web notification service (version 0.1.0).

Open Geospatial Consortium (OGC), Inc., Wayland, Mass. Report 03-

008r2.

Tax, D.M., and Duin, R.P. 2004. Support vector data description. Machine

Learning, Vol. 54, No. 1, pp. 45–66.

Vretanos, P.A. 2005. OGCTM web feature service implementation specifica-

tion (version 1.1.0). Open Geospatial Consortium (OGC), Inc., Way-

land, Mass. Report 04-094.

Whiteside, A., and Evans, J.D. 2008. OGCTM web coverage service

implementation standard (version 1.1.2). Open Geospatial Consortium

(OGC), Inc., Wayland, Mass. Report 07-067r5.

List of abbreviations

ADD Antarctic digital database

AntSDI Antarctica Spatial Data Infrastructure

ASE Autonomous Sciencecraft Experiment

BPEL business process execution language

Canadian Journal of Remote Sensing / Journal canadien de teledetection

E 2010 CASI S11

BPEL4WS BPEL and its extension for Web Services

BPELPower BPEL workflow engine developed at

CSISS

CSISS Center for Spatial Information Science andSystems (George Mason University)

CSW OGC Catalog Services Web profile

DDRS Data Discovery and Retrieval Services

DEM digital elevation model

DTM digital terrain model

EO-1 Earth Observing-1

ERS European Remote Sensing

GLAS ICESat Geoscience Laser Altimeter

System

GML geography markup language

GMU George Mason University

GPS global positioning system

MODIS Moderate-Resolution Imaging

Spectroradiometer

O&M observation and measurement

OGC Open Geospatial Consortium

OWS OGC Web Service

SAS Sensor Alert Service

SCAR Scientific Committee on Antarctic Research

SC-AGI Standing Committee on Antarctic

Geographic Information

SensorML sensor markup language

SOS Sensor Observation Service

SPS Sensor Planning Service

SPW Sensor Processing Workflow

SWE Sensor Web Enablement

SWILC snow, water, ice, land, and cloud

TML transducer markup language

VAST VisAnalysis Systems Technologies Team

WCS Web Coverage Service

WCS-T Transaction Web Coverage Service

WFS Web Feature Service

WFS-T Transaction Web Feature Service

WHU Wuhan University

WMS Web Map Service

WNS Web Notification Service

WPS Web Processing Service

WSDL Web Service Description Language

XML extensible markup language

Vol. 36, Suppl. 1, 2010

S12 E 2010 CASI