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

American National Standard for Information Systems

Spatial Data Transfer Standard - Part 4, Topological Vector Profile

1 Introduction

An SDTS profile, in general terms, is defined as a limited subset of the Spatial Data Transfer Standard, designed for use with a specific type of data. Specific choices are made for encoding possibilities not addressed, left optional, or left with numerous choices within Parts 1, 2, and 3 of SDTS.

An SDTS profile shall provide for the transfer of files, records, fields and subfields with the following objectives:

a) to encode in a standard format;

b) to provide for machine and media independence;

c) to accompany the data with their description;

d) to preserve all meaning and relationships of the data; and

e) to keep both fields and records to an appropriate maximum length.

1.1 Scope and Definition

Part 4, the Topological Vector Profile (TVP), contains specifications for an SDTS profile for use with geographic vector data with planar graph topology.

1.1.1 Geographic Data

By "geographic" we mean data that describe "real-world" features, rather than a symbolized map graphic. The data may be derived from a cartographic product (map), but the purpose of the data is not to convey the map graphic, but rather information about the geographic features displayed on the map.

1.1.2 Vector Data with Planar Graph Topology

The data are represented by vector objects which comprise, or are integrated with, one or more 2-D manifolds (see Part 1 definition 2.3.4.5.2). Excluded are raster data, geometry-only vector data, planar graphs which do not have GT-polygons, and non-planar graph-based network data. These types of data may be accommodated either by other profiles, or future extensions to this profile.

Part 4 is organized using the same major headings found in Part 1. Specific discussions regarding encoding possibilities in Part 1 are grouped under each major heading and will include specific references to Parts 1, 2, or 3 where necessary for clarification.

1.1.3 Profile Annex Options

Annexes D, E, and F of Part 4 contain permitted options to this profile. These options implement additional features of the SDTS which may be useful in some transfers. Encoders and decoders are not required to implement these options to be conforming to this profile. However, the presence of these options shall be tolerated by decoders.

1.2 Conformance

(see also Part 1, Section 1.2, Conformance)

There are three types of products which can be tested for conformance to this profile:

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 Topological Vector Profile, an SDTS transfer shall:

a) contain all mandatory spatial objects, modules, fields, and subfields as specified in this profile;

b) not contain spatial objects, modules, fields, and subfields which are not permitted by this profile or its annexes

c) conform to all requirements and specifications of Parts 1, 2, and 3 of SDTS unless they conflict with this profile;

d) conform to all restrictions on SDTS Parts 1, 2, and 3 as specified in this profile;

e) be formatted in compliance to ANSI/ISO 8211;

f) contain 2-dimensional manifolds which conform to constraint rules as defined in Section 2.3.4.5 of Part 1 of SDTS;

g) contain all topological pointers required by this profile;

h) contain only data sets which have level 1 External Spatial Reference conformance;

i) follow all module and file naming requirements of this profile;

j) contain any profile options it claims to include; and

k) adhere to all other requirements specified in this profile.

1.2.2 Encoder Conformance

In order to conform to this Topological Vector Profile, an SDTS encoder shall:

a) generate only SDTS Topological Vector Profile transfers which conform to Section 1.2.1 (or be able to be directed to only generate transfers which conform to this profile);

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) correctly maintain or generate required topological pointers; and

f) support all profile options it claims to support.

1.2.3 Decoder Conformance

In order to conform to this Topological Vector Profile, an SDTS decoder shall:

a) be able to interpret Topological Vector Profile transfers which conform to Section 1.2.1;

b) be able to decode any module required or permitted by the body or Annex A of this profile (decoding of modules permitted by Annexes D, E, and F is optional);

c) be able to decode any spatial object required or permitted by section 2.1 of the profile and "PR", "PU", and "PV" GT-polygon spatial objects permitted by Annex E and, to the fullest extent possible in the output system, convert it to a corresponding object or equivalent information structures in the output system;

d) be able to decode any Attribute Primary or Secondary module and convert it to a data base or other format usable by the output system;

e) correctly maintain linkages between spatial objects and Attribute Primary records;

f) be able to ignore modules, fields, and subfields which are permitted only by profile annexes which it chooses not to implement;

g) be able to recover if an error is encountered in a particular record, field, or subfield in the SDTS transfer;

h) 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

i) support all profile options it claims to support.

2 Spatial Data Concepts

(see also Part 1, Section 2, Spatial Data Concepts)

2.1 Spatial Objects

(see also Part 1, Section 2.3, Definition of Spatial Objects)

Table 1 indicates which spatial objects are required, optional, or not permitted for this profile.

2.2 Layers and (or) Partitions

Data are to be represented by one or more 2-D manifolds (see Part 1 definition 2.3.4.5.2). A single 2-D manifold shall be used to transfer:

Table 1 - Permitted spatial objects

Object representation code	Required	Optional	Not permitted
NP - Point1		x
NL - Label point		x
NE - Entity point2		x
NA - Area point2		x
NO - Node, planar2	x
NN - Node, network			x
LQ - Link			x
LS - String3			x
LE - Complete chain2	x
LL - Area chain			x
LW,LY - Network chain			x
AC,AE,AU,AB - All arcs3			x
RM - Ring with mixed composition			x
RS - Ring composed of strings			x
RU - Ring composed of chains4			x
RA - Ring composed of arcs			x
PG - G-polygon			x
PC - GT-polygon2	x
PR - GT-polygon4			x
PU - Universe polygon4			x
PW - Universe polygon2	x
PV - Void polygon4			x
PX - Void polygon2		x
G2, G3, G2L, G3L - Raster objects			x
FF - Composite		x

1 Points with the "NP" object representation code are allowed only for use in data quality reports. 2 Each of these objects must participate as a component of a 2-D manifold. 3 Allowed only as an option as described in Annex D. 4 Allowed only as an option as described in Annex E.

a) one theme (or sub-theme), or an integrated set of themes, as a "vertical" data layer (see Part 1 definition 2.3.4.3); within

b) one horizontal partition of the earth's surface. This partition may be representative of a map sheet (e.g. a USGS quadrangle), an administrative/political/study area unit, or a sub-partition thereof.

More than one layer and (or) more than one horizontal partition may be included within a single SDTS transfer. See Section 4.7 of Part 4, "Relationships Between Modules and 2-D Manifolds" for information on module requirements when transferring multiple 2-D manifolds.

3 Spatial Data Quality

(see also Part 1, Section 3, Spatial Data Quality)

3.1 Lineage

Separate processing histories pertaining to, for example, separate data layers, shall be documented.

3.2 Positional Accuracy

If data are collected from a graphic map, then a statement explaining that the data may contain cartographic offsets shall be included in the positional accuracy portion of the data quality report.

3.3 Logical Consistency

The technique used to verify topology shall be documented.

3.4 Completeness and (or) Logical Consistency

Report and explain data encoding practices, especially in object records, which might seem contrary to, or to deviate from, normal, standard or preferred practices. For example, if one or more composite object records lack lists of component objects, the meaning of this shall be explained in the completeness portion of the data quality report.

4 General Specification (The Transfer Model)

(see also Part 1, Section 4.1.3, The Transfer Model)

4.1 Standard Module Names

SDTS Topological Vector Profile module names (the unique name of each individual module) shall be standardized, and consist of four characters. All letters in module names shall be upper case. For modules carrying spatial objects, the module name shall begin with the same two characters as the object representation code for the objects (use "PC" for modules with "PC", "PX", and "PW" objects and use "FF" for composite objects). The other valid two character Object Representation codes are shown in Section 2.1 of Part 4, Spatial Data Concepts, Spatial Objects. The last two characters of the module name are free to distinguish different modules/files. Attribute Primary and Secondary modules shall be named "Axxx" and "Bxxx" respectively (where x is any number 0-9 or any upper case letter A-Z).

Non-object modules shall be named the same as the primary module field mnemonic (ISO 8211 Tag) (see Part 1, Sections 5.2 and 5.3, Global Information and Data Quality Modules, and Part 3 Table 1):

• IDEN (Identification),
• CATD (Catalog/Directory),
• CATX (Catalog/Cross Reference),
• CATS (Catalog/Spatial Domain),
• SCUR (Security),
• IREF (Internal Spatial Reference),
• XREF (External Spatial Reference),
• SPDM (Spatial Domain),
• DDDF (Data Dictionary/Definition),
• DDOM (Data Dictionary/Domain),
• DDSH (Data Dictionary/Schema),
• STAT (Statistics),
• DQHL (Data Quality/Lineage),
• DQPA (Data Quality/Positional Accuracy),
• DQAA (Data Quality/Attribute Accuracy),
• DQLC (Data Quality/Logical Consistency),
• DQCG (Data Quality/Completeness)

More than one module of the following types may exist:

• SCUr, IREf, SPDm, DDDf, DDOm, DDSh, DQHl, DQPa, DQAa, DQLc, and DQCg.

The last character shall change to reflect more than one module of the same type.

4.2 Order of Records, Fields, and Subfields within Modules

a) Records within modules shall 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³¹ - 1).

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

4.3 Coordinate Frame of Reference

(see also Part 1, Section 4.1.3.5, Spatial Registration)

There shall be only one external coordinate frame of reference within a transfer. The external spatial reference system shall be one of the systems which make up conformance level 1: latitude-longitude (geographic), Universal Transverse Mercator/Universal Polar Stereographic (UTM/UPS), or State Plane Coordinate Systems (SPCS.) If different horizontal partitions are included within the transfer, each 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).

4.4 Spatial Address (Coordinate) Format

(see also Part 1, Section 4.1.3.5, Spatial Registration, and Section 5.2.4, Spatial Reference)

4.4.1 External Spatial Reference

Topological Vector Profile transfers shall be restricted to the use of conformance level 1 for horizontal external coordinates. To explicitly state this restriction,

a) the External Spatial Reference subfield of the Conformance field of the Identification module shall have the value of "1" indicating that, YES, one of three recommended systems is used, and

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

Note that Part 1 restricts the unit of measurement in the external reference system to meters for all Z coordinates and X and Y coordinates when using the State Plane Coordinate System. However, coordinates can be stored in the internal reference system in feet as long as the appropriate scaling factors are used in the Internal Spatial Reference module.

4.4.2 Internal Representation of Spatial Addresses

(see also Part 1, Section 4.2.1, Specification Layout; Part 3, Section 9.3 Binary Data)

The internal representation of X, Y and Z coordinates shall be as 32-bit signed implicit fixed point binary numbers ("BI32" SDTS data type). Signed integers are represented in "two's complement" format as defined in ANSI X3.122 - 1986 Part 3, Section 5.1. This standard requires "big-endian" bit ordering in which the most significant bit is stored first (Related references: ANSI X3.122, FIPSPUB 128, and ISO 8632-3; all of which are parts of the Computer Graphics Metafile standard.)

Internal fixed point coordinates can be converted to external coordinates by converting to floating point and applying the scaling and translation values from an Internal Spatial Reference module--see Part 1, 5.2.4.1.)

4.4.3 Restrictions on X and Y Subfields

The X subfield of spatial addresses shall only be used to transfer longitude and easting values. The Y subfield shall only be used to transfer latitude or northing.

4.5 Null (and Like) Values

(see also Part 1, Section 4.1.3.3.9, Nulls and Defaults)

When a transfer uses fixed length subfields (e.g. to carry attribute data linked to the various objects), then special consideration must be given to handling Null values. The SDTS default option for implementing nulls is not feasible in this case. When appropriate, the following text shall 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 shall be associated to applicable modules through the Catalog/Cross Reference module.

4.6 Attribute Usage

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

All agencies shall use established FIPS codes where applicable, such as FIPS PUB 6-4 (31 August 1990) Counties and Equivalent Entities Codes or FIPS PUB 10-3 (9 February 1984) Countries, Dependencies, Areas of Special Sovereignty and their Principal Administrative Division.

4.7 Relationships Between Modules and 2-D Manifolds

a) For objects particular to one 2-D manifold there shall be:

• exactly one Point-Node module for required simple object type NO;
• exactly one Line module for required simple object type LE;
• exactly one Polygon module for simple object types PC, PW, and PX;
• zero or one Point-Node module for optional simple object type NE;
• zero or one Point-Node module for optional simple object type NA;
• and zero or one Point-Node module for optional simple object type NL.

• There is no restriction on the number of modules containing points with the NP object representation code.

b) If more than one 2-D manifold is transferred, data particular to a given 2-D manifold will be transferred within its own set of simple object modules, and these modules will be related to each other and to theme(s) and partition (map or domain) in the Catalog/Spatial Domain module. If more than one 2-D manifold is contained in a transfer, each 2-D manifold shall be assigned a unique name which shall be used in the Aggregate Object subfield for all records for modules which apply only to the particular 2-D manifold.

c) Each partition may have its own internal coordinate system. Therefore an SDTS transfer with more than one partition (and 2-D manifolds) may have more than one Internal Spatial Reference module. But separate 2-D manifolds representing different layers of the same partition shall share the same Internal Spatial Reference module.

d) There may be different entity types represented by the records of a given object module (e.g. a single Composite module may contain records for many different types of entities).

e) There are two methods of identifying the entity type of a particular spatial object: (1) the SDTS default option which uses the Data Dictionary/Schema module to assign an entity to a particular attribute in a Attribute Primary module or (2) the method described under Section 4.9 of Part 4. When the SDTS default option is used, each different entity type shall be distinguished in its own unique Attribute Primary module. When using the SDTS default option, there shall be one Attribute Primary module for each unique entity type for data particular to a given 2-D manifold.

f) Composite objects may be composed of objects from more than one 2-D manifold. Additional Composite modules shall be used to transfer such composite objects. There shall be a separate Attribute Primary module for each entity type represented in these multi-manifold Composite modules.

4.8 Multi-valued Attributes

Attributes that can be multi-valued shall be in their own tables, along with any other attributes that are functionally dependent. An attribute's cardinality and functional dependence is solely determined by the data encoder's data model. As an example of multi-valued consider an entity "road" with the attribute "name" that has the two values "10th Street" and "Highway BB". Attributes are functionally dependent when the value of one attribute determines the value of another attribute. For example, say attribute "route_number" is dependent on "name", which means the value of "name" determines the value for "route_number". (See Annex B for an example of encoding multi-valued attributes.)

4.9 Attributing Feature Objects with Entity Labels

The SDTS implementation of the entity-attribute-attribute value feature model provides a means of directly assigning attribute values to specific feature objects. The type of entity which the object represents is specified indirectly through Data Dictionary/Schema module records. The assumption is that each entity type represented is characterized by attributes. In some cases, however, all that may be encoded about a feature is its entity type with no other attributes.

For use with features with entity labels but no attributes (and optionally in cases where different features share the same attributes), two generic attribute labels are defined by this profile: "ENTITY_LABEL" and "ENTITY_AUTHORITY" (an entity label may only be unique when coupled with the authority for its definition). The authority for the definition of these two attribute labels is this profile, designated in Data Dictionary/Schema records (Attribute Authority subfield) as "SDTS/TVP". (No Data Dictionary/Definition or Data Dictionary/Domain records are necessary for these two attribute labels.) The domain of attribute values for these attributes shall be any entity label and its authority as defined in either SDTS Part 2 or Data Dictionary/Definition records included with the transfer (either internally or externally). When all entity labels in a single transfer are defined by the same authority, the ENTITY_AUTHORITY attribute may be omitted in the attribute records.

Annex C contains an example of attributing feature objects with entity labels.

5 Transfer Module Specification

(see also Part 1, Section 5, Transfer Module Specification)

This section addresses the module level restrictions as they apply to a transfer. Certain requirements of 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 Part 1, Section 5.

Table 2 contains the inclusion/exclusion, and cardinality rules for each module. The standardized modules names are included, along with the minimum number and the maximum number of occurrences of the module type. A lowercase "n" indicates that the upper limit is user defined. Any lowercase letters or dots in the module name has the meaning explained in Section 4, Standard Module Names.

5.1 Global Information Modules

(see also Part 1, Section 5.2, Global Information Modules)

a) If more than one 2-D manifold is transferred, data particular to a given 2-D manifold will be transferred within their own set of modules. These modules will be related to each other and to theme(s) and partition (map or domain) in the Catalog/Spatial Domain module. If more than one 2-D manifold is contained in a transfer, each 2-D manifold shall be assigned a unique name which shall be used in the Aggregate Object subfield for all records which apply only to the particular 2-D manifold.

b) Each partition may have its own internal coordinate system. Therefore an SDTS transfer with more than one partition (and 2-D manifolds) may have more than one Internal Spatial Reference module. But separate 2-D manifolds representing different layers of the same partition shall share the same Internal Spatial Reference module.

c) For each SDTS transfer data set that does not reference an external SDTS data dictionary, there must be at least one and it is recommended that there be only one of the

Table 2 - Module level restrictions and requirements

Module type	Name	Min. No.	Max. No.
Global Information Modules (see also 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	n
External Spatial Reference	XREF	1	1
Registration	--	0	0
Dimension Definition	--	0	0
Spatial Domain	SPDm	0	n
Data Dictionary/Definition	DDDf	01	n2
Data Dictionary/Domain	DDOm	13	n6
Data Dictionary/Schema	DDSh	1	n6
Transfer Statistics	STAT	1	1
Data Quality Modules (see also 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
Composite Module	FF..	0	n
Attribute Modules (see also Part 1, Section 5.4, Attribute Modules)
Attribute Primary	A...	1	n
Attribute Secondary	B...	0	n
Vector Modules (see also Part 1, Section 5.6, Vector Modules)
Point-Node	NO..	1	n
	NE.., NA.., NL..,NP..	0	n
	NN	0	0
Line	LE..	1	n
Arc4	--	0	0
Ring5	--	0	0
Polygon	PC..	1	n
Raster Modules	--	0	0
Graphic Representation Modules6	--	0	0

1 A minimum of one module is required if the transfer does not have level 1 feature conformance with SDTS Part 2. The module may be contained in an external SDTS data dictionary as described in Annex A. 2 A maximum of one module is recommended. 3 The module may be contained in an external SDTS data dictionary as described in Annex A. 4 Allowed only as an option as described in Annex D. 5 Allowed only as an option as described in Annex E. 6 Allowed only as an option as described in Annex F.

following global module:

• Data Dictionary/Domain (DDOM).

• For each SDTS transfer data set that does not reference an external SDTS data dictionary and that does not have level 1 feature conformance with Part 2, there must be at least one and it is recommended that there be only one of the following global module:
  • Data Dictionary/Definition (DDDF).
• There must be at least one and it is recommended that there be only one of the following global module:
  • Data Dictionary/Schema (DDSH).

a) A common set of Data Dictionary/Definition and Data Dictionary/Domain modules may be used for an entire series of files to be distributed. This Data Dictionary may be made available separately; and it need not be duplicated within each SDTS transfer. If the SDTS data dictionary is separate from the individual SDTS transfer data set, then it shall be uniquely identified and referenced by the individual SDTS transfer data set. Annex A describes the method by which such a master data dictionary transfer will be accomplished. See also Part 1, Section 4.1.3.3.1, Modules within a Spatial Data Transfer (clause (d)), and Section 5.2.2.1, Catalog/Directory (Table 11, subfields External and Module Version), and Section 5.2.6 Data Dictionary.

5.2 Data Quality Modules

(see also Part 1, Section 5.3, Data Quality Modules)

a) 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 shall be uniquely identified and referenced by the individual SDTS transfer data set. See Part 1, Section 4.1.3.3.1, Modules within a Spatial Data Transfer (clause (e)), and Section 5.2.2.1, Catalog/Directory (Table 11, subfields External and Module Version).

b) Separate processing histories pertaining to, for example, separate data layers, shall be documented in a Lineage module.

c) If data are collected from a graphic map, the Positional Accuracy module shall contain a statement explaining that the data may contain cartographic offsets.

d) The technique used to verify topology shall be documented in the Logical Consistency module.

e) Completeness modules and (or) Logical Consistency modules shall be used to report and explain data encoding practices, especially in object records, which might seem contrary to, or to deviate from, normal, standard or preferred practices. For example, if one or more composite object record lacks lists of component objects, the meaning of this shall be explained in a Completeness module.

5.3 Attribute Modules

(see also Part 1, Section 5.4, Attribute Modules)

There is no restriction on the relationships between objects and Attribute Primary module records: the relationship may be one-to-one, one-to-many, many-to-one, or many-to-many. If the relationship is not one-to-one or one-to-many, the encoder is required to alert decoders to this fact in the Catalog/Cross Reference module record for the modules involved. This shall be done by placing the characters "JJ" into the first two characters of the Comment subfield.

5.4 Composite Module

(see also Part 1, Section 5.5, Composite Module)

a) Composite objects may optionally not have a list of component objects. If such a list does not exist, the meaning of this shall be explained in a Data Quality Completeness module record.

b) Chains comprising a continuous linear composite object may be ordered. Each Chain ID in the list of components may have an "F" (for forward) or "B" (for backward) in the Foreign ID Usage Modifier subfield (see Part I, Section 5.1.2, Foreign Identifiers). The list of chain Foreign IDs may be ordered such that: the first point (start node of "F" chains and end node of "B" chains) of each chain following the first in the list, shall be equivalent to the last point (end node of "F" chains and start node of "B" chains) of the previous chain in the list.

• The ordering and forward/backward chain usage modifiers are included to allow the transfer of directional information for composite objects representing such things as one-way roads and drains. This capability to direct and sequence chains could also be used to specify plotting sequences, but that is not a major reason for including this capability in this Topological Vector Profile.

5.5 Vector Modules

(see also Part 1, Section 5.6, Vector Modules)

5.5.1 Topological Pointers

a) Nodes shall not have any topological pointers;

b) complete chains shall have start node, end node, polygon right, and polygon left pointers (polygon pointers shall be to GT-polygon records);

c) entity points and area points, if present, shall have pointers to their surrounding GT-polygon (only one; entity points may not exist at the same location as a chain or node which is part of the same 2-D manifold);

d) label points may optionally have pointers to their surrounding GT-polygon;

e) points with the "NP" object representation code shall not have topological pointers;

f) GT-polygons may optionally have pointers to their chains, in "walk-around" sequence; Pointers to chains (if present) will also have an "L" (for polygon on left side of chain) or an "R" (for polygon on right side of chain) in the Foreign ID Usage Modifier subfield (see Part 1, Section 5.1.2, Foreign Identifiers).

The information in the Data Structure subfield of the Identification module will indicate the presence or absence of the various optional items such as area points and pointers from polygons to chains. The presence of these items in a transfer will typically reflect their presence in the source format and structure. For example, Standard DLG data do not have polygon-to-chain pointers, so a transfer from DLG-S data would not have pointers from polygons to chains (unless these pointers were built and added by the SDTS encoder, which is doubtful).

5.5.2 Universe Polygon

(see Part 1 definition 2.3.3.3.1)

A universe polygon (object representation code "PW") is mandatory. Its Record ID subfield shall be encoded with "1". Attributes of the universe polygon, if any, shall have null values (see below for specifications for implementing null values).

The Ring ID field is not permitted for universe polygons with an object representation code of "PW".

5.5.3 Void Polygons

(see Part 1 definition 2.3.3.3.2)

Other GT-polygons may be included with attribution similar to the universe polygon; these void polygons shall be coded with a "PX" object representation code.

The Ring ID field is not permitted for void polygons with an object representation code of "PX".

5.5.4 Attribute Primary References

Object records may reference zero, one or more attribute primary records except for area points ("NA" object representation code) which shall always reference zero attribute primary records. Attribute primary references for area points should instead be contained in the surrounding GT-polygon spatial object record.

5.5.5 Number of Object Types Within a Single Module

A single module shall contain only records of a single object type (indicated by appropriate object representation code), with the technical exception that modules carrying "PC" (GT-polygon) records may also contain a "PW" (universe polygon) and "PX" (void polygon) records.

5.5.6 Use of "NP" Points

Points with the "NP" object representation code are allowed only for use in data quality reports. An example use is to transfer control points used for transformations which might be part of the Lineage Data Quality report.

5.5.7 Label Points

The Attribute Primary Foreign ID (PAID) field is mandatory for the "NL" object representation code. This field references the record and the label of the attribute to be annotated. This field shall reference an attribute record in either an Attribute Primary module or an Attribute Secondary module.

5.6 Raster Modules

These modules shall not be included in a transfer conforming to this profile.

5.7 Graphic Representation Modules

These modules shall not be included in a transfer conforming to this profile unless the options described in Annex F are implemented. Encoders and decoders are not required to support these module types to be conforming to this profile.

5.8 Module Restrictions/Requirements: Identification Module

(see also Part 1, Section 5.2.1, Table 10 Identification)

5.8.1 External Spatial Reference

(see also Part 1, Section 5.2.1.2.2, External Spatial Reference Subfield)

The External Spatial Reference subfield of the Conformance field of the Identification module shall have the value of "1" indicating that, YES, one of three recommended systems is used.

5.8.2 Profile Identification

Each transfer encoded per these specifications shall have

• "SDTS TOPOLOGICAL VECTOR PROFILE"

as the value of the Profile Identification subfield of the Identification module primary field.

If options described in Annexes D, E, or F are implemented in a transfer, each implemented annex shall 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 Annexes D and E, Profile Identification would contain "SDTS TOPOLOGICAL VECTOR PROFILE/D/E".

Each transfer shall have

• June 10, 1994

as the value of the Profile Version subfield of the Identification module primary field.

Each transfer shall have

• FIPSPUB 173-1

as the value of the Profile Document Reference subfield of the Identification module primary field.

5.8.3 Feature Level Conformance

(see also Part 1, Section 5.2.1.2.3, Features Level Subfield)

Any level of SDTS Features Conformance is allowed (the value in the Features Level subfield of the Conformance field of the Identification module record shall be either "1", "2", "3" or "4"). Note that if SDTS is not the authority for any entity and attribute terms, then the Features Level subfield must be valued as "4".

5.8.4 Global Attributes

The Attribute ID field is used to reference global information that applies to the entire transfer (e.g. Census TIGER/LINE min and max ID numbers).

5.9 Module Restrictions/Requirements: Internal Spatial Reference

The X subfield of spatial addresses shall be used only for longitude and easting values. The Y subfield shall be used only for latitude and northing. Therefore, 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. 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. If spatial addresses include Z values, the Scale Factor Z and Z Origin subfields 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 Part 1, 5.2.4.1). The use of the Registration module to specify this transformation is not allowed.

5.10 Module Restrictions/Requirements: External Spatial Reference

The Reference System Name subfield in the External Spatial Reference Module primary field shall have the value "GEO", "SPCS", "UTM", or "UPS" depending upon the external spatial reference system being used.

5.11 Module Restrictions/Requirements: 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 which separate data into themes.

c) The Aggregate Object Type subfield shall contain the object representation code "GT" indicating that the module references a 2-D manifold.

d) The Aggregate Object subfield shall be used to indicate the 2-D manifold to which modules, themes, domains, and maps are related. If more than one 2-D manifold is contained in a transfer, each 2-D manifold shall be assigned a unique name which shall be used in the Aggregate Object subfield for all records for modules which apply only to the particular 2-D manifold. The use of the Aggregate Object subfield is optional in other cases.

5.12 Module Restrictions/Requirements: Catalog/Directory

So that 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 shall not be used.

b) The File subfield shall not include a directory path, only a file name meeting the requirements of Section 6.5.

5.13 Module Restrictions/Requirements: Data Dictionary/Schema

The Entity Authority and Attribute Authority subfields shall contain "SDTS-USA" when Part 2 of FIPS 173 is the authority for the definition. When a standard register of entities and attributes of a country other than the United States is the authority, these subfields shall contain "SDTS-" followed by the three-character ISO 3166 country code. Entity Authority and Attribute Authority may have a maximum length of 8 graphics characters.

5.14 Module Restrictions/Requirements: Data Dictionary/Domain

The Attribute Authority subfield may have a maximum length of 8 graphics characters.

5.15 Module Restrictions/Requirements: Data Dictionary/Definition

The Attribute Authority subfield may have a maximum length of 8 graphics characters.

5.16 Module Restrictions/Requirements: Catalog/Cross-Reference

When a transfer includes multiple Internal Spatial Reference (IREF) Modules, each spatial object module must be cross-referenced to one IREF module.

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 Part 3, ISO 8211 Encoding)

6.1 Objective

(see also 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).

6.2 Relationship of Modules to ISO 8211 Files

(see also Part 1, Section 4.1.3, Tables 3a & 3b,

and Part 3, Section 7, Assignment of Fields to Records and Files)

a) A file (an ISO 8211 Data Definition File (DDF)) shall contain one and only one module. All Topological Vector 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 only when the size of a single file would exceed volume capacity, that is if the file needs to be broken into separate files to be placed on separate volumes, because of media constraints. Thus modules may be broken into different files only in a multi-volume transfer, and then only if the module cannot itself fit on a single volume.

6.3 Media

(see also Part 3, Section 10, Media Requirements)

When only a single SDTS transfer is on a media volume, then the volume name shall begin with the same four characters as the first four characters of file names for that transfer (see section 6.5.) When multiple transfers are contained on a volume, then the first four characters of the volume name shall be "SDTS".

For multi-volume transfers, the first four characters shall be the transfer base characters as described above, and the remainder of the name shall indicate the volume sequence.

6.4 Organization of Files on Media

In general, the files comprising a single transfer shall be kept separate from any other transfer files.

a) On floppy disks and CD-ROM, each transfer shall 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, files of a single transfer shall be ordered by module type, following the order of presentation in Part 1, Section 5. File adjacency shall 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) up until another Identification Module or an end of tape marker is encountered shall be considered part of the transfer.

c) A file called "README" is required (see Part 3, Section 11, Conformance). There shall be one such file per media volume. This file shall reside in the root directory of a floppy disk or CD-ROM.On a magnetic tape, the README file shall be located immediately before the Identification module (the first file in each SDTS transfer) of the first SDTS transfer. It is permissible for non-SDTS adjunct files to be placed before the README file. Contents of the README file is discussed in section 6.10.

6.5 File Names

SDTS Topological Vector Profile file names, to be consistent from the various agencies shall consist of eight characters of base name. A single transfer data set shall 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 shall be the unique name of the module transferred in that file (see naming convention for modules in Section 4.1 of Part 4). When allowed, the extension should be ".DDF" to indicate the type of file transferred; but the last character of this extension or an optional ninth character on the base name may be used in the case of modules that span files. Thus the extension could become ".DDG", ".DDH", ".DDI", ... for multi-volume modules. Such file extenders are optional. Any file that is not ISO 8211 compliant (e.g. adjunct files) shall not have the ".DDx" extension. All letters in file names shall be upper case.

6.6 Taking Advantage of Dropped Leader and Directory

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

This profile encourages taking advantage of ISO 8211 mechanisms to reduce file size. All modules shall 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 shall be ordered within a file to maximize the use of dropped leaders and directories. This means that exceptional data records (DRs) shall be placed first in the DDF. All records that can share a common leader and directory shall be grouped at the end of the file. (This is necessary because once the leader and directory are dropped, they cannot be respecified later in the file.)

Maximizing the use of dropped leaders and directories needs to be taken into consideration when designing attribute modules. If there are attributes that can have a wide range in the size of their value (e.g. place names), then considering separating these attributes into their own module.

6.7 ISO 8211 DDR Contents

a) Data descriptive fields which 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 shall be "X" and "Y".

c) The first part of the file title shall 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 Binary Data Type for Spatial Addresses

A binary data type shall be used in the subfields of a spatial address field. The binary subfields shall be a fixed width of 32 bits.

a) In the case where the spatial address field does not repeat, the following format control shall be used for a spatial address type:

		(2B(32))

		where:
			2 = 2 or 3 depending on x,y or 
x,y,z
			B = indicates binary type subfield
			32 = specifies the width of the 
binary subfield

b) In the case where all Data Records (DR) in a DDF contain the same number of repetitions, a user-calculated repeat factor shall be used in the format control for the field. A format control for a spatial address type field shall have the form:

		(n(2B(32)))

		where:
			n = the number of spatial address 
tuples
			2 = 2 or 3 depending on x,y or 
x,y,z
			B = indicates binary type subfield
			32 = specifies the width of the 
binary subfield

c) In the case where each DR in a DDF contains a different number of repetitions (such as is likely to occur in the Line module), the following format control shall be used:

		((2B(32)))

		where:
			2 = 2 or 3 depending on x,y or 
x,y,z
			B = indicates binary type subfield
			32 = specifies the width of the 
binary subfield

• 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 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 Part 3, Section 11, Conformance)

The README file shall contain volume name, date, a list of SDTS transfers (if more than one), and then for each SDTS transfer: a list of subdirectories and non-SDTS files, if appropriate, the file name of the Catalog/Directory module, where it can be found, and an explanation that this file and all other SDTS files are in ISO 8211 format, and that the Catalog/Directory module carries a complete directory to all other SDTS ISO 8211 files comprising the SDTS transfer, notes about any non-SDTS adjunct/auxiliary files, a brief explanation of the spatial domain, the purpose, authority (FIPS 173), source (e.g. agency name) and contacts within the source organization. If there are any issues about the transfer, use of optional profile annexes, special purposes (i.e. private agreement transfer), non-standard uses of modules, etc., this shall be described.