Chapter 7

From The SDI Cookbook

Contents 1 Chapter Seven: Other Services 1.1 Context and Rationale 1.2 Organisational Approach 1.3 Geospatial Application Services 1.3.1 Catalogue Services 1.3.2 Geospatial Data Services 1.3.3 Portrayal Services 1.3.4 Processing Services 1.3.5 Service Chaining 1.4 Implementation Approach 1.5 Recommendations 1.6 References and Linkages

Chapter Seven: Other Services

Editor: Doug Nebert, FGDC ddnebert {[at]} usgs.gov

Context and Rationale

Over the past decade, GIS technologies have evolved from the traditional model of stand-alone systems, in which spatial data is tightly coupled with the systems used to create them, to an increasingly distributed model based on independently-provided, specialized, interoperable GIS services. This evolution was fueled by various factors including the growing role of GIS in today’s organizations, the increasing availability of spatial data and its inherent conduciveness to reuse, the maturity of Web and distributed computing technologies, and the key role GIS is expected to play in a promising location-based services market. Furthermore, most users of traditional GIS systems only use a small percentage of their systems’ functionalities; Services can provide users with just the functionality and data they need at any time, bypassing the need to install, learn, or pay for any unused functionalities.

Services can be defined as self-contained, self-describing, modular applications consisting of collections of operations, accessible through interfaces, which allow clients to evoke behaviors of value to the user. Clients can invoke services from across a network using standardized protocols independently of platform, language, or object model on which the services or the client were deployed.

By building applications to common service interfaces, applications can be built without a-priori or run-time dependencies on other applications or services. Applications and services can be added, modified, or replaced without impacting other applications. In addition, operational workflows can be changed on-the-fly, allowing rapid response to time-critical situations. This loosely coupled, standards-based approach to system development can produce very agile systems- systems that can be flexibly adapted to changing requirements and technologies

Organisational Approach

The preceding chapters of this cookbook have discussed three types of services that are fundamental to any Spatial Data Infrastructure: data catalogues, online mapping, and access. As described in the OGC Service Framework, a broad range of other geospatial services may exist in SDIs. The OGC Service Framework (shown in Figure 7.1) identifies services, interfaces and exchange protocols that can be utilized by any application. The framework, which can be implemented in different ways, primarily provides a basis for coordinated development of new and extended geospatial services.

Figure 7.1 - The OGC Service Framework

The OGC Service Framework groups geospatial services into five categories (shown below) corresponding to the OGC services taxonomy top-level domains described in OGC’s Service Architecture Abstract Specification (also ISO 19119). By providing a summary of these categories, this section is intended to help you decide on the right mix of services that you need in your applications. When available, applicable implementation specifications for these services will be highlighted.

Geospatial Application Services

Application services operate on user terminals (e.g. desktop, notebook, handset, etc) or servers to provide access to the various services described here. They are used by users to access Catalog, Portrayal, Processing and Data services depending on the requirements and the designed implementation of the application. They often provide user-oriented displays of geospatial content and support user interaction at the user terminal.

Catalogue Services

Catalogue Services are described in detail in Chapter Four.

Geospatial Data Services

Geospatial Data services provide access to a wide range of collections of geospatial data stored in distributed repositories and databases. Examples of data services include

• Feature Access Services: provide access and management of feature stores. Applicable implementation specification: OGC Web Feature Service (WFS; http://www.opengis.org/docs/02-058.pdf)
• Coverage Access Services: provide access and management of coverage stores. Applicable implementation specification: OGC Web Coverage Service (WCS; http://www.opengis.org/docs/03-065r6.pdf)
• Sensor Collection Services: provide access, manipulation and collection of sensor observations. Applicable implementation specification: OGC Sensor Collection Service (SCS; http://www.opengis.org/docs/02-028.pdf)
• Image Archive Services: provide access and management of large sets of digital images and related metadata

Data services also provide access to location-based data in the form of the following services (Applicable implementation specification: OGC Location Services OLS; http://portal.opengis.org/files/?artifact_id=3418):

• Directory Services: provide access to online directories to find the locations of specific or nearest places, products or services
• Geocoding Services: transform a description of a location (placename or street address) into a normalized description of the location
• Navigation Services: determine travel routes and navigation between two points
• Gateway Services: fetch the position of a known mobile terminal from the network

Portrayal Services

Portrayal services provide visualization of geospatial information. Given one or more inputs, portrayal services produce rendered outputs (maps, perspective views of terrain, annotated images, etc). They can be tightly or loosely coupled with other services such as the Data and Processing services, and can transform, combine, or create portrayed outputs. Examples of such services include:

• Map Portrayal Services: described in detail in Chapter Five.
• Coverage Portrayal Services: Applicable implementation specification: OGC Coverage Portrayal Service (CPS; http://www.opengis.org/docs/02-019r1.pdf)
• Mobile Presentation Services

Processing Services

Unlike data services, processing services are not associated with specific datasets. Instead, they provide operations for processing or transforming data in a manner determined by userspecified parameters. Processing services can be tightly or loosely coupled with other services such as the Data and Processing Services. The most common examples of processing services are:

• Coordinate Transformation Services: convert geospatial coordinates from one reference system to another. Applicable implementation specification: Coordinate Transformation Services (CTS; http://www.opengis.org/docs/01-009.pdf)
• Image Processing Services, detailed in OGC’s Abstract Specification Topic 15, include:
  • Image Manipulation Services: manipulate images (resizing, changing color and contrast values, applying various filters, manipulating image resolution, etc.) and are used for conducting mathematical analyses of image characteristics (computing image histograms, convolutions, etc.).
  • Image Exploitation Services: support the photogrammetric analysis of remotely sensed and scanned imagery and the generation of reports and other products based on the results of the analysis.
  • Image Synthesis Services: create or transform images using computer-based spatial models, perspective transformations, and manipulations of image characteristics to improve visibility, sharpen resolution, and/or reduce the effects of cloud cover or haze.
• Geospatial Analysis Services: exploit information available in a Feature or Feature Collection to derive application-oriented quantitative results that are not available from the raw data itself.
• Gazetteers: provide access to geospatial data indexed by placename rather than by coordinate locations. Applicable implementation specification: Gazetteer service profile of a WFS (http://www.opengis.org/docs/02-076r3.pdf)

Service Chaining

Chaining services can be considered as a special case of processing services, enabling the combination or pipelining of results from different services in response to clients’ requests.

Efficient service chaining is critical to your ability to leverage and combine multiple information sources hosted by various service providers. The key to achieving such efficiency relies on the use of standard interfaces and encodings in the design of the underlying services. Service chaining is required when a task needed by a client cannot be provided by a single service, but rather by combining or pipelining results from several complementary services.

Indeed, most GIS applications will require the chaining of multiple geospatial and non-geospatial services. Figure 7.2 shows a typical service chaining scenario where a Coverage Portrayal Service (CPS) fetches several GIS coverages from different WCS services, then mosaics them to portray the resulting composite image of Cambridge, Massachusetts. A processing service reprojects the resultant coverage to another spatial reference system. An overlay service then supplements the coverage with features extracted from a WFS, and sends the result to the client as a rendered map.

Figure 7.2 – A typical service chaining example

Approaches and technologies to efficiently and scalably construct and express service chains are still areas of active research. In addition, several issues surround the execution and tracking of a typical service chain such as the one shown above, including:

• Transparency: How much should the client be exposed to the service chaining complexities? How much should the client be involved in constructing, validating, executing and managing service chains?
• Tracking: How should the service chain track and relay to the client the sources of geographic data used along the chain, and the various transformations applied to it? Keeping track of metadata is important because users cannot often trust the data unless they have some information about its resolution, orthorectification parameters, remote sensing origin, etc. Such information is also critical in evaluating the fitness of use of returned data in various applications.
• Error reporting: How should services handle errors and report them along a chain to the client? Precise error reporting is particularly critical in the case of synchronous chains (such as the one depicted in Error! Reference source not found..

To date, three general service chaining methods have been identified according to ISO 19119:

• User-defined transparent chaining, where the user defines and controls the order and execution of the individual services. This service chaining method requires deep involvement of the client, which may hinder a wide-base adoption of geospatial web services.
• Opaque chaining, where the chaining of service is performed by a new aggregate service. The services appear as a single service which handles all coordination of the individual services behind the aggregate service. Aggregate services bundle static (predefined) chains of services and present them to the client as one. The client, however, loses all control over the service chaining process.
• Workflow-managed translucent chaining where the execution of the chain is managed by a mediating service. Mediating services can act as gateways to other services by coordinating between multiple services without necessarily storing any data of their own (Alameh, 2003). Mediating services combine the simplicity of aggregate services with the flexibility and control inherent in client-coordinated service chaining. Mediating services can use pre-specified client preferences to search for appropriate data and processing services. With the wide range of possible GIS applications and the different semantics needed in different fields, it is likely that the internal mediating services rules will be tuned to specific application domains. The need for such specialization will likely enable the emergence of a variety of mediating value-adding service providers in the GIS market.

Chaining of geospatial (possibly in conjunction with other non-geospatial services) is still considered an area of active research both from the conceptual and implementation perspectives.

Implementation Approach

While specific GIS software packages may offer one or more of the services discussed so far in a proprietary fashion, there are few existing standards and protocols for providing geospatial domain services in an interoperable manner. Consequently, if you need to implement any of these services in your production environment, it is advisable that you first try to reuse existing interfaces to the extent possible. You should also work with others in your field and with applicable standards bodies to design standard interfaces that can meet your needs. By ensuring that new services fit within the described OGC Service Framework and are consistent with existing standards and abstract specifications, you contribute to the sustainability and extensibility of architectures based on that framework. Furthermore, this enables you to more easily respond to new requirements and quickly deploy new applications while providing a wide range of clients with the flexibility of mixing and matching services when building their own customized applications.

In terms of supporting technologies, work is underway within OGC to define a suite of web service interfaces that have explicit bindings for both HTTP GET and POST (e.g. the WMS, WFS and WCS specifications). In this case, XML is very fundamental as it provides the extensibility and vendor, platform and language independence that are key to the loosely coupled standards-based interoperability. XML is also being used for defining several methods of encodings (e.g. the SLD, GML specifications).

As for service chaining, work is still under way to enable it using existing and emerging XML technologies, such as

• The Web Services Description Language (WSDL; http://www.w3.org/TR/wsdl), which provides a way to describe the messages and operations of a service in an abstract way and bind them to a concrete protocol and message format. A Web service described with WSDL enables programs, also known as proxy generators, to automatically construct a request to that service. By not requiring the calling party (client or another service) to know a priori the interface to any WSDL-described service, WSDL makes both transparent and workflow-managed chaining easier to implement.However, it should be noted that in the case of GIS services, describing the service interfaces is often not enough. In a data-centric field such as GIS, a mechanism is needed to describe the data characteristics that various GIS services can serve or process. Within the OGC, this is currently achieved by requiring each GIS Web service to support a getCapabilities operation which returns, among other information, details about the data supported by that service.

• The Universal Description, Discovery and Integration (UDDI; http://www.uddi.org) which enables businesses to quickly and dynamically find and transact with each other. The major obstacle slowing down the adoption of UDDI within the geospatial community is attributed to the fact that UDDI registries do not currently support any type of spatial queries. With spatial queries being at the heart of any GIS application, the ability of not being able to search for services or data by bounding box constitutes a real limitation for users. It remains to be seen whether future versions of UDDI will support such functionality.

• The Simple Object Access Protocol (SOAP; http://www.w3.org/TR/SOAP/) which provides a simple and light-weight mechanism of exchanging structured and typed information between peers in a decentralized distributed environment.

• DAML-based Web Service Ontology (DAML-S; http://www.daml.org/services) which supplies Web service providers with a core set of markup language constructs for describing the properties and capabilities of their Web services in unambiguous, computer-interpretable form. DAML-S’ support for automatic selection, composition and interoperation of Web services is of particular relevance to service chaining. Such support is possible because DAML-S provides declarative specifications of the prerequisites and consequences of individual service use that are necessary for automatic service composition and interoperation. These specifications have the potential of being used to dynamically identify which services can be chained to each other, and which ones can be substituted for one another for the purpose of answering a specific request.

• The Business Process Execution Language for Web Services (BPEL4WS; http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/) which defines a notation for specifying business process behavior based on Web Services. It is a standard promotedby Microsoft, IBM, Siebel, SAP and BEA for orchestrating discrete services into end-toendbusiness processes. Processes defined in BPEL can export and import functionalityby using Web Service interfaces exclusively. BPEL provides a language for the formalspecification of business processes and business interaction protocols. By doing so, itextends the Web services interaction model and enables it to support businesstransactions. BPEL defines an interoperable integration model that should facilitate theexpansion of automated process integration in both the intra-corporate and thebusiness-to-business spaces.

It remains to be seen how the listed technologies (and others) can be leveraged for service description, discovery and chaining within the geospatial domain. The sooner a tested and reliable approach is crafted, the faster the benefits of geospatial services can be reaped. Interoperable geospatial services will be especially beneficial for scientific research and engineering modeling as well as state and federal government settings where tightly coupled hierarchical systems are unlikely to provide the desired breadth and flexibility. Services allow users to freely combine services to create customized solutions with minimal programming, integration and maintenance efforts.

Figure 7.3 – Potential value chain for a service-based GIS marketplace

In such a service environment, having expertise in certain fields or industries can provide you with the advantage of uniquely supplying customized solutions to your partners and clients. As shown in Figure 7.3, in this environment, it will not be necessary for players to build comprehensive systems in order to gain a share of the market. The new environment can open the door to small niche players to enter this market with application specific offerings that leverage their understanding of particular industries or processes.

Recommendations

In light of the described organization and implementation approaches and the importance of interoperability in sustaining a scalable SDI, the Cookbook authors recommend the following:

• Comply with existing standard interfaces and encodings when implementing your geospatial services (to maximize other people’s access to your data holdings and service offerings);
• Require that your COTS providers support existing standard interfaces and encodings (to enable you to maximize your access to outside data sources and geospatial services);
• Refer to the OGC Service Framework and ISO 19119 Service Architecture when designing new services, in order to make sure that your services fit well within the existing reference architecture;
• When designing new services, try to reuse existing interfaces to the extent possible; You should also work with others in your field as well as with applicable standard bodies (such as ISO, OGC, W3C) to design standard interfaces that can meet your needs;
• Leverage and build on general IT and Web services technologies in order to ensure wider acceptance and use of your geospatial services. In most cases, the more general technologies will need to be extended to address requirements that are unique to the geospatial community. Communication with the general IT and Web services standards bodies is needed when working on these geospatial-specific extensions.

References and Linkages

[1] Alameh, Nadine. Chaining Geographic Information Web Services, IEEE Internet Computing (2003), Volume 7, Number 5

[2] Percivall, George (ed.), OpenGIS Abstract Spec Topic 12: OpenGIS Service Architecture, version 4.3 (2001): http://www.opengis.org/docs/02-112.pdf

[3] Kottman, Cliff (ed.), OpenGIS Abstract Spec Topic 15: Image Exploitation Services, version 5 (2000): http://www.opengis.org/docs/00-115.pdf

[4] Kottman, Cliff (ed.), OpenGIS Abstract Spec Topic 16: Image Coordinate Transformation Services, version 4 (2000): http://www.opengis.org/docs/00-116.pdf

[5] Daly, Martin (ed.), Coordinate Transformation Services, version 1 (2001): http://www.opengis.org/docs/01-009.pdf

[6] Mabrouk, Marwa (ed.), OpenGIS Location Services (OpenLS): Core Services, version 1 (2003): http://portal.opengis.org/files/?artifact_id=3418

[7] Buehler, Kurt (ed.), OpenGIS Reference Model (ORM), version 0.1.2 (2003): http://www.opengis.org/docs/03-040.pdf