Reproduced from Cartography and Geographic Information Systems, Special Issue: IMPLEMENTING THE SPATIAL DATA TRANSFER STANDARD, American Congress on Surveying and Mapping, Vol. 19, No. 5, Dec. 1992. An Overview of FIPS 173, The Spatial Data Transfer Standard Robin G. Fegeas Janette L. Cascio Robert A. Lazar ABSTRACT. The Spatial Data Transfer Standard (SDTS), after 9 years of development, was approved on July 29, 1992, as FIPS Publication 173. The SDTS consists of three distinct parts. Part 1 is concerned with logical specifications required for spatial data transfer and has three major components: a conceptual model of spatial data, data quality report specifications, and detailed logical transfer format specifications for SDTS data sets. Part 2 provides a model for the definition of real-world spatial features, attributes, and attribute values and includes a standard but working and expandable list with definitions. Part 3 specifies the byte-level format implementation of the logical specifications in SDTS part 1 using ISO/ANSI 8211 (FIPS Publication 123), a general data exchange standard. KEYWORDS: spatial data, data exchange, data standards. Introduction The Spatial Data Transfer Standard (SDTS), or Federal Information Processing Standard (FIPS) Publication 173, provides solutions to the problems of transferring the full range of spatial (i.e. geographic and cartographic) data. Vector data and raster data of many different types, models, and structures, along with associated attribute data also of widely varying types, models, and structures, can be exchanged between dissimilar systems using FIPS 173. The SDTS addresses a number of levels and issues necessary to successful spatial data transfer. These range from conceptual modeling at the highest level, to the definition of feature and attribute terms, to the inclusion of metadata and quality reporting, to logical structuring and, at the lowest level, to details of physical encoding. History The Spatial Data Transfer Standard is the culmination of approximately 9 years of work by many individuals from government, private industry, and academia. But the ground work for this accomplishment was laid even earlier. The U.S. Geological Survey (USGS) assumed leadership in developing, defining, and maintaining Federal earth science standards in February 1980 with the signing of a memorandum of understanding (MOU) between the National Bureau of Standards and the USGS. Under the terms of this MOU, the USGS sought to develop standards for digital cartographic data exchange through the Standards Working Group (SWG) of the Federal Interagency Coordinating Committee on Digital Cartography (FICCDC), established by the Office of Management and Budget in 1983, and through grants to the National Committee for Digital Cartographic Data Standards (NCDCDS), which operated under the auspices of the American Congress on Surveying and Mapping from 1982 to 1988. The Proposed Standard for Digital Cartographic Data (Digital Cartographic Data Standards Task Force, 1988) represented a merger of the efforts of the FICCDC-SWG and the NCDCDS to develop a comprehensive standard for digital cartographic data. This merger was accomplished by a task force formed by the USGS from members of the FICCDC-SWG, the NCDCDS, and other representatives of the spatial data community. The proposed standard was tested by government agencies and private industry during 1988 and early 1989. During 1989 and 1990 a technical review board, consisting of experts from government, academia, and the private sector introduced numerous enhancements and revisions as a result of testing. During this development, the name of the standard was changed to the Spatial Data Transfer Standard to reflect its evolving emphasis on the needs of data transfer between dissimilar spatial data systems, including geographic information systems. In early 1991, the SDTS was submitted to the National Institute of Standards and Technology (NIST), formerly the National Bureau of Standards, for approval as a FIPS. After an open public review and comment period and resulting minor changes the SDTS was resubmitted to NIST and on July 29, 1992 was approved as FIPS Publication 173. The Parts of SDTS The SDTS consists of three parts. The parts are related but relatively independent, each dealing with its own piece of the spatial data transfer problem. The remainder of this article will discuss the three parts in more detail, but a brief introduction to each is in order. Part 1 is concerned with logical specifications required for spatial data transfer, and itself consists of three major sections. First, a conceptual model of spatial data is presented, which consists of a model of spatial phenomena as real-world entities with attributes, and a defined set of zero-, one-, and two-dimensional spatial objects that represent the real-world phenomena. Second, components of a data quality report are specified to enable a data user to evaluate fitness of the data for use; five components of quality are specified: lineage, positional accuracy, attribute accuracy, logical consistency, and completeness. Third, detailed logical transfer format constructs and specifications for SDTS transfer data sets are presented, constituting the majority of part 1--indeed the majority of FIPS 173. An SDTS transfer is organized as modules with records, fields, and subfields; 34 module types are specified as detailed field and subfield record layout specification tables, designed to include many kinds of information: global, data quality, feature and attribute data dictionary, coordinate reference, spatial object, and associated attribute and graphic symbology information. Part 2 of the SDTS addresses data content by providing a model for the definition of spatial features (entities), attributes, and attribute values. Included is a standard but working and expandable list with definitions of some 200 topographic and hydrographic features and approximately 250 attributes, plus more than 1200 included terms (synonyms or sub-types of standard terms). Part 3 specifies the implementation of the logical specifications in part 1 of SDTS using a general data-exchange standard (ISO/ANSI 8211, also known as FIPS 123) (American National Standards Institute, 1986a). Translating between a specific spatial data system and its corresponding SDTS transfer is done progressively through several levels of abstraction, from the conceptual to the physical, using all three parts of the SDTS. A view of spatial information is translated into the concepts of SDTS part 2 and represented as spatial objects. The spatial objects defined in part 1, along with associated attribute data and metadata, are transferred using the logical structures also specified in part 1. These structures are physically formatted as files on media (e.g. tape, diskette or CD-ROM) according to ISO 8211/FIPS 123 as specified in part 3 of FIPS 173, and according to the appropriate media standards. Part 1 Those concerned with actually developing SDTS translation procedures and software will need to spend considerable time mastering part 1 of the SDTS. The primary objective of part 1 is to provide detailed specifications for the transfer of spatial data, but its initial sections can also serve as a basis for common understanding in other settings (for example, in designing new systems or enhancing the quality of data within systems). Physically, part 1 is organized into five numbered sections. Section 1 is a brief introduction summarizing the scope of the standard, criteria for conformance, references, and a set of essential terms. Section 2 presents a conceptual model of spatial data. Section 3 includes specifications for a spatial data quality report. Sections 4 and 5 present the detailed logical record and field-level specifications for transfer. Part 1, Section 2--Conceptual Model of Spatial Data A mutually accepted conceptual model of spatial data is fundamental to the exchange of information between dissimilar spatial data systems. All too often in data exchange, the task of establishing a common model has been subsumed in the process of equating individual data fields and records, resulting in frequent ambiguities. The conceptual model presented in the SDTS, in parts 1 and 2, provides a basis for a common understanding of spatial data information and a means for representing spatial phenomena digitally. The SDTS model was developed to be sufficiently general as to accommodate any user- defined spatial data model. The SDTS conceptual model has three parts: a model of spatial phenomena, a model of spatial objects, and a model of spatial features. Respectively, these parts describe (a) the real world as entities (cities, farms, roads, streams, etc.) with attributes, (b) a set of spatial objects (points, lines, polygons, etc.), and (c) the relationship between the two (spatial objects are used to digitally represent real-world entities). To use SDTS, one must understand this model and describe one's own view of geographic and cartographic reality in terms of entities and attributes, and then correlate the geometric primitives and other digital representations of one's system to the SDTS spatial objects. Spatial Phenomena. The SDTS model of spatial phenomena is presented in both parts 1 and 2 and provides the link between the two parts. Briefly, the SDTS model describes the real world as consisting of entities characterized by attributes which are assigned attribute values. "Entity" is the term chosen to describe real-world phenomena because of confusion invoked by the more common term "feature." See part 2, below, for more discussion on entities, attributes, and attribute values. Spatial Features. The term "feature" has in the past been applied to either a real-world phenomenon or a digital representation, with resulting ambiguity. Reserving "entity" for the real-world, and "object" for the digital world, the SDTS defines "feature" as both a real-world entity and its object representation. A spatial data transfer is the means for exchanging information about spatial features--both real-world entities and their digital representations. Spatial Objects. Spatial objects are used to digitally represent real-world entities. The SDTS defines a set of 13 simple zero-, one-, and two-dimensional spatial objects (with additional sub types--see table 1). The object definitions are oriented toward surface representations (i.e. two-dimensional data), but are also valid for nonplanar geometry, and coordinates associated with the objects may include z values. Simple spatial objects may represent entities either directly or through aggregations termed composite objects. Composite objects, which consist of simple objects or other composites, enable virtually any spatial data model to be accommodated by the SDTS. For example, although SDTS does not explicitly define three-dimensional objects, a three-dimensional object type could be transferred as an SDTS composite object with defined rules for its construction from SDTS two-dimensional objects. Both raster and vector objects are included in the set of simple objects and classified as either geometry only (G) or geometry and topology (GT). (The pixels and grid cells of raster data are seen as special cases of two-dimensional G objects.) These classifications, along with subclassifications by aggregate spatial object type (see next paragraph), very frequently indicate distinct spatial data models, and can therefore be used as guidelines in creating subsets of object types for inclusion in SDTS profiles (see Lazar, 1992). Precise definitions of the simple raster and topology objects also require definitions of what are termed aggregate spatial objects. These objects provide the context within which the simple objects must be defined; for example, a digital image is defined as the context for pixels, and a two-dimensional manifold is defined as the context for a topologically integrated set of nodes, chains, and GT-polygons. Table 1. Definition of SDTS Simple Spatial Objects GEOMETRY-ONLY (G) SPATIAL OBJECTS Point. A zero-dimensional object that specifies geometric location. One coordinate pair or triplet specifies the location. Note: There are three sub-types of Point: Entity Point, Area Point, and Label Point. Line Segment. A direct line between two points. (A line is a generic term for a one-dimensional object.) String. A connected nonbranching sequence of line segments specified as the ordered sequence of points between those line segments. Note: A string may intersect itself or other strings. Arc. A locus of points that forms a curve that is defined by a mathematical expression. G-ring. A sequence of nonintersecting strings and (or) arcs, with closure. A ring represents a closed boundary, but not the interior area inside the closed boundary. (G-Ring is a sub-type of Ring.) Interior Area. An area not including its boundary. (An area is a generic term for a bounded, continuous, two-dimensional object that may or may not include its boundary.) G-Polygon. An area consisting of an interior area, one outer G-ring and zero or more nonintersecting, nonnested inner G-rings. No ring, inner or outer, shall be collinear with or intersect any other ring of the same G-polygon. Pixel. A two-dimensional picture element that is the smallest nondivisible element of a digital image (a defined aggregate spatial object). Grid Cell. A two-dimensional object that represents the smallest nondivisible element of a grid (a defined aggregate spatial object). GEOMETRY AND TOPOLOGY (GT) SPATIAL OBJECTS Node. A zero-dimensional object that is a topological junction of two or more links or chains, or an end point of a link or chain. Link. A topological connection between two nodes. A link may be directed by ordering its nodes. Chain. A directed nonbranching sequence of nonintersecting line segments and (or) arcs bounded by nodes, not necessarily distinct, at each end. Note: there are three sub-types of Chain: Complete Chain, Area Chain, and Network Chain. GT-ring. A sequence of nonintersecting chains, with closure. A ring represents a closed boundary, but not the interior area inside the closed boundary. (GT-Ring is a sub-type of Ring.) GT-Polygon. An area that is an atomic two-dimensional component of one and only one two-dimensional manifold (a defined aggregate spatial object). The boundary of a GT-polygon may be defined by GT-rings created from its bounding chains. A GT-polygon may also be directly associated with its chains (either the bounding set, or the complete set). Part 1, Section 3--Data Quality Knowledge of the quality of data, characterizing fitness for use, is an important and integral part of data transfer. The SDTS recognizes the importance of enabling users to evaluate the suitability of data for their particular use by requiring a data quality report. The report must be part of a transfer, and it must also be available separately so that evaluation may be done without actually acquiring the data. Employing a truth-in-labeling approach, as opposed to setting absolute quality thresholds, the SDTS places responsibilities on both the producer and the receiver of data. The producer must report what quality information is known in each of five quality areas, and the receiver must determine whether data are suitable for a given application. Part 1, section 3 specifies five portions of a data quality report: lineage, positional accuracy, attribute accuracy, logical consistency, and completeness. Temporal information is relevant in each portion. The lineage portion describes source and update material (with dates), methods of derivation, transformations, and other processing history. Positional accuracy is concerned with how closely the locational data (encoded coordinate values) represent true locations. Attribute accuracy is similarly concerned with non-locational descriptive data. Different methods of obtaining measures of positional and attribute accuracy are described in section 3. Logical consistency refers to the fidelity of encoded relationships in the structure of the spatial data; for example, where appropriate, the degree to which topological relationships have been verified should be reported. The completeness portion of the quality report includes information about geographic area and subject matter coverage; for example, selection criteria and other mapping rules are relevant completeness data. The SDTS data quality report specifications are flexible and extensible, designed to allow for growth and evolution in the science and practice of reporting quality metadata. Currently only the five broad categories of quality information are defined, but detailed metadata standards could be adopted and implemented using SDTS. A data quality report can relate metadata to any level of a transfer: the entire data set, selected themes or maps, or the individual features and spatial objects. Note that the lower levels of metadata reporting (e.g. at the individual object level) are necessary for data sets created by merging data from different sources. Three methods of quality reporting are possible--textual narration, defined quality attributes, and quality overlays. Textual narration is simply verbal description of quality information. Defined quality attributes are characteristics or parameters (for example, date of source material or estimate of positional accuracy in meters) which can be assigned values. Quality overlays are layers of quality data which portray spatial variation in metadata. Reliability diagrams sometimes found in the margin of paper maps are good examples of quality overlays. Part 1, Sections 4 and 5--Logical Specifications for Spatial Data Transfer As mentioned above, translating between a specific spatial data system and its corresponding SDTS transfer is done through progressive levels of abstraction, from the conceptual to the physical. Sections 4 and 5 of part 1 represent the middle levels of the process, bridging the conceptual and the physical. Spatial objects defined at the conceptual level in section 2, along with associated attribute data and metadata, are transferred using the logical structures specified in sections 4 and 5. At the more physical levels, these logical structures are formatted as files as specified in part 3 of FIPS 173 and by ISO 8211. The SDTS Transfer Model. The organization of an SDTS spatial data transfer is defined in sections 4 and 5 in terms of a hierarchy of logical constructs that apply only to the SDTS. An SDTS transfer consists of modules; each module consists of one or more module records; each module record consists of one or more module fields; each module field consists of one or more module subfields; a module subfield carries an individual data item. The SDTS specifies 34 types of modules; a module specification table for each module type defines in detail how records, fields, and subfields shall be composed. These module specification tables and associated text comprise section 5--the bulk of the SDTS document. Section 4 contains general concepts and specifications that pertain to the module specifications in section 5. SDTS Module Types. The 34 SDTS module types can be grouped into 5 categories (table 2): global, data quality, spatial object, attribute, and graphic representation. Global modules carry information (metadata) that relate to the spatial data transfer as a whole, including information necessary for interpreting data in other modules. Data quality modules carry the data quality report. Spatial object modules convey the digital representations defined in section 2 (that is, the actual points, lines, polygons, rasters, and composites). Attribute modules carry the nonlocational data that may be associated with spatial objects and with other types of data. Graphic representation modules provide the means for transferring cartographic text display, and point, line, and area symbol information. These module types, as a whole, possess the ability to transfer an extremely wide spectrum of spatial data. A single transfer, however, would not consist of all 34 module types, but only those modules necessary for that data set (with some mandatory modules). Likewise, fields within module records and subfields within fields may be included or excluded as required. The information in the various modules of an SDTS transfer is integrated into a whole by a number of mechanisms. Entire modules can be grouped and linked by catalog records (see below). Module records can be related by values in equivalent fields or subfields. However, the primary means of linking module records is through the use of module record identifiers and foreign identifiers. A module record consists of at least one field, called the primary field, and possibly one or more secondary fields. The primary field always includes a module record identifier, unique to the entire transfer, consisting of a module name and a record number. The SDTS defines a number of relationships possible between certain module types and reserves named secondary fields to carry foreign identifiers (pointers). A foreign identifier is simply the module record identifier of another module record. Global Modules. Thirteen of the 34 SDTS module types are global, providing various metadata, including parameters for interpreting the transfer. The global modules may be further categorized into five subtypes: identification, catalog, spatial reference, data dictionary, and other. The Identification module provides (a) the identity of the versions of the SDTS and profile used (e.g. the FIPS 173 (1992) and the 2/92 version of the Topological Vector Profile), and (b) header data--several basic descriptive items about the data contained in the transfer (for example, a title, date, scale, etc.). An Identification module is required for all SDTS transfers. The catalog, consisting of three module types (Catalog/Directory, Catalog/Cross-Reference, and Catalog/Spatial Domain), supplies information about the individual modules in a transfer. All three catalog modules are recommended for transfer. The Catalog/Directory lists where each module in a transfer may be found (i.e. by file name, volume label, and record number if appropriate). The Catalog/Cross-Reference module indicates individual module-to- module relationships. For example, such a relationship exists when two different coordinate systems are used (encoded in spatial reference modules); in this case, Catalog/Cross-Reference records specify the spatial reference modules that apply to each spatial object module. The Catalog/Spatial Domain module categorizes modules by geographic area, map name, and (or) theme; for example, a module may be cataloged as "Alaska" (geographic area), "Wheelhorse 7.5- minute quad" (map name), and "hydrography" (theme). Four spatial reference module types define the reference system(s) for coordinate data (termed spatial addresses). Two module types (Internal Spatial Reference and External Spatial Reference) are always required; a third type (Registration) is required for certain raster data sets, and optional for other data; the fourth type (Spatial Domain) is optional but recommended for all transfers. The Internal Spatial Reference module specifies primarily (1) the type ((x,y) or (x,y,z)) and format (integer, real, binary...) of data coordinates, and (2) scaling and translation values to convert internal coordinates to the ground coordinate system specified in the External Spatial Reference module. The External Spatial Reference module usually specifies a ground- based coordinate system (related to latitude and longitude) in terms of horizontal and vertical datums and a map projection system; three standard systems are preferred: (1) latitude/longitude, (2) Universal Transverse Mercator (UTM), and (3) State Plane Coordinate System (SPCS). The Registration module can transfer points used to tie the internal data coordinates to the external coordinate system; for each point, both internal and external coordinates are specified. Lastly, the Spatial Domain module specifies either a window or a boundary within which data coordinates fall (for example, a map quadrangle may be specified by the latitude and longitude values of its neatline). The data dictionary, consisting of three module types (Data Dictionary/Definition, Data Dictionary/Domain and Data Dictionary/Schema), conveys the meaning and structure of entity and attribute data. The Data Dictionary/Definition module defines the meaning of entity and attribute terms (called labels) and identifies a responsible body (called authority) for each definition. The Data Dictionary/Domain module specifies the type and range of values each attribute may take and defines the meaning of attribute value codes. The Data Dictionary/Schema module specifies the record layout of each attribute module (Attribute Primary and Attribute Secondary) in terms of which attributes are included, the type, format and maximum length of the attribute values, and, for Attribute Primary modules, which entity type (specified by label) is being characterized by the attributes. See the discussion of the attribute modules (below) for more on the data dictionary modules. Two other optional module types complete the set of global modules. The Security module provides security information for modules and(or) individual module records. The Transfer Statistics module provides data volume information for each module--the number of module records and, if appropriate, the number of data coordinates. Data Quality Modules. Five mandatory data quality module types are specified for the transfer of the five components of the data quality report. The module and record structure of the report can take many forms, depending on methods of reporting used and different levels at which quality information is required. A quality record may (1) contain a textual report of any length (from a single sentence to an entire set of encyclopedias), (2) refer to any number of attribute records (with values for defined quality attributes), and (or) (3) describe via foreign identifiers the quality of any number of other individual module records (for example, individual spatial objects, attribute records, etc.). Quality modules (with one or more records) can also describe the entire transfer or only selected modules (for example, those for a given map or theme), linked through Catalog/Cross-Reference records. Spatial Object Modules. Individual feature-level spatial data are transferred in the spatial object modules. An object as defined in section 2 (see table 1) is encoded in one spatial object module record. A two-character object representation code in the primary field of the module record indicates the type of object encoded (see table 3). Spatial object data consist of three types--location, relationship, and attribute. Location data (coordinates) are transferred in the spatial address secondary fields of appropriate spatial object records (most but not all spatial object records carry coordinates). To express topological relationships between objects and to define the composition of objects in terms of other objects, SDTS-defined pointers, called foreign ID's, are included in the spatial object records. Attribute data, encoded in separate modules (see below), are also linked to the spatial objects via foreign ID's (see figure 1). The spatial objects and modules may be classified into three subcategories, related to broad classes of spatial data structures: composite, vector, and raster. The Composite module, in a subcategory of its own, transfers composite objects. Used to build user-defined objects, a composite carries no coordinate data, but is composed (via pointers) of one or more other spatial objects of any structural type--either vector or raster, or composite. Vector modules are designed to transfer point, line, and polygon objects. Nine of the 13 objects defined in section 2 fall into the vector subcategory, with a total of 27 vector object representation codes distinguishing further subtypes (see table 3). Rather than have a separate module type for each object type, however, most vector modules, differentiated primarily by dimension, can transfer several object types. The Point-Node module transfers zero-dimensional objects (points and nodes). The Line module transfers most one- dimensional objects (strings, links, and chains). The Arc and Ring modules transfer other one-dimensional objects (arcs and rings). The Polygon module transfers two-dimensional objects (G-polygons and GT-polygons). Raster modules can accommodate image data, digital terrain models, gridded GIS layers, and other regular point sample and grid cell data (all of which are termed raster data). Two module types are required for the encoding of raster data: the Raster Definition module and the Cell module. Additionally, a Registration module might be required to register the grid or image geometry to latitude/longitude or a map- projection-based coordinate system. Many different organization schemes may be used for encoding raster data. The four raster object representation codes (see table 3) are reflective of some of these schemes. Other data recorded in the Raster Definition module complete the definition of the structure, orientation, and other parameters required for interpreting the raster data. Actual pixel or grid cell data values are encoded in Cell module records. Optionally, Cell records may refer to attribute records, rather than carry values. Attribute Modules. A wide variety of possible attribute data can be associated with spatial data, both in terms of content and structure. The attribute-data-handling mechanisms in the SDTS must therefore be exceedingly flexible. Although there are only two attribute module types, Attribute Primary and Attribute Secondary, a full range of attribute data can be accommodated. Indeed, a complex relational data base can be transferred in its entirety. One can define any number of different attribute data modules, each with its own set of attributes (of any number), with each attribute having its own data type and domain of values. An attribute module can be thought of as a table (a simple relational table), with the rows being module records and the column headings being attribute labels. The only difference in structure between the Attribute Primary and Attribute Secondary modules is that Attribute Primary module records must be directly linked (by foreign ID's) to other records in the SDTS transfer. Attribute Secondary modules allow the encoding of hierarchical attribute structures and additional information about the values in the Attribute Primary modules and other Attribute Secondary modules. The secondary tables are linked to other attribute tables by the values of common attributes (that is, through possible relational joins). The attribute modules are used to transfer data linked to a number of other SDTS module types. All of the spatial object types except rings (used only to construct polygon boundaries) can be attributed by any number of Attribute Primary records. Each data quality record may also refer to any number of attribute records containing quality data. Identification records can be linked to attribute records with global attribute data. If a map projection system other than one of the standard three (latitude/longitude, UTM, or SPCS) is used, the map projection parameters are carried in an Attribute Primary module linked to the External Spatial Reference module record. Data dictionary modules (see above under global modules) define the structure and meaning of the data in the attribute modules (see figure 2). Data Dictionary/Schema records define the structure of each Attribute Primary and Attribute Secondary module in terms of the attributes included (the column heading attribute labels of the subfields in the table), and for each attribute subfield, its format, maximum length, and units of measurement (if appropriate). Schema records can also indicate which entity type (see part 2 below), if any, is characterized by the attributes in an attribute module. In this manner, the individual spatial objects may be related to the type of entity they represent. For example, an Attribute Primary module named "Roadattrs" could be designed to carry attribute data characterizing "road" (a defined entity type); the attribute labels might be surface_material, width, route_number, etc. The fact that a spatial object represents a road (for example, object "Lines#27" in a module named "Lines") would be indicated by an attribute pointer (for example, the foreign ID "Roadattrs#921"), and a schema module defining module "Roadattrs" as containing attributes of the entity type "road." An important concept in the definition of both attributes and entity types is the authority for their definition. The authority is the organization and (or) document through which meaning is assigned to an entity or attribute label. Therefore the combination of both label and authority is what makes an attribute or entity type unique in a transfer. For example, a transfer of road data might carry two different width attributes: one defined by the Highway Department (an authority) as the shoulder-to-shoulder width, and a second defined by the Planning Department (another authority) as the legal right-of-way width. All data dictionary records (including the schema records discussed above) must specify attributes and entity types as the combination of label and authority. Annexes to part 2 of the SDTS contain lists of standard entity type terms and attribute terms; if these terms are used as labels in a transfer, the authority for their definition is "SDTS" and Data Dictionary/Definition records are not required to further convey the meaning of the terms. Otherwise, each attribute and entity label must be defined in a Data Dictionary/Definition module record, with a full description of the source and authority for the definition. To complete the data dictionary information required to interpret attribute data, the Data Dictionary/Domain module is required to specify the domain of values that each attribute can take. Domains are characterized by type (character, integer, real, binary, etc.) with a possible range of values, or as a set of enumerated values. If the values are codes (other than standard FIPS codes), the meaning of the codes must be defined in the Data Dictionary/Domain module. Note that a single data dictionary of Data Dictionary/Definition and Data Dictionary/Domain modules could be defined for a series of transfers such as those from a major data producer. Each individual transfer could then just refer to these modules as external rather than include them in the transfer. One last but important word about the capabilities and uses of the SDTS attribute data modules is in order. If some component or data element of a user data model cannot be translated to a specific SDTS module record, field, or subfield, it can usually be modeled and encoded as attribute data. This includes relationships which are not predefined in the SDTS. Examples of such relationships might include secondary topological relationships (for example, winged-edge topology) or vertical relationships between features. A user-defined relationship can be modeled as an attribute, complete with a label and authority defined in data dictionary records. Relationship pointers are stored as attribute values in Attribute Primary modules. In this manner, any module record which can have generic user-defined attributes (that is, spatial object and Identification records) can be linked to any other record in the transfer through a user-specified relationship defined in the data dictionary and encoded in Attribute Primary records. Graphic Representation Modules. The SDTS has been designed to transfer primarily geographic data (that is, data related to the real- world). Although the scope of the standard includes cartographic data, the SDTS is not intended to transfer purely graphic picture data such as instructions for drawing a map. Other standards, such as the Computer Graphics Metafile standard (ANSI, 1986b), provide this capability. The ability to transfer cartographic display information along with the geographic data, however, is a frequent requirement in spatial data transfer. The graphic representation modules therefore allow this type of information to be transferred. A vector object encoded in a Point-Node, Line, Arc, or Polygon module record may be symbolized or displayed by reference to an appropriate Graphic Representation module record. Six graphic representation module types are specified: Text Representation, Line Representation, Symbol Representation, Area Fill Representation, Color Index, and Font Index. The Text Representation module transfers textual display information. A special point object type, the label point (encoded in a Point-Node record), defines the reference point for the text string to be displayed. Other fields in a label point record relate it to the text string (in an attribute module subfield) and may encode an orientation or curve for the text string to follow. A Text Representation record specifies display information such as font, color, character height, spacing, skew angle, and aspect ratio, and the text alignment relative to the label point data. Font and color are specified by referring to records in the Font Index and Color Index modules, respectively. The Symbol Representation, Line Representation, and Area Fill Representation module types provide information for symbolizing zero- , one-, and two-dimensional objects, respectively. All three types include display scale parameters and refer to the Color Index module. The Symbol Representation module includes size and marker type data for symbolizing points and nodes. The Line Representation module provides width and linear symbol type data necessary to portray strings, links, chains, and arcs. The Area Fill Representation module includes fill type and, if appropriate, hatch or pattern index data for symbolizing polygons. The Color Index module defines colors referred to by the other graphic representation modules in terms of red, green, and blue components. A black component and equations for converting to yellow-magenta- cyan are also supplied for color process printing. The Font Index module provides a link between a font index value in a Text Representation module record and a font specified either as a number or a name in a Data Dictionary/Domain record. In this same manner, a number of the parameters in other graphic representation modules may take user-defined values, which are then defined in Data Dictionary/Domain records. Part 2 As part of the data transfer process, there is a need for common definitions of spatial features. Additionally, the spatial data community recognizes the intensifying need to share data. Agreement on a common format is not sufficient to ensure that the information transferred is meaningful to both the exporter and the importer. Part 2 of the SDTS is a formal attempt to develop a standardized list of entities. The lists in part 2 are the product of several years of effort which involved consideration of about 2,600 definitions of geographic features by different organizations with different requirements. The lists present 200 defined entity types, 244 defined attributes, and over 1,200 included terms. The standard defines the following terms: Entity type - a set into which similar entity instances are classified (e.g., bridge). Entity instance - a spatial phenomenon of a defined type that is embedded in one or more phenomena of a different type, or that has at least one key attribute value different from the corresponding attribute values of the surrounding phenomena (e.g., the 10th Street Bridge). Attribute - a defined characteristic of an entity type (e.g., composition). Attribute value - a specific quality or quantity assigned to an attribute (e.g., steel) for a specific entity instance. Standard term - primary label of an entity type or attribute (e.g., bridge). Included term - a synonym or specialization that is cross- referenced to an SDTS-defined entity type or attribute (e.g., overpass). One standard entity term may have multiple attributes or included terms associated with it. For example, the entity "watercourse" includes terms such as arroyo, stream, creek, canal, wash, and gully and includes attributes such as location, depth, width, and name. Attributes accommodate the differences in definitions which may occur from one source to another. For example, to differentiate included terms such as creek and river, the attribute "volume_of_flow" may be added to the entity watercourse. The relationship between a covered bridge and a watercourse may also be expressed using attributes. For the bridge, the attribute "feature_spanned" can have "watercourse" as a value, and for watercourse, "feature_crossed_under" can be coded with the value "bridge." Translating from one feature coding scheme to another is similar to the process of encoding real-world entities as digital feature objects. For example, to define a covered bridge that has the user- specific system code 170.511, a relational table may look like this: User Code Feature Attribute Value 170.511 BRIDGE COVERED/UNCOVERED COVERED The SDTS allows for different levels of conformance to part 2 taking into consideration the variety of features and definitions that exist. Within the Identification module mentioned in part 1, a features level subfield indicates the level of conformance to part 2. Level 1 indicates that the transfer consists only of standard entity and attribute terms listed and defined in part 2. Level 2 indicates use of standard entity and attribute terms along with nonstandard terms that have been converted to standard terms if contained in list of included terms. Level 3 indicates use of a mixture of standard and user-defined terms. Level 4 indicates that all terms are user-defined. In all cases where user-defined or nonstandard terms are used, the data dictionary modules are included in the transfer to explain these terms. Part 2 is presented as a living document subject to future expansion to meet the diverse needs of the spatial data community. Although the initial development effort focussed on hydrographic and topographic features, additional categories are being standardized. The U.S. Department of Commerce, NIST, delegated authority to the USGS to establish a FIPS Spatial Features Register. This register will be maintained and managed by the USGS; USGS will be responsible for the addition, modification, or deletion of spatial features to the register. The USGS will designate organizations as sponsoring groups for appropriate categories of spatial features; the FGDC may provide several possible sponsoring groups. The next update of part 2 will be submitted as a revision to the FIPS. All interested parties are encouraged to participate. Introduction to Part 3 While parts 1 and 2 of the SDTS address the logical and conceptual levels of the standard, part 3 addresses the physical implementation of the SDTS using an existing data exchange standard, ISO 8211. Part 3 specifies how the constructs defined in part 1 of the SDTS--modules, fields, and subfields--are mapped into ISO 8211 constructs. ISO 8211 The ISO 8211 standard is recognized by three different standards organizations and thus has three different names. It was first adopted as a standard by the International Organization for Standards (ISO) as ISO 8211-1985. It was then adopted by the American National Standards Institute, Inc. (ANSI) as ANSI/ISO 8211-1985. Finally, it was adopted by NIST as FIPS Publication 123 in 1986. ISO 8211, ANSI/ISO 8211, and FIPS 123 are all the same standard. This article will refer to the standard as ISO 8211. It is important to keep in mind that the SDTS and ISO 8211 are separate standards. ISO 8211 is a general-purpose data-exchange format that can be used to transfer any type of data, not just spatial data. ISO 8211 provides a means of transferring data records and their description between dissimilar computer systems, but requires that the content and the meaning of the records be defined by the user. The SDTS can be considered the user of ISO 8211. The SDTS is designed so that parts 1 and 2 are independent of part 3. If necessary, the SDTS could change part 3 to use a different implementation format other than ISO 8211 without affecting parts 1 and 2. ISO 8211 was selected so that the SDTS could use an existing general- purpose transfer standard rather than having to develop a new SDTS- specific format. ISO 8211 is designed for data transfer, not data processing. It is designed to work for any media, including communications lines. ISO 8211 is self describing. A file contains both data and the description of the data. There is a fixed portion of the file defined by the standard; this fixed portion defines the following portion that is variable. ISO 8211 Structure An ISO 8211 file is called a Data Descriptive File (DDF) (fig. 3). It consists of two types of records. The Data Descriptive Record (DDR) contains the structure and description of data. The Data Records (DR's) contain the actual data. There is always one DDR in a file, and one or more DR's. Records consist of one or more fields. A field can be thought of having two components: its description and structure contained in the DDR, and its data contained in the DR. Fields consist of one or more subfields. Subfields are the basic ele- ments of data. Record Structure. Both DDR's and DR's are broken into three parts. These parts are described below. The first part of both the DDR and DR is called the leader. Although its format varies between the DDR and the DR, its purpose is the same. The leader is always 24 bytes long and serves to describe the remainder of the record. Information included in the leader includes the length of the record and the lengths of entries in the second part of the DDR and DR, the directory. The directory specifies the tag, length, and position (relative to the start of the DDR or DR) of each field in the record. Tags are internal field names that are used in the directories of both the DDR and DR's to match the description in the DDR with the data in the DR's. The third part of a record differs between the DDR and the DR. The third part of DR's contains the User Data Area (UDA), containing the actual data fields. Data Descriptive Area. The third part of a DDR contains the Data Descriptive Area (DDA), which consists of data descriptive fields that define the structure and description of particular fields. There are four parts to the description of each field: The field control part consists of 6 bytes describing the field's structure and type: - Position 0 is the structure code (0=elementary, 1=vector, 2=array) - Position 1 is the type code (character, integer, real, binary, mixed, etc.) - Positions 2 and 3 are reserved and are always 0 - Position 4 is a user-defined printable symbol for the system field terminator delimiter, often ";" (see below) - Position 5 is a user-defined printable symbol for the system unit terminator delimiter, often "&" (see below) The field name, a descriptive name of the field Labels, descriptions of the subfields that make up a field (see below) Format, specification of the format of each subfield (see below) The varying portions of a data descriptive field (the field name and labels), must end with a special delimiter reserved by ISO 8211. This delimiter, called the Unit Terminator (UT), is unprintable ASCII character 31 (decimal). As in the examples in this article, this character is often printed with the "&" character. The data descriptive field must end with the Field Terminator (FT), another delimiter reserved by the standard. The FT is also unprintable, ASCII character 30 (decimal). It is often replaced by ";" when printed, including in this article. Field Structure. Fields can be either elementary (containing a single value), a vector (a one-dimensional array), or an array (two or more dimensions). For elementary structures there are no subfields and the label portion of the data descriptive field is empty. For vector structures, the labels for each subfield are separated by exclamation marks. For example LABEL1!LABEL2!LABEL3 Array-structured fields have Cartesian labels, which are vector labels separated by asterisk characters. For example A!B!C*X!Y!Z Cartesian labels are multiplied out with the labels in the last vector varying the fastest. For example, the previous example when multiplied out becomes AX AY AZ BX BY BZ CX CY CZ Labels that start with an asterisk, called a null vector by ISO 8211, repeat themselves indefinitely to correspond to the data. For example, *X!Y indicates that the vector label X!Y will repeat until the end of the data field is reached. This is how the SDTS implements two- dimensional spatial addresses (coordinates) in the Line module where the actual number of spatial addresses can be variable. Format Description. The format portion of the data descriptive field consists of format controls that specify the character-by-character or bit-by-bit structure of the data field. Format controls can be used to specify fixed field lengths. For example (A(10)) indicates a 10 character field with character data. Format controls can be used to specify user delimiters within the data. For example (A(,)) indicates character data with a user delimiter of a comma character. If user delimiters or field lengths are not used the unit terminator can be used to separate subfields, and the field terminator can be used to end fields. In such cases the format control for a subfield consists only of the character indicating the data type. For example (A) Subfield formats can be preceded by a repeat count. For example (5A(10)) Types of subfields can be mixed in a field. For example (A(3),I(2),5A(#),A) The types of data that can be included in the format are as follows: A - character data B - bit field data (binary) C - character mode bit field (characters "0" and "1") I - integer data R - real number data S - floating point data X - unused character positions ISO 8211 Special Purpose Fields. ISO 8211 defines several special purpose fields. The file control field is identified by tag 0..0 (0.. indicates zero fill; the number of zeros will vary based on the tag length). This optional tag is used only in the DDR to specify a title for the entire file. The record identifier field, tag 0..1, is required to assign an identifier to each record. Tag 0..2 is an optional user extension field of user-defined content. It can only appear in the DDR. Tags 0..3 through 0..9 are reserved for future standard uses. ISO 8211 File Levels. There are three levels of ISO 8211 DDF's. Level 1 contains only elementary structures and character data. Level 2 supports any structure and any data type and is the most commonly used. Level 3 supports everything level 2 does but also supports hierarchical relationships between fields. The file level is specified in the DDR leader. Dropping Leaders and Directories. When DR's are fixed length and the leader and directory sections of the record are the same for all records, the leader and directory for all records after the first can be dropped. The leader for the first DR should contain an "R" in offset position 6 to indicate that the same leader and directory should be used for all subsequent DR's. Once the leader and directory is dropped, it cannot be respecified for the remainder of the file. Dropping leaders and directories can significantly reduce file sizes when there are many fixed-length records. Binary Data. In addition to ASCII character data, ISO 8211 supports binary data. Binary data have special requirements. Binary data must have format control with the width being specified in bits. For example, the format control for a 16-bit binary value would be: (B(16)) Because the field terminators and unit terminators cannot be used with binary data, the exact length in bits must be specified so that the precise end of the data can be determined. Binary data must start and end on a byte boundary, with binary zero padding if necessary. ISO 8211 transfers binary data without interpretation; the data are just a series of bit values. The data may be signed or unsigned, integer or real, etc. The interpretation of the data is the responsibility of the user. The SDTS as the user of ISO 8211 provides subfields to transfer information on the type of binary data. For example, when spatial addresses are transferred as binary data, the Horizontal Component Format and Vertical Component Format subfields of the Internal Spatial Reference module contain information on how the binary values are to be interpreted. An Example ISO 8211 File Figure 4 shows an example ISO 8211 DDF. This example has been re- formatted for clarity. Carriage returns have been inserted at logical breaks. The unit terminators have been replaced by "&" characters and the field terminators by ";" characters. Space characters have been replaced by "^" characters. Explanatory comments have been added (in parentheses) to the right of the data. In this example, as in any ISO 8211 file, there is one DDR. This example has 3 DR's. The leader of the DDR contains the following: 002212L^^^0600073^^^4404 Decoding some of the information in this leader results in the following: The total length of the DDR in bytes is 221 bytes (first 5 characters of leader) The interchange level of the file is 2 (6th character) The lengths of the length, position, and tag entries in the directory are all 4, (characters 21, 22, and 24) Looking at the directories of both the DDR and DR it can be seen that both contain a tag called ATTP. The entries for the ATTP tag are highlighted in figure 4. In the DDR, tag ATTP has a length of 44 and an offset of 104 from the beginning of the DDR. In the DR, tag ATTP has a length of 11 and an offset of 18 from the start of the DR. Using these lengths and positions one can locate the descriptive field in the DDR and the data field in the DR. These are highlighted in figure 4. The descriptive field for ATTP in the DDR includes the following: The field control is 1600;& - 1 indicates vector structure - 6 indicates mixed data type - ;& are printable characters for the field and unit terminators The field name is PRIMARY ATTRIBUTES There are two subfields with labels PSAD and NAME The format of PSAD is character with a fixed length of 2 characters. The format of NAME is character with no length specified and no user-defined terminator. Using the format to decode the field from the first DR, The first two characters of the field are "01", these are the data for the PSAD subfield. The data for the NAME subfield are "Missouri". Since this subfield had no length or user-defined terminator in its format definition in the DDR, its end is indicated by the field terminator. Mapping the SDTS into ISO 8211 Part 3 specifies how SDTS logical constructs defined in part 1 are mapped into ISO 8211 constructs. Table 4 is a summary of corresponding constructs. Note that the field mnemonic from part 1 becomes the ISO 8211 field tag and that the subfield name or mnemonic from part 1 becomes the ISO 8211 label. Part 3 Specifications of ISO 8211 Constructs Part 3 contains a table of ISO 8211 specifications including tags, field controls, names, labels, and formats reserved by the SDTS for the transfer of modules. It consists of entries for each module field in the following format: Tag st00fuName& (part 1 section reference) []|[n]|[m,n] Label& Format; where: Tag is the ISO 8211 field tag st00fu are the field controls (6 bytes) Name& is the field name, "&" represents its unit terminator delimiter [] specifies there are no labels [n] specifies n subfield elements of a vector structure [m,n] specifies the dimensions of a two-dimensional array | indicates that one of the above 3 cases will exist Label& is an ISO 8211 vector or Cartesian label, "&" represents its unit terminator delimiter Format; is the ISO 8211 format control, ";" represents its field terminator delimiter. Formats may require completion by the user to add field widths, user-defined delimiters, or repeat factors. A value of "z" indicates that the data type must be supplied by the user from a list of allowable types. It can be seen that the entries in the specification table contain the field controls, field name, label, and formats required for the ISO 8211 data descriptive field. The ISO 8211 tag required for DDR and DR directories is indicated. The information on field dimensions and the part 1 section reference are for information. The part 1 section reference only appears on the first field of each module. The following is an example entry from the specifications table in part 3: IDEN 1600;&IDENTIFICATION& (See part 1, 5.2.1.1) [15] MODN!RCID!STID!STVS!DOCU!PRID!PRVS!PDOC! TITL!DAID!DAST!MPDT!DCDT!SCAL!COMT& (A,I,11A,I,A); These are the specifications for the Identification field in the Identification module. The ISO 8211 field tag is "IDEN", field control is "1600;&", the field name is "IDENTIFICATION", the field has a vector structure with 15 subfields, the first subfield label is "MODN", and the format of the first subfield is "A". This entry can be compared to table 10 of part 1 of the SDTS, which contains the logical specification for the Identification module, to see how the part 1 specifications map into ISO 8211. The part 1 field mnemonic is "IDEN"; this maps to the ISO 8211 field tag. The first subfield mnemonic in part 1 is "MODN"; this maps to the first ISO 8211 subfield label. The part 1 field name is "Identification"; this maps to the ISO 8211 field name "IDENTIFICATION". The part 1 data type of the first subfield is character and its domain is alphanumeric characters; the ISO 8211 format for this subfield is character. As a general rule in the SDTS, fields that do not repeat are in a vector structure while fields that can repeat are in an array structure. The following is an example of an array structure in an entry in the part 3 specifications table: SADR 2600;&SPATIAL ADDRESS& [m,3] *X!Y!Z& (3z); where z implies (I|R|S|B) This is the entry for spatial addresses in the Line module. This is an example of a field that can repeat, since the number of spatial addresses for a line spatial object is variable. The "m" indicates that one of the dimensions of the array is variable. The leading "*" indicates that the field can repeat. The "2" in the format control indicates array structure. Also note that the "z" in the format control indicates a choice of data types; in this case the choices are integer, real, floating point, and binary. If the field does not repeat, part 3 allows the field to be changed from Cartesian structure to vector structure: the "2" in the format control would change to "1" and the leading "*" would be eliminated. Example of Encoding Tables 5 and 6 and figures 5 and 6 present an example of encoding user data into ISO 8211 using the SDTS. This example encodes data into an SDTS Line module as used by the Topological Vector Profile. The source of the data for this example is a digital line graph 3 (DLG- 3) file produced by the USGS; many other topological vector data models could be similarly encoded. Part 1 Transfer Specification. Table 5 lists the fields and subfields for the Line module as described in the logical transfer module specification of part 1 of the SDTS (section 5.6.2). The table includes the subfield DR contents and their sources when mapping DLG-3 data into the SDTS using the Topological Vector Profile. Some fields or subfields are not applicable because they are not used in this particular SDTS profile or are not applicable to the DLG-3 data model. For example, because the Topological Vector Profile does not include representation modules, the Representation Module ID field can not be used. The Z subfield of the spatial address field is not applicable, because DLG-3 data have only two-dimensional coordinates. Many fields in the Line module are foreign identifiers--pointers to records in other modules; these consist of module name and record ID subfields. Module names, standardized by the Topological Vector Profile, consist of a standard two-character object representation code followed by two digits. The foreign identifier that links this line record to its corresponding attribute primary module would have to be generated by the encoding software since there is no corresponding record identifier in the DLG-3 file (the identifier would be eliminated if there were no corresponding attribute module record). All other subfield contents can be obtained directly from the input DLG-3 dataset. DLG area, node, and line numbers become SDTS record ID's. Part 3 Specifications. Table 6 is an extract from the specifications table of part 3 where the ISO 8211 tags, control fields, names, labels, and formats for each field in the Line module are listed. Example File. Figure 5 contains an ISO 8211 file for a Line module created from a DLG-3 dataset using the SDTS Topological Vector Profile. It has been reformatted for greater legibility: field terminators are replaced with ";" characters, unit terminators are replaced with "&" characters, space characters are replaced with "^" characters, carriage returns are added to improve legibility. This file originally had more DR's, only three have been included in this exam- ple. An Example of One Field. As an example, the Polygon ID Left field can be examined in more detail. As shown in table 5, the Polygon ID Left field consists of a foreign identifier that identifies the polygon module record of the polygon to the left of the line. The field consists of two subfields. The module name subfield is standardized by the Topological Vector Profile; it consists of the letters "PC" followed by two digits. The record ID corresponds to the record ID pointed to in the polygon module; in this case it corresponds exactly to the DLG left area ID. Using part 3, as shown in table 6, it can be seen that the ISO 8211 field tag is "PIDL", the field controls are "1600;&", the field name is "POLYGON ID LEFT", the subfield labels are "MODN" and "RCID", and the format is "(A,I)". These ISO 8211 specifications can then be used in the DDR, as highlighted in the ISO 8211 file illustrated in figure 5. The data for this field in the three DR's shown are also highlighted. Since the format does not specify subfield lengths or user delimiters, the unit and field terminators indicate the end of each subfield's data. Note that MODN and RCID are both the corresponding ISO 8211 labels and the SDTS subfield mnemonics and that PIDL is both the ISO 8211 tag and the SDTS field mnemonic. Figure 6 contains a plot of the data contained in figure 5. The record ID's of the chains, polygons, and nodes are shown in figure 6. Special Situations Tag Conflicts. Generally, part 3 specifies the ISO 8211 tags for each field. However, ISO 8211 does not allow a tag to be repeated in the same DDR, and there may be situations where the user may need to specify multiple descriptive fields for the same tag. These are situations where there are user-selected data types, and the user needs to use different data types in different instances of a subfield. For example, the Data Dictionary Domain field has a Domain Value subfield which has a data type selected by the user. The data type of the field is likely to vary from record to record depending upon the data type of the attribute being referred to. There are three possible solutions to tag conflicts. Multiple DDF's could be used to separate the conflicting tags into different DDF's. This may not be practical in many cases, including the example of the Data Dictionary Domain (above). Another would be to convert all data and descriptions to be compatible. For example, all data could be converted to ASCII character data. This would work but would require more work when translating to ISO 8211 to convert the data, and this would eliminate the data description capability of ISO 8211. Part 3 offers a third solution to tag conflicts; this solution will always work and may be the most practical to use. The user can add an optional fifth character to the tag. For example, instead of DDOM, the tag specified in part 3, the user could create tags DDOM1 and DDOM2. All tags within a file must be the same length, so if some tags must be made 5 characters long, all tags must also be 5 characters long. Missing Data. Part 3 specifies procedures for handling missing data. If a data field is missing from all DR's in a file, the tag and data descriptive field may be omitted from the DDR. If a field is missing from a specific DR, the tag for the field is eliminated from the directory of the specific DR. If a particular subfield is missing from all DR's in a file, then the subfield label may be omitted from the list of labels. For example, when spatial addresses do not have an elevation coordinate, the "Z" subfield label can be omitted. If a subfield is intermittently missing, its format should use a delimiter and missing data should be represented by zero bytes followed by the delimiter. User-defined Labels. Labels are defined in part 3 except for attribute modules, in which users can specify labels that correspond to attribute names. Users also modify the data type and format control to correspond to the data type of the attribute. Files and Media Global Modules. For global modules, one ISO 8211 record always contains the fields of exactly one module record. One ISO 8211 file contains the records of exactly one module. Other Modules. For other modules, ISO 8211 records may contain fields from one or more modules. ISO 8211 files may contain records from one or more modules. The SDTS warns against indiscriminately merging unrelated modules. The Topological Vector Profile is more restrictive than the SDTS: it requires that all ISO 8211 files contain exactly one SDTS module. If required due to the amount of data, the SDTS allows multivolume files. If the media do not support multivolume files, modules can be transferred as multiple files. Media Requirements. ISO 8211 references other standards for specific media: ANSI X3.27 level 2 for magnetic tapes (the SDTS specifies a block size of 2048 bytes), ISO 9293 (DOS format) for flexible diskettes, level 2 of ANSI/ISO 4341 for magnetic tape cartridges and cassettes (the SDTS specifies a block size of 2048 bytes), level 1 of ISO 9660 for compact disk read only memory (CD-ROM). Part 3 specifies that any unused bytes of the last media record of a file are filled with caret characters. The SDTS permits a human-readable README file describing the nature of the file set to be included with an SDTS transfer. On sequential media it should be the first file. On random access media volumes it should be in the root directory. Conclusion The SDTS (FIPS Publication 173, 1992), is now available as a mechanism for the transfer of spatial data between dissimilar systems. By conforming to common concepts for the definition of spatial features, and eventually to common terms for features and attributes as in part 2 of the SDTS, data producers and users can convey the meaning of spatial information. The conceptual model in part 1 of the SDTS provides a basis for agreement on the representations of geographic and cartographic information in a digital environment. The transfer specifications in part 1 provide the mechanisms for structuring and encoding these representations so that the meaning of the data is not lost in transfer. By using a general data transfer standard, ISO 8211, for the implementation of the logical specifications in part 1, part 3 enables the SDTS to be flexible, extensible, self-defining, and system and media independent. By requiring that a data quality report be available to allow users to evaluate the fitness of data for use, the SDTS clarifies the integrity, quality, and useability of data transferred. The SDTS represents a major accomplishment by the spatial data community as a whole, and serves as a significant step toward common understanding and meaningful sharing of information. _______________________________________ REFERENCES Altheide, P. 1992. "Presentation Notes for ISO 8211 Standard for the Spatial Data Transfer Standard." Available from the SDTS Task Force, U.S. Geological Survey, 526 National Center, Reston, VA 22092. Altheide, P. 1992. "Presentation Notes for SDTS Part 3." Available from the SDTS Task Force, U.S. Geological Survey, 526 National Center, Reston, VA 22092. American National Standards Institute. 1986a. Specification for a Data Descriptive File for Information Interchange, ANSI/ISO 8211- 1985, FIPS PUB 123. American National Standards Institute. 1986b. Computer Graphics Metafile for the Storage and Transfer of Picture Descriptive Information, ANSI X3.122-1986, FIPS PUB 128. Digital Cartographic Data Standards Task Force. 1988. "The Proposed Standard for Digital Cartographic Data." The American Cartographer, vol. 15, no. 1, pp. 7-140. Lazar, R. 1992. "The SDTS Topological Vector Profile," to be published in Cartography and Geographic Information Systems, December 1992. National Institute of Standards and Technology. 1992. Federal Information Processing Standard Publication 173 (Spatial Data Transfer Standard). U.S. Department of Commerce. U.S. Geological Survey. 1991. National Mapping Program Technical Instructions, FIPS Pub 123 Function Library Software Documentation. U.S. Department of the Interior. _______________________________________ ACKNOWLEDGEMENTS The original version of Figure 2 was drafted by Peter Aronson, Environmental Systems Research Institute, Phoenix, AZ. Figures 3 and 4 were created by Phyllis Altheide of the U.S. Geological Survey. Robin Fegeas is a geographer, and Janette Cascio and Robert Lazar are cartographers in the Branch of Standards and Technology, Office of Research, U.S. Geological Survey, 526 National Center, Reston, VA 22092 _______________________________________ FIGURES Figure 1. SDTS spatial object module linkages. Figure 2. SDTS attribute module linkages. Figure 3. ISO 8211 file structure. (Not in Word Perfect format.) Figure 4. ISO 8211 DDF example. Figure 5. SDTS Line module encoded in ISO 8211. Figure 6. Plot of data shown in figure 5. Chain, polygon, and node ID's can be compared to figure 5. (Not in Word Perfect format.) TABLES Table 1. Definitions of SDTS simple spatial objects. Table 2. SDTS module categories and types. Table 3. SDTS spatial object modules, object types, and object representation codes. Table 4. Relationship between SDTS and ISO 8211 constructs. Table 5. SDTS Line module fields and subfields. Table 6. ISO 8211 specifications for SDTS Line module. Note: Figures and tables are not available in the ASCII version of this document. Most (but not all) are included in the Word Perfect and PostScript versions.