FGDC-STD-002.5-1999

##   {#section .TOC-2}

##  {#section-1 .TOC-2}

##  {#section-2 .TOC-2}

## Spatial Data Transfer Standard (SDTS) {#spatial-data-transfer-standard-sdts .TOC-2}

## Part 5: Raster Profile and Extensions {#part-5-raster-profile-and-extensions .TOC-2}

#  {#section-3 .TOC-1}

Subcommittee on Base Cartographic Data

Federal Geographic Data Committee

February 1999

Federal Geographic Data Committee

Established by Office of Management and Budget Circular A‑16, the
Federal Geographic Data Committee (FGDC) promotes the coordinated
development, use, sharing, and dissemination of geographic data.

The FGDC is composed of representatives from the Departments of
Agriculture, Commerce, Defense, Energy, Housing and Urban Development,
the Interior, State, and Transportation; the Environmental Protection
Agency; the Federal Emergency Management Agency; the Library of
Congress; the National Aeronautics and Space Administration; the
National Archives and Records Administration; and the Tennessee Valley
Authority. Additional Federal agencies participate on FGDC subcommittees
and working groups. The Department of the Interior chairs the committee.

FGDC subcommittees work on issues related to data categories coordinated
under the circular. Subcommittees establish and implement standards for
data content, quality, and transfer; encourage the exchange of
information and the transfer of data; and organize the collection of
geographic data to reduce duplication of effort. Working groups are
established for issues that transcend data categories.

For more information about the committee, or to be added to the
committee\'s newsletter mailing list, please contact:

Federal Geographic Data Committee Secretariat

c/o U.S. Geological Survey

590 National Center

Reston, Virginia 22092

Telephone: (703) 648-5514

Facsimile: (703) 648-5755

Internet (electronic mail): gdc@usgs.gov

Anonymous FTP: ftp://www.fgdc.gov/pub/gdc/

World Wide Web: http://www.fgdc.gov

#  CONTENTS {#contents .TOC-1}

Page

# SDTS PART 5: RASTER PROFILE and EXTENSIONS [1](#sdts-part-5-raster-profile-and-extensions) {#sdts-part-5-raster-profile-and-extensions-1 .TOC-1}

### 1.1 Introduction [1](#introduction) {#introduction-1 .TOC-3}

#### 1.1.1 Objective [2](#objective) {#objective-2 .TOC-4}

#### 1.1.2 Scope [2](#scope) {#scope-2 .TOC-4}

#### 1.1.3 Applicability [2](#applicability) {#applicability-2 .TOC-4}

#### 1.1.4 Related and Referenced Standards [3](#related-and-referenced-standards) {#related-and-referenced-standards-3 .TOC-4}

##### 1.1.4.1 Referenced Standards [3](#referenced-standards) {#referenced-standards-3 .TOC-5}

#### 1.1.5 Standards Development Procedures [3](#standards-development-procedures) {#standards-development-procedures-3 .TOC-4}

#### 1.1.6 Maintenance Authority [4](#maintenance-authority) {#maintenance-authority-4 .TOC-4}

### 1.2 Conformance and Testing [4](#conformance-and-testing) {#conformance-and-testing-4 .TOC-3}

#### 1.2.1 Transfer Conformance [4](#transfer-conformance) {#transfer-conformance-4 .TOC-4}

#### 1.2.2 Encoder Conformance [4](#encoder-conformance) {#encoder-conformance-4 .TOC-4}

#### 1.2.3 Decoder Conformance [5](#decoder-conformance) {#decoder-conformance-5 .TOC-4}

## 2 Raster Data Concepts [5](#raster-data-concepts) {#raster-data-concepts-5 .TOC-2}

### 2.1 Spatial Objects [5](#spatial-objects) {#spatial-objects-5 .TOC-3}

### 2.2 Multiple Raster Objects, Layers, and Partitions [6](#multiple-raster-objects-layers-and-partitions) {#multiple-raster-objects-layers-and-partitions-6 .TOC-3}

### 2.3 Non-ragged Grids [6](#non-ragged-grids) {#non-ragged-grids-6 .TOC-3}

### 2.4 Nongeospatial Dimensions [6](#nongeospatial-dimensions) {#nongeospatial-dimensions-6 .TOC-3}

### 2.5 Raster Scan Reference System [7](#raster-scan-reference-system) {#raster-scan-reference-system-7 .TOC-3}

### 2.6 Band Interleaving (Cell Sequencing Code) [7](#band-interleaving-cell-sequencing-code) {#band-interleaving-cell-sequencing-code-7 .TOC-3}

### 2.7 Warped Grid Raster [7](#warped-grid-raster) {#warped-grid-raster-7 .TOC-3}

### 2.8 Tesseral Indexing/Blocking [8](#tesseral-indexingblocking) {#tesseral-indexingblocking-8 .TOC-3}

### 2.9 Compression [8](#compression) {#compression-8 .TOC-3}

## 3 Spatial Data Quality [8](#spatial-data-quality) {#spatial-data-quality-8 .TOC-2}

### 3.1 Lineage [8](#lineage) {#lineage-8 .TOC-3}

### 3.2 Positional Accuracy [9](#positional-accuracy) {#positional-accuracy-9 .TOC-3}

### 3.3 Attribute Accuracy [9](#attribute-accuracy) {#attribute-accuracy-9 .TOC-3}

### 3.4 Logical Consistency [9](#logical-consistency) {#logical-consistency-9 .TOC-3}

### 3.5 Completeness [10](#completeness) {#completeness-10 .TOC-3}

## 4 General Specification [10](#general-specification) {#general-specification-10 .TOC-2}

### 4.1 Standard Module Names [10](#standard-module-names) {#standard-module-names-10 .TOC-3}

### 4.2 Order of Records, Fields, and Subfields within Modules [11](#order-of-records-fields-and-subfields-within-modules) {#order-of-records-fields-and-subfields-within-modules-11 .TOC-3}

### 4.3 Spatial Reference System [11](#spatial-reference-system) {#spatial-reference-system-11 .TOC-3}

#### 4.3.1 External Spatial Reference Conformance Level [12](#external-spatial-reference-conformance-level) {#external-spatial-reference-conformance-level-12 .TOC-4}

#### 4.3.2 Internal Representation of Spatial Addresses [12](#internal-representation-of-spatial-addresses) {#internal-representation-of-spatial-addresses-12 .TOC-4}

#### 4.3.3 Restrictions on X and Y Subfields [13](#restrictions-on-x-and-y-subfields) {#restrictions-on-x-and-y-subfields-13 .TOC-4}

### 4.4 NULL (and Like) Values [13](#null-and-like-values) {#null-and-like-values-13 .TOC-3}

### 4.5 Attributes [13](#attributes) {#attributes-13 .TOC-3}

### 4.6 Relationships between Modules and Raster Objects [14](#relationships-between-modules-and-raster-objects) {#relationships-between-modules-and-raster-objects-14 .TOC-3}

## 5 Transfer Module Specification [14](#transfer-module-specification) {#transfer-module-specification-14 .TOC-2}

### 5.1 Global Information Modules [15](#global-information-modules) {#global-information-modules-15 .TOC-3}

#### 5.1.1 Module Restrictions/Requirements: Identification Module [15](#module-restrictionsrequirements-identification-module) {#module-restrictionsrequirements-identification-module-15 .TOC-4}

#### 5.1.2 Module Restrictions/Requirements: Catalog/Directory [16](#module-restrictionsrequirements-catalogdirectory) {#module-restrictionsrequirements-catalogdirectory-16 .TOC-4}

#### 5.1.3 Module Restrictions/Requirements: Catalog/Spatial Domain [16](#module-restrictionsrequirements-catalogspatial-domain) {#module-restrictionsrequirements-catalogspatial-domain-16 .TOC-4}

#### 5.1.4 Module Restrictions/Requirements: Internal Spatial Reference [16](#module-restrictionsrequirements-internal-spatial-reference) {#module-restrictionsrequirements-internal-spatial-reference-16 .TOC-4}

#### 5.1.5 Module Restrictions/Requirements: External Spatial Reference [17](#module-restrictionsrequirements-external-spatial-reference) {#module-restrictionsrequirements-external-spatial-reference-17 .TOC-4}

### 5.2 Data Quality Modules [17](#data-quality-modules) {#data-quality-modules-17 .TOC-3}

### 5.3 Attribute Modules [17](#attribute-modules) {#attribute-modules-17 .TOC-3}

### 5.4 Composite Modules [18](#composite-modules) {#composite-modules-18 .TOC-3}

### 5.5 Vector Modules [18](#vector-modules) {#vector-modules-18 .TOC-3}

### 5.6 Raster Modules [18](#raster-modules) {#raster-modules-18 .TOC-3}

#### 5.6.1 Module Restrictions/Requirements: Raster Definition [18](#module-restrictionsrequirements-raster-definition) {#module-restrictionsrequirements-raster-definition-18 .TOC-4}

##### 5.6.1.1 Specific Subfield Restrictions: [18](#specific-subfield-restrictions) {#specific-subfield-restrictions-18 .TOC-5}

#### 5.6.2 Module Restrictions/Requirements: Layer Definition [18](#module-restrictionsrequirements-layer-definition) {#module-restrictionsrequirements-layer-definition-18 .TOC-4}

##### 5.6.2.1 Specific Subfield Restrictions: [19](#specific-subfield-restrictions-1) {#specific-subfield-restrictions-19 .TOC-5}

#### 5.6.3 Module Restrictions/Requirements: Cell [19](#module-restrictionsrequirements-cell) {#module-restrictionsrequirements-cell-19 .TOC-4}

##### 5.6.3.1 Specific Subfield Restrictions/Requirements: [19](#specific-subfield-restrictionsrequirements) {#specific-subfield-restrictionsrequirements-19 .TOC-5}

### 5.7 Graphic Representation Module [20](#graphic-representation-module) {#graphic-representation-module-20 .TOC-3}

## 6 ISO 8211 Specific Decisions [20](#iso-8211-specific-decisions) {#iso-8211-specific-decisions-20 .TOC-2}

### 6.1 Objective [20](#objective-1) {#objective-20 .TOC-3}

### 6.2 Relationship of Modules to ISO 8211 Files [20](#relationship-of-modules-to-iso-8211-files) {#relationship-of-modules-to-iso-8211-files-20 .TOC-3}

### 6.3 Media [20](#media) {#media-20 .TOC-3}

### 6.4 Organization of Files on Media [20](#organization-of-files-on-media) {#organization-of-files-on-media-20 .TOC-3}

### 6.5 File Names [21](#file-names) {#file-names-21 .TOC-3}

### 6.6 Taking Advantage of Dropped Leader and Directory [22](#taking-advantage-of-dropped-leader-and-directory) {#taking-advantage-of-dropped-leader-and-directory-22 .TOC-3}

### 6.7 ISO 8211 DDR Contents [22](#iso-8211-ddr-contents) {#iso-8211-ddr-contents-22 .TOC-3}

### 6.8 Use of Data Types for Cell Values [22](#use-of-data-types-for-cell-values) {#use-of-data-types-for-cell-values-22 .TOC-3}

### 6.9 Use of Character Data Type for Dates [23](#use-of-character-data-type-for-dates) {#use-of-character-data-type-for-dates-23 .TOC-3}

### 6.10 README File [23](#readme-file) {#readme-file-23 .TOC-3}

# ANNEX A: SDTS BIIF EXTENSION [24](#annex-a-sdts-biif-extension) {#annex-a-sdts-biif-extension-24 .TOC-1}

## 1 Introduction [24](#introduction-2) {#introduction-24 .TOC-2}

### 1.1 References [24](#references) {#references-24 .TOC-3}

### 1.2 Background of BIIF *(Informative)* [25](#background-of-biif-informative) {#background-of-biif-informative-25 .TOC-3}

## 2 BIIF Restrictions/Requirements [25](#biif-restrictionsrequirements) {#biif-restrictionsrequirements-25 .TOC-2}

### 2.1 BIIF Standard Data Types [26](#biif-standard-data-types) {#biif-standard-data-types-26 .TOC-3}

### 2.2 Two Dimensions [26](#two-dimensions) {#two-dimensions-26 .TOC-3}

### 2.3 BIIF Data Extensions [26](#biif-data-extensions) {#biif-data-extensions-26 .TOC-3}

#### 2.3.1 Geospatial Support Data Extension Segment [26](#geospatial-support-data-extension-segment) {#geospatial-support-data-extension-segment-26 .TOC-4}

#### 2.3.2 Lineage-related Tagged Record Extensions [27](#lineage-related-tagged-record-extensions) {#lineage-related-tagged-record-extensions-27 .TOC-4}

### 2.4 Compression [27](#compression-1) {#compression-27 .TOC-3}

### 2.5 BIIF File Header [27](#biif-file-header) {#biif-file-header-27 .TOC-3}

### 2.6 BIIF Image Subheader [27](#biif-image-subheader) {#biif-image-subheader-27 .TOC-3}

## 3 SDTS Restrictions/Requirements [27](#sdts-restrictionsrequirements) {#sdts-restrictionsrequirements-27 .TOC-2}

### 3.1 SDTS Restrictions/Requirements: Identification Module [28](#sdts-restrictionsrequirements-identification-module) {#sdts-restrictionsrequirements-identification-module-28 .TOC-3}

### 3.2 SDTS Restrictions/Requirements: Catalog/Directory Module [28](#sdts-restrictionsrequirements-catalogdirectory-module) {#sdts-restrictionsrequirements-catalogdirectory-module-28 .TOC-3}

### 3.3 SDTS Restrictions/Requirements: Catalog/Cross-Reference Module [28](#sdts-restrictionsrequirements-catalogcross-reference-module) {#sdts-restrictionsrequirements-catalogcross-reference-module-28 .TOC-3}

### 3.4 SDTS Restrictions/Requirements: External Spatial Reference Module [28](#sdts-restrictionsrequirements-external-spatial-reference-module) {#sdts-restrictionsrequirements-external-spatial-reference-module-28 .TOC-3}

### 3.5 SDTS Restrictions/Requirements: Data Dictionary/Schema Module [29](#sdts-restrictionsrequirements-data-dictionaryschema-module) {#sdts-restrictionsrequirements-data-dictionaryschema-module-29 .TOC-3}

### 3.6 SDTS Restrictions/Requirements: Data Quality Modules [29](#sdts-restrictionsrequirements-data-quality-modules) {#sdts-restrictionsrequirements-data-quality-modules-29 .TOC-3}

### 3.7 SDTS Restrictions/Requirements: Raster Definition Module [29](#sdts-restrictionsrequirements-raster-definition-module) {#sdts-restrictionsrequirements-raster-definition-module-29 .TOC-3}

### 3.8 SDTS Restrictions/Requirements: Layer Definition Module [29](#sdts-restrictionsrequirements-layer-definition-module) {#sdts-restrictionsrequirements-layer-definition-module-29 .TOC-3}

### 3.9 SDTS Restrictions/Requirements: Cell Module [29](#sdts-restrictionsrequirements-cell-module) {#sdts-restrictionsrequirements-cell-module-29 .TOC-3}

### 3.10 File Naming Convention [29](#file-naming-convention) {#file-naming-convention-29 .TOC-3}

# ANNEX B: COLOR INDEX MODULE OPTION [30](#annex-b-color-index-module-option) {#annex-b-color-index-module-option-30 .TOC-1}

## 1 Introduction [30](#introduction-3) {#introduction-30 .TOC-2}

## 2 SDTS Restrictions/Requirements [30](#sdts-restrictionsrequirements-1) {#sdts-restrictionsrequirements-30 .TOC-2}

### 2.1 Module Restrictions/Requirements: Identification Module [30](#module-restrictionsrequirements-identification-module-1) {#module-restrictionsrequirements-identification-module-30 .TOC-3}

### 2.2 Module Restrictions/Requirements: Catalog/Cross-reference Module [30](#module-restrictionsrequirements-catalogcross-reference-module) {#module-restrictionsrequirements-catalogcross-reference-module-30 .TOC-3}

### 2.3 Module Restrictions/Requirements: Color Index Module [31](#module-restrictionsrequirements-color-index-module) {#module-restrictionsrequirements-color-index-module-31 .TOC-3}

#### 2.3.1 Color Index Module Names [31](#color-index-module-names) {#color-index-module-names-31 .TOC-4}

# ANNEX C: COMPRESSED RASTER OPTION [32](#annex-c-compressed-raster-option) {#annex-c-compressed-raster-option-32 .TOC-1}

## 1 Introduction [32](#introduction-4) {#introduction-32 .TOC-2}

### 1.1 References [32](#references-1) {#references-32 .TOC-3}

## 2 Compression Methods [32](#compression-methods) {#compression-methods-32 .TOC-2}

### 2.1 Run Length Encoding Compression [32](#run-length-encoding-compression) {#run-length-encoding-compression-32 .TOC-3}

### 2.2 JPEG Compression in JFIF [32](#jpeg-compression-in-jfif) {#jpeg-compression-in-jfif-32 .TOC-3}

### 2.3 Decompression Support [33](#decompression-support) {#decompression-support-33 .TOC-3}

## 3 SDTS Restrictions/Requirements [33](#sdts-restrictionsrequirements-2) {#sdts-restrictionsrequirements-33 .TOC-2}

### 3.1 SDTS Restrictions/Requirements: Identification Module [33](#sdts-restrictionsrequirements-identification-module-1) {#sdts-restrictionsrequirements-identification-module-33 .TOC-3}

### 3.2 SDTS Restrictions/Requirements: Catalog/Directory Module [33](#sdts-restrictionsrequirements-catalogdirectory-module-1) {#sdts-restrictionsrequirements-catalogdirectory-module-33 .TOC-3}

### 3.3 SDTS Restrictions/Requirements: Data Dictionary Modules [33](#sdts-restrictionsrequirements-data-dictionary-modules) {#sdts-restrictionsrequirements-data-dictionary-modules-33 .TOC-3}

### 3.4 SDTS Restrictions/Requirements: Data Quality Modules [34](#sdts-restrictionsrequirements-data-quality-modules-1) {#sdts-restrictionsrequirements-data-quality-modules-34 .TOC-3}

### 3.5 SDTS Restrictions/Requirements: Raster Definition Module [34](#sdts-restrictionsrequirements-raster-definition-module-1) {#sdts-restrictionsrequirements-raster-definition-module-34 .TOC-3}

### 3.6 SDTS Restrictions/Requirements: Layer Definition Module [34](#sdts-restrictionsrequirements-layer-definition-module-1) {#sdts-restrictionsrequirements-layer-definition-module-34 .TOC-3}

### 3.7 SDTS Restrictions/Requirements: Cell Module [34](#sdts-restrictionsrequirements-cell-module-1) {#sdts-restrictionsrequirements-cell-module-34 .TOC-3}

### 3.8 File Naming Convention [34](#file-naming-convention-1) {#file-naming-convention-34 .TOC-3}

# ANNEX D: SPECIAL PURPOSE TRANSFERS [35](#annex-d-special-purpose-transfers) {#annex-d-special-purpose-transfers-35 .TOC-1}

## 1 Introduction [35](#introduction-5) {#introduction-35 .TOC-2}

### 1.1 Rapid Transmission Example (Informative) [35](#rapid-transmission-example-informative) {#rapid-transmission-example-informative-35 .TOC-3}

## 2 SDTS Restrictions/Requirements [36](#sdts-restrictionsrequirements-3) {#sdts-restrictionsrequirements-36 .TOC-2}

### 2.1 Module Restrictions/Requirements: Identification Module [36](#module-restrictionsrequirements-identification-module-2) {#module-restrictionsrequirements-identification-module-36 .TOC-3}

### 2.2 Module Restrictions/Requirements: Catalog/Directory [36](#module-restrictionsrequirements-catalogdirectory-1) {#module-restrictionsrequirements-catalogdirectory-36 .TOC-3}

### 2.3 Module Restrictions/Requirements: External and Internal Spatial Reference System Modules [37](#module-restrictionsrequirements-external-and-internal-spatial-reference-system-modules) {#module-restrictionsrequirements-external-and-internal-spatial-reference-system-modules-37 .TOC-3}

### 2.4 Module Restrictions/Requirements: All Other Modules [37](#module-restrictionsrequirements-all-other-modules) {#module-restrictionsrequirements-all-other-modules-37 .TOC-3}

# ANNEX E: SDTS GEOTIFF EXTENSION [38](#annex-e-sdts-geotiff-extension) {#annex-e-sdts-geotiff-extension-38 .TOC-1}

## 1 Introduction [38](#introduction-6) {#introduction-38 .TOC-2}

### 1.1 References [38](#references-2) {#references-38 .TOC-3}

### 1.2 Background of GeoTIFF *(Informative)* [38](#background-of-geotiff-informative) {#background-of-geotiff-informative-38 .TOC-3}

### 1.3 Applicability of this Option *(Informative)* [38](#applicability-of-this-option-informative) {#applicability-of-this-option-informative-38 .TOC-3}

## 2 TIFF Restrictions/Requirements [39](#tiff-restrictionsrequirements) {#tiff-restrictionsrequirements-39 .TOC-2}

## 3 GeoTIFF Restrictions/Requirements [40](#geotiff-restrictionsrequirements) {#geotiff-restrictionsrequirements-40 .TOC-2}

## 4 SDTS Restrictions/Requirements [40](#sdts-restrictionsrequirements-4) {#sdts-restrictionsrequirements-40 .TOC-2}

### 4.1 SDTS Restrictions/Requirements: Identification Module [41](#sdts-restrictionsrequirements-identification-module-2) {#sdts-restrictionsrequirements-identification-module-41 .TOC-3}

### 4.2 SDTS Restrictions/Requirements: Catalog/Directory Module [41](#sdts-restrictionsrequirements-catalogdirectory-module-2) {#sdts-restrictionsrequirements-catalogdirectory-module-41 .TOC-3}

### 4.3 SDTS Restrictions/Requirements: Catalog/Cross-Reference Module [41](#sdts-restrictionsrequirements-catalogcross-reference-module-1) {#sdts-restrictionsrequirements-catalogcross-reference-module-41 .TOC-3}

### 4.4 SDTS Restrictions/Requirements: External Spatial Reference Module [41](#sdts-restrictionsrequirements-external-spatial-reference-module-1) {#sdts-restrictionsrequirements-external-spatial-reference-module-41 .TOC-3}

### 4.5 SDTS Restrictions/Requirements: Data Dictionary/Schema Module [42](#sdts-restrictionsrequirements-data-dictionaryschema-module-1) {#sdts-restrictionsrequirements-data-dictionaryschema-module-42 .TOC-3}

### 4.6 SDTS Restrictions/Requirements: Data Quality Modules [42](#sdts-restrictionsrequirements-data-quality-modules-2) {#sdts-restrictionsrequirements-data-quality-modules-42 .TOC-3}

### 4.7 SDTS Restrictions/Requirements: Raster Definition Module [42](#sdts-restrictionsrequirements-raster-definition-module-2) {#sdts-restrictionsrequirements-raster-definition-module-42 .TOC-3}

### 4.8 SDTS Restrictions/Requirements: Layer Definition Module [42](#sdts-restrictionsrequirements-layer-definition-module-2) {#sdts-restrictionsrequirements-layer-definition-module-42 .TOC-3}

### 4.9 SDTS Restrictions/Requirements: Cell Module [42](#sdts-restrictionsrequirements-cell-module-2) {#sdts-restrictionsrequirements-cell-module-42 .TOC-3}

### 4.10 File Naming Convention [42](#file-naming-convention-2) {#file-naming-convention-42 .TOC-3}

## 5 Implementation Resources (*Informative*) [42](#implementation-resources-informative) {#implementation-resources-informative-42 .TOC-2}

# ANNEX 1: DEFINITIONS and ACRONYMS [44](#annex-1-definitions-and-acronyms) {#annex-1-definitions-and-acronyms-44 .TOC-1}

## 1 Introduction [44](#introduction-7) {#introduction-44 .TOC-2}

### 1.1 Definitions [44](#definitions) {#definitions-44 .TOC-3}

### 1.2 Acronyms [46](#acronyms) {#acronyms-46 .TOC-3}

# ANNEX 2: DIAGRAMS AND EXAMPLES [47](#annex-2-diagrams-and-examples) {#annex-2-diagrams-and-examples-47 .TOC-1}

## 1 Introduction [47](#introduction-8) {#introduction-47 .TOC-2}

## 2 Relationships among Standards [47](#relationships-among-standards) {#relationships-among-standards-47 .TOC-2}

#### 2.1.1 SDTS and BIIF [48](#sdts-and-biif) {#sdts-and-biif-48 .TOC-4}

#### 2.1.2 SDTS and GeoTIFF [49](#sdts-and-geotiff) {#sdts-and-geotiff-49 .TOC-4}

#### 2.1.3 SDTS and JPEG [49](#sdts-and-jpeg) {#sdts-and-jpeg-49 .TOC-4}

## 3 Example Encodings [50](#example-encodings) {#example-encodings-50 .TOC-2}

### 3.1 Case: SRPE Base Transfer [50](#case-srpe-base-transfer) {#case-srpe-base-transfer-50 .TOC-3}

#### 3.1.1 Option: Addition of Color Index Module [51](#option-addition-of-color-index-module) {#option-addition-of-color-index-module-51 .TOC-4}

#### 3.1.2 Option: Addition of Compression [52](#option-addition-of-compression) {#option-addition-of-compression-52 .TOC-4}

### 3.2 Case: Using the BIIF Extension [53](#case-using-the-biif-extension) {#case-using-the-biif-extension-53 .TOC-3}

#### 3.2.1 BIIF File Structure [53](#biif-file-structure) {#biif-file-structure-53 .TOC-4}

### 3.3 Case: Using the GeoTIFF Extension [54](#case-using-the-geotiff-extension) {#case-using-the-geotiff-extension-54 .TOC-3}

# ANNEX 3: BIIF to SDTS Crosswalk [57](#annex-3-biif-to-sdts-crosswalk) {#annex-3-biif-to-sdts-crosswalk-57 .TOC-1}

#  {#section-4 .TOC-1}

## FIGURES Page {#figures-page .TOC-2}

## Figure 1: Relationship Among Standards  {#figure-1-relationship-among-standards .Table-of-Figures}

## Figure 2: Conceptual Delineation of SRPE  {#figure-2-conceptual-delineation-of-srpe .Table-of-Figures}

## Figure 3: SDTS and GeoTIFF Relationship  {#figure-3-sdts-and-geotiff-relationship .Table-of-Figures}

## Figure 4: SDTS and JPEG Relationship  {#figure-4-sdts-and-jpeg-relationship .Table-of-Figures}

## Figure 5: File Level View of SDTS Raster Transfer  {#figure-5-file-level-view-of-sdts-raster-transfer .Table-of-Figures}

## Figure 6a: File Level View of SDTS Raster Transfer with Color Option  {#figure-6a-file-level-view-of-sdts-raster-transfer-with-color-option .Table-of-Figures}

## Figure 6b: File Level View of SDTS Raster Transfer with JFIF Option  {#figure-6b-file-level-view-of-sdts-raster-transfer-with-jfif-option .Table-of-Figures}

## Figure 7: BIIF File Structure Showing Segment Order  {#figure-7-biif-file-structure-showing-segment-order .Table-of-Figures}

## Figure 8: BIIF File Example for SDTS Transfer  {#figure-8-biif-file-example-for-sdts-transfer .Table-of-Figures}

## Figure 9: File Level View of SDTS Transfer using GeoTIFF Option  {#figure-9-file-level-view-of-sdts-transfer-using-geotiff-option .Table-of-Figures}

## Figure 10: File Level View of SDTS Transfer using TIFF Supplement  {#figure-10-file-level-view-of-sdts-transfer-using-tiff-supplement .Table-of-Figures}

## Tables Page {#tables-page .TOC-2}

## Table 3.1 - Raster Spectrum - from Natural to Synthetic [9](#__RefHeading___Toc431887634) {#table-3.1---raster-spectrum---from-natural-to-synthetic-9 .Table-of-Figures}

## Table 4.1 - Standard Module Names [11](#__RefHeading___Toc431887635) {#table-4.1---standard-module-names-11 .Table-of-Figures}

## Table 5.1 - Module Level Restrictions and Requirements [14](#__RefHeading___Toc431887636) {#table-5.1---module-level-restrictions-and-requirements-14 .Table-of-Figures}

## Table 6.8 -- Cell Value Data Types [22](#__RefHeading___Toc431887637) {#table-6.8-cell-value-data-types-22 .Table-of-Figures}

## Table D.1 - Transmission Comparison [36](#__RefHeading___Toc431887638) {#table-d.1---transmission-comparison-36 .Table-of-Figures}

## Table Annex 3.1 - SDTS and BIIF Term Crosswalk [57](#__RefHeading___Toc431887639) {#table-annex-3.1---sdts-and-biif-term-crosswalk-57 .Table-of-Figures}

## Table Annex 3.2 - NITF Format Requirements on Lineage [58](#__RefHeading___Toc431887640) {#table-annex-3.2---nitf-format-requirements-on-lineage-58 .Table-of-Figures}

#  SDTS PART 5: RASTER PROFILE and EXTENSIONS

### 1.1 Introduction

The Spatial Data Transfer Standard (SDTS) defines a general mechanism
for the transfer of geographically referenced spatial data and its
supporting metadata, i.e., attributes, data quality reports, coordinate
reference systems, security information, etc. The overriding principle
that SDTS promotes is that the spatial data transfer should be
self-documenting. The data set in SDTS should contain all of the
information that is needed to assess and (or) use the data for any
appropriate GIS application.

The SDTS base specification (ANSI NCITS 320-1998, Parts 1,2 and 3) is
implemented via profiles of SDTS. A SDTS profile, in general terms, may
be defined as a limited subset of the standard, designed for use with a
specific type of data model, i.e., topological vector, point, grid,
image, etc. Specific choices are made for encoding possibilities not
addressed, left optional, or left with numerous choices within the SDTS
base specification. A profile may also specify extensions to the base
standard to address changing technologies, and to take advantage of
other industry standards.

For raster image data, there are numerous standards, with various
properties, restrictions, and degrees of implementation. The SDTS Raster
Profile and Extensions (SRPE) permits the use of two other industry
standards for image data: ISO/IEC 12087-5 Basic Image Interchange Format
(BIIF) and Tagged Image File Format (TIFF). BIIF defines a general
mechanism for the transfer of image data and any supporting data, i.e.
image parameters, visualization parameters, compression parameters, text
annotations, symbols, etc. BIIF is in use in the commercial/military
community under a joint profile form of Mil-Std 2500 (National Imagery
and Transmission Format) and NATO STANAG 4545 -- NATO Secondary Imagery
Format (NSIF). TIFF is a general-purpose image file format that is used
widely for simple image applications. TIFF is an ad-hoc standard,
available for public use, based on a specification owned by Adobe, Inc.

This document, referred to herein as SRPE, is organized into a main
body, called the profile core specification, and a number of annexes,
both informative and normative. SRPE uses the same major sections found
in SDTS Part 1. Specific discussions regarding encoding possibilities in
SDTS and BIIF are grouped under each major heading and will include
specific references to SDTS Parts 1, 2, or 3, and (or) BIIF where
necessary. To aid in the implementation of the optional BIIF extension,
a few notes are inserted in appropriate paragraphs to identify potential
areas of concern and added capabilities. (These notes are not all
inclusive and the implementers should not rely on them to identify all
differences or areas of concern.)

Normative annexes provide additional options that may be implemented but
are not required. Normative annexes are numbered using uppercase alpha
characters. Informative annexes provide additional information that may
be useful in the implementation of this profile and the options allowed
in the normative annexes. Informative annexes are numbered using numeric
characters. Annex A is the profile annex option that permits BIIF to be
used for the image data portion of an SDTS transfer. Annex B permits the
SDTS color modules to be used. Annex C permits data compression to be
used. Annex D permits special purpose transfer where it may be necessary
to omit otherwise mandatory information. Annex E permits TIFF to be used
for the image data portion of an SDTS transfer. Annex 1 contains a
glossary. Annex 2 contains examples to help clarify the implementation
of this profile. Annex 3 is a crosswalk between the standards terms and
concepts to assist those familiar with only SDTS or BIIF.

#### 1.1.1 Objective

In general, a SDTS profile provides for the transfer of files, records,
fields and subfields with the following objectives:

> a\. to encode in a standard non-proprietary format;
>
> b\. to provide for machine and medium independence;
>
> c\. to accompany the spatial data with their description;
>
> d\. to preserve all meaning and relationships of the data; and,
>
> e\. to make use of other industry related standards.

Additionally, the SRPE seeks to take positive action to converge the
efforts relating to raster image standards. To meet this objective, new
image handling capabilities are made available for use with SDTS by
referencing other standards, rather than duplicating the capability
within SDTS. This approach is possible because the SDTS was designed
with a separation of logical structures and format. The BIIF Extension
is a good example of the convergence strategy.

The SRPE seeks to take advantage of the capabilities of both SDTS
(raster portion) and BIIF. The SDTS has a geographic information focus
and provides the capability of encoding raster grid and image data,
georeferencing information, simple color look-up tables, data quality
reports, data dictionary information and other such metadata. The BIIF
has an image transmission focus and provides an efficient image file
format, image compression, image blocking/tiling, variety of color
models, and visualization controls. Rather than modify SDTS structures
to directly include these more advanced image-handling capabilities,
this profile seeks to use BIIF structures as defined. This approach will
alleviate redundant development of similar capabilities and facilitate
convergence of the military and commercial spatial data communities. To
further the convergence of these raster standards, Annex A of this SRPE
is intended to be equivalent to the NSIF profile to BIIF.

#### 1.1.2 Scope 

The SRPE contains specifications for a profile for use with
georeferenced two-dimensional raster data. Both raster image and raster
grid data are included within the scope of this profile. The transfer of
indirectly referenced images is permitted, i.e., a satellite image of
St. Louis, MO where city and state are the only ground based reference
included. Excluded are three-dimensional and higher raster data and
vector data.

SRPE can accommodate image data, digital terrain data, gridded
geographic information system (GIS) layers, remotely sensed images, and
any other data that can be conceptualized as a two-dimensional array of
data values. For the purposes of SRPE, both gridded data and image data
will be referred to as raster data.

#### 1.1.3 Applicability

SRPE can be utilized by the Defense and Civil communities to accommodate
exchange of image data, digital terrain data, gridded geographic
information system (GIS) layers, remotely sensed images, and any other
data that can be conceptualized as a two-dimensional array of data
values. Because of its self-documenting nature, SRPE is most appropriate
for blind transfers, spatial data archives, and data distribution in a
non-proprietary format.

#### 

#### 1.1.4 Related and Referenced Standards 

The following references contain provisions either by direct reference
or relationship, which through references in this paragraph or within
this text, constitute provisions of SRPE. At the time of publication,
the editions reflect the document versions used for implementing the
SRPE. Revisions to referenced standards that post-date this document,
and do not cause ambiguity or change to this profile may be used without
violating compliance. For clarification, contact the profile maintenance
authority.

##### 1.1.4.1 Referenced Standards

The following referenced standards constitute provisions of SRPE by
specific reference within the text of SRPE.

> ANSI NCITS 320-1998: Spatial Data Transfer Standard (SDTS).
>
> FGDC-STD-001-1998: Content Standards for Digital Geospatial Metadata.
>
> ISO 8211-1984 Data Descriptive File for Information Interchange.

#### 1.1.5 Standards Development Procedures

The SRPE was developed jointly by the U.S. Geological Survey (USGS) and
the National Imagery and Mapping Agency (NIMA). The SRPE was developed
as an interface and intermediary step to the convergence of SDTS raster
capabilities and the BIIF raster transmission standards. The SRPE
provides a means of using the archival capabilities, the non-proprietary
distribution mechanism, and the geographic information focus of the SDTS
and the imagery transmission focus of BIIF.

The SRPE is intended to replace the December 1995 Draft Part 5: Raster
Profile. The SRPE retained all the functionality of the previous draft
SDTS Raster Profile. Annex A of the SRPE is intended to be equivalent to
the NSIF Profile to BIIF to facilitate convergence of these efforts.

Other extensions (Annexes) may be added to SRPE without modifying the
profile core specification as long as the implementation of the new
Annex does not require the addition of capabilities within the profile
core specification.

The ad-hoc working group that consisted of the following members
developed the SRPE:

Phyllis Altheide, U.S. Geological Survey

Laura Moore, National Imagery and Mapping Agency

Thomas Hampton, U.S. Geological Survey

Ron Galloni, Joint Interoperability Test Command

Robert Garneau, TASC, BIIF Editor

David Webb, Joint Interoperability Test Command

Bryon Ellingson, U.S. Geological Survey

We gratefully acknowledge the contributions and support of the
following:

Charles Roswell, National Imagery and Mapping Agency

Richard Hogan, U.S. Geological Survey

Ralph Goldsmith, National Imagery and Mapping Agency

William Harris, U.S. Geological Survey

Robin Fegeas, U.S. Geological Survey

Dave Hastings, National Oceanic and Atmospheric Administration

Charley Hickman, U.S. Geological Survey

Steve Kerr, Joint Interoperability Test Command

Laura Thompson, National Imagery and Mapping Agency

Canadian Geomatics Standards Board, Raster Subcommittee

Digital Geographic Information Working Group

#### 1.1.6 Maintenance Authority

The maintenance authority for the SDTS Raster Profile and Extensions
base profile resides with the US Geological Survey, National Mapping
Division (USGS/NMD). The maintenance authority for the NITF profile to
BIIF, referenced in ANNEX A, resides with the National Imagery and
Mapping Agency (NIMA). Therefore, the maintenance of the SDTS Raster
Profile and Extensions will be accomplished by a collaborative effort
between the USGS/NMD and the NIMA

### 1.2 Conformance and Testing

(See also SDTS Part 1, Section 1.2, Conformance, and BIIF clause 5
Conformance profiles and extensions)

There are three types of products and (or) aspects which can be tested
or evaluated for conformance to SRPE. Depending on the product
capability being evaluated, one or more of the following aspects will be
utilized to measure compliance:

\(a\) SDTS transfers (the actual data sets);

\(b\) SDTS encoding software; and

\(c\) SDTS decoding software.

#### 1.2.1 Transfer Conformance

In order to conform to this SRPE a transfer shall:

> \(a\) contain all mandatory spatial objects, modules, fields, and
> subfields as specified in SRPE;
>
> \(b\) not contain spatial objects, modules, fields, and subfields
> which are not permitted by SRPE or its annexes;
>
> \(c\) conform to all applicable requirements and specifications of
> BIIF and Parts 1, 2, and 3 of SDTS unless they conflict with SRPE;
> (profile takes precedent)
>
> \(d\) conform to all restrictions of SDTS Parts 1, 2, 3 and as
> specified in SRPE;
>
> \(e\) be formatted in compliance with ISO 8211 or the applicable
> adjunct file format as permitted by an annex;
>
> \(f\) follow all module and file naming requirements of SRPE;
>
> \(g\) contain any profile options it claims to include; and
>
> \(h\) adhere to all other requirements specified in SRPE.

#### 1.2.2 Encoder Conformance

In order to conform to this SRPE, an encoder shall:

> \(a\) generate only SRPE transfers which conform to Section 1.2.1 (or
> be able to be directed to only generate transfers which conform to
> SRPE);
>
> \(b\) convert spatial objects in the input system to appropriate SDTS
> spatial objects;
>
> \(c\) convert attribute data stored in the input system (such as in a
> data base) to SDTS Attribute Primary and Secondary modules;
>
> \(d\) correctly maintain linkages between spatial objects and
> attributes;
>
> \(e\) encode raster formats, with the choice of data type (i.e.,
> integer, real, etc.) specified by the user at the time of encoding,
> and, as an option, be able to create a single transfer with different
> precessions (i.e., 8-bit, 32-bit, etc.) for each separate layers; and
>
> \(f\) properly implement all profile options it claims to support.

#### 1.2.3 Decoder Conformance

In order to conform to this SRPE, a decoder shall:

> \(a\) be able to interpret any SRPE transfer which conforms to Section
> 1.2.1;
>
> \(b\) be able to decode any module required or permitted by the body
> of SRPE;
>
> \(c\) be able to decode any spatial object required or permitted by
> section 2.1 of SRPE and, to the fullest extent possible, convert it to
> the receiving systems' corresponding object or equivalent information
> structure;
>
> \(d\) be able to decode any Attribute Primary or Secondary Module and
> convert it to a data base or other format usable by the receiving
> system;
>
> \(e\) correctly maintain linkages between spatial objects and
> Attribute Primary records;
>
> \(f\) decode multiple precision raster formats, as necessitated by the
> data type format used in the encoded transfer files; when data
> precision exceeds system capability then provide notification of
> action taken;
>
> \(g\) be able to tolerate the presence of modules, fields, subfields,
> and adjunct files which are permitted by profile annexes which the
> decoder does not support;
>
> \(h\) be able to recover if an error is encountered in a particular
> record, field, or subfield in the SRPE transfer;
>
> \(i\) report to a file or output device information describing the
> position of errors encountered in the SDTS transfer, including Module
> Name, Record ID, tag, and label of the last successfully decoded data
> element and, if possible, the Module Name, Record ID, field tag, and
> subfield label of the data element containing the error; and
>
> \(j\) properly implement all profile options it claims to support;

\(k\) be able to decompress all permitted compression methods.

## 2 Raster Data Concepts

### 2.1 Spatial Objects

(See SDTS Part 1, Section 2.3 Definition of Spatial Objects)

The SRPE permits only the Digital Image or Grid (object code G2) raster
object. All other object representation codes are not permitted. A
conformant transfer must contain at least one G2 object. This profile
further restricts the Grid Cell and Pixel spatial objects to be of
rectangular geometry, i.e., hexagons, triangles, octagons, etc. are not
permitted. (An image that has not been corrected geometrically to a
rectangular grid can also be transferred. See Section 2.7 Warped Grid.)
Any image or grid data that can be conceptualized as a two-dimensional
array of values can be transferred under this SRPE.

In this profile, the term *raster* will be used to collectively refer to
both digital image and grid, and the term *cell* will be used to
collectively refer to both grid cell and pixel, unless otherwise noted.
The SRPE requires cell values to be numeric.

### 2.2 Multiple Raster Objects, Layers, and Partitions

The SRPE permits one or more raster objects to be contained in a single
transfer. A raster object may consist of one or more layers with the
restriction that all layers of a single raster object have the same
geographic extents (i.e., cover the same portion of the earth's
surface), and use the same raster object scan reference system (i.e.,
cell address 2,3 refers to the same cell location in every layer.) The
raster objects may occupy the same, overlapping, or different horizontal
partitions of the earth's surface.

The data encoder is permitted to encode multiple raster objects in a
single transfer, but should be warned that the relationship between the
raster objects is undefined. The relationship between the multiple
raster objects or between the multiple layers of a single raster object
must be explained in the SDTS Logical Consistency Module.

BIIF Note: In the case of using the BIIF option the following applies. A
BIIF file is permitted to include multiple images. Each image in BIIF
can have one or more bands. Further, the SRPE permits the simultaneous
use of both SDTS and BIIF. For example, an SDTS grid may be used to
encode a layer of elevation data and the BIIF image may be used to
encode an orthoimagery layer of the same geographic extent.

### 2.3 Non-ragged Grids

(See SDTS Part 1, Section 5.7.6.3 (Raster) Data Dictionary Domain)

The SRPE requires a raster grid to be non-ragged. A data encoder can
define a "fill value" to convert a ragged grid to a non-ragged grid. In
SDTS a Layer Definition module record defines a raster layer. The Data
Dictionary module records further describes the meaning of this layer.
An associated Data Dictionary Domain module record(s) defines which
pixel value means data not present, and any other special pixel values.

BIIF Note: In the case of using the BIIF option the following applies.
If the image data to be encoded is ragged then padding or transparent
pixels must be used. BIIF uses "masking techniques" to identify
non-valued, or transparent pixels within an image BIIF Clause 4.2.5.2).
If an image is partitioned into equal size tiles/blocks, then padding
can also be used to fill an empty portion of a block.

### 2.4 Nongeospatial Dimensions

The use of nongeospatial dimensions is not permitted by SRPE. SRPE only
permits the transfer of two dimensional raster data in the x,y
coordinate space. (The z coordinate is not permitted in the spatial
address. Elevation data values are permitted to be transferred as a
raster grid layer under this profile.)

BIIF Note: In the case of using the BIIF option the following applies.
Baseline BIIF provides for homogenous pixel values for monochrome or
color images. PIKS images provide capability for heterogeneous pixel
values of up to five dimensions\--x, y, z, temporal, multispectral. Only
baseline BIIF is permitted, with two-dimensional data occurring in the
x,y coordinate space. (BIIF Clause 4.2.4.1 Image Subheader)

### 

### 2.5 Raster Scan Reference System

(See SDTS Part 1, Section 5.7.7)

SDTS raster modules permit the definition of a raster object scan
reference system and layer scan reference system which are different.
The SRPE requires that the raster object scan reference system and the
layer scan reference system be identical so no coordinate conversion is
required (i.e. the layer coordinate and the raster object coordinate are
the same.) The SRPE requires that the scan origin be located at the top
left and the scan pattern be linear and the scan direction be row.

### 2.6 Band Interleaving (Cell Sequencing Code)

(See SDTS Part 1, Section 5.7.1.1. Raster Definition Module)

SRPE permits the cells of a raster object to be sequenced in one of
three modes: layer sequential (code GI), layer

interleaved by line (code GJ), or layer interleaved by pixel (code GL).
Only layers from the same raster object are permitted to be interleaved.
All layers of the same raster object must be interleaved in the same
manner (i.e., not permitted to interleave layers one and two and leave
layer three sequential.) A raster object with one layer must be denoted
as code GI. Each band may have different data types (e.g. band 1 may
have a data type of 8-bit integer and band 2 may have the data type of
16-bit integer).

BIIF Note: In the case of using the BIIF option the following applies.
(BIIF Clause 4.2.5.4.2) The band interleaving options permitted are by
pixel, block, and row as defined for BIIF element IMODE.

### 2.7 Warped Grid Raster

No standard mechanism is provided to rectify geospatial imagery. In
transferring a warped grid image (non-rectified), the geometric
correction information is of utmost importance for the correct
utilization of the imagery. The geospatial community recognizes the need
for standardization of these geometric correction parameters, however,
no single standardized set has been developed as of this writing. SRPE
recommends that for the transfer of geometric correction parameters, a
widely accepted industry standard be used. Geometric correction
parameters should be passed along with the image data or at a minimum
referenced to provide the receiver of the data with enough information
to identify the appropriate system(s) for processing.

The SRPE will permit the transfer of warped grid images. To indicate the
transfer of a warped grid image, the object representation code of G2
will have a "W" appended to it, yielding "G2W". A decoder that cannot
perform automatic rectification will minimally display the image as a
normal grid and warn the data user that this has been done. If the
geometric correction parameters are included in the transfer, then the
data encoder will encode these geometric correction parameters in SDTS
Attribute Primary Module(s) records that are referenced by the Raster
Definition Module record.

A conformant decoder must be able to display a G2W object code as if it
were a G2 code, with appropriate warnings to the data consumer. Full
support of the G2W object representation code is optional for conforming
encoders and decoders.

### 2.8 Tesseral Indexing/Blocking 

(See SDTS Part 1 Section 5.7.6 and BIIF Clause 4.2.5.1 Blocked Images)

The SRPE does not permit tesseral indexing.

BIIF Note: In the case of using the BIIF option the following applies.
Blocked images are permitted. If compression is used, the entire image
(each tile) must be compressed using the same algorithm. If interleaving
is used, each tile must be interleaved in the same fashion.

### 2.9 Compression

(See SDTS Part 1 Section 5.7.10)

The SRPE does not permit compression. (Compression is permitted in Annex
A, C, and E.)

Decompression must be supported. This requirement is based on the
assumption that compressing is more complex than decompressing, and that
data encoders can optionally chose to implement compression. A data
decoding capability must support decompression as described below to
facilitate data exchange.

Decompression of run length encoding as described in SDTS Part 1 Section
5.7.10.1 must be supported.

BIIF Note: In the case of using the BIIF option the following applies.
The NSIF BIIF Profile requires decompression of VQ, Bi-level, and JPEG
(lossy and lossless), and compression using JPEG. Compression using VQ
and bi-level are optional.

## 3 Spatial Data Quality

(See SDTS Part 1, Section 3 Spatial Data Quality)

In addition to SDTS Part 1, Section 3 the following requirements must be
satisfied.

### 3.1 Lineage

A report of lineage must include a description of the source material
and how it was used. The Federal Geographic Data Committee (FGDC)
Content Standards for Digital Geospatial Metadata, Section 2.5 elements
are highly recommended to be included in the transfer.

For a remotely sensed image, radiometric information is of utmost
importance for correct utilization of the imagery. The SDTS is capable
of encoding this information, however, no single standardized set of
radiometric parameters has been developed. Any parameters encoded as
SDTS attributes need to be fully defined using the SDTS Data Dictionary
modules. The Lineage Module should contain a description of how to apply
the parameters or reference a document that describes the process.

Separate processing histories pertaining to, for example, separate
raster data layers, must be documented. If data are collected from an
aerial photograph, then a statement explaining the rectification process
is highly recommended. If the raster has undergone multiple lossy
compressions, then a report regarding the compression history is highly
recommended.

In general, the more that has been done to the raster data, the more
there is to put in the Lineage report. The table below shows a
progression of raster products with increasing lineage reporting
requirements proceeding from left to right.

+-----------+-----------+-----------+-----------+-----------+-----------+
| []{#      |           |           |           |           |           |
| __RefHead |           |           |           |           |           |
| ing___Toc |           |           |           |           |           |
| 431887634 |           |           |           |           |           |
| .anc      |           |           |           |           |           |
| hor}Table |           |           |           |           |           |
| 3.1 -     |           |           |           |           |           |
| Raster    |           |           |           |           |           |
| S         |           |           |           |           |           |
| pectrum - |           |           |           |           |           |
| from      |           |           |           |           |           |
| Natural   |           |           |           |           |           |
| to        |           |           |           |           |           |
| Synthetic |           |           |           |           |           |
+-----------+-----------+-----------+-----------+-----------+-----------+
| Remote    | Aerial    | Rectified | Map/Chart | Regular   | Feature   |
| Sensing   | P         | Aerial    |           | Grid      | Coded;    |
| Thematic  | hotograph | Photo     | Scan      |           | Land      |
| Mapper    | scan      | Scan      |           |           | charact   |
|           |           |           |           |           | erization |
| -LandSat  |           |           |           |           |           |
+-----------+-----------+-----------+-----------+-----------+-----------+

BIIF Note: In the case of using the BIIF option the following applies.
Lineage information may be carried in the History Tagged Record
Extension and the Geospatial Support Data Extension. Lineage information
in BIIF and SDTS should cross-reference each other, so the data consumer
is aware of all relevant information.

### 3.2 Positional Accuracy

In reporting positional accuracy, use of a standard reporting method is
highly recommended. If no other standard reporting method applies, the
FGDC Content Standards for Digital Geospatial Metadata, Section 2.4
elements should be used for encoding.

BIIF Note: In the case of using the BIIF option the following applies.
DIGEST Annex D outlines the Geospatial Support Data Extension Segment
(DES) through which accuracy data can be included in a BIIF file. BIIF
DES also supports reporting of positional accuracy that varies by region
within a data set coverage area. Positional accuracy information in BIIF
and SDTS should cross-reference each other, so the data consumer is
aware of all relevant information.

### 3.3 Attribute Accuracy

For raster data, attribute accuracy refers to the accuracy of the
pixel/cell values for a layer.

For qualitative or categorical attributes, such as land classification
or soil type (non-numeric), attribute accuracy is a degree of the
reliability of the measurement. For quantitative attributes, such as
elevation or temperature values, the accuracy data is a statistical
measurement, i.e. standard deviation, or root mean square error (RMSE).

If the raster layer contains elevation measurements, use the Positional
Accuracy Module to describe the accuracy of the elevation measurements.

### 3.4 Logical Consistency

Logical consistency addresses the fidelity of the relationships between
spatial objects. With regard to raster data, this addresses the
relationships between grids, images, and layers. There are already
subfields in the raster modules for describing the number of layers and
bands and what each represents. The Data Quality/Logical Consistency
module \"comment\" field includes other information (as textual
narration) that would be useful for human-interpretation. If multiple
raster objects are included in the transfer then the relationship
between the raster objects must be described.

The Logical Consistency module must contain a description of the NULL
scheme used to indicate not relevant missing data and relevant but not
known data. (See 4.4 of SRPE for more information.)

BIIF Note: In the case of using the BIIF option the following applies.
If raster objects are in SDTS and in BIIF, their relationship must be
described in the Logical Consistency Module. If BIIF is used to encode
image and sub-image relationships, a statement to this effect should be
included in the Logical Consistency Module. If the visual representation
of the raster data is also being transferred, include statements in the
Logical Consistency module that describe why the visual representation
is included and how the information is being included. If BIIF is to be
used for display control on a receiver's system, then include a
statement in the Logical Consistency module explaining this and to what
extent the display is being controlled. For a BIIF image file, a
mechanism for specifying display levels and attachment levels assigns a
hierarchy coding to each element of the image.

### 3.5 Completeness

(See SDTS Part 1, Section 3.5 Completeness)

If the original raster data was a ragged grid, state how the grid has
been made regular.

BIIF Note: In the case of using the BIIF option the following applies.
If pad values or transparent pixels are used, then state that they are
present and why, if applicable.

## 4 General Specification

(See also SDTS Part 1, Section 4.1.3, The Transfer Model)

### 4.1 Standard Module Names

The SRPE module names (the unique name of each individual module) will
be standardized, and consist of four characters according to the
following rules.

All modules must be named the same as the primary module field mnemonic.
For any module type that can occur multiple times in a transfer, the
last 1, 2, or 3 characters of the name can be used to show a series. For
example, if a particular SDTS raster transfer contained three distinct
Cell modules, the encoder could choose CEL1, CEL2, and CEL3 as the
module names. Cell modules must not be named CATD, CATX, CATS, or CLR\*.
Which of the module types can occur more than once in a transfer and the
number of characters in the name that can be varied to signify multiple
occurrences are identified in Table 5.1. The complete list of standard
module names for SRPE is in Table 4.1.

  ----------------------------------------- -----------------------------
  []{#__RefHeading___Toc431887635           
  .anchor}Table 4.1 - Standard Module Names 

  IDEN (Identification),                    CATD (Catalog/Directory),

  CATX (Catalog/Cross Reference),           CATS (Catalog/Spatial
                                            Domain),

  SCUR (Security),                          IREF (Internal Spatial
                                            Reference),

  XREF (External Spatial Reference),        RGIS (Registration)

  SPDM (Spatial Domain),                    DDDF (Data
                                            Dictionary/Definition),

  DDOM (Data Dictionary/Domain),            DDSH (Data
                                            Dictionary/Schema),

  STAT (Transfer Statistics),               DQHL (Data Quality/Lineage),

  DQPA (Data Quality/Positional Accuracy),  DQAA (Data Quality/Attribute
                                            Accuracy),

  DQLC (Data Quality/Logical Consistency),  DQCG (Data
                                            Quality/Completeness).

  CLRX (Color Index)                        

  RSDF (Raster Definition)                  LDEF (Layer Definition)

  Cell (Cell) (cannot be CATD, CATX, CATS,  Attp (Attribute Primary)
  CLR\*)                                    

  Bttp (Attribute Secondary)                
  ----------------------------------------- -----------------------------

### 4.2 Order of Records, Fields, and Subfields within Modules

Records within modules must be ordered, in ascending order, by Record
ID. But the actual Record ID integer values need not start with \"1,\"
and records in sequence may skip integers arbitrarily, up to (2^31^
--1).

The subfields within fields and fields within records must be ordered as
in the SDTS module specification layout tables found in SDTS Part 1,
Section 5.

### 4.3 Spatial Reference System 

(See also SDTS Part 1, Section 4.1.3.5, Spatial Registration)

There must be only one external coordinate frame of reference within a
transfer. SDTS External Spatial Reference Conformance level 1, 2, or 3
(unspecified) is permitted. Level 1 must be one of the preferred
external reference systems, level 2 must be a known and well-defined
system and level 3 indicates indirect referencing or a warped grid
system, with an unspecified relationship to latitude and longitude. For
additional information see SDTS Part 1 paragraph 4.1.3.5.

Each raster object may have its own internal coordinate system
(referenced to the external spatial reference system by translation and
scaling parameters in an Internal Spatial Reference module record).
Horizontal and vertical datums are specified in the External Spatial
Reference module under the HDAT and VDAT subfields respectively.

BIIF Note: In the case of using the BIIF option the following applies.
(See DIGEST Annex D Geospatial SDE) - Each image can have its own
external spatial reference system.

#### 4.3.1 External Spatial Reference Conformance Level

(See SDTS Part 1, Section 5.2.4.2 External Spatial Reference)

For External Spatial Reference Conformance level 1,

a)  The External Spatial Reference EXSP subfield of the Conformance
    field of the Identification Module must have the value \"1\"
    indicating that, YES, one of three recommended systems is used; and,

b)  The Reference System Name RSNM subfield in the External Spatial
    Reference Module primary field must have the value \"GEO\",
    \"SPCS\", \"UTM\", or \"UPS\".

For External Spatial Reference Conformance level 2,

a)  The External Spatial Reference EXSP subfield of the Conformance
    field of the Identification Module must have the value \"2\"
    indicating that a projection other than the three recommended
    systems is used;

b)  The Reference System Name RSNM subfield in the External Spatial
    Reference Module primary field must have the value \"OTHR\";

c)  The Projection PROJ subfield in the External Spatial Reference
    Module primary field must have the name and (or) description of the
    projection and reference system used; and,

d)  The Reference Documentation RDOC subfield in the External Spatial
    Reference Module must contain the document where the projection is
    defined. It is recommended that the projection named be defined in
    the General Cartographic Transformation Package (GCTP[^1]).

For External Spatial Reference Conformance level 3,

a)  The External Spatial Reference EXSP subfield of the Conformance
    field of the Identification Module must have the value \"3\"
    indicating that georeferencing is unspecified;

b)  The Reference System Name RSNM subfield in the External Spatial
    Reference Module primary field must have the value \"UNSP"; and,

c)  The Reference Documentation RDOC subfield in the External Spatial
    Reference Module may contain the document where the rectifying
    method is described, if applicable.

#### 4.3.2 Internal Representation of Spatial Addresses

The internal representation of X and Y coordinates is permitted by SRPE
to be Integer ("I"), Real ("R"), 32‑bit signed binary integer
(\"BI32\"), 32-bit unsigned binary integer ("BUI32"), or 32- or 64-bit
binary floating point ("BFP32", "BFP64") . Signed binary integers are
represented in \"two\'s complement\" format as defined in ANSI X3.122 ‑
1986 CGM Part 3 Binary Encoding, SDTS Part 3, Section 5.1, pages 10‑11.
This standard requires \"big‑endian\" bit ordering in which the most
significant bit is stored first (see also ISO 8632‑3, and SDTS Part 3,
Section 9.3, Binary Data.) Binary floating point values are encoded as
specified by ANSI/IEEE 754-1985, Standard for Binary Floating Point
Arithmetic. The "I" and "R" types are encoded as per ISO 6093 for
numeric values in character string format.

Internal coordinates can be converted to external coordinates by
applying the scaling and translation values from an Internal Spatial
Reference module (see SDTS Part 1, Sections 5.2.4.1 Internal Spatial
Reference, and 5.7.7.1 Rules for assigning Layer Coordinates to Cell
Values).

#### 4.3.3 Restrictions on X and Y Subfields

The X subfield of spatial addresses must only be used to transfer
longitude and easting values; and, the Y subfield must only be used to
transfer latitude or northing. Only the X and Y geospatial dimensions
are permitted. No other geospatial or nongeospatial dimensions are
permitted.

### 4.4 NULL (and Like) Values

(See also SDTS Part 1, Section 4.1.3.3.9, Nulls and Defaults)

The SRPE permits null values for user-defined attributes and cell values
to be defined in the Data Dictionary modules. For standard subfields or
implementation restrictions, the scheme below is recommended. The SRPE
requires that the NULL scheme used be described in the Logical
Consistency Module.

When a transfer uses fixed length fields in an ISO 8211 file, special
consideration must be given to handling NULL values. NULL values are
defined in two general categories:

> a\. undefined, not relevant;

b\. relevant, but unknown or missing.

The data encoder determines null values. When appropriate, the following
text will be encoded in the Comment subfield of a Logical Consistency
module record, and implemented:

> When a subfield, either user‑defined in Attribute Primary and
> Attribute Secondary module records, or in other SDTS module records,
> is implemented as fixed‑length, the following null scheme is used:
>
> a\. when information to be encoded in the subfield is known to be not
> applicable (undefined, not relevant), then the subfield is valued by a
> string of spaces; and
>
> b\. when the information to be encoded is relevant but unknown (or
> missing), then the subfield is valued by a string of question marks
> \"?\".

The Logical Consistency module with the above text must be associated to
applicable modules through the Catalog/Cross-Reference module.

### 4.5 Attributes

(See also SDTS Part 1, Annex B, Section B.6 Suggested Code Sets)

SRPE highly recommends the use of established FIPS codes where
applicable, such as FIPS PUB 6‑4 (31 August 1990) Counties and
Equivalent Entities Codes. SRPE permits any level of feature conformance
(1-4), but highly recommends the use of standardized entities (i.e.,
layer names for raster) and attributes.

The entire raster or any of its layers may have attributes. Attributes
are not permitted on individual cells.

### 4.6 Relationships between Modules and Raster Objects

There must be one Raster Definition module, one Layer Definition module,
at least one Cell module and one Internal Spatial Reference module. The
Raster Definition module may have one or more records; one record for
each raster object. The Layer Definition module contains one record for
every raster layer. The Cell module(s) contain the Cell data for the
raster layers.

## 5 Transfer Module Specification

(See also SDTS Part 1, Section 5 Transfer Module Specification)

This section addresses the module level restrictions as they apply to a
transfer. Certain requirements of SDTS Part 1 are repeated here for
clarity. Following the module level restrictions/requirements, any
restrictions on field/subfield values are noted for each module. The
order of coverage follows that of SDTS Part 1, Section 5.

Table 5.1 contains the inclusion, exclusion, and cardinality rules for
each module. The standardized module names are included, along with the
minimum and maximum number of occurrences of the module type. A
lowercase \"n\" indicates that the upper limit is user defined. Any
lowercase letters in the module name means that multiple modules of this
type can be named as a series by replacing the lowercase characters with
uppercase alphanumeric characters.

+---------------------------------+----------+------------+------------+
| []{#__RefHeading___Toc431887636 |          |            |            |
| .anchor}Table 5.1 - Module      |          |            |            |
| Level Restrictions and          |          |            |            |
| Requirements                    |          |            |            |
+=================================+==========+============+============+
| Module Type                     | Name     | Min. No.   | Max. No.   |
+---------------------------------+----------+------------+------------+
| Global Information Modules (See |          |            |            |
| also SDTS Part 1, Section 5.2,  |          |            |            |
| Global Information Modules      |          |            |            |
+---------------------------------+----------+------------+------------+
| Identification                  | IDEN     | 1          | 1          |
+---------------------------------+----------+------------+------------+
| Catalog/Directory               | CATD     | 1          | 1          |
+---------------------------------+----------+------------+------------+
| Catalog/Cross Reference         | CATX     | 0          | 1          |
+---------------------------------+----------+------------+------------+
| Catalog/Spatial Domain          | CATS     | 1          | 1          |
+---------------------------------+----------+------------+------------+
| Security                        | SCUr     | 0          | n          |
+---------------------------------+----------+------------+------------+
| Internal Spatial Reference      | IREF     | 1          | 1          |
+---------------------------------+----------+------------+------------+
| External Spatial Reference      | XREF     | 1          | 1          |
+---------------------------------+----------+------------+------------+
| Registration                    | RGIS     | 0          | n          |
+---------------------------------+----------+------------+------------+
| Dimension Definition            | DMDF     | 0          | 0          |
+---------------------------------+----------+------------+------------+
| Spatial Domain                  | SPDm     | 0          | n          |
+---------------------------------+----------+------------+------------+
| Data Dictionary/Definition      | DDDf     | 1[^2]      | n[^3]      |
+---------------------------------+----------+------------+------------+
| Data Dictionary/Domain          | DDOm     | 1^2^       | n^3^       |
+---------------------------------+----------+------------+------------+
| Data Dictionary/Schema          | DDSh     | 1^2^       | n^3^       |
+---------------------------------+----------+------------+------------+
| Transfer Statistics             | STAT     | 1          | 1          |
+---------------------------------+----------+------------+------------+
| Data Quality Modules (See also  |          |            |            |
| SDTS Part 1, Section 5.3, Data  |          |            |            |
| Quality Modules)                |          |            |            |
+---------------------------------+----------+------------+------------+
| Lineage                         | DQHl     | 1          | n          |
+---------------------------------+----------+------------+------------+
| Positional Accuracy             | DQPa     | 1          | n          |
+---------------------------------+----------+------------+------------+
| Attribute Accuracy              | DQAa     | 1          | n          |
+---------------------------------+----------+------------+------------+
| Logical Consistency             | DQLc     | 1          | n          |
+---------------------------------+----------+------------+------------+
| Completeness                    | DQCg     | 1          | n          |
+---------------------------------+----------+------------+------------+
| Attribute Modules               |          |            |            |
|                                 |          |            |            |
| (See also SDTS Part 1, Section  |          |            |            |
| 5.4, Attribute Modules)         |          |            |            |
+---------------------------------+----------+------------+------------+
| Attribute Primary               | Attp     | 0          | n          |
+---------------------------------+----------+------------+------------+
| Attribute Secondary             | Bttp     | 0          | n          |
+---------------------------------+----------+------------+------------+
| Raster Modules                  |          |            |            |
|                                 |          |            |            |
| (See also SDTS Part 1, Section  |          |            |            |
| 5.7, Raster Modules)            |          |            |            |
+---------------------------------+----------+------------+------------+
| Raster Definition               | RSDF     | 1          | 1          |
+---------------------------------+----------+------------+------------+
| Layer Definition                | LDEF     | 1          | 1          |
+---------------------------------+----------+------------+------------+
| Cell                            | Cell[^4] | 1          | n          |
+---------------------------------+----------+------------+------------+
| Graphic Representation Modules  |          |            |            |
| (See also SDTS Part 1, Section  |          |            |            |
| 5.8, Graphic Representation     |          |            |            |
| Modules)                        |          |            |            |
+---------------------------------+----------+------------+------------+
| Color Index                     | CLRx     | 0          | 0 (Annex   |
|                                 |          |            | B)         |
+---------------------------------+----------+------------+------------+
| Text Representation             | TEXT     | 0          | 0          |
+---------------------------------+----------+------------+------------+
| Line Representation             | LNRP     | 0          | 0          |
+---------------------------------+----------+------------+------------+
| Symbol Representation           | SYRP     | 0          | 0          |
+---------------------------------+----------+------------+------------+
| Area Fill Representation        | AFIL     | 0          | 0          |
+---------------------------------+----------+------------+------------+
| Font Index                      | FONT     | 0          | 0          |
+---------------------------------+----------+------------+------------+
| All Vector Modules              | ‑‑       | 0          | 0          |
+---------------------------------+----------+------------+------------+
| Composite Modules               | FFxx     | 0          | 0          |
+---------------------------------+----------+------------+------------+

### 5.1 Global Information Modules

#### 5.1.1 Module Restrictions/Requirements: Identification Module

(See also SDTS Part 1, Section 5.2.1 and Table 10, Identification)

There will be only one Identification module, and it must contain at
least one record.

Specific subfield requirements/restrictions:

a)  The Profile Identification PRID subfield must minimally have the
    value \"SRPE: SDTS RASTER PROFILE and EXTENSIONS\".

b)  If options described in the Normative Annexes of this profile are
    implemented in a transfer, each implemented annex must be indicated
    by adding a \"/\" and the upper case letter of the annex to the
    Profile Identification subfield. Any combination of annexes may be
    implemented in a transfer. For example, if a transfer implements
    Annex A, Profile Identification PRID subfield would contain an "/A".

c)  The Profile Version PRVS subfield must have the version identifier,
    if applicable, followed by the cover date of the profile. (Example:
    VER 1.1 1998 01 or JUNE 1998)

d)  The Profile Document Reference PDOC subfield must contain "Federal
    Geographic Data Committee" and any applicable document control
    numbers. (Example: Federal Geographic Data Committee
    FGDC-STD-002.5-1998.)

e)  The External Spatial Reference EXSP subfield must have the value of
    \"1\" indicating that, YES, one of the three recommended systems
    identified in Section 4.4.1 of this document is used; or, the value
    \"2\" indicating that another projection, besides those in level 1,
    is being used; or, "3" indicating that indirect referencing is used
    or that a warped grid image is being transferred.

f)  The Features Level FTLV subfield is permitted to be either \"1\",
    \"2\", \"3\" or \"4\". Note that if SDTS is not the authority for
    any entity and (or) attribute term, then the Features Level subfield
    must be valued as \"4\".

g)  The Attribute ID field is permitted and is used to reference global
    information (i.e., metadata) that applies to the entire transfer.

#### 5.1.2 Module Restrictions/Requirements: Catalog/Directory

(See also SDTS Part 1, Section 5.2.2.1 Catalog/Directory)

To ensure the contents of a transfer are independent of the transfer
media, the following restrictions are placed on the primary field of the
Catalog/Directory module:

> a\. The Volume subfield will not be used.
>
> b\. The File subfield will not include a directory path, only a file
> name meeting the requirements of Section 6.5 of this document.

#### 5.1.3 Module Restrictions/Requirements: Catalog/Spatial Domain

(See also SDTS Part 1, Section 5.2.2.3 Catalog/Spatial Domain)

The following requirements apply to the Catalog/Spatial Domain field in
the Catalog/Spatial Domain module:

> a\. Either the Domain or Map subfields or both are required so that
> the coverage of the module is indicated.

b\. The Theme subfield is required for all data sources that separate
data into themes.

> c\. Where appropriate, the Aggregate Object Type subfield must contain
> the raster object representation codes (G2 or G2W) indicating that the
> module references a raster.

#### 5.1.4 Module Restrictions/Requirements: Internal Spatial Reference

(See also SDTS Part 1, Section 5.2.4.1 Internal Spatial Reference)

The X subfield of spatial addresses must be used only for longitude,
easting, or equivalent values. The Y subfield must be used only for
latitude, northing, or equivalent values. Therefore, for SDTS level 1
External Spatial Reference conformance, the Spatial Address X Component
Label subfield is restricted to \"LONGITUDE\" when the external spatial
reference system is geographic and \"EASTING\" when the external spatial
reference system is UTM/UPS or SPCS. Also for level 1 conformance, the
Spatial Address Y Component Label subfield is restricted to \"LATITUDE\"
when the external spatial reference system is geographic and
\"NORTHING\" when the external spatial reference system is UTM/UPS or
SPCS.

The Scale Factor X, Scale Factor Y, X Origin, and Y Origin subfields in
the Internal Spatial Reference field are required. These subfields
specify the scaling and translation required to transform spatial
addresses from the internal spatial reference to the external spatial
reference (see SDTS Part 1, Section 5.2.4.1 Internal Spatial Reference).
The Registration module can also be used to specify this transformation.
If the Registration module is used to convert from internal to external
coordinates, subfields containing scaling factors and the origin of the
external system are optional. Otherwise, the subfields are mandatory and
must not be null. If no transformation is required, scaling factors of
1.0 and origin of 0.0 will indicate the identity transformation.

The Internal Spatial Reference module describes the resolution for the
spatial dimension. The External Spatial Reference module defines the
units and coordinate system for the resolution. The X Component of
Horizontal Resolution (XHRS), Y Component of Horizontal Resolution
(YHRS), and the Vertical Resolution Component (VRES) subfields will be
real numbers.

The Dimension Id (DMID) field must not be present because nongeospatial
dimensions are not permitted.

#### 5.1.5 Module Restrictions/Requirements: External Spatial Reference

(See also SDTS Part 1, Section 5.2.4.2 External Spatial Reference)

There must be only one External Spatial Reference module per transfer,
with only one record. All spatial data in the same SDTS transfer must be
referenced to the same external spatial reference system.

The Reference System Name RSNM subfield must have the value \"GEO\",
\"SPCS\", \"UTM\", \"UPS\", or \"OTHR\" depending upon the external
spatial reference system being used. In the case of a G2W object, the
value "OTHR" must be used.

### 5.2 Data Quality Modules

(See also SDTS Part 1, Section 5.3, Data Quality Modules)

A common set of Data Quality modules may be used for an entire series of
files to be distributed. These Data Quality modules may be made
available separately; and they need not be duplicated within each SDTS
transfer. If the SDTS Data Quality modules are separate from the
individual SDTS transfer data set, then they will be uniquely identified
and referenced by the individual SDTS transfer data set. (See SDTS Part
1, Sections 4.1.3.3.1 Modules within a Spatial Data Transfer (clause
(e)), and 5.2.2.1 Catalog/Directory, subfields External and Module
Version.)

Requirements for contents of data quality modules are as specified in
SDTS Part 1, Section 3, and additionally in Section 3 of the SRPE.

### 5.3 Attribute Modules

(See also SDTS Part 1, Section 5.4 Attribute Modules)

Attribute modules are permitted by the SRPE. Attributes can be specific
to individual layers and (or) to the entire raster, but not individual
cells within the raster.

### 5.4 Composite Modules

These modules are not permitted by the SRPE.

### 5.5 Vector Modules

These modules are not permitted by the SRPE.

### 5.6 Raster Modules

(See also SDTS Part 1 Section 5.7 Raster Modules)

SRPE permits either the default or non‑default implementation. If the
transfer is a default implementation, rules in SDTS Part 1, Section
5.7.3 Default Implementation, regarding subfield name and default value
apply. The default implementation is strongly recommended for raster
transfers.

#### 5.6.1 Module Restrictions/Requirements: Raster Definition

a)  One Raster Definition module record represents one raster object.

b)  One Raster Definition module may have one or more records.

c)  One Raster Definition module record may have one or more Layer Id
    fields.

d)  Each Raster Definition module record must reference different Layer
    Definition module records.

e)  For object code G2W, the data encoder may optionally encode the
    geometric correction parameters in SDTS Attribute Primary Module(s)
    records that are referenced by the Raster Definition Module record.

f)  Compression and tesseral indexing are not permitted.

##### 5.6.1.1 Specific Subfield Restrictions:

a)  Object representation code OBRP must be "G2" or "G2W".

b)  Cell Sequencing Code CSCD must be "GI" or "GJ" or "GL".

c)  Default Implementation DEFI must be "DEF" (highly recommended) or
    "NON".

d)  Data Compression CMPR must be "NON".

e)  Scan Origin SCOR must be "TL" (top left origin).

f)  Scan Pattern SCPT must be "LINEAR".

g)  Tesseral Indexing TIDX must be "NOTESS".

h)  Number of Lines per Alternation ALTN must be "1".

i)  First Scan Direction FSCN must be "R" (by row).

j)  Raster Dimension Extent RDXT field is not permitted.

k)  X-, Y-, Z-, Dimension Axis Label (XXLB, YXLB, ZXLB, DALn) fields are
    not permitted.

#### 5.6.2 Module Restrictions/Requirements: Layer Definition

a)  One Layer Definition module may have many records.

b)  One Layer Definition module record describes one layer of a single
    raster object.

c)  One Layer Definition module may contain records describing layers
    from one or more raster objects.

d)  Each Layer Definition module record may be referenced by one and
    only one Raster Definition module record.

e)  One Layer Definition module record will reference one Cell module.
    More than one Layer Definition module record can reference the same
    Cell module, and this means that the layers' cell values are
    interleaved (code GJ and GL). If no interleaving (code GI), then
    each layer has its own Cell module.

##### 5.6.2.1 Specific Subfield Restrictions:

a)  Number of Rows NROW subfield must be equal to the value Row Extent
    RWXT of the referencing Raster Definition module record.

b)  Number of Columns NCOL subfield must be equal to the value Column
    Extent CLXT of the referencing Raster Definition module record.

c)  Scan Origin Row SORI subfield must be "1".

d)  Scan Origin Column SOCI subfield must be "1".

e)  Row Offset Origin RWOO subfield must be "0".

f)  Column Offset Origin CLOO subfield must be "0".

#### 5.6.3 Module Restrictions/Requirements: Cell

a)  One Cell module may have many records.

b)  One Cell module is not permitted to contain cell values from
    different raster objects. All of the cell values in all of the
    module records of a Cell module must be for a single raster object.

c)  One Cell module is not permitted to contain cell values from
    different layers, unless the layers are interleaved with code GL or
    GJ.

d)  One Cell module record contains one or more cell values from a
    single raster object. If the Cell Sequencing code is GI then one
    Cell module record contains cell values from only a single layer. If
    the Cell Sequencing code is GL or GJ then one Cell module record
    contains cell values from every layer of a single raster object.

e)  It is highly recommended that a single Cell module record contain a
    row worth of data or the entire raster, unless this becomes
    unreasonably long (as defined by current technology.) A single Cell
    module record may contain partial, one, or many rows of the raster.

f)  The data type of the cell value subfield(s) must be one of binary,
    integer, or real (specifically I, R, BI8, BI16, BI32, BUI8, BUI16,
    BUI32, BFP32).

##### 5.6.3.1 Specific Subfield Restrictions/Requirements: 

a)  Row Index ROWI subfield is required.

b)  Column Index COLI subfield is required.

c)  Cell Values CVLS field is required.

d)  Plane Index PLAI subfield is not permitted.

e)  Tesseral Index TIND subfield is not permitted.

f)  Dimension Index DNDX Field is not permitted.

g)  Attribute Id ATID field is not permitted.

h)  Cell Coding Foreign Id CFID field is not permitted.

### 5.7 Graphic Representation Module

(See also SDTS Part 1, section 5.8, Graphic Representation Modules)

These modules are not permitted by the SRPE.

## 6 ISO 8211 Specific Decisions

(See also ANSI/ISO 8211‑1985 (a.k.a. FIPS PUB 123) Specifications for a
Data Descriptive File for Information Interchange, and SDTS Part 3, ISO
8211 Encoding)

### 6.1 Objective

(See also SDTS Part 3, Sections 1.1 and 1.2, Purpose and Objectives):

SDTS/ISO 8211 is optimized for retrieval and storage (versus interactive
decoding); non‑SDTS directories/indices may be added to allow such
interactive decoding (e.g. on a CD‑ROM media). These files are not
considered part of the transfer when it comes to determining compliance,
and they should not be described in the Catalog/Directory module
records.

### 6.2 Relationship of Modules to ISO 8211 Files

(See also SDTS Part 1, Section 4.1.3 The Transfer Model, and SDTS Part
3, Section 7, Assignment of Fields to Records and Files)

a)  A file (an ISO 8211 Data Descriptive File (DDF)) shall contain one
    and only one module. All raster profile files must have only fields
    from the same module in any particular record and file, i.e. each
    file will represent only a single module. Normally, a module will
    only occupy a single file.

b)  A module may span files when the size of a single file would exceed
    volume capacity or a reasonable size constraint (as determined by
    current technology). The data encoder should keep files as large as
    practical, to keep the overall number of files to a minimum.

### 6.3 Media

(See also SDTS Part 3, Section 10, Media Requirements)

All files belonging to the same transfer must share the same first four
characters or base name. A base name of \"HYDR\" would result in file
names like: HYDRIDEN.DDF, HYDRCATD.DDF, HYDRLE01.DDF, etc. When a volume
contains a single transfer, the volume name is recommended to begin with
the four character base identifier of the transfer. When multiple
transfers are contained on a volume, the first four characters of the
volume name are recommended to be \"SDTS\". For multi‑volume transfers,
the first four characters are recommended to be the base name, and the
whole name should consistently reflect the volume sequence.

### 6.4 Organization of Files on Media

In general, files comprising a single transfer shall be kept separate
from any other transfer files and organized as follows:

a)  On floppy disk and CD‑ROM, or any random access medium, each
    transfer must be grouped completely in a single directory. Multiple
    transfers may reside on the same media volume, with each in its own
    subdirectory.

b)  On magnetic tape, or any sequential access medium, files of a single
    transfer must be ordered by module type, following the order of
    presentation in SDTS Part 1, Section 5. File adjacency will be used
    to group transfer files when multiple transfers reside on the same
    media volume. All files that follow the Identification Module (first
    file of a transfer) until another Identification Module or an end of
    media marker is encountered will be considered part of the transfer.

c)  A file called \"README\" is required (see SDTS Part 3, Section 11,
    Conformance). There may be one such file per medium volume or
    transfer. (This file must be the first file on sequential media such
    as a magnetic tape.) Content of the README file is discussed later
    in this section.

d)  To reduce the number of files and file sizes, file packing and
    compression utilities may be used to facilitate distribution on any
    media including electronic distribution over a network. However, the
    transfer file set is only considered for compliance to the SRPE in
    an unpacked, non file-compressed state. Specifically, all or some of
    the files may be packed into a single file that may be compressed.
    (Data providers should insure that utilities to unpack and
    decompress the files are available to the data consumers.)

### 6.5 File Names

For consistency among file names from various agencies, the SRPE
requires that file names begin with a 4-character base followed by the 4
character module name contained in the file. A single transfer data set
must use the same first four characters in the file name of each SDTS
ISO 8211 file in the entire transfer. The next four characters in the
file name must be the unique name of the module transferred in that file
(see naming convention for modules in Section 4.1 of Part 4). The file
extension should be \".DDF\" to indicate the type of the file is ISO
8211. For example, the files named 6642IDEN.DDF, 6642RSDF.DDF,
6642IREF.DDF would all belong to the same transfer.

In the case of modules that span files, the last character of the file
extension or an optional ninth character on the base name may be used to
indicate file sequence. For example, if a single file could not contain
all the information required for a Cell module, the information would be
transferred in files 6642CELL.DDF, 6642CELL.DDG, 6642CELL.DDH or
6642CELL1.DDF, 6642CELL2.DDF, 6642CELL3.DDF. Any file that is not ISO
8211 compliant (e.g. adjunct files) must not have the \".DDx\"
extension.

Letters in the file names can be upper or lower case. The file names in
the Catalog/Directory module records must match the case of the file
names when the transfer is originally produced. The file title stored
inside of an ISO 8211 file is recommended to match the case of the file
name. Copying files between media and operating systems can often change
the case of the file name. Robust software should take this into
consideration when using the file names from the Catalog/Directory
module records to access the files.

### 6.6 Taking Advantage of Dropped Leader and Directory

(See also SDTS Part 3, Section 6.4, Repeating Fields and Records)

SRPE encourages taking advantage of ISO 8211 mechanisms to reduce file
size. All modules are recommended to use fixed size fields whenever
practical to allow for the dropping of leader and directory information
from the data records in ISO 8211. In the case where there are a few
records that exceed the fixed size fields\' size, records may be ordered
within a file to maximize the use of dropped leaders and directories.
This means that exceptional data records (DRs) is recommended be placed
first in the DDF. All records that can share a common leader and
directory can be grouped at the end of the file. (This is necessary
because once the leader and directory are dropped, they cannot be
specified later in the file.)

Maximizing the use of dropped leaders and directories needs to be taken
into consideration when designing attribute modules. Attributes that
range widely in the length of their values (i.e. open text) may be
optimally placed in a separate module.

### 6.7 ISO 8211 DDR Contents

a)  Data descriptive fields that have no specified labels may be
    augmented by user‑supplied labels for the identification of subfield
    data. An import system is not required to recognize user‑supplied
    labels.

b)  Subfield labels for the horizontal components of spatial address
    fields must be \"X\" and \"Y\".

c)  The first part of the file title must be consistent for all files
    within the transfer, but the last part should be unique for each
    file and give some indication of the contents of that file. This
    file title should be equivalent to the eight character base name
    (plus the optional ninth character).

### 6.8 Use of Data Types for Cell Values

The following data types may be used for cell values:

  -----------------------------------------------------------------------
  []{#__RefHeading___Toc431887637 .anchor}Table 6.8 -- Cell Value Data
  Types

  I (Integer)

  R (Real)

  BI8,BI16,BI32

  BUI8,BUI16,BUI32

  BFP32
  -----------------------------------------------------------------------

a\) In the case where all DRs in a DDF contain the same number of
repetitions, a user‑calculated repeat factor is used in the format
control for the field. A format control for a cell value type field has
the form:

> (n(D(w)))
>
> where n = the number of cells
>
> D = indicates cell data type \[ I \| R \| B\]
>
> w = specifies the width of the value

(225(B(8),B(16),B(8))) Every data record has 225 repetitions of a
3-tuple value set, with first an 8-bit binary, second a 16-bit binary,
and third an 8-bit binary. This would indicate a three layer raster
encoded as interleaved by pixel.

b\) In the case where each DR in a DDF contains a different number of
repetitions, the following format control is used:

> ((D(w)))
>
> where D = indicates cell data type \[ I \| R \| B\]
>
> w = specifies the width of the value
>
> ISO 8211 does not permit a binary field located after the left
> parenthesis to implicitly repeat. Therefore, the above format includes
> an additional pair of parentheses.

### 6.9 Use of Character Data Type for Dates

(See also SDTS Part 3, Section 9.2 Dates)

Dates in the form YYYYMMDD are to be encoded as ISO 8211 data type = A.

### 6.10 README File

(See also SDTS Part 3, Section 11 Conformance)

The README file is recommended to contain:

a)  volume name, if applicable;

b)  date the README was written;

c)  information about the SDTS transfer(s) which includes but is not
    limited to the following:

1\. a list of subdirectories and non‑SDTS files, as appropriate;

2\. the file name of the Catalog/Directory module;

3\. the Catalog/Directory location;

4\. an explanation that this file and all other SDTS files are in ISO
8211 format;

> 5\. an explanation that the Catalog/Directory module carries a
> complete directory of all other SDTS ISO 8211 files comprising the
> SDTS transfer;

6\. notes about any non‑SDTS adjunct/auxiliary files;

7\. a brief explanation of the spatial domain;

8\. purpose;

9\. authority (e.g., FIPS PUB 173, this profile, other standards used);

10\. source (e.g. agency name);

11\. contacts within the source organization;

> 12\. description of any issues about the transfer, special purposes
> (i.e. private agreement transfer) or non-standard uses of modules,
> etc.

#  ANNEX A: SDTS BIIF EXTENSION

(Normative)

## 1 Introduction

This annex option permits the use of the ISO/IEC 12087-5 Basic Image
Interchange Format (BIIF) as an adjunct file in an SDTS transfer for the
purpose of encoding an image and its related information. All other
stipulations of the main body of this profile apply, unless specifically
addressed in this annex option. To indicate that this annex option is in
effect, an "/A" must be appended to the Profile Identification subfield
value of the Identification module record. (Certain sections marked as
informative provide explanatory information that does not constitute any
binding requirements for conformance.)

### 1.1 References

The following references contain provisions either by direct reference
or relationship, which through references in this paragraph or within
this text, constitute provisions of SRPE. At the time of publication,
the editions reflect the document versions used for implementing the
SRPE. Revisions to referenced standards that post-date this document,
and do not cause ambiguity or change to this profile may be used without
violating compliance. For clarification, contact the profile maintenance
authority.

> ISO/IEC 12087-5 - Information Technology Computer Graphics and Image
> Processing, Image Processing and Interchange Functional Specification
> Part 5: Basic Image Interchange Format (BIIF), 1998.
>
> NIMA N0105-97: - NITFS Standards Compliance and Interoperability Test
> and Evaluation Program Plan, 6 March 1998. Supersedes JIEO/JITC
> Circular 9008.
>
> MIL-STD 2500B National Imagery Transmission Format (NITF) Version 2.1,
> Draft 1997; Available from the National Imagery and Mapping Agency,
> Attn: NIMA, Customer Support/COD, Mail Stop P-38, 12310 Sunrise Valley
> Drive, Reston, VA 20191-3449. (Online information at
> [http://www.itsi.disa.mil](http://www.itsi.disa.mil/) or
> http://jitc-emh.army.mil/nitf/nitf.htm.
>
> MIL-STD 188-198A Joint Photographic Experts Group (JPEG) Image
> Compression for the NITFS, December 15, 1993.
>
> MIL-STD 188-196 Bi-Level Image Compression for the NITFS, June 18,
> 1993.
>
> NSIF BIIF Profile, equivalent to the NITF BIIF Profile; To be
> developed by the Format Working Group under the auspices of the NITF
> Technical Board based on MIL-STD 2500B; Not Yet Drafted; Scheduled for
> completion November 1998.
>
> STANAG 4545 NATO Secondary Imagery Format (NSIF), Ratification Draft
> 1, 15 April 1997. (See DIGEST Annex D for the Geospatial Support Data
> Extension)
>
> DMA Technical Manual 8358.1 Datums, Ellipsoids, Grids, and Grid
> Reference Systems, Edition 1, September 1990. The DMA Technical Manual
> 8358.1 provides information that is useful when implementing datums,
> ellipsoids, grids and grid reference systems.
>
> ISO/IEC 8632-3:1994 Information technology - Computer graphics -
> Metafile for the storage and transfer of picture description
> information - Part 3: Binary encoding Amendment 1:1994 to ISO/IEC
> 8632-1:1992 Rules for profiles Amendment 2:1995 to ISO/IEC 8632-1:1992
> Application structuring extensions.
>
> STANAG 7074/A GeoP-3A Digital Geographic Information Exchange Standard
> (DIGEST), Edition 2, June 1997. Online at http://www.digest.org. Note:
> Annex D of DIGEST Part 2 provides the source for the geospatial
> extension to the NSIF BIIF Profile.

### 1.2 Background of BIIF *(Informative)*

BIIF was developed from a complement of military, ANSI, ISO, and NATO
standards which were derived from the U.S. Military Standard 2500
National Imagery Transmission Format Standard (NITFS) and JIEO/JITC
Circular 9008. The NITFS is a format initially developed for the
transmission of military intelligence and digital mapping, charting and
geodetic products, and is now being expanded to include commercial
requirements.

BIIF is formally recognized as ISO/IEC 12087-5, approved in April 1998.
NITF is ratified as a military standard and is implemented. NATO is
sponsoring the development of STANAG 4545 - National Secondary Image
Format (NSIF) which is a NATO implementation of NITF, and is currently a
Ratification Draft. Because the NSIF and NITF are fundamentally similar
documents, the evolution of the BIIF profile will be a collaboration of
NATO and US military standards under NSIF.

BIIF defines a general mechanism for the transfer of image data and any
supporting data (i.e. image parameters, visualization parameters,
compression parameters, text annotations, symbols, etc.) BIIF is a
standard developed to provide a foundation for interoperability in the
interchange of imagery and imagery-related data among applications. BIIF
is intended to be used to transfer any digital image\-\--x-rays,
fingerprints, portraits, aerial photography, remotely sensed data, etc.
An profile to BIIF is prepared and registered based on the requirements
of a data producer/user community for a certain application domain.
Registration of profiles will encourage collaborative interface of data
between domains. For example, potential profiles for the law enforcement
community and medical community might include a common method for
dealing with personal identification data, i.e., fingerprints, photo id,
DNA-mapping, and x-rays. The BIIF profile for NSIF/NITF will herein be
referred to as the NSIF Profile.

## 2 BIIF Restrictions/Requirements

The restrictions and/or requirements placed on the use of BIIF originate
from the following sources: 1) the ISO 12087-5 standard; 2) the NSIF
profile to BIIF; and, 3) this profile annex option which includes the
BIIF notes in the base SRPE standard.

All requirements of the NSIF profile and its references to the BIIF
standard apply in this annex unless specifically addressed by this
profile annex option. A BIIF file compliant to the NSIF Profile shall
herein be referred to as a "BIIF file". This annex option addresses
requirements that are supplemental or alternative to the NSIF ISP.

### 2.1 BIIF Standard Data Types

(See BIIF Clause 4.1.1.2 Standard Data Types)

BIIF recognizes three standard types of data: image, symbol, and text. A
BIIF file can include zero, one, or more data segments of each standard
type. As per BIIF clause 4.1.1.2, the order of data segments in a BIIF
file must be all image data segments, followed by all symbol data
segments, followed by all text data segments, followed by any extension
segments.

All restrictions and requirements placed on the use of BIIF data
segments by the NSIF Profile apply, unless specifically addressed by
this profile annex option. This profile annex option requires the BIIF
file to include at least one image data segment. A conformant decoder
under this profile annex option must be able to decode any image data
segment, and optionally may decode any symbol or text segments. In all
cases, a decoder must report the presence of all segments, whether it
can decode them or not.

### 2.2 Two Dimensions

(BIIF Clause 4.1.4 Logical structure of pixel storage)

BIIF images are two-dimensional. PIKS images can be up to
five-dimensional (BIIF Clause 4.2.5.7 PIKS Objects). This profile annex
option only requires a decoder to support the x and y spatial dimensions
of a baseline BIIF image.

### 2.3 BIIF Data Extensions

(See BIIF Clause 4.1.1.3 Extensions)

BIIF extensions are a way to include information not explicitly
accounted for in the standard. There are three types of extensions:
tagged record extensions (TRE), data extension segments (DES), and
reserved extension segments (RES). A Tagged Record Extension (TRE) is a
way to provide additional description about BIIF standard data segments
not provided for in BIIF standard defined fields. The DES and RES are
intended primarily for adding support for new types of data (other than
image, symbol, and text). (Although, a data encoder may use this in
place of a standard data segment this practice is discouraged as it
limits the ability to decode the data.)

All restrictions and requirements placed on the use of BIIF extensions
by the NSIF Profile apply, unless specifically addressed by this profile
annex option. A conformant decoder implementing this annex option must
be able to handle the receipt of unknown extension types by ignoring
them without program error, and reporting the existence to the data
consumer.

#### 2.3.1 Geospatial Support Data Extension Segment

This annex option permits an image in BIIF to be georeferenced or not.
When a BIIF file is used to transfer georeferenced data, the BIIF
Geospatial Support Data Extension Segment must be used to encode the
georeferencing parameters. The georeferencing parameters may be
duplicated in both SDTS and BIIF. This profile annex option does not
permit an image to be encoded in BIIF and its georeferencing to be
encoded only in SDTS structures. (Since georeferencing is machine
processable information it should be as integrated as possible.)

#### 2.3.2 Lineage-related Tagged Record Extensions

There are some TREs that provide for lineage or processing and source
description information. SDTS also provides structures through its Data
Quality Modules and attribute mechanism for encoding lineage type
information. Lineage information is often textual narration and
generally read and acted on by the user, rather than being trusted to
machine interpretation and use. The SRPE highly recommends that the
lineage content be based on the elements in the FGDC Content Standards
for Digital Geospatial Metadata. This profile annex option highly
recommends that the majority of the Lineage information and other such
data quality information be encoded in SDTS structures, thus keeping the
"non-machine processable" information in the BIIF file to a minimum.
(This recommendation is in the interest of convergence, i.e., rather
than duplicating the geospatial information requirements in a general
purpose image standard, use an existing geospatial transfer standard for
this.)

The data encoder shall not encode data where the relationship between
the metadata and the image data is ambiguous. The relationship between
the SDTS structures and the BIIF structures must be stated in the SDTS
Logical Consistency module.

### 2.4 Compression

Compression is permitted as specified by the NSIF Profile. JPEG
compression is permitted as per MIL-STD 188-198A. Bi-level is permitted
as per MIL-STD 188-196. Vector Quantization(VQ) is permitted as per
ISO/IEC 12087-5 (BIIF) Annex B: Vector Quantization. Other compression
formats and methods are not permitted.

The NSIF profile requires decompression of VQ, Bi-level, JPEG (lossy and
lossless) and compression using JPEG. Compression support for VQ and
Bi-level are optional.

### 2.5 BIIF File Header

(See BIIF Clause 4.2.3 Header, Table 1: Header)

To indicate that this SDTS profile option is in effect in a BIIF file,
the Originator Identification (OID) field of the BIIF File Header, may
optionally include the value "SDTS-SRPE" in addition to any other
values.

### 2.6 BIIF Image Subheader

(See BIIF Clause 4.2.4 Image Segment, Table 3: Image Subheader)

To indicate that this image is part of an SDTS transfer, the Image
Information (IINFO) field may optionally include a statement to alert
the data consumer of additional information in SDTS files.

## 3 SDTS Restrictions/Requirements

A BIIF file with or without georeferencing is permitted to be included
in an SDTS Transfer. One or more BIIF files are permitted in a single
SDTS transfer file set. Each separate BIIF file must contain at least
one image.

The BIIF file is intended to be a substitute for the SDTS Cell Module
encoded in ISO 8211 format. In this case, the Layer Definition module
record would reference the BIIF file id and there would be no SDTS Cell
Module file. All other modules in the transfer would be the same as if
the raster data were encoded in the Cell Module, except they need to
describe the data as it is encoded in the BIIF file.

This profile annex option permits a BIIF file to be included as a
supplement to a SDTS Cell Module. In this case, the Layer Definition
module record would reference the Cell Module, as before. The BIIF file
would be related to the Cell Module through a Catalog/Cross-reference
module record, where the comment field would explain the relationship.

All methods of georeferencing supported by the Geospatial Support Data
Extension Segment are permitted in this profile annex option. In the
event the georeferencing method encoded with the Geospatial Support DES
is not supported by SDTS, the georeferencing method will be encoded in
SDTS descriptions as "unspecified". If the georeferencing method is a
projected coordinate system, then the projection parameters must be
encoded in the Geospatial Support DES structure and are not required to
be encoded as SDTS attributes.

The NSIF profile permits bi-level, vector quantization, and JPEG (lossy
and lossless) compression. This profile annex options permits any of
these compression options, or no compression. The data should be
described as it is encoded in the BIIF file.

### 3.1 SDTS Restrictions/Requirements: Identification Module

To indicate that this profile annex option is in effect, an "/A" must be
appended to the value in the Profile Identification (PRID) subfield.

The External Spatial Reference (EXSP) subfield must be "1", if UTM/UPS,
SPCS, or Geographic is encoded in the Geospatial Support DES; "2", if a
projected system is encoded in the Geospatial Support DES; "3", if the
georeferencing method encoded using the Geospatial Support DES is not
supported by SDTS, or if no Geospatial Support DES is used.

The Coding Level (CDLV) subfield must be "1" when a BIIF file is
substituted for a Cell Module.

### 3.2 SDTS Restrictions/Requirements: Catalog/Directory Module

The Name (NAME) subfield must contain an identifier to uniquely
reference a single BIIF file.

The Type (TYPE) subfield must contain "BIIF".

The External (EXTR) subfield must contain "A", indicating an adjunct
file is included.

### 3.3 SDTS Restrictions/Requirements: Catalog/Cross-Reference Module

If a BIIF file is a supplement to a Cell Module, then this relationship
must be expressed through a Catalog/Cross-reference module record with
the relationship explained in the Comment subfield.

### 3.4 SDTS Restrictions/Requirements: External Spatial Reference Module

The Reference System Name (RSNM) subfield must be "GEO" when a latitude
and longitude system is used; "SPCS" when State Plane Coordinate System
is used; "UTM" when UTM is used; "UPS" when UPS is used; "OTHR" when a
Projected Coordinate system is used; or, "UNSP" when anything else or
when the Geospatial Support DES is not used at all.

The Attribute ID (ATID) subfield is not required, when Reference System
Name is "OTHR". This means that the projection parameters are not
required to be encoded as SDTS attributes because they are already
encoded in the Geospatial Support DES structures.

### 3.5 SDTS Restrictions/Requirements: Data Dictionary/Schema Module

The Type (TYPE) subfield should contain "CELL" even when the raster data
is in a BIIF file.

### 3.6 SDTS Restrictions/Requirements: Data Quality Modules

If there are multiple BIIF files included in a single SDTS transfer file
set, then the relationship among the files and the images they contain
must be explained in the Logical Consistency module, at a minimum.

If a BIIF file represents a visualization of more fundamental raster
data stored in a SDTS Cell Module, then the process used to generate the
image must be described in the Lineage Module, at a minimum.

### 3.7 SDTS Restrictions/Requirements: Raster Definition Module

If BIIF file uses the JPEG option, then the Data Compression Method
(CMMD) subfield must contain "NITF-JPEG"; if vector quantization, then
"NITF-VQ"; if bi-level, then "NITF-BILEVEL".

The Decompression parameters (DCOM) subfield is not required, as the
BIIF file must contain all information needed to decompress the data.

The Coding Method (METH) subfield must contain "BIIF" to indicate that a
BIIF file is used to encode the data for this raster object, instead of
a SDTS Cell Module.

### 3.8 SDTS Restrictions/Requirements: Layer Definition Module

The Cell Module Name or Adjunct File id (CMNM) subfield must contain the
identifier for the BIIF file. This must match the identifier used in the
Catalog/Directory module.

### 3.9 SDTS Restrictions/Requirements: Cell Module 

If the BIIF file is substituted for the Cell Module, then no Cell module
is present.

If a BIIF file is just a supplement, then the Cell Module is present, as
before.

### 3.10 File Naming Convention

In addition to the file naming conventions in the core SRPE, any adjunct
BIIF file is recommended to have the file extension ".bif". The file
name is recommended to start with the same four characters as the rest
of the SDTS files in the transfer.

#  ANNEX B: COLOR INDEX MODULE OPTION 

(Normative)

## 

## 1 Introduction

This annex option permits the use of the SDTS Color Index Module (SDTS
Part 1, Section 5.8.5, Color Index ) to carry color table information
for raster data. All other stipulations of the main body of this profile
apply, unless specifically addressed in this annex option. To indicate
that this annex option is in effect, a "/B" must be appended to the
Profile Identification subfield value of the Identification module
record.

(Note: For color model options other than provided by this annex, see
Annex A BIIF Extension and Annex E GeoTIFF Extension.)

BIIF Note: In the case of using the BIIF option the following applies.
If BIIF is used to encode an image, then use the BIIF color mechanism to
encode color information. BIIF Clause 4.2.4.2 Look-up Tables (LUTS) and
Table 3: Image subheader Fields IREP and IREPBAND1 describe options for
encoding color.

## 2 SDTS Restrictions/Requirements

The SDTS Color Index Module must only be used to describe color
information for raster data in a SDTS Cell Module. The Color Index
module is used to transfer color palettes. A color palette's (color
table) values for red, green, blue and/or black, are converted to the
corresponding red, green, blue, and/or black component subfields of the
color index module records. Color values are real numbers normalized
between 0.0 and 1.0. The encoder decides the number of significant
digits.

The method for associating color values with a pixel is as follows. A
SDTS Cell Module and its Color Index Module are related by a SDTS
Catalog/Cross-Reference module record that minimally contains the phrase
"Color lookup for raster" in the Comment subfield. The raster cell value
(which must be of data type integer) is used to reference a module
record in the associated Color Index Module. The normalized red, green,
blue and optional black color component values from the module record
with the record id matching the raster cell value are used to display a
device dependent color for the corresponding pixel.

### 2.1 Module Restrictions/Requirements: Identification Module

To indicate that this profile annex option is in effect, an "/B" must be
appended to the value in the Profile Identification (PRID) subfield.

### 2.2 Module Restrictions/Requirements: Catalog/Cross-reference Module

There must be one module record to describe each Cell Module and Color
Index Module relationship. The Comment (COMT) subfield must, minimally,
include the phrase "color lookup for raster".

### 2.3 Module Restrictions/Requirements: Color Index Module

Multiple Color Index modules are permitted in one SDTS Transfer. One
Color Index module corresponds to one color palette. Each SDTS Cell
Module can be associated with zero or one Color Index Module. One Color
Index module can be associated with one or more Cell Modules.

#### 2.3.1 Color Index Module Names

If a single Color Index module is used, then its name will be CLRX. If
two or more color palettes are transferred, the first module name and
primary field name must be CLR0. The second module name and primary
field name must be CLR1. This pattern will continue through CLR9. Once
the module names CLR0 and CLR9 are used, the names must continue through
CLRA, CLRB, CLRC, etc.

#  ANNEX C: COMPRESSED RASTER OPTION

(Normative)

## 1 Introduction

This annex option permits the transfer of compressed raster data.
Compression algorithms other than those identified herein are not
permitted by this annex option. All other stipulations of the main body
of this profile apply, unless specifically addressed in this annex
option. To indicate that this annex option is in effect, a "/C" must be
appended to the Profile Identification subfield value of the
Identification module record. This annex option is limited to
compression of the raster data, not general file compression (see SRPE
Section 6.4d.)

### 1.1 References

The following references contain provisions either by direct reference
or relationship, which through references in this paragraph or within
this text, constitute provisions of this annex option. At the time of
publication, the editions indicated were valid. All standards are
subject to revision, and parties to agreements based on SRPE should
investigate any recent editions of the references listed below.

ISO/IEC 10918-1:1994 Information Technology - Digital Compression and
Coding of Continuous Tone Still Images: Requirements and Guidelines
(a.k.a. JPEG)

JPEG File Interchange Format (JFIF), Version 1.02, available on-line
from ftp://ftp.uu.net/graphics/jpeg

Pennebaker, William B. and Joan L. Mitchell, JPEG Still Image Data
Compression Standard, 1993, Van Nostrand Reinhold, ISBN 0-442-01272-1.
(Book contains complete text of DIS 10918-1 and 10918-2.)

## 2 Compression Methods

This profile annex option specifies the permitted compression methods
for use within an SDTS module and within stand-alone adjunct files (a
combination of a compression algorithm and a file format). Note:
Compression methods applied to BIIF files or TIFF files are not
controlled by this annex option. Refer to Annex A and E, respectively,
for permitted extension compression methods.

Lossy methods must not be used on gridded data.

### 2.1 Run Length Encoding Compression

Run length encoding as described in SDTS Part 1, Section 5.7.10.1 is
permitted by this annex option. This compression method works within the
fields of the SDTS Cell Module (not requiring an adjunct file.) This
compression method is most applicable to gridded raster data, and is
lossless.

### 2.2 JPEG Compression in JFIF 

The ISO/IEC 10918-1 documents JPEG compression algorithms, which can be
used in many contexts. The JPEG File Interchange Format (JFIF) is a
specification of a file format to use with JPEG compression techniques.
Although any JPEG process is supported by the syntax of the JFIF, it is
recommended that the baseline algorithm in ISO/IEC 10918-1 be used to
ensure maximum compatibility with all applications supporting JPEG.

This annex option permits the use of JPEG compression algorithms to
compress raster data and encode in a standalone file as per the JFIF
specification. The JFIF file must then be treated as an adjunct file in
a SDTS transfer. Both lossless and lossy methods are permitted. The JPEG
compression methods are most applicable to image data. (For an alternate
way to use JPEG methods, see SRPE Annex A BIIF Extension, Section 2.4.)

### 2.3 Decompression Support

A conformant decoder must support decompression of SDTS Run Length
Encoding and JPEG JFIF methods. A conformant encoder must provide RLE
compression for gridded raster data and JPEG compression for image data.

## 3 SDTS Restrictions/Requirements

In SDTS, compression is specified at the raster object level; all layers
of a single raster object are compressed as a whole, or no compression
is used. This annex permits each raster object to specify compression
independent of other raster objects in the same transfer.

One or more JFIF files are permitted in a single SDTS transfer file set.

The JFIF file is intended to be a substitute for the SDTS Cell Module
encoded in ISO 8211 format. The Layer Definition module record must
reference the JFIF file id and there will be no SDTS Cell Module file.
All other modules in the transfer would be the same as if the raster
data were encoded in the Cell Module, except they need to describe the
data as it is encoded in the JFIF file.

### 3.1 SDTS Restrictions/Requirements: Identification Module 

To indicate that this profile annex option is in effect, a "/C" must be
appended to the value in the Profile Identification (PRID) subfield.

The Coding Level (CDLV) subfield must be "1" when a JFIF file is
substituted for a Cell Module. CDLV must be a zero or absent when the
SDTS RLE is used within a Cell Module. The CDLV must be set to the
highest applicable value for the entire transfer.

### 3.2 SDTS Restrictions/Requirements: Catalog/Directory Module

In the case of using JFIF the following applies:

> The Name (NAME) subfield must contain an identifier to uniquely
> reference a single JFIF file.
>
> The Type (TYPE) subfield must contain "JFIF".

The External (EXTR) subfield must contain "A", indicating an adjunct
file is included.

### 3.3 SDTS Restrictions/Requirements: Data Dictionary Modules

In the Data Dictionary/Schema Module, the Type (TYPE) subfield must
contain "CELL" even when the raster data is in a JFIF file.

For the case of the SDTS RLE option, the Cell Values (CVLS) fields'
subfield of RLECOUNT must be referenced in the Data Dictionary modules
with an Attribute Authority of "SDTS-RLE".

### 3.4 SDTS Restrictions/Requirements: Data Quality Modules

If there are multiple JFIF files included in a single SDTS transfer file
set, then the relationship among the files and the images they contain
must be explained in the Logical Consistency module, at a minimum.

If a lossy compression is used, then the process used to generate the
file must be described in the Lineage Module, at a minimum.

### 3.5 SDTS Restrictions/Requirements: Raster Definition Module

For the case of using the JFIF option the following applies:

> The Data Compression (CMPR) subfield must contain "COM".
>
> The Data Compression Method (CMMD) subfield must contain "JPEG-JFIF".
>
> The Decompression Parameters (DCOM) subfield may optionally reference
> an attribute record containing decompression parameters.
>
> The Coding Method (METH) subfield must contain "JFIF" to indicate that
> a JFIF file is used to encode the data for this raster object, instead
> of a SDTS Cell Module.

For the case of using the SDTS RLE option the following applies:

> The Data Compression (CMPR) subfield must contain "COM".
>
> The Data Compression Method (CMMD) subfield must contain "RLE".
>
> The Decompression Parameters (DCOM) subfield must not be present.

The Coding Method (METH) subfield must contain "ISO8211".

### 3.6 SDTS Restrictions/Requirements: Layer Definition Module

The Cell Module Name or Adjunct File id (CMNM) subfield must contain the
identifier for the JFIF file or the cell module name. This must match
the identifier or module name used in the Catalog/Directory module.

### 3.7 SDTS Restrictions/Requirements: Cell Module 

If the JFIF file is substituted for the Cell Module, then no Cell module
is present.

If the SDTS RLE option is used, the Cell Values (CVLS) field must have
two subfields: a cell value subfield defined by the data encoder, and
subfield RLECOUNT.

### 3.8 File Naming Convention

In addition to the file naming conventions in the core SRPE, any adjunct
JPEG files is recommended to have the file extension ".jpg". The file
name is recommended to start with the same four characters as the rest
of the SDTS files in the transfer.

#  ANNEX D: SPECIAL PURPOSE TRANSFERS

(Normative)

## 1 Introduction

This annex option permits certain information that is otherwise
mandatory to be not present in an SDTS transfer. All other stipulations
of the main body of this profile apply, unless specifically addressed in
this annex option. To indicate that this annex option is in effect, a
"/D" must be appended to the Profile Identification subfield value of
the Identification module record. (Certain sections marked as
informative provide explanatory information that does not constitute any
binding requirements for conformance.)

The requirements of the SDTS are founded in the principles of
self-documenting transfers. These type of transfers are not necessary in
every transfer situation. This annex option permits special purpose
transfers that contain abbreviated or minimal information, which can be
correctly interpreted by the intended recipient. This annex option in
effect is decoupling the information requirements of SDTS from the
format mechanics. Standard file formats and minimal content are still
required to insure data reuse and interoperability between different
systems. The scope of this annex option is to provide a data set
transfer mechanism for situations with a pre-established context, data
consumers known a priori, and the requirement for interoperability
between different systems. (The physical network connection and
transmission protocols are not within the scope of this profile.)

To use this annex option properly, the data consumer and their
application for the data transfer should be known to the data provider.
This profile annex option can be used in conjunction with annexes A, B,
and C.

### 1.1 Rapid Transmission Example (Informative)

This profile annex option is included to satisfy the needs of data
encoders for cases of time critical spatial data transmissions, very
limited bandwidth, and (or) other such special purposes. Rapid
transmission defines a scenario that identifies the need to provide
imagery data in near real-time for field employment (includes
battlefields, fires, floods, etc.) Table D.1 provides a comparison of
characteristics to assist in determining the appropriate transmission
option. Characteristics on the left are generally not appropriate
situations for using this profile annex option, whereas characteristics
on the right are appropriate.

+-------------------------------------+---+--------------------------------+
| []{#__RefHeading___Toc431887638     |   |                                |
| .anchor}Table D.1 - Transmission    |   |                                |
| Comparison                          |   |                                |
+=====================================+===+================================+
| Blind transfer/Archive              | R |                                |
| Characteristics                     | a |                                |
|                                     | p |                                |
|                                     | i |                                |
|                                     | d |                                |
|                                     | T |                                |
|                                     | r |                                |
|                                     | a |                                |
|                                     | n |                                |
|                                     | s |                                |
|                                     | m |                                |
|                                     | i |                                |
|                                     | s |                                |
|                                     | s |                                |
|                                     | i |                                |
|                                     | o |                                |
|                                     | n |                                |
|                                     | C |                                |
|                                     | h |                                |
|                                     | a |                                |
|                                     | r |                                |
|                                     | a |                                |
|                                     | c |                                |
|                                     | t |                                |
|                                     | e |                                |
|                                     | r |                                |
|                                     | i |                                |
|                                     | s |                                |
|                                     | t |                                |
|                                     | i |                                |
|                                     | c |                                |
|                                     | s |                                |
+-------------------------------------+---+--------------------------------+
| Data of Historical Significance     |   | Data expires rapidly           |
| (\"long term value\") usually       |   |                                |
+-------------------------------------+---+--------------------------------+
| Sender Known, Receiver Unknown:     | S |                                |
|                                     | e |                                |
| Send maximum information            | n |                                |
| (self-contained transfer)           | d |                                |
|                                     | e |                                |
|                                     | r |                                |
|                                     | K |                                |
|                                     | n |                                |
|                                     | o |                                |
|                                     | w |                                |
|                                     | n |                                |
|                                     | , |                                |
|                                     | R |                                |
|                                     | e |                                |
|                                     | c |                                |
|                                     | e |                                |
|                                     | i |                                |
|                                     | v |                                |
|                                     | e |                                |
|                                     | r |                                |
|                                     | K |                                |
|                                     | n |                                |
|                                     | o |                                |
|                                     | w |                                |
|                                     | n |                                |
|                                     | : |                                |
|                                     |   |                                |
|                                     | S |                                |
|                                     | e |                                |
|                                     | n |                                |
|                                     | d |                                |
|                                     | m |                                |
|                                     | i |                                |
|                                     | n |                                |
|                                     | i |                                |
|                                     | m |                                |
|                                     | a |                                |
|                                     | l |                                |
|                                     | i |                                |
|                                     | n |                                |
|                                     | f |                                |
|                                     | o |                                |
|                                     | r |                                |
|                                     | m |                                |
|                                     | a |                                |
|                                     | t |                                |
|                                     | i |                                |
|                                     | o |                                |
|                                     | n |                                |
|                                     | b |                                |
|                                     | e |                                |
|                                     | c |                                |
|                                     | a |                                |
|                                     | u |                                |
|                                     | s |                                |
|                                     | e |                                |
|                                     | c |                                |
|                                     | o |                                |
|                                     | n |                                |
|                                     | t |                                |
|                                     | e |                                |
|                                     | x |                                |
|                                     | t |                                |
|                                     | i |                                |
|                                     | s |                                |
|                                     | p |                                |
|                                     | r |                                |
|                                     | e |                                |
|                                     | - |                                |
|                                     | e |                                |
|                                     | s |                                |
|                                     | t |                                |
|                                     | a |                                |
|                                     | b |                                |
|                                     | l |                                |
|                                     | i |                                |
|                                     | s |                                |
|                                     | h |                                |
|                                     | e |                                |
|                                     | d |                                |
+-------------------------------------+---+--------------------------------+
| One-way Communication               | O |                                |
|                                     | n |                                |
|                                     | e |                                |
|                                     | - |                                |
|                                     | w |                                |
|                                     | a |                                |
|                                     | y |                                |
|                                     | C |                                |
|                                     | o |                                |
|                                     | m |                                |
|                                     | m |                                |
|                                     | u |                                |
|                                     | n |                                |
|                                     | i |                                |
|                                     | c |                                |
|                                     | a |                                |
|                                     | t |                                |
|                                     | i |                                |
|                                     | o |                                |
|                                     | n |                                |
+-------------------------------------+---+--------------------------------+
| Data Assessment                     | D |                                |
| /Interpretation/Analysis done       | a |                                |
| afterwards; transmitted data useful | t |                                |
| for many possible applications      | a |                                |
|                                     | A |                                |
|                                     | s |                                |
|                                     | s |                                |
|                                     | e |                                |
|                                     | s |                                |
|                                     | s |                                |
|                                     | m |                                |
|                                     | e |                                |
|                                     | n |                                |
|                                     | t |                                |
|                                     | / |                                |
|                                     | I |                                |
|                                     | n |                                |
|                                     | t |                                |
|                                     | e |                                |
|                                     | r |                                |
|                                     | p |                                |
|                                     | r |                                |
|                                     | e |                                |
|                                     | t |                                |
|                                     | a |                                |
|                                     | t |                                |
|                                     | i |                                |
|                                     | o |                                |
|                                     | n |                                |
|                                     | / |                                |
|                                     | A |                                |
|                                     | n |                                |
|                                     | a |                                |
|                                     | l |                                |
|                                     | y |                                |
|                                     | s |                                |
|                                     | i |                                |
|                                     | s |                                |
|                                     | d |                                |
|                                     | o |                                |
|                                     | n |                                |
|                                     | e |                                |
|                                     | b |                                |
|                                     | e |                                |
|                                     | f |                                |
|                                     | o |                                |
|                                     | r |                                |
|                                     | e |                                |
|                                     | h |                                |
|                                     | a |                                |
|                                     | n |                                |
|                                     | d |                                |
|                                     | ; |                                |
|                                     | t |                                |
|                                     | r |                                |
|                                     | a |                                |
|                                     | n |                                |
|                                     | s |                                |
|                                     | m |                                |
|                                     | i |                                |
|                                     | t |                                |
|                                     | t |                                |
|                                     | e |                                |
|                                     | d |                                |
|                                     | d |                                |
|                                     | a |                                |
|                                     | t |                                |
|                                     | a |                                |
|                                     | f |                                |
|                                     | o |                                |
|                                     | r |                                |
|                                     | a |                                |
|                                     | v |                                |
|                                     | e |                                |
|                                     | r |                                |
|                                     | y |                                |
|                                     | s |                                |
|                                     | p |                                |
|                                     | e |                                |
|                                     | c |                                |
|                                     | i |                                |
|                                     | f |                                |
|                                     | i |                                |
|                                     | c |                                |
|                                     | a |                                |
|                                     | p |                                |
|                                     | p |                                |
|                                     | l |                                |
|                                     | i |                                |
|                                     | c |                                |
|                                     | a |                                |
|                                     | t |                                |
|                                     | i |                                |
|                                     | o |                                |
|                                     | n |                                |
+-------------------------------------+---+--------------------------------+
| Blind/Broadcast (open) - Public     | P |                                |
| FTP, Sales Counter                  | o |                                |
|                                     | i |                                |
|                                     | n |                                |
|                                     | t |                                |
|                                     | - |                                |
|                                     | t |                                |
|                                     | o |                                |
|                                     | - |                                |
|                                     | P |                                |
|                                     | o |                                |
|                                     | i |                                |
|                                     | n |                                |
|                                     | t |                                |
|                                     | / |                                |
|                                     | B |                                |
|                                     | r |                                |
|                                     | o |                                |
|                                     | a |                                |
|                                     | d |                                |
|                                     | c |                                |
|                                     | a |                                |
|                                     | s |                                |
|                                     | t |                                |
|                                     | ( |                                |
|                                     | s |                                |
|                                     | e |                                |
|                                     | c |                                |
|                                     | u |                                |
|                                     | r |                                |
|                                     | e |                                |
|                                     | ) |                                |
+-------------------------------------+---+--------------------------------+

Rapid transmission always involves communication from a known sender to
a known receiver. In this situation much of the metadata that would
normally be required is unnecessary because it can be correctly assumed
or implied. The format, data fields, spatial objects from SDTS and/or
BIIF are valid in this situation, i.e. there is no reason it won't work.
However, a data set that has been sent with abbreviated content is not
something that would get archived or kept for later use.

## 2 SDTS Restrictions/Requirements

In this profile annex option certain mandatory SDTS metadata
requirements become optional. They are:

a)  SDTS Quality Report (SDTS requirement)

b)  SDTS Data Dictionary (SDTS requirement)

c)  SDTS External and Internal Spatial Reference Module

The subsections that follow state the effects of this on each module.

### 2.1 Module Restrictions/Requirements: Identification Module

The Identification Module must be present. The following subfields are
mandatory, with all others becoming optional: Module Name (MODN), Record
Id (RCID), Profile Identification (PRID), and Comment (COMT).

To indicate that this profile annex option is in effect, a "/D" must be
appended to the value in the Profile Identification (PRID) subfield.

The Comment (COMT) subfield must state that the transfer is for a
special purpose and may not contain all content typical of a SDTS
transfer.

### 2.2 Module Restrictions/Requirements: Catalog/Directory

The Catalog/Directory Module must be present if two or more files are in
the transfer. It must contain a record for every file that belongs to
the special purpose transfer, except referencing itself is optional. The
following subfields are mandatory, with all others becoming optional:
Module Name (MODN), Record Id (RCID), Name (NAME), Type (TYPE), and File
(FILE).

### 2.3 Module Restrictions/Requirements: External and Internal Spatial Reference System Modules

The External Spatial Reference module (XREF) and the Internal Spatial
Reference module (IREF) are only required if the data type for the
spatial addresses fields (subfield HFMT in IREF module) needs to be
encoded, and (or) the georeferencing needs to be encoded.

### 2.4 Module Restrictions/Requirements: All Other Modules

All other modules not addressed in the preceding sections, that are
otherwise permitted and required by the SRPE, are optional. All fields
and subfields become optional on the assumption that any subfield value
critical to the correct application of the transmitted data is known in
advance or can be implied by the recipient.

#  

#  ANNEX E: SDTS GEOTIFF EXTENSION

(Normative)

## 1 Introduction

This annex option permits a tagged image file format (TIFF) compliant
file with GeoTIFF tags to be included in an SDTS transfer for the
purpose of encoding an image. All other stipulations of the main body of
this profile apply, unless specifically addressed in this annex option.
To indicate that this annex option is in effect, a "/E" must be appended
to the Profile Identification subfield value of the Identification
module record. (Certain sections marked as informative provide
explanatory information that does not constitute any binding
requirements for conformance.)

### 1.1 References

The following references contain provisions either by direct reference
or relationship, which through references in this paragraph or within
this text, constitute provisions of this profile annex option. At the
time of publication, the editions indicated were valid. All standards
are subject to revision, and parties to agreements based on SRPE should
investigate any recent editions of the references listed below.

> Ritter, N.D., and Ruth, M., 1995, GeoTIFF Format Specification,
> Revision 1.0, (final November 10, 1995). Available at
> ftp://sdts.er.usgs.gov/release/geotiff/jpl_mirror/spec/

Aldus Corporation, 1992, TIFF, revision 6.0. Aldus Corporation, 411
First Avenue South, Seattle, WA 98104. Phone number 206-628-6593.
On-line at ftp.adobe.com in directory
/pub/adobe/DeveloperSupport/TechNotes/PDFfiles/TIFF6.pdf; or access as
ftp://ftp.adobe.com/pub/adobe/devrelations/devtechnotes/pdffiles/tiff6.pdf

### 1.2 Background of GeoTIFF *(Informative)*

TIFF is a general purpose image format widely used in applications like
electronic publishing, clip art, and general image distribution. TIFF is
a registered trademark of Adobe Corporation, (formerly Aldus), and is
available for use without cost or licensing. Increasingly, TIFF is being
used to encode images of the earth based on satellite imagery or scanned
maps. An industry-standard set of public domain TIFF tags to support
georeferencing of a TIFF encoded image is described in the GeoTIFF
specification. To encode projection and coordinate system information,
the method from the Petrotechnical Open Software Company (POSC)'s
implementation of the European Petroleum Survey Group (EPSG)s' Epicentre
2.0 geodetic model was used. The GeoTIFF Specification 1.0 is based on
the TIFF Revision 6.0 and the POSC/EPSG tables version 2.2.

### 1.3 Applicability of this Option *(Informative)*

In the context of this profile annex option, TIFF is most appropriately
used to display one visual representation of an image such as a three
band red, green, blue visualization of a digital orthophoto or a scan of
a map. GeoTIFF is appropriate when this image can be georeferenced
(which implies that the geometry has been corrected to a projection
space.) The GeoTIFF encoded image can be used for visual analysis,
backdrops, and overlays. The use of GeoTIFF is less appropriate for
raster image or grid data that could be visualized in many different
ways or used to support more sophisticated analysis, such as digital
elevation grids or multi-spectral satellite data.

This annex option enables a data provider to offer a single data set
package that can meet a wide variety of application needs, from simple
visual to more sophisticated analysis. The data consumer purchases the
software tools to meet their application needs, and the data provider
offers one-size fits all data sets. For applications requiring viewing
only, the TIFF portion is accessed; for georeferencing, the GeoTIFF is
accessed; for generation of alternate views or more sophisticated
analysis, SDTS raster and metadata is accessed.

## 2 TIFF Restrictions/Requirements

The restrictions and (or) requirements placed on TIFF originate from the
following sources: 1) the TIFF Revision 6 specification; 2) the GeoTIFF
Format Specification, Revision 1.0; and, 3) this profile annex option
itself.

The requirements for TIFF readers and writers as specified in TIFF Part
1 and the additional requirements of GeoTIFF section 2.3 on TIFF
implementations apply in this annex. There must be only one image per
TIFF file. However, there may be more than one TIFF file included as
part of an SDTS Raster Profile with Extensions transfer. The
relationship among all images in the transfer, both TIFF and native
SDTS, must be explained in the SDTS Logical Consistency module. A TIFF
file with no GeoTIFF tags is permitted when georeferencing is not
possible (for example, a shaded relief perspective view of a terrain
surface.)

The required set of baseline TIFF fields, taken from TIFF Part 1, are
listed below:

BitsPerSample (tag id 258)

ColorMap (tag id 320)

Compression (tag id 259)

ImageLength (tag id 257)

ImageWidth (tag id 256)

PhotometricInterpretation (tag id 262)

ResolutionUnit (tag id 296)

RowsPerStrip (tag id 278)

SamplesPerPixel (tag id 277)

StripByteCounts (tag id 279)

StripOffsets (tag id 273)

XResolution (tag id 282)

YResolution (tag id 283)

TIFF implementation requirements to support GeoTIFF, taken from the
GeoTIFF Format Specification, Section 2.3, and summarized below:

> a\) Must support all documented TIFF 6.0 data-types, especially the
> IEEE double precision floating point "DOUBLE" type tag. (Data types
> are BYTE, ASCII, SHORT, LONG, RATIONAL, SBYTE, UNDEFINED, SSHORT,
> SLONG, SRATIONAL, FLOAT, and DOUBLE as defined in TIFF Section 2,
> Image File Directory; Types.) Modification: This profile annex option
> only requires support of types ASCII, SHORT, and DOUBLE at a minimum.
>
> b\) TIFF specification indicates that the byte-order indicator in the
> Image File Header must be supported. This means that 4-byte integers
> and 8-byte double's on opposite order machines will be swapped by the
> software.

A conformant decoder must, at a minimum, support the required baseline
set of TIFF fields, and respective values; fields or values not
supported by the decoder should be tolerated or ignored, and should not
cause a failure in the processing of the file. A conformant encoder must
use the required TIFF baseline fields to their fullest extent. Use of
TIFF extension and TIFF private fields is permitted, but these are not
required to be supported.

## 3 GeoTIFF Restrictions/Requirements

The requirements on GeoTIFF implementations are described in the GeoTIFF
Format Specification. These requirements are summarized below:

> a\) A GeoTIFF writer must support baseline TIFF and creation of the
> GeoTIFF fields; a reader must parse GeoTIFF fields. GeoTIFF fields,
> taken from GeoTIFF Section 2: Baseline GeoTIFF, are:

GeoKeyDirectoryTag (tag id 34735)

GeoDoubleParamsTag (tag id 34736)

GeoAsciiParamsTag (tag id 34737)

ModelTiepointTag (tag id 33922)

ModelPixelScalTag (tag id 33550)

ModelTransformationTag (tag id 34264)

> b\) From GeoTIFF Section 2.4 GeoTIFF File and Key Structure, special
> handling is required for ASCII-valued keys. The null delimiter of each
> ASCII Key value must be converted to a "\|" (pipe) character before
> being encoded into the ASCII holding tag. "A baseline GeoTIFF reader
> must check for and convert the final '\|' pipe character of a key back
> into a NULL before returning it to the client software."
>
> c\) GeoTIFF writers must store the GeoKey entries in key-sorted order
> within the CoordSystemInfoTag.

## 4 SDTS Restrictions/Requirements

A TIFF file with or without GeoTIFF tags is permitted to be included in
an SDTS transfer. In this section, the more general term "TIFF file"
will be used to refer to either type. One or more TIFF files are
permitted in a single SDTS transfer file set. Each separate TIFF file
must contain only one image (as encoded in TIFF file structures).

The TIFF file is intended to be a substitute for the SDTS Cell Module
encoded in ISO 8211 format. In this case, the Layer Definition module
record and the Schema module record would reference the TIFF file id and
there would be no SDTS Cell Module file. All other modules in the
transfer would be the same as if the raster data were encoded in the
Cell Module, except they need to describe the data as it is encoded in
the TIFF file.

This profile annex option permits a TIFF file to be included as a
supplement to a SDTS Cell Module. In this case, the Layer Definition
module record and the Schema module record would reference the Cell
Module, as before. The TIFF file is related to the Cell Module through a
Catalog/Cross-reference module record, where the comment field would
explain the relationship.

All methods of georeferencing supported by GeoTIFF tags are permitted in
this profile annex option. If the georeferencing method encoded using
GeoTIFF tags is not supported by SDTS, then this will be encoded in SDTS
descriptions as "unspecified". If the georeferencing method is a
projected coordinate system, then the projection parameters must be
encoded in the GeoTIFF structure and are not required to be encoded as
SDTS attributes.

The TIFF baseline specification supports packbits compression and a
modified Huffman compression. This profile annex option permits either
of these compression options, or no compression. The data should be
described as it is encoded in the TIFF file.

### 4.1 SDTS Restrictions/Requirements: Identification Module

To indicate that this profile annex option is in effect, an "/E" must be
appended to the value in the Profile Identification (PRID) subfield.

The External Spatial Reference (EXSP) subfield must be "1", if UTM/UPS,
SPCS, or Geographic is encoded in the GeoTIFF tags; "2", if a projected
system is encoded in the GeoTIFF tags; or, "3", if the georeferencing
method encoded using GeoTIFF tags is not supported by SDTS, or no
GeoTIFF tags are used.

The Coding Level (CDLV) subfield must be "1" when a TIFF file is
substituted for a Cell Module.

### 4.2 SDTS Restrictions/Requirements: Catalog/Directory Module

The Name (NAME) subfield must contain an identifier to uniquely
reference a single TIFF file.

The Type (TYPE) subfield must contain "TIFF".

The External (EXTR) subfield must contain "A", indicating an adjunct
file is included.

### 4.3 SDTS Restrictions/Requirements: Catalog/Cross-Reference Module

If a TIFF file is a supplement to a Cell Module, then this relationship
must be expressed through a Catalog/Cross-reference module record with
the relationship explained in the Comment subfield.

### 4.4 SDTS Restrictions/Requirements: External Spatial Reference Module

The Reference System Name (RSNM) subfield must be "GEO" when a latitude
and longitude system is used; "SPCS" when State Plane Coordinate System
is used; "UTM" when UTM is used; "UPS" when UPS is used; "OTHR" when a
Projected Coordinate system is used; or, "UNSP" when geocentric is used
or when GeoTIFF tags are not used at all.

The Attribute ID (ATID) subfield is not required, when Reference System
Name is "OTHR". This means that the projection parameters are not
required to be encoded as SDTS attributes because they are already
encoded in the GeoTIFF structures.

### SDTS Restrictions/Requirements: Data Dictionary/Schema Module

When the TIFF file replaces the Cell module, the Name (NAME) subfield
must contain the adjunct file id of the TIFF file, defined in the
Catalog/Directory module record.

The Type (TYPE) subfield must contain "CELL" even when the raster data
is in a TIFF file.

### 4.6 SDTS Restrictions/Requirements: Data Quality Modules

If there are multiple TIFF files included in a single SDTS transfer file
set, then the relationship among the files and the images they contain
must be explained in the Logical Consistency module, at a minimum.

If a TIFF file represents a visualization of more fundamental raster
data stored in a SDTS Cell Module, then the process used to generate the
image must be described in the Lineage Module, at a minimum.

### 4.7 SDTS Restrictions/Requirements: Raster Definition Module

If the TIFF file uses the PackBits Compression, then the Data
Compression Method (CMMD) subfield must contain "PACKBITS"; if modified
Huffman, then "MODHUFFMAN".

The Decompression parameters (DCOM) subfield is not required, as the
TIFF file must contain all information needed to decompress the data.

The Coding Method (METH) subfield must contain "TIFF" to indicate that a
TIFF file is used to encode the data for this raster object, instead of
a SDTS Cell Module.

### 4.8 SDTS Restrictions/Requirements: Layer Definition Module

The Cell Module Name or Adjunct File id (CMNM) subfield must contain the
identifier for the TIFF file when it replaces the Cell module. This must
match the identifier used in the Catalog/Directory module.

### 4.9 SDTS Restrictions/Requirements: Cell Module 

If the TIFF file is substituted for the Cell Module, then no Cell module
is present.

If a TIFF file is just a supplement, then the Cell Module is present, as
before.

### 4.10 File Naming Convention

In addition to the file naming conventions in the core SRPE, any adjunct
TIFF files is recommended to have the file extension ".tif". The file
name is recommended to start with the same four characters as the rest
of the SDTS files in the transfer.

## 5 Implementation Resources (*Informative*)

Software and information resources useful to implementers of this annex
are listed below. All referenced software is public domain, but
commercial tools may also be available.

LIBTIFF - Public Domain TIFF library. Available via anonymous FTP from
ftp://sgi.com/graphics/tiff.

LIBGEOTIFF - Public Domain GeoTIFF library. Available via anonymous FTP
to ftp://mtritter.jpl.nasa.gov/pub/tiff/geotiff/code

or at its USGS mirror site
ftp://sdts.er.usgs.gov/release/geotiff/jpl-mirror/code.

SDTS++ - Public Domain SDTS C++ library. Available from
http://mcmcweb.er.usgs.gov/sdts, follow links to SDTS++.

SDTS Home Page is maintained by USGS at URL
http://mcmcweb.er.usgs.gov/sdts and contains information on the Spatial
Data Transfer Standard, profiles, datasets, software, articles,
presentation materials, and standard document.

GeoTIFF Web Page is at
http://home.earthlink.net/\~ritter/geotiff/geotiff.html.

Ritter, N., and Ruth, M., "The GeoTiff data interchange standard for
raster geographic images", International Journal of Remote Sensing,
1997, Vol. 18, No. 7, pp. 1637-1647. This article is a review of the
GeoTIFF development initiative and an overview of the main technical
characteristics and principles of the GeoTIFF format

#  ANNEX 1: DEFINITIONS and ACRONYMS

(Informative)

## 1 Introduction

This annex to the SDTS Raster Profile and Extensions (SRPE) serves to
facilitate the use of the SRPE by providing definitions for terms and
acronyms used in this document. Additional definitions are available in
SDTS and BIIF.

### 1.1 Definitions

Bands - commonly used in describing imagery; usually collected at the
same time by the same acquisition device. For an image, a group of
representation modes such as those visible to the human eye and those
detected by other means such as infrared, side-aperture radar,
electro-magnetic, etc.

Block - rectangular portion of an image; there is no overlapping of
blocks or gaps between adjacent blocks within a single image (BIIF
Clause 4.2.5.1.)

Cell - used in this document to refer to both the terms grid cell of a
data grid and pixel of image data.

Data Extension Segment (DES) - a construct used to encapsulate different
data types, other than image, symbol, and text. (BIIF clause 4.2.8.2)

Data Segment - In BIIF this refers to one section of a BIIF file, as in
an image, symbol, or text segment.

Digital Image - A two-dimensional (geospatial) array of regularly spaced
picture elements (pixels) constituting a picture. (See SDTS Part 1,
Section 2.3.4.1); Object representation code of G2.

Geometric Transformation - an operation that redefines the spatial
relationship between points in an image. This includes simple
translation, scale, rotation, or something as elaborate as a convoluted
transformation. Also called warping.

Georeferenced data - data that has been geographically registered to the
earth\'s surface; this includes performing any geometric corrections to
fit the raster data to grid of the projection.

Grid - A two-dimensional (geospatial) set of grid cells forming a
regular tessellation of a surface. (See SDTS Part 1, Section 2.3.4.2);
Object representation code of G2.

Grid Cell - A two-dimensional (geospatial) object that represents the
smallest non-divisible element of a grid (SDTS Part 1 Section 2.3.3.5).
(Similar to a pixel for an image.)

Image - uses a two-dimensional reference system and has zero, one, or
more data values associated with each cell. Although image has a visual
connotation to it, it is often used to refer to any measurement from a
remote sensing device that has a two-dimensional spatial orientation. An
image may consist of one or more bands. (See Digital Image)

Indirect georeferencing - locating spatial data to the earth's surface
using place names or feature names.

International Standard - terminology used in ISO to refer to an approved
and available standard.

Layer - a set of data values (i.e., cell values) all measuring the same
phenomena for an image or grid. In SDTS terms, a "layer" refers to one
band of an image or a raster grid. For example, if a three-band image
was transferred along with a digital elevation grid, this would
constitute four layers in SDTS.

Mosaicking - the joining together of several images that may overlap
each other to create a single new image.

Pixel - A two-dimensional (geospatial) picture element that is the
smallest non-divisible element of a digital image (SDTS Part 1 Section
2.3.3.4). (Similar to a cell of a grid.)

Radiometric \[camera\] calibration - The calibration of a camera for its
spectral recording characteristics.

Radiometric linearity - The gray levels are in linear proportion to the
light intensities within a color band.

Radiometric non linearity - The analog to digital conversion system that
provides signal to noise (S/N) ratios of the sensors, where the S/N is
calculated by the difference of the sensor\'s average dark signal value
divided by the root mean square dark noise value. Intermediate
intensities will be linear representations from average white reference
to the average dark reference. Intermediate intensities will be
represented using a linear tonal transfer curve for each color channel.
For example, the error introduced during the digitization process causes
gray scale values for a color component (RGB) to be out of linear
proportion to the source intensities for that component.

Raster object - One or more related raster data layers collected and/or
processed together, registered to a common scan reference system and
having similar geographic extents. (SDTS Part 1, Section 2.3.4.4)

Rectification - In photogrammetry, the process of projecting a
photograph onto a horizontal reference plane. A rectified print is a
photograph in which displacement has been removed from the original
negative, and which has been brought to a desired scale.

SDTS Transfer - A spatial data set composed of metadata and one or more
data files. The metadata portion of the transfer defines lineage,
positional accuracy, security restrictions, definitions of feature and
attribute terms, etc. and content of the SDTS transfer.

Synthetic raster data - data derived by digitizing or extensive
processing. An example is a scanned map image. Also called derived,
symbolized, interpreted, exploited.

Tagged Record Extension (TRE) - A way to provide additional attributes
about standard BIIF data segments not contained in the BIIF standard
headers. (BIIF Clause 4.2.8.1)

Tile - same as block. A tiled image is equivalent to blocked image.

Transformation - (Photogrammetry) The process of projecting a photograph
(mathematically, graphically, or photographically) from its plane onto
another plane by translation, rotation, and/or scale change. The
projection is made onto a plane determined by the angular relations of
the camera axes and not necessarily onto a horizontal plane.

Visual Representation - for the purposes of this profile, this term is
used to indicate a critical need to display the image exactly as the
image was generated.

Warped Grid - a two-dimensional set of warped grid cells that are
adjacent, non-overlapping and partially overlapping, and some cells are
not square. (For example, remotely sensed imagery that has not been
rectified, or a scanned image that has not had scanner distortion
removed.)

### 1.2 Acronyms

ANSI - American National Standards Institute

BIIF - Basic Image Interchange Format

CGM - Computer Graphics Metafile

DR - Data Record (ISO 8211 term)

DDR - Data Descriptive Record (ISO 8211 term)

> DDF - Data Descriptive File (ISO 8211 term)

FIPS - Federal Information Processing Standard

FGDC - Federal Geographic Data Committee

> G2 - SDTS object code for Digital Image or Grid
>
> G2W - Defined by SRPE to indicate warped or non-rectified raster data

GI - SDTS sequencing code for Band Sequential

GJ - SDTS sequencing code for Band Interleaved by Line

GL - SDTS sequencing code for Band Interleaved by Cell

IS - International Standard

ISO - International Standards Organization

IEC - International Electrotechnical Commission

JFIF - JPEG File Interchange Format

JPEG - Joint Photographic Experts Group (often refers to work done on
compression algorithms for continuous tone still images)

LUTS - Look up tables, used for color palettes for raster grid data

NIMA - National Imagery and Mapping Agency

NITFS - US National Imagery Transmission Format Standard

NSIF - NATO Secondary Interchange Format

RMSE - Root Mean Square Error

SDTS - Spatial Data Transfer Standard

SRPE - SDTS Raster Profile and Extensions

> TIFF - Tagged Image File Format
>
> VQ - Vector Quantization (compression technique in BIIF)
>
> USGS - U.S. Geological Survey

#  ANNEX 2: DIAGRAMS AND EXAMPLES

(Informative)

## 1 Introduction

This annex to the SDTS Raster Profile and Extensions (SRPE) serves to
facilitate the use of the SRPE by providing diagrammatic illustrations
of the relationship between standards and example encodings using SDTS
and the various extensions. There are many combinations of options that
are permitted by the SRPE, and this annex only illustrates a few.

## 2 Relationships among Standards

This section explains the relationship among the many standards
referenced by various parts of the SRPE. Diagrams are used to facilitate
the description of the multi-faceted relationships. One of the
objectives of the SRPE is to be a convergence agent in the various
geospatial raster data efforts. Rather than duplicate capabilities
available in other standards, the SRPE sought to use these directly.
Figure 1 shows the image and metadata standards that the SRPE integrates
with the fundamental SDTS.

![](media/image3.wmf){width="6.194444444444445in"
height="3.6944444444444446in"}

Figure 1: Relationship Among Standards

The Federal Geographic Data Committee (FGDC) under its authority to
develop standards for the National Spatial Data Infrastructure (NSDI)
developed a content standard for geospatial metadata. The SRPE requires
the use of this content standard to encode certain types of information.

When it comes to image format standards, there are quite a few. The SRPE
therefore permits images to be encoded in other formats, offering
additional capabilities to SDTS data encoders immediately without
duplicating efforts. The military community has been working on
developing a joint ANSI/ISO standard for imagery applications based on
their military standard National Imagery Transmission Format (NITF). The
SRPE permits BIIF, specifically the NSIF Profile, as an image format in
Annex A. Satellite image providers have taken a popular image format
TIFF and added georeferencing capability. The SRPE permits a TIFF file
with or without GeoTags to be included in an SDTS transfer in Annex E.
The SRPE permits the use of the JPEG compression algorithms, and
specifically the JPEG File Interchange Format (JFIF) to encode a
compressed image in Annex C.

#### 2.1.1 SDTS and BIIF

This section serves to explain the relationship between the SDTS
standard, its SRPE (Profile), and the BIIF Standard, and the proposed
NSIF/NITF Profile. The relationship is explained in Annex A, section
1.2, and is depicted in Figure 2.

![](media/image4.wmf)

Figure 2: Conceptual Delineation of SRPE

The SRPE is fundamentally comprised of SDTS, and optionally includes
BIIF extensions, delineated by the overlap of SRPE and NITF/NSIF profile
to BIIF. BIIF as an international standard will be implemented through
national profiles, and the NSIF will become the US profile. For
compatibility, the NITF profile will be a subset of the NSIF
requirements.

#### 2.1.2 SDTS and GeoTIFF

This section serves to explain the relationship between the SDTS
standard, the TIFF specification, and the GeoTIFF specification. The
relationship is depicted in Figure 3.

![](media/image5.wmf)

Figure 3: SDTS and GeoTIFF Relationship

The SRPE permits the use of TIFF to encode images in Annex E. If the
image is capable of being georeferenced, then the GeoTags are required
to encode this information. The GeoTags are an extension of the TIFF
specification to support georeferencing in an open, non-proprietary
manner. The GeoTag structure duplicates the tag mechanism used within
TIFF to offer a hierarchy of tags.

#### 2.1.3 SDTS and JPEG

The relationship between JPEG and SDTS is defined by the SRPE in Annex
C. The base SDTS leaves the specification of compression up to the
profile. The JPEG is a suite of compression methods, lossy and lossless,
for continuous tone images. The JFIF is a format for compressed image
transfer that is neutral on the compression method used, but compatible
with JPEG. The relationship permitted in SRPE Annex C is depicted in
Figure 4.

![](media/image6.wmf)

Figure 4: SDTS and JPEG Relationship

The SRPE permits the use of the JPEG compression methods by permitting
the use of JFIF for compressed image transfer. (Similar to the SDTS,
both BIIF and TIFF extensions address the use of JPEG. This offers
multiple paths to JPEG for a user of the SRPE, through the Annex A BIIF
and Annex E TIFF extensions.)

## 3 Example Encodings

This section will describe some example encodings down to the file
level. These illustrate the file level impact of the various extensions
and options available in the SRPE. For details about the content and
structure of each file, refer to the appropriate annex and standard or
specification. References for each are listed in the annex that permits
the extension.

The order of the examples proceeds from the base or core of the SRPE, to
any permitted SDTS options (such as use of the Color Index Module), and
through the permitted extensions.

### 3.1 Case: SRPE Base Transfer

This section describes a transfer that uses SDTS only as permitted by
the base of the SRPE. A gridded elevation data set will be used as an
example. In Figure 5, the transfer is shown as a set of files. Each of
these files corresponds to an SDTS module type. The permitted module
types and permitted number of each type is stated in the SRPE Section 4
and 5. These requirements are used to determine the number and kind of
modules needed for a specific data set. A typical transfer of a single
layer of gridded raster data would consist of the eighteen files shown
in Figure 5.

![](media/image7.wmf){width="6.208333333333333in"
height="4.041666666666667in"}

Figure 5: File Level View of SDTS Raster Transfer

Most of the files are file level metadata (IDEN, CATD, STAT), data
quality (DQ) information, data dictionary (DD) information or
georeferencing (XREF, IREF, SPDM) information. The raster data and
description is the largest part of the data set even though it only
occupies three files (RSDF, LDEF, CEL0).

#### 3.1.1 Option: Addition of Color Index Module

In this section, the base transfer from above is modified to show the
effect of using Annex B: Color Index Module. Annex B permits the SDTS
Color Index Module to encode color palettes for the raster data in a
SDTS Cell Module. This is most appropriate for gridded raster data and
not image raster data.

For example, a color palette could be used to show elevation intervals
in our elevation data. To use the Color Index Module, the cell values
(in this case elevation measurements) need to be encoded as integers.
Then there needs to be a module record in the Color Index Module for
every different elevation value in the data set. To associate the Color
Index module file to the Cell module file, there needs to be a
Catalog/Cross-Reference Module. At the file level, the effect of Annex B
in this example is to add two files. In Figure 6a, the two additional
files are CLRX and CATX.

![](media/image8.wmf){width="6.208333333333333in"
height="4.041666666666667in"}

Figure 6a: File Level View of SDTS Raster Transfer with Color Option

Notice that these two files are in addition to all the other files, and
are not replacing any files. If a decoder does not support optional
Annex B, then there is no lost access to the actual raster data.

#### 3.1.2 Option: Addition of Compression

In this section, the base transfer from section 3.1 is modified to show
the effect of using Annex C: Compressed Raster Data. There are two types
of compression permitted by Annex C. The Run Length Encoding method is
appropriate for gridded raster data, and it effects the subfield
structure within the Cell Module record. The file level illustration
would be the same as in Section 3.1, Figure 5. The base SRPE requires
that a decoder support decompression of SDTS RLE (see SRPE Section 2.9),
so there is no lost data access to a decoder that does not support Annex
C.

The JPEG method is actually a family of compression schemes and it
creates an entire new file that replaces the Cell module file. If the
transfer was of an image, and JPEG compression was used, the file level
view would be as in Figure 6b.

![](media/image9.wmf){width="6.208333333333333in"
height="4.041666666666667in"}

Figure 6b: File Level View of SDTS Raster Transfer with JFIF Option

In Figure 6b, the Cell module has been removed and the JFIF file takes
its place. The other SDTS modules would now describe the JFIF file. The
base SRPE does not require support for decoding JPEG. A decoder that
does not support Annex C might not be capable of accessing the image
data.

### 3.2 Case: Using the BIIF Extension

This section will illustrate the case of using Annex A: BIIF Extension.
Annex A includes many options within it, so this example serves only to
illustrate some of them. The BIIF is included as a single file in an
SDTS Transfer file set. In BIIF implementation terminology, this single
file may be "unpacked" into its component parts as a processing step.
The internal structure of a BIIF file is briefly described to highlight
its component parts.

#### 3.2.1 BIIF File Structure

The BIIF image transfer is encoded in a single file that consists of a
varying number and type of data segments. The order of the segments is
shown in Figure 7.

![](media/image10.emf)

Figure 7: BIIF File Structure Showing Segment Order

Each segment starts with a header followed by the data of the segment.
The BIIF file header contains counts and lengths of all the segments in
the file. Figure 8 depicts a BIIF file consisting of a single image, no
symbols, no text, and with georeferencing through a data extension
segment.

![](media/image11.wmf)

Figure 8: BIIF File Example for SDTS Transfer

As Figure 8 shows, the BIIF File Header, Field OID, may include the
characters "SDTS-SRPE" to permit decoding software to know of the
presence of additional information in SDTS files. The Image Subheader,
Field IINFO, should also include a note to a data consumer so they are
aware of the extra information. The georeferencing information for the
image is carried in the Data Extension Segment as defined by the NSIF
Profile.

The file level view of the SDTS transfer with BIIF option would be
similar to Figure 6 in Section 3.1.2 with the JFIF block replaced by a
BIIF file containing the image data. The SDTS modules would now be
describing the image as in the BIIF file.

A decoder that does not support Annex A will not be able to access the
image data in the BIIF file. (Similarly, a NITF BIIF reader that does
not support SDTS, will not be able to access the information in the SDTS
files.)

### 3.3 Case: Using the GeoTIFF Extension

The section will illustrate the case of using Annex E: GeoTIFF
Extension. Annex E includes many options within it, so this example
serves only to illustrate some of them.

Consider the case of encoding a digital orthophoto using the GeoTIFF
option. The image is grayscale and has been geometrically corrected and
sampled to conform to a projected coordinate system grid. The image is
encoded in the TIFF as a grayscale image, and the georeferencing is
encoded in the GeoTags for a projected coordinate system. The SDTS files
contain all of the other metadata which describe production processes,
accuracy, resolution, and perhaps even the geographical footprint of the
image. For this case, the file level view of the SDTS transfer is shown
in Figure 9.

![](media/image12.wmf){width="6.208333333333333in"
height="4.041666666666667in"}

Figure 9: File Level View of SDTS Transfer using GeoTIFF Option

In this case, the GeoTIFF file replaces the Cell Module file. A decoder
that does not support Annex E will not be able to access the raster
data. A decoder that supports TIFF, but not GeoTags, will still be able
to access the image, but will not be able to georeference it.

Consider the case of encoding a visual representation of a digital
elevation grid using TIFF. The image is an interval based visualization
of the elevation values, viewed from a 30 degree angle above the
horizon. The image is encoded in TIFF as RGB image and there is no
georeferencing. The grid of elevation values, used to generate the
visual display, is encoded in the SDTS Cell module. The relationship
between the Cell module and the TIFF file is explained in the
Catalog/Cross-Reference file. The process used to generate the visual
display, or the details about the viewing angle, light source, etc. can
be described in the Data Quality Lineage module. . For this case, the
file level view of the SDTS transfer is shown in Figure 10.

![](media/image13.wmf){width="6.208333333333333in"
height="4.041666666666667in"}

Figure 10: File Level View of SDTS Transfer using TIFF Supplement

In this case, the TIFF file is a supplement to the Cell Module file.
Even if a decoder does not support Annex E, access to the raster data is
supported.

#  ANNEX 3: BIIF to SDTS Crosswalk 

(Informative)

This annex to the SDTS Raster Profile and Extensions (SRPE) compares and
contrast terminology used in the Basic Image Interchange Format (BIIF)
part of SRPE and the SDTS Raster Profile. This table is intended to
identify terms not to be used interchangeably by the standards, and more
importantly, common concepts termed differently. Attempts have been made
in the SRPE to be sensitive to the high potential for confusion and
efforts to dispel that confusion include this annex. Refer to glossary
in Annex 1 of this document for definitions of each term.

+-----------------------------------+-----------------------------------+
| []{#__RefHeading___Toc431887639   |                                   |
| .anchor}Table Annex 3.1 - SDTS    |                                   |
| and BIIF Term Crosswalk           |                                   |
+===================================+===================================+
| SDTS term                         | BIIF term                         |
+-----------------------------------+-----------------------------------+
| transfer - composed of modules    | BIIF file - a file is composed of |
| and adjunct files                 | one or more data segments.        |
|                                   | Defined segments contain          |
|                                   | specified types of data.          |
|                                   |                                   |
|                                   | Within the SDTS Raster Profile -  |
|                                   | the BIIF file(s) is part of the   |
|                                   | SDTS Transfer                     |
+-----------------------------------+-----------------------------------+
| adjunct file - Within the SDTS    | file - Within BIIF, restrictions  |
| Raster Profile, the BIIF file(s)  | on content are not applied.       |
| are defined as adjunct files.     |                                   |
| This is restricted to be image    |                                   |
| data.                             |                                   |
+-----------------------------------+-----------------------------------+
| module - Within the SDTS, this is | data segment - encodes a data     |
| a conceptually related set of     | type - in BIIF this term means    |
| information.                      | image, symbol or text (and not    |
|                                   | integer, real, etc.)              |
+-----------------------------------+-----------------------------------+
| field - set of related subfields  | conditional fields groups - Sets  |
|                                   | of BIIF fields that are defined   |
|                                   | consecutively in the BIIF         |
|                                   | specification as conditional on   |
|                                   | previous fields                   |
+-----------------------------------+-----------------------------------+
| subfield - contains the data      | field - contains the data         |
+-----------------------------------+-----------------------------------+
| field - SDTS fields can repeat as | repeating fields (identified by a |
| permitted in the specification    | field that specifies the number   |
| rules for the field               | found in the file) and may be     |
|                                   | found as a group. When no valid   |
|                                   | data is available, the bytes are  |
|                                   | blank filled.                     |
+-----------------------------------+-----------------------------------+
| mandatory subfield - data or      | required fields - data or spaces  |
| spaces                            |                                   |
+-----------------------------------+-----------------------------------+
| User defined subfields are        | Tagged Record Extension and Data  |
| allowed only in the SDTS          | Extension Segments - BIIF         |
| Attribute Modules.                | mechanism for unique user defined |
|                                   | elements.                         |
+-----------------------------------+-----------------------------------+
| Similar to permitting adjunct     | data extension segment - BIIF     |
| files.                            | mechanism for encapsulated data,  |
|                                   | i.e. RPF. Could be stand alone    |
|                                   | data.                             |
+-----------------------------------+-----------------------------------+
| Profile - subset of a base        | Profile - subset of a base        |
| standard.                         | standard.                         |
+-----------------------------------+-----------------------------------+
| Conformance Field in IDEN module  | Complexity Level - in BIIF allows |
| and Transfer Statistics - gives   | a specification of a nesting of   |
| decoder some rough indication of  | complex capabilities, like large  |
| what they will encounter          | file size, blocking, compression, |
|                                   | etc.                              |
+-----------------------------------+-----------------------------------+
| Identification Module - Contains  | BIIF File header fields -         |
| Conformance Level field and       | identify the profile, version and |
| includes standard identification  | standard.                         |
| and profile.                      |                                   |
+-----------------------------------+-----------------------------------+
| Layer - image related             | Band - one of the two-dimensional |
|                                   | (row/column) pixel value arrays   |
|                                   | that comprise an image. In the    |
|                                   | case of 24-bit true color images, |
|                                   | the representation is three       |
|                                   | two-dimensional arrays (RGB).     |
+-----------------------------------+-----------------------------------+
| Pixel - The smallest              | Pixel - The smallest              |
| non-divisible picture element.    | non-divisible picture element.    |
+-----------------------------------+-----------------------------------+
| Grid Cell - The smallest data     | No equivalent - BIIF intended for |
| element in an array of gridded    | images more than grids.           |
| data.                             |                                   |
+-----------------------------------+-----------------------------------+
| Tile -- equivalent                | Block - equivalent                |
+-----------------------------------+-----------------------------------+

Table 3.2 is a crosswalk of fields from BIIF that deal with lineage
information and their equivalent in the FGDC Content Standard for
Digital Geospatial Metadata.

  ----------------------------------------------------------------------------------
  []{#__RefHeading___Toc431887640                             
  .anchor}Table Annex 3.2 - NITF                              
  Format Requirements on Lineage                              
  --------------------------------- ------------------------- ----------------------
  **BIIF field**                    **NITF/BIIF Location**    **FGDC Field**

  OID - Originator Id               File Header               Point of Contact 1.9

  FDT - File date                   File Header               

  ISORCE - Image source             Image Subheader           Source Information
                                                              2.5.1

  IDATIM - Image Date and Time      Image Subheader           Time period of content
                                                              1.3

  (Proposed TRE for use by NITF     Tagged Record Extension   Process Steps 2.5.2
  BIIF Profile:) History Tag        in Image Subheader        
  ----------------------------------------------------------------------------------

[^1]: GCTP is the General Cartographic Transformation Package developed
    by the US Geological Survey and National Oceanic and Atmospheric
    Administration. Refer to: Snyder, J.P., 1987, Map projections ‑ A
    working manual: U.S. Geological Survey Professional Paper 1395, 383
    p. and/or GCTP Software Documentation.

[^2]: ) The DDDF defines each raster layer, the DDSH defines the format
    for a layer's cells, and the DDOM provides the minimum and maximum
    as well as special, or enumerated, cell values for each layer.

[^3]: ) A maximum of one module is recommended.

[^4]: ) Where "ell" is any combination of numbers or alpha characters,
    such as CELL, CEL1, C004, etc.