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:

• Common Architecture
• Sensor Web Enablement (SWE)
• Geo-Decision Support Services (GeoDSS)
• Geo-Digital Rights Management (GeoDRM)
• Open Location Services (OpenLS)

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).

• Refine Publish-find-bind pattern using deployed OGC Catalog: NASA Earth-Sun Gateway
• Develop CS/W to register numerous OWS-3 entities
• Workflow management for service chaining
• Catalog Profiles and Population
• Refinement of OGC Catalog Profiles
• Provide Catalog Services for all of OWS-3
• SOA Maturation and Workflow
• What is needed to bind (bind to GetCapabilities or more)?
• What is needed to interoperate / federate among catalogs (c.f. ESG)?
• Workflow fine-structure, coarse-structure, chaining, representation
• Business processes and BPEL chaining - opaque / translucent / transparent

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

• refinements to service and ADT definitions of existing features,
• add a tracking service that supplies a position management and access capability and make first steps toward path-planning and navigation in buildings and other environments beyond the limits of road networks.

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 3^rd 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.

• SWE Information Engineering

  SWE Information Engineering will develop a coherent information model or set of integrated information models for distributed sensor environments. The specific activities included in this work item are:

  1. SensorML/TransducerML/1451 harmonization: Develop, integrate and harmonize information models and schema for SensorML, TransducerML and IEEE-1451. Results of this activity are anticipated to be made part of the SensorML specification.
  2. SensorML/O&M/Earth Imagery Harmonization: Develop, integrate and harmonize information models and schema for SensorML, O&M and those for Earth Imagery (OGC Abstract Specification, Topic 7) and ISO 19130. Results of this activity are anticipated to generate change requests to the related specifications.
  3. Sensor Registry Information Model: Collaborate with Common Architecture (CA) thread to develop a Sensor Registry information model. Develop sensor descriptions for sensor types and instances and publish sensor types and instances to an online instance of Sensor Registry Service (a profile of CSW) established by CA.
  4. Control and Status Messages: In many instances sensors require a period of time to plan for and conduct a measurement. Since web services are inherently stateless, the task-fulfillment process must exist at a higher level than the individual service interfaces. A message-oriented approach allows control and status information to be exchanged in a context that is above the specific implementing service infrastructure. This work item will identify the messages required by a distributed SWE environment and develop the models and schemas for those messages.
• Sensor Planning Service

  The Sensor Planning Service work item will revise and extend the Sensor Planning Service (SPS) specification to accommodate the changes to the information models and business processes developed through the Information Engineering work item. These changes will enable multiple SPS instances to work together in a nationwide sensor network. Particular emphases will be placed on enabling sensor acquisition feasibility and tasking requests as described in Appendix C and implementing the use-cases captured in Appendix D.

• Sensor Observation Service

  Revise and extend the Sensor Observation Service (SOS)[1] specification for enabling access to and exploitation of sensor observations. Particular extensions include support for; TransducerML, IEEE 1451, imagery and in-situ sensors. The Sensor Observation Service will serve as a critical component for constructing hierarchical networks for nationwide sensor webs.

• SWE Integration and Demonstration

  SWE components will be integrated with other OWS-3 components to build an OWS-3 Geo-Decision Support Demonstration. This capability will be based on the IH4DS BPEL service chaining capability developed in OWS-2. Developers of SWE components are expected to work with the Common Architecture and GeoDSS teams to assure that an integrated BPEL workflow can be demonstrated.

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:

• Schema Tailoring and Maintenance

  In a network-centric environment, information from any source may serve as input to the decision making process. However, the information may not be suitable for the issue at hand when in its’ native format. The actual information needed by the decision maker may be a subset of the information available or a combination of information elements from a number of information communities. The Schema Tailoring and Maintenance activity will build on work done in the OWS-2 Information Interoperability task to address this issue. This activity will enhance the UGAS and Schema Editing tools, develop additional application schemas and, in conjunction with the Common Architecture subtask, deploy a Schema and UML Model registry and repository to support the Schema tailoring environment.

• Data Aggregation Service

  The Data Aggregation Service work item complements the Schema Tailoring and Maintenance work item. In the schema tailoring work item, customized schemas are developed representing subsets and/or the aggregation of data elements from multiple schemas. The Data Aggregation Service task continues that work-flow by transforming information from the original sources into an information resource based on the customized schema. The intention of this work item is not to define new OGC specifications. It is expected that this functionality can be implemented using existing WFS interfaces.

• Feature Portrayal Service

  The Feature Portrayal Service work item will develop an OWS Portrayal service that is capable of rendering for web access feature data from multiple servers. This Feature Portrayal Service (FPS) will also support user-selected symbolization of the features using the techniques developed through the Emergency Mapping Symbolization (EMS) initiative.

  In the course of the FPS effort, it is expected that changes to the Style Management Services for Emergency Management document (OGC 04-040) can be expected. Areas where changes can be expected are:

  • Interactions between SLD, FPS, Context and CS-W
  • Refinement of style registration in CS-W
  • Default styling for GML
  • Reduction in redundant metadata

  EMS support will also require the development and deployment of an SLD registry. This registry will be developed in conjunction with the CA subtask.

• Geo-Video Service

  Develop a web service for access to video data including geo-location information. The service will provide an interface for requesting a stream of video data. This service must be able to serve both stored and live video data. For OWS-3 the video stream will be required to accept play-back commands from a web service client. The Geo-Video service must include metadata in the video stream sufficient for a client to geo-locate the video similar to the way WMS and WTS geo-locate data. Identification or development of a suitable metadata schema is also part of this work item. Use of video streaming standards from the broader information technology community will provide quick uptake of a geo-specific video service.

• GeoDSS Client

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.

• GML Investigations

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:

1. Investigate techniques to reduce the overhead (both bandwidth and computational) required to transfer feature data using GML
2. Investigate the impacts and implications of using GML encoded topology.
3. Investigate the use of external links within GML application schemas to support external resources.
4. Investigate data integrity when using COTS working databases with GML. Specifically, can a database ingest a GML file, store it in the internal format then export the data as GML without any changes to the data. The objective is for the input and output GML files to be identical.

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 4.4.1.2.4) so that the techniques developed here can be readily applied to the FPS.

GeoDRM Planned Activities

• GeoDRM License Model
• WMS with Click-Through License
• WFS with click-through license

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.

Scenario

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:

• Among the sensors discovered during the query is a set of chemical and temperature detectors, and units that monitor the physical plant of the storage unit that was breached. These support the IEEE 1451 Transducer Interface Standards, and are accessible through a port on the outside of the building. Real-time aerial visual and thermal imagery help operations managers using the DS client guide a team past the hazards of the blaze so that they can connect to the monitoring port and assess conditions within the storage facility. The field team is equipped with PDA’s that support the OpenLS protocols. They use these to acquire data from the building’s sensors, and relay the information to the Operations Center.
• An array of movable heat and chemical sensors placed around the fire perimeter reveal that the blaze and toxic plume have changed direction and are headed towards a response team in a canyon above the fire. Operations personnel note the hazard and notify the team, which relocates.
• Aerial thermal imagery reveals that much of the fire that has escaped into the wildland is actually very light. Upon reviewing this and the concurrent geoVideo feeds, foresters agree that it would not harm the fire-adapted forest, and in any event the fire prediction specialists expect it to burn itself out before it spreads far. However, there is a particularly intense section of the blaze that needs to be controlled more actively right away, or it will grow into a much more serious conflagration. Most response units are directed to that region.
• Using the entire array of fixed and mobile point in-situ monitors, and the thermal and visual imagery and full-motion geoVideo coming from satellite and aircraft, all superimposed on the framework of population and transportation network data, public safety operations develops a set of evacuation routes and threshold conditions that would trigger a public evacuation advisory.



---

[1] Sensor Observation Service (SOS), formerly known as Sensor Collection Service (SCS)