Electronic Seismologist logo


March/April 2004

Thomas J. Owens
E-mail: owens@sc.edu
Department of Geological Sciences
University of South Carolina
Columbia, SC 29208
Phone: +1-803-777-4530
Fax: +1-803-777-0906

Practical Problem-solving in Seismology

This column concludes the second year of the Second ES's tenure as seismology's gatekeeper for all that is going on in "information technology." The Original ES set a high standard in this role, so a little analysis of his successor seems appropriate. What was the most common topic for the ES in the last two years? Nothing! Yup, there was no ES column for five of the last twelve SRL issues. Oops. Definitely need to work on that. OK, when the ES did manage to show up for work, what were the topics? Well, four of the discussions were on the future of IT in seismology, and only three (counting this one) were on practical topics. In other words, only 25% of the available ES columns dealt with something that actually works now! That seems a little light on the practical stuff. One thing the ES has learned over the last couple of years is that writing about the future is fun. The ES likes doing it, other people like doing it, and a lot out there on the horizon is exciting to think about. Plus, readers compliment the ES on these articles! Getting people to write about stuff that actually works has been harder than expected. The thing about practical topics is that readers complain a lot more when those are published. The Original ES never let on that there could be disgruntled readers! Groupies, yes, thousands of groupies. But it never occurred to this ES that the job involved hate mail! OK, "hate mail" may be a bit melodramatic. Mostly, caring readers clearly and firmly inform the ES that their favorite, similar, application or approach was not represented in the column. If one seismologist writes an ES column, then a half-dozen complain to the ES that better things are out there and why was the ES so biased (or grossly uninformed) that good stuff was left out. Assuming roughly 10% of the population who think something is missing are irritated enough at the ES to write, that means there are several dozen seismologists working on most problems! That's a lot of potential ES contributors who are suffering in silence. Given that there is room to double the number of ES columns published over the last two years, the ES encourages his loyal reader base to lift their pens and tell the ES (in fact, The World) what you are doing. Just remember, the ES doesn't know everything that is going on or everybody who is doing something interesting! Ouch.

Enough whining ... it's time to present ES readers with an interesting article about a practical problem. Integration of GIS concepts and tools into solving seismological problems (rather than just displaying data) is a hot topic and one that a number of groups are working on. Uh-oh ... a practical problem that lots of people are working on ... the ES will now duck! Actually, this is good stuff and the ES thanks the authors for making the effort to write up their project to share with the community. The ES looks forward to more contributions on solutions to practical problems. Seriously.

SAFE-Tools: A Web-based Application for Identification of Active Faults

B. Moreno1,2, K. Atakan1, K. A. Furulokken1, S. Temel3, and O. J. Berland1

1. Department of Earth Science, University of Bergen. Allegt. 41, 5007 Bergen, Norway; atakan@geo.uib.no
2. Centro Nacional de Investigaciones Sismológicas, Calle 17 No. 61 e/ 4 y 6 Vista Alegre, Santiago de Cuba, Cuba
3. Bea Systems, Inc., 140 Allen Road, Liberty Corner, NJ 07938


Recognition of active faults, particularly in low-seismicity regions such as Western Europe, has been a challenging task for Earth scientists for many years. These regions are generally characterized by low hazard but high risk due to the concentration of population and structures with high vulnerability. Detection of tectonic deformation that may lead to destructive earthquakes in such areas requires innovative research strategies appropriate to the climate, slow deformation rates, and heavy human modification.

The variety and amount of information involved in the characterization of slowly deforming faults, which we call slow active faults, are in general distributed between different research institutions and can be difficult to access. This information, which includes earthquake data, paleoseismic trenches, geophysical cross-sections, etc., should be gathered, parameterized, and stored in a way that makes it more accessible for use in seismic hazard studies. Within the framework of the European project SAFE (Slow Active Faults in Europe), software (SAFE-T) for identifying slow active faults is being developed. The system is a Web-based application with data visualization and user interaction through the Internet.

The information relevant to fault identification by nature consists of geospatial data with several parameters or properties attached. Geographical information systems (GIS) are commonly used for the management and visualization of spatially referenced data. Commercially available GIS software is usually expensive, operating mainly as stand-alone (client-side) applications. An effort to integrate GIS into client-server architecture is being carried out by the Open GIS Consortium (http://www.opengis.org/index.htm). This consortium is an association of companies, government agencies, and universities that are developing open-interface, standard protocols and specifications to make geospatial data accessible to the public. For example, Web Map Service is one of the well established achievements of the Open GIS Consortium. CubeServ, Cadcorp SIS, and DEMIS (URL references in Table 1) are examples of server interfaces based on this technology.


URL References of Web Map Servers and Interactive Map Tools

CubeServhttp://www.cubewerx.com/World Web map server
Cadcorp SIShttp://www.cadcorp.com/World Web map server
DEMIShttp://www.demis.nl/DEMIS_UK/World Web map server
FAUSThttp://www.ingv.it/~roma/banche/catalogo_europeo/Database of potential sources for earthquakes larger than M 5.5 in Europe
Faults of Southern Californiahttp://www.scecdc.scec.org/faultmap.htmlFaults of Southern California
Geodehttp://dss1.er.usgs.gov/Geo-data Explorer (USGS)
IMAhttp://atlas.geo.cornell.edu/ima.htmlInteractive mapping and data analysis
J.V. Voyagerhttp://jules.unavco.ucar.edu/VoyagerJr/EarthJules Verne Voyager, Jr. Interactive map tool
NASA Web Map Viewerhttp://viewer.digitalearth.gov/Interactive map tool

Several Internet-based applications have been developed using Web Map Service interfaces, for example, NASA Web Map Viewer, Geode, and IMA (Table 1). Maps are dynamically generated on the server side and transmitted as images to the client. Other Web-based tools (e.g., Faults of Southern California, J. V. Voyager, FAUST) use static map images that have been created in advance and stored on the server side. In SAFE-T we use the facilities of the Web Map Service interface to generate maps dynamically with background information and then plot our geospatial data on them. The data consist of geological and geomorphic maps; paleoseismological, historical, or instrumental earthquake data; geophysical anomalies; faults; etc., which have been interpreted, parameterized, and stored in a relational database. In this paper we focus on a description of the database structure and the graphical user interface (GUI) implementation. In addition, some technical aspects of the system are presented. Since we use some technical terminology that may be unfamiliar to readers, a list of technical terms with a brief explanation is included in the glossary.

Basic Design

SAFE-T is based on a client-server architecture, with data communication and visualization occurring through the Web (Figure 1A). The processing module on the server side interacts with a relational database, while clients access the server through the Internet. A distinctive feature of the system in comparison to existing GIS software, which stores raw data (e.g., grid data such as a digital elevation model), is that the database contains mainly interpreted data. On the client side, as part of the GUI, three interfaces are operating: editing, query, and visualization. The editing interface allows data entry and maintenance of the database. The query interface gives the user the possibility to request data and launch the processing. The visualization interface displays requested data and processing results. The relevant data may be distributed in several database servers, which are connected on the Internet (Figure 1B). Once the user (client) connects to the SAFE-T system, he has access to several databases located at different institutions. To ensure portability, by which we mean a system independent of different computer platforms, the Java programming language was used for developing the system.

Figure 1

Figure 1. Basic design of the SAFE-Tools. (A) Client-server architecture. (B) Communication between database servers.


Application Architecture

The application architecture is based on a three-tier architecture (Birnam, 2001; Mukhar et al., 2001). The application is divided into three layers: the presentation, which is the graphical user interface (GUI); the processing logic; and the database (Figure 2A). These three layers may be seen as the view, the controller, and the model. The view (GUI) has access to the model (database) only through the controller (processing logic). This model-view-controller framework makes the application flexible in terms of extensibility and reusability, which means that additional functionality can easily be added to the application and the processing logic can be generalized and reused in other applications.

Figure 2

Figure 2. (A) Model-view-controller framework. The view (GUI) has access to the model (database) only through the controller (processing logic). (B) Interaction between components. On the client side the GUI, which comprises HTML forms and a Java applet, is interacting with the server through a servlet or Java server page (JSP).


Normally, to deploy the system components involved in the model-view-controller framework, additional applications are needed, which we call here "Containers" (Figure 2A). For example, the relational database management system (RDBMS) provides the basic functions to access the database. An application server is needed to deploy the EJB/JSP/Servlet (Hall, 2002; Monson-Haefel, 2002) on the server side, and on the client side a browser is needed to show the HTML documents (Powell, 2000). SAFE-T uses MySQL (http://www.mysql.com/) as a RDBMS and WebLogic (Girdley et al., 2002) as an application server. Figure 2B shows the communication framework between components. On the client side the GUI, which comprises HTML forms and a Java applet, interacts with the server through a servlet or Java server page (JSP) (see Glossary). The servlet receives the information through the Enterprise Java Beans (EJB) (see Glossary), which map the database and send it back to the GUI either as an HTML document or directly to the Java applet.

The Database

Relational Database: Basic Concepts

The first step in designing a relational database (RDB) is the classification of the information to be stored. The information is classified as different types of entities or objects according to the processing logic and the nature of the data. Each entity has a set of attributes or properties that describe its nature. Classes of entities are collected in a table where each column is associated with one of the attributes. A relational database is a set of tables connected to each other by logical relationships. The relationship between tables can be one-to-one, when one row of a table is related with one row of another table; one-to-many, when one row of a table is related with many rows of another table; and many-to-many.

Preservation of the data integrity is a basic guiding principle during the database design process. The attributes of the entities have to be organized in a way such that each piece of data is stored once and in the correct place. To design entities with data integrity a technique known as a normalization process is used. This technique consists of applying several rules to the tables to make sure that there is no redundancy of information or failure in their logical relationships. In general, the data normalization can be summarized in three basic steps (Mukhar et al., 2001): eliminating redundant attributes and/or redundant rows, removing derived data, and making certain that each table represents only one single logical entity.

RDB Tables

In SAFE-T, broad types of information have to be considered for diagnosing slow active faults. Such information can be categorized into six main groups: seismological, paleoseismic, geophysical, geological, geochemical, and geomorphic. These data are stored in tables with appropriate logical relationships (Figure 3). Four main tables are identified: earthquakes, maps, faults, and cross-sections. These tables are considered as "parent" tables with a set of subtables describing particular cases within the corresponding type of data. The data are geographically referenced either as points (e.g., earthquakes), polylines (e.g., fault segments), lines (e.g., cross-sections), or polygons (e.g., fault zones, geological units). Maps are stored as individual images and cannot be used by the processing module. The components of the maps can be parameterized and stored in the RDB to be used in a meaningful way, however. For example, in the case of "map of stress field", we stored in the database the region (polygon) in which the stress field is applicable and the corresponding parameters describing the principal stresses.

FIgure 3

Figure 3. Information included in the database. It is categorized into six main groups: seismologic, paleoseismic, geophysical, geological, geochemical, and geomorphic.


Some types of information, such as geophysical anomalies and geological units, are represented both on the surface as a map and in vertical projections (cross-sections). For example, maps of geophysical anomalies or geological units are parameterized as a set of polygons enclosing the area corresponding to the extent of the anomaly or geological unit. On the other hand, cross-sections are geographically referenced as lines and the associated anomalies have relative locations (distance and depth) to the first point of the coordinates of the cross-section. In either case, each anomaly or geological unit represents a row in the table.

Four examples of the data parameterization (tables) are listed below. Two examples, MAP and CROSS-SECTION, are parent tables, whereas the other two are daughter tables (see examples below), which include the specified information. The description of the complete list of tables used in the system can be found at http://www.geo.uib.no/seismo/safe-t/tables.html.

MAP (parent table for grouping different types of maps)

MapGeophyAnomaly (map of geophysical anomaly)

CROSS-SECTION (parent table for grouping different types of cross-sections)

CrossGeophyAnomaly (cross-section of geophysical anomaly)

In addition, all of the tables include three more properties: the user who entered the information, an access level, and a time stamp. These properties are designed for internal use.

Open Geosciences Data Retrieval

One of the objectives of SAFE-T design is to create data formats and protocols that allow interoperability between Web-based applications that retrieve geosciences data. Toward this end, we are developing server-side applications (URL-based commands) to retrieve different types of data (objects) through the Internet. These objects can be used for other Web-based applications by calling a URL address (a server-side application) followed by several input variables. The information should be retrieved in a well defined structured format. The Extensible Markup Language (XML) (Laurent and Cerami, 1999; White et al., 2001) provides a sophisticated text format that is easily read and manipulated by both people and computers. For example, to get a list of earthquakes located in a specific region within a given magnitude range, the following URL-based command could be called:


where "getEarthquakes" is a servlet (see Glossary) that can receive different variables such as the bounding box of the area selected (bbox=minLong,minLat,maxLong,maxLat). The command will return a list of earthquakes in XML format. For example:


Here, we propose specifications and data formats that could become the standard way to exchange geosciences-related data associated with active faulting and earthquakes through the Internet. Examples of XML files for different types of information used in the system can be seen at http://www.geo.uib.no/seismo/safe-t/XMLfiles.html.

The Graphical User Interface

The graphical user interface consists of HTML forms and a "Navigation Map" which is a Java applet (Figure 4). HTML forms are used for the main layout of the system and specific functions such as adding new objects into the database, removing and visualizing parametric information of a particular object, launching the "Diagnostics Wizard" (see "Processing Module" section), etc. Only an authorized user can add and remove objects from the database. The identification of users is achieved through a login and password using a secure Internet connection. The database can also be populated with XML files containing one or several objects. In this sense, authorized users submit XML files to the server side. The server-side application validates the information and indicates to the user whether the transaction succeeded or not.

FIgure 4

Figure 4. Main layout of the system is based on an HTML document, which has the "Navigation Map" (Java applet) embedded. HTML forms are used for specific functions such as adding new objects into the database, removing and visualizing parametric information of a particular object, etc. The Navigation Map allows the user to select an area on the map by a zoom-in/zoom-out action, choose type of objects to be plotted in the selected area, pick a particular object to see detailed information about, and filter the data by different properties. Earthquakes from the International Seismological Centre (ISC) are shown as an example (M > 5.5 for the period 1964-1999).


The Navigation Map (Figure 5) allows the user to perform four main functions: select an area on the map by a zoom-in/zoom-out action, choose type of objects to be plotted in the selected area, pick a particular object to see detailed information about it, and filter the data by different properties. The objects plotted on the map are also shown in a list (Figure 6). There is a direct link between the list and the map. Picking an object in the map will highlight the corresponding item in the list and vice versa. The background maps in which objects are plotted are transmitted as images to the client side. The user has the choice to select several background maps, which are generated by different Web map servers over the Internet. Most of these Web map servers belong to the Open GIS Consortium, which dynamically generate images with different layers of information (e.g., country boundaries, topography, etc.). In this case there is no limit for zooming, and the quality of the map depends on the resolution of the raw data stored.

FIgure 5

Figure 5. Examples of some object types are shown on the map. Red dots represent earthquake epicenters from the ISC database (M > 5.5 for the period 1964-1999). Objects with beachball symbols indicate focal mechanisms based on various data sources (e.g., national observatories, CMT-Harvard solutions, etc.).


FIgure 6

Figure 6. The data are visualized through four categories of symbols, which are geographically referenced either as points (e.g., earthquakes), lines (e.g., cross-sections), polylines (e.g., fault segments), or polygons (e.g., fault zones, maps, etc.). Red rectangles are the identified fault zones, whereas black rectangles correspond to objects of various types of maps. Similarly, red lines are fault segments, whereas black lines indicate locations of objects with various types of cross-sections.


Processing Module

The criteria for diagnosing slow active faults are being defined by a multidisciplinary group of scientists (Sebrier and Siame, 2001). In the first version of the system we implemented a "Diagnostics Wizard", or a quiz, to highlight the most important factors involved in the identification of slow active faults. Through the Diagnostics Wizard the users follow a logical sequence of questions. The main objective is to search for evidence or types of information relevant to deciding if the fault is active or not. This process is performed at regional, local, and site scales considering space, time, and dynamic properties of the data. At the end of the quiz the user receives an indication of whether the fault is active or not. The present implementation of the Diagnostics Wizard is an interactive tool aimed at assisting the scientist in evaluating the relevant data for identifying active faults. The user is guided through a set of questions which systematically search for diagnostic criteria in the existing data. In order to assess the reliability and the importance of the information, a multistep weighting procedure is applied. In future implementations the diagnostic criteria will be automatically applied to the data stored in the database. The algorithm for automatic processing is similar to the Diagnostics Wizard. The only difference is that the evidence used to decide if the fault is active is obtained directly from the database.

Concluding Remarks

We have presented a software tool for recognizing active faults, designed especially for slowly deforming areas such as Europe. This effort is the first attempt to classify and gather a wide range of geospatial data for the European area into a distributed relational database which can be accessed directly by a Web-based application. Furthermore, we have investigated the possibility of implementing a processing module that will help seismologists and earthquake geologists identify active faults in a given area. The flexible design of the system and the large variety of information considered in the database structure provide the opportunity to add other types of processing modules associated with active faulting and earthquakes, such as seismic hazard analysis, orientation of regional principal stress, etc. The use of distributed database technology reduces the amount of work required to maintain a large database, which can be a problem for a single institution. With the development of information technologies, Web-based applications can also easily be moved to other communication devices such as mobile phones, increasing both the usability and public interest.

How to Use the System

The system can be accessed at the Web site http://www.safe-tools.net/ at the Department of Earth Science, University of Bergen.


This work was conducted within the framework of the project "Slow Active Faults in Europe" SAFE (EVG1-CT-2000-00023), supported by the European Commission Research Directorate General. A number of people from the SAFE-Project team have contributed to the development of the concepts used in this study. We thank BEA Systems, Inc., which provided the WebLogic server software used in this Web-based application. Trond Karl Pettersen and Hector Manera helped with the HTML files and the help functions. We thank Jens Havskov and Susan Hough for their comments and suggestions, which improved the overall quality of the manuscript.


Application Server: Software for deploying Java components of the Web application on the server side, which includes EJB, JSP, servlet, etc.

Class: Type of data with properties and methods/operators.

Enterprise Java Beans (EJB): Network-aware Java classes mapping the database. They provide services (session beans) and hold information (entity beans).

Entity/Object: Instance of the class.

Extensible Markup Language (XML): Document holding information in text format (i.e., data from the database). Standard way to exchange structured textual data between computer programs.

Java Applet: Java program running in an Internet browser. The applet, which is stored on the server side, is downloaded and executed on the client side when the HTML document is downloaded.

Java Server Page (JSP): HyperText Markup Language (HTML) document embedding Java code, which is running on the server side.

Relational Database: Set of tables related each to other where one row represents an entity and the columns are the properties.

Relational Database Management System (RDMS): Software providing basic functions to access a relational database.

Servlet: Java program running on the server side and interacting with the client.


Birnam, S. (2001). Distributed Java Platform Database Development, Java Series, Sun Microsystems Press.

Girdley, M., R. Woollen, and S. L. Emerson (2002). J2EE Applications and BEA WebLogic Server, USA: Prentice Hall PTR.

Hall, M. (2002). More Servlets and JavaServer Pages, Java(TM) 2 Platform, Enterprise Edition Series, Sun Microsystems Press.

Monson-Haefel, R. (2002). Enterprise JavaBeans(TM), Second Edition, O'Reilly & Associates, Inc.

Mukhar, K., D. Shanes, J. De Carli, T. Lauinger, R. Phillips, J. Carnell, M. Mamone, J. Peach, S. Youness, N. Nanda, and D. Payne (2001). Beginning Java Databases, Wrox Press.

Powell, T. A. (2000). HTML: The Complete Reference, Third Edition, Osborne McGraw-Hill.

Sebrier, M. and L. Siame (2001). Criteria for Characterizing Slow Active Faults and Standardization of Paleoseismological Analyses: Determination of a Basic Set of Diagnostic Criteria, SAFE-Project Internal Report Deliverable.9.1, CNRS, Paris VI, France, 18 pp.

St. Laurent, S. and E. Cerami (1999). Building XML Applications, McGraw-Hill. White, C., L. Quin, and L. Burman (2001). Mastering XML(TM), Premium Edition, Sybex.

SRL encourages guest columnists to contribute to the "Electronic Seismologist." Please contact Tom Owens with your ideas. His e-mail address is owens@sc.edu.



Posted: 23 July 2005