Printer Friendly

An interoperable portal supporting prototyping geospatial applications.


NASA's Earth Observing System (EOS, including satellite sensors and satellite data-receiving systems) is generating more than two terabytes of geoscience data daily, and has archived more than four petabytes of data in its Distributed Active Archive Centers (DAACs). Among these datasets, about 34 million data products and 640 TB data were disseminated to more than 2 million distinct users in 2004 (NASA 2005). To further improve the usage of the data, NASA and its partner agencies identified 12 national applications (Birk et al 2006). These application areas integrate the earth observations, earth system modeling, and decision support tools to support national and societal needs, such as public health and coastal management. Integration of global earth observation data and earth system models in applications from regional to global benefit also helps to build the Global Earth Observation System of Systems (GEOSS, GEO 2005).

The integration processes, for national applications and GEOSS applications, are illustrated in Figure 1:

1) Earth observation systems acquire data through remote sensors and in situ sensors.

2) The earth observation data are fed into earth system models or the decision-support tools.

3) The earth system modeling results are fed into decision-support tools.

4) The decision-support tools outputs are used for policy and management decisions.

5) The feedback from the policy and management decisions are used to improve earth observation systems and earth system models.

Within the last few decades, geospatial information (such as observation data and simulation outputs) has been used widely for decision-supporting applications from a global level, such as the crop yield predictions for diplomatic use (Doraiswamy 2004), to a local level, such as the West Nile Virus surveillance (Gutro 2002). Each of the components involved in the applications is a valuable asset. With the objective to develop national applications and GEOSS applications by integrating these assets, it becomes important to share these assets in an interoperable and fast manner. Services provide an opportunity to achieve this requirement. For example, the geospatial components (see Figure 1) can be extracted and developed as different services:

1) The earth observation systems can be enhanced to provide interoperable data services.

2) The earth system models can provide simulation output as interoperable data or information services.

3) The decision-support tools can provide geospatial decision-support processing services.

4) The decision makers and practitioners can observe the impacts of decisions made and provide the impacts as a quality of service (QoS) feedback to optimize or improve the services involved in the process.


Many data and information services have been developed to share earth observations (such as the EOS Data Gateway where users can search and download or order data, EDG, 2006) and model simulations (such as the Global Modeling and Assimilation Office, which is responsible for global atmospheric phenomena simulations within NASA, GMAO, 2003). Online catalogs, such as the Federal Geographic Data Committee (FGDC) Clearinghouse (FGDC 1996), NASA's Global Climate Master Directory (GCMD,, and NASA's EOS Clearinghouse (ECHO, have been developed to facilitate the discovery of the services. The services and catalogs provide interoperable accessibility to existing earth observations and model simulations, such as the Global Mosaic WMS service based on TM images (http://onearth.jpl. Geospatial interoperability can help to leverage and link these catalogs, and to chain services (Alameh 2003) together within a larger Service-Oriented Architecture (SOA, W3C 2003). Therefore, the services can be built once and used many times to increase the return on investments and reduce time for prototyping through interoperability (Bambacus and Reichardt 2006).

Recent developments in Web portal technology provide a possible interoperable platform to share the services (Goodchild 2006) and to support application prototyping. Observing these developments, the federation of Earth Science Information Partners (ESIP, is identifying different users' information requirements and technology needs (as shown in Table 1) for sharing geospatial resources (http://wiki.esipfed. org/) via the Earth Information Exchange (ESIP 2005).

Observing the requirements, we investigated using the ESG as an interoperable portal to quickly prototype geospatial applications. This paper reports our research and development in utilizing the Web services (Deitel et al 2002) and spatial Web portal (Yang et al 2007) to leverage legacy geospatial components. The following sections introduce the technical requirements of a geospatial interoperable portal, an architecture that supports those requirements, and the design of ESG using such architecture. The last two sections provide an example of how the ESG can be used to prototype applications and include conclusions and discussions.


To support the user requirements, an interoperable portal should be able to provide support to specific geospatial characteristics (see Table 2).

Legacy earth science components are diverse and heterogeneous because various providers have developed these components to satisfy different requirements. Sharing these components across the earth observation community presents many challenges and requires the incorporation of different levels of standards, such as community-based standards (OpeNDAP,, and NetCDF,, or the HDF--EOS,, data format) and broader international standards. A series of standards have been developed within the frameworks of the FGDC, the Open Geospatial Consortium (OGC), and the International Standards Organization/ Technical Committee 211 standards (ISO/TC211).

Among the standards and specifications developed by the FGDC, OGC, and ISO/TC211, significant specifications for interoperable portals include the Catalog Service for the Web (CS-W, Nebert and Whiteside 2004), Web Map Service (WMS, de La Beaujardiere 2004), Web Feature Service (WFS, Vretanos 2002), Web Coverage Service (WCS, Evans 2003), Geography Markup Language (GML, Cox 2004), and Styled Layer Descriptor (SLD, Muller and MacGill 2005). CS-W and Z39.50 (ANSI/ NISO 2003) specifications facilitate communication among catalogs. WMS is for distributed visualization of geospatial information as mapped images. WCS facilitates the sharing of data from earth observations, scientific assimilations, or modeling. WFS helps in sharing discrete data objects, and SLD supports rendering data obtained via WFS or WCS; while such rendering services are often denoted Web Feature (or Coverage) Portrayal Services (WFPS, WCPS--cf. Lansing 2002).

Based on these service specifications and standards, the SOA can provide a publish-find-bind pattern to support sharing components and prototyping applications (as illustrated in Figure 2): (1) service providers publish service descriptions to a catalog; (2) clients find published services through service descriptions; (3) services are bound according to application logic to support specific client applications.


Based on the interoperability and Web portal technology described previously, we developed a conceptual architecture (shown in Figure 3) to share geospatial components and to support application prototyping. The ESG was implemented with a conceptual model in mind, in which future and legacy components (yellow boxes) are shared as services, while the ESG Catalog acts as the registry and index for the services. ESG clients can discover needed components from the catalog and bind them to form applications.



The External Services box provides data or information services via WMS and WCS. For example, NASA's Jet Propulsion Laboratory provides WMS access to its geophysical observation data and simulations, such as ocean color or sea surface temperature (JPL 2006). The Other Catalog box provides catalogs, such as the NSDI Clearinghouse, for searching geospatial data, information, and services.

The ESG Services box provides a set of facilitating services, such as WMSBridge, WMSMerge, and Gazetteer. WMSBridge translates requests and responses between WMS and legacy map services (such as ArcIMS, a proprietary sevice produced by ESRI). The WMSMerge service reprojects the outputs of multiple WMSes onto a common coordinate reference system and overlays them onto one image. The Gazetteer service translates place-names (cities, rivers, mountains, etc.) into precise geospatial coordinates.

Finally, the ESG Catalog box is populated with service metadata of external services and ESG services. The ESG Catalog can also connect to other catalogs through Z39.50 and CS-W to share metadata registered in other catalogs.

The ESG Clients, which is a pure html/Javascript-based Web page that will be loaded to a Web browser when being accessed, provides visualization, searching, publishing, administration, harvesting, and personalization of prototype applications, such as air-quality applications, in a service-chaining manner.


The ESG was implemented as a loosely coupled service architecture, where services can be chained through interoperable interfaces to support different clients (see Figure 4). The essential client-support prototypes include publisher, discovery, and viewer. Besides OGC Web Services, the ESG includes some functional services to facilitate the sharing of existing services, in particular WMSMerge, WMSBridge, and Gazetteer service.


The publisher can be employed to register services and Harvester can help to harvest service by connecting to the catalog (see Figure 4). The publisher supports the geographic content standard ISO 19115 (ISO 2003) and the FGDC (1998) metadata standard. The system can populate its own records from hypertext links to ISO 19115-structured metadata with the capabilities of a service. Users can interactively input metadata for their services when publishing through the publishing wizard (shown in Figure 5).



Discovery and Searching

The search function can locate a place through Gazetteer, or find services or other resources through the user interface (see Figure 6): services found can be bound into the viewer as depicted in Figure 7. ESG's use of the FGDC Metadata standard also allows it to search across the NSDI collection of heterogeneous catalogs.

Viewer (2-D, 3-D, 4-D)

The viewer can help build an application through WMSMerge to issue a GetMap request. The GetMap can get layers by issuing (a) GetMap to WMS, (b) WMS Bridge for ArcIMS, (c) WFPS for WFS, and (d) WCPS for WCS (see Figure 4). The ESG uses WMS to visualize the data within a two-dimensional client. The ESG is currently being extended to support visualization in 3-D (such as height) and 4-D (temporal variation) through other clients such as NASA's WorldWind (, Space Time Toolkit (STT,, and Google Earth (

To facilitate application prototyping and system administration, the ESG also provides several utility functions (Compusult 2005), such as Place Name Searching, Administration, and User personalization (My Portal).

Prototyping Applications through the Earth Science Gateway

Leveraging ESG services and the services published to the ESG catalog, ESG clients can assist in prototyping applications; furthermore, applications can be saved locally or onto the server. To revise or improve the application, another service can always be found and added to the product.

The following example is used for prototyping a wind-power locating application for the GEOSS demo in May, 2006, Beijing (CGC 2006). NASA's GMAO and NOAA's National Centers for Environmental Prediction (NCEP) collaborated on modeling and predicting earth science phenomena, such as global atmosphere circulation and wind speed. Other countries and agencies, such as Environment Canada, also developed similar earth science simulations. After the simulation results are produced, they are put into WCS and WMS and the services are registered into different catalogs, such as the ESG. These global earth observations and simulations have potential to be used for national applications or GEOSS applications of societal benefits, such as energy management. For example, we can use ESG to rapidly prototype an application to identify locations for building wind farms to produce electricity in the Hainan province of China (see Figure 7).


The following workflow illustrates how to discover and integrate current wind-power information to prototype a wind-power application for identifying a wind-farm location.

(1) Search ESG (see Figure 6) using "wind" to find services of interest from tens of wind-related services, such as G5FCST Wind Shear (shown in Figure 8).

(2) Add the G5FCST Wind Shear service that was found to the viewer to get the desired application (see Figure 9).

(3) The application shows some wind situations but no detailed wind-speed information. Other services, such as the Mean Wind Speed service with rough (see Figure 10) and fine (see Figure 11) resolutions are then added.

This application can then be saved, and whenever a user brings up the application, updated observations and simulations will be integrated.

Through this process, an application can be prototyped quickly with the support of the ESG. In the process, users do not have to know who provided the observations or simulations, or who provided the external WMS service. Professional users only focus on the application logic by searching available services and selecting needed services. The public users only need to bring up the application through an Internet hyperlink prepared by a professional. In this example, the legacy system of collected observation data and simulations of wind speed are leveraged in the find-and-bind process.

The ESG is demonstrated in this example for its generic find-and-bind for rapid prototyping applications. However, it has the capability to bring up 3-D and 4-D visualizations and is targeted to serve the communities in sharing global earth observation data and simulations. Therefore, the ESG better serves the purpose of rapidly prototyping national applications and GEOSS applications than do other generic portals. The ESG components, such as the Client, can also be easily reused and integrated within other portals. For example, Figure 12 illustrates that the ESG client is used to support the Earth Information Exchange (http://eie.cos., a portal for exchanging geospatial information.







This paper introduces ESG, a geospatial Web portal designed and developed to leverage the advantages of interoperability, SOA, and OGC Web Services to support prototyping applications and to reuse data by sharing earth observations, earth system modeling, and decision-support tools. In particular, ESG's interoperability provides quick and easy integration of systems and components through open interfaces for rapid prototyping (Birk et al 2006).

As a facilitating portal, the ESG provides a mechanism to prototype applications and reuse geospatial components. However, services found through the ESG discovery functions are limited by the availability and the quality of service (QoS), which depends on several factors, such as (1) the accuracy of observed data; (2) the quality of the simulation models; (3) the quality of postprocessing of information to provide the service; and (4) the reliability of the service. To support national applications prototyping, we are also evaluating, verifying, validating, and benchmarking the prototyping process with NASA partner agencies, such as the U.S. Environmental Protection Agency (EPA), which hosts national applications and GEOSS applications, such as AirNow (Dickerson and White 2006).



This paper is supported through NASA grant # NNX07AD99G.


Alameh N. 2003. Chaining geographic information Web services. IEEE Internet Computing 6(18): 22-29.

ANSI/NISO. 2003. Z39.50-2003 Information retrieval: application service definition & protocol specification. National Information Standards Organization, 2003, http://www.niso. org/standards/resources/Z39-50-2003.pdf.

Bambacus, M., and M. Reichardt. 2006. Invest in interoperability. Geospatial Solutions, February, 2006, 26-30.

Birk, R., M. Frederick, L. C. Dewayne, and M. W. Lapenta. 2006. NASA's applied sciences program: transforming research results into operational success. Earth Imaging Journal 3(3): 18-23.

CGC. 2006. Implementing the GEOSS architecture using open standards: GEOSS demonstrator using OGC specifications. The user and GEOSS architecture workshop, 22-23 May 2006, Beijing, GEOSS_Beijing_Demo-2006(flash)/GEOSS_Beijing_ Demo-2006(flash).html.

Compusult. 2005. Web enterprise suite technical architecture, V.3.0.

Cox, S., Ed. 2004. OGC geography markup language, implementation specification,

de La Beaujardiere, J., Ed. 2004. Web map service ver.1.3, OGC implementation specification, http://portal.opengis. org/files/?artifact_id=5316.

Dietel H., P. Deitel, B. DuWaldt, and L. Trees. 2002. Web services: a technical introduction. NJ: Prentice Hall PTR.

Dickerson, P., and J. White. 2006. Airnow Gateway, http://www. GC_White.pdf.

Doraiswamy, P. C., J. L. Hatfield, et al. 2004. Crop condition and yield simulations using Landsat and MODIS imagery. Remote Sensing of Environment. 92:548-59.

EDG. 2006. Earth observing system data gateway, http://delenn.

Evans, J., Ed. 2003. Web coverage service Ver. 1.0, OGC implementation specification, http://portal.opengeospatial. org/files/?artifact_id=3837&version=2.

ESIP. 2005. Earth Information Exchange, http://www.esipfed. org/business/library/meetings/16th_fed_meeting/index. html.

FGDC. 1998. Content standard for digital geospatial metadata, metadata/base-metadata/v2_0698.pdf.

FGDC. 1996. FGDC Clearinghouse, GEO. 2005. Group on earth observations, http://www.earthobservations. org/index.html.

GMAO. 2003. Global modeling and assimilation office, http://

Goodchild, M. F., D. M. Johnston, et al. 2006. Advances in distributed and mobile computing. In McMaster R., and E. L. Usery, Eds., A research agenda for geographic information science. Philadelphia: Taylor & Francis, CRC Press, 2004, Chapter 9, 2006research/chapter_9_update.pdf.

Gutro R. 2002. Pennsylvania's West Nile Virus surveillance system gets an assist from NASA data, June 16, 2007, http://www. html.

ISO. 2003. International standard: geographic information--metadata,


Lansing, J., Ed. 2002. Web coverage portrayal service Ver.0.0.2,

Muller, M., and J. MacGill. 2005. Styled layer descriptor application profile of the Web Map Service: draft implementation specification, pdf.

NASA. 2005. NASA's earth system science data resources, June, 2005, pp. 1-1, html.

Nebert, D., and A.Whiteside, Eds. 2005. Catalog services Ver.2, OGC implementation specification, http://portal.opengis. org/files/?artifact_id=5929.

Rose, L., Ed. 2004. Geospatial portal reference architecture, a community guide to implementing standards-based geospatial portals Ver.0.2, https://portal.opengeospatial. org/files/?artifact_id=6669.

Vretanos, P. A., Ed. 2002. Web feature service Ver. 1.0, http://

W3C. 2003. Web services and service oriented architecture,

Yang, C., J. Evans, et al. 2007. The emerging concepts and applications of the spacial Web portal. PE&RS 73(6): 691-98.

Myra Bambacus is the Program Manager of NASA's Geoscience Interoperability Office (GIO).

Phil Yang received his Ph.D. in Geographic Information Science from Peking University, China, in 2000. He is an assistant professor at George Mason University, and his research is focused on geospatial information modeling, computing, and visualization.

Corresponding Address: College of Science

George Mason University

4400 University Drive

Fairfax, VA 22030

John Evans received his Ph.D. in Computing Science from M.I.T. in 1997. He is a senior computer scientist at NASA's Geoscience Interoperability Office, and his research is focused on geospatial interoperability.

Marge Cole is a project manager at NASA's Geoscience Interoperability Office and is focused on geospatial interoperability.

Nadine Alameh received her Ph.D. in Computer Information Systems from M.I.T in 2001. She is a senior interoperability architect at NASA's Geoscience Interoperability Office, and her research is focused on geospatial Web services and interoperable architectures.

Stephen Marley received his Ph.D. from the University of College--London. His research is focused on geospatial interoperability and enterprise architecture.
Table 1. Information Sharing Requirement (Courtesy of ESIP

Users Information Technology

Data Users Ready access to all Catalog and
 existing metadata, interoperable data
 which describe the viewing portal access
 geospatial datasets

Researchers Data in scientific Sophisticated portal
 data formats access
 compatible with
 common scientific
 data models (e.g.,

Policy makers Advanced data Portal access to
and general products (analysis specific decision
public tools, models, support applications
 simulations, decision
 support products)

Educators Educational products Portal access
 (collections, to populated
 simulations, educational
 informational videos, communities
 lesson plans)

Table 2. Characteristics of a Geospatial Portal
(Adopted from Rose 2004)

Characteristics Explanation Relevant
 SOA and
 com orients

Interoperable A portal should be able to Service
 access other portals and legacy chaining
 systems through interoperable (Alameh
 interfaces, such as Web services, 2003
 at different levels, such as
 metadata, data, and services.

Compliant A geoscience portal OGC Web
with geospatial should support geospatial Services and
standards and specifications, such as OGC FGDC/ISO
specifications Web Services, and standards, standards
 such as ISO/TC211 standards,
 so that relevant geospatial
 applications can be accessed
 in consistent, predictable, and
 interchangeable manners.

Vendor neutral Legacy systems were developed Service
 based on different vendors' discovery
 solutions. An interoperable and service
 portal should comply with chaining
 open community standards
 and be independent of vendor-specific

Scalable and A portal should comply Publish-
expandable with the general software find-bind,
 engineering requirements JSR 168
 on component reuse and
 expansion. For example, JSR
 168 portlets' architecture and
 specifications can be adopted to
 facilitate the portal scalability
 and expandability.

Web services Portal should comply OGC Web
 with Web-interfacing Services
 standards, such as HTTP
 for communication, XML
 for encoding requests and

End-user A portal for geoscience should Clients/
applications support end-user applications. applications
COPYRIGHT 2007 Urban and Regional Information Systems Association (URISA)
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2007 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Bambacus, Myra; Yang, Phil; Evans, John; Cole, Marge; Alameh, Nadine; Marley, Stephen
Publication:URISA Journal
Date:Jul 1, 2007
Previous Article:Coupling multiagent geosimulation and spatial OLAP for better geosimulation data analysis.
Next Article:A comprehensive process for linear referencing.

Related Articles
Geospatial One-Stop portal increases data access for government and the public.
Geospatial Web services and geoarchiving: new opportunities and challenges in geographic information services.
Geospatial Engineering: combat development update.

Terms of use | Privacy policy | Copyright © 2021 Farlex, Inc. | Feedback | For webmasters |