DLG-E/SDTS Transfers
Part 3: DLG-E/SDTS Transfers describes the Digital Line Graph - Enhanced transfers as sets of modules and groups of module records.
Section 8: The DLG-E/SDTS Transfer 8. The DLG-E/SDTS Transfer
The SDTS defines 34 types of modules and rules of usage. It is up to the SDTS-user to select the set and mix of modules that will 1) meet the requirements of the SDTS and perhaps a profile, and 2) satisfy the needs of preserving user-data-model information. Part 2 of this document dealt with preserving the information content of the DLG-E model. It described how different components would be encoded and how the constructs of the SDTS would be used. Part 3 describes the types of transfers and their module sets required by both the DLG-E encoding and the SDTS/TVP.
The purpose of this section is to describe a DLG-E/SDTS transfer. This will be approached by first describing the "transfer" itself, then by describing its set of modules, and finally by describing the module records of each module. This order reflects the succession of SDTS constructs: transfers are composed of modules are composed of records are composed of fields are composed of subfields (which actually contain the data.)
8.1 What is the DLG-E/SDTS Transfer?
The highest organizational construct in the SDTS is a "transfer". A transfer is a set of modules that conform to the usage rules of SDTS and/or a profile. One of the issues for a SDTS-user to address is what constitutes a transfer?
National Mapping Division of the U.S. Geological Survey (USGS/NMD) had the choices of:
USGS/NMD decided that the data packaging decision is reflected in the producing of the E dataset. Therefore, one DLG-E dataset would be made into one DLG-E/SDTS transfer so as to preserve the original packaging.
8.2 Module Set for a DLG-E/SDTS Transfer
This section will describe the set of modules needed to create a DLG-E/SDTS transfer that conforms to the Topological Vector Profile.
The following table lists the set of modules. It has the module type in the first column, the cardinality in the second column, the source of the requirement in the third column, and the DLG-E concept being represented in the fourth column. The "#" column specifies the number of occurrences of the module type per a single transfer. When the number is followed by a dash ("-") this means it is a maximum and the actual count could be less. The "Reqrd By" column specifies whether the module is required because of the SDTS, or the TVP, or because of the DLG-E model encoding. The "DLG-E Concept" column is included to aid in relating the set of modules to DLG-E components.
There is a fixed set of 14 modules per transfer (Identification, Catalog, Spatial Reference, Transfer Statistics, DQ Report, and Schema.) The rest of the module counts depend on occurrences of instances in a specific dataset.
The spatial modules have an "n" in their cardinality. The "n" stands for number of surfaces in the dataset. This can range from 1 to 14 presently (most likely 3 to 9). There is a maximum of 5 and a minimum of 4 spatial modules per surface. (A particular surface may not have any "Points".) For those of you who love equations:
The number "x" is just one piece of the module count for the transfer. The number of modules per transfer is very DLG-E dataset dependent.
Their is a maximum of 5 composite modules and a minimum of 3. (There may be no occurrences of Non-spatial Feature Objects and/or Compound Feature Objects in a dataset.)
The attribute module count is most dependent on the instances in the dataset. For example, there is an attribute module for feature "reef." If there are no reefs in the dataset, then this module is not included. The occurrences of feature types and relationships is very dependent of the geographic domain.
So, how many modules are in a DLG-E/SDTS transfer? 14 + x + (3|4|5) + ... The previous discussion illustrates why that question does not have a simple answer. Explaining what causes the variation in the counts will provide data decoders with valuable information about what to expect.
8.3 Module Records for the DLG-E/SDTS Transfer
The SDTS contains module specifications for each of its module types (see Part 1, Section 5 of the SDTS.) A module specification describes a generic record layout with fields and subfields and rules for inclusion and repetition. The specifications for the modules were used to design specific module record layouts for the encoding of the DLG-E model. This section describes the different types of logical records for each module type.
Each module record layout is described by listing its subfields, describing the information needed for the subfield, and explaining the source of the information. The subfields are defined by the SDTS and are referenced here by their mnemonics in column "Subfield". The "Contents" column describes the information or the constant used by the subfield. The sources of information are provided in the table column "Source" via the use of the following codes:
The order of entries in the tables follow the order that fields and subfields are listed in the SDTS module specification (SDTS, Part 1, Section 5.) The tables start with the subfields for the Primary module field. A Secondary module field is denoted by inserting a line in the table immediately prior to the first subfield of the secondary field.
Secondary fields that are foreign identifier references are handled differently. (These are denoted by a "(^)" in an SDTS module specification.) The field mnemonic will be placed in the subfield column. The field mnemonics will be lower case and preceded by a caret "^". The tables in this section should be used in conjunction with the module specifications in the SDTS so there should be no confusion about field and subfield. (Well, okay maybe a little.) For the case of a foreign id field, the "Content" column will describe the contents of the module record that is being referenced.
The Identification Module provides identifying information about the data content of the transfer, about the version of the SDTS and possibly a profile, and about conformance to features and reference systems.
There is one Identification Module. There will only be one record in the Identification module. It will represent the concept of a DLG-E Dataset. As such, DLG-E dataset attributes are referenced by the identification record.
8.3.2 Catalog/Directory Module
The Catalog/Directory module describes which modules are in which files and whether modules are internal to a transfer or external. There is one Catalog/Directory module. It will contain both of the record types described below.
The TVP requires that each module have its own file. A file can be split only if constrained by file size. In general, there will be one record for every module in the transfer.
For internal modules:
In the case of using a master data dictionary, the data dictionary modules are not included in the transfer and are considered external. There will be one record for each external data dictionary module required by this transfer.
For external modules:
8.3.3 Catalog/Cross-Reference Module
The Catalog/Cross-Reference Module describes relationships or links between entire modules. This information is largely intended for human interpretation (i.e. little automated processing based on this information because of its unstructured nature.) There is one Catalog/Cross-Reference Module.
As required by the TVP, the Data Quality module that explains a null scheme will be cross-referenced to the modules to which it applies.
8.3.4 Catalog/Spatial Domain Module
The Catalog/Spatial Domain Module defines the relations between a module and a spatial domain, partition (map), theme, or aggregate object. The TVP requires that modules be related to partitions (maps) and themes and that the aggregate object used is that of a 2-D Manifold (object representation code "GT".) There will be one Catalog/Spatial Domain Module.
There will be one record for every module in the transfer. In DLG-E, there will be multiple 2-D manifolds (E surfaces) per transfer. The modules related to the same surface will share the same value in the "Aggregate Object" (AGOB) subfield. This subfield can be used to locate the set of spatial object modules that belong to the same surface. In a similar manner, the value in subfield "Map" can be used to find all modules related to the same partition. In a DLG-E transfer there will be only one partition so the "Map" subfields happen to all have the same value.
8.3.5 Internal Spatial Reference Module
The Internal Spatial Reference Module describes the coordinates used in the transfer and defines the translation and scaling to convert from the internal (to the transfer) coordinate system to the system defined in the External Spatial Reference Module.
The TVP allows one module per partition. In DLG-E, there is one partition so there is only one Internal Spatial Reference Module. There is one record in the module that describes the internal coordinate system that applies to all coordinates in the spatial object modules.
SDTS restricts the unit of measure in the external reference system to meters. Coordinates stored in the internal reference system in feet (State Plane Coordinate System) need to include the effect of feet to meter conversion in the scaling factor subfields.
8.3.6 External Spatial Reference Module
The External Spatial Reference Module defines the external spatial reference system and its relationship to latitude and longitude. There is only one External Spatial Reference Module. It contains one record.
The Spatial Domain Module specifies the geographic domain within which the coordinates used in the transfer are contained. There is one Spatial Domain Module. It contains one record which uses the minimum bounding rectangle technique.
8.3.8 Data Dictionary/Schema Module
The Data Dictionary/Schema Module describes the Attribute Primary and Secondary Modules that are contained in the transfer. The attribute modules require a SDTS-user to add subfields to meet the needs of their data model. As these are user-defined subfields, the descriptive information about these "subfields" must also be encoded in the transfer---hence schema records.
A schema record describes a table column by giving it an attribute label (i.e subfield name), a data format, units, and maximum length. It also serves the role of associating an attribute table with its entity type. (There is an example Schema module in Appendix D.)
There is one Schema Module. The contents of the schema records are generated by work done on attribute table design. There is one schema record for every column in an attribute table. In module terms, there is one schema record for every user-defined subfield as it occurs in every attribute module. The set of attribute modules required by a specific transfer is based on the instances in a E dataset. Once the set of attribute modules required by a specific transfer is determined, then the set of schema records can be determined.
8.3.9 Transfer Statistics Module
The Transfer Statistics Module describes size information about each module: its number of records and number of spatial addresses. The purpose of this module is to provide data volume information to potential data decoders. There is one Transfer Statistics Module. There will be one record for every module in the DLG-E transfer.
In keeping with the "self-contained" philosophy of the SDTS, the data quality report is mandatory. It is the responsibility of the data producer to report what data quality information is known. It is the responsibility of a potential data user to determine whether data is suitable for a given application.
Data quality information can be reported at any level: dataset, theme, partition, feature, or spatial element. Data quality information can be reported via textual narration, attributes, and/or a quality overlay.
There will be one each of the five data quality modules. DLG-E will use textual narration to explain production processes that insure a certain degree of data quality. There are attributes at the dataset, theme, surface, and feature level that provide some data quality information. The presence of these attributes will be denoted in the appropriate data quality module. There will be statements in the Logical Consistency module that explain certain aspects of the DLG-E encoding technique.
The Lineage Module describes the derivation of the data contained in the transfer. DLG-E will describe the source used in generating the data content of the transfer. DLG-E will also denote the attributes that contain lineage information. There will be one record describing source. There will be one record discussing each lineage attribute.
8.3.10.2 Positional Accuracy Module
This module contains statements regarding the positional accuracy of the coordinates included in the transfer. There will be one record for each "positional indicator" attribute on features. As required by the TVP, a note about the data may contain cartographic offsets as it was collected from a graphic map will be included.
8.3.10.3 Attribute Accuracy Module
This module contains statements regarding the accuracy of the attribute values. DLG-E will describe its production and post-production processes that verify attributes.
8.3.10.4 Logical Consistency Module
This module contains statements regarding the verification of topology, and regarding data encoding practices that are non-standard. The TVP requires an explanation of the null scheme used in the transfer. In addition, there are some aspects of the DLG-E encoding that will be explained in this module. There will be separate records for each issue.
This module contains statements regarding data collection criteria and "completeness" of the data content in the transfer. As required by the TVP, the meaning of composite objects with no components will be explained.
8.3.11 Attribute Primary Module
The Attribute Primary Module is used to encode descriptive information. The other modules in a transfer point to their attribute records via foreign id references. The attribute modules require a SDTS-user to add subfields to meet the needs of their data model. Each record in an attribute primary module must use the same set of subfields---i.e. one record layout per module.
For data models that are feature-based, the TVP requires separate attribute tables for each entity. The DLG-E uses attribute modules for dataset attributes (3 tables), theme attributes (4 tables), surface attributes (1 table), and feature attributes (113 tables). (The design of these tables is discussed in Sections 5,6, and Appendix A.) The maximum number of Attribute Primary modules in a transfer is 121. This is very unlikely however, because only the attribute modules that correspond to entity instances in the dataset are included in a transfer.
In the DLG-E encoding, spatial objects do not carry attributes. Only the identification record and the composite records reference attribute primary records. The entity and attribute labels of the attribute table are defined in the Data Dictionary. The Schema records associate an attribute table with the entity type it represents. (There are example attribute and schema modules in Appendix D.)
8.3.12 Attribute Secondary Module
The Attribute Secondary, like the Primary, is also used to encode descriptive information. However, its records are not allowed to be referenced via foreign ids. The only way to reference its records are via relational joins with other attribute (primary or secondary) tables.
DLG-E required a method for encoding relationships between other-than-spatial objects (i.e. dataset, surface, theme, and feature objects). Attribute Secondary modules were chosen. The Attribute Secondary module records point to the composite object records that participate in the relationship by using foreign ids as attribute values (SDTS, Part 1, Sect. 4.1.3.6.7) The table designs for relationships are discussed in Section 7.3.
There is a separate module for each type of relationship (7 of them). There is a maximum of 7 Attribute Secondary modules in a transfer. If no instances of a relationship type occur in an E dataset, then its attribute secondary module is not included in the transfer.
The relationship type (as an entity) and its attribute labels are defined in the Data Dictionary. The Schema records associate an attribute table with its entity type (in this case relationship type.) (There are example modules in Appendix D.)
The Composite Module is used to represent composite objects, which are aggregates of other spatials and/or composites. The TVP extends the composite to include objects without components. The composite represents a general mechanism and hence, its meaning in a transfer is defined by the data encoder based on their user-data-model. The composite will be used by DLG-E to represent any object that has attributes and/or participants in relationships.
In DLG-E, there are five uses for the composite module: themes, surfaces, basic features, non-spatial features, and compound feature objects (from Section 4.) Each of these will have their own module in a transfer. There will be one record for each object instance in the DLG-E dataset. (There is an example composite module in Appendix D.)
For Theme Object:
For Surface Object:
For Basic Feature Object:
For Non-spatial Feature Object:
For Compound Feature Object:
The Point-Node Module is used to represent 0-dimensional spatial objects. The TVP restricts this module to have only records representing the same type of spatial object (i.e. must have the same object representation code.) There are three different uses of this module in DLG-E: Nodes, Polygon Points, and Points. Each object will have its own module. The TVP also requires that the spatial objects in a module all belong to the same 2-D Manifold. In DLG-E, there will be a set of modules for each Surface.
For DLG-E Nodes
For DLG-E Polygon Points
For DLG-E Points
The Line Module is used to represent 1-dimensional spatial objects. In DLG-E, the line module will be used for complete chains. The TVP requires that the spatial objects in a module all belong to the same 2-D Manifold. In DLG-E, there will be a single Line module for each Surface.
The Polygon Module is used to represent 2-dimensional spatial objects. In DLG-E, the polygon module will be used for GT-Polygons. The TVP requires that the spatial objects in a module all belong to the same 2-D Manifold. In DLG-E, there will be a single Polygon module for each Surface. The first record in each module will be the Universe Polygon.
Pending issue of Void Polygons:
The SDTS recognizes void polygons as distinct spatial objects. Currently void polygons do not occur in DLG-E data. It is yet to be determined how "void areas" will be handled in the DLG-E model--at the spatial level, or the feature level, or perhaps some other mechanism.
|
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/emapoct_93/section8.html Last modified: Monday, 14-Jan-2013 19:28:55 EST Maintainer: mcmcweb@usgs.gov Privacy Statement || Disclaimers || FOIA || Accessibility |