![](media/image1.png){width="1.0666666666666667in"
height="0.2798611111111111in"}

**The Central Kentucky Prototype: An object-oriented geologic map data
model for the National Geologic Map Database**

**By David R. Soller^1^, Boyan Brodaric^2^, Jordan T. Hastings^3^, Ron
Wahl^4^, and**

**Gerald A. Weisenfluh^5^**

**U.S. Geological Survey Open-file Report 02-202**

**2002**

######## This report is preliminary and has not been reviewed for conformity with U.S. Geological Survey editorial standards or with the North American Stratigraphic Code. Any use of trade, product, or firm names in this publication is for descriptive purposes only and does not imply endorsement by the U.S. Government.

######## 

**U.S. Department of the Interior**

**U.S. Geological Survey**

^1^U.S. Geological Survey, 926-A National Center, Reston, VA 20192

^2^Geological Survey of Canada, 615 Booth St., Ottawa, Ontario, CA K1A
0E9

^3^University of California\--Santa Barbara, Department of Geography,
3611 Ellison Hall, Santa Barbara, CA 93106

^4^U.S. Geological Survey, Box 25046, Denver Federal Center, Denver, CO
80225

^5^Kentucky Geological Survey, 228 Mining and Minerals Bldg., University
of Kentucky,

Lexington, KY 40506

######## 

######## 

######## 

######## 

######## 

**CONTENTS**

page

INTRODUCTION [1](#introduction)

ACKNOWLEDGEMENTS [1](#acknowledgements)

BACKGROUND [2](#background)

Prototyping The National Geologic Map Database
[2](#prototyping-the-national-geologic-map-database)

Evolving a Standard North American Data Model for Geologic Databases
[3](#evolving-a-standard-north-american-data-model-for-geologic-databases)

DATA MODELS OF THE NGMDB PROTOTYPE IN CENTRAL KENTUCKY
[6](#data-models-of-the-ngmdb-prototype-in-central-kentucky)

The Conceptual Model (Overview) [6](#the-conceptual-model-overview)

Object-Orientation: The Logical Model
[10](#object-orientation-the-logical-model)

Implementation: The Physical Model
[11](#implementation-the-physical-model)

Loading Data [13](#loading-data)

Visualization [13](#visualization)

Analysis [14](#analysis)

CONCLUSION [15](#conclusion)

REFERENCES [16](#references)

APPENDIX A. Diagrams of the Logical Model.
[18](#appendix-a.-diagrams-of-the-logical-model.)

APPENDIX B. Description of elements of the Logical Model.
[23](#appendix-b.-description-of-elements-of-the-logical-model.)

APPENDIX C. Example map unit description---central Kentucky prototype
model.
[35](#appendix-c.-example-map-unit-descriptioncentral-kentucky-prototype-model.)

# INTRODUCTION

In the U.S. and Canada, national geologic map databases are being
designed and, in prototype form, constructed. These database systems
simultaneously address two basic needs: improving the efficiency of
routine information handling within an agency, and promoting both
traditional and non-traditional uses of geologic information within and
outside the agency. In North America, for example, three major systems
or initiatives exemplify this approach: 1) the Canadian Geoscience
Knowledge Network (CGKN; \<<http://cgkn.net/>\>), a cooperative
initiative to link the public geoscience data providers in Canada, led
by the Geological Survey of Canada (GSC); 2) the U.S. National Geologic
Map Database project (NGMDB; \<<http://ncgmp.usgs.gov/ngmdbproject/>\>),
a Congressionally-mandated database and standards-development effort
based on collaboration between the Association of American State
Geologists (AASG) and the U.S. Geological Survey (USGS); and 3)
GeoInformatics, a proposed network of U.S. academic geoscience databases
(GEON; \<<http://www.geoinformaticsnetwork.org/>\>).

In 1999 and 2000, drawing on experiences from the Canadian and United
States initiatives above, the authors undertook to design and build a
prototype NGMDB database for central Kentucky, a state well advanced in
geological mapping. This report describes the object-oriented data model
upon which this prototype was founded, and briefly describes the
implementation in the GE-Smallworld database environment. We believe
that it is principally through such prototypes that the geoscience
community will evolve to a stable set of modeling concepts and
implementation approaches that effectively manage digital geologic map
information.

At present, however, data modeling of geologic map information is not a
mature discipline. Both the data model and the database design presented
here are experimental; they were built as prototypes, not formal
proposals, and so lack completeness and polish by comparison to some
other publicly-accessible database designs for the geosciences. On the
other hand, these activities have stimulated additional, advanced data
modeling beyond that described here, particularly as reported in
Hastings and Brodaric (2001) and Brodaric and Hastings (2002), portions
of which are excerpted here for ease of reference. In sum, this is a
progress report on geological data modeling in the NGMDB generally, as
well as a final report on the prototype for central Kentucky.

# ACKNOWLEDGEMENTS

Each of the five authors brought different expertise and interests to
this project, and it is appropriate to identify their contributions. The
senior author notes that first-authorship could readily have been
justified for each of his coauthors, and he expresses his thanks for
their participation in this research. Jerry Weisenfluh contributed to
the data model design, prepared the map data for input, and worked
closely with the private-sector partners to migrate the data into the
database. Ron Wahl contributed to the data model design and administered
the database system. Jordan Hastings and Boyan Brodaric led the data
model design, which is the core of this project; for further information
about this work, see their references cited below. David Soller
contributed to the data model design and managed the project.

The authors wish to acknowledge the significant interest and expertise
provided to this prototype by our private-sector partners, specifically
Robert Laudati and Dennis Beck (General Electric -Smallworld) and Roger
Fredericks and Martin Champion (Techni Graphics Systems). In particular,
Mr. Laudati provided the critical technical support that allowed us to
translate our data model concepts into a complex and powerful database
system. We also thank the Kentucky Geological Survey (KGS) and the U.S.
Geological Survey (USGS), specifically James Cobb (KGS) and Patrick
Leahy (USGS) for their enthusiastic support and vision for this project.

# BACKGROUND

######## **Prototyping The National Geologic Map Database**

The provisions of the Geologic Mapping Act of 1992 and its
reauthorizations in 1997 and 1999 (PL106-148) require the U.S.
Geological Survey (USGS) to design and build a National Geologic Map
Database (NGMDB), with the assistance of the state geological surveys
(via the AASG) and other entities participating in the National
Cooperative Geologic Mapping Program (\<<http://ncgmp.usgs.gov/>\>). In
consultation with the principal architects of the NGMDB legislation, a
general plan for the project's implementation and evolution was proposed
(Soller and Berg, 1995). A progress report is provided annually (e.g.,
Soller and Berg, 2001).

The NGMDB plan identifies three complementary phases to the project.
Because many organizations produce and distribute geologic maps, and
because the majority of these are not yet in digital form, it was
essential at the project's outset to identify and catalog all extant
geologic maps for the United States, in either paper or digital format.
This first phase, which at this writing we consider to be mature, has
produced a Web-accessible geologic map catalog
(\<<http://ngmsvr.wr.usgs.gov/ngmdb/ngm_catalog.ora.html>\>) which
enables users to search for maps for their area and/or theme of
interest. This map catalog presently is supported by two additional
databases developed under the NGMDB project: 1) GEOLEX, a searchable
geologic names lexicon; and 2) Geologic Mapping in Progress, which
provides information on current mapping projects. As new mapping
projects conclude, their map products are entered into the map catalog.

The second phase of the NGMDB project focuses on public access to
geologic maps in digital form, meaning both as raster graphics and as
vector GIS datasets. The latter goal, in particular, requires the
development of standards for encoding digital geologic map contents, as
well as guidelines for their documentation and use. This is an extremely
important activity that requires a high level of interaction with all
stakeholders to ensure that the evolving standards and guidelines are
useful, necessary, and will be widely adopted.

The ultimate goal of the NGMDB, in its third and final phase, is to
create an online database containing geological and geoscientific
information that can be Web-queried, downloaded for analysis, customized
for display and/or plotting, etc. as the user desires. Although derived
to a large extent from geologic maps, this database is intended to be
accessible as a coherent, seamless whole, incorporating both map and
non-map content. Further, the database is to be updated as new geologic
maps are published so that it becomes a dynamic, "living" database.
General concepts and a report of progress on NGMDB's "phase three" are
provided in Soller et al. (2001).

Possible architectures and implementations for phase three are being
evaluated through a series of prototypes. Each prototype is designed to
prove key technical concepts, forge relations and agreements among the
collaborators (principally, the nation's geological surveys), and also
begin amassing representative collections of geologic map information.
In early 1999, the basic requirements for a first prototype geologic map
database were articulated and tested using some newly-developed digital
data for the Greater Yellowstone Area (GYA) of Wyoming and Montana (Wahl
et al., 2000). The GYA prototype was presented for discussion at the
Geological Society of America (GSA) Annual Meeting, in October, 1999.
That prototype was well-received, and planning began for a second
prototype with a more complex set of tasks.

The second prototype evolved in late 1999 through 2000, via a series of
meetings among the USGS, the Kentucky Geological Survey (KGS), and
representatives of various state constituency groups, universities, and
vendors. The original intent of this follow-on prototype was to test
applicability of the GYA research results in a production geologic
mapping environment at the state level. Significantly, Kentucky has:

> • A large amount of detailed (1:24,000-scale) map data available,
> which has been standardized and edge-matched into 1:100,000-scale
> quadrangles,
>
> • An enthusiastic interest in designing a prototype and implementing a
> standard data model, and
>
> • A proven record of statewide economic benefits from the geologic
> mapping.

In fact, the NGMDB prototype for central Kentucky focused almost
exclusively on the development and implementation of an advanced data
model (as suggested by the GYA work) in GE-Smallworld (GESW) a
commercial object-relational GIS/database management system (DBMS). In
mid-2001, this prototype became available for public comment; results
are described in Soller et al. (2001).

######## **Evolving a Standard North American Data Model for Geologic Databases**

The Kentucky prototype benefits from half a decade of work on a suitable
database structure, or data model, for geologic map databases. This work
began in 1996 at a meeting in Saint Louis, Missouri, sponsored by the
NGMDB project and the AASG. That meeting was convened to organize
"working groups" to develop standards relevant to the NGMDB and to the
participating agencies. A broad cross-section of geologic interests was
represented, including the AASG, USGS, and GSC.

From the Saint Louis meeting, a Data Model Working Group (DMWG) was
formed (see
\<<http://ncgmp.usgs.gov/ngmdbproject/standards/datamodel/datamodelWG.html>\>
for annual reports and related information). In its first year, the DMWG
produced three iterations of a digital geologic map data model, all of
which were discarded with lessons learned (see Raines and others, 1997).
After two years, in June 1998, a fourth data model iterate, known simply
as "v4.2", was formally presented to its AASG, GSC, and USGS sponsors at
an invitational workshop in Denver, Colorado. After some further minor
modification, a "v4.3" draft (Johnson and others, 1998) was informally
released on the web for public comment (initially at the NGMDB site, now
available at \<<http://geology.usgs.gov/dm/>\>). This data model was
predicated on relational database implementation. With release of that
model, the DMWG had completed its task.

In early 1999, the North American Data Model Steering Committee (NADMSC)
was established to administer future data model developments and
implementations, with a Web forum established at
\<<http://geology.usgs.gov/dm/>\>. The NADMSC adopted v4.3 as the
provisional standard, referring to it informally as the North American
Data Model, or NADM. Collaterally, since its inception NADMSC has
monitored and coordinated among groups implementing NADM.

Many attempts to implement NADM in real systems (viz., commercial GIS
and/or DBMS) have required some change in the underlying model concepts.
Nonetheless, the state geological surveys and several projects in the
USGS have successfully adapted ideas from v4.3 to their internal needs,
and/or have proposed adding to v4.3 aspects of their internal systems
(for example, (Stanford and others, 1998; Davis, 2001; Richard and Orr,
2001). Through several Canadian projects, principally CordLink
\<<http://cordlink.gsc.nrcan.gc.ca/cordlink/>\> and HydroLink
\<<http://www.cgq-qgc.ca/hydrolink/>\>, the GSC has evolved a
substantially different system, commonly referred to as "v5.x".

Within the NGMDB project, too, the GYA prototype initially attempted to
implement NADM. However, GYA was implemented as yet another ad hoc, and
in this case object-oriented, variant. Coincidentally, an
object-oriented design had been sketched concurrently with v4.2 but
never implemented. For the NGMDB Kentucky prototype, following the
Yellowstone experience, it was determined to reassess this alternative
modeling approach.

In late summer 2000, two of the present authors (Brodaric and Hastings),
who had been active contributors throughout the above-mentioned modeling
and prototyping process, met to coalesce the existing v4.3 and v5.x data
models into a more evolved structure. This new data model
reconceptualizes previous efforts in two important ways:

> • It is a meta-(data) model, a progenitor for numerous particular data
> models, of which the existing assortment may be considered examples.
>
> • It is object-oriented, explicitly designed in, and intended for
> implementation via, that emerging software paradigm.

A meta-model is, by definition, a model of models; in the present
context, a master model for a (reasonably) wide variety of geologic map
models. The meta-model's generality is achieved by recognizing the
similarities (vs. the differences) of individual models, necessarily
with some loss of specificity. Object-orientation is particularly useful
for this sort of abstraction, as it focuses on building "class
hierarchies", in which similarities (vs. differences) can be summarized.
The central tenet of this work is that a sufficiently capable meta-model
can not only subsume past variations, but also presume future ones,
flexibly and robustly. Meta-modeling and object-orientation are the
means to the essential goal of enhanced intercommunication and
interoperability between data models.

Data models typically occur at three levels of representation in the
database construction process (Date, 1999): conceptual, logical, and
physical. At the *conceptual* level, essential concepts from the domain
under consideration are represented in a technology-neutral formalism.
The *logical* level then translates the conceptual model into a specific
technology, viz., entity-relational or object-oriented DBMS. Finally,
the *physical* model adapts the logical model to a particular hardware
and software environment, e.g., a particular version of DBMS. In
practice, database implementations also may manifest one or more
*external* models, which are user-specific subsets of the total logical
data model that simplify it for particular purposes: e.g., a
comprehensive geologic map database might be subset for applications in
engineering, paleontology, etc.

In their recent work with meta-modeling, Hastings and Brodaric (2001),
Brodaric and Hastings (2002), and Brodaric and Gahegan (2002) primarily
address the conceptual level, although logical considerations also are
evident since their design is explicitly object-oriented. Implementation
of aspects of these designs for the Kentucky prototype has also resulted
in a physical model.

# DATA MODELS OF THE NGMDB PROTOTYPE IN CENTRAL KENTUCKY

######## **The Conceptual Model (Overview)**

A scientific (versus cartographic) view of a geologic map strongly
considers the meaning (as well as the appearance) of a map, including
the spatial relations between its symbols, and the connections of the
symbols to information not shown on the map. Semiotics, the study of
signs (Noth, 1990), provides a useful framework for representing this
viewpoint. In cartographic semiotics the meaning of a map symbol derives
from the relationship held between the symbol, the concept being
symbolized (per some interpreting agent), and the object being referred
to (MacEachren, 1995). This semiotic triangle (i.e., symbol, concept,
occurrence), abstracted to geologic maps, is sketched in part of Figure
1; a fourth vertex (description), turning the triangle into a diamond,
is shown below these in the Figure. This "diamond diagram" represents
the essential structure of the meta-model.

> • *Symbol*: refers to the (carto)graphic entities in the visual
> display, ultimately building up to maps, charts, tables, etc. Almost
> universally, symbols permit only a partial representation of the
> underlying geologic information, encoded in relation to concepts and
> occurrences. Independent treatment of symbols clearly separates them
> from specific software packages, viz., GIS, and also enables purely
> cartographic behavior related to scale dependencies, symbol overlap,
> etc., separate from the geologic information they seek to represent.
>
> • *Concept*: refers to the abstract entities by which geologic
> information is summarized: e.g., "Dakota formation", "granite",
> "fault", "intrudes", etc. Specific geologic vocabulary is used to
> clarify and formalize concepts, which typically manifest in
> hierarchical category systems, e.g., taxonomies, applicable to
> occurrences (below) and relationships held between them.
>
> • *Occurrence*: refers to the tangible entities by which geologic
> information is identified and recognized, i.e., geologic (and general
> geospatial) features in the environment and their relationships in
> space, time, and otherwise. Each identifiable occurrence is an
> instance of exactly one concept; being tangible, it optionally
> possesses a spatial description, its geometry.
>
> • *Description*: refers to the characterizations (either numeric or
> textual, but not geometric) assigned to a symbol, concept or
> occurrence; these encode the preponderance of knowledge about a
> symbol, concept or occurrence, beyond its pure existence. Over time,
> descriptions per se also tend to become embedded in the recognition of
> concepts and occurrences.

Frequently in the natural sciences, concepts are really prototypical
descriptions, reflecting either 1) some average summary of occurrences
(with some occurrences more typical than others), or 2) an ideal state
(Solomon, 2000). An example of the summary case is a generic
characterization of mapped units in the legend; an example of the ideal
state occurs when an individual occurrence comes to define a concept,
viz., a type locality. Thus, descriptions of basic concepts and related
occurrences may be very similar, or very different, depending on their
similarity to the summary or ideal prototype. Accommodating this fact,
the meta-model possesses a common data store for descriptions, as
illustrated in Figure 2, which allows concept and occurrence
descriptions to share, or vary, either structure and content as
required. Further extensibility can be achieved by specializing
descriptions into subtypes, as needed, also illustrated in Figure 2.

> ![](media/image2.pct){width="3.4480314960629923in"
> height="1.4834645669291338in"}![](media/image3.pct){width="1.0070866141732284in"
> height="0.4952755905511811in"}
>
> **Figure 1.** The semiotic triangle (symbol, concept, occurrence),
> augmented to a diamond (with description), in simplified UML notation
> (Rumbaugh et al. 1999), abbreviated for reasons of clarity and space.
> Insets show example instances of spatial geometries (right), symbols
> (top) and concepts (left); indents and arrows denote concept
> specialization.

The development of a geologic map is a sophisticated process that
involves reasoning about categories of mapped information (concepts)
according to both existing scientific theories and new observations
(occurrences). Concepts and occurrences may be obtained in parallel and
are mutually affective: evidence from many occurrences guides evolution
of concepts, while established concepts are being continuously retested
on each new occurrence. Hypotheses and interpretations also play vital
roles in the process. Both the evidence for, and the summary of, this
thinking are recorded in descriptions, which attach equally to concepts
and occurrences, as shown in Figures 1 and 2.

As field geologists map an area, they progressively develop *conceptual*
models that describe the general *concepts* and *rules* that govern the
occurrence of geologic features. The conceptual model can encompass more
specific models, e.g., for petrography, stratigraphy, genesis, etc.
(Heyn and others, 2000). Also, the conceptual model is often tied to an
*occurrence* model, one that describes the distribution of geologic and
other *occurrences* jointly in space and time, as well as any
explanatory *inferences*. In practical terms, the conceptual model is
typically sketched in the map legend (and its associated text and
figures), whereas occurrences appear in the map itself. For a map to be
coherent, its conceptual and occurrence models must be inter-consistent.

![](media/image6.pct){width="3.7874015748031495in"
height="4.204330708661417in"}

**Figure 2.** Amplification of the essential meta-model structure
(diamond diagram). Insets show example instances of concepts (left) and
occurrences (right) with related spatial geometries (right) and thematic
descriptions (bottom). Dashed lines illustrate concepts evolving from
occurrences.

In information science, conceptual models are formally known as
*ontologies* (Guarino, 1998); these are commonly manifested as
vocabularies, taxonomies, or classification schemes, such as those for
geologic time ("Precambrian"), rock units ("Dakota formation"), rock
types ("granite"), minerals, etc. By extension, we consider occurrence
models as *epistemologies*, formalizing how we know and evaluate
geologic realities (Raper, 1999). The two models are fundamentally
linked: an ontology provides a set of concepts and logic for how
occurrences can be arranged; and the epistemology -- the set of geologic
features recognizable in the real world and on the map, as well as their
causal and process explanations and development histories --
demonstrates the validity of the concepts and related logic. Again, a
map that "works" clearly expresses this linkage.

To be useful, a meta-model must be implemented in a real system, i.e.,
in a geologic map database, as described in following sections. From the
database geologic maps can, of course, be regenerated. How does the
meta-model terminology apply to these geologic maps? A geologic map can
be considered to be a conceptual model (ontology and theory) expressed
as a legend (a symbolized conceptual model, devoid of occurrences that
in turn exemplifies an occurrence model (epistemology) for the region of
interest. The map shows objects from one or more geospatial models
(i.e., GIS layers), and/or utilizes descriptions from some aspatial
models (i.e., attribute databases). Applying an alternate legend to the
same set of occurrences effectively generates a re-conceptualized
(derivative) visualization for the area. This construction fulfills the
initial premise that maps are tightly interwoven arrangements of
symbolized concepts and symbolized occurrences, as sketched in Figure 3,
where a map is denoted by the MapView object.

The general knowledge structure described above emphasizes the
relationships among and between symbols, concepts, occurrences, and
descriptions. Specific knowledge representations can be achieved by
grouping these primitives into arrangements called models: *symbolic*
(i.e., cartographic) models for symbol sets, *geospatial* models for
geometric data sets, and *descriptive* models for descriptions
themselves. For example, a palette is a model of symbols denoting a
particular symbol library or agency-approved cartographic standard.
Similarly, a geospatial model is a summary of the organization and
relations (geometry and topology) that denote a dataset/layer in a GIS.
Finally, a geologic map together with its legend is a fixed combination
of these basic types.

![](media/image8.pct){width="6.492361111111111in"
height="6.654861111111111in"} **Figure 3.** The definition of a geologic
map in the meta-model, abbreviated for reasons of clarity and space. See
Appendices for details.

######## **Object-Orientation: The Logical Model**

The complete logical, object-oriented model for this prototype comprises
seven principal classes of objects, including concepts (17 subclasses),
descriptions (13 subclasses) and symbols (2 basic subclasses), as well
as their aggregate models and supporting metadata. Occurrences and their
aggregate occurrence models are, of course, dynamic according to map
content. Details are documented in the Appendices.

It should be noted that several aspects of the logical model remain in
need of refinement:

> • The description objects comprising standard attributes (i.e., "pick
> lists") are present only in preliminary form (in many cases directly
> from v.4.3) and require significant development.
>
> • The symbolic objects also require elaboration to achieve
> cartographic sophistication, as well as development to better serve
> multi-map databases.
>
> • The subclassing of concepts in the logical diagrams is not
> consistent with pure object-orientation.

######## **Implementation: The Physical Model**

This prototype was implemented in General Electric's "Smallworld" GIS
(GESW), operating on a Windows 2000 Server computer system. GESW is
object-relational software. Its physical data model is created in a CASE
tool, which ensures that all objects have the commonly required
characteristics of identity, encapsulation, inheritance (multiple) and
polymorphism, and substitutability. Communication among objects is by
inter-object messaging. However, instances of all objects are stored in
a relational database with the necessary methods, ancillary tables, and
other program segments hidden from view. The relational data structures
and required object manipulations are customized in a proprietary
language called "MAGIK", based loosely on SmallTalk (Lewis 1995).
Consultants from General Electric Net Services and Techni-Graphics
Systems, Inc. (Ft Collins, CO) wrote several hundred lines of MAGIK code
during the Kentucky prototype implementation process.

Two immediate benefits of the GESW implementation were:

• *Semantic fit*: The new object-oriented data model was realized nearly
verbatim in the GESW system (compare Figure 4 and Figure 2). Because the
model and the GIS share object-oriented semantics, none of the usual
conflicts between formal design and actual implementation of software
occurred. On the contrary, the GIS anticipated the application in
various ways.

• *Technical functionality*: The new model took full advantage of
technical capabilities in the GESW system, and stretched them a bit.
Both concepts and occurrences were outfitted with behaviors (processes)
that optimized their display at various scales. Some concepts and
descriptors were specialized into various sub-classes "tuned" to the
Kentucky data, for example, coal seams (Deposits) and structure contours
(Surfaces).

In addition, several features specific to the GESW software proved
beneficial:

• *Adaptive symbology*: Mappable objects were assigned different
cartographic symbols according to map scale, creating the appearance
that the map became more detailed as the user zoomed closer.

• *Dynamic topology*: Topologic relations were maintained automatically
during even the most complex analytic activities, including those that
resulted in the creation of new occurrences on the map.

• *External data interface*: Map-related data in external databases,
specifically drillholes (maintained by KGS) and formal geologic names
information (maintained by USGS) were easily integrated using HTTP
and/or ODBC protocols.

• *Internet access*: Both the GESW application and its underlying
database were accessible by a standard Web browser, using Citrix
Metaframe; this had the added benefit of protecting security in USGS
networks.

![](media/image9.png){width="6.428472222222222in"
height="6.168055555555555in"}

**Figure 4.** The core physical model in GESW. This was only a partial
implementation of the logical model shown in Appendix A. Some
descriptions were inserted into the model as placeholders for future
development (namely, GeoChronAge, and StrucMeasure). The implemented
concepts and descriptions are shown in the red boxes. The red line
connecting "BoundDesc" and "FaultDesc" demonstrates that a relation can
occur among descriptive elements (here, a fault also can be a boundary
between map units). The relations between data model entities (e.g.,
"Map", "Description") can be *one-to-many* (denoted textually as "1:n"
and graphically as a line with a round termination at the "many" box) or
*many-to-many* (denoted textually as "m:n" and graphically as a line
with a round terminations at both ends).

######## **Loading Data**

Data for this prototype were supplied by the KGS in ESRI "shapefile" and
MS Excel spreadsheet formats. Populating the data model with map
information involved disaggregating this "legacy" feature-based
structure -- thematically distinct layers of geospatial features each
with spatial, symbol, and descriptive attributes, as well as external
database links -- and reorganizing it into conceptual, occurrence,
symbol and descriptive models. At the same time descriptive information
scattered amongst disparate data sources, such as externally held
stratigraphic lexicons, were reunified and interrelated (see Table 1).
Concepts embedded in feature attribute values, theme labels, and
external sources were collected and organized into conceptual models for
rock units, rock types, and minerals; similarly, the symbol attributes
of features were collected and organized into a single cartographic
palette. The spatial attributes of features from all maps each became
distinct but topologically-related GESW native spatial objects; the
various descriptive attributes became free-standing descriptions; and
the external database references, which inherited GESW's external data
access methods, became active links. This transformation resulted in a
dataset that was on the one hand more normalized (i.e., concept, symbol,
and attribute descriptions were not replicated for features), and on the
other hand more integrated (much scattered data were unified and
directly embedded).

**Table 1.** Relations among rock units (geologic unit name and unit
relations), in the GESW database.

  ---------------------------- ------------ ------------------------------
  Stearns coal zone            Contains     Beaver Creek coal horizon

  Stearns coal zone            Contains     Stearns No. 2 coal horizon

  Breathitt Group              Contains     Princess Formation

  Breathitt Group              Contains     Grundy Formation

  Breathitt Group              Contains     Alvy Creek Formation

  Grundy Formation             Contains     Corbin Sandstone Member

  Alvy Creek Form.             Contains     Livingston Conglomerate

  ...                          ...          ...

                                            
  ---------------------------- ------------ ------------------------------

######## **Visualization**

The meta-model above provides sufficient structure for performing
map-based visualization from a geospatial database. We tested this
structure under three visualization scenarios: 1) direct display of a
stored map; 2) display based on reclassification of existing spatial
objects; and 3) dynamic symbolization of concepts and occurrences at
multiple scales.

• *Display*: A mapview  display method (a GESW procedure programmed in
MAGIK) was used to display a map's occurrence model from the database
(Figure 5, left). This method also activated various pieces of
information, so that, for example, clicking on a spatial object returned
only those concepts, descriptions, and symbols belonging to the mapview.

  ------------------------------------------------------ -----------------------------------------------------
  ![](media/image10.jpeg){width="2.1791666666666667in"   ![](media/image11.jpeg){width="2.158333333333333in"
  height="1.9659722222222222in"}                         height="1.9659722222222222in"}

  ------------------------------------------------------ -----------------------------------------------------

**Figure 5.** Display and generalization of maps using Kentucky
prototype test data. Rock unit occurrences (left) are dynamically
reclassified into their dominant rock types (right); also symbolized
(right), without using a standard pallette, are a mine and a fossil
locality.

• *Reclassification*: A mapview  reclass method was used to
re-conceptualize a map, i.e., to derive a new map view from the one
currently displayed. In this method, concepts and spatial objects from
the current map view were retained, whereas additional occurrences and
symbols were created or activated. Figure 5 shows rock unit occurrences
(left) and a derived map view displaying their dominant rock types
(right) dynamically derived from associated rock unit concept
descriptions.

• *Symbolization*: An occurrence  display method was used to
dynamically display an occurrence. This allowed for both default and
custom cartographic representations, permitting different
representations to be shown depending on display scale. For example, in
Figure 5, as a user zooms into an area, more specific information about
paleontologic features is shown (right).

######## **Analysis** 

The fundamental purpose of this prototype was to develop in GESW
software an implementation of an object-oriented data model. This
software provides a robust analytical capability and, to a limited
extent, we decided to explore it in preparation for the next prototype.
Therefore, for demonstration purposes, a simple network analysis was
performed. Dominant rock type occurrences were evaluated in terms of
their inherent susceptibility to contamination and their occurrence
downstream from pollutant discharges. To perform this analysis, a
powerful function of GESW was invoked -- the capability to both display
and query external databases held by the user.

For this analysis, external databases of potential pollution sources,
streams, and elevation were identified by the user and translated on the
fly by GESW for display with the geologic map information. Typical GIS
operations were performed on external databases to identify pollution
sources adjacent to streams, compute from the elevation data the
downstream direction, and then, in conjunction with the geologic map
database, identify geologic units that are susceptible to contamination
and are intersected by streams, downvalley from pollution sources. The
resulting map highlighted several potential contamination sources, and
more importantly, demonstrated the significant potential for integrating
geologic information with a wide variety of thematic information in
external or user databases. This capability significantly enhances the
potential for non-geologists to use geologic map information in their
analyses and decisionmaking. Further, the analysis demonstrates that the
meta-model can interact with common external data sources in typical GIS
environments where objects are associated primarily in terms of spatial
relations, with little regard for the knowledge and highly semantic
relations inherent in geoscience and maintained by the meta-model.

# CONCLUSION

Owing largely to geology's rich conceptual and symbolic traditions,
geologic map information is complex and poses many challenges for
digital representation. Nonetheless, development of widely applicable
and broadly accepted standards for digital geologic map information is
crucial to improving the overall usability of such information, both
within the geosciences and beyond.

This prototype demonstrates both an evolution of the NADM into a fully
object-oriented design and an implementation of that design that appears
fundamental to the long-term NGMDB effort. However, this prototype was
only an isolated test, a first proof-of-concept, for object orientation
as applied to digital geologic map information. Guidelines need to be
developed -- debated and decided within the geologic community --
regarding how best to represent a broad spectrum of geologic phenomena
within the model's core structure. Concurrently, the meta-model itself
needs to be enhanced with more sophisticated behaviors regarding
geologic classification, description, and inheritance; for example
constraints/defaults on lithostratigraphic relationships and
intra-rock-unit compositions are required.

Much time and effort was expended in transliterating the Kentucky maps
from a traditional geo-relational form (ESRI's ArcInfo coverages) into
an object-oriented form (GESW-internal object-relational database). A
flexible, data-driven and/or parameterized software utility for this
chore is clearly needed, given the disparate formats for map information
in the fifty state geological surveys, and also within the USGS.

The "scalability" of GESW's performance with increasing data volumes
also requires testing, since the amount of digital geologic map
information that must eventually be captured is enormous.

Finally, presuming that various GIS infrastructures and geologic
databases will be retained in the various geologic mapping agencies, the
potential use of the GESW system as a "mediator", to achieve
interoperability among them, needs to be explored. This mediation will
become particularly important as NGMDB progresses in its third phase,
providing a distributed on-line database of geologic map information.

# REFERENCES

Brodaric, Boyan, and Hastings, Jordan, 2002, An object model for
geologic map information, [in]{.underline}: D. Richardson and P. van
Oosterom (eds.), Advances in Spatial Data Handling: 10^th^ International
Symposium on Spatial Data Handling, Ottawa, Canada, July 8-12, 2002, p.
55-68.

Brodaric, Boyan, and Gahegan, Mark, 2002, Distinguishing instances and
evidence of geographical concepts for geospatial database design,
[in]{.underline} M. Egenhofer and D. Mark (eds.), Geographic Information
Science-2nd Int'l Conference: GIScience 2002, LNCS 2478, Springer,
Berlin.

Date, C.J., 1999, An introduction to database systems, Volume 1, 7^th^
ed.: Addison-Wesley, New York. 975 p.

Davis, A.M., 2001, Will a standard data model work for Washington, DC
area geologic geospatial data?, [in]{.underline} D.R. Soller, ed.,
Digital Mapping Techniques '01 \-- Workshop Proceedings: U.S. Geological
Survey Open-File Report 01-223, p. 225-229,
\<http://pubs.usgs.gov/of/2001/of01­223/davis.html\>.

Guarino, N., 1998, Formal Ontology in Information Systems,
[in]{.underline} Guarino N. (ed.), Formal Ontology in Information
Systems: Proceedings of FOIS\'98, Trento, Italy, June 6-8, 1998, IOS
Press, Amsterdam, p. 3-15.

Heyn, G., Kuebler, S., Richter, B., Skala, W., and Voisard, A., 2000,
The geohyp project: representing knowledge in geologic hypermaps:
GEO-Informationssysteme, v. 13, no.13, p. 24-28.

Hastings, Jordan, and Brodaric, Boyan, 2001, Evolution of an
object-oriented, NADM-based data model prototype for the USGS national
geologic map database project: Proceedings, International Association of
Mathematical Geology Annual Meeting, Cancun, Mexico, Sept. 9-12,
\<http://www.kgs.ukans.edu/Conferences/IAMG/Sessions/I/brodaric.html\>.

Johnson, B.R., Brodaric, Boyan, Raines, G.L., Hastings, J.T., and Wahl,
Ron, 1999, Digital Geological Map Data Model v4.3: informal report, 69
p., \<http://geology.usgs.gov/dm/model/Model43a.pdf\>.

Lewis, Simon, 1995, The Art and Science of Smalltalk: Prentice-Hall, 250
p.

MacEachren, A. M., 1995, How Maps Work: Representation, Visualization
and Design: Guilford Press, New York.

Noth, W., 1990, Handbook of Semiotics: Indiana University Press,
Bloomington.

Raines, G.L., Brodaric, Boyan, and Johnson, B.R., 1997, Progress Report
\-- Digital Geologic Map Data Model, [in]{.underline} D.R. Soller, ed.,
Proceedings of a Workshop on Digital Mapping Techniques \-- Methods for
Geologic Map Data Capture, Management, and Publication: U.S. Geological
Survey Open-File Report 97-269, p. 43-46,
\<http://pubs.usgs.gov/openfile/of97­269/raines.html\>.

Raper, J., 1999, Spatial representation: the scientist's perspective,
[in]{.underline} P.A. Longley, M.F. Goodchild, D.J. Maquire, and D.W.
Rhind (eds.), Geographical Information Systems: Principles and Technical
Issues, 2^nd^ ed.: Wiley, New York, p. 61-70.

Richard, S.M., and Orr, T.R., 2001, Data structure for the Arizona
Geological Survey Geologic Information System: Basic geologic map data,
[in]{.underline} D.R. Soller, ed., Digital Mapping Techniques '01 \--
Workshop Proceedings: U.S. Geological Survey Open-File Report 01-223, p.
167-188, \<http://pubs.usgs.gov/of/2001/of01­223/richard2.html\>.

Rumbaugh, J., Jacobson, I., Booch, G., 1999, The unified modeling
language reference manual: Addison-Wesley, Reading, MA.

Soller, D.R., and Berg, T.M., 2001, The National Geologic Map Database:
A Progress Report, [in]{.underline} D.R. Soller, ed., Digital Mapping
Techniques '01 \-- Workshop Proceedings: U.S. Geological Survey
Open-File Report 01-223, p. 51-57,
\<http://pubs.usgs.gov/of/2001/of01­223/soller1.html\>.

Soller, D.R., Wahl, Ron, Weisenfluh, Jerry, Brodaric, Boyan, Hastings,
Jordan, Laudati, Robert, and Fredericks, Roger, 2001, Progress report on
the National Geologic Map Database, Phase 3 --- an Online Database of
Map Information, [in]{.underline} D.R. Soller, ed., Digital Mapping
Techniques '01 \-- Workshop Proceedings: U.S. Geological Survey
Open-File Report 01-223, p. 71-78,
\<http://pubs.usgs.gov/of/2001/of01­223/soller2.html\>.

Soller, D.R., and Berg, T.M., 1995, Developing the National Geologic Map
Database: Geotimes, v. 40, no. 6, pp. 16-18.

Solomon, K. O., Medin, D. L., and Lynch, E., 1999, Concepts do more than
categorize: Trends in Cognitive Sciences, v.3, no. 3, p. 99-104.

Stanford, L.R., Othberg, K.L., Lewis, R.S., and Breckenridge, R.M.,
1999, A Digital Geologic Map Data Model Designed for GIS Users,
[in]{.underline} D.R. Soller, ed., Digital Mapping Techniques '99 \--
Workshop Proceedings: U.S. Geological Survey Open-File Report 99-386, p.
169, \<http://pubs.usgs.gov/openfile/of99­386/stanford.html\>.

Wahl, R.R., Soller, D.R., and Yeldell, Steven, 2000, Prototype
Implementation of the NADMSC Draft Standard Data Model, Greater
Yellowstone Area, [in]{.underline} D.R. Soller, ed., Digital Mapping
Techniques '00 \-- Workshop Proceedings: U.S. Geological Survey
Open-File Report 00-325, p. 57-63,
\<http://pubs.usgs.gov/openfile/of00­325/wahl.html\>.

# APPENDIX A. Diagrams of the Logical Model.

![](media/image12.pct){width="6.493055555555555in"
height="4.477777777777778in"}

Figure A. Core objects of the meta-model: concept, occurrence,
description, cartographic object and spatial object.

![](media/image13.pct){width="6.498611111111111in"
height="7.480555555555555in"}

Figure B. Additional details of the meta-model, including the definition
of a map.

![](media/image14.pct){width="6.497222222222222in"
height="5.666666666666667in"}

Figure C. Descriptions and concepts.

![](media/image15.pct){width="4.939583333333333in"
height="5.970138888888889in"}

Figure D. Cartographic models, including legend and palettes.

![](media/image16.pct){width="6.499305555555556in"
height="4.843055555555556in"}

Figure E. Metadata model and metacontent.

# APPENDIX B. Description of elements of the Logical Model.

# Hierarchical notation:

# Category

###### Class

> ClassText
>
> ClassDerive
>
> ClassFields

ClassFieldText

####### Subtype

SubtypeText

> SubtypeDerive
>
> SubtypeField
>
> SubtypeFieldText

# \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

# 

# Core Objects

### NGMDBobject

An abstract class that is the superclass for all non-metadata classes in
the NADM data model. Core Objects may be related to each other.

### CartographicObject

The cartographic object defines the symbology to be applied to
occurrences and concepts, and also defines a symbol\'s text description
for use in legends.

#### Derived from NGMDBobject

#### Private Attributes:

##### cart_name : String

The name applied to a cartographic object that typically appears in a
legend. In most cases, it is the same as the concept name.

##### cart_label : String

The character symbol for the object, which may appear on the map. For a
rock unit, this would be the unit label, such as TKgr.

##### cart_code : String

An alternative symbolization code for the cart object. In typical GIS
this code may be a symbolization attribute of a spatial object.

##### cart_desc : String

A text description of the cartographic object; that typically appears on
a legend. It may be an abbreviated version of a full text description of
a concept.

### Concept

The concept object is an abstract class that provides a category for
classifying occurrences. Concepts are subtyped into categories such as
rock unit, boundary, border, etc. Such subtypes may also for the content
for hierarchical pick lists which represent scientific classification
schemes: e.g., a list of structural measurement types such as
\"foliation\", \"lineation\", etc.

#### Derived from NGMDBobject

#### Private Attributes:

##### con_name : String

The name of the concept (e.g., Dakota Sandstone, Fault, Political
Border, etc.)

##### con_desc : String

The text description of the concept

### Description

Description is an abstract class that contains subtypes such as age,
lithology, thickness, and other types of descriptive characteristics for
concepts and occurrences.

#### Derived from NGMDBobject

#### Private Attributes:

##### desc : String

A text description

### Occurrence

Occurrence is a class that represents an instance of a concept. For
example \"Mine X\", a specific foliation measurement, etc. Occurrences
are most typically spatial, in that many of the features considered by
the data model possess a spatial description (i.e., are related to a
spatial object). Occurrences are differentiated from spatial objects for
three reasons: (1) spatial objects are typically provided by a GIS in a
class hierarchy; (2) the same spatial object may be interpreted
variously, so each occurrence represents one interpretation of a spatial
object (e.g., the same geographic area may be mapped differently by
individuals); and (3) occurrences need not have spatial properties
(e.g., an instance of a report), though in this implementation they tend
to do so.

#### Derived from NGMDBobject

### Relation

Relation attributes a binary relation in which the objects are of the
same type: only between concepts, occurrences, descriptions,
cartographic objects or relations themselves. Relation and role types
can be specified for a relation, as can be proportion, similarity, and
sequence attributes.

#### Derived from NGMDBobject

#### Private Attributes:

##### rel_type : RelType

> Specified as proportion, similarity, or sequence

##### rel_role1 : RoleType

##### rel_role2 : RoleType

##### rel_proportion : float

The degree that the part forms of the whole, expressed as a percentage

##### rel_interval : float

Describes the interval between objects in a sequence (e.g., the time or
distance between things)

##### rel_interval_unit : UnitType

The unit for the interval (e.g., days, meters, etc)

##### rel_direction : String

The direction of a sequence or interval (e.g., above, below, etc.)

##### rel_similarity : float

The degree of similarity between the related objects expressed as a
percentage

### SpatialObject

A spatial object contains a geometric description of some thing and is
normally the top class from some GIS class hierarchy of geometric
objects: e.g., GESW's. A spatial object can have one or more occurrences
in the model in order to link it to concepts and descriptions.

# Descriptions

### BoundDesc

A specific geologic boundary description

#### Derived from Description

#### FaultDesc

Descriptive information for faults

#### Derived from BoundDesc

#### Private Attributes:

##### flt_throw : String

> The throw information for a fault

### Fossil

A fossil occurrence possessing a fossil name and metadata describing it.
Fossil occurrences may be related to a specific site name (OccurName)
through the Relation object when the site has been assigned a unique
name/number/identifier.

#### Derived from Description

#### Private Attributes:

##### fossil_name : String

The name of the fossil

##### 

##### 

### GeoChronAge

The Geochron Age Object describes a numerical geochronological age date.
Geochron Ages are typically associated with geologic concepts and
occurrences, such as rock units and boundaries, respectively.

#### Derived from Description

#### Private Attributes:

##### chron_age : float

The geochronological age date

##### chron_method : string

Method used to acquire the geochronological age date

##### chron_err_plus : float

The positive error for the geochronological age date

##### chron_err_minus : float

The negative error for the geochronological age date

##### 

### Image

The image object records details about a specific image including
resolution and display size. It is assumed the actual image is not
stored in this object, but may be referenced via a URL in its metadata.

#### Derived from Description

#### Private Attributes:

##### image_res : String

The resolution of the image (e.g., 400x600)

##### image_size : String

The size of the image selected from (e.g., thumbnail, half-size or
full-size)

### LithDescription

Decribes a lithology by specifying a user-defined rock name and
selecting the best-matching standard rock classification from the
lith_class and lith_form concepts. Additional non-standard attributes
for mineralogy, texture, genesis, fabric, and composition also are
permitted.

#### Derived from Description

#### Private Attributes:

##### rock_name : string

A free-form text field containing a user assigned rock name

##### lith_class : LithClass

A standard rock name term selected from the LithClass class

##### lith_genesis : LithGenesis

A genetic term(s) selected from the LithGenesis class

##### lith_texture : LithTexture

A textural term(s) selected from the LithTexture class

##### lith_fabric : LithFabric

Fabric term(s) selected from the LithFabric class

##### lith_composition : LithComposition

Composition term(s) selected from the LithComposition class

##### lith_form : LithForm

Form or morphology term(s) selected from the LithForm class

##### lith_desc : string

A free-form text field for any remaining parts of the lith. description.

##### 

### MetaContent

Metacontent provides source or contextual information about an object in
the data model; for example, author, time, date, etc; or it acts as a
repository for various Models (collections of objects) such as
ConceptModel, OccurrenceModel, etc.

#### Derived from Description

#### Private Attributes:

##### meta_comment : string

A comment about the metadata, or about whatever the metadata is
describing

### OccurName

Contains the name of an occurrence (e.g., The Province of Ontario,
Center County, Lexington Fault, Last Chance Mine, Station Number 312,
etc.)

#### Derived from Description

#### Private Attributes:

##### occur_name : string

The name of the occurrence

##### 

### Rank

> Describes the level of an object within a hierarchical structure

#### Derived from Description

#### Private Attributes:

##### rank_type : RankType

The rank_type attribute receives a RankType object that defines a
hierarchical rank (i.e., lithostratigraphic or lithodemic level). It
could contain concepts such as formal or informal stratigraphic
subdivisions. It could also be used to describe a hierarchical system
for other rankings, e.g., for book components such as chapter, section,
subsection, paragraph, etc.

##### 

### StratigraphicAge

Describes a time-stratigraphic age range. When a single value vs a range
is required then the min. and max. ages are identical. Stratigraphic age
ranges are most commonly applied to rock units or geologic boundaries.

#### Derived from Description

#### Private Attributes:

##### min_strat_name : StratTimeScale

The minimum time-stratigraphic age: a Stratigraphic Time

Scale object

##### max_strat_name : StratTimeScale

The maximum time-stratigraphic age: a Stratigraphic Time

Scale object

### StrucMeasure

Describes a structural measurement by indicating the trend and plunge
for linear data and the strike/dip_direction and dip for planar data. A
type of structural measurement can also be specified, and the
measurement may be related to a specific site name.

#### Derived from Description

#### Private Attributes:

##### strucfeat_type : StrucFeatType

The type of structural measurement concept (StrucFeatType)

##### strike_dip : integer

The strike of a planar feature or the trend of a linear feature in the
range of 1 to 360 degrees, using the right-hand-rule

##### dip_plunge : integer

The dip of a planar feature or the plunge of a linear feature in the
range of 0 to 90 degrees.

##### dip_direction : integer

A measurement of the angle of the dip projected to the horizontal \--
used instead of the strike. The strike can calculated from this by
subtracting 90 degrees \-- this calculation should be performed and the
strike attribute filled when this method is used.

### SurfaceDesc

A specific surface (isopleth) description

#### Derived from Description

#### Private Attributes:

##### surface_parameter : Surface

> The name of a surface isopleth concept
>
> **surface_value: float**
>
> The numeric value for an isopleth occurrence
>
> **surface_units: string**
>
> The units of measure for the isopleth occurrence

### Text

The text object contains a body of text that may be related to other
descriptions, concepts or occurrences. It may also be linked to various
documents through the metadata.

#### Derived from Description

#### Private Attributes:

##### text_rank : Rank

The rank of the text (e.g., volume, chapter, section, subsection,
caption, abstract)

##### text_body : string

The body of the text. May be empty or possess the text body. If empty,
the object may instead use the metadata\'s URL capability to point to a
body of text.

### Thickness

Describes the average or most pertinent thickness of a geologic rock
unit, in meters

#### Derived from Description

#### Private Attributes:

##### min_thick : float

Min. thickness of the rock unit

##### max_thick : float

Max. thickness of the rock unit

##### typ_thick : float

Typical thickness of the rock unit

**thick_unit: UnitType**

Units for the thickness measurement

**Concepts**

### AccuracyType

A type of qualitative accuracy category (e.g., interpreted, approximate,
high, low, etc.)

#### Derived from Concept

### Border

Types of non-geologic boundaries (e.g., NEATLINE, LAKE, COUNTY, etc.)

#### Derived from Concept

### Boundary

Types of geologic boundaries (e.g., Fault, Contact, etc.)

#### Derived from Concept

#### Private Attributes:

##### bnd_modifier : String

Identifies subtypes of a particular kind of geologic boundary (e.g.,
\"dextral\" fault).

### LithClass

Each LithClass object is a type of lithology. LithClasses can be
organized hierarchically to represent a lithologic classification scheme
(i.e., an ontology).

#### Derived from Concept

#### Private Attributes:

##### lith_rank : Rank

A Rank object representing the hierarchical level of the lithologic
term.

### LithComposition

Contains compositional terms for lithologic descriptions.

#### Derived from Concept

### LithFabric

Contains fabric terms for lithologic descriptions.

#### Derived from Concept

### LithForm

Contains form or morphology terms for lithologic descriptions.

#### Derived from Concept

### LithGenesis

Contains genesis terms for lithologic descriptions.

#### Derived from Concept

### LithTexture

Contains textural terms for lithologic descriptions.

#### Derived from Concept

### RankType

The RankType object provides a name and numeric value for a specific
level of a hierarchical classification scheme (i.e., ontology or pick
list). Examples of ranks include levels in a time scale such as Epoch,
or types of formal rock units such as Group, Formation, Member, etc. Not
all ranks are named; some may just have numeric values such as levels in
a lithologic classification.

#### Derived from Concept, Description

#### Private Attributes:

##### rank_level : Integer

A number assigned to a specific level in a hierarchy (e.g., to a Epoch,
Period, Formation, Member, etc.)

### RelationType

A term used to describe the relationship between core objects (i.e.,
concepts, occurrences, descriptions, and relations).

#### Derived from Concept

### RockUnit

The Rock Unit class contains the names and definitions of specific rock
(map) units (e.g., Dakota Sandstone, Blue Gem coal bed, etc.)

#### Derived from Concept

### RoleType

A term used to describe the role an object plays in the relationship
(e.g., in a relationship between a Map object and a Person object, the
role of the person might be \"author\").

#### Derived from Concept

##### 

### StratTimeScale

The StratTimeScale object contains the name and numeric ages for a
defined geologic time interval. A hierarchical collection of some
StratTimeScale objects (i.e., an ontology/pick list) defines a
particular time scale.

#### Derived from Concept

#### Private Attributes:

##### strat_rank : Rank

A keyword representing the rank of the time-stratigraphic term (e.g.,
era, epoch, period). These keywords must be an existing Rank object
(i.e., an instance of the Rank concept class).

##### min_strat_age : Float

Minimum numerical age, in millions of years.

##### max_strat_age : Float

Maximum numerical age, in millions of years.

### StrucFeatType

The StrucFeatType object represents a type of structural feature (e.g.,
foliation, lineation, etc.). Note that actual structural measurements
are recorded in a StrucMeasure description object.

#### Derived from Concept

#### Private Attributes:

##### struc_rank : Rank

A rank value representing the hierarchical level of the structural
measurement term. For example, \"Planar\" may exist at the first level
of a structural hierarchy and \"foliation\" at a second level.

### Surface

The surface object contains the name of a type of isopleth (e.g.,
isopach, structure contour, etc.).

#### Derived from Concept

### UnitType

A unit of measurement (e.g., foot, meter, day, week, year, etc.). This
class could be subtyped to represent different categories of measurement
units.

#### Derived from Concept

**MetaContent**

### MetaData

Metadata provides source or contextual information about an object in
the data model (e.g., author, time, date, title, etc.).

#### Derived from MetaContent

#### Private Attributes:

##### meta_accuracy : AccuracyType

The thematic accuracy selected from the AccuracyType concept (e.g.,
approximate, inferred, high, low, etc.)

##### meta_precision : float

The resolution value

##### meta_precunit : UnitType

The units of measure of the resolution (e.g., meters)

##### meta_certainty : String

A measure of certainty, expressed as a percentage (100=certain,
0=completely uncertain)

##### meta_completeness : Integer

A measure of the degree of completeness of whatever the metadata is
describing expressed as a percentage (100=complete, 0=totally
incomplete)

##### meta_err_plus : floa

The positive error range

##### meta_err_minus : float

The negative error range

##### meta_err_avg : float

The average error amount

##### meta_err_unit : Unit

The units of measure for the error range and average (e.g., years)

##### meta_startdate : Date

A start date

##### meta_enddate : Date

A end date

##### meta_starttime : Time

A start time

##### meta_endtime : Time

An end time

##### meta_scale : float

The denominator of a quotient representing a measure of scale (e.g.,
50,000 for 1:50,000)

##### meta_projection : String

The name of a geographic projection

##### meta_xmin : float

The x coordinate of the lower left corner of a bounding rectangle in the
projection specified

##### meta_ymin : float

The y coordinate of the lower left corner of a bounding rectangle in the
projection specified

##### meta_xmax : float

The x coordinate of the upper right corner of a bounding rectangle in
the projection specified

##### meta_ymax : float

The y coordinate of the upper right corner of a bounding rectangle in
the projection specified

##### meta_url : String

One or more internet addresses (url)

##### meta_format : String

A file format specification (e.g., ESRI shapefile, Autodesk dxf, etc.)

##### meta_standard : String

A standard specification (e.g., ISOTC211, OGC, NADM, etc.)

##### meta_title : String

A title

##### meta_authors : String

A list of authors

##### meta_agency : String

The name of an agency

##### meta_pubedition : String

The publication edition

##### meta_pubseries : String

The publication series

##### meta_pubissue : String

The publication issue

##### meta_pubdate : Date

The publication issue

##### meta_pubcontact : String

The publication contact

### Model

Model is an abstract class containing the various types of models.
Models consist of collections of objects (concepts, occurrences,
descriptions, and symbols) and their relations.

#### Derived from MetaContent

**Models**

### CartographicModel

CartographicModel is an abstract class used to define a collection of
cartographic objects (symbols and colors) and their relations.

#### Derived from Model

### Legend

A legend is a collection of hierarchically ordered concepts, their
relations and cartographic objects.

#### Derived from CartographicModel

### Palette

Palette is an abstract class used to denote a collection of cartographic
symbol objects.

#### Derived from CartographicModel

##### 

### ColorPalette

> A color palette is a named collection of color styles (e.g., USGS
> standard color library).

#### Derived from Palette

### SymbolPalette

> A symbol palette is a named collection of feature symbols (e.g., USGS
> standard symbol library).

#### Derived from Palette

### ConceptModel

A ConceptModel (ontology) is a collection of concepts and their
relations; it may be viewed as a particular classification scheme (a
specific arrangement of concepts such as rock units or lithologies). For
example, a collection of concepts may possess semantic relations (Member
X is correlated with Member Y), parent relations (Member X is part of
Formation A) and sequential relations (Member X is younger than Member
Z, which is also in Formation A, and above Member Z).

#### Derived from Model

### DescModel

A DescModel is a collection of descriptions and their relations: i.e., a
database, or a table with ordered tuples (rows).

#### Derived from Model

### Gazetteer

A Gazetteer is a collection of occurrence (place) names and their
relations (e.g., \"State College\" is part of \"Center County\" is part
of \"PA\" is part of \"USA\").

#### Derived from DescModel

### ImageGallery

An ImageGallery is a collection of images and their relations.

#### Derived from DescModel

### Document

A Document is a collection of text fragments and their relations: e.g.,
a book is a collection of text arranged hierarchically (chapter,
section, paragraph) and sequentially (chapter 1, 2, 3; section 1.1, 1.2,
1.3; paragraph 1.1.1, 1.1.2, etc.)

#### Derived from DescModel

### SpatialDataset

A SpatialDataset is collection of spatial objects and their relations

#### Derived from DescModel

### Map

A Map is a collection of 1) one legend, 2) one or more spatial datasets,
3) one or more description datasets, and 4) other data components such
as images (location maps, cross-sections, facies relation diagrams) or
text (e.g., map surrounds). In a properly constructed map model, the
legend, spatial and descriptive data sets must all intersect---they must
share concepts, cartographic objects, spatial objects and descriptions.

#### Derived from Model

### OccurModel

An OccurModel is a collection of occurrences and their relations.

#### Derived from Model

**Cartographic Objects**

### Color

The color class is an abstract class containing defined standard color
schemes (e.g., Pantone, CMYK, RGB). Other color schemes could be
defined.

#### Derived from CartographicObject

### CMYK

A CMYK color value

#### Derived from Color

#### Private Attributes:

##### color_C : Integer

> The Cyan color value from CMYK

##### color_M : Integer

> The Magenta color value from CMYK

##### color_Y : Integer

> The Yellow color value from CMYK

##### color_K : Integer

> The K-black color value from CMYK

##### 

### Pantone

A Pantone color value.

#### Derived from Color

#### Private Attributes:

##### color_pantone : Integer

> A Pantone color value

### RGB

An RGB color value

#### Derived from Color

#### Private Attributes:

##### color_R : Integer

> The Red color value for an RGB color

##### color_G : Integer

> The Green color value for an RGB color

##### color_B : Integer

> The Blue color value for an RGB color

### Symbol

The symbol class defines a specific cartographic symbol. The symbol may
be a font, pattern or fill color, and may be used for symbolizing
points, lines, polygons, volumes, etc.

#### Derived from CartographicObject

#### Private Attributes:

##### sym_name : String

The name of the symbol

##### sym_code : Integer

The numeric id of the symbol

##### sym_desc : String

A text description of the symbol

##  

# APPENDIX C. Example map unit description---central Kentucky prototype model.

The example below was prepared as part of the documentation effort for
the overall NADM model design effort to highlight similarities and
differences among various implementations of conceptual and logical
models. The following tables show how a typical (or atypical) map unit
description would be treated in the central Kentucky object-oriented
data model. It is based on a legend description extracted from:

Drewes, Harald, 1998, Geologic map of the Bartlett Mountain quadrangle,
Pima and Santa Cruz Counties, Arizona: U.S. Geological Survey,
Miscellaneous Geologic Investigations Map I-2624, scale 1:24000.

***Dacitic Vent Breccia (Miocene)** ---Light-medium-gray, finely
porphyritic dacitic rock containing inclusions of Jurassic or
Proterozoic granite and Jurassic rhyolite (welded tuff?) as much as 20 m
in diameter. The subcircular outcrop mass of breccia probably is a
volcanic vent or throat. A halo of strongly saussuritized rock 0.3 --0.5
km wide (delineated on map) surrounds this vent. The dacitic matrix
consists of phenocrysts (25-35%, as much as 2 mm in length) set in a
cryptocrystalline granular groundmass. Phenocrysts included albitized(?)
plagioclase (12-18%), chloritized biotite (2-5%), uralized amphibole
(2-10%), magnetite (trace to 2%), and apatite (trace). Quartz is present
as a secondary mineral, filling vugs.*

\*Magenta highlights in above paragraph not yet treated in conceptual
model

\*Blue items (below) not yet implemented in logical model implementation

**Metadata**

  ----------------------------------------------- -----------------------
  Map.metadata.meta_agency                        USGS

  Map.metadata.meta_authors                       Drewes

  Map.metadata.meta_pubdate                       1998

  Map.metadata.meta_pubissue                      I-2624

  Map.metadata.meta_title                         Geologic map of the
                                                  Bartlett Mountain
                                                  Quadrangle, Pima &
                                                  Santa Cruz counties, AZ
  ----------------------------------------------- -----------------------

##### CartographicObjects 

  ----------------------------------------------- -----------------------
  CartographicObject.cart_label                   Mdv (example)

  CartographicObject.cart_name                    Dacitic Vent Breccia

  CartographicObject.cart_id                      100001 (example)
  ----------------------------------------------- -----------------------

Symbol

  ----------------------------------------------- -----------------------
  CartographicObject.cart_id                      100001

  CMYK.color_C                                    56

  CMYK.color_M                                    0

  CMYK.color_Y                                    47

  CMYK.color_K                                    34
  ----------------------------------------------- -----------------------

Concepts

  -------------------------------------------- ---------------------------
  RockUnit.con_name                            Dacitic Vent Breccia

  StratTimeScale.con_name                      Miocene

  StratTimeScale.con_name                      Proterozoic

  StratTimeScale.con_name                      Jurassic

  Lith_Class.con_name                          Aphanitic.Felsic.Dacite

  Lith_Class.con_name                          Phaneritic.Felsic.Granite

  Lith_Class.con_name                          Aphanitic.Felsic.Rhyolite

  Lith_Texture.con_name                        porphyritic

  Llith_Fabric.con_name                        brecciated

  Mineral.con_name                             plagioclase

  Mineral.con_name                             biotite

  Mineral.con_name                             amphibole

  Mineral.con_name                             magnetite

  Mineral.con_name                             apatite

  Mineral.con_name                             quartz

  Matrix.con_name                              groundmass

  etc.--- for remaining blue items             
  -------------------------------------------- ---------------------------

##### Descriptions (for Dacitic Vent Breccia)

StratigraphicAge

  -------------------------------------------- --------------------------
  StratigraphicAge.max_strat_name              Miocene

  StratigraphicAge.min_strat_name              Miocene
  -------------------------------------------- --------------------------

LithDescription (Dacite)

  ------------------------------------------- ---------------------------
  LithDescription.rock_name                   Dacite

  LithDescription.lith_class                  Aphanitic.Felsic.Dacite

  LithDescription.lith_texture                porphyritic

  LithDescription.lith_fabric                 brecciated

  LithDescription.lith_color                  light gray

  LithDescription.lith_color                  medium grey
  ------------------------------------------- ---------------------------

LithDescription (Granite)

  ------------------------------------------- ---------------------------
  LithDescription.rock_name                   Granite

  LithDescription.lith_class                  Phaneritic.Felsic.Granite

  LithDescription.max_size                    20

  LithDescription.size_unit                   meters

  LithDescription.lith_habit                  inclusion

  StratigraphicAge.max_strat_name             Proterozic

  StratigraphicAge.min_strat_nam              Jurassic

  StratigraphicAge.metaData.meta_certainty    low
  ------------------------------------------- ---------------------------

LithDescription (Rhyolite)

  ------------------------------------------- ---------------------------
  LithDescription.rock_name                   rhyolite

  LithDescription.lith_class                  Aphanitic.Felsic.Rhyolite

  LithDescription.lith_genesis                welded tuff

  LithDescription.max_size                    20

  LithDescription.size_unit                   meters

  LithDescription.lith_habit                  inclusion

  LithDescription.meta_certainty              low

  StratigraphicAge.max_strat_name             Jurassic

  StratigraphicAge.min_strat_name             Jurassic
  ------------------------------------------- ---------------------------

**LithComponent** (Plagioclase)

  -------------------------------------------- --------------------------
  LithComponent.component_name                 plagioclase

  LithComponent.min_percent                    12

  LithComponent.max_percent                    18

  LithComponent.max_size                       2

  LithComponent.size_unit                      mm

  LithComponent.alteration                     albitized

  LithComponent.meta_certainty                 low\*
  -------------------------------------------- --------------------------

\* Certainty applies to alteration, but model does not support metadata
on attribute values

**LithComponent** (Biotite)

  -------------------------------------------- --------------------------
  LithComponent.component \_name               biotite

  LithComponent.min_percent                    2

  LithComponent.max_percent                    5

  LithComponent.max_size                       2

  LithComponent.size_unit                      mm

  LithComponent.alteration                     chloritized
  -------------------------------------------- --------------------------

**LithComponent** (Amphibole)

  -------------------------------------------- --------------------------
  LithComponent.component \_name               amphibole

  LithComponent.min_percent                    2

  LithComponent.max_percent                    10

  LithComponent.max_size                       2

  LithComponent.size_unit                      mm

  LithComponent.alteration                     uralized
  -------------------------------------------- --------------------------

**LithComponent** (Magnetite)

  -------------------------------------------- --------------------------
  LithComponent.component \_name               magnetite

  LithComponent.min_percent                    trace

  LithComponent.max_percent                    2

  LithComponent.max_size                       2

  LithComponent.size_unit                      mm
  -------------------------------------------- --------------------------

**LithComponent** (Apatite)

  -------------------------------------------- --------------------------
  LithComponent.component \_name               apatite

  LithComponent.min_percent                    trace

  LithComponent.max_percent                    2

  LithComponent.max_size                       2

  LithComponent.size_unit                      mm
  -------------------------------------------- --------------------------

**LithComponent** (Quartz)

  -------------------------------------------- --------------------------
  LithComponent.component \_name               quartz

  LithComponent.component \_habit              vug filling
  -------------------------------------------- --------------------------

**LithComponent** (Groundmass)

  -------------------------------------------- --------------------------
  LithComponent.component \_name               groundmass

  LithComponent.max_size                       cryptocrystalline

  LithComponent.size_unit                      relative

  LithComponent.component \_texture            granular
  -------------------------------------------- --------------------------

> **Relations**

(LithComponent---LithDescription)

  ---------------------------- --------------- -------------- --------------- -------------------
  Relation(Child)              **rel_role1**   **rel_type**   **rel_role2**   Relation(Parent)

  LithComponent(Plagioclase)   mineral         IsPartof       lithology       LithDescription
                                                                              (Dacite)

  LithComponent(Biotite)       mineral         IsPartof       lithology       LithDescription
                                                                              (Dacite)

  LithComponent(Amphibole)     mineral         IsPartof       lithology       LithDescription
                                                                              (Dacite)

  LithComponent(Magnitite)     mineral         IsPartof       lithology       LithDescription
                                                                              (Dacite)

  LithComponent(Apatite)       mineral         IsPartof       lithology       LithDescription
                                                                              (Dacite)

  LithComponent(Quartz)        mineral         IsPartof       lithology       LithDescription
                                                                              (Dacite)

  LithComponent(Groundmass)    matrix          IsPartof       lithology       LithDescription
                                                                              (Dacite)
  ---------------------------- --------------- -------------- --------------- -------------------