End- User Interest in Geotechnical Data
Management Systems
Final Report
Report CA07- 0057
November 2008
Division of Research
& Innovation
Report CA07- 0057
November 2008
This page left intentionally blank
End- User Interest in Geotechnical Data
Management Systems
Final Report No. CA07- 0057
November 2008
Prepared by:
Loren L. Turner, P. E.
Toru Saito
Paul Grimes
California Department of Transportation
Division of Research & Innovation
Office of Materials and Infrastructure
The GeoResearch Group
5900 Folsom Blvd. MS- 5
Sacramento CA 95819
( 916) 227- 7174
loren. turner@ dot. ca. gov
This page left intentionally blank
DISCLAIMER STATEMENT
This document is disseminated in the interest of information exchange. The
contents of this report reflect the views of the authors who are responsible for the
facts and accuracy of the data presented herein. The contents do not necessarily
reflect the official views or policies of the State of California or the Federal Highway
Administration. This publication does not constitute a standard, specification or
regulation. This report does not constitute an endorsement by the Department of
any product described herein.
This page left intentionally blank
STATE OF CALIFORNIA DEPARTMENT OF TRANSPORTATION
TECHNICAL REPORT DOCUMENTATION PAGE
TR0003 ( REV. 10/ 98)
1. REPORT NUMBER
CA07- 0057
2. GOVERNMENT ASSOCIATION NUMBER
3. RECIPIENT’S CATALOG NUMBER
4. TITLE AND SUBTITLE
End- User Interest in Geotechnical Data Management Systems
5. REPORT DATE
December 2008
6. PERFORMING ORGANIZATION CODE
7. AUTHOR( S)
Loren L. Turner, Toru Saito, Paul Grimes
8. PERFORMING ORGANIZATION REPORT NO.
65- 339/ 65- 680921
9. PERFORMING ORGANIZATION NAME AND ADDRESS
California Department of Transportation
Division of Research & Innovation
The GeoResearch Group
5900 Folsom Blvd. MS- 5
Sacramento, CA 95819
10. WORK UNIT NUMBER
11. CONTRACT OR GRANT NUMBER
Task ID 0057
12. SPONSORING AGENCY AND ADDRESS
California Department of Transportation
Sacramento, CA 95819
13. TYPE OF REPORT AND PERIOD COVERED
Final Report
14. SPONSORING AGENCY CODE
15. SUPPLEMENTAL NOTES
16. ABSTRACT
In conducting geotechnical site investigations, large volumes of subsurface information and associated test data
are generated. The current practice relies on paper- based filing systems that are often difficult and cumbersome
to access by users. Misplaced files, deteriorated paper records, incomplete documentation, and a lack of
awareness that certain data even exists have all contributed to inefficient or incomplete utilization of existing
data. Furthermore, the pressures to expedite project delivery only heighten the need for more efficient data
management practices and more productive field data collection methods.
This research task has been a coordinated effort between the GeoResearch Group ( GRG) and Geotechnical
Services ( GS), focusing on realizing internal operational efficiencies. Current practices in field data collection,
laboratory testing, and boring log creation have been examined for potential improvements. This research task
focused on three critical components of developing an effective data management system: ( 1) data modeling,
( 2) data collection, and ( 3) data exchange and dissemination.
17. KEY WORDS
Geotechnical document and data management,
Geographic Information Systems
18. DISTRIBUTION STATEMENT
No restrictions. This document is available to the
public through the National Technical Information
Service, Springfield, VA 22161
19. SECURITY CLASSIFICATION ( of this report)
Unclassified
20. NUMBER OF PAGES
362
21. PRICE
Reproduction of completed page authorized
This page left intentionally blank
TABLE OF CONTENTS
1 INTRODUCTION ............................................................................................................................... 1
2 DATA MODELING & INTERCHANGE .......................................................................................... 3
2.1 DEVELOPMENT OF A CALTRANS GEOTECHNICAL DATA MODEL ..................................................... 3
2.1.1 Caltrans Logging Practice ..................................................................................................... 3
2.1.2 Soil and Rock Laboratory Test Data Models .......................................................................... 6
2.1.3 Implementation of the Data Model into gINT Software .......................................................... 6
2.2 DATA INTERCHANGE STANDARDS ................................................................................................... 7
2.2.1 COSMOS XML ....................................................................................................................... 8
2.2.2 Data Interchange for Geotechnical & Geoenvironmental Specialists ( DIGGS) .................... 9
3 DATA COLLECTION TOOLS ........................................................................................................ 12
3.1 THE GEOTECHNICAL LABORATORY DATA MANAGEMENT SYSTEM ( GLDMS) ............................. 12
3.1.1 Background ........................................................................................................................... 13
3.1.2 Scope of Work ....................................................................................................................... 14
3.1.3 Benefits ............................................................................................................................... . 14
3.1.4 Main Features....................................................................................................................... 15
3.2 TABLET PCS FOR FIELD BOREHOLE LOGGING ............................................................................... 19
3.2.1 Hardware .............................................................................................................................. 19
3.2.2 Software ............................................................................................................................... 20
3.2.3 User Feedback ...................................................................................................................... 20
4 DATA EXCHANGE AND DISSEMINATION TECHNOLOGIES .............................................. 22
4.1 ONLINE DATA WAREHOUSE FOR CONE PENETRATION TEST ( CPT) DATA .................................... 22
4.2 THE COSMOS/ PEER- LL GEOTECHNICAL VIRTUAL DATA CENTER ( GVDC) ............................. 25
4.2.1 The End- User Experience ..................................................................................................... 26
4.2.2 Harvesting Architecture for the GVDC ................................................................................ 29
4.2.3 GVDC Applications .............................................................................................................. 30
4.3 SEISMIC HAZARD MAP .................................................................................................................. 33
5 SUMMARY AND RESEARCH NEEDS .......................................................................................... 35
5.1 IDENTIFYING SUBSEQUENT RESEARCH TASKS .............................................................................. 35
5.2 GEODOG ............................................................................................................................... ...... 35
APPENDIX A – GLDMS DOCUMENTATION
APPENDIX B – FIELD LOGGING PC USER’S GUIDE
APPENDIX C – DATA MODEL IMPLEMENTED IN GINT SOFTWARE
This page left intentionally blank
Section 1 1
1 INTRODUCTION
In conducting geotechnical site investigations, large volumes of subsurface information and
associated test data are generated. The current practice relies on paper- based filing systems
that are often difficult and cumbersome to access by users. Misplaced files, deteriorated paper
records, incomplete documentation, and a lack of awareness that certain data even exists have
all contributed to inefficient or incomplete utilization of existing data. Furthermore, the pressures
to expedite project delivery only heighten the need for more efficient data management practices
and more productive field data collection methods.
This research task has been a coordinated effort between the GeoResearch Group ( GRG) and
Geotechnical Services ( GS), focusing on realizing internal operational efficiencies. Current
practices in field data collection, laboratory testing, and boring log creation have been examined
for potential improvements.
This task focused on assessing three critical components of developing an effective data
management system: ( 1) data modeling, ( 2) data collection, and ( 3) data exchange and
dissemination.
The data modeling component provides the basis from which the other components are built. In
the past, Caltrans’ practice of generating geotechnical data products ( e. g. borehole log data, lab
test data, etc.) had not been standardized, impairing the progress of systematically capturing data
in a comprehensive system. This research task provided resources to develop a draft data model
for Caltrans geotechnical practice. Significant deliverables include:
• Consensus building through the development of the 2007 Soil and Rock Logging,
Classification, and Presentation Manual. This was necessary in order to establish a standard
from which a data model could be built.
• A draft data model was constructed and implemented in commercial software ( i. e. gINT) to
reflect the new standards.
The research task delivered a number of pilot data collection tools:
• A pilot Geotechnical Laboratory Data Management System ( GLDMS) was developed for the
lab, utilizing a network of touchscreen workstations located throughout the lab, replacing
redundant processes once done on paper ( Figure 1).
Figure 1 – GLDMS Figure 2 – Tablet PC Figure 3 – Online CPT
Section 1 2
• Tablet PCs were made available to GS staff to assess the effectiveness of field logging
electronically. Ruggedized tablet PCs were test deployed to evaluate their use in field
logging. With logging software and an integrated GPS receiver, they provide staff the ability
to generate near- complete borehole logs before leaving the field ( Figure 2).
The research task produced a number of pilot tools to explore the benefits of various data
exchange and web- based data dissemination technologies.
• A prototype web- based repository for Caltrans' Cone Penetration Test ( CPT) data was
unveiled in early 2002, allowing operators to upload data files over the web and clients to
browse, preview, print, or download data going back ten years. A web- based map interface
and on- demand plotting are central features to the system ( Figure 3).
• Test deployment of the pilot Geotechnical Virtual Data Center ( GVDC) through participation
with the Consortium of Strong- Motion Observation Systems ( COSMOS) and the Pacific
Earthquake Engineering Research ( PEER) Lifelines Program. This parallel effort
demonstrated improved methods of geotechnical data dissemination through use of the
internet and data harvesting technologies. The project involved the active participation of a
number of state, federal, and private organizations, including Caltrans. Using a test region in
the Southern California area, the GVDC successfully demonstrated to the geotechnical
community the benefits that data exchange can bring.
• Test deployment of a web- based Geographic Information Systems ( GIS) tool for the Caltrans
California Seismic Hazard Map 1996, which is a contour map of peak ground acceleration
( PGA) for soft California- type rock conditions. This tool was developed in March 2003
following discussions with users about current practices and applications of the maps.
Although the maps have been widely available in PDF or printed format, as well as in
ArcView shapefile format for experienced GIS users, a simplified intranet tool for Caltrans
designers with little or no GIS training had not been available to date.
Figure 4 – COSMOS GVDC Figure 5 – Seismic Hazards
Section 2 3
2 DATA MODELING & INTERCHANGE
2.1 Development of a Caltrans Geotechnical Data
Model
A data model is necessary to ensure consistency in logging practices while enabling the creation
of a geotechnical data repository for statewide geotechnical data. It’s the basis for geotechnical
data management tools. The data model defines the individual data entities that comprise the
tables of the database as well as the relationships between tables. This documentation usually
consists of information such as the parameter name, description, type ( integer, real, string, etc.),
units, or other descriptors.
A comprehensive data model for Caltrans’ geotechnical practice has been under development
since the inception of the project. In the early stages of the project, data models for specific data
sets ( e. g. Cone Penetration Test) were defined to support specific application test development.
Later in the project, interagency research activities, such as the COSMOS- PEER Geotechnical
Virtual Data Center, prompted an examination of the broader scope of Caltrans practice.
Development of the 2007 Soil and Rock Logging, Classification, and Presentation Manual
required a detailed examination of Caltrans logging and classification practices which helped
further define the data model.
2.1.1 Caltrans Logging Practice
The publication of the Caltrans 2007 Soil and Rock Logging, Classification, and Presentation
Manual was the result of a two year effort by a committee comprised of engineers and geologists
within Geotechnical Services and the Division of Research and Innovation ( Figure 6). Prior to the
publication of the manual, staff relied upon the 1996 publication, Soil & Rock Logging,
Classification Manual, Field Guide. However, as the 1996 manual only covered field operations,
it didn’t represent the breath of information processed by Geotechnical Services for typical site
investigations. Standards for metadata coding for information associated with laboratory tests, for
example, were not well defined prior to the 2007 manual. Furthermore, since the 1996 manual
was considered a guideline, not a required standard, its use was not consistently applied
throughout Geotechnical Services and was often supplemented or replaced by standards
published by the FHWA, AASHTO, EPRI, ASTM, and other standards groups. The 2007 manual
was issued as a comprehensive standard with mandatory requirements for geotechnical data
collection, compilation, and reporting.
Section 2 4
Figure 6 – Logging Manual
The revised logging requirements adopted a component- based descriptive approach. That is,
soil and rock are described in a sequence of specific attributes with pre- defined value lists as
summarized in the tables below ( Figure 7).
Section 2 5
Figure 7 – Component- based descriptions
This approach enforces consistency in soil and rock description in addition to lending itself to
database design.
Detailed soil and rock descriptions and classifications are an essential part of the information
developed to support design and construction processes. Subsurface information for any given
area is, and can be, generated and accumulated over a prolonged period of time by various
geotechnical practitioners for different projects and purposes. Maintaining consistency in
borehole logging and reporting practices is critical to assuring uniformity in geotechnical products.
The manual accomplishes this by addressing the following:
• Serves as a comprehensive reference for Departmental staff, consultants, and contractors
• Provides standardized soil description and identification procedures utilizing field data
• Provides standardized soil classification procedures utilizing laboratory data
• Provides standardized rock description and identification procedures utilizing field and
laboratory data
• Serves as a basis for Departmental products and tools, such as:
o Boring Log presentation formats,
o Log of Test Boring ( LOTB) legend sheets,
o Descriptive terminology presented in geotechnical reports, and
o Geotechnical Data Management System
Section 2 6
In addition to soil and rock identification, description, or classification, the manual contains
instructions that present Departmental standards for borehole and sample identification, minimum
material requirements for various laboratory tests, and boring log presentation formats.
2.1.2 Soil and Rock Laboratory Test Data Models
In the process of developing the Geotechnical Laboratory Data Management System ( GLDMS),
an extensive data model for soil and rock index properties was defined and implemented.
Specifically, the following tests incorporated into the GLDMS were considered:
• Moisture Content
• Unit Weight
• Specific Gravity
• Atterberg Limits
• Mechanical Analysis
• Point Load Index
• Compaction Curve
• Expansion Index
The complete data dictionary can be found in the appendices to this report.
2.1.3 Implementation of the Data Model into gINT
Software
Caltrans Geotechnical Services has been using a commercial borehole data management and
presentation software package called gINT. The software enables users to create customizable
database structures and user- definable reports to capture soil and rock data logged in the field.
Once data is entered into gINT, the user can generate Microstation compatible CAD drawings of
boring logs and records, laboratory test reports, profiles, and other design reports. The software
requires that the user define the various soil and rock attributes to be captured in addition to how
the information is synthesized and presented in report products.
Figure 8 – gINT interface
Section 2 7
The gINT interface is structured similar to a spreadsheet software interface. Related attributes
are presented within worksheet tabs ( Figure 8). Records are entered in rows with columns for
attributes. The user enters borehole information using series of pull- down lists in accordance with
the logging manual. Once data is entered, the software can auto- generate graphical
representations of the information for use in CAD applications or as report attachments ( Figure
9).
Figure 9 – gINT output
The Caltrans 2007 Soil and Rock Logging, Classification, and Presentation Manual was used as
the basis for the data model that was implemented into a gINT library and made available to staff.
This Caltrans- specific version of the gINT data model and associated import tools were tailored
for Caltrans geotechnical practices and is compatible with version 8 of the software. The data
model and tools feature:
• An enhanced data dictionary to accommodate data related to soils lab testing, specifically,
triaxial, consolidation, direct shear, moisture, density, water content, atterberg limits, specific
gravity, permeability, gradation, point load, and relative compaction. Attributes for these data
sets include those found in the Caltrans data dictionaries in addition to capturing comparable
ASTM and/ or CTM reporting requirements.
• A data file translation tool to import data sets from automated data acquisition systems from
Vertek CPT equipment into the Caltrans- gINT data model.
A more detailed description of the data model implemented into gINT can be found in the
appendices.
2.2 Data Interchange Standards
Where a data model facilitates the standardized collection and storage of data, the data
interchange standard facilitates the exchange of that data within an organization or between
Section 2 8
organizations. Data exchange can occur at many steps in the lifecycle of data. For example,
data can be electronically collected by field testing equipment, such as a CPT rig, The data is
passed to the client as a file containing the field measurements. The client may use that data in
an analysis and then provide the resulting data to their client. That data may ultimately end up in
a larger data repository or some type for that particular organization. Multiple organizations may
want to exchange this data to. At each stage in the data’s lifecycle, the data is transformed
through a series of import, modification, and export steps. Standardization of the data
transformation and exchange vehicle can make for a more efficient process.
Over the course of this research, two significant data interchange standards efforts were initiated:
( 1) the COSMOS Extensible Markup Language ( XML) schema, and ( 2) the Data Interchange for
Geotechnical & Geoenvironmental Specialists ( DIGGS) Extensible Markup Language ( XML)
schema. In both efforts the Caltrans data model served as the basis for many of the interchange
standards components. Furthermore, this research task provided the necessary funding and
resources to support Caltrans participation in these important efforts.
2.2.1 COSMOS XML
In May 2002 the Pacific Earthquake Engineering Research ( PEER) Lifelines Program initiated a
project through the Consortium of Strong- Motion Observation Systems ( COSMOS) to
demonstrate improved methods of geotechnical data dissemination through use of the internet
and data harvesting technologies. The result of the effort was the test deployment of the pilot
Geotechnical Virtual Data Center ( GVDC) ( https:// geodata. cosmos- data. org/ index. asp). The
project involved the participation of a number of entities, including Caltrans, California Energy
Commission, Pacific Gas & Electric, PEER- Lifelines Program, Pacific Earthquake Engineering
Research Center, United States Geological Survey, California Geological Survey, University of
Southern California, and COSMOS. Many of the organizations made significant contributions to
the project, participating as workgroup leaders, system developers, and data providers.
Using a test region in the Southern California area, the GVDC successfully demonstrated to the
geotechnical community the benefits that data exchange can bring. A number of innovative
technologies were incorporated into the GVDC, including: database harvesting, XML
geotechnical data interchange standards, web- GIS interface, and SVG on- demand previewers.
The system was presented in a joint COSMOS/ PEER- LL and Federal Highway Administration
( FHWA) workshop in June 2004 in Newport Beach, California. The final report, “ Archiving and
Web Dissemination of Geotechnical Data: Development of a Pilot Geotechnical Virtual Data
Center,” is available online at the PEER website ( http:// peer. berkeley. edu/ lifelines/ LL-CEC/
reports/ final_ reports/ 2L02- FR. pdf).
The COSMOS Extensible Markup Language ( XML) schema is the primary mechanism for data
exchange within the GVDC. The XML schema is web- based file format, built from the COSMOS
data model ( Figure 10) with input from the data models of the participants.
Section 2 9
Figure 10 – COSMOS data model
2.2.2 Data Interchange for Geotechnical &
Geoenvironmental Specialists ( DIGGS)
Following the success of the GVDC, a group of State Transportation agencies, led by the Ohio
Department of Transportation and FHWA, organized to initiate a Transportation Pooled Fund
( TPF) project. The focus of the TPF project would be to compile the standards development work
of COSMOS, the Association of Geotechnical & Geoenvironmental Specialists ( AGS) from the
United Kingdom, and others to create a new international data exchange format. The resulting
data interchange format would have global application and allow software vendors and users in
the geotechnical community to seamlessly exchange data. The project, “ Development of
Standards for Geotechnical Management Systems, Project TPF- 5( 111),” was approved and
funded in the Summer of 2005 at a funding level of approximately $ 700k over three years
( www. pooledfund. org).
The Geotechnical Management Systems ( GMS) Group was formed from the project’s funding
partners and sponsors to oversee and guide the work of the project ( Figure 11). The group is
comprised of representatives from a number of State Transportation Agencies, Federal Agencies,
and the United Kingdom Highway Agency. The Geotechnical Data Coalition ( GDC) was created
by the GMS Group to involve in the process representatives from the various national and
international organizations that are currently developing and maintaining geotechnical data
exchange standards and data management and/ or exchange systems. The technical work is
being carried out by the Core Team under the direction of the GDC. The focus of the GDC is to
Section 2 10
develop consensus on a single data exchange standard for the broader geotechnical community
that combines the best features of existing standards.
Geotechnical Management Systems ( GMS) Group Geotechnical Data Coalition ( GDC)
• California Department of Transportation
• Connecticut Department of Transportation
• Eastern Federal Lands Highway Division
• Federal Highway Administration
• Florida Department of Transportation
• Georgia Department of Transportation
• Kansas Department of Transportation
• Kentucky Transportation Cabinet
• Minnesota Department of Transportation
• Missouri Department of Transportation
• North Carolina Department of Transportation
• Nevada Department of Transportation
• Ohio Department of Transportation
• Tennessee Department of Transportation
• Virginia Department of Transportation
• United Kingdom Highway Agency
• United States Army Corps of Engineers
• United States Environmental Protection Agency
• United States Geological Survey
• Association of Geotechnical and Geoenvironmental
Specialists ( AGS)
• Consortium of Strong Motion Observation Systems
( COSMOS)
• Construction Industry Research and Information
Association ( CIRIA)
• Federal Highway Administration ( FHWA)
• Ohio Department of Transportation
• University of Florida ( UF)
Figure 11 - GMS
Significant progress has been made to date in the development of a new geotechnical data
exchange standard, DIGGS. An initial meeting of the Geotechnical Data Coalition was held in
May 2005 in Atlanta, Georgia. At that meeting consensus was reached by the group that it was in
the best interest of the geotechnical community to pursue the development of a single data
exchange standard. Fundamental decisions about the structure and approach for the new data
model, DIGGS, were made, and a workplan and schedule to carry forth the effort by the
partnering entities were established.
In July 2005 the COSMOS/ PEER- LL project team hosted a workshop in San Francisco,
California, to expand the current GVDC Data Dictionary ( COSMOS XML v1.0) to include data
standards for various seismic velocity tests ( e. g., PS- Logger, Downhole Logging, Crosshole
velocity data, and velocity profiles derived using surface wave profiling, SASW), laboratory
geotechnical tests ( e. g., triaxial, consolidation, and so on), and insitu tests ( e. g., pressuremeter,
vane shear). Participants from government agencies, industry organizations, and academia with
expertise in specific test procedures were brought together to develop the expanded data
dictionary.
In August 2005 the Core Team met in Richmond, California, to continue the task of developing
the initial draft version of DIGGS. The team worked to develop a data dictionary for the
comprehensive set of borehole, insitu/ lab test, and geophysical test related data using existing
data models from the Association of Geotechnical and Geoenvironmental Specialists ( AGS),
COSMOS, and the University of Florida as a starting point. They also incorporated the data
dictionary produced by the earlier July 2005 COSMOS/ PEER- LL workshop. Although a
substantial part of the data dictionary was developed, the work could not be completed at that
time. A second workshop was held in November 2005 to complete that work.
For the GVDC, DIGGS will replace the existing COSMOS XML v1.0 as the format for exchanging
data between the unique data providers, the GVDC, and the end users ( Figure 12). DIGGS will
bring many benefits to the GVDC, most notably a broader acceptance and standardization of
information management within the national and international geotechnical communities.
Additionally, DIGGS will have the benefit of being GML compliant, facilitating the use of data
within Geographic Information Systems ( GIS). Finally, DIGGS will eventually encompass a
broader range of geotechnical data beyond strictly borehole data, such as assets ( e. g. data on
piles, retaining structures, etc.) to meet the needs of a greater number of users.
Section 2 11
Figure 12 – Data interchange with DIGGS
( 2) GVDC requests
record( s) from Data
Provider
Data Provider GVDC User
( 1) User requests
record( s) from
GVDC
( 4) GVDC delivers
DIGGS XML file( s) or
SVG graphic( s) to user
( 3) Data Provider locates
and translates record( s)
into DIGGS XML file( s)
Section 3 12
3 DATA COLLECTION TOOLS
3.1 The Geotechnical Laboratory Data
Management System ( GLDMS)
The Geotechnical Laboratory Data Management System ( GLDMS) is one of the most significant
deployable, developed as a result of this research task, modernizing soil test data collection and
management practices at the Geotechnical Laboratory. The development of the system was
conducted over a 12 month period. A computer science graduate student assistant, Toru Saito,
carried out the programming and hardware integration tasks under the guidance of the task’s
Principal Investigator, Loren Turner, and the Geotechnical Laboratory Manager, Craig
Hannenian.
The system is comprised of a network of touch screen stations ( Figure 13) installed throughout
the lab facility that enables technicians to enter and retrieve test data while conducting their work.
A single web server is at the hub of the system and provides data storage, processing, and
validation. ( Figure 12)
Figure 12 – GLDMS architecture
The GLDMS architecture was designed to store test data in a central database. Having a central
repository eliminates many of the redundancies in data collection and analysis, and makes the
data much more accessible to end users.
Server
Office PC Lab Touch Screen
Section 3 13
3.1.1 Background
The Caltrans Geotechnical Laboratory is an AASHTO Materials Reference Laboratory ( AMRL)
accredited facility located in Sacramento, California. The Geotechnical Laboratory provides a
wide variety of soil and rock testing services for various Caltrans units throughout the state.
Annually, the lab processes approximately 90 job requests, consisting of an estimated 5000
samples and 10,000 soil and rock tests. The Geotechnical Laboratory has the equipment and
capacity to carry out 24 types of soil and rock tests.
Prior to the development of the GLDMS, technicians recorded data manually on paper- based
forms during testing. The data was then entered into Excel spreadsheets and used to prepare
printed reports and charts for review by lab managers. Reports were then printed for clients and
the paper archived for storage in the fileroom. This cycle of data collection and reporting involved
redundant data entry, difficult retrieval of archived data, and possibly introduced transcription
errors.
Within the lab, paper- based data entry also created redundancies. For example, in the past, a
technician would have to manually search for moisture data in a binder of past moisture
measurements ( the “ Moisture Book”) in order to proceed with a related test such as Plasticity
Index testing. The GLDMS has eliminated the need to cross reference test results, since the
tests are cross- referenced within the GLDMS database. As such, technicians are able to perform
Plasticity Index tests without using the Moisture Book or other redundant procedures.
Figure 13 – GLDMS touchscreen station
Section 3 14
3.1.2 Scope of Work
The GLDMS development effort was planned as a two phase approach. The first phase would
involve development of the interface and data models to support the common index property
tests. In most cases, index property testing to date has required manual data collection by
technicians. Phase 2 would integrate the remaining tests, in particular, the tests where
standalone data acquisition units produced digital test files.
The following eight tests are handled by the GLDMS as part of Phase 1.
• Moisture Content
• Unit Weight
• Specific Gravity
• Atterberg Limits
• Mechanical Analysis
• Point Load Index
• Compaction Curve
• Expansion Index
Phase 2 will focus on capturing data generated by the following test equipment:
• Direct Shear ( ASTM D 3080)
• Consolidation ( ASTM D 2435)
• Triaxial CU ( 3 points) ( ASTM D 4767,)
• Triaxial UU ( 1 point) ( ASTM D 2850)
• Unconfined Compression ( ASTM D 2166, ASTM D 2938)
In addition the GLDMS will accommodate test results associated with the remaining tests.
3.1.3 Benefits
The GLDMS provides three key benefits:
• Improves efficiencies in collecting and processing test data,
• Reduces errors in data handling, and
• Facilitates easy access to archived test data
By implementing the GLDMS, the processes of collecting and analyzing test data have become
more efficient. In the past, the processes of recording, processing, validating, and reporting test
data were handled by utilizing printed forms and several different computer applications, including
Microsoft Excel and FileMaker Pro. Since the test data were stored in incompatible file formats
and mediums, technicians would have to find and re- enter the same test data repeatedly during
each process, from initial collection to final reporting.
For example, a soil sample test may require a technician to determine the moisture content as
part of a mechanical analysis report. Before the GLDMS was implemented, the technician had to
search through handwritten data entries to find the moisture content associated with the
mechanical analysis. Whereas in the GLDMS, data collection and retrieval process is
streamlined, so when the technician enters moisture content data, the newly entered data is
automatically associated with soil sample’s mechanical analysis test.
To increase the reliability of test results, the GLDMS reduces calculation errors by:
Section 3 15
• Eliminating duplicative data entries.
• Automating and centralizing the calculation of test result parameters.
• Enforcing data validation at the time of data entry. ( e. g. A user enters 10.8 for the
wet+ tare weight field but then enters 15.5 for the tare weight field. Since the wet+ tare
weight value must be larger than tare weight value, there is clearly a data entry error.
The GLDMS can identify these types of input errors, send notification of the error,
and prevent further data entry until the data is corrected.)
• Storing all test data for a particular sample in a central database that makes test data
available for other tests. ( e. g. The results from a moisture content test for a sample
can be used in the calculations for a unit weight test or a mechanical analysis test on
the same sample automatically.)
• Performing necessary calculations as test data gets entered.
With data archived on paper, it has been difficult to locate old test results that match a particular
set of criteria. Using the GLDMS, old test records can be retrieved easily and quickly. For
example, a user may need to retrieve a set of test records that were conducted on soil samples
from District 04 during the period between February 2006 and March 2006. The GLDMS can
perform the search and return the results with a few mouse clicks.
Another advantage of the GLDMS is that the test data can be exported for use in other software
applications or data management systems, using standardized data interchange file formats for
geotechnical data such as Data Interchange for Geotechnical and Geoenvironmental Specialists
( DIGGS). These data exchange technologies will decrease the amount of work, not only for the
Geotechnical Laboratory, but also for its clients who further utilize soil test data.
3.1.4 Main Features
The GLDMS stores and manages lab data in a central data management server. Using client
PCs and touch- screen terminals, users input their lab data which gets stored on the server. The
system is extensible, and the Geotechnical Laboratory can expand the capacity of the system as
it increases number of terminals in the future.
The GLDMS provides search functionality to look up all available lab data with various criteria.
The criteria includes common project and job attributes ( e. g. GL Track No., Dist- EA, Structure,
No., Boring ID, Sample No., Test Type, Test Status, and others). ( Figure 14)
Section 3 16
Figure 14 – Search screen
The GLDMS can produce printable test summary reports ( Figure 15) while performing necessary
calculations automatically. The figure below shows samples of printed reports generated by the
GLDMS. These reports include summaries of index properties, mechanical analysis, atterberg
limits, etc.
Figure 15 – Summary reports
Section 3 17
The GLDMS monitors current testing activities and can generate daily, monthly, and annual
production reports to evaluate the productivity of the lab ( Figure 16).
Figure 16 – Production Reporting
By maintaining individual user logins, the GLDMS can control users’ access and keep logs of
their activity for future reference.
Commonly used web browsers are used to access the GLDMS. Since most of the technicians are
familiar with web browsers, they can navigate the system easily.
Figure 17 – Touchscreen data entry
Section 3 18
The GLDMS utilizes space- saving touch screen devices for data entry wherever space for a
conventional keyboard and mouse is not available ( Figure 17).
At some locations, the touch screen stations are connected with digital scales ( Figure 18) and the
measurement reading from the digital scale is entered into the GLDMS interface automatically.
Figure 18 – Digital scale connected to touchscreen
The GLDMS provides a level of data validation to prevent common input errors that happen
during manual data entry, such as decimal point entry errors.
For increased data integrity and performance, the GLDMS stores lab data on two separate hard
drives. A full backup of the entire database is performed daily on the server, and a copy of the
daily backups is archived on an off- site network hard drive for data files for the past month.
3.2 Tablet PCs for Field Borehole Logging
As part of this research task, the use of ruggedized tablet PCs were evaluated for their
effectiveness in documenting and collecting borehole logging data in the field. Five ruggedized
tablet PCs were deployed over the course of two years beginning in July 2005. The units function
as a standard laptop, or can be converted to a tablet, complete with pen stylus and handwriting
recognition interface. A Caltrans- specific version of the gINT logging software was installed on
each unit. The combination of features and software provided field staff with the capability of
generating near- complete borehole logs while still in the field. It addition these units minimized
errors from multiple handling of data between field and office operations.
3.2.1 Hardware
Panasonic Toughbook model CF- 18 tablets were selected for their durability in outdoor
environments and sunlight readable display. These units also incorporate an integrated GPS
receiver to provide positioning information. The specifications for the tablet PCs include 1.1 Ghz
Intel Pentium M Centrino processor, Windows XP Tablet Edition, 768MB RAM, 40 GB hard drive,
integrated WIFI, and onboard GPS.
The following physical components constitute each unit ( Figure 19):
• Panasonic Toughbook CF- 18
• Power supply for CF- 18
• Stylus Pen
• LCD cleaning towel
• External USB DVD/ CDRW drive
• SimpleTech 512MB USB memory stick
• Pelican shipping case
Figure 19 – Field borehole logging hardware
3.2.2 Software
The Toughbooks were configured with a basic suite of software suitable for borehole logging and
field operations. The following software was installed on each PC:
• gINT version 8
• Corpscon version 6
• Microsoft Office Professional 2000
• CoPilot Live 7
gINT version 8 is the primary software for entry and management of borehole logging data and is
the primary tool in the field. Corpscon version 6 is a software tool that allows staff to easily
convert between geodetic latitude- longitude ( typically output by GPS receivers) and State Plane
Northing- Easting ( typically provided by Caltrans survey crews). Microsoft Office was installed to
facilitate additional note taking and data manipulation. CoPilot Live version 7 was installed to
utilize the integrated GPS unit.
3.2.3 User Feedback
Over the course of the evaluation period, feedback was mixed with regards to the effectiveness of
the tablet PCs in the field. At one extreme there were the early adopters that had an overall
positive experience with the tool. On the other extreme, some expressed concerns with the
complexity of the device and its impracticality for logging during a drilling operation. Feedback
from this group of users are listed here:
Power Supply
USB Memory Stick
Cleaning Towel
USB DVD/ CDRW
Toughbook
Stylus Pen
Shipping Case
• Many commented that they liked the idea of being able to produce boring logs while in
the field.
• Some logged directly into the gINT software on the tablet, while others would log on
paper forms and transfer their notes into gINT later at the hotel or during drilling breaks.
• Differences between the logging standards implemented into gINT and those published
in the 1996 and 2007 editions of the Caltrans Soil & Rock Logging Manuals created
problems for many users.
• The handwriting recognition feature in the tablet PCs was not frequently used.
• The integrated GPS and related software was not frequently used.
• gINT data entry via the graphical method was not used as often as the direct table data
entry method.
• Many expressed the need for more specific training in the use of gINT software and the
Caltrans- specific gINT library.
• Some users were concerned with the potential for loss of data due to hardware failure.
Consequently, many of these users tended to collect information on paper and transfer to
the tablet PCs at a later time.
• A number of users reported that the tablet PC method for direct data collection was not
practical in the context of a drilling operation. Often times it was quicker to write notes on
paper rather than enter data in multiple fields on a tablet PC. Some users attempted data
entry directly, but found that this process delayed drilling operations unnecessarily.
4 DATA EXCHANGE AND DISSEMINATION
TECHNOLOGIES
4.1 Online Data Warehouse for Cone Penetration
Test ( CPT) Data
In early 2002 a pilot study was initiated to explore the feasibility and effectiveness of a web- based
repository for Caltrans' Cone Penetration Test ( CPT) data. The result of this work was a fully
functional prototype data warehouse system which allowed CPT operators to upload data files
using a web browser, and allowed clients to browse, preview, print, or download any Caltrans
CPT data file generated since 1994.
Features integrated into this prototype system included:
• File Upload: CPT field operators log into a password protected area of the web site, and use
a file browser to select files to be uploaded to the data warehouse. This function can be
performed while in the field, at a hotel or office near the jobsite ( using a conventional
modem), or back in the office ( over the network). The operator only needs to select the file( s)
to upload ( Figure 20). The server software automatically extracts information from the file
including job number, location, sounding number, operator, etc, and creates new directory
structures on the web server.
Figure 20 – File uploading
Figure 21 – Browse for CPT data online
• Searching for Data: Users needing access to CPT data can go the CPT website and browse
for files based upon the year, job number, and CPT sounding number ( Figure 21). Files
uploaded from CPT field crews are immediately available on the system. Alternatively, users
can use an web- based map interface ( developed with ESRI’s ArcIMS) to search for available
CPT data ( Figure 22).
Figure 22 – Browse for CPT using ArcIMS interface
• Preview Data: Once the correct data file is identified, the user can click the link under the
“ View Data” heading to open a new window with the raw data ( Figure 23), or click the link
under the " View Charts" heading to generate a plot of the data ( Figure 24) These plots were
designed to print neatly on standard 8.5" x11" paper for use in geotechnical reports. The raw
data file is also available using the links below the " View Data" header. This file can be used
to conduct further analyses.
Figure 23 – Data view
Figure 24 – Chart view
The CPT previewer was coded in VB. NET by Paul Grimes ( Caltrans Student Assistant), to allow
end users to view graphical charts of CPT data. When the “ View Charts” link is clicked, CPT
charts are generated on- the- fly and are displayed in a new browser window ( Figure 24).
The CPT previewer application is first passed a URL corresponding to the location or path of an
XML file containing Caltrans CPT data. The XML file is parsed and the required CPT data is
processed to dynamically generate multiple SVG images ( charts) per CPT. The CPT charts and
related metadata are displayed using HTML within a new browser window on the end user’s
computer. The SVG images provide the user with a graphical representation of the CPT data.
4.2 The COSMOS/ PEER- LL Geotechnical Virtual
Data Center ( GVDC)
The Geotechnical Virtual Data Center ( GVDC) was developed under the leadership of the
Consortium of Strong- Motion Observation Systems ( COSMOS) in partnership with the Pacific
Earthquake Engineering Research ( PEER) Lifelines Program. Caltrans participation through this
research task was crucial to the development of both the initial pilot system in 2004 as well as the
second generation production system expected to be unveiled in late 2008.
4.2.1 The End- User Experience
The Geotechnical Virtual Data Center ( GVDC) can be thought of as a virtual gateway to data
repositories from multiple agencies, relying upon DIGGS for standardized data exchange. The
GVDC functions as a “ data broker” rather than a “ data repository.”
When the user navigates to the GVDC home page, they are presented with general information
about the project and the system ( Figure 25).
Figure 25 – GVDC main page
Standard user account and login tools are provided for security and a personalized end- user
experience ( Figure 26).
Figure 26 – Login page
The primary interface for the user is the map- based search tool ( Figure 27). Within this interface,
the user can browse the map and view placemarks where data exists.
Figure 27 – Map- based search tool
The search criteria tool consists of an expandable area selection tool as well as an advanced
search criteria section in the lower part of the screen ( Figure 28).
Figure 28 – Advanced searching
The user can choose to search by specific types of data, dates of investigation, data provider,
and borehole depths.
Search results are presented to the user in series of interactive tables ( Figure 29). Results are
grouped at the highest level by each data provider. Tabular lists are presented and can be sorted
by various data attributes. The user can select a single data set for view within a pop- up map to
provide spatial context.
Figure 29 – Search results
The user uses the check- boxes in the table to specify which data files they’d like to download.
The user is then presented with a use agreement prior to obtaining the DIGGS files ( Figure 30).
Figure 30 – Data download
4.2.2 Harvesting Architecture for the GVDC
The Geotechnical Virtual Data Center ( GVDC) system architecture facilitates the dissemination of
geotechnical and geophysical data from a Data Provider to an end- user through the GVDC web
portal. There are two major components to the system, the GVDC Server and the Data Provider
Server.
Figure 31 – GVDC harvesting architecture
The GVDC Server provides web hosting for the GVDC’s web site, maintains an database of
metadata of available data sets, harvests metadata from Data Providers, hosts map and text
based search interfaces, manages user accounts, and tracks data usage statistics.
End- user
Private Firms
GVDC Server
Data Provider Servers
The Data Provider Server functions as either a web server or a FTP server. It hosts the collection
of available DIGGSml files, or, alternatively, a server- side application that automatically generates
DIGGSml files on demand. It also hosts a single MetaDIGGS file that can be harvested by the
GVDC. This server may also host the Data Provider’s data in its original form ( e. g. database, flat
files, Excel files, gINT files, etc.), data transform applications, and MetaDIGGS file generators.
However, this is not a requirement. A Data Provider need only host the DIGGSml files and the
MetaDIGGS file in order to participate as a Data Provider for the GVDC.
The GVDC Server has two primary functions: ( 1) harvest metadata from Data Providers, and ( 2)
deliver DIGGSml data sets to end users. The original GVDC accomplished metadata harvesting
through the implementation of OAIB, requiring a communication link between the GVDC’s
database and the Data Provider’s database. In the revised GVDC system, the function of OAIB is
replaced with a modular approach. Notably:
• The Data Provider needs to generate DIGGSml files for their data sets. This can be
accomplished in a variety of ways; however, the Data Provider will need to develop this
component. Using a DIGGS Generator application is one possibility.
• The Data Provider needs to generate a single MetaDIGGS file that contains the metadata for
their entire data repository. A single standard application, MetaDIGGS, will accomplish this.
This application can be used by any Data Provider to extract metadata from a collection of
DIGGSml files.
• The Data Provider hosts the MetaDIGGS and DIGGSml files on a web or FTP server.
• The GVDC server runs an application, Harvester, that retrieves the MetaDIGGS file from the
Data Provider, and completely replaces that Data Provider’s data in the GVDC’s PostgreSQL
database with this new information.
Delivery of DIGGSml files to the end user is accomplished through the following mechanisms:
• The Data Provider hosts DIGGSml files on their web or FTP server. These can be static files
on the server, or they can be generated dynamically, depending upon the Data Provider’s
specific system and preferences.
• The MetaDIGGS file contains the URL to where DIGGSml files are located.
• When user requests a particular data set, the GVDC retrieves the specific DIGGSml file and
provides it to the user in its original format, as an Excel file, or in a graphical preview.
4.2.3 GVDC Applications
There are four separate applications to support harvesting in the system: ( 1) DIGGSml
Generator, ( 2) MetaDIGGS Transform, ( 3) MetaDIGGS Extension Suite, and ( 4) Harvester.
These applications are illustrated in the system diagram below ( Figure 32):
Figure 32– GVDC applications
GVDC Server
Database
Data Provider Server
Flat
Files
Excel
Files
MetaDIGGS
XML File
DIGGS Generator
MetaDIGGS Transform
Harvester
Data Sources
Java
Application
MetaDIGGS
Extension Suite
( optional)
Transform
Java Wrapper
Transform
Java Wrapper
Transform
Java Wrapper
PostgreSQL DB GVDC Database
( of MetaDIGGS data)
GVDC Website:
- Map and Document Searches
- Administrative Tools
DIGGSml
Files
DIGGS Generator is an application that is very specific to the particular Data Provider. In fact,
this may be a standalone application, a function of another application, a web service, or some
other form. In its simplest implementation, this could be an export function in commercial logging
software, such as giNT, that creates a DIGGSml file. Or, perhaps one could capture data in an
Excel spreadsheet and export to a DIGGSml compatible file. This could take the form of a data
mapping application that one uses to covert from flat files, Excel files, or other file types to a
DIGGSml file. The data mapping application or transform code may be wrapped within another
application and used to automate the creation of DIGGSml files. Some Data Providers might
choose to batch convert and just host the resulting static DIGGSml files. Others might choose
not to host static files, and instead, create the DIGGSml files only when requested by the GVDC.
Since each Data Provider is unique in the way they store and manage their data, the DIGGS
Generator functionality will need to be developed and implemented by the Data Provider.
MetaDIGGS Transform is an application that a Data Provider uses to facilitate the generation of
the MetaDIGGS file. The purpose of the application is to provide simple, automated metadata
generation functionality for Data Providers. The application will output a metadata file, in the form
of MetaDIGGS XML, summarizing a data provider’s geo- technical information.
The MetaDIGGS Extension Suite is an application that adds functionality to the MetaDIGGS
Transform application. MetaDIGGS Extension Suite is not required to be installed or run by a
Data Provider in order to participate in the GVDC. This is a standalone Java application that
invokes MetaDIGGS Transform and automatically passes input parameters to it. This application
provides features that are frequently needed by most Data Providers, such as:
• Schedule MetaDIGGS Transform to run daily, monthly, quarterly, etc.
• Provide an interface to call MetaDIGGS Transform as a dynamic servlet.
• Have a DIGGSml “ watcher” feature, such that a new MetaDIGGS file is only created when a
DIGGSml file is added, modified, or removed from the target directory.
The Harvester is an application that executes on the GVDC server. The purpose of the
application is to retrieve MetaDIGGS XML files from all Data Providers and ingest that data into
the GVDC’s database.
4.3 Seismic Hazard Map
Since the publication of the Caltrans California Seismic Hazard Map 1996 and the implementation
of the Caltrans Seismic Design Criteria ( SDC), Caltrans engineers have had to assess seismic
hazards using a series of published maps and measuring distances from new project sites to
nearest faults. This design procedure required either: ( 1) physical measurements on printed
maps, or ( 2) use of ArcView software to perform distance calculations. For preliminary studies,
the first method was often employed due to its simplicity. The second method presented
challenges since most of the engineers did not have the necessary software on their PC or the
proper training to effectively utilize the software.
Figure 33 – Online seismic hazard map application
In 2003 the GeoResearch Group unveiled an online tool to facilitate the measurement of fault
distance determination ( Figure 33). The tool was developed using ESRI’s Internet Map Server
( ArcIMS) software running on a web server under a Windows Server 2003 operating system. The
application displayed general map data, such as Caltrans Districts, lakes, rivers, major cities, and
highways. In addition, the map interface also displayed the fault locations and attenuation buffers
based upon the 1996 Seismic Hazard Map as well as state and local bridges. A measurement
tool was incorporated into the interface that allowed users to select two points. Upon selection,
the application would provide the user with the measured distance on the map. Information on
the faults was also available through the interface.
5 SUMMARY AND RESEARCH NEEDS
5.1 Identifying Subsequent Research Tasks
This task focused on assessing three critical components of developing an effective data
management system:
• Data modeling
• Data collection
• Data exchange and dissemination
As described in this report, significant progress has been made in all three areas of research.
However, continued research work is required to carry this project through to a fully deployed
suite of products that more comprehensively manage geotechnical products produced by
Caltrans.
The Caltrans geotechnical data model is continually evolving. With every revision of the Soil and
Rock Logging, Classification, and Presentation Manual, or adoption of new practices, standards,
or policies, the data model requires revision. This, in turn, has implications for the various data
management systems that are built from the fundamental data model, including data collection,
exchange, and dissemination systems. Although this requires considerable effort, work under
this task has produced methods and tools to make the updating process easier.
A number of pilot data collection tools were developed and evaluated over the course of this task.
Continued work is needed in this area to facilitate alignment of existing and new data collection
tools with the Caltrans data model, while providing data interchange tools to insure that this data
can be captured and curated in data management systems.
The most significant research need at this time, however, is in the area of data exchange and
dissemination. In recent years, Geotechnical Services has been aggressively migrating from a
paper- based organization to a digital- based one. This research task produced a number of tools
that are now producing digital data repositories for various functional groups. This year,
Geotechnical Services initiated a contract with a document scanning company to convert more
than 2 million documents, covering more than 30,000 projects, and 80 years of historical data.
This massive effort will produce a collection of digital documents with associated metadata. The
challenge for Caltrans is to provide a system that enables users to easily access these
documents based upon a variety of search criteria. As such, a follow- up task has been proposed
to develop GeoDOG, short for “ Digital Repository of Geotechnical Services.”
5.2 GeoDOG
The primary deliverable of this proposed research project, when completed, is a pilot
geotechnical data management system for Geotechnical Services, that builds off of the work
completed to date in this task. This system will be comprised of the following elements:
• Central data repository on the web that houses digital files for Geotechnical Services as
well as geotechnical data generated through gINT, which includes borehole logs and
laboratory test data.
• Capability for users to search for and download data on the repository using web- based
map interface.
• A streamlined mechanism to pass data digitally between the soils lab,
engineers/ geologists, drafting services, and the data repository.
• Integration with the Department’s document management system.
The test deployment of the pilot data management system will serve as the basis for a Caltrans
Feasibility Study Report ( FSR) for full deployment and ongoing maintenance support.
This research directly supports the 2007 Geotechnical Research Roadmap, under the project
family, “ Geotechnical Data Management.” Specifically, the outcome supported is the
“ demonstration of geotechnical data management technologies through implementation.”
Geotechnical data management research is considered the top priority by the Geotechnical
Technical Advisory Panel ( GTAP). The potential benefits to GS and the Department are
substantial. For example, the recently deployed soils lab touchscreen system has resulted in an
estimated 20% reduction in staff time associated with data entry and report preparation.
The scope of work for the project will consist of the following activities:
Task Description
A Finalize the Caltrans Geotechnical Data Model
• Work with Geotechnical Services team to revise the Soil & Rock Logging,
Classification, and Presentation Manual, as needed.
• Translate the standards from the manual into a geotechnical data dictionary, with
elements to comprehensively describe Caltrans soil and rock logging and testing
practices.
B Facilitate the deployment and implementation geotechnical software within
Geotechnical Services
• Work with Geotechnical Services team to coordinate the statewide deployment of
gINT software.
• Develop a Caltrans GS specific gINT configuration based upon the data model
resulting from Task A.
• Develop a suite of standardized geotechnical products that can be easily
produced in gINT ( e. g. boring records, subsurface profiles and fences, laboratory
test summaries).
• Assist GS with training in use of the Caltrans GS specific gINT configuration.
C Develop pilot web application for document and data management
• Work with Geotechnical Services to develop system specifications document.
• Develop pilot web application:
o User account management
o Upload/ download documents/ data
o Search interface with interactive map
• Assist GS in establishing contract for statewide legacy document scanning.
Define metadata standards and requirements consistent with Caltrans
geotechnical data model from Task A. Facilitate import of files into system.
D Geotechnical Lab Data Management System ( GLDMS)
• Fix UI issues identified during prior evaluation period.
• Implement admin tool to extract summary of results into gINT compatible import
file.
E Data Transfer Tools and Processes
• Develop procedure and accompanying tool to transfer Geotechnical Laboratory
data to geoprofessional client using gINT.
• Develop procedure and accompanying tool to transfer insitu testing data to
geoprofessional client using gINT.
• Develop procedure and accompanying tool to transfer gINT generated LOTB
graphics from geoprofessional client to Drafting Services.
F Develop tools and processes for drafting geotechnical products for contract
documents
• Develop an import tool to get gINT generated borings and CPT into MicroStation
at proper scale, lineweight, levels, etc.
• Minimize time for drafters to assemble final LOTB.
• Minimize/ eliminate need for redline process.
G Deployment and Implementation Support
• Assist GS in preparation of FSR and supporting documents to implement tools
into production.
• Procure hardware for initial systems deployment.
Appendix A – GLDMS Documentation
State of California
Department of Transportation
Division of Research and Innovation
The Geotechnical Laboratory
Data Management System
( GLDMS)
August 13, 2007
© 2007 Department of Transportation
ii
Preface
This manual serves as a technical reference and maintenance guide for the
Geotechnical Laboratory Data Management System ( GLDMS). It discusses
installation, setup, and maintenance instructions for system administrators. It also
includes detailed information regarding troubleshooting, which will support future
development of the system.
Acknoledgements
The GLDMS Development Team would like to acknowledge the staff in the Caltrans
Geotechnical Laboratory for their feedback and testing during the early development
stages. The team also extends its appreciation to the management in Geotechnical
Services and the Division of Research & Innovation for their support of this effort.
The GLDMS Development Team:
• Toru Saito, System Developer
• Loren Turner, Project Manager
• Craig Hannenian, Customer Representative
iii
Table of Contents
Preface................................................................................................................. ii
Acknoledgements............................................................................................... ii
Table of Contents............................................................................................... iii
1 Introduction.................................................................................................. 1
1.1 Overview .................................................................................................... 1
1.2 Background................................................................................................ 2
1.3 Scope of Work............................................................................................ 4
1.4 Benefits ...................................................................................................... 5
1.5 Main Features ............................................................................................ 7
2 System Architecture.................................................................................. 12
2.1 Overview .................................................................................................. 12
2.2 Server ...................................................................................................... 13
2.3 Client........................................................................................................ 14
2.4 Network.................................................................................................... 15
3 Soil Testing Procedure with GLDMS........................................................ 17
3.1 Request Entry ( Step 2)............................................................................. 18
3.2 Test Entry ( Step 3) ................................................................................... 19
3.3 Test Approval ( Step 4) ............................................................................. 20
3.4 Report generation ( Step 4)....................................................................... 21
4 Laboratory Web Site.................................................................................. 22
4.1 Overview of Navigation ............................................................................ 22
4.2 Main Menu Web Page.............................................................................. 23
4.3 Test Listing Web Page ............................................................................. 24
4.4 Data Entry Web Page .............................................................................. 25
4.5 Remark Pop- Up Window.......................................................................... 26
4.6 Active Tests Web Page............................................................................ 27
4.7 Navigation of Moisture Content Test ........................................................ 28
4.8 Navigation of Unit Weight Test................................................................. 29
4.9 Navigation of Atterberg Limits Test .......................................................... 30
4.10 Navigation of Specific Gravity Test .......................................................... 32
4.11 Navigation of Mechanical Analysis Test................................................... 33
4.12 Navigation of Point Load Test .................................................................. 34
4.13 Navigation of Compaction Curve Test...................................................... 36
4.14 Navigation of Expansion Index Test......................................................... 38
5 Administrative Web Site............................................................................ 40
iv
5.1 Overview of User Groups and Privileges ................................................. 41
5.2 Navigation of Main Categories ................................................................. 42
5.3 Navigation of Test Management .............................................................. 43
5.4 Navigation of Project Management .......................................................... 44
5.5 Navigation of Production Management .................................................... 45
5.6 Navigation of Database Management ...................................................... 46
6 System Implementation............................................................................. 47
6.1 Technologies and Applications Used in GLDMS...................................... 47
6.2 Generating Pages for Touch Screen Users.............................................. 50
6.3 Generating Pages for Desktop PC Users................................................. 52
6.4 Automated Scale Reading........................................................................ 53
6.5 Touch Screen Keypad System................................................................. 54
Appendix A — File and Directory Structure
Appendix B — Formulas
Appendix C — GLDMS Backup System
Appendix D — GLDMS Installation and Setup
Appendix E — Database Structure
Appendix F — Data Dictionary
Geotechnical Laboratory Data Management System, Section 1 1
1 Introduction
1.1 Overview
The Geotechnical Laboratory Data Management System ( GLDMS) is the result of a
year- long research effort to modernize soil test data collection and management
practices at the Geotechnical Laboratory.
The system is comprised of a network of touch screen stations installed throughout
the lab facility that enable technicians to enter and retrieve test data while conducting
their work. A single web server is at the hub of the system and provides data storage,
processing, and validation. ( See Figure 1- 1.)
The GLDMS architecture was designed to store test data in a central database.
Having a central repository eliminates many of the redundancies in data collection
and analysis, and makes the data much more accessible to end users.
Server
Office PC Lab Touch Screen
Figure 1- 1 – Overview of the GLDMS
Geotechnical Laboratory Data Management System, Section 1 2
1.2 Background
The Caltrans Geotechnical Laboratory is an AASHTO Materials Reference
Laboratory ( AMRL) accredited facility located in Sacramento, California. The
Geotechnical Laboratory provides a wide variety of soil and rock testing services for
various Caltrans units throughout the state. Annually, the lab processes
approximately 90 job requests, consisting of an estimated 5000 samples and 10,000
soil and rock tests. The Geotechnical Laboratory has the equipment and capacity to
carry out 24 types of soil and rock tests. ( See Figure 1- 4, next page.)
Prior to the development of the GLDMS, technicians
recorded data manually on paper- based forms during
testing. The data was then entered into Excel
spreadsheets and used to prepare printed reports and
charts for review by lab managers. Reports were then
printed for clients and the paper archived for storage
in the fileroom. This cycle of data collection and
reporting involved redundant data entry, difficult
retrieval of archived data, and possibly introduced
transcription errors.
Within the lab, paper- based data entry also created
redundancies. For example, in the past, a technician
would have to manually search for moisture data in a
binder of past moisture measurements ( the “ Moisture
Book”) in order to proceed with a related test such as
Plasticity Index testing. The GLDMS has eliminated
the need to cross reference test results, since the tests are cross- referenced within the
GLDMS database. As such, technicians are able to perform Plasticity Index tests
without using the Moisture Book or other redundant procedures.
Figure 1- 2
The Moisture Book
Figure 1- 3
Performing tests using GLDMS
Geotechnical Laboratory Data Management System, Section 1 3
Figure 1- 4 – Common tests performed by the Geotechnical Laboratory
Laboratory Tests
Atterberg Limits ( AASHTO T 89, AASHTO T 90)
Cation Exchange ( EPA 9081)
Chlorides ( CTM 422)
Collapse Potential ( ASTM D 5333)
Consolidation ( ASTM D 2435)
Corrosion ( CTM 643)
Direct Shear ( ASTM D 3080)
Expansion Index ( ASTM D4829)
Mechanical Analysis ( ASTM D 422)
Moisture Content ( AASHTO T 265, ASTM D 2216)
Organic Content
Permeability ( CTM 220)
PH
Point Load ( ASTM 5731)
Relative Compaction ( CTM 216)
R- Value ( CTM 301, AASHTO T190)
Sand Equivalent ( CTM 217, AASHTO T176)
Shrinkage Limit ( ASTM D427)
Specific Gravity ( AASHTO T 100)
Sulfates ( CTM 417)
Swell Potential ( ASTM D 4546)
Triaxial CU ( 3 points) ( ASTM D 4767,)
Triaxial UU ( 1 point) ( ASTM D 2850)
Unconfined Compression ( ASTM D 2166, ASTM D 2938)
Unit weight ( ASTM D 4767)
Geotechnical Laboratory Data Management System, Section 1 4
1.3 Scope of Work
The GLDMS development effort was planned as a two phase approach. The first
phase would involve development of the interface and data models to support the
common index property tests. In most cases, index property testing to date has
required manual data collection by technicians. Phase 2 would integrate the
remaining tests, in particular, the tests where standalone data acquisition units
produced digital test files.
1.3.1 Phase 1
The following eight tests are handled by the GLDMS as part of Phase 1.
• Moisture Content
• Unit Weight
• Specific Gravity
• Atterberg Limits
• Mechanical Analysis
• Point Load Index
• Compaction Curve
• Expansion Index
1.3.2 Phase 2
Phase 2 will focus on capturing data generated by the following test equipment:
• Direct Shear ( ASTM D 3080)
• Consolidation ( ASTM D 2435)
• Triaxial CU ( 3 points) ( ASTM D 4767,)
• Triaxial UU ( 1 point) ( ASTM D 2850)
• Unconfined Compression ( ASTM D 2166, ASTM D 2938)
In addition the GLDMS will accommodate test results associated with the remaining
tests.
Geotechnical Laboratory Data Management System, Section 1 5
1.4 Benefits
The GLDMS provides three key benefits:
• Improves efficiencies in collecting and processing test data,
• Reduces errors in data handling, and
• Facilitates easy access to archived test data
1.4.1 Improved Efficiencies
By implementing the GLDMS, the processes of collecting and analyzing test data
have become more efficient. In the past, the processes of recording, processing,
validating, and reporting test data were handled by utilizing printed forms and
several different computer applications, including Microsoft Excel and FileMaker
Pro. Since the test data were stored in incompatible file formats and mediums,
technicians would have to find and re- enter the same test data repeatedly during each
process, from initial collection to final reporting.
For example, a soil sample test may require a technician to determine the moisture
content as part of a mechanical analysis report. Before the GLDMS was
implemented, the technician had to search through handwritten data entries to find
the moisture content associated with the mechanical analysis. Whereas in the
GLDMS, data collection and retrieval process is streamlined, so when the technician
enters moisture content data, the newly entered data is automatically associated with
soil sample’s mechanical analysis test.
1.4.2 Reduced Errors
To increase the reliability of test results, the GLDMS reduces calculation errors by:
• Eliminating duplicative data entries.
• Automating and centralizing the calculation of test result parameters.
• Enforcing data validation at the time of data entry. ( e. g. A user enters 10.8 for
the wet+ tare weight field but then enters 15.5 for the tare weight field. Since
the wet+ tare weight value must be larger than tare weight value, there is
clearly a data entry error. The GLDMS can identify these types of input
errors, send notification of the error, and prevent further data entry until the
data is corrected.)
• Storing all test data for a particular sample in a central database that makes
test data available for other tests. ( e. g. The results from a moisture content
test for a sample can be used in the calculations for a unit weight test or a
mechanical analysis test on the same sample automatically.)
• Performing necessary calculations as test data gets entered.
1.4.3 Easy Access to Archived Data
With data archived on paper, it has been difficult to locate old test results that match
a particular set of criteria. Using the GLDMS, old test records can be retrieved
Geotechnical Laboratory Data Management System, Section 1 6
easily and quickly. For example, a user may need to retrieve a set of test records that
were conducted on soil samples from District 04 during the period between February
2006 and March 2006. The GLDMS can perform the search and return the results
with a few mouse clicks.
Another advantage of the GLDMS is that the test data can be exported for use in
other software applications or data management systems. For example, in the near
future, a standardized data interchange file format for geotechnical data, called Data
Interchange for Geotechnical and Geoenvironmental Specialists ( DIGGS), will be
implemented in many of the commercially available geotechnical software packages,
such as gINT. The GLDMS can be configured to generate DIGGS- formatted files.
These data exchange technologies will decrease the amount of work, not only for the
Geotechnical Laboratory, but also for its clients who further utilize soil test data.
Geotechnical Laboratory Data Management System, Section 1 7
1.5 Main Features
1.5.1 Central Data Management Server
The GLDMS stores and manages lab data in a central data
management server. ( See Figure 1.5). Using client PCs
and touch- screen terminals, users input their lab data
which gets stored on the server. The system is extensible,
and the Geotechnical Laboratory can expand the capacity
of the system as it increases number of terminals in the
future.
1.5.2 Search Functionality
The GLDMS provides search functionality to look up all
available lab data with various criteria. ( See Figure 1.6
below.) The criteria includes common project and job
attributes ( e. g. GL Track No., Dist- EA, Structure, No.,
Boring ID, Sample No., Test Type, Test Status, and
others).
Figure 1- 6 - Search screen
Figure 1- 5
The GLDMS Server
Geotechnical Laboratory Data Management System, Section 1 8
1.5.3 Automated Report Generation
The GLDMS can produce printable test summary reports while performing
necessary calculations automatically. Figure 1- 7 shows samples of printed reports
generated by the GLDMS. These reports include summaries of index properties,
mechanical analysis, atterberg limits, etc.
Figure 1- 7 – Sample reports
Geotechnical Laboratory Data Management System, Section 1 9
1.5.4 Production Report
The GLDMS monitors current testing activities and can generate daily, monthly, and
annual production reports to evaluate the productivity of the lab.
Figure 1- 8 – Productivity report screen
1.5.5 User Management and Security
By maintaining individual user logins, the GLDMS can control users’ access and
keep logs of their activity for future reference.
1.5.6 Web Interface
Commonly used web browsers are used to access the GLDMS. Since most of the
technicians are familiar with web browsers, they can navigate the system easily.
1.5.7 Touch Screen Data Entry
The GLDMS utilizes space- saving touch
screen devices for data entry wherever space
for a conventional keyboard and mouse is
not available.
1.5.8 Automated Scale Reading
At some locations, the touch screen stations
are connected with digital scales and the
measurement reading from the digital scale
is entered into the GLDMS interface
automatically. ( See Figure 1.10 for an
example.)
Figure 1- 9 – Using the touch screen
Geotechnical Laboratory Data Management System, Section 1 10
Figure 1- 10 – Capturing a reading from digital scale
1.5.9 Data Validation
The GLDMS provides a level of data validation to prevent common input errors that
happen during manual data entry, such as decimal point entry errors.
Geotechnical Laboratory Data Management System, Section 1 11
1.5.10 Data Storage and Backup
For increased data integrity and performance, the GLDMS stores lab data on two
separate hard drives. A full backup of the entire database is performed daily on the
server, and a copy of the daily backups is archived on an off- site network hard drive
for data files for the past month.
Figure 1- 11 – Off- site backup hard drive
Geotechnical Laboratory Data Management System, Section 2 12
2 System Architecture
2.1 Overview
The GLDMS is implemented using a client- server architecture in which a central
server provides the logic and execution of programs and remote clients provide the
user interface ( UI). ( See Figure 2- 1.) Client- server architecture is widely employed
on the internet to operate web sites. Take, for example, Yahoo. com. When a user
searches for information using Yahoo’s search engine, Yahoo’s servers perform the
search and return the results to the user’s computer. The user’s web browser ( the
client) communicates with Yahoo’s server and displays the web page. Interactions
with GLDMS follow this exact same architecture, except that the system is
implemented on an intranet, a local network of computers in the lab facility.
Figure 2- 1 – Client- server environment in GLDMS
Server
Client
DBMS
MySQL
Web
Server
Apache
Server- side program
PHP
Laboratory web site for
Touch Screens users
Web Browser
UI Control
JavaScript
Administrative web site
for Desktop PC users
Web Browser
UI Control
JavaScript
Geotechnical Laboratory Data Management System, Section 2 13
2.2 Server
The server software consists of three components:
• Web server
• Database management system ( DBMS)
• Server- side programs
When a user requests to view a web page in a web browser, the browser sends a
message known as a HTTP request to the web server. Once the web server receives
the HTTP request, it runs a special server- side program to handle the request. The
program, in turn, performs a function according to the request. Usually, the program
communicates with the DBMS to extract or insert data that the user specified.
Finally, the program generates a HTML file and sends it to the user’s web browser.
The server software provides various data- entry forms for the user to input lab data.
Once the user submits these forms to the server, the server software stores the data in
the DBMS that resides on the server.
The server’s hardware is described in Figure 2- 2.
Figure 2- 2 – Current hardware and software specifications of the server
Component Specification
Hardware
HPX2000
Pentium IV
RAM 512M
HDD IBM IDE 115G
HDD Segate SETA 300G * 2
Operating System Windows 2000 Professional
Service Pack 4
Web Server Apache HTTP Server 2.0
PHP 5.1.2
DBMS MySQL Server 5.0
Server- side
Programs
Files containing PHP and
HTML code
Geotechnical Laboratory Data Management System, Section 2 14
2.3 Client
The GLDMS provides two different web interfaces:
• A laboratory interface for technicians that conduct the tests and enter data.
• An administrative interface for lab managers and system administrators.
The laboratory interface is specially designed for technicians that enter test data
through a touch screen device. Touch screen devices allow the user to enter test data
without the need for a keyboard or mouse. This facilitates the devices being easily
placed in various lab locations and less susceptible to damage. The laboratory
interface is optimized for the touch screen interface, using large fonts, large buttons,
and removal of unnecessary menu bars and other conventional web browser features.
The administrative interface provides a tool for lab managers and system
administrators to review, revise, approve, and generate test reports for lab data.
Because administrative tasks are typically performed away from the laboratory
environment, the administrative interface is optimized for a typical web browser
interface.
The server- side application generates these two kinds of web interfaces by providing
different set of JavaScript and Cascading Style Sheet ( CSS) files to the user’s
browser software.
New client PCs can be configured to operate on the GLDMS without complex
software installation. Client PCs need only to run Internet Explorer 6 software. New
features can be added to the GLDMS by simply updating software on the server, and
these features become available immediately to the clients.
Typical hardware and software requirements for client PCs are shown below.
Figure 2- 3 – Hardware and software specifications of clients
Component Specification
Typical Client PC
HP X2000
Pentium IV
RAM 256M
HD 40G
Touch screen 3M MicroTouch M150
Operating System Windows 2000 Pro
Service Pack 4.
Web Browser Internet Explorer 6.028
Geotechnical Laboratory Data Management System, Section 2 15
2.4 Network
The GLDMS architecture is based upon an intranet, using Category 5 Ethernet cable
to connect the server and the clients in a star network topology. In a star topology,
all network devices connect to a central node. ( See Figure 2- 5.) In the GLDMS
Intranet, a networking switch acts as the central node and manages all the
communications between clients and the server on the network. ( See Figure 2- 6.)
Figure 2- 4 – Hardware and software specifications of the Intranet
Component Specification
Switch
NETGEAR
ProSafe 48 Port 10/ 100
Stackable Smart Switch + 4
Gigabit Ports
Ethernet Cables Category 5
Figure 2- 5 – Networking switch as the central node
Geotechnical Laboratory Data Management System, Section 2 16
Figure 2- 6 – Physical layout of the Intranet
Legend Description
Server
Existing touch screen
station
Future touch screen
station
Desktop PC
Switch
Network HDD
Ethernet Cable
Geotechnical Laboratory Data Management System, Section 3 17
3 Soil Testing Procedure with GLDMS
The Geotechnical Laboratory conducts soil testing in a series of well- defined steps:
• A client requests tests.
• A supervisor assigns each test to a technician.
• The technicians perform requested tests and calculations.
• The supervisor approves the test results submitted by the technicians.
• The supervisor sends the testing reports to the client.
The GLDMS maintains this work flow by mimicking it within the system, making
the transition between each step transparent to the users. Figure 3- 1 shows the soil
testing procedure and how GLDMS takes part in these steps.
Figure 3- 1 – Soil testing procedure
Step 2: A supervisor enters the
request and assigns tests from
the Administrative web site.
( Request Entry)
Step 1: A client makes
request for soil tests
Step 3: Technicians perform
the requested test from the
laboratory web site.
( Test Entry)
Step 4: The supervisor approves
the tests and generates reports.
( Test Approval & Report
Generation)
Step 5: The client receives the
test report.
The
GLDMS
Geotechnical Laboratory Data Management System, Section 3 18
3.1 Request Entry ( Step 2)
Once a request is received from a client, a supervisor creates a new project in
GLDMS. Using the Add Project page, the supervisor enters information for the new
project.
Figure 3- 2 — ADD PROJECT page
After creating the new project, the supervisor enters information for project samples
while specifying which tests should be performed. Using the Add Sample page, the
supervisor can add as many samples as the project requires.
Figure 3- 3 — ADD SAMPLE page
Sample information fields
Tests information
entries
Geotechnical Laboratory Data Management System, Section 3 19
3.2 Test Entry ( Step 3)
After the project and its samples are successfully added, the technicians start the
testing process in the lab. The technicians utilize touch screen terminals to access the
Requested Tests and navigate to Data Entry pages. ( See Figure 3- 4 and Figure 3- 5.)
Figure 3- 4 — REQUESTED TESTS page for moisture content test
Figure 3- 5 — DATA ENTRY page for a moisture content specimen
Select a specimen on
which test is performed.
Enter the
measured data.
Geotechnical Laboratory Data Management System, Section 3 20
3.3 Test Approval ( Step 4)
After the technician completes the tests, the supervisor reviews and may approve the
test results. Figure 3- 6 shows the Review and Approval page that lists, in this
example, a test being reviewed for mechanical analysis. A detailed test report, as
shown in Figure 3- 7, can be accessed by clicking on Report link.
Figure 3- 6 — REVIEW AND APPROVAL page for mechanical analysis test
Figure 3- 7 — Detailed report of mechanical analysis test
Geotechnical Laboratory Data Management System, Section 3 21
3.4 Report generation ( Step 4)
After all tests for a project are approved, the supervisor generates a test summary
report from the View Project page.
Figure 3- 8 — VIEW PROJECT page
The following is an example of a summary report generated.
Figure 3- 9 — Test summary report
Geotechnical Laboratory Data Management System, Section 4 22
Login Page
Main Menu Page
Test Menu Pages
Moisture Content Test Unit Weight Test Atterberg Limits Test Specific Gravity Test Mechanical Analysis Test
4 Laboratory Web Site
The GLDMS provides a dedicated web site with a
custom designed user interface ( UI) for touch- screen
users. There is no keyboard or mouse at the touch-screen
stations; users navigate and input data using
the screen.
4.1 Overview of Navigation
Figure 4- 2 shows the navigational structure of the
laboratory web site for touch screen users.
Figure 4- 2 – Structure of the laboratory web site
Login Page – Provides a login form where each user logs in with a unique username
and password
Main Menu – Displays tests that users can perform
Test Menu – Displays the particular tests that the user selected in Main Menu
Figure 4- 1 – Touch screen
Geotechnical Laboratory Data Management System, Section 4 23
4.2 Main Menu Web Page
Figure 4- 3 shows the Main Menu web page that consists of menu buttons, a back
button, and a logoff button. Users navigate GLDMS by using these buttons.
Figure 4- 3 – Menu Screen
Menu buttons – Display web page name for performing a different task
Back button – Displays the previous web page or goes up one level in the navigation
Logoff button – Logs the user off
Back button
Logoff button
Menu button
Geotechnical Laboratory Data Management System, Section 4 24
4.3 Test Listing Web Page
The Test Listing web page shows a list of all available tests. Users can choose a test
from here, enter additional data, or review data.
Figure 4- 4 – Test Listing web page
Scroll buttons – Scrolls up/ down the listing, one line at a time
Page up/ down buttons – Scrolls the listing, many lines at a time
Confirm + Exit button – Saves the listed data to the database and closes the screen
Enter Data button – Displays data entry web page for entering a new data
Remark icon – Displays a remark for the record
Scroll Up/ Down
buttons
Page Up/ Page Down
buttons
Remark icon
Confirm + Exit button
Enter Data button
Geotechnical Laboratory Data Management System, Section 4 25
4.4 Data Entry Web Page
The Data Entry screen allows users to enter values for a sample.
Figure 4- 5 – Data Entry web page
Field button – Displays a data input box for data entry
Data field – Allows the user to enter a value
Calculated field – Displays a calculated value based on the user’s input
Numeric Keypad – Simulates a virtual keyboard number pad
Scale button – Activates the automated scale reading functionality
Continue button – Displays the next web page relevant for the test
Remark button – Shows a pop- up window to input remark text
Numeric keypad
Field button
Data field
Calculated field
Continue button
Scale button
Remark button
Geotechnical Laboratory Data Management System, Section 4 26
4.5 Remark Pop- Up Window
The Remark window pops open after the Remark button is clicked. Users can enter a
comment using the virtual keypad provided on the screen.
Figure 4- 6 – Remark window
Alphabet Keypad – Lets user input letters
Numeric Keypad – Lets user input numbers
Remark window – Shows the current remark
Alphabet keypad
Numeric keypad
Remark window
Geotechnical Laboratory Data Management System, Section 4 27
4.6 Active Tests Web Page
The Active Tests web page shows a list of active tests. Users can choose a test from
this list, enter additional data, or review the data.
Figure 4- 7 – Active Test web page
Data field – unlike the Test Listing web page, new values can be entered directly
from within the screen
Data field
Geotechnical Laboratory Data Management System, Section 4 28
4.7 Navigation of Moisture Content Test
After clicking on the Moisture Content Test button located in the Main Menu
web page, the user will access the Moisture Content Menu web page. The user can
go back to the Main Menu by either:
• Clicking on the Back button
• Complete the test by clicking on the Confirm + Exit button
Figure 4- 8 – Navigation of Moisture Content Test
Moisture Content Menu
Requested Tests List
Wet Weight Input
Dry Weight Input
Moisture Content Menu – Shows options to select to start a new test or continue
active tests.
Requested Tests List – Lists available specimens ( parts of a sample on which a
test is performed).
Wet Weight Input – Displays data- entry web page for the selected specimen. Wet
weight and tare weight can be entered.
Dry Weight Input – Lists specimens for which there is already wet weight data. Dry
weight can be entered on the screen.
Geotechnical Laboratory Data Management System, Section 4 29
Unit Weight Menu
Requested Tests List
Diameter & Length Input
Wet Weight Input
for Density
Wet Weight Input
for Moisture Content
4.8 Navigation of Unit Weight Test
After clicking on the Unit Weight Test button located in the Main Menu web
page, the user will access the Unit Weight Menu web page. The user can go back to
the Main Menu by either:
• Clicking on the Back button
• Complete the test by clicking on the Confirm + Exit button
Figure 4- 9 – Navigation of Unit Weight Test
Unit Weight Menu – Starts the Unit
Weight test process
Requested Tests List - Lists available
specimens ( parts of a sample on which a
test is performed).
Diameter & Length Input - Displays data-entry
web page for the selected specimen.
Three different diameter and length values
will be entered.
Wet Weight Input for Density - Wet
weight and tare weight values will be
entered and density value will be
automatically calculated for the specimen.
Wet Weight Input for Moisture Content –
Wet weight and tare weight values will be
entered and moisture content value will be
automatically calculated for the specimen.
Geotechnical Laboratory Data Management System, Section 4 30
Atterberg Limits Test Menu
Requested
Liquid Limit Tests List
Dry Weight Input for
Liquid Limit & Plastic Limit
Number of shocks &
Wet Weight Input
Wet Weight Input
Requested
Plastic Limit Test List
4.9 Navigation of Atterberg Limits Test
After clicking on the Atterberg Limits Test button in the Main Menu web page,
the user will access the Atterberg Limits Test Menu web page. The user can go
back to the Main Menu by either:
• Clicking on the Back button
• Complete the test by clicking on the Confirm + Exit button
Figure 4- 10 – Navigation of Atterberg Limits Test
Atterberg Limits Menu – Starts the Atterberg Limits test process.
Requested Liquid Limit Tests – Lists specimens ( parts of a sample on which a test
is performed) that need liquid limit test performed.
Number of shocks & Wet Weight Input – Displays data- entry web page for the
selected specimen. Container ID, number of shocks and wet weight values will need
to be entered for the selected liquid limit specimen. Values will be entered either
once or three times depending on the test method used.
Geotechnical Laboratory Data Management System, Section 4 31
Requested Plastic Limit Tests - Lists specimens that need plastic limit test
performed.
Wet Weight Input – Displays data- entry web page for the selected specimen.
Container ID and wet weight values can be entered.
Dry Weight Input for Liquid Limit & Plastic Limit – Lists specimens for which the
plastic limit test and liquid limit test have already been performed. Dry weights for
plastic limit test and liquid limit test will need to be entered.
Geotechnical Laboratory Data Management System, Section 4 32
Specific Gravity Test Menu
Requested Tests List
Pycnometer Reading
Input
Pyc.+ Water + Soil Weight &
Temperature Input
4.10 Navigation of Specific Gravity Test
After clicking on the Specific Gravity Test button in the Main Menu web page,
the user will access the Specific Gravity Test Menu web page. The user can go
back to the Main Menu by either:
• Clicking on the Back button
• Complete the test by clicking on the Confirm + Exit button
Figure 4- 11 – Navigation of Specific Gravity Test
Specific Gravity Test Menu – Starts the specific gravity test process.
Requested Tests List – Lists specimens ( parts of a sample on which a test is
performed) that need specific gravity test performed.
Pycnometer Reading – Displays data- entry web page for the selected specimen.
Pycnometer ID, pycnometer and soil weight values will need to be entered for the
selected specimen.
Pyc.+ Water + Soil Weight and Temperature Input – Lists specimens for which
pycnometer readings have already been entered.
Geotechnical Laboratory Data Management System, Section 4 33
4.11 Navigation of Mechanical Analysis Test
After clicking on the Mechanical Analysis Test button in the Main Menu web
page, the user will access the Mechanical Analysis Test Menu web page.
Figure 4- 12 – Navigation of Mechanical Analysis Test
Mechanical Analysis Test Menu
Requested Tests List
Coarse Grading Input
Lot Grouping 1 Hour Input 24 Hour Input Coarse Grading List
Coarse Grading Input
Mechanical Analysis Test Menu – Starts the mechanical analysis test process.
Requested Tests List – Lists specimens ( parts of a sample on which a test is
performed) that need coarse grading value.
Coarse Grading Input – Displays data- entry web page for the selected specimen.
Cumulative retained mass for coarse grading and the name of the person who
performed the coarse grading test.
Lot Grouping – Lists specimens that already have coarse- grading value. On this
screen, MA Lot No., Container ID, and wet weight values can be entered.
1- Hour Input – Lists specimens that are grouped by a MA Lot No. assigned during
Lot Grouping stage. Users should choose a Hydrometer ID for the group, and enter
1- hour temperature reading of each specimen in the group.
24- Hour Input – Lists specimens that have completed 1- hour readings grouped by
MA Lot No. Users will enter 24- hour temperature readings of each specimen in the
group
Fine Grading List – Lists specimens that have completed 24- hour readings and
need fine grading value.
Fine Grading Input – Displays data- entry web page for the selected specimen.
Cumulative retained mass for fine grading will need to be entered.
Geotechnical Laboratory Data Management System, Section 4 34
4.12 Navigation of Point Load Test
After clicking on the Point Load Test button located in the Main Menu web page,
the user will access the Point Load Test Menu web page.
Figure 4- 13 – Navigation of Mechanical Analysis Test
Point Load Test Menu
Point Load Tests List
Initial Inputs
Picture Upload List
Picture Upload
Final Inputs
Geotechnical Laboratory Data Management System, Section 4 35
Point Load Test Menu – Starts the point load test process.
Point Load Tests List – Lists specimens ( parts of a sample on which a test is
performed) that need point load test performed.
Initial Input – Displays data- entry web page for the selected specimen. Using pull
down menus, users can select a shape of the specimen and a load direction.
Depending on the selected shape, users will be asked to fill out additional data fields
After Failure Input – Users can either check the Invalid Test checkbox or enter two
values:
1. Pressure at Failure in psi
2. Final Distance in mm
As these values are being entered, GLDMS will automatically calculate pressure
failure, De ( mm), Is ( psi), and Is( 50) ( psi) values and show them on the right side of
the web page.
Picture Upload List – Lists specimens that completed initial input and after failure
input. Specimens that have icon indicated they have a photo uploaded.
Picture Upload – Users can delete or overwrite existing photo. If no previous photos
exist, users can upload new photo for the selected specimen.
Geotechnical Laboratory Data Management System, Section 4 36
4.13 Navigation of Compaction Curve Test
After clicking on the Compaction Curve Test button in the Main Menu web
page, the user will access the Compaction Curve Test Menu web page.
Figure 4- 14 – Navigation of Compaction Curve Test
Compaction Curve Test Menu
Point Entry List Accept Points List
Specimen Info Input
Points Input
Dry Weight Input
Accept Points
Geotechnical Laboratory Data Management System, Section 4 37
Compaction Curve Test Menu – Starts the compaction curve test process.
Point Entry List – Lists specimens ( parts of a sample on which a test is performed)
of active or requested point- load tests.
Specimen Info Input – If the specimen has not been confirmed, users will need to
provide the following values:
1. Moisture content received from METS
2. Specimen’s weights
3. Soil description
Points Input – For each test point, users enter:
1) Water Adjustment ( g)
2) Tamper Reading
3) Wet + Tare Weight ( g)
4) Tare Weight ( g)
Up to six different test points can be entered.
Accept Points List – Lists specimens from active compaction curve tests. Users
can complete the specimen by accepting the points for it.
Dry Weight Input – Displays data entry form for the points associated with the
selected specimen. Dry weight needs to be entered for each point.
Accept Points – Displays a graph showing the moisture density curve based on the
points. If needed, users can enter the maximum dry density and optimum moisture
manually.
Geotechnical Laboratory Data Management System, Section 4 38
4.14 Navigation of Expansion Index Test
After clicking on the Expansion Index Test button in the Main Menu web page,
the user will access the Expansion Index Test Menu web page.
Figure 4- 15 – Navigation of Expansion Index Test
Requested Tests List
Wet Weight Input
Specimen Input List
Dry Weight Input
Specimen Input
Initial Reading List
Initial Reading
Final Reading List
Final Reading
After Wet Input
After Moisture List
After Dry Input
Expansion Index Test Menu
Expansion Index Test Menu – Starts the expansion index test process.
Requested Test List – Lists specimens that may need wet weight values.
Wet Weight Input – Displays a form asking for the wet + tare weight and tare weight
for the mixed sample for the selected specimen.
Specimen Input List – Lists specimens that have wet weight values. Only
specimens belonging to active expansion index tests will be listed.
Dry Weight Input – Displays a form asking the dry + tare weight for the selected
specimen. The moisture content will be calculated automatically.
Specimen Input – Displays a form requiring soil + mold weight, mold weigh, and
specific gravity. The weight, dry density, saturation, and moisture of the specimen
are calculated automatically. The saturation value has to be in the range of 40- 60 to
continue the test.
Initial Reading List – Lists specimens that completed specimen input process. Only
specimens belonging to active expansion index tests will be listed.
Geotechnical Laboratory Data Management System, Section 4 39
Initial Reading – Displays a form to enter a value from the initial reading. Date and
time of the input is recorded automatically.
Final Reading List- Lists specimens that completed initial reading process. Only
specimens belonging to active expansion index tests will be listed.
Final Reading - Displays a form to enter a value from the final reading. Date and
time of the input is recorded automatically.
After Wet Input – Displays form to enter the wet + tare weight and tare weight for
the specimen after the expansion test.
After Moisture List – Lists specimens that completed final reading process. Only
specimens belonging to active expansion index tests will be listed.
After Dry Input - Displays form to enter the dry weight for the specimen after the
expansion test.
Geotechnical Laboratory Data Management System, Section 5 40
5 Administrative Web Site
The administrative web site is designed to be accessed from typical computers
equipped with keyboard and mouse. It features a user interface designed using
standard web page design conventions. Unlike the laboratory web site, virtual
keypad or navigational buttons are not used; instead, the administrative web site
features printer- friendly views and ability to see a large set of data entries.
Figure 5- 1 – Typical administrative UI screen
Categories tab – Displays different category
Sign- out button – Signs the user out from GLDMS
Printable- Version icon – Displays a printer- friendly version of the web page
Action button – Makes change or removes the record
Navigation Link – Displays a screen that shows more detailed information
Navigation Link
Sign- out Button
Categories Tab
Printable-
Version icon
Action Buttons
Geotechnical Laboratory Data Management System, Section 5 41
5.1 Overview of User Groups and Privileges
After logging in to the GLDMS, users can navigate through the web site using
categories tabs as shown in Figure 4- 1. Unlike the laboratory web site, the
administrative web site provides different contents for different groups of users
according to their privilege.
The GLDMS users are divided into the following groups: staff, supervisor, or
administrator. The privileges for each group assigned as follows:
• Staff – These users can only input new test data and review past data.
• Supervisors – In addition to the staff privileges, supervisors can edit, delete
tests, samples, and project records.
• Administrators – Besides being able to do everything supervisors can do,
administrators can view, edit, and delete records for users, pycnometers, and
hydrometers.
Figure 5- 2 – User Groups and Assigned Privileges
User Group Assigned Privileges Accessible Tabs
Staff Input new test data
Review old data Test Management
Supervisors
Input new test data
Review old data
Edit/ Delete tests
Edit/ Delete samples
Edit/ Delete projects
Test Management
Project Management
Production Management
Administrators
Input new test data
Review old data
Edit/ Delete tests
Edit/ Delete samples
Edit/ Delete projects
Edit/ Delete users
Edit/ Delete pycnometers
Edit/ Delete hydrometers
Test Management
Project Management
Production Management
Database Management
Geotechnical Laboratory Data Management System, Section 5 42
5.2 Navigation of Main Categories
The administrative web site has four categories for managing the test data:
1. Test management
2. Project management
3. Production management
4. Database management
These categories are shown as tabs in the web site. ( See Figure 5- 1.) After logging in
to GLDMS, all users can access to the Test Management tab. Supervisors and
administrators have access to the Test Management, Project Management, and
Production Management tabs. Administrators have an additional privilege to the
Database Management tab.
Figure 5- 3 – Navigation of Main Categories
Login Page
Test
Management
Project
Management
Production
Management
Database
Management
Supervisor & Administrator All users Only Administrator Only
Login Page – Provides a login form where each user logs in with a unique username
and password.
Test Management – Lists tests and provides search form to lookup past tests.
Project Management – Lists projects and provides search capability to find past
projects.
Production Management – Provides a form with search criteria and then displays a
production report based on the criteria.
Database Management – Lists database tables and provides buttons to modify
them.
Geotechnical Laboratory Data Management System, Section 5 43
5.3 Navigation of Test Management
Users can access the testing data using the test management web pages. In the test
management category, staff can view and print test records, while supervisors and
administrators can view, print, approve, edit, and delete test records.
Figure 5- 4 – Navigation of Test Management
Mechanical
Analysis
Test View
Atterberg
Limits
Test View
Specific Gravity
Test View
Moisture
Content
Test View
Unit Weight
Test View
Test Search
Test Summary
Action
Print
Action
Search
Action
Approve
Edit
Delete
Print
Action
Approve
Edit
Delete
Print
Action
Approve
Edit
Delete
Print
Action
Approve
Edit
Delete
Print
Action
Approve
Edit
Delete
Print
Point Load
Test View
Compaction
Curve
Test View
Expansion
Index
Test View
Action
Approve
Edit
Delete
Print
Action
Approve
Edit
Delete
Print
Action
Approve
Edit
Delete
Print
Test Search – Provides a search form where users can select criteria for specific
tests.
Test Summary – Lists tests that match the search criteria and displays their
summary. Users can read and print the summaries or go to web pages that have
more detailed test information.
Specific Test Screens – Each test has its own screen that displays detailed
information about the selected tests. Staff can access test results and can print them
out. Supervisors and administrators can approve, edit, and delete the selected tests.
Geotechnical Laboratory Data Management System, Section 5 44
5.4 Navigation of Project Management
Only supervisors and administrators can access the project management category.
They can view, add, edit, and delete projects and associated samples.
Figure 5- 5 – Navigation of Project Management
Project View
Add Project Edit Project Summary Report Sample View
Add Sample Edit Sample
Action
Add
Print
Action
Edit
Print
Action
Print
Action
Delete
Print
Action
Add
Action
Edit
Action
Delete
Project View – Lists available projects and provides action buttons to view, search,
and delete projects from this screen.
Add Project – Displays a form to add a new project.
Edit Project – Displays a form to edit project details.
Summary Report – Lists available soil classification test summary reports. Reports
can be printed and sent to clients.
Sample View – Lists available samples associated with the selected project and
provides action buttons to view, search, and delete samples.
Add Sample– Displays a form to add a new sample and associate it to the project.
Edit Sample – Displays a form to edit selected sample.
Geotechnical Laboratory Data Management System, Section 5 45
5.5 Navigation of Production Management
Supervisors and administrators can monitor the current state of tests for a given
period of time. For example, a supervisor can find out how many tests were
approved for a particular month.
Figure 5- 6 – Navigation of Production Management
Production Search
Daily Report Monthly Report Annual Report Outstanding
Action
Print
Action
Print
Action
Print
Action
Print
Production Search – Provides a search form where users can select criteria for
production reports.
Daily Report – Lists available daily production reports.
Monthly Report – Lists available monthly production reports.
Annual Report – Lists available annual production reports.
Outstanding – Lists available outstanding production reports.
Geotechnical Laboratory Data Management System, Section 5 46
5.6 Navigation of Database Management
Only users with administrator’s privileges can access the database management
screens. Administrators can modify the following database tables: user table,
pycnometer table, hydrometer table, and point load device table. When
administrators make changes to these database tables, the changes reflect to GLDMS
immediately.
Figure 5- 7 – Navigation of Database Management
Database
Management Menu
User View Pycnometer
View
Hydromete
View
Add User Edit User Add
Pycnometer
Edit
Pycnometer
Edit
Hydrometer
Add
Hydrometer
Action
Add
Action
Add
Action
Add
Action
Edit
Action
Edit
Action
Edit
Edit Point
Load Device
Database Management Menu – Lists databases tables that administrators can
manage records.
User View – Displays current listing of user logins.
Add User – Displays a form to add a new user login to GLDMS.
Edit User – Provides a form to edit selected user login information.
Pycnometer View – Lists pycnometers available in GLDMS.
Add Pycnometer – Displays a form to add a new pycnometer to GLDMS.
Edit Pycnometer – Provides a form to edit selected pycnometer details.
Hydrometer View – Lists hydrometers available in GLDMS.
Add Hydrometer – Displays a form to add a new hydrometer to GLDMS.
Edit Hydrometer – Provides a form to edit selected hydrometer details.
Edit Point Load device – Provides a form to edit details of the selected point load
device.
Geotechnical Laboratory Data Management System, Section 6 47
6 System Implementation
6.1 Technologies and Applications Used in GLDMS
Figure 6- 1 – Technologies used in GLDMS
Figure 6- 2 – Applications used in GLDMS
Name Description
Apache HTTP Server 2.0 Web Server
PHP 5.1.2 Server Side Programming Language
PEAR HTML_ Template_ IT
library HTML template management
PEAR Image_ Graph Chart drawing library
PEAR Math_ Matrix Matrix calculation library
MySQL server 5.0 Database Management Server
mysql admin 1.1.9 Database administrative tool
phpMyAdmin 2.8 Database management tool
ActivePerl 5.8 Programming Language used for scale reading
Win32:: API Perl module for Win32 API ( for serial port)
Win32:: SerialPort Perl module for Win32 serial port connection
Win32:: CommPort Perl module for Win32 comm port connection
Name Description
PHP Server- side programming language
PEAR Libraries The PHP extension and application repository
HTML A markup language for web pages.
JavaScript Client- side programming language
Document Object
Model ( DOM)
Object model used in web browsers to display
web pages
Cascading Style Sheet
( CSS)
Simple mechanism to specify the presentation of
HTML documents
Perl Scripting language that was utilized for serial port
communication
Geotechnical Laboratory Data Management System, Section 6 48
6.1.1 PHP
The GLDMS uses PHP programming language to dynamically generate web pages
on the web server. PHP is the most widely used web scripting language to build
database- driven web sites. There are many advantages of using PHP as a server- side
programming language because PHP is:
• Platform independent – PHP can run on many different web servers and
operating system unlike Microsoft’s Active Server Pages technology.
• Widely used – There are plenty of resources available to solve problems.
• Open source – PHP’s open source community of volunteer programmers
continually improve and expand the capabilities of PHP. In addition, PHP is
provided free of charge.
• Fast execution speed – PHP generates web pages faster than any other popular
scripting tools.
6.1.2 PEAR Integrated Templates
To efficiently organize the large PHP code base of the GLDMS, PEAR Integrated
Templates ( PEAR IT) was utilized. PEAR IT can be downloaded from
http:// pear. php. net/ package/ HTML_ Template_ IT. PEAR IT provides a library of
PHP classes to be used to separate the programming logic written in PHP from the
presentation code written in HTML.
With PEAR IT, a web page is generated from one or more HTML template files and
a PHP file. HTML template files do not contain any PHP code. They only contain
HTML presentation code and placeholders for PHP variables. In contrast, PHP files
do not contain any HTML code, and they only contain PHP codes and are linked to
their relevant HTML template files by using PHP’s include statement. PHP code
performs calculations and assigns values to the variable placeholders located in
HTML template files.
By separating PHP code from HTML code, a change in web page appearance can be
made without changing any PHP code. However, quite often a change in appearance
may add/ remove PHP variable placeholders. In that case, the corresponding PHP
code needs to be updated to provide a required value for placeholders.
6.1.3 Dynamic HTML ( JavaScript, CSS, and DOM)
Dynamic HTML ( DHTML) technology is used to create the user interface
functionalities in the GLDMS. DHTML is a combination of a client- side scripting
language JavaScript, the presentation definition language CSS, and DOM. Some of
the functionalities achieved by DHTML are:
• Touch Screen Keypad – implemented in includejs/ common. js file
• Page Up/ Down and Scroll buttons – implemented in includejs/ common. js file
• Input validations – implemented in includejs/ common. js and a JavaScript code
embedded in each HTML template file
Geotechnical Laboratory Data Management System, Section 6 49
6.1.4 MySQL
The GLDMS uses MySQL for the database management system. MySQL is a
relational database system widely used in database- driven web sites. Advantages of
the MySQL are:
• Platform independent
• Open source community – MySQL is provided free of charge
• Reliable – MySQL provides industry proven stability and reliability
6.1.5 Apache HTTP Server
The GLDMS uses Apache HTTP Server for a web server. The primary reason to use
Apache HTTP Server was the limitation of the Internet Information Service ( IIS) on
Windows 2000 Professional that limits concurrent connections to only 10. Apache
web server has more advantages, such as:
• No limitation on concurrent connections
• Platform independent
• Popularity
• Open source community – Apache is provided free of charge
Geotechnical Laboratory Data Management System, Section 6 50
6.2 Generating Pages for Touch Screen Users
A typical web page in the laboratory web site is generated by one PHP file that
includes several other files. The other files may include: two HTML template files,
two JavaScript files and few other PHP files. The following seven files are almost
always included:
• touchscreen. tpl. html – the template file that defines the basic layout of the
laboratory UI.
• common. js – the main JavaScript file to provide client- side functionalities,
such as the touch screen keypads and scroll buttons.
• HTML/ Template/ ITX. php – PEAR Integrated Template classes
• include/ db. php – the database connection code
• include/ sqlCommon. php – the library of SQL functions
• include/ authentication. php – the library of user authentication functions
• include/ common. php – the library of miscellaneous functions
Each web page ( a PHP file) in the laboratory web site must have references to a
HTML template file that defines the main layout for the page and a Javascript file
that defines the client- side logic specific to the page. The references to these files can
be found at the top of the PHP file. For example, maCoarseConfirm. php file has the
following references:
@ template maCoarseConfirm. tpl. html
@ javascript recordConfirm. js
All template files for the web pages reside in the template directory, and all the
JavaScript files reside in includejs directory. Therefore, the actual paths to the files
shown above code snippet are: template/ maCoarseConfirm. tpl. html and
includejs/ recordConfirm. js.
There are additional PHP files may be referenced in a web page. You can find out
these file references by reading the require_ once statements at the beginning of each
web page. For example, maCoarseConfirm. php file has the following files included:
require_ once " HTML/ Template/ ITX. php";
require_ once "../ include/ db. php";
require_ once "../ include/ sqlCommon. php";
require_ once "../ include/ authentication. php";
require_ once "../ include/ common. php";
Figure 6- 3 illustrates the file generation process of maCoarseConfirm. php file.
Geotechnical Laboratory Data Management System, Section 6 51
Figure 6- 3 – Overview of Include Process
maCoarseConfirm. php
Optionally Includes
includejs/ common. js
template/ touchscreen. tpl. html
HTML/ Template/ ITX. php
include/ db. php
include/ sqlCommon. php
include/ authentication. php
/ include/ common. php
includejs/ recordConifrm. js
template/ maCoarseConfirm. tpl. html
Always Includes
Geotechnical Laboratory Data Management System, Section 6 52
6.3 Generating Pages for Desktop PC Users
A typical web page in the administrative web site is generated by one PHP file that
includes several other files. The other files may include: two HTML template files,
two JavaScript files, and a few other PHP files. The following seven files are almost
always included:
• adminTemplate/ admin. tpl. html – the template file that defines the basic layout
of the administrative UI.
• adminIncludejs/ common. js – the main JavaScript file to provide client- side
functionalities such as form input validation.
• HTML/ Template/ ITX. php – PEAR Integrated Template classes
• include/ db. php – the database connection code
• include/ sqlCommon. php – the library of SQL functions
• include/ authentication. php – the library of user authentication functions
• include/ common. php – the library of miscellaneous functions
Like web pages in the laboratory web site, each web page in the administrative web
site must have references to am HTML template file that defines the main layout for
the page and a Javascript file that defines the client- side logic specific to the page.
The references to these files can be found at the top of the PHP file. For example,
adminMCView. php file has the following references:
@ template adminMCView. tpl. html
@ javascript adminMCView. js
All template files for the web pages reside in the adminTemplate directory, and all
the JavaScript files reside in adminIncludejs directory. There are additional PHP files
may be referenced in an web page. You can find out these file references by reading
the require_ once statements at the beginning of each web page.
Geotechnical Laboratory Data Management System, Section 6 53
6.4 Automated Scale Reading
GLDMS provides functionality to automatically take a reading from a scale into a
data entry form field. This functionality cannot be implemented on the web server
because server- side programs are prevented from accessing a local resource ( like a
COM port) on a client computer. A digital scale is connected to a client computer;
hence, it is a client resource. To overcome this technical limitation, a custom
designed Perl program that acts as a small server is installed on a client computer.
This Perl program captures a reading from a scale and passes the reading to a data
entry form.
The following components were needed to implement this functionality:
• Data entry form – a web page displaying a form that needs a reading from a
scale.
• Scale reading client program– a JavaScript script that sends a request to the
Perl program.
• Perl server program – a server program running on the local computer that
responds to a scale reading request.
• Scale – a scale that has serial port connector.
Figure 6- 4 – Automated Scale Reading Process
1. A user clicks the Scale button on a data entry form to initiate the scale reading client
program.
2. The scale reading client program sends an HTTP request to the Perl server program.
3. The Perl server program sends a command to the scale through a serial port connection.
4. The scale returns the reading to the Perl server program.
5. The Perl server program sends an HTTP response containing the reading to the client.
6. The scale reading client program dynamically inserts the reading to the data entry form
by changing the corresponding DOM element.
21.33
Data entry form
21.33
Scale
Perl
Server
Program
JavaScript
Scale Reading
Client Program
5
4
1 6
2 3
Scale
Geotechnical Laboratory Data Management System, Se