Digital Mapping Techniques '99 -- Workshop Proceedings
U.S. Geological Survey Open-File Report 99-386
Geomatter: A Map-Oriented Software Tool for Attributing Geologic Map Information According to the Proposed U.S. National Digital Geologic Map Data Model
By Boyan Brodaric1, Eric Boisvert2, and Kathleen Lauziere2
1Geological Survey of Canada
615 Booth St.
Ottawa, ON K1A 0E9
Telephone: (613) 992-3562
Fax: (613) 995-9273
e-mail: brodaric@gsc.nrcan.gc.ca
2Geological Survey of Canada
2535 Laurier Boulevard
Ste. Foy, PQ G1V 4C7
INTRODUCTION
GeoMatter (Geologic Map Attributer) is a prototype data entry tool that enables the population of databases structured in the proposed U.S. national digital geologic map data model format (Johnson and others, 1998). It was developed by Geological Survey of Canada to facilitate geologic map data entry as well as explicate the data model. Users are expected to have in their possession a digitized version of their geology in ESRI's shape file format, and an empty (or not) MS-Access database conforming to the data model version 4.3, prior to using the software. GeoMatter provides a graphic environment where the geological map and its underlying database coexist on-screen during data entry. Database contents are linked to map objects and this provides the map not only greater information content but also defines its cartographic appearance. Once linked, the map and database remain synchronized, such that selecting an item in the database causes related map objects to be highlighted, and vice versa. GeoMatter thus both expedites data entry and facilitates information browsing. It is designed to host multiple map products within its map database. Its usage should result in digital geologic maps that are complete in terms of cartographic appearance, relatively deep in information content, and compliant with a common data standard. This will aid field mappers in creating digital map products, map compilers in integrating map products, and corporate entities in managing and distributing geologic knowledge in map form.
Software
GeoMatter is a stand-alone product that requires no other software to function. It comes with a standard Windows install and un-install script that manages the addition and removal of the program. The end-user is responsible for establishing a connection (via ODBC - Open Database Connectivity) to an appropriate database (e.g. MS-Access) and for making the map layers available by copying them into an appropriate location. A bare-bones user's manual is provided to aid its usage. It differs from other mapping packages, such as ArcView, in its ability to manage a complex geological database and in coordinating maps with it.
GeoMatter follows in the footsteps of other prototype data entry tools, most notably Curly (Raines and Hastings, 1998) and LegendMaker (Sawatzky and Raines, 1998). It differs from these approaches in three main ways: firstly, in the coexistence and tight integration of the map and database; secondly, in its user interface which insulates the user from the underlying database structure; and thirdly, in its inability to adapt to major design changes in the data model without additional programming.
Hardware
GeoMatter operates on standard Windows 95 or NT computers. In its current state, disk related operations are particularly slow, and require at least a powerful Pentium II microprocessor and large quantities of memory (e.g. at least 64Mb) for adequate performance. These and other shortcomings will be remedied in a forthcoming revision.
Distribution
GeoMatter is currently at a prototype stage due to technical development issues and, in part, due to the evolving nature of the data model. Its main functions are operational but with much embedded quirkiness. It has therefore not yet been applied within a serious map compilation project, and this will likely remain to be the case until the currently planned revisions are completed. Experimentation with the product is currently limited to partners within the data model effort who contact one of the authors for "as is" access to the software and manual.
Future Directions
GeoMatter is currently being revised and completed for production usage. Many current deficiencies are being corrected and some necessary functionality added, such as full compliance with v4.3 of the proposed U.S. national geologic map data model. It is anticipated that this work will be complete in fall/winter 1999.
The discussion below touches on some historical aspects of GIS software development that impacted the creation of GeoMatter, followed by a description of the user interface and its interaction with the proposed U.S. national digital geologic map data model.
DATA MODELS AND THE NEED FOR APPLICATION SOFTWARE
The establishment of a standard data model for digital geologic map information is a critical component of the national map database initiatives in the US (Soller and Berg, 1997), Canada (Broome and others, 1998), and elsewhere (Bain and Giles, 1997; Ryburn and O'Donnell, 1998). Designers of these data models are faced with a daunting task in that the complexity of geological information requires equally complex database architectures: it is inconceivable to imagine that the computer representation of a complex earth system would be significantly simpler without great loss of context, content and, ultimately, utility. Mature data model efforts in the geosciences (POSC, 1998; PPDM, 1998) reflect this reality, being composed of hundreds of interrelated parts, such as tables in relational databases or objects in object-oriented systems. Often these parts do not reflect actual geologic elements but are artifacts of the computing system being used. It is therefore understandable why end-users feel lost in the maze of one data model or another and are reluctant or unable to populate these complex structures that seem foreign and removed from their view of the world. In database technology this conflict between how reality is represented by the computer versus the user's perspective has been long addressed and solved: application software presents the database to the user in distinct views (Date, 1990) that coincide with the user's conceptions, and the underlying data structures remaining hidden. Intermediary software is thus expected to mediate between user and database. To aid this process the database community has evolved CASE (Computer Assisted Software Engineering) tools that greatly ease the construction of application software from initial database design. Indeed, these are so mature that the database and application software design processes seem as one task within such environments, as the tools generate both a database structure and accompanying application software.
In GIS however, we are only now beginning to see the emergence of sophisticated tools for application software development. Partial responsibility for this lies in GIS' relative immaturity; however, it is also probably due to the fact that GIS explicitly deals with the added complexity of spatial information which possesses no unifying theory (Edwards, 1996; Frank and Kuhn, 1995), leading to disparate, often conflicting, implementations (Gahegan, 1996). Although several ad hoc data exchange standards such as DXF (AutoDesk, 1999) and government led efforts such as SDTS (USGS, 1994) and SAIF (Canadian General Standards Board, 1995) have come into existence, they are not theories of spatial computation in the same sense that the relational data model defines relational data management or that object-orientation defines object computing. Emerging spatial standards (Open GIS, 1998; ISO/TC 211, 1998) improve this situation to a degree, but they are also immature and, arguably, incomplete, and have not yet engendered viable software application environments. On the other hand, the explosion in the usage of object-oriented programming, and its subsequent recent adaptation by the GIS community, has caused individual vendors to forge onwards and create spatial tool kits that are powerful albeit diverse. The challenge in developing effective spatial database software now rests in sifting these various vendor offerings for a suitable match to the problem at hand.
DESIGN OF GEOMATTER
The proposed U.S. national digital geologic map data model is at once both a conceptual and logical representation of a geologic map. It is conceptual in that the fundamental components of a geologic map (as understood by the designers) have been abstracted for computer representation independent of any database implementation. This is expressed primarily in the descriptive text of Johnson and others (1998). The remaining text and diagrams of the report are oriented to a relational database description of these concepts and in this way constitute a logical, technology-specific, expression of them. When the logical design is applied within a specific relational database system, such as Oracle or Access, the resultant configuration represents a physical model.
For the software designer these distinctions can be very useful, and can in fact become the basis for the design of application software. The conceptual elements that comprise a map (e.g. legend, text, map features, etc.), being user-oriented, provides a good basis for a user-interface, whereas the logical and physical aspects (i.e. the relational database design) provide a foundation for the underlying data repository. For instance, if software designers choose to adopt SQL (Standard Query Language) as the language for manipulating relational databases in their programming, then they have in effect enabled their software to operate with any database that is SQL compliant. This illustrates the logical-physical division, as the logical SQL part is syntactic and unchanged across hardware environments, whereas the databases that respond to SQL must differ internally to cope with different physical hardware platforms -- thankfully, in a way that is largely transparent to the user.
From this we can envision a software tool that presents a geological user interface (conceptually), communicates to its data store via SQL (logically), and permits connection to a variety of relational data repositories (physically). This is essentially the design of GeoMatter. In executing this design, the Delphi object-oriented programming environment was used to enable rapid development of the user interface and to facilitate its connection to the underlying relational databases via SQL and ODBC; ESRI's MapObjects component (ActiveX) was used for map display, symbolization and various spatial operations.
USER INTERFACE
Following the data model design, the user interface is organized around six main concepts: sources, legend, rock unit, structural unit, occurrence and map (spatial objects). GeoMatter permits relevant information to be added to these components and enables linkages between them to be established. It is designed to accomplish this in a way that is familiar to the geologist by mimicking the traditional map construction process. The map is drawn on one or more layers that host geological boundaries and associated geologic features. These are given meaning by relating geological information to them through a legend that also determines their cartographic appearance. Hence the map takes shape by defining a map Legend which contains symbolized Rock Units, Structural Units or Occurrences, which in turn are then connected to a map description in the Sources and to specific map features on the map face.
Figure 1. The GeoMatter interface ‹ an extensible database window for geologic information is situated on the left, and a window for displaying the map layers is found on the right. The database window is displaying the Source component, which lists the available maps and permits their selection and modification. Once a map is selected, the map layers acquire cartographic and geologic characteristics.
|
These activities take place in two main windows (Figure 1): an information window on the left, where the text information is managed, and a map window on the right where the map is displayed. A geologist can therefore maintain the map display and simultaneously browse, add and edit information about specific map features. Moreover, focus is maintained throughout, such that as a specific item is chosen from the map or from the database, all related map and database items are selected and highlighted, thus enabling the geologist to quickly view interrelationships among them. For example, if an item in the legend is selected by the user then its related map objects are highlighted on the map, and its associated map definition, rock units, structural units or occurrences are selected and displayed within the individual information components.
Sources
The Source component (formally known as Metadata in v4.2 -- Johnson and others, 1997) is a repository for document descriptions that are cited in other parts of the database. These could be maps and reports or any other document that needs to be referenced within the data model. Sources can be browsed, added and deleted here. Selecting a source that has a legend associated to it will cause the map to be symbolized according to the attached legend. This capability has interesting ramifications as it allows derivative map products to be created and stored, as several legends, and thus many map sources could be associated with any one set of geographic layers. For instance, the spatial objects in the map window could be represented as a bedrock geology map, a tectonic unit map, a dominant lithology map, etc., each having a unique legend in the Legend section and unique reference entry in the Source section. Viewing the objects in the map window according to any one theme simply requires the appropriate reference to be selected. Since the various sections are linked, browsing the data contents thereafter will result in the highlighting of information specific to the selected theme (e.g. tectonic units or lithologies instead of bedrock units). The ability to display different map layers in the map window, permits users to manage multiple map products from one database. Note that map layers are only displayable and not editable - GeoMatter is not a digitizing tool and does not currently allow map features to be modified, though this might change in the next version.
Legend
In many ways the Legend component is the heart of GeoMatter. It effectively acts as a visualization device, coordinating specific data content, symbolization, and spatial objects to form a "map". Thus, although in appearance it resembles a typical geologic legend, it in fact best illuminates a nontraditional implication of the data model: that a map is simply a specific view of a geologic database, defined by the collection of specific symbolic, thematic and spatial parts. It is thus possible to rearrange these components and arrive at a different map from the same pool of data. This amounts to classifying a set of spatial features according to different Legends. As a Legend can only be related to a single map Source, GeoMatter requires a new map Source to be defined before another Legend can be ascribed to the same map features.
Figure 2. Part of a Legend. Each legend item contains a symbol, map label, text description, and a link to a geologic category. Objects on the map can be assigned to a legend item, and will thereby inherit the cartographic and descriptive characteristics represented by the item.
|
A Legend is displayed as a list of individual items (Figure 2), each containing a symbolization and thematic description. The Legend provides efficiencies in editing and browsing map data. Individual map objects can be selected from the map and assigned to a legend item. In browse mode, selecting a map object will cause its legend item to be highlighted, or vice versa, the selection of a legend item will cause all associated map objects to be highlighted, making very clear the distribution of that item on the map.
Rock Units and Structural Units
The geological data model differentiates between categories of geologic information (COA -- Compound Object Archive) and specific instances of geologic occurrences (SOA -- Singular Object Archive). For example, a specific structural measurement occurrence has a unique identity and defining characteristics (e.g. position, strike, dip), but belongs to a general category (e.g. foliation); likewise "fault" is a generic category whereas the "Logan fault" is a specific instance of the general category. This is very analogous to the geological mapping process where the geologist abstracts a generalized category, call it "map unit", from a set of descriptions located at specific occurrences.
The Rock Unit and Structural Unit components represent the list of available categories within the system. Rock Units typically characterize polygons and Structural Units linear features, but this is user-driven as GeoMatter will allow any geometric shape to be attached to a rock unit, structural unit or occurrence. The category lists may be arranged hierarchically (Figure 3a) to follow geological relationships: e.g., a formation contains members and may be contained within a group. Mechanisms are provided to modify the hierarchy (Figure 3b) and to alter the level of detail displayed. Individual categories may be further described according to their rank (for rock units), geochronologic age, stratigraphic age, rock composition and their relationship to other units (e.g. overlying, contemporaneous, etc.). Specific hierarchic lists are incorporated at the appropriate places during data entry, to control the content of certain database items, such as rock type terminology. As with the Legend component, selecting a unit will highlight its occurrences on the map, and vice versa, selecting a map object will highlight its associated category in the units' list.
|
Figure 3a. (LEFT) The rock unit tab contains a hierarchy of rock unit categories and their lithologic composition and age descriptions.
Figure 3b. (BELOW) Modifying the rock unit hierarchy. Rock unit categories can be added, deleted or moved.
|
Occurrences
Fossils, structural measurements, mineral deposits, and individually named plutons are examples of occurrences that can be described by GeoMatter. In addition, specific map units (e.g., polygons) can be assigned proportional compositions of lithologies or other map units. Again, this follows the mapping process where a general category is a best fit description of the occurrences leading to its inception; unless these occurrences represent a type locality for the category they will likely differ somewhat from it. For example, a map unit may contain mostly shale, then silt and sandstone, but a specific occurrence (e.g., a polygon) may contain only a subset of these in varying proportions.
CONCLUSIONS
GeoMatter could be used by any geologist interested in boosting the information content of their existing digital geologic map. It is designed to enable the assignation of cartographic and geologic attributes to digitized points, lines or polygons, and to browse resulting map database contents. This should enhance the information content of digital geologic maps and thus aid the usefulness of individual map products and promote the construction of broader map databases whose contents are interchangeable. It should particularly benefit map compilers interested in facilitating the integration of diverse map products by standardizing on one database structure. The latter might include not only individuals but also organizations developing corporate map databases for internal usage or external distribution.
Underlying all such activity must be the belief that scientific understanding will be advanced through the synthesis of information that was previously difficult to integrate. Developing effective tools that will aid the population of interchangeable databases becomes imperative to this effort, and it is in this regard that GeoMatter hopes to make an impact. At the moment it is a prototype effort that will soon be upgraded to a system capable of being utilized in production mode.
REFERENCES
Autodesk Inc., 1999, DXF Reference, http://www.autodesk.com/techpubs/autocad/dxf/.
Bain, K.A., and Giles, J.R.A., 1997, A standard model for storage of geological map data: Computers and Geosciences, vol. 23, no. 6, p. 613-620.
Broome, J., Kilby, W., and Denoyers, D., 1998, Developing the Canadian Geoscience Knowledge Network: A Distributed Approach, in Buccianti, A., Nardi., G., and Potenza, R (eds.), Proceedings of the Fourth Annual Conference of the International Association for Mathematical Geology, Part 2: De Frede, Naples, p. 663.
Canadian General Standards Board, 1995, Canadian Geomatics Interchange Standard (CAN/CGSB-171.1-95) or Spatial Archive and Interchange Format (SAIF): Canadian General Standards Board, Formal Definition, Release 3.2, January 1995, 258 p.
Date, C.J., 1990, An Introduction to Database Systems, Volume 1, Fifth Edition: Addison-Wesley, New York, NY, 854 p.
Edwards, G., 1996, Geocognostics - A New Paradigm for Spatial Information: Proceedings AAAI Spring Symposium, March 25-27, 1996, Stanford University.
Frank, A.U. and Kuhn, W., 1995, Specifying Open GIS with Functional Languages, in Max J. Egenhofer, and John R. Herring (eds.), Advances in Spatial Databases (SSD'95): Springer-Verlag, Lecture Notes in Computer Science, Vol. 951, pp. 184-195.
Gahegan, M. N. 1996, Specifying the transformations within and between geographic data models: Transactions in GIS, Vol. 1, No. 2, pp.137-152.
Johnson, B.R., Brodaric, B., Raines, G.L., Hastings, J., and Wahl, R., 1998, Digital Geological Map Data Model v4.3. http://ncgmp.usgs.gov/ngmdbproject/.
Johnson, B.R., Brodaric, B., and Raines, G.L., 1997, Digital Geological Map Data Model v4.2, 83 p. http://ncgmp.usgs.gov/ngmdbproject/.
ISO/TC 211/WG2, Geographic Information: Geospatial Data Models and Operators, http://www.statkart.no/isotc211/wg2/wg2welc.htm.
Open GIS Consortium Technical Committee, 1998, The Open GIS Guide, Third Edition, Buehler, K., and McKee, L. (Eds.): Open GIS Consortium, Wayland, MA, http://www.opengis.org/techo/guide.htm.
POSC, 1998, Petrotechnical Open Software Corporation, http://www.posc.org/.
PPDM, 1998, Public Petroleum Data Model Association, http://www.ppdm.org/.
Soller, D., and Berg, T.M., 1997, Progress Toward Development of the National Geologic Map Database, in Soller, D.R. (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, pp. 37-40. http://ncgmp.usgs.gov/pubs/of97-269/.
Raines, G. L., and Hastings, J.T., 1998, Curly and Curly Survival Guide. http://geology.usgs.gov/dm/tools/Curly/.
Ryburn, R., and O'Donnell, I., 1998, Towards national geoscience data standards: Australian Geoscience Research Newletter 29, November 1998, http://www.agso.gov.au/information/publications/resnews/1998/.
Sawatzky, D.L. and Raines, G.L., LegendMaker and LegendMaker Guide, http://geology.usgs.gov/dm/tools/LegendMaker/.
USGS, 1994, Spatial Transfer Data Standard, http://rmmcweb.cr.usgs.gov/public/nmpstds/sdts.html.