Section 7: Mapping of DLG-E Relationships
7. Mapping of DLG-E Relationships
In the DLG-E model, a "relationship" is a defined link between objects. All DLG-E object types participate in relationships---spatial objects, feature objects, attribute objects, dataset object, theme object, and surface objects.
Not all DLG-E relationships are expressed in the same manner. Some relationships between objects are implied. For example, dataset contains feature is an implied relationship by the occurrence of feature objects within a dataset object. Other relationships are expressed by element values. For example, the surface contains theme relationship is represented by the theme having a "containing surface" element. Other relationships are explicitly represented by relationship objects. These types are defined by the Standards Database. For example, instances of "Feature is bounded by Feature" relationship objects are created as needed by the data.
It is important to recognize all of the relationships in the DLG-E model and to insure that these are preserved in the SDTS mapping. The next section describes all of the relationships in the DLG-E Model. Subsequent sections describe the mapping of each relationship into the SDTS. For those relationships to be encoded using SDTS attribute tables, the last section details their attribute table designs to accomplish this encoding.
The relationships in the DLG-E model can be categorized based on the object type of the participants. This gives rise to three categories of relationships: topological, feature, and dataset-level. Each of these is described in detail in the following sections.
7.1.1 Topological Relationships
The topological relationship category includes all the relationships involving spatial objects as both participants. These relations are an inherent part of the DLG-E model as it is based on the topological-vector concept. The specific topological relationships included here are all expressed as element values. The following table lists the spatial object type with its element(s) that represents its relationships.
A DLG-E Surface is an aggregate spatial object. Each spatial object is an element of one surface object. The Spatial object belongs to Surface object relationship is implied.
The feature relationship category includes all the relationships between feature objects and between feature and spatial objects. All of these relationship types, as listed below, are defined by the Standards Database.
7.1.3 Dataset-level Relationships
The dataset-level relationship category includes all relationships between dataset, theme, and surface objects, and between these objects and feature objects.
A dataset object is the highest-level containing object. All of its relationships are of the contains type and are implied by other objects being collected as part of the DLG-E dataset. A dataset contains one or more features, one or more themes, and one or more surfaces.
A theme object is an association of feature objects. The Standards Database defines a "contains" relationship specifically for theme to feature links. A feature can belong to more than one theme. A theme can also be vertically aligned with another theme to be logically consistent (hydrography and hypsography for example) so the Standards Database defines an "aligned with" relationship between themes.
A relationship between theme and surface is handled via a theme object having a "containing surface" element. This implies that the set of features belonging to a theme have all of their spatial object components in the containing surface. A surface can contain more than one theme. A feature can belong to more than one theme as long as the themes are contained in the same surface.
The dataset-level relationships are stated as:
Each of the DLG-E relationships must be preserved in the SDTS encoding. Some are represented by how objects are grouped into modules, others are handled with standard fields, and others still are modeled as attributes.
The following sections describe how each category is mapped into the SDTS. The last section contains a table to summarize the mapping for each relationship type.
7.2.1 Topological Relationship Mapping There are many ways to represent topological information in spatial data models. The SDTS has standardized how topology is to be encoded by including standardized fields for topological information in the spatial object modules. The Topological Vector Profile has further restricted the amount of topological information to be encoded. The DLG-E mapping of topological relationships will conform to the requirements of the TVP.
Chains will have start node, end node, polygon left, and polygon right. (The Ring to Polygon relations will be used to convert ring references on a chain to polygon references.) Both the Point and the Polygon Representative Point will reference their containing Polygon. Nodes will not have any topological pointers. Polygons will not reference their bounding chains. All of these relations are handled via standard fields in the spatial object modules.
There may be (and usually is) more than one surface in a DLG-E dataset. To preserve the spatial object to surface relationship, each surface will have its own set of spatial object modules. All chains for surface 1 go in one Line module, all chains for surface 2 go in another Line module and so on. The set of modules will be delineated in the Catalog/Spatial Domain module as belonging to the same (SDTS) 2-D manifold aggregate object. Also, a surface composite record will reference its set of component spatial object modules.
7.2.2 Feature Relationship Mapping
The feature relationship category is mapped to SDTS using two methods: standard fields and relationships as attributes.
The is-composed-of relationships will be handled with standard fields. The SDTS defines a composite object as an aggregate of spatial objects and/or other composites. A DLG-E feature object maps to an SDTS composite object. The composite object has a standard field for referencing its component parts. This component field will be used to encode the DLG-E is-composed-of relationships. This will involve gathering up all of the is-composed-of relations for the same feature object and encoding as a repeating field. A"1-D BFO" composite must reference its linear components in order and denote forward and backward orientation for each chain (as required by the SDTS.)
The remaining feature relationships have no equivalent in the SDTS. The only mechanism that is available for encoding these relationships is an SDTS attribute table. This technique for encoding relationships as attributes is described in the Attribute Table Design section.
7.2.3 Dataset-level Relationship Mapping
The dataset-level relationship category is mapped to SDTS using two methods: module grouping and relationships as attributes.
A single DLG-E dataset will constitute a single transfer. Consequently, all of the relationships involving dataset will be implied by inclusion in the transfer. More specifically, the composite module for surface objects represents the dataset contains surface relationship. Similarly, the theme and feature object composite modules represent the other dataset contains relationships.
Composite module records will be used to represent the theme, surface, and feature objects. Relationships between these types of objects will be encoded as SDTS attributes. This technique for encoding relationships as attributes is described in the Attribute Table Design section.
7.2.4 Summary of Relationship Mapping
This section summarizes the mapping of each type of relationship. The left column contains the DLG-E relationship and the right column describes how it is mapped. The middle column contains a code to indicate the origin of the relationship in DLG-E: I for implied; D for data element from the DPDF; or S for defined in Standards Database. The table is sectioned by relationship category.
7.3 Attribute Table Design for Relationships
The SDTS attribute table construct can be used to serve a broader purpose than just the description of entities. Attribute tables can be used for "relationships" or "links" in a data model that are not accounted for by standard fields.
The spatial object and composite module records are used to represent objects. The attribute table then represents a "relationship" between these objects. The rows of the attribute table represent the specific occurrences of relationships between instances of objects.
The technique for encoding relationships using SDTS attribute tables is described in this section. Appendix D contains an example set of modules for a DLG-E relationship that illustrate the technique.
Each different type of relationship will have its own attribute table. The relationship type will be treated as an SDTS entity type. Hence, the relationship type will be given an entity label, authority, and definition in the DD/Definition module. The Schema records for the attribute table will reference the entity label of the relationship type.
The rows of the attribute table represent the instances of links between objects. In SDTS constructs, the objects are represented with spatial object and composite module records. The standard "pointer" to a module record is called a "foreign identifier." A foreign identifier is the pair module name and record id and it uniquely identifies every record in a transfer. Hence, the standard reference to an "object" is its foreign identifier. Consequently, the standard "pointer" will be used as the field values for relationship records, rather than a source-data-model-specific object identifier. SDTS permits the foreign identifier to be used as an attribute value (SDTS, Part 1, Sect. 4.1.3.6.7.) The Schema records for the "relationship" tables will have a caret ("^") as the data format which denotes the use of packed foreign identifiers.
The attribute labels (i.e. column headings) for the table will be defined in the DD/Definition module. The attribute labels may be used by more than one relationship type. The Schema records will describe the column headings used for each relationship table.
The SDTS has Attribute Primary and Attribute Secondary module types. Only Attribute Primary module records can be directly pointed to from other module records. The Attribute Secondary module records are accessed by relational joins. "Relationship" records more closely resemble Attribute Secondary records as they are not pointed to by other module records. "Relationship" tables will be Attribute Secondary modules.
There are many DLG-E relationship types that will use the SDTS attribute table technique. The labels and definitions for each relationship table are described in the following section.
7.3.2 DLG-E Relationship Table Design
This section describes the specifics for each DLG-E relationship type that is to be modeled as an SDTS attribute table. The relationships are identified in the previous sections discussing the mapping of all DLG-E relationships. (See Appendix D for an example set of modules for one DLG-E relationship.)
7.3.2.1 Attribute Labels for Relationships
There are some relationships that can make use of the same attribute labels for their column headings. The set of attribute labels is listed and defined here. Specific relationship table designs will refer to these labels as needed. (Note: Integers are appended to some labels because an attribute table cannot have duplicate column names.)
7.3.2.2 Details for Attribute Tables
This section contains the details for each of the relationship attribute tables.
Feature Is Above Feature
Feature Flows To Feature
Feature Connects To Feature
Feature Is Bounded By Feature
Theme Contains Feature
aaa
Theme Is Aligned With Theme
Theme Is Contained In Surface
|
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/section7.html Last modified: Monday, 14-Jan-2013 19:28:55 EST Maintainer: mcmcweb@usgs.gov Privacy Statement || Disclaimers || FOIA || Accessibility |