ARTICLE IN PRESS

Contents lists available at ScienceDirect

Computers & Geosciences

Computers & Geosciences 35 (2009) 360–372

0098-30

doi:10.1

� Cor

E-m

ldi@gm

journal homepage: www.elsevier.com/locate/cageo

Use of ebRIM-based CSW with sensor observation services forregistry and discovery of remote-sensing observations

Nengcheng Chen a,b, Liping Di a,�, Genong Yu a, Jianya Gong b, Yaxing Wei a

a Center for Spatial Information Science and Systems (CSISS), George Mason University, 6301 Ivy Lane, Suite 620, Greenbelt, MD 20770, USAb State Key Lab of Information Engineering in Surveying, Mapping and Remote Sensing (LIESMARS), Wuhan University, 129 Luoyu Road, Wuhan,

Hubei 430079, China

a r t i c l e i n f o

Article history:

Received 22 May 2007

Received in revised form

14 July 2008

Accepted 17 August 2008

Keywords:

Sensor Web

Earth observation

Sensor observation service

CSW

Registry

04/$ - see front matter Published by Elsevier

016/j.cageo.2008.08.003

responding author. Tel.: +11301345 3459; fax

ail addresses: cnc_dhy@hotmail.com (N. Chen

u.edu (L. Di).

a b s t r a c t

Recent advances in Sensor Web geospatial data capture, such as high-resolution in

satellite imagery and Web-ready data processing and modeling technologies, have led to

the generation of large numbers of datasets from real-time or near real-time

observations and measurements. Finding which sensor or data complies with criteria

such as specific times, locations, and scales has become a bottleneck for Sensor Web-

based applications, especially remote-sensing observations. In this paper, an architec-

ture for use of the integration Sensor Observation Service (SOS) with the Open

Geospatial Consortium (OGC) Catalogue Service-Web profile (CSW) is put forward. The

architecture consists of a distributed geospatial sensor observation service, a geospatial

catalogue service based on the ebXML Registry Information Model (ebRIM), SOS search

and registry middleware, and a geospatial sensor portal. The SOS search and registry

middleware finds the potential SOS, generating data granule information and inserting

the records into CSW. The contents and sequence of the services, the available

observations, and the metadata of the observations registry are described. A prototype

system is designed and implemented using the service middleware technology and a

standard interface and protocol. The feasibility and the response time of registry and

retrieval of observations are evaluated using a realistic Earth Observing-1 (EO-1) SOS

scenario. Extracting information from SOS requires the same execution time as record

generation for CSW. The average data retrieval response time in SOS+CSW mode is 17.6%

of that of the SOS-alone mode. The proposed architecture has the more advantages of

SOS search and observation data retrieval than the existing sensor Web enabled

systems.

Published by Elsevier Ltd.

1. Introduction

1.1. Sensor Web

A sensor network is a computer-accessible network ofmany spatially distributed sensors that monitor condi-tions such as temperature, sound, vibration, pressure,

Ltd.

: +11301345 5492.

),

motion or pollutants at different locations. The termSensor Web was first proposed by the NASA Sensor WebApplied Research Planning Group. Delin and Jackson(2001) defined the Sensor Web as ‘‘a system of intra-communicating spatially distributed sensor pods that canbe deployed to monitor and explore new environments’’.

In 2005, the Geospatial Information and Communica-tion (GeoICT) Lab (Liang et al., 2005) in Canada broadenedthe scope by including a wide range of sensors andapplications in the definition of the Sensor Web, whichthey defined as an electronic skin of the Earth, offering full

ARTICLE IN PRESS

N. Chen et al. / Computers & Geosciences 35 (2009) 360–372 361

dimensional, full-scale, and full-phase sensing and mon-itoring at all levels, global, regional, and local. The SensorWeb includes both in-situ sensors and remote sensors.Sensors can be mobile or stationary. The Web isconsidered a ‘‘central computer’’ that connects enormouscomputing resources. The Sensor Web can then bethought as a ‘‘global sensor’’ that is connected to allsensors and their observations. The Sensor Web can bedivided into the sensor layer, the communication layer,and the information layer. It has the following character-istics: interoperability, intelligence, low cost, scalability,reliability and high-resolution.

Di (2007) envisioned that major new Earth Observa-tion sensors in the future will be Web-ready. Someexisting sensors, such as EO-1, will also be converted intoWeb-ready sensors. Legacy data systems and evensimulation models that provide data and information toapplication can be simulated as virtual Web-readysensors. Therefore, how remote-sensing observationsunder the Sensor Web environment are registered anddiscovered will become an increasingly urgent matter inthe Earth Observation community.

1.2. The OGC data service protocol and interface

The most popular OGC protocols for data access areWeb Map Services (WMS) (de la Beaujardiere, 2006), WebFeature Services (WFS) (Vretanos, 2002) and Web Cover-age Services (WCS) (Whiteside and Evans, 2008; Lee et al.,2005). They are designed to access geospatial dataencoded as a raster map (e.g., a JPEG picture), feature(e.g., weather data), or in its original grid (e.g., spaceairborne images). Geospatial Catalogue Service-Web(CSW) profile (Nebert et al., 2007) is designed to providecapabilities for advertising and discovering shared geos-patial data and services over the Web. The metadata fordata and services are both registered in a catalogue, sothat the users can discover, bind and, invoke theseservices using the CSW.

1.3. OGC SWE standard

In the past 6 years, OGC and ISO have been formulatingstandards and protocols for the geospatial Sensor Web.The OGC Sensor Web Enablement (SWE) initiatives havedeveloped three information models:

(1)

1 VAST web site, http://vast.uah.edu/SensorML/, (accessed 28th

Sensor Model Language (SensorML) (Botts and Robin,2007): a general model and XML encoding for thegeometric, dynamic, and observational characteristicsof a sensor.

January, 2008).2 ResEau water portal web site, http://vast.uah.edu/joomla/

(2)

index.php?option=com_content&task=view&id=93&Itemid=76, (accessed

28th January, 2008).

Observations and Measurements (O&M) (Cox,2007a, b), a framework and GML encoding for mea-surements and observations.

3 Northrop Grumman web site, http://www.irconnect.com/noc/

(3) press/pages/news_releases.html?d=86661, (accessed 28th January,

2008).4 GSFC Sensor Web Testbed Initiatives project web site, http://

eo1.gsfc.nasa.gov/new/extended/sensorWeb/sensorWeb.html, (accessed

28th January, 2008).

Transducer Markup Language (TML) (Havens, 2007), amethod using a specified message format to describeinformation for transducers and transducer systems,and to capture, archive, and exchange historical, live,and future data.

The SWE initiatives have developed three serviceimplementation specifications for sensors connected to

the Web:

(1)

Sensor Planning Service (SPS) (Simonis and Dibner,2007), by which a client can determine the feasibilityof a desired set of collection requests for one or moremobile sensors/platforms;

(2)

Sensor Alert Service (SAS) (Simonis and Echterhoff,2006), by which a client can register for and receivesensor alert messages;

(3)

Sensor Observation Service (SOS) (Na and Priest,2007), an open interface with which people canretrieve and insert an observation from one or severalsensors and also descriptions of sensors and plat-forms.

In addition, the Web Notification Service (WNS) (Simonisand Wytzisk, 2003), allows a client to conduct anasynchronous dialog with one or more other services.

When these three information models and fourservices work together, it is possible to use Web servicesto discover, access, and control sensors or sensor data.

1.4. OGC SWE-enabled system

Table 1 summarizes the advantages and disadvantagesof the following Sensor Web enabled systems: GeoSWIFT(Liang et al., 2005), the Space Time Toolkit (STT),1 theResEau water portal,2 MIST SWE3 services, and the EO-1SWE4 testing projects.

A distributed geospatial infrastructure for the SensorWeb (GeoSWIFT) has been developed at GeoICT Lab. Itincludes a Sensing Server, a Service registry, and a Servicerequester. However, services information is stored only ina data file, not following the SOS standard.

The STT has been developed by the Earth SystemScience Center (ESSC) at the University of Alabama inHuntsville (UAH). The latest version supports parsing andexecuting SensorML processing chains, SOS, WMS, WFS,and WCS. The Toolkit allows display of measured orderived observations as an interactive 4D visual scene. Butit is just a client’s toolkit and can not be deployed as aservice.

The ResEau water portal implements the OGCSensorML specification to provide for compatibility andinteroperability among the monitoring programs thatdocument water monitoring stations across Canada.Implementation of CSW in the system could helpmonitoring stations harvest SensorML documents, but

ARTICLE IN PRESS

Table 1Comparison of different geospatial Sensor Web enabled systems.

Feature System

GeoSWIFT STT ResEau MIST EO-1 SWE Test

SensorML Simple support Complete support Complete support Simple support Simple support

SOS No support Support SOS access and retrieve Support No support Support

CSW No support No support Simple support No support No support

Multi-source sensor data No support No support No support No support No support

Visual search No support No support No support No support No support

N. Chen et al. / Computers & Geosciences 35 (2009) 360–372362

current harvest services use only the OGC/WFS standardand the CSW systems cannot connect with SOS.

The Multiple Intelligence (Multi-INT) Simulation Tool(MIST) developed by Northrop Grumman is a multi-sensorsimulation framework and a testing toolkit. SensorML isutilized in the description of sensors. This tool could beused to implement sensor data access, scene setup, ruledefinition, model analysis and result visualization. How-ever, it does not use SOS for sensor data access.

EO-1 SWE has been tested by NASA as an OGC testingproject, mainly to verify whether the SWE standard couldbe used for earth observation satellite sensors. Satellitesthat observe at large-scale and low-resolution are used toobtain the location of incidents such as fires. The EO-1Sensor Web enabled system can plan services, scheduleobservations, and empower satellites using the OGC SPSand SOS. Then, high-resolution satellite images of theincident can be obtained. However, the observational datacannot be registered and searched by OGC CSW.

1.5. Problems and challenges

As we all know, remote-sensing systems can generatenew data at a high rate. The location of the observationresults is dynamic, especially for remote sensors. A typicaldata flow of forest wildfire detection under Sensor Webenvironment can be summarized as: Department ofHomeland Security (DHS) analyst requests fire of interestto analyze emergency response in disaster area; ClientDecision Support System (DSS) Model queries catalog andfinds sensor capabilities and processing services that canpotentially supply the requested features; Cataloguereturns data sources as possible source; Access to high-resolution satellite data is granted based on user permis-sion; No recent satellite data is available for the disastersite, so satellite tasking is required and achieved via DSSoptimizing scheduler and SPS service; Analyst is notifiedvia instant message that satellite data products areavailable. High-resolution imagery is retrieved via SOSservices; Analyst requests data processing to extractdesired features from satellite data and workflow sequen-cer executes data processing algorithms in response;processed features are overlayed on maps, annotated bythe analyst, and shared with other users. In a word, thelarge amount of dynamic satellite observations data mustbe discovered and retrieved in the forest wildfire detec-tion under the Sensor Web environment.

The catalogue service plays an important role in thearchived remote-sensing observation discover and retrie-val. The catalogue service (Chen et al., 2006; Chu et al.,2006; Wei et al., 2005) and semantic catalogue service(Yue et al., 2006) implementations at CSISS supportdistributed management and semantic queries for re-mote-sensing observations. These services use the ebXMLRegistry Information Model (ebRIM) profile and the ISO19119/ ISO 19115 (Voges and Senkler, 2005) applicationprofile, combined with grid and semantic Web technolo-gies. However, the SWE-enabled systems and CSWsystems have the following problems:

(1)

The observation services of most sensors are inde-pendent of each other; there is no explicit support forsensor arrays and service-oriented architecture, andthe in-service expansibility is poor.

(2)

There is no discussion of the relationship of catalogueservices and remote-sensing SOS. The method forregistering remote-sensing SOSs, the informationregistered, and the registration process and steps stillneed to be explained.

(3)

The catalogue system cannot be reused to discover theremote-sensing observations from SOS. SWE-enabledSOS can generate a high rate of real-time or near real-time data. The dynamic and large volumes of data areencoded following the O&M specification. How toregister and discover O&M-encoded remote-sensingobservations is still a problem.

(4)

No good tool provides a convenient interface to helpusers quickly find the specific sensors they need.

Therefore, how to find the dynamic, large volumeremote-sensing observations for specific times, locations,and/or scales from active sensors has become a challengein Sensor Web-based applications. This paper mainlydeals with the above four issues and tries to explain howto reuse SOS and CSW in SWE-enabled system to searchand register dynamic remote-sensing observations.

1.6. Organization

The design considerations, architecture, and the maincomponents of the system are described in Section 2.Detailed information about the main procedures of SOSregistry middleware is provided in Section 3. Section 4presents a prototype for integrating an SOS system in the

ARTICLE IN PRESS

N. Chen et al. / Computers & Geosciences 35 (2009) 360–372 363

EO domain with ebRIM-based CSW and shows how thegeological disaster emergency system could use theprototype. Section 5 discusses EO-1 sensor data registryand retrieval experiments evaluating the feasibility andperformance of the proposed approach. Section 6 dis-cusses the improvements the proposed architecturemakes in data retrieval in SOS search and remote-sensingobservations. Finally, Section 7 summarizes the conclu-sions and discusses the next steps that are needed.

2. System architecture and components

2.1. Design considerations

One of the critical components of the system enabledfor the Sensor Web is an infrastructure that can registerobservations and measurements provided by a SOS. Thegoal of the system under development is to provide plugand play middleware components for a registry service toimplement SOS integration with CSW. The system must beinteroperable, reusable, and universal.

2.1.1. Interoperability

The proposed registry middleware service, the existingCSW server, the implemented SOS server, and thecustomer should interoperate through multi-level stan-dard interface protocols. For example, the client or theuser may query distributed heterogeneous data sourcesthrough CSW or Registry service middleware using the‘‘GetRecords’’ interface, access the data through the WCSby the ‘‘GetCoverage’’ interface, and executes a clippingoperation using the ‘‘Execute’’ interface of the WebProcessing Service (WPS).

2.1.2. Reusability

The registry middleware service should reuse existingsystems and services. The OGC community has usedsignificant resources to develop standards-based inter-operable services systems using value-added services tosupport timely access, integration, and utilization of EOdata. Such systems access multi-source data from the EOdata archives and model output, provide value-addedservices that generate user-specific products, and deliverthe products to the user through open, standard inter-faces. Geospatial discovery is the key problem in remotesensing sensor-webs, contrasting with in-situ sensorswhere the sensor location is static and the location ofinterest is immediately adjacent. Many services, especiallySOS and the catalog services, should be reused in buildinga Sensor Web enabled system.

2.1.3. Universality

The registry middleware should be suitable for diverseSOSs in the EO domain. SOS supports both remote sensorsand in-situ sensors. Remote sensors, such as satellites, anUnmanned Aerial Vehicle (UAV), Laser Imaging Detectionand Ranging (LIDAR), and an Aerial Digital Sensor(ADS40), can be used to produce images of terrestrialphenomena. The registry middleware should interoperate

with the diverse implementations for SOS in the EOdomain.

2.2. Architecture

To satisfy the above objectives, service-oriented mid-dleware architecture using CSW and SOS has beenadopted by the data registry for the geospatial SensorWeb. As shown in Fig. 1, the architecture of the geospatialSensor Web data registry system defines the followingthree roles for it:

2.2.1. Service requestor (geospatial sensor portal)

The geospatial sensor portal locates entries in thebroker registry using various find operations and thenbinds to the service provider in order to invoke one of itsWeb services.

2.2.2. Service broker (SOS registry service middleware and

CSW server)

SOS registry service middleware makes the SOS inter-face and implementation access information available toany potential service requestor.

2.2.3. Service provider (distributed geospatial SOS)

A distributed geospatial SOS provides its interface andaccess information to the service registry middlewareusing the ‘‘Getcapabilities’’ interface of SOS and the‘‘HarvestRecord’’ interface of registry service middleware.Each SOS provider decides what operations of the serviceshould be listed in a CSW service and what sort of tradingpartner agreements are required for use of the service.

2.3. Components

The components of the geospatial Sensor Web dataregistry system are distributed geospatial SOS, CSW basedon ebRIM, geospatial SOS registry service middleware, anda data portal for the geospatial Sensor Web. This sectiondescribes the components of the proposed architecture.The core component, the geospatial SOS registry servicemiddleware, will be explained in Section 3.

Distributed geospatial SOS in a network environmentcan be encapsulated into Web services using the WebService Description Language (WSDL) and deployed in aWeb container. Three core operations retrieve sensorproperties and sensor data: GetCapabilities, DescribeSen-sor, and GetObservation. The ‘‘GetCapabilities’’ operationgets the metadata for the identifier, provider, operationmetadata, filter capabilities, and content. The content isdata and functions that the SOS server provides. The‘‘DescribeSensor’’ operation gets a detailed description ofthe sensor, encoded using a sensor information model(SensorML or TML). The ‘‘GetObservation’’ operation getsthe observational or survey data encoded by the O&Minformation model. It has two types of users: one is theSOS provider, who can supply sensor observations andsurvey data to SOS and the other is the sensor dataconsumer. In the experiments described in this paper, the

Fig. 1. Components of remote sensing Sensor Web data registry based on CSW and SOS.

N. Chen et al. / Computers & Geosciences 35 (2009) 360–372364

sensor data consumers are the geospatial catalogueservice and the SOS registry middleware.

The ebRIM profile of CSW supports the registry anddiscovery of services, datasets, coverages, features, andthe service chain. Four core operations retrieve andregister SOS metadata: GetCapabilities, GetRecords,DescribeRecords, and HarvestRecords. The external inter-face follows the OGC CSW 2.0 standard, which supportsthree types of interfaces: OGC_Service, Discovery, andManager. The OGC Service interface is the GetCapabilitiesoperation, which provides a description of the capabilitiesfor catalogue services and providing related XML docu-ments. The Discovery interface provides three operations(GetRecords, GetRecordById, and GetDomain) by whichclients can discover and obtain the information registeredin the catalogue service database. The Manager interfaceallows users to use the ‘‘push’’ or ‘‘pull’’ mode to updatecatalogue content. Currently, this CSW implementation atCSISS is used by several projects, including GeoBrain,5 theNASA Grid project,6 and the NGA Intelligent Web serviceproject.7 It manages more than 17TB of NASA EOS data.

The SOS registry service middleware component of thesystem discovers the potential SOS, auto-harvests sensordata granules, extracts information, and generates recordsfor the sensor data granules. This middleware usesstandard interfaces and protocols to interact with theother three components. Each record in the registrycontains SOS service information, SOS observationsoffering information, or metadata for SOS observations.The SOS service information is registered in CSW as

5 NASA EOS Higher-Education Alliance (NEHEA)—GeoBrain web site,

http://geobrain.laits.gmu.edu/, (accessed 28th January, 2008).6 NASA Grid Project: Integration of the Grid technology with OGC

Web Services Technology web site, http://grid.laits.gmu.edu/, (accessed

28th January, 2008).7 NGA Project: Geospatial Knowledge Discovery via Intelligent Web

Services web site, http://www.laits.gmu.edu/geo/nga/, (accessed 28th

January, 2008).

‘‘ServiceType’’, and capability and observations metadataare registered in CSW as ‘‘DataType’’.

The portal component for the geospatial sensorinteroperates directly with the SOS registry service. It isimplemented using Java portal technology. The portalperforms the following services: user authorization, usersigning, and SOS search presentation.

3. SOS registry service middleware

3.1. WSDL

WSDL provides a model and an XML format fordescribing Web services. WSDL allows separation be-tween the description of the abstract functionality offeredby a service and the concrete details of a servicedescription, such as ‘‘how’’ and ‘‘where’’ that functionalityis offered. The components of the WSDL of SOS containtwo kinds of portTypes (HTTP Get and Post) and threemandatory operations (GetCapabilities, DescribeSensor,and GetObservation). The service registry can invoke thesemandatory operations to generate registry information.

3.2. Schema of the SOS response

The schema of a SOS Capabilities response contains fivemain elements: ‘‘ServiceIdentification’’, ‘‘ServiceProvider’’,‘‘Operations Metadata’’, ‘‘Filter_capabilities’’, and ‘‘Con-tents’’. The ‘‘Contents’’ element contains one or more‘‘ObservationOffering’’ elements containing data andfunctions that the SOS server provides. The ‘‘Observation-Offering’’ element contains ‘‘intendedApplication’’,‘‘eventTime’’, ‘‘procedure’’, ‘‘observedProperty’’, ‘‘feature-OfInterest’’, ‘‘resultFormat’’, ‘‘resultModel,’’ and ‘‘respon-seMode’’ elements.

The response of the SOS ‘‘GetObservation’’ operationcontains not only ‘‘service’’ and ‘‘version’’ attributes and the‘‘ObservationOffering’’ element but also ‘‘offering’’ and‘‘result’’ elements. In general, the ‘‘result’’ element describes

ARTICLE IN PRESS

N. Chen et al. / Computers & Geosciences 35 (2009) 360–372 365

the EO dataset. For example, the ‘‘result’’ in the EO-1 SOS‘‘GetObservation’’ response is ‘‘/result xlink: href ¼ ‘http://eo1.geobliki.com/hyperion/EO1H0410342004085110PY-2007-04-01T18:31:56Z.tar.gz’xlink:role ¼ ‘application/zip’xsi:type ¼ ‘gml: ReferenceType’/S’’.

3.3. Registration contents and sequence

3.3.1. SOS service registration

The SOS service registration function has been adoptedfor registering the information describing the SOS edition,keywords, address and operations. This information isgenerated from the ‘‘ServiceIdentification’’, ‘‘ServiceProvi-der’’, and ‘‘OperationsMetadata’’ elements in the sosgetcapabilities response and is bundled into a ‘‘Service-Type’’ object. A ‘‘ServiceType’’ object provides minimalmetadata for registry OGC service. The ‘‘ServiceType’’object has the attributes, ‘‘id’’, ‘‘home’’, ‘‘objectType’’,‘‘status’’, ‘‘expiration’’, ‘‘majorVersion’’, ‘‘minorVersion’’,‘‘stability’’, and ‘‘userVersion’’ and elements ‘‘name’’,‘‘description’’, ‘‘slot’’, ‘‘classification’’, ‘‘externalIndentifica-tion’’, and ‘‘serviceBinding’’. The ‘‘slot’’ instances provide adynamic way to add arbitrary attributes to a registryservice object. The ‘‘classification’’ element defines a treestructure to describe a structured way for classifyingor categorizing ‘‘RegistryObject’’s. the new attributes,such as ‘‘version’’, ‘keyword’’, ‘‘connectPointLinkage’’, and‘‘wsdlURL’’ are added to the ‘‘serviceType’’ object throughslots. The process is as follows (Fig. 2):

(1)

Users send a SOS search request to the service registrymiddleware. The service registry middleware gets asuitable SOS service address and then sends aGetCapabilities request to SOS.

(2)

The service registry middleware obtains and parsesthe GetCapabilities response. It obtains informationon the operation of services from ‘‘the Operations-Metadata’’ element and on the service edition from the‘‘ServiceIdentification’’ element. The information isbundled into a ‘‘ServiceType’’ object record. A ‘‘publish’’service from CSW is then invoked to insert a ‘‘Service-Type’’ object record into the MySQL database.

(3)

When the CSW service has completed the ‘‘publish’’operation, a response indicating successful registry issent to the user.

Fig. 2. Sequence diagram of S

The registration function for SOS observation offering

3.3.2. Registration of SOS observation offered

registers information on SOS capabilities for ‘‘offering’’information on observations: the observation platform,the phenomenon observed, the spatial extent, the tempor-al period, and the model of the result. The information isgenerated from the ‘‘ObservationOfferingList’’ element inthe SOS GetCapabilities response. The ‘‘OfferingType’’object is an instance of ‘‘DataType’’ and provides minimalmetadata for registering an OGC SOS ‘‘Observation-Offering’’. An ‘‘OfferingType’’ object has the attributes‘‘id’’, ‘‘home’’, ‘‘objectType’’, ‘‘status’’, ‘‘expiration’’,‘‘majorVersion’’, ‘‘minorVersion’’, ‘‘stability’’ and theelements ‘‘userVersion’’, ‘‘name’’, ‘‘description’’, ‘‘slot’’,‘‘classification’’, and ‘‘externalIndentification’’. Otherattributes, such as ‘‘boundedBy’’, ‘‘eventTime’’, ‘‘observed-Property’’, ‘‘resultFormat’’, ‘resultModel’’, and ‘‘response-Mode’’ are added to the ‘‘OfferingType’’ object throughSlots. The process is as follows (Fig. 3):

(1)

OS s

Users request service registry middleware to registeran SOS service offering. The service registry middle-ware parses the ‘‘ObservationOfferingList’’ element inthe SOS GetCapabilities response.

(2)

The metadata about the observation platform, phe-nomenon observed, spatial extent and time period isgenerated. The information is enveloped into an‘‘OfferingType’’ object record, and a CSW ‘‘publish’’service is invoked.

(3)

After the CSW service has completed the ‘‘insert’’operation, a response of successful registry is sent tothe user.

3.3.3. Registration of SOS observations

The registration function for SOS observations isdesigned to register the metadata for real-time observa-tional results in SOS. The metadata for remote-sensingobservations is registered as a ‘‘WCSCoverage’’ in the CSISSCSW. ‘‘WCSCoverage’’ contains the dataset name, itsgeographical extent, data format, coordinate referencesystem, and resolution information.

A ‘‘WCSCoverage’’ object is an instance of ‘‘DataType’’and provides minimal metadata for registry coverage data.An ‘‘Association’’ object uses an ‘‘associationType’’ attri-bute to identify the relationship between a source

ervice registration.

ARTICLE IN PRESS

Fig. 3. Sequence diagram for SOS observation offering capability registration.

Fig. 4. An example of a ‘‘WCSCoverage’’ object.

N. Chen et al. / Computers & Geosciences 35 (2009) 360–372366

‘‘WCSCoverage’’ object and a target ‘‘Service’’ object, sothat the ‘‘WCSCoverage’’ data can be served through thespecified WCS server. Fig. 4 shows an example of a‘‘WCSCoverage’’ object. It contains both ‘‘id’’, ‘‘home’’,‘‘objectType’’, ‘‘status’’, ‘‘expiration’’, ‘‘majorVersion’’,‘‘minorVersion’’, ‘‘stability’’, ‘‘userVersion’’, ‘‘mimeType’’and ‘‘isOpaque’’ attributes and ‘‘name’’, ‘‘description’’,‘‘slot’’, ‘‘classification’’, ‘‘externalIndentification’’, ‘‘gran-ule’’, ‘‘version’’, ‘‘name’’, ‘‘label’’, ‘‘gridEnvelopLow’’, ‘‘grid-EnvelopHigh’’, ‘‘xAxisName’’, ‘‘yAxisName’’, ‘‘originPoint’’,‘‘xResolution’’, ‘‘yResolution’’, ‘‘requestCRSs’’, ‘‘respon-seCRSs’’, ‘‘nativeCRSs’’, ‘‘supportedFormats’’, ‘‘native-Format’’ and ‘‘BBOX’’ elements.

The process of registering metadata from SOS observa-tion is as follows (Fig. 5):

(1)

Users send metadata from the SOS observationrequest to service registry middleware, which, in turn,sends a GetObservation request to the SOS service.

(2)

The service registry middleware parses the Get-Observation response, the metadata of the observeddataset is enveloped into a WCSCoverage record, andthe CSW service is invoked to publish the record.

(3)

After the CSW service has completed the ‘‘insert’’operation, a response that registry has been successfulis sent to the user.

ARTICLE IN PRESS

Fig. 5. Sequence diagram for registering SOS observations.

Fig. 6. Demonstration of registering and querying SOS in CSW.

N. Chen et al. / Computers & Geosciences 35 (2009) 360–372 367

prototype

4. Implementation of Sensor Web data registration

4.1. Implementation

Web services and Java technology have been used toimplement SOS registry service middleware compliantwith the OGC CSW and SOS standards. A demonstration ofthis implementation (Fig. 6) has been deployed in the‘‘GeoBrain’’ server. The access address of the demo is‘‘http://csiss.gmu.edu/sensorweb/demo.html’’. It consistsof the following functions:

(1)

SOS discovery: SOS services are discovered using one oftwo mechanisms: (1) user submission and (2) har-vesting through search crawlers. A submitting userwill provide the URL addresses for SOS services andregister them into the catalogue service. SOS URLharvesting is accomplished by crawling over the Web.One approach is to do a pattern search on OGCservices using some general search engine. Matches

for ‘‘service ¼ SOS’’ and ‘‘request ¼ getCapabilities’’are sought. Links to actual SOS services will beobtained by examination of the returned page.

(2)

SOS service registry: The program generates an XMLrequest to register services when a user selects theservice and the action ‘‘register service’’. This requestwill register the SOS service as a ServiceType object inthe CSISS CSW.

(3)

SOS offering registry: The program generates an XMLrequest to register capabilities when a user selects theservice and the action ‘‘register capabilities’’. Thisrequest will register the SOS capabilities as offering-Type objects in the CSISS CSW.

(4)

SOS observations registry: The program generates anXML request to register observation metadata when auser selects the service and the action ‘‘registerobservation’’. This request will register the SOSobservations as WCSCoverage objects in the CSISSCSW.

(5)

SOS registry information query: A query can be formedin XML and posted to the CSW. A query was sent to

ARTICLE IN PRESS

8

28th9

28th

N. Chen et al. / Computers & Geosciences 35 (2009) 360–372368

find records matching the conditions: GranuleShort-Name isLike ‘*EO1*’. The query found 22 matchingrecords.

4.2. Use in a geological disasters emergency response system

The proposed architecture can be used in the geologi-cal disasters emergency response system. The workflowfor using the proposed remote-sensing observationsregister and discovery to detect the location of fires hasbeen presented as part of EO Geo-Processing Workflow(GPW) in OGC OWS-5 meeting. This wildfire use scenariodescribes a real-time collaboration between agenciesusing different platforms and sensors. Geological scien-tists are using the proposed middleware for fire extentdata from EO-1 SOS. The WCS initiates the execution ofthe model workflow. Execution first waits for the datareceived through EO-1 SOS. Once the data is available inSOS, it is fetched and ingested into a WCS through aregistry operation of middleware. The middleware regis-ters the EO-1 Hyperion observations as a series of‘‘WCSCoverage’’ objects. The Business Process ExecutionLanguage (BPEL) engine passes the data to a NASA JPL WPSfor extracting fire information. The resulting data isingested to a WCS. The data or desired subset is thenready for the end users in a specified format andprojection.

5. EO-1 SOS registry and retrieval experiments

EO-1 provides the SOS–SOS8and the SPS–SPS.9 SPSschedules observations. The basic service information and‘‘offering’’ capability is acquired using the SOS ‘‘Get-Capabilities’’ operation. High spectrum image data fromthe Hyperion instrument can be obtained using the SOS‘‘GetObservation’’ operation. Only data more recent than2005-10-18T15:19:39.000Z is accepted. EO-1 SOS contains10 Hyperion observation offerings. Each offering includes242 bands. Each band contains about 6.64 MB of data.The size of observations at a particular moment is about15.6 GB.

5.1. Experiment on the EO-1 sensor observation data registry

5.1.1. Experiment design

This study used the EO-1 SOS and CSISS CSW toevaluate the registry service middleware proposed in thispaper. SOS registry middleware interacting with SOS andCSW was implemented using Java and deployed usingTomcat. All experiments were carried out on a Pentium 4PC with a 2.00 GHz processor and 1.0 GMB of memory,running Microsoft Windows/XP. EO-1 SOS Hyperion datasets varying from 10 bands to 224 bands were used.Subsets of from 1 to 50 bands were inserted into the CSISSCSW in separate requests. The observation data registry

EO-1 SOS web site, http://eo1.geobliki.com/sosdemo, (accessed

January, 2008).

EO-1 SPS web site, http://eo1.geobliki.com/spsdemo, (accessed

January, 2008).

time (F) was divided into two parts: information genera-tion (G) and record insert (I). The mean registry time perband was also calculated. Table 2 shows the test resultsThe ‘‘Data set’’ item gives the data size of observations inthe each register request, the ‘‘insert number’’ item givesthe number of bands in each ‘‘insert’’ operation. Forexample, if we request registry of 332 MB (about 50bands) of observations, we must execute 5 insert opera-tions (where the request insert number is 10 in one insertoperation).

5.1.2. Performance analysis

The first study was of the response time for differentnumbers of bands at a constant specified insert number of30 bands). Fig. 7(a) shows that response time increaseswith the size of Hyperion data set—the more bands a dataset has, the more response time is required for registry.This increase tends to be linear, due mostly to the datasize; a data set that has more bands requires a largeramount of information for generation and insert (eachband is about 6.64M). Fig. 7(b) shows that the ‘‘Genera-tion’’ phase time is longer than the ‘‘Insert’’ phase forsmall data size, but the fraction of response time for thephases tends to become equal with increasing data size.

The response time as a function of insert item numberwas then studied. The result is shown in Fig. 8(a and b).From Fig. 8 (a) shows that mean response time per banddecreases with the number of insert items as the numbervaries from 1 to 20; the more insert numbers a requesthas, the less response time is required for registry. Theoptimal mean response time occurs when the insert itemnumber is 20. The mean response time increase displays alinear increase after 20, due mostly to the fact that theresponse time is influenced not only by the size of thedataset, but also the number of insert items. Moreover,Fig. 8(b) shows that the ‘‘Generation’’ phase time is largerthan the ‘‘Insert’’ phase for small data size, but theapportionment of the response time between the ‘‘Insert’’and ‘‘Generation’’ phases tends to equalize with increasingdata size.

5.2. EO-1 SOS alone vs. SOS+CSW

5.2.1. Experiment design

In this experiment, the response times were comparedfor Sensor Web data retrieval of EO-1 SOS alone and withthe CSISS CSW service middleware proposed in this paper.With the EO-1 SOS model, users send a ‘‘GetObservation’’request directly to the SOS server. The SOS serverprocesses the request, packages the observed data, andtransfers the raw data to the consumer. For the SOS+CSWmodel, users first send a ‘‘GetRecord’’ request to CSW.Registry middleware then sends the ‘‘GetObservation’’request to the SOS server, gets the raw data, and registersthe retrieved metadata in the CSW. The built-in WCSserves the data on demand. The CSW, WCS, and SOSservers are deployed in a 1000 M/s Local area network(LAN). The client and server are connected by a 10 M/sWide area network (WAN). The data transmission time

ARTICLE IN PRESS

Table 2Response time of registry.

Insert number (bands) Data set (M)

66.4 332 664 996 1328 1487 Mean registry time (per band) (s/band)

1 G 5.8 29 57.7 87.1 118.3 142.6 0.68

I 1.1 3.9 9.50 13.6 16.9 22.1

F 6.9 32.9 67.2 100.7 135.2 164.7

5 G 2.6 7.4 16.9 21.5 31.6 36.2 0.24

I 0.8 2.9 6.8 9.0 11.9 15.3

F 3.4 10.3 23.7 30.5 43.5 51.5

10 G 1.0 5.1 9.3 13.6 17.8 21.8 0.17

I 0.7 3.2 6.6 9.9 12.2 15.0

F 1.7 8.3 15.9 23.5 30.0 36.8

20 G 0.9 3.8 7.4 10.5 16.6 19.2 0.15

I 0.6 3.7 8.0 11.8 15.8 18.3

F 1.5 7.5 15.4 22.3 32.4 37.5

30 G 0.9 4.0 8.3 9.9 12.8 18.7 0.17

I 0.6 4.4 9.3 14.4 18.1 22.8

F 1.5 8.4 17.6 24.3 30.9 41.5

40 G 1.7 4.6 9.4 14.1 16.3 19.0 0.21

I 0.8 5.4 10.6 15.8 21.6 26.3

F 2.5 10.0 20.0 29.9 37.9 45.3

50 G 2.1 4.9 9.8 15.4 20.3 23.7 0.25

I 1.3 6.8 13.1 18.7 25.3 29.7

F 3.4 11.7 22.9 34.1 45.6 53.4

Fig. 7. Response time as a function of Hyperion dataset size.

N. Chen et al. / Computers & Geosciences 35 (2009) 360–372 369

among CSW, WCS and SOS can be neglected. The responsetimes of the two modes were measured.

5.2.2. Performance analysis

Table 3 compares the response times for the twomodes. The SOS+CSW mode performs better than the SOS

mode. The response time of SOS+CSW mode is only 17.6%of that of the SOS mode. Transmission is the dominantinfluence on the SOS response time; however, processingis the dominant influence factor in the SOS+CSW mode.

For the SOS+CSW mode, use of a high-performanceserver, server cluster, or Grid deployment could enhance

ARTICLE IN PRESS

Fig. 8. Response time as a function of insert number.

Table 3Mean response time per band of two different modes.

Bands EO-1 SOS(S) EO-1 SOS +LAITS CSW(s)

1 4.1 1

2 5.1 1.1

10 5.19 1.13

20 6.54 1.04

40 7.99 1.13

80 7.00 1.10

120 10.3 1.12

160 8.99 1.67

200 7.69 1.45

220 7.75 1.53

N. Chen et al. / Computers & Geosciences 35 (2009) 360–372370

the performance of the server. Service quality could becontrolled by service providers. The SOS+CSW mode isfeasible for large-scale real-time observation data onlineservices.

For SOS alone mode, increasing network bandwidthand reducing transmission of data could yield a higherquality of service; however, the service provider wouldnot be able to control the network bandwidth.

6. Discussion

6.1. Use of metadata in CSW for easy search of Sensor Web

data

The tests discussed above show that, SOS informationcan be registered in CSW and the system is implementedby service middleware. In addition, it can be used forsensor and sensor data query in CSW. The stored SOSservice information, capability information, and observa-tion data search can be implemented using the rich CSWsearch functions. As Fig. 9 shows, the ‘‘GetRecord’’function of the CSW server can be used to search theSOS instances by name, serviceType, keyword, version,and serviceProvider. The ‘‘space-time’’ filter function ofthe CSW server can be used to search SOS offerings andSOS observation results in space and time.

6.2. Quick retrieval of Sensor Web observation data

The observational data in SOS is registered into CSW asa WCSCoverage. As Fig. 10 shows, an on-demand observa-tion data service can be implemented by reusing theexisting WCS or WFS server. The response time for theobservation data service can be reduced using the PNG orJPEG format from WCS server. Thus, a user can retrieve theSensor Web observation data quickly.

7. Conclusions and outlook

This paper proposes a method for using SOS, CSW, andregistry service middleware to develop a system, enabledby the Sensor Web, for the registry of remote-sensingSensor Web data. In the realistic EO-1 SOS and CSISS CSWscenario, the mean response time is about 150 ms perband. The response time for the optimal strategy is0.2–0.3 times that of the worst. The results show that itis feasible to register real-time or near real-time remote-sensing observations using ebRIM CSW and SOS based onservice middleware technology. Moreover, the methodol-ogy is an improvement over the existing OGC SWE-enabled systems mentioned in Section 1.4, in the follow-ing ways:

(1)

The flexible architecture. This strategy adopts service-oriented architecture to package the registry system.The services of the registry system can be deployedindependent of operation system with the servicecontainer and invoked through standard interfaces.

(2)

SOS service information is registered as a ‘‘Service-Type’’ and SOS capability content registered as an‘‘OfferingType’’. They can be discovered by a CSW‘‘GetRecords’’ operation. It is possible to search theSensor Web data easily using the metadata in CSW.

(3)

SOS remote-sensing observations can be registered asa ‘‘WCSLayer’’. They can also be discovered by a CSW‘‘GetRecords’’ operation and served through OGC’sWCS. A user can thus quickly retrieve data fromSensor Web observations.

(4)

Through Sensor Web data registry middleware, theremote-sensing observations can be used by other

ARTICLE IN PRESS

Fig. 9. SOS instance search using CSW ‘‘GetRecords’’ function.

Fig. 10. On-demand observation EO-1 data retrieval reusing existing SOS, CSW and WCS.

N. Chen et al. / Computers & Geosciences 35 (2009) 360–372 371

OGC data services. In the realistic EO-1 SOS and CSISSCSW scenario, the average response time of theSOS+CSW mode is 17.6% that of the SOS alone mode.Hence, the register middleware method reduceswaiting time when accessing real-time observationaldata in an emergency response system based on theSensor Web.

The proposed registry middleware is suitable fordiverse SOS in the Earth Observation domain, but only

for the CSW server based on the ebRIM profile and the ISO19115 and ISO 19119 standards for metadata and servicemetadata. The next step is to study how to provide generalregistry middleware for the CSW server.

Acknowledgements

This work was supported by grants from the US NASAESTO/AIST Sensor Web program ‘‘A General Frameworkand System Prototypes for the Self-Adaptive Earth Pre-dictive Systems (SEPS)—Dynamically Coupling SensorWeb with Earth System Models’’ (No. NNX06AG04G, PI:Dr. Liping Di), China 863 program (No. 2007AA12Z230,PI: Dr. Nengcheng Chen) and the NSFC program (No.40501059, PI: Dr. Nengcheng Chen). We sincerely thankour colleague, Dr. Barry Schlesinger, for proofreading themanuscript. The authors would like to thank Dr. SimonCox and the anonymous reviewer for their valuablecomments and insightful ideas.

ARTICLE IN PRESS

N. Chen et al. / Computers & Geosciences 35 (2009) 360–372372

References

Botts, M., Robin, A. (Eds.), 2007. OpenGISs Sensor Model Languageimplementation specification (Version 1.0.0). Open Geospatial Con-sortium (OGC) document number: 07-000, Wayland, Massachusetts,USA, p. 180.

Chen, A., Di, L., Wei, Y., Liu, Y., Bai, Y., 2006. An optimized grid-based, OGCstandards-compliant collaborative software system for serving NASAgeospatial data. In: Proceedings 30th Annual National Aeronauticsand Space Administration (NASA)/Institute of Electrical and Electro-nics Engineers (IEEE) Software Engineering Workshop, Columbia,MD, USA, pp. 159–166.

Chu, K., Di, L., Thornton, P., 2006. Introduction of grid computingapplication projects at the NASA earth science technology office.Journal of Lecture Notes in Computer Science 3947, 289–298.

Cox, S. (Ed.), 2007a. Observations and Measurements—Part 1—Observa-tion Schema. Open Geospatial Consortium (OGC) document number:07-002r1, Wayland, Massachusetts, USA, p. 85.

Cox, S. (Ed.), 2007b. Observations and Measurements—Part 2—samplingfeatures. Open Geospatial Consortium (OGC) document number: 07-002r3, Wayland, Massachusetts, USA, p. 46.

De la Beaujardiere, J. (Ed.), 2006. OpenGISs Web Map Server imple-mentation specification (Version 1.3.0). Open Geospatial Consortium(OGC) document number: 06-042, Wayland, Massachusetts, USA,p. 85.

Delin, K., Jackson, S., 2001. The sensor web: a new instrument concept.In: Proceedings of the International Society for Optical Engineering(SPIE)’s Symposium on Integrated Optics, San Jose, California, USA,pp. 1–9.

Di, L., 2007. Geospatial sensor web and self-adaptive earth predictivesystems (SEPS). In: Proceedings Earth Science Technology Office(ESTO)/Advanced Information System Technology (AIST) Sensor WebPrincipal Investigator (PI) Meeting, San Diego, USA, pp. 1–3.

Havens, S. (Ed.), 2007. OpenGISs Transducer Markup Language im-plementation specification. Open Geospatial Consortium (OGC)document number: 06-010r6, Wayland, Massachusetts, USA, p. 258.

Lee, E., Kim, M., Kim, M., Joo, I., 2005. A web services framework forintegrated geospatial coverage data. Journal of Lecture Notes inComputer Science 3480, 1136–1145.

Liang, SHL., Croitoru, A., Tao, CV., 2005. A distributed geospatialinfrastructure for Sensor WebH. Computers & Geoscience 31 (2),221–231.

Na, A., Priest, M. (Eds.), 2007. OpenGISs Sensor Observation Serviceimplementation specification (version 1.0). Open Geospatial Con-sortium (OGC) document number: 06-009r6, Wayland, Massachu-setts, USA, p. 104.

Nebert, D., Whiteside, A., Vretanos, P. (Eds.), 2007. OGCTM CatalogueServices specification (version 2.0.2). Open Geospatial Consortium(OGC) document number: 07-006r1, Wayland, Massachusetts, USA,p. 218.

Simonis, I., Dibner, P. (Eds.), 2007. OpenGISs Sensor Planning Serviceimplementation specification (version 1.0). Open Geospatial Con-sortium (OGC) document number: 07-014r3, Wayland, Massachu-setts, USA, p. 186.

Simonis, I., Echterhoff, J. (Eds.), 2006.OGCs Sensor alert serviceimplementation specification (version 0.9.0). Open Geospatial Con-sortium (OGC) document number: 06-028r5, Wayland, Massachu-setts, USA, p. 144.

Simonis, I., Wytzisk, A. (Eds.), 2003. Web Notification Service (version0.1.0). Open Geospatial Consortium (OGC) document number: 03-008r2, Wayland, Massachusetts, USA, p. 46.

Voges, U., Senkler, K. (Eds.), 2005. OpenGISs Catalogue Servicesspecification 2.0—ISO19115/ISO19119 application profile for CSW2.0 (version 0.9.3). Open Geospatial Consortium (OGC) documentnumber: 04-038r2, Wayland, Massachusetts, USA, p. 89.

Vretanos, P.A. (Ed.), 2002. OGCTM Web Feature Service implementationspecification (version 1.0.0). Open Geospatial Consortium (OGC)document number: 02-058, Wayland, Massachusetts, USA, p. 105.

Wei, Y., Di, L., Zhao, B., Liao, G., Chen, A., Bai, Y., Liu, Y., 2005. The designand implementation of a grid-enabled catalogue service. In:Proceedings of IEEE International Geoscience and Remote SensingSymposium (IGARSS 2005), Seoul, Korea, pp. 4224–4227.

Whiteside, A., Evans, J.D. (Eds.), 2008. OGCTM Web Coverage Serviceimplementation standard. Open Geospatial Consortium (OGC)document number: 07-067r5, Wayland, Massachusetts, USA, p. 133.

Yue, P., Di, L., Zhao, P., Yang, W., Yu, G., Wei, Y., 2006. Semanticaugmentations for geospatial catalogue service. In: Proceedings ofIEEE International Geoscience and Remote Sensing Symposium(IGARSS 2006). Denver, Colorado, USA, pp. 3469–3472.