This article appeared in a journal published by Elsevier. The attached copy is furnished to the author for internal non-commercial research and education use, including for instruction at the authors institution and sharing with colleagues. Other uses, including reproduction and distribution, or selling or licensing copies, or posting to personal, institutional or third party websites are prohibited. In most cases authors are permitted to post their version of the article (e.g. in Word or Tex form) to their personal website or institutional repository. Authors requiring further information regarding Elsevier’s archiving and manuscript policies are encouraged to visit: http://www.elsevier.com/copyright
Transcript
This article appeared in a journal published by Elsevier. The attachedcopy is furnished to the author for internal non-commercial researchand education use, including for instruction at the authors institution
and sharing with colleagues.
Other uses, including reproduction and distribution, or selling orlicensing copies, or posting to personal, institutional or third party
websites are prohibited.
In most cases authors are permitted to post their version of thearticle (e.g. in Word or Tex form) to their personal website orinstitutional repository. Authors requiring further information
regarding Elsevier’s archiving and manuscript policies areencouraged to visit:
A flexible geospatial sensor observation service for diverse sensor data based onWeb serviceNengcheng Chen a,b, Liping Di a,∗, Genong Yu a, Min Min aa Center for Spatial Information Science and Systems, George Mason University, 6301 Ivy Lane, Suite 620, Greenbelt, MD 20770, USAb State Key Lab for Information Engineering in Surveying, Mapping and Remote Sensing (LIESMARS), Wuhan University, 129 Luoyu Road, Wuhan 430079, China
a r t i c l e i n f o
Article history:Received 26 July 2007Received in revised form22 October 2008Accepted 8 December 2008Available online 20 January 2009
Keywords:Sensor WebSOSCSWMySQLEO-1
a b s t r a c t
Achieving a flexible and efficient geospatial Sensor Observation Service (SOS) is difficult, given thediversity of sensor networks, the heterogeneity of sensor data storage, and the differing requirementsof users. This paper describes development of a service-oriented multi-purpose SOS framework. The goalis to create a single method of access to the data by integrating the sensor observation service with otherOpen Geospatial Consortium (OGC) services — Catalogue Service for the Web (CSW), Transactional WebFeature Service (WFS-T) and Transactional Web Coverage Service (WCS-T). The framework includes anextensible sensor data adapter, an OGC-compliant geospatial SOS, a geospatial catalogue service, a WFS-T, and aWCS-T for the SOS, and a geospatial sensor client. The extensible sensor data adapter finds, stores,and manages sensor data from live sensors, sensor models, and simulation systems. Abstract factorydesign patterns are used during design and implementation. A sensor observation service compatiblewith the SWE is designed, following the OGC ‘‘core’’ and ‘‘transaction’’ specifications. It is implementedusing Java servlet technology. It can be easily deployed in any Java servlet container and automaticallyexposed for discovery usingWeb Service Description Language (WSDL). Interaction sequences between aSensor Web data consumer and an SOS, between a producer and an SOS, and between an SOS and a CSWare described in detail. The framework has been successfully demonstrated in application scenarios forEO-1 observations, weather observations, and water height gauge observations.Published by Elsevier B.V. on behalf of International Society for Photogrammetry and Remote Sensing,
Inc. (ISPRS).
1. Introduction
A sensor network is a computer-accessible network of spatiallydistributed sensors that monitor conditions such as temperature,sound, vibration, pressure, motion, or pollutants at differentlocations. Measurements made from sensor systems, whetherin-situ sensors (e.g., water monitoring) or dynamic sensors(e.g., satellite imaging), contribute most of the volume of thegeospatial data used in geospatial systems today. The term SensorWeb was first proposed by the National Aeronautics and SpaceAdministration (NASA) Sensor Web Applied Research PlanningGroup. In 2001, NASA provided the following definition (Delin andJackson, 2001): a Sensor Web is a system of intra-communicatingspatially distributed sensor pods that can be deployed to monitorand explore new environments. NASA’s direction for 2005 andbeyond (NASA, 2005) stated, ‘‘NASA will develop new space-basedtechnology to monitor the major interactions of the land, oceans,atmosphere, ice, and life that comprise the Earth system. In the
years ahead, NASA’s fleet will evolve into human-made constellationsof smart satellites that can be reconfigured based on the changingneeds of science and technology. From there, researchers envision anintelligent and integrated observation network comprised of sensorsdeployed to vantage points from the Earth’s subsurface to deep space.This ‘sensor web’ will provide timely, on-demand data and analysisto users who can enable practical benefits for scientific research,national policymaking, economic growth, natural hazard mitigation,and the exploration of other planets in this solar system and beyond’’.In 2005, the Geospatial Information and Communication (GeoICT)Lab (Liang et al., 2005) in Canada broadened the above scope byincluding awide range of sensors and applications in the definitionof the Sensor Web, which they defined as an electronic skinof the Earth, offering full dimensional, full-scale, and full-phasesensing and monitoring at all levels, global, regional, and local. Di(2007), the director of Center for Spatial Information Science andSystems (CSISS) at George Mason University (GMU) has definedthe Geospatial Sensor Web as the Sensor Web that performs Earthobservations (EO) and envisioned thatmajor new EO sensors in thefuture will be Web-ready.Lee and Reichardt (2005) discuss the three approaches for
Sensor Network construction — that of the Institute of Electrical
0924-2716/$ – see front matter. Published by Elsevier B.V. on behalf of International Society for Photogrammetry and Remote Sensing, Inc. (ISPRS).doi:10.1016/j.isprsjprs.2008.12.001
Author's personal copy
N. Chen et al. / ISPRS Journal of Photogrammetry and Remote Sensing 64 (2009) 234–242 235
and Electronics Engineers (IEEE), the National Institute of Stan-dards and Technology (NIST), and the Open Geospatial Consor-tium (OGC). The IEEE 1451 Smart Transducer Interface Standards,OGC’s SWE program and NIST’s Network Sensor Standards havebeen used for Homeland Security (HLS) sensor networks. OGC andthe International Organization for Standardization (ISO) have beendeveloping standards and protocols for the geospatial sensor web.The SWE program initiatives (Simonis, 2005; Botts, 2006; Cox,2006) have developed three information models and four serviceimplementation specifications. NASA has tested the EO-1 SensorWeb (Ip et al., 2006) as anOGCproject,mainly to verifywhether theSWE standard could be used for data from sensors on earth obser-vation satellites. OGC’s specifications for web services, geospatialportals, spatial data infrastructures, and sensor webs provide im-plementation specifications and architecture for the Global EarthObserving Systemof Systems (GEOSS). They have been put forwardby Percivall (2006).The Sensor Observation Service (SOS) (Na and Priest, 2006) is
one of the four service implementation specifications. OGC de-fines SOS as a service that provides standard Application Pro-gramming Interfaces (APIs) for managing deployed sensors andretrieving sensor data. It has three mandatory core operations—GetCapabilities, DescribeSensor and GetObservation, two optionaltransactional operations—RegisterSensor and InsertObservation,and six optional enhanced operations—GetResult, GetFeature-OfInterest, GetFeatureOfInterestTime, DescribeFeatureOfInterest,DescribeObservationType, and DescribeResultModel. The threemandatory core operations are used to help consumer discover andretrieve sensor and observations, the two optional transactionaloperations are used to help provider register sensor and observa-tions, the six optional enhanced operations are used to improve thequality of sensor and observations retrieval.Many SOS prototypes have been developed in the worldwide
Sensor Web community described in Section 2. However, theexisting systems have many problems:
(1) Current SOS systems cannot support a unified sensor modelfor geospatial sensors, which are heterogeneous. Observationscan be made from satellites, aircraft, boats, and land. Once asensor model has changed, the relevant SOSmust be modified,repackaged, and redeployed.
(2) Currently implemented SOS systems cannot meet the hetero-geneous requirements for storing andmanaging data observedby sensors. Geospatial sensor data may be stored in a flat file,a relational database, an object database, or an XML database.Once a data storage model has been changed, the relevant SOSmust be redesigned and re-implemented.
(3) Existing SOS systems are implemented as a Servlet or a PHPprogram. Service-oriented architectures that aremore flexible,in particular the emerging Web Service Architecture, cannotcurrently meet the diverse requirements of the CatalogueService—Web Profile (CSW), Web Feature Service (WFS), WebCoverage Service (WCS), and Multi-Protocol Geospatial Client(MPGC) clients. More specifically, existing SOS systems cannotmeet the large number of individual user requirements.
This paper deals with the above issues. It explains how to useService Oriented Architecture (SOA) and Java 2 Enterprise Edition(J2EE) Web service technology to design and implement a multi-purpose Sensor Observation Service.Related work is summarized in Section 2. Design considera-
tions, architecture, and themain components of the system are de-scribed in Section 3. The detailed implementation information forthe multi-purpose SOS is discussed in Section 4. In Section 5, theframework is adopted for three typical use cases, to demonstratethe feasibility of the proposedmethod. Section 6 summarizes find-ings and discusses what steps are needed next.
2. Related work
There have been many SOS implementations.The current 52◦ North SOS 1 release implements a core profile.
It consists of threemandatory operations and an optional ‘‘GetFea-tureOfInterest’’ operation. The SOS of 52◦ North is implementedas a servlet and can be deployed in any servlet container, for ex-ample, Tomcat 5.5. Sensor observation data can be stored in thePostgreSQL database. Some template files are provided for users tocreate customized SQL query tables with new data and metadata.On the client side, the OX-Framework (abbreviation for OWS Ac-cess Framework) provides an architecture that is sufficiently flex-ible and extendable to allow access to SWE SOS and subsequentvisualization of the queried data. It is connected to the SOS by aservice-connector component, SOS-Connector. The 52◦ North SOSimplementation is applied to a broad range of areas, ranging fromforest fire fighting to water pollution monitoring, for example, theAFIS (Advanced Fire Information System) project of the Council forScientific and Industrial Research (CSIR) in South Africa.GeoBliki2 emerged as a fusion of many web technologies.
To keep the cost of entry extremely low and avoid proprietaryimplementations that would have increased the barriers toentry, the GeoBliki team chose an open source approach.Ruby-on-Rails was chosen in GeoBliki SOS development for itsquick prototyping speed, its Model-View-Controller approach, itsMySQL support, and its built-in testing framework. The threemandatory core operations ‘‘GetCapabilities’’, ‘‘DescribeSensor’’,and ‘‘GetObservation’’ for SOS were implemented. A typicalapplication of GeoBliki SOS is the Earth Observing-1 (EO-1) SensorWeb project. The EO-1 mission has now shifted its emphasis fromhardware to software. EO-1 Sensor Web experiments include theAutonomous Sciencecraft Onboard Experiment, Onboard CloudCover Detection and Prediction, and Automated Detection ofVolcanoes and Fires with Collaborating Space Ground Assets.The final goal is to experiment with an evolving ground space-based software architecture to enable SensorWebs and eventuallyto develop full Autonomous Mission Operations Systems. EO-1 Hyperion data after 2005-10-18T15:19:39.000Z can be servedthrough EO-1 SOS.3The VisAnalysis Systems Technologies4 Team (VAST) performs
applied research and development on scientific visualization andanalysis, as well as on standard web-based technologies. It ispart of the Earth System Science Center at the University ofAlabama in Huntsville (UAH), located within the National SpaceScience and Technology Center (NSSTC). On the client side, theSpace Time Toolkit (STT) supports parsing and executing ofSensorML processing chains and SOS. The STT allows display ofmeasurements or derived quantities as an interactive 4D visualdisplay. The following five types of SOS are implemented in VAST:Satellite Orbital Elements SOS, Satellite Nadir Track SOS, SatelliteSensor Footprints SOS, Airdas unmanned aerial vehicle (UAV) SOSand Weather Station SOS.The Deegree5 SOS has been designed and implemented to
support the OGC SOS specification version 0.9.0, to connect toPostGIS, Oracle Spatial, or any database management systemsupporting JDBC and to support the GetCapabilities, DescribeSen-sor, DescribePlatformandGetObservation operations. Deegree SOS
1 N52 North SOS: http://52north.org/index.php?option=com_projects&task=showProject&id=4&Itemid=127. (Accessed July 21, 2008).2 GeoBliki: http://www.geobliki.com/pages/History. (Accessed July 21, 2008).3 EO-1 SOS demonstration: http://eo1.geobliki.com/sosdemo/. (Accessed July 21,2008).4 VAST: http://vast.uah.edu/joomla/index.php. (Accessed July 21, 2008).5 Deegree: http://www.deegree.org/deegree/portal/ (Accessed July 21, 2008).
Author's personal copy
236 N. Chen et al. / ISPRS Journal of Photogrammetry and Remote Sensing 64 (2009) 234–242
Table 1The SOS implementation comparison.
Feature Type52◦ North GeoBliki VAST Deegree
FunctionsGetCapabilities 3 3 3 3
GetObservation 3 3 3 3
DescribeSensor 3 3 3 3
GetFeatureOfInterest 3 × × ×
InsertObservation × × × ×
RegisterSensor × × × ×
GetResult 3 × × ×
GetFeatureOfInterestTime 3 × × ×
DescribeFeatureOfInterest 3 × × ×
DescribeObservationType 3 × × ×
DescribeResultModel × × × ×
DataBase PostgreSQL MySQL NONE MySQLProgram language Java Perl Java JavaService Servlet PHP Servlet ServletUser interface Html Ajax Html HtmlDCP request GET/POST POST GET/POST GETSensor type In-situ Remote Remote In-situClient OX-Framework × STT iGeoPortalTypical application AFIS EO-1 Weather station ×
3 Supported;× Unsupported.
is highly configurable so that existing relational databases can beconnected. On the client side, iGeoPortal is the web-based portalframework and offers visualization of geodata through a standardweb browser.Table 1 shows that, while, as of October 22, 2008, almost all SOS
have implemented all the mandatory operations, ‘‘RegisterSensor’’and ‘‘InsertObservation’’ transaction operations have not yet beenimplemented. Both in-situ and remote sensors are supported.Sensor data storage andmanagement in the SOS is either flattenedfile or sole Relational Database Management System (RDBMS).The Distributed Computing Platform (DCP) request is just HTTPGet or Post protocol. In short, the existing SOS cannot meetthe requirements of the diverse sensor networks, heterogeneoussensor data storage, and different users.
3. Design
3.1. Considerations
One of the critical components of a system enabled for theSensor Web is an infrastructure that can serve Observation andMeasurement (O&M) data provided by a sensor observationservice. The system must be interoperable with Sensor PlanningService, OGC CSW,WCS, andWFS. The systemmust be sufficientlyflexible to meet the requirements of diverse sensors. The goal ofthe system being developed is to providemiddleware componentsto manage and retrieve sensor observation data. The design of thesystem must use a loosely coupled architecture, in order to satisfythe requirements of diverse sensors and multiple users.
3.1.1. Service oriented architectureA service-oriented architecture (SOA) is used to design, develop,
and deploy the multi-purpose SOS. Every function in the SOSis a service and can perform a well-defined set of operations.Services can be registered, discovered, and accessed by differentclients using a uniform protocol. The system can be invoked andintegrated with others through the open interfaces and standardprotocols.
3.1.2. Diverse sensorsGeospatial sensor Web data can be either feature or coverage
data. Remote sensors, such as satellites, UAV, Laser Imaging
Detection and Ranging (LIDAR), and Aerial Digital Sensors (ADS),can be used to produce images of terrestrial phenomena.Observations encoded by coverage type can be served by WCS(Evans, 2003; Lee et al., 2005) or WCS-T servers. Spatiallydistributed in-situ sensors are commonly used to monitorconditions at different locations. Some of these conditions aretemperature, sound intensity, vibration, pressure, motion, andpollutants, these observations can be encoded as a feature typeand served byWFS (Vretanos, 2002) orWFS-T servers dynamically.The ‘‘RegisterSensor’’ interface in the transactional profile of SOSenables the sensor registry.
3.1.3. Heterogeneous databaseAuniformdata adapter interface of different relational database
management system (RDBMS) can be used to store and managespatiotemporal data. Current SOS implementations adopt differentRDBMS. Development of a flexible framework to feed multipleO&M data sources into a heterogeneous data management systemis a major challenge. The ‘‘InsertObservation’’ interface in thetransactional profile of SOS enables storage and management ofsensor observation data.
3.2. Architecture
To satisfy the above goals, service-oriented middleware archi-tecture has been adopted for the O&M data service for the geospa-tial Sensor Web. As shown in Fig. 1, the architecture contains thefollowing three layers: the presentation layer, the business layerand the data layer.The presentation layer consists of components with which
users can access, view, and manipulate geospatial sensor data. AMultiple Protocol Sensor Client (MPSC) makes a request to a CSWservice, gets SOS instances, binds the request to a specified SOS,obtains the O&M data from a SOS, and gets the coverage or featuredata from a WCS-T or a WFS-T. It includes a sensor map and somemethod for interacting with the sensor map through CSW, WFS-T,or WCS-T.A business layer consists of multiple adapters, one multiple-
purpose SOS, and a uniform WSDL service description. Theadapters find and retrieve the SensorWeb data from the data layerdescribed in the next paragraph. Themulti-purpose SOS is the corebusiness logic. From the viewpoint of a sensor data consumer, it
Author's personal copy
N. Chen et al. / ISPRS Journal of Photogrammetry and Remote Sensing 64 (2009) 234–242 237
Fig. 1. Service-oriented architecture of a flexible SOS.
Fig. 2. Interaction diagram of SOS with other components.
implements the OGC-compliant Sensor Observation Service oper-ations: ‘‘GetObservation’’, ‘‘GetCapabilities’’, and ‘‘DescribeSensor’’.From the viewpoint of a sensor data publisher, it implements theoptional transactional operations, ‘‘RegisterSensor’’ and ‘‘InsertOb-servation’’, for inserting new sensors and sensor observations intoan SOS. The WSDL description is used to expose the service, bind-ings, port types and operations of a specified SOS, so that the ser-vice can be invoked by different clients.A data layer provides the data source for the business layer. The
data layer stores and manages live sensor data. The sensor datasource can be a live remote sensor, an in-situ sensor, a tinywirelesssensor, an operational SOS, a dynamic spatio-temporal database,or a simulation system. The O&M data can be stored through thebusiness layer in a flattened file, an RDBMS, or an XML database.The WCS-T for an SOS transaction operation allows a MPSC
client to complete requests that a WCS server import one or morenew coverages from SOS and update or delete existing coverages.The WFS-T for an SOS transaction operation also allows a MPSCclient to fulfill requests for a WFS server to import one or morenew layers from SOS and update or delete existing layers. Bothoperations refer (externally and internally) to the data to beinserted or updated in theWCS server, and the server must resolvethese references, fetch data, and store data for future access.
3.3. Interaction
Fig. 2 is the interaction diagram. It shows that, in the methodimplemented, an SOS communicates with CSW, the consumer, thepublisher, and other SOSs.
3.3.1. Interactions between a sensor data consumer and a SOSA Sensor Web data consumer discovers SOS instances from a
CSW catalogue using the ‘‘GetRecords’’ operation. The consumerthen obtains the service-level for each service instance by request-ing the capabilities document and inspecting the observation of-ferings. The consumer invokes the ‘‘DescribeSensor’’ operation toretrieve detailed sensor metadata for those sensors advertisedin the observation offerings of the identified SOS instances. Thismetadata is in SensorML or TML. The consumer selects an appro-priate SOS and binds the SOS server to perform ‘‘GetObservation’’operation. Finally, the consumer calls the ‘‘GetObservation’’ opera-tion to actually retrieve the observations and serves the O&M dataas a coverage or a feature to the consumer using aWCS-T orWFS-Tserver.
3.3.2. Interactions between a Sensor Web data publisher and a SOSFig. 2 shows how a producer of Sensor Web data interacts
with an SOS instance that supports the transactional profile. Theproducer invokes the ‘‘GetRecords’’ operation on a CSW catalogto discover an SOS. When the producer determines that the SOSis communicating with a new sensor, the catalog service invokesthe ‘‘RegisterSensor’’ operation and registers the new sensor withthe SOS. The producer invokes the ‘‘InsertObservation’’ operationand publishes sensor observations from all sensors of the SOS. TheSOS instance then invokes the appropriate adapter and updates thecorresponding database.
3.3.3. Interactions between a SOS and a CSWFig. 2 also shows how a SOS instance interacts with a CSW
(Chen et al., 2005; Nebert andWhiteside, 2005; Voges and Senkler,2005;Wei et al., 2005) instance that supports the ebRIM profile. Ina catalog registry, an SOS service information model is registeredas a ‘‘ServiceType’’, SOS capability content is registered as an‘‘OfferingType’’, and SOS observation metadata can be registeredas either a ‘‘WCSCoverage’’ or a ‘‘WFSLayer’’ data granule. Thecapability content and data granule can later be discovered by aCSW ‘‘GetRecords’’ operation.
Author's personal copy
238 N. Chen et al. / ISPRS Journal of Photogrammetry and Remote Sensing 64 (2009) 234–242
4. Implementation
4.1. Adapter for multiple sensors
Fig. 3 shows that the SOS service can access zero or more SOSresources. Each SOS resource may be represented by an entity likea service, a relational database, or an XML database. A sensor dataadapter can be instantiated dynamically and used to access thedifferent sources of sensor data. The SOS service and its sensordata adapter will reside on the same server. A SOS resource hasan associated set of configuration files. These files specify theactivities it supports, the session information, and the class nameof its data resource adapter.The SOS data adapter is designed and implemented using the
Abstract Factory design pattern. The Abstract Factory pattern isintended to ‘‘provide an interface for creating families of related ordependent objects without specifying their concrete classes’’ (Gammaet al., 1995).Fig. 4 shows that an Abstract Factory class SOSDBFactory
provides interfaces for creating a number of data adapterinstances (MySQLDB and eXistDB). The system would have anynumber of derived concrete versions of the data base creatorclass like MySQLFactory or eXistFactory, each with a differentimplementation of createDB that would create a correspondingobject like MySQLDB or eXistDB. Each of these data adaptersis derived from a simple abstract class like SOSDB of which
Fig. 3. Adapter for multiple sensor data sources.
the client is aware. The client code would get an appropriateinstantiation of the SOSDBFactory and call its factory methods.The resulting objects would all be created from the same createDBimplementation and would share a common theme. The clientwould need to know how to handle only the abstract SOSDB class,not the specific version that it got from the concrete factory.The interface design and implementation of this SOS is based on
a Sensor Observation Service specification (Na and Priest, 2006),that defines the formal HTTP protocol binding interfaces andoperations a SOS should support. The specification also providesthe request, response, and exception messages for each operation.Fig. 5(a) shows that service discovery, observation discovery,
sensor metadata retrieval, sensor observation retrieval, sensorregistration, and publication of observations are designed andimplemented as eleven Java interfaces in the SOSDB abstractclass: IInsertObservation, IGetCapabilities, IGetFeatureInterest-ByTime, IDescribeObservationType, IDescribeSensor, IGetResult,IGetObservation, IGetObservationById, IRegisterSensor, IDescribe-FeatureOfInterest, and IGetFeatureOfInterest. Fig. 5(b) and (c)show that ‘‘MySQLAccessor’’ and ‘‘eXistAccessor’’ are concrete im-plementations. Moreover, users can customize their implementa-tions of the above eleven interfaces to support other databases.Fig. 5(b) shows a MySQL adapter implemented using Java
classes. MySQL is a multithreaded, multi-user SQL database man-agement system (DBMS) (Schumacher and Lentz, 2008). MySQLsupports spatial extensions that allow the generation, storage,and analysis of geographic features. The set of geometry typesproposed for MySQL is based on the OpenGIS Simple GeometryModel. Here, implementation of SOS interfaces that update and re-trieve sensor data is discussed, for example, MySQLRegisterSen-sor, MySQLInsertObservation and MySQL GetObservation, usingthe ‘‘geometry’’ column to store the O&M data from a data layer.The MySQLAccessor class and the MySQLConfig class are used tocreate a MySQL adapter instance. The MySQLConnectionPool classcreates and manages a connection to the MySQL database.Fig. 5(c) shows how an eXist adapter is implemented using
Java classes. The eXist database.. (Meier, 2003) is an open
Fig. 4. Abstract factory implementation of SOS data base adaptor.
Author's personal copy
N. Chen et al. / ISPRS Journal of Photogrammetry and Remote Sensing 64 (2009) 234–242 239
(a) The common interface of SOS. (b) The MySQL implementation. (c) The eXist implementation.
Fig. 5. MySQL and eXist adapter implementation.
source native XML database featuring efficient, index-basedXQuery processing, automatic indexing, extensions for full-textsearch, XUpdate support, XQuery update extensions, and tightintegration with existing XML development tools. The eXistdatabase provides a powerful environment in which XQueryand related standards can be used to develop web applications.Web applications can be written entirely in XQuery, using XSLT,XHTML, CSS, and possibly JavaScript (for AJAX functionality).XQuery server pages can be executed from the file system orstored in the database. The system extends eXist to allow thegeneration and storage of Point type geometry. SOS interfaces(for example, eXistRegisterSensor, eXistInsertObservation, andeXistGetObservation) are implemented for updating and retrievingthe O&M sensor data from a data layer.Users can implement the proposed factory and interface
to support different databases. For example, if the objectiveis to extend a data adapter to register a sensor, to insertobservations and to get observations from the PostGreSQLdatabase. a PostGreSQLFactory and PostGreSQLDB class must bewritten. The concrete PostGreSQLFactory class is used to create aninstance of PostGreSQLDB and the PostGreSQLDB class is used toimplement the proposed eleven common interfaces of the SOSDBabstract class.
4.2. Uniform invocation using WSDL for SOS
The schema of a SOS ‘‘GetCapabilities’’ operation contains aGetCapabilities element used for requests and a Capabilities ele-ment used for responses. A capabilities response consists of fivemain elements: ServiceIdentification, ServiceProvider, OperationsMetadata, Filter_capabilities, and Contents. The Contents elementcontains one or more ObservationOffering elements containingdata and functions that the SOS server provides: intendedApplica-tion, eventTime, procedure, observedProperty, featureOfInterest,resultFormat, resultModel, and responseMode elements. The ob-servedProperty element is the observables/phenomena that can berequested in this offering. The responseMode element allows theclient to request the form of the response.The schema of a SOS ‘‘DescribeSensor’’ operation contains a
DescribeSensor element used for requests and a Sensor elementused for responses. The response of the SOS DescribeSensoroperation contains identification, referenceFrame, inputs, andoutputs elements.
The schema of a SOS ‘‘GetObservation’’ operation contains aGetObservation element used for requests and an Observation ele-ment used for responses. The response of the SOS GetObservationoperation contains service and version attributes and the Observa-tionOffering element, also offering and result elements. In general,the EO dataset is described in the result element.The schema of a SOS ‘‘RegisterSensor’’ operation contains a
RegisterSensor element used for requests and a RegisterSensorRe-sponse element used for responses. This operation is designed toregister new sensors at the SOS. The response of the SOS ‘‘Regis-terSensor’’ operation contains the InsertId element. This ID is usedto link the sensor to an observationType.The schema of a SOS ‘‘InsertObservation’’ operation contains an
InsertObservation element used for requests and an InsertObser-vationResponse element used for responses. This operation isdesigned to insert new observations. The request contains the IDobtained by the ‘‘registerSensor’’ operation and the observationencoded as O&M specification. The response of the SOS ‘‘InsertOb-servation’’ operation is ‘‘successful’’ or ‘‘failed’’.Web Service Description Language (WSDL) provides a model
and an XML format for describing services. WSDL allows separa-tion of the description of the abstract functionality offered by a ser-vice from the concrete details of a service description, for example,‘‘how’’ and ‘‘where’’ that functionality is offered. In general, aWSDLinstance is divided into four parts: Operations, PortTypes, Bindings,and Services. Fig. 6 shows the components of the SOSWSDL: threekinds of portTypes (HTTP Get, Post and SOAP), three mandatoryoperations (GetCapabilities, DescribeSensor, and GetObservation),two optional transaction operations (RegisterSensor and InsertO-bservation), three kinds of bindings (SOS_HTTP_POST_ Binding,SOS_HTTP_GET_Binding and SOS_SOAP_Binding) and EO1_SOS,Weather_SOS and Camera_SOS Service components.Fig. 7 shows how input and output parameters are defined
as messages in WSDL using SOS schema. For example, the inputmessage of the ‘‘GetCapabilities’’ operation is the ‘‘GetCapabili-tiesInput’’ defined as the ‘‘sos:GetCapabilities’’ element and theoutput message is the ‘‘GetcapabilitiesResponse’’ defined as the‘‘sos:Capabilities’’ element.A publisher can use the pre-defined parameters to invoke the
‘‘RegisterSensor’’ and ‘‘InsertObservation’’ operations describedin the WSDL of SOS to register a sensor and update the O&Minformation. A consumer can use the pre-defined parametersto invoke the ‘‘DescribeSensor’’ and ‘‘GetCapabilities’’ operationsdescribed in the SOS WSDL to obtain the sensor and SOS
Author's personal copy
240 N. Chen et al. / ISPRS Journal of Photogrammetry and Remote Sensing 64 (2009) 234–242
Fig. 6. The uniformWSDL of multiple purpose SOS.
Fig. 7. The message of multiple purpose SOS WSDL.
service information, and then use this information to invoke the‘‘GetObservation’’ operation to get O&M sensor data. In short, bothpublisher and consumer can talk directly to the SOS WSDL andtransparently invoke the SOS operations.
5. Case studies
This section illustrates the application of the multiple-purposeSensor Observation Service to retrieval and management of EO-1 Hyperion observation data, IFGI water measurement data,and NSSTC weather station observation data, demonstrating theadvantages of using the Web service technology proposed in thispaper.
5.1. SOS transaction operations for diverse sensor experiments
SOS has two transaction operations: ‘‘RegisterSensor’’ and‘‘InsertObservation’’. The three set of data have been used to testthe feasibility of uniform transaction operations for diverse sensorsin the proposed SOS.The EO-1 spacecraft carries three instruments, of these three,
two are still operating: the Advanced Land Imager (ALI) andHyperion. ALI acquires data in 10 spectral bands that cover awavelength range from the visible to short wave infrared withresolution similar to Landsat 7 satellites. Hyperion acquires datain 220 10-nm-wide bands from 0.4 to 2.6 µm.
Author's personal copy
N. Chen et al. / ISPRS Journal of Photogrammetry and Remote Sensing 64 (2009) 234–242 241
Fig. 8. Sample of EO-1 Hyperion observation data.
Fig. 8 shows Hyperion observation data generated from EO-1 SOS and the content of O&M data records inserted into themulti-purpose SOS through the ‘‘InsertObservation’’ operation.The URL of the detailed EO-1 data product can be given in the‘‘result’’ element, for example ‘‘http://eo1.geobliki.com/hyperion/EO1H0410342004085110PY-2007-01-25T17:02:18Z.tar.gz’’ linkattribute.Fig. 9 shows water observation data generated and inserted
into the multi-purpose SOS using an ‘‘InsertObservation’’ oper-ation. A water observation consists of time of measurement,location of the instrument,water level, accuracy of attribute (quan-tAttributeAccuracy), and completeness of measurement (com-pletenessOmission). The time is between ‘‘2005-10-05T10:15:00-05’’ and ‘‘2005-10-10T10:15:00-05’’. The observation has sixrecords. For the ‘‘2005-10-05T10:15:00-05, id_1001, 50.0, 1, 10’’record, the time of measurement is ‘‘2005-10-05T10:15:00-05’’,the id of a referenced Point object is ‘‘id_1001’’, the water level is50.0 cm, the quantAttributeAccuracy is 1, and completenessOmis-sion is 10.The multi-purpose SOS can be used to register NSSTC weather
sensors, inserting weather observations into SOS using the ‘‘Inser-tObservation’’ operation. Fig. 10 shows how the NSSTC weatherstation observation data can be encoded in an O&M specifica-tion and inserted into SOS through the proposed flexible Sen-sor Observation Service. Consider a weather observation between‘‘20040401T04:00:0001:00’’ and ‘‘20040401T04:00:4001:00’’. Theobservation has five items, separated by commas. For the‘‘20040401T04:00:0001:0, 35.0, 1013.25, 20.4, 165.0’’ record, thetime of measurement is ‘‘20040401T04:00:0001:00’’, the air tem-perature is 35.0 ◦C, the atmospheric pressure is 1013.25 mbar, thewind speed is 20.4 km/h, and the wind direction is 165.0 deg.
5.2. Experiment on Sensor Web data storage in different databases
The Sensor Web data contains information about the sensorencoded in SensorML and observational data encoded usingthe O&M specification. The following illustrations show howPostgreSQLAdapter, MySQLAdapter, and eXistAdapter are used tostore water observation data and demonstrate the feasibility ofheterogeneous database storage and management support in themulti-purpose SOS.Observed data can be stored in a PostgreSQL database through
the PostgreSQLAdapter and queried by SQL Query. A SQL queryfor ‘‘select time_stamp, procedure_id, feature_of_interest_id, of-fering_id, and numeric_value from an observation, where the fea-ture_of_interest_id= ‘id_1001’’’ yields the six records (see Fig. 9) in
Fig. 9. Sample of gauge height observation data.
Fig. 10. Sample of weather observation data.
the result set. The ‘‘id_1001’’ is linked to a Point geometry objectencoded using the PostgreSQL spatial type-Point. The results canbe encoded in an O&M specification and served using a ‘‘GetObser-vation’’ operation implemented in the multi-purpose SOS.The observed data can be stored in a MySQL database through
the MySQLAdapter and served as data encoded in the O&M speci-fication through the proposed MySQL adapter in the flexible Sen-sor Observation Service. The items of the SOSDB table are obser-vation_id, time, offering_id, feature_id, and numeric_value. Execu-tion of a ‘‘select observation_id, time, offering_id, feature_id, offer-ing_id, numeric_value from sosdb’’ SQL query yields the six records(see Fig. 9) in the result set. The ‘‘id_1001’’ is linked to a Point ge-ometry object encoded inMySQL spatial type-Point. The results canbe encoded in the O&M specification and served by a ‘‘GetObserva-tion’’ operation implemented in the multi-purpose SOS.The observed data can be stored in the eXist XML database
through the eXist adapter and queried by XML XPath or XQuery.The XPath expression ‘‘/ObservationCollection/Observation/result/[time>‘‘2005-10-07T10:15 :00 -05’’]’’ can be used to obtain time,feature ID, and gauge height with the results encoded in theO&M specification and served by a ‘‘GetObservation’’ operationimplemented in the multi-purpose SOS.
Author's personal copy
242 N. Chen et al. / ISPRS Journal of Photogrammetry and Remote Sensing 64 (2009) 234–242
5.3. Discussion
Tests of the ‘‘RegisterSensor’’ and ‘‘InsertObservation’’ opera-tions in the multi-purpose SOS using the EO-1 SOS, the IFGI watersensor, and the NSSTC weather sensor show that the SOS transac-tion operations are suitable for diverse sensors. The operations canregister other sensors in SOS and insert other observational data.Use of the PostgreSQL, MySQL and eXist databases to test the fea-sibility of the sensor adapter for heterogeneous databases showsthat the adapter can be extended to retrieve, store, and manageSensor Web data using other databases.
6. Conclusions and outlook
To develop a Geospatial Sensor Observation Service thatcan harmonize diverse sensor networks, support heterogeneoussensor data storage and meet the individual requirements ofdifferent users is a great challenge. This paper proposes aservice-oriented framework to integrate and assimilate sensorobservations and measurements under a multi-purpose SOSin combination with other standard services—CSW, the WFS-Tand the WCS-T. The proposed method was successfully testedusing three typical sensor observation data sets. The approachovercomes many problems, discussed in Section 2, that plagueexisting Sensor Observation Service implementations. The newapproach has the following improvements over the existing SOSimplementation:(1) A flexible architecture. The strategy adopts service-oriented
architecture to package the multi-purpose Sensor ObservationService to discover and retrieve diverse sensor and observationsin business layer. This SOS service can be independently deployedwith service middleware and can communicate with CSW,the consumer, the publisher, and other SOSs through standardinterfaces.(2) Uniform transaction interfaces for diverse sensor data
providers. The strategy adopts the ‘‘RegisterSensor’’ and ‘‘InsertOb-servation’’ standard interfaces to implement the SOS transactionaloperation and exposes the service transactional operations to reg-ister sensor and observations in WSDL. The service can be invokedby different sensor data providers to publish their observation dataflexibly.(3) An extensible access framework for heterogeneous databases.
The extensible sensor data adapter for flattened files, RDBMS andthe XML database is responsible for discovery, storage, and man-agement of the data from live sensors, sensor models, and sim-ulation systems. It is designed and implemented using AbstractFactory design patterns. Users can support different databasesthrough the common interfaces.(4) Uniform access to interfaces for individual observation data
consumers. The strategy adopts the standard ‘‘GetCapabilities’’,‘‘DescribeSensor’’ and ‘‘GetObservation’’ interfaces to implementthe SOS basic operation and exposes the service basic operationto retrieve sensor and observations in WSDL. The service toobtain observation data can be invoked on-demand by differentconsumers of sensor observation data.(5) Sensor Web data can be published, stored, and served on-
demand through themultiple-purpose SensorObservation Service.The next step is to study how to use Geo-Processing Workflow
(GPW) technology to provide self-adaptive geospatial data serviceby harmonizing SOS, SPS, WCS-T, WFS-T and Web ProcessingService (WPS).
Acknowledgements
This work was supported by grants from the U. S. NASAESTO/AIST Sensor Web program: General Framework and Sys-tem Prototype for the Self-Adaptive Earth Predictive Systems(SEPS)–Dynamically Coupling Sensor Web with Earth SystemModels (No. NNX06AG04G, PI: Dr. Liping Di), 863 program (No.2007AA12Z230, PI: Dr. Nengcheng Chen) and NSFC program (No.40501059, PI: Dr. Nengcheng Chen). We also sincerely thank ourcolleague, Dr. Barry Schlesinger, for proofreading the manuscript.The authorswould like to thank the anonymous reviewers for theirvaluable comments and insightful ideas.
Delin, K., Jackson, S., 2001. The SensorWeb: A new instrument concept. In: Proc. theInternational Society for Optical Engineering (SPIE)’s Symposium on IntegratedOptics, San Jose, CA, USA, 24–25 January, 9p.
Evans, J.D., 2003. OGCTM Web coverage service specification (Version 1.0.0). In:Open Geospatial Consortium, OGC, Document Number: 03-065r6, Wayland,MA, USA, 67p.
Gamma, E., Helm, R., Johnson, R., Vlissides, J., 1995. Design Patterns. Addison-Wesley, Reading, MA, 395p.
Ip, F., Dohm, JM., Baker, VR., Doggett, T., Davies, AG., Castano, R., Chien, S., Cichy,B., Greeley, R., Sherwood, R., Tran, D., Rabideau, G., 2006. Flood detectionand monitoring with the Autonomous Sciencecraft Experiment onboard EO-1.Remote Sensing of Environment 101 (4), 463–481.
Lee, E., Kim, M., Kim, M., Joo, I., 2005. A web services framework for inte-grated Geospatial coverage data. Lecture Notes in Computer Science 3481,1136–1145.
Lee, K.B., Reichardt, M.E., 2005. Open standards for homeland security sensornetworks — Sensor interconnection and integration through Web access.Institute of Electrical and Electronics Engineers (IEEE) Instrumentation andMeasurement Magazine 8 (5), 14–21.
Liang, SHL., Croitoru, A., Tao, CV., 2005. A distributed geospatial infrastructure forSensor Web. Computer and Geoscience 31 (2), 221–231.
Meier, W., 2003. eXist: An open source native XML database. Lecture Notes inComputer Science 2593, 169–183.
NASA, 2005. The new age of exploration, NASA’s direction for 2005 andbeyond. http://www.nasa.gov/pdf/107490main_FY06_Direction.pdf (accessed21.07.08).
Nebert D.,Whiteside A. (Eds.) 2005. OGCTM catalogue services specification (Version2.0.0). In: Open Geospatial Consortium, OGC, Document Number: 04-021r3,Wayland, MA, USA, 187p.
Percivall, G., 2006. OpenGIS international standards for GEOSS interoperabilityarrangements. In: Proceedings of Institute of Electrical and ElectronicsEngineers, IEEE, International Geoscience and Remote Sensing Symposium,IGARSS, 2006, Denver, USA, 31 July–04 August. 4p.
Schumacher, R., Lentz, A., Dispelling the Myths., 2008. MySQL AB. http://dev.mysql.com/tech-resources/articles/dispelling-the-myths.html (accessed 21.07.08).
![Summer University WUHAN 2016[2]](https://static.documents.pub/doc/80x56/58f0fe701a28ab87158b4587/summer-university-wuhan-20162.jpg)
