Digital Mapping Techniques '00 -- Workshop Proceedings
U.S. Geological Survey Open-File Report 00-325
A Washington DC Area Geologic Map Database:
Working Toward Implementation of the
Digital Geologic Map Data Model
By Adam M. Davis, James Reddy, and C. Scott Southworth
U.S. Geological Survey
National Center, MS 908
12201 Sunrise Valley Drive
Reston, VA 20192
Telephone: (703) 648-6970
Fax: (703) 648-6937
e-mail: amdavis@usgs.gov
INTRODUCTION
Figure 1. Map of the Washington, DC area, showing the five 1:100,000 scale 30' X 60' quadrangles that will initially be used for the Washington D.C. area geologic map database (DCDB).
|
Members of the National Geologic Map Database Project and the Eastern Earth Surface Processes Team of the United States Geological Survey (USGS) are collaborating to create a Washington D.C. area geologic map database (DCDB). This effort involves combining geologic map information from the following 30' X 60', 1:100,000-scale quadrangles (Figure 1):
- Frederick
- Washington West
- Fredericksburg
- Baltimore
- Washington East
The digital data for this project are derived from 1:100,000-scale geologic map compilations. For each map, the original field work was done at multiple scales. The database is being designed using Microsoft Access, but the GIS coverages are stored in ArcInfo coverage and ArcView shape file formats. The database aspires to meet the USGS Eastern Region information management and map production requirements, while at the same time conforming to the Digital Geologic Map Data Model (referred to as the "Data Model" throughout) that is currently being developed under the auspices of the North American Data Model Steering Committee (http://geology.usgs.gov/dm/).
IMPLEMENTATION OF THE
DATA MODEL
The DCDB began as a set of Microsoft Access tables that contained columns (fields) for each of the data elements that the Eastern Earth Surface Processes Team collect and want to associate with their digital spatial data. Currently, the DCDB is in the process of being transformed into a format compliant with the Data Model, but in its present form is significantly different from the Data Model.
For the most part, the data fields of the DCDB each have a direct equivalent in the Data Model. However, the DCDB does have some fields and tables for which the Data Model does not contain an equivalent. For example, the DCDB contains a table dedicated to clast information and another dedicated to mineral information (for entire formations), neither of which have an exact equivalent table or even fields in the Data Model. Also, the DCDB stores geochronologic information associated with points separate from geochronologic information associated with formations or igneous bodies (i.e., there are two data tables for the different types of geochronologic information in the DCDB).
In addition, there are aspects of the Data Model that are not yet implemented or are implemented to a lesser extent in the DCDB. For example, the DCDB does not yet contain any metadata. Also, cartographic specifications are included in ArcInfo attribute tables and are not as extensive as those specified in the "legend" portion of the Data Model (Johnson and others, 1998).
The DCDB is also structured differently than the Data Model. Figure 2 is a relationships diagram that illustrates the current structure of the DCDB. In this figure, fields are marked that exist in the DCDB but do not have an identical match in the Data Model. Note that most relationships between tables are routed through the MAP_UNIT table. The MAP_UNIT field is used for relating many of the other data elements, similar to the COA_ID in the data model.
Figure 2. Diagram illustrating the relationships between data elements of the Washington D.C. area geologic map database (DCDB).
Data fields which do not have exact matches in the Data Model are marked with gray circles.
ISSUES ENCOUNTERED
As the Washington D.C. Area database effort progresses, we are addressing issues associated with implementing the Data Model. These issues relate to software, GIS, data storage, and data elements. Some issues are:
- Geologists record data elements not accounted for in the data model (e.g., they collect clast information and record which deformational event is associated with a rock unit's formation [e.g., Acadian Orogeny]),
- Geologists record data in such a way that it does not exactly fit the fields in the Data Model (e.g., recording primary and secondary minerals for the whole formation rather than for a lithology). As a result, table structure and names of fields may need to be different from that of the Data Model to maximize efficiency of data storage and use (e.g., the DCDB requires a "minerals" table in addition to a "lithology" table). Differences in the amount of normalization of the data may also be required,
- Database designers need to work with the field geologists in order to construct data entry tools and views for analysis,
- ArcInfo file structure governs parts of the database structure. Spatial data is stored in tables separate from their associated attribute data. Forming "joins" between these spatial data tables and other tables must be done through the ArcInfo attribute tables,
- Use of two software packages, ArcInfo (or ArcView) and MS Access, limits data storage and retrieval efficiency, because the two software packages must connect with one another through an ODBC driver,
- Problems with "edge-matching" of GIS coverages, including:
- Lithologic contacts offset at quadrangle boundaries
- Formation names inconsistent between quadrangles
- Formations divided into members in one quadrangle and not the other
- Geologists having different field interpretations
- Field work and cartography done at different times
- Different portions of the field work done at different times.
NEXT STEPS
Resolution of some of the issues mentioned above may require that fields be added to existing tables in the data model (e.g., the metamorphic table may need more fields). In other cases, entire tables may need to be added (e.g., clast information, and mineral information for whole formations versus individual lithologies).
Working with the geologists and analysts who will be using the database is another significant challenge for this implementation of the Data Model. The appearance of the data entry forms and views of the data will have to be compatible with the people using them. Normalized data tables can appear unfamiliar to geologists who commonly view tabular data in spreadsheet or other formats (similar to problems occurring between databases and analysts in other professions). "Queries" or "Views", depending on the database software, can be created to alleviate this problem, but complexity of the database and/or the data viewing client software increases as these "Views" and "Queries" must be stored and maintained.
In the interest of optimizing the data storage, retrieval, and analysis efficiencies of the database, the DCDB project may need to move away from its current software choice of Microsoft Access and ArcInfo (or ArcView). The project aspires to port (convert) the database into a single software or at least a more integrated software solution. After working through some of the issues mentioned in this paper, we hope to have a good prototype database that can be used as a building block for the National Geologic Map Database.
REFERENCE
Johnson, B.R., Brodaric, B., Raines, G.L., Hastings, J.T., and Wahl, R., 1998, Digital Geologic Map Data Model Addendum to Chapter 2 - Version 4.3: http://geology.usgs.gov/dm/.
U.S.Department of the Interior, U.S. Geological Survey
<https://pubs.usgs.gov/openfile/of00-325/davis.html>
Maintained by Dave Soller
Last updated 11.01.00