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 implementation-media constructs. 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 set 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 cross-references between 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: þ the preservation of or means for reconstruction of a logical order in which the recipient may retrieve data comprising module subfields, module fields, module records, and modules. þ the preservation of the identity of the interchange data elements. The general principles behind these requirements are explained as follows. 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 Backus-Naur Form. For clarification, the Backus-Naur Form (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: (a) Modules referred to by foreign identifiers in other modules in the transfer shall also be present in the transfer. (b) The global modules stated as required in 5.2 shall always be present. (c) The inclusion of the Identification module is mandatory. (d) When the Attribute Authority or Entity Authority subfield of any Data Dictionary/Schema module is null, or when the authority referred to is an authority other than this standard, appropriate Data Dictionary modules to define the entity or attributes and (or) the entity or attribute authority shall be used. Detailed conventions for the use of the authority subfields are found in 5.2.6. 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). (e) The five quality modules described in 5.3 shall always be included. 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). (f) For each Attribute Primary or Secondary module there shall be a related Schema module. (g) For each Raster Cell module there shall be a related Raster Definition module. For each Raster Definition module there can be more than one related Raster Cell module. (h) For the Line Representation, Symbol Representation, and Area Fill Representation modules, a standard field can take on specified values that are defined in the domain description column, or additional values defined in a Data Dictionary module. If additional values are used, the values and the authority for the values shall be defined in an associated Data Dictionary module, and the Data Dictionary module shall always be present. 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: ::= , {}, {}, ..., {} 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) The order of repetition is not significant. (b) The order of repetition is significant. (c) The order of repetition is significant and is correlated with the repetition of another field. This standard dictates for each field which of the above conditions apply through an appropriate code in the field description for each field (see 4.2.3). This indicates whether ordered information shall be supplied for that field. A number of modules in this specification have a simple relational structure in which all subfields may be represented as an n-tuple within a single implementation field. A module is said to have a relational structure when either one of the following conditions exists: (a) there is only a single primary field per module record and no variably repeating subfields. The relational structure of a module record is: ::= ::= , [], . . [] where the subfields are optional according to the rules of 4.1.3.3.6. (b) the module record is composed of one primary field and one or more nonrepeating secondary fields. This alternate form is sometimes present to take advantage of predefined shared fields. This structure is expressed as: ::= , , [], ..., [] where the optionality of the fields is according to the specifications of 4.1.3.3.5. 4.1.3.3.4 Subfields within Fields. A module subfield with a given name may be repeated a variable number of times within a given spatial data transfer if this is so specified within this standard (see 4.2.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/Cross-Reference module. 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-to-many, 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: (a) An entire data element may be replaced with a "*", meaning "all." (b) If the data element refers to the Record ID subfield, it may be replaced by a negative integer corresponding to the maximum value in the subfield referenced, e.g., "-9328", meaning "all 9,328 records in the module referenced," or "the maximum number of records referenced in any of the referenced modules is 9,328." (c) Non-contiguous substrings of a data element may be replaced with a "*", meaning that the data element refers to those other data elements where the explicitly specified substrings are matched in their relative order. (d) Single characters of a data element may be replaced with a "?" meaning that the data element refers to those other data elements where the explicitly specified characters match in their relative order. Whenever wildcard characters are used in data items that are part of a nested index, such as the foreign identifier, the scope of the elements referenced shall be restricted by the scope of the previous level of reference. For example, if wildcard characters are used in the same foreign identifier to refer to modules and also to refer to records, then the scope of the records is restricted to the set of modules referenced. For any transfer, the scope of a set of modules referenced shall be restricted to the modules in the Catalog/Directory module in which the referring module is cataloged. 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 systems 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 In 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: (a) The scan reference system is a row-column reference system for use with raster data, further described in 5.7.1.2. (b) The internal reference system is a Cartesian coordinate system, one that does not assume any particular orientation. For raster data, the system shall be right- handed. The internal reference system is used to store the spatial addresses for the vector spatial objects of a transfer, while the scan reference system is used to store spatial addresses for raster data. (c) The external reference system is also a Cartesian coordinate system, without an assumed orientation, but the orientation of the internal and external reference systems shall be identical. The external reference system shall be either the Latitude-Longitude system, the UTM/UPS System, one of the State Plane Coordinate Systems (metric), or a system for which a transformation to latitude and longitude can be described through a projection and its parameters. The external reference system is not used to transfer the spatial addresses of spatial objects, but is used within a transfer to record registration points and spatial domains. (d) The system of latitude and longitude is the ultimate reference system to which, for conformance levels 1 and 2, all spatial data shall be convertible. The standard provides the necessary information to transform spatial addresses from one reference system to another for the following transformations: (a) Scan reference system to internal reference system. This transformation is for raster data, and is defined through the parameters stored in the Raster Definition module (5.7.2). (b) Internal reference system to external reference system. This transformation may be accomplished (1) through translation and scaling with parameters provided in the Internal Spatial Reference module, or (2) through a transformation implicitly defined by registration points of the Registration module. (c) External reference system to latitude and longitude. This transformation can be accomplished through the known relationship between the preferred external spatial reference systems to latitude and longitude, or through the explicitly specified projection and parameters of another defined external reference system. This standard is implemented through the use of recognized horizontal and vertical datums. 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 two-digit decimal number ranging from 0 through 90. Whole degrees of longitude shall be represented by a three-digit decimal 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 (-) preceding 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 (-) preceding 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 (-) to 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 four-character numeric code as specified in table 4 of FIPSPUB 70-1. This four 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 (-) preceding 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 one-to-one or one-to-many link. 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-to-one, one-to-many, or many-to-one. 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 cross-references expressed in the Catalog/Cross-Reference module. The structure of an Attribute Primary module record is defined as: ::= [] [] [] . . . [] ::= ::= where n is a constant for the module. 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: (a) The specific set of attributes in an attribute module (b) The relationship between these attributes and an entity (c) The authorities of the attributes and (or) entity (d) The format, measurement unit, and maximum length of an attribute (e) Whether an attribute is a part of a primary or foreign relational key. The following subsections describe the first three 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: (a) Polygons that are not universe or void polygons can have associated attributes referenced through the Attribute ID field of the Polygon module, while the universe or void polygons can lack any attributes, as indicated by the absence of the Attribute ID field. (b) A different schema applies to the universe and (or) void polygons. In this case, the universe and void polygons shall be stored in a separate module. This module shall be uniquely referenced to a special Data Dictionary/Schema module using a Catalog/Cross-Reference module. (c) The same schema applies to all the polygons of a module, including the universe and (or) void polygons. The difference in attribution is accomplished through the proper application of nulls, as described in 4.1.3.3.9, to the attribute fields that are irrelevant for the universe and void polygons. 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: ::= '#' [] 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.135-1986, FIPSPUB 127). 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 0-9). Conforming to 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: ::= { } ::= 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 ::= [ ] ::= _ ::= | ::= 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: A: graphic characters, alphanumeric characters, or alphabetic characters I: implicit-point (integer) R: explicit-point unscaled (fixed point real) S: explicit-point scaled (floating point real) B: bitfield data (see types listed below) C: character mode bitfield (binary in zero and one characters) 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: BI8: 8-bit signed integer BI16: 16-bit signed integer BI24: 24-bit signed integer BI32: 32-bit signed integer BUI: unsigned integer, length specified by implementation 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 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: (a) Graphics characters (Gr-chars) (b) Alphanumeric (Alphanum) (c) Alphabetic (Alpha) (d) Integer (e) Real (f) Binary (g) Allowable values (domain enumeration) (h) Standard code sets (i) Standard field where domain is defined in Data Dictionary/Domain module In the first six cases (a, b, c, d, e, f), the domain column shall indicate "Alphanumeric," "Integer," etc. 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-l986 (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 domains1 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 ^ 1The width of the line below the character set name indicates which characters are included in the set. 2The "E" in the Numeric set is used for expressing an exponent. Note that the characters ".","+", and "-" are not part of the Alphanumeric set. 3SPACEs may be used in numeric forms as defined in ISO 6093. 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 lower-case alphabetic 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 one-to-one correspondence 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 soil 4.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 "-". 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/Spatial-Domain module 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-TUPLE." This is indicated as: Vertical Component Format [M/Spatial Address Type = 3-TUPLE]. The following BNF fully describes the structure of the field and subfield status notation: status code ::= '[' ['/' ] ['/' ] ']' ::= {'|' < object representation code> } ::= { } ::= [ ' = ' value ] ::= '|' | '+' ::= | <'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 name User must substitute one or more explicit subfields with user-assigned 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.