[Top] [Prev] [Next] [Bottom]

American National Standard for Information Systems

Spatial Data Transfer Standard - Part 3, ISO 8211 Encoding

1 Introduction

1.1 Purpose of ISO 8211 Encoding

The ISO 8211¹ encoding provides a representation of a Spatial Data Transfer Standard (SDTS) file set in a standardized method enabling the file set to be exported to or imported from different media by general purpose ISO 8211 software.

1.2 Objectives

This encoding was selected with the following objectives:

a) to place this standard within a broader community of interchange based on a general purpose, interchange standard;

b) to place the encoding of this standard in a standardized vehicle that provides the syntax and semantics necessary to the transport of files, records, fields and subfields accompanied by their data description in a machine readable form;

c) to provide for media independence of the transfer file set;

d) to provide for future extensions of the standard (e.g. adding new modules, fields, subfields) without compromise of the then existing implementations;

e) to provide for user extensions without compromising the constructs of the standard.

1.3 Relationship to Other Standards

ISO 8211 is a general purpose, media-independent interchange standard whose variable length records may be written on any medium that is able to accept them, including communications lines. In order to promote transfer, the user is advised to employ media for which volume and file structure standards exist as well as widespread implementations. The specific requirements for currently standardized media are given in section 10.

1.4 Status of Annexes

The annexes do not form an integral part of the standard but are added to provide additional information and explanation.

2 Scope and Field of Application

2.1 Scope

This part of the standard specifies an encoding of an SDTS file set in ISO 8211 and on standardized media.

2.2 Field of Application

This part of the standard applies to all ISO 8211 encodings of part 1 of this standard and to user extensions (see part 3, annex A) of this standard.

3 References

When any of the standards cited in this section is superseded by an approved revision, the revision shall apply.

ANSI X3.122-1986, Computer Graphics Metafile (CGM), FIPSPUB 128, 16 Mar 1987.

ANSI X3.27-1987, American National Standard for File Structure and Labelling of Magnetic Tapes for Information Interchange (ISO 1001)

ANSI/ISO 4341-1978, American National Standard for Magnetic Tape Cassette and Cartridge Labelling and File Structure for Information Interchange

ANSI/ISO 8211-1994, American National Standard for Information Processing - Specification for a Data Descriptive file for Information Interchange

ISO 6093-1985, Information Processing - Specification for Representation of Numeric Values in Character Strings for Information Interchange

ISO 9293-1986, Volume and File Structure of Flexible Disk Cartridges for Information Interchange

ISO 9660-1986, Volume and File Structure of CD-ROM for Information Interchange

4 Definitions

The terms used in this part of the standard are limited to those terms in common usage, or defined in part 1 or part 2, or those found in the cited ISO 8211 document.

5 Nomenclature

The methodology of this part is to define ISO 8211 constructs which, for the purpose of transfer, accept the logical constructs of part 1 of the standard and preserve their meaning. Where possible, a correspondence is maintained between the module subfields and fields of part 1 and the ISO 8211 subfields and fields maintaining both identification and order when required.

The content and size of a transfer determine what fields are present and how they are collected into records and the records into files. Part 1 allows the user considerable freedom to structure records and files as needed and this part does likewise.

Table 3, in section 6, contains the specification for the ISO 8211 encoding of all module fields defined in part 1, section 5. The constructs of Table 3 are related to the logical constructs of part 1 by section references, e.g., (see part 1, 5.d..), and by the nomenclature equivalents in Table 1:

Table 1 - Nomenclature equivelants between Part 1 and Table 3

Part1	Table 31
Module Subfield	Subfield/Element
Subfield Name/ Mnemonic	Label
Module Field	Field
Field Name	Name
Field Mnemonic	Tag
Domain	Data type/format

1 ISO 8211 nomenclature

The identification nomenclature of part 1 has been used for most of the corresponding constructions of this part. The mnemonic for a module field becomes an ISO 8211 tag and the mnemonic for a subfield becomes an ISO 8211 label. Table 3 specifies any exceptions to this practice. The field names are the corresponding names in part 1. Specifications for the substantive contents and semantics of the user data subfields corresponding to the tags and labels are found in parts 1 and 2.

Table 2 is a concordance relating the ISO 8211 data types of this Part to the data types and domains of part 1, section 4.2.1.

Table 2 - Data type concordance¹

Generic Type	ISO 8211 Data Type	Part 1 Data Type(s); Domain
Text	A	A; Graphic characters, Alphanumeric, Alphabetic
Integer	I	I; Integer
Real, fixed	R	R; Real
Real, float	S	S; Real
Logical	C	C; Binary
Binary	B	B; Binary
Binary	B	BUI, BIdd, BUIdd; Integer2
Binary	B	BFPdd;Floating Point3
Integer, unsigned	B1w	BUIdd; Unsigned Integer
Integer, signed	B2w	BIdd; Signed Integer
Real, float	B4w	BFPdd; Floating Point

1 The width indicators w and dd are related as follows: dd = 8*w, w must be a legal ISO-8211 binary width. 2 Binary Integers of this type must be formatted as specified by ANSI X3.122-1986, Computer Graphics Metafile (CGM), Part 3: Binary Encoding. The BUI type is an arbitrary precision binary. 3 Binary Floating point values of this type must be formatted as specified by ANSI/IEEE 754-1985, Standard for Binary Floating-Point Arithmetic.

When an ISO-8211 type of Binary is specified for a subfield, the intended type may need to be derived from the subfields corresponding format subfield, e.g. if the X subfield of the Spatial Address field has an ISO-8211 type of B, then the intended type can be derived from the corresponding Internal Reference record's Horizontal Component Format subfield.

The following domains may result in any one of the ISO 8211 data types depending on their use: Allowable values, Standard code sets and Standard field where domain is defined in Data Dictionary.

6 Specifications

This section specifies the allowable subset of tags, names, labels, formats and other control information necessary to the transfer of spatial data. It specifies the limits allowed users for those ISO 8211 parameters that are permitted to vary such that transfer may be accomplished. The specifications for several media are also provided.

Annex A suggests methods by which private agreements can extend the standard within the general specifications of ISO 8211 in order that the user can, by private agreement, transfer data not anticipated by this standard in a manner that does not conflict with this standard.

6.1 Specifications of ISO 8211 Constructs

Table 3 specifies the ISO 8211 tags, control fields, names, labels and formats reserved by this standard for the transfer of a set of complete modules as single or multiple files.

The field controls in Table 3 are based on the following rule. An ISO 8211 vector data structure (1x00) is used for all primary fields and other fields of part 1 that do not repeat within a module record. An ISO 8211 array data structure (2x00) is used for fields that may repeat within a module record. Alternatives to the field controls of Table 3 are specified in 6.4.1.

6.1.1 Notational Conventions of Table 3

The contents of Table 3 are formatted as follows:

Tag		st00fuName& (See part 1, section ref.)
[n]|[m,n]		Label& - continued to next line as 
necessary
		Format;
where:
	Tag		is a four character ISO 8211 tag
	st00fu		are the ISO 8211 field controls 
	where:		s is the data structure code
			t is the data type code
			00 are required characters
			f is the printable graphic for the 
field terminator
			u is the printable graphic for unit 
terminator

The printable graphics ";" and "&" at other locations in Table 3 represent FT(1/14) and UT(1/15), the required delimiters of the data description subfields.

	Name&		is the ISO 8211 name and "&" 
represents its delimiter
	[ ]		signifies that no labels are 
specified
	[n]		signifies n subfield elements of an 
n-tuple
	[m,n]		signifies the number of elements 
in a two dimensional array; often 
an n-tuple, repeating m times
			Where n is not explicitly specified, 
it is determined by the number of 
items in the user's n-tuple.
			Where m is not explicitly specified, 
the field is a repeating n-tuple 
whose first extent is determined 
from the data in the ISO 8211 
field.
	Label&		is an ISO 8211 vector label or 
Cartesian label and "&" represents 
its delimiter
			A vector label identifies the 
components of an n-tuple and has 
the form, lab1!lab2!...labn.
			A Cartesian label identifies the 
columns of a repeating table and 
has the form, *col1!col2!...coln.
	Format;		is the ISO 8211 format control and 
";" represents its delimiter.

Table 3 - Tags, field controls, names, labels and formats

ISO 8211 File Control Field
0000	0000;&external file title&
[]	&
	;
	NOTE: This field exists only in the ISO 8211 data descriptive record and contains a human-readable file title
ISO 8211 Record Identifier Field
0001	0100;&DDF RECORD IDENTIFIER&
[]	&
	;
	Note: This field is required by ISO 8211 in each record and contains a unique identifier of a data record. It is not the SDTS record identifier, RCID.
Global Information Modules (see part 1, 5.2)
IDEN	1600;&IDENTIFICATION& (See part 1, 5.2.1)
[15]	MODN!RCID!STID!STVS!DOCU!PRID!PRVS!PDOC!TITL!DAID!DAST!MPDT!DCDT!SCAL!COMT&
	(A,I,11A,I,A);
CONF	1600;&CONFORMANCE&
[8]	FFYN!VGYN!GTYN!RCYN!EXSP!FTLV!CDLV!NGDM&
	(4A,3I,A);
ATID	2600;&ATTRIBUTE ID&
[m,2]	*MODN!RCID&
	(A,I);
CATD	1600;&CATALOG/DIRECTORY& (See part 1, 5.2.2.1)
[10]	MODN!RCID!NAME!TYPE!VOLM!FILE!RECD!EXTR!MVER!COMT&
	(A,I,4A,z,3A); where z implies (I|A).
CATX	1600;&CATALOG/CROSS-REFERENCE& (See part 1, 5.2.2.2)
[7]	MODN!RCID!NAM1!TYP1!NAM2!TYP2!COMT&
	(A,I,8A);
CATS	1600;&CATALOG/SPATIAL DOMAIN& (See part 1, 5.2.2.3)
[10]	MODN!RCID!NAME!TYPE!DOMN!MAP!THEM!AGOB!AGTP!COMT&
	(A,I,5A);
SCUR	1600;&SECURITY& (See part 1, 5.2.3)
[8]	MODN!RCID!CLAS!CTRL!RLIS!RVDT!RVIS!COMT&
	(A,I,6A);
FRID	2600;&Foreign ID&
[m,2]	*MODN!RCID&
	(A,I);
IREF	1600;&INTERNAL SPATIAL REFERENCE& (See part 1, 5.2.4.1)
[17]	MODN!RCID!COMT!SATP!XLBL!YLBL!HFMT!VFMT!SFAX!SFAY!SFAZ!XORG!YORG!ZORG!XHRS!YHRS!VRES&
	(A,I,6A,9R);
DMID	2600;&DIMENSION ID&
[m,2]	*MODN!RCID&
	(A,I);
XREF	1600;&EXTERNAL SPATIAL REFERENCE& (See part 1, 5.2.4.2)
[10]	MODN!RCID!COMT!RDOC!RSNM!VDAT!SDAT!HDAT!ZONE!PROJ&
	(A,I,8A);
ATID	1600;&ATTRIBUTE ID&
[2]	MODN!RCID&
	(A,I);
VATT	2600;&VERTICAL ATTRIBUTES&
[m,4]	*VDAT!VEM!ATLB!AUTH&
	(4A);
SATT	2600;&SOUNDING ATTRIBUTES&
[m,4]	*SDAT!SEM!ATLB!AUTH&
	(4A);
DMDF	1600;&DIMENSION DEFINITION& (see section 5.2.4.4)
[6]	MODN!RCID!DMLB!DFMT!DRES!DDMU!DDES&
	(A,I,2A,z,2A); where z implies (I|R|S|C|B)
	When B is specified the ISO 8211 binary data type may be extended by Dimension Component Format subfield of the Dimension Definition field, DMDF/DFMT.
DATP	2600;&DIMENSION ATTRIBUTE ID&
[m,2]	*MODN!RCID&
	(A,I);
RGIS	1600;&REGISTRATION& (See part 1, 5.2.4.3)
[3]	MODN!RCID!COMT&
	(A,I,A);
EADS	2600;&EXTERNAL REFERENCE SPATIAL ADDRESS&
[m,3]	*X!Y!Z&
	(3z); where z implies (R|S).
IADS	2600;&INTERNAL REFERENCE SPATIAL ADDRESS&
[m,3]	*X!Y!Z
	(3z); where z implies (I|R|S|B)
	When B is specified by z for internal spatial address subfields, the ISO 8211 binary data type is extended by the HFMT (for X and Y) and VFMT (for Z) subfields of the associated Internal Spatial Reference module record, IREF/HFMT and IREF/VFMT.
SPDM	1600;&SPATIAL DOMAIN& (See part 1, 5.2.5)
[5]	MODN!RCID!DTYP!DSTP!COMT&
	(A,I,3A);
DMSA	2600;&DOMAIN SPATIAL ADDRESS&
[m,]	*X!Y!Z&
	(3z); if DSTP ="INTERNAL" then z implies (I|R|S|B) if DSTP ="EXTERNAL" then z implies (R|S)
	When B is specified by z for internal spatial address subfields, the ISO 8211 binary data type is extended by the HFMT (for X and Y) and VFMT (for Z) subfields of the associated Internal Spatial Reference module record, IREF/HFMT and IREF/VFMT.
DDDF	1600;&DATA DICTIONARY/DEFINITION& (See part 1, 5.2.6.1)
[8]	MODN!RCID!EORA!EALB!SRCE!DFIN!AUTH!ADSC&
	(A,I,6A);
DDOM	1600;&DATA DICTIONARY/DOMAIN& (See part 1, 5.2.6.2)
[10]	MODN!RCID!ATLB!AUTH!ATYP!ADVF!ADMU!RAVA!DVAL!DVDF&
	(A,I,6A,z,A); z implies (A|I|R|S|C|B)
	When B is specified the ISO 8211 binary data type may be extended by the Attribute Domain Value Format subfield, ADVF.
DDSH	1600;&DATA DICTIONARY/SCHEMA& (See part 1, 5.2.6.3)
[13]	MODN!RCID!NAME!TYPE!ETLB!EUTH!ATLB!AUTH!FMT!UNIT!PREC!MXLN!KEY&
	(A,I,8A,R,I,A);
STAT	1600;&TRANSFER STATISTICS& (See part 1, 5.2.7)
[6]	MODN!RCID!MNTF!MNRF!NREC!NSAD&
	(A,I,2A,2I);
Data Quality (See part 1, 5.3)
DQHL	1600;&LINEAGE& (See part 1, 5.3.1)
[3]	MODN!RCID!COMT&
	(A,I,A);
ATID	2600;&ATTRIBUTE ID&
[m,2]	*MODN!RCID&
	(A,I);
FRID	2600;&FOREIGN ID&
[m,2]	*MODN!RCID&
	(A,I);
DQPA	1600;&POSITIONAL ACCURACY& (See part 1, 5.3.2)
[3]	MODN!RCID!COMT&
	(A,I,A);
ATID	2600;&ATTRIBUTE ID&
[m,2]	*MODN!RCID&
	(A,I);
FRID	2600;&FOREIGN ID&
[m,2]	*MODN!RCID&
	(A,I);
DQAA	1600;&ATTRIBUTE ACCURACY& (See part 1, 5.3.3)
[3]	MODN!RCID!COMT&
	(A,I,A);
ATID	2600;&ATTRIBUTE ID&
[m,2]	*MODN!RCID&
	(A,I);
FRID	2600;&FOREIGN ID&
[m,2]	*MODN!RCID&
	(A,I);
DQLC	1600;&LOGICAL CONSISTENCY& (See part 1, 5.3.4)
[3]	MODN!RCID!COMT&
	(A,I,A);
ATID	2600;&ATTRIBUTE ID&
[m,2]	*MODN!RCID&
	(A,I);
FRID	2600;&FOREIGN ID&
[m,2]	*MODN!RCID&
	(A,I);
DQCG	1600;&COMPLETENESS& (See part 1, 5.3.5)
[3]	MODN!RCID!COMT&
	(A,I,A);
ATID	2600;&ATTRIBUTE ID&
[m,2]	*MODN!RCID&
	(A,I);
FRID	2600;&FOREIGN ID&
[m,2]	*MODN!RCID&
	(A,I);
Attribute Modules (See part 1, 5.4)
ATPR	1600;&ATTRIBUTE PRIMARY& (See part 1, 5.4.1)
[2]	MODN!RCID&
	(A,I);
OBID	1600;&SPATIAL OBJECT ID&
[2]	MODN!RCID&
	(A,I);
ATTP	1x00;&PRIMARY ATTRIBUTES&
[n]	attribute1!attribute2!...!attributen&
	(z,z...); x is selected to be consistent with the data type z implies (A|I|R|S|C|B)
	When B is specified by z for attribute subfields, the ISO 8211 binary data type is extended by the Format subfield of the associated Data Dictionary Schema module record, DDSH/FMT. The attribute subfield's label will match the Attribute Label subfield of the associated Data Dictionary Schema module record, DDSH/ATLB.
ATSC	1600;&ATTRIBUTE SECONDARY& (See part 1, 5.4.2)
[2]	MODN!RCID&
	(A,I);
ATTS	1x00;&SECONDARY ATTRIBUTES&
[n]	attribute1!attribute2!...!attributen&
	(z,z...); x is selected to be consistent with the data type z implies (A|I|R|S|C|B)
	When B is specified by z for attribute subfields, the ISO 8211 binary data type is extended by the Format subfield of the associated Data Dictionary Schema module record, DDSH/FMT. The attribute subfield's label will match the Attribute Label subfield of the associated Data Dictionary Schema module record, DDSH/ATLB.
Composite Module (See part 1, 5.5)
COMP	1600;&COMPOSITE& (See part 1, 5.5)
[3]	MODN!RCID!OBRP&
	(A,I,A);
ATID	2600;&ATTRIBUTE ID&
[m,2]	*MODN!RCID&
	(A,I);
FRID	2600;&FOREIGN ID&
[m,3]	*MODN!RCID!USAG&
	(A,I,A(1));
CPID	2600;&COMPOSITE ID&
[m,2]	*MODN!RCID&
	(A,I);
Vector Modules (See part 1, 5.6)
PNTS	1600;&POINT-NODE& (See part 1, 5.6.1)
[3]	MODN!RCID!OBRP&
	(A,I,A);
SADR	1600;&SPATIAL ADDRESS&
[3+n]	X!Y!Z!dimension1!dimension2!...!dimensionn&
	(3z,v,v,...,v); where z implies (I|R|S|B). where v implies (A|I|R|S|C|B)
	When B is specified by z for internal spatial address subfields, the ISO 8211 binary data type is extended by the HFMT (for X and Y) and VFMT (for Z) subfields of the associated Internal Spatial Reference module record, IREF/HFMT and IREF/VFMT. When B is specified by v for nongeospatial dimension subfields, the ISO 8211 binary data type is extended by the DFMT subfield of the corresponding Dimension Definition module record, DMDF/DFMT. NOTE: If there is no Dimension Definition module, then the nongeospatial subfields do not apply.
ATID	2600;&ATTRIBUTE ID&
[m,2]	*MODN!RCID&
	(A,I);
LNID	2600;&LINE ID&
[m,3]	*MODN!RCID!USAG&
	(A,I,A(1));
ARID	2600;&AREA ID&
[m,2]	*MODN!RCID&
	(A,I);
CPID	2600;&COMPOSITE ID&
[m,2]	*MODN!RCID&
	(A,I);
RPID	2600;&REPRESENTATION MODULE ID&
[m,2]	*MODN!RCID&
	(A,I);
OSAD	2600;&ORIENTATION SPATIAL ADDRESS&
[m,3]	*X!Y!Z&
	(3z); where z implies (I|R|S|B).
	When B is specified by z for internal spatial address subfields, the ISO 8211 binary data type is extended by the HFMT (for X and Y) and VFMT (for Z) subfields of the associated Internal Spatial Reference module record, IREF/HFMT and IREF/VFMT.
PAID	2600;&ATTRIBUTE PRIMARY FOREIGN ID&
[m,3]	*MODN!RCID!ATLB&
	(A,I,A);
SSAD	2600;&SYMBOL ORIENTATION SPATIAL ADDRESS&
[m,3]	*X!Y!Z&
	(3z); where z implies (I|R|S|B).
	When B is specified by z for internal spatial address subfields, the ISO 8211 binary data type is extended by the HFMT (for X and Y) and VFMT (for Z) subfields of the associated Internal Spatial Reference module record, IREF/HFMT and IREF/VFMT.
LINE	1600;&LINE& (See part 1, 5.6.2)
[3]	MODN!RCID!OBRP&
	(A,I,A);
ATID	2600;&ATTRIBUTE ID&
[m,2]	*MODN!RCID&
	(A,I);
PIDL	1600;&POLYGON ID LEFT&
[2]	MODN!RCID&
	(A,I);
PIDR	1600;&POLYGON ID RIGHT&
[2]	MODN!RCID&
	(A,I);
SNID	1600;&STARTNODE ID&
[2]	MODN!RCID&
	(A,I);
ENID	1600;&ENDNODE ID&
[2]	MODN!RCID&
	(A,I);
CCID	2600;&CHAIN COMPONENT ID&
[m,3]	*MODN!RCID!USAG&
	(A,I,A(1));
SADR	2600;&SPATIAL ADDRESS&
[m,3+n]	*X!Y!Z!dimension1!dimension2!...!dimensionn&
	(3z,v,v,...,v); where z implies (I|R|S|B). where v implies (A|I|R|S|C|B)
	When B is specified by z for internal spatial address subfields, the ISO 8211 binary data type is extended by the HFMT (for X and Y) and VFMT (for Z) subfields of the associated Internal Spatial Reference module record, IREF/HFMT and IREF/VFMT. When B is specified by v for nongeospatial dimension subfields, the ISO 8211 binary data type is extended by the DFMT subfield of the corresponding Dimension Definition module record, DMDF/DFMT. NOTE: If there is no Dimension Definition module, then the nongeospatial subfields do not apply.
CPID	2600;&COMPOSITE ID&
[m,2]	*MODN!RCID&
	(A,I);
RPID	2600;&REPRESENTATION MODULE ID&
[m,2]	*MODN!RCID&
	(A,I);
ARC	1600;&ARC& (See part 1, 5.6.3)
[5]	MODN!RCID!OBRP!SRFC!ORDR&
	(A,I,2A,I);
ARAD	2600;&ARC ADDRESS&
[3,3]	CTAD!STAD!ENAD*X!Y!Z&
	(3z); where z implies (I|R|S|B).
	When B is specified by z for internal spatial address subfields, the ISO 8211 binary data type is extended by the HFMT (for X and Y) and VFMT (for Z) subfields of the associated Internal Spatial Reference module record, IREF/HFMT and IREF/VFMT.
ELAD	2600;&ELLIPSE ADDRESS&
[2,3]	MJRA!MNRA*X!Y!Z&
	(3z); where z implies (I|R|S|B).
	When B is specified by z for internal spatial address subfields, the ISO 8211 binary data type is extended by the HFMT (for X and Y) and VFMT (for Z) subfields of the associated Internal Spatial Reference module record, IREF/HFMT and IREF/VFMT.
CADR	2600;&CURVE ADDRESS&
[m,3]	*X!Y!Z&
	(3z); where z implies (I|R|S|B)
	When B is specified by z for internal spatial address subfields, the ISO 8211 binary data type is extended by the HFMT (for X and Y) and VFMT (for Z) subfields of the associated Internal Spatial Reference module record, IREF/HFMT and IREF/VFMT.
ATID	2600;&ATTRIBUTE ID&
[m,2]	*MODN!RCID&
	(A,I);
CPID	2600;&COMPOSITE ID&
[m,2]	*MODN!RCID&
	(A,I);
RPID	2600;&REPRESENTATION MODULE ID&
[m,2]	*MODN!RCID&
	(A,I);
RING	1600;&RING& (See part 1, 5.6.4)
[3]	MODN!RCID!OBRP&
	(A,I,A);
LAID	2600;&LINE OR ARC FOREIGN ID&
[m,3]	*MODN!RCID!USAG&
	(A,I,A(1));
PLID	2600;&POLYGON ID&
[m,2]	*MODN!RCID&
	(A,I);
POLY	2600;&POLYGON& (See part 1, 5.6.5)
[m,3]	*MODN!RCID!OBRP&
	(A,I,A);
ATID	2600;&ATTRIBUTE ID&
[m,2]	*MODN!RCID&
	(A,I);
RFID	2600;&RING ID&
[m,3]	*MODN!RCID!USAG&
	(A,I,A(1));
CHID	2600;&CHAIN ID&
[m,3]	*MODN!RCID!USAG&
	(A,I,A(1));
CPID	2600;&COMPOSITE ID&
[m,2]	*MODN!RCID&
	(A,I);
RPID	2600;&REPRESENTATION MODULE ID&
[m,2]	*MODN!RCID&
	(A,I);
Raster Modules (See part 1, 5.7)
RSDF	1600;&RASTER DEFINITION& (See part 1, 5.7.1)
[20]	MODN!RCID!OBRP!CSCD!AQMD!AQDT!COMT!DEFI!CMPR!CMMD!DCOM!METH!RWXT!CLXT!PLXT!SCOR!SCPT!TIDX!TIFT! TIDS!ALTN!FSCN!ASPR!NLAY&
	(A,I,10A,3I,5A,I,A,R,I);
ISID	1600;&INTERNAL SPATIAL ID&
[2]	MODN!RCID&
	(A,I);
RDXT	2600;&RASTER DIMENSION EXTENT&
[m,2]	*DEXT!DSCO&
	(I,A);
SADR	1600;&SPATIAL ADDRESS&
[3+n]	X!Y!Z!dimension1!dimension2!...!dimensionn&
	(3z,v,v,...,v); where z implies (I|R|S|B). where v implies (A|I|R|S|C|B)
	When B is specified by z for internal spatial address subfields, the ISO 8211 binary data type is extended by the HFMT (for X and Y) and VFMT (for Z) subfields of the associated Internal Spatial Reference module record, IREF/HFMT and IREF/VFMT. When B is specified by v for nongeospatial dimension subfields, the ISO 8211 binary data type is extended by the DFMT subfield of the corresponding Dimension Definition module record, DMDF/DFMT. NOTE: If there is no Dimension Definition module, then the nongeospatial subfields do not apply.
XXLB	2600;&X-AXIS LABEL&
[m,1]	*CAVL&
	(z); where z implies (I|R|S|B)
	When B is specified the ISO 8211 binary data type may be extended by Horizontal Component Format subfield of the Internal Spatial Reference field, IREF/HFMT.
YXLB	2600;&Y-AXIS LABEL&
[m,1]	*RAVL&
	(z); where z implies (I|R|S|B)
	When B is specified the ISO 8211 binary data type may be extended by Horizontal Component Format subfield of the Internal Spatial Reference field, IREF/HFMT.
ZXLB	2600;&Z-AXIS LABEL&
[m,1]	*ZAVL&
	(z); where z implies (I|R|S|B)
	When B is specified the ISO 8211 binary data type may be extended by Vertical Component Format subfield of the Internal Spatial Reference field, IREF/VFMT.
The DAL? field will produce permutations when more than two nongeospatial dimensions are labeled. Each permutation will be encoded into one ISO-8211 Array field, as follows. This first permutation will correspond to the first Dimension Definition record referenced by the associated Internal Reference module record.
DAL1	2600;&DIMENSION AXIS LABEL&
[m,1]	*DXVL&
	(z); where z implies (A|I|R|S|C|B)
	When B is specified the ISO 8211 binary data type may be extended by Dimension Component Format subfield of the associated Dimension Definition module record, DMDF/DFMT.
This second permutation will correspond to the second Dimension Definition record referenced by the associated Internal Reference module record.
DAL2	2600;&DIMENSION AXIS LABEL&
[m,1]	*DXVL&
	(z); where z implies(A|I|R|S|C|B)
	When B is specified the ISO 8211 binary data type may be extended by Dimension Component Format subfield of the associated Dimension Definition module record, DMDF/DFMT.
Subsequent permutations will correspond to the subsequent Dimension Definition records found in the order they are referenced by the associated Internal Reference module record.
DALn	2600;&DIMENSION AXIS LABEL&
[m,1]	*DXVL
	(z); where z implies (A|I|R|S|C|B) where n may be any legal ISO-8211 field tag character.
	When B is specified the ISO 8211 binary data type may be extended by Dimension Component Format subfield of the associated Dimension Definition module record, DMDF/DFMT.
LYID	2600;&LAYER ID&
[m,2]	*MODN!RCID&
	(A,I);
RATP	2600;&RASTER ATTRIBUTE ID&
[m,2]	*MODN!RCID&
	(A,I);
CPID	2600;&COMPOSITE ID&
[m,2]	*MODN!RCID&
	(A,I);
LDEF	1600;&LAYER DEFINITION& (See part1, 5.7.2)
[17]	MODN!RCID!CMNM!LLBL!CODE!BMSK!NROW!NCOL!NPLA!SORI!SOCI!SOPI!RWOO!CLOO! PLOO!INTR!COMT&
	(A,I,3A,C,9I,2A);
LDXT	2600;&LAYER DIMENSION EXTENT&
[m,4]	*DEXT!SODM!DTOO!DINR&
	(3I,A);
LATP	2600;&LAYER ATTRIBUTE ID&
[m,2]	*MODN!RCID&
	(A,I);
CELL	1600;&CELL& (See section 5.7.3)
[6]	MODN!RCID!ROWI!COLI!PLAI!TIND&
	(A,4I,z); where z implies (I|B)
	When B is specified the ISO 8211 binary data type may be extended by the Tesseral Index Format subfield of the Raster Definition module record, RSDF/TIFT.
DNDX	2600;&DIMENSION INDEX&
[m,1]	*ANVL&
	(I);
SADR	1600;&SPATIAL ADDRESS&
[3+n]	X!Y!Z!dimension1!dimension2!...!dimensionn&
	(3z,v,v,...,v); where z implies (I|R|S|B). where v implies (A|I|R|S|C|B)
	When B is specified by z for internal spatial address subfields, the ISO 8211 binary data type is extended by the HFMT (for X and Y) and VFMT (for Z) subfields of the associated Internal Spatial Reference module record, IREF/HFMT and IREF/VFMT. When B is specified by v for nongeospatial dimension subfields, the ISO 8211 binary data type is extended by the DFMT subfield of the corresponding Dimension Definition module record, DMDF/DFMT. NOTE: If there is no Dimension Definition module, then the nongeospatial subfields do not apply.
ATID	*MODN!RCID&
[m,2]	(A,I);
The Data Descriptive Record for the CVLS field depends on the Cell Sequencing Code SubField and the number of layers being transferred per Cell Module. Based on these conditions, each Cell module can be classified into one of the categories. NOTE: One and only one of the following categories will apply for a given Cell module.
CVLS	2x00;&CELL VALUES&
[m,n]	&
	(z); where z implies (A|I|R|S|C|B)
	This form works for layers interleaved by line or stream. No labels are used. A dope vector describes the number of dimensions and the extent of each as pertaining to the amount of cell values stored in this ISO 8211 record. When B is specified the ISO 8211 binary data type may be extended by the Format subfield of the associated Data Dictionary/Schema module record, DDSH/FMT. The layer subfield's label will match the Attribute Label subfield of the associated Data Dictionary Schema module record, DDSH/ATLB.
CVLS	2x00;&CELL VALUES&
[m,n]	*layer1!layer2!...!layern&
	(z,z, ...z); x is selected to be consistent with the data type where z implies (A|I|R|S|C|B) This form works for layers interleaved by pixel, or for a single layer where only one label is present.
	When B is specified the ISO 8211 binary data type may be extended by the Format subfield of the associated Data Dictionary/Schema field, DDSH/FMT. The layer subfield's label will match the Attribute Label subfield of the associated Data Dictionary Schema module record, DDSH/ATLB. One cell value from each layer will be placed in one repetition of the CVLS array. It is possible to encode all layers of the raster into a single ISO-8211 array.
Graphic Representation (See part 1, 5.8)
TEXT	1600;&TEXT REPRESENTATION& (See part 1, 5.8.1)
[14]	MODN!RCID!BSCL!SSCL!LSCL!CLDX!CHHT!FTDX!TPTH!UTXA!VTXA!CHEX!CHSP!SANG&
	(A,5I,R,I,3A,3R);
LNRP	1600;&LINE REPRESENTATION& (See part 1, 5.8.2)
[8]	MODN!RCID!BSCL!SSCL!LSCL!CLDX!LTYP!LWTH&
	(A,6I,R);
SYRP	1600;&SYMBOL REPRESENTATION& (See part 1, 5.8.3)
[8]	MODN!RCID!BSCL!SSCL!LSCL!CLDX!SMKR!MKSZ&
	(A,6I,R);
AFIL	1600;&AREA FILL REPRESENTATION& (See part 1, 5.8.4)
[9]	MODN!RCID!BSCL!SSCL!LSCL!CLDX!FTYP!HIDX!PIDX&
	(A,5I,A,2I);
CLRX	1600;&COLOR INDEX& (See part 1, 5.8.5)
[6]	MODN!RCID!RED!GREN!BLUE!BLCK&
	(A,I,4R);
FONT	1600;&FONT INDEX& (See part 1, 5.8.6)
[3]	MODN!RCID!FNTN&
	(A,I,z); where z implies I|A.
(continued)

			When explicitly specified for a 
subfield, the ISO 8211 data type 
format code i.e., A, I, R, S, C, B) is 
given.
			The formats of subfields with user 
delimiters or fixed extents will 
require completion by the user.
			The presence of "z" implies that 
the data type must be supplied by 
the user from the list of allowed 
types.
			See 6.1.3 (e) for format variations.

The presence of:

	"lowercase" implies a user assigned name, 
label or data type code.
	Solid lines, "______", group associated sets 
of tags and field descriptions that form a 
spatial data module (i.e., the associated 
fields lie between the solid lines).  The 
primary field of the set is listed first and the 
secondary fields, if any, are listed after the 
primary field.

6.1.2 Tags, Names and Labels

The tags, names, and labels shall conform to the meanings specified in part 1 and to Table 3. The spelling of tags, names and labels shall conform to the spellings of Table 3. Labels shall occur in the order specified in Table 3 (see 6.2 for missing data specifications). Where there is a requirement in part 1 for the preservation of the order of module fields and (or) subfields or for the associations between module fields or subfields, this ordering shall be preserved by the order of the ISO 8211 records, fields and subfields.

This section is a constraint on the permissiveness of part 1, 4.1.3.1 and 4.1.3.3.3 with respect to order.

Data descriptive fields that have no specified labels may be augmented by user-supplied labels for the identification of subfield data (see part 1, 5.4).

ISO 8211 does not allow duplicate tags in the same data descriptive record. When there is a need to have duplicate instances of the same generic field description of Table 3 in the same data descriptive record, a tag is permitted to have an optional fifth character to make the tags for the two instances unique.

For example two attribute modules may be encoded in the same file with primary attribute tags:

	ATTP1	1600;&PRIMARY ATTRIBUTES&
		STATE!COUNTY!LANDTYPE&
		(A(2),A(15),I(1));
	ATTP2		2600;&PRIMARY ATTRIBUTES&
		*VEG_TYPE!STOCKING_DATE&
		(I(1),A(8));

The length of the tags within a file must be uniform. Thus when a fifth character is required for uniqueness for some tags, all tags must be five character tags. The use of the character "blank" is not recommended.

6.1.3 Permitted Variations in Field Controls and Formats

ISO 8211 field controls and formats shall conform to Table 3 in the following manner:

a) Data Structure (byte 1) -- This control shall agree with the structure of the data inthe field. Structure codes of 1 and 2 are interchangeable according to the specifications of 6.4.1.

b) Data Type (byte 2) -- This control shall agree with the data type of the corresponding user data.

c) Reserved bytes (bytes 3-4) -- No variation.

d) Printable Delimiters (bytes 5-6) -- The printable graphics to be substituted on display for the field terminator and the unit terminator may be selected by the userto prevent conflict with the data.

The printable graphics, ";" and "&" at other locations in Table 3 represent FT(1/14) and UT(1/15).

e) Format -- The format shall agree with the user data in data type. The widths of fixed-width subfields and the delimiters of variable-width subfields shall agree with the data.

The format controls of Table 3 are specifications that do not include the subfield extents. If used without change the subfield extents would default in ISO 8211 to variable-length subfields with the system delimiter, (1/15). This might result in poor file design; for reasons of efficiency, fixed width subfields are preferred over variable width subfields.

The field terminator (FT(1/14)) and the subfield terminator, either the user selected terminator or the unit terminator (UT(1/15) are not considered a part of the user data and are not subject to the domain constraints that apply to the user data.

6.1.4 Order of Data Items in Arrays

The order of data items in arrays must match the order of the ISO 8211 subfield labels. In ISO 8211 the subfield labels for an array are specified as the Cartesian product of vector labels. These labels when multiplied out correspond to the order of the data.

	a!b!c!...!n*x!y!z = ax ay az bx by bz cx... nz

Notice that the labels in the last vector vary fastest in the sequence. Hence, the order of data in arrays is essentially row-order, with the right-most label varying fastest.

When the first vector label is preceded by an asterisk (referred to as a null vector label in ISO 8211), then the Cartesian product of the vector labels can be thought of collectively as an n-tuple, and this n-tuple can be repeated in the data. In other words, this allows a single field to have multiple values corresponding to the same set of subfield labels.

If an array has a fixed dimension and extent in all data records and a Cartesian label is not required, the label may be replaced by an array descriptor comprising the dimension of the array followed by the extent of each vector, all separated by commas. For instance for a 2 dimensional array with 1024 rows and 512 columns, this descriptor will be: 2,1024,512. This descriptor is also referred to as a "dope vector."

6.2 Missing Data

See part 1, 4.1.3.3.5, 4.1.3.3.6 and 4.1.3.3.9.

This section specifies the methods by which the implementation permits the representation of missing data.

6.2.1 Fields Missing from Entire Files

When a data field is missing from all the data records of a file, the corresponding tag and data descriptive field may be omitted from the DDR of the file. (See part 1, 4.1.3.3.5)

6.2.2 Fields Missing from Specific Data Records

Missing fields may be indicated by omitting the tag from the data record directory and the field from user data area of the data record. (See part 1, 4.1.3.3.5)

6.2.3 Consistently Missing Data Subfields

When a labeled data subfield is consistently missing throughout a file in one of the tagged fields specified in Table 3, then the subfield label corresponding to that data subfield may be omitted from the list of labels. The remaining labels shall occur in the order specified in Table 3. (See part 1, 4.1.3.3.6.)

6.2.4 Intermittently Missing Data Subfields

When a data subfield is intermittently missing, a delimited data format shall be specified and a null data value comprising zero bytes shall be placed in the user data field followed by the appropriate delimiter. (See part 1, 4.1.3.3.9)

6.3 Foreign Identifiers

Foreign identifiers shall agree in data structure, data type and format with their references. The referenced record shall exist in the transfer file set.

6.4 Repeating Fields and Records

6.4.1 Repeating Fields

Where part 1 permits or requires repeated fields (within and (or) between module records and (or) between modules) a data structure control of 2 (array) may be used allowing multiple instances of the data n-tuples in the same field. This can reduce overhead and keep similar data in close proximity. Conversely, where Table 3 specifies a structure control of 2, a structure control of 1 may be used, possibly requiring use of additional fields with the same tag. Regardless of the structure control, the option also exists to use additional fields with the same tag and (or) to place the data in a separate record. Changes to the specifications of Table 3 are further subject to the restrictions of sections 7 and 8. The required ordering of fields shall always be preserved.

It is advisable to keep both fields and records to a reasonable maximum length.

6.4.2 Repeating Records

When a file contains records having repeated fixed formats, the user may drop the ISO 8211 leader/directory as specified in that standard.

This is most applicable to those modules that are relational in structure and should be transparent to the user.

7 Assignment of Fields to Records and Files

This section assigns ISO 8211 field to ISO 8211 records and ISO 8211 records to ISO 8211 files. These assignments are determined by the specifications of part 1, Table 4 with the further constraints of part 1, 4.1.3.4.1, section 7 of this part and ISO 8211 ordering constraints.

7.1 Global Modules

Each ISO 8211 record shall contain the ISO 8211 fields representing one and only one module record.

Each ISO 8211 file shall contain the ISO 8211 records representing the data of one and only one global module.

7.2 Other Modules

The ISO 8211 records containing data from modules not included in 7.1 may contain ISO 8211 fields from one or more modules subject to the general constraints of this section.

The ISO 8211 files containing data from modules not included in 7.1 may contain ISO 8211 records from one or more modules subject to the general constraints of this section.

The user should not indiscriminately merge unrelated modules.

7.3 Multi-volume Files

Nothing in this section shall prevent the user form constructing multi-volume files if this is required by the volume of data and supported by the media standards. Multi-volume files shall be described in the Catalog/Directory module.

In the event the media do not support multi-volume files, any multiple files necessary to transfer large volumes of data shall be described in the Catalog/Directory module.

8 Record Structure

See part 1, 4.1.3.4.1.

A record may contain fields from more than one module. This section provides specifications for resolving and preventing conflicting associations of primary and secondary fields.

8.1 Restriction on Primary Fields in Level 2 Files

A record in a level 2 file shall not contain two or more primary fields having, in that record, a common secondary field or fields.

8.2 Primary and Secondary Fields in Level 3 Files

A record in a level 3 file may contain multiple primary fields without restriction. The logical association of primary fields with secondary fields shall be determined by the ISO 8211 inter-field tree structure.

8.3 Arbitrary Field Sequence

In order to specify an arbitrary sequence of fields, a tree in which all fields are offspring of the ISO 8211 record identification field may be used.

9 Data Representation

9.1 Numeric Data

Character representation of numeric data shall conform to ISO 6093 with the provision that FULL STOP, i.e., period, shall be used for the decimal mark. Numeric fields shall be right adjusted.

9.2 Dates

A date in a numeric field shall be entered in the format YYYYMMDD.

9.3 Binary Data

Binary data shall be represented in ISO 8211 bit fields and subfields. These bit fields shall conform to the specifications of ISO 8632-3. The ISO 8211 subfield widths shall be specified as B(n) and the additional X3.122 format information shall be placed in the applicable Data Dictionary/Domain or Data Dictionary/Schema or Internal Spatial Reference or Raster module.

10 Media Requirements

The variable length records of ISO 8211 may be written on several media. This section specifies requirements for several standardized media.

When SDTS is used for archival purposes, selection of a media should consider permanency and expected length of future ability to read such media. Profiles may further address allowable media and media standards.

10.1 General Requirements

The ISO 8211 logical records must be written, blocked and spanned across the media physical records (blocks, sectors or packets) without further record demarcations. Any unused bytes of the last media record of a file may optionally be filled with CARET characters (5/14).

10.2 Magnetic Tapes

The ISO 8211 records must be blocked and spanned into fixed length records of 2048 bytes in a blocksize of 2048 bytes conforming to level 2 of ANSI X3.27 and other applicable standards.

10.3 Flexible Diskettes

Diskettes must be written in conformance to ISO 9293. The ISO 8211 records must be blocked and spanned into sectors without record delimiters or control fields other than the record length provided in ISO 8211.

10.4 Magnetic Tape Cartridges and Cassettes

The ISO 8211 records must be blocked and spanned into fixed length records of 2048 bytes in a blocksize of 2048 bytes conformaing to level 2 of ANSI 4341 and other applicable standards.

10.5 Compact Disk Read Only Memory

The ISO 8211 records must be blocked and spanned into fixed length media records of 2048 bytes in a Logical Block size of 2048 bytes with Record Format = 0 conforming to level 1 of ISO 9660 and other applicable standards.

11 Conformance

A Spatial Data Transfer file set is in conformance with this standard when all data files, records and fields are in conformance with the applicable media standards, ISO 8211, the specifications of part 3, sections 6 to 10 of this standard, and the required specifications of parts 1 and 2 of this standard.

A single, simple README file, that informs the recipient of the nature of the file set, may be provided as the first file on a sequential media volume set and in the root directory of a random access media volume.