Architecture

OGC® Open Geospatial Consortium

Technology Office

4899 North Old State Road 37 Bloomington, IN 47408

Telephone: +1-812-334-0601 Facsimile: +1-812-961-2053

Request For Quotation and Call For Participation In the OGC Web Services 4 Initiative Initial Operating Capability and Demonstration

Annex B: OWS-4 Architecture

RFQ Issuance Date: April 11, 2006

Proposal Due Date: May 5, 2006

Due Date: May 5, 2006 Annex B: OWS-4 Architecture

TABLE OF CONTENTS ANNEX B: OGC WEB SERVICES 4 (OWS-4) - ARCHITECTURE ...... 3 1 OVERVIEW ...... 3 2 OWS-4 THREAD SUMMARIES ...... 3 3 OWS-4 TECHNICAL BASELINE ...... 7 3.1 OPENGIS REFERENCE MODEL ...... 7 3.2 OPEN GEOSPATIAL CONSORTIUM TECHNICAL BASELINE ...... 8 3.3 OTHER STANDARDS RELEVANT TO OWS-4...... 9 4 OWS-4 ARCHITECTURE...... 9 4.1 SENSOR WEB ENABLEMENT (SWE) ...... 9 4.2 GEO PROCESSING WORKFLOW (GPW)...... 25 4.3 GEO-DECISION SUPPORT SERVICES (GEODSS)...... 43 4.4 GEODRM AND TRUSTED GEOSERVICES...... 56 4.5 CAD/GIS/BIM ...... 75 4.6 OGC LOCATION SERVICES (OPENLS)...... 90 4.7 COMPLIANCE AND INTEROPERABILITY TEST AND EVALUATION (CITE) ...... 96 APPENDIX A: OWS 4 REFERENCES TO OTHER STANDARDS ...... 105 APPENDIX B: SCENARIO NARRATIVE ...... 109 APPENDIX C: SENSOR WEB USE CASES ...... 113 APPENDIX D: ACTM DATA DICTIONARY ...... 122

Page 2 Due Date: May 5, 2006 Annex B: OWS-4 Architecture

Annex B: OGC Web Services 4 (OWS-4) - Architecture

1 Overview

The architectures presented in this Annex are based upon a collaborative effort between OGC Web Services 4 (OWS-4) Sponsors and OGC’s IP Team. The architecture team used results from previous and ongoing OGC Interoperability Program initiatives, existing OGC discussion papers and specifications, OGC Technical Committee activities, and publicly available documentation from related standards initiatives and elsewhere.

Section 2 provides an overview of the OWS-4 development threads.

Section 3 discusses the architectural approach and technical baseline for OWS-4.

Section 4 discusses the architectural approaches and issues for each of the OWS-4 development threads.

Appendix A contains key references applicable to this RFQ.

Appendix B is a description of a fictitious scenario that is to be used in support of the Sensor Web Enablement thread of OWS-4.

Appendix C contains a set of Sensor Web scenarios.

The OGC portal provides a Glossary of Terms at the following URL that may be useful to aid in understanding and interpretation of terms and abbreviations contained throughout this RFQ: http://www.opengeospatial.org/resources/?page=glossary

2 OWS-4 Thread Summaries

OGC’s Interoperability Program is a global, hands-on and collaborative prototyping program designed to rapidly develop, test and deliver proven candidate specifications into OGC’s Specification Program, where they are formalized for public release. In OGC’s Interoperability Initiatives, an international team of technology providers’ work together to solve specific geo-processing interoperability problems posed by the initiative’s sponsoring organizations. OGC Interoperability Initiatives include test beds, pilot projects, interoperability experiments, and interoperability support services – all designed to encourage rapid development, testing, validation and adoption of open, consensus based standards specifications.

In the Fall of 2005, the OGC issued a call for sponsors for an OGC OWS-4 Interoperability initiative testbed activity to advance OGC’s open framework for interoperability in the geospatial industry. Three meetings were conducted with potential OWS-4 sponsors to review the OGC technical baseline, to discuss OWS 3 results, and to identify OWS 4 requirements. Sponsors have expressed keen interest in advancing standards for sensor webs, geospatial digital rights management, geospatial semantics and knowledge management. After analyzing the sponsors input, the OGC Interoperability Team recommended to the sponsors that the content of the OWS-4 initiative be organized around the following 7 threads: 1) Sensor Web Enablement (SWE) 2) Geo Processing Workflow (GPW) 3) Geo Decision Support (GeoDSS) 4) Geo-Digital Rights Management (GeoDRM) 5) CAD / GIS / BIM 6) OGC Location Services (OpenLS) 7) Compliance Testing (CITE)

Page 3 Due Date: May 5, 2006 Annex B: OWS-4 Architecture

An introduction to these 7 threads is described below, followed by a detailed discussion of the architectural implications of the initiative threads.

2.1 Sensor Web Enablement (SWE)

The Sensor Web subtask will continue to 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.

Emphasis for SWE during this phase of the OWS project will be on:

• Leveraging results of OWS-3 and SAS IE initiatives to refine, extend and integrate those specifications and implementations.

• Developing examples of SWE Information Model schema elements (i.e., O&M, SensorML, TransducerML and SWE Common) for specific classes and uses of observation offers, phenomena, sensor systems, processes and transducers.

• Harmonizing SWE concepts and specifications with other OGC specifications and initiatives.

• Harmonizing SWE concepts and specifications with other complementary initiatives moving forward by other organizations, including IEEE, OASIS and US Government agencies and programs.

• Demonstrating support for realistic operational scenarios per the SWE Enterprise Viewpoint and Use Cases.

In OWS-4, emphasis of interoperability engineering activities for the SWE thread will be on integration and demonstration of physical sensors and simulators within a realistic operating environment. In addition, progress is expected on enhancements to the SWE specifications as described in the “Future work” clauses of the respective baseline documents.

2.2 Geo Processing Workflow (GPW)

The Geo-Processing Workflow (GPW) thread will develop and demonstrate how to interconnect geo- processes through publish-find-bind and service chaining to meet workflow requirements. The result will be the creation of valued-added enterprise systems that demonstrate the power of interoperability and service-oriented architectures. The OWS-4 GPW thread brings together developments from several previous initiatives.

The planned activities for GPW:

• UML and GML3.2 application schema development

• Producer to Customer Production Workflow

• SWE Geo-processing Workflow

• Catalog Services for OWS-4

Page 4 Due Date: May 5, 2006 Annex B: OWS-4 Architecture

2.3 Geo Decision Support (GeoDSS)

Geo-Decision Support Services (GeoDSS) provide interoperable access to distributed geospatial web services to aid decision makers in forming, analyzing, and selecting alternatives. GeoDSS utilizes workflow management to produce context-specific results from information and knowledge from multiple communities. The GeoDSS subtask will extend the Decision Support and the Information Interoperability work done in OWS-3 to include multilingual interoperability and compressed GML data.

Enhanced decision support using information provided from an increasingly wide variety of services places more demands on the ability of the user client software. The GeoDSS thread will develop and demonstrate client programs that will integrate many services, provide stand-alone relatively light-weight open-source GML visualization and 3D CAD visualization. Each of these clients offers an opportunity to exploit the wide variety of data for decision support.

The planned activities for GeoDSS:

• Portrayal

• GeoDSS Clients

• Coverage Portrayal Service

• Multilingual services

• WFS-Files and WFS-Database

• WMS Tiled

2.4 Geo Digital Rights Management (GeoDRM)

For the purpose of the OWS-4 initiative, GeoDRM consists of standards, technologies, and practices which enable interoperable trading of geospatial content to be implemented on top of OWS services. GeoDRM does not include per se, but does require and connect to capabilities for establishing trust between actors in OWS services interactions.

The planned activities for GPW:

• GeoDRM Information Elements

• GeoDRM License Lifecycle for OWS Services

• GeoDRM enablement of OWS Services and Clients

• GeoDRM component implementations

Page 5 Due Date: May 5, 2006 Annex B: OWS-4 Architecture

2.5 CAD / GIS / BIM

The CAD/GIS/BIM thread aims to develop and demonstrate a framework of interoperability across the lifecycle of building and infrastructure investment involving design, construction, and operation and decommissioning. To achieve these goals requires cooperation and collaboration among a number of organizations and domains that include CAD, AEC, geospatial, 3D visualization and urban planning and simulation. These diverse and sometimes divergent interests pose challenges to achieve interoperability due to differences in terminology, information standards and modeling, scale of interest, and technical nature of the problems to be solved in each area. This CAD/GIS/BIM thread seeks to begin to solve those interoperability issues building on the groundwork that has already been laid by the CAD/GIS WG and its involvement with key organizations such as International Alliance for Interoperability (IAI), National Building Information Management (BIM) committee and vendors supporting the architecture, engineering and construction industry.

The CAD/GIS/BIM thread’s activities will be focused in three general areas:

• Information Models and Encodings

• Services-based Interoperability

• Applications and Demonstrations

This work on information models and services will develop or extend existing OGC web services to allow storage, retrieval and coordinated use of CityGML for larger-view exploitation combined with Industry Foundation Classes (IFCs) for details using building elements such as floors, walls, doors, windows, ventilation, plumbing and electrical infrastructure. These objectives will require development of GML application schemas based on CityGML and IFCs to allow interoperable access and use of these data sources with an integrated and lightweight client for visualization and exploitation along with geospatial and 3D CAD data. Furthermore, these data must be converted to a common coordinate reference system for use in a CAD/GIS client.

2.6 OGC Location Services (OpenLS)

The OpenGIS Location Services (OpenLS) comprise an open platform for tracking and location-based applications targeting mobile terminals. OpenLS differs from the other OWS threads in its focus on the specific needs of small, wirelessly-connected devices used to track people and things as the move or navigate in geographic space. 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 and preliminary results in the form of Draft Interoperability Program Reports resulting from the OWS-2 and OWS-3 Initiatives.

The OWS-3 OpenLS thread will refine service and ADT definitions of existing features with a focus on refinement of

• Tracking Service that supplies a position management and access, and

• Micro Features that provide very compact representations of 2- and 3-D geographic features.

The goal of the OpenLS Thread is to move the Tracking Service and Micro-Features toward commercial implementation.

Page 6 Due Date: May 5, 2006 Annex B: OWS-4 Architecture

2.7 Compliance Testing (CITE)

The OGC Interoperability Program and the OGC Specification Program have achieved a great deal of momentum as a result of the multiple OGC web service specifications that have recently been published. Key consumers in the geospatial industry are modernizing their enterprises based on the applicability and interoperability of OGC web services. The major geospatial industry consumers require verifiable proof of compliance with OGC specifications in order to reach the desirable outcome of interoperability. Furthermore, as the OGC technology stack has matured, a group of interfaces has emerged that represents a baseline of technology needed to implement a full interoperable spatial data infrastructure.

Successful completion of the OWS-4 CITE thread will result in a suite of compliance tests for this baseline of interfaces, which include WMS 1.3, WFS 1.1, Filter Encoding 1.1, CSW 2.0, WCS 1.0, GML 3.1.1, SLD 1.0 and Web Map Context 1.0. Also included in the requirements are reference implementations of these specifications. A reference implementation is an open source, fully functional implementation of a specification in reference to which other implementations can be evaluated. The OGC provides open source reference implementations to ensure maximum transparency of its specifications for both vendors and customers.

Another key aspect of CITE under OWS-4 is the evaluation of the technology with which OGC runs its test program. In the past, service testing has successfully been performed using software acquired from The OpenGroup. This software has served well for developing tests for a variety of services, but it is less useful in testing XML encodings. Also, this software is a commercial product, and therefore its use incurs ongoing maintenance and feature enhancement costs to the OGC membership. For these reasons an evaluation of an open source alternative is discussed in this thread.

The Conformance and Interoperability Test and Evaluation (CITE) thread is intended to provide the geospatial industry (consumers and vendors) a methodology and tools which will test compliance with OGC web services.

3 OWS-4 Technical Baseline

3.1 OpenGIS Reference Model Relevant Specifications: OpenGIS® Reference Model version 0.1.3 (http://portal.opengeospatial.org/files/?artifact_id=3836)

The OpenGIS Reference Model (ORM) provides an architecture framework for the ongoing work of the OGC. Further, the ORM provides a framework for the OGC Technical Baseline. The OGC Technical Baseline consists of the currently approved OpenGIS Specifications as well as for a number of candidate specifications that are currently in progress.

The ORM is a living document that will be revised on a regular basis to continually and accurately reflect the ongoing work of the Consortium. It is encouraged that respondents to this RFQ understand the concepts that are presented in the ORM.

The structure of the ORM is based on the Reference Model for Open Distributed Processing (RM-ODP). This Annex of the OWS-4 RFQ will deal with the upper four views; Enterprise, Information, Computational, and Engineering as shown in the figure below. Each thread of the initiative will be described in this annex using these four views.

Page 7 Due Date: May 5, 2006 Annex B: OWS-4 Architecture

Enterprise viewpoint: articulates a “business model” that should be understandable by all stakeholders; focuses on purpose, scope, operational objectives, policies, enterprise objects, etc Information viewpoint: focuses on information content and system behavior (i.e. data models, semantics, schemas). Computational viewpoint: captures components, interfaces, interactions and constraints without regard to distribution. Reference Model Engineering viewpoint: describes infrastructure and mechanisms for component distribution, distribution transparency and constraints, and binding and interaction. Technology viewpoint: defines implementation and deployment environment using technologies, standards and products of the day.

Figure 1 - ORM Reference Model

3.2 Open Geospatial Consortium Technical Baseline

The OGC Technical Baseline, at any point in time, is the set of all Adopted Specifications plus all other technical documents that have been made available to the public by the OGC Technical and Planning Committees. The Technical Baseline includes OpenGIS Implementation Specifications, Abstract Specifications, Best Practices Documents, Recommendation Papers, Discussion Papers, and the OpenGIS Reference Model. These specifications and other documents are freely available to the public at this website: http://www.opengeospatial.org/specs/?page=baseline

With the exception of the CITE thread, OWS-4 will use GML version 3.2.0 which is available is OGC Document 05-108r1. OGC Document 05-108r1 is GML 3.2.0 and equivalent to ISO DIS 19136. It is anticipated that the next version of GML that the OGC Specification Program will approve will be 3.2.1, which is anticipated to be equivalent to the ISO International Standard for GML.

Several documents were approved for public release at the recent OGC TC/PC meeting in March 2006 and are being processed for public release. These documents will become available over the next few weeks. If a specific document is needed by a proposer and it has not yet been published to the public link above, contact OGC ([email protected]).

Page 8 Due Date: May 5, 2006 Annex B: OWS-4 Architecture

Table 1 - OGC Documents pending public posting

Access Control (AC) & Terms of Use (ToU) “Click-through” IPR (05-111r2)

Catalog 2.0 Accessibility for OWS3 (05-084)

Catalog 2.0 IPR for OWS3 (05-109r1)

Feature Portrayal Service (OWS-3 GeoDSS IPR) (05-110)

GML Performance Investigations (05-050 and 05-101)

OpenLS Tracking Service (06-024)

OWS3 GML Topology Investigation (05-102r1)

Schema Tailoring and Maintenance (OWS-3 GeoDSS IPR) (05-117)

Styled Layer Descriptor Profile of the WMS Implementation Specification (05-078)

Symbology Encoding Implementation Specification (05-077)

Symbology Management - OWS3 DIPR (05-112)

Temporal Standard Recommendations (06-022)

UGAS Tool (OWS-3 GeoDSS IPR) (05-118)

Web Coverage Processing Service (WCPS) proposal for Discussion Document (06-035)

3.3 Other Standards Relevant to OWS-4

The OGC specifications are dependent upon standards developed and released by other Standards Developing Organizations (SDOs). Documents in the OGC Technical Baseline contain a list of other standards relevant to the specific topic of the document. Additionally, OWS-4 is building on additional standards from other SDOs. These other standards are listed in Appendix A of this Annex A.

4 OWS-4 Architecture

4.1 Sensor Web Enablement (SWE)

The Sensor Web Enablement (SWE) architecture was designed to enable the creation of web-accessible sensor assets through common interfaces and encodings. Sensor assets may include the sensors themselves, observation archives, simulations, and observation processing algorithms. The role of SWE is depicted in Figure 1. The role of the OGC Sensor Web Enablement framework is to provide interoperability among disparate sensors and models, as well as to serve as an interoperable bridge between sensors, models and simulations, networks, and decision support tools.

Page 9 Due Date: May 5, 2006 Annex B: OWS-4 Architecture

Figure 1. The Role of Sensor Web Enablement (SWE)

SWE enables the creation of integrated sensor networks where all types of sensors, instruments, imaging devices and repositories of sensor data are discoverable, accessible and, where applicable, controllable via Web technologies and standards. In this vision, connections to sensors are layered with Internet and Web protocols and XML schemas are used to publish formal descriptions of the sensor’s capabilities, location and interfaces. Web services for serving, brokering and consuming sensor data can then parse and evaluate sensor characteristics and observations based on their published descriptions. Information provided in XML about a sensor’s control interface enables automated communication with the sensor system to determine, for example, its state and location, to issue controlling commands to the sensor platform, and to access its stored or real-time data.

Problems and Objectives

Problem Statement Project Objectives or “to be” state

Extremely broad and complex range of sensor Define common (standard) information models and platforms, types, and observations. Sensor service models to enable a very broad range of technology infrastructure is typically proprietary or sensors to be deployed and directly or indirectly, specialized for specific types of uses and cannot discovered and accessed. scale to nation-wide deployment.

Sensor systems typically have proprietary means for A standard solution for online access to sensor determining information about sensors. Sensors systems through a framework of Web Services, don’t describe characteristics such as capabilities enabling the capabilities of sensors (types or and state in a uniform way. individual instances) to be determined and the state of an individual sensor or set of sensors to be determined.

Page 10 Due Date: May 5, 2006 Annex B: OWS-4 Architecture

Sensors may not report their position or not in a A standard solution for online access to sensor uniform way. systems through a framework of Web Services, enabling the position of sensors to be determined (directly or computed).

Sensor systems typically have proprietary or type- A standard solution for online access to sensor specific means for obtaining and processing systems through a framework of Web Services, measurements and observations. Sensors don’t enabling sensor observations to be transformed into represent their observations in a uniform way. higher-order data objects for exploitation.

Sensor systems typically have proprietary means for A standard solution for online access to sensor management, control and access. systems through a framework of Web Services, enabling sensors to be directly or indirectly controlled or “tasked” for planned collection activities.

Sensor systems typically have proprietary alert and A standard solution for online access to sensor notification mechanisms. systems through a framework of Web Services, enabling alerts and notifications triggered by sensor systems to be handled and integrated in a uniform and less costly manner.

4.1.1 Scope

The OGC Sensor Web Enablement framework has achieved a reasonable degree of maturity over the past three OWS interoperability initiatives (OWS-1, OWS-2 and OWS-3). At the same time, related international efforts have been underway within the IEEE, OASIS and national defense and homeland security communities. OWS-4 will integrate these complementary activities and develop a framework of standards and design patterns for building scalable sensor networks.

Emphasis for SWE during this phase of the OWS project will be on:

• Leveraging results of OWS-3 and SAS IE initiatives to refine, extend and integrate those specifications and implementations.

• Harmonizing SWE concepts and specifications with other OGC specifications and initiatives.

• Harmonizing SWE concepts and specifications with other complementary initiatives moving forward by other organizations, including IEEE, OASIS and US Government agencies and programs.

• Demonstrating support for realistic operational scenarios per the Enterprise Viewpoint and Use Cases described below. 4.1.2 Planned Activities

Sponsors of the OWS-4 SWE thread have two primary goals. First, is to integrate multiple, independent sensor and sensor support systems, allowing users to transparently reach-out, access and use any of these

Page 11 Due Date: May 5, 2006 Annex B: OWS-4 Architecture sensor and systems. Second, is to enable a “plug-and-play” sensor framework. There are existing specifications that enable plug-and-play, specifically IEEE 1451. Integration of these specifications into a SOA based on SWE specifications will facilitate achievement of these goals.

4.1.2.1 SWE Information Model Engineering

The SWE Information Model Engineering activities will refine and extend the SWE Information Model for distributed sensor environments and harmonize with external information models and standards.

The specific activities included in this work item are:

4.1.2.1.1 SensorML/TransducerML/IEEE-1451 integration

Refine and integrate information models and schema profiles for SensorML, TransducerML and IEEE- 1451 for use in demonstrations of realistic operational scenarios. Results of this activity are anticipated to be change requests to the related baseline specifications, specification profiles for specific classes or applications of sensors, and worked examples for use in demonstrations of realistic operational scenarios.

4.1.2.1.2 Radiation/Video/Earth Imagery integration

Refine and integrate information models and schema for TransducerML, SensorML, O&M and the SWE Services (SOS, SPS, SAS) to support data formats for radiation detectors (ANSI N42.42), high-definition color motion video (ITU-T H.264 2005 i.e., MPEG-4), and earth imagery (OGC Abstract Specification Topic 7 and ISO 19123) with the goal of enabling automated processing of these sensor observations into high-value data products. Results of this activity are anticipated to be change requests to the related baseline specifications, specification profiles for specific classes or applications of sensors and data products, and worked examples for use in demonstrations of realistic operational scenarios.

4.1.2.1.3 Sensor Registry Information Model refinement

Develop, integrate and harmonize information models and schema profiles for a Sensor Registry based on the ebRIM profile of the Catalog Service for the Web (CSW). Develop taxonomies and dictionaries for sensor types, instances, observations, phenomenon and units of measure and publish these as resources to an online instance of Sensor Registry Service. Results of this activity are anticipated to be change requests to the related baseline specifications, specification profiles for specific classes or applications of sensors, and worked examples for use in demonstrations of realistic operational scenarios.

4.1.2.1.4 Sensor control and status message refinement and harmonization

In many instances sensors require a period of time to plan for and perform an observation event. 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 is sought that allows tasking, control and status information to be exchanged in a context that abstracts the specifics of an implementing sensor infrastructure. This work item will identify the messages required by a distributed SWE environment and develop the models and schemas for those messages. Results of this activity are anticipated to be change requests to the related baseline specifications, specification profiles for specific classes or applications of sensors, and worked examples for use in demonstrations of realistic operational scenarios.

Page 12 Due Date: May 5, 2006 Annex B: OWS-4 Architecture

4.1.2.1.5 Alerting and notification refinement and harmonization

Refine and integrate information models and schema for subscribing to and publishing sensor alerts. Results of this activity are anticipated to be change requests to the related baseline specifications, specification profiles for specific classes or applications of sensors, and worked examples for use in demonstrations of realistic operational scenarios. Emphasis will be placed on the use of OASIS EDXL-DE1 as the messaging envelope for use in demonstrations.

4.1.2.2 SWE Service Model Engineering

The SWE Service Model Engineering activities will refine and extend the SWE Service Model for distributed sensor environments and harmonize with external information and service models and standards.

The specific activities included in this work item are:

4.1.2.2.1 Sensor Planning Service

This work item will refine and extend the Sensor Planning Service (SPS) specification to accommodate the changes to the information models and business processes developed through the Information Model Engineering work item. These changes will enable multiple SPS instances to work together in scalable sensor networks. Results of this activity are anticipated to be change requests to the related baseline specifications, specification profiles for specific classes or applications of sensors, and worked examples for use in demonstrations of realistic operational scenarios.

Particular emphases will be placed on enabling sensor acquisition feasibility and tasking requests per the Asset Control Task Message (ACTM) vocabulary, implementing the use-cases described in this document and support for sensor systems supporting IEEE 1451, ANSI N42.42 and MPEG-4 (ITU-T H.264 2005) specifications. Other issues expected to be addressed include support for “volatile” or dynamically changing sensor state, role-based authentication and control, and standardized and community-defined tasking and control messages.

4.1.2.2.2 Sensor Observation Service

This work item will refine and extend the Sensor Observation Service (SOS) specification for enabling access to and exploitation of sensor observations. Emphasis will be placed on the ability to support “native-speaking” SensorML, TransducerML and IEEE 1451 systems for imagery and in-situ sensors. The SOS will serve as a critical component for constructing hierarchical and mesh networks for scalable sensor webs. Results of this activity are anticipated to be change requests to the related baseline specifications and working implementations for use in demonstrations of realistic operational scenarios.

Issues expected to be addressed include support for CBRNE sensor systems, ANSI N42.42 and MPEG-4 observation results, controlling high volume results from SOS requests, aggregating and computing summary observations, identifying and associating sensor instances with a standard URN identifier scheme, and dynamically changing sensor state.

4.1.2.2.3 Sensor Alert Service

1 http://www.oasis-open.org/committees/download.php/14163/EDXL_DE_Spec_v1.0.html

Page 13 Due Date: May 5, 2006 Annex B: OWS-4 Architecture

This work item will revise and extend the Sensor Alert Service (SAS) specification for enabling clients to subscribe alert conditions to sensor constellations and receive published alert messages. Emphasis will be placed on the ability to define and subscribe to alert conditions and support for different, COI-specific, content for alert messages. SAS should support “native-speaking” SensorML, TransducerML and IEEE 1451 systems for imagery and in-situ sensors. The SAS will be demonstrated as a critical element of scalable sensor webs and emergency warning systems. Results of this activity are anticipated to be change requests to the related baseline specifications and working implementations for use in demonstrations of realistic operational scenarios.

Support for multiple alert payloads and messaging protocols is desired, including support for ANSI N42.42, IETF XMPP, OASIS EDXL-DE and IETF GeoRSS/GeoAtom specifications.

4.1.2.2.4 Sensor Registry Service

The Sensor Registry provides capabilities for publishing, associating and discovering sensor resources of the sensor web infrastructure. These resources include SWE services (as well as other OGC services), sensor descriptions, process chains, taxonomies and dictionaries (e.g., of sensor types, phenomena, units of measure) and observation offerings. Results of this activity are anticipated to be change requests to the related baseline specifications and working implementations for use in demonstrations of realistic operational scenarios.

Issues expected to be addressed include support for identifying and associating sensor resources using a standardized URN identifier scheme and description and discovery of sensors with dynamically changing state.

4.1.2.3 SWE Integration and Demonstration

SWE components will be integrated with other OWS-4 components to build an OWS-4 Geo-Decision Support Demonstration. This capability will be based on the service chaining and workflow capability developed in the Geospatial Workflow Processing (GPW) thread of OWS-4. Developers of SWE components are expected to work with the OWS-4 Common Architecture and GPW teams to assure that an integrated sensor observation processing value-chain can be demonstrated. 4.1.3 Requirements

Proposals for the SWE thread should specifically address the following requirements:

Table 2 - SWE Requirements

SWE Information Model Engineering 1) Use of TML, SensorML and O&M schema for generation, access and exploitation of IEEE-1451 enabled sensors 2) Use of TML, SensorML and O&M schema for generation, access and exploitation of high-definition color motion video (ITU-T H.264 2005, i.e., MPEG-4 capable) sensors 3) Use of TML, SensorML and O&M schema for generation, access and exploitation of ANSI N42.42 radiation detector data 4) Use of TML, SensorML and O&M schema for generation, access and exploitation of data conforming to the ISO-19123 Conceptual Schema for Coverage Geometry and Functions 5) Demonstrate use of the SWE Information Model elements and schema for the Sensor Registry CSW, enabling publication and discovery of sensor system resources (e.g., sensors, sensor types,

Page 14 Due Date: May 5, 2006 Annex B: OWS-4 Architecture

observations, dictionaries for phenomenon and units) 6) Identify and model the business processes and information flows needed to manage and implement sensor related information and workflows, specifically: a) The model shall scale to support large-area, multi-sensor and multi-agency sensor networks. b) The model shall accommodate the use-cases documented in the SWE Enterprise Viewpoint and Appendix C of this document. 7) Refine and extend the SWE Information Model and schemas needed to implement the business processes and information flows of requirement item 6. a) The information exchange shall be based on a message oriented model b) Collection and feasibility requests for air and space-borne sensors shall include the information content described by the Asset Control Task Message (ACTM) vocabulary and schema. Sensor Planning Service (SPS) 8) Identify and document enhancements for the SPS Discussion Paper due to: a) Changes to the SWE Information Model and schema developed through the SWE Information Model Engineering work item. b) Changes to the service interface specification and schema reflecting changes to the SWE Information Model, new operational requirements and lessons-learned through testing and demonstration of implementations. 9) Develop and deploy an SPS implementing the changes identified in requirement item 8 and supporting one or more of the following classes of sensor systems and observable phenomenon: a) Distributed Sensor Communications Networks (DSCN) (e.g., adaptable wireless mesh networks of sensors) b) Remotely sensed imagery from airborne and spaceborne platforms c) CBRNE (Chemical, Biological, Radiological, Nuclear, Explosive) type sensors d) Simulation (control inputs and outputs of a model/simulation algorithm) e) Geo-located high-definition color motion video (e.g., MPEG-4 capable) sensors on stationary and mobile platforms Sensor Observation Service (SOS) 10) Identify and document enhancements for the SOS due to : a) Changes to the SWE Information Model and schema developed through the SWE Information Model Engineering work item. b) Changes to the service interface specification and schema reflecting changes to the SWE Information Model, new operational requirements and lessons-learned through testing and demonstration of implementations. 11) Develop and deploy an SOS implementing the specification identified in requirement item 10 and supporting one or more of the following classes of sensor systems and observable phenomenon: a) Distributed Sensor Communications Networks (DSCN) (e.g., adaptable wireless mesh networks of sensors) b) Remotely sensed imagery from airborne and spaceborne platforms c) CBRNE (Chemical, Biological, Radiological, Nuclear, Explosive) type sensors d) Simulation (output of a model/simulation algorithm)

Page 15 Due Date: May 5, 2006 Annex B: OWS-4 Architecture

e) Geo-located high-definition color motion video (e.g., MPEG-4 capable) sensors on stationary and mobile platforms Sensor Alert Service (SAS) 12) Enhance the SAS interoperability specification, including: a) Support for the SWE Information Model and schema developed through the SWE Information Model Engineering work item. b) Service interface specifications and schema reflecting changes to the SWE Information Model, new operational requirements and lessons-learned through testing and demonstration of implementations. 13) Develop and deploy an SAS implementing the specification identified in requirement item 12 and supporting one or more of the following classes of sensor systems, observable phenomena and protocols: a) Distributed Sensor Communications Networks (DSCN) ) (e.g., adaptable wireless mesh networks of sensors) b) Remotely sensed imagery from airborne and spaceborne platforms c) CBRNE (Chemical, Biological, Radiological, Nuclear, Explosive) type sensors d) Simulation (output of a model/simulation algorithm) e) Geo-located high-definition color motion video (e.g., MPEG-4 capable) sensors on stationary and mobile platforms f) IETF XMPP messaging protocol g) OASIS EDXL-DE message addressing 14) Evaluate, demonstrate and document standards-based patterns and strategies for automated transformation of low-level sensor-driven alerts into higher-level alerts and warnings for exchange and exploitation by decision-makers. Web Processing Service (WPS) 15) Develop profiles of the WPS implementation specification, including: a) Support for the SWE Information Model and schema developed through the SWE Information Model Engineering work item. b) Service interface specifications and schema reflecting changes to the SWE Information Model, new operational requirements and lessons-learned through testing and demonstration of implementations. 16) Develop and deploy an WPS implementing the specification identified in requirement item 15 and supporting one or more of the following automated processing functions: a) Transformation of O&M Observation data obtained via SOS for any given phenomena into coverage representations suitable for access and exploitation via WCS implementations b) Transformation of O&M Observation data obtained via SOS for any given phenomena into feature representations suitable for access and exploitation via WFS implementations c) Transformation of O&M Observation data obtained via SOS for any given phenomena into a multi-part information package consisting of observations, alerts, features, video and other relevant data for access and exploitation by decision-makers. SWE Integration and Demonstration 17) In cooperation with the OWS-4 sponsors, provide taskable sensors for use during OWS-4 and deploy

Page 16 Due Date: May 5, 2006 Annex B: OWS-4 Architecture

at the OWS-4 demonstration facility. 18) In cooperation with participants of the OWS-4 Geo-Processing Workflow (GPW) thread, develop processing chains incorporating SWE services, observation and image handling services and related data and processes. 19) In cooperation with the GPW Client work item, develop a SWE client that integrates and interoperates with OWS-4 SWE services and other related OWS services 20) Demonstrate the use of SWE processes, services and encodings to execute the demonstration scenario and use-cases developed for the project 21) Develop the Field Exercise Preparatory Plan, a plan for phased rollout of SWE Information Model and Service Model elements for use in out-year joint agency and coalition partner interoperability demonstrations and exercises.

4.1.4 Deliverables

The following Interoperability Program Reports (IPRs) will be developed in the SWE thread and submitted to the OGC Specification Program at the completion of the OWS-4: 1. SWE Architecture IPR – updates to existing SWE Architecture discussion paper for describing the Enterprise, Information, Computation, Engineering and Technology viewpoints of the SWE Architecture. 2. O&M IPR - updates to the O&M Discussion Paper, including updates to XML schema and documented instance examples for IEEE-1451 TEDS, ANSI N42.42 and ITU-T H.264 2005 (MPEG- 4) sensor data specifications. 3. SensorML Change Requests IPR - describes changes needed to the SensorML RFC for submittal to the OGC Specification Program as a Change Request. Must include updates to XML schema and documented instance examples for IEEE-1451 TEDS, ANSI N42.42 and ITU-T H.264 2005 (MPEG- 4) sensor data specifications. 4. TransducerML Change Requests IPR - describes changes needed to the TransducerML RFC for submittal to the OGC Specification Program as a Change Request. Must include updates to XML schema and documented instance examples for IEEE-1451 TEDS, ANSI N42.42 and ITU-T H.264 2005 (MPEG-4) sensor data specifications. 5. SOS Change Requests IPR – describes changes needed to the SOS RFC for submittal to the OGC Specification Program as a Change Request. Must include updates to XML Schema, WSDL, interaction diagrams and documented example requests and responses showing support for IEEE-1451 TEDS, ANSI N42.42 and ITU-T H.264 2005 (MPEG-4) sensor systems and data specifications. 6. SPS Change Requests IPR – describes changes needed to the SPS RFC for submittal to the OGC Specification Program as a Change Request. Must include updates to XML Schema, WSDL, interaction diagrams and documented example requests and responses showing support for tasking and control of sensors systems supporting IEEE-1451, ANSI N42.42 and ITU-T H.264 2005 (MPEG-4) specifications. 7. Sensor Alert Service IPR – updates to the SAS DP, including XML Schema, WSDL, interaction diagrams and documented example requests and responses showing support for IEEE-1451 TEDS, ANSI N42.42 and ITU-T H.264 2005 (MPEG-4) sensor systems and data specifications. Must also document support for generation of alert messages encapsulated with EDXL-DE. 8. Web Processing Service Change Requests IPR – describes changes needed to the WPS RFC for submittal to the OGC Specification Program as a Change Request. Must include updates to XML Schema, WSDL, interaction diagrams and documented example requests and responses demonstrating

Page 17 Due Date: May 5, 2006 Annex B: OWS-4 Architecture

support of automated processing of O&M Observations from SOS implementations into coverage, feature and other high-value data representations. 9. Geo-Video Service (GVS) IPR – updates to the GVS DP originally developed in OWS-3, including updates to XML Schema, WSDL, interaction diagrams and documented example requests and responses. May be developed as a profile of SOS addressing the specialized requirements and use of video sensors and data encodings. 10. Field Exercise Preparatory Plan IPR – a plan for the phased rollout of SWE Information Model and Service Model elements for use in out-year joint agency and coalition partner interoperability demonstrations and exercises.

Implementations of the following services, tools and data instances will be developed in OWS-4 SWE, tested in Technology Integration Experiments (TIEs) and invoked for cross-thread scenarios for OWS-4 demonstration events: 1. Sensor Data Center – a composition of integrated SOS, SPS and SAS service implementations for tasking of sensors, access to sensor system observation data and alerting of sensor system state changes and measurements. Implementations must support the requirements for sensor systems and protocols listed in this document. Descriptions of the sensors systems, observation offerings and services must be published to CSW implementations. 2. Sensor Observation Service (SOS) for IEEE 1451 systems – a SOS implementation that ingests and serves sensor observations from IEEE 1451 NCAP system, producing O&M Observations and supporting the requirements for SOS listed in this document. Descriptions of the sensors systems, observation offerings and services must be published to CSW implementations. 3. Sensor Observation Service (SOS) for mobile MPEG-4 video – a SOS implementation that ingests and serves sensor observations from video sensors on mobile platforms, resulting in O&M Observations and supporting the requirements for SOS listed in this document. Descriptions of the sensors systems, their observation offerings and services must be published to CSW implementations. 4. Web Processing Services (WPS) for O&M Observations – one or more WPS implementations that ingest O&M Observations from two or more SOS implementations and automatically process the results, according to an algorithm or processing chain (to be specified), into OGC Coverage and/or OGC Feature representations suitable for access and processing via WCS-T, WFS-T or other OGC Web Services. Descriptions of the services must be published to CSW implementations. 5. SWE Processing Client – A user-facing client that invokes Geo-Processing Workflows (GPW) to transform and synthesize raw observations obtained from the SOS instances listed above into processed data products for access via WFS-T and WCS-T services. 6. SWE Visualization Client – A user-facing client that provides access to multiple implementations of SOS, SAS, and CSW services for discovery of sensor resources, visualization of observation data and presentation of alerts.

4.1.5 OGC Reference Model (ORM) Viewpoints

4.1.5.1 SWE Enterprise Viewpoint

The Sensor Web Enablement thread will mature the existing set of SWE work items to enable the federation of sensors, platforms and management infrastructure into a sensor enterprise. A SWE enterprise will enable the discovery and tasking of sensors as well as the delivery of sensor observations regardless of sensor type and controlling organization. SWE brings geospatial web services interoperability to the

Page 18 Due Date: May 5, 2006 Annex B: OWS-4 Architecture diverse plug-and-play sensor hardware developments. 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.

4.1.5.1.1 Enabling Sensor Webs

The concept of operations for the SWE Framework is to enable the deployment and integration of distributed self-describing arrays of network-linked sensors and their supporting network-centric services. These sensors and services will be integrated through common information models, XML encodings of those models and well-defined service interfaces. This framework will make sensor observations available for use in value-added processing chains and for exploitation by users on workstations, web browsers and mobile devices. Catalog services and SWE Framework discovery metadata for platforms, sensors observations and services will allow for the construction of ad-hoc sensor processing chains on a national scale.

The SWE architecture must be scaleable to nationwide deployment. Scalability techniques include but are not limited to: • Nodes with varying functionality extending from sensors to web services • Message payloads designed considering limited bandwidth connections • In-network processing to eliminate bottlenecks at aggregating servers • Automatic registration of new sensors installations • Observatory nodes focused on a context but coordinating with other nodes

It is anticipated that the SWE architecture will enable a single web service node to provide access to 10s or 100s of gateway nodes, with each higher-level gateway node providing access to multiple orders of magnitude more numerous sensors. OGC SWE will interface with numerous sensor community architectures to enable this scalability.

Figure 2. Sensor Web Enablement Concept (courtesy ORNL)

Page 19 Due Date: May 5, 2006 Annex B: OWS-4 Architecture

Most sensors have a limited capacity to support computing and communication functions. It is not feasible to expose these components directly as web resources. SWE provides a three tiered approach to this problem. The first tier provides standards for integrating small footprint sensors to a Network Node (sometimes called a “gateway”) that can handle the computation and communication needs for a number of sensors. The second tier integrates Network Nodes through a local network environment where Web Services and related technologies can play a role in sensor system interoperation and data exchange. In the third tier the local network environment is exposed to larger networks, typically through Web Services. From there the sensor observations are available for use by a much larger population of analysts and decision makers.

4.1.5.1.2 Sensor Operations and Management

There is no common model for managing sensors. Some sensors, such as a thermometer, have no management functions. Others, such as an airborne imaging sensor, have a very complex planning and management infrastructure. In order to bring simple and airborne sensors into the same management framework, they will be treated as the two extremes of a continuum. Simple sensors make up the low-end of this complexity continuum. Airborne sensors make up the high end. Management approaches that can support both the low and high ends should be able to handle anything in between.

4.1.5.1.2.1 “Simple” Sensors

Simple sensors include “simple” measuring devices such as strain gages, thermocouples, and accelerometers. Simple sensors may not be all that simple but are generally characterized as small devices with little computational capacity. In most cases they have no on-board management capabilities. The first opportunity for managing these sensors occurs at the Network Node where they are first integrated. The Network Node does have the computational resources to provide management capabilities. It is limited, however, by the very simple nature of the sensors themselves.

While it may not be possible to manage the sensors themselves, it is possible to manage what the Network Node does with the sensors. Basic management functions that can be provided by the Network Node include the following:

• Enable Sensor – begin accepting observations from a sensor

• Disable Sensor – stop accepting observations from a sensor

• Get/Put Sample Interval – the time interval between readings of a sensor

• Configure Alarm – do something if the sensor reading(s) exceed or fall below a certain level

• Get/Put Threshold – the level of the sensor reading that will trigger an alarm

4.1.5.1.2.2 Airborne Sensor Tasking and Acquisition

Airborne sensors represent the other end of the complexity continuum. These sensors are installed in platforms that move in both space and time. Due to the size and complexity of some most airborne platforms, the sensors themselves tend to be very complex, fewer in number and often with limited availability due to high demand. This level of system complexity can require a relatively large number of parameters to satisfy an observation collection request and manage the collection task. As a result, airborne (and spaceborne) sensors are rarely managed directly. Rather, users submit collection requests to a support team responsible for the sensor/platform package. This support team reviews the collection requests and plans the mission and collection schedule for the package in an effort to satisfy as many of the requests as possible. Figure 3 illustrates the activities required to support a typical collection request.

Page 20 Due Date: May 5, 2006 Annex B: OWS-4 Architecture

Figure 3. Activities Inside a Sensor Collection Request

4.1.5.1.3 Sensor Exploitation

Like all service oriented architectures, the fundamental pattern in SWE is publish-find-bind. SWE resources (sensors, sensor system taxonomies, services, observation offers, phenomenon dictionaries, etc) are published to catalogs which contain metadata describing those resources. Users query catalogs seeking to find resources that meet their needs. Finally the user binds their client software to the resource so that it can be used to address the users’ needs.

The basic activities for exploitation include planning, tasking and accessing sensors, involving the ability to:

1) Quickly discover sensors and sensor data (secure or public) that can meet the users needs – location, observables, quality, ability to task

2) Task sensors, when possible, to meet the users’ specific needs

3) Obtain sensor information in a standard encoding that is understandable by the user and their software

4) Readily access sensor observations in a common manner, and in a form specific to the users’ needs

Sensor data exploitation activities are further described in the OWS-3 Geo-Processing Workflow (GPW) thread.

Page 21 Due Date: May 5, 2006 Annex B: OWS-4 Architecture

4.1.5.2 SWE Use Cases

In addition to the use cases captured in Appendix C, two operational scenarios are described in this section in order to further characterize the goals of the OWS-4 SWE thread and the context for the deployment of SWE Information Model and Service Model elements.

4.1.5.2.1 Scenario 1: Sensor Alerts for Emergency Response

The context for this scenario is a tiered model (Figure 4) of the notional components and elements of emergency response operations, comprised of Field Observation and Detection Elements (e.g., geographically distributed and heterogeneous sensor systems), one or more Emergency Operation Centers (EOC), and External Emergency Planning, Response and Recovery Components comprised of local, state, national government agencies, non-governmental organizations and the general public. In this scenario, the EOC is the center tier and receives observations, indications and alerts from the sensors deployed in the Field Observation and Detection tier. The primary flow of information from the EOC to the External Emergency Planning, Response and Recovery Components is in the form of outbound alerts and warnings. These alerts and warnings are “human-readable” and generally intended for broad distribution via private networks and the Internet to a number of different supporting organizations and warning systems.

Private Local and Wireless Networks Open and Private Wide Area Many applications… Many sensors… Networks Sensor Data Incident Node / Data 1451 Commander Local Center 1451 1451 NCAP Task SPS 1451 Personnel Status Sensor Constellation EOC Raw Subscribe Decision State RawData SAS Support RawData Alert Data System Message ws1 Alerts & Router GetObservation Weather Warnings ws2 SOS Gateway Observation Business Logic ws3 GetRecord Sensor Constellation Sensors CSW DHS Record

MPG4

MPG4 MPG4 System NGO

MPG4

Sensor Constellation

Field Observation Emergency Operations Center Elements External Emergency and Detection Planning, Response & Elements Recovery Components

Figure 4. Automated processing of sensor-driven alerts

The EOC is comprised of two interoperating elements: the “EOC Decision Support System” and the “Sensor Data Node/Data Center”. The sensor systems are physically external to the EOC but connected to it via private local/wireless networks. The Sensor Data Node/Data Center element inventories sensor resources and stores unprocessed data received from bandwidth and storage-constrained sensors. Access to the sensor data (e.g., chemical/biological/radiological/nuclear/explosive, video, weather, etc) attached to the EOC is via the SWE Service endpoints for SPS, SAS, SOS and CSW. In a Service Oriented Architecture, the SWE services are the façade to the Sensor Data Node/Data Center element, providing common ways to represent sensor system resources and data as well as mechanisms for accessing the data.

Page 22 Due Date: May 5, 2006 Annex B: OWS-4 Architecture

The EOC issues requests to the SWE services for tasking sensors, subscribing to alert conditions, getting sensor observations and discovering sensor system capabilities, etc. When alarms, indications and warnings from the sensor systems are received, they are validated and verified, monitored and tracked by EOC staff and the Incident Commander using the Decision Support System. At certain points in the development of an emergency situation, the Incident Commander may issue alerts and warnings to partner agencies of the External Emergency Planning, Response and Recovery tier.

In this scenario, we seek to automate and thereby shorten the decision loop, starting from 1) the receipt of raw observations and alerts originating from sensor systems, 2) the analysis and refinement of these data into actionable information by EOC staff and the Incident Commander and 3) the dissemination of alerts and warnings to external supporting agencies and the public. The approach must be modular and extensible (i.e., not a “point solution”) and align with the scope, activities, requirements and deliverables for the SWE thread of OWS-4.

4.1.5.2.2 Scenario 2: Automated Processing of Sensor Data

The context for this scenario (Figure 5) is automated processing of sensor data for effective decision making. The goal is to eliminate or delay as much as possible the need for human interaction and interpretation of raw sensor data. The scenario begins in step 1 with the SWE client application (a notional Decision Support System), subscribing to receive “motion” alerts on a particular sensor or constellation of sensors. Next, a motion event is detected and the sensor node/gateway forwards this message to the SAS (steps 2 and 3). The SAS alerts all subscribers of this condition (motion detected) (step 4). The controller (the component of the Decision Support System that executes business logic), next interacts with the SPS to request tasking of a sensor or constellation of sensors in order to more closely inspect and verify the detected motion event (steps 5 and 6). The tasked sensors collect observations and (in this scenario) save their results in a persistent store of observations (step 7). In step 8, the application requests the SOS for observations based on, for example, a particular location, time or sensor (with this information supplied in step 4). The SOS looks up the matching observations and returns them as O&M Observations to the application (steps 9 and 10). In step 11, the application requests a specialized WPS instance to process the observation results from step 10 into a high-value information product. The WPS processes the observations to produce the results (e.g., a set of features, coverages, rendered map layers and/or a WMS Context Document) and returns the results to the application client (steps 12 and 13). The application in turn, presents the results to the decision-maker (step 14).

An alternative approach to this scenario is for the Controller functions to be handled by the SAS or by a decentralized chain of activities where the Controller functions are performed by several SWE services. OGC seeks proposals addressing variations on this use case, with the primary criteria is reducing false positives while insuring valid alerts reach human interaction.

Page 23 Due Date: May 5, 2006 Annex B: OWS-4 Architecture

1 2 3 subscribe ! ` change SAS alert! 4

5 Decision 6 task SPS submitRequest Support System

put 7 8 Controller getObservation 9 SOS observation get 10 Obs DB get 11 execute

12 WPS result 13 display Viewer 14

Figure 5. Alert-driven processing of sensor data

In this scenario, we seek to again automate and thereby shorten the decision loop. The difference in this scenario from the earlier scenario is the focus on automated sensor management and sensor data processing to produce actionable information for decision makers. The approach must be modular and extensible (i.e., not a “point solution”) and align with the scope, activities, requirements and deliverables for the SWE thread of OWS-4.

4.1.5.3 SWE Information Viewpoint

Refer to the Sensor Web Enablement Architecture Discussion Paper (OGC 06-021r1) for identification and description of key elements of the SWE Information Model.

4.1.5.4 SWE Computational Viewpoint

Refer to the Sensor Web Enablement Architecture Discussion Paper (OGC 06-021r1) for identification and description of key elements of the SWE Service Model.

4.1.5.5 SWE Engineering Viewpoint

Refer to the Sensor Web Enablement Architecture Discussion Paper (OGC 06-021r1) for identification and description of patterns for distribution and interaction with SWE architecture elements.

Page 24 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

4.2 Geo Processing Workflow (GPW) 4.2.1 Scope

The OWS-4 GPW thread brings together developments from several previous initiatives. The OWS-2 Image Handling for Decision Support (IH4DS) thread extended the baseline of OWS service types with image processing services. In OWS-3 the Common Architecture thread built on that earlier work by applying the services developed in OWS-2 to the SWE and GeoDSS environments. In OWS-3 DSS, the work on application schemas and prior work on Information Interoperability provides a basis for workflow transformation using GML Application Schemas in OWS-4. As in the Common Architecture thread of OWS-3, the GPW thread will provide the Catalog Servers for the OWS-4 Testbed. Through this effort further refinement of catalog and workflow services will be carried out, as well as investigations of the patterns for building general purpose geo-processing services.

The OGC community has accumulated a significant body of knowledge in designing, building and operating Web Services. The full potential of Web Services as an integration platform will be achieved only when applications and business processes are able to integrate their complex interactions by using a standard process integration approach. The OASIS Business Process Execution Language for Web Services (BPELWS or BPEL) formally describes a business process that will take place across Web Services in such a way that any cooperating entity can perform one or more steps in the process the same way. 4.2.2 Planned Activities

The GPW work is organized into four groups:

• UML and GML3.2 application schema development

• Producer to Customer Production Workflow

• SWE Geo-processing Workflow

• Catalog Services for OWS-4

Each of these topics are described in the following subsections.

4.2.2.1 UML and GML3.2 application schema development

OWS-3 developed the schema tailoring process for the application schema development in the decision support services thread (GeoDSS). In particular these activities were accomplished:

- Metadata describing agency application schemas to support discovery and assessment using CS-W 2.0 services based on the ebXML Registry Information Model.

- Creation of ISO 19109 Application Schemas in UML for several feature catalogues

- Derivation of the GML Application Schemas for four application schemas using the ShapeChange UML-to-GML-Application-Schema (UGAS) conversion tool

Page 25 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

- Manipulation of the GML Application Schemas using a Schema Assembly Tool

For OWS-4, these work items will be applied to additional types of features and datasets. This group of work item is intended to test the feasibility of GML application schemas based on OGC’s Geography Markup Language Version 3.2 (GML3) to encode NGA data and serve as a transfer format. This task develops GML and UML application schemas to support the NSG Feature Catalog, NGA’s Mission Specific Data (MSD) Levels 1 – 5, as well as, NGA’s Aeronautical data content to support Vertical Obstructions (VOs), Stereo Airfield Collection (SAC) and Digital Aeronautical Flight Information File (DAFIF) data. Additionally, the development of mapping tables and/or procedures for mapping NGA Aeronautical data into the FAA/EuroControls Aeronautical Information Exchange Model (AIXM) and AIXM content into NGA Aeronautical data content.

Additional topics for this work group:

• GML Applications Schemas may need to meet the requirement for handling temporal features as addressed in the next section.

• Schema Mapping and Subsetting Tool –update and enhance the Schema Mapping and Subsetting Tool developed as part of OWS3.

• Optional workflow to create application schema’s from UML models.

• Post all application schemas to OGC Network and DGIWG Portal

This work must consider Schema Tailoring and Maintenance (OWS-3 GeoDSS IPR) (05-117).

See OGC Technical Baseline section of Annex B for a note regarding the GML 3.2 document to be used in OWS-4.

4.2.2.2 Producer to Customer Production Workflow

Delivery of features from the producer to the consumer involves geo-processing to meet the consumer’s decision support needs. The OGC Web Services Architecture supports a two way Producer to Customer Production Flow. The producer to consumer process includes producing features in GML Application Schemas (as defined the prior section). OWS-4 will experiment with approaches to this delivery including the BPEL workflows using WPS services as well as the Data Aggregation Service as initial developed in OWS-3. The consumer to producer process includes feature updates from the consumer using WFS-T (Web Feature Service - Transactional)

Refinements in WFS and WFS-T will be an integral part of the NGA production process and as such needs to be evaluated as part a production scenario. WFS and WFS–T must be able to provide a GZIP capability to compress and uncompress data based on user input. Use for OGC Filter Encoding with WFS will be investigated to meet “Clip Zip, Ship, Unzip” functionality in an OWS environment.

Additional topics for this work group:

• Using BPEL create a workflow to features suitable for decision makers needs. The BPEL workflow is designed to execute several functions including use of data tailored schema then bundle and compress, GZIP, the requested data for delivery.

o Respondents should either propose a new “Clip Zip, Ship, Unzip” Service or preferably develop a workflow creating such a service by combining existing services to produce the desired behavior.

Page 26 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

• Topology Quality Assessment Service. This OWS service, perhaps implemented as a profile of WPS, shall check topological consistency of vector data to verify the quality of the data. The service shall support a sets of consistency rules that can be defined independent of the service interface. This assessment results should then be captured as dataset level metadata based on ISO 19115/19139

• Gather the different sources using a combination of WFS and WMS, including the open source data, GML data and imagery. Identification of the different sources is provided out in a Web Context Document. The analyst submits a notification to other analysts responsible for construction and security. A BPEL workflow describing the creation of the context document creation and notification should be proposed

• Address modifications needed for OWS services to handle temporal features. Develop approaches on issues relating to Temporal Filtering and Buffering. Develop approaches for storing history of feature updates using WFS-T

• Using the client and a BPEL workflow the data is bundled zipped and shipped back as an update to the WFS-T. The BPEL workflow also initiates a notification message [Web Notification Service] back to the WFS-T that an update has been sent.

• Enhance WCS with JPIP capabilities. Use JPIP and GML/JP2 to allow interactive access to JPEG 2000 compressed ‘smart’ imagery maintaining strong correlation with the support and other metadata associated with the imagery.

• GeoRSS – for use with entities within a Feature Catalog that have no geometry, some of which use the geometry of other entities evaluate and test GeoRSS within GML as a potential solution to encoding this type of information (i.e. reports, pictures, names, boundaries).

• Analysis of Oracle 10G database to store temporal aspects of features, attributes and geometries

• GML 3.2 open source client - a lightweight open source client for GML 3.2 viewing to be developed as part of the OWS-4 GeoDSS thread.

This work must consider the OGC Discussion Papers: OWS-2 IH4DS Service Chaining with BPEL, the OGC Discussion Paper on OWS-3 Imagery Workflow Experiments, and OWS-3 GML Performance Investigations.

4.2.2.3 SWE Geo-processing Workflow

This activity will require development of workflows to process observations from the SWE thread into features and coverages suitable for the decision support thread. Refer to SWE concept of operations as well as the use cases enumerated for SWE for examples of possible process steps in support. In general, in order to support the type of workflow depicted in Figure 6, proposing organizations should consider the following: • Access services o WCS and WFS access to persistent store of features o Insert data from SWE - Transactional WFS and WCS • Web Processing Service (WPS) o Profile of WPS to meet the SWE processing needs o Web Coverage Processing Services as a profile of WPS. • Service Chaining best practices

Page 27 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

o Workflow engine using BPEL o SOAP bindings for OWS services This work must consider the OGC Discussion Papers: OWS-2 IH4DS Service Chaining with BPEL, the OGC Discussion Paper on OWS-3 Imagery Workflow Experiments, and the WPS.

Figure 6 - Enterprise SWE Geo-Processing Workflow

4.2.2.3.1 WPS Interface for Image Processing Toolkit

Additional development of a WPS with the WCPS profile to accomplish interoperability with an image processing toolkit may be proposed as part of geo-processing and Feature Handling workflow activity. RFQ responses should address how the individual services will be distributed either as separate WPS's or a single WPS supporting several operations. This activity will provide a suite if operations from an image processing toolkit accessible via OGC interface. In order support the type of workflow depicted in Figure 7.

In conjunction with the WPS for Image Processing, enhance the WCS with JPIP capabilities. Use JPIP and GML/JP2 to allow interactive access to JPEG 2000 compressed ‘smart’ imagery maintaining strong correlation with the support and other metadata associated with the imagery.

Page 28 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

Figure 7 - Detailed SWE Geo-Processing Workflow

4.2.2.3.2 Use WPS to access the outputs NASA models of physical phenomena

In support of NASA's Modeling, Analysis and Prediction program (MAP '05) Intensive Analysis Hurricane project, a WMS server (http://map05.gsfc.nasa.gov/cgi-bin/viewer.cgi) was established to provide visualizations of numerical weather model data and satellite observations.

The primary data component visualized consists of the voluminous output (more than 60 GB per day) from the Goddard Earth Observing System (GEOS) incorporating the finite-volume General Circulation Model (fvGCM). The data is a result of running both the GEOS4-NCEP and GEOS5-NCEP models (GEOS 4th and 5th generation models, initialized from National Centers for Environmental Prediction). Each model runs 4 times per day, generating 6 hr forecasts for 120 hours into the future. At the completion of the MAP '05 Intensive Analysis Hurricane project, the database approached 20 TB in size.

For OWS-4, the intent is to provide the users with more control over the subsets of data that they can extract from the MAP '05 model results as well as over the final portrayal of that data. To meet that goal, the participants should evaluate the suitability of use of OGC's WPS and WCPS for filtering, processing and portraying the model results (including slices by height or by time), and to identify any enhancements to the specs to meet the desired objectives. An alternative approach should consider Coverage Portrayal Service creating a picture from data accessible from a WCS containing the model output data. Proposals must define an approach to developing a recommendation to determining a WPS/WCPS or WCS/CPS approach as a result of the testbed. The end result for the user is a WMS view of the model data. Access to the model output data will be made available by NASA during OWS-4.

4.2.2.4 Catalog Services for OWS-4

The GPW thread will provide the Catalog Servers for the OWS-4 Testbed. Deployment of Catalog Services for the Web (CSW) will be led by the GPW thread with inputs from the other threads. Each of

Page 29 Due Date: March 14, 2005 Annex B: OWS-3 Architecture the other threads will work with the GPW thread to register items in the CSW servers that the GPW thread develops. This approach is identical to the approach of a single catalog provider in OWS-3.

Emphasis will be placed on the ebRIM profile of CS/W. Of particular interest are proposals to define and implement and SOAP binding for the ebRIM profile of CS/W. Proposals should take into consideration the Discussion papers from previous OWS Testbeds addressing SOAP bindings.

The OWS-4 Catalog (CSW-ebRIM-SOAP) must register the following items:

• Services

• Data (supporting spatial, temporal, and quality and feature level metadata.)

• Application Schemas, UML and GML

• SensorML, TML schemas for specific

• Symbol encodings and SLD documents.

4.2.3 Requirements

Table 3 – Geo-Processing Workflow Requirements

1) Web Services Architecture and Workflow a) Support a producer to customer production flow to include value adding. i) b) Support SWE and Image geo-processing workflow c) Include information on BPEL workflows implemented 2) Web Coverage Service (WCS) Enhancements a) Support Transactions b) Investigate JPEG 2000 Interactive Protocol (JPIP) c) Test and Evaluation of GMLJP2 in meeting requirements for controlled imagery and scanned maps in a net-centric environment i) The JPIP standard supports interactive/dynamic presentation/navigation of the raster coverage (pixels) within the JPEG 2000 compressed data on the server. The goal of this investigation is to have all the available geospatial positioning and attributes correlated with the pixels made available to the user as they dynamically interact with the raster coverage. (GMLJP2/JPIP- enabled service) 3) Web Feature Service-Transactional (WFS-T) Enhancements a) Support for Temporal Data b) Analysis of Oracle 10G database ability to store temporal aspects of features, attributes and geometries i) Oracle 10g support to GML 3.2 with Temporal and Topology – Evaluate and test Oracle 10g

Page 30 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

database capabilities to ingest and store data provided in GML 3.2 with temporal and topology encoded. Database needs to be able to hold a past, current and future view of data (i.e. feature doesn’t exist today but will in 6 months, aero data) c) Data Clipping functionaligy for Feature data or workflow to Clip/Zip/Ship/Unzip data with existing WFS 4) Data Aggregation Service a) The Data Aggregation Service is a form of mediation service that can ingest data from two or more sources and integrate parts of each data stream into a third, customized data stream. This service is intended to complement the Schema Tailoring effort. (See: Data Aggregation Service OWS-3 Requirements and Use Cases; Stan Tillman, Intergraph Corporation James Sullins, CAST) b) WFS-T / WFS + DAS – Web Feature Service (Transactional) will be an integral part of the NGA production process and as such needs to be evaluated as part a production scenario. Web Feature Service must be enhanced to incorporate a Data Aggregation capability is required to support the implementation of the mapping tables for input and output of NGA data to and from AIXM. WFS and WFS – T must be able to provide a GZIP capability to compress and uncompress data based on user input. 5) UML and GML3.2 application schemas: This work item is intended to test the feasibility of GML application schemas based on OGC’s Geography Markup Language Version 3.2 (GML3) to encode NGA data and serve as a transfer format. This section describes the requirements for the development of GML and UML application schemas to support the NSG Feature Catalog, NGA’s Mission Specific Data (MSD) Levels 1 – 5 as well as NGA’s Aeronautical data content to support Vertical Obstructions (VOs), Stereo Airfield Collection (SAC) and Digital Aeronautical Flight Information File (DAFIF) data. Additionally, the development of mapping tables and/or procedures for mapping NGA Aeronautical data into the FAA/EuroControls Aeronautical Information Exchange Model (AIXM) and AIXM content into NGA Aeronautical data content. a) Create UML models for: i) NSG Feature Catalog ii) MSD Data Content Specifications for Levels 1-5. b) Generate GML 3.2 application schemas (in accordance with ISO 19109 and the DGIWG Profile(s) of ISO 19107 that support two-dimensional topology) for: i) NSG Feature Catalog ii) MSD Levels 1 –5 iii) NGA Aeronautical Content (1) Vertical Obstructions (2) Stereo Airfield Collection (3) Digital Aeronautical Flight Information File c) Schemas shall include metadata based on the requirements of the DoD Discovery Metadata Specification (DDMS), ISO TC/211-19139 and the DGIWG/MGCP/GeoScout/Global Metadata Profile. d) Schemas shall be capable of addressing the following requirements for: i) Attributes with complex datatypes -- the value of an attribute may be a complex multi-field data structure, including a list or array of values or structures. ii)Both entities/classes and datatypes may reference other entities/classes through associations with cardinalities and optional ordering. iii) Entities/classes that have no geometry, although all entities/classes are associated in some way to an entity/class that does have geometry. iv) Entities/classes that may have many geometries, including many uses of the same geometry, simultaneously. v) Complex Attributes such as a Timesheet (i.e. AIXM and aero Timesheets for identifying operating hours of a aero facility) vi)Topology and temporal requirements as optional components. Evaluate and incorporate

Page 31 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

recommendations of the Topology investigation effort under OWS-3 (i.e. encoding of universal face, cyclic ordering of edges around nodes) vii) Versioning of GML Application Schemas. e) The capability to ingest AIXM data content into internal environment and accordingly output their internal aero content into an AIXM structure. This will require: i) Mapping tables for AIXM data content to support internal VO, SAC and DAFIF content. ii)Mapping tables for internal VO, SAC and DAFIF content to AIXM structure. f) Respondents should consider the following complexities related to the NSG Feature Catalog. i) Attributes take on complex data types -- meaning that the value of an attribute may be a complex multi-field data structure, including a list or array of values or structures. ii) Both entities/classes and data types may reference other entities/classes through associations with cardinalities and optional ordering. iii) Some entities/classes have no geometry, although all entities/classes are associated in some way to an entity/class that does have geometry. Entities/classes may have many geometries, including many uses of the same geometry, simultaneously. iv) Overall there are extremely few entities/classes that are "self-contained", meaning that the information considered a "feature" in the past is actually distributed across multiple entities/classes. v) There is no explicit topology in the NSG FC, although topology may be used in physical implementations to meet performance requirements for certain classes of operations. vi) There are approximately 509 entities/classes in the NSG FC, 4595 associations, and on the order of 21k entity-attribute-enumerant combinations.

6) 8) Schema Mapping and Subsetting Tool – A requirement exists to update and enhance the Schema Mapping and Subsetting Tool developed as part of OWS3. This tool requires modifications to provide: a) Support to GML 3.2 b) Provide capabilities to perform functions such as calculations based on different input schema and output schema requirements (i.e. meters to feet conversions, etc.) 7) Catalog Reference Implementation for discovery and retrieval of Services, Application Schemas, and Data (spatial, temporal, and quality) a) Support for SOAP i) Develop and test a specification to enable a binding to a CS/W 2.0, ebRIM service using SOAP. ii) Develop server software or modify existing product server software to exercise the SOAP binding developed for the CS/W ebRIM service. iii) Develop client software or modify existing product client software to exercise the servers developed under (2) to bind to a CS/W ebRIM service. iv) Demonstrate the discovery of data registered to a CS/W ebRIM compliant catalog service utilizing a SOAP binding. v) Demonstrate the discovery of other OGC services registered to a CS/W ebRIM compliant catalog service utilizing a SOAP binding. b) Catalog must be enhanced to address the need to query for data content not just spatially but also temporally and qualitative. Catalog must be able to utilize a register of trusted sources as a first option in the query process and return those results prior to initiating a query search beyond those

Page 32 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

trusted sources identified in the register. This will require: c) Catalog must be able to evaluate metadata contained at the feature level (i.e. positional accuracy). d) Clipping of data for extraction (i.e. provide all data within 200 meters of “X” feature) is required. Catalog, Filter Encoding or some other service must be able to “clip” data for extraction based on specific user input. e) Catalog needs to develop capability to routinely verify as valid the locations of registered resources thereby eliminating any no longer valid resources from the query result list. f) Catalog need to be able to publish and find metadata about symbology 8) WPS with the WCPS profile to create value added services to provide the following functionality (Participants may propose against one or both sets of WPS functionality ): a) Wrap an image processing toolkit to be tested as part of geo-processing and Feature Handling workflow activity. b) Use WPS to access the outputs NASA models of physical phenomena, e.g., hurricanes. The models run every 24 hours and create a rather large output file. The WPS would provide access to the model results file. The request to the WPS would require parameters to select specific elements of the model results. The participant should evaluate if the WCPS as a profile of WPS would be the best approach to this access. (See: 06-035 Web Coverage Processing Service (WCPS) proposal for Discussion Document.) i) Model outputs may need to be persisted via a WCSb. The WCS-T would ingest WPS-Model outputs. 9) Topology Quality Assessment Service a) A requirement exists for a service to create topology for GML 3.2 encoded data as a means of verification of a certain level of data quality. This service should be automated as much as possible and implemented within a BPEL workflow that utilizes a list of feature topological requirements. The Topology service should provide a verification of success and/or level of conformance (i.e. percent of features that can properly be encoded with topology). This information should then be captured as dataset level metadata based on ISO 19115/19139).

4.2.4 Geo-Processing Workflow Use Cases

Use Case Identifier: OWS3 GPW #1 Use Case Name: Production Flow to include value adding

Use Case Domain: OWS-4 GPW Status: Draft 3/24

Use Case Description: Using the Business Process Execution Language to create a workflow to request data and imagery. The BPEL workflow is designed to execute several functions including use of data tailored schema then bundle and compress, GZIP, the requested data for delivery [new Zip, Ship, Unzip Service]. Analyst modifies and edits data based on requirements. Using the client and a new BPEL workflow the data is bundled zipped and shipped back as an update to the WFS-T. The BPEL workflow also initiates a notification message [Web Notification Service] back to the WFS-T that an update has been sent.

Actors (Initiators): GIS Analyst Actors (Receivers) Same as initiator Pre-Conditions: Post-Conditions: - User requires several types if GIS data, vector, - Modified Coverage and Vector data inserted

Page 33 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

raster, imagery. via transactional WFS and WCS - Tailored GML schemas have been created - User can create workflow or discovers existing workflow in catalog.

System Components - Web Feature Service – Transactional (WFS-T) - BPEL Engine - Sensor Observation Service - Web Map Service - Web Feature Service -- Transactional - Web Coverage Service – Transactional with GMLJP2 / JPIP - Catalog Service CS-W - Web Notification Service - New Zip, Ship, Unzip Service

Basic Course of Action: 1. Analyst queries CS-W to determine if needed BPEL document is available 2. BPEL is not available 3. Analyst uses BPEL authoring tool to express workflow 4. BPEL workflow is designed to execute several functions including use of data tailored schema then bundle and compress, GZIP, the requested data for delivery 5. Identification of the different sources is provided out in a Web Context Document. 6. (Optional) The analyst submits a notification to other analysts responsible for construction and security (Link to CAD/GIS use case?) a. (Optional ) The Analyst receives a message from the Web Notification Service that an external update is pending. b. (Optional) The analyst executes a Geospatial Digital Rights Management authority review of the pending data to verify the individual as authorized for sending updates. c. (Optional) The analyst receives back an approval message for the update authority from the GeoDRM service. d. (Optional) The analyst then executes a data quality assessment of the topological consistency of the vector data [new Topology Service] to verify the quality of the data. e. (Optional) The topology service indicates a number of breaks in the road network that require investigation. 7. Analyst pulls the data from the WFS-T converts to internal GIS for review and update. 8. Analyst updates data 9. Analyst discovers existing workflow document in CS-W for update process.

10. Using the client and a BPEL workflow the data is bundled zipped and shipped back as an update to the WFS-T. The BPEL workflow also initiates a notification message [Web Notification Service] back to the WFS-T that an update has been sent.

Page 34 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

Use Case Identifier: OWS4 GPW #2 Use Case Name: Complete Web Services Production Flow to Include Value Adding

Use Case Domain: OWS-4 GPW Status: Draft 3/24

Use Case Description: This use case is based on the same conditions and course of action as OWS4 GPW #1 described above with the exception that there is no Zip, Ship, Unzip Bundling Service providing data for offline processing.

In this use case all processing is conducted via web services, including editing The BPEL workflow is designed to execute several functions including use of tailored schemas, data modification and transactional services. Using the client and a new BPEL workflow an update to the WFS-T is posted. The BPEL workflow also initiates a notification message [Web Notification Service] back to the WFS-T that an update has been posted.

Actors (Initiators): GIS Analyst Actors (Receivers) Same as initiator Pre-Conditions: Post-Conditions: - User requires several types if GIS data, vector, - Modified Coverage and Vector data inserted raster, imagery. via transactional WFS and WCS - Tailored GML schemas have been created - User can create workflow or discovers existing workflow in catalog.

Page 35 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

the GeoDRM service. d. (Optional) The analyst then executes a data quality assessment of the topological consistency of the vector data [new Topology Service] to verify the quality of the data. e. (Optional) The topology service indicates a number of breaks in the road network that require investigation. 7. Analyst pulls data with client from the WFS-T for review and update. 8. Analyst discovers existing workflow document in CS-W for update process. 9. Analyst updates data

10. The BPEL workflow also initiates a notification message [Web Notification Service] back to the WFS-T that an update has been sent.

Use Case Identifier: OWS4 GPW #3 Use Case Name: Schema Tailoring Workflow

Use Case Domain: OWS-4 GPW Status: Draft 3/24

Use Case Description: This use case supports the creation of GML (3.1.1) application schemas (precondition to above use cases)

Actors (Initiators): Schema Creator Actors (Receivers) Same as initiator Pre-Conditions: Post-Conditions: - ISO 19109 Application Schema in UML - GML application Schema created, catalogued and stored in schema repository

System Components - BPEL Engine - UML to GML Service - Schema Repository - Catalog Service CS-W

Basic Course of Action: 1. BPEL Workflow engine orchestrates the following process: a. The UML model is converted to an XMI file b. The XMI file is published in a web-accessible schema repository c. Schema metadata is extracted as a set of DDMS resources (DDMS are a DoD metadata specification based on Dublin Core). Identification of the different sources is provided out in a Web Context Document and stored in CS-W d. Search the catalog for schemas e. Access Schema to be converted f. Convert to GML application schema g. Store GML application schema in repository h. Publish GML application schema in catalog

Page 36 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

Page 37 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

4.2.5 Deliverables

The following Interoperability Program Reports (IPRs) will be developed in the Geo-processing Workflow and submitted to the OGC Specification Program at the completion of the OWS-4 Testbed.

1) Web Services Architecture IPR: Report the enhancements begun in OWS-2 building robust service oriented architecture with service chaining and the use of SOAP, WSDL, and BPEL in Geo-Processing Web Services to support a Producer to Customer Production Flow that includes value adding. Descriptions should include information on BPEL workflows implemented. 2) WCS CR: Discuss the additions of transactional support and JPIP to allow access to JPEG 2000 compressed ‘smart’ imagery maintaining strong correlation with the support and other metadata associated with the imagery. 3) WFS-T CR: Report on issues relating to Temporal Features and adding GZIP 4) Filter Encoding CR: Report on issues relating to Temporal Filtering and Buffering 5) GMLJP2 CR: as needed 6) GML Application Schemas IPR: 7) CS/W Profile(s) CR 8) Web Notification Service IPR: Discuss role in service chaining and workflow 9) WFS on Oracle 10G database IPR : Analysis of Oracle 10G database to store temporal aspects of features, attributes and geometries for access using WFS 1.2 and GML 3.2. 10) Topology Quality Assessment IPR: Discuss new service for checking topological consistency of vector data to verify the quality of the data. 11) WPS IPR: use of Web Processing Service and profiles in support of the various uses of WPS in GPW thread 12) Workflow Best Practice IPR

Implementations of the following services, tools and data instances will be developed in OWS4-thread, tested in Technology Integration Experiments (TIEs) and invoked for cross-thread scenarios for OWS-4 demonstration events:

1) WFS-T: Temporal, FE,GZIP 2) WCS-T: GMLJP2, JPIP 3) CS/W ebRIM SOAP binding 4) WPS/WCPS to include WPS wrapped image toolkit 5) WPS or CPS approach for NASA Models access 6) WNS – Web Notification Service; a capability is required to automatically generate an email notification to a pre-defined point of contact with responsibility for an area of interest when an update to that area has occurred. A number of possible solutions (WNS, BPEL, GeoRSS) relate to the requirement evaluate and implement the best solution. 7) BPEL workflow engine 8) GML Application Schemas - Post all application schemas to OGC Network and DGIWG Portal 9) UML Models 10) UGAS Tool updates

Page 38 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

11) Schema Assembly Tool –update and enhance the Schema Mapping and Subsetting Tool developed as part of OWS3 12) Data Aggregation Service 13) SOAP Bindings for WMS, WFS, WCS

4.2.6 OGC Reference Model (ORM) Viewpoints

4.2.6.1 Geo-Processing Workflow Enterprise Viewpoint

The OGC community has accumulated a significant body of expertise in designing, building and operating Web Services. The full potential of Web Services as an integration platform will be achieved only when applications and business processes are able to integrate their complex interactions by using a standard process integration approach. The Business Process Execution Language for Web Services (BPELWS or BPEL) formally describes a business process that will take place across Web Services in such a way that any cooperating entity can perform one or more steps in the process the same way.

4.2.6.2 Geo-Processing Workflow Information Viewpoint

This viewpoint explains the data models in the system: what the system needs to know specific to this thread

4.2.6.2.1 GML Application Schema development

Relevant Specifications: Schema Tailoring and Maintenance (OWS-3 GeoDSS IPR) (05-117).

4.2.6.2.2 BPEL

Relevant Specifications: OASIS Web Services Business Process Execution Language Technical Committee BPEL4WS 1.1

The Business Process Execution Language for Web Services (BPEL4WS or BPEL for short) defines a notation for specifying business process behavior based on Web Services. It is a standard promoted by Microsoft, IBM, Siebel, SAP and BEA for orchestrating discrete services into end-to-end business processes. Processes defined in BPEL can export and import functionality by using Web Service interfaces exclusively. BPEL provides a language for the formal specification of business processes and business interaction protocols. By doing so, it extends the Web services interaction model and enables it to support business transactions. BPEL defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intra-corporate and the business-to-business spaces.

Business processes can be described in two ways. Executable business processes model actual behavior of a participant in a business interaction. Business protocols, in contrast, use process descriptions that specify the mutually visible message exchange behavior of each of the parties involved in the protocol, without revealing their internal behavior. The process descriptions for business protocols are called abstract processes.

4.2.6.2.3 GML 3.2

Relevant Specifications: OpenGIS® Geography Markup Language (GML) Encoding Specification

Page 39 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

The Geography Markup Language (GML) is an XML encoding for the transport and storage of geographic information, including both the geometry and properties of geographic features.

4.2.6.2.4 GML in JPEG 2000 for Geographic Imagery Encoding Specification (GMLJP2)

Relevant Specifications: : OpenGIS® GML in JPEG 2000 for Geographic Imagery Encoding Specification (GMLJP) 05-047r3

The GML (Geography Markup Language) is an XML grammar for the encoding geographic information including geographic features, coverages, observations, topology, geometry, coordinate reference systems, units of measure, time, and value objects. JPEG 2000 is a wavelet based encoding for imagery that provides the ability to include XML data for description of the image within the JPEG 2000 data file. This specification defines the means by which GML is to be used within JPEG 2000 images for geographic imagery. This includes the following: · Specification of the uses of GML within JPEG 2000 data files. · Packaging mechanisms for including GML within JPEG 2000 data files. · Specific GML application schemas to support the encoding of OGC coverages within JPEG 2000 data files.

4.2.6.2.5 Catalog ebRIM Profile

Relevant Specifications: OpenGIS® Catalog Services – ebRIM Profile Discussion Paper

The OGC Catalogue Services 2.0 specification (OGC 04-021) establishes a framework for implementing catalogue services that can meet the needs of stakeholders in a wide variety of application domains. This application profile is based on based on EbXML EbRIM ISO/TS 15000-3.

4.2.6.2.6 Web Map Context

Relevant Specification: OpenGIS® Implementation Specification (WMC) 1.1 05-005 2005-05-03

This document is a companion specification to the OGC Web Map Service Interface Implementation Specification version 1.1.1 [4], hereinafter "WMS 1.1.1." WMS 1.1.1 specifies how individual map servers describe and provide their map content. The present Context specification states how a specific grouping of one or more maps from one or more map servers can be described in a portable, platform-independent format for storage in a repository or for transmission between clients..

4.2.6.3 Geo-Processing Workflow Computational Viewpoint

This viewpoint is deals with how the system is assembled from application components and program interfaces

4.2.6.3.1 Workflow Chaining Service (WfCS)

Relevant Specifications: OWS 2 Service Chaining with BPEL Discussion Paper (OGC 04-078)

The Workflow Chaining Service (WfCS) executes workflow processes and correlates and coordinates synchronous interactions into collaborative and transactional business flows. It is an infrastructure service for modeling, connecting, deploying and managing and executing business processes.

For each process, the WfCS takes a BPM script (i.e., BPEL “flow”) that describes the workflow or processing chain to be executed, a WSDL document (without binding information) that describes the

Page 40 Due Date: March 14, 2005 Annex B: OWS-3 Architecture interface that the process will present to clients (partners in BPEL terms), and WSDL documents that describe the service instances that the process may invoke during its execution. From this information, the process is made available as a Web Service. A WSDL file that describes the process's interface may be retrieved from the WfCS at run-time.

As described in ISO 19119, there are many possible approaches to composing chains of processing services into aggregate or compound service components. General patterns can be used to describe these approaches based on, for example, the visibility of the services to the user (or client application) as well as the difference in how control of the services is managed. Using these criteria, the following service chaining patterns include (Figure 2):

1. User defined (transparent) chaining: the client application manages the workflow and control of the chain is exclusively with the user of the client application

2. Workflow-managed (translucent) chaining: in which the client application invokes a Workflow Management service that controls the chain and the user is aware of the individual services; a workflow service controls the chain execution, perhaps with oversight by the human user of the client application

3. Aggregate service (opaque): in which the client application invokes a service that carries out the chain, with the user having no awareness of the individual services; the aggregate service exclusively performs the control function with no visibility by the client application. [OWS 2 Service Chaining with BPEL Discussion Paper (OGC 04-078]

2 1

Figure 8 - Service Chaining Patterns

4.2.6.3.2 JPIP

Page 41 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

Relevant Specifications: : JPEG 2000 Part 9, JPIP (interactive protocols and API ) (http://www.jpeg.org/jpeg2000/j2kpart9.html)

The main component of Part 9 is a client-server protocol called JPIP. JPIP may be implemented on top of HTTP, but is designed with a view to other possible transports. To facilitate its deployment in systems with varying degrees of complexity, JPIP handles several different formats for the image data returned by the server: these include ordinary image formats, such as complete JPEG or JPEG 2000 files, and two new types of incremental "stream" that use JPEG 2000's "tiles" and "precincts" to take full advantage of its scalability properties. JPIP also supports both stateless and stateful modes of operation, enabling sophisticated cache-modeling to eliminate the redundant transmission of data.

JPIP provides selective access to the image metadata that may be contained within JPEG 2000 files. Although Part 9 is focused on the application of technology from Part 1, including the JP2 file format, it does support some file format extensions from Part 2. A mechanism has also been provided for selection from amongst multiple codestreams in JPX (Part 2), MJ2 (Part 3) and JPM (Part 6) files. Potentially this could be applied to any file format containing images, not just to the JPEG 2000 family of file formats.

Part 9 also defines some new file format boxes for indexing JPEG 2000 files and codestreams. The indexes are based on the same concepts as the JPIP stream types, and may be useful in server implementations of JPIP. They are also intended, however, to enable random access to JPEG 2000 files in the absence of JPIP. For example, the byte-range requests built into an unmodified HTTP (version 1.1) server could be used for this purpose.

4.2.6.4 Geo-Processing Workflow Engineering Viewpoint

This viewpoint contains information on how the components from the computational viewpoint are implemented

Page 42 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

Client Image

StartFlow EndFlow

GetCoverage Transform WfCS

Invoke

Image Image WCS WPS WPS

Figure 9 - Example Geo-Processing Workflow

4.3 Geo-Decision Support Services (GeoDSS) 4.3.1 GeoDSS Scope

4.3.1.1 Problem and Objectives

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:

• How to use the source of information if the available information is not organized in a useful format?

• How to search/identify sources that are cataloged for a user community which I don’t recognize?

• How to integrate information and sources into a manageable work environment?

4.3.1.2 Planned Activities

Page 43 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

There are six planned activities in GeoDSS:

• Portrayal

• GeoDSS Clients

• Coverage Portrayal Service

• Multilingual services

• WFS-Files and WFS-Database

• WMS Tiled

4.3.1.2.1 Portrayal

The portrayal work item will extend and refine the symbology management work performed in OWS-3 and described in OWS-3 IPR 05-112r1 Symbology Management, which uses a Catalog to store, search and retrieve in the format described in 05-077 Symbology Encoding (SE). Also required is work to implement and refine Feature Portrayal Service work performed in OWS-3 and described in IPR 05-110 Feature Portrayal Service.

Portrayal work will also involve developing an SLD (Styled Layer Descriptor) profile for WMS 1.3 and further development of symbol encodings in either SLD or SE format for GeoSym.

4.3.1.2.2 GeoDSS Clients

In this work item, three decision support clients will be developed:

• An Integrated Client for multiple OGC-compliant services (Integrated Client)

• A standalone, relatively lightweight, open source GML visualization client (GML OS Client)

• A 3D CAD data visualization client (3D Client)

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 development of a this client will build on the results of the OWS-3 Integrated Client for Multiple OGC-compliant Services (OGC Discussion Paper, document 03-021). The Integrated Client is defined as a software application that provides common functionality for the discovery, retrieval, and handling of data from WMS, WFS, WFS- T, WCS, SPS, SOS, GeoVideo, FPS, GeoRSS and WMS Tiled (described below). Search is implemented via support for the CS/W ebRIM profile, and state is handled by support for WMS Context and/or OWS Context documents. The Integrated Client will extend the OWS-3 Integrated Client to include the services developed and enhanced through OWS-4.

One major new feature of the Integrated Client is to support multiple languages. The specific services that will support this multilingual feature, as well as the implementation details, will be determined in the course of the project.

The GML OS Client is designed for distribution with GML 3.2 data to provide an simple, self-contained map and data viewer and editor. This client shall support search via CS/W and also provide mapping and editing services for WMS, WFS and WFS-T interfaces.

Page 44 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

The 3D Client will access CAD data such as CityGML being retrieved via the WFS 1.2 draft interface and IFC XML coming from a CAD Model Service, which will be defined in the work of the CAD/BIM thread. Sensor data will also be visualized in this client.

4.3.1.2.3 Coverage Portrayal Service

As described in OGC IPR document 02-019r1, “OWS1 Coverage Portrayal Service,” The CPS links together WMS clients and WCS services, using SLD as a service language. The CPS interfaces are slight extensions or restrictions of the corresponding WMS interfaces. The objective of this work item is to refine this prior work into a service that fits within the current OWS architecture with particular attention to the Feature Portrayal Service (FPS). As with the FPS, the CPS should be viewed as an intermediate service that facilitates the ability of a WMS client to flexibly portray coverage data without becoming a full- fledged Web Coverage Services client. More specifically, a CPS client should resemble an FPS client in that while the request mechanism may require an in-depth ability to understand the data model of a coverage, and the coverage styling capabilities of SLD, the response from a CPS should be much like that of a WMS.

4.3.1.2.4 Multilingual services

This work item seeks to internationalize OGC services to support XML requests and responses in multiple languages. In OWS-4 participants will implement multilingual capabilities in the WMS 1.3 and WFS 1.2 services and recommend changes to OWS Common to support multilingual services and XML encoding formats. Implementation details will be explored in the course of the project, but are expected to include the following areas:

• The ability of the server to identify the language used in XML documents by supporting the xml:lang attribute as per the W3C XML Language Specification version 1.0 [http://www.w3.org/TR/REC-xml/#sec-lang-tag]. The xml:lang attribute can be applied to the document root if the document contained a single language, or to any element within the document to allow it to include multiple languages in the same document.

• The ability for a server to publish the list of languages it supports via the GetCapabilities response, perhaps by using the ISO codes as:

en-CA fr-CA

• The ability of a client to specify the language of choice via an optional LANGUAGE parameter that takes the values of one of the language codes advertised by a service’s Capabilities, e.g.: http://my.site.com/wms.cgi?VERSION=1.1.0&LANGUAGE=en-CA&REQUEST=GetMap&…

4.3.1.2.5 WFS-Files and WFS-Database

These services will greatly expand the ability for commonplace enterprise IT infrastructures to participate in a spatial data infrastructure by targeting software platforms that already exist.

One work item is to develop a service for a minimal WFS, called WFS-Files—in essence a Web Feature Service with a target implementation on a file-based platform, such as a Web server with no database or geospatial support, a file server, or a WebDAV server.

Page 45 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

The specific features of this service will be determined in the project, but it is envisioned that this profile will not deviate from the WFS 1.2 draft implementation specification, except in its elimination of most all optional features. For example the following features may not be supported:

• Filter encoding

• Bounding box constraints

• Anything other than retrieval of all features

• Coordinate transformation

• Sophisticated version negotiation

The second work item will develop a service, called WFS-Database, for a WFS with a target implementation on a database-driven Web platform, such as a content management system with no geospatial support. The specific features of this test suite will be determined in the project, but it is envisioned that this requirement will not deviate from the WFS 1.2 draft implementation specification, except in its elimination of many optional features. For example the following features may not be supported:

• Filter encoding

• Coordinate transformation

These interfaces shall be developed using WFS 1.2 draft and GML 3.2.

4.3.1.2.6 WMS Tiled

OWS-4 seeks to investigate the feasibility of implementing a tiling scheme for WMS. Currently, the architecture of WMS allows for complete flexibility in the characteristics of the map image requested. This architecture implicitly assumes that the map image is being generated on a per-request basis, which results in a heavy load on any server supporting the WMS interface. This work item will define an architecture by which WMS implementations may cache map image tiles at predetermined scales and sizes, making the fulfilment of a WMS-Tiled request a simple matter of returning the correct map image tile. Realizing this requirement may require constraining the normal parameters of a WMS to limit the coordinate reference systems supported and having a certain number of fixed scales that may be requested. This work is also expected to require the development of a global tiling scheme to ensure interoperability of WMS-Tiled requests across implementations.

4.3.2 Requirements Feature Portrayal Service 1) Build on the Feature Portrayal Service work from OWS-3: a) Ingesting feature data from two or more WFS b) Support user-selected symbolization of the features using the techniques developed through OWS-3 and the Emergency Mapping Symbolization (EMS) initiative c) Render the symbolized features for viewing through a web browser 2) Refine and deploy a Registry for SLD documents.

Page 46 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

3) Develop SLDs and/or SEs mapping the GeoDSS developed application schemas to GeoSym. 4) Register the SLD and SE elements in the Registry. GeoDSS Integrated Client 1) The GeoDSS client shall be able to access and utilize the following OGC Web Services: a) WMS – Web Map Service including WMS 1.3.0 and WMS 1.1.1 b) WFS – Web Feature Service including WFS 1.2 draft with transactions and translation c) WCS – Web Coverage Service 1.0 and 1.1 draft d) Coverage Portrayal Service e) FPS - Feature Portrayal Service from OWS-3 f) CS/W – Catalog Service for the Web, ebRIM profile with SOAP bindings, with special attention to searches having spatial, temporal and quality indicators (positional accuracy) g) Sensor –Sensor Observation Service, Sensor Planning Service, Sensor Alert Service h) WNS – Web Notification Service i) OpenLS Tracking service j) GeoVideo Portrayal Service k) GeoRSS l) WfCS – Workflow Chaining Service m) WMS Tiled 2) In conjunction with the Geoprocessing Workflow thread, support WFS with compression a) Extend WFS request to support requesting data in GZip format b) Support on-the-fly decompression of WFS response in GZip format c) Develop and implement a data synchronization capability, wherein data is requested from a WFS repository and cached locally in the client for online and offline use. Updates may be requested periodically to replace or add to the local data store. 3) The client shall be able to portray imagery in the JPEG2000 interactive protocol (JPIP) format 4) SOAP services WMS, WFS, WCS 5) The GeoDSS client will be capable creating a OWS Context Document to capture and share the results of an analysts progress GML OS Client 1) Read local GML data using a default Context document on launch 2) The GML OS Client shall be able to access and utilize the following OGC Web Services: a) GML 3.2 b) WMS 1.3 c) WFS 1.2 3D Client 1) Access CityGML being retrieved via the WFS 1.2 interface

Page 47 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

2) Access IFC XML coming from a CAD Model Service

4.3.3 Deliverables The following Interoperability Program Reports (IPRs) will be developed in OWS4-GeoDSS and submitted to the OGC Specification Program at the completion of the OWS-4:

1) GeoDSS Integrated Client IPR 2) GeoDSS OS GML Client IPR 3) GeoDSS 3D Client IPR 4) Symbology Management Services IPR 5) Multilingual OWS IPR 6) OWS Common Change Request (to support multilingual OWS ) 7) Coverage Portrayal Service IPR 8) WFS-File and WFS-Database Services IPR 9) WMS Tiled IPR 10) GeoRSS Change Request

Implementations of the following services, tools and data instances will be developed in OWS4-GeoDSS, tested in Technology Integration Events (TIEs) and invoked for cross-thread scenarios for OWS-4 demonstration events:

1) GeoDSS Integrated Client 2) GML 3.2 OS Viewer Client 3) 3D Visualization Client 4) Feature Portrayal Service 5) Coverage Portrayal Service 6) SLD/SE registry documents (These items will be made accessible using a CS/W developed in the GPW thread) 7) SLD/SE documents for GeoSym 8) WMS – Multilingual 9) WFS – Multilingual 10) WMS Tile Service 11) WFS-File Service 12) WFS-Database Service

4.3.4 OGC Reference Model (ORM) Viewpoints

4.3.4.1 GeoDSS Enterprise Viewpoint

Page 48 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

The GeoDSS Enterprise Viewpoint captures the capabilities that must be present in support of Geospatially enabled Decision Support activities and operations. The capabilities identified here describe the requirements to be met by the OWS computation and information models. The Enterprise Viewpoint is defined by a high-level system concept and use-cases. The system concept illustrates the operational setting, major system components and key interfaces. The use cases provide descriptions of the behavior of the system from the point of view of enterprise users.

Use Case Identifier: OWS4 GeoDSS #1 Use Case Name: DSS Analyst Use Case Domain: OWS-4 GeoDSS Status: Draft 04/02/06 Use Case Description: An analyst uses a decision support client application to gather information about an event. Actors (Initiators): Analyst (A) Actors (Receivers) Same as initiator Pre-Conditions: Post-Conditions: - An event has taken place that requires a All available relevant information has been coordinated response by non-local resources reviewed and a decision made. - The available information resources have been cataloged, and pertinent catalogs are known System Components - see section 4.3.2 Requirements— GeoDSS Integrated Client Course of Action: 1. A activates the decision support system (GeoDSS Integrated Client) 2. A queries catalog to see what feature data is available 3. The catalog accepts the query and sends a result set 4. A selects data sets and accesses the data from various WMS, WFS, WCS services 5. A selects symbology to display the features 6. A reviews feature data 7. A queries catalog to see what imagery is available 8. The catalog accepts the query and sends a result set 9. A edits feature data 10. A sends feature data changes to a QA/QC service 11. A saves the portrayal of the situation to a Context document

Use Case Identifier: OWS4 GeoDSS #2 Use Case Name: 3D Analyst Use Case Domain: OWS-4 GeoDSS Status: Draft 04/02/06 Use Case Description: An analyst uses a client application to view 3D CAD data. Actors (Initiators): Analyst (3DA) Actors (Receivers) Same as initiator Pre-Conditions: Post-Conditions: - The available information resources have been All available relevant information has been cataloged, and pertinent catalogs are known reviewed and a decision made.

Page 49 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

System Components - see section 4.3.2 Requirements— 3D Client Course of Action: 1. 3DA activates the 3D Client 2. 3DA queries catalog to see what feature data is available 3. The catalog accepts the query and sends a result set 4. 3DA selects data sets meeting specific format requirements, such as CityGML and/or IFC XML 5. 3DA selects symbology to display the features 6. A views feature data

Use Case Identifier: OWS4 GeoDSS #3 Use Case Name: GML Viewer Use Case Domain: OWS-4 GeoDSS Status: Draft 04/02/06 Use Case Description: A non-specialized professional uses a client application to view GML feature data. Actors (Initiators): User Actors (Receivers) Same as initiator Pre-Conditions: Post-Conditions: - GML data in well-defined application schemas GML data is viewed and explored. have been packaged with the client System Components - see section 4.3.2 Requirements— GML OS Client Course of Action: 1. User activates the GML OS Client 2. Using a pre-packaged Context document, various local data sets are immediately portrayed in the client 3. User zooms, pans, and queries the data in view 4. User performs point-and-click feature queries of local GML data 5. User performs data searches using a built-in, predefined CS/W catalog 6. User adds remote WMS, WFS and WCS data to the view 7. User saves the state of the session into a new Context document

Use Case Identifier: OWS4 GeoDSS #4 Use Case Name: Multilingual Service Access—Success Use Case Domain: OWS-4 GeoDSS Status: Draft 04/02/06 Use Case Description: A client negotiates the use of a specific language with a multilingual service. Actors (Initiators): User Actors (Receivers) Same as initiator Pre-Conditions: Post-Conditions: - Language support enabled web service Using the specified language operation requests are made and responses are received and consumed. - Language support enabled client

Page 50 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

System Components - see section 4.3.2 Requirements— GeoDSS Integrated Client Course of Action: 1. User activates the decision support system (GeoDSS Integrated Client) 2. User issues a getCapabilities request in English 3. Based on the response, User chooses a different language supported by the service 4. User issues a getCapabilities request in that language 5. Further requests to the service include the LANGUAGE parameter and responses are in that language

Use Case Identifier: OWS4 GeoDSS #5 Use Case Name: Multilingual Service Access—Failure Use Case Domain: OWS-4 GeoDSS Status: Draft 04/02/06 Use Case Description: A client fails to use their preferred language with a multilingual service. Actors (Initiators): User Actors (Receivers) Same as initiator Pre-Conditions: Post-Conditions: - Language support enabled web service After negotiation, a less-prefereed language is used in operation requests and responses. - Language support enabled client System Components - see section 4.3.2 Requirements— GeoDSS Integrated Client Course of Action: 1. User activates the decision support system (GeoDSS Integrated Client) 2. User issues a getCapabilities request in a non-English language 3. Service responds with Capabilities containing all supported languages, but not the one requested 4. Based on this response, User selects a supported language and issues next request in that language

4.3.4.2 GeoDSS Information Viewpoint

4.3.4.2.1 Decision Context

Geospatial Information is used to support pragmatic decisions that address the goals of multiple stakeholders. Key to effective decisions is identifying the context in which the decision applies. The context determines what information is relevant to the decision. Geo-Decision Support Services aid the decision analyst in identifying and preparing relevant information to the decision context.

Geo-DSS enables the geographic information collected from different sources to become an integrated digital representation accessible for critical decisions.

Classes of Information that are relevant to Geo-DSS include the following:

• Geographic Features, including

Page 51 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

- Discrete features - Coverages - Observations including Imagery - 3D CAD data • Application Schemas for Information Community • Portrayal of Geographic Features - Symbology - Feature portrayal - Coverage portrayal - Portrayal of Geo-video • Context containers The remainder of this Information Viewpoint summarizes the key information types for OWS-4.

4.3.4.2.2 Styles and Symbology

Relevant Specifications: Symbology Management (OGC 05-112r1) OGC Feature Portrayal Service (OGC 05-110) Symbology Encoding Implementation Specification (OGC 05-077) Style Management Services (SMS) Specification (OGC 02-046) The OGC OWS-3 initiative developed an architecture, information models and services needed to allow users to select the styling and symbolization to be used for displaying geospatial features. The major components defined by OWS-3 are represented in the Style Management Services (SMS) UML class diagram (Figure 10). OWS-4 will extend and refine this work to move symbology management services towards maturity. The symbol sets supported will include GeoSym.

Page 52 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

<> <> Symbology Editor or <> Portrayal Service <>

<> <> <>

Symbol Registry Style Registry Feature Type WFS Feature Collection Registry Registry

Symbol Metadata Style Metadata Repository Repository Feature Feature Collection Collection Metadata

Symbol Repository Style Repository

0..1 Feature Feature Symbol Feature Type Type 1..* Style 1..*

Style Management Service

Figure 10 - UML Notational Form of SMS System Architecture

4.3.4.2.2.1 Symbol Metadata Record

The Symbol Metadata Record is an object describing Symbol Objects. The metadata requirements of Symbols are analogous to those of Style Objects.

4.3.4.2.2.2 Symbol Object

Symbols are pieces of graphics used by Portrayal Services to represent geographic features on a map. Symbols are the instructions for how vector and raster graphics are to be portrayed. Vector graphic symbols may have properties such as geometry, graphic, fill, color, stroke, font, orientation, size, opacity etc. Raster graphic symbols may have properties such as opacity, RGB channel selection, color map, shaded relief, contrast enhancements, etc.

Symbols may be represented as a set of graphical instructions using encoding languages such as SLD, SVG or CGM or as a raster graphic (image file) encoded in one of a set of standard formats (e.g., JPG, PNG, GIF, CGM). In principle, any number of Symbol representations may be used with the SMS architecture. One set of Symbol Objects will be created and exercised under OWS-4—GeoSym.

4.3.4.2.2.3 Style Metadata Record

Page 53 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

A Style Metadata Record is an object describing Style Objects. The metadata includes descriptive information such as titles, keywords and contact information (such as defined in ISO 19115/19117/19119 specifications).

Each Style Object must have a name that can be used as a primary key for identification and access. In addition to referencing this style name, Style Metadata Record objects may also contain references for all of the Feature Types to which a style can be applied. This allows a SMS Client, after locating feature styles, to more easily locate and access Style Objects

4.3.4.2.2.4 Style Object

A Style Object is a description of how to portray a type of feature or coverage in a particular way. Styles are used by Portrayal Services. Styles can specify conditions that allow Features to be portrayed based on the value of a Feature Object’s type and its geometric and non-geometric attributes. Styles are composed of one or more Symbols that may be stored with the Style Object or separately managed by SMS. Associations of Symbol Objects with geographic Feature Objects are explicitly given through Styles.

In principle, any number of style representations may be used with the SMS architecture. The primary representations, however, are based on the OGC Symbology Encoding (SE) and Styled Layer Descriptor Implementation Specifications (SLD).

4.3.4.2.3 IFC XML and CityGML

Relevant specifications: IFC/ifcXML Specifications (http://www.iai-international.org/Model/IFC(ifcXML)Specs.html)

CityGML (http://www.citygml.org/)

Realization of the 3D Client will require the portrayal of information encoded in IFC XML and CityGML formats. Full details of this support will be developed during the course of OWS-4.

For more information see CAD/GIS/BIM Information Viewpoint.

4.3.4.2.4 GML 3.2

Relevant specifications: OpenGIS® Geography Markup Language (GML) Encoding Specification)

The default feature encoding format for OWS-4 is GML 3.2. A number of GML profiles may be supported, including but not limited to MSD levels 1-5, GeoRSS, AIXM, NSG feature catalog, and GGMA implementation profile for Aero (DAFIF content) and Hydro.

4.3.4.3 GeoDSS Computational Viewpoint

4.3.4.3.1 Overview of GeoDSS

Page 54 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

Geospatial Knowledge Base Predictions

Policy Decision Decisions Information Support Services Management Decisions

Observations Geospatial Features

Data Data Sensing Surveying

Figure 11: Decision Support based on Geospatial Features

4.3.4.3.2 Style and Symbol Management Services

Relevant Specifications: Symbology Management (OGC 05-112r1) OGC Feature Portrayal Service (OGC 05-110) Symbology Encoding Implementation Specification (OGC 05-077) Style Management Services (SMS) Specification (OGC 02-046) The OGC OWS-3 initiative developed an architecture, information models and services needed to allow users to select the styling and symbolization to be used for displaying geospatial features. The major components defined by EMS-1 are represented in the Style Management Services (SMS) class diagram (Error! Reference source not found.). OWS-4 will leverage this work to enhance the repository of symbology available for user-selected symbolization via the Feature Portrayal Service (FPS). The symbol sets supported will include GeoSym.

4.3.4.3.2.1 Symbol Catalog

Relevant Specifications: OpenGIS® Catalog Service Implementation Specification, v 2.0

The Symbol Catalog provides the basic mechanism for SMS clients to publish and discover essential operational information about Symbol Objects. It also provides the ability to manage (create, read, update and delete) and search for Symbol Metadata Records. This catalog will be tested and refined.

4.3.4.3.2.2 Symbol Repository

Relevant Specifications: OpenGIS® Web Object Service Discussion Paper (OGC 03-013)

The Symbol Repository provides storage and management of the Symbol Objects. Symbol Repositories provide the ability to create, read, update and delete Symbol Object instances in a repository. They also allow SMS Client objects to publish and access Symbol Object instances.

4.3.4.3.2.3 Style Catalog

Relevant Specifications: OpenGIS® Catalog Service Implementation Specification, v 2.0

Page 55 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

The Style Catalog provides the basic mechanism for SMS Client objects to publish and discover essential operational information about Style Objects. Allows the ability to manage (create, read, update and delete) and search for Style Metadata Records. This catalog will be tested and refined.

4.3.4.3.2.4 Style Repository

Relevant Specifications: OpenGIS® Web Object Service Discussion Paper (OGC 03-013)

The Style Repository provides storage and management of the Style Objects. Style Repositories provide the ability to create, read, update and delete Style Object instances in a repository. They also allow SMS Client objects to publish and access Style Object instances.

4.3.4.3.3 GeoDSS Integrated Client

Relevant Specifications: OpenGIS® Integrated Client Discussion Paper

The GeoDSS Integrated Client is an extension of the OWS Integrated Client (OGC Discussion Paper, document 05-116) developed in OWS-3. The OWS-3 Integrated Client was defined as a software application that provides common functionality for the discovery, retrieval, and handling of data from WMS, WFS, WCS, FPS, CS/W, SOS, SPS, GeoVideo and workflow management. The OWS-4 client will expand on the OWS-3 Integrated Client by adding client support for the services developed and enhanced through OWS-4. These enhancements will include support for:

• on-the-fly decompression of WFS response in GZip format • Workflow Chaining Service (WfCS) • GeoRSS • OpenLS Tracking Service

4.4 GeoDRM and Trusted Geoservices

GeoDRM or Geospatial Digital Rights Management is defined in the OGC GeoDRM Reference Model as the packaging, distributing, controlling and tracking of geospatial content based on rights and licensing information. More generally it can be taken to cover a broad spectrum of capabilities and underlying technologies supporting description, identification, trading, protecting monitoring and tracking of all forms of rights usages for both tangible and intangible (electronic) assets, including the management of rights- holders relationships. For the purpose of the OWS-4 initiative, GeoDRM consists of standards, technologies, and practices which enable interoperable trading of geospatial content to be implemented on top of OWS services. GeoDRM does not include per se, but does require and connect to capabilities for establishing trust between actors in OWS services interactions. Trust in this context focuses on control of access to services; it includes authentication of actor identities and authorization of interactions. 4.4.1 GeoDRM Scope

4.4.1.1 Problems and Objectives

After the introduction of the Web Mapping Service Specification in April 2000, important Geospatial Web and Spatial Data Infrastructure (SDI) components began to be developed. Today, in 2006, major parts of the Geospatial Web and SDI vision have become real. Implementation Specifications like the WMS, WFS, WCS, CS-W and GML can be used to build up global service-oriented and interoperable SDI’s.

Page 56 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

Interoperable software products have been developed and deployed. The concept of a SDI based on OGC components has been proven with realized SDIs at many organizational levels worldwide.

From an economic point of view, SDI provides the communication and transport mechanism for trading/selling/distributing use of spatial content. The development and implementation of business models for trading spatial data has already started. Diverse standards and technologies have been developed to facilitate trading other media; so far these are neither sufficiently functional for geospatial content nor sufficiently interoperable to support an SDI. The OGC has not yet developed specifications for interoperable trading capabilities; there is a risk that inappropriate and/or proprietary solutions could limit the capacity of SDI for serving geospatial lines of business.

The OGC GeoDRM Reference Model (RM) has been developed as an initial basis for specifications to address this need. The RM defines a license model for trading geospatial content / services, lays out a number of use cases and GeoDRM workflow roles, and begins the task of specifying GeoDRM operations. The RM focuses on license structures and decisions, leaving more generic trading elements such as discovery, negotiation, authentication, and enforcement to external protocols and implementation specifications.

The GeoDRM thread in OWS-3 (which preceded development of the RM) investigated ways in which protocol bindings for OWS services (e.g. WMS, WFS) could be extended interoperably with existing technologies to accommodate a simple “click-through” trading scenario. The GeoDRM thread in OWS-4 will investigate more involved trading scenarios with the aim of extending both the OWS-3 and RM work towards an overall OWS trading framework.

4.4.1.2 Planned Activities

4.4.1.2.1 GeoDRM Information Elements

4.4.1.2.1.1 License expression

A prerequisite for a licenced OWS service interaction is a valid licence. Sample licences will be developed which support the OWS-4 use cases presented below.

4.4.1.2.1.2 License offer

The information and establishment phases of licence management require that a provider develop and a consumer have access to the licence terms under which trading is being offered. These again will be sample documents to support the OWS-4 use cases.

4.4.1.2.1.3 License acknowledgement

An information element is required which communicates and represents the user’s acceptance of licence terms and fulfillment of licence preconditions. The acknowledgement may include or it may reference the licence itself.

4.4.1.2.1.4 License decision

This element communicates a licence decision for service authorization. It serves as input both to service authorization and to the recording of licence usage.

4.4.1.2.1.5 License usage record

Page 57 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

This element records a licenced service interaction for a number of purposes including violation documentation and implementation of licence terms such as “Peak_Hour_Limit / Peak_Day_Limit”. ”. The documentation itself does not imply a particular consequence. For example, a violation of licence terms may result in denial of access, a change to a different licence, or simply an accumulation of statistics in support of some other action.

4.4.1.2.1.6 Access control policy

Access control policy elements (e.g. “GetMap requests shall be authenticated by an appropriate x.509 client certificate from authority Y”) are required in order to implement authentication and authorization of licenced interactions, and so that licence terms can reference them.

4.4.1.2.2 GeoDRM License Lifecycle for OWS Services

An essential aspect of interoperable GeoDRM for OWS services will be development of a license “lifecycle” which enables OWS software and users to negotiate compatible approaches to each stage of license management. Phases of this lifecycle, with the service components they involve and information elements they require are shown in Figure nn and discussed below. The specific sequence of service interactions is not shown in this diagram and is somewhat dependent on the choice of architectural pattern for service implementation.

Service Information 1. Information on resources, Components Components processes, rights, and terms New License 2. Identification of principals Product Registry Identities and agents Offers 3. Negotiation / acceptance of Licence Broker Licence licence terms Acceptances 4. Licence establishment Authentication and 5. Request for service Authorization Service Lifecycle Licences 6. Validation of Licence Manager Session preconditions Requests 7. Licence decision 8. Execution of GeoDRM Gatekeeper Decisions post-conditions Effects 9. Service response OWS Service

10. Licence revocation / expiry Usage

Figure 12 - GeoDRM Licence Lifecycle with Service Components and Information Elements

4.4.1.2.2.1 Information

Page 58 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

This licence information phase combines metadata about available content and services with metadata about licence(s) under which they can be utilized. This metadata may be available from a product catalog or registry; it may also be available as a part of the service capabilities for an individual service.

4.4.1.2.2.2 Authentication

This initial licence establishment phase begins the identification of principals and agents which can be party to a licence. This activity continues throughout the lifecycle. The authentication phase covers not only identification of principals such as users and service providers, but also identification / validation of the software (instances) which are communicating on their behalf, as well as the documents which are being exchanged through the course of the interaction. Authentication also does not imply a particular technology or level of control; for example, the required user identity for Use Case #1 may be “Anonymous person making GetMap requests from a single IP address during a limited session initiated by a click-through licence terms acceptance”. The required user identity for Use Case #3 may be “unique person identified by a particular username/password combination using HTTP Basic Authentication”.

4.4.1.2.2.3 License establishment

In this phase, the broker offers and the user accepts / fulfills the terms of a licence, resulting in transmission of an executed licence to the licence manager and a licence acknowledgement returned to the user.

4.4.1.2.2.4 Service request

The beginning of a licenced interaction is a service request combined with whatever identification and acknowledgement information is required by the licence terms and the system implementation (e.g. whether separate identification and acknowledgement elements are required).

4.4.1.2.2.5 License validation

The trust requirements of all parties are met by a process of authenticating and validating the elements of a licence decision (request(s), identities, licences, preconditions, etc)

4.4.1.2.2.6 License decision

The GeoDRM Gatekeeper makes a decision whether the service request is covered by the licence, based on the information provided to it. The actual authorization and enforcement of a request is carried out as a result of this decision but by an authorization component, not by the Gatekeeper component itself.

4.4.1.2.2.7 Service response

The interacting service returns a valid response or an exception as appropriate for the request, the identity of the requester and the licence terms.

4.4.1.2.2.8 License effects

Service interaction effects may include a log of the interaction, update of service statistics, charges for service usage, etc. The use cases developed for this thread include the “recycling” of usage statistics (e.g. number of requests from a licenced organization per hour or day) into the licence preconditions for subsequent requests.

4.4.1.2.2.9 License expiry / revocation

Page 59 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

The final step in the license lifecyle comes when a licence is no longer valid through expiry or revocation by either party.

4.4.1.2.3 GeoDRM enablement of OWS Services and Clients

Once the information elements and lifecycle have been defined, specific capabilities for OWS services will be defined which together constitute “GeoDRM enablement”. This refers to OWS services in general and not specifically to (new) services such as a GeoDRM license broker which may perform utility functions in support of a GeoDRM workflow.

4.4.1.2.3.1 GeoDRM-capable service protocol

A GeoDRM-protected service interaction requires adding a number of information elements “around” the basic request-response messages. While this is possible to accomplish on an ad hoc basis with HTTP GET and POST protocols, the SOAP messaging protocol provides much more regularized structure and reuse of existing information standards to meet this need. SOAP bindings for OWS services are therefore the preferred method of implementation in this thread. GeoDRM-enabled POST and GET bindings may optionally be defined and implemented in a way which is consistent with the SOAP implementations.

4.4.1.2.3.2 GeoDRM-enabled service request

At a minimum, a valid GeoDRM-enabled service request will contain a token asserting that the requester is licenced to make the request. Additional information may be needed, such as fulfillment of license preconditions. Results of OWS-3 suggest that reuse of existing OWS service message and protocol capabilities for this new purpose (i.e. no change in existing interfaces) is not workable, both because many of the possible capabilities are not widely implemented and because implementations are not written to handle such re-purposing. This additional information should therefore be made an explicit part of OWS service interface specifications (e.g. in OWS Common) to be implemented by both OWS services and their clients.

4.4.1.2.3.3 Chaining to GeoDRM-relevant services

GeoDRM enablement introduces additional workflow into OWS service interactions. Most scenarios and service configurations will benefit from a separation of concerns where tasks specific to GeoDRM and trust (e.g. authentication, license decision) are accessed through separate service interfaces. OWS services will in these circumstances implement the capability to act as clients to such utility services as License Brokers, License Managers, Product registries, etc.

Several component patterns are possible depending on particular system requirements. A proxy pattern would place a GeoDRM-enabled service “proxy” in front of an actual service such as WMS. An integrated service pattern would add GeoDRM enablement into the service itself. A look-aside pattern would add GeoDRM service interaction capabilities directly to the client. A pattern should be developed and implemented in OWS-4 which leads to the greatest degree of interoperability within the context of the GeoDRM use cases and activities in other threads.

4.4.1.2.3.4 GeoDRM-aware service response

Additional information may also accompany a GeoDRM-enabled service response, whether it is an effect of the licenced usage, or an exception which redirects the client to another supporting workflow.

4.4.1.2.4 GeoDRM component implementations

Page 60 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

The formal component requirement for this thread is a set of GeoDRM-enabled OWS services, including WMS, WFS, WFS-T, and CS/W (optionally WCS). In practice, participants may implement additional components in order to separate concerns and leverage existing technology.

GeoDRM Services (Broker, Manager, Gatekeeper) functions may be stand-alone or integrated with the OWS services / clients they support

4.4.1.2.4.1 GeoDRM / Access Services (Broker, Manager, Gatekeeper, A&A) and Clients

These implemented interfaces may be stand-alone or integrated with the OWS services / clients they support

4.4.1.2.4.2 WMS Service and Client

Both stand-alone and cascading GeoDRM-enabled Web Map Servers are required by the use cases in this thread.

4.4.1.2.4.3 WFS (-T) Service and Client

There are separate use cases covering a GeoDRM-enabled Web Feature Server supporting licenced GetFeature access, and a GeoDRM-enabled Web Feature Server – Transactional supporting licenced update requests to particular feature collections.

4.4.1.2.4.4 CS/W Service and Client

There are two envisioned usages for a Web Catalog Service in this thread. The first is as a metadata repository for GeoDRM documents, particularly licence offers. Such a component would not necessarily be considered GeoDRM-enabled. The second is as a catalog of any metadata to which licenced access would be appropriate. This type of CS/W component would be specifically GeoDRM-enabled. There is no explicit requirement in this thread for a separate CS/W component, but catalog capabilities as described here in whatever catalog components are deployed in OWS-4 will be an important factor for integrating GeoDRM into the OWS-4 demonstration

4.4.1.2.4.5 WCS (?) Service and Client

Provision of a GeoDRM-enabled Web Coverage Server is a Tier 2 (unfunded) requirement at this time.

4.4.2 Requirements

Table 4– GeoDRM Requirements

1) Develop licence expressions, offers, acknowledgements, and usage records for OWS-4 use cases a) These documents shall be consistent with the OGC RM licence model b) These document types shall be defined with XML Schema and encoded in XML but are not intended to constitute a general REL (rights expression language) c) Licence expressions shall generally reference (through pre-conditions, constraints, and effects) but not include information and mechanisms which enable trust between service / content providers and consumers 2) Develop access control (authentication & authorization) policy elements to support OWS-4 GeoDRM

Page 61 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

use cases a) Elements shall make use of OASIS standards for security policy such as XACML and SAML b) Elements shall support authentication of documents required for licence decisions c) Elements shall support authorization of OWS service requests based on licence decisions d) Elements shall support both HTTP BASIC and x.509 certificate methods of authentication, however a complete PKI is out of scope for this initiative. 3) Develop Trusted Geoservices Authentication&Authorization service (WA2S) a) Service shall support authentication and authorization of users (individuals and groups), clients, services, service requests and responses, and related documents such as licences. b) Service shall provide a SOAP protocol binding and optional POST and GET bindings c) Service shall support access control policy and security standards required in 2) 4) Develop GeoDRM Broker service a) Service shall support offer, negotiation, acceptance, and establishment of GeoDRM licences with users b) Service shall provide a SOAP protocol binding and optional POST and GET bindings c) Service shall incorporate or function as a client to WA2S. 5) Develop GeoDRM Manager service a) Service shall support insertion, query, update, revocation/deletion of GeoDRM licences b) Service shall provide a SOAP protocol binding and optional POST and GET bindings c) Service shall incorporate or function as a client to WA2S. 6) Develop GeoDRM Gatekeeper service a) Service shall support validation of OWS service requests against GeoDRM licences and supporting elements, returning a licence decision or appropriate exception. b) Service shall provide a SOAP protocol binding and optional POST and GET bindings c) Service shall incorporate or function as a client or service to WA2S. 7) Develop GeoDRM-enabled Web Map Server (WMS) a) Service shall provide a SOAP protocol binding b) Service shall implement support for WS-security or equivalent to carry GeoDRM information c) Service shall incorporate or function as a client to GeoDRM-supporting services. This may include enforcing WA2C responses. 8) Develop GeoDRM-enabled Cascading Web Map Server (cWMS) a) Service shall provide a SOAP protocol binding b) Service shall implement support for WS-security or equivalent to carry GeoDRM information c) Service shall incorporate or function as a client to GeoDRM-supporting services. This may include enforcing WA2C responses. d) Service shall cascade map requests to originating Web Map Servers as an agent for a distributor licencee

Page 62 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

9) Develop GeoDRM-enabled Web Feature Server with transactional capabilities (WFS-T) a) Service shall provide a SOAP protocol binding b) Service shall implement support for WS-security or equivalent to carry GeoDRM information c) Service shall incorporate or function as a client to GeoDRM-supporting services. This may include enforcing WA2C responses. 10) Develop GeoDRM-supporting Web Catalog Service (CS/W) a) Service shall act as a catalog of product offers b) Service shall act as a catalog of licence documents c) Service shall implement SOAP binding and WS-security or equivalent in order to support trust in GeoDRM workflows d) Service shall optionally incorporate or function as a client to GeoDRM-supporting services. This may include enforcing WA2C responses. 11) Participate in OWS-4 demonstration 12) Deliver an OWS-4 GeoDRM Engineering Viewpoint Interoperability Program Report describing the information and computational elements developed in the initiative, as well as their implementation, deployment, and testing during the intiative and demonstration. 13) Deliver an OWS-4 Trusted Geoservices Model IPR describing the enterprise, information, computation, and engineering viewpoints of a Trusted Geoservices architecture developed in OWS-4

4.4.3 GeoDRM Use Cases

Use Case Identifier: GeoDRM #1 Use Case Name: Unrestricted Use License

Use Case Domain: OWS-4 GeoDRM Status: Draft 04/01/06

Use Case Description: This use case describes “unrestricted” access to map layer resources based on a session license in which the user has read a statement of terms-of-use and agreed to them with a click- through gesture.

Actors (Initiators): User of WMS Actors (Receivers) Same as initiator Pre-Conditions: Post-Conditions: - User requires WMS map layers. WMS map layers are viewable within the user’s - User has access to WMS client. WMS client software. - User is able to discover WMS services with the needed layers through a CS/W catalog and/or Web Map Context document

System Components (may be combined) - GeoDRM-enabled CS-W: Catalog Service Web Profile - GeoDRM-enabled WMS: Web Map Service - GeoDRM-enabled Web WMS / WMC client

Page 63 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

- GeoDRM-enabled Desktop WMS / WMC client - License Broker: presents license offers and establishes licenses - License Manager: stores and matches licenses - License Gatekeeper: decides whether a specific request is valid under a specific license - License Enforcer: “security” implements authentication of license decision elements and authorization of consequences

Basic Course of Action: 1. Client queries a CS-W and/or WMS and/or reads a WMC to determine if needed map layers are available and under what terms 2. User selects layers of interest 3. Client obtains terms of use 4. User agrees to terms presented by client 5. Client returns license acknowledgement to Server 6. Server stores established license with session identity and returns acknowledgement token 7. Client issues map layer request with license acknowledgement token to WMS 8. Server validates identity of user and authenticity of license information, decides that license applies to request. 9. WMS returns map layer to client 10. (Alternate unrestricted use distribution) WMS Server seen by the client is cascading both the map layers and license offer / acknowledgement from one or more other servers

Use Case Identifier: GeoDRM #2 Use Case Name: Distributer License

Use Case Domain: OWS-4 GeoDRM Status: Draft 04/01/06

Use Case Description: This use case describes “distributer” rights to WMS map layers. The provider of a cascading WMS operates under a license with an originating WMS to re-distribute on its own one or more map layers to clients under an unrestricted use license.

Actors (Initiators): User of WMS and provider of Actors (Receivers) Same as initiators cWMS Pre-Conditions: Post-Conditions: - User requires WMS map layers. WMS map layers are viewable within the user’s - User has access to WMS client. WMS client software. - cWMS provider is able to cascade map layers from one or more originating WMS Servers

System Components - CS-W: Catalog Service Web Profile - WMS: Web Map Service - cWMS: Cascading Web Map Service - License Broker: presents license offers and establishes licenses - License Manager: stores and matches licenses

Page 64 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

- License Gatekeeper: decides whether a specific request is valid under a specific license - License Enforcer: “security” implements authentication of license decision elements and authorization of consequences

Basic Course of Action: 1. cWMS provider establishes a distributer license with an originating WMS for one or more map layers and receives a license acknowledgement token. 2. User queries a CS-W and/or the cWMS and/or a WMC to determine if needed map layers are available and under what terms 3. User selects layers of interest 4. Client obtains terms of use 5. User agrees to terms 6. Server stores established license and returns acknowledgement token 7. Client issues map layer request to cWMS with license acknowledgement token. 8. Server validates identity of user and authenticity of license information, decides whether license applies to request. 9. cWMS issues map layer request to originating WMS with its own (distribution license) acknowledgement token 10. WMS returns map layer to cWMS 11. cWMS returns map layer(s) to client.

Use Case Identifier: GeoDRM #3 Use Case Name: End User License

Use Case Domain: OWS-4 GeoDRM Status: Draft 04/01/06

Use Case Description: This use case describes “end user” rights to WMS map layers and/or WFS feature collections for specifically identified individual users. The end user rights may be individual or may be based on an individual’s role (e.g. membership) in a licensed organization. The end user license may carry specific pre-conditions and constraints which need to be satisfied before a request can be honored.

System Components - CS-W: Catalog Service Web Profile - WMS: Web Map Service - License Broker: presents license offers and establishes licenses - License Manager: stores and matches licenses - License Gatekeeper: decides whether a specific request is valid under a specific license - License Enforcer: “security” implements authentication of license decision elements and authorization of consequences

Basic Course of Action:

Page 65 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

1. User queries a CS-W and/or WMS/WFS and/or WMC to determine if needed map layers or datasets are available and under what terms 2. User selects layers and/or datasets of interest 3. User logs in and is authenticated with a specific identity (e.g. username/password or X.509 certificate) 4. Server matches identity with established individual or organization license and returns acknowledgement token 5. Client issues map layer or dataset request with license acknowledgement token 6. Server validates identity of user and authenticity of license information, decides whether license applies to request and whether any pre-conditions and constraints are met (e.g. time of request, area of request, state of daily usage quotas) 7. Server returns map layer or dataset to client

Use Case Identifier: GeoDRM #4 Use Case Name: WFS-T Feature Updater

Use Case Domain: OWS-4 GeoDRM Feature Update Status: Draft 04/01/06

Use Case Description: This use case describes “Updater” rights to provide specific feature update transactions to a WFS-T server.

System Components - CS-W: Catalog Service Web Profile - WMS: Web Map Service - License Information Point - License Decision Point - License Enforcement Point

Basic Course of Action: 8. User queries a CS-W to determine if needed map layers are available and under what terms 9. User selects layers of interest 10. Client obtains terms of use 11. User agrees to terms 12. Server stores established license and returns acknowledgement token 13. Client issues map layer request with license acknowledgement token 14. Server validates identity of user and authenticity of license information, decides whether license applies to request. 15. Server returns map layer to client

Page 66 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

4.4.4 Deliverables

The following Interoperability Program Reports (IPRs) will be developed in the GeoDRM thread and submitted to the OGC Specification Program at the completion of the OWS-4 Testbed.

1) OWS-4 GeoDRM Engineering Viewpoint IPR This document will reference both the OGC GeoDRM RM and the Trusted Geoservices Model IPR and further develop viewpoints of the architecture and implementation of GeoDRM-enabled services 2) OWS-4 Trusted Geoservices Model IPR This document will form the beginning of an OGC reference model for the incorporation of trust elements into OWS services. It will then be referenced by the above IPR in support of those elements as they play a part in GeoDRM enablement. 3) OWS Common CP IPR This document will propose to the OWS Common specification those changes recommended from the OWS-4 experience for incorporating GeoDRM enablement uniformly and interoperably into OWS services.

Implementations of the following services, tools and data instances will be developed in the OWS4 GeoDRM thread, tested in Technology Integration Experiments (TIEs) and invoked for cross-thread scenarios for OWS-4 demonstration events:

1) GeoDRM-enabled (integrated or proxy) CS/W, WMS, WFS-T. This may take the form of an integrated service or a GeoDRM-enabled proxy on an existing service. 2) GeoDRM-enabled OWS browser and stand-alone clients (integrated or proxy) 3) Sample license expressions and terms-of-use texts which utilize XML encodings and existing standards wherever possible. 4) Other GeoDRM-enabling components a) GeoDRM Gatekeeper (compare licenses to service requests) b) License Manager (store, match, and return licenses) c) WA2S Authentication – authorization service (provide elements of trust and security to licensed interaction) d) License Broker (offer, negotiate, and establish license)

4.4.5 OGC Reference Model (ORM) Viewpoints

The following sections describe RM-ODP viewpoints into the structure and role of digital rights management for OGC-enabled geospatial content and services. These viewpoints provide both a conceptual framework and best-practices recommendations for applying standards and technology from the general IT domain to the specific needs of distributed geocomputing.

For more information see Geospatial Digital Rights Management Reference Model (GeoDRM RM). OGC document 06-004r3- GeoDRM RM is has been approved by the OGC Specification for electronic vote to become a volume of the OGC Abstract Specification. The remainder of this clause draws heavily from the GeoDRM RM, but the material herein is focused on providing a reference model only for those items in OWS-4.

Page 67 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

4.4.5.1 GeoDRM Enterprise Viewpoint

This viewpoint describes concepts and use cases for GeoDRM, as well as references to distributed computing concepts which are not GeoDRM sensu stricto but are required for any GeoDRM implementation. The capabilities identified here describe the requirements to be met by the OWS computation and information models. The Enterprise Viewpoint is defined by a high-level system concept and use-cases (see earlier section for use cases).

The figure below shows the roles within a GeoDRM-enabled network of services. Within this model an individual person or organization may perform one or more of these roles in the network. In fact, because many of us currently perform a number of these roles at the same time, it is difficult to imagine other ways of doing business where the roles and responsibilities are allocated in a different way.

In the following figure various roles have divided responsibilities, so they may be combined according to the needs of a specific business model. In many ways these roles can be thought of as the “primitives” that can be selected and assembled according to the specific needs of a business model.

In OWS-4, the specific roles of Service Provider / Owner, Licencee, Sublicencee, Licence Broker (Agent), and Licence Manager will be exercised, as well as the responsibility of making licence decisions (described below).

Payment Provider Payments Licence fee

Contract Owner Licensee

Delegates Assigns Assign licensing licence policy Sub-licence

Licensing Delegates hosting Agent Sub - Licensee

Delegates Valid Licence Establish work licence credentials Manager

Request Service Content End - User Provider

Figure 13 - GeoDRM roles and responsibilities

The activities and spatial data system to be exercised in OWS-4 constitute a communications and transport network for exchanging geospatial content and services. The GeoDRM thread in OWS-4 adds a new layer to this network capability, one which adds two trading aspects to the existing capabilities:

Page 68 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

• Trust in the identities and behavior of the trading partners (and their software agents)

• Explicit and actionable terms (rights on resources plus conditions) for trading of content and services.

While both trading terms (DRM) and trading trust (Security) are required in this layer, their definition and specification are maintained as separate concerns. The purpose of this separation is both to allow for maximum flexibility in system designs, and to provide the maximum reuse of existing standards and technology for supporting trust which happen largely to be defined outside of a GeoDRM framework.

Security system for DRM Resource protection Gatekeeper Security

Transport

Figure 14 - Role of (Geo)DRM and Security in support of trading geospatial content

4.4.5.2 GeoDRM Information Viewpoint

This viewpoint describes the types and roles of information required to support a GeoDRM license lifecycle. At least three types of information are needed for GeoDRM

• (Geo)license information

• Trust information

• Service information

For the purpose of OWS-4 GeoDRM, the structure and elements of a “geolicence” are defined in the OGC GeoDRM Reference Model.

A licence is defined in ISO 21000-5 as an "expression that is created by Principals to conditionally or unconditionally permit the same or other Principals to perform Rights upon Resources." A Right is an act identified by the licence subject to any conditions associated with it in the licence.

A licence is a sequence of grants. Each grant specifies a principal, which receives a right to act, and optionally, a resource upon which that right may be applied.

Within a licence, most principal references may be references to patterns, that is may be statements of the properties that would include a particular principal in an implied set of principals. This is not the case for the licensee, who is the principal actually contracted with the licensor (licensing agent) for the acquisition of the licence in question.

Page 69 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

License Grant Principal

Right

Resource

Condition

Issuer Signature

Details

Figure 15 - General structure of a (Geo) licence.

4.4.5.2.1 License information

For the purpose of OWS-4 GeoDRM, the structure and elements of licence information are defined in the RM and will be exercised through example licence texts and licence expressions. Development of GeoREL is out of scope for this initiative. Examples of additional related information elements will be exercised in OWS-4; these include:

• Product offer

• Licence acknowledgement

• Licence decision

• Licence usage

4.4.5.2.2 Trust information

The elements of trust information to be exercised in OWS-4 correspond to many of the elements of the licence information and fall into two categories:

• Authenticity – credential information such as tokens, usernames and passwords, x.509 certificates which authenticate identities and documents involved in service trading

• Authorization – decision information such as authenticity, licence, and access decisions to be enforced by controlled-access services. A licence decision may be only one condition (i.e. necessary but not sufficient) of a more general access authorization decision.

4.4.5.2.3 Service information

Page 70 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

Any user / client of an OWS service requires information (capabilities metadata) on what the service does and how to interact with it. This information is defined generally within OWS Common and supporting specifications, and specifically within each service specification. Other forms of service information may be provided, such as WSDL or WSIL. A service which is GeoDRM enabled must similarly provide information on the licence status of its contents and the requirements for trading with it. This may be provided in two forms:

• Product offer – this extended element of service metadata describes the licence terms which accompany specific use (contents and/or operations) of the service.

• Licence exceptions – extended service exception responses which indicate clearly to a user / client that a service request cannot be fulfilled because required licence terms are not met. Preferably the exception message also indicates in a clear and standard manner how the user / client may proceed to satisfy licence terms (e.g. read and acknowledge a licence text).

This extended service metadata should also be included in and accessible from OGC catalogs, such that a user may search for services and geocontent based on the licence terms which control their use.

4.4.5.3 GeoDRM Computational Viewpoint

This viewpoint describes the services, interfaces and operations required for GeoDRM enabled distributed computing interactions.

(This section contains excerpts from OGC document: Access Control (AC) & Terms of Use (ToU) “Click- through” IPR (05-111r2)).

The most general approach for GeoDRM is to separate the security and DRM aspects technically from the Geo functionality as much as possible. The advantage of this approach is that existing security concepts and implementations from IT industry, such as the WS-Security standard and extensions, can be leveraged for implementing security and DRM aspects for geo Web services. The second advantage is the possibility of using geo Web service implementations (e.g., WMS, WFS) without modifications by placing DRM functionalities as separate services between geo Web client and geo Web server.

The next step is to separate the geoprocessing service from the security service. All requests and answers are routed through the security service, which processes the security information in the header (usually together with the body information, e.g., to determine from a WMS request which layers are requested and which licenses are needed). The geoprocessing service needs no understanding of security aspects and processes only the body information. As a consequence, existing geoprocessing service implementations may be used without modifications in GeoDRM scenarios.

4.4.5.3.1 GeoDRM Gatekeeper

The focus of the GeoDRM framework, once all valid and authentic elements of a licence and requested usage request have been provided, is the licence decision, whether a requested activity is valid under the terms of a licence. This decision is carried out by a GeoDRM Gatekeeper which compares an authenticated request and support documentation (e.g. user identity, fulfillment of preconditions) with the terms and conditions of an authenticated licence. The Gatekeeper does not itself carry out any functions of service provision, communication, authentication, or enforcement. It may, however, need to compare documentation of these functions with references to them in the licence in order to render an appropriate decision.

4.4.5.3.2 Authentication & authorization

Page 71 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

There are many layers and elements of trust and security in distributed computing, as well as a myriad of standards, technologies, and practices for implementing them. As a first step in an OGC Trusted Geoservices framework describing their interoperable use with OWS services, the focus will be on two functions:

• Authentication of OWS services actors (users, providers, agents, documents)

• Authorization of their interactions (requests, responses, challenges, notifications, and so on) carried out through definition and implementation of interfaces for an Authentication & Authorization service (WA2S). A WA2S will provide at a minimum the operations

• GetCapabilities

• AuthenticateIdentity

• ValidateDocument

• AuthorizeRequest

4.4.5.3.3 OWS service

For the purposes of the GeoDRM / Trusted Geoservice thread, an OWS service is considered one of the OGC-defined geospatial Web services (including but not limited to WMS, WFS, WCS, CS/W), which are consistent with the OGC OWS Common specification and which may be considered as part of an SDI (Spatial Data Infrastructure) implementation.

4.4.5.4 GeoDRM Engineering Viewpoint

This viewpoint describes the combinations of technology, information, and best practices required to implement GeoDRM on specific computing platforms.

For OWS-4 the GeoDRM roles are accomplished by six functionalities

• GeoDRM gatekeeper

• GeoDRM licence broker

• GeoDRM licence manager

• Authentication & authorization

• OWS service

In addition, an existing catalog may be used for product descriptions and other metadata. Proposals should identify a series of components that implement these functionalities using services and interfaces identified in the computational viewpoint.

4.4.5.4.1 SOAP HTTP

Augmenting OWS Services with resource trading capabilities requires the addition of a number of information elements pertaining to identity and licencing around the service request message for an given

Page 72 Due Date: March 14, 2005 Annex B: OWS-3 Architecture service. This “envelope – body” metaphor is very well supported by a number of information protocols and encodings which make use of the basic structure of SOAP (Simple Object Access Protocol). SOAP over HTTP is therefore the preferred protocol binding for GeoDRM-enabled OWS services. Services may also implement GeoDRM extensions to existing GET and POST bindings which are consistent with (if not inclusive of) the information exchanged through SOAP bindings.

For the first two OWS-4 GeoDRM Use Cases, it is anticipated that security standards are not needed to accomplish the requirements.

For the latter OWS-4 Use Cases, proposers should consider a SOAP DCP for all communication where security information is involved (such as identity credentials, signatures, licenses, authorization certificates etc.). The security information is carried in the SOAP header part, as specified in WS-Security and the related standards. The geodata specific requests and answers are carried in the SOAP body and need not be modified in any way.

By using a protocol converter from SOAP to HTTP get/post, it is even possible to use geoprocessing services not supporting the SOAP DCP, since the additional security information needs not to be communicated to the geoprocessing service.

4.4.5.4.2 WS-Security and WS-Context

A number of standards have been developed which provide a standard means of accompanying a SOAP message with additional supporting information relating to the trust and other contexts within which the message is being exchanged. These existing standards should be leveraged as much as possible in order to avoid wheel reinvention in the development of an OWS Trusted Geoservices framework. WS-Security is a standard from OASIS as of March 2004. The specification “describes enhancements to SOAP messaging to provide message integrity and confidentiality. The specified mechanisms can be used to accommodate a wide variety of security models and encryption technologies. This specification also provides a general- purpose mechanism for associating security tokens with message content.”

Currently the following four token profiles are defined and approved by OASIS:

Page 73 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

• Username Token Profile • X.509 Token Profile • SAML Token Profile • REL Token Profile A token profile for Kerberos is in work within the WSS TC at OASIS.

In the case of service chaining, the cascading service should forward the credentials to the cascaded service. For example a FPS would extract the security tokens from the message request and include them in the request that it makes to the WFS. If exceptions occur, the cascading service (the FPS in the picture above) shall send them to the client.

4.4.5.4.3 SAML / XACML

Standards and XML schemas have also been developed for exchanging information about and assertions over identity, resources, and permissions in service interactions. Two such standards which are relevant to this thread include

• SAML – Security Assertion Markup Language

• XACML – XML Access Control Markup Language

Proposals should consider the use of these standards to achieve the OWS-4 GeoDRM objectives, e.g., Use Case #4 requires permissions specific to updating a feature using WFS-T.

4.4.5.4.4 Component Patterns

OWS-4 intends to define and exercise a set of GeoDRM / Trusted Geoservices information elements, the means of encoding / combining them with OWS service messages, and useful operations to process them. GeoDRM / TG workflows inevitably consist of chains or orchestrations of multiple distributed computing tasks except in the most trivial of cases.

A component diagram for OWS-4 GeoDRM implementation is shown in the figure below. This initial configuration shows an integrated GeoDRM-enabled service and client. Yellow components represent alternative configurations such as a non-GeoDRM-enabled OwsService behind a OwsGeoDrmService acting as a proxy, an OwsCascader which exercises a Distributor licence, and a separate BrokerClient for licence establishment.

Page 74 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

Figure 16 - OWS-4 GeoDRM component diagram – Initial draft

4.5 CAD/GIS/BIM A great deal of technical innovation has been accomplished in the areas of CAD, AEC, geospatial, 3D visualization, and urban simulation. A variety of products, information and services abound in each of these environments. A framework of data interoperability should exist across the lifecycle of building and infrastructure investment: planning, design, construction, operation, and decommissioning.

source: OGC CAD/GIS WG

Page 75 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

Figure 17 - The CAD/GIS/BIM Interoperability Challenge

This work is of interest to the geospatial community in that there is a growing need for technologies and information to effectively interoperate between these domains to support a range of vital services and decision support needs. The OGC CAD-GIS Interoperability WG is focusing its efforts on identifying and acting on opportunities to improve interoperability of geospatial data and services across these domains.

The CAD/GIS/BIM thread of OWS-4 is a joint activity with IAI and NBIM (to be confirmed).

IAI is an alliance of organizations dedicated to bring about a coordinated change for the improvement of productivity and efficiency in the construction and facilities management industry (Building Smart). Our members engage in national-industrial programmes that aim to change the organisation, process and technology of the industry. http://www.iai-international.org/

The International Alliance for Interoperability (IAI) is a global standards-setting organization representing widely diverse constituencies—from architects and engineers, to research scientists, to commercial building owners and contractors, to government officials and academia, to facility managers, and to software companies and building product manufacturers. Alliance members are committed to promoting effective means of exchanging information among all software platforms and applications serving the AEC+FM community by adopting a single Building Information Model (BIM). (http://www.iai-na.org/)

The mission of the National BIM Standard Project Committee is to improve the performance of facilities over their full life-cycle by fostering a common, standard and integrated life-cycle information model for the A/E/C and Facilities Management industry. This information model will allow for the free flow of graphic and non-graphic information among all parties to the process of creating and sustaining the built environment, and will work to coordinate U.S. efforts with related activities taking place internationally. 4.5.1 Scope OWS-4 will focus on these activities in the CAD/GIS/BIM thread.

4.5.1.1 Information models and encodings

• CityGML: GML3 Application Profile for virtual 3D City Models • Industry Foundation Classes (IFC) o Using IFC to define BIM information views. o Use OGC GML Application Schema tools to IFC UML models and XML encodings. • TransXML: schemas for exchange of transportation data • Coordinate system management o Buildings in space – point/direction, footprint, envelop, solid model o Definition of CRS in GML CRS schema o EPSG convention for Coordinate Reference Systems (CRSs) Solving the harmonization of geometry model differences between CAD and GIS is not in the OWS-4 scope.

4.5.1.2 Services based interoperability

• Interoperability across building and infrastructure lifecycle • Service oriented architecture for CAD/GIS/BIM

Page 76 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

• CAD/GIS Client access to BIM views from a CAD Model Server (CMS) and GIS Features from a WFS. • Update of BIM objects by CAD/GIS Client

4.5.1.3 Functional applications and demonstrations

• CAD space assessment • Access to objects over the construction life-cycle (4-D) • Co-location of GIS features and CAD objects in several CRSs • 3-D visualization of GIS and CAD data:

Page 77 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

4.5.2 Requirements

Table 5 - CAD/GIS/BIM Requirements

1. Develop information model of CAD/GIS/BIM suitable to the tasks in OWS-4 a) Information model shall use existing models of CityGML, IFCs. (TransML to be considered) b) Select elements of IFC UML models for use in OWS-4 c) Develop domain specific and product specific extensions of IFC the previously developed GML Application Schema tools. d) Develop IFC application schemas for the OWS-4 CAD/GIS Use Cases e) Define CityGML for use in OWS-4 CAD/GIS Use Cases f) Define TransML for use OWS-4 CAD/GIS Use Cases (TBD) 2. Develop web services to provide interoperable access to CAD/GIS/BIM models and data. a) As possible, base CAD/GIS web services on existing the OGC Web Services Architecture, the OWS Common Implementation Specification, and specific OGC Web Services (WMS, WFS, WCS). b) Define a CAD Model Service (CMS) including the interface and the semantics of the service c) Implement CRS in WFS and CMS to allow co-location of CAD data in CityGML data. 3. Develop CAD/GIS Client with the following functionalities: a) Client shall access CMS for CAD data identified in the CAD/GIS Use Cases. b) Client shall access WFS for GIS data identified in the CAD/GIS Use Cases. c) Client shall render CAD and GIS data in the same visualization, insuring that the data is co- located to a common coordinate system for visualization. d) Client shall provide 2-D and 3-D spatial visualization. e) Client shall access project planning data and render the change of BIM Objects over time. f) Client shall access CMS-T to modify a BIM object. g) Client shall access WFS-T to modify a GIS Feature. h) Client shall control the transfer of BIM Model from one CDS to another CDS. For this transaction, the BIM data shall not pass through the Client. i) Client shall provide visualization from global view (small scale) to room view (large scale)

Page 78 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

4.5.3 Use Cases

Use Case Identifier: CAD/GIS/BIM #1 Use Case Name: Temporary Field Hospital Planning

Use Case Domain: OWS-4 CAD/GIS Status: Under development. Draft 060322

Use Case Description: Facility planners analyze a location for siting a temporary field hospital, including consideration of access by road and helicopter. Security is a high concern for planning.

Actors (Initiators): Emergency response commander Actors (Receivers): security and construction analysts Pre-Conditions: Post-Conditions: Commander has determined a desireable site is an Plans for slight construction and deployment of abandoned building at the local airport secure perimeter have been determine.

System Components

• CAD Model Server (CMS) provides access to the following data: • As-built data for buildings originally in CAD files (dgn) w/o coordinate system information • Existing roads alignments in civil design applications (i.e. InRoads, CAICE, MXRoads) • Existing underground utilities, i.e., sewer system • Manholes in recent photogrammetric planimetric data in CAD file (dwg) • Web Feature Servcie (WFS) provides access to the following data: • Site data (terrain, orthophotos, land use) maintained in GIS data, accessible as GML • AIXM data available for a helicopter pad. 1. Basic Course of Action: 2. Render BIM and civil engineering data existing building in the CAD/GIS Client. Insure that both models share the same coordinate systems and units of measure. Confirm that the building models, surface and road models come together in a geospatial application. (Where exactly does the building meet the surface model?) 3. Construction analysts are tasked to evaluate the site for a temporary heliport on the grounds. Determine the location of the heliport based upon the surface landing location and the AIXM model for a heliport. Render CAD plans and GIS models in the 3D CAD/GIS Client. These additions to the facility will necessitate taking one of the airport runways, taxiway and apron out of service. 4. Army security and construction analysts working together evaluate the site and perimeter information. Analysts need to determine the need and locations for possible road closures and placement of IEEE sensors (motion) to secure the perimeter, including sewers. Access the sewer system data to determine citing of the perimeter security. Determine location for sensors. Create or update a CAD model for the location where the sensors are too be deployed. 5. As the construction projrect requires a temporal sequencing of the heliport construcntion and the sensor installation, create a several views of the construction model over time and insert in the CMS. Review the stages of the project in the CAD/GIS Client a. Update a CAD object in the CDS using the CAD/GIS Client. b. Update a GIS feature in the WFS-T using the CAD/GIS Client. 6. Analyst creates a CityGML feature collection of the information relevant to the other operaiotns and inserts tot he WFS. 7. Analyst creates a Context document linking to the WFS and CMS content.

Page 79 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

4.5.4 Deliverables

The following Interoperability Program Reports (IPRs) will be developed in the CAD/GIS/BIM thread and submitted to the OGC Specification Program at the completion of the OWS-4 Testbed.

1) CAD/GIS/BIM Services IPR – report results of using web services for CAD/GIS/BIM data; include initial definition of CDS interface and service, recommend next steps. 2) CityGML Schema CR – report results of using CityGML with WFS (and WFS-T) for the CAD/GIS Use Cases; include the schemas as developed; provide change requests on the CityGML specification. 3) IFC Implementation IPR – report results of developing IFC schemas using the GML Application Schema tools; results of using IFC with CDS (and CDS-T) for the CAD/GIS Use Cases; include the schemas as developed; provide change requests on the IFC specification. 4) TransML Implementation IPR – report results of using TransML with WFS (and WFS-T) for the CAD/GIS Use Cases; include the schemas as developed; provide change requests on the TransML specification 5) OGC Network – create entries on OGC Network for the items above.

Implementations of the following services and tools and data instances will be developed in OWS4-thread, tested in Technology Integration Experiments (TIEs) and invoked for cross-thread scenarios for OWS-4 demonstration events:

1) UGAS-for-IFC Tool (1); for converting UML models of IFC into XML schemas. This will be built on the existing UGAS for GML Application Schema development. 2) CAD Model Server (CMS) (2); serving IFC data encoded in XML. 3) CAD Model Server – Transactional (CMS-T). CDS that allows client to change the BIM data held in the CDS. 4) Web Feature Server (WFS); serving CityGML, TransXML, and other data relevant to the use cases for this thread. 5) CAD/GIS Client (1); client to CDS(-T) and WFS(-T), able to render visual models of the CAD and GIS data in 2D and 3D; able to show BIM object over project timeline.

Page 80 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

4.5.5 OGC Reference Model (ORM) Viewpoints

4.5.5.1 CAD/GIS/BIM Enterprise Viewpoint

A recent study by the U.S. Department of Commerce, National Institute of Standards and Technology (NIST) titled “Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry” indicates that US$15.8B is lost annually due to the lack of interoperability. (NIST GCR 04-867, August 2004) http://www.bfrl.nist.gov/oae/publications/gcrs/04867.pdf

The NIST Study states:

“Interoperability problems in the capital facilities industry stem from the highly fragmented nature of the industry, the industry’s continued paper-based business practices, a lack of standardization, and inconsistent technology adoption among stakeholders.

“Based on interviews and survey responses, $15.8 billion in annual interoperability costs were quantified for the capital facilities industry in 2002. Of these costs, two-thirds are borne by owners and operators, which incur most of these costs during ongoing facility operation and maintenance (O&M). In addition to the costs quantified, respondents indicated that there are additional significant inefficiency and lost opportunity costs associated with interoperability problems that were beyond the scope of our analysis. Thus, the $15.8 billion cost estimate developed in this study is likely to be a conservative figure.

“Unfortunately, the construction industry has not yet used information technologies effectively to integrate its design, construction, and operational processes. There is still widespread use of paper as a medium to capture and exchange information and data among project participants.

“Inadequate interoperability increases the cost burden of construction industry stakeholders and results in missed opportunities that could create significant benefits for the construction industry and the public at large.

The NBIM Committee has defined the term Building Information Model (BIM) as a digital representation of physical and functional characteristics of a facility. As such it serves as a shared knowledge resource for information about a facility forming a reliable basis for decisions during its life-cycle from inception onward.

A basic premise of BIM is collaboration by different stakeholders at different phases of the life cycle of a facility to insert, extract, update or modify information in the BIM to support and reflect the roles of that stakeholder. The BIM is a shared digital representation founded on open standards for interoperability.

4.5.5.2 CAD/GIS/BIM Information Viewpoint

4.5.5.2.1 CAD/GIS/BIM Information engineering

The information viewpoint is concerned with the semantics of information and information processing. The information viewpoint defines conceptual schemas for CAD/GIS/BIM information and methods for defining application schemas. The conceptual, or base, schemas are formal description of the model of any CAD/GIS/BIM information. Application schemas are information models for a specific information community. Applications schemas are built from the conceptual schemas.

Page 81 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

The Information viewpoint provides brief descriptions of three modeling efforts followed by a discussion o Schema Maintenance and Tailoring. The three modeling specifications to be used in OWS-4 CAD/GIS are CityGML, IFCs and TransML.

An objective for the CAD/GIS/BIM information engineering in OWS-4 is to move toward seemless access to information across the extremes of spatial scales, across the different semantic domains and across the lifecycle of a project (see Figure 17 and Figure 18).

Figure 18 – Seamless semantics and spatial information for CAD/GIS/BIM

Differences between CAD and GIS Information Models are apparent when attempting to import CAD data into GIS Software, e.g., lack of object definitions in the CAD models, differenct scale representations, transformation of the local (CAD) coordinates into a reference system for both the horizontal and vertical coordinates, parametric shapes that cannot be converted into GIS objects, different levels of detail that require generalization, etc. (From “Large-scale 3D Data Integration: Challenges and Opportunities,” S. Zlatanova and D. Prosperi Editors, Taylor and Francis, 2006.)

OWS-4 will not solve the CAD-to-GIS-to-CAD data transformation challenge –work is needed on comparing the abstract CAD and GIS information models before attempting to build those transformation. An emphasis in OWS-4 is to allow access to GIS and CAD data and visualizing the disparate data sets. This will begin the process of working on GIS and CAD data in the one OGC testbed.

4.5.5.2.2 CityGML

CityGML is a common information model for the representation of 3D urban objects. It defines the classes and relations for the most relevant topographic objects in cities and regional models with respect to their geometrical, topological, semantic and appearance properties. Included are generalization hierarchies between thematic classes, aggregations, relations between objects, and spatial properties. This thematic information goes beyond graphic exchange formats and allow to employ virtual 3D city models for sophisticated analysis tasks in different application domains like simulations, urban data mining, facility management, and thematic inquiries.

CityGML is realised as an open data model and XML-based format for the storage and exchange of virtual 3D city models. It is implemented as an application schema for the Geography Markup Language 3 (GML3), the extensible international standard for spatial data exchange issued by the Open Geospatial

Page 82 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

Consortium (OGC) and the ISO TC211. CityGML is intended to become an open standard and therefore can be used free of charge.

The CityGML specification document is currently being compiled from contributions of different SIG 3D members. The description of the general concepts and the building model is almost complete. The description of the other themes is still work in progress with an internal deadline by the end of April. The first version of the complete specification proposal will be uploaded to the OGC pending document page before the end of May. (http://www.citygml.org/)

CityGML does not only represents the graphical appearance of city models but especially takes care of the representation of the semantic resp. thematic properties, taxonomies and aggregations of Digital Terrain Models, sites (including buildings, bridges, tunnels), vegetation, water bodies, transportation facilities, and city furniture. The underlying model differentiates five consecutive levels of detail (LOD), where objects become more detailed with increasing LOD regarding both geometry and thematic differentiation. CityGML files can - but don't have to - contain multiple representations for each object in different LOD simultaneously.

Figure 19 - Visualization of a CityGML document

Page 83 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

4.5.5.2.3 Industry Foundation Classes (IFC)

The Industry Foundation Classes (IFC) system is a data representation standard and file format used to define architectural and construction-related CAD graphic data as 3D real-world objects. Its main purpose is to provide architectural CAD users with the ability to exchange data between complementary applications such as CAD and estimating tools. The IFC specification is developed by the IAI. http://www.iai-international.org/Model/IFC(ifcXML)Specs.html

The Industry Foundation Classes for GIS (IFG) project intended to provide support for geographic information within the IFC model to support the integration of CAD and GIS data. A task of the IFG was data transformation between IFC and GML. A description of the IFG project is available here: http://ce.vtt.fi/iaiIFCprojects/ShowProjectInfo.jsp?project_id=89&status_id=2

Figure 20 - IFC2x3 Architecture

Page 84 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

Table 6 - IFC2 Data Models most relevant to OWS-4

IFC Data Model Description

Ifc The most abstract part within the IFC architecture. It captures general constructs, that Kernel are basically founded by their different semantic meaning in common understanding of an object model, like object, property and relationship. Those are then specialized into non-AEC/FM specific constructs, like product, process, control and resource, which form the main entry points for the next level, the Core Extension layer.

Ifc Further specialises the concepts of a (physical) product, i.e. a component likely to Product have a shape and a placement within the project context. The product information is Extension provided for individual product occurrences as subtypes of IfcProduct, and for common specific product types as subtypes of IfcTypeProduct. Both definitions are rooted in supertypes provided within the IfcKernel. Ifc The schema IfcGeometryResource defines the resources used for geometric Geometry representations. The primary application of this resource is for representation of the Resource shape or geometric form of a product model.

Ifc This schema defines the representation of shape and topology as important Representation definitional properties for products defined within the IFC Object Model. The Resource representations characterize certain properties of a product, and any product can be defined by zero, one, or many of those properties.

IFCkernel defines the most general definition of semantics in IFC. The IFC kernel serves a role for IFC that is similar to the General Feature Model for GIS. The GFM can be found in GML and ISO19109. For example, in the IFC Kernel is IfcRoot which is the super type of IfcObjectDefiition, IfcPropertyDefinition and IfcRelationship.

IFCs have several methods to extend the basic types of the IFC specification to specific industry domains: IfcTypeProduct and Domain Data Models.

• The product type (IfcTypeProduct) defines a list of property set definitions of a product and an optional set of product representations. It is used to define a product specification (i.e. the specific product information, that is common to all occurences of that product type). A product type is used to define the common properties of a certain type or style of an object that may be applied to instances of those products to assign a specific style to them. Product types may be exchanges without being already assigned to products.

• Several Domain Data models are defined in the non-platform part of the IFC specification (Figure 20), e.g., Architecture Domain, Facilities Management Domain, Structural Analysis Domain. For example, the IfcConstructionMgmtDomain schema defines concepts in the construction management (CM) domain. Together with the IfcProcessExtension and IfcSharedMgmtElementschema it provides a set of models that can be used to exchange information between construction management applications.

One area for study in OWS-4 is to apply the previously developed GML Application Schema tools to the support development of domain specific and product specific extensions of IFC.

(A set of UML Models for IFC is under development and may be available to OWS-4. If this occurs, location of the UML models for IFC will be announced as a clarification.)

4.5.5.2.4 TransXML

Page 85 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

The objectives of this project are to develop broadly accepted public domain XML schemas for exchange of transportation data, and a framework for development, validation, dissemination, and extension of current and future schemas. This project will focus on four key business areas that have been identified as the initial focus for AASHTOWare XML migration: 1) Survey/Roadway Design, 2) Transportation Construction/Materials, 3) Highway Bridge Structures, and 4) Transportation Safety. Ultimately TransXML will encompass a broader set of schemas for all crucial transportation business areas (including ITS, for example.)

4.5.5.2.5 Coordinate Reference Systems

OGC Abstract Specification Topic 2, Spatial referencing by coordinates, defines Coordinate Reference Systems using UML. OGC Topic 2 is the basis of a joint project with ISO TC211 to revise ISO 19111:2003, Spatial referencing by coordinates. OGC GML implements the CRS abstract model in OGC Topic 2 in XML. GML is also a joint project with ISO TC211 were it is known as project ISO 19136. Consistent with OGC AS Topic 2, GML defines six schema documents for encoding the definitions of coordinate reference systems and coordinate operations, explaining their contents, structure, and dependencies. Those six schema as defined in Clause 12 of the GML specification are a) referenceSystems.xsd b) coordinateReferenceSystems.xsd c) datums.xsd d) coordinateSystems.xsd e) coordinateOperations.xsd f) dataQuality.xsd

These schema documents are available at http://www.opengis.net/gml

A fundamental concept of OGC AS Topic 2 (ISO 19111) is that of a Coordinate Reference System (CRS) which is composed of a Coordinate System and a Datum. Examples of Coordinate Reference Systems include: Geographic, Geocentric, Projected, and Engineering. Examples of Coordinate Systems include: Cartesian, ellipsoidal, spherical, cylindrical, linear. A datum defines the position of the origin, the scale, and the orientation of a coordinate reference system. Examples of datums include geodetic, vertical, and engineering. Coordinate systems and datums are constrained to be used with only certain CRSs. For example Cartesian CS is used only with Geocentric, Projected, and Engineering CRSs.

For IFC information models a fundamental assumption is that all geometry shall be defined in a right- handed rectangular Cartesian coordinate system with the same units on each axis. A common scheme has been used for the definition of both two-dimensional and three-dimensional geometry. Points and directions exists in both a two-dimensional and a three-dimensional form, these forms are distinguished solely by the presence, or absence, of a third coordinate value. Complex geometric entities are all defined using points and directions from which their space dimensionality can be deduced. (See IFC2x Edition 3: IFCGEOMETRYRESOURCE). IFCs do not directly represent datums. The IfcSite object does contain reference latitude, longitude and other methods to geolocate the site.

For OWS-4, merging of GIS and CAD data occurs in the CAD/GIS Client. The client will receive GML data in a variety of CRSs as discussed above. The IFC data will be in a Cartesian CS with other data indicating where to locate the CAD model. The OWS-4 CAD/GIS Client developer will be the primary source of change requests recommended for GML and IFC to readily collocate CAD/GIS data.

Page 86 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

Secondary reference: “Comparison of gml3.0 and IFC2x(2),” Thomas Liebich, AEC3 Ltd., IFG Project Phase 1, 27 May 2004

4.5.5.2.6 Schema Maintenance and Tailoring

(Reference for this section is an OWS-3 IPR that has been voted to be a Discussion Paper – “OWS-3 Schema Maintenance and Tailoring,” Clemens Portele, Editor, OGC IPR, OGC document 05-117, Version: 0.0.7, 2005-11-03.)

OGC has developed a schema tailoring process for the application schema development. The process was developed for UML and GML. In the CAD/GIS/BIM thread, the process is extended to IFCs. The process follows these steps.

- Creation of Application Schemas in UML using IFCs. Application Schemas are developed for the domains relevant to CAD/GIS Use Cases.

- Derivation of the XML Application Schemas for all the UML application schemas using the ShapeChange UML-to-GML-Application-Schema (UGAS) conversion tool. For more information see: UGAS Tool (OWS-3 GeoDSS IPR) (OGC document 05-118)

- Manipulation of the XML Application Schemas using a Schema Assembly Tool

Page 87 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

4.5.5.3 CAD/GIS/BIM Computational Viewpoint

The geospatial world has seen a transition from file-based approaches to database management system (DBMS) approaches and, more recently, service oriented architectures (SOA) in particular OGC Web Services. In contrast, recall the statement from the NIST study in the Enterprise Viewpoint, that “there is still widespread use of paper as a medium to capture and exchange information and data among construction project participants.” While information technology developments are moving to the construction engineering marketplace, “to date, CAD systems are still dominated by a file-based use, despite the fact that all modern CAD systems have connections to a DBMS” (From “Large-scale 3D Data Integration: Challenges and Opportunities,” S. Zlatanova and D. Prosperi Editors, Taylor and Francis, 2006.)

In order to achieve the objectives of the BIM vision, the CAD systems will need to develop a service oriented architecture. This has begun in an IAI SABLE Project on a services oriented architecture compatible with IFCs. (http://www.blis-project.org/~sable/)

SABLE means Simple Access to the Building Lifecycle Exchange. In short SABLE is about harmonizing the access to IFC Model Servers and the access to the data that persists on these servers by defining a common low level API to IFC Model Servers and a set of high-level domain specifics API to the IFC data model. A developer toolbox is available for the SABLE Server developed by Eurostep. The main purpose is as an application server giving access to single/mutiple product model servers in a standard way. http://www.iai-international.org/software/Tools%20for%20IFC%20developers.html#IFC_toolboxes_high_level

Figure 21 - IAI Sable Services Architecture

Of particular interest to OWS-4 is the SABLE Model Servers Web Service Specifications.2 The SABLE project has defined a series of use cases to aid development of the service interface. Comparison of the SABLE use cases and interfaces to the OWS Architecture, OWS Common and specific OGC Web Services, e.g., WFS, will be a source of progress in CAD/GIS integration.

2 http://www.blis-project.org/cgi-bin/cvsweb.cgi/%7Echeckout%7E/sable/specifications/Modelservers/MSWS/Use_Cases/index.html

Page 88 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

The CAD Model Server to be developed in OWS-4 will be developed following the established principles of the OGC Web Services:

• “OpenGIS® Web Services Architecture Description,” an OGC Best Practice, OGC document 05- 042r2. This document summarizes the most significant aspects of the Open Geospatial Consortium (OGC) web services architecture. This architecture is a service-oriented architecture, with all components providing one or more services to other services or to clients.

• “OGC Web Services Common,” OGC Document 03-088r6. This document specifies many of the aspects that are, or should be, common to all or multiple OGC Web Service (OWS) interface Implementation Specifications. These common aspects are primarily some of the parameters and data structures used in operation requests and responses. Of course, each such Implementation Specification must specify the additional aspects of that interface, including specifying all additional parameters and data structures needed in all operation requests and responses.

• Specific OGC Web Service Implementation Specifications provide the interfaces consistent with the two previous bullets: WMS, WFS, WCS, CS/W, etc.

CAD client is a robust client for handling CAD and GIS data suitable for a high-end CAD user. The DSS Client will also be a server to the CAD data, but it is not expected to provide as much end-user functionality for the CAD data as the CAD client.

4.5.5.4 CAD/GIS/BIM Engineering Viewpoint

Figure 22 shows the components for the CAD/GIS/BIM thread. Names for the operations are prelimininarly labled as just “get”. Also note the preliminary label indicating a transaction of data from one CMS to another CMS.

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.

Figure 22 - CAD/GIS/BIM Engineering Diagram

Page 89 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

4.6 OGC Location Services (OpenLS) 4.6.1 Scope

OpenLS is structured as a set of services. Each service is independently accessible via an XML API. The services use an OpenLS-specific XML messaging format intended for network data transfer HTTP. The seven existing services defined for OpenLS are: 1) the Directory Service provides access to an online directory (e.g. Yellow Pages) enabling an application to find the location of a specific or nearest place, product or service. 2) the Gateway Service retrieves the position of a known mobile terminal from the network. This interface is modeled after the LIF/OMA Mobile Location Protocol (MLP), Standard Location Immediate Service, specified in OMA (Open Mobile Alliance) MLP 3.0. 3) the Geocoding Service converts a text description of a location, such as a place name, street address or postal code to a position structured as Point geometry (see GML Specification for OGC geometry). 4) the Reverse Geocoding Service converts given position into a normalized description of a feature location (Address with Point), where the address may be a street address, intersection address, place name or postal code. 5) the Route Service determines travel routes and navigation information between two or more points. 6) the Navigation Service is an enhanced version of the Route Service, which determines routes between two or more points and the associated navigation information. 7) the Presentation Service creates maps and other graphic depictions of selected geospatial data, with a set of ADT’s as logical layers. The current OpenLS specifications are commercially useful in their present form. They enable the intended functionality, they are implementable, they are internally complete and consistent and they interface with the external environment using primitives shared with other geospatial domains.

The OpenLS thread in OWS-3 created a new Tracking Service described in OGC document 2006-026R0.

This Tracking Service has three main features: 1) A standard interface to a service that stores and retrieves tracking data. 2) A concise encoding scheme for efficient communication of location data over a low-bandwidth network such as provided by current "2.5G" CDMA or GPRS providers. 3) A standard for efficient storage and retrieval of location data at the server. OWS-3 addressed only the first item in the above list. The remaining two items were considered in OWS-3 and some design and implementation was completed. Issues remain regarding the necessity, relevance, and commercial value of extension to these items. One of the “refinements” to the Tracking Service addressed in OWS-4 will be a better resolution of those issues and the inclusion or exclusion of various aspects of these items. The practical application of the Tracking Service is to support near real-time tracking of vehicles and personnel equipped with suitable tracking devices and CDMA or GPRS data networks. "Near real time tracking" is meant to provide for an active display of accurate location information of multiple (up to 100) tracked assets with minimal latency. A use case is an E911 emergency dispatch center geographic display of emergency responder personnel and vehicle locations. There will be some latency in the display system itself and in the database retrieval of the location information to be displayed, but the OLS tracking standard should not introduce latency greater than 5 seconds, including network delays, on current commodity-priced tracking devices such as GPS-equipped smart phones. Ideally, most of the latency should appear as network delays with minimal latency introduced by the CPU cycles required to generate an encoded location on a device and decode it for storage at the server. As true 3G wireless networks appear, the latency should diminish to less than 1000 milliseconds, not including acquisition of GPS data.

Page 90 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

The tracking service should support position reports as frequently as once per second for fast moving assets. The Tracking Service should support a base level of operation just sufficient to support a simple “moving dots on a base map” tracking application. In addition there may additional optional capabilities as follows: 1) The means to specify when (time period) the device or mobile device should be tracked. 2) The means to specify the criteria (temporal & spatial) that should be used to generate a notification or alert. This includes periodic updates and notifications when a mobile device enters or exits a region, starts, stops, moves a specific distance or when a mobile device interacts with another mobile device. 3) A well-defined mechanism and message format used to send a notification or alert to the client application. 4) The means to access position/time/speed/direction information for one or more mobile terminals/assets through the Gateway Service. 5) The means to store position/time/speed/direction information for one or more mobile terminals/assets for a designated time period and sampling periodicity. 6) The means to fetch position/time/speed/direction information tracks for one or more mobile terminals/assets for a designated time period. The OpenLS enhancements should be harmonized with JSR 179 and the Parlay X API where reasonable and possible. For example, if the device reports a position due to a geofence violation, the location reporting protocol should include an indication of which fence was violated, along with the location report. There should be a way to store the fence geometry on the server, and download the fence geometries from the server. The focus of OpenLS in OWS-4 will be to refine and test the design developed in OWS-3. We also hope to further develop the Micro-Features prototype. In addition, we will look at SOAP messaging rather than an OpenLS-specific request-response structure as a way to simplify the specification and. The following is an outline of the range of OWS-4 experiments expected: 1) Refine and test the Tracking Service: a. Core functionality i. position reporting to a central location server ii. position query of the central location server by subscriber or mobile terminal ID iii. (optional) geo-fencing with fence-violation notification iv. (optional) latency-free predictive position queries b. Extensions to the Presentation Service if and as needed to support dynamic display of positions from the Tracking Service c. Extensions to the Presentation Service to include 3D views as well as maps d. Creation of a new service or extensions to the Navigation Service to include indoor and pedestrian navigation 2) Refine the “Micro Feature” protocol. 3) Define an alternative request/response structure using SOAP messaging and WSDL service descriptions.

4.6.2 Planned Activities As part of OWS 4.0 we will continue to refine the Tracking Service protocol developed as part of OWS 3.0. We will also focus on creation of interoperable clients that go beyond the simple demonstration of Micro Features in OWS 2.0. Continuing research will be performed in areas called out in our report delivered as part of OWS 2.0.

The OpenLS Thread will find opportunities to apply the Tracking Service within the scenarios of the other threads.

Page 91 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

4.6.2.1 Refine and Test the Tracking Service

This is the primary focus for OpenLS in OWS-4.

4.6.2.1.1 Specification Refinement 1) Provide a mechanism for directory service requests to specify the list of properties to return with each feature. This includes ensuring that all types of properties (spatial and non-spatial) can be returned with features. 2) Enhance filtering mechanism to limit or qualify features returned from a directory service query. In a manner similar to WFS, it needs to be able to filter based on an arbitrary set of properties and specify the filter matching operation. Matching operations include: Exact match, begins with, contains, like, less then, greater then, etc. 3) Enhance Directory Service to deal with enhanced query capabilities and a greater variety of directory information types. 4) Add the ability to provide access to POIs where they can be obtained from navigable network “links” directly. This activity is intended to enhance performance. 5) Some work in the area of adapting to positioning and navigation in and near buildings and other structures is also planned. It is important 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.

4.6.2.1.2 More Interoperability Testing

The purpose is to put more stress on the existing specification so that it will me more suitable for a wide range of interoperable public and commercial applications before it enters the formal standardization process. The relevant activities are to 1) Implement more than one Tracking Server. 2) Use more than one type of mobile terminal.

4.6.2.2 Further Development of Micro Maps

The Open Geospatial Consortium (OGC) has sponsored an Open Web Services (OWS) 2.0 collaborative research program. As part of OWS 2.0, a map data Presentation Service was developed. A Presentation Service supplies vector map data to clients, typically "offboard" navigation systems. The goal of this experiment is to settle on the most lightweight yet sufficiently detailed delivery of content to insure that the Presentation Service will function adequately under real-world conditions. Starting with baseline XML schemas developed in collaboration with the Open Location Services (OLS) working group, we performed static analysis of instance XML documents generated from real map databases. We iteratively improved our XML schema, ultimately yielding XML documents less than 10% of the baseline size and less than 30% the size of a GIF image. We developed a client and server that demonstrate the practicality of the protocol that was developed. The overarching goal of our OWS 4.0 work on Micro Maps will be to achieve a level of stability, acceptance, and harmonization with other OLS protocols such that we can proceed to standardize the Micro Map protocol as part of OLS 2.0.

Page 92 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

4.6.2.3 SOAP/WSDL Messaging Framework

Investigate and possibly implement an OpenLS Messaging Framework based on SOAP 1.2. The goal is to determine if and how we might adopt SOAP messaging in place of the OpenLS-specific messaging used in the current specification. 4.6.3 OGC Reference Model (ORM) Viewpoints

4.6.3.1 OpenLS Enterprise Viewpoint

OpenLS markets are wide and varied. They include any markets applications for consumers, business and government users where location-enabled mobile assets or mobile terminals are or may be employed, including: • Wireless Location-Based Services (LBS) • Automatic Vehicle Location (AVL) systems • Telematics • Asset tracking and management • Seamless indoor-outdoor navigation service • Emergency services and homeland security • Mobile workforce applications (field operations, field service, field inventory, etc.) Figure 23 illustrates a typical operational configuration for a wireless mobile phone service provider. Subscribers receive their services over the network via a Portal Platform, which handles authentication, billing and other basic service needs. Application services run on a designated Service Platform. The OpenLS platform is called upon to be perform location-based services, as needed. A GMLC/MPC determines positions of mobile terminals. The OpenLS platform may also call upon Web-based geospatial data and/or processing capabExtendingilities via OpenLS OGC Web Platform Services. with OGC Web Services

Portal & Service CORE Platforms NETWORK

Mobile Internet Switch

OGC Web OpenGIS® Services Location Services At work On the go (OpenLS) or home The OGC Web Services initiatives are rapidly expanding the variety of services that will be available to wireless users. GMLC/MPC Position Determination Methods: LDT/PDE: cell/ID/sector, A-GPS, E-OTD, AOA, TDOA, TOA

Figure 23 - OpenLS Concept

4.6.3.2 OpenLS Information Viewpoint

OpenLS is mostly based on a set of internally consistent ADTs and well-known types. At those points where interaction with other services or systems is possible, the data types and interfaces of those external

Page 93 Due Date: March 14, 2005 Annex B: OWS-3 Architecture services or systems are adopted. The only such external interaction at the present state of development is the use of GML 3.0.

4.6.3.3 OpenLS Computational Viewpoint

The Core Services are location-based application services that form the Services Framework for the GeoMobility Server.

Core Service Network GeoMobility Server Provider

OpenLS-based Applications OpenLS Personal Navigator, Concierge, Tracker… Portal / Service Platform

L (Authentication,

e p Billing, etc.)

O Position OpenLS Core Services

Determination •Route •Gateway (LIF) L

LIF n Equipment •Presentation •Directory e

(GMLC/MPC) –Route Display O –Map Display Applications OpenLS –Route Directions Display Residing on •Geocode / Reverse Geocode Mobile Terminals Location Content & Desktops •Road Networks •Directories •Navigation Info •Addresses •Maps •Traffic Info

Figure 24 - The GeoMobility Server

4.6.3.3.1 Directory Service

This service provides subscribers with access to an online directory to find the nearest or a specific place, product or service. Through a suitably equipped OpenLS application, the subscriber starts to formulate the search parameters in the service request, identifying the place, product or service that they seek by entering the name, type, category, keyword, phone number, or some other ‘user-friendly’ identifier. A position must also be employed in the request when the subscriber is seeking the nearest place, product or service, or if they desire a place, product or service at a specific location or within a specific area. The position may be the current Mobile Terminal position, as determined through the Gateway Service, or a remote position determined in some other manner. The directory type may also be specified (e.g. yellow pages, restaurant guide, etc). Given the formulated request, the Directory Service searches the appropriate online directory to fulfill the request, finding the nearest or specific place, product or service, depending on the search criteria. The service returns one or more responses to the query (with locations and complete descriptions of the place, product, or service, depending upon directory content), where the responses are in ranked order based upon the search criteria.

4.6.3.3.2 Gateway Service

Page 94 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

This is the interface between the GeoMobility Server and Location Server that resides in the GMLC or MPC through which OpenLS services obtain position data for Mobile Terminals. This interface is modeled after the MLP specified in LIF 3.0 for Standard Location Immediate Service.

4.6.3.3.3 Geocoding and Reverse Geocoding Services

The Geocoding Service determines a geographic position, given a place name, street address or postal code. It also returns a complete, normalized description of the place (which is useful, say, when only partial information is known). The Reverse Geocoding Service determines a complete, normalized place name/street address/postal code, given a geographic position. Both the geocoder and reverse geocoder may return zero, one, or more responses to a service request, depending on subscriber request information, the algorithm being employed, and the match criteria.

4.6.3.3.4 Presentation Service

This service renders geographic information for display on a Mobile Terminal. Any OpenLS Application may call upon this service to obtain a map of a desired area, with or without map overlays that depict one or more OpenLS ADTs, such as Route Geometry, Point of Interest, Area of Interest, Location, Position and/or Address. The service may also be employed to render route directions from Route Maneuver List ADT and/or Route Instructions List ADT.

It may be desirable to add a very low overhead dynamic update capability for positions obtained from the Tracking Services.

It may be desirable to allow other depictions of spatial information such as 3D views,

4.6.3.3.5 Route/Navigation Service

This service determines a route for a subscriber. The subscriber must use a navigation application to set up the use of the service. They must indicate the start point (usually the position acquired through the Gateway Service, but this could be a planned trip from a specified location, say, from their home), and the endpoint (any location, like a place for which they only have the phone number or an address, or a place acquired through a search to a Directory Service). The subscriber may optionally specify waypoints, in some manner, the route preference (fastest, shortest, least traffic, most scenic, etc.), and the preferred mode of transport. The subscriber may optionally store a route for as long as needed, thus requiring the means to also fetch a stored route.

4.6.3.4 OpenLS Engineering Viewpoint

Figure 25 conveys the general architecture. An end-user application service such as a Buddy Finder, Personal Navigator or Concierge Service running on a host Service Platform calls upon OpenLS services for location-based content and processing, as needed. In this figure we also show a possible configuration for the new traffic and tracking services, with back-office applications. Tracking Service will need timely access to mobile device location information. These services can access the GMLC / MPC directly using OMA/LIF MLP. The challenge OGC addresses through OpenLS is to define the foundational components and related specifications for near-time tracking, and navigation services.

Page 95 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

End-user Application Portal & Service Mobile Terminal Gateway Service Service Platforms (front-end)

Route Presentati Geocoder Directory Tracking LIF MLP Determinati on Service Service Service Service on Service

GMLC/MPC Route Map Address Directory Track Data Data Data Data (e.g., Data Y. P.)

Emergency Response Command and Control

Back Office Apps OpenLS 2 Current OpenLS

Figure 25 - OpenLS Engineering View

4.7 Compliance and Interoperability Test and Evaluation (CITE) 4.7.1 Scope

Page 96 Due Date: March 14, 2005 Annex B: OWS-3 Architecture ready for participant’s to use in advance of the OWS-4 kickoff. However, if the software is not ready, some of the work items discussed below can not be performed, and will be removed, or re-scoped at the appropriate time.

Validating compliance with an OGC specification means verifying that a software product has implemented the specification correctly by testing the software interface for response and behavior that is outlined in the specification. Verifying compliance to the standard is necessary in order to achieve interoperability. As a result, geospatial application vendors desire to provide their potential costumers a means to verify adherence to OGC standards as a measurable discriminator for the interoperability of software products. Similarly, users desire assurance that acquired software components will interoperate with their existing investments in OGC-compliant technology. The Conformance and Interoperability Test and Evaluation (CITE) thread is intended to provide the geospatial industry (consumers and vendors) a methodology and tools which will test compliance with OGC web services.

4.7.1.1 Problem and Objectives

OGC has successfully developed and deployed a compliance and certification program based on a commercial test engine provided by the OpenGroup (OpenGroup engine). While this software has been an excellent resource for compliance testing of WCS, WMS and WFS specifications, it is not able to provide adequate testing of XML schema-based information models, such as GML, SLD and their associated profiles and application schemas. Going forward, OGC is interested in evaluating a new open source test engine developed by Northrup Grumman/TASC (NG engine) as it may be less expensive to maintain (due to no licensing costs) and improve (due to full access to the source code).

The CITE thread will develop a suite of compliance test scripts for testing and validation of products with interfaces implementing the OpenGIS® specifications listed below. These scripts will be written for both the OpenGroup engine and the NG engine to evaluate the feasibility of migrating all OGC compliance testing to the NG engine. The participants in this thread will develop Interoperability Program Reports (IPRs) detailing this evaluation, and outlining the developed test guidelines and test scripts. These IPRs will be presented to the Technical Committee and Planning Committee for approval.

All development activities within the CITE thread should result in products that are fully functional on a Linux platform on the OGC IT infrastructure, excluding reference implementations which may be served from a vendor’s facility.

4.7.1.2 Planned Activities

In general, the planned activities for the CITE thread involve creating compliance test scripts for the required technologies. However, due to the fact that the NG engine is open source, if additional functionality is needed to complete the test requirements, it is expected that the participant will be able to make enhancements to the engine at the code level. In your proposal, please describe your ability and willingness to work with the technologies the NG engine is built upon—i.e. Java and the Saxon XSL interpreter.

4.7.1.2.1 WMS

• Develop compliance test script suites for WMS 1.3 for the OpenGroup and NG engines.

• Port the compliance test script suite for WMS 1.1 from the OpenGroup to the NG engine.

• Develop a reference implementation for WMS 1.3.

Page 97 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

4.7.1.2.2 WFS

• Develop compliance test script suites for WFS 1.1 with filter encoding 1.1 and transactional support for the OpenGroup and NG engines.

• Port the compliance test script suite for WFS 1.0 with filter encoding 1.0 from the OpenGroup to the NG engine.

• Develop a reference implementation for WFS 1.1 with filter encoding and transactional support.

• Develop a test script suite that defines a compliance regime for a minimal WFS, called WFS- Files—in essence a Web Feature Service with a target implementation on a file based HTTP platform, such as a Web server with no database or geospatial support. The specific features of this test suite will be determined in the project, but it is envisioned that this requirement will not deviate from the WFS 1.1 implementation specification, but ignore all optional features. For example the following features may not be supported:

o Filter encoding

o Bounding box constraints

o Anything other than retrieval of all features

o Coordinate transformation

o Sophisticated version negotiation

• Develop a test script suite that defines a compliance regime for a WFS with a target implementation on a database-driven HTTP platform, called WFS-Database, such as a content management system with no geospatial support. The specific features of this test suite will be determined in the project, but it is envisioned that this requirement will not deviate from the WFS 1.1 implementation specification, but ignore most optional features. For example the following features may not be supported:

o Filter encoding

o Coordinate transformation

4.7.1.2.3 CS/W

• Develop compliance test script suites for CS/W 2.0 ebRIM profile for the NG engines.

• Develop a reference implementation for CS/W 2.0 ebRIM profile.

4.7.1.2.4 WCS

• Update compliance test script suite for WCS 1.0 to comply with approved corrigenda.

• Port the compliance test script suite for WCS 1.0 from the OpenGroup to the NG engine.

• Develop compliance test script suite for WCS 1.1 for the OpenGroup and NG engines.

• Develop a reference implementation for WCS 1.1.

Page 98 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

4.7.1.2.5 OpenLS (Tier 2)

• Update and refine test script suite for 1.0

• Port the compliance test script suite for OpenLS 1.0 from the OpenGroup to the NG engine.

• Develop compliance test script suite for OpenLS 1.1 for the OpenGroup and NG engines.

4.7.1.2.6 GML

Beyond industry-standard XML schema and instance validation, robust compliance testing of information models such as those described by XML schema does not exist. The purpose of this task is to investigate how OGC should extend XML validation to better ensure interoperability of this key component of OGC technology. Some issues that have already been identified are:

• In many profiles, some constraints exist only in the narrative of the specification and are not captured by the XML schema. These must be captured in the compliance testing.

• XML validation error messages are usually quite generic. How can we combine XML validation with test scripts to produce more informative error reporting?

• What issues exist in areas such as profile namespace definition and application schema design that impact the interoperability of GML profiles with each other and the generic GML schema?

Participants will address these concerns while using the NG engine to develop a compliance test suite for at least these GML profiles:

• GML Simple Features

• GML Point Profile

• GML for GeoRSS

• GML 3.1

• GML 3.2

4.7.1.2.7 Context

All of the issues mentioned above in the discussion of compliance testing for GML information models apply here. In particular, the participant(s) will address these concerns while using the NG engine to develop a compliance test suite for the following Context encoding specifications:

• Web Map Context 1.0

• Web Map Context 1.1

• Open Web Context 0.0.3

4.7.1.2.8 Comparison of OpenGroup engine versus NG/TASC engine

Page 99 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

• All participants who work on test script suites that are developed for both engines will contribute to an IPR documenting their findings. One participant will be tasked with editorial responsibility for the IPR.

4.7.2 Requirements

WMS

1) Develop compliance test script suites for WMS 1.3 for the OpenGroup and NG engines.

2) Port the compliance test script suite for WMS 1.1 from the OpenGroup to the NG engine.

3) Develop a reference implementation for WMS 1.3.

WFS

1) Develop compliance test script suites for WFS 1.1 with filter encoding 1.1 and transactional support for the OpenGroup and NG engines.

2) Port the compliance test script suite for WFS 1.0 with filter encoding 1.0 from the OpenGroup to the NG engine.

3) Develop a reference implementation for WFS 1.1 with filter encoding and transactional support.

4) Develop a test script suite that defines a compliance regime for a minimal WFS—in essence a Web Feature Service with a target implementation on a file based HTTP platform, such as a Web server with no database or geospatial support.

5) Develop a test script suite that defines a compliance regime for a WFS with a target implementation on a database-driven HTTP platform.

CS/W

1) Develop compliance test script suites for CS/W 2.0 ebRIM profile for the NG engine.

2) Develop a reference implementation for CS/W 2.0 ebRIM profile.

WCS

1) Update compliance test script suite for WCS 1.0 to comply with approved corrigenda.

2) Port the compliance test script suite for WCS 1.0 from the OpenGroup to the NG engine.

3) Develop compliance test script suite for WCS 1.1 for the OpenGroup and NG engines.

4) Develop a reference implementation for WCS 1.1

OpenLS

1) Update and refine test script suite for 1.0

Page 100 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

2) Port the compliance test script suite for OpenLS 1.0 from the OpenGroup to the NG engine.

3) Develop compliance test script suite for OpenLS 1.1 for the OpenGroup and NG engines

GML

1) GML Simple Features test script suite

2) GML Point Profile test script suite

3) GML for GeoRSS test script suite

4) GML 3.2

Web Map Context

1) Web Map Context 1.0 test script suite

2) Web Map Context 1.1 test script suite

3) Open Web Context 0.x test script suite

Comparison of OpenGroup engine versus NG/TASC engine

4.7.3 Deliverables The following Interoperability Program Reports (IPRs) will be developed in OWS4-CITE and submitted to the OGC Specification Program at the completion of the OWS-4. All but the engine evaluation IPR will include the code for the completed compliance test script suites.

6) WMS Compliance Test IPR 7) WFS Compliance Test IPR 8) WCS Compliance Test IPR 9) CS/W Compliance Test IPR 10) GML Compliance Test IPR 11) WMC Compliance Test IPR 12) Compliance Test Engines Evaluation IPR

Implementations of the following Reference Implementations will be developed and tested with the respective Compliance Test Script. Source code for the reference implementations shall be delivered to OGC.

1) WMS Reference Implementation Update to WMS 1.3 2) WFS 1.1 Reference Implementation 3) WCS 1.1 Reference Implementation 4) CSW 2.0 Reference Implementation

Page 101 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

5) OpenLS 1.1 Reference Implementation

4.7.4 OGC Reference Model (ORM) Viewpoints

4.7.4.1 CITE Enterprise Viewpoint

The CITE thread provides a framework to test conformance of software components to OGC specifications. The foundation of this framework lies in the globally dispersed data exchange technologies provided by the Internet and World Wide Web. The Compliance Engine for an OGC specification accepts one or more Compliance Test Suites. These suites will be run against a candidate OGC-compliant software component. The results of the test will be codified in a Compliance Test Report, indicating success or failure and as much detail as possible regarding the reasons for such.

Passing the compliance tests means that a product should be interoperable with any other product that passes the same tests. In practice, compliance is not sufficient to guarantee interoperability, due to slight differences in implementations and imprecision in the original specification, combined with variances in performance that certain data sets may expose. This is why integration experiments and plugfests are key components of interoperability testing. However, compliance testing is a necessary, crucial step along this continuum.

4.7.4.2 CITE Information Viewpoint

The primary information concepts in CITE are the “test suite”, “test script”, a “test”, and an “assertion”. A test suite is a collection of test scripts that validate compliance with a named technology. The technology may be an OpenGIS® implementation specification, an encoding specification, or a profile or subset of either.

While a test script does not have a strict formal definition, the term is usually used to refer to a collection of tests that validate compliance with a particular Web service operation.

A test is an XML file covering one assertion, or statement of required behavior that is derived from a specification. Tests typically contain one or more requests that are sent to the service begin tested, and XPath expression(s) that are evaluated against the results to determin whether the test passed or failed.

The test files also contain textual information describing the assertion being tested and how the test is performed. The engine automatically assembles this information to generate an assertions document describing each test the test suite is capable of performing.

In addition to the tests, the engine can be configured to prompt the user for information in the form of "scopes" which determine which tests will be executed for the session, or "variables", which can be used in the tests themselves.

This information viewpoint applies to both the OpenGroup and NG engines.

Page 102 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

Compliance Test Suite Compliance OGC-compliant Engine server

Compliance Test Report

4.7.4.3 CITE Technology Viewpoint

Error! Reference source not found. below depicts the architecture of the NG engine. In developing tests for the NG Engine, participants have the option to extend the engine’s functionality by writing custom functions and parsers. These may either be developed in XSL, or when needed, Java 1.4 with the Saxon XSL interpreter [http://saxon.sourceforge.net/]. Since in this thread there is minimal work specified for upgrading tests currently deployed on the OpenGroup engine, there is no need for extended functionality, and therefore no need to have an in-depth view into the computational viewpoint of the engine.

Page 103 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

Select test suite

Starting test

Saxon XSLT XSL request request Web Service Preprocessor

test Response call-test XML Message Parser message Log Failure fail parameters call-function XSL Function results parameters call-function Java Function HTML Form form results Submitted form values

Figure 26 - Architecture of the NG engine

Page 104 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

Appendix A: OWS 4 references to other standards

This Appendix contains a selection of the specifications developed and released by other organizations that are relevant to OWS-4. Contact the OGC Tech Desk if you need assistance in gaining access to these documents ([email protected]). Latest versions of these documents need to be confirmed with the developing organizations.

Refer to the OGC website (http://www.opengeospatial.org/specs/?page=baseline) for the authoritative listing of adopted documents. Documents in the OGC Technical Baseline contain a list of other standards relevant to the specific topic of the document.

B.1. ISO TC211 International Standards

ISO Techncial Committee 211 is developing standards in the area of geographic information/geomatics. ISO TC211 and OGC have a Cooperative Agreement to coordinate and, on occasion, to jointly develop international standards. For the current status of the ISO TC211 projects listed below, visit the TC211 website: http://www.isotc211.org/

• ISO 6709 - Standard representation of latitude, longitude and altitude for geographic point locations

• ISO 19101 - Reference Model

• ISO 19101-2 - Reference model - Part 2: Imagery

• ISO 19107 - Spatial Schema

• ISO 19108 - Temporal Schema

• ISO 19109 - Rules for Application Schema

• ISO 19110 - Methodology for feature cataloguing

• ISO 19111 - Spatial referencing by coordinates - Revision of ISO 19111:2003

• ISO 19112 - Spatial Referencing by Geographic Identifiers

• ISO 19115 - Metadata

• ISO 19115-2 - Metadata - Part 2: Extensions for imagery and gridded data

• ISO 19116 - Positioning services

• ISO 19117 - Portrayal

• ISO 19118 - Encoding

• ISO 19119 - Services

• ISO 19123 - Schema for Coverage Geometry and Functions

• ISO 19125-1 - Simple feature access - Part 1: Common architecture

Page 105 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

• ISO 19125-2 - Simple feature access - Part 2: SQL option

• ISO 19128 - Web Mapping Service

• ISO 19130 - Sensor and data models for imagery and gridded data

• ISO 19132 - Location based services - Reference model

• ISO 19135 – Procedures for registration of items of geographic information

• ISO 19136 - Geography Markup Language

• ISO 19139 - Metadata - Implementation specification

• ISO 19141 - Schema for moving features

• ISO 19142 - Web Feature Service

• ISO 19143 - Filter encoding

B.2. Other ISO/IEC/ITU International Standards:

• ITU-T H.264 2005 (MPEG-4)

• ISO/IEC JTC1/SC29/WG11 N4668, Coding of Moving Pictures and Audio (MPEG 4). http://www.chiariglione.org/mpeg/standards/mpeg-4/mpeg-4.htm

• ISO/IEC JTC1/SC29/WG11N5525, Coding of Moving Pictures and Audio (MPEG 7). http://www.chiariglione.org/mpeg/standards/mpeg-7/mpeg-7.htm

• ISO/IEC JTC1/SC29/WG11/N5231, Coding of Moving Pictures and Audio (MPEG 21). http://www.chiariglione.org/mpeg/standards/mpeg-21/mpeg-21.htm

• ISO/IEC 15444-9:2005 Information technology -- JPEG 2000 image coding system: Interactivity tools, APIs and protocols (JPIP) http://www.jpeg.org/jpeg2000/j2kpart9.html

B.3. IEEE 1451 international standards http://www.motion.aptd.nist.gov/ • IEEE Std 1451.1-1999, Network Capable Application Processor (NCAP) Information Model for smart transducers • IEEE P1451.0, Common Functions, Communication Protocols, and Transducer Electronic Data Sheet (TEDS) Formats • IEEE Std 1451.2-1997, Transducer to Microprocessor Communication Protocols and Transducer Electronic Data Sheet (TEDS) Formats • IEEE Std 1451.3-2003, Digital Communication and Transducer Electronic Data Sheet (TEDS) Formats for Distributed Multidrop Systems d • IEEE Std 1451.4-2004, Mixed-mode Communication Protocols and Transducer Electronic Data Sheet (TEDS) Formats • IEEE P1451.5, Wireless Communication and Transducer Electronic Data Sheet (TEDS) Formats –

Page 106 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

• IEEE P1451.6, A High-speed CANopen-based Transducer Network Interface B.4. OASIS international standards

• Common Alerting Protocol (CAP)

• Emergency Data Exchange Language (EDXL) Distribution Element, (EDXL-DE)

• eXtensible Access Control Markup Language (XACML) V1.0 OASIS February 2003

• OASIS Web Services Business Process Execution Language (BPEL)

• WS-Security

• Security Assertion Markup Language (SAML) • Universal Description, Discovery, and Integration (UDDI)

B.5. W3C international standards relevant to OWS-4:

• Extensible Markup Language (XML) – several parts

• XML Linking Language (XLink)

• Web Services Description Language (WSDL)

• Simple Object Access Protocol (SOAP)

• Web Ontology Language (OWL)

B.6. IETF international standards

• Uniform Resource Identifiers (URI): Generic Syntax (RFC 2396)

• (many other IETF standards are referenced in OpenGIS Implementation Specifications).

B.7. ANSI US National Standards

• Data format standard for radiation detectors used for Homeland Security, ANSI N42.42, to be published by ANSI and IEEE

B.8. International Alliance for Interoperability standards http://www.iai-international.org

• IFC Specifications

• IFC/ifcXML Specifications

B.9. National government specifications

• DGIWG/TSMAD Profile of ISO 19107, Edition 4

Page 107 Due Date: March 14, 2005 Annex B: OWS-3 Architecture

• Geospatial Symbols (GeoSym) for Digital Displays, NGA. http://www.nima.mil/cda/article/0,2311,3104_12137_118865,00.html and http://www.nima.mil/ast/fm/acq/mil89045.pdf

• NSG Feature Catalog

• NGA’s Mission Specific Data (MSD) Levels 1 – 5

• Digital Aeronautical Flight Information File (DAFIF) data.

• FAA/EuroControl’s Aeronautical Information Exchange Model (AIXM)

Page 108 Due Date: May 3, 2006 Annex B: OWS-4 Architecture

Appendix B: Scenario Narrative

Context

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 4 (OWS-4).

In particular, it motivates the use of interfaces and encodings to be developed or enhanced in the various threads of this Initiative. This scenario incorporates elements of a multi-faceted operation that requires setup of a temporary medical response facility within an existing military installation. The scenario 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, including building information and structure available in CAD data and overall facility layout (roads, buildings, and related infrastructure) using CityGML models and Industry Foundation Classes (IFCs), some of which are only accessible by exercising digital rights mechanisms. Ultimately, analysis, portrayal, and in-building 3D visualization would enable operational coordinators to direct response teams, provide bulletins to public safety agencies, and monitor the ongoing status of the operation.

Scenario

The joint operations support activity involving civil and military participants is investigating sites for a temporary medical response facility. An evaluation of unoccupied buildings at a closed section of the military airfield installation appears suitable for this facility. Army GIS analysts are asked to gather as much information about the location, its facilities and anything within a surrounding 200-meter security perimeter as possible to secure the site.

Using a lightweight open source GML 3.2 enabled client the GIS analyst makes a spatial query of an OGC CS/W compliant Catalog to locate any data over the requested area. The query identifies links to two local road maps (one vector and one raster), a CAD drawing of the airfield facility and a sewer system diagram. The analyst performs a quick analysis of the imagery holdings found in Google Earth. He quickly determines this imagery is sufficient to provide an overall view, but is somewhat dated and not of sufficient resolution. Therefore, additional imagery over the airport and 200 meter perimeter is needed to provide a more detailed picture to include temporal and accuracy requirements. Using the lightweight open source client, the analyst queries the additional catalog using spatial, temporal and quality indicators (for positional accuracy) and restricted to a series of “pre-defined trusted sources” to locate any data holdings that satisfy specific temporal and accuracy requirements. The catalog query results identify a suitable Web Feature Service – Transactional (WFS-T) which can provide both vector data and a Web Coverage Service (WCS) with imagery data in GMLJP2 format that meets the spatial, temporal, and quality requirements as specified by the analyst.

The analyst chooses to access orthophoto coverage over the area using the JPIP-enabled WCS for the imagery. This service enables dynamic access (roam, zoom, pan, chip, etc.) in order to select the imagery coverage in a more interactive method for analysis.

Based on review of the resulting WFS-T metadata contents, the analyst determines the vector data is based on the MSD3 data content specification. Using a Schema Subsetting Tool via interface from the lightweight open source client, the analyst tailors a GML application schema to request specific feature and attribute content from the full MSD3 dataset. The analyst creates a schema for airports, runways/taxiways/aprons, airport facilities, roads, walls, fences, and buildings. Using a Filter Encoding request of a WFS-T the user restricts the spatial extent to retrieve only those features that fall within the 200-meter security perimeter of the temporary field

Page 109 Due Date: May 3, 2006 Annex B: OWS-4 Architecture hospital. Given the anticipated size of the output results from the WFS, the analyst determines that a zipped format response would be necessary. By examination of the WFS response capabilities document, the analyst determines that the WFS offers an optional zipped format response. Using the Business Process Execution Language (BPEL) the Army analyst creates a workflow to request the data and imagery. The BPEL workflow is designed to execute several functions including use of data tailored schema defined above. The workflow then sends the requested data, which is then zipped by the client upon receipt.

The Army analyst gathers the different sources from a combination of WFS and WMS, including the open source data, GML data and imagery. Identification of the different sources is provided out in a Web Context Document. The analyst submits a notification to other Army analysts responsible for construction and security.

Army security and construction analysts working together evaluate the site, the selected building structures and perimeter information. First, analysts determine the need for possible road closures and their locations. Locations for placement of IEEE 1451 sensors (motion and radiation) are chosen to secure the perimeter, including sewers. Using the 3D CAD file for the building and Web 3D visualization tools, construction and security analysts collaborate on planning a building addition to serve as an emergency room with security sensors in place.

Construction analysts are tasked to evaluate the site for a temporary heliport on the grounds. Using the 3D CAD/GIS Client to render the CAD plans and GIS models, they determine the location of the heliport based upon the surface landing location and the AIXM model for a heliport. These additions to the facility will necessitate taking one of the airport runways, taxiway and apron out of service. The construction analysts create several views of the construction model over time and insert in the CMS. The construction analysts, working together with the GIS analysts, review the stages of the project in the CAD/GIS Client. The analysts then update the CAD file in the CDS using the CAD/GIS Client and update GIS features in the WFS-T using the CAD/GIS Client.

As part of the construction analysis, a Canadian analyst requests the WFS features in French.

The construction analyst creates a CityGML feature collection of the information relevant to the other operations for update in the WFS. In addition, he creates a Context document linking to the WFS and CMS content.

The Army GIS analyst and Security analysts are then tasked with evaluating helicopter ingress and egress flight paths, navigation aid locations and potential placement of IEEE sensors to monitor helicopters in flight to and from the temporary facility. Analysts retrieve additional aeronautical data (Digital Aeronautical Flight Information Files) from suitable holdings in Aeronautical Information eXchange Model (AIXM) GML format to support the evaluation of air space restrictions and modifications based on the removal of one runway from use.

Based on the results of the analysis the Army decides to occupy the facility. With this decision in place, the analysts are then tasked to update the modified geospatial information about the facility based on their analysis and plans for use.

The Army GIS analyst then performs a data conversion from GML 3.2 to their internal GIS data format. The analyst locates the facility that is proposed as a temporary medical response facility. The GIS analyst makes changes to the original geometry to include the addition made to the building, road closure points (disconnecting road network), temporary heliport and temporary removal of some supporting aeronautical features. The analyst updates the data to indicate the new functional use for the building along with metadata information (feature and attribute level) to indicate the time at which the facility became a temporary medical response facility and a scheduled end date. The analyst also adds a temporary heliport site within the medical facility

Page 110 Due Date: May 3, 2006 Annex B: OWS-4 Architecture security zone along with flight paths and associated aeronautical information. The heliport is identified with operating hours of 0600 – 1800 each day. Specific flight paths for heliport and remaining runway are identified for approach and take off as well as airspace elevation levels. Each of these changes receives a temporal indicator to identify the start and end date of the features existence. The analyst then links this aero data to an OpenLS tracking service to track the GPS position of incoming and outgoing helicopters. Integrated into the OpenLS tracking service is the capability to provide estimated arrival times.

The analyst determines that IEEE 1451 motion and radiation sensors need to be tied in to an OGC sensor web and services as part of the security alert warning system. Alerts issued by the Sensor Alert Service will send a message allowing the analyst to task a UAV fly over to investigate possible intrusions.

The Army analyst determines this information is relevant to other operations in the area and should be posted back into the source database and made available to other field analysts. The analyst creates a tailored ‘view’ of the data available through a Feature Portrayal Service based on symbology encodings for GeoSym. A Web Context Document is created to identify all data and services used in this analysis. The Army analyst then completes a metadata update of the source database via WFS-T to include information, such as who he is, what authority he has to provide updates and contact information. In addition, the analyst uploads a CAD drawing of the building, a video of the surrounding perimeter, and the orthophoto as JPEG2000 with GML annotations, identifying the road closures with ingress and egress points to the temporary facility. The analyst then converts the modified/new data, as applicable, back into GML 3.2 for shipment. Using the client and a BPEL workflow the data is bundled zipped and shipped back to the source database as an update to the WFS-T. The BPEL workflow also initiates a notification message via a Web Notification Service back to the WFS-T that an update has been sent.

The analyst with responsibility over the area receives a message from the Web Notification Service that an external update is pending review. The analyst executes a Geospatial Digital Rights Management authority review of the pending data to verify the individual as authorized for sending updates. The analyst receives an approval message in reply with update authority from the GeoDRM service. The analyst then executes a data quality assessment of the topological consistency of the vector data [new Topology Service] to verify the quality of the data. The Topology Service indicates a number of breaks in the road network that require investigation. Once assured of the authority approval the analyst pulls the data from the WFS-T converts to internal GIS for review and update. The analyst determines the geometry for the airport facilities have been altered and the feature and attributes have changed. The analyst determines these changes are all tagged as temporary. The analyst determines that until such time as either the temporary changes expire or are made permanent both sets of geometry, feature code and attributes need to be retained within the database. The analyst determines the temporal aspects of the temporary medical response facility need to be the active attribution within the database so that any queries for data would receive the most current functional use for the building and surrounding features.

After the construction is complete an event occurs that demonstrates the ability of the OWS-4 to support the following scenario in real time, using real data:

i. Detect and locate various sensed phenomenon in the vicinity of the border/perimeter using a variety of in-situ ground sensors

ii. Identify through application of single or multiple layers of logic whether the sensed phenomenon is a potential incursion

iii. Based on determination of ii. above, trigger an alert through the SAS to a control center display monitoring the area, and display an alert message along with a visual prompt on the

Page 111 Due Date: May 3, 2006 Annex B: OWS-4 Architecture controller’s display. At the same time, send a tasking message with the precise coordinates of the potential threat to the remote platform(s)/sensor(s)

iv. Automatically steer the platform(s) as necessary, pan/focus/zoom the remote sensor(s) to point at the precise location of the potential incursion and automatically switch the controller’s display to show the output of the remote sensor(s). NOTE: if manned piloted airborne platform(s) are used, man-in-the-loop intervention may be required to steer the platform, based on the coordinate cues provided by SAS

v. Confirm through application of multiple layers of logic whether the potential incursion is a threat (OCR on license plate of vehicle, face recognition of driver, make/model of vehicle – all compared to existing knowledge bases to make the correct determination). NOTE: Some man- in-the-loop intervention may be required to pan, zoom, and initiate track on the appropriate sections of the target, via remote control links from the controller station to the remote sensor(s) to place into view specific discriminating elements to be used in the logic layers.

vi. Based on determination of v. above, automatically display an alert message to the controller, with all supporting information and imagery shown on his display. At the same time, send an alert message, including the precise location of the threat and other supporting information and imagery, through SAS to a rapid response force dispatcher for immediate response/action. NOTE: Man-in-the-loop radio coordination with the response force may be required to interdict and neutralize threat.

Page 112 Due Date: May 3, 2006 Annex B: OWS-4 Architecture

Appendix C: Sensor Web Use Cases

The following use cases capture the operational requirements of the Sensor Web Thread. Use Case 1 – Airborne Collection Context

Use Case Identifier: SWE #1 Use Case Name: Airborne Collection Context

Use Case Domain: OWS-4 SWE Airborne Status: Under development. Draft 12/17

Use Case Description: This use case describes the basic discovery, tasking, notification and access of sensor data. It provides an operational context in which the more detailed use cases will operate.

Actors (Initiators): User of imagery data Actors (Receivers) Same as initiator Pre-Conditions: Post-Conditions: - User requires imagery. Imagery has been collected, processed and is provided to the user for exploitation. - User has authorization to request the collection of the needed imagery.

System Components

- CS-W: Catalog Service Web Profile

- SPS: Sensor Planning Service

- MCS: Mission Control System – manages the operation of the platform and sensor package

- Platform: the vehicle that the sensor package is mounted on

- Sensor Package: the collection of instruments that detect phenomena and generate the metadata associated with the readings

- Data Server: A web service that stores and disseminates data. Includes the WCS and SCS

- Notification Service: Informs the user of events related to the requested automated processing

Basic Course of Action:

11. User queries a CS-W to determine if needed imagery is available

12. Imagery is not available

13. Airborne Collection is tasked (Use Cases 3.*)

14. (Optional) User requests collection status from SPS or CS-W

15. Collection status provided to user through notification service

16. (Optional) User modifies tasking for sensor and platform

17. Collection status provided to user through notification service

Page 113 Due Date: May 3, 2006 Annex B: OWS-4 Architecture

18. Collection delivered to a Data Server

19. User notified of collection status and access instructions through notification service

20. User accesses collection.

Use Case 2 – Airborne Collection Federated Context

Use Case Identifier: SWE #2 Use Case Name: Airborne Collection Federated Context

Use Case Domain: OWS-4 SWE Airborne Status: Under development. Draft 12/17

Use Case Description: Extends Use Case #1 by addressing a federation of many services, platforms and sensors. The objective of this Use Case is to provide an understanding of how services, sensors and platforms can be shared across organizational boundaries.

Actors (Initiators): User of imagery data Actors (Receivers) Same as initiator

Pre-Conditions: Post-Conditions: - User requires imagery. Imagery has been collected, processed and is provided to the user for exploitation. - User has authorization to request the collection of the needed imagery.

System Components – There are multiple instances of each component except for the Notification Service. Different instances are indicated by a subfix (ex. CS-W(A) is the CS-W owned by organization A).

- CS-W: Catalog Service Web Profile

- SPS: Sensor Planning Service

- MCS: Mission Control System – manages the operation of the platform and sensor package

- Platform: the vehicle that the sensor package is mounted on

- Sensor Package: the collection of instruments that detect phenomena and generate the metadata associated with the readings

- Data Server: A web service that stores and disseminates data. Includes the WCS and SCS

- Notification Service: Informs the user of events related to the requested automated processing

Basic Course of Action:

1. User(A) queries CS-W(A) to determine if needed imagery is available

2. Imagery is not available

3. User(A) issues federated query to CS-W(A) to include communities B and C

Page 114 Due Date: May 3, 2006 Annex B: OWS-4 Architecture

4. CS-W(A) issues query to CS-W(B) and CS-W(C)

5. CS-W(B) and CS-W(C) report to CS-W(A) that imagery is not available

6. CS-W(A) reports to User(A) that imagery is not available

7. User(A) performs Federated Tasking (Use Case 3.3) including communities A, B, and C

8. Sensor and Platform from community C is selected and tasked

(Alternate – multiple sensor could be tasked and their observations processed through a sensor fusion service)

9. User(A) is notified of selected tasking through notification service

10. (Optional) User requests collection status from SPS or CS-W

11. Collection status provided to user through notification service

12. (Optional) User modifies tasking for sensor and platform

13. Collection status provided to user through notification service

14. Collection delivered to Data Server(C)

(Alternate – tasking request may designate another Data Server to receive the collection)

15. User notified of collection status and access instructions through notification service

16. User accesses collection from Data Server (C).

Use Case 3 – Tasking Airborne Collection

Use Case Identifier: OWS3 SWE #3 Use Case Name: Tasking Airborne Collection.

Use Case Domain: OWS-4 SWE Airborne Status: Under development. Draft Oct. 11/23

Use Case Description: A user requires information from a sensor that is not currently available. A sensor and sensor platform must be deployed to the desired location to take measurements. This use case captures the activities and interactions needed to provide the user the required information.

Actors (Initiators): User of sensor data Actors (Receivers) Same as initiator

Page 115 Due Date: May 3, 2006 Annex B: OWS-4 Architecture

Pre-Conditions: Post-Conditions: - User requires sensor information that is not Required data is posted to a data server and the user currently available. is notified of its’ availability. - User has authorization to request the collection of the needed data.

System Components

- CS-W: Catalog Service Web Profile

- SPS: Sensor Planning Service

- MCS: Mission Control System – manages the operation of the platform and sensor package

- Platform: the vehicle that the sensor package is mounted on

- Sensor Package: the collection of instruments that detect phenomena and generate the metadata associated with the readings

- Data Server: A web service that stores and disseminates data. Includes the WCS and SCS

- Notification Service: Informs the user of events related to the requested automated processing

Basic Course of Action:

1. User queries a CS-W for observations over a specific area using a specific type of sensor

2. CS-W indicates that there are no observations that meet the users criteria

3. IF supported by CS-W

a. User instructs the CS-W to request the data

b. CS-W builds a collection request message

c. CS-W issues collection request message to an SPS

4. ELSE

a. User builds collection request message

b. User issues the collection request message to an SPS

5. User receives request message receipt from the SPS

6. SPS identifies a platform and sensor package suitable for satisfying the request

7. SPS tasks the MCS to perform the collection

8. SPS informs the user of the tasking, when and where results will be delivered

9. Platform performs measurement and downloads data to the MCS

Page 116 Due Date: May 3, 2006 Annex B: OWS-4 Architecture

10. MCS posts data to a data server

11. Data server updates appropriate CS-Ws

12. MCS informs SPS of data delivery

13. SPS informs User of data delivery

14. User downloads data

Use Case 3.1 – Tasking Airborne Collection with Bids

Use Case Identifier: SWE #3.1 Use Case Name: Tasking Airborne Collection with Bids

Use Case Domain: OWS-4 SWE Airborne Status: Under development. Draft Oct. 11/23

Use Case Description: Elaborates on use case SWE #3 by allowing the user to select the platform and sensor package to be used for collection. This use case is applicable to an environment where the user will be charged for tasking the collection and wishes to get the best value for their investment.

Actors (Initiators): User of sensor data Actors (Receivers) Same as initiator

System Components

- CS-W: Catalog Service Web Profile

- SPS: Sensor Planning Service

- MCS: Mission Control System – manages the operation of the platform and sensor package

- Platform: the vehicle that the sensor package is mounted on

- Sensor Package: the collection of instruments that detect phenomena and generate the metadata associated with the readings

- Data Server: A web service that stores and disseminates data. Includes the WCS and SCS

- Notification Service: Informs the user of events related to the requested automated processing

Basic Course of Action:

1. User queries a CS-W for observations over a specific area using a specific type of sensor

Page 117 Due Date: May 3, 2006 Annex B: OWS-4 Architecture

2. CS-W indicates that there are no observations that meet the users criteria

3. User builds collection request message

4. User issues the collection request message to numerous SPS

5. SPSs identify platform and sensor packages suitable for satisfying the request

6. SPSs send User bids on the collection. Responses include sensor package description, cost, schedule, quality of service.

7. User selects an SPS and places the order

8. User receives order receipt from the SPS

9. SPS tasks the MCS to perform the collection

10. SPS informs the user of the tasking, when and where results will be delivered

11. Platform performs measurement and downloads data to the MCS

12. MCS posts data to a data server

13. Data server updates appropriate catalogs

14. MCS informs SPS of data delivery

15. SPS informs User of data delivery

16. SPS charges User for collection

17. User downloads data

Use Case 3.2 – Tasking Airborne Collection with Federation

Use Case Identifier: SWE #3.2 Use Case Name: Tasking Airborne Collection with Federation

Use Case Domain: OWS-4 SWE Airborne Status: Under development. Draft Oct. 11/23

Use Case Description: Elaborates on use case SWE #3 by supporting multiple SPS. This use case is applicable to an environment where there will be multiple organizations making their ------

Actors (Initiators): User of sensor data Actors (Receivers) Same as initiator

Page 118 Due Date: May 3, 2006 Annex B: OWS-4 Architecture

System Components

- CS-W: Catalog Service Web Profile

- SPS: Sensor Planning Service

- MCS: Mission Control System – manages the operation of the platform and sensor package

- Platform: the vehicle that the sensor package is mounted on

- Sensor Package: the collection of instruments that detect phenomena and generate the metadata associated with the readings

- Data Server: A web service that stores and disseminates data. Includes the WCS and SCS

- Notification Service: Informs the user of events related to the requested automated processing

Basic Course of Action:

1. User queries a CS-W for observations over a specific area using a specific type of sensor

2. CS-W indicates that there are no observations that meet the users criteria

3. IF supported by CS-W

a. User instructs the CS-W to request the data

b. CS-W builds a collection request message

c. CS-W issues collection request message to a primary SPS

4. ELSE

a. User builds collection request message

b. User issues the collection request message to a primary SPS

5. Primary SPS issues the collection request message to numerous SPS

6. SPSs identify platform and sensor packages suitable for satisfying the request

7. SPSs inform primary SPS on their ability to satisfy the collection request.

8. Primary SPS selects an SPS and places the order

9. User receives request receipt from the primary SPS

10. Selected SPS tasks the MCS to perform the collection

11. Selected SPS informs the user, through the primary SPS, of the tasking, when and where results will be delivered

12. Platform performs measurement and downloads data to the MCS

Page 119 Due Date: May 3, 2006 Annex B: OWS-4 Architecture

13. MCS posts data to a data server

14. Data server updates appropriate catalogs

15. MCS informs SPS of data delivery

16. SPS informs primary SPS of data delivery

17. Primary SPS informs User of data delivery

18. User downloads data

Use Case 4 – Airborne Processing Chain

Use Case Identifier: SWE #4 Use Case Name: Airborne Processing Chain

Use Case Domain: OWS-4 SWE Airborne Status: Under development. Draft Oct. 11/23

Use Case Description: Places SWE #3 within the larger context of an image processing work flow. User will task an imagery collection, then process the collected imagery through a series of image processing services to get it prepared for exploitation.

Actors (Initiators): User of imagery data Actors (Receivers) Same as initiator

Pre-Conditions: Post-Conditions: - User requires imagery that is not currently Imagery has been collected, processed and is available. available to the user for exploitation. - User has authorization to request the collection of the needed imagery.

System Components – The processing services identified in this Use Case are the Coordinate Transformation Service and the Image Classification Service. These services were identified because they were used in OWS-2. Any image processing services designed to work within an OGC workflow can be used.

- CS-W: Catalog Service Web Profile

- SPS: Sensor Planning Service

- MCS: Mission Control System – manages the operation of the platform and sensor package

- Platform: the vehicle that the sensor package is mounted on

- Sensor Package: the collection of instruments that detect phenomena and generate the metadata associated with the readings

- Data Server: A web service that stores and disseminates data. Includes the WCS and SCS

Page 120 Due Date: May 3, 2006 Annex B: OWS-4 Architecture

- Notification Service: Informs the user of events related to the requested automated processing

- Workflow Management Service

- Workflow Editor: A tool for building workflow definitions for the Workflow Management Service

- Coordinate Transformation Service

- Image Classification Service

Basic Course of Action:

1. User tasks the collection of a pan-chromatic image over a specific area (Use Case #3)

2. Using the Workflow Editor, the user constructs a workflow that

a. Uses the Coordinate Transformation Service to re-project the collected image

b. Uses the Image Classification Service to classify areas of the image based on their spectral characteristics

c. Stores the processed imagery in a Data Service

3. User receives notification that the image has been collected.

4. Using the Workflow Editor, user adds the URL to the collection to the input of the workflow

5. User executes the workflow using the Workflow Management Service

6. User downloads processed imagery

Page 121 Due Date: May 3, 2006 Annex B: OWS-4 Architecture

Appendix D: ACTM data dictionary

The following use cases capture the operational requirements of the Sensor Web Thread.

Field Type** Usage* M - Mandatory A-Alpha O - Optional N-Numeric C - Conditional S-Symbol

Field Name Field Definition Field Type** Size Value Range & Structure Usage * ACTM Metadata Security Security classification of M A 2 U=Unclassified, R=Restricted, Classification the Aircraft Collection C=Confidential, S=Secret, TS=Top Tasking Message Secret (ACTM). SCI Control SCI control systems and C A/S 35 If the ACTM contains Sensative Systems/Codewords code words. Compartmented Information (SCI), SCI Control Systems/Codewords must be used…field is therefore conditional.

Dissemination Dissemination control C A/S 35 If releasable, use the Authorized for Control Markings codewords. Release to (REL TO) marking followed by country trigraphs in alphabetical order. Use country trigraphs from International Organization for Standardization (ISO) 3166. If dissemination of the ACTM must be further controlled, Dissemination Control Markings must be used here...field is therefore conditional.

Declassification Declassification C A/N/S 35 If the ACTM is classified, Declassification Information information for the Information must be used…field is ACTM. therefore conditional.

Page 122 Due Date: May 3, 2006 Annex B: OWS-4 Architecture

Creation Timestamp Date/time the ACTM file O A/N/S 20 "YYYY-MM-DDThh:mm:ssZ", which is a was created or modified. standard xs:dateTime format with a Creation Timestamp will mandatory "Z" timezone specifier on the change anytime there is end. Creation Timestamp will change a change to the ACTM. with any changes to the ACTM. So, for every Requirement ID control date change, there will be a Creation Timestamp change. But, there will not be a control date change for every Creation Timestamp change, ie Mission ID change with all the same requirements.

Originator Unit which originated the O A/N/S 50 Free text requirement. Mission Mission ID The theater specific M A/N 10 Alphanumeric. See theater-specific mission number. instructions. Program Code A theater-specific code M A/N 2 Theater code (A/N) followed by A/N. See which is part of the theater-specific instructions. mission number. Month 2-digit Month, part of M N 2 NN Mission ID Sortie The sortie number M N 2 01-99 associated with the project code. Year Four digit year M N 4 NNNN Project Code The project code which M A 2 Alpha, AA-ZZ. See theater-specific is part of the mission instructions. number. Track ID Theater designation O A/N 6 Alphanumeric. See theater-specific used to identify the instructions. aircraft track (or orbit). This is the path on the earth's surface directly beneath the flight path of the airborne platform. The path may or may not be geographically coincident to that of a scene centerline. Track Name Theater designation O A/N N/A Alphanumeric. Size of field unbounded. used to identify the aircraft track (or orbit) name. Collection Requirements Requirement ID User specified M A/N/S 12 User defined identification to facilitate tracking collection requirements. Requirement Name User specified text name O A/N 50 User defined providing descriptive data about the collection requirement purpose; usually the same as the

Page 123 Due Date: May 3, 2006 Annex B: OWS-4 Architecture

nomination name.

Requestor ID Code for the unit which O A/N/S 50 Free text created the ACTM. Control Date Date/Time the M A/N/S 20 "YYYY-MM-DDThh:mm:ssZ", which is a Requirement ID was standard xs:dateTime format with a created or modified. mandatory "Z" timezone specifer on the The Requirement ID end. Control Date changes only when may not change if the there is a change to the requirement ID. exact same tasks were So, for every Requirement ID control flown over several days. date change, there will be a Creation Timestamp change. But, there will not be a control date change for every Creation Timestamp change, ie Mission ID change with all the same requirements.

Requirement Priority The relative importance M N 3 000-999 of the collection requirement, where the lower assigned number value, the higher the priority. Tasks Task Priority The relative importance M N 3 000-999 of the task, where the lower assigned number value, the higher the priority. EEI ID Identification code for an O A/N N/A Alphanumeric: "EEI_NNNN"…size of essential element of field unbounded information set within a task. EEI identification codes are defined by the user in the Exploitation Requirements section of the ACTM. Target Data Target Type Indicates the collection type for the target to be collected as either a point, LOC, or DSA Point Target BE Number The Basic Encyclopedia M A/N/S 15 Possible values are: BE (BE) number of the number (10 A/N/S) BE target. w/suffix (15 A/N/S) BE w/suffix (KAI) (15 A/N/S) Target Name The target name which M A/N/S 38 Alphanumeric and symbol generally provides information about the target's location and/or function. Target Category The target category O N 5 10000-99999. See theater-specific Code code is based on a instructions. breakdown of targets

Page 124 Due Date: May 3, 2006 Annex B: OWS-4 Architecture

into major groups.

Center Coords Latitude The latitude of the point M A/N 11 DDMMSS.SSSH where DD 00-90 target associated with degrees; MM 00-59 minutes; SS.SSS the target's BE number. 00.000-59.000 seconds; H hemisphere N (north) or S (south) Longitude The longitude of the M A/N 12 DDDMMSS.SSSH where DD 00-180 point target associated degrees; MM 00-59 minutes; SS.SSS with the target's BE 00.000-59.000 seconds; H hemisphere E number. (east) or W (west) Elevation The elevation of the O S/N 6 SNNNNN; -00680 to +10688 (in meters, point target associated mean sea level) with the target's BE number. Major Axis The long axis of a point O N 6 NNNN.N; 00.1 - 9999.9 meters target as determined by an imaginary ellipse around the target center point coordinates. Minor Axis The short axis of a point O N 6 NNNN.N; 00.1 - 9999.9 meters target as determined by an imaginary ellipse around the target center point coordinates. True North Angle The angle measured in O N 3 NNN, 000-180 degrees degrees from True North clockwise to the major axis of the target. Look At Coords Latitude The "look at" center C A/N 11 DDMMSS.SSSH where DD 00-90 point latitude when this degrees; MM 00-59 minutes; SS.SSS coordinate is different 00.000-59.000 seconds; H hemisphere from the target center N (north) or S (south). When Look at latitude. This is the Coords are used, latitude and longitude coordinate latitude must be provided…field is therefore where the requestor conditional. wants the collection focused. Longitude The "look at" center C A/N 12 DDDMMSS.SSSH where DD 00-180 point longitude when this degrees; MM 00-59 minutes; SS.SSS coordinate is different 00.000-59.000 seconds; H hemisphere from the target center E (east) or W (west). When Look at point longitude. This is Coords are used, latitude and longitude the coordinate longitude must be provided…field is therefore where the requestor conditional. wants the collection focused. Elevation The elevation of the O S/N 6 SNNNNN; -00680 to +10688 meters point target as mean sea level expressed by the "look at" (collection) coordinates. Major Axis The long axis of a point O N 6 NNNN.N; 00.1 - 9999.9 meters target as determined by an imaginary ellipse around the target center point coordinates.

Page 125 Due Date: May 3, 2006 Annex B: OWS-4 Architecture

Minor Axis The short axis of a point O N 6 NNNN.N; 00.1 - 9999.9 meters target as determined by an imaginary ellipse around the target center point coordinates. True North Angle The angle measured in O N 3 NNN, 000-180 degrees degrees from True North clockwise to the major axis of the target. Directed Search Area (DSA) Target DSA ID The target identifier of M A/N/S 15 Unrestricted the DSA. Target Name The target name which M A/N/S 38 Alphanumeric and symbol generally provides information about the target's location and/or function. Vertex Count For a directed search M N 2 03-24 area (DSA), this field indicates the number of vertices in the polygon. Vertex Coords Latitude The latitude for each M A/N 11 DDMMSS.SSSH where DD 00-90 vertex in a DSA degrees; MM 00-59 minutes; SS.SSS collection. 00.000-59.000 seconds; H hemisphere N (north) or S (south) Longitude The longitude for each M A/N 12 DDDMMSS.SSSH where DD 00-180 vertex in a DSA degrees; MM 00-59 minutes; SS.SSS collection. 00.000-59.000 seconds; H hemisphere E (east) or W (west) Line of Communication (LOC) Target LOC ID The target identifier of M A/N/S 15 Unrestricted the LOC. Target Name The target name which M A/N/S 38 Alphanumeric and symbol generally provides information about the target's location and/or function. Vertex Count For a LOC, this field M N 2 02-24 indicates the number of vertices in the LOC. Segment Vertex Latitude The latitude for the M A/N 11 DDMMSS.SSSH where DD 00-90 segment start point in an degrees; MM 00-59 minutes; SS.SSS LOC collection. 00.000-59.000 seconds; H hemisphere N (north) or S (south) Longitude The longitude for the M A/N 12 DDDMMSS.SSSH where DD 00-180 segment start point in an degrees; MM 00-59 minutes; SS.SSS LOC collection. 00.000-59.000 seconds; H hemisphere E (east) or W (west) Elevation The elevation for the O S/N 6 SNNNNN; -00680 to +10688 meters segment start point in an mean sea level LOC collection.

Page 126 Due Date: May 3, 2006 Annex B: OWS-4 Architecture

Country Code2 Two-letter digraph O A 2 Alpha. Standard codes may be found in defining the country for International Organization for the reference point of Standardization (ISO) 3166. the image.

Country Code3 Three-letter trigraph O A 3 Alpha. Standard codes may be found in defining the country for International Organization for the reference point of Standardization (ISO) 3166. the image. Geographic Region The geographic region in O A/N 2 Alphanumeric. See theater-specific which the target is instructions. located. Collection Constraints Sensor ID Identifies the specific M A/N 6 Alphanumeric, from the following list: sensor which will APG-73 produce the image. AIP ASARS1 ASARS2 CA236 (Darkstar EO) CA260 CA261 CA265 CA270 CA295 D500 DB110 DS-SAR (Darkstar Radar) GHR (Global Hawk Radar) HYDICE HSAR IRLS (ATARS) LAEO (ATARS) MAEO (ATARS) SIR-C SYERS TSAR (Tactical SAR on Predator)

Page 127 Due Date: May 3, 2006 Annex B: OWS-4 Architecture

Sensor Mode Identifies the mode in O N 3 001-999, based on the folowing list: which the sensor will For AIP: operate. 013 – Monopulse Calibration 014 – Wide Area MTI (WAMTI) 015 – Coarse Resolution Search 016 – Medium Resolution Search 017 – High Resolution Search 018 – Point Imaging 019 – Swath MTI (SMTI) 020 – Repetitive Point Imaging For ASARS-2: 001 – Search 002 – Spot 3 004 – Spot 1 007 – Continuous Spot 3 008 – Continuous Spot 1 009 – EMTI Wide Frame Search 010 – EMTI Narrow Frame Search 011 – EMTI Augmented Spot 012 – EMTI Wide Area MTI (WAMTI) 013 – Monopulse Calibration For APG-73: 001 – Strip (Search) 002 – Spotlight Other sensors: SAR – TBD EO-IR: 001-003 – Reserved 004 – EO Spot 005 – EO Point Target 006 – EO Wide Area Search 014 – IR Spot 015 – IR Point Target 016 – IR Wide Area

Sensor Specific Data Optical NIIRS The National Imagery O N 3 0.0-9.9 Interpretability Rating Scale required for the imagery to be acceptable to the requestor. Map Angle True Map Angle. The Constraints true map angle is defined in the NED coordinate system with the origin at the aircraft (acft local NED) as the angle between the scene entry line of sight and the instantaneous aircraft track heading vector. The aircraft track heading vector is obtained by rotating the north unit vector of the

Page 128 Due Date: May 3, 2006 Annex B: OWS-4 Architecture

aircraft local NED coordinate system in the aircraft local NE plane through the aircraft track heading angle. This angle is always positive.

Min Minimum acceptable O N 5 NNN.N, 000.0-180.0 degrees Map Angle Max Maximum acceptable O N 5 NNN.N, 000.0-180.0 degrees Map Angle Grazing Angle The angle, measured in Constraints degrees ,at the target between the focus plane and the line of sight to the sensor. Min Minimum acceptable O N 4 NN.N 00.1-90.0 degrees Grazing Angle Max Maximum acceptable O N 4 NN.N, 00.1-90.0 degrees Grazing Angle Look Angle The angle, measured in Constraints degrees, from True North to the line-of-sight vector from the sensor to the target tangent plane. Min Minimum acceptable O N 5 NNN.N, 000.0-359.9 degrees Look Angle Max Maximum acceptable O N 5 NNN.N, 000.0-359.9 degrees Look Angle Elevation Angle The angle, measured in Constraints degrees, from the target tangent plane at the intersection of the optical line of sight with the earth's surface at the time of the first image line. Min Minimum acceptable O N/S 3 SNN, -90 to +90 degrees Elevation Angle Max Maximum acceptable O N/S 3 SNN, -90 to +90 degrees Elevation Angle Sun Elev Angles Measured in degrees from the target plane at intersection of the optical line of sight with the earth's surface at the time of the first image line. Min Minimum acceptable O N/S 3 SNN, -90 to +90 degrees Sun Elev Angle Max Maximum acceptable O N/S 3 SNN, -90 to +90 degrees Sun Elev Angle

Page 129 Due Date: May 3, 2006 Annex B: OWS-4 Architecture

Sun Azimuth Angles The angle, measured in degrees, from True North clockwise (as viewed from space) at the time of the first image line. Min Minimum acceptable O N 5 NNN.N, 000.0-359.9 degrees Sun Azimuth Angle Max Maximum acceptable O N 5 NNN.N, 000.0-359.9 degrees Sun Azimuth Angle Slant Range Distance from the Constraints sensor reference point (e.g. aperture reference point) to the ground reference point. mmmmmmmm.mm Min Minimum Slant Range O N 10 0000000.10 - 9999999.99 (m) Max Maximum Slant Range O N 10 0000000.10 - 9999999.99 (m) Destination Point Numeric label for a O N 2 0-99 waypoint in a navigation plan. Pair Identifier Indicates whether a O A I I = Initial Collect. R = Recollect collection is intended to be the initial collection of a pair, or a subsequent recollection to finish the pair. Spectral Type User defined bands - O N TBD TBD TBD SAR NIIRS The National Imagery O N 3 0.0-9.9 Interpretability Rating Scale required for the imagery to be acceptable to the requestor. Map Angle True Map Angle. The Constraints true map angle is defined in the NED coordinate system with the origin at the aircraft (acft local NED) as the angle between the scene entry line of sight and the instantaneous aircraft track heading vector. The aircraft track heading vector is obtained by rotating the north unit vector of the aircraft local NED coordinate system in the aircraft local NE plane through the aircraft track heading angle. This angle is always positive. Min Minimum acceptable O N 5 NNN.N, 000.0-180.0 degrees Map Angle Max Maximum acceptable O N 5 NNN.N, 000.0-180.0 degrees

Page 130 Due Date: May 3, 2006 Annex B: OWS-4 Architecture

Map Angle Grazing Angle The angle, measured in Constraints degrees ,at the target between the focus plane and the line of sight to the sensor. Min Minimum acceptable O N 4 NN.N 00.1-90.0 degrees Grazing Angle Max Maximum acceptable O N 4 NN.N, 00.1-90.0 degrees Grazing Angle Look Angle The angle, measured in Constraints degrees, from True North to the line-of-sight vector from the sensor to the target tangent plane. Min Minimum acceptable O N 5 NNN.N, 000.0-359.9 degrees Look Angle Max Maximum acceptable O N 5 NNN.N, 000.0-359.9 degrees Look Angle Elevation Angle The angle, measured in Constraints degrees, from the target tangent plane at the intersection of the optical line of sight with the earth's surface at the time of the first image line. Min Minimum acceptable O N/S 3 SNN, -90 to +90 degrees Elevation Angle Max Maximum acceptable O N/S 3 SNN, -90 to +90 degrees Elevation Angle Slant Range Distance from the Constraints sensor reference point (e.g. aperture reference point) to the ground reference point. mmmmmmmm.mm Min Minimum Slant Range O N 10 0000000.10 - 9999999.99 (m) Max Maximum Slant Range O N 10 0000000.10 - 9999999.99 (m) Continuous Spot Required sweep angle O N 2 0-90 degrees Angle for the continuous spot scene. Destination Point Numeric label for a O N 2 0-99 waypoint in a navigation plan. Pair Identifier Indicates whether a O A 1 C = Initial Collect. R = Recollect collection is intended to be the initial collection of a pair, or a subsequent recollection to finish the pair. Complex Data Filled out if requestor O A 1 Y = Requestor wants complex data wants a complex data product. N or blank = Requestor wants product. detected product SIGINT TBD - SIGINT fields left empty as placeholders.

Timing Constraints

Page 131 Due Date: May 3, 2006 Annex B: OWS-4 Architecture

Collection Time Window Earliest The earliest time the O A/N/S 20 "YYYY-MM-DDThh:mm:ssZ", which is a imagery can be acquired standard xs:dateTime format with a and still be of value to mandatory "Z" timezone specifer on the the requestor. end. Latest The latest time the O A/N/S 20 "YYYY-MM-DDThh:mm:ssZ", which is a imagery can be acquired standard xs:dateTime format with a and still be of value to mandatory "Z" timezone specifer on the the requestor. end. Looks per Mission The number of times the O N 2 00-99 target is to be imaged during the mission. Periodicity The frequency of target O N/S 3 N:N collection a requestor needs for a given time period; expressed as the number of times a requestor wants an image in a specified time span measured in days. Collection A unique number O N 3 001-999 Precedence assigned by the collection manager to set the precedence assignment of all pre- mission tasking and during mission retasking by external requestors. It may be changed by the collection manager to respond to changing needs. The lower the assigned number value, the higher the collection precedence. Exploitation Requirements EEI ID List List of all user defined O A/N N/A Alphanumeric: "EEI_NNNN"…size of essential elements of field unbounded. information codes for the ACTM. EEI Text The essential elements O A/N/S N/A Narrative. Size of field unbounded. of information associated with an EEI ID.

Page 132