ieee journal of selected topics in applied earth ...swe.whu.edu.cn/cnc_web/paper/chen...

IEEE JOURNAL OF SELECTED TOPICS IN APPLIED EARTH OBSERVATIONS AND REMOTE SENSING, VOL. 4, NO. 3, SEPTEMBER 2011 615

An Efficient Method for Near-Real-Time On-DemandRetrieval of Remote Sensing Observations

Nengcheng Chen, Zeqiang Chen, Liping Di, Senior Member, IEEE, and Jianya Gong

Abstract—Recent advances in sensor web geospatial data cap-ture, have led to the generation of large numbers of real-time ornear-real-time observations and measurements. As the magnitudeof Web Coverage Service (WCS) and Sensor Observation Service(SOS) becomes increasingly large, a major problem is how to makefast and fully robust use of such data services in a Web-readysensors environment. A new method is proposed, Real-time Cov-erage Service (RCS), for serving observational data based onthe integration of WCS and SOS. The RCS method hides thecomplexity of a series of information models and service interfacesin the Earth Observation (EO) and Sensor Web world, allowingnear-real-time on-demand access to geospatial observations. Thecore components—dynamical schema transformer and automaticinformation extractor—are designed and implemented based onservice middleware technology. The Observations & Measure-ments (O&M) schema of SOS and coverage schema of WCSare matched by schema transformer dynamically. The coverageinformation is extracted from a SOS “GetObservation” operationby an information extractor and served by a WCS “GetCoverage”operation on-demand. Experiments on the feasibility of EarthObserving-1 (EO-1) Hyperion data retrieval for the RCS methodand OGC Sensor Web SOS method were conducted and theirefficiency compared. The results show that the proposed RCS hasarchitecture that is more robust and performs more efficientlythan the SOS method.

Index Terms—Earth Observing-1 (EO-1), near-real-time, SensorObservation Service (SOS), Sensor Web, Web Coverage Service(WCS).

I. INTRODUCTION

B UTLER [1] indicates that “the scientists can ask newquestions or test hypotheses under Sensor Web.” The Na-

tional Aeronautics and Space Administration (NASA) definesthe Sensor Web as “a coordinated observation infrastructurecomposed of a distributed collection of resources—e.g. sen-sors, platforms, models, communications infrastructure thatcan collectively behave as a single, autonomous, task-able,dynamically adaptive and reconfigurable observing system thatprovides raw and processed data, along with associated meta-data, via a set of standards-based service-oriented interfaces”

Manuscript received April 25, 2010; revised September 09, 2010, December28, 2010, and January 18, 2011; accepted January 21, 2011. Date of publicationFebruary 14, 2011; date of current version August 26, 2011. This work wassupported in part by the National Basic Research program of China under Grant2011CB707101, by the National Nature Science Foundation of China programunder Grant 41023001 and Grant 41021061, and by the NASA ESTO/AISTSensor Web program under Grant NNX06AG04G.

N. Chen, Z. Chen, and J. Gong are with the State Key Laboratory for Infor-mation Engineering in Surveying, Mapping and Remote Sensing (LIESMARS),Wuhan University, Wuhan 430079, China (e-mail: [email protected]).

L. Di is with the Center for Spatial Information Science and Systems (CSISS),George Mason University, Fairfax, VA 22032 USA.

Digital Object Identifier 10.1109/JSTARS.2011.2109035

[2], [3]. Di [4] envisioned that major new Earth Observationsensors in the future will be Web-ready. Some existing sensors,such as Earth Observing-1 (EO-1), have also been convertedinto Web-ready sensors. Existing Earth Observation (EO) dataand information service systems can be summarized in thefour methods: raw data download method based on a directory;inquiries and ordering method based on the metadata; theOGC (Open Geospatial Consortium) data service; and theOGC Sensor Web data service. In the past two years, we haveproposed the implementation of remote-sensing satellite SensorObservation Service (SOS) [5], and provided a middlewareservice to registry and discovery the remote-sensing observa-tion under Sensor Web [6], however, the integration of the WebCoverage Service (WCS) with the SOS under a Web-readysensors environment to achieve on-demand near-real-time (in-stant) remote-sensing observation retrieval faces the followingproblems:

1) The Sensor Web has emerged from recent developmentsin sensor, communication, and information technolo-gies. NASA has sponsored more than 30 related projectson evolving and developing Sensor Web technology [7].Living remote-sensing observation is often served by SOS,and WCS is often used to achieve archived remote-sensingobservation mapping [8]. However, how to couple theOGC Sensor data service method with OGC Sensor Webdata service method to achieve the near- real-time re-mote-sensing observation sharing is a big issue.

2) As the Ocean Science Interoperability Experiment (OceansIE) Phase I [9] found that Web Feature Service is differentwith SOS in query semantics of request, observation se-mantics of response and client interoperability of response.The interfaces and protocols of the OGC Sensor data ser-vice method and OGC Sensor Web data service methodare too complex to confuse the users [10]. Moreover, WCSare not reusable with the OGC Sensor Web data servicemethod.

The objective of this paper is twofold. First, it proposesand describes a near-real-time earth observation data servicemethod based on the integration a uniform WCS with a seriesof SOSs, including a WCS, schema transformer, informationextractor and SOSs components. The second objective is toexplore the uses that this method can provide to retrieve theEarth Observing-1 (EO-1) Hyperion data and achieve thenear-real-time mapping under Sensor Web environment.

The rest of the paper is organized as follows. Backgroundto the OGC Web service is summarized in Section II. A near-real-time earth observation data service method, namely RCS,based on the Sensor Observation Service and Web Coverage

1939-1404/$26.00 © 2011 IEEE

616 IEEE JOURNAL OF SELECTED TOPICS IN APPLIED EARTH OBSERVATIONS AND REMOTE SENSING, VOL. 4, NO. 3, SEPTEMBER 2011

Service is proposed in Section III, including its architecture,components, and interaction. The experiments and results areillustrated in Section IV. Section V discusses the benefits ofthe proposed method. Section VI summarizes findings and dis-cusses what steps are needed next.

II. BACKGROUND TO THE OGC SERVICES FRAMEWORK

A. OGC Data Interoperability Protocols

Open Geospatial consortium (OGC) has been developingOGC Web Services (OWS) since 1999, a seamless frameworkfor a variety of online geo-information processing and locationservice based on the web services technology. Currently, OWScontains a set of abstract specifications and implementationspecifications.

In the archived data service method under OGC data in-teroperability environment [11]–[14], the metadata of datasets and services are constructed and accessed by a CatalogueService-Web (CSW) [15]. Feature information (such as points,lines, surfaces, bodies, and other geometry) is provided by theWeb Feature Service (WFS) [16] and coverage information[17] (such as digital elevation models and land cover mea-surements) is served by a Web Coverage Service (WCS) [18],the feature and coverage information is represented by ISOgeneral feature model—Geography Markup Language (GML)[19]. A typical system is GeoBrain [20], developed in CSISS.The GeoBrain system supplies NASA EOS data to universitiesusing OGC data service and CSW based spatial knowledgediscover technology. The data services, processing services,and service chain management are implemented by expandingthe OGC CSW service. The service chain’s instantiation andexecution is implemented by the Business Process ExecutionLanguage (BPEL) engine [21]. The advantages are that OGCstandards are followed and on-demand service is provided;the shortcoming is that real-time data cannot be registered,planned, and served.

B. OGC Sensor Web Standard

In the past seven years, OGC and ISO have been formulatingstandards and protocols for the Sensor Web. The OGC SensorWeb Enablement (SWE) initiatives have developed three infor-mation models and five service implementation specifications.The three information models are Sensor Model Language(SensorML) [22], Observations and Measurements (O&M)[23], [24] and Transducer Markup Language (TML) [25]. Thefive service implementation specifications are Sensor PlanningService (SPS) [26], Sensor Observation Service (SOS) [27],Sensor Alert Service (SAS) [28], Web Notification Service(WNS) [29] and Sensor Event Service (SES) [30]. When thesethree information models and five services work together, it ispossible to use Web services to discover, access, and controlsensors or sensor data.

In the near-real-time observation service method under OGCSensor Web [31]–[33], the data requirement is scheduled by theSPS, the tasking status is notified to the registered users by theWNS, the sensor information is encoded using SensorML orTML, and the observational data is encoded using the O&M

standard, as accessed by the SOS. A typical system is the NASAEO-1 Sensor Web project [34]. NASA has implemented thisproject as an OGC testing project, mainly used to verify whetheror not the Sensor Web standard could be used for earth ob-servation satellite sensors. Large-scale and low-resolution ob-servations are used to obtain incident location by Moderate-resolution Imaging Spectroradiometer (MODIS) with a 1000-meter spatial resolution. Then high-resolution satellite imagesof the incident could be obtained by EO-1’s Hyperion with a30-meter spatial resolution, while the system could plan ser-vices, schedule data, and empower satellites using the OGCsensor planning and observation services. The advantage of thismethod is that it can provide real-time data collection; its short-coming is that it is not integrated with the OGC data serviceprotocol.

Currently, the archived data service method under OGC datainteroperability environment is in development orientation [8],and the near-real-time observation service method under OGCSensor Web environment is in the direction of future develop-ments of intelligent real-time data observation. As the magni-tude of WCS and SOS becomes increasingly large under “Data-casting Web” [35] environment, in order to achieve real-time in-tegration with a visualization tool based next web browser [36],a major problem is how to make fast and fully robust use of suchdata services in a Web-ready sensors environment.

III. REAL-TIME COVERAGE SERVICE (RCS) METHOD

A. Architecture and Components

The goal of the proposed method is to provide plug andplay middleware components for high performance in servingremote-sensing satellite observational data on-demand in theWeb-ready sensors environment. The middleware must beservice-oriented, universal accessibility interface, stability andefficiency.

The RCS combines a WCS and a SOS into a service middle-ware to access remote sensing observations in near- real-timewith the specified spatial range. Observation data could be ac-quired from SOS with a temporal range and sub-setted by WCSwith spatial extent, so that the observation data could be servedby RCS on-demand. RCS exposes the universal standard WCSinterfaces to client partners and the universal standard SOS in-terfaces to satellite sensor partners. As shown in Fig. 1, thearchitecture of RCS contains the following four components:WCS, Transformer, Extractor, and SOSs.

1) WCS Component: The WCS component provides accessto intact imagery generated from a SOS “GetObservation” re-sponse, supporting interchange of geospatial data as “coverage”.The WCS component is deployed in the “WCSURL” (WC-SURL = http://data.laits.gmu.edu:8080/cgi-bin/wcs110?”) andsupports three operations: GetCapabilities, DescribeCoverage,and GetCoverage (Samples of WCS can be found in “http://data.laits.gmu.edu:8080/pli/www/wcs110.htm”). The WCS compo-nent supports multi-dimensional sub-setting, both spatial andnon-spatial. Spatial sub-setting is based on a spatial boundingbox provided by the clients, and non-spatial sub-setting is basedon the dimension name and a sub-setting field value. For geo-

CHEN et al.: AN EFFICIENT METHOD FOR NEAR-REAL-TIME ON-DEMAND RETRIEVAL OF REMOTE SENSING OBSERVATIONS 617

Fig. 1. Architecture of near-real-time Coverage Service (RCS).

rectified data (i.e., HDF-EOS grid), the returned coverage ex-actly matches the requested spatial bounding box. For data notgeo-rectified (i.e., HDF-EOS swath), the returned coverage rep-resents the minimum subset that will fill the spatial boundingbox sent by the client. No single row (scan) or column (cross-scan) can be dropped from the returned coverage; otherwise,the requested bounding box will not be filled. This behavior is asignificant improvement over some existing software packages,which retrieve a complete Swath scan once the scan touches thebounding box.

2) SOS Component: The SOS component can be encapsu-lated into web services using the Web Service Description Lan-guage (WSDL) and deployed in a web container. Three coreoperations retrieve sensor properties and sensor data: GetCa-pabilities, DescribeSensor, and GetObservation. The GetCapa-bilities operation gets the metadata for the identifier, provider,operation metadata, filter capabilities, and content. The con-tent comprises data and functions that the SOS server provides.The DescribeSensor operation gets a detailed description of thesensor, encoded using a sensor information model (SensorML).The GetObservation operation gets the observational or surveydata encoded by the O&M information model. In this paper, weuse the multi-purpose SOS [6] deployed in the “SOSURL” (SO-SURL = “http://swe.whu.edu.cn:9000/sos”) to serve the EO-1,MODIS, and SPOT satellite observations.

3) Transformer Component: The transformer component isin charge of generating the XML schema match between a SOSand a WCS. The workflow of schema transformation is shownin Fig. 2, including schema importing, fragment identification,fragments matching and mapping combination. The matchstrategy is based on a system for flexible combination of theschema matching approach—COMA [37]. COMA is a systemfor combining match algorithms in a flexible way. COMArepresents a generic match system supporting different appli-cations and multiple schema types such as XML and relationalschemas. It provides an extensible library of match algorithms

Fig. 2. Schema transformation between a SOS and a WCS.

and supports different ways of combining match results. Newmatch algorithms can be included in the library and used incombination with other matchers. COMA thus allows thetailoring of match strategies by selecting the match algorithmsand their combinations for a given match problem. A varietyof matching strategies and dozens of different matchers areadopted to find the corresponding items between SOS andWCS schema files. An Extensible Stylesheet Language (XSL)Transformations (XSLT) [38] template is generated by thetransformer component.

We take the example of schema matching between wcsGet-Capabilities_xsd (version 1.1.2) and sosGetCapabilities_xsd(version 1.0.0), as the two schemas are based on the sameinformation model—OWS 1.1.0, so we applied the COMAto perform the matching task. All Context strategy and CON-TEXTS matcher in COMA are used to generate the similaritycube. There are 112 correspondences between wcsGetCapabil-ities_xsd (version 1.1.2) and sosGetCapabilities_xsd (version1.0.0).

The main contents of the sosGetObservation_xsd schemaare the follow elements: “service”, “version”, “result”, “re-sponseFormat”, “resultMode”, “responseMode”, “srsName”,“offering”, “eventTime”, “procedure”, “observedProperty”, and“featureOfInterest”. The main contents of the schema of wc-sGetCoverage_xsd are elements such as “service”, “version”,“Identifier”, “DomainSubset”, “RangeSubset”, and “output”.There are five mappings between the two schemas: “service”,“version”, “responseFormat”, “srsName”, and “temporalOps”.The generated correspondent and mapping information areshown in Fig. 3.

4) Extractor Component: The extractor component convertsthe XML document from a SOS response or a WCS requestinto a new document to meet the specified requirements usinga XSLT template and a XSLT processor. The XSLT template isgenerated by the above transformer component. The new doc-ument is serialized by the processor in standard OGC SOS orWCS XML syntax. The extraction is executed dynamically bythe service middleware. The XSLT processor ordinarily takestwo input documents—an XML source document, and an XSLTstyle sheet—and produces an output document.


Fig. 3. Mapping between wcsGetCoverage_xsd and sosGetObservation_xsdschema.

WCS “GetCapabilities” extraction is to generate a responseto the WCS “GetCapabilities” request from the response of SOS“GetCapabilities” request. The XSLT processor transforms theresponse of SOS “GetCapabilities” request to the correspondentresponse of WCS “GetCapabilities” request according to thestyle sheet file generated from transformer component. Herewe take the example of EO-1 SOS implemented by GeoBliki(http://eo1.geobliki.com/sos). Capabilities file of the EO-1satellite can be retrieved by the SOS “GetCapabilities” request.Just as shown in the top part of Fig. 4, the source EO-1 SOS“GetCapabilities” response contains five main elements: “Ser-viceIdentification”, “ServiceProvider”, “Operations Metadata”,“Filter_capabilities”, and “Contents”. As is shown in the lowerpart of Fig. 4, the generated CSISS WCS “GetCapabilities” re-sponse contains three main elements: “Service”, “Capability”,and “ContentMetadata”.

The “Service” element in CSISS WCS “GetCapabilities”response contains “description”, “name”, “label”, “keywords”,“responsibleParty”, “fees”, and “accessConstraints”. For ex-ample, the value of the “keywords” element is “EO1, SOS,satellite, ali, hyperion, fire, flood” and generated from the“keywords” element in EO-1 SOS “GetCapabilities” response.The “Service” element in CSISS WCS “GetCapabilities” re-sponse contains “description”, “name”, “label”, “keywords”,

Fig. 4. Instance of WCS “GetCapabilities” request extraction.

“responsibleParty”, “fees”, and “accessConstraints”. For ex-ample, the value of the “keywords” element is “EO1, SOS,satellite, ali, hyperion, fire, flood” and generated from “key-words” element in EO-1 SOS “GetCapabilities” response.The “Capability” element in CSISS WCS “GetCapabilities”response contains description information of “GetCapabili-ties”, “DescribedCoverage”, and “GetCoverage” operation.The “ContentMetadata” element in CSISS WCS “GetCapabili-ties” response contains one or many “CoverageOfferingBrief”elements. One “CoverageOfferingBrief” contains “name”,“label”, and “lonLatEnvelope” elements; for example, the value


Fig. 5. UML diagram of EO-1 SOS response extraction.

of “lonLatEnvelope” element is generated from the “bound-edBy” element in EO-1 SOS “GetCapabilities” response.

Just as shown in the Fig. 5, WCS “GetCoverage” extractionis to generate a response to the WCS “GetCoverage” requestfrom the response of SOS “GetObservation” request. The XSLTprocessor transforms the response of a SOS “GetObservation”request to the correspondent response of WCS “GetCoverage”request according to the style sheet file generated from trans-former component. Just as shown in the Fig. 5, we take the ex-ample of EO-1 SOS implemented by GeoBliki (http://eo1.geob-liki.com/sos).

Just as shown in the top part of Fig. 6, the O&M documentof the EO-1 satellite can be retrieved by SOS “GetObser-vation” request. The value of the “result” element in EO-1SOS “GetObservation” response is the URL of the detailedEO-1 data product; for example, “http://eo1.geobliki.com/hy-perion/EO1H0410342004085110PY-2007-01-25T17:02:18Z.tar.gz” link attribute. As is shown in the lower part of Fig. 6,a “WCSCoverage” object [5] can be generated from the “re-sult” element. The generated “WCSCoverage” object contains“granule”, “name”, “label”, “gridEnvelopLow”, “gridEn-velopHigh”, “xAxisName”, “yAxisName”, “originPoint”,“xResolution”, “yResolution”, “requestCRSs”, “response-CRSs”, “nativeCRSs”, “supportedFormats”, “nativeFormat”and “BBOX” elements. Thus, the “WCSCoverage” data canbe added by “Transaction” operation and served by “GetCov-erage” operation through the specified WCS server.

B. Interaction

1) External Interactions Between RCS and a SOS: Theresponse of RCS is generated from SOS. RCS service in-formation in the “GetCapabilities” is generated from the“ServiceIdentification”, “ServiceProvider”, and “Operations-Metadata” elements in the SOS “GetCapabilities” responsethrough schema transformer and information extractor. RCScoverage description information—observation platform,

Fig. 6. Instance of WCS “GetCoverage” response generation.

phenomenon observed, space extent, temporal period and anencoding model of the result in the “DescribeCoverage”—isgenerated from the “ObservationOfferingList” element in theSOS “GetCapabilities” response. RCS coverage informationcontaining geographical scope, data format, spatial reference,and resolution information is generated from the SOS “GetOb-servation” response.

2) Internal Interactions Between Transformer and Extractor:The extractor component invokes the transformer component togenerate “GetCapabilities”, “DescribeCoverage” and “GetCov-erage” XSLT templates between a SOS and a WCS. The XSLTprocessor in the extractor component transforms the responseof SOS to the correspondent response of WCS according to thespecified XSLT template. A template can contain elements thatspecify literal result element structure and also contain elementsfrom the XSLT namespace that are instructions for creating re-sult tree fragments.


TABLE IEO-1 HYPERION DATA SET

TABLE IITHE GETCOVERAGE REQUEST EXPRESSED AS KEY-VALUE PAIRS

IV. EXPERIMENTS AND RESULTS

A. EO-1 Sensor Web

EO-1 [39] is the first satellite in NASA’s New MillenniumProgram Earth Observing series. The primary focus of EO-1 isto develop and test a set of advanced technology land imaginginstruments. EO-1 was launched on a Delta 7320 from Vanden-berg Air Force Base on November 21, 2000. The EO-1 satellitecontains three observing instruments supported by a variety ofnewly developed space technologies. The three observing in-struments onboard are an advanced land imager (ALI), a hy-perspectral imaging sensor Hyperion, and an atmospheric cor-rector. The case studies described in this paper use hyperspectraldata from the Hyperion instrument. The Hyperion is a high-res-olution imager capable of resolving 242 spectral bands (from0.4 to 2.5 m) with a 30-meter spatial resolution. Each imageshows a 7.5 km by 42 km land area. Detailed spectral mappingis provided with high radiometric accuracy for all 242 channels.

EO-1 Sensor Web project [34] now provides SOS (http://eo1.geobliki.com/sos/) and SPS (http://eo1.geobliki.com/sps/).

Observations can be scheduled by SPS, the basic service in-formation, “offering” capability can be acquired through theSOS “GetCapabilities” operation, and the high spectrum imagedata of the Hyperion instrument can be obtained by the SOS“GetObservation” operation accepting data more recent than“2005-10-18T15:19:39.000Z”.

B. Experiment Environment

As shown in Table I, EO-1 SOS contains 10 observation of-ferings; each offering includes 242 bands, and the total data sizeof an observation at a particular moment is about 1.56 GB.

The detailed information of the experiment environmentshown in Fig. 7 is as follows:

1) User sends a “GetCoverage” request to the built-in WCS(http//geobrain.laits.gmu.edu/cgi-bin/gdalwcs/gdalwc-swcs?) in RCS. A “GetCoverage” request includes datatype, time-space and description information. An exampleis shown in Table II.

2) RCS generates a “GetObservation” request (shown inTable III) using transformer and extractor, RCS sends the


TABLE IIITHE GETOBSERVATION REQUEST EXPRESSED AS KEY-VALUE PAIRS

Fig. 7. Illustration of experiment environment (1. Client sends a “GetCoverage” request to RCS server, 2. RCS transforms the “GetCoverage” request to a EO-1SOS “GetObservation” request, 3. RCS sends the “GetObservation” request to the EO-1 SOS Server, 4. RCS gets a “GetObservation” response in O&M, 5. RCStransforms the “GetObservation” response to a “GetCoverage” response, 6. Client gets a subsetted hyperion image in GeoTIFF).

request to EO-1 SOS. The “GetObservation” operationprovides access to sensor observations and measurementdata via a spatio-temporal query that can be filtered byranges of time and location.

3) RCS analyzes “GetObservation” response and packagesthe result set into “WCSCoverage”. For EO-1 SOS, a WC-SLayer data granule record is generated and populated asa coverage by a WCS transaction operation.

4) The value of “COVERAGE” parameter inRCS is change to “/usr/local/1172512474854/EO1H0140322006342100PF_ B240_L1T-2109035.tif”;then RCS sends the concrete “GetCoverage” request tothe WCS server.

5) RCS can provide online data on-demand services by theconcrete WCS subset function. The client can invoke theconcrete WCS server “GetCoverage” operation to get thesubsstted image and overlay the image on a visualizationtool.

C. Result

This section reports the response time of the EO data servicein two different methods. Eleven groups of experiments wereconducted for each of two general methods: one is the RCSmethod, the other is OGC Sensor Web method. There are threevariations of the RCS method (“Portable Network Graphics(PNG)”, “Joint Photographic Experts Group (JPEG)” and


TABLE IVRESPONSE TIME OF FOUR DIFFERENT METHODS (� � �� ; � � �� ; � � �� ;

� � �� ; AND � � �� )

Fig. 8. Total response time of two methods.

“Graphics Interchange Format (GIF)”). Each group refers toa different number of bands in an observation, provided bythe “EO1H0140322006342100PF” offering: 1, 2, 10, 20, 40,80, 120, 160, 200, and 220 to 242 bands, the original data ofeach band is encoded in GeoTIFF file format, if we send 242bands observation request to the EO-1 SOS, we can get 242individual GeoTIFF files packaged in a “*.tar.gz” URL link,each GeoTIFF file is described by a “WCSCoverage” objectand served by CSISS WCS. The methods are EO-1 SOS, RCSPNG, RCS GIF, and RCS JPEG. In the EO-1 SOS method,users send a “GetObservation” request directly to the SOSserver, and the SOS server processes the request, packages theobserved data and transfers the raw data to the users. In the RCSmethod, users send a “GetCoverage” requests to RCS, RCSthen sends the “GetObservation” request to the SOS serverand obtain the raw data. The built-in WCS in RCS serve thedata on-demand. The RCS method can be divided into PNG,JPEG, and GIF variations, depending upon the format of theresponse. If the RCS, WCS and SOS servers are deployed ina 1000 Mbps Local Area Network (LAN) and the client andserver are connected by 10 Mbps Wide Area Network (WAN),the data transmission time between RCS, WCS, and SOS canbe neglected. The response time of the two methods weremeasured. Table IV shows the results. The R, T, U, and F items

represent, respectively, data request, transmission, extraction,and total response time in the EO-1 SOS method. The PNG,JPEG, and GIF items represent response times of the threedifferent variations of RCS; the P, T, and F items in GIF methodof RCS represent, respectively, the online data processing, datatransmission, and the overall response times.

1) The Total Response Time of Methods: The first studywas of the total response time for data service in two differentmethods. Fig. 8 shows the results. The response time in thetwo methods increases with the number of bands; the morebands in a data set, the longer the required response time. Thisincrease displays a linear tendency with the number of bands;the response time in the RCS JPEG method tends to equal thatof the RCS PNG method; the response time in the RCS GIFmethod is between the EO-1 SOS method and the RCS PNGmethod; the response time in EO-1 SOS is more than that ofthe RCS PNG method. The results of the test show that RCSperforms better than EO-1 SOS method.

Moreover, the growth rate of response time with the amountof data in the RCS JPEG method or RCS PNG method is smallerthan that of the RCS GIF method and EO-1 SOS method. TheRCS JPEG method varies from 0.10 to 0.34 and the averagevariation rate is 0.18; the RCS PNG method varies from 0.15 to0.34 and the average variation rate is 0.21; the RCS GIF method


Fig. 9. Average response time of two methods.

varies from 0.50 to 1.52 and the average variation rate is 0.96;the EO-1 SOS method varies from 0.38 to 2.26 and the averagevariation rate is 1.05.

2) The Average Response Time of Methods: The secondstudy was of the mean total response time per band for dataservice in two different methods. Fig. 9 shows the results. Themean response time in RCS JPEG method was comparable tothat in the RCS PNG method, the mean response time for EO-1SOS was greater than that for the RCS PNG method, and themean response time in the RCS GIF method was between thatof EO-1 SOS method and RCS PNG method. The RCS JPEGmethod response varied from 1.05 to 1.64 seconds per band,with a mean response time of 1.28 seconds per band, that is0.193 seconds per KB. The RCS PNG method response variedfrom 1.00 to 1.67 seconds per band, with a mean response timeof 1.25 seconds per band, or 0.188 seconds per KB. The RCSGIF method varied from 6.15 to 6.98 seconds per band, with amean response time of 6.47 seconds per band, or 0.97 secondsper KB. The EO-1 SOS method varied from 2.4 to 10.3 secondsper band with a mean response time of 7.11 seconds per band,or 1.07 seconds per KB. The average response time of the RCSPNG method is 17.6% of that of the EO-1 SOS method.

V. DISCUSSIONS

This section analysis the performance of the two methods anddiscusses the benefits of the proposed RCS method.

A. Stability Comparison Between EO-1 SOS Method and RCSMethod

Just as Fig. 8 shows, the growth rate of response time with theamount of data in the RCS JPEG method or RCS PNG methodis smaller than that of the RCS GIF method and EO-1 SOSmethod. The RCS JPEG method varies from 0.10 to 0.34 andthe average variation rate is 0.18; the RCS PNG method variesfrom 0.15 to 0.34 and the average variation rate is 0.21; the RCSGIF method varies from 0.50 to 1.52 and the average variationrate is 0.96; the EO-1 SOS method varies from 0.38 to 2.26 andthe average variation rate is 1.05. For the response time in thetwo methods, the RCS JPEG is the most stable and EO-1 SOS isthe most unstable method, varying 5.8 times as much as the RCS

Fig. 10. Execution time of each phase in EO-1 SOS method.

Fig. 11. Execution time of each phase in RCS GIF method.

JPEG method. The RCS method has in general higher stabilitythan the EO-1 SOS method. The potential cause is the outputof the EO-1 SOS “GetObservation” is encoded by lossless Geo-TIFF format, while JPEG is a commonly used method of lossycompression for photographic images.

B. Influences Comparison on Performance in EO-1 SOSMethod and RCS Method

Table IV shows the response times, including those for datarequests (R), transmission (T), and unzipping (U). The resultsconverted into percentages are shown in Fig. 10. Request timeoccupies 5%–45% of the time, the average value is 14%; trans-mission time occupies 40%–85%, the average value is 75%; andunzip time occupies 10%–15%, the average value is 11%.

Table IV shows the response times, including those for dataprocessing stages (P) and data transmission (T). The results con-verted into percentages are shown in Fig. 11. Processing timeoccupies 60%–96% of the time, the average value is 69%; whiletransmission time occupies 4%–40%, the average value is 31%.

From the above analysis, the processing time is the dominantinfluence on the response time in the RCS GIF method, while thetransmission time is the dominant influence on the EO-1 SOSmethod response time. The potential cause is that RCS methodhas the sub-setting functions in server side. For the RCS method,use of a high-performance server, server cluster, or Grid de-ployment could enhance the performance of the server. Servicequality could be controlled by service providers. For EO-1 SOS


method, increasing network bandwidth and the reduce transmis-sion of data could be used to obtain a higher quality of ser-vice; however, the service provider could not control the net-work bandwidth, and the server-side scalability is limited.

As is well known, the average total response time reflectsthe execution efficiency, while the average variation of responsetime reflects the stability of the system. The above results showthat the RCS PNG method is the most efficient, the EO-1 SOSmethod is the least efficient, the RCS JPEG method is the moststable, and the EO-1 SOS method is the most unstable in theresponse time of data retrieval.

C. SOA Based Standard Data Service System

The RCS is a Web service oriented data service system. TheWCS, schema transformer, information extractor and SOS areimplemented by plug-and-play components, packaged into Webservices, and exposed their functions by the WSDL. The aboveWeb services are more adequate for loosely coupled systems,where the clients might have no prior knowledge of web ser-vices until they invoke them. The above Web services can beregistered in the ebRIM CSW server and achieved better per-formance of the near-real-time on-demand remote-sensing ob-servation service by the optimum combination.

D. Disadvantage of the Proposed RCS Method

In the RCS method, compressed 8 bit PNG and JPEG fileformats are nice for visualization, but have a series of limi-tations. As we know, when automatic information extractionfrom EO imagery is performed, often an accurate radiometryis needed. The real radiometric information is often stored in11-bit or more using TIFF or some proprietary formats. TheRCS PNG/JPEG/GIF method is not suitable for automatic in-formation extraction. The next step is to develop the RCS TIFFor GeoTIFF method under grid computing or cloud computingenvironment to achieve the high performance information ex-traction.

VI. CONCLUSIONS

How to achieve high performance in serving observationaldata on-demand in a virtual Web-ready sensors environment hasbecome a bottleneck in applications enabled by the geospatialSensor Web. This paper proposes a method for using SOS andWCS, based on RCS service middleware, to develop a systemfor the distribution of Sensor Web data. The methodology is animprovement over the existing OGC data service method andOGC SWE enabled data service method mentioned in Section I:

1) The RCS system is a standard data service system, whichuses service middleware, a universal “WCS” interface, toaccess near-real-time earth observation data sources.

2) The RCS method uses middleware to link the Sensor DataService Method and the Sensor Web Data Service Method.RCS hides the complexity of the EO (Earth-Observation)world behind its standard interfaces.

3) In the RCS method, SOS observation data can be servedthrough OGC WCS. Thus, this method can provide onlinedata on-demand services by the WCS subset function.

4) The RCS method has higher stability than the EO-1 SOSmethod. The response time variation with data size in the

EO-1 SOS method is 5.8 times that of the RCS JPEGmethod.

5) The RCS method is more efficient than the EO-1 SOSmethod. The average response time per band in the RCSPNG method is 17.6% of that for the EO-1 SOS method.

6) Transmission is the dominant influence on the EO-1 SOSresponse time and processing is the dominant influence inthe RCS method.

Access to the sensor Web system is by SPS and SOS. The nextstep is to study how to provide an open self-adaptive geospatialdata service by harmonizing SPS, SOS, and WCS and achievethe high performance information extraction.

ACKNOWLEDGMENT

The authors sincerely thank Dr. David A. Tait, for proof-reading the manuscript. The authors would also like to thank theeditors and anonymous reviewers for their valuable commentsand insightful ideas.

REFERENCES

[1] D. Butler, “2020 computing: Everything, everywhere,” Nature, vol.440, no. 7083, pp. 402–405, 2006.

[2] M. Botts and A. Robin, “Bring the sensor web together,” Geosciences,vol. 6, pp. 46–53, 2007.

[3] K. Moe, S. Smith, G. Prescott, and R. Sherwood, “Sensor web tech-nologies for NASA earth science,” in Proc. IEEE Aerosp. Conf., BigSky, Montana, Mar. 1–8, 2008.

[4] L. Di, “Geospatial sensor web and self-adaptive earth predictive sys-tems (SEPS),” in Proc. Earth Sci. Technol. Office (ESTO)/Advanced Inf.Syst. Technol. (AIST) Sensor Web Principal Investigator (PI) Meeting,San Diego, CA, Feb. 13–14, 2007.

[5] N. Chen, L. Di, G. Yu, J. Gong, and Y. Wei, “Use of Ebrim-based CSWwith sensor observation services for registry and discovery of remote-sensing observations,” Comput. Geosci., vol. 35, no. 2, pp. 360–372,2009.

[6] N. Chen, L. Di, G. Yu, and M. Min, “A flexible geospatial sensor ob-servation service for diverse sensor data based on web service,” ISPRSJ. Photogramm. Remote Sens., vol. 64, no. 2, pp. 234–242, 2009.

[7] NASA, “2008 report from the earth science technology office(ESTO) advanced information systems technology (AIST) sensor webmeeting,” in Proc. ESTO/AIST Sensor Web Principal Investigator (PI)Meeting, Orlando, FL, Apr. 2–3, 2008.

[8] S. Kempler, C. Lynnes, B. Vollmer, G. Alcott, and S. Berrick, “Evo-lution of information management at the GSFC earth sciences (GES)data and information services center (DISC): 2006–2007,” IEEE Trans.Geosci. Remote Sens., vol. 47, no. 1, pp. 21–28, 2009.

[9] B. Luis, B. Philip, B. Eric, C. Tony, G. Charlton, C. Gerry, F. David,and G. John, “Web feature service (WFS) and sensor observation ser-vice (SOS) comparison to publish time series data,” in Proc. Int. Symp.Collab. Technol. Syst., Baltimore, MD, May 18–22, 2009.

[10] L. Di, K. L. Moe, and G. Yu, “Metadata requirements analysis for theemerging sensor web,” Int. J. Digital Earth, vol. 2, pp. 3–17, 2009,Suppl. 1.

[11] Y. Wei, L. Di, B. Zhao, G. Liao, A. Chen, Y. Bai, and Y. Liu, “The de-sign and implementation of a grid-enabled catalogue service,” in Proc.IEEE IGARSS Symp., Seoul, Korea, Jul. 25–29, 2005.

[12] C. Zhang and W. Li, “The roles of web feature and web map servicesin real-time geospatial data sharing for time-critical applications,” Car-tography and Geographic Inf. Syst., vol. 32, no. 4, pp. 269–283, 2005.

[13] S. Nativi, L. Bigagli, B. Domenico, J. Caron, and E. Davis, “ExtendingTHREDDS middleware to serve OGC community,” Adv. Geosci., vol.8, pp. 57–62, 2006.

[14] N. Chen, S. Gao, J. Gong, W. Ye, and Z. Nie, “Implementation andintegration of web coverage service based on multi-source data,” inProc. Int. Soc. Opt. Eng. Geoinformat. Geospat. Inf. Technol., Wuhan,China, Oct. 28–30, 2006.

[15] OGC Catalogue Services Specification (Version 2.0.2), OGC Standard,218, 2007.

[16] OGC Web Feature Service Implementation Specification (Version1.1.0), OGC Standard, 131, 2005.


[17] OGC Web Coverage Service Implementation Stand. (Version 1.1.2),OGC Standard, 133, 2008.

[18] ISO 19123: Geographic Information—Schema For Coverage Geom-etry and Functions, ISO Standard, 65, 2005.

[19] ISO 19136: Geographic Information—Geography Markup Language(GML), ISO Standard, 394, 2007.

[20] M. Deng and L. Di, “Building an online learning and research environ-ment to enhance use of geospatial data,” Int. J. Spatial Data Infrastruc-tures Res., vol. 4, pp. 77–95, 2009.

[21] N. Chen, L. Di, G. Yu, and J. Gong, “Geo-processing workflow drivenwildfire hot pixel detection under sensor web environment,” Comput.Geosci., vol. 36, no. 3, pp. 362–372, 2010.

[22] OpenGIS Sensor Model Language Implementation Specification (Ver-sion 1.0.0), OGC Standard, 180, 2007.

[23] Observations and Measurements—Part 1—Observation Schema (Ver-sion 1.0), OGC Standard, 85, 2007.

[24] Observations and Measurements—Part 2—Sampling Features (Version1.0), OGC Standard, 46, 2007.

[25] OpenGIS Transducer Markup Language Implementation Specification(Version 1.0.0), OGC Standard, 136, 2006.

[26] OpenGIS Sensor Planning Service Implementation Specification (Ver-sion 1.0), OGC Standard, 186, 2007.

[27] OpenGIS Sensor Obs. Service Implementation Specification (Version1.0), OGC Standard, 104, 2007.

[28] OpenGIS Sensor Alert Service Implementation Specification (Version0.9.0), OGC Standard, 144, 2006.

[29] OpenGIS Web Notification Service (Version 0.1.0) OGC DiscussionPaper, 38, 2003.

[30] OpenGIS Sensor Event Service Interface Specification (Version 0.3.0),OGC Discussion Paper, 88, 2008.

[31] M. Reichardt, “The Sensor Web’s: Point of beginning,” GeoSpatial So-lutions, vol. 13, no. 4, pp. 40–43, 2003.

[32] M. Reichardt, “Building the Sensor Web,” GeoSpatial Solutions, vol.14, no. 3, pp. 36–38, 2004.

[33] S. H. L. Liang, A. Croitoru, and C. V. A. Tao, “Distributed geospatialinfrastructure for Sensor Web,” Comput. Geosci., vol. 31, no. 2, pp.221–231, 2005.

[34] D. Mandl, “Experimenting with Sensor Webs using Earth Observing1,” in Proc. IEEE Aerosp. Conf. Proc., MD, USA, Mar. 13–13, 2004.

[35] A. W. Bingham, S. McCleese, T. Stough, R. G. Deen, K. Hussey, andN. Toole, “Earth science datacasting: Informed pull and informationintegration,” IEEE Trans. Geosci. Remote Sens., vol. 47, no. 10, pp.3570–3580, 2009.

[36] D. Bulter, “Agencies join forces to share data,” Nature, vol. 446, no.7134, p. 354, 2007.

[37] A. H. Doan, P. Domingos, and A. Halevy, “Reconciling schemas ofdisparate data sources: A machine-learning approach,” SIGMOD Rec.,vol. 2001, pp. 509–520, 2001.

[38] XSL Transformations (XSLT) (Version 1.0), W3C RecommendationStandard, 102, 1999.

[39] S. G. Ungar, J. S. Pearlman, J. A. Mendenhall, and D. Reuter,“Overview of the earth observing one (EO-1) mission,” IEEE Trans.Geosci. Remote Sens., vol. 41, no. 6, pp. 1149–1159, Jun. 2003.

Nengcheng Chen received the B.Sc. degree ingeodesy from Wuhan Technical University ofSurveying and Mapping, China, in 1997, the M.S.degree in geographical information systems fromWuhan University, China, in 2000, and the Ph.D.degree in photogrammetry and remote sensing fromWuhan University in 2003.

He was a post-doctoral research associate with theCenter for Spatial Information Science and Systems,George Mason University, Greenbelt, MD, from2006 to 2008. Currently, he is a Professor of geo-

graphic information science at the State Key Lab for Information Engineeringin Surveying, Mapping and Remote Sensing, Wuhan University, Wuhan, Hubei,China. His research interests include Smart Planet, Sensor Web, Semantic Web,Digital Antarctica, Smart City, and Web GIS.

Prof. Chen is a member of the International Association of Chinese Profes-sionals in Geographic Information Sciences (CPGIS). He was the chair of the2010 CPGIS Young Scholar Summer Workshop.

Zeqiang Chen received the B.Sc. degree in geog-raphy from Huazhong Nomal University, China, in2005, and the M.S degree in geographical informa-tion systems from Wuhan University, China, in 2008.He is currently pursuing the Ph.D. degree in LIES-MARS at Wuhan University.

He is also a research assistant in CSISS at GeorgeMason University, Greenbelt, MD. His currentresearch interests include Semantic Web and SensorWeb.

Liping Di (M’01–SM’05) received the B.Sc. degreein remote sensing from Zhejiang University, China,in 1982, the M.S. degree in remote sensing/computerapplications from the Chinese Academy of Sciencein 1985, and the Ph.D. degree in geography from theUniversity of Nebraska–Lincoln in 1991.

He was a research scientist at the ChineseAcademy of Science from 1985 to 1986 and theNOAA National Geophysical Data Center from1991 to 1994. He served as a principal scientist from1994 to 1997 and a chief scientist from 1997 to

2000 at Raytheon ITSS. Currently, he is a Professor of geographic informationscience and the Director of the Center for Spatial Information Science andSystems, George Mason University, Greenbelt, MD. His research interestsinclude remote sensing, geographic information science and standards, spatialdata infrastructure, global climate and environment changes, and advancedEarth observation technology.

Jianya Gong received the Ph.D. degree in pho-togrammetry and remote sensing from WuhanTechnical University of Surveying and Mapping,China, in 1992.

He is currently a Professor and Director in theState Key Lab of Information Engineering in Sur-veying, Mapping and Remote Sensing (LIESMARS)at Wuhan University, China. He was the ChairProfessor of the Cheung Kong Scholars Program,Visiting Professor in the Department of Surveyingand Land Information at Hong Kong Polytechnic

University from in 1998, and Visiting Professor in the Department of Ge-ography at the University of Massachusetts during 1995–1996. His researchinterests include GIS and remote sensing.

ieee journal of selected topics in applied earth ...swe.whu.edu.cn/cnc_web/paper/chen...

Documents