OGC Web Services, Phase 3
1. OWS-3 Overview
Building on previous work in other OGC initiatives and technical working groups, OWS-3 participants worked collaboratively to extend the OGC baseline to enable an interoperable, multi-source decision support environment. The work addressed a rich set of requirements provided by OWS-3's sponsors. Sponsors include: BAE Systems, IONIC, GeoConnections (Canada), Lockheed Martin, MAGIC Services Initiative, National Aeronautic and Space Administration (NASA), Oak Ridge National Laboratory, NAVTEQ, Questerra, US Geological Survey (USGS) and other organizations.
Participants worked in the following areas:
The OWS-3 kickoff took place April 19-21, 2005 and the final demonstration of capabilities occured in October 2005.
OWS-3 is dedicated to memory and contributions of John Vincent.
The initiative manager was Chuck Heazel. For more information on the OWS-3 Initiative, please contact George Percivall, percivall [at] opengeospatial [dot] org
This document provides a summary of the OWS-3 results: http://portal.opengeospatial.org/files/?artifact_id=10380
2. OWS-3 Initiative Threads
2.1 - Common Architecture
The Common Architecture (CA) thread addresses issues, infrastructure and requirements necessary to integrate services implemented using OGC specifications into an operational Web Service enterprise. For OWS-3, the emphasis of the CA thread will be on capturing best practices and on extending the scope and capabilities of catalog services. These items are being addressed in the OWS-3 CA effort:
Framework of fundamental patterns and infrastructure services for implementation and deployment of a Service-Oriented Architecture (SOA).
2.2 - OGC Location Services
The OpenGIS Location Services (OpenLS) comprise an open platform for position access and location-based applications targeting mobile terminals. The OpenLS feature set is defined by "Core Services and Abstract Data Types (ADT)" that comprise this platform. The services are defined in two OGC specifications that are now in the RFC stage within OGC TC.
The OWS-3 OpenLS thread will
As part of OWS 3.0 we will continue to refine the protocol developed as part of OWS 2.0. We will also focus on creation of interoperable clients that go beyond the simple demonstration of OWS 2.0. Continuing research will be performed in areas called out in our report delivered as part of OWS 2.0.
Indoor-outdoor Navigation refers to the means for clients with mobile terminals to receive location and navigation guidance indoors or outdoors, as well as receive navigation guidance across indoor-outdoor and indoor-indoor transition points (e.g., doorways). Indoor location concepts must be supported for how people identify location for indoor environments, e.g., building, floor, room, etc. Indoor navigation concepts must also be supported for how people negotiate their way around indoor environments, e.g., park on level P1-P4, elevator to 3rd floor, right hall to room 310.
The present OpenLS services and information model are limited to outdoor navigation (i.e., the concepts of ‘location’ and ‘navigation’ are confined to outdoor activities.) An enhancement to the OpenLS services and information model is to support seamless indoor-outdoor navigation. The OpenLS services and information model will have to be modified to accommodate indoor location and navigation constructs.
2.3 - OGC Sensor Web Enablement
The Sensor Web subtask will mature the existing set of SWE work items to enable the federation of sensors, platforms and management infrastructure into a single sensor enterprise. This enterprise will enable the discovery and tasking of sensors as well as the delivery of sensor measurements regardless of sensor type and controlling organization. The ultimate vision is of a sensor market place where users can identify, evaluate, select and request a sensor collection regardless of sensor type, platform or owner.
The OGC Sensor Web Enablement framework has achieved a reasonable degree of maturity over the past two OWS interoperability initiatives (OWS-1 and OWS-2). At the same time, related efforts have been underway within the IEEE, Defense and Homeland Security communities. OWS-3 will integrate these complementary activities and develop a framework of standards and design patterns for building nationwide sensor networks.
Sponsors of the OWS-3 SWE thread have two primary goals. First of all, the sponsors have multiple, independent sensor and sensor support systems. It is their desire to integrate these systems allowing users to reach-out, access and use any sensor and any system. The second goal is to enable a "plug-and-play" sensor framework. There are existing specifications that enable plug-and-play, specifically IEEE 1451 and TransducerML. Integration of those specifications into the SWE framework would achieve that goal.
2.4 - Geo Decision Support Services (GeoDSS)
The Geo-Decision Support Services subtask will extend the DSS and Information Interoperability work done in OWS-2. One issue facing DSS systems is the ability to exchange and access geographic information within and across information communities (Information communities are groups that share common geographic terms and common spatial feature definitions). To address this issue, the GeoDSS subtask will leverage the Information Interoperability work from OWS-2 to explore ways to tailor geographic information for different information communities. The GeoDSS subtask will also build on the OWS-2 service chaining work to explore (in cooperation with the Sensor Web subtask) the integration and processing of geographic and sensor data to support an emergency response scenario. In addition, GeoDSS will develop new capabilities including a geoVideo service, XML schemas for moving objects and a portrayal service for feature data. Finally, GeoDSS will explore extensions/enhancements to the underlying OGC services to address a greater extent of emergency response scenarios.
One objective of geospatial web services is to allow decision makers to access and use information that was collected for other purposes. The GeoDSS thread will extend on existing OWS capabilities to better address the use of "unanticipated" information sources. The specific issues that need to be addressed are:
In OWS-3, the development of a GeoDSS Client will begin with the results of the OWS 1.2 Integrated Client for Multiple OGC-compliant Services (OGC Discussion Paper, document 03-021). The OWS1.2 Integrated Client was defined as a software application that provides common functionality for the discovery, retrieval, and handling of data from WMS, WFS, and WCS. At the core of the integrated client concept is the requirement to provide a unified environment that allows a user to simultaneously visualize, analyze, and/or edit data from multiple sources. The GeoDSS client will extend the OWS1.2 Integrated Client to include the services developed and enhanced through OWS-3.
Operational environments encounter data volume and performance issues that are not exposed in a prototype environment. The Investigations work item will look as some of the issues that have come to light as OWS technologies move into the operational sphere. The sponsors expect that these investigations will be conducted using well-structured experiments where dependent and independent variables are identified and controlled.
The specific investigations to be pursued under this work item are:
2.5 - Geospatial Digital Rights Management (GeoDRM)
After the introduction of the Web Mapping Service Specification in April 2000, important Spatial Data Infrastructure (SDI) components began to be developed. Today, in 2004, major parts of the SDI vision have become real. Implementation Specifications like the WMS, WFS, WCS, CS-W and GML can be used to build up global interoperable SDIs. Interoperable software products have been developed and deployed. The concept of a SDI based on OGC components has been proven with many realized SDIs worldwide.
From an economic point of view, a SDI provides the transport mechanism for trading/selling spatial content. The development of business models for trading spatial data has already started. The OGC, however, has not provided any interoperable trading capabilities. There is the risk that proprietary solutions could cut the SDI interoperability workflow. The OGC GeoDRM effort has been started to address this need. This thread of OWS-3 is a first step in developing the needed GeoDRM capabilities.
The objective of the GeoDRM thread in OWS-3 is to extend the "click-through" licensing concept for web sites to geospatial data services. In particular, click-through licensing techniques will be developed for the Web Map Service and Web Feature Service. This activity will be coordinated with the Feature Portrayal Service (FPS) work item in GeoDRM (paragraph 220.127.116.11.4) so that the techniques developed here can be readily applied to the FPS.
GeoDRM Planned Activities
3. OWS-3 Demonstration Scenario
This Appendix describes a fictitious scenario that provides context for a demonstration of the functionality to be developed in the OGC Interoperability Program (IP) Initiative, Open Web Services, Phase 3 (OWS-3).
In particular, it motivates the use of interfaces and encodings to be developed in the Common Architecture, Sensor Web, and Decision Support components of this Initiative in a fire-response scenario incorporating elements of a generic emergency It includes discovery and deployment of remote imaging and point in-situ sensors of various types, acquisition and processing of data obtained from them, integration of these data with other geospatial data assets, and ultimately analysis and portrayal that enables response coordinators to direct damage control and containment teams, provide bulletins to public safety agencies, and monitor the ongoing status of the blaze.
A fire monitoring facility in Southern California receives notification of a probable fire on the outskirts of a hypothetical community in the hills surrounding the Los Angeles basin. Further queries reveal that there is indeed a substantial conflagration. Its origin is unknown, but it has impinged upon a variety of industrial facilities at the edge of the inhabited area and breached a storage facility for a variety of industrial chemicals. Recognizing the risk that the resulting plume may contain toxic or low-level radioactive components in addition to the particulates and combustion products typical of a wildland fire, the professionals act quickly to find and deploy resources to track the plume and evaluate its composition, as well as to support the response effort.
Using the discovery features of a broadly capable Decision Support (DS) client, they initially call up a standard set of framework data including topography, population, the transportation network and elements of critical infrastructure for the surrounding region. Using this same client, [and also a specialized Sensor Web Client,] they search a Web-based catalog service (CS/W) known to federate a variety of other catalogs whose contents describe a wide range of sensor systems and sensor webs. They are able to restrict their queries to the geographic region of interest, to seek out sensors with certain known internal characteristics, and also to look for sensors based on their ability to detect certain toxins or other hazardous materials.
They discover a UAV facility that has deployable multispectral imaging capabilities, provides live feeds using geolocated video (geoVideo) service, and is also capable of carrying various point in-situ sensors suitable for detecting a variety of chemical species and radiation levels. The search also identifies a number of imaging instruments in spacecraft, a network of fixed meteorological sensors and a variety of services that stream data from networks of point in-situ sensors. (The operators do not know or need to know this, but some of the sensor services thus discovered support transducers that report their observations using TransducerML, while others conform to the IEEE 1451 specification.)
Data from some of the point in-situ sources needs to be processed or filtered so that, to the extent possible, it is delivered to the client in a consistent fashion with respect to units, observation time, or other parameters. The DS client’s search capabilities are invoked to find web-based services that can perform the necessary operations, and then the client’s service chain management features are used to invoke a [previously-constructed] chain that integrates these data into its working view of the affected area.
Mobile assets, including satellite-based services, ground-based mobile point in-situ units, and the UAV resource are queried via the DS client’s SPS capabilities to learn whether and when they can collect information to help with evaluation or to support field operations. Available units are tasked to collect required information at selected times and locations. Data acquired from them are processed, again using [predefined] service chains invoked by the DS client, so that the client ultimately acquires as comprehensive a view of the emergency response region as time, resources, and technology permit. This view is updated in real time as suitably processed sensor data arrive. Critical features, danger zones, and predictions about the movement of the blaze and its plume are identified and distributed as needed.
The same information must be distributed to various organizations assisting with the response. These include military units as well as civil emergency response organizations. Bulletins and appropriate summaries must be distributed to the public and the media. Maps for the various groups must be symbolized differently. To make the work as easy as possible, the mapped information is distributed periodically in hardcopy and electronic form using two different stylings, one based on the Emergency Management Symbology specification, and the other based on MIL-STD 2525B. This is accomplished via the Feature Portrayal capability the DS client, which styles the information using two SLDs provided in a registry that has been provisioned for this purpose.
Specific scenarios demonstrating the above technologies might include the following:
 Sensor Observation Service (SOS), formerly known as Sensor Collection Service (SCS)