geotechnical data management system · odot uses a large amount of drilling and laboratory test...

Geotechnical Data Management System

Assessment Report

Table of Contents

1.0 Introduction ...................................................................................................... 1

2.0 Executive Summary........................................................................................... 3

2.1. Conditions for the GDMS ........................................................................................ 3

2.2. Benefits ................................................................................................................ 4

2.3. Business Processes and Impacts............................................................................. 5

2.4. Software Evaluation and Recommendation.............................................................. 6

2.5. Conceptual Design and Requirements ..................................................................... 6

3.0 Current Conditions............................................................................................. 7

3.1. Existing Geotechnical Data Processes...................................................................... 7

3.2. Historical Archives ................................................................................................11

4.0 System Use ...................................................................................................... 13

4.1. Functions .............................................................................................................13

4.2. Components.........................................................................................................16

4.3. User Community...................................................................................................17

5.0 Conditions Needed to Support GDMS.............................................................. 20

5.1. Data Standardization ............................................................................................20

5.2. Data Collection .....................................................................................................20

5.3. Data Referencing..................................................................................................22

5.4. Database Model and Design ..................................................................................22

5.5. Computing Infrastructure ......................................................................................22

6.0 Benefits............................................................................................................ 24

6.1. Direct Cost Savings...............................................................................................24

6.2. Expanded Capabilities ...........................................................................................26

6.3. Improved Procedures............................................................................................27

Page i


Assessment Report

6.4. Improved Service .................................................................................................27

6.5. Standardization ....................................................................................................28

7.0 Impacts of No Action....................................................................................... 30

7.1. Direct Costs..........................................................................................................30

7.2. Limited Capabilities...............................................................................................31

7.3. Limited Procedures ...............................................................................................31

7.4. Limited Service .....................................................................................................32

7.5. Standardization ....................................................................................................32

8.0 Functional Requirements ................................................................................ 34

9.0 Business Processes for GDMS.......................................................................... 37

9.1. Data Collection .....................................................................................................37

9.2. Data Analysis .......................................................................................................38

9.3. Integration with Other Systems .............................................................................40

10.0 Impact on Current Business Processes ........................................................... 41

10.1. Drilling Operations ................................................................................................41

10.2. Laboratory Analysis...............................................................................................41

10.3. Project Review .....................................................................................................41

10.4. Geohazard Investigation .......................................................................................42

10.5. Historical Research ...............................................................................................42

10.6. Other Offices........................................................................................................43

10.7. Consultants ..........................................................................................................43

11.0 Software Evaluation ........................................................................................ 44

11.1. Software Categories..............................................................................................44

11.2. Software Selection and Support.............................................................................45

Page ii


Assessment Report

11.3. Database Management System..............................................................................45

11.4. GIS Software........................................................................................................46

11.5. Application Software .............................................................................................51

11.6. Image Software....................................................................................................52

12.0 Conceptual Design........................................................................................... 54

12.1. System Vision.......................................................................................................54

12.2. System Architecture..............................................................................................54

12.3. Historical Data......................................................................................................56

12.4. Borings (Operations) Modules................................................................................57

12.5. Geohazards (Inventories) Modules.........................................................................58

12.6. Structures ............................................................................................................58

12.7. Materials ..............................................................................................................59

12.8. Construction.........................................................................................................59

12.9. External Information.............................................................................................59

12.10. Additional Modules................................................................................................59

13.0 Next Steps ....................................................................................................... 60

13.1. Functional Requirements.......................................................................................60

13.2. High-level System Design......................................................................................60

13.3. Detailed Design ....................................................................................................60

13.4. System Development ............................................................................................60

13.5. Training ...............................................................................................................61

13.6. Maintenance.........................................................................................................61

14.0 Appendix – Software Application Evaluation Notes........................................ 62

Page iii


Assessment Report

11..00 IInnttrroodduuccttiioonn

The Ohio Department of Transportation (ODOT) Office of Geotechnical Engineering (OGE) has initiated a project with the purpose of providing a comprehensive data management system for geotechnical data. Geotechnical investigations are routinely required for planning, design, construction support, and emergency response on all ODOT projects involving structures and roadway construction. This process generates an enormous amount of data of significant value to a broad geotechnical engineering and construction community. A Geotechnical Data Management System (GDMS) is needed to provide a centralized hub of information that will incorporate archived data, geologic hazard inventories, ranking matrices, remediation cost, boring logs, laboratory test results, and technical application software. The GDMS is intended for use throughout ODOT as well as by numerous external groups. The GDMS would support the following ODOT and OGE activities: • Construction • Operations and Maintenance • Instrumentation and Monitoring • Geologic Site Management Program • Planning and Research • Operations (drilling, geophysics, and lab testing) • Production • Structures • Pavement • Materials Management. Ultimately, the data management system will provide internal and external customers with access to search, input, and export geotechnical information through a secure geographic information system (GIS) application for planning, design, cost-benefit analysis, data correlations, modeling, and to support monitoring. The GDMS will lead to improved quality and will provide a better decision-making tool. The GDMS project includes the development of this Assessment Report. The primary objectives of this report are to describe the conditions of the GDMS, develop the business case for the system, and to lay out a conceptual design of the system. The conditions of the GDMS include the current ODOT geotechnical business processes, the potential use of the system, and the impacts of the system on processes. The business case describes why the system is needed. The report provides both benefits of the system, and impacts of not proceeding. The conceptual design of the GDMS provides a high-level view of the components and modules of the system. The report also includes a software evaluation of products that could be used within the GDMS. The evaluation attempts to provide the workings of software components and to guide ODOT in selecting implementation pieces. The primary source of information for this report was information gathered from potential users. GeoDecisions conducted on-site interviews with a cross-section of ODOT personnel and

Page 1


Assessment Report

external users. The purpose of the interviews was to solicit users’ expectations, suggestions, applications, and objectives for using geotechnical data. In addition to the on-site interviews, telephone interviews were conducted with a selected set of users that were unable to attend scheduled interviews. GeoDecisions also used its existing knowledge of environmental and geotechnical GIS processes, as well as the knowledge of Gannett Fleming, Inc., GeoDecisions’ parent company. The software evaluation used a combination of research, communication with vendors, existing knowledge of products, and use of products. The report is organized into the following sections: 1.0 Introduction – describes the background of the project and content of the report. 2.0 Executive Summary – briefly summarizes of the report contents, with emphasis on the

major points of the report. 3.0 Current Conditions – describes the current geotechnical business processes within

ODOT. 4.0 System Use – describes the potential functions and users of the GDMS. 5.0 Conditions Needed to Support GDMS – describes the resources required for the adoption

of the GDMS. 6.0 Benefits – Details the direct and indirect benefits of the GDMS. 7.0 Impacts of No Action – Describes the impacts on operations if the GDMS is not

implemented. 8.0 Functional Requirements – Lists users’ system requirements. 9.0 Business Processes for GDMS – describes new or changed business processes to support

the GDMS. 10.0 Impacts on Current Business Processes – describes positive and negative impacts on

GDMS business processes. 11.0 Software Evaluation – Evaluates potential GDMS software components. 12.0 Conceptual Design – Provides a high-level description and design of the GDMS and its

components. 13.0 Appendix A – Software Application Evaluation Notes.

Page 2


Assessment Report

22..00 EExxeeccuuttiivvee SSuummmmaarryy

This Assessment Report is prepared as the culmination of a project to study ODOT geotechnical processes and data, and to determine the business case for a GDMS. The GDMS would serve geotechnical professionals and data users from OGE, District Offices, other units of ODOT, other state agencies, Federal agencies, local government, academia, and private industry. The GDMS would primarily be a Web-based system running from a central database, with specialized applications deployed both through the Web and as desktop applications for individual users. The Report is organized into sections, as described in the Introduction. This Executive Summary provides many of the main points and discussions of the full Report. 2.1. Conditions for the GDMS

The Current Conditions section of the report describes the current business processes and functions concerning geotechnical operations for ODOT. OGE provides policies and procedures documents and guidance. Many other units of ODOT, including District Offices, consultants, and others make use of the policies and procedures as they do their work. OGE is also responsible for project operations activities, and it conducts these operations in conjunction with other ODOT units and consultants. OGE maintains a large amount of historical project data. This information, dating back to the 1920s, is being scanned and converted to electronic images and a database containing a subset of the information. This archive data must currently be searched manually by project investigators, at great expense to both ODOT and consultants. The GDMS will make this archive available for Web-based search and query. ODOT uses a large amount of drilling and laboratory test data for project work. Consultants collect 80 percent of this data (ODOT collects the remainder); the consultant data is not centrally collected and used. The GDMS will establish policies, procedures, a database, and application programs to collect this data and make it accessible to all potential users. ODOT also inventories, monitors, and provides remediation for geohazards (mine subsidence, landslides, rockfalls, etc.). The geohazard component of the GDMS would be used to: • Predict geohazard problems • Establish a priority for remediation • Provide monitoring • Avoid these areas, if possible, during design, or manage them during construction • Develop geohazard remediation procedures for existing sites. Other geotechnical activities of OGE will be met by the GDMS, as will needs of other units. Groups such as Structures, Materials, and Planning will all use the GDMS to enter data, review data, conduct analyses and comparisons, and improve their efficiencies.

Page 3


Assessment Report

OGE has been working towards the GDMS for quite some time. Users of the system have been identified, as have functions and components. Section 4.0, System Use, describes how the GDMS would be structured and used. It must be emphasized that the GDMS is envisioned and designed to not only meet the geotechnical needs of all units within ODOT, but to be used by all of the geotechnical community throughout Ohio and surrounding areas. 2.2. Benefits

This Assessment Report documents both direct and indirect benefits of the GDMS. The direct benefits come in the form of identifiable project and operations cost savings. The indirect benefits come in the form of expanded capabilities, improved procedures, improved service, and standardization of processes. The GDMS will reduce the need for and number of test drillings. It is estimated that ODOT will directly save 10 to 20 percent on geotechnical costs in projects with implementation of the GDMS. This reflects savings in both consultant operations as well as OGE operations. These savings would largely be due to having additional information available for online searching in project planning activities. The number of drilling samples in an area would be reduced, resulting in savings in field time, materials used, and analysis of samples. The GDMS will also provide direct benefits in geohazard remediation activities. Currently, high maintenance costs are accrued in re-opening roads that have been closed by landslides, subsidence, etc. The GDMS will allow a proactive approach to be taken in geohazard instances. The GDMS will allow faster identification of problems, ratings of the hazards, and development of remediation strategy. Remediation of the problem will reduce costs in maintenance time and materials required for repeated patching of problem sites. State and federal agencies and local governments will also directly benefit from use of the GDMS. The Ohio Department of Natural Resources (ODNR) estimates that they will save 320 hours of staff time per month once they are able to use the GDMS for what are now manual and time-consuming searches for information. The ODNR geologic mapping program for the state will be improved. The Army Corps of Engineers will be able to save costs on its projects by referring to pertinent data in the GDMS. Local governments will experience the same degree of project cost savings that ODOT does, as the consultants that do work for local government will be able to save time on their project research and drilling efforts. Agencies such as ODNR, OEPA, and the Corps of Engineers will participate in the GDMS in a bidirectional mode; they will be able to access GDMS information, and will also supply their own data to the system. Indirect benefits will be numerous. ODOT will be able to take advantage of increased capabilities in operations, analysis, and modeling. Procedures for project planning and review will be improved, and tighter estimates made of project costs. Service for customers inside and outside of ODOT will be improved as they are able to take advantage of the GDMS. Finally, standardization will promote consistency in operations and analysis throughout the state.

Page 4


Assessment Report

Impacts of not implementing the GDMS are discussed in Section 7.0. A large direct potential impact is the value of the existing historical project data. This data is in paper form only, and there are no copies or archives of the data. If some of this project material is lost, it is gone forever. It is estimated that it would cost $20,000 to $25,000 to re-create this material for one project; there are approximately 21,000 projects in the archive. This represents a total value of about $500 million. Some of this data has been electronically scanned, which provides a digital backup of the material. The remaining material represents a large potential loss without completion of the electronic conversion. Additional impacts include the future costs of not implementing an electronic data capture process. Data captured and managed in an efficient manner would lead to additional data resources available for ODOT as well as other state agencies, federal agencies, local government, and private industry. There would also be increased opportunities for new or more advanced analysis of geotechnical data, providing better data for planning and remediation activities. 2.3. Business Processes and Impacts

Implementation of the GDMS will entail changes in business processes for many users and data suppliers. These process changes are described herein and are noted as to whether the change has a positive or negative overall effect. The biggest process change is likely to occur in the various data collection activities. ODOT has not implemented any widespread electronic data collection efforts, and these will be necessary for the GDMS to succeed. Field data collection may have to occur for processes like sample drilling and geohazard inventory. The use of handheld (PDA) or notebook computers with global positions system (GPS) and specialized data collection software should be investigated. Accurate elevation data is also needed for sites. While the process change for these activities will be significant, the impact will be positive as data collection proceeds. Other process changes will occur in analysis activities. The accessibility of data, and a wider variety of data, will lead to more thorough reviews of projects. Laboratory analysis activities will have few process changes. The tools that are used in the laboratory – for database management, log generation, etc. – will likely change, but operating steps involved will not. A Laboratory Information Management System (LIMS) could be implemented to coordinate data collection, analysis, and management activities. The LIMS would serve as a data repository and staging system. Additional change will occur with integration with other ODOT systems. Information that is contained in other systems or databases, such as Construction or Maintenance, will need to be integrated with the GDMS. This integration could occur as data replication or data linkages between systems.

Page 5


Assessment Report

2.4. Software Evaluation and Recommendation

A software evaluation was performed as part of the project. The intent was to evaluate software used for geotechnical applications, but was expanded to include many software components of the GDMS. This section includes discussion and recommendations for each component. The recommendations are: • Oracle as the database management system using Oracle Spatial for management of GIS

data. • The Environmental Systems Research Institute (ESRI) suite of GIS software for Web and

desktop GIS use. This includes the ArcIMS Web server, ArcSDE database management, and ArcGIS desktop (user PC) software. The ESRI products were compared to those from Intergraph.

• Application programs should include the gINT application suite for visualization and analysis, and the EQuIS product for data management and analysis. Products from RockWare are also recommended for use in specific applications. These products were chosen from a larger review set.

• Image viewing software will be required for the system. The Falcon suite of tools from the TsaADVET document management program would be used in certain applications, particularly where interaction with document images is required. The Web portal and tools can use programmed image viewers to supplement Falcon to take advantage of native image viewing routines in Web software.

2.5. Conceptua Design and Requirements l

Some functional requirements for the GDMS are listed in section 8.0. These requirements were voiced during the interview and survey process, and serve as a starting point for a more exhaustive and necessary system requirements gathering phase. The future system requirements phase should include more detailed and more numerous interviews of potential stakeholders of the system. The stakeholders include data suppliers and data users from participating agencies and groups. The interviews should focus on the information, functions, and interfaces that users want to see in the GDMS. The last section of the report provides a high-level conceptual design of the system. This design attempts to describe the major components of the GDMS and how they will work and interact. The design serves as an illustration of the overall system.

Page 6


Assessment Report

33..00 CCuurrrreenntt CCoonnddiittiioonnss

Geotechnical tasks in ODOT are managed or supported by many different groups, at both the Central Office and in the Districts. OGE serves as the primary geotechnical resource; it sets policy and procedures for work by other entities, and serves as a project resource for data collection, analysis, and geotechnical management. Project work currently takes precedence for OGE, but the section would like to focus on policy issues. The Design Resources Section is responsible for oversight of the geotechnical aspects of ODOT projects. The Section reviews work performed by Consultants and the Districts, and also performs in-house designs related to earthwork treatments, retaining walls, reinforced slopes, landslides, rockfall, and mine subsidence. When required, analyses of embankment stability and settlement are performed, and a field instrumentation program might be recommended. The Section makes itself available to support projects that have extraordinary geotechnical features during construction. The Section’s activities include specification development for the performance of subsurface investigations, as well as construction specifications, plan notes, and proposal notes related to earthwork and geotechnical engineering. The Section has been active in the development of the Abandoned Underground Mine and Risk Assessment (AUMIRA) Manual and provides support to the Districts for its implementation. The Geotechnical Operations Section consists of three areas: the drilling crews, the laboratory, and the draftsmen. The drilling crews explore the subsurface of proposed and existing ODOT roads and projects. They also install and monitor slope inclinometers in several of Ohio's geologically volatile areas. This information is vital in the design, construction, and maintenance of Ohio's roads. The laboratory tests the samples collected by the drilling crews. This material is tested and classified using the Construction and Material Specifications Manual. Finally, the draftsmen produce plan and profile sheets to be used in construction plans. They also maintain a library of the subsurface investigations for reference for future projects. ODOT decentralization has pushed much of the work to the Districts, including geotechnical work. OGE has set up procedures (e.g., QAR, Checklist, SSI) for Districts for data collection and similar tasks to help coordinate operations and promote standardization. The policies and procedures that OGE sets up must be detailed enough to establish methodology but also reasonable to all concerned so that they are actually implemented. 3.1. Existing Geotechnical Data Processes

The primary geotechnical processes involve boring data operations and geohazards. Each is described in more detail below. ODOT maintains an historical data archive; this is also described below. OGE staff use a variety of information sources for project review purposes. These include historical data, new borings and borings results, soil surveys, water well records, oil and gas well records, EPA records, abandoned underground mine maps, wetland maps, landslide maps,

Page 7


Assessment Report

and ODNR geologic maps. As-built drawings, when available, are used to verify boring log information; where rock was encountered in construction is compared to the logs. Various software products are in use for geotechnical work. MicroStation is used to compile, display, and interpret boring log data. Other CAD files (primarily AutoCAD) are generated by consultants for their reports, though the majority of consultant reports are delivered as hard copy. The section has evaluated products like gINT and RockWorks to facilitate investigations and analysis. The District Offices employ varying methods of managing data, though the methods are mostly similar. Much of the geotechnical material collected at the Districts is not sent to the Central Office. Boring logs from consultants are only maintained at the Districts and are generally purged after five to seven years to save storage space. A record of the subsurface investigation for a project exists as plan sheets attached to the project plans (e.g., soil profiles, structure foundation investigations). The data at the District offices is very important in terms of potential cost savings on proposed new work, and to gain an increased perspective on the geologic setting. Typically, the soils, geology, and hydrogeology data are not in electronic format and the standardized nomenclature for interpretation is not in place, making the reuse of this information difficult. 3.1.1. Borings

ODOT collects a large amount of boring log data. These borings are done for project investigation, construction, structural, and geohazard work. Approximately 20% of the information is collected by ODOT crews, while 80 percent is collected by consultants. In the past this number was reversed. The 80% of data collected by consultants usually goes directly to the Districts. Currently, ODOT has two drilling crews and is working on getting a third crew. The crews work from, and are managed by, the Central Office. The crews note some site features and prepare field logs with visual description and moisture content. They are focused on the drilling operations. GPS data collection is being tested with GeoExplorer III units. GPS units are used to collect real-world coordinates at the drilling site for each hole. The coordinate values are written on the drilling card. They are also entered into a Paradox database following differential correction. Equipment challenges prevent the GPS unit from being used directly at the drill hole; ways of collecting the exact coordinates are being evaluated. Consultant drilling operations are conducted in a similar manner. Some consultant crews are collecting GPS coordinates, but have found a more automated method for coordinate collection is needed due to limitations in personnel time. The boring samples are brought to the laboratory for testing. Samples data is hand-written on two worksheets. Each sample has notes on visual description and moisture content. Each sample is given a unique ID (the ID numbers repeat about every 12 years). The data is

Page 8


Assessment Report

entered into a Delphi database program. The entire batch for a project is combined in this program. Calculations are then made of the samples. Test results are presented as boring logs and plan/profiles, and plotted using MicroStation and a custom program (BASIC and/or MDL). The MicroStation files are backed up on CD and at the main server. Consultants are also using CAD to generate boring logs; the primary software used is AutoCAD. Most of the consultant drawings do not use real-world coordinates. The information is gathered together in a hard copy file folder. Paper copies of each boring log and/or profiles go to the folder. The folders are organized by county/route/section. The county/route/section referencing system is modified during road realignments or change in route designation, making this data hard to find. OGE has tens of thousands of these hard copy files at any one time. The folders are kept in accessible files for about five years. The files are then moved to the dead storage area. Hard copy folders that are generated for each project include: • Topographic map of the study area • Drilling request letter • Utilities information • Field notes. The current Delphi-based database system has been in place since 1996. Prior to this, a mainframe system was used for data entry and management. This mainframe data is still accessible. However, the data format would have to be decoded to attempt to use this older data. The Delphi-based system includes the following data: • Merged soil samples • Plasticity analysis • Gradation analysis • Water content determination • Visual descriptions of bore samples. Card files are kept for each of the projects. The same information is found on the archive cards. The project level information includes driller identification and location of the hard copy file containing the detailed data, as well as some of the information in the Delphi system. The card information is also entered into the GQL database for the central repository file; there is double entry of data to both the Delphi system and GQL. The project sample data is transferred to the appropriate district office and/or to OGE staff. The OGE staff use the data for their project review activities. A typical larger project review includes a walkthrough of the site to look for mines or other geohazards, and other important features. The reviewer uses boring logs and project plans along with the analysis from the lab to make recommendations on fill activities. Tracking the performance of each type of fill or aggregate over time is being done to a limited extent. This correlation of performance would be enhanced by the GDMS.

Page 9


Assessment Report

Projects have several stages. In stage 1, letters are sent out with recommendations for project activities. Stages 2 and 3 are review periods for recommendations and corrective actions. 3.1.2. Geohazards

Geohazards are problems or conditions that impact the road due to geologic or soil conditions, or related activities. Typical geohazards are landslides (where slope failure damages the road), rockfalls (where rocks from cut slopes, banks, or cliffs fall onto the road), karst areas (where sinkholes develop due to solution activity in the bedrock), organic peat deposits (areas underlain by very weak and highly compressible soils), and mine subsidence (where the road and ground “sinks” into an underground mine cavity). OGE staff is called to inspect and make recommendations on geohazards throughout the state. Staff walk through the site and observe conditions. Site characteristics may be recorded using field photos, site drawings or maps, and notes. GPS coordinates may be recorded. Staff meet with a drilling crew to discuss where samples should be taken. Each drill location adds to expense, but determining the right number of borings to characterize the site requires a comprehensive understanding of the available information. All information about the site is maintained in a hard copy file folder. The site location is referenced using the county/route/section LRS. Consultant reports may be prepared to study slope stability elements. Staff stated it would be helpful to have information about the history of the site, including prior occurrences, maintenance, materials, etc. During the construction phase, information about encountered geohazards, and measures taken to mitigate them, are usually documented. However, much of this documentation takes place as hard copy notes, instead of being entered into the more-accessible electronic construction management “diary”. These notes can contain critical information on methods employed or conditions found at each location. Maintenance activities on geohazard locations take place frequently. Maintenance crews are supposed to record the material type and amount used to correct a problem, as well as the hours used. Unfortunately, this information is not always entered, and it can be difficult to determine how frequently a site presents a problem, and how severe the problem is. Anecdotes indicate that, occasionally, many feet of paving material are placed at a landslide site over time, at considerable expense in time and materials. Many sites are patched repeatedly, without a solution or remediation to the problem being investigated or attempted. These efforts are often done as a quick -ix solution to reopen a road to travel but often lead to additional road failures and closures in time. Districts 10 and 11 have collected and maintain some landslide inventories, but the format and use of their inventories are different from other inventory needs. These District efforts are used mainly for maintenance/location and priority ratings for risk assessment.

Page 10


Assessment Report

The geohazard component of the GDMS would be used to assess, prioritize, and manage potential geohazard problems. Management of the sites would include avoidance or special consideration during design, consideration during construction, remediation of existing sites, and monitoring. 3.2. Historical Archives

ODOT has geotechnical project data dating back to the 1920s. This information is a valuable source for researching conditions around the state, particularly for new project investigations. However, the information is in hard copy only, and there is no backup copy. The existing data archive is used by ODOT staff, consultants, ODNR staff, and others to investigate conditions. Consultants are required to do a prior information investigation for their project work. Currently, all users must travel to the archive site to research the information, which adds to project expense. There is also an opportunity for valuable information to be missed due to the current difficulties in data retrieval. ODOT staff can help users find information, particularly if the user is not familiar with the archive and/or changes that took place in the referencing system over time. Some users will call in to request information, and staff will then look for and retrieve the information, if available. Project reference information is entered on a card file. The card file contains 37 fields of information, which include a reference to the hard copy folder containing the project materials, as well as a project reference number, and a county/route/section LRS reference for the project. However, the county/route/section references change as roads change or are re-numbered, making the LRS reference somewhat problematic for older data. ODOT can usually get hard copy boring logs back to the requesting individual in about a day, depending on priority. The boring log information is relatively easy to find, but information describing found conditions are more difficult to identify and locate. Consultants are currently required to photocopy the originals and are sometimes permitted to take the originals with them. Both methods are cause for concern regarding the original documents, considering their condition and lack of other off-site, secure copies. In general, the information-finding process requires one to two days for two to three people to retrieve, with no current estimate at the proportion of data that might have been missed in the search. OGE has initiated a project to scan all of this information, develop a database of selected project information that is tied to the scans, and provide information viewing tools. The project information and scans will be tied by the standard project number format (example: FRA–270–13.46). It is estimated there are 21,000 project files to be scanned. A pilot conversion study has been started and is estimated to produce 50,000 scans of 24x36 inch plan sheets and 1,500,000 8.5x11 inch records, in compressed TIFF format. A database was established for the project information on the card files. Currently, 18 of the 37 fields are included in the database and available for query. The card is also included in the scanned information, so the full contents of the card can be viewed. Some of the 18 database

Page 11


Assessment Report

fields are considered especially valuable: project type, date, county, route, section, number of boring logs, total feet of boring, number of samples, and comments. The database was originally developed in Microsoft Access but has been migrated to Sybase IQ. Sybase GQL is used to access and query the database. As a precursor to GDMS work, ODOT has been investigating both database and image viewing software. The viewing package currently used has not been readily available or considered user-friendly by ODOT staff. ODOThas been looking into Falcon software to view the scans. Future plans for the conversion project include adding data sheets and plans from the District Offices and consultants. The vision for the GDMS is to capture all future data electronically, eliminate the use of the card files, and use the digital archive for research purposes.

Page 12


Assessment Report

44..00 SSyysstteemm UUssee

OGE has been considering the development of a GDMS for some time. OGE has considered the types of functions the GDMS should include, and the types of users. This information was provided as part of the project and was used in this system assessment. 4.1. Functions

OGE has developed a diagram of a potential GDMS. This diagram is shown below.

The diagram includes both proposed functions and components of the system. The functions are described in this section. System components are also briefly described in this section, with more information included as part of the software evaluation and conceptual design. In addition, a section on consultant activities and their supply and use of information in the GDMS is included.

Page 13


Assessment Report

4.1.1. Inventories

ODOT collects inventory information on multiple geologic features, activities, and geohazards, including karst areas, rockfalls, landslides, and underground mines. This inventory data would be managed within the GDMS, and included in monitoring and research, analysis with software applications, and remediation routines. 4.1.2. Operations

OGE collects and uses a large volume of data as part of its regular operations. Much of this data is collected as part of boring/drilling activities. Consultants collect 80 percent of this data, and OGE collects the other 20 percent. ODOT has two crews that drill sample holes and collect data as part of the drilling effort. The samples are analyzed at the OGE laboratory. Data from these tests are collected on worksheets and databases. The consultant data is analyzed in much the same way. Consultants generally deliver their project results in the form of hard copy drawings and reports. Geophysical studies are also conducted by OGE staff and consultants in support of ODOT projects and other activities. All of this information would be collected into and managed by the GDMS. The data would be available for research by OGE or other entities, and it would be used in analysis routines. 4.1.3. Monitoring

OGE staff and consultants are responsible for ongoing monitoring of conditions for project work, geohazards, remediations, tests, etc. This monitoring activity generates a regular amount of data and reports, all of which would be included in the GDMS. This information would be stored in the database, and the reports or analysis functions and output would be included as part of the GDMS. The information would also be available for research purposes, so that OGE, designers, consultants, and others could compare conditions across multiple sites. This would allow the refinement of monitoring activity over time, and lead to a storehouse of information to use in future project efforts. 4.1.4. Research

OGE research activities are closely linked to monitoring functions. One of the primary functions of the GDMS will be to enable research of information by all users. The research would include querying and viewing the historical information, but would also be extended into all or most of the information managed by the GDMS. The GDMS would include querying functions to allow users to search across the GDMS database, as well as through other information such as reports.

Page 14


Assessment Report

4.1.5. Historical Data

ODOT’s extensive volume of historical geotechnical project information will be included in the GDMS as database and image information. Other historical information, such as aerial photos and site photos, will also be included. 4.1.6. Operations and Maintenance

The GDMS will support ODOT’s ongoing maintenance activities, and these activities will be aided by use of the GDMS. Extensive maintenance work can occur for geohazards like landslides and rockfalls; time and materials costs for these efforts are to be captured in maintenance systems. This information would be available or copied to the GDMS, so that these resources can be tracked. Remediation efforts can be targeted at problem sites. 4.1.7. Construction

Information on geotechnical conditions is vital in project design and construction phases. The GDMS will serve as a repository of information that can be accessed to improve the design process, allowing activities to avoid sensitive areas, or providing for the design to alleviate conditions. Construction records will be passed back to the GDMS so that geotechnical investigations can be compared to actual conditions encountered. Construction activities are also a source of new geohazard inventory information. Geohazards encountered or created during construction work will be identified in the GDMS, and mitigation or monitoring efforts will be entered into or be accessible from the GDMS. 4.1.8. Remediation

OGE and ODOT consultants are tasked with developing remediation plans when adverse geotechnical conditions are discovered. Such conditions can include subsidence, rockfalls, or slips. The GDMS will allow staff and consultants to research similar conditions and the remediation efforts previously used, to discover those efforts that worked well or did not work. This will allow OGE to develop effective remediations for new problems. The Remediation Cost Database will be included as part of the system. This database can be linked to project line item costs for evaluation purposes. 4.1.9. Consultant Activities

The GDMS will encompass ODOT consultant tasks, though these are not specifically identified on the diagram. Some of these tasks have been described in the preceding sections, such as Operations and Monitoring. Consultants collect the vast majority of drilling data, and also perform other geotechnical tasks for ODOT. Much of the functionality of the GDMS will apply to these consultant activities as much as they do to ODOT, OGE, and other agency staff. Consultants can be expected to use the historical data extensively, and it is proposed that the GDMS include a data entry module for consultant-collected data.

Page 15


Assessment Report

Building consultant-themed functions into the GDMS will require extensive meetings and discussions with user groups to identify functional requirements. In addition, some functions may require extra effort and cost on the part of the consultants in the form of additional processing steps or software products. For example, adding a data entry capability to collect consultant data may require the consultants to expend additional time in entering the data. 4.2. Components

The GDMS will be composed of many different components. Some components , such as the central database, will be used by all users and functions, while others may be used by only a very few staff members. The Software Evaluation and Conceptual Design sections of this report describe most of the system components; following are short descriptions of three of the primary components. 4.2.1. Data Management System

A geotechnical information database will be the centerpiece of the GDMS. This database will be hosted on a full-featured database management system (DBMS). The database will host the majority of the system’s data; some information such as scanned drawings may be hosted as files on a file server. The GDMS database would also contain a spatial component, so that the geotechnical GIS information will be stored directly in the database. The GDMS database will serve data to all GDMS applications. It may be connected to other systems, such as maintenance or constructions records, so that data on these other systems may be accessed and used. The GDMS database will require data modeling and database design efforts to make certain of efficient access performance and validity of data. 4.2.2. Web Portal

A Web information portal will be developed as the primary interface to the GDMS. The portal will be available to ODOT staff on the intranet and to other users through the firewall and Internet. The portal should have many options for selecting, querying, and viewing data. It will include a GIS interface to allow users to view data in a map context and to select and query data spatially. The portal may also include analysis functions that can be delivered effectively through the intranet or Internet. The Web portal can also serve as a data entry mechanism for ODOT consultants. Consultants collect the majority of the sample data used by ODOT. This data is typically provided to ODOT in the form of hard copy reports and drawings, while the sample data collected directly by ODOT includes the raw data and analysis results. The GDMS can include data entry applications on the Web which will allow consultants to input their original data along with their reports. This data would be reviewed by ODOT and then loaded into the GDMS database to join the ODOT-collected data, dramatically increasing the amount of data that can be researched and used. This Web-based data entry program would have to be enabled for users outside of the ODOT firewall, with a secure login approach used to verify users.

Page 16


Assessment Report

Capabilities of the Web portal can be expected to increase over time, particularly as the detailed applications needed for geotechnical analysis are ported to the Web. Many of the applications initially included as desktop tools in the GDMS will be able to be implemented as Web-based applications in the future. 4.2.3. Desktop Applications

Many GDMS users will have desktop, or PC-based, applications to work with geotechnical data. The database and Web portal will have the capability for a user to download a selected set of data for analysis at the desk. These types of analyses will usually require the types of routines that are not currently available as Web services or cannot be achieved effectively or efficiently through the Web. These desktop applications will include GIS software for more intensive spatial analysis, or specialized software programs for specific geotechnical or project functions. They can be expected to migrate to, and be implemented as, Web applications when feasible. 4.3. User Community

The GDMS will potentially have a wide variety of users. These users will include ODOT staff, staff within other state agencies, other governmental units, private enterprise, academia, and the public. Each group will have its own particular use of the system, or role, and system functions must likewise be designed with each group in mind. OGE developed a matrix that shows potential users and associated roles for the GDMS. This matrix is adapted and presented in the following tables. The roles are: • Approximate Number of Users – Estimate of number of users within the category after a 10-

year period. Number for public indicates concurrent users. • Administration – GDMS system administration and maintenance. • Data Entry – Collection of GDMS data. • Data Update – Review and updating of data. • Data Delete – Deletion of system data. • Isolated Data Entry – Collection and entry of selected portions of data; for example,

consultant data collection. • Isolated Data Update – Review and update of selected portions of data. • Isolated Data Transfer – Download and use of selected data. • Search – Query of data. • View – Display of data, maps, images, etc. • Print – Printing of displayed information. • Report Access – Display of selected system data or archival reports. • Application Use – Access to and use of specialized GDMS functions or applications.

Page 17


Assessment Report

Table 1 shows ODOT users that would access the system through the ODOT intranet (inside the firewall).

Table 1

Capabilities OGE Columbus Office

District Offices

Approximate Number of Users 6 6 24

Administration X

Data Entry X X X

Data Update X X X

Data Delete X

Isolated Data Entry X

Isolated Data Update X

Isolated Data Transfer X

Search X X X

View X X X

Print X X X

Report Access X X X

Application Use X X X

Page 18


Assessment Report

Table 2 shows external users, or those that would be accessing the GDMS through the Internet. External users will have a limited number of system roles.

Table 2

G

eote

chni

cal

Cons

ulta

nts

Oth

er

Cons

ulta

nts

Tow

nshi

ps

Coun

ties

Citie

s

OD

NR

OEP

A

USG

S

USE

PA

FHW

A

Arm

y CO

E

Acad

emia

Publ

ic

Approximate Number of Users 25 6 3 5 5 2 2 1 1 1 1 10 6

Isolated Data Entry X X X

Isolated Data Update X X X

Isolated Data Transfer X X X X X X X X X

Search X X X X X X X X X X X X X

View X X X X X X X X X X X X X

Print X X X X X X X X X X X X X

Report Access X X X X

Application Use X X X X

Page 19


Assessment Report

55..00 CCoonnddiittiioonnss NNeeeeddeedd ttoo SSuuppppoorrtt GGDDMMSS

This section describes the conditions that will be needed for implementation of the GDMS. 5.1. Data Standardization

Data consistency was a common theme in the project interviews. Standardization among terms and measures used for geotechnical information is needed to facilitate proper and wide usage of the information. The GDMS can serve as both an agent for change in developing standardization and for providing education to users. Standardization will require efforts in several areas, as described below: • Methodology – Policies and procedures for data collection. ODOT has methodology in place

through manuals such as the ODOT Specifications for Subsurface Investigations. OGE should establish any policies and procedures needed to support the GDMS, and ODOT needs to adopt them for use by staff and consultants.

• Terminology – Standards for terminology need to be established. Education will then be needed to make certain that geotechnical and GIS terms are clearly understood around the state. A glossary or similar tool could be developed and disseminated through the GDMS. Terminology standards may be initiated through widespread use of a program like gINT, with users following gINT terms and methods.

• Measures – Measurement values and interpretation of measurements also need to be made clear. The number of significant digits and decimal places should be established for data fields. Classification of data value ranges and interpretation of individual values need to be standardized or outlined. This can be accomplished at least partially through the GDMS.

• Database Design – ODOT’s GDMS can be an early implementation of the type of system that can be expected to become more widespread at the state and federal level. The GDMS data model and database design should be constructed with an emphasis on following established data standards and processes. Similar efforts by other organizations (CalTrans, FHWA AGIDS, etc.) should be evaluated to determine applicability to the GDMS.

5.2. Data Collection

In addition to refining data collection policies and procedures for ODOT and consultant operations, new mechanisms can be put in place to enable useful data collection for the GDMS. In addition to the county/route/section LRS, real-world coordinate data collection should be implemented for geotechnical field operations such as drilling, inventories, investigations, etc. GPS could be the primary means of collection, but other methods could be used in locations where GPS is not feasible (such as in heavy tree canopy). Real-world coordinates will provide a tie to other available geographic information that is critical to site investigation. This will require education and procedures documents, as many drillers are still getting used to GPS equipment. OGE should be encouraging or mandating that consultants provide accurate coordinate information for all field operations. Consultants will also need to be required to use

Page 20


Assessment Report

GPS (or other coordinate collection means) as this technology has become a standard utility in geotechnical engineering. Accurate elevation data is also needed for all locations. The elevation value at ground level for drilling holes, geohazards, etc. is desired at the tenth to hundredth foot accuracy level. This information is needed for proper determination of elevation (Z) values of subsurface features, and the resultant analysis and display of those features. Achieving the desired elevation accuracy level is currently not possible with non-survey-grade GPS units. The elevation values must be acquired with surveying equipment and crews or use of survey grade GPS units. This issue may require procedural changes. ODOT should investigate the use of ruggedized handheld (PDA) or notebook computers for future field data collection. These units can be used in conjunction with GPS units to collect pertinent field data for repeatability and completeness. Very simple-to-use user interface applications would be required for the operators to enter information and make certain that it is correct. The data could then be uploaded to the GDMS database. For example, the drillers could enter basic project and sample data, the visual sample information that they currently collect, and information such as where water or boulders are encountered and other distinctive field conditions. Dropdown data choices (based on the drilling data dictionary) and standard radio button selections will help to make certain of data integrity. The ability to capture the data electronically one time (and by the persons who actually capture the information) will help to eliminate transposing errors. Many processes within ODOT need to be evaluated to determine if procedural changes are warranted. For instance, information about geohazard management during construction should be noted electronically in the construction management diary. This information can then be extracted from the Construction Management System (CMS) to the GDMS. Another example of procedural change is with maintenance information. Information on geohazard maintenance activities should be consistently documented in either the GDMS or the maintenance management system. The documentation should include at a minimum: conditions found, maintenance action used, material type, material amount, date, and resources used (number of hours). If the information is entered into a maintenance system, an extraction process should be developed to copy the information to the GDMS. As described for the Web portal, the GDMS should provide means for direct consultant data entry. ODOT would benefit from the timely electronic entry of the original data that consultants collect, in addition to their current submittals. This data would include their drilling sample information as well as data collected for all other geotechnical operations. The system should provide a secure Web-based interface through which consultants can enter their data, then allow the data to be checked by ODOT staff and then be loaded into the GDMS database. This will require significant system requirements discussions with the consultant community, and the development of additional policies and procedures.

Page 21


Assessment Report

5.3. Data Referencing

Field operations (such as individual boring locations or other project activities) should be referenced to accurate ground coordinates (State Plane, North/South Zone). Geotechnical data will also continue to be referenced to the ODOT LRS (county, route, section, station and offset) to facilitate use of the data with historic and existing ODOTprocesses and operations. The ground coordinates will be required for use in many of the planned software programs or routines, which will not recognize an LRS reference. Groups of boring locations, or similar data, may be grouped together or remain independent with a single State Plane coordinate reference and county, route, section reference for ease of project data management. However, individual coordinate values should always be maintained with the data. Filter programs to convert data between county, route, section station and offset and ground coordinates will need to be developed, if they are not already available within ODOT. Ideally, these programs would also properly handle the conversion given changes in the route referencing over time (road re-numbering or re-alignment that causes the LRS reference to be out of place). 5.4. Database Model and Design

One of the primary components of the GDMS will be a central DBMS to manage and serve a large part of the data. This database would house information currently residing in other databases (historical archive, Delphi lab system) as well as new information. The GDMS will require both a high-level data modeling effort (for both project and analysis data) as well as a more detailed database design effort. The data model will describe groups or classes of data, how data will interact or relate together, how data will get to the database, and how applications will use the data. The database design is required for the construction of the data tables. The design should include information on table field structures and names, allowable data value ranges for fields, null values, minimum data entry fields, etc. It is important that the database design define the structure of data, and also define where data flexibility is desired. This flexibility must be accommodated before final data table construction. 5.5. Computing Infrastructure

ODOT has plans for a complete migration of all desktop computers to an operating system standard of Windows 2000 or XP. This will be necessary for many of the software components of the GDMS, and the migration must be completed before the GDMS can be fully operational. The GDMS will require specific computing resources, including: • Database management software and server • Web software and server • File-based storage server (for scanned images and other files)

Page 22


Assessment Report

• Application software and server • Analysis software for both Web and desktop • Web-based application development • User authentication for Internet users • Data verification software. Some of the identified functions, such as some servers, can be combined on a single physical server. More information about GDMS resources is provided in the Conceptual Design section.

Page 23


Assessment Report

66..00 BBeenneeffiittss

The GDMS will provide multiple benefits to ODOT, as well as benefits to stakeholders such as other state agencies, consultants, and the public. The system will provide tangible or measurable benefits in the form of direct cost or time savings, as described in section 6.1. The system will also provide many intangible benefits that may not be directly measured, but will still have a large and positive impact on operations. These are described in the remaining portions of this section. Benefits are grouped into the following categories and are described in detail below. • Direct cost savings • Expanded capabilities • Improved procedures • Improved service • Standardization. 6.1. Direct Cost Savings

ODOT will realize substantial savings in both direct costs and staff time with the GDMS. These savings will also be extended to the consultant community performing work for ODOT, and to other organizations serving the public. 6.1.1. Savings to ODOT

The ability of the GDMS to provide online research into previous geotechnical work and correlate this with new and existing environmental GIS data provides the most measurable potential cost savings. The proposed online archive of past work will allow ODOT staff, consultants, and others to investigate prior work in and around new project sites, as well as to review detailed digital data such as NRCS soils. This will allow users to more closely estimate drilling efforts, refine design plans, and estimate construction costs, saving ODOT money throughout the project process. Any work that involves drilling will experience cost savings with the GDMS. The current rate for drilling is $90.00 per linear foot; the savings from using just one boring log from a previous sample will save time and money on new investigations. Reducing the number of drillings on a project due to effective prior research will lower project costs. Gaining a clear understanding of the geotechnical environment will also reduce cost by allowing planners to target any new drilling more effectively. Consultants are currently responsible for the bulk (80 percent) of the geotechnical data collection process. These consultants are required to research previous work around the new sites, which requires them to expend time in traveling to and sorting through hard copy drilling records. They may be able to find previous work records, but sometimes these records cannot be located. If they can access and use existing borings information, they will be able to focus their drilling efforts and reduce overall drilling costs.

Page 24


Assessment Report

Consultants stated that potential savings of 10 to 20 percent is reasonable for most projects if the data already collected was made available in the GDMS. This savings would result in lower project cost estimates to ODOT. This would result in a direct savings of 8 to 16 percent (10 to 20 percent of 80 percent of the work) on geotechnical project costs. ODOT collection efforts (20 percent of the total) can be expected to have a savings similar to the consultant work, since the work is similar. This would result in direct savings of 2 to 4 percent (10-20 percent of 20 percent of the work) on geotechnical project costs. Potential savings exist in reducing transportation costs for drillers. The ability to research existing conditions will allow drilling operators to better plan their work. They will be able to determine how much equipment (e.g., auger material) to take into the field for any given situation and reduce the number of equipment transports. The geohazards portion of the GDMS will also provide cost savings. Currently, maintenance operations on areas of landslides, rockfalls, or subsidence are reactive; the objective of the operation is to open the road as soon as possible. Many times, the type of work done, the materials used, and notice that the work was done in response to a geohazard event are not recorded. Substantial amounts of material and resources have been used to repeatedly patch problem sites. The GDMS would allow these geohazard events to be tracked and costs analyzed on a proactive basis. The first objective of the geohazard work is to prevent a road closure. The second objective is to reopen a road as soon as possible if it is closed. The GDMS would allow a complete life cycle of geohazard prevention. The first step of the cycle is to inventory the site and collect information. The second step is to rate the hazard. The third step is to develop an effective remediation, resulting in the final step of fixing the problem. Thus, a long-term remediation can be applied to a site to keep the road open at all times and provide a more cost-effective solution to the problem. 6.1.2. Savings to Others

Discussions with consultants and staff from other agencies indicate that there would be substantial savings in time and effort for others when using ODOT data. This savings may not be directly accountable to ODOT, but certainly represents savings to taxpayers as public agencies reduce time required for data research. The GDMS will be able to decrease the cost and increase the speed of the ODNR statewide geological mapping program. ODNR estimates that it spends 320 hours of staff time per month tracking down ODOT geotechnical records for various purposes, including their mapping program. Most of that time is spent trying to retrieve and copy older data, which requires travel to and time spent at ODOT. The effort also requires ODOT staff time in assisting the ODNR staff. The GDMS would enable online research of this data, eliminating ODNR travel time, and ODNR and ODOT archival search times. The bulk of the 320 monthly hours for ODNR

Page 25


Assessment Report

could be directed towards enhancement or faster completion of their mapping programs, which is a direct benefit to the state. State agencies such as the Ohio Environmental Protection Agency (OEPA) and the Department of Health can use the online functions of the system to perform their own searches of information. They may combine the geotechnical information with their own data on drinking water or underground storage tanks to determine, for example, the possible movement of contaminant plumes in the ground. These agencies can make more informed and timely decisions on public health questions such as the safety of groundwater. County and city engineers will be able to use the GDMS data to augment their own data management and collection efforts. Municipalities and counties perform their own geotechnical investigations for their projects, and like ODOT, they can use the system to determine existing conditions in an area and reduce their own data collection costs. Consultants also perform work for counties and municipalities, and can do the same kinds of research and planning for these projects that they do for ODOT projects. The same degree of savings can be expected as well, reducing project costs for these local governments, as well as for other state agencies, private companies, and others that need the same services. The U.S. Army Corps of Engineers will also make use of the GDMS research facilities during their project planning process, allowing this agency to save federal dollars on Corps projects. The Corps maintains its own geotechnical data, and provided the systems have compatible or translatable data structures, data may be shared between the GDMS and the Corps. The Federal Highway Administration (FHWA) uses geotechnical data for its review of ODOT projects. This information is used to assess the quality of the design or assist with potential problems. FHWA also makes use of the project data to validate adjacent data. FHWA would make use of the GDMS to support these activities. The Department of Homeland Security or FEMA may also be interested in the data for risk assessment and site ranking. Other potential users may include academia and USGS. 6.2. Expanded Capabilities

The GDMS will provide data access and additional software capabilities. This combination will allow staff to develop more robust data analysis routines with a larger amount of data. These routines will provide: • Increased validity for models and methods due to use of a larger volume of test data from

field collection. • Modeling of potential groundwater flow regimes for a more effective control of groundwater. • Modeling of geohazard locations and processes, allowing ODOT to avoid geohazard areas. • Integration with other ODOT business unit data. • Sharing of routines, data models, and analysis with other agencies such as ODNR, FHWA, or

the Corps of Engineers, resulting in collaboration on research and use of new methods.

Page 26


Assessment Report

• Predictive models, remediation models, and methods for geohazard locations. • Cost analysis modeling. • Data correlation analysis. • Spatial analysis of geohazards for planning purposes. 6.3. Improved Procedures

The GDMS can be expected to improve ODOT operations in a number of ways, and impact on procedures from project planning to maintenance. The GDMS will provide: • Accurate information in the planning stages of projects, allowing better decisions to be

made earlier in the project timeline. • Improvements in the corridor selection process as additional data is available for quicker

evaluation and comment. Environmental analysis of proposed projects will be enhanced with additional data. Reliable data will promote better understanding of in-field conditions.

• Additional and improved accuracy data for project designs, providing for more accurate design drawings and plans.

• Shorter project delivery times, as the time required for geotechnical investigations is reduced.

• Tighter estimates of project costs due to improved research of conditions, resulting in fewer change orders during the construction phase.

• Capture of geotechnical data during project investigation and construction phases, allowing data to be used for estimation of future projects and maintenance.

• Integration of data from materials and structural tests, allowing for better estimates for future work. The number of future tests can be reduced due to accessibility of pertinent and similar data from previous tests. Test results can be shared with other states and agencies, increasing regional cooperation and allowing ODOT to benefit from other initiatives elsewhere.

• Development and use of decision-support tools based on models and remediation methods. • Improved methods for maintenance and remediation of geohazard sites, resulting in less

overall maintenance time required for sites. • Electronic capture of geotechnical data for future access and use. Very little of the data

currently being collected for ODOT (e.g., the consultant data) is being electronically captured. Electronic capture provides a data archive in the form of data backups, and enables access and use.

6.4. Improved Service

There are many customers for ODOT’s geotechnical data. These customers include ODOT staff in OGE as well as in many other units. The customers also include many people from outside ODOT. The GDMS will improve service for all of these customers.

Page 27


Assessment Report

Currently, searching ODOT’s geotechnical records requires that researchers travel to the data archives and sort through files and paper. This requires the assistance of ODOT staff to procure the proper files from dead storage. The GDMS would include electronic images (scanning) of these records and database, and provide an online search engine for them. Researchers would be able to do their searches online through the Web interface. Customers will no longer be required to travel to the archives and will be able to perform their searches at their convenience. The use of an electronic data retrieval system will promote standardization in nomenclature and measurements, and will foster better communication between consultants and ODOT reviewers. Outside agencies will be able to use the system to augment and improve their own processes. For example, ODNR will be able to improve the quality and timeliness of its geologic mapping program by using ODOT’s data for online research of conditions. This geologic mapping will improve environmental monitoring by governments and agencies throughout the state. Online access will also increase the number of customers for this information. Consultants, county engineers, and others who do not make use of the information due to the costs associated with their searches will be able to do so. The GDMS will also prompt these entities to enter their own data via a secure password-protected mechanism. This will significantly increase the quantity of available information. The GDMS will have a positive impact on economic development activities in the state. Many infrastructure projects, developments, and business expansions can make use of this data to lower their project costs, shorten their project times, reduce duplication, and avoid problem areas. Economic development efforts can be focused in suitable areas and be completed sooner. 6.5. Standardization

Standardization of geotechnical data, procedures, and analysis will provide for efficiencies in operations and more accurate interpretations of analysis. GDMS standardization will allow: • A single data model to be established for geotechnical data. The data model may be built

from other efforts (CalTrans, FHWA AGIDS). • An increase in data sharing among organizations. • Established methods of data collection and reporting for consultants to follow, including the

use of electronic delivery of data, and development of automated and efficient routines for following procedures.

• Better understanding of terminology among practitioners, allowing for widespread understanding of analyses.

Page 28


Assessment Report

• Test results on materials to be used statewide to allow for better comparison tests and

reduce the number of tests needed. Test results can be spatially analyzed. • Structural information and test results to be shared regionally, increasing confidence in

structural designs, reducing changes, and allowing for fewer expensive tests.

Page 29


Assessment Report

77..00 IImmppaaccttss ooff NNoo AAccttiioonn

An alternative to the development of the GDMS is to continue on the current course of geotechnical processes; that is, a “no-build” option. This option does have impacts, or adverse affects, on ODOT. As with benefits, some of these impacts are directly measurable, while others are less tangible but just as important and critical to effective operations at ODOT. 7.1. Direct Costs

Information from the assessment project interviews and survey indicate real and potential instances of losses of money and resources if current practices are continued. The current geotechnical archive is a collection of 21,000 hard copy report files that represents approximately 75 years of information collection. There are no backup copies of this information; the archive consists of single originals only. This is a very valuable, and irreplaceable, resource for ODOT. It represents the only store of geotechnical knowledge for ODOT. It is estimated to cost $20,000 to $25,000 per project if this data needed to be collected again for future projects. Thus, without the GDMS to provide a digital copy of all of this information (preserving it for future use), ODOT is risking an approximate $500 million loss of important data. The majority of geotechnical data does not change over time. Therefore, the data will remain a valuable asset for ODOT. Structures represent significant expenditures in money and resources for ODOT. A structural failure, as evidenced elsewhere, can be catastrophic to human life. It is imperative that structures be thoroughly and safely planned, designed, built, and inspected. Structural tests such as load tests or dynamic monitoring of pile driving are a primary component of this process. However, all of the materials comprising a structure cannot be individually tested; ODOT must rely on representative tests. The tests themselves are expensive, depending on the structure, and can run into hundreds of thousands of dollars or more. Test results must be interpreted and interpolated for regional conditions and across the state. The geotechnical information associated with the tests is an essential component of the test, and must also be interpreted and interpolated consistently. Terminology, data structures and values, and analysis methods can vary from area to area, making it difficult to successfully apply interpretation and spatially analyze data. Conversely, a structural test can be only partially reliable if geotechnical information is not available for the test, or for where the tested design will be applied. Thus, ODOT has spent, and will continue to spend, many dollars on structural tests that could be replaced by accurate and meaningful interpretations. Information about structural tests needs to be captured and disseminated. Major structural tests are rarely conducted; the expense for these tests is great. For example, ODOT spent about $1 million on a test of two shafts. One shaft passed all tests, but the second shaft did not pass one of the tests. Information about similar configurations and tests could be available in the GDMS, and provide information that might cause ODOT to change or improve a design prior to testing.

Page 30


Assessment Report

7.2. Limited Capabilities

Current systems of managing geotechnical information rely heavily on use of hard copy reports or isolated databases, and do not focus on data accessibility. This reliance precludes being able to integrate data or look at several sources of data at once, and does not allow analysis of data using many of the user-friendly and advanced software routines available today. The following impacts are the result of data isolation and lack of integration: • Software capabilities are increasing dramatically, allowing users to perform desktop analyses

and visualization of data that could not be attempted before. These capabilities are resulting in new or refined project approaches. However, these software routines require data to be collected and managed differently, and generally cannot be attempted successfully by ODOT’s current system.

• Visualization and presentation of data across a small or large area can dramatically improve public or stakeholder participation, comment, understanding, and consensus on project efforts. ODOT is unable to readily show and explain geological and geotechnical aspects of projects in this manner, which can slow down project input and mutual acceptance.

• Comparison of test results, along with interpolation of test results, is difficult with current data management practices. This affects chemical, physical, road materials, and structural tests. Many tests must be performed needlessly because results of similar and previous tests, which could be interpreted and used, are not available. In the case of materials tests, the ability to see what material types perform well or poorly in other parts of the state (or region) could be very useful.

• ODOT is unable to take advantage of either existing systems or methods and procedures for evaluating geohazards and other geotechnical problems adversely impacting operations or roadways. Other states and organizations have data to offer, but ODOT cannot directly use these efforts with the current practices and system.

7.3. Limited Procedures

Many ODOT operations involve geotechnical processes, but few make full use of what geotechnical processes can provide. In many cases, work must be repeated because of an inability to access data or use particular software analyses and methods. The following can be expected to recur: • As described earlier, geohazard operations and maintenance is primarily focused on getting

and keeping roadways open (treating the symptoms), and not necessarily on solving the problem. In the absence of GDMS geohazard capabilities, ODOT will likely continue to focus on a reactive rather than proactive approach to solving these problems. Patching operations will continue, piling up new paving material, while older material is carried away from the road to streams or other sensitive areas. There is a need to conduct forensics on roadway and/or structural failures with the GDMS.

• The boring data represents a wealth of information if it can be evaluated in new software programs. However, without accurate spatial referencing of locations, elevations, or accessibility of boring interpretations and lab analysis, effective site analysis cannot be performed on the data. Many other organizations, such as ODNR, the Corps of Engineers,

Page 31


Assessment Report

or consultants, would like to be able to access and use this data, but cannot in its current form.

• There are no procedures in place for saving or managing geotechnical information collected by and used for the Districts. The Districts collect a large volume of geotechnical information. However, much of this information is stored in file folders for several years, and then discarded. No additional use is made of the information, though it is potentially very valuable. Some of this material is microfilmed, which does not make it any more accessible for use. This data can be scanned or otherwise converted to electronic records and made available through the GDMS.

7.4. Limited Service

There are a large number of potential geotechnical information customers. However, most of these potential customers cannot or will not use the information in its current form. This lack of customer service will have the following impacts: • Many respondents to the project survey indicated no knowledge of the existing geotechnical

data archive, or minimally used the archive. The large amount of valuable information in the archive will remain unused by a large potential audience if current conditions persist. This information will not be used for project planning purposes if users must physically visit and search through the archives.

• ODOT is missing an opportunity to serve many customers and take credit for that service. Outside users of the information will continue to be limited. Users such as county engineers, planners, engineering firms, developers, and builders have not made use of the existing information. They likely will not make use of geotechnical information for their purposes, though it can be valuable for them. ODOT would be recognized by these groups if it were to provide ready access to valuable data.

• Other areas of ODOT, such as Planning, Maintenance, and Construction Management, will miss out on improved use of geotechnical information. These groups can benefit from using this information to improve processes. However, this will not take place without a resource-efficient way of doing so.

• Consultants will continue to spend time and money in manual searches of the project archives. This will continue to cause higher costs for ODOT projects, as well as for projects that consultants perform for local government, businesses, etc.

7.5. Standardization

The current lack of standardization in data terminology, collection, and analysis holds back the geotechnical community in performance. The impacts of this include: • Material or characteristics being described or analyzed in different ways, causing users to

miss data or potentially misinterpret data. • Redundant data in ODOT and uncertainty on authority of data.

Page 32


Assessment Report

• Multiple databases developed by agencies, surrounding states, and consultants, requiring

each organization to develop its own data model and design, preventing timely or widespread sharing of data.

• Consultants using different collection and reporting methods, causing ODOT to rely on hard copy reports for interpretation, and potentially causing data error or interpretation problems as double-entry of data takes place.

• Redundant tests and analyses being performed around the state and regionally because existing test results cannot be fully understood or evaluated.

Page 33


Assessment Report

88..00 FFuunnccttiioonnaall RReeqquuiirreemmeennttss

This section lists the many various requirements for the GDMS, as provided by users and staff in project meetings, the interviews, and the project survey. This list is not meant to provide the full potential list of requirements, as the assessment project does not contain a full requirements gathering task. The list is, however, a good starting point and comprehensive, as users were enthusiastic about providing their ideas for the system. Additional items are expected to be identified during detailed development of each module of the GDMS. There is no order of importance or priority in the list. The following data is needed: • Boring logs • GPS locations of drilling locations • Elevations • Geotechnical reports • Design drawings: cross-sections, profiles, boring logs, test results, details • As-built drawings and notes • Drive lengths on piles • Soils data (NRCS SSURGO or SSURGO II) • Surface mine locations • Historic and current USGS quadrangle topographic maps • Abandoned underground mine maps • Geohazard locations (rockfall, landslide, mines, bank erosion) • Historic site photos • Coal seam base elevation data • Landslide susceptibility map • Bedrock geology maps • Bedrock structure maps • Aquifer maps • Water well logs • Top of rock • Roof rock thickness • Glacial deposit mapping • Groundwater data • Planimetric overlays • Historic aerial photography • Cross section data • Geotechnical reports, field notes • Soil profiles

Page 34


Assessment Report

• Test pit data • Engineering drawings • Environmental data from consultants • Lab test results. The following functions were identified: • On-demand (ad-hoc) data and map queries as well as pre-programmed query functions and

reporting should be provided. • Consultants should be able to submit their project data electronically through the system,

with quality control and data format check performed by ODOT. • The project should have a modular approach. Strategic objectives of each module or phase

need to correspond with equipment and software requests. • The system should provide the ability to generate a profile across an entire project site. 2D

and 3D analysis are both useful. • Cross-referencing of older and current LRS is needed to accurately place older projects on

the current road system. Keeping the old alignments available in GIS would be useful in tying corresponding data to that time frame.

• It is essential that the system should be accessible to everyone in ODOT who works with geotechnical data.

• Test data should be made available with the ability to manipulate the data online or download the data for offline analysis.

• Maintenance records from the Districts, including time and materials records, should be included.

• Information from the CMS (such as the job diaries) should be included. • The system should support one-time only data entry with governing controls to make

certain of data integrity. • Standards in nomenclature and terminology should be established and followed. • Compatibility with FHWA methodology and the Automated Geotechnical Information and

Design System (AGIDS) is critical. ODOT and FHWA are collecting a synthesis of what every state is doing so that all systems can interact. They have started investigating terminology and methods for this purpose. The final report from this study will be available in March 2004.

• The USGS proposed National Landslide Hazard Mitigation Strategy should be reviewed to make certain of terminology and data collection compatibility with proposed national standards.

• The system should be compatible with efforts in adjacent states to permit it to be used at sites that require data from multiple agencies.

• Data from adjacent states should be researched and acquired. This is especially important for structural information and test results. Information on equipment and methods used for these tests should be provided.

Page 35


Assessment Report

• Field data collection should have a geographic component (coordinates) as well as

elevation. A common statewide coordinate system and Datum would be required. • Data such as grouting logs, dynamic loading tests, and re-strikes should all be available.

This is needed to understand correlations in the materials and their use. • The project review reports, corrective actions, soil profiles, and maintenance information

should all be maintained indefinitely. The undisturbed records test especially should be maintained.

• The system should include a modification of TMS to include geohazard categories. • Pavement ratings information is useful. However, these data are only stored by changeable

highway markers and only based on roughness and aggregates. Other, more accurate tests may be needed for best correlation efforts.

• The system needs sub-foot accuracy for boring logs, and ability to link photo logs and all reports associated with the data collection and analysis. The boring locations need to be recorded as both geographic locations and station/offset.

• Soil boring logs and plans should be available while in the field or office. • Construction plans should be linked to or included in the GIS map. • Raw data from consultants would be useful to test their assumptions. Raw data would be

beneficial for developing correlations such as N. A method for online data entry would expedite the data entry process.

• Pile driving records and drill shaft data would also be very useful, especially for expanding bridges. Settlement information on structures and other data on slope and wells would also be very useful.

• The system should provide the ability to perform data correlations between logs. • The user should be able to interactively select an area by quadrangle or county or multi-

county area. • The system should provide the ability to download selected data. • The system should enable prioritization for where to spend funding.

Page 36


Assessment Report

99..00 BBuussiinneessss PPrroocceesssseess ffoorr GGDDMMSS

The establishment of the GDMS will require changes in ODOT business processes. Many of the changes will occur within OGE, while other changes will occur elsewhere in ODOT. Some changes will be entirely new processes, while others will be procedural or system changes. This section and the next describe these changes and their impacts. GDMS development efforts to date have focused on the scanning and database development for the historical archive data. This effort will both protect the value of that data and provide better access to it. However, the emphasis of the GDMS should be on moving forward with efficient data collection and management practices focused on providing data access to a wide variety of users. 9.1. Data Collection

Perhaps the biggest changes will take place within the data collection process. Changes will impact the geotechnical data collection operation, but will also affect consultants and other sections within ODOT. Minimum standards for consultants (such as data formats, use of GPS, and collection of elevation data) will need to be established. Processes for streamlining the data entry component such as Web-technology will allow for greater access and standardization. 9.1.1. Drilling Operations

Additional data collection duties should eventually be given to the drilling crews. This would require the use of GPS units for each of the drilling rigs, and the probable use of rugged notebook-type computers for field data collection. As mentioned earlier, custom data collection programs or geotechnical off-the-shelf programs would have to be implemented for these operations. These data collection efforts may have to be assumed by a technician-level position, which would be a new staff position on the ODOT drilling crews. The collection of elevation data at the desired accuracy level will likely require the use of survey crews in conjunction with field operations. Consultant operations should follow the same procedures and collect the same electronic data. The equipment and methods that each individual operator would use can be left to his or her discretion, provided the same quality information is collected and delivered, and requirements for accuracy are met. The use of electronic collection will allow the data to be loaded directly into a staging area of the GDMS. This staging area would be used as a quality control process. ODOT staff would review the provided data (from ODOT crews or consultants) and make certain that it meets quality criteria. Data is moved from the staging area into the GDMS on final approval.

Page 37


Assessment Report

9.1.2. Geohazard Operations

Data collection and management for geohazards has been an ad-hoc process. Policies and procedures should be established for the collection or documentation of geohazards; these policies will generally apply to District personnel as well as staff in Construction Management, Environmental Services, and potentially other areas. The GDMS should strive to collect as much existing information about geohazards and geotechnical information as possible, while improving the internal processes. The GDMS should help to identify more potential geohazard sites during the project design and review stage. ODOT should then be able to use remediation methods developed with the help of the GDMS to more proactively treat or avoid these areas, saving on future costs. Geohazards are inevitably discovered during construction work. Construction managers should be using the electronic job diary function of the CMS to record these events and any work efforts about them. Ideally, this information can be coded in the system in such a way as to allow geohazard diary entries to be automatically extracted from the CMS to the GDMS. District personnel perform the maintenance activities on geohazard sites. Currently, the recording of this work does not promote geohazard site monitoring. The Maintenance Management System or other type of application should be used to record all maintenance activities on geohazards. As with the construction information, this information can be coded in the system in such a way as to allow geohazard work activities to be automatically extracted to the GDMS. 9.1.3. GIS

Coordination will have to take place with the GIS Manager and staff within the Office of Technical Services. The GDMS will be making use of a large number of GIS data layers, most of which will originate or be managed by Technical Services. The GDMS will require an initial load of existing data layers, which should be performed by GIS. Over time, additional data will be identified for inclusion in the GDMS. OGE would be responsible for performing quality assessment on geotechnical layers. The Office of Technical Services GIS staff would be responsible for performing quality assessment on other GIS data (reference data such as roads, streams, boundaries, etc.), and then loading it for use by the GDMS if it is acceptable. This assessment should include review of such items as source scale acceptability and data projection/datum. 9.2. Data Analysis

Data analysis activities include both the laboratory testing of samples and the manipulation and visualization of data for project purposes.

Page 38


Assessment Report

9.2.1. Laboratory Analysis

Most laboratory operations will be unaffected. The electronic data collected at drilling operations will be able to come directly to the laboratory, starting database records for further input. The samples testing will continue. However, the stand-alone, Delphi-based data system should be replaced by a system hosted within the GDMS. This will allow laboratory data and results to be directly available to a wider audience of users, with appropriate security measures. The MicroStation-based drawing routines for borings information may be replaced, or augmented in the short term, by software developed expressly for boring analysis. The software would read sample data directly from the database, allowing logs or other graphics to be generated when needed. This software could also be used by other GDMS users, allowing them to generate their own logs, profiles, etc. for sets of data of their own choosing. The hard copy files and folders currently used for data storage and ultimately archival would be replaced by the GDMS database. The project and other information found on the card files would be entered directly into the GDMS through the field collection efforts or as part of test results, replacing the hard copy card. Consultant laboratory operations may be affected in various ways by GDMS implementation, depending on particular laboratory procedures and programs used. Currently, their focus is on producing hard copy reports and drawings for submittal to ODOT. It is assumed that all or most are using electronic means to produce this material, but those means vary by consultant. ODOT would most likely be requesting (as part of procedures) that consultants now submit electronic material along with supporting data. This may require changes in methods and software for the consultants. 9.2.2. Project Analysis

The GDMS would provide better data access for project review, in the form of a wider variety of and quicker access to data. Some of the timesavings resulting from online access would be used to review additional data types, hopefully producing more thorough reviews. ODOT may consider laptop or notebook-type computers or CE devices for these staff, to allow them to have access to the GDMS while doing site visits. These devices could include all pertinent data records, electronic images, and other data about the project site, downloaded to the device before the visit. They would also be able to use these devices to directly input their notes into the project record databases. The updated data could be uploaded to the GDMS on return to the office, or the database could be updated directly through wireless access. Direct entry of information while at the project site may reduce errors or omissions in later data entry. Consultants may also make use of similar technology and procedures for their project analysis activities. They would be able to download from and upload data to the GDMS through secure password-protected routines. Analysis programs could be developed as part of the GDMS, and be made available through Web access. Secure data areas can be developed for each project, and allow ODOT, consultants, and other analysts to share data, perform analyses, and share analysis results. The

Page 39


Assessment Report

project data store would allow ODOT staff to evaluate project work performed by consultants and other partners. 9.3. Integration with Other Systems

Integration with construction and maintenance systems for data retrieval has already been described. The GDMS will be expected to have interfaces with various ODOT data systems, to provide access to data used for the GDMS. This type of access may come through ODOT’s Sybase data warehouses, or from other means. Generally, data would be copied or replicated to the GDMS, though it could also be transformed for use. The GDMS could potentially be linked to systems in other agencies, such as databases at ODNR or the Corps of Engineers. This linkage could be used for data exchange between systems on a batch basis, or for direct (transactional) data access. Security and performance issues must be carefully considered for this type of integration. Data transfer may have to occur over the Internet instead of a secure state network, and user authentication must be implemented. The GDMS can also make use of GIS data or map services provided by other agencies. Increasingly, agencies are making use of Web-based map services to publish their data holdings on the Internet. These data holdings may be used as spatial data within the GDMS, or may be used as map services within GDMS applications. For example, geologic maps published by ODNR through the Web may be accessed and displayed in conjunction with GDMS map displays. Examples of such data use can be found with ESRI’s Geography Network or the Open GIS Consortium’s Web services standards and samples.

Page 40


Assessment Report

1100..00 IImmppaacctt oonn CCuurrrreenntt BBuussiinneessss PPrroocceesssseess

The previous section described various business processes that will be affected, or created, by the GDMS. These processes will have positive or negative implications for the operations that they impact. These implications are further described in the following sections. 10.1. Drilling Operations

It may be a significant challenge to introduce additional and electronic field data collection duties to the drilling operations. However, the ability to collect accurate information at the source is very important to the GDMS’s goal of streamlining data management practices. The effort will require training of crews and patience with the training and early operations. It may require the addition of a technician to the crews, or training sufficient to provide that level of service. A geologist may be added to each of the crews to log information. A surveyor or survey unit may be required to gather elevation information during or after drilling operations. The units and applications used must meet the criteria of being rugged and simple. The data entry process must include no or minimal keyboard or similar data entry. Data entry options should ideally all be through interface elements like pick lists or check boxes. Data upload should be through desktop cradles or similar mechanisms. This process would have substantial up-front costs for the electronic data units and training in their use. This change may not be an early phase implementation option for the GDMS. The overall effect of the changes would be positive for the GDMS. 10.2. Laboratory Analysis

The change in laboratory processes is really a change in the tools (software, databases) that are used, with a possible small decrease in data entry due to prior electronic collection of data. A Laboratory Information Management System or similar software may be implemented for data management purposes. If the tools that are introduced can effectively do what the previous tools did, and introduce additional capabilities, effects on laboratory operations will be positive. 10.3. Project Review

The process changes for project review will be overwhelmingly positive. The combination of quicker access to existing data, additional data sources, and the ability to perform more complex analyses and visualizations, will produce more thorough reviews and increase confidence in the reviews. The time now spent collecting and reviewing archival material can be spent in planning and developing recommendations. Reviewers may be asked to evaluate more material, and may need to learn analysis software products.

Page 41


Assessment Report

Collaborative review of projects may be achieved through Web-based analysis tools. Outside users (e.g., consultants, agencies) could use GDMS analysis programs and data to run their own analyses or models, and store their results within the system for review and use by ODOT. 10.4. Geohazard Investigation

The potentially largest impact will be on geohazard investigation. This is currently an ad-hoc process with varying degrees of data availability and quality, and minimal policy and procedure adherence. The GDMS’s proposed processes cross through ODOT lines and require following new processes. They also involve what could be significant system integration challenges. However, ODOT needs to get a handle on this work and establish geohazard management practices. There may be significant time requirements for ODOT to adopt these processes. Rather, it may be more a matter of developing specific procedures and “steering” where current data is entered. In conjunction, technology must be used to get the data into the GDMS in an efficient manner. Geohazard inventory and analysis programs would need to be developed for the GDMS. These programs should be Web-based if possible, and may make use of existing programs or code. The Delphi-based AUMIRA application would eventually be ported to be a Web application. A number of small negative or neutral impacts would in fact result in a large positive effect for ODOT. 10.5. Historical Research

The job of digitally capturing all of the historic project data and making it widely accessible will be time-consuming and expensive, but the direct savings in archive value, staff resources, and project savings, and increase in customer service, make this portion of the GDMS overwhelmingly positive. Large amounts of staff and customer time will be saved using the new process, and there are measurable savings in project costs. The existing historical data is queried with an ODOT-developed GQL program. This program allows for the query of the database information, but has no capability to view the scanned images. These images, as well as other images such as engineering drawings, can be viewed with a combination of document management system software and Web-based viewers. The Falcon viewing packages from the TsaADVET document management package may be used in some cases to view these images, particularly where interaction with the images is required. In other, simpler, cases, a more lightweight Web-based application would be developed to combine both database access and query with the ability to view associated scans.

Page 42


Assessment Report

10.6. Other Offices

In addition to project review activities, other units within ODOT (e.g., Planning, Materials, Structures, Construction) will experience a positive impact on their own processes. They are frequently tasked with viewing, analyzing, entering, or reviewing geotechnical data. The GDMS will provide faster and easier access to data, as well as system-based application programs for their use. 10.7. Consultants

Consultants will also experience a net positive impact with the GDMS. Consultants should find it easier and much more convenient to search project archives for relevant data, and may also be able to take advantage of some or all of the Web-based application tools. Consultants will also be able to enter both their raw and processed data into the GDMS. This data entry step may provide a negative impact on consultant processes in the form of a procedural step that they do not currently perform.

Page 43


Assessment Report

1111..00 SSooffttwwaarree EEvvaalluuaattiioonn

Software is an integral part of the GDMS, particularly for users of the system. There is not a single software product that can adequately address all or even most of the requirements of the GDMS. The GDMS will ultimately require many types of software comprising various products from separate vendors. A software evaluation was conducted as part of the assessment project; this evaluation looks at multiple products covering major functional areas of the GDMS. 11.1. Software Categories

The software evaluation is broken into four areas: • A DBMS will form the core of the GDMS data management system. The DBMS will supply all

users and applications with data, and must be compatible with all components. • GIS software will be a central part of the GDMS. GIS will allow data to be queried,

displayed, analyzed, and reported through spatial relationships and map interfaces. GIS will be used as part of the foundation of the Web application, and will also be used as a “power tool” on the desktops of ODOT users.

• Application software will be used to perform specific functions, and will be both Web- and desktop-based. This software component will be comprised of geotechnical and related software products to handle tasks such as data collection and management, analysis, and reporting. The analysis may include tasks such as generation of 3D models of subsurface conditions or statistics.

• Imagery software will be needed to manage and view the many images within the GDMS. This imagery will include the scanned archive information, as well as other scans and similar data sets.

All applications will be using the same data sources. Some applications may be calling others to perform certain tasks. For example, a database query tool may call on an image viewing tool for the display of a scanned document. Therefore, the components of the GDMS must be able to interface with each other when necessary. Compatibility of products is evaluated as part of this study, but more extensive investigation and testing should be performed for potential GDMS product selections. 11.1.1. Desktop versus Web

Application programs of the GDMS will be divided into desktop and Web programs. Desktop programs are usually installed on a user’s PC. They may possibly be run or installed from a server, but the application still uses the PC. Data for a desktop application may come from the PC or a server. Web applications run from a Web server and usually are accessed from a browser (e.g., Internet Explorer) or from a Web-based program written with software like Java. Data for Web applications usually come from a server. OGE desires as much Web-based functionality for the GDMS as possible. Web-based applications available to all users would provide consistency in software use and data analysis

Page 44


Assessment Report

and reporting. OGE can develop policies and procedures for the use of GDMS-based applications, with the storage of data in the GDMS database allowing multiple users (and reviewers) to use the same data and check results. Much of the GDMS will be available for use through the Web portal, and this will serve most of the users. However, some of the desired analysis functions, and nearly all of the geotechnical-specific “heavy-duty” functions like 3D and surface analysis, can currently be accomplished only with desktop applications. The off-the-shelf geotechnical software products evaluated in this section (as well as the GIS 3D capabilities) are only available as desktop applications. Any desired Web-based geotechnical functions would have to be developed with extensive custom programming, and some may be difficult to accomplish. It is probable that the full range of geotechnical functions and programs desired for the GDMS will eventually be available as Web-based applications, but when that will occurs in uncertain. The full desired functionality of the GDMS would have to be developed as a combination of Web and desktop applications. A full functional requirements study will identify the types of applications users will need, and how those applications should be delivered to them. Most users will likely have most of their needs met through the Web applications. Some users may have to use desktop applications for some analysis purposes until such time as the programs become commercially available as Web applications, or the desired functionality is built as custom programs. A GDMS system design will determine how each individual application should be implemented; as an off-the-shelf product or as custom-programmed software. 11.2. Software Selection and Support

It must be recognized that the software chosen must be the best fit and have the needed capabilities for the GDMS, which may require deviation from ODOT standards or current platforms. It must also be emphasized that GDMS software selection decisions should be made in collaboration with Technical Services and Department of Information Technology staff. Consideration must be made to issues of software compatibility with ODOT standards, installation and support, licensing and/or maintenance costs, and other administrative items. These issues are not covered in detail in this review. Some of the functionality of the GDMS will be met with off-the-shelf software, while other functionality (e.g., the Web portal) will be met with custom programming. All software must be maintained over time, and OGE will have to work with DoIT to identify maintenance costs and resources needed over time. Custom programming must be done with development languages and environments current with standard practices with which ODOT or its contract consultants are familiar or can become familiar with. Changes and updates in software are inevitable, and the GDMS must be able to be supported by ODOT, its consultants, and/or the software manufacturers. 11.3. Database Management System

The GDMS will use a DBMS for data management purposes. The GIS data should be stored within this database as well, as the best Web and multiple user performance will come from

Page 45


Assessment Report

spatial data in a database. The DBMS must be an enterprise-class database to support a wide variety of users and applications in a secure environment. The GDMS DBMS will require a significant amount of data modeling and database design work to make certain of efficient database operation. The DBMS will also require administrative (DBA) support from DoIT; DoIT should be involved in all phases of database selection, design, and implementation. The database must support spatial data. Intergraph directly supports the Oracle Spatial format, and uses its own proprietary formats for Microsoft Access and SQL Server, and IBM DB2. ESRI uses its own proprietary ArcSDE database engine for data within databases, including Oracle Spatial. ArcSDE will work with Oracle, SQL Server, and IBM’s DB2 and Informix. The GDMS DBMS should be Oracle, using Oracle Spatial for GIS data. ODOT will likely be making use of both Intergraph and ESRI software for various purposes, and the GDMS database should support access by both software platforms. Both Intergraph and ESRI GIS software can access and use the data in Oracle Spatial; Intergraph will read it directly, while ESRI must use ArcSDE. Microsoft’s SQL Server and IBM’s DB2 and Informix also support spatial data, but not in ways that ESRI and Intergraph can both use. 11.4. GIS Software

GIS software will be used as one of the primary component pieces of the GDMS. The software will be used in two main functional areas: as the map interface in the system Web application (portal) and as “power” analysis tools ODOT staff desktops. These two functional areas have different software requirements as users will be interacting with the software in quite different ways. On the Web side, the users are usually interacting with a map image and a small set of map tools (pan, zoom, layers on/off, etc.); GIS processing is accomplished on the server and functionality is well-defined and limited to the application design. Generally, not much training is required. On the desktop side, the user is working interactively with a complex suite of GIS tools. The user must have extensive training or experience to fully understand and use all of the tools available. GIS software will also be used to manage the storage and access of spatial data such as drilling point locations, soil polygons, and aerial photography. Product suites from two GIS vendors are evaluated: ESRI ArcGIS and Intergraph Corporation GeoMedia. These products are evaluated for use in both the Web application and on the desktop. The ESRI products include: • The ArcGIS suite (ArcMap, ArcCatalog, ArcToolbox) running at the ArcInfo, ArcEditor, and

ArcView license levels. The ArcInfo license has full capability, ArcEditor has data creation and maintenance capability but some limits on analysis, while ArcView has limited data creation and maintenance capability.

• The ArcSDE product is used for data storage and management within many types of database management systems.

• ArcIMS is used for Web-based mapping and applications.

Page 46


Assessment Report

• The 3D Analyst and Spatial Analyst extensions are used for more advanced data analysis

and visualization techniques. The GDMS would require the use of all of these ESRI products. ESRI software is used widely for environmental, geologic, and geotechnical systems, by engineering and consultant firms, and state and local government agencies. Other geotechnical software applications operate as “extensions” to ArcGIS and use the power of its spatial assessment capabilities to perform specific modeling tasks. The Intergraph products include: • The GeoMedia suite, with GeoMedia and GeoMedia Professional. GeoMedia is used for

desktop query, analysis, and display of data. GeoMedia Professional has more analysis capability than GeoMedia, along with additional data creation and maintenance tools. GeoMedia directly supports data management within selected databases.

• GeoMedia WebMap Enterprise, a server-based program with a browser component plug-in that provides extensive Web GIS capability.

• The Terrain and Grid extensions to the GeoMedia suite, which provide raster and elevation (3D) data analysis tools.

The GDMS would require the use of all of these Intergraph products. The Intergraph products are used by GIS operations in Technical Services. Intergraph products are not as widely used in environmental, geologic, and geotechnical systems as the ESRI products. Geotechnical software application vendors do not provide programmed interfaces or “extensions” to the Intergraph products. 11.4.1. Desktop Use

While Web GIS will play a major role in the GDMS, full geotechnical GIS routines will only be available (for at least another year) through the desktop product suites, ArcGIS and GeoMedia. The 3D and other spatial analysis routines of the ESRI and Intergraph desktop products have not been ported to their Web products. ESRI is expected to release version 9.0 of its products in the second half of 2004. This release will greatly increase the functionality of the ArcGIS product for Internet and Web use. After a “shakedown” testing and evaluation period, it can be expected that geotechnical analysis routines would be feasible, and that geotechnical vendors would be providing updated versions of their ArcGIS extensions. Intergraph’s intentions are not as definite, but it can be expected that it will continue to build functionality into the WebMap Enterprise product. Both ESRI (ArcGIS) and Intergraph (GeoMedia) provide extensive desktop GIS suites. These suites are more similar in functionality than they are different, and interoperability among the products has greatly improved over the past few years. The base functionality of each suite would not provide the full capability needed for GDMS and OGE operations; each vendor has developed add-ons or extensions that attempt to meet these more particular needs.

Page 47


Assessment Report

The ArcGIS 3D, Spatial, and Geostatistical Analyst extensions have evolved from their original releases of several years ago. Spatial and 3D Analyst were both developed and introduced for the ArcView 3.x program, and have been adapted and updated for the ArcGIS program. The 3D Analyst and Spatial Analyst extensions would provide the most benefit for the GDMS. This package is designed to work with data with true x,y,z coordinates through its ArcGLOBE technology; it can work with drilling depth values as the z component. 3D Analyst can be used to model groups of borings, to develop 3D visualizations of subsurface data, and to produce contour or raster data sets of subsurface data. Many of the tools in Spatial Analyst are similar but are used more for assessing the spatial distribution of sampled data sets. The raster data sets can be further analyzed in Spatial Analyst to develop area models of subsurface conditions. The Geostatistical Analyst package was developed with ArcGIS, and provides additional statistical, validation, and data modeling routines. Many geologic and environmental software developers have targeted ArcGIS as their preferred GIS platform for product integration. Vendors such as EarthSoft and RockWare have built their products to integrate or interface directly with ArcGIS. ArcGIS is well-suited for geotechnical operations. The Intergraph Terrain and Grid extensions are fairly new releases for GeoMedia. The Terrain extension is similar to 3D Analyst. The Grid extension is analogous to Spatial Analyst, in that both work with raster data sets. The in-practice use of Terrain and Grid is low. They do not support common industry formats as import and export routines, though these functions are supposed to be added in a future (undetermined) release. In fact, it can be problematic getting data directly between the Grid and Terrain products, as they use different native formats. Third-party vendors that supply the geotechnical-specific software that will be needed within the GDMS, such as gINT and EQuIS, do not integrate their products with GeoMedia and have not announced plans to do so. GeoMedia is not as well-suited as ArcGIS for geotechnical operations. The GDMS will be a multiple-user, multiple-application system with its data managed in a DBMS. The GIS products must work within that environment. The use of the ArcSDE data management product will be required if the ArcGIS suite is used with the GDMS, due to the magnitude of data and potential users. This is an additional software layer (at additional purchase and maintenance cost). The GeoMedia products work directly with Oracle Spatial data, and implement their own data storage format for DB2 and SQL Server databases. GeoMedia does not require an additional software product for this capability. ESRI ArcGIS products are much more suitable for the GDMS and are recommended for use. The routines available in 3D and Spatial Analyst extensions, along with possible use of the Geostatistical Analyst extension, have been in use far longer than the corresponding GeoMedia routines. There is a large informal support community for the ESRI products, with a wide variety of scripts and techniques available for the types of analyses GDMS users are likely to need. The vendors of specialized products, such as RockWorks and EQuIS, look to integrate their offerings with ArcGIS to build a comprehensive system. However, an ArcGIS solution may have higher initial and ongoing maintenance costs due to the use of the ArcSDE database middleware package.

Page 48


Assessment Report

11.4.2. Web Portal

Performing GIS-based queries and displays of information on the Internet or intranet has become a common GIS operation. The Web portal and applications will make use of map interfaces for the display of certain data, and allow the user to make selections of information through the map. Both ESRI (ArcIMS) and Intergraph (WebMap) have excellent Web GIS products. Implementing Web GIS functionality nearly always requires some custom programming and development, as the out-of-the-box tools for each product are very simple and limited in scope. Both products use standard development tools such as ASP, DHTML, JavaScript, or Java for customization. Both products will require a Web server, and both will require a fairly extensive amount of administrator support to keep the applications running smoothly. The Intergraph Web products are restricted to Microsoft’s Internet Information Server (IIS) and the methods supported by IIS; ESRI is slightly more expansive in its hosting environments, including IIS, Apache, iPlanet, IBM HTTP Server, etc. It is anticipated that the GDMS would usually make use of both vector and raster data streaming to the client. Both products will serve raster map images and vector maps to the client. ArcIMS serves raster map images with the HTML Viewer. ArcIMS serves vector data through the Java Viewer applet. Because of performance issues, ESRI does not recommend Java Viewer use in Internet applications, but it is suitable for intranet applications. Raster images with the HTML Viewer are recommended for Internet applications. GeoMedia WebMap serves vector maps to the client through the ACGM component plug-in which can only be run on Windows. The Java Viewer for GeoMedia WebMap extends the viewing environment to other platforms such as Java applications. Dynamic segmentation is a process used to map linear or point events (such as roadway data or crashes) on to a linear network (the roads), and is a common function of transportation GIS. Dynamic segmentation capabilities are required for using ODOT data referenced to the county/route/section LRS. ESRI requires the use of the ArcMap Server extension to handle dynamic segmentation functions, which negatively impacts performance and requires more configuration and maintenance support. The GeoMedia WebMap products provide high-end dynamic segmentation capability. Linear location management software routines, such as those provided with Bentley’s LDMx product, are now available which run dynamic segmentation routines directly in the database. These products work separately from the GIS software, and eliminate the need for dynamic segmentation capability within GIS applications. These routines create line and point features in the database for all event tables (tables containing linear or point events based on the LRS). ODOT may be considering the use of such software as part of an Enterprise GIS effort, which can have a major impact on GDMS data and the need for dynamic segmentation in the Web portal.

Page 49


Assessment Report

There is no known use of ArcIMS within ODOT, though it is used by other state agencies. OGE, Technical Services, and/or DoIT would have to become proficient in use and administration of ArcIMS. ODOT is most familiar with the GeoMedia WebMap product. It is in use in both the Central Office and in the Districts. Support for the product is available within Technical Services, and the WebMap user community within ODOT can provide informal support. ESRI’s ArcIMS is recommended as the Web portal GIS software. The compatibility of ArcIMS with the desktop ArcGIS products is very important. In addition, the wider variety of server and development environments may be more compatible with ODOT standards and conventions. Geotechnical analysis routines are much more likely to be incorporated or integrated in the future with ESRI’s ArcIMS due to existing vendor interfaces with ArcGIS, though to what extent cannot yet be known. The use of dynamic segmentation routines will be a small portion of the functionality of the GDMS Web GIS, which minimizes Intergraph’s better support for dynamic segmentation. Due to ODOT familiarity with the product, Intergraph’s GeoMedia WebMap would likely be the easiest and quickest for implementation, and would have the better existing support infrastructure. However, it would not provide the best functionality for the GDMS. 11.4.3. Summary

The table below provides a summary of the strengths of each GIS product for factors important for the GDMS. The factors are presented in an approximate decreasing order of importance. In two cases the products are judged equal in capability. Based on the evaluation, the ESRI products are more suitable for use for the GDMS.

Capability ESRI Intergraph

Geotechnical Use - Desktop X

Geotechnical Use - Web X

3D Analysis X

Links to Application Software X

Oracle Spatial Data Support X

Transportation Use - Web X

Transportation Use - Desktop X X

ODOT Experience With Product X

Interoperability With Other GIS Products X X

Annual Maintenance Cost (lower cost) X

Development/Customization Environment X

Web Deployment Environment X

Page 50


Assessment Report

11.5. Application Software

Much of the detailed analysis needed for geotechnical operations will continue to occur on user PCs. The Web portal will evolve over time to include many analysis and reporting functions, and may ultimately replace desktop-based software packages entirely. In the short term, though, specialized desktop software packages, or access to software through the Web, will still be needed. OGE currently uses a wide variety of software. This software includes CAD and GIS packages (MicroStation and GeoMedia), general-use applications such as Excel, WordPerfect, and Minitab, proprietary geotechnical software packages or suites such as Surfer, RockWorks99, Visual Modflow, and AQTESOLV, and FHWA-provided geotechnical software applications such as CBEAR, DRIVEN, and SPILE. OGE provided a complete list of software for use in the project assessment. The evaluation for geotechnical application software looked at numerous packages that are designed specifically for geologic and/or environmental data management functions. The evaluation focused on packages or suites that provided multiple functions within a single product, or combined multiple programs within a single suite. The intent was to evaluate and make recommendations on software that will help form the basis or foundation for the GDMS. An initial review of available products was combined with knowledge of the GIS functions desired for the GDMS and current use within engineering and consultant offices. The final review and evaluation included the more highly integrated and developed software below. Appendix A is a table of information about each product compiled as part of the evaluation. • gINT – gINT (GCA), including gINT Professional and gINT for ArcGIS. • EarthSoft – the EQuIS Subsurface Data Management and Environmental Data Management

packages. • Rockware – RockWorks2002, LogPlot2003, RockPack III, Groundwater Management System

(GMS), Visual Modflow Pro, AQTESOLV. • Environmental Simulations Int’l – Groundwater Vistas. • GEMTeck – EQWin. • Integrated Environmental Services – 3D Master, WebEDMS, eDAR, ModFlow Pro. There are many other software applications that would be used in conjunction with the GDMS (e.g., DRIVEN, LPILE, CRSP, STEDWIN). These perform very specific tasks, and were not considered as part of this evaluation. Their continued use as desktop (and ultimately Web) applications is expected. A single evaluated product would not provide all of the functionality needed for the GDMS. Products from gINT, EarthSoft, and RockWare all warrant further testing and consideration and all may find a role in the GDMS. Each of the products integrates to some extent with ArcGIS; none integrate with GeoMedia, though data exchange between the programs should be able to be accommodated. The products from Environmental Simulations, GEMTeck, and Integrated Environmental Services do not have the feature sets, user acceptance, and enterprise suitability

Page 51


Assessment Report

of the other packages. The Groundwater Vistas product from Environmental Simulations could be considered further as a groundwater-specific tool to use in the future. EQuIS from EarthSoft can be considered a data management and integration package. It has extensive and tested data management capabilities for GDMS-type data, and integrates well with other packages. In particular, it functions well in conjunction with the RockWare suite of products. It also works well as a data management partner with ArcGIS. EQuIS is not, however, a full-featured product. It does not contain many of the analysis and display applications that are required for the GDMS. A companion product like gINT or the RockWorks suite will be required to perform tasks such as log generation or surface analysis. The operation and support of EQuIS with enterprise databases such as Oracle and SQL Server is currently under development and testing by EarthSoft, and eventual functionality must be investigated and tested. This database interaction is necessary to support multiple users and applications. EQuIS is recommended as the data management product for the GDMS, provided the interaction and performance with enterprise databases is functional. The gINT suite of software provides much of the specific functionality needed for the GDMS that EQuIS lacks. gINT for ArcGIS also is integrated well with ArcGIS and can provide a very focused companion feature set. The product is strong at importing and exporting data in a variety of formats. Boring logs can be exported as DXF format and imported into MicroStation, though gINT still does not directly support the DGN file format. gINT should be strongly considered for the boring sample analysis and log generation portion of the GDMS. RockWare produces a diverse group of software products, in addition to distributing other programs like EQuIS. The RockWare suite, RockWorks2002, contains many routines to meet the needs of the GDMS, including log generation. It is not as tightly integrated with ArcGIS as gINT. The gINT product is favored over RockWorks. The individual RockWare products, such as RockPack, GMS, and Visual ModFlow Pro, should be used to fill functional needs within the GDMS. The software is widely used, and should find acceptance among the outside users of the GDMS. The RockWare products are recommended for use within the GDMS. Additional application software products may need to be custom developed, particularly products for very specific purposes in the GDMS, such as geohazard inventory and remediation. This may be especially true given the desire of OGE to have as much functionality as possible available as Web-based applications. 11.6. Image Software

The GDMS will contain a wide variety of image data types. These will range from GIS data sets like orthophotos and USGS scan maps, to scanned drawings, to scanned report pages and documents. There will not be a single image viewing tool that will work effectively with all of the image types and the way users will need to interact with different types. It can be expected that GIS tools would be used to view spatial images such as aerial photography. Document management viewing tools would be used to view imagery resulting from these systems. However, images are an integral part of the Web, and image viewing capability is

Page 52


Assessment Report

now native within Web applications and browsers. Much of the image viewing functions of the GDMS will take place as part of the Web portal, and these native capabilities can be used. 11.6.1. Document Management Software

ODOT is evaluating the Falcon product from TsaADVET as an image viewing program. TsaADVET produces and develops document management systems, with Falcon (and its components) as the viewing component. Falcon provides both desktop and Web-based viewing tools. Software such as Falcon can be especially useful for accessing and viewing images resulting from the scanning of multiple page documents like reports, and for engineering and other CAD drawings. Falcon components should be used for some image viewing tasks within the GDMS, particularly for those tasks where the specific Falcon tools provide needed functionality. For example, the links between multiple-page scans are contained within Falcon, and the pages may only be viewed in a seamless manner with the Falcon software. Falcon tools should also be used for viewing and manipulating engineering documents, as Falcon will work with CAD formats such as .dwg (AutoCAD) and .dgn (MicroStation). 11.6.2. Web Viewing Tools

The GDMS will include scanned project cards, design drawings, and other plans. Much of this material will be made accessible through the Web portal, and suitable Web formats (TIFF, JPG, GIF, PNG) should be used for these images, or the images stored in a database. These methods are directly supported by browsers, so that images can usually be displayed and viewed without much programming required. If viewing tools such as pan, zoom, or magnify are needed, the tools can usually be readily programmed directly in the Web application, and not require external software. TsaADVET provides the Falcon WebSuite product, which allows document images in the document management system to be viewed through the Web. Such images can also be edited or updated through the Web. The functionality provided by WebSuite or other viewing programs should be evaluated against system functional requirements to determine where different viewing tools are best used.

Page 53


Assessment Report

1122..00 CCoonncceeppttuuaall DDeessiiggnn

This section describes a high-level conceptual design for the GDMS. The conceptual design describes the potential workings of the system, provides information to move forward with design and development, and lays out a potential architecture. The conceptual design is not a specific task of the assessment project, but it is provided here to help ODOT visualize how the GDMS would be constructed. 12.1. System Vision

It is clear from the interviews and survey that users envision a broad, encompassing system that can serve as a “one-stop shop” for geotechnical information, while also providing the detailed functionality to meet their particular needs. The GDMS would serve to improve geotechnical operations within ODOT. It would also serve the geotechnical user community within Ohio and around the region. 12.1.1. Modular Development

To meet this comprehensive vision, the GDMS should be designed and built in a modular fashion. It will ultimately be a large and complex system, but it does not have to be built as a single large system. As long as the system vision, goals, and objectives are followed, the GDMS can be developed as a group of system components. The GDMS should be designed and built as a series of modules that can be easily accomplished within short (approximately one year or less) time periods, with reasonable budget outlays and focused project management. These modules can be pieces of the Web portal, conversion of data, integration of programs, or similar efforts. This section describes many of the potential modules. It is important in building enterprise systems that success be achieved early and often. This will maintain both user enthusiasm and upper management support for the system. If functional pieces of the system can be rolled out on a regular basis, users will make use of them and be ready with additional ideas. As each module is completed, planning and design for the next should begin. ODOT should re-visit system requirements and technologies at each step to make certain that new ideas and methods can be incorporated. 12.2. System Architecture

In keeping with the idea of modular development, the GDMS technology architecture should be thought of as a collection of components. Each of the pieces can be developed and installed individually, though all will work off important central components. The central components can be developed in steps as well; for instance, the GDMS database will grow as different functional areas are brought online. The diagram on the following page illustrates the conceptual design of the GDMS. The modules and components of the system are described below. Each description will attempt to provide

Page 54


Assessment Report

information about the infrastructure pieces (hardware, software) that may be required for implementation.

DatabaseDrilling Data

GIS DataHistoric Data

etc.

StructureInformation

HistoricData

Input(Examples)

Use(Examples)

GeohazardInventories

Constructionand

MaintenanceNotes

Cities,Counties,

OtherStates

Boringsand Lab

Data

Server(s)DatabaseWebFile/imageAuthenticationApplication

Core GDMS

Field Data Collection

Internet

Desktop SoftwareAnalysis

Firewall

Consultant Data

Research andInformationConsultants

Cities, CountiesCollegesFederalPublic

ArchiveView

Research

IntranetWeb Portal

ResearchQuery

Analysis

Page 55


Assessment Report

12.2.1. Core System Components

The GDMS will employ core components that will serve the rest of the system. These items, in the center of the diagram, are represented as the database and servers. The database, using a DBMS product, will house, manage, and provide nearly all of the system’s data. All tabular data will be in the database, most or all of the GIS data should be in the database, and the database may also house and manage image data. As described in the previous section, the recommended DBMS for the GDMS is Oracle, using Spatial for storage of spatial (GIS) data. The GIS software recommendation is for ArcGIS and ArcIMS from ESRI; this will require the use of the ArcSDE database middleware product for the Oracle Spatial database. The infrastructure for the GDMS will be a collection of servers. These servers will have the following functions: • Database server – to house the GDMS DBMS. This will likely be the highest-end server

used. GIS data would be stored within this database. • Web server – to host the GDMS Web portal. • File/Image server – to house any file-based data, such as scanned images. Imagery could

also be housed in the database. • Application server – to host any Web- or server-based applications needed for the GDMS. • Authentication server – to handle login requests from outside users of the GDMS. There could be other servers as implementation proceeds; as new modules are developed, infrastructure needs should be identified and procured. The actual number and use of each server can only be determined at detailed design time. These servers are described as logical servers, with particular functions, rather than as physical servers. Some of these server functions could be handled by existing ODOT resources (e.g., Authentication), or could be combined into a single physical server (e.g., Web and Application). 12.3. Historical Data

The GDMS will serve as an archive as well as an access source for at least some of ODOT’s historic geotechnical data. This information will be converted and made available in the GDMS as a mixture of scanned images and data tables. 12.3.1. Project Archives

OGE has already started the process of converting the historical archive data for the GDMS. Project cards have been scanned to TIFF files, and some of the information on the cards has been entered into a database. The intent is to complete the conversion and make all of the information available through the GDMS.

Page 56


Assessment Report

The project archives will produce a significant amount of scanned images. These images can be maintained as TIFF files and placed on a file server; the GDMS would access them from the file server (functioning as an image server). Alternatively, the images may be stored in tables in the database and served as images by the database. This method may be preferable in a multiple-user system, and should be studied further. If the images-in-database approach is used, the following table shows how this data could be stored and managed. This is a sample record for the project archive. All information associated with the project can be stored as a single record. The Image field would store the scanned image as a binary or image data type, and the GIS point for the project is also stored as a binary data type. Actual structure of the table would depend on the DBMS chosen. This can greatly simplify the maintenance and backup methods needed for the full project archive.

Record ID Field1 Field2 Image GIS_Shape 23 1745 45 Low Binary data Binary data

12.3.2. Mainframe Lab Data

Lab test results prior to 1996 were managed in a mainframe-based data store. This information may still be accessible, and if so, may be useful within the GDMS. The data may be able to be extracted from the mainframe. A database design would be needed within the GDMS to store and use this data. 12.4. Borings (Operations) Modules

The current borings processes can be changed so that data is entered into and managed by the GDMS. 12.4.1. Field Data Collection

Some important drilling information may be able to be captured in the field at the drilling site, given the right equipment, procedures, and training. This information can be entered into a notebook- or handheld-type computer, and then transferred electronically into a new table structure in the GDMS. This would require the purchase of the field computer units and programming necessary to develop an extremely user-friendly and conditions-resistant data entry program. 12.4.2. Borings and Lab Data

Much of the information about borings is collected in the lab. Observations and other notes are entered onto worksheets, and lab results are captured in a Delphi-based database. A GDMS data model and database design can be used to construct borings tables in the GDMS, and procedures and programs can be developed to write borings information to these tables.

Page 57


Assessment Report

12.4.3. Consultant Operations

Consultants currently provide the bulk (80 percent) of the borings data collected. They typically provide this information as hard copy. The GDMS can include functions to allow consultants to provide their raw data as well as their analysis reports as electronic data, so it can be incorporated with ODOT-collected data. The data input functions could be provided as both a bulk submission of a data file (e.g., FTP transfer) or input of data through a Web-based input form. 12.5. Geohazards (Inventories) Modules

The various tasks associated with geohazards can be broken down into several different modules as part of the overall geohazard management system portion of the GDMS. In addition to data collected within ODOT, the GDMS should eventually host data about geohazards collected by other agencies, local governments, and others. The geohazards modules should all include both inventory information for investigation, monitoring information, and analysis routines to develop remediation procedures. The modules should also include pertinent links to regional information about geohazards, so that investigators can see what methods and procedures have been used successfully elsewhere. 12.5.1. Landslide

Information about landslide areas is collected by both OGE and Maintenance staff. The Maintenance time and materials information can be linked into the GDMS database for each location so that OGE investigators can determine the history of a site. The GDMS data should be designed so that a site can be selected and all information about the site be accessible. 12.5.2. Mine Subsidence

The current mine subsidence applications (e.g., AUMIRA) can be linked within the Web portal to allow a user investigating a site to automatically jump to the application and view any mine subsidence information. In addition, subsidence GIS data can be linked to or copied to the GDMS database and made available as a layer in the Web portal or for desktop analysis. The AUMIRA database can also be linked or copied to the GDMS database. 12.5.3. Rockfall

Rockfall operations are similar in nature to landslide operations, and these modules should be linked. The locations of incidents are nearly identical. 12.6. Structures

Information and operations associated with structures should be included. Structures staff are particularly interested in learning of test results from other parts of the state and around the region. Their own test results should be made available through the GDMS.

Page 58


Assessment Report

12.7. Materials

Materials and testing staff want to know regional aggregate conditions, as well as the result of tests on materials and pavement. Information collected by materials operations should be linked or copied to the GDMS for accessibility. 12.8. Construction

Records and notes collected by ODOT staff during construction projects should be electronically captured. Some of these notes pertain to geohazard or structural conditions discovered during the construction phase, and should be added to inventory information. 12.9. External Information

OGE currently uses a wide variety of external data sources to aid in its investigations and reviews. This data includes soil maps, water well records, geologic maps, oil and gas records, etc. This data exists as GIS layers, database tables, and hard copy. This information should be linked or copied to the GDMS for use. OGE will have to work with external data providers to make certain that the data is up-to-date, valid, and suitable for inclusion in the GDMS (i.e., is electronic). 12.10. Additional Modules

The OGE-supplied diagram in section 4.1 shows many functions of the GDMS. The modules described in this conceptual design do not cover all of the functions described in section 4.1. Conversely, some of the modules described in this section are not shown in the OGE diagram. The OGE diagram shows functional areas of the system, while the conceptual design describes components of the system. There is not necessarily a one-to-one correlation between functions and components, as one component can cover multiple functions, while one function can be implemented in multiple components. The conceptual design has been provided to illustrate the potential system as it is developed. It is not meant to be inclusive of all potential components or functions.

Page 59


Assessment Report

1133..00 NNeexxtt SStteeppss

The development of the GDMS will be a multi-step, multi-year process. It should follow a systematic and cyclic approach to make certain that user expectations are continually identified and addressed. The following steps are presented as a guide for ODOT to use to more fully develop the system. The steps should be repeated as additional modules or components are added to the GDMS. 13.1. Functional Requirements

Interview users and potential users of the system and identify what they want the system to do for them. Identify the applications that they would like to use and how those applications should be delivered to them. Identify data sources and users, and determine level of data accuracy required. Prepare high-level estimates of work effort to meet requirements. Work with users to prioritize requirements and develop an implementation schedule. 13.2. High-level System Design

A team of system designers, developers, and administrators should prepare a high-level system design that describes and diagrams the major components of the system. The high-level design should describe data collection, transformations, and flow among components. It should describe interoperability of system components. It should also describe user interfaces and output options of the system. The high-level system design should be reviewed and approved by all appropriate system managers before proceeding with a detailed design. 13.3. Detailed Design

The team of system designers, developers, and administrators should prepare a detailed system design of all proposed components. The detailed design should include specifications for all hardware and software components. It should include database designs for all data elements. It should include coding approaches for all custom-programmed software elements. It should include details on all off-the-shelf software products used. The detailed design should be reviewed and approved by all appropriate system managers before proceeding with system development. 13.4. System Development

System development activities can include procurement and configuration of hardware and software products and programming of system components. System development is usually the most costly and long-term step. System development should include multiple layers of testing, including final user testing and acceptance.

Page 60


Assessment Report

13.5. Training

Training of users should occur whenever new functionality is added to the system. The training may include the production of hard copy or online user’s guides. System administrators should also be trained in how to manage new system components. 13.6. Maintenance

A maintenance plan should be prepared for each round of system development. The maintenance plan will provide guidance for system administrators and developers responsible for upkeep and debugging of the system. The plan should include information on configuration management of hardware and software components to help guide update and upgrade activities.

Page 61


Assessment Report

1144..00 AAppppeennddiixx –– SSooffttwwaarree AApppplliiccaattiioonn EEvvaalluuaattiioonn NNootteess

Manufacturer Product Purpose and Functions ComponentsApplications Supported

gINT gINT (GCA)

ArcGIS package: fence diagrams, boring logs/ gINT Logs: boring logs, Atterber limits tests, seive analysis test

gINT Professional; gINT log Writer, gINT Logs, gINT for ArcGIS

gINT for ArcGIS, BORING AND BOR HOL LOGS, WELL LOGS, FENCE DIAGRAMS, GEOTECH LAB TESTING

EarthSoft EQuISEvironmental Data Management and Subsurface Data Management

Geology, Hydrology, DMR (Discharge Monitoring Reports), DQM (data Qualification Module), ELDC (Eletronic Lab Data Checker), CARStat, DUMPStat, Desktop Dashboard, Limnology and Chemistry: integrates ArcView EVS, GMS, LogPlot, RockWorks

supports LIMS (Laboratory Information Management Systems), Lithography/Stratigraphy, point to point transects, data review and validation, EZView (time series), Surfer

Rockware LogPlot2003 Log Plotting Software, create bore logs Log Designer, LogView, Data Editorcross sections, Bore Logs

Rockware RockPack III

Package of programs useful for all phases of rock slope analysis and design where stability is controlled by the orientations and characteristics of rock mass discontinuities (joints, bedding, foliations, faults, etc).

Kinematic stereonet analyses (Dip Vector Plot, Pole Plot)/Plane, wedge, and toppling safety factors

Applicable to practically all rock excavations, including highway roadcuts, quarries, mines, and building excavations

Rockware GMS Groundwater simulation

Modules: Map Module, Subsurface Characterization (Borehole, TINs, Solids), Mesh (2D & 3D Mesh modules), Grid (2D & 3D Grid modules), Geostatistics (2D & 3D Scatter Point modules), Stochastic Module, -Interfaces: MODFLOW Interface, MODPATH Interface, MT3D Interface, RT3D Interface (also includes ART3D), SEAM3D Interface, FEMWATER Interface, SEEP2D Interface, Parameter Estimation Module (PEST & UCODE), UTCHEM Interface

Two and three-dimensional groundwater modeling, geostatistical analysis, stratigraphic modeling

Rockware Visual MODFLOW Pro

Groundwater flow and contaminant transport with 3D

Visual MODFLOW (MODFLOW, MODPATH, MT3D, RT3D), 3-D Explorer, WinPEST, MT3D99, MODFLOW-SURFACT

Rockware AQTESOLV Pumping, Slug and Single Well Tests Standard and Pro Versions

Determination of aquifer properties based on pump and slug test

AutoCAD

Environmental Simulations Intl)

Groundwater Vistas 3D Groundwater Modeling MODFLOW, MT3D, MODPATH

GEMTeck EQWin Environmental Database Management EQWin Data Manager ver6.0

Integrated Environmental Services

3D Master, webEDMS, eDAR, Processing Modflow Pro

webEDMS-environmental management & site analysis, 3D Master- 3D model for environmental assessment, eDAR-field collection, Modflow Pro- Groundwater Modeling MODFLOW Suite

Page 62


Assessment Report

Product Native Data Formats Data Import

Formats Data Export

Formats Output Formats Databases Supported

gINT (GCA)

PDF, XML, Correspondence File Editor, Contouring Export, Excel, RockWroks Export, LogPlot Import, Winlog Import, DXF, RASTER, HPGL 1,

DXF, RASTER, XLS, CSV, GEN IO, PGF, DBF, AGS

Access, FoxPro, dBase, Paradox, Oracle

EQuISEQuIL (EquIS Interface Language)

GMS and gINT formats

STORET, HTML, XML,

x sections, CAD, 3D visualization, reports, crosstabs, 3D DXF

GMS, EVS, 3D DXF, Excel, Word, Surfer

LogPlot2003DAT file, ASCII, LDF, LPT LAS, ASCII, DBF

LAS, RockWorks2002 BH file LPT, WMF, EMF, BMP, JPG, HTML

EQuIS database software is a database the exports to LogPlot2003 DAT files

RockPack III

CSV for stereonet data, PLN, RAP, CMP and TPL for Plane, Rapid Wedge, Comprehensive Wedge and Toppling Failure Analyses CSV, TXT CSV, TXT BMP None

GMS GPR – Project File

DEM, DXF, DWG, ArcASCII Grid, Shapefile, JPG, TIFF, Surfer ASCII Grid

DXF, DWG, ArcASCII Grid, Shapefile

Data sets can be saved in ASCII format by right clicking on the data set in the Data Tree and selecting the Export command from the pop up menu. For both file formats, multiple data sets can be stored in a single file and both scalar and vector data sets can be saved to the same file. The file format is identical for 2D and 3D data sets.

Database Import Wizard supports same data types as Text Import Wizard

Visual MODFLOW Pro

MODFLOW ASCII file, DXF, BMP, SHP, TXT, Surfer ASCII GR ASCII AutoCAD (.dxf), EMF, TecPlot ASCII, SHP None

AQTESOLV .AQT - binary CSV, TXT, DAT, LEV, PRN

TXT, type curve, Surfer GRD EMF, WMF None

AutoCAD

Groundwater Vistas

ArcView data, MODFLOW, ModelCad, Flowpath, SURFER, ASCII

SURFER, Slicer, DXF, BMP, WMF, EarthVision, EVS, Tecplot, ASCII, ArcView data

EQWin

MicroSoft Excel (using COM technology), XML

ACCESS (MicroSoft JET), SQL, Oracle support being developed

3D Master, webEDMS, eDAR, Processing Modflow Pro

3D Master displays DXF, SHP, BMP 3DMaster-BMP 3D Master-*.avi

Page 63

geotechnical data management system · odot uses a large amount of drilling and laboratory test...

Documents