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. An "N" indicates that none of the object types associated with that profile is present, with the following exception. Certain one-dimensional, geometry only vector objects (of type LS, AC, AE, AU, and AB) may be used to construct other objects with topology. An "N" for the geometry only profile indicates that such objects, although present, are used only as building blocks for topologically structured objects. Similarly, an "N" for the with-topology profile indicates that these objects are not used in topological structures.
Table 9 Presence or absence of object types by Profile Specification
--------------------------------------------------------------------
Profile Specification subfield
----------------------------------------------
Object
Code type Composite Vector: Vector with Image or
geometry only topology Grid
FF Composite Y N N N
NP Point N Y N N
NE Entity point N Y Y N
NL Label point N Y N N
NA Area point N Y Y N
NO Node, planar N N Y N
NN Node, network N N Y N
LS String N Y Y N
LQi Link N N Y N
LE Complete chain N N Y N
LL Area chain N N Y N
LW Network chain N N Y N
LY Network chain N N Y N
AC Arc N Y Y N
AE Arc N Y Y N
AU Arc N Y Y N
AB Arc N Y Y N
RM Ring, mixed N Y N N
RS Ring, strings N Y N N
RU Ring, chains N N Y N
RA Ring, arcs N Y N N
PG G-polygon N Y N N
PR GT-polygon N N Y N
PC GT-polygon N N Y N
PU Universe polygon N N Y N
PW Universe polygon N N Y N
PV Void polygon N N Y N
PX Void polygon N N Y N
GI Raster object N N N Y
GJ Raster object N N N Y
GK Raster object N N N Y
GM Raster object N N N Y
------------------------------------------------------------------
5.2.1.2.2 External spatial reference subfield . The mandatory External Spatial Reference subfield indicates whether one of the three recommended systems, Latitude and Longitude, UTM/UPS, or State Plane Coordinate Systems, has been used in the transfer. The subfield shall contain 1 if yes, 2 if no but another projection has been used with a specified relationship to Latitude and Longitude, 3 if the relationship to Latitude and Longitude is unspecified.
5.2.1.2.3 Features level subfield . The mandatory Features Level subfield indicates the level of conformance to part 2 of this standard. The meaning of each level is as follows:
Table 10 Identification FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC Identification(P) IDEN [M] Module Name A unique name for this A Alphanum Name shall begin with an MODN Identification module. alphabetic character other than SPACE. Record ID A number for the module record, I Integer Unsigned integer; with Module RCID unique within the module. Name shall form unique ID within the file set. Standard A title for the standard to A Alphanum SPATIAL DATA TRANSFER STANDARD STID Identification which this transfer conforms. [M] Standard Version Version of the standard to which A Alphanum Value of the version number. STVS [M] this transfer conforms. Standard Reference to specific published A Gr-chars FIPSPUB number and date. DOCU Documentation documentation for the standard. Reference Profile A title for the profile to which A Alphanum Alphanumeric title of profile, PRID Identification or "none" if transfer does not [M] conform to a profile. Profile Version Version of the profile to which A Alphanum Version, date, and FIPS or PRVS [M] this transfer conforms. proposed FIPS information; or "none". Profile Reference to specific published A Gr-chars Any combination of graphics PDOC Documentation documentation for the profile, characters. Reference including publisher or source of documentation. Title An overall title or name applied A Gr-chars Any combination of graphics TITL [M] to all data content of the data characters. transfer. Data ID A user-defined data set identifier A Gr-chars Any combination of graphics DAID ,usually unique to the user. characters. Data Structure A description of the internal data A Gr-chars Any combination of graphics DAST structure, organization, or other characters. properties of the data relating only to the digital representation rather than, and independent of, the actual "analog" data represented. Map Date A data specifying the temporal A cs: FIPSPUB 4 specified date (day MPDT extent of the data. This date shall FIPSPUB4 or month-day may be ommitted). apply to the acrual real-world info represented by the data, and not to data collection or any other processing history. Data Set Creation A date specifying when the data A cs: FIPSPUB 4 specified date (day DCDT Date were created (a processing history FIPSPUB4 or month-day be omitted). date"stamp" on the data set rather than the info represented. Scale A scale denominator at which the I Numeric A valid numeric scale SCAL data may be referenced in a "paper denominator. map" sense. If the data were collected from a graphic map, or meant to be displayed graphically, this subfield would indicate the scale of the map /display. Comment Additional comments. A Gr-chars Any combination of graphics COMT characters. Conformance(N) See 5.2.1.2 for details. CONF [M] Composites Transfer contains at least one A Y Yes FFYN [M] composite object. N No Vector Geometry Transfer contains vector objects A Y Yes VGYN [M] used for geometry only operations. N No Vector Topology transfer contains vector objects A Y Yes GTYN [M] with topological relationships incl. N No Raster Transfer contains rester--image A Y Yes RCYN [M] and (or) grid--objects. N No External Spatial Specifies whether one of the three I 1 Yes. EXSP Reference[M] recommended coordinate systems 2 Other projection used. (Latitude and Longitude, UTM/UPS, or 3 Projection unspecified State Plane Coordinates) has been used as the External Spatial Reference system. Features Level Specifies the level of conformance I 1 All SDTS FTLV [M] to the lists and definitions of 2 Mixed, non-overlapping entity and attribute terms in part 3 Mixed, overlapping 2. 4 All non-SDTS (^)Attribute ID Foreign identifier for Attribue ATID Primary module record. (R) Attirbute data referenced are global.5.2.2 Catalog
The Catalog module specification describes three types of modules:
5.2.2.1 Catalog/Directory . This module contains information on where to locate all modules within the transfer.
FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC Catalog/Directory CATD (P)[M] Module Name [M] A unique identifier for this A Alphanum Name shall begin with an MODN Catalog/Directory module. alphabetic character other than SPACE Record ID [M] A number for the module record, I Integer Unsigned integer, with Module RCID unique within the module. Name shall from unique ID within the file set. Name[M] The unique value in the module A Alphanum Name shall start with alphabetic NAME Name subfield of the module character. referenced. Type [M] The transfer module promary field A Gr-chars Shall be a valid module primary TYPE name of "Name" above. module field name. Volume The volume on which a part or all A Gr-chars Valid volume descriptor, VOLM of the module is to be found. wildcard cahracters may be used. File The file on which a part or all of A Gr-chars Valid file name, wildcard FILE the module is to be found. characters may be used. Record The record on which a part or all I|A Integer Unsigned integer, wildcard RECD of the module is to be found GR-chars characters may be used. (implememtation record). External The module is external to this A Y Yes EXTR transfer data set. N No Module Version Version of the module referenced A Gr-chars Valid version designator. MVER [M/External = Y] by, or included in, this transfer data set. Comment Any other information. A Gr-chars Any combination of graphics COMT characters.
5.2.2.2 Catalog/Cross . This module contains the linkages for modules in the transfer. These linkages can be many, one, or one. For example, for global modules, the linkage may be oneor one. For the oneand many linkages, multiple module records for a given module shall be present.
Table 12 Catalog/Cross-ReferenceFIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC Catalog/Cross CATX Reference(P) [M] Module Name [M] A unique identifier for this A Alphanum Name shall begin with an MODN Catalog/Cross-Reference module. Alphabetic character other than SPACE. Record ID [M] A number for the module record, I Integer Unsigned Integer, with Module RCID unique within the module. Name shall form unique ID within file set. Name 1 [M] The unique value in the Module A Alphanum Name shall be name of a module NAM1 Name subfield of the module referenced in the transfer. Type 1 The transfer module primary field A Gr-chars Shall be a valid module primary TYP1 name of "NAME 1" above. field name. Name 2 [M] The unique value in the Module A Gr-chars Name shall be name of a module NAM2 Name subfield of the module in the transfer, wildcard referenced. characters may be used. Type 2 The transfer module primary field A Gr-chars Shall be a valid module primary TYP2 name of "Name 2" above. module field name. Comment Any other information. A Gr-chars Any combination of graphics COMT characters.
5.2.2.3 Catalog/Spatial Domain . This module defines the relations between a particular module and a spatial domain, map, theme, or aggregate object.
Table 13 Catalog/Spatial Domain FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC Catalog/Spatial CATS Domain(P) [M] Module Name [M] A unique identifier for this A Alphanum Name shall begin with an MODN Catalog/Cross-Reference module. Alphabetic character other than SPACE. Record ID [M] A number for the module record, I Integer Unsigned Integer, with Module RCID unique within the module. Name shall form unique ID within file set. Name [M] The unique value in the Module A Alphanum Name shall be name of a module NAM1 Name subfield of the module referenced in the transfer. Type The transfer module primary field A Gr-chars Shall be a valid module primary TYP1 name of "NAME 1" above. field name. Domain Area of geographic coverage A Gr-chars Any combination of graphics DOMN referenced by this module. characters; wildcard cahracters may be used and are always taken as wildcards. Map Map coverage name within A Gr-chars Any combination of graphics MAP [O/Domain|Theme geographic coverage characters; wildcard characters |Agregate Object] referenced by this module. may be used and are always taken as wildcards. Theme Theme referenced by this module. A Gr-chars Any combination of graphics THEM [O/Domain|Map| characters; wildcard characters Aggregate Object] may be used and are always taken as wildcards. Aggregate Object Aggregate spatial object A Gr-chars Any combination of graphics AGOB [O/Domain|Map| referenced by this module. characters; wildcard characters Theme] may be used and are always taken as wildcards. Aggergate Object Type of aggregate spatial object A Gr-chars Any combination fo graphics AGTP Type [M/ referenced, such as Graph or Raster characters. Aggregate Object] Comment Any other information. A Gr-chars Any combination of graphics COMT characters.5.2.3 Security
The Security module provides information on the security of the data in a transfer. Information on security may be carried at different levels of aggregation. Thus, information on security may refer to a domain, map, coverage, or an individual spatial object. Because some organizations have more rigorous requirements for this information than do other organizations, each organization may customize this module to its own needs.
Table 14 Security FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC Security SCUR [M] Module Name [M] A unique identifier for this A Alphanum Name shall begin with an MODN Catalog/Cross-Reference module. Alphabetic character other than SPACE. Record ID [M] A number for the module record, I Integer Unsigned Integer, with Module RCID unique within the module. Name shall form unique ID within file set. Security Class Security Classification level. A Gr-chars Any combination of graphics CLAS characters. Examples are "Top Secret","Secret","Confidential" "Restricted" or "Unclassified. Control Instructions for distribution and A Gr-chars User-defined combination of CTRL handling of the data. graphics characters. Release Instruction on release A Gr-chars User-defined combination of RLIS Instructions. restrictions. graphic characters. Review Date Reclassification Date A cs: FIPSPUB 4 specified date. RVDT FIPSPUB4 Review Reclassification Instructions. A Gr-chars Any combination of graphics RVIS Instructions characters. Comment Any other information. A Gr-chars Any combination of graphics COMT characters. (^)Foreign ID (R) Reference to a specific module FRID record.5.2.4 Spatial Reference
The spatial reference in a spatial data transfer is defined through the use of the following transfer modules:
The internal (to the transfer) coordinate system can be related to geographic coordinates through the use of the Internal and External Spatial Reference modules. The Internal Spatial Reference module provides a mechanism for the sender to explicitly define the translation and scaling of the internal coordinate system to the system defined in the External Spatial Reference module.
5.2.4.1 Internal Spatial Reference . The transformation parameters described in the Internal Spatial Reference module record provide for a simple translation and scaling from the internal reference system to the external reference system. Three scale factors and a translation vector that is the origin of the external spatial reference system provide for the independent scaling and translation of internal coordinates to external coordinates.
The following matrix equation shall be specified:
|X| |SX 0 0| |X'| |Xo| |Y| = |0 SY 0| |Y'| + |Yo| |Z| |0 0 SZ| |Z'| |Zo|
X,Y,Z = components of spatial address in the external system
SX,SY,SZ=scaling factors for scaling to the external system, forming the diagonal elements of a diagonal matrix with offzero elements
X',Y',Z' =components of spatial address in internal system
Xo,Yo,Zo=components of spatial address of origin of internal system in external system
If the external reference system is the State Plane coordinate system and the internal system uses units of feet, the feet to meters conversion factor of 0.3048 shall be used in computing scaling factors.
An alternative method for converting from internal to external coordinates is provided through the use of registration points in the Registration module. The subfields containing the scaling factors and the origin of the external system are optional only if registration points are used. Otherwise, the subfields are mandatory and shall not be null. If no transformation is required, then the identity transformation shall be indicated by scaling factors of 1.0 and components of the origin of 0.0.
Table 15 Internal Spatial Reference FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC Internal Spatial IREF Reference (P) [M] Module Name [M] A unique identifier for this A Alphanum Name shall begin with an MODN Catalog/Cross-Reference module. Alphabetic character other than SPACE. Record ID [M] A number for the module record, I Integer Unsigned Integer, with Module RCID unique within the module. Name shall form unique ID within file set. Comment Free-form comment subfield A Gr-chars Any combination of graphics COMT characters. Note: the following subfields provide information for the type of spatial address used. Spatial Address Indicates whether horizontal comp. A 2-TUPLE Horizontal component only. SATP Type [M] only or both horizontal and verticle 3-TUPLE Horizontal componont and a components are present in the verticle component. spatial address. Spatial Address X Indicates the correspondence of A LATITUDE For use with geographic XLBL Component Label internal and external spatial address LONGITUDE coordinates. [M] X components to either one of the horizontal components of the external spatial reference system. EASTING For use with State Plane or NORTHING UTM/UPS systems. When latitude is selected, then Longitude shall be selected for the following subfield. When Easting is selected, then Northing shall be selected, for the following subfield. May be used with External Gr-chars Spatial Reference Conformance level 2 or level 3. Registration module required for conformance levle 2. Spatial Address Y Indicates the correspondence of A LATITUDE For use with geographic YLBL internal and external spatial address LONGITUDE coordnates. Y components to either one of the horizontal components of the external spatial reference system. EASTING For use with State Plane or NORTHING UTM/UPS systems. When Latitude is selected, then Longitude shall be selected for the previous subfield. When Easting is selected, then Northing shall be selectedfor the previous subfield. May be used with External Spatial Gr-chars Reference Conformance level 2 or level 3. Registration module required for conformance level 2. Horizontal Specific format of the horizontal A I Implicit-point integer HFMT Component Format components of the spatial address R Explicit-point unscaled. [M] S Explicit-point Scaled BI8 8-bit signed integer BI16 16-bit signed integer BI24 24-bit signed integer BI32 32-bit signed integer BUI Unsigned integer BUI8 8-bit unsigned integer BUI16 16-bit unsigned integer BUI24 24-bit unsigned integer BUI32 32-bit unsigned integer BFP32 32-bit floating point real BFP64 64-bit floating point real Vertical Specific format of the verticle A I Implicit-point integer VFMT Component Format components of the spatial address. R Explicit-point unscaled. [M/Spatial Address S Explicit-point Scaled Type=3-TUPLE] S Explicit-point Scaled BI8 8-bit signed integer BI16 16-bit signed integer BI24 24-bit signed integer BI32 32-bit signed integer BUI Unsigned integer BUI8 8-bit unsigned integer BUI16 16-bit unsigned integer BUI24 24-bit unsigned integer BUI32 32-bit unsigned integer BFP32 32-bit floating point real BFP64 64-bit floating point real Note: the following subfields are used to specify the scaling matrix and translation vector. The off-diagonal elements of the scaling matrix are always zero, and are therefore not transferred. Scale Factor X Scaling factor for the X axis. R Real Any real number. SFAX [O/Registration] Scale Factor Y Scaling factor for the Y axis. R Real Any real number. SFAY [O/Registration] Scale Factor Z Scaling factor for the Z axis. R Real Any real number. SFAZ [M/Spatial Address Type=3-TUPLE] X Origin X component of origin spatial R Real Expressed in dgrees for XORG [O/Registration] address in external system. geographics, in meters for State plane or UTM/UPS. Y Origin Y component of origin Spatial R Real Expressed in degrees for geo- YORG [O/Registration] address in external system. graphics, in meeters for State Plane or UTM/UPS. Z Origin Z component of origin Spatial R Real Expressed in degrees for geo- ZORG [M/Spatial Address] address in external system. graphics, in meeters for State Type = 3-TUPLE] Plane or UTM/UPS. Note: the following subfields specify the resolution comonents for the spatial address, where resolution is defined as the minimum difference between two independently measured or computed coordinate values that can be distinguished by the measurement or analytical methode used. X component of X component of horizontal coordinate I|R|S Integer As Indicated by the Horizontal XHRS Horizontal resolution. Component format. Expressed in meters for geographics. State Plane, or UTM/UPS. Y component of Y component of horizontal coordinate I|R|S Integer As Indicated by the Horizontal YHRS Horizontal resolution. Component format. Expressed in meters for geographics. State Plane, or UTM/UPS. Vertical Vertical component of horizontal I|R|S Integer As Indicated by the Vertical VHRS Resolution resolution. Component format. Expressed in component meters for geographics. State [M/Spatial Address Plane, or UTM/UPS. Type=3-TUPLE]5.2.4.2 External Spatial Reference . This module is used to define the external spatial reference system and its relationship to latitude and longitude (see 4.1.3.5). The external spatial referencing systems supported by the standard and to be used under conformance level 1 are Latitude-Longitude (GEO), Universal Transverse Mercator/Universal Polar Stereographic (UTM/UPS), and State Plane Coordinate Systems--metric (SPCS). The system being used is indicated by one of the codes (GEO, UTM/UPS, or SPCS) in the Reference System Name subfield.
For conformance level 2, the Reference System Name subfield shall contain OTHR, meaning that another reference system is used. In this case, the system and its projection shall be fully described in the Projection subfield, the associated parameters for conversion to latitude and longitude shall be fully defined in Data Dictionary modules, and parameter values shall be provided as attributes referenced by the Attribute ID field. A full description of the system used shall be provided in the Lineage portion of the Quality Report as well.
For conformance level 3, the Reference System Name subfield shall contain UNSP, meaning that the relationship of the spatial addresses to geographic coordinates is not specified, and this fact shall also be documented in the Lineage portion of the Quality Report.
Table 16 External Spatial Reference5.2.4.3 RegistrationFIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC External Spatial XREF Reference (P) [M] Module Name [M] A unique identifier for this A Alphanum Name shall begin with an MODN Catalog/Cross-Reference module. Alphabetic character other than SPACE. Record ID [M] A number for the module record, I Integer Unsigned Integer, with Module RCID unique within the module. Name shall form unique ID within file set. Comment Free-form comment subfield A Gr-chars Any combination of graphics COMT characters. Reference Reference in which the external A Gr-chars Any combination of graphics RDOC Documentation system used is documented. characters. Reference system Name for the external system used. A GEO Geographics (latitude and RSNM Name longitude). [M] SPCS State Plane-meters. UTM UTM - meters UPS UPS - meters OTHR Other - Described in Projection subfield UNSP Unspecified Vertical Datum Reference surface for the third A NGVD National Geodetic Vertical VDAT [X/Spatial Address component of the internal spatial Datum of 1929 Type=2-TUPLE| addresses (not used for hydrographic NAVD North American Vertical Datum Sounding Datum] depths). of 1988. GEODETIC All altitudes are referenced to the ellipsoid of the specified datum. Gr-char Any other geodetic datum. Sounding Datum Reference datum for the third A MHW Mean height water SDAT [X/Spatial address component of the internal spatial NHWN Mean height water Neaps Type=2-TUPLE| addresses (for hydrographic depths MHWS Mean height water Springs Vertical datum] only). MHHW Mean higher height water MLW Mean lower water MLWN Mean low water Neaps MLWS Mean low water Springs MLLW Mean lower low water Horizontal datum Geodetic datum to which the A NAS North American 1927 HDAT internal spatial addresses have NAX North American 1983 been referenced. WGA World Geodetic System 1960 WGB World Geodetic System 1966 WGC World Geodetic System 1972 WGE World Geodetic System 1984 Gr-chars Any other geodetic datum Zone Number UTM/UPS/State Plane Zone number A Gr-chars Valid UTM/UPS/State Plane ZONE [M/Reference System zone number (see 1.3.21 and Name = annex C). SPCS|UTM|UPS] Projection Name and/or description of the A Gr-chars Any combination of graphics PROJ [M/Reference system projection and reference system characters. Name = OTHR] used. (^)Attribut ID Foreign identifier for Attribute ATID (N) Primary module record containing [M/Reference projection parameters. System Name=OTHR]
Registration points may be used to express the relationship between the internal spatial reference system and the external spatial reference system.
Table 17 Registration FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC Registration (P) RGIS [M] Module Name [M] A unique identifier for this A Alphanum Name shall begin with an MODN Catalog/Cross-Reference module. Alphabetic character other than SPACE. Record ID [M] A number for the module record, I Integer Unsigned Integer, with Module RCID unique within the module. Name shall form unique ID within file set. Comment Free-form comment subfield A Gr-chars Any combination of graphics COMT characters. (-) External EADS Reference Spatial Address (O/A) [O/Projection] (-) Internal IADS Reference Spatial Address (O/A) [O/Projection]
5.2.5 Spatial Domain
The Spatial Domain module specifies a geographic areal domain within which the spatial addresses of other modules are contained. Two basic methods of specifying this coverage are allowed for in this module:
Two types of spatial addresses may be used:
Table 18 Spatial Domain FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC Spatial Domain SPDM (P) [M] Module Name [M] Unique name for this Spatial A Alphanum Name shall begin with an MODN Catalog/Cross-Reference module. Alphabetic character other than SPACE. Record ID [M] A number for the module record, I Integer Unsigned Integer, with Module RCID unique within the module. Name shall form unique ID within file set. Spatial domain Method of specifying the domain A MINMAX Spatial domain is specified by DTYP Type [M] spacial addresses. two spacial addresses. The first containing the minimum value associated with each component; the second containing the max value associated with each component. RING Spatial domain is specified by a series of spatial addresses forming a ring boundary. Domain Spatial System employed to specify the A INTERNAL Internal spatial addresses are DSTP Address Type domain spatial addresses used. [M] EXTERNAL Spatial addresses are in the form defined in the external spatial reference module. Comment Fre-form comment subfield. A Gr-chars Any combination of graphics COMT characters. (-)Domain Spatial Spatial address of spatial domain DMSA Address (O) boundary vertex. The ordering required [M] for the instances of the field relates to the proper sequence of the vertices for describing the boundary. 5.2.6 Data Dictionary
The Data Dictionary/Definition module shall also provide a full description of the attribute and (or) entity authority, when an authority other than the standard is referenced in the Data Dictionary/Schema subfields. In this case, the referenced definitions shall be available in the form of a standard Data Dictionary/Definition module. Wildcard characters may be used in the Entity/Attribute Label field, indicating that the authority applies to a collection of attributes defined in an authority document not included in the transfer. The applicable wildcard rules are those specified in 4.1.3.4.5.
Data Dictionary/Domain modules shall accompany Data Dictionary/Definition modules except where domain and value definitions are available from the attribute authority as noted above. A separate Data Dictionary/Domain module shall also be provided, where necessary, for the purpose of defining values of standard subfields where the domain type dd: is specified (case (i) in 4.2.1, Specification Layout). Such a module shall (a) contain no corresponding Data Dictionary/Definition or Data Dictionary/Schema module, (b) contain a concatenations, separated by a slash "/", of the field and subfield mnemonics (e.g., AFIL/HIDX for Area Fill Representation/Hatch Index) for which definitions are provided, in the Attribute Label subfield, and (d) be referenced in a corresponding Catalog/Cross Reference module which associates the Data Dictionary/Domain module with the module(s) for which subfield value definitions are provided.
The three data dictionary modules are relational modules with one primary module field per module record. For examples of the use of data dictionary modules, consult annex B.
If the authority for an attribute is another FIPS standard, the Attribute Domain Type subfield of the Data Dictionary/Domain module shall contain the keyword FIPSCODE (see 5.2.6.2) with the number of the applicable FIPSPUB cited in the Attribute Authority Description subfield of Data Dictionary/Definition module (see 5.2.6.1).
5.2.6.1 Data Dictionary/Definition . This module contains definitions for entities and entity attributes. It also specifies the name of the relevant authority and provides a full description of this authority. This module is a relational module, thus any onerelationships between entities or attributes and definition, source, and authority shall be expressed using multiple module records.
Table 19 Data Dictionary/Definition FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC Data Dictionary/ DDDF Definition (P) [M] Module Name Unique name for the Data Dictionary A Alphanum Name shall begin with an MODN [M] /Definition module. alphabetic character other than SPACE. Record ID A number for the module record, I Integer Unsigned integer; with Module RCID [M] unique within the module. name shall form unique ID within the file set. Entity or Indicates whether the module record A ENT Definition is for entity. EORA Attribute [M] contains an entity or attribute ATT Definition is for attribute definition. Entity/Attribute Entity or attribute label. A Gr-chars Any combination of graphics EALB [M] characters; wildcard characters may be used and are always taken as wildcards. Source Source for the definition. A Gr-chars Any combination of graphics SRCE characters. Definition Definition of the attribute or A Gr-chars Any conbination of graphics DFIN [M] entity denoted by the contents characters. of the Entity/Attribute subfield. Attribute Auth. Name of the attribute (or entity) A Gr-chars Any conbination of at most four AUTH [M] authority. If the authority is another graphics characters. FIPS standard,specify FIPS in this subfield, and give a full reference in the ADSC subfield. Attribute Auth. Full description of the attribute A Gr-chars Any combination of graphics ADSC Description (or entity) authority.5.2.6.2 Data Dictionary/Domain . This module is used to specify attributes and their associated e domains. It is also used to provide descriptions and definitions for user-defined attribute ues. The module is a relational module with one primary field, so that the one ationship between an attribute and the values of its associated domain shall be expressed ough the use of multiple module records. The domain types specified in this module are ctly the same as those specified for use in the transfer module specification layout (see 4.2.1). Special values of a domain, such as may be the case with an enumerated domain or with the specification of user null conventions, shall be defined using this module. The module serves to attach domain value definitions to domain values. Values shall always be defined, in one of three ways: (a) by specifying a measurement unit in the Attribute Domain Value Measurement Unit subfield, (b) by providing a definition in the Domain Value Definition subfield; or (c) by providing ference to a published source of definitions of value terms used in the Attribute Authority Description subfield of the corresponding Data Dictionary/Definition module record for the attribute.
This module is also used to specify the complete domain for subfields for which the domain is only partially defined in the standard. These are identified in the module description tables by a notation of dd: in the domain column. See 4.2.1.
Table 20 Data Dictionary/Domain FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC Data Dictionary/ DDOM Domain (P) [M] Module Name Unique name for the Data Dictionary A Alphanum Name shall begin with an MODN [M] /Domain module. alphabetic character other than SPACE. Record ID A number for the module record, I Integer Unsigned integer; with Module RCID [M] unique within the module. name shall form unique ID within the file set. Attribute Label Attribute label. A Gr-chars Attribute subfield name as in ATLB [M] the Attribute Primary and Secondary modules shall conform to the SQL standard as described in 4.1.3.6.8> The Attribute Label subfield shall contain, if necessary, a concatenation of the field and subfield mnemonics for the representation index, separated by a slash for domain types dd: for case (i) in section 4.2.1. Attribute Name of the attribute authority. A Gr-chars Any combination of at most AUTH Authority [M] four graphics characters. Attribute Domain Attribute Domain Type. If the auth. A GR-CHARS ATYP Type is another FIPS standard which ALPHANUM [M] contains standard codes for attribute ALPHABET value, specify FIPSCODE in this INTEGER subfield REAL BINARY ENUMERATED FIPSCODE Note: the contents of the Attribute Domain Value Format Subfield shall be the same in all records specifying the same attribute (where the Attribute Label and Attribute Authority subfield contents are equivalent). Attribute Domain Attribute domain value format A A Graphics Characters ADVF Value format [M] I Implicit-point (integer). R Explicit-point unscaled (fixed point real). S Explicit-point scaled. (floating point real).5.2.6.3 Data Dictionary/Schema . The primary function of this module is to describe the specific composition of the Attribute Primary and Secondary modules, and to relate the attributes in the attribute modules to the corresponding entities according to the entitymodel specified in 2.1.1 and in part 2, section 2. A secondary function is to provide additional information about the entity and attributes, such as authority, format, measurement unit, and subfield length. The module also contains a subfield indicating whether an attribute is a part of a relational primary or foreign key so as to preserve a relational attribute model. For an additional explanation of the relationships between this and the Attribute Primary and Attribute Secondary modules, see 4.1.3.6.1.
Table 21 Data Dictionary/Schema
FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC
Data Dictionary/ DDSH
Schema (P)
[M]
Module Name Schema module name. A Alphanum Name shall begin with an MODN
[M] alphabetic character
other than a SPACE.
Record ID A number for the module record, unique I Integer Unsigned integer; with RCID
[M] within the module. Module Name shall form
unique ID within the file
set.
Name Name of module with data to which the A Alphanum Name shall begin with an NAME
[M] schema applies. alphabetic character and
be the module name of an
Attribute module.
Type Type of module with data to which the A ATPR Shall be a valid module TYPE
schema applies. ATSC primary field mnemonic.
Entity Label Entity label of entity for which the A Gr-chars Any combination of ETLB
[O/Attribute subfield will contain an attribute value. graphics characters.
Label]^M
Entity Authority Authority for the definition (including A SDTS Part 2 of this standard Data
[O/Attribute meaning) of the entity. is the authority for the
uniquely named entity.
Gr-chars Any combination of up to
four graphics characters.
The meaning of this code
shall be explained in a
Data Dictionary/Definition
module.
Attribute Label Name of attribute subfield A Gr-chars Attribute subfield name ATLB
[M/Attribute as in the Attribute
Primary] Primary and Secondary
modules.
Shall conform to the SQL
standard as described in
4.1.3.6.8
Attribute Authority for the definition (including A SDTS Part 2 of this standard AUTH
Authority meaning) of the attribute. is the authority for the
[M/Attribute definition of the
Primary] uniquely named attribute.
Any combination of up to
Gr-chars four graphics characters.
The meaning of this code
shall be explained in a
Data
Dictionary/Definition
module.
Format Format for contents of attribute subfield. A I Implicit-point (integer) FMT
[M/Attribute R Explicit-point unscaled
Primary] (fixed-point real)
S Explicit-point scaled
(floating-point real)
B Bitfield Data.
BI8 8-bit signed integer
BI16 16-bit signed integer
BI24 24-bit signed integer
BI3 32-bit signed integer
BUI Unsigned integer
BUI8 8-bit unsigned integer
BUI16 16-bit unsigned integer
BUI24 24-bit unsigned integer
BUI32 32-bit unsigned integer
BFP32 32-bit floating point real
BFP64 64-bit floating point real
C Character mode bitfield
A Graphics Characters
^ Packed foreign identifier
(see 4.1.3.6.7)
The selected code shall
correspond to the data types
and domain for the attributes
in the attrtbute model
to which the schema model
applies.
Unit Measurement unit for contents of attribute A Gr-chars Any combination of U NIT
subfield graphics characters. Any
recognizable measurement
unit or abbreviation for
measurement unit
Maximum Subfield Maximum length of the subfield for all I Integer Unsigned Integer >= 1. MXLN
Length module records expressed as the maximum
[M/Attribute number of ASCII characters.
Primary]
Key Indicates whether attribute is part of A NOKEY Attribute is not part of key. KEY
primary or foreign relational key. PKEY Attribute is part of primary key.
Atribute is part of foreign key
FKEY Attribute is part of both
PFKEY primary and foreign key.
5.2.7 Transfer Statistics
This module shall be used to provide a transfer recipient with volume information at various levels. For this purpose, the module consists of a table of module names, total module record counts, and total spatial address counts.
Table 22 Transfer Statistic
FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC
Transfer
Statistics (P) STAT
[M]
Module Name A unique identifier for this Transfer A Alphanum Name shall begin with an MODN
[M] Statistics module. alphabetic character
other than SPACE.
Record ID A number for the module record, unique I Integer Unsigned integer; with RCID
[M] within the module. Module Name shall form
unique ID within the file
set.
Module Type The primary field name of the module to A Alphanum Valid primary field name. MNTF
Referred which the total module record count
refers.
Module Name Module name of module to which the total A Alphanum Name shall begin with an MNRF
Referred module record count refers. alphabetic character
[M] other than SPACE.
Module Record Total number of module records in the I Integer Unsigned integer >= 1. NREC
Count module with the module name given in the
[O/Spatial Module Name Referred field.
Address Count]
Spatial Address The total number of spatial address field I Integer Unsigned integer >= 0. NSAD
Count instances in the module.
[O/Module Record
Count]
5.3 Data Quality Modules
The Data Quality group is composed of the following modules: Lineage, Positional Accuracy, Attribute Accuracy, Logical Consistency, and Completeness. The contents for the Attribute field groups associated with these modules are specified in section 3.
Information on data quality can be carried at different levels of aggregation. Thus, information on quality can refer to a domain, map, coverage, or an individual spatial object. The Catalog can be used to make reference to the level of specificity of the information on quality. This can be done through the use of Catalog/Directory data subfields Volume, File, or Record; or the Catalog/Spatial Domain module subfields. There is also the provision for a data quality overlay relationship where a separate data layer provides the geometric and attribute information that applies to another data layer.
Use of all data quality modules in a data transfer is mandatory, and shall include at least a statement to the effect that no data quality description is available at the time of data preparation if such a statement reflects the status of the information available.
5.3.1 Lineage
The Lineage module transfers the information described in 3.1. This module may contain elaboration of the information also coded in 5.2.1, Identification. However, the transformation details shall be transferred in the Spatial Reference modules (see 5.2.4).
Table 23 Lineage
FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC
Lineage (P) DQHL
[M]
Module Name A unique module name for a Lineage module. A Alphanum Name shall begin with an MODN
[M] alphabetic character
other than SPACE.
Record ID A number for the module record, unique I Integer Unsigned integer; with RCID
[M] within the module. Module Name shall form
unique ID within the file
set.
Comment Any comments A Gr-chars Any combination of COMT
[M] graphics characters.
(^)Attribute Foreign identifier for Attribute Primary ATID
ID (R) module record. Attributes or comments as
determined by the supplier organization in
accordance with 3.1.
(^)Foreign ID Reference to a specific module record. FRID
(R)
5.3.2 Positional Accuracy
The Positional Accuracy module transfers the description of testing procedures and related details specified in 3.2. The estimates of positional accuracy obtained from the tests shall be transferred using the Spatial Reference modules (see 5.2.4).
Table 24 Positional Accuracy
FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC
Positional DQPA
Accuracy (P)
[M]
Module Name A unique module name for a Positional A Alphanum Name shall begin with an MODN
[M] Accuracy module. alphabetic character
other than SPACE.
Record ID A number for the module record, unique I Integer Unsigned integer; with RCID
[M] within the module. Module Name shall form
unique ID within the file
set.
Comment Any comments. A Gr-chars Any combination of COMT
[M] graphic characters.
(^)Attribute Foreign identifier for Attribute Primary ATID
ID (R) module record. Attributes or comments as
determined by the supplier organization in
accordance with 3.2.
(^)Foreign I Reference to a specific module record. FRID
(R)
5.3.3 Attribute Accuracy
The Attribute Accuracy module transfers all information required by 3.3.
Table 25 Attribute Accuracy
FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC
Attribute DQAA
Accuracy (P)
[M]
Module Name A unique module name for an Attribute A Alphanum Name shall begin with an MODN
[M] Accuracy module. alphabetic character
other than a SPACE.
Record ID A number for the module record, unique I Integer Unsigned integer; with RCID
[M] within the module. Module Name shall form
unique ID within the file
set.
Comment Any comments. A Gr-chars Any combination of COMT
[M] graphics characters.
(^)Attribute Foreign identifier for Attribute Primary ATID
ID (R) module record. Attributes or comments as
determined by the supplier organization in
accordance with 3.3.
(^)Foreign I Reference to a specific module record. FRID
(R)
5.3.4 Logical Consistency
The Logical Consistency module transfers all information required by 3.4.
Table 26 Logical Consistency
FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC
Logical DQLC
Consistency
(P)
[M] Module Name A unique module name for a Logical A Alphanum Name shall begin with an MODN
[M] Consistency module. alphabetic character
other than SPACE.
Record ID A number for the module record, unique I Integer Unsigned integer; with RCID
[M] within the module. Module Name shall form
unique ID within the file
set.
Comment Any comments. A Gr-chars Any combination of COMT
[M] graphics characters.
(^)Attribute Foreign identifier for Attribute Primary ATID
ID (R) module record. Attributes or comments are
determined by the supplier organization in
accordance with 3.4.
(^)Foreign ID Reference to a specific module record. FRID
(R)
5.3.5 Completeness
The Completeness module transfers all information required by 3.5.
FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC
Completeness DQCG
(P) [M]
Module Name A unique module name for a Completeness A Alphanum Name shall begin with an MODN
[M] module. alphabetic character
other than SPACE.
Record ID A number for the module record, unique I Integer Unsigned integer; with RCID
[M] within the module. Module Name shall form
unique ID within the file
set.
Comment Any comments. A Gr-chars Any combination of COMT
[M] graphics characters.
(^)Attribute ATID
ID (R) Foreign identifier for Attribute Primary
module record. Attributes or comments as
determined by the supplier organization in
accordance with 3.5.
(^)Foreign ID Reference to a specific module record. FRID
(R)
5.4 Attribute Modules
Refer to annex B for a full discussion and examples of the logical encoding of attribute modules.
5.4.1 Attribute Primary
The Attribute Primary module defines the primary attributes associated with a spatial element or object. All fields for the module record are nonrepeating and the module is therefore a relational module. The forward link, if present, from the spatial object through the Attribute ID field, shall match the Module Name and Record ID of the primary field of the module record for this module. The backward link, if present, is provided through the Spatial Object ID field, and the contents of this field shall match the module record identifier of the spatial object. The subfields of the Primary Attributes field are generic, user defined, with the description occurring in the Schema module. The number of attributes is selected by the user, but this number shall not vary for a given module in a transfer.
Table 28 Attribute Primary
FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC
Attribute ATPR
Primary (P)
[M]
Module Name A unique identifier for this Attribute A Alphanum Name shall begin with an MODN
[M] Primary module. alphabetic character
other than SPACE.
Record ID A number for the module record, unique I Integer Unsigned integer; with RCID
[M] within the module. Module Name shall form
unique ID within the file
set.
(^)Spatial Foreign identifier of spatial object with OBID
Object ID which the attribute record is associated.
(N)
Primary ATTP
Attributes (N)
[M] (+)attribute Primary attributes for spatial object. A|I|R Alphanum As indicated by Format in
[M] S|B|C Numeric the Data
Bitfield Dictionary/Schema module.
5.4.2 Attribute Secondary
The Attribute Secondary module defines the secondary attributes associated with values of primary attributes. The module is also of the relational type. The Catalog/Cross-Reference module shall be used to indicate associations between Attribute Primary and Attribute Secondary modules. Further association between attributes in both modules shall then be made through common attributes (same name and authority) to be used in relational joins. The Data Dictionary/Schema module can be used to indicate primary and foreign key relationships between attributes in both types of modules.
Table 29 Attribute Secondary
FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC
Attribute ATSC
Secondary (P)
[M]
Module Name A unique identifier for this Attribute A Alphanum Name shall begin with an MODN
[M] Secondary module. alphabetic character
other than SPACE.
Record ID A number for the module record, unique I Integer Unsigned integer; with RCID
[M] within the module. Module Name shall form
unique ID within the file
set.
Secondary ATTS
Attributes (N)
[M] (+)attribute Secondary attributes associated with A|I|R Alphanum As indicated by Format in
[M] primary attribute. S|B|C Numeric the Data
Bitfield Dictionary/Schema module.
5.5 Composite Module
The Composite module is used to transfer composite objects (see 2.3). It serves to transfer usercomposite data in ways that cannot be accomplished with the Point, Line, Polygon, Ring, Arc, or Raster modules alone. A composite object is composed of one or more other spatial objects, either vector or raster, simple or composite. Using this module, spatial objects are aggregated to make a more complex spatial object; therefore, composite objects do not carry any coordinate data within the module record.
Composite objects are given the Object Representation Code "FF". Additional Object Representation Codes are listed in table 31 for vector objects and in table 37 for raster objects.
Table 30 Composite
FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC
Composite (P) COMP
[M]
Module Name A unique identifier for the module. A Alphanum Name shall begin with an MODN
[M] alphabetic character
other than SPACE.
Record ID Composite object record identifier. I Integer Unsigned integer; with RCID
[M] Module Name shall form
unique ID within the file
set.
Object Representation code for the object. A FF A constant value of "FF" OBRP
Representation for composite objects.
[M]
(^)Attribute Foreign identifier for Attribute Primary ATID
ID (R) module record.
(^)Foreign ID Foreign identifier of module record for FRID
(O) object that is a part of this composite.
[M] The order of the instances of this field
is significant when referencing linear
objects; the order indicates the sequence
of construction of the composite object in
terms of its component objects.
(^)Composite Foreign identifier of Composite module CPID
ID (R) record that includes this composite
object.
5.6 Vector Modules
The vector modules are designed for the transfer of vector data as objects; that is, each module record defines a vector object including links to its component parts as well as a possible direct link to its attribute data.
The vector objects of 2.3 have been grouped into corresponding modules according to the similarity in data fields required to represent the object.
Aside from attributes, the modules that implement the vectorspatial objects are: Point, Line, Arc, Ring, Polygon, and Composite.
As more than one type of object can be stored in each type of module, the type of object represented is expressed through an object representation code. Table 31 summarizes the assignment of vectorobjects to modules and lists the object representation code for each.
The vectorspatial objects may include both the downward "is composed of" definition in the composite module and the upward "composes" definition in the Point, Line, Arc, Ring, and Polygon modules.
Table 31 Modules and vector-based object representations
---------------------------------------------------------------------------------
Module type Object representation Representation code
----------- -------------------------------- -------------------
Point-Node Point NP
Entity point NE
Label point NL
Area point NA
Node, planar graph NO
Node, network NN
Line String LS
Link LQ
Complete chain LE
Area chain LL
Network chain, planar graph LW
Network chain, nonplanar graph LY
Arc Circular arc, three point center AC
Elliptical arc AE
Uniform B-spline AU
Piecewise Bezier AB
Ring Ring with mixed composition RM
Ring composed of strings RS
Ring composed of chains RU
Ring composed of arcs RA
Polygon G-polygon PG
GT-polygon composed of rings PR
GT-polygon composed of chains PC
Universe polygon composed of rings PU
Universe polygon composed of chains PW
Void polygon composed of rings PV
Void polygon composed of chains PX
---------------------------------------------------------------------------------
5.6.1 Point
The Pointmodule shall be used to transfer points of the following type: generic point, entity point, label point, area point, and node.
Table 32 Point-Node
FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC
Point-Node (P) PNTS
[M]
Module Name A unique identifier for the module. A Alphanum Name shall begin with an MODN
[M] alphabetic character
other than SPACE.
Record ID Point object record identifier. I Integer Unsigned integer. With RCID
[M] Module Name shall form
unique ID within the file
set.
Object Representation code for the object. A NP Point OBRP
Representation NE Entity point
[M] NL Label Point
NA Area Point
NO Node, planar graph
NN Node, network
(-)Spatial Spatial address of point (single spatial SADR
Address (N) address).
[M/NP|NE|NL|NA
]
(^)Attribute Foreign identifier for Attribute Primary ATID
ID (R) module record.
[M/NE|NL]
(^)Line ID (O) Contains foreign identifier of line LNID
[X/NP|NE|NL| associated with the node. The required
NA] ordering for the instances of this field
relates to the occurrence of adjacent
lines around the node.
(^)Area ID (O) [X/NP|NN] Contains foreign identifier of area or ARID
polygon associated with the node, area
point, label point, or entity point.
The required ordering for the instances
of the field relates to the occurrence
of adjacent areas around the node.
(^)Composite Contains foreign identifier of Composite CPID
ID (R) module record that includes this Point-
Node.
(^)Representa- Contains foreign identifier of the RPID
tion Module ID Representation module record.
(O)
(-)Orientation Spatial address of orientation point. OSAD
Spatial This point combined with the location
Address (O) point determines the angle of the text
[X/NP|NE|NA| string. If omitted, the text string is
NO|NN] placed horizontally. If more than one
point is provided, then these points
combined with the location point define a
curve along which the text string is
placed. If a total of three points are
provided, the location point is the start
point of the circular arc. The first
orientation point is an intermediate point
on the circular arc between the location
point and the second orientation point,
which lies on the circular arc. If more
than three points are provided, the arc is
defined as a second order piecewise Bezier
arc.
(^)Attribute Contains foreign identifier of the PAID
Primary Attribute Primary module record that
Foreign ID (O) includes the attribute to be annotated.
[X/NP|NE|NA|
NO|NN]
(N)Attribute Name of attribute subfield to be A Gr-chars Attribute subfield name ATLB
Label (O) annotated. as in the Attribute
[X/NP|NE|NO| Primary and Secondary
NN] modules.
(-)Symbol Address (N) Spatial address of orientation point (single SSAD
Orientation [X/NL] patial address). This point combined with the
Spatial location point determines the angle of symbol
representing the point. If omitted, the
symbol is placed horizontally.
5.6.2 Line
The Line module shall be used to transfer spatial objects of the following type: string, link, complete chain, area chain, and network chain (both planar and nonplanar).
When the object type is that of a chain (LE, LL, LW, or LY), the Chain Component ID field may be used instead of the Spatial Address field. The Chain Component ID then refers to records in other Line or Arc modules.
This allows for the transfer of a chain entirely composed of arcs, or a chain made up of a mixture of arcs and strings. The Chain Component ID and Spatial Address fields are both listed in the module description table, but only one of the two fields shall be used in any particular Line module, according to the rules for optional fields of 4.1.3.3.6.
Table 33 Line
FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC
Line (P) LINE
[M
Module Name A unique identifier for the module. A Alphanum Name shall begin with an MODN
[M] alphabetic character
other than SPACE.
Record ID Line object record identifier. I Integer Unsigned integer. With RCID
[M] Module Name shall form
unique ID within the file
set.
Object Representation code for the object. A LS String OBRP
Representation LQ Link
[M] LE Complete chain
LL Area chain
LW Network chain, planar
LY graph
Network chain, nonplanar
graph
(^)Attribute Foreign identifier for Attribute Primary ATID
ID (R) module record.
The following two fields are to be used for complete and area chains (object representation codes LE and LL)
and shall reference the topologically correct GT-Polygons (see 2.3.4.5.2, Two-dimensional Manifold).
(^)Polygon ID Foreign identifier of left Polygon or Area PIDL
Left (N) Point module record.
[M/LE|LL]
[X/LS|LW|LY|LQ
]
(^)Polygon ID Foreign identifier of right Polygon or PIDR
Right (N) Area Point module record.
[M/LE|LL]
[X/LS|LW|LY|LQ
]
The following two fields are to be used for links and for complete and network chains (object representation codes
LQ, LE, LW and LY) and shall reference the topologically correct nodes (see 2.3.4.5, graph).
(^)Startnode Foreign identifier of start node Point- SNID
ID (N) Node module record.
[M/LE|LW|LY|
LQ]
[X/LS|LL]
(^)Endnode ID Foreign identifier of end node Point-Node ENID
(N) module record.
[M/LE|LW|LY|
LQ]
[X/LS|LL]
(^)Chain Foreign identifier of module record of CCID
Component ID other Arc or Line module. The order of
(O) the instances of this field indicates the
[X/LS|LQ] sequence of construction of the chain
[A/LE|LL|LW|LY composed of arcs, or of strings and arcs.
/Spatial
Address]
(-)Spatial Spatial address of line point. The order SADR
Address (O) of the instances of this field indicates
[M/LS] the construction of the line in terms of
[A/LE|LL|LW|LY vertices. Note that even if the line
/Chain module record includes foreign identifiers
Component ID] of the nodes (for chains and links), the
spatial addresses of the nodes, although
redundant, shall be included here.
(^)Composite Foreign identifier of Composite module CPID
ID (R) record which includes this line.
(^)Representa- Contains foreign identifier of the RPID
tion Module ID Representation module record.
(O
5.6.3 Arc
An Arc module shall be used to transfer the arc object as defined in 2.3.2.3. Arc modules are used to transfer only the geometry of the curved line and rudimentary attributes. If topology is required, then a chain shall be used to reference the appropriate Arc module record, and the topology shall be associated with the chain object.
An Arc module shall be used to transfer arcs of the following types:
and other curves of the following types:
For both circular and elliptical arcs, the start and end addresses shall occur in counterclockwise order. Total sweep angle for circular arcs and elliptical arcs shall be less than or equal to 360 degrees.
Notes:For circular arcs, radius and start vector are defined by the start address. Arcs with a sweep angle of 360 degrees have the same start and end addresses.
The Order subfield shall not be used with circular arcs or elliptical arcs.
All parametric descriptions shall apply only to the horizontal components of the spatial address. All other components may be encoded; however, these components shall be ignored in reconstructing objects based on these descriptions.
Table 34 Arc
FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC
Arc (P) ARC
[M]
Module Name A unique identifier for this Arc module. A Alphanum Name shall begin with an MODN
alphabetic character
other than SPACE.
Record ID Arc object record identifier. I Integer Unsigned integer; with RCID
Module Name shall form
unique ID within the file
set.
Object Representation code for the object. A AC Circular arc, three point OBRP
Representation center.
AE Elliptical arc.
AU Uniform B-spline.
AB Piecewise Bezier.
Surface Indicates the type of surface on which the A PLAN PLANAR; reconstruction of SRFC
reconstruction shall take place. arc occurs only on a
planar surface.
ELIP ELLIPSOIDAL;
reconstruction of arc
occurs on an ellipsoidal
surface.
Order Value of the largest exponent in the I Integer <9, positive value ORDR
[X/OBRP=AC|AE] parametric expression. indicating the value of
the largest exponent in
the parametric
expression.
Arc Address [M/OBRP= [X/OBRP= Address
(N) AC|AE] AU|AB] (-)Center
ARAD
Spatial address
of the center
point of the
arc. CTAD
(-)Start AddressSpatial address of the start point of the STAD
arc and also defining the start vector
(-)End Address Spatial address of the end point of the ENAD
arc and also defining the end vector.
Ellipse Address ELAD
(N)
[M/OBRP=AE]
[X/OBRP=AC|AU|AB
] (-)Conjugate Spatial address of a point on the major MJRA
Diameter Point -axis and the ellipse.
Major Axis
(-)Conjugate Spatial address of a point on the minor MNRA
Diameter Point -axis (placed perpendicular to the major
Minor Axis axis) and the ellipse.
(-)Curve Address Spatial address for control points on CADR
(O) curve.
[M/OBRP=AU|
AB]
[X/OBRP=AC|AE]
(^)Attribute ID Foreign identifier for Attribute Primary ATID
(R) module record
(^)Composite ID Foreign identifier of composite module CPID
(R) record which includes this arc.
(^)Representa- (O) Contain foreign identifier of the Representation module RPID
tion Module ID Representation modulerecord.
5.6.4 Ring
The Ring module shall be used to transfer the ring object as described in 2.3.2.6. A ring is defined to consist of either strings, arcs, or chains, which are oneline objects. However, four types of chains can be represented in the Line module, and arcs can be referenced directly, or indirectly as components of chains. The Object Representation Codes for Rings are "RM" for a ring of mixed composition, "RS" for a ring of strings, "RU" for a ring of chains (any type), and "RA" for rings directly composed of arcs. Because strings, arcs, and chains are all stored in the Line module or can be referenced through the Line module, the composition of a Ring is primarily expressed as a sequence of Line foreign identifiers. But Rings can be expressed in the form of arcs as well, so that the same foreign identifier field may be used to refer to Arc module records. Because rings are parts of polygons that themselves can be linked to attributes, there is no forward attribute link provided in this module.
Table 35 Ring
FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC
Ring (P) RING
[M]
Module Name A unique identifier for the module. A Alphanum Name shall begin with an MODN
[M] alphabetic character
other than SPACE.
Record ID Ring object record identifier. I Integer Unsigned integer; with RCID
[M] Module Name shall form a
unique ID within the file
set.
Object Representation code for the object. A Alpha Two characters as OBRP
Representation specified in Table 31
[M] under Representation
Code.
(^)Line or Arc Foreign identifier of Line or Arc module LAID
Foreign ID (O) record for line or arc object as part of
[M] the ring. The order of the instances of
this field indicate the sequence of
construction of the ring in terms of its
line in a clockwise direction with
reference to the interior of the ring.
(^)Polygon ID Foreign Identifier of a polygon of which PLID
(R) the ring is a part.
[M]
5.6.5 Polygon
The Polygon module shall be used to transfer polygons as defined in 2.3.3. There are two types of polygons: G, and GT. Geometry only polygons (G) consists of one outer ring, and zero or more inner rings. This module therefore contains a secondary field that is a foreign identifier for its member rings. The order of the rings is significant. The outer ring shall occur first, followed by the inner rings, if any.
The geometrypolygons (GT-polygons) can also be transferred in terms of constituent rings, but an alternative is to use chains instead of rings. For this purpose the module has a secondary field that is a foreign identifier for its member chains. The order of the chains is significant but is not specified. Either one or the other method may be used, so that in a given module either the Ring ID field or the Chain ID field may be present, but not both. When rings are used for GT, the ordering requirements are the same as for G.
Table 36 Polygon
FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC
Polygon (P) POLY
[M]
Module Name A unique identifier for the module. A Alphanum Name shall begin with MODN
[M] alphabetic character
other than SPACE.
Record ID Polygon object record identifier. I Integer Unsigned integer; with RCID
[M] Module Name shall form
unique ID within the file
set.
Object Representation code for the object. A Alpha Two characters as OBRP
Representation specified in Table 31
[M] under Representation
code.
(^)Attribute Foreign identifier for Attribute Primary ATID
ID (R) module Record.
(^)Ring ID (O) Foreign identifier of Ring module record RFID
[M/PR] for ring object as part of the polygon.
[X/PC] Order is significant, the outer ring shall
be referenced first.
(^)Chain ID Foreign identifier of Line module record CHID
[X/PR|PU|PV] for chain object as part of the polygon.
Order is significant, but not specified.
(^)Composite Foreign identifier of Composite module CPID
ID (R) record that includes this polygon.
(^)Representa- Foreign identifier of the Representation RPID
tion Module ID module record. This representation module
(O) refers to the area fill representation.
The boundary is represented via the line
object.
5.7 Raster Modules
The raster modules can accommodate image data, digital terrain models, gridded GIS layers, and other gridded data. For the purposes of this specification, raster, grid, or image data will all be referred to as raster data. A raster object may consist of different layers, each layer being composed of a number of grid cells or pixels (as defined in 2.3.3.4 and 2.3.3.5), henceforth to be referred to as cells, arranged by row and column.
Many different types of organizational schemes exist for raster data. To distinguish between the main aspects of these schemes, the concept of an object representation code has been carried through to this transfer form. For this code to be applied consistently, a raster object definition is needed. A raster object consists of one or more related layers of cells arranged in such a way that corresponding cells between layers are registered to a common scan reference system (to be defined) and overlap, but need not be of the same spatial extent.
There are two different types of raster modules: the Raster Definition module, and the Cell module. A typical transfer of a raster object can require one Raster Definition module, several Cell modules, and one corresponding Registration module.
5.7.1 Subfield Specifications
The following information is necessary to interpret the meanings of the subfields in the Raster modules.
5.7.1.1 Object Representation Codes . The object representation code for a raster reflects its structural organization of which there are three main components, namely sequencing (such as layer sequential), encoding (such as run encoding), and whether or not attributes are used at the cell level. Not all combinations are meaningful. In the following, each of these three structural components will be discussed in turn.
5.7.1.1.1 Sequencing . Sequencing refers to the pattern in which the cells of the raster are arranged. A frequently used synonym for layer is "band." The most frequently encountered organizations are usually referred to as band sequential and band interleaved by line. These are also the two sequences supported by this specification. Other possibilities exist such as row major or column major, and different scan patterns may exist for each.
5.7.1.1.2 Encoding . Encoding refers primarily to the way in which similar cells are recorded. In this specification, two types of encoding are considered: straight encoding and run encoding. With straight encoding, all cells are recorded in sequence. With run encoding, a cell value and its position (either by row and column or by ground coordinates) are recorded, and following cells with similar values are omitted. Run encoding as defined in this specification is not the same as runencoding, although the two concepts are very similar. Run encoding derives the position of a cell in the raster from its specified coordinates, whereas run encoding derives this position from the position of the previous cell and a specified run length.
5.7.1.1.3 Attributes for each cell . There is a capability to link attributes with each cell. When this capability is used, structuring by layer becomes a moot issue, because all information otherwise expressed as different layers is contained in the attributes.
Table 37 summarizes the object representations for raster data based on these organizational components.
Table 37 Raster Object Representation Codes ___________________________________________________________________ Representation Code Meaning of Representation Code ___________________ ______________________________ GI Layer sequential, straight encoding. GJ Layer interleaved by line, straight encoding. GK Layer sequential, run encoding. GM Run encoding with attributes for each cell.___________________________________________________________________
The main components of the Raster Definition module are: (1) a primary field consisting of subfields pertaining to the entire raster, (2) a repeatable Layer Definition field with information pertaining to each layer of the raster, and (3) attribute foreign identifier fields to form a link with attributes associated with each layer and with the entire raster. A general comment field is available for each layer as well.
The module record of the Cell module has been designed so that each module record can hold information on a number of related cells. Designating these related cells as a "stream" to facilitate the following explanation, examples of a stream are a single scan line of an image, a number of layer-interleaved scan lines as a part of an image, a run in a run-encoded image, a single cell, a block of a quad tree, or even an entire layer of a raster. A stream does not necessarily start at the beginning of a line or row, but can start in the middle or row i, proceed through rows i through n terminate somewhere in row n.
The main components of the Cell module are: (1) a primary field with the number of cells per logical scan line and a row and column index of a point location associated with the stream, (2) a full spatial address of a point associated with the stream, (3) an attribute foreign identifier for the stream, and (4) a Cell Values field with a number of layer subfields, each to be repeated for each cell value. The attribute link can be used, for instance, to store ancillary data with a layer interleaved scan line, or it can be used to associate a full set of attributes with each run encoded cell.
Combinations of the different components of the Raster Definition and Cell modules allow many different organizations of the data, but only those represented by the Object Representation codes shall be present in a spatial data transfer. They are described in the following using the BNF notation of 4.1.3.2.
5.7.1.1.4 Object Representation Code GI . In the layer sequential, straight encoding organization, the layers are divided among a number of Cell module records with the first set containing the first layer, the second set the second, and so on. Most often it will be most convenient when each set of module records for a layer is contained within its own cell module, but this is not a requirement. The following BNF makes this assumption:
<raster> ::=<Raster Definition module>{<Cell module>}
<Raster Definition module> ::=<Raster Definition primary field>
{<Layer Definition field>}
<Cell module 1> ::={<Cell module record for Layer 1>}
.
.
.
<Cell module n> ::={<Cell module record for Layer n>}
<Cell module record for Layer 1> ::=<Cell primary field>
<attribute foreign identifier>
<Cell Values field>
<Cell Primary field>::=<Row Index subfield>
<Column Index subfield>
<Cell Values field> ::= {<Layer 1 subfield>}
Here the repetitions of the Layer subfields contain the data for a stream that may consist of multiple lines.
5.7.1.1.5 Object Representation Code GJ . The layer interleaved by line, straight-encoding organization is expressed as:
<raster> ::=<Raster Definition module><Cell module>
<Raster Definition module> ::=<Raster Definition primary field>
{<Layer Definition field>}
<Cell module> ::={<Cell module record>}
<Cell module record> ::=<Cell primary field>
<attribute foreign identifier>
<Cell Values field>
<Cell Primary field>::=<Row Index subfield>
<Column Index subfield>
<Cell Values field> ::=<Layer 1 subfield>}
.
.
.
{<Layer n subfield>}
Here, the iterations of the Layer subfields also contain the data for a stream, but all the data for all layers are together in the same Cell Values field.
5.7.1.1.6 Object Representation Code GK . The layer sequential, run-encoding organization is very similar to the corresponding straight-encoding organization with the exception that the layer subfield is not repeated because it contains the value for a run. The Row Index and Column Index subfields of the Cell primary field are required to be used.
<raster> ::=<Raster Definition module>{<Cell module>}
<Raster Definition module> ::=<Raster Definition primary field>
{<Layer Definition field>}
<Cell module 1> ::={<Cell module record for Layer 1>}
.
.
.
<Cell module n> ::={<Cell module record for Layer n>}
<Cell module record for Layer 1> ::= <Cell primary field>
<attribute foreign identifier>
<Cell Values field>
<Cell primary field> ::=<Row Index subfield>
<Column Index subfield>
<Cell Values field> ::=<Layer 1 subfield>
5.7.1.1.7 Object Representation Code GM . The run-encoding organization with attributes for each cell is expressed as follows:
<raster> ::=<Raster Definition module> <Cell module><Raster Definition module> ::=<Raster Definition primary field>
<Cell module> ::={<Cell module record>}
<Cell module record> ::=<Cell primary field>
<attribute foreign identifier>
<Cell primary field> ::=<Row Index subfield>
<Column Index subfield>
Layers play no role in this organization because all relevant data are stored in the attributes. Therefore, the Layer Definition fields of the Raster Definition module and the Cell Values field of the Cell module shall be absent. The Row Index and Column Index subfields of the Cell primary field shall be present.
5.7.1.2 Spatial Referencing . Spatial referencing for raster data shall be governed by parameters transferred in the Internal and External Spatial Reference modules. For raster data with a known and expressed relationship to latitude and longitude, spatial registration conformance level 2 (see 5.2.4.2) might be the best registration level, allowing the raster data to remain untransformed in a specified projection that is not one of the three preferred systems (GEO, UTM/UPS, or SPCS). Use of one of these three preferred systems might result in a loss of information because of transformation.
The following coordinate systems, defined in 4.1.3.5, are further specified for use with raster data as follows.
5.7.1.2.1 The scan reference system . This is a Cartesian leftright, rowcoordinate system with its origin at the center of the first cell of a layer of the raster. Whether the system is leftrightdepends on whether the scan origin of the raster is in the top left, top right, bottom left, or bottom right of the raster. Row or column indices (coordinates) are always >= 0 and are always discrete integer units. The origin may be defined to occur at (0,0) or (1,1). Different layers can have different scan reference systems. However, the origin parameters are the only parameters that may be changed from layer to layer; other characteristics such as leftright-handedness shall be the same for the entire raster.
5.7.1.2.2 The internal reference system . This is a Cartesian rightsystem with its origin located somewhere within the raster. Row or column type coordinates can be negative and can have fractional units. This system applies to the entire raster.
5.7.1.2.3 The external reference system . This is a system that has a known relation to latitude and longitude and is specified by the parameters contained in the External Spatial Reference module.
The transformation from the scan reference system to the external reference system is accomplished as follows:
The Scan Origin subfield of the Raster Definition field defines where the origin of the scan reference system is located with respect to the raster such as top left, top right, bottom left, or bottom right. The First Scan Direction subfield indicates whether the data are presented by row or column. This provides sufficient information for converting from a leftrightscan reference system to a rightinternal reference system.
5.7.1.3 Default Implementation . The Raster Definition module has a strongly recommended default implementation in which a number of subfields are omitted according to the rules governing the optionality of subfields as defined in 4.1.3.3.6 and the use of nulls and defaults as specified in 4.1.3.3.9. Subfields with an implied default value are indicated by the symbol "(d)" preceding the field name in the Module Composition Table, as defined in 4.2.3.7. Table 38 lists the subfields that shall be omitted in the default implementation, as well as the implied default values for these subfields. Other subfields may be omitted as well, but none of the fields of table 38 shall be present in a default implementation.
Table 38 Subfields omitted in the default raster implementation___________________________________________________________________ Subfield name Default value _____________ _____________ Data Compression NONCOM Scan Origin TL Scan Pattern LINEAR Tesseral Indexing NOTESS Number of Lines per Alternation 1 First Scan Direction R Aspect Ratio 1. Scan Origin Row 1 Scan Origin Column 1 Row Offset Origin 0 Column Offset Origin 0 Intracell Reference Location TL ____________________________________________________________________
5.7.1.4 Absence of Module Name in the Cell Module . The Cell primary field in the Cell module optionally may not include the same Module Name, Record ID, and Object Representation Code subfields as found in other modules, because the instances of these subfields will become highly repetitive for large rasters. The name of the Cell module shall therefore be recorded elsewhere, and this shall be done in the Cell Module Name field of the Raster Definition module, and (or) in the Catalog/Crossmodule. The location of the Cell module shall be recorded in the Catalog/Directory module. The Raster Definition module and the Cell module may be transferred in conjunction, with the first Cell field signaling the beginning of the Cell module.
5.7.1.5 Data Compression . Data that are represented by object representation code GK are compressed using the run encoding technique as explained in 5.7.1.1. However, it is recognized that other data compression techniques are allowed. For this purpose two data compression subfields are included in the primary field of the Raster Definition module. The first shall be used to indicate whether a compression method is in effect or not, and the second shall contain a name or description of the compression method. Compression methods are sufficiently application dependent to prevent current standardization. Therefore, decompression parameters such as looktables shall be transferred as primary attributes of the Raster Definition module. The link with the decompression parameters shall be established through use of the Attribute ID field of the Raster Definition module.
Data compression shall only be in effect within the subfields of the Cell Values field of the Cell module and occurs therefore within the implementation records. All parameters except the decompression parameters shall apply to the data in their uncompressed form.
5.7.1.6 Tesseral Indexing . The use of the raster portion of the standard is not restricted to raster transfer using a row-column layout. Rasters can be divided into tiles of regular or irregular size and can be transferred on a tile basis. To fit this type of organization into the SDTS model, each tile is equated with a stream. Each stream (tile) can be preceded by a row-column address, or alternately, a tesseral index can be used. A tesseral index is not the equivalent of a row and column address, because the index can contain the extent of the tile as well through the use of wildcard components. The type of tesseral index shall conform to the contents of the Scan Pattern subfield of the Raster Definition module, and can therefore only be a Linear, Boustro, Morton, or Peano key (see Appendix F). If the pixel values for a tile are constant, as can be the case for quad trees, the pixel value should be stored only once, and the encoding type is then run encoding with an object representation code of GK (or possibly GM).
Use of tesseral indexing shall be indicated through the Tesseral Indexing Description subfield, and the type of data structure, particular method, and meaning of the index digits shall be specified in the Tesseral Index Format subfield.
5.7.1.7 Radiometric Information . For remotely sensed images, radiometric information is of utmost importance for correct utilization of the imagery. SDTS must therefore be able to carry this information. Unfortunately with the present state of the art, it is impossible to standardize a set of selected radiometric parameters. Attributes shall therefore be used to transfer radiometry. Primary and secondary attribute tables can be defined for use at the raster, layer, and stream levels. Reference to these tables shall be made through the appropriate Attribute foreign identifiers for the different levels.
5.7.1.8 Cell Encoding. Various methods are possible for assigning a unique attribute value to each cell in a raster. The Cell Encoding Type subfield of the Raster Definition module specifies the method used. The possible values are: "L", indicating that the presence or absence of the attribute is coded for each cell; "D", indicating that the value assigned occupies the greatest area of the cell; "F", indicating that the value assigned is the one that occurs most frequently within the cell; "V", indicating that the value is a continuous numeric variable measured at the center of the cell; or "X", indicating that the value is a code representing a value defined in a corresponding Data Dictionary/Domain module.
5.7.2 Raster Definition
This module is used to define the parameters and layout for the raster.
Table 39 Raster Definition
FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC
Raster RSDF
Definition (P)
[M]
Module Name A unique identifier for the module. A Alphanum Name shall begin with MODN
[M] alphabetic character
other than SPACE.
Record ID Raster object record identifier (applies I Integer Unsigned integer; with RCID
[M] to entire raster). Module Name shall form a
unique ID within the file
set.
Object Representation code for the raster. A GI Layer sequential, OBRP
Representation straight encoding.
[M] GJ Layer interleaved by
line, straight encoding.
GK Layer sequential, run
GM encoding
Run encoding with
attributes.
Acquisition Sensor or acquisition device from which A Gr-chars Any combination of AQMD
Device/Method the data originated and method by which graphics characters.
the data were acquired/processed.
Acquisition Date Acquisition date for the data. A cs: FIPSPUB 4 specified date. AQDT
FIPSPUB4
Comments Any desired comments pertaining to the A Gr-chars Any combination of COMT
entire raster. graphics characters.
Cell Module Name Name of Cell module to which the Raster A Alphanum Name of Cell module to which CMNM
[O/"Catalog/Cross Definition module applies. Raster Definitionmodule
-Reference"] applies.
[M]
Default Signifies whether the module version is a A DEF Default Implementation DEFI
Implementation default implementation or not. NON Nondefault Implementation
[M]^M
(d)Data Signifies whether data compression is in A COM Compressed data CMPR
Compression effect or not. NONCOM Noncompressed data
[M/Default
Implementation =
NON]
Data Compression Describes the data compression method A Gr-chars Any graphics characters CMMD
Method used.
[M/Data
Compression =
COM]
Note: The next group of subfields contains layout and ancillary information pertaining to all layers.
Row Extent Number of rows in the union of the spatial I Integer Unsigned integer >= 1. RWXT
[M] extent of all layers, including the origin
of the scan reference system.
Column Extent Number of columns in the union of the I Integer Unsigned integer >= 1. CLXT
[M] spatial extent of all layers, including
the origin of the scan reference system.
(d)Scan Origin Location of the first cell with respect to A TL Origin top left. SCOR
[M/Default the image viewed as a rectangle. TR Origin top right.
Implementation = BL
NON] BR Origin bottom right
(d)Scan Pattern Scan pattern for the raster. A Linear Scan by row or by column SCPT
[M/Default (begin-end-begin-end..).
Implementation = Boustro Boustrophedonic scan order
NON] (begin-end-end-begin..).
Morton Morton or Z order.
Peano Hilbert-Peano order.
(d)Tesseral Signifies whether tesseral indexing is A TESS Tesseral indexing used. TIDX
Indexing used or not. NOTESS No tesseral indexing
[M/Default used.
Implementation =
NON]
Tesseral Index Format for the tesseral index. A I Implicit-point (integer) TIFT
Format B Binary
[M/Tesseral BI8 8-bit signed integer
Indexing=TESS] BI16 16-bit signed integer
BI24 24-bit signed integer
BI32 32-bit signed integer
BUI Unsigned integer
BUI8 8-bit unsigned integer
BUI16 16-bit unsigned integer
BUI24 24-bit unsigned integer
BUI32 32-bit unsigned integer
C Character mode bitfield
Tesseral Indexing Gives further information on data A Gr-chars Any combination of TIDS
Description structure, indexing method, and meaning of graphics characters.
[M/Tesseral index components.
Indexing=TESS]
(d)Number of Number of line per alternation in the scan I Integer Unsigned integer >= 1 ALTN
Lines per pattern.
Alternation
[M/Default
Implementation =
NON]
(d)First Scan Direction (row or column) of the first A R First scan proceeds by FSCN
Direction scan. row.
[M/Default C First scan proceeds by
Implementation = column.
NON]
(d)Aspect Ratio Aspect of cells: cell row spacing R REAL Aspect ratio of cells: ASPR
[M/Default divided by cell linespacing. cell row spacing divided
Implementation = by cell column spacing.
NON]
Number of Layers Number of cell layers (e.g., spectral I Integer Unsigned integer >= 1 NLAY
bands).
(^)Raster Foreign identifier for Attribute Primary RATP
Attribute ID module record. Attributes pertain to
(R) entire raster.
Layer One Layer Definition field for each data LDEF
Definition (O) layer. The ordering for the instances of
[M] this field is with respect to the layers
of the raster data as they occur in the
Cell module.
Layer Name Layer name, description or code. A Alphanum Name shall begin with LNAM
alphabetic character
Cell Code Cell encoding type. A L Presence/absence of theme CODE
in pixel.
D Dominant type of area.
F Dominant type by
V frequency.
Value of a continuum
X attribute variable at
cell center.
Assigned code, shall be
defined in Data
Dictionary/Domain module.
Format Cell format. A I Implicit-point(integer) FMT
[M] R Explicit-point,unscaled
(fixed point real)
S Explicit-point,scaled
(floating point real)
BI8 8-bit signed integer
BI16 16-bit signed integer
BI24 24-bit signed integer
BI32 32-bit signed integer
BUI Unsigned integer
BUI8 8-bit undigned integer
BUI16 16-bit undigned integer
BUI24 24-bit undigned integer
BUI32 32-bit undigned integer
BFP32 32-bit floating point real
BFP64 64-bit floating point
C Character mode bitfield
A Alphanumeric
Bitmask Defines bitfield length and active bits. C C An ordered list BMSK
corresponding to unused
and active positions of
bitfield bits.
Number of Rows Number of rows in the layer I Integer Cannot exceed Row Extent. NROW
Number of Colum Number of cells (columns) in a row of the I Integer Cannot exceed Column NCOL
layer. Extent
Minimum Value Data minimum value A|I|R|S Alphanum Minimum cell value for MINV
|B|C Integer layer.
Real Data type shall
Binary correspond to the format
in the Format subfield.
Maximum Value Data maximum value. A|I|R|S Alphanum Maximum cell value for MAXV
|B|C Integer layer.
Real Data type shall
Binary correspond to the format
in the Format subfield.
Note: The next group of subfields has information about the scan reference system origin for the layer.
(d)Scan Origin Designates whether row index starts at 0 I 0 First cell occurs at row SORI
Row or 1. 1 0.
[M/Default First cell occurs at row
Implementation = 1.
NON]
(d)Scan Origin Designates whether column index starts at I 0 First cell occurs at SOCI
Column 0 or 1. 1 column 0.
[M/Default First cell occurs at
Implementation = column 1.
NON]
(d)Row Offset Number of rows of offset of scan origin to I Integer Unsigned integer >= 1. RWOO
Origin internal reference system origin.
[M/Default
Implementation =
NON]
(d)Column Offset Number of columns of the offset of scan I Integer Unsigned integer >= 1. CLOO
Origin origin to internal reference system
[M/Default origin.
Implementation =
NON]
(d)Intracell Relative location of the internal A TL Top left of cell INTR
Reference reference system origin within the pixel. TR Top right of cell
Location BL Bottom left of cell
[M/Default BR Bottom right of cell
Implementation = CE Center of cell
NON]
comment Comments pertaining to the specific layer. A COMT
(^)Layer Foreign identifier for Attribute Primary LATP
Attribute ID module record. Attributes pertain to a
(O) specific layer. The order of the
instances of this field shall correspond
to the order of the instances of the Layer
Definition field.
(^)Composite Contains foreign identifier of Composite CPID
ID (R) module record that includes this Raster.
5.7.3 Cell
This module contains the actual data values for the raster.
Table 40 Cell
FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC
Cell (P) CELL
[M]
Module Name A unique identifier for the module. A Alphanum Name shall begin with MODN
alphabetic character
other than SPACE.
Record ID A number for the module record, unique I Integer Unsigned integer; with RCID
within the module. Module Name shall form
unique ID within the file
set.
Number of Cells Number of cell fields in a logical line or I Integer Unsigned Integer >= 1 NCEL
[X/GK] in a run (for a run this value is 1).
Row Index Row index of first cell in module record. I Integer Unsigned Integer >= 1 ROWI
[M/GK]
[O/GK/Tesseral
Index]
Column Index Column index of first cell in module I Integer Unsigned Integer >= 1 COLI
[M/GK] record.
[O/GK/Tesseral
Index]
Tesseral Index Tesseral index for the tile contained in I|B Integer Unsigned Integer TIND
[M/GK] the module record. Binary
[O/GK/Row Index +
Column Index]
(-)Spatial Spatial address of first cell in module SADR
Address (N) record.
(^)Attribute Foreign identifier for Attribute Primary ATID
ID (R) module record.
[M/GK]
Cell Values Contains cell data values for part or all CVLS
(O) of a stream, and for part of, all, or one
[X/GK] or more layers, depending on the object
representation code. The ordering of the
fields corresponds to the ordering of the
Layer Definition field in the accompanying
Raster Definition module.
(#)Cell Value Variably repeating subfield of the Cell A|I|R Alphanum As indicated by the CVAL
[X/GK] Values field, in which the data for this S|B|C Integer Format subfield in the
field are stored. Real Raster Definition module.
Binary
5.8 Graphic Representation Modules
Each vector based object in the SDTS transfer except Ring can include a foreign identifier that references a representation module. The representation module reference determines how the object should be portrayed within fixed product scale ranges (i.e., scale ranges, Small Scale Minimum and Large Scale Maximum, are given in the appropriate subfields for this module).
The parameters associated with the representation module indexed by the foreign identifier determine the values used by graphical devices to produce a display or plot. The Computer Graphics Metafile (CGM) standard provides a device-independent format for the transmission of picture description data. The SDTS standard and the CGM standard (ANSI X3.122-1986) follow the same formats for definition of the graphical representation of an object. To support cartographic spatial applications, several parameters have been modified to present parameters in a standard form used by cartographers. The content is the same and the format differences are clearly noted. CGM shall be used as the reference for the modules.
The graphic representation modules include the following:
Table 41 relates the module type with the representation code and lists the types of objects that reference the module type.
Note:The Register of Graphical Items (see 1.3.16) may also be used to support the
Line, Symbol, and Area Fill graphical representation modules.
Table 41 Representation module type and object representations
-----------------------------------------------------------------------
Module Object
type representations Object type
Text NL Label Point
Line LS String
LQ Link
LE Complete Chain
LL Area Chain
LW Network Chain (planar graph)
LY Network Chain (nonplanar graph)
AC Circular arc, three point center
AE Elliptical arc
AU Uniform B-spline
AB Piecewise Bezier
Symbols NP Point
(points) NE Entity point
NA Area point
NO Node, planar graph
NN Node, network
Area fill PG G-polygon
PR GT-polygon composed of rings
PC GT-polygon composed of chains
PU Universe polygon composed of rings
PW Universe polygon composed of chains
PV Void polygon composed of rings
PX Void polygon composed of chains
-----------------------------------------------------------------------
The representation modules use an index into the Color and Font Index modules. These modules reference primitive graphics elements defined by a registration authority, such as the one for CGM or defined explicitly in a Data Dictionary/Domain module. For complex graphic representations, the formats may be transmitted using a separate SDTS transfer that includes a graphic representation for each symbol or line representation option. The authority shall then be the associated transfer modules.
5.8.1 Text Representation
The Text Representation module provides the graphic data necessary to portray the text.
Table 42 Text Representation
FIELD NAME SUBFIELD NAME FIELD/SUBFIEL DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC
Text TEXT
Representation
(P)
[M]
Module Name A unique identifier for this Text A Alphanum Name shall begin with an MODN
[M] Representation module. alphabetic character
other than SPACE.
Record ID A number for the module record, unique I Integer An unsigned integer RCID
[M] within the module. unique within the
representation module.
With Module Name shall
form unique ID within the
file set.
Base Scale The scale denominator used to translate I Integer A valid numeric scale BSCL
[M] the scale-independent data transferred in denominator.
the SDTS transfer to scale-dependent
graphic attributes such as text height.
Small Scale The smallest appropriate scale denominator I Integer A valid numeric scale SSCL
Minimum for the graphics representation. denominator.
Large Scale The largest appropriate scale denominator I Integer A valid numeric scale LSCL
Maximum for the graphics representation. denominator.
Color Index Index corresponding to a value of the I Integer Unsigned integer. CLDX
[M] Record ID subfield in the Color Index
module.
Character Height Specifies the distance measured in R Real Character height measured CHHT
[M] millimeters between the capline and the in millimeters.
baseline of the font for the graphics
portrayal of the spatial data at the base
scale.
Font Index Index corresponding to a value of the I Integer Unsigned integer. FTDX
[M] Record ID subfield in the Font Index
module.
(d)Text Path Specifies the writing direction of the A RIGHT Right, TPTH
text string. Path directions are right, LEFT left,
left, up, or down. Right is assumed if UP up, or
text path is not explicitly included. DOWN down.
(d)Horizontal Controls the positioning of the text A LEFT Left, UTXA
Text Alignment extent rectangle in relation to the text CENTER center, or
position. The horizontal text alignment RIGHT right.
has three possible values: "left,"
"center," and "right." For example, if
the horizontal text alignment is "left,"
the left side of the text extent rectangle
passes through the text position. Left is
assumed if horizontal text alignment is
not explicitly included.
(d)Vertical Text Controls the positioning of the text A TOP Top, VTXA
Alignment extent rectangle in relation to the text CAP cap,
position. The vertical text alignment has HALF half
five possible values: "top," "cap," BASE base, or
"half," "base," and "bottom." BOTTOM bottom.
The vertical alignment causes the text to
be moved in such a way that the
corresponding defining line of the text
extent rectangle passes through the text
position. Base is assumed if vertical
text alignment is not explicitly included.
Note that the values specified for the
horizontal and vertical text alignment are
a subset of those required by the CGM for
the CGM text alignment vector.
(d)Character Specifies the deviation of the width to R Real The deviation of the width CHEX
Expansion Factor height ratio of the characters from the to height ratio indicated by
ratio indicated by the font designer. the font designer.
A value of one is assumed if the
factor is not explicitly included.
(d)Character Specifies how much additional space is to R Real Space to be inserted CHSP
Spacing be inserted between adjacent character between adjacent
bodies. Character spacing is specified as character bodies.
fraction of character height. Zero is
assumed if not explicitly defined.
(d)Skew Angle Specifies the skew angle of the R Real Measured in decimal SANG
[O] characters. The skew angle is the angle degrees between 0 and 180
between the character base vector and the .
character up vector. It represents the
slant angle of the characters. The value
is measured in decimal degrees with 90
assumed unless otherwise specified. Skew
angle values near 0 or 180 should be
avoided since the result is likely to be
unreadable or not visible.
Necessary parameters are included to define the placement of text independently of device
functionality. Parameters such as text precision, which is in the CGM standard, must be
determined by the product requirements and device capabilities of the receiving system. The
CGM standard uses a character orientation vector that encodes character height, skew angle, and
orientation in a CGM-defined coordinate system. SDTS specifies the same parameters at a base
geographic scale. These parameters can be directly converted to the CGM character orientation
vector.
The font coordinate system is
illustrated at right. The character
body encloses all of the drawn parts
(kerning excepted) of all characters in
the font (that is, no descender
extends lower than the "bottom" and
no accent or oversized symbol
extends higher than the "top"). The
left and right edges of the character
body may be defined on a per-character basis to accommodate
variable widths and proportional
spacing. It is expected that some
font designers will specify fonts
having kerns beyond the character
body. The body exceeds the actual
character symbol width and height as
necessary to provide adequate white
space between characters, so that
text is readable and adequately
separated when the character spacing
is zero. The character height is the
height of the character at the base scale. For different scale products the character should be
scaled inversely with the scale factor. The character expansion factor specifies the deviation of
the width to height of the characters from the ratio indicated by the font designer. If the value of
the character spacing is positive, additional space is inserted between character bodies. If the
value of character spacing is negative, adjacent character bodies overlap although the character
symbols themselves might not. The character height is specified as a fraction of the scaled
character height.
The text path and the horizontal and vertical text alignment parameters specify how the string is aligned relative to the label point and the orientation points. The skew angle is the angle between the base vector and the character up arrow.
5.8.2 Line Representation
The Line Representation module provides the graphic data necessary to portray one-dimensional spatial objects.
Table 43 Line Representation
FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC
Line LNRP
Representation
(P)
[M] Module Name A unique identifier for this Line A Alphanum Name shall begin with an MODN
[M] Representation module. alphabetic character
other than SPACE.
Record ID A number for the module record, unique I Integer An unsigned integer RCID
[M] within the module. unique within the
representation module.
With Module Name shall
form unique ID within the
file set.
Base Scale The scale denominator used to translate I Integer A valid numeric scale BSCL
[M] the scale independent data transferred in denominator.
the SDTS transfer to scale dependent
graphic attributes such as dash spacing.
Small Scale The smallest appropriate scale denominator I Integer A valid numeric scale SSCL
Minimum for the graphics representation. denominator.
Large Scale The largest appropriate scale denominator I Integer A valid numeric scale LSCL
Maximum for the graphics representation. denominator.
Color Index Index corresponding to a value of the I Integer Unsigned integer. CLDX
[M] Record ID subfield in the Color Index
module.
Line Type The type of line representation: I The type of line LTYP
[M] 1: Solid representation:
2: Dash 1 solid,
3: Dot 2 dash,
4: Dash-dot 3 dot,
5: Dash-dot-dot 4 dash-dot, or
5 dash-dot-dot.
Values above 5 are reserved for extensions dd:>5 Reserved for extension.
and future standardization. Negative dd:\3630 Implementation dependent.
values are available for implementatio
dependent use, with definitions given in
corresponding Data Dictionary/Domain
module (see 5.2.6).
Line Width The line width measured in millimeters at R Real The line width measured LWTH
the base scale. If not specified, the in millimeters.
receiving system should use the smallest
visible line width.
The standard line representation repertoire is not sufficient for most cartographic applications. To use a line type outside the defined domain, the SDTS user shall identify the application's representation requirements, assign line types to these representations, and fully define the representations in a Data Dictionary/Domain module. The definition shall include precise lengths, symbol references, and other requirements.
5.8.3 Symbol Representation
The Symbol Representation module provides the graphic data necessary to portray the symbols.
Table 44 Symbol Representation
FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC
Symbol SYRP
Representation
(P)
[M] Module Name A unique identifier for this Symbol A Alphanum Name shall begin with an MODN
[M] Representation module. alphabetic character
other than SPACE.
Record ID A number for the module record, unique I Integer An unsigned integer RCID
[M] within the module. unique within the
representation module.
With Module Name shall
form unique ID within the
file set.
Base Scale The scale denominator used to translate I Integer A valid numeric scale BSCL
[M] the scale independent data transferred in denominator.
the SDTS transfer to scale dependent
graphic attributes such as symbol height.
Small Scale The smallest appropriate scale denominator I Integer A valid numeric scale SSCL
Minimum for the graphics representation. denominator.
Large Scale The largest appropriate scale denominator I Integer A valid numeric scale LSCL
Maximum for the graphics representation. denominator.
Color Index Index corresponding to a value of the I Integer Unsigned integer. CLDX
[M] Record ID subfield in the Color Index
module.
Symbol Marker The type of symbol representation: I The type of symbol SMKR
Type 1: Dot representation:
[M] 2: Plus 1 dot,
3: Asterisk 2 plus,
4: Circle 3 asterisk,
5: Diagonal Cross 4 circle, or
5 diagonal cross.
Values above 5 are reserved for extensions dd:>5 Reserved for future
and future standardization. Negative extensions.
values are available for implementation dd:\3630 Implementation dependent.
dependent use, with definitions given in
corresponding Data Dictionary/Domain
module (see 5.2.6).
Marker Size The symbol measured in millimeters at the R Real The symbol height MKSZ
[M] base scale. measured in millimeters.
The standard symbol representation repertoire is not sufficient for most cartographic applications. To use a symbol marker outside the defined domain, the SDTS user shall identify the application's requirements, assign marker types to these representations, and fully define the representations in the Data Dictionary.
5.8.4 Area Fill Representation
The Area Fill representation module provides the graphic data necessary to fill polygonal areas.
Table 45 Area Fill Representation
FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC
Area Fill AFIL
Representation
(P)
[M] Module Name A unique identifier for this Area Fill A Alphanum Name shall begin with an MODN
[M] Representation module. alphabetic character
other than SPACE.
Record ID A number for the module record, unique I Integer An unsigned integer RCID
[M] within the module. unique within the module.
With Module Name shall
form unique ID within the
file set.
Base Scale The scale denominator used to translate I Integer A valid numeric scale BSCL
[M] the scale independent data transferred in denominator.
the SDTS transfer to scale dependent
graphic attributes such as symbol height.
Small Scale The smallest appropriate scale denominator I Integer A valid numeric scale SSCL
Minimum for the graphics representation. denominator.
Large Scale The largest appropriate scale denominator I Integer A valid numeric scale LSCL
Maximum for the graphics representation. denominator.
Color Index Index corresponding to a value of the I Integer Unsigned integer. CLDX
[M/Fill Style Record ID subfield in the Color Index
Type = module.
HOLLOW|SOLID|HATC
H|PATTERN]
Fill Style Type The interior fill style may be "hollow," A HOLLOW No filling, but the FTYP
[M] "solid," "pattern," "hatch," or "empty." bounding line of the
Additional index values shall be defined filled area is drawn
in the Data Dictionary/Domain module (see using the fill color
5.2.6). currently selected. The
boundary of a HOLLOW
filled area is the
representation of the
interior. The bounding
line is distinct from the
SOLID edge and is drawn only
for HOLLOW filled areas.
PATTERN Fill the interior using
the fill color.
HATCH Fill the interior using
the pattern index defined
EMPTY pattern.
Fill the interior using
the fill color and the
hatch index.
dd: HOLLOW| No filling is done and no
SOLID|PATTERN|HA boundary is drawn, i.e.,
TCH|EMPTY nothing is done to
represent the interior.
Additional values defined
in a Data
Dictionary/Domain module.
Hatch Index The following hatch indices are defined: I Hatch index value: HIDX
[M] 1: Horizontal equally spaced parallel lines 1 horizontally equally spaced
2: Vertical equally spaced parallel lines parallel lines.
3: Positive slope equally spaced parallel lines 2 vertical equally spaced
4: Negative Slope equally spaced parallel lines parallel lines.
5: Horizontal/vertical cross hatch 3 positive slope equally spaced
6: Positive slope/negative slope crosshatch parallel lines.
Values above 6 are reserved for registration and 4 negative slope equally spaced
future standardization. Negative values are parallel lines.
available for implementation dependent use, with 5 Horizontal/vertical cross hatch
definitions given in corresponding Data or Positive slope/negative slope
Dictionary/Domain module (see 5.2.6). 6 crosshatch.
Implementation dependent
dd:<=0 Reserved for registration.
dd:>=6
Pattern Index An integer value that defines the type of I Integer An integer value that PIDX
[M] pattern. Values for this index shall be defines the type of
defined in a Data Dictionary/Domain pattern.
module.
The representation of the edge of a polygon is defined by its associated linear objects.
5.8.5 Color Index
The Color Index module provides the correlation between a color index value and specific normalized values for the red, green, and blue components of the desired color. Color values are a 3-tuple of values providing the normalized weight of red, green, and blue components. Each component of the 3-tuple is normalized to the continuous range of real numbers [0,1]. For any given component, one end of the range indicates that none of that component is included, and the other end indicates the maximum intensity of that component.
For color process printing, magenta, cyan, and yellow values are combined with a black intensity to fully define the color to be printed. The values for magenta, cyan, and yellow may be determined by the following equations:
magenta component = 1. -green component;cyan component = 1. -red component; and
yellow component = 1. -blue component.
The Color Index module also provides an optional Black Intensity Component to provide the black intensity to complete the process color definition. If the Black Intensity Component is omitted, a default value of zero is assumed.
Table 46 Color Index
FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC
Color Index CLRX
(P)
[M] Module Name A unique identifier for this Color Index A Alphanum Name shall begin with an MODN
[M] module. alphabetic character
other than SPACE.
Record ID A number for the module record, unique I Integer An unsigned integer RCID
[M] within the module. unique within the
representation module.
With Module Name shall
form unique ID within the
file set.
Red Component The red component of the desired color R Real The red component of the RED
[M] normalized from zero to one. desired color normalized
from zero to one.
Green Component The green component of the desired color R Real The green component of GREN
[M] normalized from zero to one. the desired color
normalized from zero to
one.
Blue Component The blue component of the desired color R Real The blue component of the BLUE
[M] normalized from zero to one. desired color normalized
from zero to one.
Black Intensity The black intensity component normalized R Real The black intensity BLCK
Component from zero to one. component normalized from
zero to one.
5.8.6 Font Index
The Font Index module provides the correlation between a font index value and a font defined in the Data Dictionary.
Table 47 Font Index
FIELD NAME SUBFIELD NAME FIELD/SUBFIELD DESCRIPTION TYPE DOMAIN DOMAIN DESCRIPTION MNEMONIC
Font Index (P) FONT
[M]
Module Name A unique identifier for this Font Index A Alphanum Name shall begin with an MODN
[M] module. alphabetic character
other than SPACE.
Record ID A number for the module record, unique I Integer An unsigned integer RCID
[M] within the module. unique within the
representation module.
With Module Name shall
form unique ID within the
file set.
Font The name or index of the actual font. I|A Integer Font number or font name FNTN
[M] Alphanum Format defined in a Data
Dictionary/Domain module.
ANNEXES
Informative Annex
A: The SDTS Model of Spatial Data
The basis of SDTS is a model of spatial data sufficiently general so that any user data can be accepted, but at the same time sufficiently structured to provide an adequate basis for the organization of spatial phenomena. This model encompasses the spatial objects in section 2 and also the attributes associated with these objects (which are of equal importance), and the ways in which objects and attributes are organized and bound into other more comprehensive forms. The SDTS model of spatial data incorporates the model concepts of part 2 (Spatial Features), including the entity type and attribute concepts used to organize the definitions in part 2.
This spatial data model is presented as an informative annex, because the model may be considered an aid to understanding the normative concepts of part 1, rather than an absolute requirement for spatial data transfer.
The SDTS conceptual model has three parts: a model of spatial phenomena; a model of the spatial objects used to represent phenomena; and a model of spatial features, which explains how spatial objects and spatial phenomena are related.
Terms from the Object Oriented Programming System literature are used to define the parts of the model. These terms are given specific definitions in this standard as a way of distinguishing the various criteria for grouping elements into sets that are meaningful as spatial data abstractions. The terms are:
A.1 Model of Spatial Phenomena
SDTS transfers information about phenomena that are defined in space and time, and so are described using a fixed location-- spatial phenomena. All phenomena are 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 attribute value 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 all members of the class have in common. It also includes characteristics which distinguish the class from other classes. These definitional characteristics are necessary and sufficient conditions for classifying some phenomena into the class and excluding others. The data collector defines 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 key attributes are the set of attributes of a class such that the combination of values of the key attributes forms a unique identifier for each entity instance.
Conceptually, an entity instance is a spatial phenomenon of a defined type that is embedded in one or more phenomena of a different type, or that has at least one key attribute value different from the corresponding attribute values of the surrounding phenomena. Such an entity instance is not further subdivided into phenomena of the same type. Examples of entity instances include obvious physical structures (such as a bridge), fuzzy physical regions (such as a soil polygon), cultural artifacts (such as a political boundary), and modeling constructs (such as an economic region).
The distinction between class and instance of entities can be shown as:
Class Instance ----- -------- Class or Instance Entity type Extity instance Characteristic attribute attribute value
An example of an entity type is Bridge with attributes Name and Composition. An instance of this type might be the "10th Street Bridge" composed of "steel." "10th Street Bridge" and "steel" are attribute values of Name and Composition. Another example is the entity type Farm with key attribute Owner and non-key attribute Crop_cultivated. Smith's Farm is adjacent to Jones' Farm. Both cultivate corn and soybeans. The two farms can be distinguished as entity instances because of the change in the value of the key attribute Owner. Across the road from the two farms is a shopping mall. The instances of the entity type Farm are bounded by other farms with different key attribute values, but also by instances of other types of entity such as Shopping Center and Road.
Entity instances may be aggregated into instances of a different type of entity. For example, although a lock is partly composed of walls, it is not itself a wall.
Entity types can be generalized into themes based on the definitional characteristics shared by more than one class. A theme can also have its own attributes, including Name. An example of a theme is "transportation" which is by definition a function of both Railway and Road.
The distinction between class and instance of themes can be shown as:
Class Instance _____ ________ Class or instance Theme Entity Typ Characteristics Theme Name Entity Labe
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 specified range. 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.
The distinction between class and instance of relationships can be shown as:
Class Instance _____ ________ Class or instance Relationship Relationship instanceCharacteristics Relationship type Relationship value
A.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 aggregation of other spatial objects, not all of which necessarily represent an entity instance. A spatial object 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 representation of 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. Rather than creating a whole new set of terms, the characteristics' names are generally the same whether referring to phenomena or their digital representation. In this standard, whether phenomena or their digital representations are being referred to is indicated by the context. The following table gives examples:
Phenomena Digital Representation _________ ______________________ Class Entity Type Entity Object Class Characteristic Attribute Attribute Instance Entity Instance Entity Object Characteristic Attribute Value Attribute Value Generalization Theme Theme Association Spatial Domain Spatial Domain Entity objects have locational attributes (spatial address), non-locational 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 objects (not aggregated from any other objects), or are aggregated only from spatial objects belonging to different classes (polygons 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, topological relationships, or any other criteria.
A.3 Model of Spatial Features
A feature type consists of an entity type and the entity object class that represents it. If a class is viewed as a set, whose members are the instances of the class, then a particular feature type is the intersection of the entity type and the entity object class. The feature type represents those entity instances that have representative entity objects.
The term feature is defined in the standard for completeness. A spatial data transfer contains entity objects and other spatial objects. Entity instances are not transferred; they exist in the real world.
Informative Annex
B: Attribute Encoding
This annex presents a further explanation of the attribute encoding methods specified in the
normative portion of the standard. Encoding examples, at the logical level, of the Attribute
Primary and Attribute Secondary modules are given, together with examples of the Data
Dictionary modules that describe the attribute data.
This annex also presents examples of valid attribute labels, and further describes the use of code
sets. It presents a suggested list of code sets for use in a transfer.
B.1 Attribute Primary and Attribute Secondary Modules
The structure of an Attribute Primary module record is defined in 4.1.3.6.1, using BNF, as:
[<spatial object ID>]
[<attribute 1>]
[<attribute 2>]
.
.
.
[<attribute n>]
<module record identifier>::= <module name> <record id>
<spatial object ID>::= <module name> <object id>
The structure of the secondary attribute module record is nearly identical to the structure of the
primary module record: the difference is the absence of the spatial object link field.
The following schematic example shows some spatial objects with primary and secondary
attributes and their potential links. In the first example ("Bridges"), the Attribute Secondary
module is used to handle values of the standard attribute 'Composition' with a onelink
between 'Composition' and the attribute 'Material' (i.e., each bridge is composed of more than one
material). In the second example, primary attributes such as 'State', 'County', and 'LandType' are
given FIPS and DLG code equivalents.
_________________________________________________________________________
Point-Node Attribute ID Spatial Address
_____________________ _____________________ _________________
MODN RCID OBRP MODN RCID X Y
____ ____ ____ ____ ____ _ _
Bridges 1 NP BridgeAtts 81 etc.
Bridges 2 NP BridgeAtts 82
Bridges 3 NP BridgeAtts 83
_________________________________________________________________________
Attribute Primary Module "BridgeAtts"
_________________________________________________________________________
Attribute Primary Spatial Object ID Attributes
___________________ ___________________ ______________________________
MODN RCID MODN RCID COMPOSITION SPAN
LENGTH
______ ____ ____ ____ ___________ ____
BridgeAtts 81 Bridges 1 A 300
BridgeAtts 82 Bridges 2 B 1200
BridgeAtts 83 Bridges 3 A 500
_________________________________________________________________________
Attribute Secondary Module "BridgeComp"
_________________________________________________________________________
Attribute Secondary attributes
___________________ ____________________________
MODN RCID COMPOSITION MATERIAL
____ ____ ___________ ________
BridgeComp 27 A Wood
BridgeComp 28 A Concrete
BridgeComp 29 A Steel
BridgeComp 30 B Concrete
BridgeComp 31 B Wood
_________________________________________________________________________
In the above example, the link between the Point-Node and Attribute Primary module records is
one, while the link between Attribute Primary and Attribute Secondary records is
one.
The DLG example shows attributes for a set of polygons, with one Attribute Primary Module and
three Attribute Secondary modules:
_________________________________________________________________________
Polygon Attribute ID Ring ID
_____________________ _________________________ ______________
MODN RCID OBRP MODN RCID MODN
RCID
____ ____ ____ ____ ____ ____
GlenEllen 1 PR GlenEllenAtts 11 etc.
GlenEllen 2 PR GlenEllenAtts 12
GlenEllen 3 PR GlenEllenAtts 13
GlenEllen 4 PR GlenEllenAtts 14
_________________________________________________________________________
Attribute Primary Module "GlenEllenAtts"
_________________________________________________________________________
Attribute Primary Spatial Object ID Attributes
_________________ _________________ _____________
MODN RCID MODN RCID STATE COUNTY LANDTYPE
____ ____ ____ ____ _____ ______ ________
GlenEllenAtts 11 GlenEllen 1 California Sonoma Park
GlenEllenAtts 12 GlenEllen 2 California Sonoma null
GlenEllenAtts 13 GlenEllen 3 California Sonoma Land Grant
_________________________________________________________________________
Attribute Secondary Module "States"
Attribute Secondary Attributes
___________________ ____________________________________________
MODN RCID STATE DLGCODE STATEFIPSCODE
____ ____ _____ _______ _____________
States 37 California 091.0006 06
States 38 Nevada etc.
_________________________________________________________________________
Attribute Secondary Module "Counties"
_________________________________________________________________________
Attribute Secondary Attributes
___________________ ____________________________________________
MODN RCID COUNTY DLGCODE COUNTYFIPSCODE
____ _____ ______ _______ ______________
Counties 92 Sonoma 092.0097 097
Counties 93 Napa etc.
Counties 94 Mendocino
_________________________________________________________________________
Attribute Secondary Module "LandTypes"
_________________________________________________________________________
Attribute Secondary Attributes
___________________ _________________________________________
MODN RCID LANDTYPE DLGCODE
____ ____ ________ _______
LandTypes 6 Land Grant 090.0113
LandTypes 7 Park 090.0130
_________________________________________________________________________
Each Attribute Primary or Attribute Secondary module shall have an associated Data
Dictionary/Schema module. The following is an example of the Data Dictionary/Schema module
for the BridgeAtts and BridgeComp modules of the Bridge example (the sequence of the subfield
mnemonics in the table corresponds to the sequence of the subfields in the module description
table). The entity for this example is "Bridge," a standard SDTS entity.
_________________________________________________________________________
DATA DICTIONARY/SCHEMA FIELD
_________________________________________________________________________
Module
Record Subfield
Number Mnemonic Subfield Contents
______ ________ _________________
1 MODN BridgesSchema
RCID 1
NAME BridgeAtts
TYPE ATPR
ETL BBRIDGE
EUTH SDTS
ATLB SPAN_LENGTH
AUTH NCHA
FMT I
UNIT METERS
MXLN 5
KEY NOKEY
2 MODN BridgesSchema
RCID 2
NAME BridgeAtts
TYPE ATPR
ETLB BRIDGE
EUTH SDTS
ATLB COMPOSITION
AUTH NCHA
FMT A
UNIT null
MXLN 1
KEY FKEY(1)
3 MODN BridgesSchema
RCID 3
NAME BridgeComp
TYPE ATSC
ETLB BRIDGE
EUTH SDTS
ATLB COMPOSITION
AUTH NCHA
FMT A
UNIT null
MXLN 1
KEY PKEY
4 MODN BridgesSchema
RCID 4
NAME BridgeComp
TYPE ATSC
ETLB BRIDGE
EUTH SDTS
ATLB MATEIAL
AUTH ASTM
FMT A
UNIT null
MXLN 1
KEY PKEY
_________________________________________________________________________
(1) - COMPOSITION in BridgeAtts is only part of a foreign key.
Note that in the above example there is one Data Dictionary/Schema module for two attribute
modules, confirming that there need not be a one-to-one correspondence between Data
Dictionary/Schema modules and attribute modules. Also note that there are two records for the
attribute Composition, because it occurs in both the Attribute Primary and Attribute Secondary
modules.
B.3 Data Dictionary/Definition Module
The Data Dictionary/Definition module defines the entities and attributes used in the Attribute
Primary, Attribute Secondary and Data Dictionary/Schema modules.
The use of the Data Dictionary/Definition module is demonstrated with the following example:
_________________________________________________________________________
Module
Record Subfield
Number Mnemonic Subfield Contents
______ ________ _________________
1 MODN DDDEF
RCID 1
EORA ENT
EALB Lagoon
SRCE A dictionary of geography, Monkhouse
DFIN A sheet of salt water separated from ....
AUTH FDMA
ADSC Federal Mapping Authority
2 MODN DDDEF
RCID 2
EORA ENT
EALB Bridge
SRCE Canadian Council on Surveying and Mapping
DFIN A structure erected over a depression...
AUTH NCHA
ADSC National Charting Board, Report Q17...
3 MODN DDDEF
RCID 3
EORA ATT
EALB SPAN_LENGTH
SRCE Bridge Engineering Associates Inc.
DFIN Distance between bridge abutments...
AUTH SDTB
ADSC Spatial Data Transfer Board, publication...
_________________________________________________________________________
In this example the first two records contain entity definitions; the last record defines an attribute
of the entity "Bridge." The fourAttribute Authority codes such SDTB, FDMA,
NCHA, would also be used in the Attribute and Entity authority subfields of the Data
Dictionary/Schema module for the example transfer.
An example of wildcard character use in this module is the following:
B.4 Data Dictionary/Domain Module
The Data Dictionary/Domain module describes the valid domains for the attributes stored with the
Attribute Primary and Attribute Secondary modules.
The use of the Data Dictionary/Domain module is demonstrated with the following example:
B.5 Attribute Labels and SQL Keywords
The standard specifies that an attribute label shall not be identical to an SQL keyword. The SQL
keywords are:
_________________________________________________________________________
Examples of valid attribute labels are:
Example of labels that are not valid are:
B.6 Suggested Code Sets
The encoding of data content by the sender, based upon the following widely used code sets, will
facilitate a more efficient transfer of meaning. It is not the intent of this standard to recommend
the coding of all data content, but simply to employ existing code sets where applicable. These
sets may be used with the "cs:" convention and the appropriate FIPSPUB number as a domain
specification in the Data Dictionary/Domain module.
Each document in the list is preceded by a short subject for reference purposes only.
Informative Annex
C: Spatial Address Encoding
This annex is intended for use as a guide to spatial address encoding within SDTS.
Spatial address refers to the geographic point location of an object, and is used to define the
position of a point (in a defined coordinate system) that may be on, above, or below the Earth's
surface. There are many systems available for indicating point locations. This standard allows for
the use of any of the three most widely used in the United States (listed in order of preference):
Latitude and Longitude, 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.
Use of altitude data is not required; however, specifications for altitude data are provided in
4.1.3.5.5, Altitude.
References for more detailed information on the methodology, techniques and applications of the
three systems are provided in 1.3.
When transforming the coordinates of linear objects (for the purposes of using this standard or
otherwise), great care must be taken. A line segment (the most simple component of most of the
linear objects) is defined as "a direct line between two points." For the purposes of this standard,
a direct line shall be defined as a line of constant slope (the change in Y or latitude divided by the
change in X or longitude). When the points of a line segment are specified by coordinates within
a given coordinate system, the direct line between them is a function of only that coordinate
system. This means that when a line segment is transformed, there will always be two direct lines
defined by that line segment: one line before transformation and the second line after
transformation. If the distance between the two points of a line segment is great enough,
the two direct lines could be significantly different. If this is the case, a data encoder using this
standard should break the line segment into two or more segments (by adding intermediate points)
to ensure that the resultant before and after sets of direct lines are not significantly different.
The problem of transforming arc objects is conceptually even greater than that of line segments.
Just as with line segments, points provide the basis for positioning the arc, and these points can be
transformed just as line segment points. But whereas "direct line" has a well defined meaning in
both a before and after transformation reference surface, a "curve that is defined by a
mathematical function" might not. It can be said that there are no general solutions available for
transforming curves.
However, from a practical standpoint, the problem might not be so great. When dealing with
large scale data (within a relatively small area), where arc objects are most likely to be used (e.g.,
highway construction and land parcel maps), and rectangular coordinate projection systems are
used, the before and after transformation differences are usually not significant. Where this is not
the case (differences are significant), this standard requires that a data encoder convert the arc to
a string (or chain if appropriate) with enough line segments to ensure proper relative positional
accuracy is retained. The fact that this conversion has been done should also be available to a
user of the encoded data.
C.1 Latitude and Longitude
Latitude and longitude are ellipsoidal coordinate representations that show locations on the
surface of the earth using the earth's equator and the prime meridian (Greenwich, England) as the
respective latitudinal and longitudinal origins.
C.1.1 Representation of Degrees
Latitude and longitude are angular quantities, and according to the standard, should be expressed
as decimal fractions of degrees.
Degrees of latitude, according to the standard, should be represented by a two-digit decimal
number ranging from 0 through 90.
Degrees of longitude, according to the standard, should be represented by a three-digit decimal
number ranging from 0 through 180.
When a decimal fraction of a degree is specified it, according to the standard, should be separated
from the whole number of degrees by a decimal point.
C.1.2 Hemisphere Representation
Latitude north of the equator, according to the standard, should be specified by a plus sign (+) or
by the absence of a minus sign (-), preceding the two digits designating degrees. A point on the
equator, according to the standard, should be assigned to the northern hemisphere. Latitude
south of the equator shall be designated by a minus sign (-) preceding the two digits designating
degrees.
Longitudes east of the prime meridian, according to the standard, should be specified by a plus
sign (+) or by the absence of a minus sign (-), preceding the three digits designating degrees of
longitude. Longitudes west of the meridian, according to the standard, should be designated by a
minus sign preceding the three digits designating degrees. A point on the prime meridian,
according to the standard, should 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 or -90 degrees specifies the location of the North or
South pole, respectively. The longitude component may have any legal value.
C.2 Universal Transverse Mercator/Universal Polar Stereographic Grid Systems
C.2.1 Universal Transverse Mercator Grid System
The Universal Transverse Mercator Grid System (UTM) provides rectangular coordinates that
may be used to indicate locations of points on the surface of the Earth. UTM involves linear
measurements, and the unit of measure is the meter. A point is located by specifying a
hemispheric indicator, a zone number, an easting value, and a northing value.
UTM is designed for world use between 80 degrees south latitude and 84 degrees north latitude.
The globe is divided into narrow zones, 6 degrees of longitude in width, starting at the 180 degree
meridian of longitude and progressing eastward. The zones are numbered 1 through 60. Each
zone has, as its east and west limits, a meridian of longitude. Each zone also has a central
meridian passing through the center of the zone. The location of any point within a zone is given
in relation to the central meridian within that zone and the equator. The system zone yields
positive values for the identification of a point on the earth's surface by first assigning numeric
values to the equator and the central meridian. Then, a point's northlocation is obtained by
either adding or subtracting the point's distance north or south of the equator. Similarly, a point's
eastlocation is obtained by either adding or subtracting the point's distance east or west of
the central meridian.
A value of 500,000 meters is assigned to the central meridian of each zone in order to avoid
negative numbers at the west edge of the zone. The values increase from west to east. For
northvalues in the northern hemisphere, the equator is assigned 0 meters, and the numbers
increase toward the north pole. In the southern hemisphere, the equator is assigned 10,000,000
meters, and the numbers decrease toward the south pole.
On a map, appropriate values for the easting and northing of a point are determined relative to
labeled grid lines. A point on the equator is assigned a value of zero for its northing and is treated
as if it were in the northern hemisphere. A point on a boundary meridian is assigned the zone
number for the zone to the east of the point.
C.2.2 Universal Polar Stereographic Grid System
The Universal Polar Stereographic Grid System (UPS) is used in place of UTM in the polar
regions of greater than 84 degrees north latitude and 80 degrees south latitude. Characteristics of
UTM (paragraph C.2.1) also apply to UPS, with some important modifications. The 0 degree and
180 degree meridians divides each polar region into an eastern and western half. At the north
pole, the western grid zone is labeled "Y" and the eastern grid zone "Z". The corresponding
south polar grid zones are labeled "A" and "B". The location of any point within either of the
polar regions is given in relation to the 180 degree meridian and 90 degree meridian. A value of
2,000,000 meters north and 2,000,000 meters east is added in order to avoid negative numbers.
C.2.3 Hemisphere and Zone Representation
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 (+), according to the standard, should be used to indicate the northern hemisphere, and a
minus sign (-) to indicate the southern hemisphere. The remainder of the subfield, according to
the standard, should contain the zone number indicating the 6 degree longitudinal band in which
the point is located (01, 02, ... 60) for UTM or grid zone letter designator (A,B,Y or Z) for UPS.
C.2.4 Unit of Measurement
The unit of measurement for both Northing and Easting, according to the standard, should be the
meter.
C.3 State Plane Coordinate Systems
The State Plane Coordinate Systems (SPCS's) are designed to define the location of points within
a geographic grid system. They were used first in the nineteenth century; the first formal use was
in 1932. There are now one or more State Plane Coordinate Systems in use in each of the 50
United States, as well as in the Commonwealth of Puerto Rico, the U.S. Virgin Islands, American
Samoa, and Guam. The District of Columbia is included with the State of Maryland. State Plane
Coordinate Systems represent separate, distinct systems for the 54 political jurisdictions involved,
as opposed to the universally applicable Latitude and Longitude and Universal Transverse
Mercator/Universal Polar Stereographic (UTM/UPS) Grid Systems.
Nine States, Puerto Rico, American Samoa, and Guam are covered individually by one State
Plane Coordinate System or zone. The nine States are: Connecticut; Delaware; Maryland; New
Hampshire; New Jersey; North Carolina; Rhode Island; Tennessee; and Vermont. The remaining
41 States and the Virgin Islands are covered individually by from two to ten SPCS's. These
systems fall into four general categories, based upon the conformal mapping projection methods
utilized in the political jurisdiction:
Further, a zone may be defined in one of three ways. In each of these three methods, an arbitrary
point of origin in latitude and longitude is one element of the definition of the zone. The other
element of definition varies with the conformal mapping projection system used in the zone:
C.3.1 Zone Representation
Each of the zones or SPCS's in each jurisdiction is uniquely identified by a four-character numeric
code as specified in Table 4 of FIPSPUB 70-1. This four character code, according to the
standard, should be transferred in the Zone Number subfield of the External Spatial Reference
module.
C.3.2 Coordinate Representation
Three methods are available for the designation of the east(X or E(easting) coordinate) and
north(Y or N(northing) coordinate) location indicators: (1) the Lambert Conformal Conic
Projection, (2) the Transverse Mercator Projection, and (3) the Oblique Mercator Projection used
in Alaska.
An X or Y coordinate in an existing SPCS may be expressed by a number of the general
magnitude of NNNNNNN.NNN. This will suffice for a range of not less than .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 conventions apply. Where a decimal fraction is
used, according to the standard, it should be one, two or three positions in length, as required (for
example, .1, .15., .125).
C.3.3 Unit of Measurement
The unit of measurement of both the X and Y coordinate, according to the standard, should be
the meter, as required by the SPCS '83 specification.
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 systems must
have their horizontal components expressed in meters to conform to the SPCS specifications.
However, there remain several SPCS's which 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 must be
converted to meters.
C.4 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, according to the standard, should be used to specify this surface.
All altitude measurements below the reference Vertical Datum, according to the standard, should
be designated by a minus sign (-) preceding the number. Measurements at or above the Vertical
Datum, and at or below the Sounding Datum, may be either without a sign or may be designated
by a plus sign (+); however usage, according to the standard, should be consistent throughout a
set of data.
The use of meters as the unit of vertical measurement is required.
Informative Annex
D: Catalog Module Examples
This annex is a companion to 5.2, to provide user assistance in the preparation of Global
Information modules. The examples in this annex demonstrate the logical encoding of the
Catalog global modules.
D.1 Catalog/Directory
The following example demonstrates the use of the Catalog/Directory module (module types have
been abbreviated to fit the table):
Modul Record
Name ID Name Type Volume File Record Comment
____ _____ ____ ____ ______ ____ ______ _______
CD 1 CD Cat/Dir FloppyA C.DAT 1 86/6/13
CD 2 CX Cat/Cross FloppyA C.DAT 2 null
CD 3 CS Cat/Spatial FloppyA C.DAT 3 Alaska data
CD 4 ID Identification FloppyA I.DAT 1 Read pls.
CD 5 IR Internal Ref FloppyA IR.DAT * null
CD 6 ER External Ref FloppyA ER.DAT * null
CD 7 P1 Point FloppyA P1.DAT * Points
CD 8 P2 Point FloppyA P2.DAT * Nodes
CD 9 L1 Line FloppyA L1.DAT * Lines
CD 10 L2 Line FloppyA L2.DAT * Chains
CD 11 PR Polygon FloppyA PR.DAT * Polygons
CD 12 PR Polygon FloppyB PR.DAT *
_________________________________________________________________________
Note that Module Name is by definition the same throughout the entire module.
D.2 Catalog/Cross-Reference
The following example demonstrates the use of the Catalog/Cross-Reference module:
_________________________________________________________________________
Module Record
Name ID Name 1 Type 1 Name 2 Type 2 Comment
____ _____ ______ ______ ______ ______ _______
CX 1 CD Cat/Dir * * All modules
are cataloged.
CX 2 ER External Ref P1 Point-Node null
CX 3 ER External Ref P2 Point-Node null
CX 4 ER External Ref L1 Line null
CX 5 ER External Ref L2 Line null
CX 6 ER External Ref PR Polygon null
CX 7 PR Polygon L2 Line PR pols consist
of L2 chains.
_________________________________________________________________________
The use of the Catalog/Spatial Domain module is demonstrated with the following example (the
comment subfield is not shown):
This glossary assembles terms defined in parts 1, 2 and 3 of this standard, in addition to selected
terms used in these definitions.
Informative Annex
This annex includes normative references to other standards contained in 1.3 and in part 3, in
addition to selected works used in the preparation of this standard.
American National Standards Institute, Inc., 1986, American National Standard for Information
Systems - Computer Graphics - Graphical Kernel System (GKS) Functional Description (GKS).
American National Standards Institute, Inc., 1430 Broadway, New York, New York 10018.
American National Standards Institute, Inc., 1986, American National Standard for Information
Systems - Computer Graphics - Metafile for the Storage and Transfer of Picture Description
Information (CGM). American National StanInstitute, Inc., 1430 Broadway, New York,
New York 10018.
Canadian Council on Surveying and Mapping, 1982, Standards for the Classification of
Topographic Features, Draft Report, Ottawa: Energy, Mines and Resources.
Claire, Charles N., 1973, State Plane Coordinates by Automatic Data Processing, Coast and
Geodetic Survey Publication, 62\par
Corbett, James P., Topological Principles in Cartography, U.S. Department of Commerce, Bureau
of the Census, Technical Paper 48, Dec 1979.
Defense Intelligence Agency, 1983, Intelligence Data Elements (IDEAS), Wash.
Defense Mapping Agency, 1984, 1985, Feature File (DMAFF) Data Collection Guide, 1st and
2nd eds. St. Louis
Elassal, Atef A., 1986, General Cartographic Transformation Package (GCTP), NOAA Charting
Research and Development Laboratory, Office of Charting and Geodetic Services, National
Ocean Service, NOAA Rockville, Maryland.
Graphical Kernel System (GKS), FIPSPUB 120, 18 Apr 86.
Monkhouse, F.J., 1965, A Dictionary of Geography, Chicago: Aldine Publishing Company.
Moore, W.G., 1966, A Dictionary of Geography, Baltimore: Penguin Books.
National Committee for Digital Cartographic Data Standards, 1982}Issues in Digital
Cartographic Data Standards, Reports 1by Harold Moellering, Columbus: The Ohio
State Uni[Available as USGS OpenReports 878787\par
Naur, P., 1963, "Revised Report on the Algorithmic Language ALGOL 60," Communications of
the ACM, Vol. 6, No 1, pp. 1\par
Samet, Hanan, 1990, Applications of Spatial Data Structures: Computer Graphics, Image
Processing, and GIS, New York: Addison-Wesley Publishing Company.
Samet, Hanan, 1990, The Design and Analysis of Spatial Data Structures, New York: Addison-Wesley Publishing Company.
Snyder, J.P., 1987, Map Projections }A Working Manual, USGS Professional Paper 1395.
Stamp, Dudley, 1966, Dictionary of Geography, New York: John Wiley and Sons.
States and Outlying Areas of the United States, FIPSPUB 570.
U.S. Geological Survey, 1986, Geographic Names Information Sys: U.S. Geological Survey
Data Users Guide 6, 30 p. [replaces USGS Circular 895].
US National Ocean Service, 1985, Glossary on Mapping, Charting and Geodesy Terms, Draft Edition.
<Attribute Primary module record>::= <module record identifier>
The spatial object ID field is optional. If used, it constitutes a backward link from the attributes
to the spatial object. Forward links from the spatial object are made through the use of a foreign
identifier in the spatial object module record named Attribute ID. This field is also optional, but
the minimum requirement is that there be at least either a forward or a backward link.
Point-Node module "Bridges"
Polygon Module "GlenEllen"
B.2 Data Dictionary/Schema Module
_________________________________________________________________________
DATA DICTIONARY/DEFINITION FIELD
D.3 Catalog/Spatial Domain
_________________________________________________________________________
Module
Record Subfield
Number Mnemonic Subfield Contents
______ ________ _________________
1 MODN DDDEF
RCID 1
EALB *
AUTH FDMA
ADSC Federal Mapping Authority
_________________________________________________________________________
meaning that the code FDMA as used in each Attribute Definition or Schema field refers to
"Federal Mapping Authority" for all attributes ("*" meaning all).
_________________________________________________________________________
MODN RCID ATLB AUTH ATYP ADVF ADMU RAVA DVAL DVDF
____ ____ ____ ____ ____ ____ ____ ____ ____ ____
DDDOMAIN 1 COMPOSITION SDTS ALPHABET A null VALUE Steel
iron &
carbon
DDDOMAIN 2 COMPOSITION SDTS ALPHABET A null VALUE Wood
xylem
DDDOMAIN 3 SPAN_LENGTH FDMA INTEGER I Meters MIN 5
DDDOMAIN 4 SPAN_LENGTH FDMA INTEGER I Meters MAX 300
______________________________________________________________________
The first two records contain the domain type of ALPHABET for the attribute "composition" of
the entity "bridge"; the last two contain the upper and lower limits of the range for the attribute
"Span_length" of the entity bridge. Note that "Steel" and "Wood" are not part of an enumerated
domain, other alphabetic values are legal. With an ENUMERATED domain type, no other values
would have been allowed.
_________________________________________________________________________
TYPE, Z_09, VEGETATIONCODING, B, Q_A_1, ATTRIBUTE000000001.
type, 1ATTRIBUTE, _SECONDATTRIBUTE, VALIDATTRIBUTELABEL, Q__ABC,
VEGETATION CODE, soiltype, SQLERROR and COUNT.
A zone may extend to the State boundaries of a political jurisdiction and to county boundaries
where these are contiguous with State boundaries.
The arbitrary point of origin for each zone is typically located outside the geographic area it
covers. This is designed to meet the objective that no coordinate may have a negative value.
_________________________________________________________________________
_________________________________________________________________________
Module Record Aggregate
Name ID Name Type Domain Map Theme Object type
______ _____ ____ ____ ______ ___ _________ ___________
CS 1 CD Cat/Direct * * * null
CS 2 P1 Point-Node Alaska Mount Drum null null
CS 3 P2 Point-Node Alaska Gulkana null null
CS 4 L1 Line Alaska Copper River Transport network
CS 5 L2 Line Alaska Gulkana null null
CS 6 PR Polygon Alaska Gulkana null null
CS 7 PS Polygon Alaska Kenai Soils null
_________________________________________________________________________
Informative Annex
U.S. Department of the Interior
|| U.S. Geological Survey
1400 Independence Road, Rolla, MO 65401
For general information call: (573)308-3500
URL: http://mcmcweb.er.usgs.gov/sdts/SDTS_standard_oct91/part1.html
Last modified: Thursday, 21-Feb-2002 20:28:05 EST
Maintainer: mcmcweb@usgs.gov
Privacy Statement || Disclaimers ||
FOIA || Accessibility