# Presentation: 423824

## Part 3

**Transfer Standard**
**(SDTS)**

**Part 3**

## ISO 8211 Encoding

**The architecture of the SDTS ensures independence between Part 1 and Part 3 to as great a degree as possible**
**The SDTS, therefore, can be implemented in different ways without affecting the model and logical specifications developed in Part 1**
**An implementation could be replaced or a new implementation could be added to the Standard if deemed necessary**

**(The Physical Specifications)**

## ISO 8211

**Standard Document title:**
**“****Specification for a Data Descriptive File for Information Interchange”**
**Standard document Reference Numbers:**
**ISO 8211-1985**
**ANSI/ISO 8211-1985**
**FIPS PUB 123**

**The ISO 8211 Document**

**Notes:**
The title of the standard is "Specification for a Data Descriptive File for Information Interchange". This standard is recognized by three standards organizations. The body of the standard is the same, but the cover and front matter differ depending on from where the copy is purchased.

In the order of adoption of the standard, the organizations are:

International Organization for Standardization (ISO)
    ISO 8211-1985 (adopted December 15, 1985)

American National Standards Institute, Inc. (ANSI)
    ANSI/ISO 8211-1985 (adopted February 28, 1986)

National Institute of Standards and Technology (NIST)
(formerly called National Bureau of Standards)
Federal Information Processing Standards (FIPS) Publication
    FIPS 123 or FIPS PUB 123 (adopted September 19, 1986)

The jurisdiction of the standards organizations - ISO, ANSI, and NIST - are the Federal Government, United States of America, and the international community,  respectively. This standard is recognized by a wide audience.

## ISO 8211

**Purpose:**

**Uses:**

**To provide a mechanism allowing data structures to be moved between dissimilar computer systems, with the capability of preserving content and meaning**

**Recurring Exchange**
**Migration**
**Archives**

**Notes:**
The standard was proposed to solve the problem of transporting file structures from one computer system to another (of a different type). It sought to provide a mechanism to allow data structures (regardless of size or complexity) to be moved between dissimilar computer systems, with the capability of preserving content and meaning.

"The standard is for use by implementors and users who have a need to represent data structures and data definitions in a standard format for information interchange purposes so that the data can be transported from one system to another" (FIPS PUB 123, page 1)

Uses:
It is intended for high-volume and/or recurring interchanges

"to provide a standard interchange format when migration from one computer system to another computer system occurs" (FIPS PUB 123, page 1)

"to provide a standard interchange format for archiving data for future recall by assuring that standard software will be available for this purpose" (FIPS PUB 123, page 1)

## ISO 8211

**General Purpose**
**Media-independent**
**System-independent**
**Intended for transfer, not processing**
**Can preserve content and structure of data**
**Self-describing**

**Characteristics of ISO 8211**

**Notes:**
General purpose:
    it is not application specific - like Initial Graphics Exchange System(IGES),      Computer Graphics Metafile (CGM), Revisable Form Text (RFT), Document      Interchange Format (DIF), etc.

Media-independent:
    this standard will work for any media including communications lines

System-independent: 
    the structures are not inherent to any particular computer system

Intended for Transfer:
    The transport structures of the standard are designed for interchange     purposes only. Not intended to be used for processing

Content and Structure: 
    to include in the transfer all the information necessary to recreate the original structure

Self-describing:
    an ISO 8211 file contains data, the data description, and a description of the file itself 
Example of being designed for transfer purposes:
    There are many schemes used to represent real numbers. To transfer real type data, ISO 8211 represents them as character strings. This is not the type of representation to be used for processing.

## The Transfer Process

**ISO 8211**
**Processor**
**Media**
**Standards**

**Source**
**Data**
**Model**

**encode**

**Senders Machine**

**ISO 8211**
**Processor**
**Media**
**Standards**

**Target**
**Data**
**Model**

**decode**

**Receivers Machine**

**Media**

**floppy**
**cd rom**
**network**
**tape**
**cartridge**
**...**

## Relationship between SDTS and ISO 8211

**Two independent standards**
**SDTS is the specification and the ISO 8211 is the chosen implementation methodology**

## Relationship between SDTS and ISO 8211

**“****It provides the means for the description of the contents of data records but does not define their content.”**

**Description and content are defined by the SDTS**

**(ANSI/ISO 8211-1985, page 1)**

**Notes:**
ISO 8211 is a standard for data exchange. Why does spatial data require SDTS?  ISO 8211 could be used to exchange spatial data without SDTS. But, there remain all the problems of vocabulary differences (line, chain , arc, edge), conceptual model differences, data quality information missing, etc.  Using just ISO 8211, the bytes will get from here to there, but the meaning of the bytes will not. So spatial data exchange needs a standard like SDTS. And because data exchange has to eventually consist of the physical transfer of bytes, SDTS needs a standard like ISO 8211. [Note: The SDTS document is organized so that Part 3 could be changed with very little effect on Part 1 & 2]. 

So, the two standards are independent. ISO 8211 can be used in any data exchange situation. And SDTS could use any data exchange format. However, SDTS has chosen to use ISO 8211. And because SDTS has constructs for encoding data relationships (i.e. foreign identifiers, modules, etc.), the full power of ISO 8211 is not needed. Part 3 of the SDTS document contains the details of how SDTS type data will make use of ISO 8211 constructs.

## Relationship between SDTS and ISO 8211

**Purpose:**

**To specify how the contents of SDTS (modules, fields, and subfields) are encoded into implementation constructs (files, records).**

**“****The methodology of this part is to define ISO 8211 constructs which, for the purpose of the transfer, accept the logical constructs of Part 1 of the standard and preserve their meaning.”**

**(The SDTS Part 3, Section 5)**

**Notes:**
Parts 1 and 2 of the SDTS addressed the conceptual level, and the logical level (i.e. modules) of spatial data transfer. Eventually, in any type of data transfer, you have to get down to the business of bytes.

As indicated in Table 3b (SDTS Part 1), there is an almost-anything-goes relationship between logical constructs and implementation constructs. For example, a field can contain part of, or one or more of a module field.

In order to achieve an encoding mechanism, Part 3 can make further restrictions on these relationships if necessary. If Part 3 hadn't chosen to use an existing exchange standard, it would have been a lot longer. As it is, it relies on the general encoding mechanism of ISO 8211, and only needs to specify how SDTS logical constructs are represented.

## Why was the ISO 8211 Selected?

**To place SDTS within a broader community of interchange**
**To provide for media/system independence of the transfer**
**To provide a mechanism which encodes both data and description**
**To allow for future extensions**
**To allow user extensions**

**Notes:**
(Reference the SDTS, Part 3, Section 1.2)

Reasons for selecting ISO 8211:

o to place SDTS within a broader community of interchange based on a general purpose, interchange standard      (An SDTS specific interchange mechanism did not have to be developed)
o transfer file set is media independent, and system independent
o transfer mechanism that handles data and description
o new modules, fields, and subfields could be added in the future and not compromise the existing structure
o user extensions are possible without compromising the constructs of the SDTS

## Relationship between SDTS and ISO 8211

**Partially specifies the mapping of SDTS constructs onto ISO 8211 constructs**
**Leaves some of the mapping to be completed--either by a user of SDTS or a profile**

**SDTS:**

**Notes:**
Part 3 of the SDTS specifies how the SDTS constructs of Part 1 (modules, records, fields, and subfields) are mapped onto ISO 8211 constructs (files, records, fields, and subfields.)  Part 3 contains a table, called Table 1, which contains ISO 8211 specifications for each field.

Part 3 is very flexible as to how SDTS is encoded using ISO 8211.  For example, the correspondance between modules and files is flexible and many subfields have a choice of ISO 8211 formats.  The choice is left up to the user of SDTS, although in many cases profiles will make choices to reduce the optionality in transfers.

## ISO 8211 Conceptual Model

**Field     --  consists of data, its structure and its                             ****	****	****  description     (call user-data-field)**
**Record --  set of 1 or more fields**
**File       --  a set of 1 or more records**
**Example of user-data-field ****:**
**structure:       single value**
**Description:   2-digit integer, named ‘age’**
**data:               23**

**ISO 8211 Conceptual Model**

## Constructs

**             ****Record**

**description (structure and name)**
**data**
**record of description**
**record of data**

**File -- one description record, 1 or more data records**
**User-Data-Field -- One or more Subfields**

**Constructs**

## Terminology

**Data Descriptive File (DDF)**
**Data Descriptive Record(DDR)**
**Data Record(DR)**
**Portion of DDR that contains Data Descriptive Fields is called Data Descriptive Area (DDA)**
**Portion of a DR that contains User Data Fields is called User Data Area (UDA)**
**A DDF is composed of one DDR, and one or more DRs.**

**Terminology**

## Constructs / Terminology

**User-Data-Field**
**             ****Record**

**description (structure and name)**
**data**
**record of description**
**record of data**

**Data Descriptive**
**Field / DDA**

**User Data Field / UDA**

**DDR**

**DR**

_**DDF**_

**File -- one description record, 1 or more data records**

**Constructs / Terminology**

## Field Examples

**Elementary, integer data****:   ****0100;&Age&&(I(3));**
**Data:****	****	****	****    ****101**
**Vector, mixed data****:    ****1600;&Address2&City!State!Zip&(A(#),A(2),I(5));**
**Data:****	****	****       Rolla#MO65401**
**Array, reals****:  ****	****2200;&Sales&Jan!Feb!Mar*Bob!Jane!Fred&(3R);**
**Data:****	****	****20.3&19.2&18.5&15.3&16.2&15.2&17.2&16.9&17.2**

**Field Examples**

## Tags

**Tags link Data with its Description**
**Tags are internal field names that are 1 - 7 characters long**
**Allows the same description to apply to more than one data field**

**Tags**

## Field

**Leader     Directory     UDA**

**Field****	****   Field****	****  Labels****	****   Format**
**Control****	****   Name****	****	****	**
**st00fu****	****   ****	****   a!b!c*x!y****	****    ****A(2),31(6),...**

**The Data**

**User Data Field**

**DESCRIPTIVE FIELD**

**Field**

**Structure and**
**Description**

**Data**

**DDF File**

**Varying Length Records**

**Data**
**Desc Record**

**Data Record**

## SDTS Part 3

**Leaves some of the mapping to be completed --either by a user mapping or a profile**

**SDTS Part 3**

## Part 3: What does Table 1 do?

**Table 1 specifies the “structure and description” components for each type of module field.**
**Table 1 specifies the ISO 8211 tags, field controls, names, labels and formats reserved by this standard for the transfer of a set of complete modules.**

**Part 3: What does Table 1 do?**

## Part 3: How to Read Table 1

**Format of an entry in Table1:**
**Tag****	**** ****	****	****st00fuName&****	****	****(section reference)**
**[n] | [m,n]****	**** ****	****Label&**
**	****	**** ****	****	****Format;**
**Order:**
**Fields for each module are grouped together.  The order of the fields follows the order in the module specifications  of Part 1, Section 5.                                                                                   Same applies to the order of the modules.**

**Part 3: How to Read Table 1**

## Module Specification

**Catalog/Directory **
**  ****CATD**
**(P) [M]**
**                                 ****Module Name[M]     A       MODN**
**                                 ****Record Id [M]            I       RCID**
**                                 ****Name [M]                  A      NAME**
**                                 ****Type [M]                   A      TYPE**
**                                 ****Volume                     A      VOLM**
**                                 ****File                            A      FILE**
**                                 ****Record                     I/A     RECD**
**                                 ****Comment                  A      COMT**

**Module Specification**

## Part 3, Table 1 Entry :

**CATD        1600;&CATALOG/DIRECTORY&**
**[8]              MODN!RCID!NAME!TYPE!VOLM!**
**                  ****FILE!RECD!COMT&**
**                  ****(A,I,4A,z,A); where z implies (I/A).**

**Part 3, Table 1 Entry :**

## DDF (Data Descriptive File)

**&DDF RECORD IDENTIFIER;1600;&CATALOG/DIRECTORY&MODN!RCID!NAME!TYPE!VO**
**LM!FILE!&(A,I,4A);00083 R     00039   21040001060CATD386;    1;CATD&1**
**&IDEN&IDEN&USGSSDT&WMHYIDEN.DDF;    2;CATD&2&CATD&CATD&USGSSDT&WMHYC**
**ATD.DDF;    3;CATD&3&CATS&CATS&USGSSDT&WMHYCATS.DDF;    4;CATD&4&IR**
**EF&IREF&USGSSDT&WMHYIREF.DDF;    5;CATD&5&XREF&XREF&USGSSDT&WMHYXREF**
**.DDF;    6;CATD&6&RGIS&RGIS&USGSSDT&WMHYRGIS.DDF;    7;CATD&7&DDDF&**
**DDDF&USGSSDT&WMHYDDDF.DDF;    8;CATD&8&DDOM&DDOM&USGSSDT&WMHYDDOM.DD**
**F;    9;CATD&9&DDSH&DDSH&USGSSDT&WMHYDDSH.DDF;   10;CATD&10&STAT&ST**
**AT&USGSSDT&WMHYSTAT.DDF;   11;CATD&11&DQHL&DQHL&USGSSDT&WMHYDQHL.DDF**
**;   12;CATD&12&DQPA&DQPA&USGSSDT&WMHYDQPA.DDF;   13;CATD&13&DQAA&DQ**
**AA&USGSSDT&WMHYDQAA.DDF;   14;CATD&14&DQLC&DQLC&USGSSDT&WMHYDQLC.DDF**
**;   15;CATD&15&DQCG&DQCG&USGSSDT&WMHYDQCG.DDF;   16;CATD&16&AP00&AT**
**PR&USGSSDT&WMHYAP00.DDF;   17;CATD&17&AP01&ATPR&USGSSDT&WMHYAP01.DDF**
**;   18;CATD&18&NE01&PNTS&USGSSDT&WMHYNE01.DDF;   19;CATD&19&NA01&PN**
**TS&USGSSDT&WMHYNA01.DDF;   20;CATD&20&NO01&PNTS&USGSSDT&WMHYNO01.DDF**
**;   21;CATD&21&LE01&LINE&USGSSDT&WMHYLE01.DDF;   22;CATD&22&PC01&PO**
**LY&USGSSDT&WMHYPC01.DDF; **

**DDF (Data Descriptive File)**

## DDF (edited to show records)

**0000;&WMHYCATD;**
**0100;&DDF RECORD IDENTIFIER;**
**1600;&CATALOG/DIRECTORY&MODN!RCID!NAME!TYPE!VOLM!FILE!&(A,I,4A);**
**00083 R     00039   21040001060CATD386;    **
**1;CATD&  1& IDEN& IDEN& USGSSDT& WMHYIDEN.DDF;    **
**2;CATD&  2& CATD& CATD& USGSSDT& WMHYCATD.DDF;    **
**3;CATD&  3& CATS& CATS& USGSSDT& WMHYCATS.DDF;    **
**4;CATD&  4& IREF& IREF& USGSSDT& WMHYIREF.DDF;    **
**5;CATD&  5& XREF& XREF& USGSSDT& WMHYXREF.DDF;    **
**6;CATD&  6& RGIS& RGIS& USGSSDT& WMHYRGIS.DDF;    **
**7;CATD&  7& DDDF& DDDF& USGSSDT& WMHYDDDF.DDF;    **
**8;CATD&  8& DDOM& DDOM& USGSSDT& WMHYDDOM.DDF;    **
**9;CATD&  9& DDSH& DDSH& USGSSDT& WMHYDDSH.DDF;   **
**10;CATD& 10& STAT& STAT& USGSSDT& WMHYSTAT.DDF;   **
**11;CATD& 11& DQHL& DQHL& USGSSDT& WMHYDQHL.DDF; **
**                                            ****  ****:**
**                                    ****:**
**20;CATD& 20& NO01& PNTS& USGSSDT& WMHYNO01.DDF;   **
**21;CATD& 21& LE01& LINE& USGSSDT& WMHYLE01.DDF;   **
**22;CATD& 22& PC01& POLY& USGSSDT& WMHYPC01.DDF; **

**DDF (edited to show records)**