, University of New Orleans
, University of New Orleans
Pages: pp. 13-15
Enterprises in the public and private sectors have recently produced a surge in Web services and Web applications for geographic information systems (GISs), making large spatial-data archives available over the Internet. Google Maps, Google Earth, and Microsoft Virtual Earth, for example, introduce GIS services to ordinary Internet users with astonishing aerial imagery and responsive performance.
Logically, maps are a natural platform on which information from different perspectives can converge through geographic locations. Technically, Web services technologies have provided the necessary standards for applications in different domains to integrate with GIS data and services. 1 Significant accomplishments in GIS Web services have led to several exemplifying map and image services that adhere to Web services standards and bring terabytes of geospatial data and digital maps to enterprise developers who house no GIS data. Meanwhile, Yahoo Maps and the Google and Microsoft services we mentioned earlier are providing numerous APIs, enabling light-weight integration of digital maps and business location information into any Web pages and applications. This is a clear indication that a broader wave of GIS Web services applications is on its way. However, this growing field is not without problems. This special issue serves as a forum for crosstalk about the models and technologies related to GIS Web services.
Although the growth of geospatial data and digital maps has given Internet application developers a great opportunity to integrate location information into their services, achieving harmonious integration is challenging. GIS services often transmit very large volumes of data; geospatial query processing involves extensive GIS domain knowledge and requires intensive computation; and GIS Web services clients are traditionally heavy-duty, stand-alone software tools. 2 These factors have made GIS Web services more difficult to build than the ordinary business transactions for which general-purpose Web services were originally intended.
Web services are Web sites intended for use by computer programs rather than human users. The W3C has defined a general-purpose Web service architecture based on a trio of standards — SOAP, the Web Services Description Language (WSDL), and Universal Description, Discovery, and Integration (UDDI) — as well as others for business processes, security, coordination, transaction, inspection, and so on. 3 In parallel with the development of these general-purpose Web services, the Open Geospatial Consortium (OGC) has successfully executed efforts for GIS interoperability. For example, the OGC Web Services (OWS) initiative has undergone multiple phases — including the Web Map Server (WMS), Web Feature Server (WFS), Web Coverage Server (WCS), and OGC Web Service Architecture, 1 which support application developers in integrating a variety of online geoprocessing and location services. Conceptually, the OWS technology stack is a service-oriented architecture (SOA) that includes service discovery, description, and binding layers corresponding to UDDI, WSDL, and SOAP in the W3C architecture. Rather than general issues, however, the OGC intended to specify only those issues that are specific to geographic information. Currently, OGC Web services aren't equivalent to the W3C SOAP-based Web services, although the OGC is attempting to integrate the Web services standards into the OWS framework, including specifying changes to the common OWS architecture and providing WSDL descriptions in WMS, WFS, and WCS.
The articles in this issue's theme section aim to reflect the state-of-the-art development in GIS Web services from different angles.
In "Designing and Building TerraService," Tom Barclay and his coauthors give technical insight into TerraService technologies through a bottom-up tour of the GIS Web service site's design and construction, as well as end-to-end descriptions of two large-scale GIS projects that use TerraService. As a pioneering GIS Web services provider, TerraService provided W3C Web services interfaces for one of the world's largest geospatial databases. Every developer looking to build GIS Web services based on W3C standards can learn from this set of proven technologies.
"A Distributed Geotechnical Information Management and Exchange Architecture," by Roger Zimmermann and his coauthors, presents another case study on applying W3C Web services technologies, but to a GIS Web service site with additional complexity. The services aim to facilitate the exchange and utilization of geotechnical information stored in distributed heterogeneous databases. To reduce query-forwarding traffic, the authors also apply a sophisticated query-routing algorithm supported by tree-based spatial indexing. This article complements literature in the GIS field, which often focuses on the OGC Web service approach. The authors report that adopting the W3C Web service approach makes it possible for developers to use many high-quality (sometimes free) development tools as well as access to large libraries of various, preexisting Web services.
In "Evaluating Performance in Spatial Data Infrastructures for Geoprocessing," Marius Scholten, Ralf Klamma, and Christian Kiehle discuss model-based analysis for a specific spatial data infrastructure, a groundwater vulnerability assessment service. This site is implemented with multiple OGC WCSs, all of which accept SOAP requests through a WCS-SOAP proxy. The authors base their performance analysis on the stochastic Petri net model and supplement it with empirical measurements. They consider influential performance parameters in their evaluation, including caching, network speed, data granularity, and communication mode.
Rob Lemmens and his coauthors present a prototype framework for a semiautomatic Web service chaining tool in "Integrating Semantic and Syntactic Descriptions Chain Geographic Services." The tool consists of two components: a service discovery component that finds semantically and syntactically matching services for a given requirement description, and a service composer that realizes the desired service composition into a workflow implementation. This framework makes the basic assumption that all participants share a collection of common geo-ontology sets, which means that every service provider must annotate every working service using these shared ontology sets. The authors use a high-quality academic ontology editor and a Web Ontology Language (OWL) reasoner in service discovery, which helps the prototype handle complex knowledge representation.
Finally, John Sample and his coauthors' "Enhancing the US Navy's GIDB Portal with Web Services" describes what one organization can do when confronted with implementing a large geospatial portal. The authors discuss two interesting efforts that support Web services for GIS: increasing WMS resources' availability and mediating clients' requests and available services based on domain-specific semantics.
Taken as a whole, these articles cover a wide spectrum of issues that arise during Web services development for GIS.
Given the rapidly increasing availability of geospatial data and maps as well as GIS Web APIs, most users of GIS on the Web will differ dramatically from traditional GIS users — rather than domain experts, they'll be ordinary people. We believe that this will increase the demand for new GIS Web services significantly, simultaneously changing GIS requirements. People will no longer limit their needs to data distribution, but will demand direct location-aware services. GIS developers will face not only traditional concerns such as scalability, reliability, security, and performance, but also how to turn the traditional data-distribution model into a service-delivery model that covers the entire GIS space.