KFD Development

8/14/2019 KFD Development

1/11

Introduction

In the past decade, GIS and Database ManagementSystem (DBMS) have been widely used to develop Karst

Feature Databases (KFDs) for spatial manipulation andresource management (Denizman 1997; Whitman andGubbels 1999). Several countries have built nationalKFDs to enhance data accessibility and resource man-agement (Cooper et al. 2001; Lei et al. 2001). In the US,many state agencies and karst scientists have signifi-cantly updated the geologic information and karst fea-ture inventories in the past two decades (Gao et al. 2002;Whitman and Gubbels 1999). Several karst scientists are

working with the US Geological Survey (USGS) tocreate a new karst map of the US (Veni 2002; White2001). The new karst map will be created based onregional geologic information and karst feature distri-

bution. The new karst map of the US will use GIStechnology to combine regional karst information andtherefore will be easily accessible to land-use plannersand managers, educators as well as karst scientists. Apreliminary version of such a map was published by theAmerican Geological Institute (Veni et al. 2001).

Although GIS-based KFDs have been established inmany karst regions, the absence of comprehensivedatabase models and standard metadata impeded the

Y. GaoE. C. Alexander JrR. G. Tipping

Karst database development in Minnesota:design and data assembly

Received: 28 October 2003Accepted: 12 January 2005Published online: 9 April 2005 Springer-Verlag 2005

Abstract The Karst FeatureDatabase (KFD) of Minnesota is arelational GIS-based DatabaseManagement System (DBMS).Previous karst feature datasets usedinconsistent attributes to describekarst features in different areas ofMinnesota. Existing metadata weremodified and standardized to repre-sent a comprehensive metadata forall the karst features in Minnesota.Microsoft Access 2000 and ArcView3.2 were used to develop this work-ing database. Existing county andsub-county karst feature datasetshave been assembled into the KFD,which is capable of visualizing andanalyzing the entire data set. ByNovember 17 2002, 11,682 karstfeatures were stored in the KFD ofMinnesota. Data tables are stored ina Microsoft Access 2000 DBMS and

linked to corresponding ArcViewapplications. The current KFD ofMinnesota has been moved from aWindows NT server to a Windows2000 Citrix server accessible toresearchers and planners throughnetworked interfaces.

Keywords Database ManagementSystem (DBMS) Karst FeatureDatabase (KFD) Relationaldatabase Entity Relationship Minnesota

Environ Geol (2005) 47: 10721082DOI 10.1007/s00254-005-1240-3 O R I G I N A L A R T I C L E

Y. Gao (&)Department of Physics, Astronomy, andGeology, East Tennessee State University,Johnson City, TN, 37604, USAE-mail: [email protected].: +1-423-4395878

E. C. Alexander Jr (&)Department of Geology & Geophysics,University of Minnesota, Minneapolis,MN 55455, USA

E-mail: [email protected]

R. G. Tipping (&)Minnesota Geological Survey,2642 University Ave., St. Paul,MN 55114, USAE-mail: [email protected]


2/11

data compatibility and management. The karst lands ofMinnesota present an ongoing challenge to environ-mental planners and researchers and have been the focusof a series of research projects and studies by researchersfor approximately 30 years (Giammona 1973; Wopat1974). Datasets in different counties and periods useddifferent metadata to describe the karst features in

Minnesota (Alexander and Maki 1988; Dalgleish andAlexander 1984; Witthuhn and Alexander 1995). Thissituation exists in many developed databases for otherkarst regions. One goal of this research was to design acomprehensive relational database for the karst featuresin Minnesota. The methodology used to design thisDBMS is applicable to the development of other GIS-based databases to analyze and manage geomorphic andhydrologic datasets at regional and local scales.

Microsoft Access 2000 and ArcView 3.2 were used todevelop the working database. Existing county and sub-county karst feature datasets have been assembled into alarge GIS-based database capable of analyzing the entire

data set. Data tables were stored in a Microsoft Access2000 DBMS and linked to corresponding ArcViewshape files. The current KFD of Minnesota was initiallyloaded onto a Windows NT server and then moved to aWindows 2000 Citrix server at Minnesota GeologicalSurvey (MGS). The server is accessible to researchersand planners through networked interfaces.

The development, implementation, and data analysesof the Minnesota KFD are described in detail in the firstauthors Ph.D. dissertation (Gao 2002). This paper is thefirst in a series of two papers describing the MinnesotaKFD (Gao et al. 2005).

Relational database design

The relational model of data was introduced by Codd(1970). This model is based on a simple and uniformstructurerelation. In the past 30 years, the relationalmodel has become one of the most important and widelyused database models. There are many well-establishedcommercial relational DBMS packages in the market.

Two of the most important concepts in a relationalmodel are entities and relationships (Fleming and vonHalle 1989). An entity is a real-world object or concept. Inthe KFD, different karst features such as sinkholes,springs, stream sinks, and water-tracing vectors are dif-ferent entities. The relational model represents a databaseas a collection of relations (Elmasri and Navathe 1994). Arelationship is an association among two or more entities.For example, the entity water-tracing vector has bothtracer input and tracer output. The input is often associ-ated with one or more sinkholes and stream sinks and theoutput is usually associated with one or more springs orwells. Each entity has specific properties, called attributes,which describe it. An entity type defines a set of entities

that have the same attributes. The attribute values thatdescribe each entity are a major part of the data stored inthe database. Each entity type in a relational model isequivalent to a relation. A relation or entity type corre-sponds to a table of values and each row in the tablerepresents a collection of related data values.

Other important terms in a relational database model

are domain, key, primary key, and foreign key. Inrelational model terminology, a table is called a relation,a row in a table is called a tuple, and a column header ina table is called an attribute. The data type describingthe types of values that can appear in each column iscalled a domain. A domain is a set of atomic values anda data type or format is specified for each domain.Atomic means that each value in the domain is indivis-ible (Elmasri and Navathe 1994). For example, theUniversal Transverse Mercator North (UTMN) coor-dinate of a karst feature is a 7-digit numerical value. Arelation consists of a set of tuples. In the relationalmodel, no two tuples can have the same combination of

values for all their attributes. In general, all attributevalues are not needed to identify a particular tuple. Forexample, a RELATEID can be used to identify a par-ticular karst feature in the karst index table. This mini-mal identifying attribute or set of attributes is defined asthe key. A relation or entity type may have more thanone key and each of the keys is called a candidate key.One of the candidate keys is usually designated as theprimary key which is used to identify tuples in a relation.In other words, the primary key is used to identify re-cords in a table. According to Fleming and von Halle(1989), a foreign key is an attribute or set of attributesthat completes a relationship by identifying the associ-

ated entity. In other words, a foreign key refers to aforeign entity. For instance, the attribute RELATEID ina spring data table refers to a specific spring in the karstindex table.

Relational model constraints include domain con-straints, key constraints, entity integrity, and referentialintegrity constraints (Elmasri and Navathe 1994). Do-main constraint means that the value of an attributemust be an atomic value from the domain of thatattribute. For example, the NAME of a karst featuremust be a string that is less than or equal to 40 characterlong. A user who enters a 41-character-long string hasviolated the domain constraint for the NAME attributeof the karst feature. A key constraint specifies that notwo tuples or records can have the same values for thekey attributes in a relation or table. RELATEID is theprimary key in the karst index table. If two karst fea-tures have the same RELATEID, it violates the keyconstraint. In the relational model, no primary key valuecan be null and this is defined as the entity integrityconstraint. The referential integrity constraint is speci-fied between two tables and is used to enforce the con-sistency between the records of the two related tables.

1073


3/11

According to Fleming and von Halle (1989), thereare three steps to design a relational database: logicaldata modeling (LDM), translation of the logical datamodel to a relational database, and tuning of therelational database. Fleming and von Halle (1989)recommended a comprehensive LDM including 12phases. It starts from identifying major entities and

ends with analyzing for stability and growth. Elmasriand Navathe (1994) divided a medium or large data-base application system into eight phases, starting fromsystem definition and ending with DBMS monitoringand maintenance.

Fleming and von Halles (1989) and Elmasri andNavathes (1994) methods of building a DBMS werecustomized to develop a simpler DBMS that is usableby both karst scientists and the general public. Fig-ure 1 shows the process to develop the KFD forMinnesota. This paper explains the first five phases ofthis process and a follow-up paper will discuss the lasttwo phases.

Data and system requirements

The process of identifying and analyzing the intendeduses of a database is called requirements collection andanalysis (Elmasri and Navathe 1994). This process isthe most important procedure before the design of thephysical data structure of a DBMS. Data and system

requirements should be the first process of a DBMS lifecycle. The karst feature DBMS used the following stepsto collect information for data and system requirements:

1. Identify major pplication areas and user groups thatwill use the database.

2. Investigate existing documentation concerning theapplication of the database.

3. Study the current operating environment and planneduse of the information.

4. Collect responses from potential database users.

The results of data and system requirement are basedon the information collected from existing documents

and potential users (Table 1). ArcView GIS andMicrosoft Access 2000 are the main software packagesselected to construct a GIS-based DBMS for the karstfeatures in Minnesota. Existing karst feature data andGIS data could be easily loaded or converted toMicrosoft Access 2000 data tables and ArcView shapefiles. Most of the regular users of karst DBMS haveaccess to these two software packages and many of theoperations and analyses proposed in the conceptualmodel of the karst feature DBMS can be conductedusing these two software packages. ArcView andMicrosoft Access are also widely used in the karstcommunities in the US and other countries. These con-

siderations make the Minnesota karst feature DBMSexpandable and applicable to other karst areas.

Entity identification

Table 2 lists all the karst features recorded in existingdocuments or reported by local residents or state agen-cies in Minnesota. Features like caves and mines werenot included in the KFD to protect the owners prop-erty, cave and mine features, and possible explorers tothe caves and mines. Information about caves and mineswas kept as private instead of public accessible data.

Publicly accessible caves are identified as miscellaneousfeatures. Karst windows were not included in the KFDdue to their rarity in Minnesota.

Dry valleys are usually included in bigger areasdrained by subsurface runoff. Many karst researchersdeveloped methods to delineate such areas to modelgroundwater flow in karst areas. Unlike most non-karstareas, topographic divides and hydrologic basins oftendo not coincide in karst terrains. Ray et al. (2000)Fig. 1 Relational database development process

1074


4/11

compared tracer-delineated groundwater basins with

Hydrologic Unit Code (HUC) watershed maps. Thiscomparison demonstrated that 1520% of the HUCtopographic basins in karst regions fail to coincide withhydrologic basins in Kentuckys karst watersheds.Alexander et al. (1995) defined springshed by usingwater-tracing tests and surface runoff in FillmoreCounty. A springshed contains surface area and sub-surface volume that contribute water to a spring (Alex-ander et al. 1995). Green et al. (2002) delineated areascalled karst units based on bedrock geology, depth tobedrock, geomorphology, topography, surface andsubsurface hydrology, and the distribution of karstfeatures in Mower County. The Minnesota KFD in-

cludes a feature called sub-drained area, which is an areadrained by subsurface runoff. Sub-drained areas can be

delineated based on topological water boundaries, bed-

rock geology, depth to bedrock, and the distributions ofkarst features such as sinkholes, springs, and streamsinks. The boundaries are further adjusted by water-tracing tests. Sub-drained areas are usually larger thanspringsheds defined by Alexander et al. (1995) andsmaller than karst units defined by Green et al. (2002).

Agricultural drainage tiles are artificial but performmany of the functions of karst features. Tile inlets orsurface tile inlets are pipes extending to the surface, in-stalled to remove water from closed depressions andwaterways on the land surface and move it via pipes(conduits) to points where water is returned to surfacewater flows. In Minnesota, tile inlets are often installed

in filled sinkholes, sinking streams, or solution-enlarged joints and several can function as injection wells. Tileoutlets are the ends of pipes (conduits) that return sub-surface water to surface waterways. They are equivalentin function to springs. Tile outlets can easily be mistakenfor springs. One of the reasons for having them in thedatabase is to keep future workers from mistaking themfor natural springs. Features such as tile inlets, tileoutlets, sub-drained areas, and water-tracing vectors areartificial but important components to model ground-water flow in the karst areas of Minnesota. These itemsare integral parts or descriptions of the regions karsthydrogeology and our user groups specifically requestedthat this information be accessible to all in the samedatabase. Therefore, these features were included in theMinnesota KFD.

There is no noticeable distinction between springsand seeps and they were not differentiated in mostcounties. In addition, stream sinks were used in most ofthe survey to represent losing streams. Therefore,springs and seeps were treated as one entity type andstream sinks and losing streams were treated as oneentity type in the KFD.

Table 1 The scope of the karstfeature database system, itsusers and applications

Users Department of Geology and Geophysics,University of Minnesota

Minnesota Geological Survey (MGS)Minnesota Department of Health (MDH)Minnesota Department of Natural Resources (MNDNR)Minnesota Pollution Control Agency (MPCA)Minnesota Department of Transportation (MNDOT)Other state agencies, resource managers, karst scientists,

and the general publicSystem

requirementsMicrosoft Access 2000ArcView GIS 3.2Convertible to more powerful DBMS and GIS software packages

such as ArcGIS and OracleRequirements

for DBMS applicationsEasy to use interfaces in both Microsoft Access 2000 and ArcView GISReliable concurrency control and securityNetwork and web accessible

Additional requirementsfrom users

Standardize existing metadata for the karst features in MinnesotaMaintain adaptability to new software and hardwareProvide scientifically defensible criteria for making land-use decisions

in the karst areas of Minnesota

Table 2 Possible entities for the karst feature database in Minne-sota

Naturally occurringkarst features

blind valleyCaveDry valleyKarst windowLosing streamOutcropSeepSinkholeCompound sinkholeSpring

Stream sink/stream sieveArtificial features Quarry

MineTile inletTile outlet

Other features Sub-drained areaWater-tracing vectorSpringshed/

groundwater basinKarst unit

1075


5/11

Table 3 lists both naturally occurring and artificialfeatures included in the KFD. Appendix A in Gao(2002) contains definitions of all features in the karst

feature DBMS. Features in Table 3 correspond toindividual data tables in the KFD. In addition to theabove karst features, a miscellaneous data table wasconstructed to store features not easily defined or notincluded in Table 3. An index table was created to in-clude all common attributes shared by all karst features.A remarks table was used to store additional commentsabout a karst feature. An address table was used to storelandowners contact information. All karst featuresshare some common attributes but many features lackinformation about address and remarks. Separate index,remarks, and address tables can greatly reduce the sizeof the database and improve the performance of the data

queries. Appendix B in Gao (2002) describes all theentities and data tables in the KFD of Minnesota.Entities in the KFD were divided into one supertype andmany subtypes (Fleming and von Halle 1989). Karstfeature index is the supertype, which includes commonattributes of all karst features. The rest of the entitytypes are subtypes.

Determination of relationships and referentialintegrities

When the entities of a DBMS are defined in a relationaldatabase, the next step is to construct relationshipsamong these entities. A relationship is usually repre-sented by action words. For example, a compoundsinkhole contains two or more sinkholes within a singleclosed depression (Contains is the name of this rela-tionship).

Two of the most important properties for a rela-tionship are direction and cardinality ratio. Direction ina relationship describes that one entity of the two entitiesin a relationship is the from entity and the other one is

the to entity. Direction is often represented by anarrow between two entities. In the above example,compound sinkhole is the from entity and sinkhole isthe to entity. The cardinality ratio in a relationshipdefines the expected number of related occurrences foreach of the two entities. There are three different kindsof relationships based on cardinality ratio: One-to-One

(1:1), One-to-Many (1:N), and Many-to-Many (M:N).The relationship between compound sinkholes andsinkholes are One-to-Many. For simplicity, a Many-to-Many relationship is usually decomposed into two One-to-Many relationships by adding a new entity to act asan intermediate entity between the two entities in theoriginal Many-to-Many relationships. The KFD ofMinnesota is constructed by a series of One-to-One andOne-to-Many relationships. Figure 2 shows directionsof all the One-to-One relationships in the karst featureDBMS. Figure 3 shows directions of all the One-to-Many relationships in the karst feature DBMS. Overallstructures of the relationships in this DBMS are illus-

trated in Fig. 4.Notice in Fig. 3 that any entity listed in Table 3 has aOne-to-Many relationship with the address or remarkstable. This means that any entity could potentially havemany addresses or comments. The relationships betweenthe karst feature index table and address or remarks

Table 3 Entities included in the karst feature database in Minne-sota

Naturally occurringkarst features

blind valleyOutcropSinkholeCompound sinkholeSpring/seepStream sink/ losing

streamArtificial features Quarry

Tile inletTile outlet

Other features Sub-drained areaWater-tracing vectorMiscellaneous

(any useful featuresother than the abovefeatures)

Fig. 2 One-to-One relationships in the Karst Feature Database ofMinnesota

1076


6/11

tables are propagated through specific karst featureentities as shown in Fig. 4. If One-to-Many relationshipsare constructed between karst feature index table andaddress or remarks tables, those two relationships wouldbe redundant. These redundant relationships should beremoved from the karst feature DBMS to ensure a clearand simple relational model.

Identification of attributes, domains, keys, and dataintegrity

The datasets used in this research have been built overthe past 20+ years by individual researchers and vari-ous agencies. Different attributes have been used to de-scribe karst features in various karst areas of Minnesota.For example, the sources of the information used toidentify and locate a karst feature were labeled inputsource, information source, and location source indifferent datasets. Side and Shape were used todescribe the shape of a sinkhole. Datasets in different

counties used different codes to represent the age of asinkhole. This made the metadata of karst featuresredundant and confusing. The most complete sinkholedatabase was constructed for Winona County by Dal-gleish and Alexander (1984), and updated by Magdalene(1995) using a spreadsheet format. That inventory con-tinued to be the model for subsequent work.

Magdalenes (1995) metadata of attributes and do-mains for sinkholes in Winona County were modified tobe compatible with sinkholes in other counties. Moreattributes and domains were added and standardized torepresent a comprehensive metadata for all the karstfeatures in Minnesota. Redundant and confusing attri-butes were clarified during this process.

Appendix C in Gao (2002) describes attributes anddomains for all the entities included in the KFD ofMinnesota. Code tables were used to simplify somecomplex and descriptive attributes. Codes are stored inseparate lookup tables and are accessed by StructuredQuery Language (SQL) requests. Appendix D in Gao(2002) defines all the code tables used in the karst feature

Fig. 3 One-to-Many relation-ships in the Karst FeatureDatabase of Minnesota

1077


7/11

DBMS. Using codes in this database significantlyreduces storage space and improves the performance of

applications built on the DBMS. These codes areconnected with meaningful descriptions through userinterfaces or karst feature reports to be easily under-standable to outside users.

The attributes initially added into the KFD are pri-mary and candidate keys. A candidate key is an attributeor a set of attributes that can uniquely identify theoccurrence of an entity (Fleming and von Halle 1989). Acandidate key that consists of more than one attribute iscalled a composite key. Table 4 shows all the primaryand foreign keys to the entities in the KFD of Minne-sota. Four tables use a composite key as the primarykey. Spring or tile outlet can be measured multiple timesand RelateID+Measurement date is used to uniquelyidentify each occurrence of such measurements. Re-marks and address of a karst feature are updated on aregular basis and a feature can have multiple addressesand remarks. When a new comment is added to a spe-cific karst feature, a new sequence number is assigned tothe new comment. Therefore, the combination of Re-lateID and sequence number uniquely identifies everyindividual record in the remarks table. Contact infor-mation about the landowner of a karst feature is very

important for karst feature inventories. Karst workersneed permission and help from the landowners to accesstheir properties. Some landowners may also be able toprovide valuable information such as the formation dateof a sinkhole, contamination of a spring, locations ofsome karst features, and their concerns of some prob-lems related to karst features in their properties. Whenownership changes, the information of the previousowner would be kept in the database and the contactinformation of the current owner will be added in theaddress. RelateID+ the last update date is the primary

Fig. 4 Database Structure of the Karst Feature Database ofMinnesota (Updated from Gao et al. 2002). (i.) is the maindatabase structure. The top level karst feature index table storesbasic and location information for each karst feature; The middlelevel tables, blind valleymisc., store specific information fordifferent features; The bottom level tables, address and remarks,store owners address and additional comments of each karst

Table 4 Primary and foreign keys of different entities in the karstfeature database in Minnesota

Entity Primary Key Foreign Key

Karst featureindex

RelateID

Blind valley RelateID RelateIDOutcrop RelateID RelateIDSinkhole RelateID RelateIDCompound

sinkholeRelateID RelateID

Spring/seep RelateID+Meas. Date RelateIDStream sink/

losing stream

RelateID RelateID

Quarry RelateID RelateIDSub-drained area RelateID RelateIDTile inlet RelateID RelateIDTile outlet RelateID+Meas. Date RelateIDWater-tracing

vectorRelateID RelateID

Remarks RelateID+seq. no. RelateIDAddress RelateID+Last Update RelateIDMiscellaneous

featureRelateID RelateID

1078


8/11

key to identify a unique individual record in the addressdata table.

As can be seen in Table 4, RelateID is used as aforeign key for all the entities in the KFD. It is also aprimary key or part of a primary key for those entities.Propagating primary keys as foreign keys makes it easyto understand and manipulate the relationships among

entities in the KFD.After the physical data structure such as relation-

ships, attributes, domains, and keys are defined in aDBMS, the next step is to specify a series of rules orconstraints to ensure the consistency of data valuesamong different relations. These data integrity rules in-clude domain integrity, entity integrity, and referentialintegrity. Appendix C in Gao (2002) defines the domainconstraints for the attributes of all data tables in thekarst feature DBMS. Entity integrity was enforced tomaintain the uniqueness of primary keys.

Referential integrity constraint is a set of rules spec-ified for a relationship to maintain consistency among

the records of the two entities involved in the relation-ship. In a database with many relations, there are usu-ally many referential integrity constraints (Elmasri andNavathe 1994). Rules for referential integrity in Micro-soft Access 2000 are defined as follows:

You cannot enter a value in the foreign key field of therelated table that does not exist in the primary key ofthe primary table. However, you can enter a Null valuein the foreign key, specifying that the records areunrelated. For example, you cannot have an addressthat is assigned to the owner of a sinkhole that does notexist, but you can have an address that is assigned to noone by entering a Null value in the RELATEID field.

You cannot delete a record from a primary table ifmatching records exist in a related table. For example,you cannot delete a karst feature index record fromthe kfix table if corresponding records in anyspecific karst feature table (e.g. sinkhole data table,kfsh) exist.

You cannot change a primary key value in the primarytable if that record has related records. For example,you cannot change the RELATEID of a karst featureindex record in the kfix table if correspondingrecords in any specific karst feature table (e.g. springdata table, kfsp) exist.

If referential integrity is enforced and users break oneof the rules with related tables, Microsoft Access dis-plays a message and does not allow the change. How-ever, the last two rules are too conservative to beimplemented in the KFD. As the karst feature data havebeen accumulated over more than 20 years, there aremany errors associated with previously assigned uniquenumbers. These unique numbers were represented asRELATEID in the database. Different features mighthave been assigned to the same RELATEID and

features with different RELATEIDs could be identical.Some features with previously assigned RELATEIDmay not exist. Referential integrity constraints aboutchanging and deleting primary keys were softened toclean up these errors.

In Microsoft Access 2000, the restrictions againstdeleting or changing related records can be overridden

to preserve referential integrity by setting the CascadeUpdate Related Fields and Cascade Delete RelatedRecords check boxes in a relationship. When the Cas-cade Update Related Fields check box is set, changing aprimary key value in the primary table automaticallyupdates the matching value in all related records. Whenthe Cascade Delete Related Records check box is set,deleting a record in the primary table deletes any relatedrecords in the related table. In the karst feature DBMSof Minnesota, all relationships were enforced with ref-erential integrity and supplemented by cascading updateand cascading delete options.

In the karst feature DBMS, a Karst Feature Index

Table is the primary table of the database, and has aseries of One-to-Many and One-to-One cascadingdownward relationships to the other data tables asshown in Fig. 4. Two additional sets of One-to-Manyrelationships exist between compound sinkholes andsinkholes and between the water-tracing vector and itsinput and output features.

To summarize, well-structured relationships amongentities, standardizing the metadata of attributes, usingcode tables for repetitive descriptive attributes, andpropagating RelateID as foreign keys make the KFD ofMinnesota a consistent, stable, and less redundantDBMS.

Data gathering and assembly

Existing county and sub-county karst feature datasetshave been assembled into the karst feature DBMS. Assome of the data were recorded more than twentyyears ago, the attributes of most data were modified tomatch the new metadata as described in Gaos (2002)Appendix C. The processing steps to develop the currentKFD of Minnesota can be divided into the followingseven phases:

1. The documentation concerning the application ofthe database, the operating environment, and theplanned use of KFD were investigated. Initial DBMSstructure and metadata guidelines were constructedin this stage to make the metadata compatible withmapped karst features. A conceptual data modelincluding interactive modules was developed at thisstage.

2. The KFD for Winona County was developed. In thisstage, the most recent up-to-date sinkhole dataset

1079


9/11

from Magdalene (1995) was modified and loaded intothe database for this county. Outcrops in Winona

County were digitized and transferred into the data-base. Sub-drained areas were delineated based onsurface topography, watershed boundaries, karstfeature distribution, and drainage patterns.

3. Entities, attributes, domains, keys, relationships, andreferential integrities for the KFD were revised. Arelatively complete metadata for all the karst featureswas created to include detailed entity types, attributes,domains, and keys for all the entities in the karstfeature DBMS. Relationships and referential integri-ties among entities in the karst feature DBMS wereestablished in Microsoft Access 2000 (Fig. 4).

4. Other archived karst feature datasets were loaded into

the KFD and applications were built for the KFD.Archived karst feature datasets were modified to becompatible with the metadata of the karst featureDBMS and then loaded into the database. Magda-lenes (1995) sinkhole datasets were modified to re-place the sinkhole data in Winona County in MGSsarchived karst feature dataset. Applications were

written in Visual Basic, ArcInfo AML, and ArcViewAvenue programing languages to interact with the

KFD.5. Database consistency and security were verified and

DBMS applications were tested. The karst featureDBMS was put on a Window NT server accessible toresearchers in MGS and the Department of Geologyand Geophysics at the University of Minnesotathrough networked interfaces. The applications of thekarst feature DBMS were tested and modified tomaintain its consistency and security.

6. User tests were conducted to verify attributes andlocations of karst features in the database by usingapplications built for the database. Users in MGSand the Department of Geology and Geophysics at

the University of Minnesota tested the applications ofthe karst feature DBMS and verified the locationsand attributes of karst features in Winona andOlmsted Counties. Applications were revised basedon issues and problems reported by the users.

7. Additional data were converted and loaded into thedatabase and their overall consistency and security

Table 5 Number of karst features sorted by county and feature types stored in the Karst Feature Database of Minnesota (Last update,November 17, 2002)

County Sinkholes Springs Stream sinks Tile inlets Tile outlets Misc. Total

Chicago 1 1Dakota 31 63 1 95Dodge 62 28 1 91Fillmore 6,253 866 138 2 7,259

Goodhue 347 154 9 510Hennepin 2 27 1 30Houston 63 71 134Mower 302 92 18 412Olmsted 915 530 6 1 35 1,487Pine 260 260Ramsey 14 14Wabasha 197 45 2 20 264Washington 22 129 151Winona 661 300 12 1 974Total 9,115 2,320 186 1 38 22 11,682

Fig. 5 Number of karst fea-tures sorted by feature types inMinnesota (Last update, Nov.17, 2002)

1080


10/11

were verified. The conceptual data model, applicationsand metadata of the karst feature DBMS were furtherrevised to be compatible with current and subsequentdatasets. Web-accessible karst feature inventorypoints are generated and posted to the MinnesotaDepartment of Natural Resources website.

Table 5 lists all the karst features sorted by countyand feature types stored in the KFD of Minnesota.There were 11,682 karst features stored in the KFD ofMinnesota on November 17, 2002. Figures 5 and 6 showthe number of karst features sorted by feature types andcounties, respectively. Sinkholes and springs account forapproximately 78% and 20% of all the karst featuresstored in the karst feature DBMS, respectively. Themain data sources of the database are from CountyAtlas projects (Alexander et al. 2003; Alexander andMaki 1988; Dalgleish and Alexander 1984; Tipping et al.2001; Witthuhn and Alexander 1995). The karst

mapping portions of County Atlas projects have focusedon mapping sinkholes and nearby springs and otherkarst features. The sinkhole dataset is relatively morecomplete than the other karst feature types but a sig-nificant fraction of sinkholes have not been mapped inMinnesota. As can be seen in Fig. 6, more than 60% of

all the karst features appear in Fillmore County. Fill-more, Olmsted, and Winona counties account for morethan 80% of the currently mapped karst features andless than 20% of the karst features were located in theother 11 counties.

Acknowledgements This research project was supported withfunding and technical assistance from the Minnesota Departmentof Health (MDH) and conducted through the Minnesota Geolog-ical Survey (MGS). The karst feature locating and verification ef-forts of Scott Alexander, David Berner, Jeff Green, Lisa Holland,Sue Magdalene, Bev Shade, and many others are gratefullyacknowledged.

Fig. 6 Number of karstfeatures sorted by counties inMinnesota (Last update, Nov.17, 2002)

References

Alexander EC Jr, Maki GL (1988) Sink-holes and Sinkhole Probability. Geo-logic Atlas Olmsted County,Minnesota, County Atlas Series C-3,Plate 7 (1:100,000). Minnesota Geolog-ical Survey, University of Minnesota

Alexander EC Jr, Green JA, Alexander SC,Spong RC (1995) Springsheds. GeologicAtlas Fillmore County, Minnesota,County Atlas Series C-8, Part B, Plate 9(1:100,000). Minnesota Department ofNatural Resources, Division of Waters

Alexander EC Jr, Berner D, Gao Y, GreenJA (2003) Sinkholes and SinkholeProbability, and Springs and Seeps.Geologic Atlas of Goodhue County,Minnesota, County Atlas Series C-12,Part B, Plate 10 (1:100,000). MinnesotaDepartment of Natural Resources,Division of Waters

Codd EF (1970) A relational model of datafor large shared data banks. CACM13(6):377387

Cooper AH, Farrant AR, Adlam KAM,Walsby JC (2001) The development of anational geographic information system(GIS) for British karst geohazards andrisk assessment. In: Beck BF, HerringJG (eds) Geotechnical and environ-mental applications of karst geologyand hydrology, proceedings of the 8thmultidisciplinary conference on sink-holes and the engineering and environ-mental impacts of karsts. Louisville,KY, A.A. Balkema, Lisse, 14 April2001, pp 145151

Dalgleish JD, Alexander EC Jr (1984)Sinkholes and sinkhole probability.Geologic Atlas Winona County, Min-nesota, County Atlas Series C-2, Plate 5(1:100,000). Minnesota Geological Sur-vey, University of Minnesota

Denizman C (1997) Geographic informa-tion systems as a tool in karst geomor-phology. In: Abstracts with Programs-Geological Society of America29(6):290

Elmasri R, Navathe SB (1994) Fundamen-tals of database systems. Addison-Wesley, Reading, pp873

Fleming CC, von Halle B (1989) Handbookof relational database design. Addison-Wesley, Reading, pp605

Gao Y (2002) Karst feature distribution insoutheastern Minnesota: extendingGIS-based database for spatial analysisand resource management. PhD Thesis,University of Minnesota

Gao Y, Alexander EC Jr, Tipping RG(2002) The development of a karst fea-ture database for southeastern minne-sota. J Cave Karst Stud 64(1):5157

1081


11/11

Gao Y, Alexander EC Jr, Barnes RJ (2005)Karst database implementation inMinnesota: analysis of sinkhole distri-bution. Environ Geol (in press)

Giammona CP (1973) Fluorescent dyedetermination of groundwater move-ment and contamination in permeablerock strata. Int J Speleol 5(34):201208

Green JA, Marken WJ, Alexander ECJ,

Alexander SC (2002) Karst unit map-ping using geographic information sys-tem technology, Mower County,Minnesota, USA. Environ Geol42(5):457461

Lei M, Jiang X, Li Y (2001) New advancesof karst collapse research in China. In:Beck BF, Herring JG (eds) Geotechni-cal and environmental applications ofkarst geology and hydrology, proceed-ings of the 8th multidisciplinary con-ference on sinkholes and theengineering and environmental impactsof karsts. Louisville, KY, 14 April,A.A. Balkema, Lisse, pp 145151

Magdalene SCC (1995) Sinkhole distribu-tion in Winona County, Minnesota,revisited. MS Thesis, University ofMinnesota

Ray JA, Goodmann PT, Meiman J (2000)Inaccurate sub-division of hydrologicunits in kentuckys karst watersheds[abs.]: 45th annual midwest groundwater conference. Columbus, OH,

October 1719, pp 3536Tipping RG, Green JA, Alexander EC Jr,

(2001) Karst features. Geologic Atlas ofWabasha County, Minnesota, CountyAtlas Series C-14, Part A, Plate 5(1:100,000): Minnesota Geological Sur-vey, University of Minnesota

Veni G (2002) Revising the karst map of theUnited States. J Cave Karst Stud64(1):4550

Veni G, DuChene H, Crawford NC,Groves CG, Huppert GN, KastningEH, Olson R, Wheeler BJ (2001) Livingwith karst: a fragile foundation. Amer-ican Geological Institute, Alexandria,pp65

White WB (2001) The karstmap project:progress and status [abs.]: nationalspeleological society convention pro-gram guide. Great Saltpetre Cave Pre-serve, Kentucky, pp86

Whitman D, Gubbels T (1999) Applica-tions of GIS Technology to the trig-gering phenomena of sinkholes incentral Florida. In: Beck BF, Pettit AJ,Herring GJ (eds) Hydrogeology andengineering geology of sinkholes andkarst, proceedings of the 7th multidis-ciplinary conference on sinkholes andthe engineering and environmental im-

pacts of karst. Harrisburg-Hershey,Penn., 1014 April, A.A. Balkema,Rotterdam, pp 6773

Witthuhn MK, Alexander EC Jr (1995)Sinkholes and Sinkhole Probability.Geologic Atlas Fillmore County, Min-nesota, County Atlas Series C-8, Part B,Plate 8 (1:100,000): Minnesota Depart-ment of Natural Resources, Division ofWaters

Wopat MA (1974) The karst of southeast-ern Minnesota; and methods for statis-tical analysis of polymodal two-dimensional orientation data. MS The-sis, University of Wisconsin-Madison

1082

KFD Development

Documents

Transcript of KFD Development