Web Services for Imaging Workflow: Chaining
By Sam Bacharach, OGC
Geoprocessing technology stakeholders are working together inthe OGC and other standards development organizations to create an open Web standards framework for discovering, evaluating, accessing, processing and displaying imagery and other kinds of geodata. Despite the complexity of Earth imaging, "service chaining" that involves Earth imaging is moving forward rapidly and is being exercised and demonstrated in multiple projects.
What is "Image Service Chaining"?
Web services are the latest, most complete realization of the idea that "the network is the computer." Actions that previously took place only inside a computer across the computer's motherboard or backplane can now be programmed to take place across the Internet. Almost all designers and developers of major enterprise information systems are implementing or planning "service oriented architectures" (SOA) that use the public Web and/or enterprise intranets for communicating between distributed clients and servers.
Think of the old paradigm as file-based computing and the new paradigm as Web service-based computing. In the old paradigm, we pass large data files and load them in their entirety into standalone software systems. In the new paradigm, we pass queries that return the results of services that execute on remote Web servers.
In the old paradigm, we use the Internet (or LAN or physically transported storage media) to obtain a large data file from which we then painstakingly extract information. In the new paradigm, we reach across the Web to get just the information we request. For example, Earth browsers enable anyone with a Web browser to access huge spatial databases to get a particular result—typically a map view—without downloading the whole database. The user gets an answer, not a file.
"Service chaining," one of the key benefits of the new paradigm, involves Web services that invoke other Web services. In the old paradigm, software programs invoke subroutines to provide particular kinds of processing on the local host. Interfaces are important: The subroutines must be called in a specific way, provide certain kinds of data in a list of parameters, and return certain kinds of data in a list of parameters. Subroutines can invoke other subroutines.
In the new paradigm, a software program that is a Web client calls a Web service that's available at a particular URL. Interfaces are important here, too: The Web-based query must be done in a specific way, and the Web service must be provided with certain data in a list of parameters. The invoked Web service might call another Web service, just as one subroutine can call another, except that, if the interfaces are open, the Web services do not all have to be provided by the same software vendor, as they do in the old paradigm.
Web services, like stand-alone software packages and their libraries of subroutines, can be completely proprietary, with unpublished interfaces that let the software provider control who can "play" in the bounded environment of that software product or Web service "walled garden." But proprietary interfaces are part of the old paradigm. Open interfaces make full use of the potentials of the new paradigm. Each Web service can be a "black box" running proprietary algorithms, and yet, through open interfaces, that service can be accessed by anyone or any remote client with permission to use it.
Geoprocessing service chaining involves Web services that perform processes that include any algorithm, calculation or model that operates on spatially referenced data. These are tasks that we normally associate with GIS, remote sensing, location services, navigation, etc. These Web services usually depend on OGC Web Services (OWS) standards and Sensor Web Enablement (SWE) standards developed in the OGC's consensus process in collaboration with other standards organizations such as ISO (International Organization for Standardization), W3C (World Wide Web Consortium) and OASIS (Organization for the Advancement of Structured Information Standards). OWS and SWE standards specify interfaces, encodings and best practices for open geoprocessing Web services. Image service chaining is usually service chaining that involves image-related OWS and SWE standards.
Many of the vector and raster geoprocessing service chaining activities to date involve the OpenGIS Web Processing Service (WPS) Interface Standard. WPS defines a standardized interface that facilitates the publishing of geospatial processes and the discovery of and binding to those processes by clients. Publishing means making available machine-readable binding information, as well as human-readable metadata that allows service discovery and use. WPS provides mechanisms to identify the spatially referenced data required by the calculation, initiate the calculation, and manage the output from the calculation so that the client can access it. The WPS specification is designed to allow a service provider to expose a web-accessible process in a way that allows clients to input data and execute the process with no specialized knowledge of the underlying process. The WPS interface standardizes the way processes and their inputs/outputs are described, how a client can request the execution of a process, and how the output from a process is handled.
A user or a user's application finds appropriate Web services via a catalog and then chains the Web services to perform a repeatable multi-step operation. See Figure 1.
Figure 1 In this example of geoprocessing Web servers with OWS interfaces, five chained services reside on five different servers.
An ORCHESTRA Geoprocessing Service Chaining Example
ORCHESTRA, a major European "integrated project" under IST-FP6, was undertaken to improve technical interoperability for risk management. The project developed a service-oriented architecture for risk management based on open standards, together with a software infrastructure for enabling risk management services. The ORCHESTRA architecture is a platform-neutral (abstract) specification based on Web service specifications of the ISO, OGC, W3C and OASIS. Three Orchestra pilots were organized to provide practical tests and demonstrations of what could be accomplished using this architecture. One goal was to define workflows that combine several services into one value-added service chain that achieves a certain goal, as shown in Figure 2.
Figure 2 In one ORCHESTRA scenario, a user first finds data and services by means of a Catalog Service containing metadata about available data and services, then creates a service chain and deploys it to a Service Chain Access Service (SCAS), which deploys the service chain as multi-component Risk Assessment Service.
OWS-6 Testbed Activity
Some OWS standards, such as the OpenGIS® Web Map Service (WMS) and Web Feature Service (WFS) interface standards, are implemented in hundreds of products. Others, including those focused on service chaining, are currently implemented mainly in experimental settings, such as the OGC Web Services - 6 (OWS-6) testbed activity. OWS-6 includes a Geoprocessing Workflow thread that involves service chaining with particular emphasis on ensuring authenticity, integrity, quality and confidentiality of services and information in OWS service chains. Conflation and Grid processing use cases are being explored.
EC08 OGC Pilot
The recent Empire Challenge 08 (EC08) OGC Pilot was a multivendor demonstration of workflow that demonstrated the "chaining" of Web services in an Intelligence, Surveillance and Reconnaissance (ISR) scenario. The demonstration involved off-the-shelf software that implemented standard interfaces and encodings to task and control an airborne or spaceborne imaging device, collect the data, orthorectify it, and display it in a single frame, all in near-real time.
Ocean Observation Community
In January 2007, members of the OGC launched the Ocean Science OGC Interoperability Experiment (Oceans IE) to study implementations of OWS standards and SWE standards (and complementary standards from organizations including the ISO, IEEE, and OASIS) being used by the international ocean-observing community. More than a dozen ocean observation initiatives are using these standards, including regional application-oriented organizations such as the Gulf of Maine Ocean Observing System (GoMOOS), the open-source, community-oriented OOSTethys initiative, and others such as:
- In the US, the NOAA IOOS program made a recent decision to leverage the OGC's Sensor Web Enablement (SWE) standards as the basis for interoperability of sensors (ioos.noaa.gov).
- SURA Coastal Ocean Observing and Prediction (SCOOP) and the related community initiative: www.openioos.org.
- Interoperable GMES Services for Environmental Risk Management in Marine and Coastal Areas of Europe (InterRisk).
The Global Earth Observing System of Systems (GEOSS) is being developed by the Group on Earth Observations (GEO) (www.earthobservations.org), a partnership of 126 governments and international organizations. Through agreements on technical standards and through institutional coordination on policies, the governments are making available on Web servers a very large collection of geospatial data, including live sensor data and stored geodata of many kinds. The goal is to improve understanding and capacity in dealing with challenges involving disasters, health, energy, climate, water, weather, ecosystems, agriculture and biodiversity. OGC is leading the GEOSS Architecture Implementation Pilot.
GEOSS and the service chaining it will support are attractive to scientists because the Earth itself is a system of systems, and modelers increasingly seek to "couple" systems to see how Earth systems interact with one another. Governments look forward to decision support systems that will be able to draw on a rich collection of data and processing resources.
Image Georeferencing: AKey but Complicated Link in Imaging Service Chains
In many cases, it is important to compare extracted ground positions to positions that were previously or subsequently measured in other images or that were obtained by cadastral surveys or GPS. Georeferencing is the process of assigning, or reassigning, geographic coordinates to an image. Georeferencing simplifies both the comparison of overlapping and adjacent images and the measurement and comparison of ground positions. Initial georeferencing coordinate transformations often need improvement to increase ground position accuracy and to reduce position differences between overlapping and adjacent images.
Remote sensing practitioners also perform image georectification (or orthorectification) using georeferencing coordinate transformation. This involves shifting pixel locations to remove distortion. Often the process of georectification includes georeferencing, because one can both shift the pixels to remove distortion and assign coordinates to those pixels at the same time.
OGC Web Service standards and Sensor Web Enablement standards offer several ways to accomplish these tasks, although not all of the relevant standards have been adopted yet by the OGC members, and there are competing ideas among Technical Committee participants regarding best approaches.
Georectification can be performed by the relatively new OpenGIS Web Coverage Service (WCS) Interface Standard 1.1. New extensions of WCS 1.1 include:
- the transaction extension (WCTS), which allows input of new images, and;
- a new processing extension for subsequent retrieval, georectification, and processing of image parts that allows modification of retrieved pixel values, such as for image enhancement or classification of ground cover.
Georeferencing coordinate transformations can be defined by the OpenGIS Geography Markup Language (GML) Encoding Standard (in accordance with ISO 19111) or by the OpenGIS Sensor Model Language (SensorML) Encoding Standard. SensorML specifies an XML encoding framework within which the geometric, dynamic, and observational characteristics of all types of sensors and sensor systems can be defined, from simple visual thermometers to complex earth-observing satellites. Most of the experiments on image service chaining have utilized SensorML and other approaches such as Business Process Execution Language (BPEL).
A proposed Image Georeferencing Service (IGS) standard in the OGC improves georeferencing coordinate transformations by triangulation and uses georeferencing coordinate transformations defined by an Image Georeferencing Metadata (IGM) application profile of GML. The proposed IGS and IGM standards came close to adoption in 2008, but they are now being improved before re-consideration. OGC members are in the process of introducing a SWE version of WPS that will be in harmony with SWE and could provide a more harmonious and common foundation for image processing services. The SWE-WPS would support service chaining of sensor data, including georectification and other data.
Though work remains in finalizing the georeferencing approaches, this is a major step forward for Web-based processing of Earth images.
Many of the manual tasks involved in Earth imaging can be accomplished by Web services working together in an automated fashion to provide information requested directly by users or by computer models or decision support systems. All of the standards in the "OGC Baseline," or collection of OGC standards, can provide links in these Web service chains.
Looking ahead, service chaining will support workflows that involve geospatial rights management, Earth browsers, data preservation, data quality, geosemantics and other concerns. These are all elements in the foundation that is being built for a new era in which Web-based geoprocessing, including chained Web services that operate on images, will be the norm.