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.
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.
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 Object Specification subfields of the Conformance field in the Identification module.
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 3 and 4. 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 4 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.
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.
An implementation of this standard must preserve the meaning of the data including any logical associations required by this standard. The specifications require:
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.
Construct | Logical | Implementation | Media |
|---|---|---|---|
Logical Constructs of this Standard | Implementation Constructs | Medium Constructs | ||
|---|---|---|---|---|
| 1 B = A implies functional equivalence of A and B B > A implies A contains one of B |
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 must 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 must preserve the order for a repetitive list. This is explicitly stated in 4.1.3.3.8, Preservation of Order.
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 meaning described in Table 5 -, BNF Notation.
Symbol | Meaning |
|---|---|
term enclosed is used any number of times (not used, used once, or used several times) | |
The ordering relationships between the logical constructs of this standard in the transfer are designated in Table 4. This table also designates the relationships between the logical constructs and the implementation and media constructs.
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 must be the first modules in the sequence. Unless otherwise specified by the Catalog/Directory module, the remaining modules must be organized in the order that they appear in section 5, Transfer Module Specification. 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 must be easily identifiable, preferably through file names that reflect the module type. Regardless of the type of media used, each global information module (Table 10 -, Global module types) must be contained in one or more separate files that contain only that module.
Modules may be included or omitted, with the following exceptions:
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 must occur in the order dictated by the spatial data model (2.1.2).
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 must be identical for each module record. Multiple Object Representation codes are allowed within the same module.
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 record 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:
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 must 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:
<module record> ::= <Primfield> <Primfield> ::= <Subfield1>, [<Subfield2>], . . [<Subfieldn>]
<module record> ::= <Primfield>, <Secfield1>, [<Secfield2>], . . [<Secfieldn>]
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).
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 of part 3 that uses tagged fields. The meaning of missing module fields is specified in 4.1.3.3.9. Mandatory fields must not be null. The mandatory absence of fields must have the meaning of "undefined, not relevant," as specified in 4.1.3.3.9. Mandatory fields in mandatory modules must never be absent or null.
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 of part 3 that uses labeled subfields. The meaning of missing module subfields is specified in 4.1.3.3.9. Mandatory subfields must not be null. The mandatory absence of subfields must have the meaning of "undefined, not relevant," as specified in 4.1.3.3.9. Mandatory subfields in mandatory modules must never be absent or null.
Extra module fields and subfields must not be added to nongeneric specifications, except under private agreement. The names and mnemonics used for any additional fields and subfields, under such an agreement, must not duplicate any of those specified in the standard.
For a repetitive list, the implementation must preserve the order as received from the sender, and on output, preserve order as found on the media.
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:
Structure indicated null values may be manifest in two ways:
For the purposes of this standard, the default method for indicating null values must be through the structure imposed by the implementation. Empty fields and subfields must have the meaning of "missing, relevant but not known," while missing fields and subfields must 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 must fully describe the selected method in the data quality Logical Consistency module, and if applicable, must 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.
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.
As indicated in Table 4 -, Relationships between the transfer logical constructs, implementation constructs, and typical medium constructs., 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 must 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 has 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.
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 has one field consisting of subfields which contain module name and type for two modules.
Relationships between modules and spatial domain, map, theme and aggregate object (e.g., graph) are expressed through the Catalog/Spatial Domain module.
Explicit relationships between module records are established through module record identifiers and foreign identifiers.
Module Record Identifiers - A module record identifier must 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 must be unique within the module.
Foreign Identifiers - References to other records from a given record must be made through foreign identifiers. Foreign identifiers consist of three subfields: (1) Module Name, (2) Record ID, and (3) Usage Modifier (See "Foreign Identifier" on page 36.) 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.
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:
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 must 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 must 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.
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 must contain data that have a specified relationship to latitude and longitude, while this relationship must 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 must 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:
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:
The standard provides the necessary information to transform spatial addresses from one reference system to another for the following transformations:
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 must meet the stated requirements.
Further information concerning the preferred external spatial reference systems see Annex D .
This standard allows for geospatial and nongeospatial 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 and (or) additional non-geospatial dimensions are 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 Specifications for additional non-geospatial dimensions are provided in 4.1.3.5.6.
Internal to the standard, the components of the spatial address are subfields with the labels X, Y, Z, and nongeospatial labels defined in the Dimension Definition module. The Z component of the spatial address must always correspond to the Z component of the selected external reference system. The X component of the spatial address can be assigned to either one of the horizontal components of the selected external spatial reference system, and similarly the Y component. The selected assignment must be communicated through the Spatial Address Component Label subfields in the Internal Spatial Reference Module. Additional nongeospatial dimensions are added to the spatial address by referencing Dimension Definition records through the Dimension ID field of the Internal Spatial Reference module.
Latitude and longitude are angular quantities and must be expressed as decimal fractions of degrees. Whole degrees of latitude must be represented by a two-digit decimal number ranging from 0 through 90. Whole degrees of longitude must be represented by a three-digit decimal number ranging from 0 through 180. When a decimal fraction of a degree is specified, it must be separated from the whole number of degrees by a decimal point.
Latitudes north of the equator must be specified by a plus sign (+), or by the absence of a minus sign (-), preceding the two digits designating degrees. Latitudes south of the Equator must be designated by a minus sign (-) preceding the two digits designating degrees. A point on the Equator must be assigned to the Northern Hemisphere.
Longitudes east of the prime meridian must 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 must be designated by minus sign (-) preceding the three digits designating degrees. A point on the prime meridian must be assigned to the Eastern Hemisphere. A point on the 180th meridian must 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.
The Universal Transverse Mercator Grid System must 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 must be a code to indicate the hemisphere in which the point is located. A plus sign (+) must be used to indicate the Northern Hemisphere, and a minus sign (-) to indicate the Southern Hemisphere. The remainder of the subfield must 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 must be the meter.
The Universal Polar Stereographic Grid System must 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 must 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) must be used in place of the 6 degree longitudinal band zone numbers.
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 must 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 must 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 (1.4.20). This four character code must be transferred in the Zone Number subfield of the External Spatial Reference module.
Altitude (1.5.2) 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 must be used to specify this surface.
All altitude measurements below the reference Vertical Datum must 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 must be consistent throughout a set of data.
The unit of measurement must be the meter.
If nongeospatial dimensions are used, the additional dimensions are defined by the user of this standard. The additional dimensions can be labeled, formatted, and described, and units can be applied through the Dimension Definition module. If additional metadata about the dimension needs to be encoded, the metadata can be encoded as attributes, referenced by the Attriubte ID field of the Dimension Definition module.
Attributes must be transferred as simple relational tables. Each Attribute module record must contain a table row. Two types of attribute tables exist: primary and secondary. Each table row must be stored as one module record of an Attribute Primary or Attribute Secondary module. The attributes must be separate from the spatial objects, but primary attributes must 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, one-to-many, many-to-one, or many-to-many link. For each spatial object there may be more than one Attribute Primary module record, and more than one spatial object may 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 must 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 follows where n is a constant for the module.
<Attribute Primary module record> ::= <module record identifier> [<spatial object ID>] [<attribute 1>] [<attribute 2>] . . . [<attribute n>] <module record identifier> ::= <module name> <record id> <spatial object ID> ::= <module name> <record id>
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:
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 must have the same definition and value domain throughout the transfer.
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.
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:
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 must be transferred through the data quality Lineage module (see 5.3.1).
Attribute and entity authorities must 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 must 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.
A foreign identifier must 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 must 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 must 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 must follow the Record ID directly (for example, SOILCHAINS#34L). When packed foreign identifiers are used, module names referred must 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>]
Attributes labels must conform to the "identifier" specification of the ANSI standard for the data base language SQL (1.4.11 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 must not exceed 18 characters. An attribute label must 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
The Data Dictionary will be used to describe the layers of a raster data set. The usage of the Data Dictionary modules will be similar to its usage for encoding attributes. For a given layer there will be one entry in the Data Dictionary Schema module, one entry in the Data Dictionary Definition module, and at least two entries in the Data Dictionary Domain module.
The Data Dictionary/Schema contains the format for the layer. The Attribute Label subfield value is a short name for the layer. This value will match the value found in the Layer Label subfield of the Layer Definition record corresponding to this D/D Schema record. This value will be unique between all layers of a transfer. This label will also be used as the subfield mnemonic for the subfield.
The Data Dictionary/Definition contains an english readable description for the layer. The Data Dictionary/Domain module usually contains at least two records for each layer, one for the minimum value and one for the maximum value the layer will contain. Other special purpose values can be coded here as well, like the meaning of categories in a thematic map.
|
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_nov97/part1b18.html Last modified: Monday, 14-Jan-2013 19:27:54 EST Maintainer: mcmcweb@usgs.gov Privacy Statement || Disclaimers || FOIA || Accessibility |