We-Shnn Ku, Unversty of Southern Calforna, USA Roger Zmmermann, Unversty of Southern Calforna, USA
Abstract
We present an information architecture using Web services for exchanging and utilizing geotechnical information, which is of critical interest to a large number of municipal, state, and federal agencies as well as private enterprises involved with civil infrastructures. For example, in the case of soil liquefaction hazard assessment, insurance companies rely on the availability of geotechnical data for evaluating potential earthquake risks and consequent insurance premiums. The exchange of geotechnical information is currently hampered by a lack of a common data format and service infrastructure. We propose an infrastructure of Web services, which handles geotechnical data via an XML format. Hereafter we report on the design and some initial experiences.
Introduction
Geotechnical information on soil deposits is critical for our civil infrastructure.
Local, state, and federal agencies, universities, and companies need this informa- tion for a variety of civil engineering and urban policy applications, including land usage and development, and mapping of natural hazards such as soil liquefaction and earthquake ground motions. Foremost examples of geotechnical information, geotechnical boreholes are vertical holes drilled in the ground for the purpose of obtaining samples of soil and rock materials and determining the stratigraphy, groundwater conditions, and/or engineering soil properties (Hunt, 1984). In spite of rather costly drilling operations, boreholes remain the most popular and economi- cal means to obtain subsurface information. These types of data range from basic borehole logs containing a visual inspection report of soil cuttings to sophisticated composite boreholes combining visual inspection and in-situ, laboratory geotechni- cal and geophysical tests. Figure 1a shows an example transcript of the Standard Penetration Test (SPT), a particular type of geotechnical borehole test. Significant amounts of geotechnical borehole data are generated in the field from engineering projects each year. The data and results of boreholes are usually published and released as hardcopy reports, without the digital data from the field test. Naturally, sharing data via the traditional hardcopy reports is slow and results in errors when the data is converted back to digital form for further processing. With the recent ubiquity of communication networks, particularly the Internet, the trend toward electronic storage and exchange of geotechnical borehole data has accelerated. So far these efforts have often been uncoordinated and ad hoc.
Geotechnical borehole data is complex and sophisticated in that it contains both well-structured and semi-structured elements. In Figure 1a, for example, the Sum- mary field contains free-form text, while some of the other columns are well defined.
Therefore, an efficient data format for storage and exchange is required that is suit- able for the diversity of geotechnical borehole data. Currently, there is no accepted common format for exchanging these data among researchers and practitioners. To date, the most commonly-used formats for representing geotechnical borehole data include the Association of Geo-technical and Geoenvironmental Specialists (AGS, 1999), the Log ASCII Standard (Heslop Karst, Prensky, & Schmitt, 2000) for well logging in petroleum engineering, and the National Geotechnical Experimental Site (Benoit & Lutenegger, 2000) format that adopts the AGS data dictionary and expands it to cover more research-oriented geotechnical tests. Another research project was initiated at the U.S. Army Engineer Waterways Experiment Station (U.S. Army, 1998) to establish a standard electronic data format for geotechnical and geological exploration in order to automate data interchange. In addition, the Pacific Earthquake Engineering Research Center at Berkeley (PEER) and the Consortium of Organizations Strong Motion Observation Systems (COSMOS) commence a
project to create a geotechnical data dictionary and exchange format specifically for the digital dissemination of geotechnical data (COSMOS/PEER, 2002).
Recently, we have proposed the use of XML as the preferred format for storage and exchange of borehole data (Bardet, Hu, & Swift, 2003; Zimmermann, Bardet, Ku, Hu, & Swift, 2003). Similar efforts have been carried out by the W3G (The World Wide Web of Geotechnical Engineers), which proposed the Geotechnical Markup Language (Geotech-XML), a geotechnical engineering version of the eXtensible Markup Language.1 The eXploration and Mining Markup Language (XMML) project2 of the SEEGrid Community (Solid Earth and Environment Grid) also proposed an XML-based encoding for geoscience and exploration information. XMML is intended to support exchange of exploration information in a wide variety of contexts. In addition, the Open Geospatial Consortium3 (OGC) suggested the specification of Geography Markup Language (GML). GML is an XML encoding for the transport and storage of geographic information, which includes features, coordinate refer- ence systems, geometry, topology, time, units of measure, and generalized values.
Geographic features in GML include coverage and observations as subtypes.
XML offers many advantages over other data formats for borehole data. Its tree- structure and flexible syntax are ideally suited for describing constantly evolving and annotated borehole data. However, in addition to defining new data formats Figure 1. The photographs illustrate the geotechnical boring activities from drilling until the soil samples are examined; the result is a boring log showing stratigraphy, physical sampling record, and SPT blow count: (a) example of boring log; (b) drill- ing and sampling activities
(a) (b)
for borehole data, there is much research to be done to improve the exchange and utilization of geotechnical information over the Internet. There is a need for an infrastructure for sharing and manipulating this valuable information.
As the data collection and digital technologies improve, more and more geotechni- cal borehole data from the field, laboratory, or office are directly produced in, or converted to, a digital format. This makes it possible to use, share, and disseminate geotechnical data nationwide by coordinating geotechnical data standard and In- ternet dissemination activities within large organizations or government agencies.
With the recent ubiquity of communication networks, particularly the Internet, the trend towards electronic storage and exchange of geotechnical borehole data has accelerated. The ROSRINE (Resolution of Site Response Issues from the North- ridge Earthquake) project has produced an integrated system based on a relational database management system (RDBMS), geographic information system (GIS), and Internet map server (IMS) to disseminate geotechnical data via the Internet (Swift, Bardet, Hu, & Nigbor, 2002). The U.S. Geological Survey (USGS) is con- tinually publishing seismic cone penetration test (CPT) data, which is collected with USGS CPT trucks and then distributed through a Web-based system managed by the USGS Earthquake Hazard Program in Northern California (Holtzer, 2001).
All these efforts make it easier, faster, and less expensive for all levels of public and private sectors to access geotechnical information. Hence, these systems try to address the challenges and needs for timely, high-quality data as required in many geotechnical projects.
The architecture of most current geotechnical data archive and distribution systems follows the schematic in Figure 2. The end user utilizes a Web browser to gather the information of interest via the Internet. The data providers host large informa- tion sets in their database systems. Using standard Web server technology, a query interface at a URL address is provided to the end user for querying and retrieving data via the Web browser. Since geotechnical data is spatial in nature, a GIS map server is often integrated to provide a more graphical and user-friendly data query ability. This type of interactive data exchange system is designed for human partici-
Web.Server
HTTP/HTML
e.g.,.ROSRINE Data
Source
Internet
Web.Browser
Local Memory
Applications
Figure 2. Traditional client-server architecture with a Web server and a browser- based client; the client is used mostly for information presentation and visualization
pants since the data flow occurs between the end user (most likely engineers) and the system servers. However, this architecture lacks the flexibility to handle more complex tasks. For instance, how can we streamline the upload of data gathered in the field via digital equipment such as CPT trucks, which not only involve human interaction but also machine-to-machine communication? Furthermore, many times a geotechnical data set is not the end product, but the input to an analysis, simula- tion, or other computation. With a Web server/browser architecture, no simple, direct programmatic access to remote data is possible. Because many of the data repositories are under different administrative control, it is important that the data exchange format and the communication protocol follow a universally-acceptable standard that is both simple and extensible.
We believe that the emerging standard of Web services (WS) is well suited to al- leviate some of these problems.4 Web services build upon an old idea of accessing resources (storage space, compute cycles, etc.) from a local machine on a powerful remote computer. Unlike earlier attempts to provide this functionality, WS are a broadly-accepted and open standard that is supported by all major industry vendors.
The communication protocol to access services is based on the simple object access protocol (SOAP),5 which uses XML syntax. A Web service interface is formally described with a Web Service Description Language (WSDL) file. A new service can be registered with a universal description discovery and integration (UDDI) server, and it can then be located, explored, and accessed from computers around the Internet. Figure 3 illustrates the Web services paradigm with a geotechnical data repository. Multiple applications, such as soil liquefaction analysis or borehole data visualization can be built in a modular fashion. The next section describes two applications in detail. A traditional, browser-based interface can also be provided if desired.
This chapter describes our efforts to design and implement such an infrastructure based on an extensible set of Web services. The services that are initially required are: (1) file storage and (2) query and exchange. With these facilities, practitioners in the field can directly store newly-acquired data in a repository while the data customers are able to access these data sets in a uniform way. Beyond these two basic services, we have also designed a (3) visualization capability that allows an automated conversion of XML geotechnical data into a graphical view similar to the traditional hardcopy format. The output is presented as Scalable Vector Graph- ics (SVG).6
Later in this chapter we introduce the proposed WS architecture for Geotechni- cal Information Management and Exchange, hereafter referred to as GIME. We continue in next with a detailed description of the GIME Web services. Then we illustrate the usability of the GIME approach with two client applications. Related work is discussed in next. Conclusions and future research directions are contained are discussed last.
Geotechnical. Information...
Management. and. Exchange. (GIME)
Our proposed architecture for the Geotechnical Information Management and Exchange system makes extensive use of Web services to provide access to these valuable data sets for the expert practitioners as well as the general public. We will now describe each component of the system in detail.