Digital Mapping Techniques '03 — Workshop Proceedings
U.S. Geological Survey Open-File Report 03–471

Geologic Map Database Implementation in the ESRI^TM Geodatabase Environment

By Stephen M. Richard

Arizona Geological Survey, 416 W. Congress # 100, Tucson, AZ 85701
Telephone (520) 770-3500; fax (520) 770-3305; email Steve.Richard@azgs.az.gov

Introduction

The Arizona Geological Survey (AZGS) has been producing 1:24,000-scale geologic map deliverables for the National Cooperative Geologic Mapping Program since the inception of the program. Digital compilation and production of map deliverables started on a prototype basis in 1998, using ArcEdit for map digitizing, and ArcView 3.2 for cartographic production. Map layouts were converted into Adobe Acrobat documents, and are available on CDROM or as hard copy generated using an HP 755CM large-format inkjet printer. The release of version 8.3 of ArcGIS, with the capability of enforcing topological relationships between geologic lines (faults and contacts) and polygons, makes it possible to do the entire map compilation and production process in one software environment. Digital compilation and cartography is done by the mapping geologists at the AZGS, and the ability to do all map production work in one software environment means the geologists need only learn one software package. In order to reduce the amount of software training necessary, we decided to convert to map production using ArcGIS 8.3, and in 2002–2003 produced 7 quadrangle-map deliverables using this product.

AZGS geologic map databases have been produced with spatial data in ArcInfo coverages and with thematic data (mostly metadata, so far) in Microsoft Access databases. The ESRI Geodatabase data model used in ArcGIS 8.3 allows implementation of an integrated database containing both spatial data and thematic data in one package. ArcGIS 8.3 introduced a new model for representing topologic relationships between geologic contacts and faults and the polygons representing outcrop of geologic units. The new software release also added some subtype and domain definition functionality. Production of geologic maps using the new software allowed us to investigate these capabilities for improved geologic map representation.

DATABASE CONCEPTUAL DESIGN

The data structure described here builds on the design described in Richard and Orr (2001), and is intended to conform to the conceptual model produced by the Data Model Design Team of the North American Data Model Steering Committee (NADMSC, 2003) (http://nadm-geo.org/).

GEODATABASE IMPLEMENTATION

The geologic map database implementation consists of a feature dataset (see table 1) that contains geologic points, lines, and polygons feature classes; a feature dataset for cross-sections; a feature dataset for cartographic objects in the map layout that have fill symbols corresponding to geologic units (map explanation, correlation of map units); and a group of tables containing thematic data. The AZGS implementation uses personal geodatabases, which are Microsoft Access .mdb files.

The geologic spatial data is in a feature dataset named GeologyFeatures. The spatial reference for the geology feature dataset was defined using a standard spatial reference system designed for the state of Arizona, with meters as the unit of measurement (Table 2). The coordinate system provides better than 1 millimeter (mm) possible precision for horizontal coordinates (see scale value in Table 2, 1/1533.9 m), which is considered quite adequate given that location uncertainty assigned to mapped geologic contacts by AZGS geologists is generally no better than 10 m.

The GeologyFeatures dataset contains a point feature class, line feature class and polygon feature class; and one topology. Points represent stations occupied in the field; they may be associated with one or more structural measurements, samples, photos, rock descriptions, etc. The line feature class represents contacts (depositional, gradational, intrusive. . .) and faults, and the polygon feature class represents outcrop of geologic map units on the map horizon depicted. User-defined fields for the line and polygon geology feature classes are identical to those described in Richard and Orr (2001). The table associated with point locations has been modified from the GeoPnt table described in Richard and Orr (2001) using feedback from AZGS geologists. The Station data feature class attributes (Table 3) are designed to accommodate all standard data collected in the field. Multiple instances of this class may share the same location, and contain different information ‘bits’ collected at that site. One topology is defined with the lines and polygons participating. Rules for this topology are summarized in table 4. These rules implement the same topology implemented in an ESRI polygon coverage.

Subtypes

The geodatabase data model allows one field in a table or feature class to be specified as a subtype field. The field must contain integer values. This allows subsets of a feature class to have distinct value domains defined for database fields, and to have distinct topology rules. The subtype hierarchy is only one level deep, and only one hierarchy may be represented. The subtype values must be entered by hand in a dialog, along with any description of the subtype (fig. 1).

Figure 1. Subtype definition dialog. CartoObjID codes are those defined by AZGS.

Several fields might be used as a subtype field for geologic lines (table 5). After consideration of the pros and cons, the CartoObjID field (symbolization selector field) was chosen to define subtypes. This has proven very useful in several ways. During data entry, the symbol is selected before digitizing a feature, and is immediately displayed on screen using standard geologic symbolization (defined using a standard legend file). The selected symbol provides constraints on data that may be entered in other fields. For instance, selection of a solid line implies a maximum value for the Accuracy field, depending on the map accuracy standard. The symbol also implies one or a few possible ConceptID values; if a thrust fault symbol subtype is selected, then the ConceptID must be the value for the thrust fault concept.

Domains

The geodatabase allows different value domains to be specified for fields in a table based on the subtype code. These domains are presented to the user as pick-lists (combo boxes) in the user interface (fig. 2). Definition of value domains is similar to definition of subtypes—entries must be typed value by value in a dialog box. There is no facility for representing hierarchical value domains. Construction of the domain lists is facilitated by a tool included in the ArcObjects developer kit (the extension is named Table2Domain) that constructs a domain from values from a stand-alone table. Each domain required must be defined as a separate table.

Figure 2. Subtype selection determines domains for some attributes. The Target control on the tool bar allows selection of the subtype for a new feature when digitizing. In this figure, assignment of a subtype value (fault) determines the value domain for the ConceptID attribute.

Relationships

The geodatabase model includes provision for representing relationships as relationship classes. These may be either simple or complex (geodatabase parlance). Simple relationships are essentially relational table joins stored in the geodatabase. Complex relationships are represented by a correlation table in the geodatabase, allowing each relationship link to have associated properties. Both kinds of relationships appear in the geodatabase table of contents viewed in ArcCatalog (fig. 3). The ArcMap interface allows editing of data in related tables by selecting a source object in the relationship. Thus, a line or polygon may be selected, and properties specified in related tables may be edited. The Identify dialog (opened by clicking on a feature using the ‘Identify’ tool on the ‘Tools’ toolbar) allows for browsing of links to related tables, to inspect the contents of linked records. Unfortunately, there is no way to control which linked information is displayed (fig. 4). Unlike explicit joins, which may also be constructed in the ArcMap environment, fields in tables linked by a relationship class do not show up in the Table view of a feature class, and are not available for constructing queries.

Figure 3. Relationship classes in ArcCatalog table of contents.

Figure 4. Identify Results dialog for geologic unit information linked to a polygon. Without significant customization, the significance of the various links is not apparent, and much unnecessary information is presented. Age of unit has a lowerBoundAge and UpperBoundAge that are both links to stratigraphic ages from a geologic time scale (such as Eocene). Each of these stratigraphic ages has a lower and upper bounding age (in Ma) that are stored in linked measuredQuantity objects. Science language terms (geologic unit type and rank) are hierarchical, and the hierarchy links appear due to the defined geodatabase relationships, not only immediate parent and child terms, but also to every other term with the same parents.

DIGITIZING WORKFLOW AND MECHANICS

The transition from digitizing coverages using ArcEdit to digitizing features in a geodatabase required rethinking the map construction workflow. Issues included when and how to generate polygons from digitized lines, the best method of editing topologic features, and procedures for editing map data. Because maps are compiled from field sheets, the AZGS map compilation process is incremental. Polygons are constructed as line work is digitized from scanned, georeferenced field sheets. First, a group of lines is digitized from a field sheet. Then, these lines are planarized (similar to ‘clean’ in Arcedit—producing nodes at line intersections and snapping where necessary) by selecting the lines and clicking the ‘Planarize Lines’ button on the Topology tool bar. The topology validator is used to fix all dangles and undershoots. Faults that end within a polygon are legal dangles and are marked as exceptions. When the line topology problems are fixed, the lines defining polygons to be generated are selected, and the ‘construct features’ button on the Topology toolbar is clicked. The Target (Editor toolbar) must be set to the geology polygon layer, and the Task (Editor toolbar) to ‘Create New Feature’. Once all polygons defined by line work on a field sheet scan have been constructed, a new field sheet scan may be started.

During the transition to map production in ArcGIS 8.3, some data were digitized using ArcEdit to produce coverages, which were then imported into geodatabase feature classes. This process worked well using the ‘Coverage to Geodatabase’ wizard, accessible by right-clicking on the geodatabase icon in ArcCatalog. This produces both a line and a polygon feature class. In order to integrate these into a single topology, so that lines or polygons may be edited keeping polygon boundaries coincident with lines, a new topology must be defined that applies the rules in Table 4 to the new feature classes. The new line and polygon feature classes must be in the same feature dataset to create the topology. Care must be taken that the cluster tolerance defined for the topology is less than the fuzzy tolerance for the coverage; if the fuzzy tolerance is too small, the coverage lines must be generalized (at the workstation Arc command line) using a weed tolerance slightly greater than the cluster tolerance for the geodatabase topology.

The ‘topology edit’ tool (Topology toolbar) works well for editing polygon boundaries with coincident lines. When editing at the junction of three or more polygons must be done, it is commonly easier to use the standard edit tool (Edit toolbar) with snapping set to “on” between the line and polygon features. The snap environment—which feature classes will snap, and whether snapping will occur between nodes, vertices, or edges—is set using the ‘Snapping. . .’ choice on the Editor drop-down menu on the Editor tool bar. The snap tolerance is set via the ‘Editing Options’ dialog accessed through the ‘Options’ choice on the Editor drop-down menu on the Editor tool bar. A value of 3–5 meters (m) seems to work well for the Arizona spatial reference system. Setting the ‘Sticky move tolerance’ in the same dialog to a value of 5–10 pixels avoids frustration with features being selected and moved accidentally when trying to select nearby features.

Adding and removing polygons can be done in a variety of ways. The topology tools offer several features that can facilitate the process. A polygon may be created by splitting an existing polygon. Set the edit target to the polygon layer, and select the ‘Cut polygon features’ choice on the Task drop-down menu on the Editor tool bar. Select the polygon to split, and with the ‘Sketch tool’ (pencil button), draw the line where the polygon will be split. After splitting, validate the topology, and the new polygon boundary will show up as a violation of the ‘Polygon boundaries must have coincident geologic lines’ rule (Table 4). In fact there are two topology errors, one for each polygon, but both are fixed by creating a line along the boundary. Clicking on the topology error with the ‘Fix topology error tool’ (Topology toolbar) selects both errors. Right clicking with the ‘Fix topology error tool’ provides choices for fixing the error, and ‘Create feature’ is the obvious choice. Unfortunately, this will create two new, coincident lines, and a new topology error because of the rule ‘Lines may not intersect’. Some trouble can be saved by having the ‘Error Inspector’ window open (click the ‘Error Inspector’ button on the Topology toolbar); then search for errors after doing the polygon split, right-click on one of the ‘Lines may not intersect’ errors and select ‘Create feature’. This creates just one line, and finishes the split operation.

When the new polygon overlaps more than one existing polygon, the new polygon may be digitized on top of the existing polygons. Validating the topology at this point results in errors because of overlapping polygons, and a polygon boundary without coincident lines. Using the ‘Fix topology error tool,’ right click on the line error produced along the new polygon boundary and select ‘Create feature’ to create a line on the new polygon boundary. Select this line and all existing lines it intersects and click the ‘Planarize Lines’ button on the topology tool bar to split the existing lines where they intersect the new polygon boundary (and vice versa). Using the ‘Fix topology error tool’, right-click on the area error created by the new polygon (overlap with existing polygons) and select ‘Create feature’ to insert the new polygon into the map topology by intersecting it with the existing polygons. The map geometry must then be cleaned up by 1) merging the parts of the new polygon created where it overlapped different polygons in the original map; and 2) deleting lines that were polygon boundaries within the new polygon.

MAP UNIT DESCRIPTION

The basic elements of geologic unit description are shown in figure 5. The GeologicUnitLexicon is a vocabulary of geologic unit names. Each is associated with at least one description in the GeologicUnitDescription table that is called the normative description. Other descriptions in the GeologicUnitDescription table may be associated with a geologic unit. Each geologic unit description pertains to some body of rock represented by an Extent object. This may represent an outcrop (point location), the rock exposed in some area (one or more polygons), or the entire geologic unit (in the case of the normative description). The geologic unit description contains links to terms from a geologic vocabulary (NGMDBScienceLanguage) that specify various properties of the unit (links labeled ‘PropertyTermLinks (many)’ in Figure 5). Some properties may be specified by complex data objects that are collections of more specific properties and relationships. Some examples include geologic unit thickness, age, surface character, and genesis. A geologic unit is composed of one or more parts, represented by the aggregation relationship from GeoUnitDescription to GeoUnitPart in the top left of figure 5. The parts of a geologic unit may be 1) an Earth material specified by a term in a geologic lexicon of lithologic classes (NGMDBCompoundMaterialLexicon); 2) an Earth material specified by an Earth material description but not part of a vocabulary (CompoundMaterialDescription); 3) a geologic unit from a geologic unit lexicon (GeoUnitLexicon), for instance, in the description of a stratigraphic group, the parts are named (in a lexicon) formations; or 4) a geologic unit description not part of a lexicon (GeoUnitDescription).

Figure 5. Generalized scheme for geologic unit description.

A more detailed entity-relationship diagram for the implementation of geologic unit description is shown in figure 6. A summary of the fields in each table is included in the appendix. Each table includes several standard fields. The Name field contains a text string used to identify each data instance. In the case of lexicon terms (GeologicUnit and CompoundMaterial) the name is the preferred name associated with a concept. For description tables, the name identifies the description, as an abbreviated summary of the description or some user-defined name. Tracking links (see below for discussion of ‘ID’ and ‘DS’ suffixes) associate data instances metadata documenting processing history and intellectual sourcing of data. OriginDate is an automatic field that records the data and time a record was created in the database.

Figure 6. Entity-Relationship schema for geologic unit description. Pairs of fields with the same name with suffixes ‘ID’ and ‘DS,’ such as GeoAgeID/GeoAgeDS, are links to data that may come from different tables. The ‘. . .DS’ value identifies the table that contains the linked record, and the ‘. . .ID’ value identifies the appropriate record in that table. This mechanism allows for different representations of a property’s value; for instance a geologic age may be a stratigraphic age range as shown in this diagram, but may also be reported as an isotopic age or a single stratigraphic age from a stratigraphic time scale. Other tables are used to describe geologic unit thickness, particle geometry, surface characteristics, and to record tracking (metadata) information. These have been omitted for simplicity.

Each geologic unit definition record in the GeologicUnitLexicon table contains a link to a type and rank term in the NGMDBScienceLanguage (GeoUnitTypeID, RankID); a name for the unit; a free text description explaining the intent of the unit; and the URL of the GeoLex record for the unit, if one exists. The geologic unit definition also includes a link to a normative description (DescID/DescDS), and a link to a geologic age description (GeolAgeID/GeolAgeDS). These links are compound (foreign key is based on two fields), with a ‘. . .DS’ value that specifies the data container (such as a table or view in a relational database) for related data, and the ‘. . .ID’ value identifies the particular linked data instance in that container. This convention holds for all table attributes that occur as pairs with the same name followed by the suffixes ‘. . .ID’ and ‘. . .DS’.

The GeoUnitPartDescription entity correlates a geologic unit description with its parts, which may come from GeoUnitLexicon, GeoUnitDescription, NGMDBCompoundMaterialLexicon, or CompoundMaterialDescription. Each part has an associated proportion, specified by a typical, minimum, and maximum value. The MeasuredQuantityTypeID attribute is a link to a science language term that specifies how the proportion values are to be interpreted—either as a value with uncertainty bounded by minimum and maximum values, or as a range with upper and lower bounds and a default typical value. Because the parts of a geologic unit may include other geologic units, the data structure is recursive. If the implementation constraints allow the most general application of this structure, standard SQL queries cannot be used to search for the occurrence of some particular lithology instance as a part of a geologic unit. The descriptions constructed thus far have avoided this difficulty by requiring geologic unit parts to come from a standard lithology lexicon.

A geologic unit also has an age, which may be specified in a number of ways, including a single term from a stratigraphic time scale (a geologic vocabulary), a range of ages specified by lower and upper bounds from a time scale, or a single numeric age (with error bounds) for an isotopically dated unit. In the implementation diagrammed in figure 6, geologic age is represented by a StratigraphicAgeRange entity that defines a lower and upper age boundary specified using named ages from a stratigraphic time scale. The StratAgeRangeConnector attribute specifies the relationship between the age range bounds and the occurrence of a specified event during that time period (see table 6). The time scale is represented by the StratigraphicTimeScale table, which associates each named time interval (such as Jurassic) with lower and upper time boundaries in million years before present (Ma) specified by linked MeasuredQuantity records. The MeasuredQuantity table is a general representation for measurements, and allows recording of uncertainty bounds, range quantities, measurement method, and tracking information.

The link between geologic unit descriptions and the spatial data in a geodatabase is obtained using a relationship class that links the MapUnitID in the geology polygon feature class to the InstanceID in the GeologicUnitLexicon table. Other relationship classes in the geodatabase link the geologic unit to its geologic age, normative description, and rank definition. Because relationship classes do not allow joining on compound keys, the current implementation requires that all geologic unit definitions, geologic ages, and science vocabulary are each contained in individual tables. Some significant customization of the ArcGIS environment would be necessary to realize the full expressive power of the relational implementation outlined here. Because of the complexity of the knowledge representation necessary to fully capture geologic unit description and Earth material description in a computer analyzable form, other knowledge representation tools, including frame-based and description logic systems, are being investigated for data storage and analysis.

REFERENCES

NADMSC (North American Data Model Steering Committee), 2003, NADM conceptual model 1.0, A conceptual model for geologic map information: preliminary website release under the auspices of the Geological Survey of Canada, the U.S. Geological Survey, and the Association of American State Geologists. Available at http://nadm-geo.org/.

Richard, S.M. and Orr, T.R., 2001, Data structure for the Arizona Geological Survey geologic information system; basic geologic map data, in Soller, D. R., Ed., Digital Mapping Techniques 2001, Workshop Proceedings, U. S. Geological Survey Open-File Report 01-223, p. 167–188, http://pubs.usgs.gov/of/2001/of01-223/richard2.html.

Appendix

Data dictionary for tables in Figure 6.

Data types are as follows. Boolean, real number, and integer are standard data types. Short text is text string <256 characters long. Long text is a text string longer than 255 characters, equivalent to an MS Access memo field. Links to a specified table (such as NGMDBScienceLanguage) are the datatype required by the unique identifier (key) for that table. The project is in the process of converting to system-assigned globally unique identifiers (GUIDs) as the key for data objects. Links to a table specified as a ‘description object’ are compound, with the first part identifying the record in the table (foreign key), and the second part identifying the table that is the source of the linked data. Appendix Table 1 lists fields that are present in all other tables.