The following contains the conventions and notation for the module specification tables of section 5.
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 is also the module type. Subfield names must identify the data content of the module records. The Data Type indicates the manner in which the subfield will be encoded. Each of the codes have the following meaning:
A: graphic, alphanumeric, or alphabetic chars 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: char mode bitfield (zero and one chars)
In some instances, one may select from two or more 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 must 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 must be interpreted as an unsigned integer with the most significant bit first and least significant bit last.
The domain column specifies the set of values that may be encoded within the indicated data type. There are nine major domain specifications:
In the first six cases (a, b, c, d, e, f), the domain column must indicate "Alphanum," "Integer," etc.
In case (g), the permitted values must be listed, and each value must 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 must 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 is no difference in meaning between a negative or positive zero. The actual implementation of an integer or real number must be according to the domain Data Type in the Domain Description column 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 must 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 6 contains a complete enumeration of the character sets to be used for the graphics characters, alphabetic, numeric, and alphanumeric domains. All graphics characters must 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.
Various specification elements, such as module names, field names, and subfield names, can be specified generically rather than explicitly. In this case, the user must 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 must 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).
Graphics Characters | |||||||||
|---|---|---|---|---|---|---|---|---|---|
Alphanumeric | |||||||||
Alphabetic | Numeric | ||||||||
E2 | |||||||||
SPACE3 | |||||||||
This subsection specifies notation conventions for the nature and character of field names and subfield names occurring in the module specification tables. A summary of this section is provided in Table 7.
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.
Generic field names and subfield names are specified in lower-case alphabetic characters only, and the entire name is to be replaced, according to the instructions for the particular specification.
After substitution, all specifications appear as though they were explicit specifications.
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 must 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 within 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)
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
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. (Not currently used anywhere in this standard. Subfields only repeat if the entire containing field repeats.)
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 "-".
Subfields that have a specified default value will be prefixed with the symbol "d". The default values are specified in the standard.
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 specification tables 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 Mandatory absence presence M Mandatory Optional presence presence X Mandatory Optional absence presence O Optional Mandatory presence 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 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 Chain Component ID field in the Line module is optional if the Object Representation Codes "LE", "LL", "LW" or "LY" is used or the Spatial Address field is used. This is indicated as: Chain Component ID [O/LE|LL|LW|LY/Spatial Address]
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 ::= '[' <status key>
['/' <object representation codes> ]
['/' <field and subfield names > ] ']'
<object representation codes> ::=
<object representation code>
{'|' < object representation code> }
<field and subfield names> ::=
<field or subfield>
{ <separator> <field or subfield>}
<field or subfield> ::=
<field or subfield name>
[ ' = ' value ]
<separator> ::= '|' | '+'
<field or subfield name> ::=
<character string> |
<'character string'>
Each field or subfield can have one or more status codes, indicating the conditions under which the field or subfield should be included, excluded, or optionally included. A field or subfield can have a single status code with an attached condition. If the condition is false, then the disposition of the field or subfield depends on the status code as indicated in the table above. For multiple status codes, the disposition of the field is determined by the intersection of the logical conditions resulting from each status code.
The status codes are relative to the optionality of the module so that when a field or subfield is mandatory, it is mandatory within each SDTS transfer only if the module in which the field or subfield occurs is mandatory.
The notation conventions are as follows:
All fields will have one field class code of (P), (O), (O/x), (R), or (N). Each field or subfield may have zero, one, or more status codes: [A], [M], [X], and [O]. Zero status codes means completely optional. Multiple status codes means the intersection of the interpretations. See Table 7 -, Summary of the special flags used with field names and subfield names.
Flag | Used with | Meaning |
|---|---|---|
User must substitute one or more explicit subfields with user-assigned names for the generic subfield in the generic specification. | ||
Subfield with given name and type can be repeated an indefinite number of times. (Currently not in use.) | ||
Secondary module field where order of repetition is significant and the criteria for order are specified. | ||
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). | ||
Secondary module field where order of repetition is not significant. | ||
Contents and structure of the field is that of a spatial address. (see Table 8) | ||
Contents and structure of the field is that of a foreign identifier. (see Table 9) | ||
Mandatory absence if condition true; otherwise mandatory presence. | ||
|
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/part1b19.html Last modified: Monday, 14-Jan-2013 19:27:55 EST Maintainer: mcmcweb@usgs.gov Privacy Statement || Disclaimers || FOIA || Accessibility |