TRANSFER STANDARD
PART 1
LOGICAL SPECIFICATIONS
Foreword
This document contains a specification of the Spatial data Transfer Standard (SDTS), that will serve as a national spatial data transfer mechanism for the United States. As such it is designed to transfer a wide variety of data structures that are used in the spatial sciences. These sciences include cartography, geography, geology, geographic information systems and many other neighboring sciences. SDTS consists of three primary parts: the first is the SDTS logical superstructure that presents the organization and structure of the SDTS transfer mechanism; the second presents the definition of spatial features and attributes; and the third part presents the ISO 8211 data transfer implementation (i.e., encoding method).
Work on a national spatial data transfer standard was begun by the National Committee for Digital Cartographic Data Standards in 1982 to develop a comprehensive set of data exchange standards for the profession. This work was funded by the U.S. Geological Survey through a grant to the American Congress on Surveying and Mapping. In 1985, the Standards Working Group of the Federal Interagency Coordinating Committee on Digital Cartography also began work on spatial data exchange standards. During 1987, the results of these parallel efforts were merged by the Digital Cartographic Data Standards Task Force into the proposed Digital Cartographic Data Standards, published as a special issue of The American Cartographer in January 1988. Subsequent testing, modification, and refining of the results of these efforts were done by the Spatial Data Transfer Standard Technical Review Board. The end product of all of this effort is the standard presented here.
This result represents a collaborative effort by these groups to define a standard that will support work with cartographic and geographic data systems and facilitate spatial data transfer. It is designed to serve the spatial data transfer needs of the Federal agencies, especially the proposed National Geo-Data System, and the work of State and local governmental entities, the private sector, and research organizations.
The committees and individuals who developed this standard include:
U.S. Geological Survey,
Spatial Data Transfer Standard Technical Review Board
(as of October 1991)
U.S. Geological Survey,
Digital Cartographic Data Standards Task Force
(as of April 1988)
Voting Members
Advisory Members
Federal Interagency Coordinating Committee for Digital Cartography,
Standards Working Group
(as of April 1987)
American Congress on Surveying and Mapping,
National Committee for Digital Cartographic Data Standards
(as of April 1987)
Steering Committee
Working Group I, Data Organization
Working Group III, Cartographic Features
This Spatial Data Transfer Standard (SDTS) provides a solution to the problem of spatial (i.e., geographic and cartographic) data transfer from the conceptual level to the details of physical file encoding. Transfer of spatial data involves modeling spatial data concepts, data structures, and logical and physical file structures. To be useful, the data to be transferred must also be meaningful in terms of data content and data quality. SDTS addresses all of these aspects for both vector and raster data structures.
The standard is in three parts. Part 1 addresses the logical specifications in terms of conformance requirements, a conceptual model, quality specifications, the data structure model, and the transfer format. Part 2 addresses data content by providing a standard list and definitions of spatial features and their attributes. Part 3 specifies the implementation of SDTS in terms of the International Organization for Standardization for a Data Descriptive File for Information Interchange.
Section 1 of part 1 includes a statement of scope and conformance requirements for SDTS. It also includes normative references to other standards and definitions of terms.
The conceptual model of spatial data is presented in section 2 to provide a framework for defining spatial features and a context for the definition of a set of spatial objects. This conceptual model supports the translation of user data models to and from the SDTS model. Within section 2 is a defined set of spatial objects, for zero, one, and two dimensions, used in spatial data systems to represent real-world spatial phenomena. Threespatial objects have not been specified. The defined set of objects will support the three major types of spatial data operations: (1) geometry only,
(2) geometry and topology, and (3) topology only. These objects have been specified in a modular fashion so that more elaborate composite objects can be confrom them.
Section 3 includes specifications for a quality report concerning the objects in a transfer and their attributes. The purpose of the quality report is to provide detailed informafor a user to evaluate the fitness for a particular use. This style of standard can be characterized as "truth in label," rather than fixing arbitrary numerithresholds of quality. To implement this portion of the standard, a producer is urged to include the most rigorous and quantitative information available on the components of data quality described in this section.
Sections 4 and 5 present specifications for the transfer of spatial data. Section 4 contains general concepts and specifications, the underlying models that pertain to the transfer module specifications of section 5. Section 4 also specifies the general elements of an implementation, the relationships of the logical constructs of the data models to the general elements of a detailed implementation, and general constraints on the implementation. Finally, section 4 presents the transfer module specification conventions used in section 5. Logical modules consisting of detailed record, field and subfield specifications are presented in section 5.
This standard specifies a structure and content for spatially referenced data in order to facilitate data transfer between dissimilar spatial data base systems.
This standard anticipates products that do not contain instances of all the specified information and syntactic forms. This portion specifies the condiof conformance and the requirements of a conformance statement. This standard does not specify requirements for processing data into and out of the standard, therefore such processing cannot itself conform to this standard.
Any product claiming conformance to this standard shall follow the applicable requirements and specifications of parts 1, 2, and 3 with respect to both the syntax and the semantics of all included data elements.
This standard requires that spatial data to be transferred shall include a report on data quality. This Data Quality Report shall always accompany the data in a standard transfer. It consists of five portions described in detail in section 3: lineage, positional accuracy, attribute accuracy, logical consistency, and complete. Where a spatial variation in quality is known, the quality report shall record that variation.
1.2.2.1 Form of a Quality Report . The Data Quality Report shall always accompany the data in a stantransfer. Because the quality report will function in the assessof fitness for use, it shall also be obtainable in its entirety and separately from the actual data. This separate quality report may be issued as a Spatial Data Transfer or as a paper docu.
1.2.2.2 Tests for Data Quality . In 3.2, 3.3, and 3.4 below, options are described for different categories of testing. Informed assessment of fitness for use is best served by the most rigorous types of tests.
1.2.2.3 Quality Overlays . For those components of quality displaying spatial variation, a quality overlay system may be used. The producer of the quality report may choose to produce a comprehensive quality overlay describall components of quality or separate overlays portraying various components. When the quality report is issued on paper, the quality overlays appear as diagrams with text labels or thematic map depictions. In digital form, the overlays shall be encoded using the specifications of sections 4 and 5.
A statement claiming conformance to this standard shall specify the profile and level of conformance for each applicable component of the Transfer Specification as defined in 1.2.4.
1.2.4 Transfer Specification Conformance Field
The Identification module of the Transfer Specification (5.2.1) includes a Conformance field. This field contains subfields for a profile specification, external spatial reference conformance and a level of conformance to spatial feature definitions. Each subfield is required to contain one of the values enumerated in 5.2.1.2.
1.2.4.1 Profile Specification . The transfer shall include the profile specifidescribed in 5.2.1.2.1. This specificadefines the domain of object types included in the transfer. Object types other than those identified in the Profile Specification subfields shall not be included in the transfer.
1.2.4.2 External Spatial Reference Conformance . Whether or not one of the three recommended reference systems-- Geographics, UTM/UPS, or State Plane-- has been used, shall be specified in the External Spatial Reference subfield of the Conformance field of the Identification module, as described in 5.2.1.2.2, as well as in the Reference System Name subfield of the External Spatial Reference module (5.2.4.2).
1.2.4.3 Features Level . The level of conformance to the list of stanterms and definitions of spatial Entities and Attributes conin part 2 of this standard shall be specified in the Features Level subfield of the Conformance field of the Identification module. Each level has the meaning specified in 5.2.1.2.3.
1.2.5 Private Agreements
Private agreements limit the scope of the transfer and are discouraged. Recurring needs for similar private agreements should be referred to the maintenance organization for this standard.
1.3 References
This standard shall be used in conjunction with the following normative references. When a publication is superseded by a revision approved by the authorizing organization, the revision shall apply. (An informative list of references that includes the following in addition to other sources used in preparing this standard is contained in annex F.)
1.3.1American National Standards Institute, Inc., 1986, American National Standards for Information Processing -- Coded Character Sets -- 7-Bit ASCII. 1.3.2 American National Standards Institute, Inc., 1430 Broadway, New York, New York 10018.
1.3.2American National Standards Institute, Inc., 1986, American National Standard for Information Systems - Database Language - SQL (SQL). American National StanInstitute, Inc., 1430 Broadway, New York, New York 10018.
1.3.3American Society for Photogrammetry and Remote Sensing, Committee for Specifications and Standards, 1990, "ASPRS Accuracy Standards for Large Maps," (approved by ASPRS Professional Practicing Division, March 1990), Photogrammetric Enand Remote Sensing, Volume LVI, No. 7, July 1990, pp. 1068-1070.
1.3.4Calendar Date, 1968, FIPSPUB 4-1, 27 Jan 88; also ANSI/X3.30-1985.
1.3.5Catalog of Widely Used Code Sets, 1985, FIPSPUB 1985.
1.3.6Codes for Identification of Federal and Federally Assisted Or, 1982, FIPSPUB 95, 23 Dec 82.
1.3.7Codes for the Identification of Hydrologic Units in the United States and Caribbean Outlying Areas, 1983, FIPSPUB 103, 15 Nov 83; also ANSI/X3.145-1986.
1.3.8Computer Graphics Metafile (CGM), 1987, FIPSPUB 128, 16 Mar 1987; also ANSI/X3.122-1986; also ISO 8632-1987.
1.3.9Congressional Districts of the United States, 1969, FIPSPUB 9, 14 Nov 69.
1.3.10Counties, and County Equivalents of the States of the United States and District of Columbia, 1979, FIPSPUB 679.
1.3.11Countries, Dependencies, Areas of Special Sovereignty and their Prin Administrative Division, 1984, FIPSPUB 1084.
1.3.12Database language SQL, 1986, FIPSPUB 127; also ANSI/X3.135-1989 and ANSI/X3.168-1989
1.3.13Federal Geodetic Control Committee, 1984, Standards and Specifications for Geodetic Control Networks. Rockville, Maryland, Federal Geodetic Control Committee GPO\_021\_9, 29 pp.
1.3.14Guideline for Implementation of ANSI Codes for the Implementation of Names of Countries, Dependencies and Areas of Special Sovereignty, 1983, FIPSPUB 104-1, 12 May 86.
1.3.15Guideline: Codes for Names of Populated Places, Primary County Divi, Other Locational Entities in the United States, 1983, FIPS5587.
1.3.16Information processing -- Procedures for Registering of Graphical Items, ISO Technical Report 9973, 1988.
1.3.17Metropolitan Statistical Areas, 1984, FIPSPUB 884.
1.3.18National Zip Code and Post Office Directory, U.S. Postal Service Publication 65.
1.3.19Programmers' Hierarchical Interactive Graphics System (PHIGS), 1988, FIPSPUB 153, 14 Oct 88; also ANSI/X3.144-1988 and ANSI/X3.144-1-1988.
1.3.20Power Plant Identification: Recommended Practice, 1983, IEEE 803 IEEE 803A\-1983.
1.3.21Representation of Geographic Point Locations for Information Inter, 1986, FIPSPUB 7086; also ANSI/X3.61-1986.
1.3.22Representations of Local Time of the Day for Information Inter, 1979, FIPSPUB 58-1, 27 Jan 88; also ANSI/X3.43-1986.
1.3.23Representations of Universal Time, Local Time Differentials, and United States Time Zone References for Information Interchange, 1979, FIPSPUB 59, 1 Feb 79; also ANSI/X3.51-1975.
1.3.24Specification for a Data Descriptive File for Information Inter(DDF), 1986, ANSI/ISO 8211123, 19 Sep 86.
1.3.25Codes for Identification of the States, District of Columbia and Outlying Areas of the United States, 1970, FIPSPUB 570.
1.3.26Stem, J., and T. Vincenty, 1987, The 1983 State Plane Coordinate, NOS Technical Manual NOS\par
1.3.27Defense Mapping Agency, 1990, Datums, Ellipsoids, Grids and Grid Reference Systems, DMA Technical Manual 83558.1, edition 1.
1.3.28Unrecorded Magnetic Tape for Information Interchange, ANSI X3.4-1983
1.4 Definitions
The following terms are used in the definitions of concepts essential to this standard. The concepts for which this standard provides normative definitions appear in section 2, Spatial Data Concepts; section 3, Spatial Data Quality; and section 4, General Specification. An informative list of all defined terms is contained in annex E.
1.4.1Accuracy\_closeness of results of observations, computations, or estimates to the true values or the values accepted as being true.
1.4.2Altitude - Elevation above or below a reference datum, as defined in FIPSPUB 70-1; the z-value in a spatial address. See also elevation.
1.4.3Control (mapping)\_system of points with established horizonand verti positions that are used as fixed referenin positionand relating map features.
1.4.4Coordinates\_of numbers expressing horizontal distances along orthogonal axes; alternatively, triplets of numbers measurhorizontal and vertical distances.
1.4.5Data base\_subject information stored as a volume set, volume, file set, or file.
1.4.6Data element\_logically primitive item of data.
1.4.7Digital encoding - To convert to a form that can be operated upon by electronic computer as binary digits.
1.4.8Elevation - Conforming to FIPSPUB 70-1, the term "altitude" is used in this standard, rather than the common term elevation, for the z-value in a spatial address.
1.4.9Field\_of one or more related subfields. It may contain part or all of a module field. It does not contain parts of two or more module fields.
1.4.10Field name\_name associated with a field.
1.4.11File\_identifiable collection of zero or more related record. It may contain part of, or all of one or many modules.
1.4.12File set\_identifiable collection of zero or more related files.
1.4.13Geocodes\_system of encoding used to represent an exhauslist of a class of spatial features (usually applied to political units).
1.4.14Implementation method\_method of encoding data content and data structure to accomplish a transfer between dissimilar computer systems without loss of content, meaning, or structure.
1.4.15Map - A spatial representation, usually graphic on a flat sur, of spatial phenomena.
1.4.16Media - The physical devices used to record, store, and (or) transmit data.
1.4.17Media record - A physical unit of data. The characteristics of a record and its means of delimitation are defined by standards specific to each given medium.
1.4.18Misclassification Matrix\_of an attribute accuracy test given in the form of a row by column contingency table (crosstabu) sometimes called a classification error matrix. The rows reprethe interpretation tested and the columns represent the verificaassumed to be correct. The diagonal elements represent the correct classwhen the matrix is square and the rows and colare strictly comparable. The remaining elements can be treated rowas errors of commis, and columnas errors of omission.
1.4.19Module\_logical collection of module records.
1.4.20Module field - A defined set of one or more module subfields in a Spatial Data Transfer.
1.4.21Module record - A defined set of one or more module fields in a Spatial Data Transfer.
1.4.22Module specification\_meaning, identification, order re, and data structure requirements for data belonto the module.
1.4.23Module subfield - A logical construct defining a single data element in a Spatial Data Transfer.
1.4.24Primitive - The quality of not being subdivided; atomic.
1.4.25Quality\_essential or distinguishing characteristic necessary for spadata to be fit for use.
1.4.26Quality overlay\_collection of points, lines, and areas orto represent quality information for another set of map information. An overlay describing lineage may be termed a source data index; a posiaccuracy overlay may be termed a reliability diagram.
1.4.27Record\_implementationconstruct that consists of an identifiable collection of one or more related fields.
1.4.28Representation - Graphical symbolization of a spatial object.
1.4.29Resolution\_minimum difference between two independently measured or computed values that can be distinguished by the measurement or analy method being considered or used.
1.4.30Spatial data transfer\_collection of related modules.
1.4.31Subfield - A physical area containing, or logical construct defining, a single data element.
1.4.32Transfer construct\_volume set, volume, file set, file, mod, module record, module field, module subfield, field, subfield, record, or media record.
1.4.33Transformation\_computational process of converting a position from one coordinate system to another.
1.4.34Volume\_mediaconstruct consisting of an identifiable collection of part of or all of one or more files. A volume is a discrete interconstruct such as a unit of dismountable media or a single online session.
1.4.35Volume set\_mediaconstruct consisting of an idencollection of one or more volumes containing a single file set.
2 Spatial Data Concepts
The basis of SDTS is a model of spatial data sufficientgeneral so that any user data model can be accepted.
2.1 Conceptual Model
The SDTS conceptual model has three parts: a model of spatial pheno, a model of the spatial objects used to represent phenomena, and a model of spatial features that explains how spatial objects and spatial phenomena are related (see also annex A).
The following terms define the parts of the model.
(a) Phenomenon. A fact, occurrence, or circumstance. Route 10, George Washington National Forest, and Chesterfield County are all phenomena.
(b) Classification. The assignment of similar phenomena to a common class. An individual phenomenon is an instance of its class. Route 10 is an instance of the class road.
(c) Generalization. A process in which classes are assigned to other classes. The general class includes all the instances of the conclasses. Sewers are included in the more general class of utilities.
(d) Aggregation. The operof constructing more complex phenomena out of com phenomena. A lock is an aggregation of walls, gates, and a reservoir.
(e) Association. The assignment of phenomena to sets, using criteria different from those used for classification. Concrete roads may be associated with concrete sewers, concrete locks, and other phenomena constructed of concrete.
2.1.1 Model of Spatial Phenomena
SDTS transfers information about phenomena that are defined in space and time and are described by using a fixed location-- spatial phenomena. All phenomeare defined as belonging to a class of phenomena. (Smith's Farm belongs to Farm.) A characteristic of such a class is called an attribute. (Area is an attribute for Farm.) An atvalue is a specific quantity or quality of the attribute assigned to a phenomenon in that class. (Smith's Farm has an Area of 160 acres.)
Whether a given phenomenon belongs to a class is determined by the definition of the class. The definition consists of a statement about characteristics that all members of the class have in common. It also includes characteristics that distinguish the class from other classes. These definitional characare necessary and sufficient conditions for classifying some phenomena into the class and excluding others. The data collector may define which classes of phenomena are of interest. Those classes of phenomena are called entity types, and the individual phenomena are called entity instances.
Certain attributes are identified with each class. The attributes of a class include key attributes. The combination of values of the key attributes forms a unique identifier for each entity instance.
Entity instances may be aggregated into instances of a different type of entity.
Entity types can be generalized into themes based on definitional characshared by more than one class. A theme can also have its own attributes, including name.
Associations of entity instances are defined in terms of characteristics other than those used to define an entity type. A common association is the spatial domain, which groups all entity instances having coordinates within a specirange. Another useful association is temporal domain. SDTS represents entity instances as static, without temporal dimension. However, values of a temporal attribute such as Age may be assigned to entity instances and used to associate them into sets with a common extent in time.
A relationship is a special case of an association. A relationship exists between entity types. A relationship instance is an association between entity instances with a unique relationship value.
2.1.2 Model of Spatial Objects
Entity instances have a digital representation. That digital representation consists of one or more spatial objects. A spatial object may be an aggregaof other spatial objects, not all of which necessarily represent an entity instance. A spaobject that represents all of a single entity instance is an entity object. It may be classified into an entity object class. Entity objects have generalizations and associations as well: the representaof an entity theme is an object theme, and an entity spatial domain, an object spatial domain. In general, the correspondence between entity instance and entity object is paralleled by all characteristics of entities and objects.
Entity objects have locaattributes (spatial ad), nonlocational attributes, and relationships (topology). The attributes and relationships of entity objects need not be as extensive as those of their corresponding entity instances. The key attributes used to distinguish a particular entity instance may not be present in the actual transfer; instead, the entity object record identifier may be the only way to distinguish between instances.
Spatial objects may have attributes independently of whether they are entity objects or not. All objects may be classified, aggregated, and associated in the same general manner that entity instances may be.
This standard defines a set of simple spatial objects. These simple spatial objects are either primitive ob(not aggregated from any other objects), or aggregated only from spatial objects belonging to different classes (poly, for example, are not aggregated from polygons, only from rings, chains or strings). The only exception is the composite object. Composite spatial objects may be aggregated from simple objects or from other composites.
Spatial objects are classified into module types, one of the basic building blocks of the standard. Once defined, modules may be associated into sets by spatial domain, temporal domain, data quality, security requirements, topolorelationships, or any other criteria.
2.1.3 Model of Spatial Features
The terminology in geographic data handling has traditionally not distinbetween the phenomenon and its representation, referring to both as features. For the sake of clarity, a feature is defined as the combination of the phenomenon and its representation. A feature instance consists of an entity inand the entity object that represents it, and belongs to a feature type.
Table 1 Feature Instance
An instance of a defined entity and its object representation
Entity instance Entity object
A spatial phenomenon of a A digital representation of
defined type. an entity instance.
2.2 Classification and Intended Use of Objects
This standard defines three classes of spatial objects. Two classes are defined explicitly: geometry only and geometry and topol. The third class, topology only, can be defined implicitly by removing the coordinates from the geometry and topology class of objects. The intended use of these three classes of objects is as follows:
(a)Geometry only-drawing, display, and geometrically defined operations.
(b)Geometry and topology-vector data structures that use geometric drawing and topological operations.
(c)Topology only-certain analytical opera.
The relationship between the explicitly defined classes of objects and their intended use is specified in table 2.
Table 2 Intended use of defined spatial objects ----------------------------------------------------------- Intended use --------------------------------------------- Number of Geometry Geometry and dimensions only (G) topology (GT) ---------- -------- ------------- zero dimensions point*node one dimension line segment link string chain* arc G-ring GT-ring two dimensions G-polygon GT-polygon* pixel grid cell ----------------------------------------------------------- *There are additional special objects that are based on the point, the chain, and the polygon.
2.3 Definition of Spatial Objects
The spatial objects specified in 2.3.1 through 2.3.3 represent the simple objects required for digital spatial processing which can be used to construct composite objects that represent a more complex realization of the real world. The following definare valid in planar and non-planar, Euclidean geometry, as well as simple curved surfaces such as the sphere or ellipsoid. Each object type is associated with one or more two-character object representation codes. Use of the codes is explained in 5.6 and 5.7 (see also tables 31 and 37).
Composite objects (object representation code FF) shall be constructed from the simple objects by aggregation. Specifically, a composite object consists of one or more other objects, either simple or composite.
2.3.1 Definition of ZeroSpatial Objects
2.3.1.1 Point (NP). A zeroobject that specifies geometric location. One coordinate pair or triplet specifies the location.
The three point definitions that follow are special implemenof the general case:
2.3.1.1.1 Entity point (NE). A point used for identifying the location of point features (or areal features colto a point), such as towers, buoys, buildings, places, etc.
2.3.1.1.2 Label point (NL). A reference point used for dismap and chart text (e.g., feature names) to assist in feature identification.
2.3.1.1.3 Area point (NA). A representative point within an area usually carrying attribute information about that area.
2.3.1.2 Node (NO, NN). A zeroobject that is a topological junction of two or more links or chains, or an end point of a link or chain.
2.3.2 Definition of One-dimensional Spatial Objects
A line is a generic term for a oneobject.
2.3.2.1 Line Segment . A direct line between two points.
2.3.2.2 String (LS). A connected nonbranching sequence of line segments specified as the ordered sequence of points between those line segments. Note: A string may inteitself or other strings.
2.3.2.3 Arc (AC, AE, AU, AB). A locus of points that forms a curve that is defined by a mathematical expression.
2.3.2.4 Link (LQ). A topological connection between two nodes. A link may be directed by ordering its nodes.
2.3.2.5 Chain . A directed nonbranching sequence of nonintersecting line segments and (or) arcs bounded by nodes, not necessarily distinct, at each end.
The following three objects are special cases of chain. They share all characteristics of the general case as defined above.
2.3.2.5.1 Complete chain (LE). A chain that explicitly references left and right polygons and start and end nodes. It is a component of a two-dimensional manifold (2.3.4.5.2).
2.3.2.5.2 Area chain (LL). A chain that explicitly references left and right polygons and not start and end nodes. It is a component of a two-dimensional manifold.
2.3.2.5.3 Network chain (LW, LY). A chain that explicitly references start and end nodes and not left and right polygons. It is a component of a network (2.3.4.5.3).
2.3.2.6 Ring . A sequence of nonintersecting chains or strings and (or) arcs, with closure. A ring represents a closed boundary, but not the interior area inside the closed boundary.
2.3.2.6.1 G-ring (RS, RA, RM). A ring created from strings and (or) arcs.
2.3.2.6.2 GT-ring (RU). A ring created from complete and (or) area chains.
2.3.3 Definition of TwoSpatial Objects
An area is a generic term for a bounded, continuous, two-dimensional object that may or may not include its boundary.
2.3.3.1 Interior Area . An area not including its boundary.
2.3.3.2 G-Polygon (PG). 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.
2.3.3.3 GT-Polygon (PR, PC). An area that is an atomic two-dimensional component of one and only one two-dimensional manifold. The boundary of a GT-polygon may be defined by GT-rings created from its bounding chains. A GT-polygon may also be associated with its chains (either the bounding set, or the complete set) by direct reference to these chains. The complete set of chains associated with a GT-polygon may also be found by examining the polygon references on the chains.
2.3.3.3.1 Universe polygon (PU, PW). Defines the part of the universe that is outside the perimeter of the area covered by other GT-polygons ("covered area") and completes the two-dimensional manifold. This polygon completes the
2.3.3.3.2 Void polygon (PV, PX). Defines a part of the two-dimensional manifold that is bounded by other GT-polygons, but otherwise has the same characteristics as the universe polygon. The geometry and topology of a void polygon are those of a GT-polygon. Attribution of a void polygon may not exist, or may be substantially different from the attribution of the covered area.
2.3.3.4 Pixel. A twopicture element that is the smallest nondivisible element of a digital image (2.3.4.1).
2.3.3.5 Grid Cell . A twoobject that represents the smallest nondivisible element of a grid (2.3.4.2).
2.3.4 Definition of Aggregate Spatial Objects
Certain aggregate spatial objects must be defined to provide context for many of the simple objects defined above. These aggregate objects are necessary for the definition of (a) raster objects (grid, image, layer, and raster) and (b) topology objects (three types of graphs, with or without geometry).
2.3.4.1 Digital Image (GI, GJ, GK, GM). A two-dimensional array of regularly spaced picture elements (pixels) constituta picture.
2.3.4.2 Grid (GI, GJ, GK, GM). A set of grid cells forming a regular, or nearly regular, tesselof a surface. The tessellation is regular if formed by repeating the pattern of a regular polygon, such as a square, equilateral triangle, or regular hexagon. The tessellation is nearly regular if formed by repeating the pattern of an "almost" regular polygon such as a rectangle, non-square paral, or non-equitriangle.
2.3.4.3 Layer . An areally distributed set of spatial data representing entity instances within one theme, or having one common attribute or attribute value in an association of spatial objects. In the context of raster data, a layer is specifically a two-dimensional array of attribute values aswith all or part of a grid or image.
2.3.4.4 Raster . One or more overlapping layers for the same grid or digital image.
2.3.4.5 Graph . A set of topologically interrelated zero-dimensional (node), one-dimensional (link or chain), and sometwo-dimensional (GT-polygon) objects that conform to a set of defined constraint rules. Numerous rule sets can be used to distinguish different types of graphs. Three such types, planar graph, network, and two-dimensional manifold, are used in this standard. All three share the followrules: each link or chain is bounded by an ordered pair of nodes, not necessarily distinct; a node may bound one or more links or chains; and links or chains may only intersect at nodes\par
Planar graphs and networks are two specialized types of graphs, and a two-dimensional manifold is an even more specific type of planar graph.
2.3.4.5.1 Planar graph . The node and link or chain objects of the graph occur or can be represented as though they occur upon a planar surface. Not more than one node may exist at any given point on the surface. Links or chains may only intersect at nodes.
2.3.4.5.2 Two-dimensional manifold . A planar graph and its associated two dimensional objects. Each chain bounds two and only two, not necessarily dis, GT-polygons. The GT-polygons are mutually exclusive and completely exhaust the surface.
2.3.4.5.3 Network . A graph without two dimensional objects. If projected onto a two-dimensional surface, a network can have either more than one node at a point and (or) interlinks or chains without corresponding nodes.
3 Spatial Data Quality
The Data Quality Report consists of five portions covering lineage, positional accuracy, attribute accuracy, logical consistency, and completeness. Each portion of the report shall contain reference to temporal information.
3.1 Lineage
The lineage portion of a quality report shall include a description of the source material from which the data were derived and the methods of deriva, including all transformations involved in producing the final digital files. The description shall include the dates of the source material and the dates of ancillary information used for update. The date assigned to a source shall reflect the date that the information corresponds to the ground; however, if this date is not known, then a date of publication may be used, if declared as such.
Any data base created by merging information obtained from distinct sources shall be described in sufficient detail to identify the actual source for each element in the file. In these cases, either a lineage code on each element or a quality overlay (source data index, etc.) shall be required.
The lineage portion shall also include reference to the specific control information used. Control from the National Geodetic Reference System shall be identified according to identifiers in that system, while other points used for control shall be described with sufficient detail to allow recovery.
The lineage portion shall describe the mathematical transformations of coordinates used in each step from the source material to the final product. The locations of any registration points for coordinate transformations shall be given. The methods used to make coordinate transformations shall be documented. To fulfill this standard, it is acceptable to make reference to separate documentation for the coordinate transformation algorithm used, but the specific parameters applied shall be described for the particular case. Documentation of a transformation algorithm shall include the nature of computational steps taken to avoid loss of digits through roundoff and shall include a set of sample computations including numerical values of coeffito confirm equivalence of transformations. The documentation of a transformation algorithm shall be available on request by a user obtaining digital data even if that user is not licensed to use the particular software.
3.2 Positional Accuracy
The quality report portion on positional accuracy shall include the degree of compliance to the spatial registration standard (see section 4.1.3.5). Quality of control surveys shall be reported by using the procedures established in the geodetic standard. If a separate control survey has been used, it shall be described in the standard form, even if results fall below the recognized classification thresholds.
Descriptions of positional accuracy shall consider the quality of the final product after all transformations. The information on transformations forms a part of the lineage portion of the quality report.
The report of any test of positional accuracy shall include the date of the test. Variations in positional accuracy shall be reported either as additionattributes of each spatial object or through a quality overlay (reliability diagram).
Measures of positional accuracy may be obtained by one of the following optional methods.
3.2.l Deductive Estimate . Any deductive statement based on knowledge of errors in each production step shall include reference to complete calibration tests and shall also describe assumptions concerning error propagation. Results from deductive estimates shall be distinguished from results of other tests.
3.2.2 Internal Evidence . Federal Geodetic Control Committee procedures will be used for tests based on repeated measurement and redundancy such as closure of traverse or residuals from an adjustment.
3.2.3 Comparison to Source . When using graphic inspection of results ("check plots"), the geometric tolerances applied shall be reported and the method of registration shall also be described. Use of check plots shall be included in the lineage portion.
3.2.4 Independent Source of Higher Accuracy . The preferred test for positional accuracy is a comparison to an independent source of higher accuracy. The test shall be conducted using the rules prescribed in the "ASPRS Accuracy Standards for Large Scale Maps" (see 1.3.3). When the dates of testing and source material differ, the report shall describe the procedures used to ensure that the results relate to positional error and not to temporal effects. The numerical results in ground units, as well as the number and location of the test points, shall be reported. A statement of compliance to a particular threshold is not adequate in itself. This test may only be applicable to wellpoints.
3.3 Attribute Accuracy
Accuracy assessment for measures on a continuous scale shall be performed using procedures similar to those used for positional accuracy (providing a numerical estimate of expected discrepancies). The report of a test of attribute accuracy shall include the date of the test and the dates of the materials used. In the case of different dates, the report shall describe the rates of change in the phenomena classified. Spatial variations in attribute accuracy may be reported in a quality overlay.
Accuracy tests for categorical attributes may be performed by one of the following methods. All methods shall make reference to map scale in interclassifications.
3.3.l Deductive Estimate . Any estimate, even a guess based on experience, is permitted. The basis for the deduction shall be explained. Statements such as "good" or "poor" should be explained in as quantitative a manner as possible.
3.3.2 Tests Based on Independent Samples . A misclassification matrix shall be reported as counts of sample units crosstaby the categories of the sample and of the tested material. The sampling procedure and the location of sample units shall be described.
3.3.3 Tests Based on Polygon Overlay . A misclassification matrix shall be reported as areas. The relationship between the two maps shall be explained; as far as possible, the two sources should be independent and one should have higher accuracy.
3.4 Logical Consistency
A report on logical consistency shall describe the fidelity of relationships encoded in the data structure of the digital spatial data. The report shall detail the tests performed and the results of the tests.
3.4.l Tests of Valid Values . Tests for permissible values may be applied to any data structure. Such a test can detect gross blunders, but it does not ensure all aspects of logical consistency.
3.4.2 General Tests for Graphic Data . A data base containing lines may be subjected to the following general questions:
Different tests may be applied to address these questions, but the quality report shall contain a description of the tests applied or a reference to documentation of the software used. The report shall state whether all inconsistencies were corrected or it shall detail the remaining errors by case.
3.4.3 Specific Topological Tests . For exhaustive areal coverage data transmitted as chains or derived from chains, it is permissible to report logical consistency as "Topologically Clean" under the condition that an automated procedure has verified the following conditions:
(a)All chains intersect at nodes. Use of exact case or tolerance shall be reported.
(b)Cycles of chains and nodes are consistent around polygons. Or, alternatively, cycles of chains and polygons are consistent around nodes.
(c)Inner rings embed consistently in enclosing polygons.
The quality report shall identify the software (name and version) used to verify these conditions.
3.4.4 Date of Test . The report shall include the date on which the tests were applied. If corrections and modifications have occurred after the test for logical consisten, the quality report shall indicate how the new information was checked for logical consistency.
3.5 Completeness
The quality report shall include information about selection criteria, definitions used and other relevant mapping rules. For example, geometric thresholds such as minimum area or minimum width shall be reported.
In encoding spatial entities, standard geocodes (such as described in the FIPS codes for States, counties, municipalities, and places) shall be employed if possible. Deviations from standard definitions and interpretations shall be described.
The report on completeness shall describe the relationship between the objects represented and the abstract universe of all such objects. In particular, the report shall describe the exhaustiveness of a set of features. Exhaustiveness concerns spatial and taxonomic (attribute) properties, both of which can be tested. A test for spatial completeness can be obtained from topological tests for logical consistency described in 3.4.3. Tests for taxonomic completeness operate by comparison of a master list of geocodes to the codes actually appearing in the file. The procedures used for testing and the results shall be described in the quality report.
4 General Specification
This section contains general concepts and specifications that pertain to the transfer module specifications of section 5. It also specifies the general elements of an implementation and the relationships of the logical constructs of the data models to the general elements of a detailed implementation as well as general constraints on implementations. This section consists of two main parts: (1) the underlying models and (2) specific transfer module specification conventions used in section 5. This section also contains specifications for the relationships of the logical constructs of the model to the general constructs of an implementation.
4.1 Spatial Data Transfer Models
Three data models-- the conceptual model, the data structure model, and the transfer model-- form the basic foundation for the process of converting from a user representation of a spatial entity to a corresponding digital object representation in a spatial data transfer.
4.1.1 The Conceptual Model of Spatial Data . This model describes the spatial objects, as well as the logical and topological relationships between the spatial objects and the captured spatial entities. This general model is object oriented and is also based on existing topological and graph models for spatial data. The conceptual model is presented in section 2 and more fully described in annex A.
4.1.2 The Data Structure Model . This model is used to express the spatial objects of the conceptual model in terms of transfer data structures. The data structures used in this transfer standard are based on the traditional relational and network models. Data structures viewed as spatial data structures are both the traditional vector and raster models. One or more data structures used in the transfer are encoded in the Profile Specification subfields of the Conformance field in the Identification module.
4.1.3 The Transfer Model . This model is used to express the logical constructs of the transfer form in terms of implementationconstructs. The implementation constructs are made operational by an implementation method. The implementation method selects one or more media and defines the constructs pertaining to those media.
The transfer model is defined in terms of its constructs and logical relationships. It deals with three types of transfer constructs: (1) logical constructs solely pertaining to this standard, (2) constructs relating to the implementation method, and (3) constructs solely pertaining to the transfer media. The three types are summarized in tables 3a and 3b. Logical characteristics of constructs are defined in 4.2 that have physical instances that are implementation and (or) medium dependent. Definitions for the corresponding physical constructs may be found in the implementation requirements of part 3 where additional constraints exist.
Table 3a Transfer constructs of this standard ------------------------------------------------------------ Construct Logical Implementation Media ----------- ------ ------------- ----- Spatial Data Transfer X X X Module X Module record X Module field X Module subfield X Subfield X Field X Record X File X X File setu X Volume X Volume set X Media record X ------------------------------------------------------------
Table 3b depicts the relationships of the logical constructs specified in part 1 of this standard to the implementation constructs of part 3 and to typical media constructs.
Table 3b Relationships between the transfer logical constructs, implementation constructs, and typical medium constructs ---------------------------------------------------------------- Logical Constructs Implementation Medium of this Standard Constructs Constructs ------------------ -------------- ---------- spatial data > file set > volume set transfer ^ ^ ^ ^ volume ^ ^ ^ ^ p module p>> file = file ^ ^ ^ ^ ^ ^ module record p>> record p>> media record ^ ^ ^ ^ module field p>> field ^ ^ ^ ^ module subfield = subfield ------------------------------------------------------------------ Note: B = A implies functional equivalence of A and B B > A implies A contains one of B B >> A implies A contains one or more of B B p>> A implies A contains part of, or one or more of B
The transfer model specifies relationships of the following basic types: (1) implicit relationships between constructs expressed through order and (2) explicit crossbetween constructs.
4.1.3.1 Ordering Concepts . An implementation of this standard shall preserve the meaning of the data including any logical associations required by this standard. The specifications require:
Order is the sequential arrangement of elements in a construct. In a data transfer, the reason for a sequential arrangement is that each element has an implied sequence number that serves to identify its participation in the construct, so that its structure can be preserved.
This standard does not impose general ordering requirements for transfer constructs with specific identification. In particular, most modules, which are assigned unique module names, and fields and subfields that carry names assigned by the standard, need not occur in any specific order in the context in which they are used. However, the order of presentation in the standard is recommended as a default order.
The standard imposes ordering requirements on unnamed or nonuniquely named transfer constructs such as elements in repetitive lists resulting from repeated fields and subfields. This ordering can be imposed on repeated instances of fields or subfields to capture the structure of the data to be transferred in such a repetitive list. For example, repeated instances of the Spatial Address field containing point data for a line shall be encoded in a certain order and decoded in the same order to fully preserve the meaning of the line. Ordering can also be imposed on repetitive instances of two or more types of fields when elements of repetitive lists are correlated. Ordering requirements of this type are imposed on a field by field basis as set out in 4.1.3.3.3 and 4.2.3.3.
Wherever repetitive lists occur on which the standard does not impose any ordering requirements, a user of the standard may still encode the field instances in a significant order, and decode these instances in the same order, because any implementation shall preserve the order for a repetitive list. This is explicitly stated in 4.1.3.3.8, Preservation of Order.
4.1.3.2 BackusForm . For clarification, the BackusForm (BNF) is used to concisely express structure, relationships, and layout of the transfer constructs in this specification.
Each production rule has a left side (identifier) and a right side (expression) connected by the symbol "::=", meaning that the left side is replaced by or produces the right side. Terms in the right side either match other identifiers or are terminal symbols. Making substitutions using matching symbols in the production rules therefore leads to explaining the highest level identifier in terms of the lowest level terminal symbols. Other identifiers are intermediate, explaining the organization of the lower level symbols, and it is this expressive power of BNF that is used to define the organization of the transfer constructs in this standard. Most often the terminal symbols will actually be absent, but the production rules are presented in an indented form which indicates the levels of organization. The BNF used here is an extension from normal usage, where the order of the terms in the right hand side of the production rule implies a physical ordering of these terms (as characters in a sentence, for example). However, for data transfer, order may not be important at times, and the terms may be considered a set. When order is not important, the convention of separating the terms with a "," will be used.
The symbols used in the production rules have the following meaning:
Symbol Meaning
----- -------
::= is replaced by, produces, consists of
| exclusive or
[] term enclosed is optional (not used or used once)
{}term enclosed is used any number of times
(not used, used once, or used several times)
<>term enclosed is nonterminal
,exists together with (no order implied)
...indicates a repetitive list of similar items
4.1.3.3 Implicit Relationships between Constructs . The ordering relationships between the logical constructs of this standard in the transfer are designated in table 3b. This table also designates the relationships between the logical constructs and the implementation and media constructs.
4.1.3.3.1 Modules within a Spatial Data Transfer . Spatial data transfers may occur on sequential media where order is significant, or on random access media where, depending on the level of detail, order might not be significant. On a medium where order is significant, the Identification Module and the Catalog modules shall be the first modules in the sequence. Unless otherwise specified by the Catalog/Directory module, the remaining modules shall be organized in the order that they appear in section 5. When the Catalog/Directory module implies a different ordering, this default ordering for the remaining modules is not required. For random access media the Identification modules and Catalog modules shall be easily identifiable, preferably through file names that reflect the module type. Regardless of the type of media used, each global information module (see table 8 for a list of global module types) shall be contained in one or more separate files that contain only that module.
Modules may be included or omitted, with the following exceptions:
Data Dictionary/Definition and Data Dictionary/Domain modules may be separate and external to a transfer, but if separate, they must be uniquely referenced (by module name and version) and labeled as "external" in Catalog/Directory records. The separate Data Dictionary modules shall easily merge with SDTS transfer data which reference them (e.g. no module name conflicts, no file name conflicts, and only editing of the Volume and External subfields of the Catalog/Directory module records for the Data Dictionary/Definition and Data Dictionary/Domain modules).
Data Quality modules may be separate and external to a transfer, but if separate, they must be uniquely referenced (by module name and version) and labeled as "external" in Catalog/Directory records. In addition, external Data Quality modules shall have no records with foreign identifier fields. The separate Data Quality modules shall easily merge with SDTS transfer data sets which reference them (e.g. no module name conflicts, no file name conflicts, and only editing of the Volume and External subfields of the Catalog/Directory module records for the Data Quality modules).
4.1.3.3.2 Module Records within Modules . Module records should preferably occur in ascending sorted order, according to the module record identifier field. Module records representing spatial objects or relationships between components of spatial objects shall occur in the order dictated by the spatial data model (2.1.2).
4.1.3.3.3 Module Fields within Module Records . It is recommended that module fields within module records occur according to the sequence specified in section 5. Module fields may occur in a different order on a module by module basis, provided that each field is identified through the selected implementation method and that significant relationships between fields are preserved. Within a module, the ordering, type and number of types of fields shall be identical for each module record. Multiple Object Representation codes are allowed within the same module (see 5.6 and 5.7).
Module fields within each module description are arranged so that within a given module record the primary module field will not repeat, whereas the instances of the secondary module field may repeat a fixed or variable number of times.
The structure of a module with a primary field "Primfield" and secondary fields "Secfield1, Secfield2,...,Secfieldn" is expressed as:
<module record>::= <Primfield>, {<Secfield1>}, {<Secfield2>},
..., {<Secfieldn>}
The rules for the case where a field is absent are given in 4.1.3.3.5.
The order of repetition of a module field can be significant. Moreover, the order of repetition can be correlated with the order of repetition of another field. The following three classes are therefore recognized:
A number of modules in this specification have a simple relational structure in which all subfields may be represented as an nwithin a single implementation field. A module is said to have a relational structure when either one of the following conditions exists:
<module record> ::=<Primfield>
<Primfield>::=<Subfield1>,
[<Subfield2>],
.
.
[<Subfieldn>]
where the subfields are optional according to the rules of 4.1.3.3.6.
<module record>::= <Primfield>, <Secfield1>, [<Secfield2>],
..., [<Secfieldn>]
where the optionality of the fields is according to the specifications of 4.1.3.3.5.
4.1.3.3.5 Optionality of Module Fields . Module fields may be included or excluded. Both inclusion and exclusion may be either mandatory or optional, depending on the context for the use of the fields. When included, field contents may be null or may not be null. The following rules apply. Unless stated otherwise in a particular field description in the module specification table, module fields may be omitted provided that fields can be properly identified in the decoding process without additional external information not contained in the transfer. This can be satisfied with the current implementation method that uses tagged fields. The meaning of missing module fields is specified in 4.1.3.3.9. Mandatory fields shall not be null. The mandatory absence of fields shall have the meaning of "undefined, not relevant," as specified in 4.1.3.3.9. Mandatory fields in mandatory modules shall never be absent or null.
4.1.3.3.6 Optionality of Module Subfields . Module subfields may be included or excluded. Both inclusion and exclusion may be either mandatory or optional, depending on the context for the use of the subfields. When included, subfield contents may be null or may not be null. The following rules apply. Unless stated otherwise in a particular subfield description in the module specification table, module subfields may be omitted provided that subfields can be properly identified in the decoding process without additional external information not contained in the transfer. This can be satisfied with the current implementation method that uses labeled subfields. The meaning of missing module subfields is specified in 4.1.3.3.9. Mandatory subfields shall not be null. The mandatory absence of subfields shall have the meaning of "undefined, not relevant," as specified in 4.1.3.3.9. Mandatory subfields in mandatory modules shall never be absent or null.
4.1.3.3.7 Extra module fields and subfields shall not be added, except under private agreement. The names and mnemonics used for any additional fields and subfields, under such an agreement, shall not duplicate any of those specified in the standard.
4.1.3.3.8 Preservation of Order . For a repetitive list, the implementation shall preserve the order as received from the sender, and on output, preserve order as found on the media.
4.1.3.3.9 Nulls and Defaults . The definition and the method for implementing null values is implementation dependent, and for the user-defined fields and subfields will be application specific. Null values in fields and subfields may be indicated in two ways: (l) through the structure imposed on a transfer's contents by the implementation, and (2) by setting aside certain values in the domain of the specified field or subfields contents as null values. Structure indicated null values may be manifest in two ways: (l) through the absence of fields or subfields, and (2) through empty fields or subfields.
For the purposes of this standard, the default method for indicating null values shall be through the structure imposed by the implementation. Empty fields and subfields shall have the meaning of "missing, relevant but not known," while missing fields and subfields shall have the meaning of "undefined, not relevant." If this default option for implementing null values is not feasible, the user may define alternative meanings to missing and empty fields or subfields, or may opt to implement a different null scheme by designating domain values as null values. In this case, the user shall fully describe the selected method in the data quality Logical Consistency module, and if applicable, shall specify the designated null domain values in a Data Dictionary/Domain module.
The fields and subfields that may be omitted, and when omitted have the meaning of "undefined, not relevant," are specified in 4.1.3.3.5 and 4.1.3.3.6.
A subfield may have an associated default value that must be assumed in effect when the subfield is omitted from the transfer. In this specification, subfields with default values are flagged appropriately and the default values are indicated. Values of omitted subfields without a preassigned default value are assumed to be of the null type "undefined, not relevant," unless otherwise specified in the Logical Consistency module.
4.1.3.4 Explicit Relationships between Constructs . The following relationships between constructs are explicitly encoded in the spatial data transfer. The relationships described are not only restricted to relationships between transfer constructs, but also include other elements of the transfer such as spatial addresses and attributes.
4.1.3.4.1 Modules, Records, Files, and Volumes . As indicated in table 3b, a module record may occur in a part of, in all of, or in more than one media record, file, or volume. Global modules may occur in all of or in more than one media file, but shall not share the same media file with other modules. The Catalog/Directory module may be used to specify which records, files, and volumes are associated with a particular module. Each Catalog/Directory module record shall have a single field with subfields containing identifiers for module, record, file, and volume. More than one catalog module record may be used to express the relationships between a specific module and its associated media records, files, and volumes.
4.1.3.4.2 Module Cross-References . Certain modules can reference, have bearing on, or relate to other modules. These relationships are specifically expressed in the Catalog/Crossmodule. Each module record in this module shall have one field consisting of four subfields, containing module names and types for two modules.
4.1.3.4.3 Modules and Spatial Domain . Relationships between modules and spatial domain, map, theme and aggregate object (e.g., graph) are expressed through the Catalog/Spatial Domain module.
4.1.3.4.4 Module Record Cross-References . Explicit relationships between module records are established through module record identifiers and foreign identifiers.
Module Record Identifiers
A module record identifier shall provide a unique identification for the record in the entire transfer. The identifier has two subfields: (1) Module Name and (2) Record ID. The module record identifier exists as the first two subfields of the primary module field associated with the module record. The record number shall be unique within the module.
Foreign Identifiers
References to other records from a given record shall be made through foreign identifiers. Foreign identifiers consist of three subfields: (1) Module Name, (2) Record ID, and (3) Usage Modifier (see 5.1.2). Module Name and Record ID are mandatory subfields corresponding to the mandatory module record identifier fields with matching names. The Usage Modifier subfield is optional and has no equivalent module record identifier subfield.
4.1.3.4.5 Wildcard Characters in References . For the purpose of eliminating multiple module reference records and multiple foreign identifiers for those cases where the reference model is one, the use of wildcard characters is allowed where indicated in a module domain description table in section 5. Wildcard characters are also used in attribute definition relationships. Except for the Record Identifier subfield, the subfield containing wildcard characters must be alphanumeric. When so indicated, the following rules apply:
The use of wildcard characters in the Module Name subfield of a foreign identifier field is not permitted except in global modules.
4.1.3.5 Spatial Registration . The standard includes a number of mechanisms by which spatial data contained in the transfer can be related to locations on the Earth's surface. The primary goal of this standard is to promote the transfer of data for which all spatial addresses have a known (and expressed) relationship to latitude and longitude. However, for certain types of applications this might not always be possible or meaningful. The standard therefore recognizes three spatial registration conformance levels. A transfer with conformance levels 1 or 2 shall contain data that have a specified relationship to latitude and longitude, while this relationship shall remain unspecified for a level 3 transfer.
The known relationship to latitude and longitude is expressed through the use of an external coordinate reference system, of which the three most widely used in the United States are (listed in order of preference): Latitude and Longitude (also termed Geographic), Universal Transverse Mercator/Universal Polar Stereographic (UTM/UPS) Grid Systems, and State Plane Coordinate Systems (metric). These systems are mathematically interconvertible, on a point by point basis, and are also officially recognized by many mapping and surveying agencies of the Federal and State governments. This standard allows the use of any of these preferred systems as the external coordinate reference system for spatial registration conformance level 1, and no other system shall be used for this conformance level.
Any other external reference system may be used for registration conformance level 2, in which case the standard requires a full disclosure of the reference system, its projection and parameters. The spatial registration conformance levels are summarized as:
Level 1 Relationship with latitude and longitude known through the use of one of the preferred external reference systemsIn addition to the latitude-longitude system and the specified external reference system, the standard includes two additional reference systems: the internal reference system and the scan reference system. The four types of spatial referencing systems are defined as follows:Level 2 Relationship with latitude and longitude known through the specification of an external reference system and its projection and parameters
Level 3 Unspecified relationship with latitude and longitude
The spatial address refers to the geographic point location of an object. It is used to define the position of a point (in a defined coordinate system) that can be on, above, or below the Earth's surface. A point location in any one of the described reference systems is specified by means of a spatial address. The scan reference system for raster data is a special case, because it requires transformation from a row-column position to a spatial address in the internal reference system.
The method of spatial addressing is specified in 4.1.3.5.1. This is followed by the requirements for constructing spatial addresses in any of the three preferred external reference systems. These requirements apply directly to the external spatial addresses of the Registration and Spatial Domain modules only. Otherwise, it is upon transformation of internal reference system spatial addresses to external system addresses that the external addresses shall meet the stated requirements.
Further information concerning the preferred external spatial reference systems is provided in annex C.
4.1.3.5.1 Spatial Address and Coordinate Coding . This standard only allows for spatial addressing techniques corresponding to the conventional method of Cartesian coordinates. Within this method, different numbers of subfields (depending on whether or not a Z component is included) may be needed to form a complete spatial address. The specification for a spatial address is given in 5.1.1. The type of address is identified in 5.2.4.1. Specifications for altitude data are provided in 4.1.3.5.5.
Internal to the standard, the components of the spatial address are subfields with the labels X, Y, and Z. The Z component of the spatial address shall always correspond to the Z component of the selected external reference system. The X component of the spatial address may be assigned to either one of the horizontal components of the selected external spatial reference system, and similarly the Y component. The selected assignment shall be communicated through the Spatial Address Component Label subfields in the Internal Spatial Reference Module.
4.1.3.5.2 Latitude and Longitude . Latitude and longitude are angular quantities and shall be expressed as decimal fractions of degrees. Whole degrees of latitude shall be represented by a twodecimal number ranging from 0 through 90. Whole degrees of longitude shall be represented by a threedecimal number ranging from 0 through 180. When a decimal fraction of a degree is specified, it shall be separated from the whole number of degrees by a decimal point.
Latitudes north of the equator shall be specified by a plus sign (+), or by the absence of a (-) sign, preceding the two digits designating degrees. Latitudes south of the Equator shall be designated by a minus sign (the two digits designating degrees. A point on the Equator shall be assigned to the Northern Hemisphere.
Longitudes east of the prime meridian shall be specified by a plus sign (+), or by the absence of a (-) sign, preceding the three digits designating degrees of longitude. Longitudes west of the meridian shall be designated by minus sign (the three digits designating degrees. A point on the prime meridian shall be assigned to the Eastern Hemisphere. A point on the 180th meridian shall be assigned to the Western Hemisphere.
Any spatial address with a latitude of +90 (90) or -90 degrees will specify the position at the North or South Pole, respectively. The component for longitude may have any legal value.
4.1.3.5.3 Universal Transverse Mercator/Universal Polar Stereographic Grid Systems .
4.1.3.5.3.1 Universal Transverse Mercator Grid System. The Universal Transverse Mercator Grid System shall be used for spatial addresses between 84 degrees North and 80 degrees South Latitude. The first graphics character of the Zone Number Subfield in the External Spatial Reference module record shall be a code to indicate the hemisphere in which the point is located. A plus sign (+) shall be used to indicate the Northern Hemisphere, and a minus sign (indicate the Southern Hemisphere. The remainder of the subfield shall contain the zone number indicating the 6 degree longitudinal band in which the point is located (01, 02, ...60). The unit of measurement for both Northing and Easting shall be the meter.
4.1.3.5.3.2 Universal Polar Stereographic Grid System. The Universal Polar Stereographic Grid System shall be used in place of the Universal Transverse Mercator Grid System whenever the point is located north of 84 degrees North or south of 80 degrees South Latitudes. The Zone Number Subfield shall be filled according to the rules outlined in paragraph 4.1.3.5.3.1, except the grid zone letter designator (A,B,Y, or Z) shall be used in place of the 6 degree longitudinal band zone numbers.
4.1.3.5.4 State Plane Coordinate Systems . Currently, many of the SPCS's are, through legislative mandate, referenced to the North American Datum Adjustment of 1983 and are referred to as SPCS 83 systems. The SPCS 83 systems are required to have their horizontal components expressed in meters to conform to the SPCS specifications. However, several SPCS's remain that are referenced to the North American Datum of 1927 and are referred to as SPCS 27 systems. The SPCS 27 specifications required that the horizontal components be expressed in feet. The horizontal component of SPCS 27 data shall be converted to meters.
An X or Y coordinate in an existing SPCS can be expressed by a number of the general magnitude of NNNNNNN.NNN. This will suffice for a range of not less than 0.003 meters and not more than 3,000,000.000 meters and is considered to be appropriate for this standard. For the purposes of coordinate transfer, the following convention applies. Where a decimal fraction is used, it shall be one, two or three positions in length, as required (e.g., .1, .15, .125).
Each of the zones or SPCS's in each jurisdiction is uniquely identified by a fournumeric code as specified in table 4 of FIPSPUB 70four character code shall be transferred in the Zone Number subfield of the External Spatial Reference module.
4.1.3.5.5 Altitude . Altitude of a point, as used in this standard, is defined as the distance in meters either above or below a reference surface. The Vertical Datum and Sounding Datum subfields of the External Spatial Reference module shall be used to specify this surface.
All altitude measurements below the reference Vertical Datum shall be designated by a minus sign (the number. Measurements at or above the reference datum, or at or below the Sounding Datum, may be either without a sign or may be designated by a plus sign (+), however usage shall be consistent throughout a set of data.
The unit of measurement shall be the meter.
4.1.3.6 Attributes
4.1.3.6.1 Introduction . Attributes shall be transferred as simple relational tables. Each Attribute module record shall contain a table row. Two types of attribute tables exist:primary and secondary. Each table row shall be stored as one module record of an Attribute Primary or Attribute Secondary module. The attributes shall be separate from the spatial objects, but primary attributes shall be related to the objects through forward and (or) backward foreign identifiers. While the Attribute Primary module records are linked directly to the spatial objects, the records for the secondary attribute tables are related to primary attributes and (or) other secondary attributes through common attributes of the same name and domain, allowing for a relational join between primary and secondary tables. Secondary attributes can provide additional information for the primary attributes without having to repeat this information for each spatial object. Secondary attributes can also relate to other secondary attributes or to more than one set of primary attributes. The link between spatial object module records and Attribute Primary module records is a oneor onelink. For each spatial object there may be more than one Attribute Primary module record, but more than one spatial object may not refer to the same Attribute Primary module record. The link between Attribute Primary and Attribute Secondary module records may be one, one, or many. Attribute Secondary modules are linked to Attribute Primary modules or other Attribute Secondary modules through possible relational joins on corresponding attributes. The names and types of related modules that can be joined shall be transferred in the form of module crossexpressed in the Catalog/Crossmodule. The structure of an Attribute Primary module record is defined as:
<Attribute Primary module record> ::=<module record identifier> [<spatial object ID>] [<attribute 1>] [<attribute 2>] . . . [<attribute n>]where n is a constant for the module.<module record identifier> ::=<module name> <record id>
<spatial object ID> ::=<module name> <record id>
4.1.3.6.2 Attributes and Schema . The attribute subfields of both the Attribute Primary and Attribute Secondary modules are generic subfields, to be defined by the user of the standard. Therefore, the information about the attributes is also user defined and must be transferred as well. The Data Dictionary/Definition module carries the definition of attributes and entities. The Data Dictionary/Domain module specifies the attribute domains. Specifications contained in these modules can be applicable to all attribute modules in a transfer. The Data Dictionary/Schema module applies to specific tables, and specifies the composition of these tables with respect to specific attributes used from among the total set defined in the other Data Dictionary modules. The Data Dictionary/Schema module transfers five important types of attribute information:
4.1.3.6.3 Attributes and Entity . Part 2, section 2 defines an attribute as "a defined characteristic of an entity type." Attributes may also be used without reference to an associated entity. The combination of an attribute label and its associated authority is considered unique. Therefore, two attributes with the same label and authority shall have the same definition and value domain throughout the transfer.
4.1.3.6.4 Object and Entity . As described, spatial objects are normally associated with entities through attributes stored in Attribute Primary and Attribute Secondary modules, that have associated Schema modules, in which the entity type may be stored.
4.1.3.6.5 Attributes and the Universe and Void Polygons . As stated in the definitions of the universe and void polygons (2.3.3.3.1 and 2.3.3.3.2), the attribution of these objects can be substantially different from the attribution of the other polygons of a two-dimensional manifold. This difference in attribution may be implemented in any of the following three ways:
4.1.3.6.6 Attribute Definition, Authority, and Domain . Attribute meaning can only be transferred through the association of an attribute label with an attribute definition. The Data Dictionary/Definition module is used to relate an attribute label to an attribute definition. It also relates the attribute label to the attribute source and attribute authority.
The attribute authority is the organization and (or) document through which a meaning is assigned to the attribute label as it occurs in the transfer. The attribute authority is not responsible for the actual value assigned to the attribute in the transfer, other than the specification of the value domain. The description of the authority responsible for actual value assignment shall be transferred through the data quality Lineage module (see 5.3.1).
Attribute and entity authorities shall be specified in the Attribute and Entity Authority subfields of the Data Dictionary/Schema module. If the authority subfields are null or contain authorities other than this standard, then the attribute and (or) entity shall be fully described through Data Dictionary module entries. Detailed conventions for the use of the authority subfields are found in 5.2.6.
A valid domain for each attribute can be specified through the use of the Data Dictionary/Domain module.
4.1.3.6.7 Foreign Identifiers as Attributes . A foreign identifier shall be composed of either two or three subfields: Module Name, Record ID, and an optional Usage Modifier (see 5.1.2). To facilitate joining attribute relations using foreign identifiers, and to facilitate the implementation of relationships, the following special convention allows the storage of foreign identifiers as single attribute values in a single subfield. The format of the attribute containing the foreign identifier shall be specified as "^" in the Format subfield of the applicable Data Dictionary/Schema module (see 5.2.6.3), indicating that the attribute is a "packed" foreign identifier. The corresponding attribute subfield shall contain the concatenated subfields of a foreign identifier as follows: Module Name and Record ID separated by the Graphic Character "#" (for example, SOILCHAINS#34). The optional Usage Modifier shall follow the Record ID directly (for example, SOILCHAINS#34L). When packed foreign identifiers are used, module names referred shall not contain the graphics character "#". The following BNF fully specifies the syntax of a packed foreign identifier:
<packed foreign identifier> ::=<Module Name> '#' <Record ID> [<Usage Modifier>]
4.1.3.6.8 Attribute Labels . Attributes labels shall conform to the "identifier" specification of the ANSI standard for the data base language SQL (ANSI X3.135127). This standard specifies an identifier as beginning with an uppercase letter (SDTS alphabetic character A-Z) and followed by zero or more "character pairs." A "character pair" consists of an optional underscore (SDTS graphic character "_") and an uppercase letter or digit (SDTS numeric 0to the SQL standard, the length of an attribute label shall not exceed 18 characters. An attribute label shall not be identical to an SQL keyword. The BNF for the attribute label is:
<attribute label> ::=<uppercase alphabetic character>
{ <character pair> }
<uppercase alphabetic character> ::= A|B|C|D|E|F|
G|H|I|J|K|L|
M|N|O|P|Q|R|
S|T|U|V|W|X|
Y|Z
<character pair> ::=[ <underscore> ]
<letter or digit>
<underscore> ::=_
<letter or digit> ::=<uppercase alphabetic character> |
<digit>
<digit> ::=0|1|2|3|4|5|6|7|8|9
4.2 Transfer Module Specification Conventions
The following contains the conventions and notation for the module specification tables of section 5.
4.2.1 Specification Layout
Each specification consists of a table describing the composition of records in a module. A module record is composed of module fields consisting of a set of subfields. Each subfield has a specified data type and domain. The columns of the specification table are (1) Field Name, (2) Subfield Name, (3) Field/Subfield Description, and, for subfields, (4) Data Type, (5) Domain, and (6) Domain Description. Column (7) gives a four-character mnemonic tag for each field and subfield specified.
The primary module field name for a module record shall be also the module type. Subfield names shall identify the data content of the module records. The Data Type shall indicate the manner in which the field or subfield will be encoded. Each of the codes shall have the following meaning:
In some instances, one may select from two of the above types, in which case the code letters will be separated by a vertical bar ( | ). The data type used should always be predictable.
The code "B" for bitfield data may have an additional qualification as follows:
B or BUI binary patterns may be used when their extent can be described by the implementation and the bit order is preserved by the implementation. When B is used without qualification, the bit pattern shall be interpreted according to a subfield description contained in the Domain Value Definition subfield of the appropriate Data Dictionary/Domain module. When BUI is used, the bit string shall be interpreted as an unsigned integer with the most significant bit first and least significant bit last.
The domain column specifies the set of values that may be encoded within the indicated data type. There are nine major domain specifications:
In case (g), the permitted values shall be listed, and each value shall be defined in the domain description column. The domain description column may provide further restrictions on the allowable domain. For example, if an alphanumeric item shall begin with an alphabetic character, this will be stated. When the domain column indicates "Integer," a positive, negative, or unsigned whole number is indicated. A "Real" number on the other hand calls for a positive or negative number with a fraction. In either case, there shall be no difference in meaning between a negative or positive zero. The actual implementation of an integer or real number shall be according to the domain Data Type in the Domain Description Table and as further specified in ISO 6093 for numeric values in character string format and ANSI X3.122(FIPSPUB 128) for binary data. For additional information see part 3.
In case (h), in most instances the number of a specific FIPS standard code set will be given, preceded by the characters "cs:" (e.g., cs:FIPSPUB4-1 for calendar dates). The Data Dictionary modules also provide a general capability to use code sets from any other FIPS standard as Attribute Values. (See 5.2.6.)
In case (i), a standard field may take on specified values that are defined in the domain description column and (or) additional values defined in a Data Dictionary/Domain module. The notation in the domain column shall be preceded by "dd:" followed by any appropriate limitation in the domain. For example, dd:<0 means that negative values are permitted but they must be defined in an associated Data Dictionary/Domain module.
Table 4 contains a complete enumeration of the character sets to be used for the graphics characters, alphabetic, numeric, and alphanumeric domains. All graphics characters shall be encoded as specified in ANSI X3.4, extended to an 8-bit environment if required. Note that the set of graphics characters has been expanded slightly to include unprintable characters for carriage return (CR), line feed (LF), backspace (BS), tab, and form feed (FF) commonly found in text strings.
Table 4 Character sets used to express the Graphics Characters,
Alphanumeric, Alphabetic, and Numeric domains 1
------------------------------------------------------------------
Graphics Characters
----------------------------------------------------
Alphanumeric
---------------------------
Alphabetic Numeric
------------------------ --------------
A N a n SPACE 0 E2 ! | _
B O b o 1 . " / {
C P c p 2 + # : }
D Q d q 3 - $ ; FF
E R e r 4 SPACE3 % < LF
F S f s 5 & = CR
G T g t 6 ' > BS
H U h u 7 ( ? TAB
I V i v 8 ) @
J W j w 9 * [
K X k x ~ ]
L Y l y ` \
M Z m z ^
------------------------------------------------------------------
------------------------------------------------------------------
4.2.2 Generic Versus Explicit Specification
Various specification elements, such as module names, field names, and subfield names, can be specified generically rather than explicitly. In this case, the user shall replace the generic names with names composed by the user or selected by the user from a name substitution table as indicated by the notation and naming conventions in the following.
An explicit specification is one that shall appear verbatim as documented in this standard (independent of case). Names may be abbreviated internal to the transfer as long as the meaning of the data are unambiguously transmitted to the user of the standard (also see 4.1.3.1 and part 3, annex B).
4.2.3 Notation and Naming Conventions
This subsection specifies notation conventions for the nature and character of field names and subfield names occurring in the module specification tables.
4.2.3.1 Explicit Specification . All explicit field names are specified in alphabetic characters, with the first character in uppercase. Subfield names are specified the same as field names. Upper and lowercase expression is only significant for the specification of this standard, not for the content of field and subfield names in a transfer.
4.2.3.2 Generic Specification . Generic field names and subfield names are specified in loweralphabetic characters only, and the entire name shall be replaced by the user, according to the instructions for the particular specification.
After user substitution, all specifications shall appear as though they were explicit specifications.
4.2.3.3 Classes of Fields . Fields may be grouped into different classes. Some fields may have repeated instances in the transfer, while others are not allowed to repeat. For some fields ordering may be important, while for others it is not. Therefore, to designate the class of a field, each field has one or more characters following its name. The meaning of these designations is as follows.
Primary fields are marked by (P), secondary fields where order of repetition is not significant are marked by (R), and secondary fields where the order is significant are marked by (O). Secondary fields that shall not be repeated within a module record are marked by (N).
Secondary fields where order of repetition is significant and is correlated with the repetition of one or more other fields are designated as follows. Each set of fields with a module record where ordering is correlated will be assigned a character. This character is appended to the order symbol (O) for a field, symbolically expressed as (O/x), where x is replaced by an uppercase alphabetic character in the specifications. For example, if two fields named Internal address and External address have an ordering relationship in which there is a onecorrespondence between the elements in the list of instances of these fields, then the pair of these fields is designated as set A and the fields are marked:
Internal address (O/A)
External address (O/A)
4.2.3.4 Repeated Subfields in Generic Specifications . Certain subfields of a field, such as the components of a spatial address, are generically identical and are thus described only once in each generic specification. In the generic specification, the number of these subfields is variable because the number of subfields required depends on the individual application. After user substitution, however, the subfield names will be different, and the number of subfields will be the same for the field throughout the entire module. Subfields of this type are specified only once and are flagged by a "+" in subsequent specifications.
For example, the subfield names for the attributes of an attribute module are not known until the user determines the types of attributes to be used in the transfer. For this reason, the generic specification for the subfield names of the Attributes field in the Attribute Primary module (and similarly for the Attribute Secondary module) is as follows:
FIELD SUBFIELD FIELD/SUBFIELD
NAME NAME DESCRIPTION
----- -------- --------------
attributes(N)
(+)attribute
Primary attributes for the spatial object
with the meaning that the user should make substitutions for the "(+) attribute" generic subfield name for his/her specific application so that for the user's purpose the table then reads (for example):
FIELD SUBFIELD FIELD/SUBFIELD NAME NAME DESCRIPTION ----- -------- -------------- attributes DEPTH Depth of soil TEXTURE Texture of soil SLOPE Slope of soil4.2.3.5 Variably Repeating Subfields . Subfields with a given name and type that may repeat a variable number of times (0 or more repetitions) within a given transfer will have a name flagged by a "#" in subsequent specifications.
4.2.3.6 Shared Module Field Types . Some module fields that occur in a number of modules, and do not change from module to module, are specified only once in 5.1. These fields will thereafter be shown only as a field name; subfield names and descriptions will be omitted from the module specification tables. The entire field will be absent in the domain description table.
For foreign identifiers and spatial addresses the shared field is generic, and these fields may then be assigned a different name in the module descriptions tables. However, to indicate that the contents and structure of these fields are either that of a foreign identifier or a spatial address, foreign identifier fields will be prefixed with the symbol "^" and spatial addresses will be prefixed with the symbol "\par
4.2.3.7 Subfields with Default Values . Subfields that have a specified default value when they are omitted from the transfer will be prefixed with the symbol "d". The default values are specified in the standard.
4.2.3.8 Mandatory and Optional Presence and Absence of Fields . Presence or absence of fields and subfields can be mandatory or optional, depending on the context in which the field or subfield is used. Unless the field is completely optional, one or more status codes may appear in the field or subfield description in the Module Composition Table indicating the disposition of the field. The status code is enclosed in square brackets and consists of up to three parts. The first part is a key that can be followed by one or more conditions in the second and (or) third part. The key is one of four symbols with the following meaning:
Key No condition or true Condition false --- -------------------- --------------- A Mandatory absence Mandatory presence M Mandatory presence Optional presence X Mandatory absence Optional presence O Optional presence Mandatory presence
The second part is an optional set of one or more Object Representation codes, separated by vertical bars ( | ). The third part is an optional set of field or subfield names with optional values, separated by a "+" or "|", the plus indicating that both fields are present and the vertical bar indicating that either one, but not both, fields are present.
For example, the Row Index in the Cell module is optional for raster objects with an Object Representation Code "GK" when the Tesseral Index subfield is used. This is indicated as: Row Index [O/GK/Tesseral Index]. The Domain subfield in the Catalog/Spatialmodule is optional if the Map, Theme, Aggregate Object subfield is used: Domain [O/Map|Theme|Aggregate Object].
The required presence or absence of a field or subfield can also depend on the value of another field or subfield. This will be indicated by the field or subfield name, followed by a "=" and by one or more values separated by vertical bars. For instance, the Vertical Component Format subfield is required when the value of the Spatial Address Type is "3." This is indicated as: Vertical Component Format [M/Spatial Address Type = 3].
The following BNF fully describes the structure of the field and subfield status notation:
status code ::= '['<status key>
['/' <object representation codes> ]
['/' <field and subfield names > ] ']'
<object representation codes> ::= <object representation code>
{'|' < object representation code> }
<field and subfield names> ::= <field or subfield>
{ <separator> <field or subfield>}
<field or subfield> ::= <field or subfield name>
[ ' = ' value ]
<separator> ::='|' | '+'
<field or subfield name> ::= <character string> |
<'character string'>
Each field or subfield can have one or more status codes, indicating the conditions under which the field or subfield should be included, excluded, or optionally included. A field or subfield can have a single status code with an attached condition. If the condition is false, then the disposition of the field or subfield depends on the status code as indicated in the table above. For multiple status codes, the disposition of the field is determined by the intersection of the logical conditions resulting from each status code.
The status codes are relative to the optionality of the module so that when a field or subfield is mandatory, it is mandatory within each SDTS transfer only if the module in which the field or subfield occurs is mandatory.
4.2.3.9 Notation Summary . The notation conventions are as follows:
Type of Name Generic Specification Explicit Specification ------------ --------------------- ---------------------- Field name Lowercase Initial uppercase Subfield name Lowercase Initial uppercase
Table 5 Summary of the special flags used with field names and subfield names
-----------------------------------------------------------------------------
Flag Used with Meaning
---- --------- -------
(+) generic subfield User must substitute one or more
name explicit subfields with user names
for the generic subfield in the
generic specification.
(#) subfield name Subfield with given name and type
can be repeated an indefinite number
of times.
(P) field name Primary module field.
(O) field name Secondary module field where order
of repetition is significant and the
criteria for order are specified.
(O/x) field name Secondary module field where order
of repetition is significant, and
where the order is correlated with
the order of one or more other fields
belonging to the set x (x to be replaced
with an uppercase alphabetic character).
(R) field name Secondary module field where order of
repetition is not significant.
(N) field name Nonrepeating secondary module field.
(-) field name Contents and structure of the field
is that of a spatial address.
(^) field name Contents and structure of the field
is that of a foreign identifier.
(d) subfield Subfield has a preassigned default
value when omitted from the transfer.
[A/..] field, subfield name Mandatory absence if condition true;
otherwise mandatory presence.
[M/..] field, subfield name Mandatory presence if condition
true; otherwise optional.
[X/..] field, subfield name Mandatory absence if condition true;
otherwise optional.
[O/..] field, subfield name Optional presence if condition true;
otherwise mandatory.
-----------------------------------------------------------------------------
5 Transfer Module SpecificationThis section contains field and subfield specifications for each transfer module record type. Each transfer module may contain a number of module records. The general data models and specifications of section 4, combined with the specific details of this section, form the implementationcore of the standard.
5.1 Spatial Address and Foreign Identifier Fields
Spatial address and foreign identifiers fields are common to a number of modules and are therefore defined only once in this section. They are referenced only by field name in the module specification tables and are not further described in the domain description columns of the tables. The field name used in the module specification table may be different from the field names shown in this section, but the field prefix (-) will indicate that a field is a spatial address field, and the field prefix (^) indicates that a field is a foreign identifier field (see 4.2.3.9, Notation Summary).
5.1.1 Spatial Address
Spatial address fields occur in many modules and are fully defined as:
Table 6 Spatial Address
FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC
(-)spatial address The order of the instances of this SADR
field is dictated by the particular
module in which the field is used.
X X Component of the spatial address. I|R|S|B Numeric As defined in the Horizontal X
[M] Componont Format subfield of
the internal Spatial Reference
module and according to the
4.1.3.5.1
Y Y Component of the spatial address. I|R|S|B Numeric As defined in the Horizontal Y
[M] Componont Format subfield of
the internal Spatial Reference
module and according to the
specifications of 4.1.3.5.1
Z Y Component of the spatial address. I|R|S|B Numeric As defined in the Vertical Z
[O] Componont Format subfield of
the internal Spatial Reference
module and according to the
specifications of 4.1.3.5.1
Note that the field name "spatial address" has all lowercase characters, meaning that the field name is generic. Different names may therefore appear in the module dexcription tables (see 4.2.3.2, Generic Specifications).5.1.2 Foreign Identifier
Foreign identifiers are also part of a number of module specifications and are specified as:
Table 7 Foreign IdentifierThe third subfield is only appropriate to modify references to lines or rings. Hence, it is only appropriate when the Object Representation subfield of the referenced module record contains Lx or Rx (see table 9).FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC (^)foreign id FRID Module Name Module name(s) of module(s) referenced A Gr-chars Module name of module MODN [M] referred. Wildcard characters may be used for references to multiple module names. Use of wildcards in this subfield is restricted to global modules. Record ID Identifier of record(s) referenced. I Integer The absolute value of this RCID [M] integer represents the Record ID of the record referred to. A negative value is used to reference all records in a module, as specified in 4.1.3.4.5 (b). Usage Modifier Used to modify references to lines or A S Start node of line USAG rings. Shall only be used when pointing E Ecd node of line to Line Module records from composites, L Left polygon of a line nodes, rings, or polygons, or to Ring R Right polygon of a line MOdule records from polygons. F Forward orientation of a line or ring B Backward orientation of a line or ring I Interior polygon of a ring X Exterior polygon of a ring
5.2 Global Information Modules
The global information modules define global parameters for interpreting the data transfer. Table 8 lists the global module types:
Table 8 Global module types --------------------------------------------------- MODULE TYPEIdentification
Catalog/Directory
Catalog/Cross
Catalog/Spatial
Security
Internal Spatial Reference
External Spatial Reference
Registration
Spatial Domain
Data Dictionary/Definition
Data Dictionary/Domain
Data Dictionary/Schema
Transfer Statistics
---------------------------------------------------
The Identification, Internal, and External Spatial Reference modules are always required. The following modules are recommended: Catalog/Directory, Catalog/Cross, Catalog/Spatial Domain, and Spatial Domain. Data Dictionary modules are required as defined in 4.1.3.3.1.
5.2.1 Identification
The Identification module provides identifying information about the content of other data modules in the transfer. At least one Identification module is required for each data transfer. It consists of two mandatory fields: Identification and Conformance.
5.2.1.1 Identification Field . Except for Module Name, Record ID, Standard Identification, Standard Version, Profile Identification, Profile Version, and Title, all remaining subfields of the Identification field are optional.
5.2.1.2 Conformance Field . The Conformance field includes profile specification subfields, an external spatial reference subfield, and a features level subfield.
5.2.1.2.1 Profile specification subfields . The profile specification subfields specify which object types are included in the transfer and which are not included. Table 9 lists the object types associated with each of the subfields in the Profile Specification. The object types are identified by Object Representation Code (see tables 31 and 37, and section 5.5 Composite Module). All profile specification subfields shall be coded either "Y" or "N". A "Y" indicates the presence of one or more of the object types associated with the indicated profile.