3. Application Platform Entity Standards

3.1 Background

This section specifies the Imagery and Geospatial Community (IGC) profile of the DoD Joint Technical Architecture (JTA) for Application Platform Services. The profile, in addition to requiring the use of most JTA standards, also mandates standards which are in addition to or take exception to those currently mandated in the JTA 2.0. Differences between the JTA and UTA standards are clearly noted. This section also includes additional information on other standards of special interest to the IGC which may affect planned acquisitions. Each referenced standard includes textual descriptions and usage criteria.

The IGC Profile is organized in a format consistent with that of the JTA. The JTA addresses commercial and Government standards common to most DoD information technology, grouped into categories: Information Processing Standards; Information Transfer Standards; Information Modeling, Metadata, and Information Exchange Standards; Human-Computer Interface Standards; and Information Systems Security Standards.

Some of the significant standards changes from the previous (first) version of the UTA:

• New mandate for MIL-STD-2500B (NITFS 2.1); which supersedes MIL-STD-2500A (NITFS 2.0)
• New mandate for MIL-STD-2301A, CGM for NITFS; which supersedes MIL-STD-2301
• New mandate for CORBA 2.2; superseding version 2.1
• Mandate for new version of the DoD/IC/USIGS Video Imagery Standards Profile (VISP) version 1.3; superseding earlier version 1.1
• Addition of NITFS Support Data Extensions for specific NITF implementation categories

3.2 Standards Definitions

The UTA describes several types or categories of standards. The definitions of these standards types and categories are consistent with those in the JTA unless noted. The definitions in this section are necessary to understand the content of this section and the usage requirements for the standards.

Standards

A 'standard' is a document that establishes engineering and technical requirements for processes, procedures, practices, and methods. The standards in the UTA and JTA include commercial, government, DoD standards and specifications, as well as other kinds of authoritative documents.

Profiles

'Profile of a Standard' - Some standards have optional parts or parameters that can affect interoperability, so an individual standard may be further defined by a separate, authoritative document called a 'profile' or a 'profile of a standard' which refines-via specified options and parameters-the implementation of the original standard.

'Standards Profile' - A collection of two or more standards, profiled together to meet the requirements of a specific user community. A standards profile may also include one or more instances of a 'profile of a standard'; an example of this is the National Imagery Transmission Format Standard (NITFS) standards profile described in this section.

Exceptions and Additions

This section of the UTA is the IGC standards profile of the JTA standards. The terms used to describe differences between the UTA and JTA are 'Exception' and 'Addition.'

'Exception to JTA' - a UTA standard which replaces, or supersedes, an existing mandated or emerging standard from the JTA 2.0. Exceptions are rare, since the JTA was developed with input from NIMA. This version of the UTA only contains seven (7) exceptions, all of which are updated versions of the JTA standard. An exception is to be used in all new or upgraded USIGS systems IN PLACE OF the JTA standard.

'Addition to JTA' - an additional standard required for all new or upgraded USIGS systems, exceeding the mandatory or emerging standards listed in the JTA 2.0. An addition is usually non-conflicting with the JTA mandate; any known conflicts will be noted in the discussion of the mandate. There are numerous 'Additions to JTA' in this version of the UTA. These standards will be proposed for inclusion in future versions of the JTA.

USIGS Status

The time phasing that is part of the information provided by a technical architecture is reflected in the UTA as a 'USIGS Status' indicator. Terms used to describe the USIGS status of each of the standards and specifications presented in both Sections 3 and 4 are Mandatory and Emerging:

Mandatory: Mandatory standards in the UTA and the JTA must be implemented or used by USIGS systems that have a need for the corresponding service areas. A standard is mandatory only if the service or interface provided is necessary in the system under development. The standards in the UTA are grouped into service areas such as 'Still Imagery Data Interchange' or 'Distributed Object Computing.' If the service area is to be implemented in a USIGS system, it must be done using the UTA (or JTA) mandated standard(s) at a minimum. The UTA and JTA do not prohibit the use of additional standards in a service or interface above and beyond this minimum, mandatory set; however, these other standards must not conflict with the UTA and JTA mandates. All new systems within USIGS must support the minimum set of mandatory standards within the UTA. Migration systems will be evaluated on a case-by-case basis as described in Section 1.2.1.1. The UTA identifies standards or practices, beyond those also mandated in the JTA 2.0, which are necessary to support interoperability within the USIGS. Each mandated UTA standard is identified by a formal reference citation that is suitable for inclusion within Requests for Proposals (RFPs), Statements of Work (SOWs), or other formal acquisition documents.

All new systems within USIGS must support the mandatory standards from the JTA 2.0 unless otherwise noted in the UTA Profile by an 'Exception.' Several UTA standards are mandatory only for a specified subset of the USIGS. For each of these standards, the Remarks column of Table 3-1 and/or the Usage paragraph will specify which part of the USIGS must implement the standard.

Emerging: These are existing standards or developing standards that may become mandatory in the UTA at some future date. The UTA definition of 'Emerging' includes standards or specifications under development. This expands the JTA definition, which is normally limited to approved, formal documents. The purpose of listing these emerging standards in the UTA is to help the USIGS acquisition and development community determine those services or interfaces that are likely to undergo change in the next several years. The expectation is that many of the emerging UTA (or JTA) standards will most likely be elevated to mandatory UTA status at some time in the future. This is likely to happen when the services provided by these standards are needed within USIGS to enhance existing functions or to provide additional functionality not currently available in existing standards.

An Emerging UTA or JTA standard may also be implemented in new or upgraded USIGS systems, but not in place of a Mandatory UTA or JTA standard. The decision to require an emerging standard in new or upgraded USIGS systems should be made after considering the developmental state of the standard and the predicted development timeframe of a system.

3.3 Standards Profile Summary

Table 3-1 lists the IGC exceptions and additions to the mandated JTA standards, grouped by JTA-defined Service Areas. If a UTA Exception or Addition to the JTA is included in the table, the standard that supports that function or service is identified by name and document identifier assigned by the specification's issuing organization. If no UTA standards or profiles are listed for a specific JTA service area, the UTA mandates all the standards in the indicated JTA section without exception. Emerging standards exceptions and additions to the JTA are also included in this table. Internet URLs for obtaining copies of each standard and specification in the table are provided at the beginning of Section 3.4.

A complete summation of the JTA 2.0 and UTA standards, sorted by each service area, is provided in an addendum to the UTA. That set of tables is not intended to be a comprehensive substitute for the UTA or JTA documents.

JTA Service Area & Section Number	USIGS Status	Standard Name(s)	Standard Document Identifier(s)	Remarks
2.2 INFORMATION PROCESSING				The UTA includes both Exceptions and Additions to the JTA 2.0 mandated standards in JTA Section 2.2. The UTA also includes additions to the JTA emerging standards.
2.2.2.2.1.4.4 Still Imagery Data Interchange	Mandatory	National Imagery Transmission Format (Version 2.1) for the National Imagery Transmission Format Standard (NITFS)	MIL-STD-2500B, National Imagery Transmission Format (Version 2.1) for the National Imagery Transmission Format Standard, 22 August 1997; with Notice 1, 2 October 1998	EXCEPTION TO JTA. NITF 2.1 supersedes the NITF 2.0 (MIL-STD-2500A). With the addition of the Notice 1, 2500B and NATO STANAG 4545 (NSIF), Edition 1, are technically equivalent.
2.2.2.2.1.4.4 Still Imagery Data Interchange	Mandatory	Computer Graphics Metafile (CGM) Implementation Standard for the NITFS	MIL-STD-2301A, Computer Graphics Metafile (CGM) Implementation Standard for the NITFS, effective 5 June 1998	EXCEPTION TO JTA. MIL-STD-2301A is the NITFS profile of the ISO CGM standard and enhances the CGM capabilities in MIL-STD-2301, Computer Graphics Metafile (CGM) Implementation Standard for the NITFS, 18 June 1993. 2301A supersedes 2301. Use of MIL-STD-2301A is only mandatory for NITF 2.1-compliant files.
2.2.2.2.1.4.4 Still Imagery Data Interchange	Mandatory	Adaptive Recursive Interpolated Differential Pulse Code Modulation (ARIDPCM)	MIL-STD-188-197A 12 Oct 1994	ADDITION TO JTA. This standard is only required for ingesting and decompressing ARIDPCM compressed files (NITF 1.1 format imagery) This mandate is unchanged since UTA 1.0, 6 Nov 1997.
2.2.2.2.1.4.4 Still Imagery Data Interchange	Mandatory	ICHIPB Support Data Extensions for the National Imagery Transmission Format	ICHIPB, 16 November 1998	ADDITION TO JTA. This standard is only applicable to a subset of the USIGS: For systems which produce, disseminate, or use National Technical Means (NTM), Tactical/Airborne imagery, or Commercial Satellite imagery ONLY
2.2.2.2.1.4.4 Still Imagery Data Interchange	Mandatory	National Imagery Transmission Format Profile for Imagery Access Extensions (PIAE)	PIAE, Version 3.0, 25 September 1997; as documented in Section 6 of the Compendium of Controlled Extensions (CE) for the National Imagery Transmission Format (NITF) 1.0, 25 August 1998	ADDITION TO JTA. This standard is only applicable to a subset of the USIGS: For systems which produce, disseminate, or use National Technical Means (NTM), Tactical/Airborne imagery, or Commercial Satellite imagery ONLY
2.2.2.2.1.4.4 Still Imagery Data Interchange	Mandatory	Synthetic Aperture Radar (SAR) Support Data Extensions (SDE) for the National Imagery Transmission Format Standard	SAR SDE, 20 May 1996; as documented in Section 8 of the Compendium of Controlled Extensions (CE) for the National Imagery Transmission Format (NITF) 1.0, 25 August 1998	ADDITION TO JTA. This standard is only applicable to a subset of the USIGS: For systems which produce, disseminate, or use Tactical/Airborne imagery ONLY
2.2.2.2.1.4.4 Still Imagery Data Interchange	Mandatory	Visible, Infrared, and Multispectral Airborne Sensor Support Data Extensions (SDE) for the National Imagery Transmission Format Standard	VIMAS SDE, 25 September 1997; as documented in Section 10 of the Compendium of Controlled Extensions (CE) for the National Imagery Transmission Format (NITF) 1.0, 25 August 1998	ADDITION TO JTA. This standard is only applicable to a subset of the USIGS: For systems which produce, disseminate, or use Tactical/Airborne imagery ONLY
2.2.2.2.1.4.4 Still Imagery Data Interchange	Mandatory	HISTOA Extension, Softcopy History Tag	HISTOA Extension, as documented in Section 15 of The Compendium of Controlled Extensions (CE) for the National Imagery Format Transmission Format (NITF), Version 1.0, 25 August 1998	ADDITION TO JTA. For systems which produce, disseminate, or use National Technical Means (NTM)
2.2.3.3.5 Still Imagery Data Interchange	Emerging	Commercial Electro-Optical Support Data Extensions (SDE) for the National Imagery Transmission Format Standard	Commercial SDE, Version 0.9, 25 September 1997; as documented in Section 7 of The Compendium of Controlled Extensions (CE) for the National Imagery Format Transmission Format (NITF), Version 1.0, 25 August 1998	ADDITION TO JTA. For systems which produce, disseminate, or use Commercial Satellite Imagery ONLY
2.2.3.3.5 Still Imagery Data Interchange	Emerging	(PROPOSED) NITF ISP of ISO/IEC International Standard 12087-5, Basic Image Interchange Format (BIIF)	Document under development	ADDITION TO JTA. BIIF, ISO/IEC IS 12087-5, Information Technology - Computer graphics and image processing - Image Processing Interchange (IP) - Functional specification - Part 5: Basic Image Interchange Format (BIIF), was published 1 December 1998. The ISP of BIIF will supersede MIL-STD-2500B, NITF 2.1
2.2.2.2.1.4.5.1.1 Video Imagery	Mandatory	DoD/IC/USIGS Video Imagery Standards Profile (VISP)	DoD/IC/USIGS Video Imagery Standards Profile (VISP) version 1.3, 6 March 1998	EXCEPTION TO JTA. This document is later version than the version referenced in the JTA. JTA 2.0 mandates 5 core standards from the VISP 1.21 and specifically omits VISP Recommended Profiles and Practices. The UTA mandates VISP 1.3, which includes the same base standards as the JTA, but also includes the Profiles and Practices NOT required by the JTA.
2.2.2.2.2.4.2 Distributed Object Computing	Mandatory	The Common Object Request Broker: Architecture and Specification	OMG document formal/98-02-01, CORBA/IIOP 2.2	EXCEPTION TO JTA. Later version than JTA mandate. JTA 2.0 mandates CORBA 2.1 Includes Interface Definition Language (IDL)
2.2.3.5 Emerging Distributed (Object) Computing	Emerging	Fault Tolerance (ORB Enhancement) April 3, 1998	OMG document orbos/98-04-01, Fault Tolerance RFP	ADDITION TO JTA
2.2.3.5 Emerging Distributed (Object) Computing	Emerging	IDL to Java (ORB Enhancement) January 19, 1998	OMG document orbos/98-01-06, Final Java/POA	ADDITION TO JTA
2.2.3.5 Emerging Distributed (Object) Computing	Emerging	Java to IDL (ORB Enhancement) January 19, 1998	OMG document orbos/98-01-07, Java to IDL Revised; orbos/98-02-01, Revised Java to IDL Mapping; orbos/98-03-08, Errata to Java to IDL mapping	ADDITION TO JTA
2.2.3.5 Emerging Distributed (Object) Computing	Emerging	Messaging Service (ORB Enhancement) March 7, 1996	OMG document orbos/98-05-06, Revised Messaging RFP submission; orbos/98-05-12, IDL files related to Messaging Revised Submission	ADDITION TO JTA
2.2.3.5 Emerging Distributed (Object) Computing	Emerging	Multiple Interfaces and Composition (ORB Enhancement) January 11, 1996	OMG document orb/96-01-04, Revised Multiple Interfaces and Composition RFP	ADDITION TO JTA
2.2.3.5 Emerging Distributed (Object) Computing	Emerging	Objects-by-Value (ORB Enhancement) January 19, 1998	OMG document orbos/98-01-01, Objects-by-Value Revised Submission; orbos/98-01-18, Joint Revised Objects-by Value Submission with Errata	ADDITION TO JTA
2.2.3.5 Emerging Distributed (Object) Computing	Emerging	Tagged Data (ORB Enhancement) March 4, 1998	OMG document orbos/97-12-26, Tagged Data draft RFP; orbos/98-02-18, Tagged Data RFP Errata Sheet	ADDITION TO JTA
2.2.2.2.2.4.2 Distributed Object Computing	Mandatory	CORBAservices Naming Service	OMG document formal/97-12-10, CORBAservices Naming Service	EXCEPTION TO JTA. This document is later version than the version referenced in the JTA.
2.2.2.2.2.4.2 Distributed Object Computing	Mandatory	CORBAservices Event Service	OMG document formal/97-12-11, CORBAservices Event Service	EXCEPTION TO JTA. This document is later version than the version referenced in the JTA.
2.2.2.2.2.4.2 Distributed Object Computing	Mandatory	CORBAservices Transaction Service	OMG document formal/97-12-17, CORBAservices Transaction Service	EXCEPTION TO JTA. This document is later version than the version referenced in the JTA.
2.2.2.2.2.4.2 Distributed Object Computing	Mandatory	CORBAservices Object Collections	OMG document formal/97-12-24: CORBAservices Object Collections	ADDITION TO JTA.
2.2.2.2.2.4.2 Distributed Object Computing	Mandatory	CORBAservices Concurrency Control Service	OMG document formal/97-12-14: CORBAservices - Concurrency Control Service	ADDITION TO JTA.
2.2.2.2.2.4.2 Distributed Object Computing	Mandatory	CORBAservices Externalization Service	OMG document formal/97-12-15: CORBAservices - Externalization Service	ADDITION TO JTA.
2.2.2.2.2.4.2 Distributed Object Computing	Mandatory	CORBAservices Life Cycle Service	OMG document formal/97-12-13: CORBAservices - Life Cycle Service	ADDITION TO JTA.
2.2.2.2.2.4.2 Distributed Object Computing	Mandatory	CORBAservices Licensing Service	OMG document formal/97-12-19: CORBAservices - Licensing Service	ADDITION TO JTA.
2.2.2.2.2.4.2 Distributed Object Computing	Mandatory	CORBAservices Property Service	OMG document formal/97-12-20: CORBAservices - Property Service	ADDITION TO JTA.
2.2.2.2.2.4.2 Distributed Object Computing	Mandatory	CORBAservices Query Service	OMG document formal/97-12-18: CORBAservices - Query Service	ADDITION TO JTA.
2.2.2.2.2.4.2 Distributed Object Computing	Mandatory	CORBAservices Relationship Service	OMG document formal/97-12-16: CORBAservices - Relationship Service.	ADDITION TO JTA.
2.2.2.2.2.4.2 Distributed Object Computing	Mandatory	CORBAservices Security Service	OMG documents formal/97-12-22: CORBAservices - Security Service	ADDITION TO JTA. Augmentation of these specifications is expected in 1998 or 1999 to provide for greater levels of assurance.
2.2.2.2.2.4.2 Distributed Object Computing	Mandatory	CORBAservices Time Service	OMG document formal/97-12-21: CORBAservices - Time Service	ADDITION TO JTA.
2.2.2.2.2.4.2 Distributed Object Computing	Mandatory	CORBAservices Trading Object Service	OMG document formal/97-12-23: CORBAservices - Trading Object Service	ADDITION TO JTA. (NOTE: This is also the ISO RM-ODP Trader Function)
2.2.3.5 Emerging Distributed (Object) Computing	Emerging	CORBAservices Persistent State Service	OMG document orbos/98-05-10, Persistent State Service 2.0	ADDITION TO JTA This service will eventually replace the current CORBAservices Persistent Object Service, OMG document formal/97-12-12
2.2.3.5 Emerging Distributed (Object) Computing	Emerging	DCE/CORBA Interworking Service	OMG document orbos/98-06-01, CORBAservices DCE/CORBA Interworking Service	ADDITION TO JTA
2.2.3.5 Emerging Distributed (Object) Computing	Emerging	CORBAservices CORBA/Firewall Security	OMG document orbos/98-05-04, CORBAservices CORBA/Firewall Security	ADDITION TO JTA
2.2.3.5 Emerging Distributed (Object) Computing	Emerging	CORBAservices Interoperable Name Service	OMG document orbos/98-03-04, CORBAservices Interoperable Name Service	ADDITION TO JTA When approved, this specification will replace the CORBAservices Naming Service
2.3 Information Transfer Standards				The UTA contains Additions, but no Exceptions to JTA mandated and emerging standards for Section 2.3
2.3.2.2.2.5 Asynchronous Transfer Mode (ATM)	Mandatory	Defense Information System Network (DISN) Asynchronous Transfer Mode (ATM) System Specification	DISN ATM System Specification, 17 April 1998	ADDITION TO JTA - This standard is only applicable to a subset of the USIGS: For system interface to DISN only. Not identical to JTA 2.0 ATM mandates.
2.3.2.2.2.5 Asynchronous Transfer Mode (ATM)	Mandatory	DoD Asynchronous Transfer Mode Standards	DoD ATM Standards, (version 1.0), 17 April 1998	ADDITION TO JTA - This standard is only applicable to a subset of the USIGS: For system interface to DISN only. Not identical to JTA 2.0 ATM mandates.
2.4 Information Modeling, Metadata, and Information exchange Standards				There are no UTA exceptions or additions to JTA Mandated or Emerging standard(s) in JTA Section 2.4. USIGS Data Modeling standards are addressed in Section 5 of the UTA.
2.5 Human-Computer Interface standards				There are no additions or exceptions to JTA Mandated Standard(s) in JTA Section 2.5. However, there are additions to the Emerging standards.
2.5. 3 Emerging (Symbology) Standards	Emerging	DoD Performance Specification Geospatial Symbols for Digital Displays (GeoSymä ) DRAFT	MIL-PRF-89045, DoD Performance Specification Geospatial Symbols for Digital Displays (GeoSymä ) DRAFT, 20 February 1998	ADDITION TO JTA. Supplements MIL-STD-2525A and supersedes DRAFT BIMA (Basic Imagery and Mapping Annotation) Graphics document. Approval expected in 1999.
2.6 Information Systems Security Standards				There are no UTA exceptions or additions to JTA Mandated or Emerging standard(s) in JTA Section 2.6.

3.4 Description of Specifications and Usage

This section provides textual descriptions for each standard in Table 3-1 and for additional JTA standards which are likely to be of interest to the USIGS community. The descriptions are provided for clarity and direction for USIGS developers and for program planning. The discussion is organized by JTA service area, to be consistent with the table. Each standard is referenced with a formal Title, Description, USIGS Status, and a Usage reference. All of the standards and specifications described in this section can be obtained in softcopy at the following URLs:

Geospatial Data Interchange (MIL-STDs, STANAG): www.nima.mil
DIGEST: www.digest.org
Still Imagery and Video Data Interchange: www.ismc.nima.mil
Distributed Computing Services: www.omg.org
DISN ATM: www.disa.atd.net/DISNATM_DOCS
Geospatial Symbols for Digital Displays: www.nima.mil

3.4.1 Additional IGC Standards

Section 3.4 includes additional standards descriptions not included in Table 3-1. These standards, listed in Table 3-2, are geospatial or imagery standards already covered in the DoD JTA 2.0 or are international standards of special developmental interest to the IGC.

Standard	Referenced in:	Standard	Referenced in:
Vector Product Format	JTA	Bi-Level Image Compression for the NITF Standard	JTA
Raster Product Format	JTA	Common Warfighting Symbology	JTA
DoD World Geodetic System 1984	JTA	Basic Image Interchange Format (BIIF)	JTA emerging
Countries, Dependencies, Areas of Special Sovereignty and Their Principal Administrative Divisions	JTA	Digital Geographic Information Exchange Standard (DIGEST)	JTA emerging
JPEG for the NITF Standard	JTA	NIMA Tech Report for the DoD WGS	JTA emerging
Vector Quantization Decompression for the NITF Standard	JTA	NATO Secondary Imagery Format (NSIF), STANAG 4545

3.4.2 Information Processing Standards

The UTA includes both Exceptions and Additions to the JTA 2.0 mandated standards in JTA Section 2.2. The UTA also includes additions to the JTA Section 2.2 emerging standards.

3.4.2.1 Graphics Data Interchange

USIGS developers will comply with the JTA for this service area with the exception of graphics formats which support the exchange of National Imagery Transmission Format (NITF) files. See UTA Section 3.4.3 for Computer Graphics Metafile (CGM) standards for USIGS systems producing, exchanging, or using NITFS files.

3.4.2.2 Geospatial Data Interchange

MIL-STD-2407, Interface Standard for Vector Product Format (VPF), 28 June 1996

Description: Vector Product Format (VPF) defines a common format, structure, and organization for data objects in large geographic databases that are based on a georelational data model and intended for direct use. VPF is designed to be compatible with a wide variety of applications and products. Existing geospatial products which implement VPF include:

Vector Smart Map (VMap) Levels 0-2
Urban Vector Smart Map (UVMap)
Digital Nautical Chart (DNC)
VPF Interim Terrain Data (VITD)
Digital Topographic Data (DTOP)
World Vector Shoreline Plus (WVS+)

USIGS Status: Mandatory

Usage: All new or upgraded USIGS systems which prepare or access digital geographic data in vector product format.

MIL-STD-2411A, Raster Product Format (RPF), 6 October 1994, with Notice of Change 1, 17 January 1995

Description: MIL-STD-2411A, the Raster Product Format (RPF), is a specification which defines a standard data structure for rectangular arrays of pixels. RPF is most often used for geospatial databases in compressed (using Vector Quantization) or uncompressed form. It is intended for data interchange and is designed to require no manipulation of the data, other than decompression, in order to use or display it. MIL-STD-2411-1 is an accompanying standard to the RPF that defines registered data values to be used in RPF files. Existing geospatial products which implement RPF include:

Compressed Arc Digitized Raster Graphics (CADRG)
Controlled Image Base (CIB)
Digital Point Positioning Data Base (DPPDB)

USIGS Status: Mandatory

Usage: All new or upgraded USIGS systems which prepare or access digital geographic data in raster product format.

MIL-STD-2401, Department of Defense World Geodetic System (WGS-84), 11 January 1994

Description: The Department of Defense World Geodetic System (WGS 84), MIL-STD-2401, a Conventional Terrestrial Reference System (CTRS), specifies a standard global coordinate system for representation of a reference frame, reference ellipsoid, fundamental constants, and an Earth Gravitational Model with related geoid. Included in the Reference System are parameters for transferring to/from other geodetic datums. WGS 84 is the official DoD positional reference system. Navigation solutions from the NAVSTAR Global Positioning System (GPS) and the Navy Navigation Satellite System (NNSS) are referred to this system.

The technical content of WGS 84 is provided by DMA TR8350.2, DMA Technical Report - DoD World Geodetic System 1984, 1 September 1991. This Report has recently been updated and republished as NIMA TR8350.2, NIMA Technical Report - DoD World Geodetic System 1984, 4 July 1997. This new version of the report supersedes the earlier version.

USIGS Status: Mandatory

Usage: This standard applies to all DoD systems and products which require use of a world geodetic system; i.e., a consistent global coordinate system which allows an unambiguous representation of positional information. WGS 84 will be used for all joint operations and is recommended for use in multinational and unilateral operations after coordination with allied commands (CJCS).

FIPS PUB 10-4, Countries, Dependencies, Areas of Special Sovereignty, and Their Principal Administrative Divisions, April 1995

Description: FIPS PUB 10-4 provides a list of the basic geopolitical entities in the world, together with the principal administrative divisions that comprise each entity.

USIGS Status: Mandatory

Usage: For USIGS applications involving the interchange of geospatial information requiring the use of country codes.

STANAG 7074, Digital Geographic Information Exchange Standard (DIGEST) 2.0, June 1997

Description: The Digital Geographic Information Exchange Standard (DIGEST) was developed by the Digital Geographic Information Working Group (DGIWG) to support efficient exchange of Digital Geographic Information among nations, data producers, and data users.

The Digital Geographic Information Working Group (DGIWG) was established in 1983 to develop standards to support the exchange of Digital Geographic Information (DGI) among NATO nations. The DGIWG is not an official NATO body; however, the DGIWG's standardization work has been recognized and welcomed by the NATO Geographic Conference (NGC).

DIGEST is a comprehensive "family of standards" capable of supporting the exchange of raster, matrix, and vector data (and associated text) among producers and users. DIGEST can support the entire range of topological structures from no topology to full topology.

DIGEST is divided in 4 parts:

Part 1 consists of a brief general description of the standard.
Part 2 consists of the Theoretical Model, Exchange Structure, and Encapsulation specifications. The encapsulations include:
Annex A - based on ISO 8211.
Annex B - for telecommunication based on ISO 8824/5.
Annex C - Vector Relational Format (VRF).
Annex D - Image Interchange Format based on the NATO Secondary Imagery Format (NSIF) and the geopositioning parameters of DIGEST.
Annex E - Simple table of contents option for the data transmittal.
Part 3 consists of Codes, Parameters, and Tags.
Part 4 of DIGEST is the Feature and Attribute Coding Catalogue (FACC). FACC is a comprehensive coding scheme for features, their attributes and attribute values.

DIGEST has evolved to address new technologies and new geospatial requirements. Enhancements for version 2 include: imagery geopositioning; compression algorithm options via NATO Secondary Image Format (NSIF/STANAG 4545); mixing and alignment of various data types; compatibility with the National Imagery and Mapping Agency (NIMA) Vector Product Format (MIL-STD 2407); consistent Metadata across encapsulations; and a logical restructuring of the document. DGIWG is working closely with ISO TC 211 in the development of International Geospatial Standards and the migration of DIGEST as a profile of the ISO standards. Compatibility with other standards such as the NATO Secondary Imagery Format (NSIF), the International Hydrographic Organization S-57 Standard, and other International standards will continue to influence future versions of DIGEST.

Digital Geographic Information (or geospatial information) has evolved into an essential element in the planning and conduct of civil and military operations. The required data volume, demands and data complexity dictates the need for standards to assure interoperability and compatibility. DIGEST satisfies this need by defining those aspects necessary for the exchange of Digital Geographic/Geospatial Information such as data structures, format, feature coding scheme, exchange media, and administrative procedures.

Over the last few years DIGEST has become the basis for coproduction opportunities between nations. DIGEST-compliant datasets are being produced and exchanged by a number of nations to support a variety of military and civilian applications. DIGEST is a NATO standardization agreement (STANAG 7074). Industry continues to develop and promote commercial software based on compliance with DIGEST. NIMA Vector Product Format and NIMA's feature and attribute coding is based on DIGEST. The NATO Secondary Imagery Format (NSIF) points to DIGEST for georeferencing imagery. DIGEST/elements of DIGEST have been implemented by over 20 nations.

USIGS Status: Emerging

Usage: N/A

3.4.2.3 Still Imagery Data Interchange

Still Imagery refers to imagery where a likeness or representation of any natural or man-made feature or related object or activity and the positional data acquired at the same time was acquired, including products produced by space-based national intelligence reconnaissance systems, and likenesses or representations produced by satellites, airborne platforms, unmanned aerial vehicles, or other similar means. The Still Imagery standards in the DoD Joint Technical Architecture and the UTA are currently limited to the National Imagery Transmission Format Standard (NITFS).

The National Imagery Transmission Format Standard (NITFS) is a DoD and Federal Intelligence Community suite of standards for the exchange of digital still imagery products and image related products. Figure 3-1 diagrams the expected evolution of the NITFS.

NITFS provides a package containing information about the image, the image itself, and optional overlay graphics. The Standard provides a 'package' containing an image(s), subimages, symbols, labels, and text as well as other information related to the image(s). The NITFS suite is the standard for the exchange of USIGS Still Imagery. Refer to the National Imagery Transmission Format Standard (NITFS) Five Year Program Plan, Version 1.0, 1 July 1998 for an introduction to the NITFS suite of standards.

The NITFS Bandwidth Compression Standards and Guidelines, Version 1.0, 25 August 1998, covered in Section 5 of the UTA, defines the Bandwidth compression conventions and guidelines (such as "Downsample JPEG Compression - NIMA Method 4") required for use by the National Imagery Transmission Format Standard (NITFS).

MIL-STD-2500B, National Imagery Transmission Format (Version 2.1) for the National Imagery Transmission Format Standard, 22 August 1997 with Notice 1, 2 October 1998

Description: EXCEPTION TO JTA MANDATE (LATER VERSION). MIL-STD-2500B defines the NITF version 2.1, the standard file format for the exchange of imagery and imagery-related products to be used by the DOD and IC. MIL-STD-2500B is the United States' implementation of the NATO Secondary Imagery Format (NSIF) - STANAG 4545. NITF 2.1 is a part of the more inclusive National Imagery Transmission Format Standard (NITFS) and is used for transmission of still imagery and associated data. NITF 2.1 is the core of the NITF Suite of standards, and is coupled with additional standards for compression, graphics, and communications.

The NITF can be used to support interoperability by providing a data format for shared access applications, while also serving as a standard file format for the exchange of images, imagery derived intelligence, graphics, text, and associated data. The NITF is suitable for archiving imagery.

A NITF file supports the inclusion of three standard types of segments in a single file: image, graphic, and text segments. Additional types of data may be included in a NITF file by use of Extension Segments (ES).

MIL-STD-2500B shall be implemented in accordance with the National Imagery Transmission Format Standard (NITFS) Five Year Program Plan, Version 1.0, 1 July 1998, and MIL-HDBK-1300A.

NOTE: With the addition of the Notice 1 to MIL-STD-2500B, the NITF 2.1 standard and NATO STANAG 4545 (NATO Secondary Image Format/NSIF) are technically equivalent.

USIGS Status: Mandatory

Usage: NITF 2.1 is mandated for all C4I systems disseminating secondary imagery by the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASD(C3I)), and is required for interoperability within the USIGS when exchanging digital still imagery products and image related products. All new USIGS systems, and those undergoing major modification, shall conform to this standard.

Figure 3-1. Expected Evolution of the NITFS

Description: EXCEPTION TO JTA MANDATE (LATER VERSION). This standard defines a subset of Computer Graphics Metafile (CGM) commands applicable for graphic annotation of NITFS imagery. This standard is necessary to implement CGMs used for the representation of symbol graphics in the NITFS. MIL-STD-2301A enhances and expands the CGM capabilities in MIL-STD-2301, Computer Graphics Metafile (CGM) Implementation Standard for the National Imagery Transmission Format (NITF) Standard, 18 June 1993. MIL-STD-2301A superseded MIL-STD-2301 on 1 October 1998, which coincides with the date on which MIL-STD-2500B, National Imagery Transmission Format Version 2.1 for the NITF Standard, 22 August 1997 superseded MIL-STD-2500A, National Imagery Transmission Format (Version 2.0) for the NITF Standard, 12 October 1994.

USIGS Status: Mandatory

Usage: This standard is applicable to the DoD and the Intelligence Community and is mandatory for all new or upgraded Secondary Imagery Dissemination Systems (SIDS) which exchange digital still imagery products and image related products. Use of MIL-STD-2301A will only be mandatory for NITF 2.1-compliant files. However, the content of 2301A included in the earlier 2301 standard is still required for processing NITF 2.0-formatted files.

MIL-STD-188-198A, Joint Photographic Experts Group (JPEG) Image Compression for the National Imagery Transmission Format Standard, 15 December 1993 with NOTICE 1, 12 October 1994 and NOTICE 2, 14 March 1997

Description: This standard establishes the requirements to be met by systems complying with NITFS when image data are compressed using the JPEG image compression algorithm as described in DIS 10918-1, Digital Compression and Coding of Continuous-tone Still Images.

MIL-STD-188-198A provides technical detail of the NITFS compression algorithm designated by the code C3 in the Image Compression field of the National Imagery Transmission Format (NITF) file image subheader, JPEG, for both eight- and 12-bit gray scale imagery and 24-bit color imagery. It also provides the required default quantization tables for use in Secondary Imagery Dissemination Systems (SIDS) complying with NITFS.

The requirements specified in this standard are intended to enable the interchange of 8- and 12-bit gray scale imagery and 24-bit color imagery compressed with JPEG. This standard specifies two classes of encoding and decoding processes, lossy and lossless processes.

Follow-on(s) to 188-198A: Joint Photographic Experts Group (JPEG) 2000 is the title given to the follow-on to the currently defined NITFS JPEG standard, but which will be a wavelet based solution. A key feature of this compression is that it will be based on a "modular" architecture framework. This facilitates insertion of new technologies in the future, provides for flexibility, and facilitates the potential to "swap" modules based on compression requirements (quality, rate, etc.) of individual users.

The current schedule of activities for JPEG 2000 calls for a Draft International Standard (DIS) in November 1999, and a published International Standard available in November 2000. No format specification document exists at this time. Refer to the JPEG 2000 working group at www.ismc.nima.mil for additional information.

Multicomponent Joint Photographic Experts Group (JPEG) is being developed to provide support for multispectral, medical and color imagery as part of the JPEG 2000 effort. No format specification document exists at this time. Refer to the JPEG 2000 working group at www.ismc.nima.mil for additional information.

USIGS Status: Mandatory

Usage: MIL-STD 188-198A (JPEG) is the required lossy compression standard for 8-bit and 12-bit NITFS imagery within the USIGS and is required for all new or upgraded USIGS systems which exchange digital still imagery products and image related products.

MIL-STD-188-199, Vector Quantization Decompression for the National Imagery Transmission Format Standard, 27 June 1994 and NOTICE 1, 27 June 1996

Description: This standard describes the Vector Quantization (VQ) decompression algorithm for the National Imagery Transmission Format (NITF) file format and establishes its application within the NITFS. Vector Quantization (VQ) MIL-STD-188-199 is the mandated standard for decompressing NITF files compressed with VQ. Vector Quantization is a compression algorithm currently defined for multiband, color, and grayscale raster scanned maps and imagery. MIL-STD-188-199 establishes the requirements for the communication or interchange of image data in VQ compressed form.

Vector quantization is a lossy compression approach, chosen for use with certain types of image data because it can be implemented with acceptable performance and quality, because it provides a predictable compression ratio, and because decompression is very fast. The basic algorithm for the various types of imagery decompression is the same, and all information required for decompression of an NITF VQ file is contained within the NITF file itself.

USIGS Status: Mandatory

Usage: For all new or upgraded USIGS systems which exchange digital still imagery products and image related products. This standard is applicable to the IC and the DOD. VQ is mandatory for all Secondary Imagery Dissemination Systems (SIDS) in accordance with the memorandum by the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASD(C3I)). VQ compressed NITF files shall comply with MIL-STD-2500B and MIL-HDBK-1300A.

MIL-STD-188-196, Bi-Level Image Compression for the National Imagery Transmission Format Standard, 18 June 1993, and NOTICE 1, 27 June 1996

Description: This standard establishes the requirements to be met by NITFS systems when Still Image Data are compressed using the bi-level facsimile compression specified by the International Telecommunications Union (ITU) Telecommunication Standardization Sector (ITU-T) (formerly CCITT) Recommendation T.4 and MIL-STD-188-161C for Group 3 facsimile devices.

MIL-STD-188-196 establishes the requirements for the exchange of Still Image Data in compressed form. The bi-level compression standard may be operated in one of three modes:

mode 1 - one-dimensional coding
mode 2 - two-dimensional coding with standard vertical resolution, K = 2
mode 3 - two-dimensional coding with higher vertical resolution, K = 4

USIGS Status: Mandatory

Usage: Bi-level Image Compression, MIL-STD-188-196, is required for Bi-level (i.e., 1 bit per pixel, or black and white) lossless image compression as defined within the NITFS standard. MIL-STD-188-196 is mandatory for all Secondary Imagery Dissemination Systems in accordance with the memorandum by the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASD(C3I)). For image Data greater than one bit pixel, other NITFS specified compression algorithms should be used.

Description: ADDITION TO JTA. This standard establishes the requirements to be met by complying with NITFS systems when NITF 1.1 image data are compressed using the Adaptive Recursive Interpolated Differential Pulse Code Modulation (ARIDPCM) compression algorithm. ARIDPCM is a spatial compression algorithm currently defined for 8- and 11-bit gray scale images.

This standard provides technical detail of the NITFS compression algorithm designated by the code C2 in the image compression field of the image subheader, ARIDPCM, for both 8- and 11-bit gray scale imagery. It also provides the required default ARIDPCM quantization.

The ARIDPCM defined by this standard consists of three parts: the compressed data interchange format which defines the image data field of the NITF file format, the encoder, and the decoder. Two types of operation are specified by the acquisition authority.

Type 1 - 8-bit sample compression
Type 2 - 11-bit sample compression

USIGS Status: Mandatory

Usage: ARIDPCM, removed as a required compression for the NITF 2.1, is now only required for use with ingesting and decompressing legacy files (NITF 1.1). NITF 2.0 (MIL-STD-2500A) and NITF 2.1 (MIL-STD-2500B) requires all new or upgraded USIGS systems which exchange digital still imagery products and image related products to decompress using ARIDPCM for backward-compatibility with version 1.0 of the NITF standard.

(PROPOSED) NITF ISP of ISO/IEC International Standard 12087-5, NITF International Standardized Profile of Part 5: BASIC IMAGE INTERCHANGE FORMAT (BIIF )

Description: ADDITION TO JTA. THIS IS A PROPOSED STANDARD; NO FORMAL DOCUMENT EXISTS AT THIS TIME. BIIF is an international standard, approved on 1 December 1998, which provides a commercial/international foundation for interoperability in the interchange of imagery and imagery-related data among applications. BIIF provides a data format container for image, symbol, and text, along with a mechanism for including image-related support data.

As part of the 12087 family of image processing and interchange standards, BIIF conforms to the architectural and data object specifications of 12087-1, the Common Architecture for Imaging. BIIF supports a profiling scheme that is a combination of the approaches taken for 12087-2 (PIKS), 10918 (JPEG), 8632 (CGM), and 9973 (The Procedures for Registration of Graphical Items).

BIIF, the international version of NITF, is equivalent, but not identical, to NITF 2.1 (MIL-STD-2500B - See NITF 2.1 for more information). It is intended that profiles of the BIIF will be established as an International Standardized Profile (ISP) through the normal ISO processes (ISO/IEC TR 10000). A USIGS profile of BIIF, technically equivalent to the NITF 2.1 standard, will be created with the expectation that this profile will eventually supersede MIL-STD-2500B as a UTA mandate. This BIIF Profile will not require software upgrades in USIGS systems in order to maintain interoperability with the NITF MIL-STD. Refer to the National Imagery Transmission Format Standard (NITFS) Five Year Program Plan, Version 1.0, 1 July 1998 for more information on the BIIF profile development process.

USIGS Status: Emerging

Usage: N/A

STANAG No. 4545, Edition 1, 27 November 1998 NORTH ATLANTIC TREATY ORGANISATION (NATO) MILITARY AGENCY FOR STANDARDIZATION (MAS) STANDARDIZATION AGREEMENT (STANAG) SUBJECT: NATO Secondary Imagery Format (Format d' Imagerie Secondaire OTAN)

Description: ADDITION TO JTA. STANAG 4545 defines the NATO Secondary Imagery Format (NSIF), the NATO standard file format for imagery and imagery-related products. The NSIF provides a common standard for storage and interchange of images and associated data among existing and future systems and is the standard for formatting digital imagery files and imagery-related products and exchanging them among NATO members. The NSIF can be used to support interoperability by simultaneously providing a data format for shared access applications, while also serving as a Standard NSIF File Format for dissemination of images graphics, text, and associated data.

For the NSIF, the image data encompasses multispectral imagery and images intended to be displayed as monochrome (shades of grey), colour-mapped (pseudocolour), or true colour and may include grid or matrix data intended to provide additional geographic or geo-referencing information. Graphic data is used in the NSIF to store two-dimensional information represented as a CGM. The graphic format is CGM as described in ISO/IEC 8632-1. The precise tailoring of the CGM standard to NSIF is found in MIL-STD-2301A.

Among NATO nations, many kinds of systems are used for the reception, transmission, storage, and processing of images, graphics, text, and other associated data. Without special efforts, the NSIF File Format used in one system is likely to be incompatible with the format of another system. Since each system may use a unique, internal data representation, a common format for exchange of information across systems is needed for interoperability of systems within and among NATO nations.

When systems use other than NSIF as an internal imagery format, each system will have to translate between the system's internal representation for files, and the NSIF File Format. A system from which imagery data is to be transferred is envisioned to have a translation module that accepts information, structured according to the system's internal representation for images, graphics, text, and other associated data, and assembles this information into one file in the Standard NSIF File Format. Then the NSIF File will be exchanged with one or more recipients. Each of the receiving systems will translate the data from the NSIF File into its internal format.

NOTE: With the addition of the MIL-STD-2500B, NITF 2.1 Notice 1, 2 October 1998 and the approval of STANAG 4545, Edition 1, the NITF 2.1 standard and NATO STANAG 4545 (NSIF) are technically equivalent.

USIGS Status: Emerging

Usage: The NSIF will be used for transmission and storage of Secondary Imagery within and among NATO C3I nodes.

ICHIPB Support Data Extensions for the National Imagery Transmission Format, 16 November 1998

Description: ADDITION TO JTA. ICHIPB is a system-independent NITF Support Data Extension (SDE) that, when included with NITF image chips, will support the USIGS mensuration of image chips. The ICHIPB NITF SDE supports the generation of required data for imagery mensuration for exploiters of non-dewarped imagery chips. The ICHIPB holds the support data that analysts need when using imagery software to mensurate or determine detailed geospatial parameters on pixel based features within image chips. There is no mechanism in the standard NITF format to pass a standardized set of data with an image chip such that a user can easily apply imagery software to that image.

The proposed ICHIPB SDE is an attempt to standardize the solution so that any recipient of an image, regardless of system or application, will be able to access the necessary mensuration support data and exploit the image chip in a uniform and consistent manner.

ICHIPB will be incorporated into the next published version of The Compendium of Controlled Extensions (CE) for the National Imagery Transmission Format (NITF).

USIGS Status: Mandatory

Usage: This standard is only applicable to a subset of the USIGS: For systems which produce, disseminate, or use National Technical Means (NTM), Tactical/Airborne imagery, or Commercial Satellite imagery ONLY. To maintain interoperability within the USIGS, ICHIPB should be included with all non-dewarped NITF chips, specifically when the chip is disseminated. It is recommended that it not be included with dewarped images. NITF receiving systems will be expected to read and interpret the information within ICHIPB if they have requirements to mensurate on the received image chip.

NITF Profile for Imagery Access Extensions (PIAE) 3.0, 25 September 1997, as documented in the Section 6 of the Compendium of Controlled Extensions (CE) for the National Imagery Transmission Format (NITF), Version 1.0, 25 August 1998

Description: ADDITION TO JTA. This support extension is designed to provide an area to place fields not currently carried in NITF but which were documented in the now superseded Standards Profile for Imagery Access (SPIA). This extension was developed to align the SPIA and NITF for product information, and adds descriptive detail associated with products.

USIGS Status: Mandatory

Usage: This standard is only applicable to a subset of the USIGS: For new or upgraded USIGS systems which produce, disseminate, or use National Technical Means (NTM), Tactical/Airborne imagery, or Commercial Satellite imagery using the NITFS suite of standards ONLY.

Synthetic Aperture Radar (SAR) Support Data Extensions (SDE) for the National Imagery Transmission Format Standard, 20 May 1996 as documented in Section 8 of the Compendium of Controlled Extensions (CE) for the National Imagery Transmission Format (NITF), Version 1.0, 25 August 1998

Description: ADDITION TO JTA. The SAR SDE describes specific tagged records which incorporate all Support Data Extensions relevant to primary imagery processed from Synthetic Aperture Radar (SAR) data.

SAR Related Support Data Extensions

AIMIDA Additional Image Identification
EXPLTA Exploitation Related Information
BLOCKA Image Block Information
SECTGA Secondary Targeting Info
MPDSRA Mensuration Data
MENSRA Airborne SAR Mensuration Data
ACFTA Aircraft Information
PATCHA Patch Information
MTIRPA Moving Target Information

USIGS Status: Mandatory

Usage: This standard is only applicable to a subset of the USIGS: For new and upgraded USIGS systems which produce, disseminate, or use Tactical/Airborne SAR imagery formatted according to NITF 2.X.

Visible, Infrared, and Multispectral Airborne Sensor Support Data Extensions (SDE), 25 September 1997, as documented in Section 10 of the Compendium of Controlled Extensions (CE) for the National Imagery Transmission Format (NITF), Version 1.0, 25 August 1998

Description: ADDITION TO JTA. This document specifies the format and content of a set of controlled tagged record extensions for the National Imagery Transmission Format (NITF v2.X) file format. These support data extensions are defined for use with visible (i.e., electro-optical (EO)), infrared (IR) and multispectral imagery (MSI) collected on airborne sensor platforms. The specified tagged records incorporate all Support Data Extensions (SDE) relevant to visible/infrared/multispectral/ hyperspectral (EO-IR-MSI-HSI) primary. However, the primary sources are not yet explicitly included. Systems using visible, or infrared imagery formatted according to NITF 2.X, obtained from airborne sensors, should be designed to extract the needed data from the tagged records.

Sensors collecting imagery also collect and report auxiliary data that uniquely identifies the imagery, defines the collection geometry, and contains other information to aid exploitation of that imagery. The extensions described herein define the format for that support information within a NITF 2.X file containing visible or infrared imagery.

USIGS Status: Mandatory

Usage: ADDITION TO JTA. This standard is only applicable to a subset of the USIGS: For new or upgraded USIGS systems which produce, disseminate, or use Tactical/Airborne imagery ONLY, having a requirement to support airborne EO-IR and multispectral imagery. These systems shall conform to the NITF 2.X standard, including the SDEs described in this section. Tactical Airborne sensor platforms collecting the imagery are excluded from this mandate.

HISTOA Softcopy History Tag, as documented in Section 15 of the Compendium of Controlled Extensions (CE) for the National Imagery Transmission Format (NITF), Version 1.0, 25 August 1998

Description: The purpose of the tag is to provide a history of the softcopy processing functions that have been applied to NITF imagery. Although the tag was originally designed for National System Imagery, it can also be used to record the softcopy processing history of airborne and commercial imagery, provided that the imagery is processed in a manner consistent with the Softcopy History Tag. Ideally, the tag would be created whenever a National, airborne, or commercial image is formatted in NITF and updated each time the image is processed and saved by a softcopy processing system.

USIGS Status: Mandatory

Usage: ADDITION TO JTA. For systems which produce, disseminate, or use National Technical Means (NTM) ONLY.

Commercial SDE, Version 0.9, 25 September 1997; as documented in Section 7 of The Compendium of Controlled Extensions (CE) for the National Imagery Format Transmission Format (NITF), Version 1.0, 25 August 1998

Description: This SDE documents a set of controlled tagged record extensions for the National Imagery Transmission Format (NITF v2.X) file format. These extensions describe the format for support information within a NITF 2.X file containing commercial imagery.

USIGS Status: Emerging

Usage: ADDITION TO JTA. For systems which produce, disseminate, or use Commercial Satellite Imagery ONLY. Primary collection systems are excluded from this mandate.

3.4.2.4 Motion Imagery/Video Data Interchange

Video is defined as Electro-Optical motion imagery technologies defined by standards developed by ISO, ITU, SMPTE, EBU, etc., reviewed, adopted and profiled for various applications. Video systems are further subdivided into (4) categories:

Video Imagery Systems
Video Teleconference Systems
Video Telemedicine Systems
Video Support Services

3.4.2.4.1 Video Imagery Data Interchange

Video Imagery Systems create, transmit, edit, store, archive or disseminate digital video for real-time, near-real time or for other end-user product distribution, usually in support of Intelligence, Surveillance, and Reconnaissance (ISR) activities. Video, and more specifically "video imagery," is classified as a subset of motion imagery in the DoD JTA and the UTA.

DoD/IC/USIGS Video Imagery Standards Profile (VISP), Version 1.3, 6 March 1998

Description: EXCEPTION TO JTA (LATER VERSION). The JTA 2.0 mandates 5 core standards from the VISP 1.21 and specifically omits VISP Profiles and Practices. The UTA mandates VISP 1.3, which includes the same base standards as the JTA, but also includes the Profiles and Practices NOT required by the JTA. Therefore, this mandate is additive to the existing JTA 2.0 mandate; it is non-conflicting.

The Video Imagery Standards Profile (VISP) 1.3 mandates the minimum set of standards and interoperability profiles for the acquisition of all DoD, Intelligence Community and IGC systems that produce, use, or exchange Video Intelligence information.

The VISP provides a consolidated, clear and concise view of the standards needed to build and operate Video Imagery systems within USIGS. The VISP includes guidance on uncompressed, compressed, and related video sampling structures; video time standards, video metadata standards, interconnections, and common language descriptions of video system parameters. All of the technology outlined in the VISP document is based on commercially available (or very near term available) systems and components based on defined Open Standards.

The VISP documents:

- Approved Commercial Standards, Interoperability Profiles and Recommended Practices for DoD/IC/USIGS implementations
- Emerging Standards, Profiles, and Recommended Practices that are still in Study Status
- Video System Description Recommended Practices that include both Approved and Study status elements.

Where the term Recommended Practice is used, the VISP item documents a recommended implementation or practice that further clarifies the implementation of a Standard or Profile in order to insure interoperability across DoD/IC/USIGS systems.

Where the term Study is used, the VISP identifies a preliminary version of an anticipated and or emerging Standard, Profile, or Recommended Practice where the primary initial parameters are outlined and understood but additional coordination or engineering analysis is required.

USIGS Status: Mandatory

Usage: All USIGS component systems that create, process, transmit, manipulate, exploit, store, archive and disseminate (both for real-time and other end-user wide area product distribution) video signals in support to Intelligence, Reconnaissance, and Surveillance (ISR) applications will comply with the Standards and Interoperability Profiles contained in VISP.

All USIGS video systems should also comply with VISP Recommended Practices if possible.

3.4.2.5 Distributed Computing Services

In the area of distributed computing, USIGS has designated CORBA 2.2 [CORBA98] as the environment in which it will deliver these services. The Technical Reference Model (TRM) discussion in Section 2 stresses a service-oriented software environment, a software component architecture, and interoperability through software re-use and standard interfaces. The appropriate CORBAservices and CORBAfacilities are identified and defined.

3.4.2.5.1 Remote Procedure Computing

Although the USIGS profile for distributed computing services profiles CORBA 2.2, there is current work developing interfaces between both DCE (which is based on remote procedure computing) and OLE/COM and CORBA.

3.4.2.5.2 Distributed Object Computing

The mandate for distributed object computing is interworking with the Object Management Group (OMG) Object Management Architecture (OMA), composed of the Common Object Request Broker Architecture (CORBA), CORBAservices, and CORBAfacilities.

CORBA - defines the interfaces and services for Object Request Brokers, including an Interface Definition Language (IDL) and the Internet Inter-ORB Protocol (IIOP).
CORBAservices - defines interfaces and semantics for services required to support distributed objects, such as naming, security, transactions, and events.
CORBAfacilities - defines interfaces and semantics for services required to support functions such as compound document manipulation.

The CORBA interoperability mandate does not preclude the use of other distributed object technologies, such as ActiveX/DCOM or Java, as long as the capability for interworking with CORBA applications and objects is maintained by the non-CORBA system. Interworking is the exchange of meaningful information between computing elements (semantic integration). Application Level Interworking, for CORBA, results in CORBA clients interacting with non-CORBA servers and non-CORBA clients interacting with CORBA servers. For OLE/COM, Application Level Interworking results in COM/OLE clients interacting with non-COM/OLE servers and non-COM/OLE clients interacting with COM/OLE servers. Products are available that allow interworking among distributed object techniques.

USIGS will comply with the DoD JTA in using CORBA and the associated Interface Definition Language (IDL) and Internet inter-ORB protocols (IIOP), but exceeding the JTA mandate by specifying the latest version of CORBA, version 2.2.

The Object Management Architecture describes the Object Request Broker (ORB), which allows objects to communicate over a distributed environment. There are also several categories of object interfaces, one of which is called Object Services (CORBAservices). These Object Services are interfaces which support general interfaces likely to be used in most programs which rely on distributed objects. Both the Joint Technical Architecture, in Section 2.2, and the UTA, in Section 3, address ORB and CORBAservices specifications. The remaining categories of object interfaces are part of the Application Software Entity and are addressed in Section 4 of the UTA.

3.4.2.5.2.1 Object Request Broker (CORBA)

OMG document formal/98-02-01, CORBA/IIOP 2.2, The Common Object Request Broker: Architecture and Specification

Description: EXCEPTION TO JTA (LATER VERSION). JTA 2.0 mandates CORBA 2.1. CORBA is a common object request broker architecture based on the Object Management Architecture use of object technologies. The architecture and specifications described CORBA/IIOP 2.2 are aimed at software designers and developers who want to produce applications that comply with OMG standards for the Object Request Broker (ORB) including an Interface Definition Language (IDL). As defined by the Object Management Group (OMG) in the Object Management Architecture Guide, the ORB provides the mechanisms by which objects transparently make requests and receive responses. The ORB provides interoperability between applications on different machines in heterogeneous distributed environments and seamlessly interconnects multiple object systems.

USIGS Status: Mandatory

Usage: All new or upgraded USIGS systems

OMG document orbos/98-04-01, Fault Tolerance Request for Proposal (RFP), April 3, 1998

Description: ORB Enhancement. The Fault Tolerance RFP addresses the need to standardize CORBA functions supporting fault tolerant applications, when clients of these applications will be isolated from details such as management of redundant copies, failure masking, and recovery. The RFP also addresses systems where the applications, or some third-party software, requests additional control over fault management.

USIGS Status: Emerging

Usage: N/A

OMG document orbos/96-08-01, IDL to Java Request for Proposal (RFP), August 1, 1996

Description: ORB Enhancement. This RFP requests technology that provides a Java language mapping for the OMG Interface Definition Language (IDL) specification language. The Java Mapping specification is to provide the ability to access and implement CORBA objects within programs written in Java.

Three separate Revised Submissions have been received to date.

USIGS Status: Emerging

Usage: N/A

OMG document orbos/97-03-08, Java to IDL Request for Proposal (RFP), January 19, 1998

Description: ORB Enhancement. The RFP addresses the need to enhance the CORBA Java language mapping with an Java-IDL mapping. A Java to IDL mapping will allow developers to build distributed applications directly in Java and communicate via IIOP.

USIGS Status: Emerging

Usage: N/A

OMG document orbos/96-03-16, Messaging Service Request for Proposal (RFP), March 7, 1996

Description: ORB Enhancement. RFP requests services or ORB enhancements designed to manage asynchronous messages in distributed object systems, including the ordering and quality of service of request.

Submissions have been received:

orbos/98-05-12, IDL files related to the Messaging Revised Submission, May 18, 1998
orbos/98-05-06, Revised Messaging RFP submission with changebars and attached errata explanation, May 18, 1998

USIGS Status: Emerging

Usage: N/A

OMG document orbos/96-01-04, Multiple Interfaces and Composition Request for Proposal (RFP), January 11, 1996

Description: ORB Enhancement. The RFP deals with the resolution of conflict between multiple IDL interfaces to the same object. The Composition facility will provide the means for objects to be composed of logically distinct services by the use of multiple interface definitions. Multiple Revised submissions have been received.

USIGS Status: Emerging

Usage: N/A

OMG document orbos/96-06-14, Objects by Value Request for Proposal (RFP)

Description: ORB Enhancement. This RFP seeks proposals for interfaces which provide for the passing of CORBA objects by value (rather than by reference) as parameters in CORBA object operations. Passing objects by value is more efficient and straightforward in many circumstances.

Revised Submissions:

orbos/98-01-18 (Joint Revised Objects-by-Value Submission with Errata), January 19, 1998
orbos/98-01-01 (Objects-by-Value Revised Submission), January 19, 1998

USIGS Status: Emerging

Usage: N/A

OMG document orbos/97-12-26, Tagged Data Request for Proposal

Description: ORB Enhancement. The RFP requests the development of a specification for a tagged data capability that supports arbitrary items of data of in-memory size, where each data value is tagged for identification. The goal is to develop an interface that will provide a standardized way of creating, accessing, updating, and manipulating these arbitrary data structures or objects.

USIGS Status: Emerging

Usage: N/A

3.4.2.5.2.2 Object Services (CORBAServices)

CORBA is a common object request broker architecture based on the Object Management Architecture use of object technologies. The object services associated with CORBA 2.2 are commonly referred to as CORBAservices and are a collection of services (interfaces and objects) that support basic functions for using and implementing objects. CORBAservices are described in the CORBAservices: Common Object Services Specification, November 1997 document. CORBAservices are necessary to construct any distributed application and are always independent of application domains. The interface designs of all the services are general in nature and do not require specific supporting software in order to implement. Each specification of an Object Service usually consists of a set of interfaces and a description of the service's behavior.

The CORBAservices summarized include:

Mandatory:

Naming Service, Licensing Service, Event Service, Property Service, Transaction Service, Query Service, Object Collections, Relationship Service, Concurrency Control Service, Security Service, Externalization Service, Time Service, Life Cycle Service, Trading Object Service

Emerging:

DCE/CORBA Interworking, Persistent State Service 2.0, Firewall RFP, Interoperable Name Service, Fault Tolerance

Each CORBA Services document, description, and their USIGS status is provided below:

OMG document formal/97-12-10, CORBAservices Naming Service

Description: EXCEPTION TO JTA (LATER VERSION). The 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.

USIGS Status: Mandatory

Usage: All new or upgraded USIGS systems

OMG document formal/97-12-11, CORBAservices Event Service

Description: EXCEPTION TO JTA (LATER VERSION). The Event Service supports Asynchronous events and reliable event delivery.

USIGS Status: Mandatory

Usage: All new or upgraded USIGS systems

OMG document formal/97-12-17, CORBAservices Transaction Service

Description: EXCEPTION TO JTA (LATER VERSION). The Object Transaction Service supports interoperability between different programming models. For instance, some users want to add object implementations to existing procedural applications and to augment object implementations with code that uses the procedural paradigm. To do so in a transaction environment requires the object and procedural code to share a single transaction. The Transaction Service supports multiple transaction models, including the flat (mandatory in the specification) and nested (optional) models.

USIGS Status: Mandatory

Usage: All new or upgraded USIGS systems

OMG document formal/97-12-24, CORBAservices Object Collections Service

Description: ADDITION TO JTA. Collections are groups of objects which, as a group, support some operations and exhibit specific behaviors that are related to the nature of the collection rather than to the type of object they contain. Examples of collections are sets, queues, stacks, lists, and binary trees. The purpose of the Object Collections Service is to provide a uniform way to create and manipulate the most common collections generically.

USIGS Status: Mandatory

Usage: All new or upgraded USIGS systems

OMG document formal/97-12-14, CORBAservices Concurrency Control Service

Description: ADDITION TO JTA. The Concurrency Control Service enables multiple clients to coordinate their access to shared resources. Coordinating access to a resource 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.

USIGS Status: Mandatory

Usage: All new or upgraded USIGS systems

OMG document formal/97-12-15, CORBAservices Externalization Service

Description: ADDITION TO JTA. The Externalization Service defines protocols and conventions for externalizing and internalizing objects. Externalizing an object is to record the object state in a stream of data (in memory, on a disk file, across the network, and so forth) and then be internalized into a new object in the same or a different process. The externalized object can exist for arbitrary amounts of time, be transported by means outside of the ORB, and be internalized in a different, disconnected ORB. For portability, clients can request that externalized data be stored in a file whose format is defined with the Externalization Service Specification.

USIGS Status: Mandatory

Usage: All new or upgraded USIGS systems

OMG document formal/97-12-13, CORBAservices Life Cycle Service

Description: ADDITION TO JTA. The Life Cycle Service defines conventions for creating, deleting, copying and moving objects.

USIGS Status: Mandatory

Usage: All new or upgraded USIGS systems

OMG document formal/97-12-19, CORBAservices Licensing Service

Description: ADDITION TO JTA. The Licensing Service provides a mechanism for producers to control the use of their intellectual property. Producers can implement the Licensing Service as needed, because the Licensing Service does not impose its own business policies or practices.

USIGS Status: ;Mandatory

Usage: All new or upgraded USIGS systems

OMG document formal/97-12-20, CORBAservices Property Service

Description: ADDITION TO JTA. Property Service provides the ability to dynamically associate named values with objects outside the static IDL-type system.

USIGS Status: Mandatory

Usage: All new or upgraded USIGS systems

OMG document formal/97-12-18, CORBAservices Query Service

Description: ADDITION TO JTA. The Query Service allows users and objects to invoke queries on collections of other objects. These queries are declarative statements with predicates and include the ability to: specify values of attributes; to invoke arbitrary operations; and to invoke other Object Services. The Query Service allows indexing and correlates well to the query mechanisms used in database systems and other systems that store and access large collections of objects.

USIGS Status: Mandatory

Usage: All new or upgraded USIGS systems

OMG document formal/97-12-16, CORBAservices Relationship Service

Description: ADDITION TO JTA. The Relationship Service allows entities and relationships to be explicitly represented. Entities are represented as CORBA objects. This Service defines two new kinds of objects: relationships and roles. A role represents a CORBA object in a relationship. The Relationship interface can be extended to add relationship-specific attributes and operations. In addition, relationships of arbitrary degree can be defined. Similarly, the Role interface can be extended to add role-specific attributes and operations.

USIGS Status: Mandatory

Usage: All new or upgraded USIGS systems

OMG documents formal/97-12-22, CORBAservices Security Service

Description: ADDITION TO JTA. The Security Service supports:

• Identification and authentication of human users, and objects, which need to operate under their own rights to verify who they claim to be.
• Authorization and access control - deciding whether a principal can access an object, normally using the identity and/or other privilege attributes of the principal (such as role, groups, security clearance) and the control attributes of the target object (stating which principals, or principals with which attributes) can access it.
• Security auditing to make users accountable for their security related actions. Auditing mechanisms should be able to identify the user correctly, even after a chain of calls through many objects.

USIGS Status: Mandatory

Usage: All new or upgraded USIGS systems

OMG document formal/97-12-21, CORBAservices Time Service

Description: ADDITION TO JTA. Time Service enables the user to obtain current time together with an error estimate associated with it. The Time Service also ascertains the order in which "events" occurred, generates time-based events based on timers and alarms, and computes the interval between two events.

USIGS Status: Mandatory

Usage: All new or upgraded USIGS systems

OMG document formal/97-12-23, CORBAservices Trading Object Service

Description: ADDITION TO JTA. The Trading Object Service provides a matchmaking service for objects. The Service Provider registers the availability of the service by invoking an export operation on the trader, passing as parameters information about the offered service. The export operation carries an object reference that can be used by a client to invoke operations on the advertised services, a description of the type of the offered service (i.e., the names of the operations to which it will respond, along with their parameter and result types), information on the distinguishing attributes of the offered service.

USIGS Status: Mandatory

Usage: All new or upgraded USIGS systems

OMG document orbos/98-05-10, CORBAservices Persistent State Service 2.0

Description: ADDITION TO JTA. The Persistent State Service provides a set of common interfaces to the mechanisms used for retaining and managing the persistent state of objects.

This specification is proposed to replace the earlier, approved Persistent Object Service (POS). The POS, adopted 3 years ago, could not be implemented due to major flaws.

USIGS Status: Emerging

Usage: N/A

OMG document orbos/98-06-01, CORBAservices DCE/CORBA Interworking Service

Description: ADDITION TO JTA. The DCE/CORBA Interworking Service provides CORBA objects with access to DCE application servers and the standard DCE CDS (Cell Directory Service). The service may be used for CORBA clients since there is no requirement for clients to have non-CORBA capabilities in order to use the Interworking Service.

USIGS Status: Emerging

Usage: N/A

OMG document orbos/98-05-04, CORBAservices CORBA/Firewall Security

Description: ADDITION TO JTA. The CORBA/Firewall Security service describes changes to CORBA that are needed for ORBS to function in a modified manner so that CORBA communications can be handled by firewalls. The service also describes how current firewall techniques can be used to control CORBA communications. It adds to CORBA new data elements that provide clients, firewalls, and servers additional needed for firewall traversal and also defines the CORBA interfaces that can be used with CORBA software to provide information to a firewall.

USIGS Status: Emerging

Usage: N/A

OMG document orbos/98-03-04, CORBAservices Interoperable Naming Service

Description: ADDITION TO JTA. See CORBAservices Naming Service specification described earlier. This document is expected to eventually supersede the CORBAservices Naming Service specification.

USIGS Status: Emerging

Usage: N/A

3.4.3 Information Transfer Standards

The UTA contains Additions, but no Exceptions to JTA mandated and emerging standards for Section 2.3.

3.4.3.1 Secondary Imagery Dissemination Communications

MIL-STD-2045-44500, National Imagery Transmission Format Standard (NITFS) Tactical Communications Protocol 2 (TACO2), 18 June 1993; with Notice of Change 1, 29 July 1994, and Notice of Change 2, 27 June 1996

Description: The Tactical Communications Protocol 2 (TACO2) is the communications component of the National Imagery Transmission Format Standard (NITFS) suite of standards used to disseminate secondary imagery. TACO2 is used over point-to-point tactical data links in high BER disadvantaged communications environments.

USIGS Status: Mandatory

Usage: TACO2 is used to transfer secondary imagery and related products where JTA transfer protocols are not applicable (e.g., TACO2 only applies to users having simplex and half-duplex links as their only means of communications).

Defense Information System Network (DISN) Asynchronous Transfer Mode (ATM) System Specification, Version 1.2c, 17 April 1998

Description: ADDITION TO JTA. This specification describes and defines subsystems, functions, interface requirements and performance requirements for DISN ATM subsystems to support services via a DISN ATM infrastructure. The document is intended as guidance for acquiring or leasing functional subsystems and/or component elements of the DISN. ATM is a high-speed switched data transport technology that takes advantage of primarily low bit error rate transmission media to accommodate intelligent multiplexing of voice, data, video, imagery, and composite inputs over high-speed trunks and dedicated user links. Asynchronous Transfer Mode (ATM) is a transfer mode in which information is organized into cells and is asynchronous in the sense that the recurrence of cells containing information from an individual user is not necessarily periodic.

For all other applications (non-DISN), refer to the DoD JTA ATM standards.

USIGS Status: Mandatory

Usage: This standard is only applicable to a subset of the USIGS: For new or emerging USIGS systems with an interface to DISN.

DoD ATM Standards, (version 1.0), 17 April, 1998

Description: ADDITION TO JTA. This specification is an approved profile of ATM standards for DISN and systems interfacing with DISN ONLY. In order to support DoD and other systems interfacing with the DISN, DISA mandates the standards in this document for major interfaces and ATM applications identified within. This document specifies minimum standards and requirements for DISN ATM systems, equipment, and services for the interfaces and the applications.

For all other applications (non-DISN), refer to the DoD JTA ATM standards.

USIGS Status: Mandatory

Usage: This standard is only applicable to a subset of the USIGS: For new or emerging USIGS systems with an interface to DISN.

3.4.4 Information Modeling, Metadata, and Information Exchange Standards

There are no UTA Section 3 exceptions or additions to JTA Mandated or Emerging standard(s) in JTA Section 2.4. USIGS developers will comply with the JTA for these services. However, USIGS Data Modeling and Metadata standards are addressed in Section 5 as UTA Conventions.

3.4.5 Human-Computer Interface Standards

There are no additions or exceptions to JTA Mandated Standard(s) in JTA Section 2.5. However, there are additions to the Emerging standards. USIGS developers will refer to the JTA mandates for this service area. See [JTA98] Section 2.5.

MIL-STD-2525A, Common Warfighting Symbology, 15 December, 1996 with NOTICE 1, 10 July 1997

Description: MIL-STD-2525A is the standard symbol set for all future DoD C4I Warrior symbology applications. The symbol set is compliant with the Computer Graphics Metafile (CGM) standard. The CGM provides a file format suitable for the storage and retrieval of picture information. The file format consists of a set of elements that can be used to describe pictures in a way that is compatible between systems of different architectures and devices of differing capabilities and design.

USIGS Status: Mandatory

Usage: All new or upgraded DoD systems

MIL-PRF-89045, DoD Performance Specification Geospatial Symbols for Digital Displays (GeoSym™) DRAFT, 20 February 1998

Description: ADDITION TO JTA. This specification defines the format and content of the symbol graphics and symbol assignment tables that comprise the Geospatial Symbols for Digital Displays products. GeoSym™ symbols were created for use with Vector Product Format (VPF™) products. However, GeoSym™ symbols may be used to display many types of digital data, not only VPF™. GeoSym™ was compiled from hundreds of symbols in existing paper and digital symbology standards and are rendered in Computer Graphics Metafile (CGM) format, using the ISO CGM specification. GeoSym™ was designed to complement the symbols in Common Warfighting Symbology, MIL-STD-2525A. The current draft version of GeoSym™ is intended to support the symbolization of the following VPF™ products:

Usage: N/A

3.4.6 Information System Security Standards

There are no UTA exceptions or additions to JTA Mandated or Emerging standard(s) in JTA Section 2.6. USIGS developers will refer to the JTA for this service area. See [JTA98] Section 2.6.