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@opengeospatial.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.

src="http://portal.opengeospatial.org/files/?artifact_id=10382">

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)