• 1 Foreword
• 1.1 Purpose
• 1.2 Scope
• 1.3 Document Overview and Revision Summary
• 2 Background
• 2.1 Changing Requirements in the Post Cold War Era
• 2.2 Translating Mission Requirements into Requirements for Geospatial Information
• 2.2.1 Changes in Types of Support
• 2.2.2 Changes in Coverage Requirements
• 2.2.3 Changes in OPTEMPO
• 2.2.4 The Defense Science Board’s Challenge
• 2.3 The GII Vision: Developing a Framework for Geospatial Information and Services
• 2.3.1 Geospatial Framework
• 2.3.2 Readiness and Responsiveness
• 2.4 Implementing the vision
• 2.4.1 GII 97 activities
• 2.4.2 Recommendations of the GI IPT
• 2.4.3 Importance of architectures
• 2.4.4 Future activities
• 3 GII Architecture
• 3.1 GII Architecture Views Require a Common Data Model
• 3.2 GII Operational Architecture
• 3.3 GII Technical Architecture
• 3.3.1 GII Standards Profile
• 3.3.2 GII Technical Architecture Extensions
• 3.3.3 USIGS Technical Architecture
• 3.3.4 USIGS Technical Reference Model Entities
• 3.4 GII System Architecture
• 3.4.1 Mapping the GII Operational Architecture to USIGS Mission Specific Applications Categories
• 3.4.2 GII 97 System Architecture
• 3.4.3 Future Systems View - FY 2000 and Beyond
• 3.4.3.1 GII Goal Architecture
• 3.4.3.2 Emerging Technology
• 4 GII Requirements
• 4.1 Requirements Management
• 4.1.1 Requirements Drivers
• 4.1.2 Current Environment
• 4.1.3 Future Environment
• 4.2 Data Acquisition and Information Production
• 4.2.1 General Description
• 4.2.2 Detailed Functional Requirements
• 4.2.2.1 Input Requirements
• 4.2.2.2 Output Requirements
• 4.2.2.3 Process Rules
• 4.2.2.4 Acquire Source
• 4.2.2.5 Source Ingest
• 4.2.2.6 Evaluate Data
• 4.2.2.7 Adjust Data
• 4.2.2.8 Extract Data
• 4.2.2.9 Integrate Data
• 4.2.2.10 Generate and Manipulate Metadata
• 4.2.3 Performance Requirements
• 4.2.3.1 Production of Foundation Data
• 4.2.3.2 Intensification of Foundation Data
• 4.2.4 Issues and Design Considerations for Outreach
• 4.3 Information Management and Dissemination
• 4.3.1 Requirements Description
• 4.3.2 Architecture
• 4.3.2.1 Architecture Compliance
• 4.3.2.2 Data Management
• 4.3.2.3 Framework Information
• 4.3.2.4 Formats
• 4.3.2.5 Compression
• 4.3.2.6 Metadata
• 4.3.3 User Services
• 4.3.3.1 Query
• 4.3.3.2 Browse Services
• 4.3.3.3 Order
• 4.3.3.4 Human Computer Interface (HCI)
• 4.3.3.5 User Profile
• 4.3.3.6 Security Profile
• 4.3.3.7 Automated Information Systems (AIS) Security
• 4.3.4 Performance Expectations
• 4.3.4.1 Storage Capacity
• 4.3.5 Issues and Design Considerations for Outreach
• 4.4 Applications
• 4.4.1 User Environments and Requirements Overview
• 4.4.2 Detailed Functional Requirements
• 4.4.2.1 Cartographic Definition
• 4.4.2.2 Geospatial Data
• 4.4.2.3 Subject Military Spatial Analysis
• 4.4.2.4 Additional Requirements
• 4.4.3 Issues and Design Considerations - Comparison of GII Requirements and JMTK Requirements and Capabilities
• 4.4.3.1 Background
• 4.4.3.2 Organization
• 4.4.3.3 Caveats
• 4.4.3.4 Summary of Findings
• 5 Industry Outreach for GII 97
• 5.1 Development of the Technology Matrix
• 5.2 Broad Agency Announcement for GII 97
• 5.2.1 BAA Assessment Criteria
• 5.2.2 Results of the BAA for GII 97 Selection Process
• 6 GII Concept Demonstration Assessment Scenarios
• 6.1 Noncombatant Evacuation Operation (NEO)
• 6.1.1 Background
• 6.1.2 Geospatial Information Impact
• 6.1.3 Actions
• 6.2 Mission Planning in Support of an Air Strike
• 6.2.1 Background
• 6.2.2 Geospatial Information Impact
• 6.2.3 Actions
• 6.3 Rapid Mapping
• 6.3.1 Background
• 6.3.2 Geospatial Information Impact
• 6.3.3 Actions

Figure 2-1 Technology Trends in Geospatial Information
Figure 2-2 Geospatial Framework
Figure 2-3 Readiness and Responsiveness Production Strategy
Figure 2-4 Geospatial Infrastructure Relationships
Figure 3-1 C4ISR Architecture Views
Figure 3-2 Examples of USIGS Data Model Views
Figure 3-3 GII Operational Architecture
Figure 3-4 USIGS Distributed Environment
Figure 3-5 Simplified USIGS Technical Reference Model
Figure 3-6 USIGS Mission Specific Application Categories
Figure 3-7 Common Support Applications and the Open Geospatial Exchange (OGE) Service Categories
Figure 3-8 Common Facilities in the USIGS Technical Reference Model
Figure 3-9 OMG Object Services in the USIGS
Figure 3-10 Platform Services in the USIGS Technical Reference Model
Figure 3-11 Notional GII System Architecture
Figure 3-12 GII Operational Architecture
Figure 3-13 USIGS Information Cycle
Figure 3-14 Relationships between NIMA PEOs, Mission Specific Applications Categories, and OGE Services
Figure 3-15 Overall Mapping of the GII and USIGS Categories onto the USIGS Information Cycle
Figure 3-16 GPF Information Production Process
Figure 3-17 GPF Information Applications Process
Figure 3-18 GPF Information Management and Dissemination Process
Figure 3-19 GPF Initial System Architecture for Information Production
Figure 3-20 Trends in Applications
Figure 3-21 Enterprise System Concept
Figure 4-1 Software Component Approach to Building User Applications

Table 4-1 Summary of GII Applications Requirements
Table 4-2 Comparison of GII Applications Requirements to JMTK Requirements

1 Foreword

1.1 Purpose

This document is a companion to the Geospatial Information Infrastructure (GII) Master Plan Volume 1 - Overview and the separately-bound Stakeholder Annexes to Volume 1. It presents a greater level of detail than its companion documents and is designed primarily for use by people implementing components of the Master Plan. Accordingly, readers may also wish to refer to Volume 1 for context on many issues.

Another companion document, a final report of the technology assessments conducted in the Geospatial Prototyping Facility (GPF) during the summer of 1997 and of the final composition of GII 97, will be published as Volume 3 of the GII Master Plan.

1.2 Scope

Volume 2 of the Master Plan describes the system and technical aspects of the architecture for the GII, identifies functional requirements, and describes the results of an initial round of down-selects from industry proposals to meet identified requirements. Volume 2 is oriented to those commands, agencies, and organizations that either use or provide access to geospatial information and services. Volume 2 also provides information of interest to the academic community and to industry.

The GII architectural views and the requirements in this document focus specifically on the production of, access to, and exploitation of geospatial information. From a technology perspective, this includes raster, vector, text, and multi-media data, as well as the geodetic control needed to fuse geospatially-referenced data from other sources. From a user perspective, geospatial information, in the context of this document, refers to any data that has associated with it some contextual, spatial, and temporal reference. This includes geospatially referenced imagery, feature, elevation/depth, geophysical, and safety of navigation data.

Because the GII defines an infrastructure and not a system, functional and performance requirements are emphasized rather than system engineering and capacity requirements. The system-level engineering and capacity outcomes of GII 97, the first spiral of outreach, assesssment, and integration within the GII, will be documented in Volume 3 of the Master Plan. Any large-scale system development or implementations undertaken by stakeholder organizations must further consider the full range of implications associated with portability, scalability, and interoperability.

1.3 Document Overview and Revision Summary

Volume 2 is organized as follows:

• Section 2 provides background on the changing environment for support with geospatial information, introduces the vision for a ready and responsive geospatial Framework, and summarizes recommendations of the Geospatial Information Integrated Product Team (GI IPT) that were developed in Volume 1;

• Section 3 defines the current view of the architecture needed to support the GII;

• Section 4 establishes functional requirements for the GII;

• Section 5 provides information on the criteria used for selecting technology solutions for assessment in the first spiral of industry outreach and outlines the results of the initial selection;

• Section 6 describes the scenarios being used to perform technology assessments in GII 97; and

• The appendices provide (A) a GII Requirements and Technology Matrix that contains a summary of all the requirements presented in Version 0.21 of Volume 2 and informal industry assessment of capabilities that can be used to satisfy those requirements; (B) a list of NIMA products; (C) candidate standards for the GII; (D) a list of related documents; and (E) a glossary of abbreviations and key terms used in this volume.

This document, Version 1.0, supersedes the draft Version 0.21, Geospatial Information Infrastructure Master Plan, Volume 2 - Requirements, January 17, 1997. Major changes that have been made to Volume 2 since the prior release include:

• The background in section 2 and introductions in several of the sections have been updated to reflect the information provided in Version 1.0 of Volume 1.

• The GII architecture in section 3 has been related to the U.S. Imagery and Geospatial Information System (USIGS) Data Model and USIGS architecture.

• Where substantive updates or additions have been made to the GII requirements in section 4, changes are shown in italics.

• A set of new requirements were added to section 4.3 covering information management and dissemination to address security needs.

• A comparison of GII applications requirements to the capabilities of the Joint Mapping Tool Kit (JMTK) was added to section 4.4.

• The requirements matrix in appendix A has been expanded to a technology matrix. The appendix contains a listing of the GII requirements as they were stated in Version 0.21. The technology matrix contains the results of an informal industry survey of capabilities assessed against those requirements.

2 Background

2.1 Changing Requirements in the Post Cold War Era

The end of the Cold War was a turning point in international relations, defense strategy, global economics, and the disciplines that support them. During the Cold War, the geospatial community invested most of its effort in producing traditional maps, charts, and digital products over known threat areas. After the collapse of global Communism and emergence of the United States as the sole superpower in the post Cold War era, the international environment became one of rapid change and diminished predictability. The U.S. recognized the need to engage globally, both diplomatically and economically, to preserve the nation’s ideals and interests. The U.S. military has become primarily an expeditionary force, required to respond to a wide variety of tactical missions such as peacekeeping, evacuations, and coalition warfighting while also training to keep its traditional fighting edge.

2.2 Translating Mission Requirements into Requirements for Geospatial Information

The impact of changes in type of mission in the post Cold War era, as well as increases in the range of activity over larger geographic areas, is having a profound effect on a geospatial community that is undergoing increasing resource constraints.

2.2.1 Changes in Types of Support

Significant technological advances in digital storage, networking, other communications, computing, and displays have raised expectations among users that they should be able to know at all times where they are, what’s around them, and how that affects their mission. Perhaps more importantly, they now also expect everyone on their team to have consistent information. The same advances that are raising user expectations are creating technological opportunities for the geospatial community. Figure 2-1 shows projected trends in the use of geospatial information that are possible through advances in technology and that respond to the emerging needs of users.

The trends can be summarized as follows:

• Overall, demand for geospatial information is increasing;

• The importance of hardcopy support, particularly for standard maps and charts, is diminishing while that of support with digital information is growing, but the need for hardcopy is not going away;

• Within hardcopy support, tailored hardcopy produced closer to the site of need and adapted to the situation will gradually supplant standard hardcopy products; and

• Electronic displays of “dumb” maps, primarily raster versions of hardcopy maps, will yield ground to machine decisionmaking and smart, interactive displays that operate on primarily vector datasets.

Figure 2-1 Technology Trends in Geospatial Information

2.2.2 Changes in Coverage Requirements

There has been a long-standing requirement for seamless, consistent near-global coverage of critical geospatial information that is readily available for the policy maker and military planner and that includes safety information to support global air and sea navigation. For many years, this global planning and navigation requirement has been supported by a variety of traditional products ranging in level of detail down to the 1:250,000-scale Joint Operations Graphic (JOG). The JOG requirement alone has stretched and challenged the geospatial community. In the post Cold War era, the emerging near-global requirement is moving toward 1:100,000- and 1:50,000-scale levels of detail, representing orders of magnitude increases in data density.

Geographically focused requirements for even greater levels of detail are increasing, as warriors are beginning to substitute synchronization, agility, precision, and focus for brute force and numbers. These new warfighting approaches depend on dominant knowledge of battlespace.

2.2.3 Changes in OPTEMPO

During the Cold War, with relatively stable threats, geospatial requirements could be projected with confidence several years in advance. Geospatial support tended to follow rigid procedures, generating standard products, to optimize efficiency and predictability of support. In the post Cold War era, operational tempo (OPTEMPO) has increased. Available response times have gone to days and hours, challenging the old ways of doing business.

2.2.4 The Defense Science Board’s Challenge

The Defense Science Board (DSB), with assistance from the extended geospatial community, tackled the growing disconnects between traditional geospatial support based on products, changing missions and requirements, and emerging technologies. In 1995, the DSB recommended that the Department of Defense:

• “Evolve a distributed heterogeneous Internet-like architecture that uses geospatial databases as its foundation.”

• “Change the defense mapping mission to: Maintain the geospatial databases and protect access and integrity.”

• “Institute a requirements process that prioritizes users’ geographic needs.”

• “Rapidly acquire access to virtual worldwide databases using all available, commercial, government and foreign sources and practices.”

• “Equip and educate the end user to locally add value and meet his needs (e.g., smart workstations, printers, etc.).”

• “Establish an Integrated Product Team (IPT) to manage the whole process.”

2.3 The GII Vision: Developing a Framework for Geospatial Information and Services

Per the recommendation of the DSB and guidance of the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence, ASD(C3I), the Director of the Defense Mapping Agency (DMA) (now National Imagery and Mapping Agency, NIMA) established a Geospatial Information Integrated Product Team (GI IPT) that reviewed and validated the DSB recommendations and documented the vision for and demonstrated the feasibility of a Geospatial Information Infrastructure (GII). The GII vision, formulated with the assistance of Stakeholders from throughout the geospatial community, is for a geospatial Framework that is ready and responsive.

2.3.1 Geospatial Framework

The geospatial Framework is composed of a consistent set of geospatial information and supporting services that enable users to exploit and apply the information with confidence. Together, Framework Information and Services provide a coherent frame of reference to build an integrated view of the mission space. The Framework is described in considerable detail in Volume 1 of this Master Plan, and is summarized in Figure 2-2.

Figure 2-2 Geospatial Framework

2.3.2 Readiness and Responsiveness

The strategy for populating the geospatial Framework so that it is constantly ready to meet operational requirements and also responsive to emergency situations for crisis support is described in some detail in Volume 1 of this Master Plan and summarized in Figure 2-3.

2.4 Implementing the vision

2.4.1 GII 97 activities

The outcomes of GII 97 will be documented in greater detail in Volume 3 of this Master Plan, to be prepared upon completion of the ongoing assessments.

Figure 2-3 Readiness and Responsiveness Production Strategy

2.4.2 Recommendations of the GI IPT

To implement and sustain the GII, the GI IPT developed the following recommendations to the geospatial community in Volume 1 of this Master Plan:

• Change the overall geospatial information support strategy to be more responsive to the user;

• Change the geospatial production strategy to establish Framework Information supporting the readiness and responsiveness requirements of the user;

• Rapidly acquire access to virtual geospatial databases worldwide;

• Refine the geospatial mission to reflect the new focus on geospatial Framework Information;

• Establish a new requirements system that links mission information needs to production;

• Evolve a distributed heterogeneous Internet-like architecture to enhance access;

• Equip and train geospatial users to exploit the Framework as an information resource; and

• Establish the business practices and infrastructure needed to sustain the changes. These include:

  • Incorporate successful business processes from the GI IPT;

  • Implement a new technology transfer and system acquisition process;

  • Utilize an approach that assures the attainment of interoperability;

  • Establish an investment strategy for the GII;

  • Follow a Roadmap to implement the GII;

  • Manage and mitigate the risks; and

  • Monitor success criteria.

2.4.3 Importance of architectures

Interoperability will be the linchpin of the GII, not only because the GII must enhance the ability of users to interchange spatially-referenced information as they execute their missions but also because interoperability will be critical to the internal workings of the GII. Members of the geospatial producer community must be able to reach across organizational boundaries to access each other’s data and information holdings. Users must be able to navigate, browse, access, and use geospatial information. When users correct, update, or add to existing geospatial information, they must be able to exchange this new information with each other and get it back to geospatial producers for formal integration and redissemination. The infrastructure boundaries that must be crossed in these exchanges are outlined in Figure 2-4. If any of these essential exchanges breaks down, synergy will be lost and the GII’s ability to support the user community will be greatly diminished.

Figure 2-4 Geospatial Infrastructure Relationships

Volume 1 describes the operational architecture for the GII in some detail. This volume expands on the systems and technical architectures that are necessary to get essential information and services across the boundaries shown above.

2.4.4 Future activities

The GI IPT concludes its work upon publication of this Master Plan. The Roadmap to the GII outlined in Volume 1 of the Master Plan serves as NIMA’s implementation annex. Implementation annexes of the other Stakeholders are also part of Volume 1. The pace at which the geospatial community implements these annexes will give life to Figure 2-1 earlier in this section, putting dates along the timeline, putting shape to the outlined trends, and providing an “information edge” to our national security.

3 GII Architecture

As discussed in Volume 1 of the GII Master plan, both the GII and USIGS follow the guidelines for architecture development established by the C4I Integration Support Activity (CISA) for DoD Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance (C4ISR). These guidelines:

• Establish a process to ensure system interoperability, portability and evolvability; and

• Provide a structure for collecting and decomposing requirements.

Interoperability is a key goal of the GII. It is promoted through communications and data interchange standards that enable applications to exchange and use information with confidence.

Portability is promoted through operating system service standards that reduce dependence of an application on a single hardware platform.

Figure 3-1 C4ISR Architecture Views

Evolvability is promoted through the delineation and standardization of application programming interfaces (APIs) and data management services that allow additional functionality to be added and existing functionality to be replaced with alternative component implementations.

The C4ISR documentation divides architecture into three views as shown in Figure 3-1 on the previous page. These views help define the necessary concepts and relationships for an enterprise environment:

• Operational Architecture - identifies the operational elements, tasks and information flows required to accomplish the mission;

• Technical Architecture - provides the technical guidelines for systems implementation;

• System Architecture - is constructed to satisfy operational architecture requirements per the standards defined in the technical architecture.

3.1 GII Architecture Views Require a Common Data Model

The data model and data dictionary for the GII are being developed as part of the United States Imagery and Geospatial Information System (USIGS). Standardizing the USIGS Data Model across the imagery, imagery intelligence and geospatial information domains is necessary to provide seamless information access for the user community. An integrated USIGS Data Model ensures the appropriate application of information across system implementations. It will also support the efficient exchange of data either through standardized exchange formats or as part of the specifications for APIs.

In a large-scale enterprise such as USIGS, the “data model” is really a set of models which may include an enterprise-wide logical model, subject-specific logical models, as well as physical models to support specific system installations. The resultant USIGS model provides different views of the data as shown in the examples in Figure 3-2.

Maintenance of the data model is an iterative process that continues to reflect changes in the operational requirements, such as the need for additional elements of information in a Mission Specific Data Set (MSDS). As new functionality is incorporated into the logical data model, the model must be updated. Data elements must be periodically reviewed, and any changes, additions, or deletions must be reflected in the repository of standardized data.

Figure 3-2 Examples of USIGS Data Model Views

3.2 GII Operational Architecture

The GII operational architecture, defined in Volume 1 of the GII Master Plan, is based on five mission areas:

• Requirements Management

• Data Acquisition

• Information Production

• Information Management and Dissemination

• Information Applications

The relationship of these components and the information flows are shown in Figure 3-3. As the GII operational architecture is refined through future management and engineering spirals, the goal is to specify the operational elements, assigned tasks, and information flows needed to accomplish the mission functions. This process is driven by the mission needs and operational requirements of the users and includes:

• The types of information (based on the data model),

• The frequency and types of information exchanges, and

• Identification of the tasks supported by these exchanges.

The operational architecture must define the activities and the information exchange requirements of the GII. Considerations to be made in this process include:

• The operational architecture starts with doctrine and assigned tasks, which in turn drive the definition of the activity model;

• Activity descriptions are essential in order to refine the data model and information exchange requirements;

• Information exchange requirements may cross organizational boundaries;

• Activities may cross organizational boundaries;

• Activity descriptions are not based on organizational models or force structures.

Figure 3-3 GII Operational Architecture

3.3 GII Technical Architecture

The technical architecture identifies the services, interfaces, standards and their relationships needed to implement the operational architecture based on the system architecture. The technical architecture provides the guidelines for implementation of systems upon which specifications are based, common building blocks are formed, and information views are developed.

For the GII, the primary purpose of the technical architecture is to define the rules governing the arrangement, interaction, and interdependence of the geospatial information system components. The following characteristics further describe the technical architecture:

• It is based on requirements defined in the operational architecture and analyses of possible enabling technologies;

• Information system paradigms for data processing, database design and communications network design are identified and strongly influence the technical architecture;

• The technical architecture accounts for the requirements of multi-platform and network interconnections among all systems that produce, use, or exchange information electronically;

• Definitions and corresponding technical criteria for system capabilities, services, performance, and interfaces are provided;

• It accommodates new technology, evolving standards, and the phasing out of old technology; and

• The rules of the technical architecture are defined in terms of nonproprietary specifications and, therefore, reduce reliance on proprietary technologies.

The technical architecture supporting the geospatial domain must evolve within USIGS for the same reasons that the GII data model must be incorporated as part of the USIGS Data Model. Through USIGS, NIMA will establish the services, facilities, and components needed to fulfill its imagery, imagery intelligence, and geospatial information mission. The USIGS technical architecture is based primarily on the Joint Technical Architecture (JTA), and USIGS will provide standards and extensions to the JTA to support imagery and imagery intelligence. The GII community management and engineering process, through USIGS, must define the required standards and standards extensions to support geospatial information within the broader JTA information environment.

3.3.1 GII Standards Profile

The standards profile is the set of standards to be used collectively to specify requirements for a specific interface across an application. For the geospatial domain the profile must identify standards for:

• Data structures and data exchange formats - raster, grid, matrix, vector, text

• Features and attributes

• Encoding

• Metadata

• Symbology

• Data quality

• Datums, grids, and coordinate systems

Candidates for these standards are presented in Appendix C. The goal of identifying appropriate standards in each of these areas for the geospatial domain is to promote interoperability, portability, and evolvability at the data level.

Through the proposed community management, engineering, and planning process discussed in Volume 1, NIMA will propose candidate standards for incorporation in the USIGS Interoperability Profile (UIP) to support the geospatial domain.

3.3.2 GII Technical Architecture Extensions

The community process for the coordination of geospatial standards will also be used to propose extensions to the USIGS technical architecture as needed to support the GII. As required, these defined extensions will also be provided as input to the JTA and Defense Information Infrastructure Common Operating Environment (DII COE).

The primary focus of these extensions is to support the evolution toward the use of commercial off-the-shelf (COTS)-based geospatial information applications. With well defined technical architecture standards, commercial vendors will be able to offer geospatial application solutions which meet the requirements for interoperability and offer the opportunity for rapid technology insertion. The OGC is expected to play an important role in facilitating this process and in defining standard API’s to access commercial solutions.

A secondary focus is on the application platform entity. Geospatial extensions to the JTA profile for the application platform entity are yet to be determined, but may include Structured Query Language 3 (SQL3) for data management and Vector Product Format (VPF) for data interchange. Although the JTA will largely be sufficient to meet the needs of the GII, some geospatial-specific extensions may be required (e.g., human-computer interface standards specific to geospatial applications).

3.3.3 USIGS Technical Architecture

Implementing the GII within the USIGS technical architecture is important because it:

• Establishes the set of principles (in terms of standards, conventions, guidelines, data formats, etc.) applicable to new and migration system development, and application component development, across the USIGS community;

• Establishes the context within which international standards can be established for the broader USIGS community;

• Provides a technical architecture environment based upon the concept of open distributed computing; and

• Promotes interoperability across the USIGS community by focusing on common services and open interfaces among USIGS systems and components.

The USIGS technical architecture is defined in three time-phased views:

• Currently mandated standards,

• Emerging and candidate standards (near-term), and

• Emerging technologies.

Using this approach, standards can be tailored by the user organization to facilitate system development and evolution. As emerging technology matures and standards approach obsolescence, the technical architecture must evolve to establish new standards at reasonable, announced intervals. This approach supports both stability and progress.

The USIGS architecture is based on distributed object computing technology. A distributed object is a component that is designed to interoperate across a heterogeneous network of hardware and software. Each object is also designed to be independent, self-managing and secure. Distributed objects work with all other distributed objects connected through an object bus. Distributed object based architectures are scalable and offer the potential for reduced software development and maintenance costs.

A basic object model is shown in Figure 3-4. In this model, all access to the computing services is through standard APIs that access a distributed computing services object bus. This encourages strong object definition, reuse/sharing of components, and common access/processing of the Mission Specific Applications and Open Geospatial Exchange (OGE) Services. The distributed object services approach represents a major shift from the traditional one-to-one interface between applications. It offers a common set of services whereby applications use objects to satisfy their functional needs.

The technical architecture also emphasizes the separation of applications from infrastructure services. This promotes the sharing of common software functions on the application platform. It also emphasizes the separation of user interfaces from support applications, promoting client-server capabilities, and the sharing of support application services by multiple applications instead of the replicated functionality common today.

Many current software packages do not fulfill this goal of plug-and-play interoperability, yet they provide valuable capabilities for fulfilling operational missions. The goal of the technical architecture is not to preclude the use of these packages, but to establish the minimum level of compliance necessary to:

• Reasonably deploy large systems;

• Establish a target level of compliance to serve as a basis of selection for competing products; and

• Provide guidance for future information set developments.

Figure 3-4 USIGS Distributed Environment

Components of the technical architecture are defined in the USIGS Technical Reference Model (UTRM). This model highlights interfaces for services within a distributed computing environment. Note that the reference model is not intended to define physical components or connections, nor does it show software modules or aspects of software implementation. Engineering design considerations such as these are part of the system architecture.

A simplified version of the UTRM is shown in Figure 3-5. The USIGS model is based on the DoD Technical Architecture Framework for Information Management (TAFIM) Volume 2 and various derivatives, including the DII COE Reference Model and the draft Intelligence Community Technical Reference Model (IC TRM). The IC TRM was adopted by the Intelligence Systems Board (ISB) Standards Panel in April 1996, but was never officially published.

The content of the UTRM is a profile of the JTA that borrows from the Object Management Group’s (OMG’s) Object Management Architecture (OMA). It is based on a distributed computing environment and is built around the concepts of an object model presented in Figure 3-4. The UTRM will be used to organize discussion of the standards, conventions, and guidelines that make up the complete technical architecture.

Figure 3-5 Simplified USIGS Technical Reference Model

3.3.4 USIGS Technical Reference Model Entities

The UTRM consists of the following six basic entity types:

• Mission Specific Applications,

• Common Support Applications,

• Common Facilities,

• Platform Services,

• Distributed Computing and Object Services, and

• External Entities.

Mission Specific Applications

Mission specific applications are, typically, those applications with which a user interacts and which provide specific services to a user. This entity type is based upon the DII COE view, wherein an application is considered to be mission specific if it:

• Is used to support a specific military missions (e.g., maritime, land, Joint/CINC/Coalition, air, intelligence), or

• Provides user services for “vertical markets” within the DoD (e.g., medical support).

For the most part, the UTRM does not identify specific applications but rather identifies categories of applications that may be regarded as mission specific. Categories of applications that are currently defined as mission specific to the USIGS were determined through examination of the NIMA Business Plan and co-referenced with the USIGS Operational Architecture.

USIGS Mission Specific Applications categories, shown in Figure 3-6, include:

• Information Discovery and Retrieval - applications to navigate the USIGS to locate and retrieve information, products, and services;

• Information Viewing and Enhancement - applications to open, view, and enhance imagery, imagery intelligence, and geospatial products and information;

• Information Exploitation and Analysis - applications to analyze, exploit, and extract information from geospatial products and information;

• Information Integration and Fusion - applications to combine, integrate, layer, and fuse multiple types of information;

• Order Entry & Tracking - applications to accept, process, track, and support delivery of information, products, and services;

• Information Production - applications that are used to generate imagery intelligence and/or other geospatial information;

• Information Production Management - applications that manage information production processes;

• Information Storage and Retrieval Systems - applications that provide for digital storage and retrieval of formatted products and seamless data;

• Information Delivery - applications that accept, store, and execute information interest profiles to support the delivery of required information;

• Information Reproduction and Replication - applications that generate, reproduce, and replicate digital products and information sets; and

• Customer Support - applications that deal with users’ needs for information about products, information sets, and services.

Figure 3-6 USIGS Mission Specific Application Categories

Common Support Applications

Common support applications, shown in Figure 3-7, are of two basic types. First, there are applications that have a user interface, but which provide only general support. Example categories for general support Common Support Applications include:

• Office Automation Services: - functional capabilities that include, but are not limited to, word processing, email, presentation graphics, spreadsheet, drawing, and illustration;

• On-Line Help Services - provide users with the necessary assistance in all aspects of system operation. Four basic support services are required to achieve comprehensive coverage of system operation: On-Line Help, On-Line Job Planning, On-Line References, and Computer-Based Instruction (CBI);

• Alert Services - include generic mechanisms to support an alert process. When an alert process has determined that a predefined criterion or event for notifying other processes has occurred, that process will use the Alert Services software to notify all interested processes and parties of the event;

Figure 3-7 Common Support Applications and the Open Geospatial Exchange (OGE) Service Categories

• Correlation Services - include, but are not limited to, maintenance of a track database in near real time to include the following information: high level tactical objects to represent platforms (ships, submarines and aircraft), installations (both fixed and land mobil), land force units, and technical collection and reporting domain track objects (e.g., ELINT, COMINT).

The other type of Common Support Applications contains information domain applications that are used by other applications. For USIGS, as shown in Figure 3-7, the information domain specific Common Support Applications are provided by OGE Services. These applications are based on standardized APIs and provide services that can be invoked by other applications. The APIs are being defined using International Organization for Standardization (ISO) Interface Definition Language (IDL). As commercial vendors develop standard IDL APIs, their COTS solutions will be considered for use as applications in OGE Services.

The OGE Service categories which have currently been defined include:

• Geospatial Information Access Services - defines a set of interfaces for retrieving selected geospatial information and products from a geographic information system (GIS) and for updating the contents of a GIS (by storing, deleting, or modifying geospatial information or products);

• Feature Generalization Services - services that modify the characteristics of a feature collection to increase the effectiveness of communication by counteracting the undesirable effects of data reduction;

• Geospatial Catalog Services - supplies a set of common software services to support both local and global product discovery, product attribute (metadata) retrieval, product browsing, and product cataloging and indexing;

• Geospatial Information Extraction Services - services supporting the extraction of feature and terrain information from remotely sensed and scanned images;

• Geospatial Coordinate Transformation Services - services for converting geospatial coordinates from one reference system to another;

• Geospatial Annotation Services - services to add ancillary information to a feature in the Feature Collection (e.g., by way of a label, a hot link, or an entry of an attribute for a feature into a database) or image that augments or provides a more complete description;

• Imagery Manipulation Services - interfaces to standard algorithms for manipulating imagery (resizing, changing color and contrast values, applying various filters, manipulating image resolution, etc.) and for conducting mathematical analyses of image characteristics (computing image histograms, convolutions, etc.);

• Geospatial Manipulation Services - services that support creation, quality control methods, analysis, display, and generalization of feature collections of interest to an end user;

• Imagery Exploitation Services - services required to support the generation of intelligence reports and other products that ultimately reach policy makers and other consumers of intelligence;

• Geospatial Analysis Services - exploits information available in a Feature Collection to derive mission-oriented quantitative results that are not available from the raw data itself;

• Geolocation Services - interfaces to software tools that support the derivation of precise geographic coordinates on images and maps;

• Geospatial Symbolization Services - services management of symbol libraries, the linking of symbol types to specific features for display, and the representation of symbols as proxies for features in legends and portions of feature collections displayed on the screen;

• Geospatial Dissemination Services - interfaces required to receive, prepare (reformat, compress, decompress, etc.), prioritize, and transmit geospatial information and products; also defines standard interfaces to support information and product distribution management and to enable dissemination of imagery and image information and products to third parties;

• Image Map Generation Services - interfaces for automatically aligning, co-registering, or otherwise determining image-to-image spatial correlations on the basis of image content;

• Image Synthesis Services - interfaces for creating or transforming images using computer-based spatial models, perspective transformations, and manipulations of image characteristics to improve visibility, sharpen resolution, and/or reduce the effects of cloud cover or haze;

• Image Understanding Facility - enables automated image change detection, registered image differencing, significance-of-difference analysis and display, and area-based and model-based differencing;

• Geospatial Display Services - services that prepare and execute the rendering of one or more Feature Collections or Coverages to an output device.

Common Facilities

The Common Facilities, shown in Figure 3-8, are likely to be developed by other organizations such as OMG and fulfill key requirements of the USIGS technical architecture. As the IDL specifications for each of these facilities are completed and published, they will be thoroughly assessed, and those that are found to meet the requirements for the USIGS will be adopted as components.

A description of each common facility, as currently defined by the OMG, follows.

• Automation and Scripting Facility - defines conventions and interfaces that allow access to the key functionality of an object from another object. The design goal of this facility is to support user visible objects which are larger grained than the typical object request broker (ORB) object. The typical object acted upon by the Automation and Scripting Facility would be a document, a paragraph, a spreadsheet cell, and so forth. The emphasis of the facility is for objects to expose enough of their capabilities so they may be driven by scripts and macros.

Figure 3-8 Common Facilities in the USIGS Technical Reference Model

• Compound Presentation and Interchange Facility - enables the creation of cooperative component software that supports compound documents, that can be customized, that can be used collaboratively, and that is available across multiple platforms. Also provides for the storage and interchange of data objects, and roughly maps to the persistent storage subsystem of a compound document architecture.

• Data Interchange Facility - allows for the exchange of information across networks of heterogeneous computer systems by providing a common information model and a common way of encoding information within that model. Encoding must support not only character data, but other sorts of data as well, including imagery, graphics, multimedia documents, and electronic mail. Enables objects to interoperate through exchange of data, and can be used for many forms and kinds of data transfer, such as: bulk transfer; interchange of formatted data such as TIFF, GIF, EPS, NITF, etc.; structured data transfer such as ISO IDL specified data types; interchange of domain-specific object representations; and the data interchange between objects and encapsulated software (legacy applications).

• Imagery Compression Facility - defines a set of interfaces to generalized services for imagery compression and decompression, and for conversion between internal representations and standardized representations of such data.

• Information Storage and Retrieval Facility - comprises the higher level storage and retrieval specifications for distributed applications. These specifications will be applicable to a wide range of information services, including database access and information highways.

• Internationalization and Time Operations Facility - enables developers to use an information system or application in their own language using their own cultural conventions. In addition, this technology will allow the developer to use a culture’s numeric and currency conventions, and keep track of time zones.

• Meta-Object Facility - defines the interfaces and sequencing semantics needed to create, store, and manipulate object schemas that define the structure, meaning, and behavior of other objects within the OMG Object Management Architecture. These objects may be application objects, common business objects, objects representing analysis and design models of applications, or objects providing the functionality of Common Facilities and Common Services. The Meta-Object Facility can be used in an information system (such as a repository) that enables an enterprise to specify and manage a wide variety of information assets with a common, integrated set of services. The use of a common meta-object facility for specifying the schemas of the information assets will play a key role in helping to achieve data and process integration by enabling tools and processes to share information and coordinate activities.

• Mobile Agents Facility - supports the need to create massively distributed information systems over Wide Area Networks. Agent technology efforts range from building these massively distributed systems to mobile information systems, intelligent workflow systems, and agile corporation information structures.

• Printing Facility - one component of a coordinated set of facilities and standards needed to satisfy modern distributed printing requirements. Together, the capabilities provided must enable users to create and produce high-quality documents in a consistent and unambiguous manner within a distributed object environment. The Printing Facility should be able to meet a range of printing requirements from simple one document, one copy printing, all the way up to high volume production printing, which might involve several documents, several copies, and several printers.

• Rendering Management Facility - provides facilities to present information for output on devices such as screens, printers, plotters and sound and speech output devices. It also handles user input from a variety of hardware devices such as a mouse, keyboard, scanner, speech recognition device, digital camera, and security devices. Rendering management includes support for window management, class libraries for user interface objects, user interface dialog objects, and abstractions of the many different input/output devices.

• Security Administration Facility - provides standard interfaces, as well as the necessary control mechanisms, to facilitate required security protections, including provisions for:

  • User registration, password maintenance, permissions maintenance;

  • Access control, authentication, and audit trail maintenance;

  • Resource registration;

  • Security classification downgrading;

  • Encryption key management; and

  • Discretionary and mandatory access control.

• Workflow Facility - provides management and coordination of objects that are part of a work process (e.g., purchase orders). This facility will provide support for production-based workflow in the form of structured, pre-defined processes that are governed by policies and procedures, as well as ad-hoc, or coordination-based workflows, including evolving workflows defined by one or more people to support the coordination of knowledge workers.

Distributed Computing and Object Services

The Joint Technical Architecture (JTA) allows for the use of either the Distributed Computing Environment (DCE) standard or the Common Object Request Broker Architecture (CORBA) specification for distributed computing services. This choice of distributed computing environments is based upon a choice between procedural computing or object oriented computing. NIMA has determined that the preferable paradigm for future USIGS application interoperability is the object oriented paradigm and, therefore, the distributed computing environment of choice is that based on the CORBA specification. This also implies the choice of Object Services as shown in Figure 3-9. APIs for these services have been defined by OMG, and industry is already creating some usable bridges through developments such as Object Linking and Embedding / Common Object Model (OLE/COM) and ActiveX- Distributed Component Object Model (DCOM).

The OMG Object Services are defined as follows:

• Collections Service - provides a uniform way to generically create and manipulate the most common collections. Collections are groups of objects which, as a group, support some operations and exhibit specific behaviors related to the collection, such as stacks, queues, and lists.

Figure 3-9 OMG Object Services in the USIGS

• Concurrency Control Service - enables multiple clients to coordinate their access to shared resources. Coordinating access to resources means that when multiple, concurrent clients access a single resource, any conflicting actions by the clients are reconciled so that the resource remains in a consistent state. The Concurrency Control Service consists of multiple interfaces that support both transactional and non-transactional modes of operation.

• Event Service - provides basic capabilities that can be configured together in a very flexible and powerful manner. Asynchronous events (decoupled event suppliers and consumers), event “fan-in,” notification “fan-out,” and - through appropriate event channel implementations - reliable event delivery are supported. Both push and pull event models are supported; i.e., consumers can either request events or be notified of events, whichever is needed to satisfy application requirements.

• Externalization Service - defines protocols and conventions for the externalization and internalization of objects. Externalizing an object is to record the object state in a stream of data (in memory, on a disk file, across a network, etc.) and then internalize it into a new object in the same or different process. The externalized object can exist for arbitrary amounts of time, be transported by means outside the ORB, and be internalized in a different, disconnected ORB.

• Interface Type Versioning Service - provides for the management of the evolution of interfaces and their IDL descriptions. The service will provide the ability for a system to recognize that a new interface has evolved from an old one, allow multiple versions of the “same” interface to exist at the same time, allow for a choice of automatic or manually specified conversion to use a new interface, and support the concept of a default version of an interface.

• Licensing Service - provides a mechanism for producers to control the use of their intellectual property in a manner determined by their business and user needs. This service offers fundamental usage control.

• Life Cycle Service - defines services and conventions for creating, deleting, copying, and moving objects. Because Distributed Computing Environments support distributed objects, life cycle services define services and conventions that allow clients to perform life cycle operations on objects in different locations.

• Messaging Service -provides interfaces that allow clients to make requests on an object without blocking the client execution thread. Some requests are not expected to be complete during the lifetime of the client execution environment, so mechanisms will be established to receive the response and process it appropriately. The service allows object servers to control the order in which incoming requests are processed.

• Naming Service - provides the ability to bind a name to an object relative to a naming context. A naming context is an object that contains a set of name bindings in which each name is unique. To resolve a name is to determine the objects associated with the name are given context. Through the use of a “names library,” name manipulation is simplified and names can be made representation independent, thus allowing their representation to evolve without requiring client changes.

• Persistent Object Service - provides common interfaces to the mechanisms used for retaining and managing the persistent state of objects. The Persistent Object Service will be used in conjunction with other Object Service Interfaces such as naming, relationships, transactions, and life cycle. The Persistent Object Service has the primary responsibility for storing the persistent state of objects, with other services providing other capabilities.

• Properties Service - provides the ability to dynamically associate named values with objects outside the static IDL type system. The interfaces provided by this service are used for defining, deleting, modifying, enumerating, and checking for the existence of properties. By using the interfaces defined by the Property Service, useful information such as a title or a date can be associated with an object’s state.

• Query Service - provides query operations on collections of objects. The queries are predicate-based and may return collections of objects. They may be specified using object derivatives of SQL and/or other styles of object query languages including direct manipulation query languages. Query operations include selection, insertion, updating, and deletion on collections of objects or data.

• Relationship Service - allows entities and relationships to be explicitly represented. Entities are represented as objects. The service defines two new kinds of objects: relationships and roles. A role represents an object in a relationship. The Relationship interface can be extended to add relationship-specific attributes and operations. Similarly, the Role interface can be extended to add role-specific attributes and operations.

• Security Service - protects an information system from unauthorized attempts to access information or interfere with its operation. For example, security services may include (but are not limited to) the following:

  • Confidentiality - information is disclosed only to users authorized to access it.

  • Integrity - information is modified only by users who have the right to do so, and only in authorized ways. It is transmitted only between intended users and in intended ways.

  • Accountability - users are accountable for their actions relevant to security. A particular case of this is non-repudiation where responsibility for an action cannot be denied.

  • Availability - use of the system cannot be maliciously denied to authorized users.

• Startup Service - enables requests to automatically start up when an Object Request Broker is invoked.

• Time Service - maintains current time, ascertains order in which events occurred, and computes the interval between two events.

• Trader Service - provides a matchmaking service for objects – registers availability of the service, provides parameters, distinguishing attributes, and names of operations to which it will respond. It also allows objects in different domains to negotiate and share services without losing control of their own policies and services.

• Transaction Service - supports multiple models (flat and nested) of transactional behavior in a distributed heterogeneous environment. The Transaction Service brings the transaction paradigm, essential to developing reliable distributed applications, and the object paradigm, key to the productivity and quality in application development, together to address the business problems of commercial transaction processing.

Platform Services

Platform Services in the UTRM are derived from the DII COE reference model and include the operating system and primitive level services that provide fundamental functionality to the platform in general, as illustrated in Figure 3-10. While Platform Services are of great significance in the development of software using traditional structured procedural techniques, the specifics of the Platform Services will take on less and less importance as the USIGS migrates to a fully component based architecture based on CORBA. When the USIGS is completely migrated to a component based architecture based on CORBA, the choice of platform and services will depend only on performance characteristics and the meeting of minimal standards for network services.

Platform Services include:

• Data Interchange - includes file formats and protocols required for the transfer of information among applications program.

• Data Management - includes File Access, File Management, Database Access, and Database Management. Includes definition, storage, and retrieval of files, databases, and object bases distributed over the network. Includes data exchange facilities between users, computers, and databases.

• Distributed Computing and Object Services - capabilities that permit procedures and objects to be invoked on remote hosts as though they were local to the calling module. In addition to these basic capabilities, the distributed computing component is accompanied by a variety of enabling services, such as security, time, persistence, and naming; many of these services are required for the development of applications that are distributed. The two fundamental technologies that will be implemented in the COE are the DCE and the CORBA, including some related services.

• Graphics - services that provide for device-independent rendering of both vector-based and raster-based graphics, for purposes including, but not limited to: plotting, computer-aided design (CAD) manipulation and display, simulation, animation, scientific visualization, process control, and art. These services include graphical, attribute and input primitives; coordinate and systems clipping; and input and output model implementation.

Figure 3-10 Platform Services in the USIGS Technical Reference Model

• Network - an infrastructure of coordinated services primarily supporting connectivity and data exchange between one mission application system or workstation and another. Network services provide the capability to send, receive, forward, and manage electronic and voice messages. They also provide real-time information exchange services in support of interpersonal conferences. These services include Personal Message Transfer, Organizational Message Transfer, enhanced telephony, shared screen, teleconferencing, and broadcast.

• Operating System - the core services required for the management and control of the hardware platform resources, including the central processing unit (CPU), memory, physical file storage and retrieval, and generalized input and output. Services in this category include such platform management functions as: process, physical file, input/output, and memory management.

• Security Systems Management - administrative tools required for the management of information and communications security within a single platform and between and among multiple platforms.

• Software Engineering - a collection of the basic services required to develop software for a given platform, including text editors, compilers, linkers, interpreters, and certain virtual machines (e.g., the Java virtual machine).

• System Management. - ability to manage all hardware and software resources in a heterogeneous, distributed information system. Includes network administration, and system administration. Includes four of the five System Management Functional Areas defined by ISO: configuration management, fault management, performance management, and accounting management. Three levels of management have been defined for DII: global, campus, and site.

• Transaction Processing - services required to support transactional access to a single database manager on a single platform or on multiple platforms (i.e., a distributed database management system), transactional access to non-database resource managers (e.g., automated tellers), Online Transaction Processing (OLTP), and distributed transaction processing.

• User Interface - services required for the exchange of information with a user. Specifically, services to display information, including rendered graphics, on a user’s workstation, printer, or other display device and to accept information from a user through an input device.

External Entities

External Entities, as defined in the Institute of Electrical and Electronics Engineers (IEEE) Draft Guide to the POSIX Open System Environment and in the UTRM, are of two types: Information Interchange Entities and Communications Entities. Information Interchange Entities are those hardware devices with which the platform services exchange information. These include keyboards, displays, mass storage devices, joysticks, and mice. Communications entities are those hardware devices required to exchange information among platforms (e.g., wires, switches).

3.4 GII System Architecture

Under the C4ISR definition, the System Architecture defines the physical connections, location, and identification of the key nodes, circuits, networks, platforms, etc., and specifies system and component performance parameters. It is constructed to satisfy operational architecture requirements per standards defined in the technical architecture. The system architecture shows how multiple systems within an area are linked and interoperate, and may describe the internal construction or operations of particular systems within an architecture.

The system architecture enables or automates operational activities through physical processes. Key characteristics include the following:

• Driven by the operational architecture;

• Maps systems with their associated platforms, functions, characteristics, and data elements back to the operational architecture;

• Identifies system interfaces and defines the connectivity between systems;

• Defines system constraints and bounds of system performance behavior;

• Shows systems interconnectivity from sensor-to-shooter/decision maker through the system components; and

• Technology-dependent, showing how multiple systems within or across subject areas are linked and interoperate, and may describe the internals of particular systems.

As described in Volume 1 of the Master Plan, the GII is the collection of people, doctrine, policies, architectures, standards, and technologies necessary to create, maintain, and utilize a shared geospatial Framework. Also as discussed in section 3.3, GII Technical Architecture, the GII represents the geospatial domain of the USIGS environment. In the context of a systems architecture, other than prototype instantiations of the GII (e.g., GII 97), there is no specific system architecture associated with the infrastructure. However, systems constructed using the components of the GII can be expected to have certain characteristics. These include the following:

• A relationship to other architectures as defined by the requirements of those specific architectures (e.g., DII, Horizon, Copernicus, MAGTF C4I). The GII provides geospatial domain information and services to all service and agency architectures within the USIGS community.

• A complex “system-of-systems” structure, requiring GII based components to work with a large number of currently deployed and planned systems. These systems include command and control (C2), mission planning, and modeling/simulation. Legacy systems not complying to the GII technical architecture may need gateways to make their information and services available.

• An Internet-like structure in which geospatial information services are provided by a large number of autonomous entities through a global communications network. The communications network will be logically and physically partitioned to meet security and performance requirements. The communication network include local area networks, wide area networks, and broadcast communications.

• System components distributed worldwide to support end users wherever they are. Users include both humans (e.g., mission planners) and machines (e.g., navigation equipment), working both on-line and off-line. While the GII emphasizes on-line access to geospatial information, equipment, facilities and transportation networks will be required to support production and dissemination of traditional hardcopy map products as well as digital media (e.g., CD-ROMs).

• Subject-oriented information collections (i.e., information libraries) connected to communication networks at a variety of security levels. These collections should operate in a federated manner. That is, users should be able to access multiple collections with a single request, yet each collection should be able to operate independently, without centralized control.

• Information distributed worldwide to support autonomous operations and ensure high performance and availability. This may necessitate “regional information libraries” with copies of information from other libraries, as well as unique data of local interest.

• Production systems that receive information from collection systems and other production systems on the network and produce new imagery, imagery intelligence, and geospatial information.

A notional system architecture depicting these characteristics is shown in Figure 3-11. For potential vendors of GII components, the complexity of the system architecture may at first appear daunting. However, the level of integration and interoperability necessary for a given component can vary according to its purpose. This may range from a moving map display with no network connection to a geospatial information library with worldwide connectivity to a large variety of users and systems.

Figure 3-11 Notional GII System Architecture

Since GII is part of the USIGS architecture, this section will provide a mapping of the GII operational architecture categories to the USIGS Mission Specific Applications categories. This provides a mapping of “where” the geospatial components of the GII are located in the USIGS architecture and “how” they are implemented by USIGS services (i.e., OGE services). However, the USIGS architecture will continue to be influenced by ongoing developments in the GII through a community assisted spiral engineering process and thus these mappings may need to be revised.

The steps to perform this mapping are described below:

• First, the five GII operational architecture mission areas (i.e., requirements management, data acquisition, data production, information management and dissemination, information applications) and USIGS Mission Specific Applications categories (described in section 3.3.4) are mapped onto the USIGS information cycle. This answers the question “where” the GII geospatial components are located in the context of the USIGS technical architecture.

• Second, the GII Geospatial Prototyping Facility (GPF) provides various implementations of the GII operational architecture categories. These implementations are described and documented as a set of system architectures driven by a community assisted spiral engineering process. The first GII system architecture is called the GII 97.

• Third, the GII system architecture is technology dependent. Technology forecasts and roadmaps will be considered for how these factors may potentially affect the GII system architecture in the future.

The three steps described above will be addressed in the following subsections.

3.4.1 Mapping the GII Operational Architecture to USIGS Mission Specific Applications Categories

This mapping is performed by comparing the components of the operational architecture and the mission specific applications categories with the USIGS information cycle.

The GII operational architecture, repeated as Figure 3-12, is comprised of five major mission areas:

• Requirements Management - a process based on identifying essential elements of geospatial information needed to support national security, defense, and civil missions;

• Data Acquisition - includes remotely sensed imagery, vector data, and other ancillary data sources;

Figure 3-12 GII Operational Architecture

• Information Production - initially targeted at the population of Foundation Information, with densification of data to produce Mission Specific Data Sets;

• Information Management and Dissemination - a process that coordinates requirements with acquisition and production assets while ensuring information and product transmission via the proper media and format; and

• Information Applications - allows and promotes interoperability with the DII COE, civil, academic, and commercial operating environments, thus providing an integrated view of the mission space.

This operational architecture supports the production and acquisition of mission-essential geospatial information based on a strategy that supports both readiness and responsiveness. The readiness component uses scheduled production to provide near global coverage of Foundation Data and MSDS based on area requirements. Together, this information supports global monitoring and assessing, mission planning, and quick-response operational needs. The responsiveness component provides additional MSDS by rapidly intensifying Foundation Data to meet specific crisis/emergency requirements.

Figure 3-13 USIGS Information Cycle

As shown in Figure 3-13, the USIGS information cycle begins and ends with the user. When users input their geospatial information needs and requirements, the Workflow Management portion of the architecture is activated and distributes user requirements to the collection. The Workflow Management cell is also responsible for keeping the users aware of the response and status of their geospatial information orders.

The Collection cell is responsible for tasking the necessary systems and acquiring geospatial data including: remotely sensed, vector, and other ancillary source data. After collection, the acquired source data is sent to the Processing cell where such things as enhancement, geo-rectification, and mosaic generation may take place. The geospatial data is then sent via the Primary Dissemination cell to the Library & Catalog cell where it is made available to any user with access to USIGS. If the user does not require raw data, the data will first be exploited, analyzed, and integrated with other source material to satisfy specific production requirements in the Exploitation & Production cell. The Dissemination & Reporting cell is then responsible for delivery of the geospatial information which satisfies the initial user’s requirements.

Figure 3-14 Relationships between NIMA PEOs, Mission Specific Applications Categories, and OGE Services

Figure 3-14 shows the organizational relationships between the USIGS Mission Specific Applications categories and NIMA program element offices (PEOs). It also shows the relationships between USIGS Mission Specific Applications categories and the supporting OGE Services. As indicated previously in the technical architecture section, the USIGS Mission Specific Applications are developed through the use of the USIGS OGE Services. At present, OGE Services are being defined, and a mapping between USIGS Mission Specific Applications categories and OGE Services is underway.

Figure 3-15 shows the overall mapping of the GII and USIGS categories onto the USIGS information cycle.

Figure 3-15 Overall Mapping of the GII and USIGS Categories onto the USIGS Information Cycle

3.4.2 GII 97 System Architecture

Since the goal in defining an evolutionary GII system architecture is to move towards a USIGS-based framework, the methodology deployed to achieve that is carefully designed. Initially, each of the GII functional allocations (Information Production, etc.) is configured in an assessment environment in the Geospatial Prototyping Facility (GPF). Each step of the way, the results of assessment will help verify, define, or refine the GII through enhanced requirements definition, standards development and risk management. A feedback mechanism will direct the assssments conducted in the GPF to maximize the benefit to the USIGS initiative.

There are numerous vendor products that are being assessed in the GPF. These products are listed in Figure 3-16 through Figure 3-18.

Figure 3-16 GPF Information Production Process

Figure 3-17 GPF Information Applications Process

Figure 3-18 GPF Information Management and Dissemination Process

These diagrams show the functions performed by the various vendor products in the assessment portion of the GPF against each of the major components of the GII - Information Production, Information Applications, and Information Manage-ment and Dissemination. The products may have additional capabilities, but those functions are not assessed at this time. There is one diagram for each of the major functional processes.

System architecture configurations for the assessment portion of the GPF are continually altered to determine the capabilities of the products to function on different platforms and in different configurations. The products will be assessed using three operational scenarios that have been developed with specific information, production and application requirements. Each of these operational scenarios will affect the particular configuration that will be used. These scenarios are discussed further in section 6 of this document. The GII 97 system architecture, which will be established once the assessments are completed, will be published in Volume 3.

There is also a production portion of the GPF where selected vendor products available under existing Government contracts are used for the actual production of Foundation Data. This configuration is shown in Figure 3-19.

Figure 3-19 GPF Initial System Architecture for Information Production

To support Foundation Data production, this portion of the GPF is maintained in a stable configuration.. The configuration is based on business process reengineering using the information production paradigm. It incorporates commercial and government off-the-shelf (GOTS) technologies that have been integration to optimize the Foundation Data production. Metrics are being gathered to compare this approach with NIMA’s current production processes.

3.4.3 Future Systems View - FY 2000 and Beyond

Future versions of the GII system architecture will be influenced by several factors including the continued development of the USIGS technical architecture and the DII COE; the incorporation of emerging technologies; and the eventual development of an enterprise system architecture.

As shown in Figure 3-20, many applications currently used in support of the GII are relatively independent applications that do not utilize other available underlying services. As the GII system architecture, USIGS, and other common support applications become available and interoperable, more GII applications are expected to use the underlying services that will then be available. Features of the goal architecture include:

• Interoperable Applications

• Reusable Software

• Object Oriented Technologies

• Common Utilities

Figure 3-20 Trends in Applications

3.4.3.1 GII Goal Architecture

The goal architecture will eventually be an enterprise system consisting of standard workstations within standard workgroup clusters that have connectivity to NIMA enterprise servers and enterprise warehouse data (see Figure 3-21). These workstations will, as a common utility, serve the needs of both imagery analysts and geospatial information analysts. The standard workgroup clusters will provide the functionality needed for standard IA/GI cells.

Figure 3-21 Enterprise System Concept

3.4.3.2 Emerging Technology

This section presents a variety of emerging standards and technologies expected to result in new standards and capabilities that will have a significant effect on future GII system architectures. This section is not intended to be a comprehensive analysis of technology trends in general, but rather to identify key categories of promising technologies and standards that could have considerable impact on the development of the GII.

Technology categories addressed in this section and that are expected to have significant effects on future GII system architectures are:

• Geospatial standards based interfaces,

• Geospatial commercial-off-the-shelf (COTS) products,

• Geospatial components,

• Distributed object technologies,

• Geospatial and intelligence extraction,

• Intelligent agents,

• Object-oriented database management systems,

• Communications infrastructure, and

• Hand-held personal computing devices.

Each of these technology categories is assessed relative to its maturity at the time of document completion, expectations for the near future, and its potential effects on the GII and the USIGS. These and other emerging technologies will continue to be assessed.

Geospatial Standards Based Interfaces

The first technology to have a large impact on the GII is the suite of interfaces being forwarded by the Open GIS Consortium that enable “Simple Feature Access.” There are two important consequences of these interfaces. The interfaces introduce a technology that is feature-centric, not product-centric. Commerce becomes enabled at the level of the exchange of a single feature.

COTS

The “Simple Feature Access” interfaces enable each vendor of a GIS to position their GIS as a client within a client-server architecture in which other vendors’ GIS’s are acting as servers. Alternatively, if it fits a vendor’s marketing plan, that vendor’s GIS can be marketed as a server. In either case, users are no longer stuck with single-vendor proprietary products, and the door is opened to competition at the component level.

Before the end of 1997, vendors will offer tool kits with which one may construct new clients and new servers as attachments to existing stovepipe systems, without regard to the brand name of the proprietary product. Of course, this outcome assumes that the stovepipe vendors will support the new interfaces, but it is obvious that vendors who fail to provide product that meets industry consensus standards will quickly lose market share.

Geospatial Components

An increase in the availability of geospatial components is expected to occur during the 1998-99 time period. Among the components will be catalogs, warehouses, geospatially-enabled browsers, photogrammetric clients and servers, cartographic clients and servers, geospatial information access services, feature generalization services, geospatial coordinate transformation services, grid services, imagery manipulation services, geospatial registration and adjustment services, geospatial symbolization services, dissemination services, image map generation services, and many others.

Distributed Object Technologies

It is predicted that distributed object technologies will increasingly be inserted into new and existing geospatial applications and products, thereby supporting a seamless network computing environment. At present there are several distinct distributed computing platforms, each with its own view of the distributed computing marketplace, and with unique interface designs that cater to those views.

With the Common Object Request Broker Architecture (CORBA), the view favors distributed platforms, each optimally hosting a specific service or data store. The ActiveX - DCOM favors a view composed of many active processes that seamlessly weave into a workflow. The Structured Query Language (SQL) model favors geoprocessing information services collocated with the generic information services associated with databases. In addition to the technologies noted, there are other Internet models that cater to still other architectural views.

Today, there is little interoperability between these architectures. The next two years will see them learn to become indistinguishable. The impact will be a much larger and more open marketplace, with correspondingly greater attention to the specific missions of users.

Geospatial and Intelligence Extraction

Intelligence extraction, geospatial feature extraction, and large image manipulations are performed today on expensive platforms constructed specifically for use with Government-only sources to accomplish primarily Government missions. Soon, however, the commercial marketplace will expand in the areas of remote sensing, distributed asset management, and real-time traffic management.

These tasks require capabilities similar to those of today’s custom Government systems. The consequences of this convergence are clear - - there will be intense pressure to offer the most advanced feature extraction and image manipulation functionality on COTS platforms.

Intelligent Agents

It is predicted that around the 1999 - 2000 time period, as the business model that characterizes the movement of source data and geospatial information across the GII develops and becomes mature, the GII will grow rapidly to remove bottlenecks and to optimize repetitive tasks. This will be the era of intelligent agents, optimization of communication channels, user profiles, and smart “push” technologies.

Object-Oriented Database Management System (OODBMS)

Emerging ODBMS technologies and new SQL3 and Object Database Management Group (ODMG)-93 standards that have been under development for some time are already having and will continue to have a significant impact on the GII architecture. At present, however, OODBMS’s make up only a tiny share of the overall $5.7 billion database market dominated by relational database management systems (RDBMS).

Based on the above forces, new standards, GII architecture, and a large base of legacy systems using RDBMS’s, it is predicted that geospatial applications will evolve to use a hybrid object-relational database management system (ORDBMS). This will enable legacy systems to interoperate with newly developed systems based on the GII architecture. Several ORDBMS products are already on the market and can be defined by the following features^:

• Support for the “traditional object model”, i.e., objects, classes (or user-defined types), attributes, methods, inheritance, and polymorphism.

• One-to-one, one-to-many, and many-to-many bi-directional references (with enforced integrity).

• An object-oriented (OO) “navigational” API, such that programmers using the database with an object programming language, such as C++ or Smalltalk, “see” the database as if it were an OODBMS.

• An SQL/Set API such that RDBMS programmers “see” the database as if it were an enhanced RDBMS.

• “Traditional” relational features such as indexes, constraints (unique, primary key, not null, etc.), triggers, security policies.

• Support for the SQL3 query language.

• Support for the ODMG object query language (OQL).

Communications Infrastructure

The backbone and limiting factor of many of the technologies discussed previously is the emergence and growth of global intelligent communication services. The goal of these services is to support real-time global point-to-point high-volume messaging. Global advertising and entertainment will be the primary markets driving the emergence of these services, but they will also be exploited by telephony, commercial broadcast, defense, and other communications-related market segments. The fundamental technology supporting this marketplace consists of networks of “cellular” and “broadcast” satellites that will be launched in increasing numbers over the next five years.

Hand-held Personal Computing Devices

An extremely important development will be the hand-held or shirt-pocket device that contains the capabilities of today’s telephone, Global Positioning System (GPS) receiver, television (broadcast and display), and Internet access devices. This innovation, together with global “cellular-like” communications, will provide the basis for an explosive new information-based economy into which geospatial services are seamlessly interwoven. These developments will signal the maturity of the GII Architecture.

4 GII Requirements

Note that where there has been a change in the statement of a specific requirement, or where a new requirement has been inserted in this version of the document as compared to the last draft (Version 0.21, dated 17 Jan 97), the requirement is shown in italics.

4.1 Requirements Management

This section describes the functions necessary to collect, analyze, consolidate, prioritize and manage GII requirements. The GII requirements process extends from the guidance provided by the National Command Authorities, through policy makers who develop strategies, campaign plans, and operational plans; to warfighters, the military departments, defense agencies and other U.S. Government organizations. All of these participants must be linked by a distributed database of GII requirements information. The GII requirements process is based on identifying the essential elements of geospatial information, products, and services required to support national objectives and mission specific operations.

GII requirements are categorized as information describing what is required (information, products, services, etc.) and where it is required (geographic areas). The GII requirements process must address each of these categories in a seamless, integrated environment supported by automated tools and techniques that make the submission and management of GII requirements information as easy as possible for NIMA and its broad user community. All relevant GII requirements information should be accessible to NIMA’s internal and external users for continuous review, analysis and update. Internal NIMA users responsible for production, customer support, and research and development (R&D) activities use the GII requirements information to support program development, program integration, user coordination, and R&D planning. External NIMA users employ the GII requirements information to help determine the geospatial readiness posture of their commands and organizations.

4.1.1 Requirements Drivers

The operational missions of the CINCs, Services and Agencies (C/S/As) have, in the past, been the principal basis for GII requirements submitted to NIMA. C/S/A operations plans (OPLANS) and contingency plans (CONPLANS) have also been the basis for identifying the geographic area requirements for needed geospatial products and services. As NIMA moves to a data-centric geospatial production and dissemination environment, requirements will be stated in terms of essential elements of geospatial information and linked directly to users’ mission responsibilities.

Technology enhancements (computers, networks, user interfaces, etc.) will create new requirements for geospatial information and dramatically expand the range of GII dissemination, manipulation and exploitation capabilities for the users. Mission Needs Statements (MNS), Operational Requirements Documents (ORD) and Mission-Essential Task Lists (METL) policy issues and intelligence problems will be used to describe these new requirements and the information will be made available to NIMA and its user community as part of an on-line, user-accessible geospatial requirements information database.

4.1.2 Current Environment

Geographic area requirements for standard NIMA geospatial products are submitted by C/S/As in accordance with guidance contained in CJCS Instruction 3901.01. For most products, NIMA users input requirements information using the Requirements Analysis System (RAS). Requirements for geospatial products and services not included in RAS are submitted separately to NIMA by users through a variety of methods and formats. Requirements for new geospatial products and services are also submitted by users to NIMA through a variety of methods and formats. DoD and NIMA Instructions provide general guidance describing the process for submitting requirements for new geospatial products and services. A formal, enterprise-wide process to identify the elements of geospatial information does not exist.

CJCS Instruction 3901.01 and the DoD and NIMA Instructions that describe the submission of geospatial requirements apply directly to NIMA’s DoD users. Other users have adopted the same policies and procedures, modified for their particular operational environments. The instructions are primarily focused on the identification of well-defined, standard geospatial products and services.

4.1.3 Future Environment

All portions of the requirements process should be networked and web-based and be accessible to all external and internal NIMA users.

In the future, users will submit GII requirements to NIMA using a process based on identifying the essential elements of geospatial information required to support national objectives and mission-specific operations. The process will be supported by the use of automated tools, advanced techniques, and web-based technologies for the identification, coordination, and management of geospatial requirements information. NIMA will maintain the geospatial requirements information of all its users in a user-accessible, distributed, collaborative environment. User interface to the requirements information will be provided via the NIMA Gateway Services environment.

Users, supported by NIMA Customer Support Teams (CSTs), will conduct assessments of their mission/task responsibilities to determine their requirements for geospatial information. Requirements will be used to develop mission profiles describing specific activities, events and operational scenarios. Quality assessments and meaningful mission/task profiles will be based on the answers to mission/task-related questions such as: What do you need to do? What decisions do you need to make? What views do you need to create? Answers to these questions will lead to the identification of the essential elements of geospatial information required to ensure successful mission execution.

NIMA will maintain the geospatial requirements information in databases modeled to categorize the information in terms of What and Where. User requirements information will be maintained in separate database partitions to ensure the privacy and integrity of the data. Access privileges will be provided to other users based on authorization and a valid “Need to Know”. Geospatial requirements information databases will be linked to other requirements-related databases maintained across the NIMA enterprise (Requirements Management System - RMS, Community Imagery Needs forecast - CINF, etc.). Requirements information contained in the databases will be used to program and direct NIMA’s geospatial information production assets.

The following information describes processes and capabilities that must be developed and/or enhanced to support implementation of an integrated geospatial requirements management process by FY2000:

• Development of an interactive web-based geospatial requirements information collection process - an enterprise-wide, distributed process for submitting and consolidating geospatial information requirements.

• Implementation of the new geospatial requirements process as an integral part of the NIMA Gateway Services environment. Implementation must also include the use of automated tools and techniques to support requirements maintenance, analysis, and reporting.

• Addition of a capability for users to state requirements for Foundation Data and Mission Specific Data Sets using the new requirements process and tools.

• Design, development and implementation of a mission decomposition process and a tool for the on-line identification, validation, prioritization, and submission of mission-specific geospatial information requirements.

• Design, development, and implementation of a Geospatial Requirements Information Database (GRID) for maintaining user mission profiles and mission profile catalogs. This database will link missions/tasks with systems, and organizations.

• Upgrade of RAS into a relational database that is seamlessly integrated into the web-based requirements process.

• Design, development and implementation of a simple easy-to-use Graphic User Interface (GUI) for accessing information from various geospatial requirements information databases that describe the What and Where of each element of information. The GUI must also provide seamless access to information about the availability of NIMA geospatial information and products being held in production databases across the enterprise.

• Access to the geospatial requirements information that is maintained by NIMA for all NIMA internal users (e.g., production managers, CSTs, R&D coordinators).

• Interface to other NIMA requirements systems such as RMS and CINF.

4.2 Data Acquisition and Information Production

This section describes the functional requirements for Data Acquisition and Information Production. Data Acquisition and Information Production are the processes of acquiring, generating, densifying, and maintaining Framework Information, specifically Foundation and Mission Specific Data Sets. The production function will also address the acquisition, evaluation, and establishment of reliable Qualified Data obtained from commercial and other sources.

It is assumed that Information Management and Dissemination (IM&D), as described in section 4.3, will provide all data storage, maintenance, and communications services. The production function will also address the acquisition, evaluation, and establishment of reliable metadata Qualified Data obtained from commercial and other sources. Also, it is assumed that functionality developed to meet Data Acquisition and Information Production requirements will use many of the same applications described in section 4.4, Applications.

In addition to the requirements specifically discussed in this section , the guidelines in section 3.3, GII Technical Architecture, shall be followed. Of specific interest are the standards profile, described in section 3.3.1 and Appendix C, as well as the details of the USIGS Technical Reference Model.

4.2.1 General Description

Data Acquisition and Information Production are responsible for the acquisition, generation, densification, and maintenance of Foundation and Mission Specific Data Sets, as well as Qualified Data, which are key components of Framework Information. Data Acquisition and Information Production are also responsible for the population, maintenance, and manipulation of Framework metadata.

This section provides a list of inputs and outputs required by the Data Acquisition and Information Production functions and describes the activities expected to perform these functions. Section 4.2.2 levies requirements on major functional components. The IPT encourages commercial feedback on alternative methodologies that meet or exceed the stated requirements.

Section 4.2.3 provides specific performance requirements for the production of Foundation and Mission Specific Data Sets.

Section 4.2.4 identifies additional issues and considerations beyond the specific functional and performance requirements. The IPT encourages commercial feedback on these as well.

Note that certain components of the Foundation (specifically aeronautical safety, navigation safety, magnetics and gravity) identified in Volume 1 of the Master Plan will be produced by other NIMA systems and provided as source to information production. NIMA has been addressing these capabilities in separate initiatives which are now being implemented and are expected to become operational through the year 2003. Although many of the requirements identified below will address the acquisition and production of this information, a comprehensive inclusion of requirements will occur in the next spiral.

4.2.2 Detailed Functional Requirements

4.2.2.1 Input Requirements

The intent of the input requirements section is to provide an appreciation of the wide variety of data (i.e., form, format and content) that NIMA must be able to exploit in order to accomplish its mission. The production function must be able to input non-Framework Information (e.g., foreign or commercial sources which are uncertified, or have unknown accuracy and other lineage), as well as Framework Information to include Qualified Data (i.e., legacy NIMA products and other sources with known accuracy, lineage), Foundation Data (e.g., DPPDB, CIB, DTED II, Foundation Features, Aeronautical Safety and Nautical Safety information), and Mission Specific Data Sets. This is not an all inclusive listing, but is intended to be representative of the sources anticipated for use in production.

The following sections outline some of the major categories of data that must be accepted for use as direct input or as reference material.

4.2.2.1.1 Digital Data

-a Digital Data, Support Data and Metadata - The ability to input the types of data below, its support data and metadata shall be provided.

-b DTED - The ability to input Digital Terrain Elevation Data (DTED) levels 1 - 5 shall be provided.

-c Digital Elevation Data - The ability to input Digital Elevation Data (Non-DOD standard Information e.g., Digital Elevation Model, Triangular Irregular Network) shall be provided.

-d DFAD - The ability to input Digital Feature Analysis Data (DFAD) levels 1 and 2 shall be provided.

-e ADRG - The ability to input ARC-Digitized Raster Graphics (ADRG) data shall be provided.

-f CADRG - The ability to input Compressed ARC-Digitized Raster Graphics (CADRG) data shall be provided.

-g Raster Scanned Data - The ability to input raster scanned data shall be provided.

-h Vector Graphic Data - The ability to input vector graphic data (in a variety of formats and from various sources including commercial and foreign) shall be provided.

-i PITD - The ability to input Planning Interim Terrain Data (PITD) shall be provided.

-j ITD - The ability to input Interim Terrain Data (ITD) shall be provided.

-k VITD - The ability to input VPF-Interim Terrain Data (VITD) shall be provided.

-l VMap - The ability to input Vector (Smart) Map (VMap) level 1 and 2 data shall be provided.

-m UVMap - The ability to input Urban Vector (Smart) Map (UVMap) data shall be provided.

-n DTOP - The ability to input Digital Topographic Data (DTOP) in VPF format shall be provided.

-o DNC - The ability to input Digital Nautical Chart (DNC) data shall be provided.

-p ENC - The ability to input Electronic Navigation Chart data shall be provided.

-q NFL - The ability to input Navigation Feature Layer (NFL) data shall be provided.

-r DPS MC&G format - The ability to input DPS MC&G format feature and elevation data shall be provided.

-s Framework Information - The ability to input Framework Information (as defined in the GII Master Plan, Volume 1) shall be provided.

-t SDRS Data - The ability to input Ships Data Recording System (SDRS) Data shall be provided.

-u MSDDB - The ability to input Master Seafloor Digital Database (MSDDB) data shall be provided.

-v Soundings - The ability to input soundings shall be provided.

-w AAFIF - The ability to input Automated Air Facilities Information File (AAFIF) shall be provided.

-x DAFIF - The ability to input Digital Air Facilities Information File (DAFIF) shall be provided.

-y DVOF - The ability to input Digital Vertical Obstruction File (DVOF) shall be provided.

-z Digital Names Data - The ability to input Digital Names Data shall be provided.

4.2.2.1.2 Intelligence Data

-a Intelligence Data, Support Data and Metadata - The ability to input the types of data below, its support data and metadata shall be provided.

-b TINT - The ability to input Target Intelligence file (TINT) data shall be provided.

-c MIDB - The ability to input Modernized Integrated Data Base (MIDB) data shall be provided.

-d Intelligence Studies and Reports - The ability to input Intelligence Studies and Reports shall be provided.

-e Janes PI/IT Keys - The ability to input data from Janes PI/IT Keys shall be provided.

-f GALE - The ability to input data for Generic Area Limitation Environment (GALE) shall be provided.

4.2.2.1.3 Digital and Hardcopy Imagery

-a Digital and Hardcopy Imagery, Support Data and Metadata - The ability to input the types of data below, its support data and metadata shall be provided.

-b NTM - The ability to input National Technical Means (NTM) imagery shall be provided (to include panchromatic, multispectral, hyperspectral, radar).

-c Commercial - The ability to input Commercial imagery shall be provided (to include panchromatic, multispectral, hyperspectral, radar).

-d Foreign - The ability to input imagery from foreign governments shall be provided (to include panchromatic, multispectral,hyperspectral, radar).

-e CIB - The ability to input Controlled Image Base (CIB) image product shall be provided.

-f DPPDB - The ability to input Digital Point Positioning Database (DPPDB) image product shall be provided.

-g Video - The ability to input video (NTSC and other formats) data shall be provided.

-h Acoustic - The ability to input acoustic imagery shall be provided.

4.2.2.1.4 Image Support data

-a NTM - The ability to input National Image Support Data (ISD) shall be provided (e.g., Metric Mapping Support Data, Adjusted Mapping Support data, Instrument Data file).

-b Commercial - The ability to input Commercial Image Support Data (ISD) shall be provided.

-c Foreign - The ability to input Foreign Government Image Support Data (ISD) shall be provided.

4.2.2.1.5 Hardcopy Cartographic Data and Textual Material

-a Hardcopy Cartographic Data and Textual Material, Support Data and Metadata - The ability to input the types of data below, its support data and metadata shall be provided.

-b Maps and Charts - The ability to input map and chart data shall be provided.

-c Notice to Mariners - The ability to input Notice to Mariners data shall be provided.

-d Notice to Airmen - The ability to input Notice to Airmen data shall be provided.

-e List of Lights - The ability to input List of Lights data shall be provided.

-f Graphic Overlays, Boundaries - The ability to input graphic overlays, Boundaries data shall be provided.

-g Graphic Overlays, Names Data - The ability to input graphic overlays, names data shall be provided.

-h Echograms - The ability to input echograms shall be provided.

-i Bathymetric Survey/Smooth Sheets - the ability to input bathymetric survey/smooth sheet data shall be provided.

-j Sounding Log Books - The ability to input data from sounding log books shall be provided.

-k NIMA Aeronautical Chart Update Manual - The ability to input NIMA Aeronautical Chart Update Manual (CHUM) data shall be provided.

-l Flight Information Publications - The ability to input Flight Information Publication (FLIP) data shall be provided.

4.2.2.2 Output Requirements

4.2.2.2.1 Foundation and Mission Specific Data Sets

These data sets consist of feature data, elevation data, geodetically controlled mono and stereo image data, support data and metadata as a result of Information Production.

The ability to produce the following information, support data, and metadata types shall be provided:

-a Mono imagery - The ability to produce geodetically controlled monoscopic imagery shall be provided.

-b Stereo Imagery - The ability to produce geodetically controlled stereoscopic imagery shall be provided.

-c Elevation - The ability to produce geodetically controlled elevation data shall be provided.

-d Features - The ability to produce geodetically controlled vector feature data shall be provided.

4.2.2.2.2 Foundation Data and Mission Specific Data Set Exchange Format Generation

Foundation Data and Mission Specific Data Sets shall meet or exceed NIMA specifications for accuracy, content and structure.

Conversion of Framework Information to NIMA standard products shall include the generation of:

-a CIB - The ability to produce geodetically controlled monoscopic imagery consistent with CIB (Controlled Image Base (CIB), MIL-C-89041, May 1995) shall be provided.

-b DPPDB - The ability to produce geodetically controlled stereoscopic consistent DPPDB (Digital Point Positioning Database (DPPDB) MIL-PER-89034 DRAFT) shall be provided.

-c DTED - The ability to produce geodetically controlled elevation consistent with DTED level 1 and 2 (Digital Terrain Elevation Data (DTED) MIL-PRF-89020A, Dec. 1995) and emerging high resolution DTED level 3 - 5 shall be provided.

-d VPF - The ability to produce geodetically controlled vector feature data consistent with VPF Products (MIL-STD-2407, Interface Standard for Vector Product Format (VPF), 2^nd Edition, et al) shall be provided.

-e FACC - Vector feature attribution consistent with FACC - Feature attribute coding (NATO STANAG 7074, Jan 94 DIGEST Part 4 Feature Attribute Coding Catalog) from framework information shall be provided.

-f Hardcopy maps and charts - as described in Apendix B of this volume

4.2.2.3 Process Rules

The Process Rules activity shall provide the capability to process rules that are applicable to NIMA products, services, information and processing. Rules include national, international, commercial, industrial, and agency technical and business concepts, standards, specifications. Rules provide or assist in providing consistency and uniformity of results.

-a Maintain Rules (Create, Review, Update, Delete, Organize Rules)

-b Process Rules

4.2.2.4 Acquire Source

The Acquire Source activity shall provide the capability to perform the following functions:

-a Search - The ability to search for geospatial information shall be provided (i.e., Web Crawlers).

-b Identify - The ability to identify sources automatically as they become available shall be provided (i.e. Smart agents).

-c Order - The ability to order hardcopy or softcopy source information shall be provided.

-d Retrieve - The ability to retrieve softcopy source information shall be provided.

4.2.2.5 Source Ingest

This Source Ingest activity shall provide the capability to perform the following functions:

-a Data Conversion - The ability to convert hardcopy maps and charts, echograms and imagery into a format (e.g. softcopy textual, vector, raster, raster-to-vector, vector-to-raster, gridded) for further processing shall be provided.

-b Digital Ingest - The ability to accept softcopy sources and perform adjustments for further exploitation of source data shall be provided.

4.2.2.6 Evaluate Data

The Evaluate Data activity shall provide the capability to perform the following functions:

4.2.2.6.1 Feasibility Study

Perform feasibility studies that evaluate the applicability, suitability, availability and quality of specific sets of data or products to meet specifications and requirements of geospatial information including:

-a Area of interest - The ability to determine the coverage of the area of interest by the source shall be provided.

-b Accuracy - The ability to determine the accuracy of the source shall be provided.

-c Obscuration - The ability to identify obscuration of features of interest in the source shall be provided.

-d Sufficiency - The ability to determine the sufficiency of source data content and density shall be provided.

-e Currency - The ability to determine the currency of the source shall be provided.

-f Change Detection - The ability to determine the difference between two or more sources of different dates or versions shall be provided

-g Maintenance - The ability to determine the requirements for routine maintenance shall be provided.

4.2.2.6.2 Source Collection Requirement

-a Generate Requirement - The ability to generate a requirement for additional source collection shall be provided.

4.2.2.7 Adjust Data

The Adjust Data activity shall provide the capability to perform the following functions:

-a Georeferencing - The ability to perform georeferencing shall be provided.

-b Geopositioning, Multi-Image - The ability to perform geopositioning of multiple image from the same sensor, including both triangulation and mensuration, shall be provided.

-c Geopositioning, Multi-Sensor - The ability to perform geopositioning from different sensors, including both triangulation and mensuration, shall be provided.

-d Datum transformations - The ability to perform datum transformations shall be provided.

-e Map projections - The ability to perform map projections shall be provided.

-f Image processing - The ability to perform image processing shall be provided.

-g Accuracy adjustments - The ability to perform accuracy adjustments shall be provided.

-h Map registration - The ability to perform map registration shall be provided.

-i Image rectification - The ability to perform image rectification shall be provided.

-j Image orthorectification - The ability to perform image orthorectification shall be provided.

-k Image mosaicking - The ability to perform image mosaicking shall be provided.

4.2.2.8 Extract Data

The Extract Data activity shall provide the capability to perform the following functions:

4.2.2.8.1 Select Source

-a Select Source - The ability to select production ready source for exploitation from the available source holdings shall be provided.

4.2.2.8.2 Identify Entity

The Identify Entity activity shall provide the capability to

-a Identify Entities - The ability to identify entities (features) through visual, statistical and other analyses and interpretation shall be provided. An example would be to identify a bridge or a road.

4.2.2.8.3 Extract Entity

The Extract Entity activity shall provide the capability to

-a Capture Entities - The ability to capture identified entities and data/information (feature, elevation, bathymetric, aeronautical and textual data) shall be provided. An example would be an actual delineation of a road centerline or bridge location.

-b Change Detection - The ability to perform entity change detection shall be provided.

-c Edit - The ability to edit the data entities shall be provided.

4.2.2.8.4 Attribute Entity

The Attribute Entity activity shall provide the capability to

-a Attribute - The ability to add appropriate attribution to the extracted data shall be provided. An example would be to attribute a road as all weather hard surface, no median and 6 meters wide.

-b Change Detection - The ability to perform attribute change detection shall be provided.

-c Edit Attribution - The ability to edit attributed data and metadata shall be provided.

4.2.2.8.5 Assemble Extracted and Attributed Entities

The Assemble Extracted and Attributed Entities activity shall provide the capability to

-a Assemble - The ability to assemble extracted and attributed entities into coverages shall be provided.

-b Edit - The ability to edit coverages shall be provided.

4.2.2.9 Integrate Data

The Integrate Data activity shall provide the capability to perform the following functions:

-a Conflation - The ability to perform conflation, which is the identification, resolution and merging of different renditions of what is actually the same entity, shall be provided.

-b Horizontal Integration - The ability to perform horizontal integration which is the integration of a dataset with datasets of adjacent geographical areas shall be provided.

-c Data fusion - The ability to perform data fusion which is the vertical integration of geographically coincident areas shall be provided.

-d Edit - The ability to identify and add, remove and modify data within a dataset shall be provided.

4.2.2.10 Generate and Manipulate Metadata

The Generate and Manipulate Metadata activity shall provide the capability to perform the following functions:

-a Identify - The ability to identify metadata shall be provided.

-b Capture - The ability to capture metadata shall be provided.

-c Update - The ability to update metadata shall be provided.

-d Delete - The ability to delete metadata shall be provided.

-e Organize - The ability to organize metadata shall be provided.

-f Query - The ability to query metadata shall be provided.

-g Analyze - The ability to analyze metadata shall be provided.

4.2.3 Performance Requirements

4.2.3.1 Production of Foundation Data

-a Foundation Data - Production of a 1 degree cell of Feature Foundation Data within 160 labor hours (tube time commensurate with the number of cartographers/analysts applied to the effort) shall be achievable.

4.2.3.2 Intensification of Foundation Data

-a MSDS - Intensification of features within a 15 X 15 minute area to meet the Mission Specific Data Set requirements of our users shall be met within 40 labor hours. For this release of the Master Plan, MSDS performance will be based on the generation of additional features required to produce NIMA standard VMap2 and 1:50,000 scale Topographic Line Map.

-b Terrain Elevation Data - Generation of high resolution terrain elevation data (DTED levels 3, 4, or 5) coverage within a 15 X 15 minute area of interest shall be supported by one cartographer/analyst within one 8 hour shift.

-c Feature and Terrain Elevation Update - Populated feature and elevation information shall be easily and quickly updated using additional or later date sources to densify, change, and delete existing feature and elevation information as necessary to keep the information current to within 90 days.

4.2.4 Issues and Design Considerations for Outreach

Through the establishment of functional requirements for production and through our environmental scans of industry capability, the following items are of particular value for special attention for the GII. Further collaboration with industry, academia, and government are essential to success in finding the best paths to take regarding:

1. Commercial Geospatial Data Sources - Availability of commercial data sources as input to the population of the Framework (imagery, terrain, and features), and for direct deploy to our user base in support of mission execution. Examples include ETAK, AAA, and other vector road maps, phone listings, other geospatially referenced information. Of interest are the associated licensing requirements, issues, and limitations for direct use of these sources (access electronically by users across browser) by the user base, and as incorporated into framework information.

2. Collaborative Production Tools - Refers to the types of "show me” shared applications, e-mail and other related collaborative tools that enable real time audio / video connectivity to support collaborative activities between producers and users. Collaboration may be internal to an organization, inter-organizational, and may involve multiple parties. Emphasis here is on the assessment and recommendation of best alternatives available (functionality and interoperability) in the market.

3. Unobtrusive/Automated Metadata - Capabilities available to automatically or semi-automatically collect metadata. Comparison of industry capabilities to the metadata portion of the DoD geospatial data standardization effort (under development) to determine how this effort can be influenced by industry direction.

4. AI and Expert Systems to Support Geospatial Information Production - To support efficient capture and attribution of geospatial information and to reduce production costs, NIMA desires community focus on Geospatial Information artificial intelligence (AI) and expert systems to conduct inference of multi-sensor information and data sets against spectral knowledge bases and extraction and production specification knowledge bases to identify and extract features and targets to Geospatial Information specifications. Two AI and expert systems of interest are briefly described below:

   1. Automatic Feature Extraction and Automatic Target Recognition

      1. Supervised Classification

         1. Classifier - The classifier performs multispectral classification of imagery pixels into like groups based on the spectral response of the pixels.

         2. Spectral Knowledge Base (SKB) and SKB Processing - The SKB contains spectral responses and associated meaning. In SKB processing, the results of the classifier is compared to the SKB and the meaning of the spectral response is determined (e.g. water, vegetation, pavement, sand).

      2. Feature Knowledge Base (FKB) and FKB Processing - The FKB contains contextual information about features. This contextual information includes shape, size, region of world, country, latitude, longitude, elevation, slope, terrain, geomorphology, specifications, and spatial relations. FKB processing takes a delineated feature, which may or may not include the results of SKB processing, and compares to the FKB and determines what the feature is (e.g., river, trees, road, dunes) and what its associated attributes are.

   2. Information Production Rules (IPR) and IPR Processing. The IPR contains rules for capture conditions and conflict detection based on a Information Production extraction and product specifications. Processing implies the application of the rules to a specific job.

4.3 Information Management and Dissemination

4.3.1 Requirements Description

The external and internal interfaces needed to provide the proper and timely movement and use of data requires the GII Information Management and Dissemination (IM&D) efforts to fit within the overarching Joint Technical Architecture in support of Joint Vision 2010. A number of ongoing activities such as the Master Environmental Library (MEL), Data Architecture and Gateway Services (DAGS), the NIMA Libraries Initiative (NLI), Global Command and Control System (GCCS) and others all have some degree of IM&D activities and development.

The focus of this section is to define the requirements for a data architecture that allows for the storage and retrieval of geospatial information. The focus of the end-to-end capability is on providing commercial tools that support the management and dissemination of GII Framework Services and data associated with the GII Framework Information (Foundation, Mission Specific Data Sets, and Qualified Data). The overarching engineering requirements that must be addressed for the implementation of the data architecture are:

-a Cataloging - Support the population of data and metadata fields through automated and interactive methods as appropriate

-b Open Databases - Support independent, evolutionary development and implementation of databases and applications accessing databases.

-c Simultaneous Access Management - Manage simultaneous access to multiple, independent and autonomous databases.

-d Maintain Data Integrity - Maintain integrity of data throughout the Enterprise.

-e Data Security - Provide for data safety which includes, but is not restricted to, the ability to recover data at the record, file, volume, database, subsystem, or center level, as well as the mechanisms required to restore an entity to operational capability.

-f Database Maintenance Operations - Support to database maintenance and overhead functions. Specifically, necessary functions and tools shall be provided to minimize database maintenance operations.

-g Standard Data Elements - Provide standard data elements to ensure interoperability among enterprise information systems.

-h Multiple Database Access - Provide discretionary access to multiple databases.

-i Independent Client-Server Connections - Sustain client-server connections independent of the client application's and database server's hosts.

-j Distributed Databases - Support distribution of databases across multiple hosts with replication and distributed updates and be extensible.

-k Security Access - Provide maintainability of users' access rights and permissions. Support a multiple security level environment (e.g., security tagging and flagging).

-l Tolerant Operations - Provide a fault-tolerant environment.

-m DBMS Independent - In addition, database services within the enterprise will not be restricted to a single vendor’s Data Base Management System (DBMS). As a result, the system databases shall have little or no dependence on any particular DBMS vendor’s product.

-n Common Browser - The development of a common browsing tool for imagery and geospatial information.

4.3.2 Architecture

The GII architecture and infrastructure needs to adhere to a minimal set of standards and design principles in order to build the seamless USIGS overarching system.

4.3.2.1 Architecture Compliance

At a minimum the data architecture development shall adhere to the following standards and design principles:

-a Commercial Database - The architecture shall be capable of storing and managing GII Framework Information in a commercially available database management system.

-b Data Management - Data Architecture shall consist of capabilities for Data Management. Data Management is the Database Management System (DBMS) functionality and the population of the database from the various certified information sources.

-c FIPS 127-2 (SQL) - Data Architecture shall be FIPS 127-2 (SQL) compliant.

-d Portable - Data Architecture shall support hardware and software portability.

-e Non-Limiting Extensions - Data Architecture shall not implement extensions limiting portability.

-f FIPS 184 (IDEF1X) Modeling - Data Architecture shall be based on and support FIPS 184 (IDEF1X) modeling.

-g Security Granularity - Database design and implementation shall support the security and sensitivity level of all database fields at the table, row, column and cell level of granularity.

-h Precluded Responses - Database design shall preclude incorrect query response as a result of null fields and out of range fields.

-i Dynamic Extraction - Database design shall support dynamic extraction to the lowest feature attribution level.

-j Multiple Information - Data Architecture shall support an integrated architecture addressing imagery, imagery products, imagery intelligence, and geospatial information.

4.3.2.2 Data Management

Data Management specifies the functionality for managing GII framework and non-framework (other) information. Data Management also contains the utilities for acquiring and distributing data. Data Management shall:

-a GII Framework - Manage and store the Framework Information that is derived from the production systems, existing data stores, and data generated by users (value-added).

-b New Data Linkage - Provide the capability to define and accept new data types/products and build linkages.

-c Data Search Types - Provide the capability to do `keyword, Boolean, and spatial’ searches for data.

-d Non-Blocked Access - Provide the capability to perform non-blocking (no lock-out) update, deletion and archival processes. This is especially critical for framework feature data.

-e Updating Process - Include the updating processes of the framework information .

-f Automatic Check/Update Metadata - Provide the capability to automatically check and update the metadata for both new and changed Framework Information during the update processes.

-g Error Conditions - Provide the capability to designate the error conditions and capture the erroneous data records during update processing.

-h Skip Erroneous Data - Provide the capability to skip erroneous records without load interruption during update processing.

-i Modify Rules - Provide administrators the capability to create and modify the rules by which data is moved.

-j Audit Trail - Capture an audit trail between backups.

-k Prioritize Resources - Provide administrators the capability to adjust resources for querying and ordering based on a user's priority level.

-l Automatic Deletion - Provide administrators the capability to define an expiration date or event (e.g., end of special exercise, period of inactivity, etc.) after which a product or discrete file will be deleted.

-m Backup Copies - Provide administrators the capability to maintain a backup copy of databases.

-n Selective Backup - Provide administrators the capability to specify full database backup or backup of selected segments of the databases.

-o Restore Databases - Provide administrators the capability to restore the databases from the backup copy of the databases and the audit trail.

-p Access Path Monitoring - Provide administrators the capability to monitor access paths used for data retrieval (e.g., indices used).

-q Tunable - Provide the capabilities for performance tuning (e.g., creation and deletion of indices, partitioning of data, locking, parallel processing, etc.).

4.3.2.3 Framework Information

The architecture and infrastructure for the creation, storage and management of GII Framework Information must support the migration to fully deconflicted data. Some of the capabilities necessary to achieve this include:

-a Source Data - Preserve valid, useful, and necessary information present in the source data (e.g., topological, cartographic and temporal information).

-b Topological Change Capture -Update topological relationships when changes occur.

-c Topological Consistency - Enforce topological consistency.

-d Data Model/FACC Compliant - data representations, data structure (format), and data schema must adhere to the USIGS Data Model and the Foundation Feature Data (FFD) must be FACC compliant.

-e Create Associated Metadata - see section 4.3.2.6.

-f Automatic Edge Matching - Provide the capability to perform automatic edge matching adjustments of the location of points and vectors in order to maintain the continuity of the dataset.

-g Generalization - Provide generalization capabilities, (e.g., the ability to derive a lower resolution representation of the original dataset).

-h Time Relationship - Time varying relationships between database entities.

-i Detect Errors - Detection of common integration errors including slivers and gaps.

-j Error Correction - Automated and semi-automated correction or flagging of common errors.

-k Best View - Creation of single “Best” current information data view based on user selectable parameters.

4.3.2.4 Formats

As described in the DAGS, NIMA Libraries Initiative (NLI), and USIGS Interoperability Profile (UIP) documentation, data import and export of the following formats shall be supported at a minimum:

-a NITF - Data import and export of NITF formatted data shall be supported.

-b TFRD - Data import and export of Tape Format Requirements Document (TFRD) formatted data shall be supported.

-c TIFF - Data import and export of TIFF formatted data shall be supported.

-d Sun Raster - Data import and export of Sun Raster formatted data shall be supported.

-e GIF - Data import and export of GIF formatted data shall be supported.

-f PostScript - Data import and export of PostScript formatted data shall be supported.

-g RPF - Data import and export of Raster Product Format (RPF) formatted data shall be supported.

-h VPF (FACC) - Data import and export of VPF formatted data shall be supported.

-i FACS - Data import and export of Feature Attribute Coding Standard (FACS) formatted data shall be supported.

-j ASCII - Data import and export of ASCII formatted data shall be supported.

-k DIGEST A - Data import and export of DIGEST A formatted data shall be supported.

-l DIGEST C - Data import and export of DIGEST C formatted data shall be supported.

-m PDF - Data import and export of Portable Document Format (PDF) formatted data shall be supported.

-n MARC - Data import and export of Multi-Automated Reader Card (MARC) formatted data shall be supported.

-o RTF - Data import and export of Rich Text Format (RTF) formatted data shall be supported.

-p SDTS - Data import and export of Spatial Data Transfer Standard (SDTS) formatted data shall be supported.

4.3.2.5 Compression

As described in the DAGS, NLI, and USIGS Interoperability Profile (UIP) documentation, imagery import and export imagery of the following user selectable compression formats shall be provided:

-a 4.3 bpp DPCM - Import and export of images using 4.3 bpp differential pulse code modulation (DPCM) compression shall be provided.

-b 2.3 bpp DCT - Import and export of images using 2.3 bpp discrete cosine transform (DCT) compression shall be provided.

-c 1.29 bpp DCT - Import and export of images using 1.29 bpp DCT compression shall be provided.

-d 8 bit JPEG - Import and export of images using 8 bit Joint Photographic Expert Group (JPEG) compression shall be provided.

-e 12 bit JPEG - Import and export of images using 12 bit JPEG compression shall be provided.

-f Color JPEG - Import and export of images using Color JPEG compression shall be provided.

-g MPEG - Import and export of images using Motion Pictures Expert Group (MPEG) compression shall be provided.

-h Vector Quantization - Shall be capable of performing Vector Quantization (VQ) decompression on VQ compressed maps which may accompany a NITF-compliant imagery product.

4.3.2.6 Metadata

Information Management and Dissemination is responsible for metadata. As part of this activity the metadata shall comply with the following:

-a SPIA/SDE - Standards Profile for Imagery Access (SPIA) and Support Data Extensions (SDE).

-b USIGS Data Model - Data standard for Geospatial Information, Imagery and Imagery Intelligence. Includes the NIMA metadata model.

-c FGDC - Federal Geographic Data Committee (FGDC) metadata standard.

4.3.3 User Services

User services describes the means by which potential users of the geospatial information can determine the content of the holdings and request that the holdings be transferred to their location for subsequent exploitation. The capabilities are generically categorized as: query, order, user interface, user profile and administrative services. These categories are used as a means to group the requirements not specify the design. Users will have the ability to create and place queries and orders. The user interface and user profile capabilities will interact with the placed query and/or order for validation and access constraints. Administrative services provides the help and tools necessary to support maintenance and operations.

4.3.3.1 Query

Query accepts user input parameters and builds a query that will be used to retrieve metadata and queriable data. Users will have the ability to define and initiate ad-hoc queries, standard queries, and standing queries. Standard queries are queries which can be referenced and executed by multiple users. Standing queries are queries which will be executed based on a pre-defined time or event. Query shall provide:

-a Metadata/Data Access - Access and execute queries against metadata, as cited in section 4.3.2.6, and data as addressed in the USIGS Data Model and GII Framework Information. The user will have the capability to browse the metadata and retrieve items of interest.

-b Proper Coordinates - Maintain proper coordinates when spanning the 0 and 180 meridians, the equator and the poles (90N, 90S).

-c Community Archive Access - Access NIMA holdings and DoD Intelligence Information Systems (DODIIS) compliant community archives.

4.3.3.1.1 Query Building

Query Building shall provide:

-a Interface Assistance - The capability for users to exploit graphical and textual interfaces to build queries (e.g., point, radius around a point, rectangle/drag box, user defined polygon, and line and area surrounding the line/route).

-b Graphical/Textual Assistance - Users graphical and textual assistance for building queries (e.g., prompts, pull-down menus, etc.).

-c Geographical Coordinates - The capability to accept geographical coordinates from graphical interaction on the map display (e.g., point, polygon, etc.).

-d Textual Input - The capability to accept geographical coordinates from textual input with degrees/minutes/seconds (DDD MM SS), degree decimal minutes (DDD MM.MMM....), decimal degrees (DDD.DDDDD....), Military Geographic Reference Model (MGRS) and Universal Transverse Mercator (UTM) coordinates as initial formats presented for user choice.

-e Administrator Assistance - The capability for administrators to maintain query building assistance.

-f Exact/Best Match - The capability for both ‘exact match’ and `best match' to textual input parameters.

-g Keyword Search - The capability for ‘keyword' searches on textual products and metadata.

-h Complex Queries - The capability to build complex queries which include combinations of query parameters and Boolean operators. The query capability shall support negative logic on all queriable fields.

-i Cross Over Queries - The capability to build a query based on individual domain parameters or any combination to allow for multiple table joins within and across themes and data libraries.

-j Resolution/Scale - The capability to build a query based on resolution/scale.

-k Save Between - The capability to save a submitted query, containing submitter's name, date of submission and query parameters between logon/logoff sessions.

-l Rework Saved Queries - The capability to retrieve, edit and delete previously saved queries.

-m Rework Standard Queries - Administrators the capability to create, edit, save and delete Standard Queries.

-n Multiple Execution - The capability for the execution of standard queries by multiple users.

-o Standard Queries - The capability to create, edit, save and delete standing queries.

-p User Initiation - The capability to initiate standing queries based on a time or event as defined by the user.

-q Gazetteer Coordinates - The capability to query on a geographical name based on gazetteer-like coordinates.

-r Keyword Index - The capability for building an index of keywords.

-s Specified Submittal - The capability to specify whether queries are submitted to a single identified library, a group of identified libraries or all available libraries.

4.3.3.1.2 Query Response

Query response shall provide:

-a Textual/Graphical Response - Provide textual and graphical query responses.

-b Refinement - Provide the capability to iteratively refine the query based on previous query responses.

-c Default Display - Provide administrators the capability to define the default display format for the metadata response to queries (e.g., title and date).

-d User Defined Default Display - Provide the user the capability to specify a user specific default display format for the metadata response to queries (e.g., title, date, source and size).

-e Display Format Choice - Provide the user the capability to specify the display format for the query specific metadata response to queries (e.g., title, date, source, quality parameters and size).

-f User Notification - Provide the capability for user notification of an unviewed query response at next logon (e.g., "You have unread mail/ queries").

-g Order Creation - Support the creation of an order.

-h Single Response - Have the ability to aggregate the query responses from distributed libraries and archives and return the aggregate as a single response to the client.

-i Search Time Termination - Provide the capability to terminate a response based on elapsed search time.

-j User Intervention Termination - Provide the capability to terminate a response based on user intervention.

4.3.3.1.3 Query Parameters

Query parameters for administrators shall provide:

-a Linkage - Maintain linkages between data and metadata.

-b Hierarchical Structure - Define hierarchically structured metadata groupings for metadata fields.

-c Specification - Specify, add, edit, and delete queriable parameters and desired formats and ranges for the parameters.

-d Query Log - Create and maintain a log of submitted queries.

4.3.3.2 Browse Services

The browse function will allow a user's interactive review of data that is returned in a query response. The data to be browsed includes overview of images, image products, integrated geospatial data and metadata. The user should be able to browse returned query responses as foot prints overlaid on a map display background. Browse Services shall provide:

-a Previews - Provide the user with the ability to view overviews of returned query results consisting of thumbnail images, sub sampled images and screen size overviews.

-b Thumbnail Metadata - Link metadata associated with the overviews to the associated thumbnail for review by the user.

-c Direct Order - Provide the user with the capability of directly ordering the full dataset being browsed.

4.3.3.3 Order

Orders are requests for integrated geospatial information, image products, imagery and imagery intelligence. Functionally orders can be viewed as three distinct types: Profile Based Requests for automatic dissemination of information, Ad Hoc orders for existing information, and Custom Orders that require a tasking to generate data.

4.3.3.3.1 Order Building

Order building shall provide:

-a Interface Preferences - Provide the capability to retrieve user profile details regarding user interface preferences.

-b Create/Submit - Provide the ability to create and submit an order.

-c Methods - Provide the capability for a user to choose from available order methods

-d Edit/Delete - Provide the capability to edit and delete an order before it is submitted.

-e User Actions - Validate all fields on an order and highlight discrepant field(s) for user action prior to order submission (e.g., mandatory fields, range limits, dates, etc.).

-f Correction Help - Provide help in correcting discrepant fields.

-g Order Saving - Provide the capability to save an order, containing submitter's name, date of submission and order details between logon/logoff sessions.

-h Manipulate Saved Order - Provide the capability to retrieve, edit and delete a previously saved order.

-i Reuse - Provide the capability to submit a previously saved order.

-j Automatic Field Fill In - Integrate with the Query capability and automatically complete (fill in) the required Order fields based on the user selected query response or hit.

-k Logs - Provide the capability to create and maintain logs.

-l Cancellation - Provide the capability to request a submitted order be canceled.

-m Prioritize - Allow for user prioritization of the order.

4.3.3.3.2 Order Response

Order response shall provide:

-a Item Preparation for Delivery - Have the capability to prepare the completed ordered items for delivery to the user.

-b Electronic Delivery - Have the capability to deliver the ordered items electronically, if within the size parameters based on the network and user profile.

-c Order Submission Acknowledgment - Provide users with acknowledgment of order submission.

-d Processing Details - Provide the capability to collect the order processing details (e.g., time stamps, event, system routed to, etc.).

4.3.3.3.3 Order Parameters

Order parameters for administrators shall provide:

-a On-line Forms - Create and maintain on-line order forms.

-b Parameter Manipulation - Create, edit, save and delete the parameters which comprise an order.

-c Logs - Create and maintain a log of submitted orders.

4.3.3.3.4 Order Security

Order security shall provide:

-a Downgrading - Determine if User Orders, entering the system at a higher security level, can be downgraded to a lower security level and submitted.

4.3.3.3.5 Profile Based Requests

Profile Based Requests for users shall provide:

-a Automatic Dissemination - Various criteria to determine what information they are to receive based on an automatic dissemination basis.

-b Information Profile - Various criteria to determine what information they are to receive when their profile is activated and executed.

-c Characteristics - The characteristic of the products or information of interest.

-d Notification - The method of notification of availability and dissemination means.

4.3.3.3.6 Ad Hoc Orders

Ad Hoc orders are generated by a user who has queried the data holdings and determined that information in the area of interest is available. Custom Orders are a subset of the Order and as such will include all the capabilities specified for Order Building.

The system shall provide:

-a Accept Ad Hoc - The ability to accept Ad Hoc orders.

-b Accept Custom - The ability to accept Custom Orders.

4.3.3.3.7 Custom Order

A custom order is a user request for information that requires either data or human processing. This may be tailored (special) information, or new information (i.e., a production request). The user has the ability to specify parameters for the tailored or production request.

Requests for tailored information are based on parts or combinations of existing data holdings. The data required to produce the tailored product is available, but requires varying levels of processing.

Requests for new information, a production request, will be passed to the producer for consideration in the requirements process. Custom orders shall provide:

-a Same Capabilities as Order - Include all the capabilities specified for Order Building.

-b Specify Parameters - Provide the ability for users to specify parameters available for the product/data type and the available distribution media.

-c User Feedback - Provide the capability for a user feedback mechanism (e.g., availability, delivery time, etc.).

-d Thresholds - Provide administrators the capability to set thresholds by user priority (e.g., size, quantity, etc.).

-e Immediate Feedback - Provide the capability to send an immediate feedback (e.g., threshold limits, error code, etc.) message to the user when administratively set limits are exceeded.

-f Outside Data - Provide the capability to request data not currently part of the data holdings.

-g Production Request - Provide the capability to forward a production request to the producer.

4.3.3.3.8 On-line Delivered Orders

On-line delivered orders shall provide:

-a Transmission Time - Inform the user of size and estimated transmission time for user acknowledgment or cancellation prior to transmission.

-b Order Manipulation -Provide the capability for order cancellation and re submission of an order.

4.3.3.4 Human Computer Interface (HCI)

The HCI will allow users access to the system through software residing on the user platforms. It must therefore be compatible with the standards of the user's hardware and software and preserve Native Mode Operations (environment) without interference with other user platform uses. It is envisioned that the interface will have a similar "look and feel" to commercial Internet service providers, but it must also support the "look and feel" of the deployed military systems with which operators are familiar. The interface shall support access to and interaction with libraries through:

-a Browser - A web browser.

-b GUI - FIBS PUB 158-1 compliant Graphical User Interface (GUI).

-c CUI - Character User Interface (CUI) that supports functions not intrinsically requiring graphics capability.

-d UIP API - USIGS Application Program Interface (API) that is USIGS Interoperability Profile (UIP) compliant.

4.3.3.4.1 Communications

The user desktop will employ communications services provided by Defense and Intelligence Community Network providers to connect with data services and be compliant with the standards and requirements of the community network providers. Connectivity shall be made through the following mechanisms:

-a JWICS - Joint Worldwide Intelligence Communications System (JWICS).

-b SIPRNET - Secure Internet Protocol Router Network (SIPRNET).

-c OSIS - DoD-Intelligence Open Source Information System (OSIS).

-d NIS - National Imagery System (NIS).

-e USIGS - United States Imagery and Geospatial Information System (USIGS).

-f Internet - unclassified network connection.

-g UKMilSvy - United Kingdom Military Survey (UKMilSvy) (TBD).

-h DISN-LES - Defense Information System Network Leading Edge Services (DISN-LES)

-i JBS - Joint Broadcast System

-j LOCI (NATO)

-k Coalition (CTF) - Combined Task Force (CTF)

4.3.3.5 User Profile

The User Profile will store user identification information, including password and account information. This user profile will allow common access to imagery, imagery products, imagery intelligence and geospatial information. Each user must have a User Profile before being able to access framework information. The profile will also capture user preferences for automatic dissemination of data, dissemination methods and addresses.

An administrator will be responsible for processing requests for new User Profiles and an administratively designated security official will be responsible for validating the security clearances and release parameters of each user.

-a Profile Relationships - User Profile shall provide administrators the capability to add, delete and modify the user profile elements and their relationship to privileges and services.

-b UIP Attributes - The User Profile shall be based on query attributes as defined in the USIGS Interoperability Profile (UIP).

-c DoDAAC/FedACC - Additional profile information may be required based on Department of Defense Activity Address Code (DoDAAC) / Federal Activity Address Code (FedAAC) (note: this field is mandatory for users ordering standard stocked products; not all GII users will have a DoDAAC or FedAAC)

-d New Profiles - User Profile shall provide new users the capability to initiate a request for a new user profile.

-e User Edit - User Profile shall provide users the ability to view and edit elements of their own user profile to which they have been granted those access privileges.

-f Administrative Edits - User Profile shall provide administrators the capability to create, edit, save and delete user profiles.

-g One Profile Access - User Profile shall establish one profile for each user that will give a user access via the requested network and any lower security networks.

-h Access Control - User Profile shall provide administrators the capability to control user access.

4.3.3.6 Security Profile

-a Information Protection - The Security Profile is used to ensure that information is restricted to users with appropriate security access and sensitivity.

-b Capabilities - The Security Profile is a subset of User Profile and shall include all the capabilities specified for User Profile

-c Minimum Information - The Security Profile shall contain the following information at a minimum:
- Security access level
- Sensitivity (e.g., releasability, proprietary, etc.)

-d Validated Access - A user's Security Profile information shall be validated before access to any of the data is permitted.

-e Default Levels - The default Security Profile security level/sensitivity parameters shall be at the unclassified/non-sensitive level.

-f Administrative Access - Security Profile shall provide the capability for administratively designated security officials to define, protect, and configure Security Profile elements for security access and sensitivity.

-g User View - Security Profile shall provide users the capability to view their Security Profile information, except for account details (e.g., User ID, password cannot be viewed).

-h Administrator Privilege - Security Profile shall provide administrators the capability to view Security Profile information.

4.3.3.7 Automated Information Systems (AIS) Security

Note: This new section of requirements has been added since the release of Version 0.21.

4.3.3.7.1 Security Services

The following security services shall be allocated throughout the architecture in appropriate combinations to ensure that information is protected in accordance with DoD security policy. Additionally, ongoing development iterations shall not lessen or degrade the security of the system. Requirements related to accomplishment of these services are provided in section 4.3.3.7.2.

Authentication Service - The GII Client Interface, based on User Profile information, shall provide the capability to confirm the identify of users, processes or components. Interactions with the data shall be allowed only after users, processes and/or components have been authenticated.

-a Access Control Service - The GII Client Interface, based on User Profile information, shall provide the capability to protect against unauthorized access and use of resources. Resources include communications resources; privileges related to the reading, the writing, or the deletion of an information resource; and the execution of a processing resource.

-b Data Confidentiality Service - The GII Client Interface, based on User Profile information, shall protect against unauthorized disclosure. This service shall use the authenticated identity, and may use information labels, and/or capabilities of or information about users (User Profile information) to determine and enforce confidentiality.

-c Traffic Flow Confidentiality Service - GII Framework Information Services shall protect information to ensure that value cannot be derived from observation of traffic flows.

-d System Integrity Service - The GII shall ensure that source product data resident in production systems cannot be modified, inserted or deleted without authorization.

4.3.3.7.2 AIS Security Requirements

4.3.3.7.2.1 Authentication Requirements

-a Verified User - The GII shall grant individual user access only to verified authorized users.

-b Prior ID - The GII shall require each individual wishing access to the system to identify themself prior to performing any system functions.

-c Acceptance - The GII shall accept information only from authenticated users.

-d Lock-Out - The GII shall provide the capability to lock a user out of the system after a number of incorrect log-on attempts.

-e Auto Log Off - The GII shall automatically log an authorized user off the system after a predetermined period of inactivity.

-f Inactive Period - The GII shall provide the capability to select the period of individual inactivity.

4.3.3.7.2.2 Access Control

-a Unauthorized Access - The GII shall protect information from unauthorized access.

-b Unauthorized Use - The GII shall prevent the system from being used in an unauthorized manner.

-c Privilege Level - The GII shall provide the capability to include or exclude individual authorized users access to GII Framework Information and Services, based on the privileges associated with the authorized user.

-d Security Labels - The GII shall provide security labels for all information and data items.

-e Sensitivity Level - The GII shall indicate a sensitivity level associated with each data item.

-f Securely Bind Labels - The GII shall securely bind the security labels to the information to which it is associated.

4.3.3.7.2.3 Data Confidentiality Requirements

-a Unauthorized Disclosure - The GII shall protect information from unauthorized disclosure.

-b Full Protection - The GII shall protect proprietary, classified, and unclassified but sensitive information from unauthorized users and authorized users without proper access privileges.

-c Release Restriction - The GII shall enforce release restriction imposed by treaty or agreement.

-d Traffic Flow Value - The GII shall protect information to ensure that value cannot be derived from observation of traffic flows.

4.3.3.7.2.4 Data Integrity Requirements

-a Prohibited Changes - The GII shall prohibit inadvertent or unauthorized modification, destruction, and deletion of GII information and software.

-b Restricted Changes - The GII shall restrict the modification and deletion of information and software only to authorized users.

4.3.3.7.2.5 Non-repudiation Requirements

-a Denial Protection - The GII shall protect against denial by one of the individuals involved in an exchange of information of having participated in all or part of the exchange.

-b False Denial - The GII shall protect against any attempt by a sender or provider of information to falsely deny sending the data or its contents.

-c Subsequent Denial - The GII shall protect against any subsequent attempt by the receiver or recipient to falsely deny receiving the information or its contents.

4.3.3.7.2.6 Security Event Detection Requirements

-a Auto Detect - The GII shall automatically detect, notify administrators, and record system events or activities designated as security-relevant by GII cognizant security officials.

-b Define Security Events - The GII shall provide the capability to define the security related events.

-c Record Event Types - The GII shall, at a minimum, record the following types of events;

• User authentication

• Introduction of information to the system

• Removal of information from the system

• Actions performed by authorized users and system administrators

-d Identify Event Type - The GII shall, at a minimum, identify the type of security event detected, time and date of the event, and the user’s name and/or system identification.

4.3.3.7.2.7 Security Audit Trail Requirements

-a Time Tag Events - The GII shall provide a chronological record of system security related activities detected by the system.

-b Hard Record - The GII shall provide a non-editable audit trail of total transaction accounts, by user/organization and by originating system.

-c Authorized Audit Review - The GII shall provide the audit trail information only to designated authorized users.

4.3.3.7.2.8 Training Requirements

-a Secure Operation - A training program shall be established for operators to provide security awareness and training for the secure operation of the GII.

4.3.3.7.2.9 Documentation Requirements

-a Mechanics - Documentation shall be developed to describe the security requirements and protection mechanisms integrated into the GII to satisfy the requirements. This documentation shall provide guidelines on their use and how they interact.

-b Actions - Documentation shall be developed to describe the operator and security actions related to the security functions and mechanisms.

-c Supplied Softcopy - Security documentation shall be provided in a soft-copy (to be specified) format to future development contractors as iterations of the system are implemented.

4.3.3.7.3 Security Mechanisms

The following mechanisms may be applied to the GII initiative as needed to provide some of the services described above. Many of these mechanisms are typically integrated into products such as operating systems which can satisfy multiple security services. These mechanisms are not specifically required for implementation in GII incremental developments. However, proper allocation and combination of these mechanisms throughout the GII architecture should ensure that the security services mandated in the security policy are satisfied. Any proposed design shall describe the mechanisms to be implemented in satisfying the above requirements and how they will be implemented.

1. Encipherment - Encipherment can provide confidentiality of either data or traffic flow information and can play a part in or complement a number of other security mechanisms. The existence of an encipherment mechanism implies the use of a key management mechanism except in the case of some irreversible encipherment algorithms. Encipherment in the GII could be used to satisfy the confidentiality, authentication, integrity and traffic flow services. Encipherment mechanisms proposed for use in the GII shall comply with appropriate DoD and/or Federal Government standards.

2. Digital Signature Mechanisms - Digital signature mechanisms provide the capability for a user to “sign” an electronic message using a key which is unique and confidential to the user. The message receiver uses a public key to verify that the electronic signature was in fact produced with the signer’s private key. Digital signature mechanisms could be useful to the GII for authenticating users when requesting services and/or information from GII data warehouses. Digital Signature mechanisms proposed for use in the GII shall comply with the FIPS PUB 186, Digital Signature Standard.

3. Access Control Mechanisms - These mechanisms may use the authenticated identity, capabilities of, or information about users (or processes) in order to determine and enforce the access rights of the user (or process). If the user attempts to use an unauthorized resource or an authorized resource with an improper type of access, then the access control function will reject the attempt and may additionally report the incident for the purposes of generating an alarm and/or recording it as part of a security audit trail.

   For the GII, access control mechanisms are envisioned to be based on use of one or more of the following:

   • User access control profiles, where the access rights of users are maintained.

   • Authentication information such as passwords, possession and subsequent presentation of which is evidence of the accessing entity's authorization;

   • Security labels, which when associated with an entity may be used to grant or deny access in accordance with this security policy.

4. Data Integrity Mechanisms - Data integrity mechanisms are implemented to protect against the unauthorized modification, insertion, deletion or replay of data. These mechanisms are primarily based on a combination of other mechanisms. Current telecommunications protocols serve as a rudimentary mechanism to ensure that data is not modified during data transfer. Encipherment mechanisms can be used to encrypt check values and block checks to strengthen the integrity of telecommunications protocols. Additionally, access control mechanisms can be used to establish write and update privileges, facilitating integrity of data residing in end systems.

5. Authentication Exchange Mechanism - To be provided.

6. Traffic Padding Mechanism - Traffic padding mechanisms can be used to provide various levels of protection against traffic analysis.

7. Routing Control Mechanism - Routes can be chosen either dynamically or by pre-arrangement so as to use only physically secure sub-networks, relays, or links. End-systems may, on detection of persistent manipulation attacks, wish to instruct the network service provider to establish a connection via a different route. Data carrying certain security labels may be forbidden by the security policy to pass through certain sub-networks, relays or links. Also the initiator of a connection may specify routing caveats which request that specific sub-networks, links or relays be avoided.

   At least in early GII implementations, routing control will be provided by restriction of traffic to Intelink (SCI, JWICS), Intelink-S (Secret/Collateral, SIPRNET), and the OSIS (Unclassified, NIPRNET, Internet) communications backbones. Routing control for future implementations will require a case-by-case evaluation to identify the need for routing control based on risk.

8. Notarization Mechanism - Properties about the data communicated between two or more entities, such as its integrity, origin, time, and destination, can be assured by the provision of a notarization mechanism. The assurance is provided by a third party notary, which is trusted by the communicating entities, and which holds the necessary information to provide the required assurance in a testifiable manner. Each instance of communication may use digital signature, encipherment, and integrity mechanisms as appropriate to the service being provided by the notary. When such a notarization mechanism is invoked, the data is communicated between the communicating entities via the protected instances of communication and the notary.

4.3.3.7.4 Pervasive Security Mechanisms

This subsection describes a number of mechanisms which are not specific to any particular service and are not specifically required. Some of these pervasive security mechanisms can be regarded as aspects of security management.

1. Trusted Functionality - Trusted functionality may be used to extend the scope or to establish the effectiveness of other security mechanisms. Any functionality which directly provides or provides access to security mechanisms should be trustworthy. The problems can be minimized by choosing an architecture which permits implementation of security functions in modules which can be made separate from, and provided from, non-security-related functions. The GII security architecture should address the need for trusted functionality of security services and mechanisms. Typically, trusted functionality has been achieved through implementation of National Security Agency (NSA) evaluated products. If trusted functionality cannot be achieved through the implementation of evaluated products, then the risks associated with implementation of (untrusted) mechanisms which have not been evaluated should be documented. These risks can be mitigated through certification testing.

2. Security Labels - Resources, including data items, may have security labels associated with them to indicate a sensitivity level. It is often necessary to convey the appropriate security label with data in transit. A security label may be additional data associated with the data transferred or may be implicit, e.g., implied by the use of a specific key to encipher data or implied by the context of the data such as the source or route. Explicit security labels must be clearly identifiable in order that they can be appropriately checked. In addition they must be securely bound to the data with which they are associated.

3. Event Detection - Security-relevant event detection includes the detection of apparent violations of security and may also include detection of "normal" events, such as a successful access (or log on). Detection of various security-relevant events may, for example, cause one or more of the following actions:

   • Local reporting of the event

   • Remote reporting of the event

   • Logging of the event

   • Recovery action

4. Security Audit Trail - Security audit trails provide a valuable security mechanism as they potentially permit detection and investigation of breaches of security by permitting a subsequent security audit. A security audit is an independent review and examination of system records and activities in order to test for adequacy of system controls, to ensure compliance with established policy and operational procedures, to aid in damage assessment, and to recommend any indicated changes in controls, policy and procedures. A security audit requires the recording of security-relevant information in a security audit trail, and the analysis and reporting of information from the security audit trail.

4.3.4 Performance Expectations

The following performance expectations are estimates being used to initially size the DAGS Geospatial Information Library (GIL) (formally known as the Central Data Library (CDL) and Geospatial Warehouse (GW)) and should serve as guidelines for the GII 97.

4.3.4.1 Storage Capacity

-a Product Data - Storage capacity for the following product data types, with the volume indicated, shall be provided:

• Available 24 hrs/day, 365 days per year

• 100 - 500 concurrent users

• 2400 - 5000 users per day

• Query response nominally 5 seconds for a complex metadata query

  • Search 10 tables with 20 million records, 12 parameters in the query
  
  
• Query response nominally 2 seconds for a simple metadata query
  
  
  • Search 1 table with 250,000 records, 6 parameters in the query

4.3.5 Issues and Design Considerations for Outreach

Several issues specific to the IM&D arena are not adequately addressed under existing strategies and need further discussion:

1. Network Environment for Dissemination - Solutions that are bandwidth intensive for dissemination of data and imagery put a heavy burden on the network providers. Solutions that are developed need to address the network capabilities and solve the dissemination issue without assuming unlimited bandwidth availability for their solution. Technology areas of compression, wavelet compression and fractals (for thumbnails) and progressive transmission schemes based on user feedback (detail is transmitted only for area the user is interested in) are of interest.

2. Integration and Conflation - Tools and logic for fully automatic integration and conflation of disparate datasets are not available commercially. Strategies for integration and conflation that allow users to fuse datasets from multiple data source are desirable in addressing the need to integrate data into non product specific formats. Additionally, at present we generate and store distinct datasets for data at different resolutions. An alternative would be to attribute once, and to delineate a highly accurate polygon for limited use, a lower-resolution polygon for use in many applications, and a point representation of the same feature for other uses. This “single” feature with multiple delineations must ensure that attribution is consistent across representations. We believe there are two sets of related issues: data structures and ease of selecting the correct delineation. If this is technically prohibitive approach, then we may need to continue to keep multiple representations of data for different user needs and will then require the need for additional capability to manage linkages between the multiple representations. Ongoing efforts such as the Air Force Rome Laboratory effort on the Multiple Data Base Integration and Update (MDBI&U) system consisting of an integrated hybrid of advanced technologies (reference: ESRI 1997 Conference Abstracts - Automated Conflation and Update of Geospatial Feature Data Bases, Track: Defense and Intelligence) offer some promise for possible solutions to these issues.

3. Graphic Representation of Framework Feature Information - Commercially available software that provides reliable, repeatable graphic output on monitors, completely eliminating human judgment in selecting, decluttering, generalizing, symbolizing, and displacing feature data for hardcopy output or video display is not available. There is a need for software that will provide the repeatable graphic representation of feature data at multiple view scales (e.g., 1:250k, 1:50k).

4. Query at the Feature Level - Existing RDBMS cannot efficiently handle topology queries. Strategies for enabling users to ask questions like "give me all bridges > 50 tons only" need to be addressed. Current trends in GIS technology pave the way for a topology-less non-product-oriented data standard which can be readily handled with Information Technology products. Perhaps the simple extensions to RDBMS which we are already seeing will provide all the functionality required. Developments such as SQL3 which will support spatial queries through geometry (but no direct support for topology) will be all that will be needed to fuel the industry to the next generation of enterprise-wide geospatial systems. Topology may become a largely transient state of the geospatial data.

5. To Tile or Not to Tile - The maintenance and update strategies for data need to be part of the IM&D design. Can we design and afford to maintain records at the feature level of definition or do we need to treat data as "tiles" with metadata rolled up from the elements for a general level of accuracy and currency. Integration and merging of disparate data sources may force an integrated hierarchical model where the complete metadata record consists of data from the feature, tile or layer, and area within that tile or layer.

6. Open Exchange Formats

   1. Features - Vector Product Format (VPF) was developed to serve as a vendor-independent exchange format for geospatial features and their topological relationships. As NIMA and the rest of DoD and intelligence community prepare to make wider use of commercial software, an evaluation of the VPF in its current form is in order to include suitability for direct access and/or data exchange, utility of VPF-provided topology, FACC and metadata, limitations on performance inherent to VPF, and recommendations for alternative commercial geospatial feature exchange standards

   2. Elevation - Currently Digital Terrain Elevation Data (DTED) is the NIMA elevation data exchange format standard. An evaluation of DTED in its current form is in order to include suitability for direct access and/or data exchange and recommendations for alternative open exchange formats for the elevation component of framework information.

   3. Imagery - NIMA exchanges imagery and image products in various exchange standards including Raster Product Format (RPF) and National Imagery Transfer Format (NITF). An evaluation of the NIMA Imagery exchange standards and recommendations for commercial alternatives for open exchange formats for the imagery component of framework information is an outstanding issue.

7. Customer Profiles - Several customer profiling and data dissemination tools have been discovered in the area of electronic commerce. These tools include capabilities (of varying extent) to address the issues discussed below. The actura implementation and use of these tools will be employed by the user based on need.

   1. Management of Profiles for Dissemination - There are two basic methods for users to find information within the geospatial framework. Smart pull requires the standard search and recovery tools to query and/or browse for information. Smart push requires the user to establish an interest on a library or local data store. This establishment of interest can be thought of as a standing query. When a data item enters the library, the metadata is created and the standing query, or profile, is invoked. If the data item meets the criteria within the profile, several things might occur: a notification message is sent informing the user that an item of interest has been established on the library, a notification message along with user defined metadata elements can be sent, or the data item itself could simply be sent directly to the user.

   2. Organization Profiles - One of the issues within profile management is the interaction with profiles established by individual users within an organization and the organization itself. Should, for example, each intelligence officer at U.S. Atlantic Command (USACOM) establish a profile on the geospatial information library that says: Please notify me when the transportation layer over Haiti is updated. This results in numerous and redundant messages/data going to the same site. Should the organization, USACOM, establish an interest? If the organization establishes an interest, how is each individual officer notified that an update occurred? What happens when an organization establishes a profile, such as the example above, but an individual establishes a more specific (or even a more general) profile? For example, an officer wants only to know when the data holdings updates bridge data, and has no interest in road or airport updates. One possible approach is the establishment of a hierarchical profile: one for the organization indicating interest in transportation features, and another sub-profile that sends out messages to individuals when their specific items of interest change.

8. Application Tools Dissemination - New data types will be introduced over the lifecycle of the GII. Tools and applications will need to be disseminated along with the data types for manipulation and viewing. Industry capabilities for "applet development and dissemination" and management of user desktop tool sets are important areas of design for geospatial data. If the user already has a viewer we don’t want to load it every time a dataset is disseminated. Along with the overlap of profiles within organizations there is also overlap between organizations. This can be of great benefit, if users having similar profiles (based on geographic region or issues) can be grouped together into a virtual team covering that issue. The notification of the group members of each other’s existence will create new channels of information flow and reduce duplication of effort, while increasing the overall quality of work. There are some security implications to this group profiling, such as the sudden appearance of special operations forces in a specific regional profile, that can handled by having an allowance for shadow membership in profile group.

9. Multi Level Security (MLS) - Data and metadata of varying security classification and releasability levels will be distributed electronically at various network security levels. Emerging Guard technologies offer limited, almost exclusively one-way, passage of data from low to high security levels. Data and metadata will need to reflect the security classification perhaps at the feature level for a robust automated MLS system to be effectively employed. Impacts to storage, management and maintenance could be significantly reduced with a fully accredited MLS system and strategy.

4.4 Applications

This section defines the requirements for geospatial information applications. The descriptions contained in section 4.4.1 provide a top level view of the user environments and requirements specified in section 4.4.2. Issues and design considerations are presented in section 4.4.3.

4.4.1 User Environments and Requirements Overview

As described previously in Volume 1, the Joint Mapping Tool Kit (JMTK) is the current means by which geospatial applications are delivered to DII COE users. In the future, USIGS will provide geospatial applications to users both within and outside the DII COE environment. For DII COE users, USIGS Open Geospatial Exchange Services and Mission Specific Applications will be the means by which these services and applications are delivered. These services and applications will be minimally Level 5 compliant with the intent to achieve higher levels of compliance over time. For users outside the DII COE environment, access will be through Framework Services and associated interfaces provided directly by USIGS. Within the broad stakeholder community, many additional application tools will be needed to support specific missions. For these additional specific missions, such as targeting and terrain analysis, application development will be coordinated within the stakeholder community and some will be shared across the community while for others, interest will not extend beyond the originator.

The requirements specified herein include applications representing a wide spectrum of users within the stakeholder community and are categorized as “general purpose” applications and “specialized” applications. General purpose applications are those capabilities utilized by the majority of the user community who employ geospatial information as a tool in the course of performing their missions. Typical users of general purpose geospatial applications include intelligence analysts, command & control personnel and logistics planners. General purpose applications are the focus of the current JMTK effort. In the future, general purpose functionality will be delivered by USIGS Open Geospatial Exchange Services and USIGS Mission Specific Applications.

Specialized applications are those functions needed by a small percentage of the user community who focus on geospatial information as the primary means of task execution. These users include Army and Marine Corps terrain analysts and a small cadre of geospatial data managers within the Air Force and Navy. Workstations employed by these users will host general purpose applications as well as domain specific specialized applications. These specialized applications may be shared within the stakeholder community or may only be used in specific stakeholder environments. Given the specialized nature of these applications to a limited user base, their implementation will need to be coordinated within the community to ensure interoperability and responsibility.

Typical user roles and environments are depicted in the Operational Scenarios contained in Appendix H of the “DoD Interoperable Map Software (IMS) MC&G Domain Definition Report (DDR) (Version 2)”, dated 1 June 1996.

Figure 4-1 provides a notional representation of how application components would be utilized to build the capability needed for a specific user role. Delivery of these capabilities will be provided through a combination of USIGS compliant Open Geospatial Exchange Services and Mission Specific Applications as well as specialized application components designed to plug and play via published standard API’s.

Table 4-1 provides a summary of application requirements with an initial characterization as to their intended use – “general” for general purpose or “specialized”. The detailed requirements referenced in the table and contained in section 4.4.2 of this document were primarily derived from section 3.4 of the IMS DDR. Some modification to these requirements, identified by italics, were made as a result of imagery analyst input via the Pathfinder 97 project. The IMS DDR contains additional information not presented in this document which may further clarify the requirements and should be consulted as needed. The last column of Table 4-1 identifies the page in the IMS DDR that discusses each item in the table.

This document provides a baseline of requirements for general purpose and specialized applications. Requirements for additional capabilities will be added as user domain needs are further identified.

Figure 4-1 Software Component Approach to Building User Applications

4.4.2 Detailed Functional Requirements

The requirement hierarchy presented in this section is based on the object oriented MC&G Domain Analysis Model described in the DoD IMS MC&G Domain Definition Report.

The Cartographic Definition subject area, section 4.4.2.1 presents requirements necessary for the construction, manipulation, generation and presentation of a map.

The Geospatial Data subject area, section 4.4.2.2, describes the “local” data and the capabilities to perform staging and basic preparation of data prior to use. The capabilities in this section provide for the storage of data after manipulation as well as retrieval based on a variety of parameters.

The Military Spatial Analysis subject area, section 4.4.2.3, presents requirements for analytical capabilities that support a wide range of military applications.

4.4.2.1 Cartographic Definition

Cartographic definition involves the general capabilities needed to define and present the details of a map or chart. This includes capability for the construction (e.g., the area that the map will represent, selection of projection and datum), manipulation (e.g., manipulation and analysis capabilities via the geometric construct provided by point, polyline, and areas), generation (e.g., selection of background, overlays), and presentation of the map (e.g., zoom, pan, print/plot).

4.4.2.1.1 Area

Cartographic definition shall support area definitions.

-a Area Type/Color - The capability to utilize special line types and colors to indicate some attribute of an area (e.g., a restricted area, a threat area, an intersection of two areas, or an area on the map display defined by an end user) shall be provided. This capability shall include fill patterns (e.g., varieties of hachures or shading) that can be used to distinguish the type of area or the value of a feature associated with an area.

-b Boundary - Cartographic definition shall utilize boundaries to specify the region that is included in an area. The boundary shall consist of two sets of closed polylines. One set represents the regions that are included inside the polylines. That is, the “inside” of each closed polyline in this set is defined to be within the area. (No point that is outside all of these closed polylines can be in the area.) The other set represents the regions that are to be excluded. To be meaningful, each polyline in this set must bound a region that intersects some region defined in the “inclusion” set.

-c Label - The capability to label areas with text and graphics (e.g. icons, legends, scale, insets) shall be provided.

-d Compute Area Size - The capability to compute the extent or quantity of land and/or sea covered as measured over hills or on a flat surface shall be provided. Input is an Area object; output is a value such as “5.3 square miles.” This size shall accurately reflect any exclusions.

-e Compute Average Elevation - A compute average elevation capability shall be provided to compute the average elevation within a specified area.

-f Define Area - A define area capability shall allows the user to designate a region for survey by identifying a selected closed combination of arcs and line segments as its boundary. In addition, define area capability shall allows the user to exclude a region from such a survey by identifying a selected closed combination of arcs and line segments as the boundary of an excluded region. This capability shall include the capability to create or modify an area by adding or changing any of its attributes.

-g Generate Roughness - A capability shall be provided to display a visual representation of the approximate texture or coarseness of the terrain.

-h Locate Min/Max - A locate minimum/maximum elevation capability shall be provided to compute the highest and/or lowest elevation and its corresponding geographic position within a given area.

4.4.2.1.2 Background

Cartographic definition shall include a background capability that utilizes maps and charts showing certain fundamental information. The background is used as a base upon which additional data of specialized nature are compiled or overprinted. The background is treated as a whole, so that its individual features cannot be selected, moved, or modified. The background usually consists of static information from the spatial dataset. The two exceptions are perspective view and terrain profile where DTED-based pre-processing of spatial data is required. Background examples include, but are not limited to, Digital Chart of the World (DMA-VPF) and Digital Nautical Chart (DMA-VPF).

-a Define Background - The capability to define and select the background for a display shall be provided.

4.4.2.1.3 Context Map

Cartographic definition shall support context maps (also known as inset map) that show a smaller scale map relative to the area of interest of the Map object.

-a Type of Context - The capability to distinguishes between a context map showing the area of interest within the coverage area or the area of display within the area of interest shall be provided.

-b Visibility - The capability to toggle the visibility of the overlay, context map, symbols, labels and other objects shall be provided.

-c Display Context Map - The capability to portray a map as it relates to the coverage area of spatial data or as it relates to the portion currently being displayed shall be provided.

-d Redefine Area of Display - This capability shall allow the user to move a rectangle representing the current viewing position and scale of the map in relation to the entire area of interest so that the map will automatically be redraws to reflect the new viewing position. This capability shall also resize the rectangle of the inset map by enlarging or decreasing the size in rubber-band fashion and cause a corresponding change in scale in the main map window

4.4.2.1.4 Isopleth

The capability to define, display, and manipulate isopleths shall be provided (e.g. detection and engagement, line of sight (LOS), visibility, and altitude).

-a Isopleth Type - Multiple isopleth types shall be supported.

-b Unit Value - Each isopleth type shall have a unit value that defines the shape/topology of the isopleth (e.g., 3000 foot elevation contour).

-c Define Isopleth - The capability to specify the isopleth type (e.g., equal elevation, equal threat, etc.) and to specify the unit value for which the isopleth is to be identified (e.g., 100 meters, threat level 1) shall be provided.

4.4.2.1.5 Map

The cartographic definition capability shall provide the capability to generate and modify different map types using framework information. Map types include, but are not limited to, Topographic Maps, Hydrographic Charts and Aeronautical Charts.

-a Area of Interest - A map shall be capable of supporting multiple areas of interest (AOI) which are used to specify a particular region under investigation.

-b Datum - Maps shall be supported by a variety of datum. The default shall be WGS-84. Datum is defined as any numerical or geometrical quantity or set of such quantities which may serve as a reference or base for other quantities.

-c Projection - The capability for different map projections shall be provided. Examples include, but are not limited to, Mercator, Equidistant Conic, Orthographic, and Polar Stereographic.

-d Scale - Multiple map scales shall be supported.

-e Define Area of Interest - The capability to define area of interest shall be provided. This capability allows a narrowing of focus from a global to a regional area of interest within a coverage area. Its parameters are: area of interest (AOI), data type, and destination (overlay or background).

-f Register/Align - The elements in overlays and the background shall be automatically moved, resized, or otherwise adjusted based on the selected Map attributes.

-g Select/Set Scale - Select/set scale shall expand or restrict the inclusion of map features based on map scale. The smaller scale maps (those with the larger denominator, e.g., 1:1,000,000) will not include the detail that could be included in larger scale maps (those with smaller denominators, e.g., 1:12,500).

-h Transform Projection - Transform projection shall alter the map so that all features conform to the spatial relationships of the specified Projection attribute. Transformations involve changes in equations, ellipsoids, scale factors, cone constants, standard lines, standard parallels, origins, central meridians, etc. Grids shall be included to allow display in latitude/longitude, UTM, UPS or MGRS coordinates. Grid control shall include on/off, line type, line width, line color, scale increments, hatch increments, and labeling.

-i Transform/Shift Datum - The capability to alter the position of a point or feature in the map based on its datum attributes, different datum recorded with a spatial dataset, or datum given by a user, shall be provided. The result shall be an equivalent set of coordinates for one or more coordinates in an alternate datum. Transform/shift datum can be performed on one coordinate pair, area of interest, or entire data store.

4.4.2.1.6 Map Display

The Cartographic definition function shall support visual representation of a maps, human interaction with maps, and map output to printers and plotters.

-a Area of Display - The capability to specify the display area within a map shall be provided.

-b Center Point - A center point capability which automatically auto-pans to the middle of the map display shall be provided.

-c Orientation - Map orientation shall be selectable.

-d Convert Unit of Measure - The capability to change from one unit of measurement to another (e.g., nautical miles to statute miles, height in feet to height in meters, etc.) shall be provided.

-e Display - The capability to create a map display and output its image to a computer screen shall be provided.

-f Fade/Unfade - The degree of brightness (map intensity) of a map shall be selectable.

-g Pan - The capability to pan (i.e. scroll or roam) the display shall be provided.

-h Print/Plot Map - The capability to create a map image that is output to a printer, plotter, or other device shall be provided.

-i Recenter - Recenter shall position the map image so that a selected or default point is in the middle of the display window.

-j Rotate - The user shall have the capability to rotate displayed data.

-k Zoom - The capability to allow the user to zoom in and out of a map specified factor shall be provided.

4.4.2.1.7 Map Marginalia

Cartographic definition shall include map marginalia which provides a key for reading and interpreting a map. Map marginalia contains information enabling the interpretation of the map. It contains text and associated symbology, as well as such data as currency, copyright information, projection and scale data.

-a Define Marginalia - The capability to create, define, and modify the contents of map marginalia shall be provided.

4.4.2.1.8 Overlay

An overlay capability shall be provided which supplements a background with a data layer dealing with a distinct aspect of related information. It shall show details not appearing or requiring special emphasis on the background. An overlay shall be superimposed on a background at the same scale and registered by a common coordinate system.

-a Visibility (on/off) - The visibility of an overlay shall be on/off selectable.

-b Annotate - The capability to create and modify annotations shall be provided.

-c Declutter Features - A declutter capability shall be provided to remove, offset, or restore symbols in the overlay. This service shall operate based on criteria supplied by the end user.

-d Define Overlay - The capability to create, delete, select and/or modify the coverage and content of an overlay shall be provided.

-e Determine Union/Intersection - The capability to determine the union/intersection of two or more constituent areas or polylines of an overlay shall be provided.

-f Hide/Show/Reorder - This capability shall the capability to specify the order in which overlays are presented (e.g., an overlay containing city outlines and rivers would be presented “first prior” to an overlay containing building outlines and bridges or the city outline overlay would obscure the building outline overlay). This service shall also provide the capability to either hide (i.e., make the overlay invisible) or show (i.e., make the overlay visible).

-g Register/Align - Register/Align shall provide the following capability:

• Correctly position one component of a composite map image in relation to the other components.

• “Registers” the various Overlays and the Background such that the relative position is maintained.

• Makes attributes of the Map available to Background and each Overlay. The elements in each Overlay can be moved, resized, or otherwise adjusted based on the Map attributes.

• Replacement of Overlays for those that were registered or re-aligned.

4.4.2.1.9 Perspective View

The perspective view capability shall represent and manipulate a three-dimensional surface on the Earth with a reference to a specific viewer location on or above the surface portrayed. The perspective view shall provide the capability of displaying a slant perspective of shaded terrain, charts, or images based on DTED around planner-designated location and selected sight direction, altitude, depression angle, roll, and field of view. The perspective shall illustrate predicted sun sky angle or moon position and phase based on a planner-defined date and time. Additionally, the display over shaded terrain shall be sun or moon shaded. The display shall allow the planner to select routes, checkpoints, cultural features, threat symbols, and targets for inclusion in the display.

Generate Perspective Views shall support:

• Visual, radar, Synthetic Aperture Radar (SAR) for given altitude, heading, field of view.

• Visual draped on DTED.

• ADRG draped on DTED.

Perspective views shall support Fly-Throughs, since Fly-Throughs are a series of Perspective Views.

-a Date and Time - The user shall be able to specify the date and time of day (Zulu) so that solar illumination is properly provided to a visual prediction.

-b Field of View - The user shall be able to specify the field of view.

-c Illumination - The user shall be able to specify illumination. This attribute represents the lighting effect of sun or moon based on date, time, or weather information.

-d Observer Orientation - The user shall be able to specify the observer orientation.

-e Observer Position - The user shall be able to specify observer position (vertical and horizontal location of the observer to be used as the basis for intervisibility calculations). This may include the height and/or altitude of the observer or sensor.

-f Terrain Exaggeration - Perspective view shall include a capability that enhances differences in displayed elevation to highlight subtle terrain undulations.

-g Define Perspective View - The user shall be able to define perspective view shall by creating or modifying the three-dimensional representation of the map based on horizontal and vertical viewing position and azimuth.

-h Depict Illumination - Adjust perspective view display to reflect light/shadow effects of the sun or moon as defined by the Illumination attribute.

4.4.2.1.10 Point

A point is an elementary position within a geographic reference system. Points shall be selectable by a cursor, by a given set of coordinates, or by providing distance and azimuth relative to another point. Capabilities shall be provided to associate a point with a feature and/or item of application specific data.

-a Coordinate - Coordinates shall be available for each point as defined above.

-b Elevation/Depth - Elevation and depth of points shall be supported.

-c Label - Descriptive labels for points shall be supported.

-d Point Type/Color - The use of colors to indicate special points or features shall be supported.

-e Convert Coordinate - The capability to translate the value of a point in one coordinate system to its equal in a different coordinate system shall be provided.

-f Define Point - The capability to create, select, and/or modify a point shall be provided.

4.4.2.1.11 Polyline

Cartographic definition shall support polylines. These may be a series of connected legs or line segments, a circle, an ellipse, an arc, or any curvilinear figure. A closed polyline can represent the boundary of an area (polygon). There are many specializations of a line depending on the application (e.g., roads, communication links, etc.).

-a Label - Labeling of polylines shall be supported.

-b Polyline Type/Color - The capability to use different colors and/or types (also known as visual line formats [e.g., dashes]) to distinguish the associated values or meanings of a polylines shall be supported.

-c Compute Distance - A compute distance capability shall be provided that can determine the spatial separation of two points, measured by the length of a line joining them. This capability shall include support for great circles, rhumb lines, true distance and convergence.

-d Define Polyline - The capability to create, select, and/or modify a Polyline shall be provided.

4.4.2.1.12 Symbol

Cartographic definition shall include a flexible symbol capability that includes symbol scaling to presentation scale. Examples include, but are not limited to, symbols for ground, air, naval, electronic, and missile orders of battle.

-a Label - Labeling of symbols shall be supported.

-b Symbol Type/Color - Different colors and types of symbols shall be supported.

-c Define Symbology - The capability to create, edit, or delete predefined templates for symbols and define the criteria or rules for applying a template to a unique symbol shall be provided.

-d Group/Ungroup - A group/ungroup capability which can manipulate an assemblage of symbols as one or, conversely, to segregate and manipulate each of the various symbols independently of the group shall be provided.

4.4.2.1.13 Terrain Profile

Cartographic definition shall include a terrain profile capability.

-a Ending Point - The capability to define a terrain profile end point shall be provided.

-b Starting Point - The capability to define a terrain profile start point shall be provided.

-c Define Terrain Profile - The capability to define a terrain profile or modify the cross-section representation of the Earth’s terrain from the starting point to the ending point shall be provided.

4.4.2.1.14 Text

Cartographic definition shall support the use of text (annotation) which can be associated with an area, point, line, or symbol.

-a Text Type/Color - Different types and colors of text shall be supported.

-b Define Text - A define text capability shall allow the user to insert additional information within the map as an annotation or as free text.

4.4.2.1.15 Vector

The polyline capability shall support the definition and use of vectors which represent magnitude and direction.