U.S. Geological Survey
926 National Center
Reston, VA 20192
Telephone: (703) 648-6349
Fax: (703) 648-6953
e-mail: mmcrae@usgs.gov
In many common geographic information systems (GIS), real-world objects are represented as points, lines, or polygons. The spatial representation of the object (i.e., the point, line, or polygon), in turn is often associated with tabular data. In Arc/Info, points, lines, and polygons are referred to as features and are stored in coverages (thematic data layers). Tabular data pertaining to these features is stored in feature attribute tables.
The mathematical procedure for representing geometry and spatial relationships of these features is called topology. According to Understanding GIS: The Arc/Info Method (Environmental Systems Research Institute, Inc., 1997), the three major topological concepts are 1) lines (arcs) are connected at nodes, 2) arcs that connect to surround an area define a polygon, and 3) arcs have direction and left and right sides.
Certainly, topology based on points, lines, and polygons adequately represents many geologic features, especially if those features represent single observations. For example, a sample location may be represented by a point, or an outcrop location by a point or polygon. However, many geologic objects are not easily represented by a single feature. This is further complicated by the mechanics of the topological data structure, which often undesirably fragment lines and polygons by placing nodes at line intersections. Consider two cases. In the first example, a single fault is offset by an intersecting fault, creating two individual line segments. In the second example, a bedrock geologic map shows multiple locations where a sedimentary unit has been eroded to reveal an underlying volcanic unit. Although the mapping geologist may have interpreted the fault segments as part of one system or the individual volcanic unit polygons to be part of a continuous unit at depth, this interpretation is obscured by fragmentation by the software. Although the attribute tables usually reflect this information, the visual integrity of the unit is compromised. Further, database size is negatively impacted, since individual entities have their own records in the feature attribute table. Does this system adequately represent our knowledge of the known geology? Or are there tools that can help us both maintain the geologist's interpretation of the data and minimize storage requirements?
Arc/Info provides two other feature types often overlooked by the geologic community: regions (which are based on polygons) and routes (which are based on lines). Essentially, regions and route systems aggregate overlapping, noncontiguous, and nested features, allowing the user to model them as singular entities. There is no limitation on the number of regions or routes that can exist within a coverage. When a region or route is initially created, a subclass name is assigned. Each region or route subclass then has its own feature attribute table. Further, region or route subclasses can be aggregated into larger region and route systems. It is important to note that the addition of these features types does not take away the geologist's ability to attribute individual entities. Individual polygons can still be attributed in the polygon attribute table. Route systems are even more flexible, allowing the user to attribute individual sections within a route.
If the volcanic unit discussed above was incorporated into a region subclass, the database user would better understand how the field geologist viewed the unit: as multiple occurrences of a single unit. In addition, the database size would be minimized as the attributes pertaining to each individual polygon are consolidated into one. Similarly, it may be advantageous to construct route systems with thrust, normal, and strike-slip subclasses. That way, individual faults of each type can be placed in their respective subclass without losing the ability to attribute individual fault segments.
In conclusion, regions and route have a wealth of applications in geologic data modeling. Although I have provided two cases of how they may be applied, their inherently hierarchical nature raises many implementation questions. Certainly, it is not advantageous to implement them in every case where lines or polygons share attributes. How extensively should they be used? When you do decide to implement them, how do you determine the fundamental "building block" (i.e., the least divisible geologic object) of your region or route system? What are the ramifications of exporting data with region or route system topology to other GIS software? These questions need to be addressed in order to thoroughly exploit the utility of these powerful tools.
|
Return to Table of Contents
This site is https://pubs.usgs.gov/openfile/of99-386/mcrae.html
|