How to Integrate ArcView, DLLs, DDE, RPC, and Version Control in a True 3D Application of ArcView for an Underground Waste Repository

Daniel Elroi
GIS Manager
Knight Piésold LLC

Rey Carrasco
Senior Engineer
Westinghouse Electric Corporation

Introduction

The Waste Isolation Pilot Plant (WIPP), located in Southeastern New Mexico, is a US Department of Energy underground facility designed for the safe disposal of low-level radioactive waste. Half a mile under the surface, a stable and layered salt structure will ultimately entomb up to 6,200,000 cubic feet of "transuranic," or heavier than Uranium, nuclear by-products of the defense industry. It is the plasticity of salt that provides for a permanent and impervious medium in which to place the waste. It is also this characteristic of salt which is the target of intensive research by the Geotechnical Engineering department at WIPP. Thousands of instruments, mounted in the floor, roof, and walls of the underground repository, have been recording ground movement measurements for over a decade. Accessing, analyzing, and displaying these instruments and their readings in a three dimensional space, are the purposes of the Spatially-referenced Geotechnical Information System (SrGIS), currently being developed by Knight Piésold LLC for Westinghouse Electric Corporation (WEC), the Management and Operating Contractor (MOC) of WIPP. The system takes advantage of the latest developments in ArcView 3, ArcInfo 7.0.4, Excel, Visual dBASE, and Delphi, and will operate in the Windows NT and Windows 95 environments.

WIPP

WIPP has been in construction under the New Mexico desert for over a decade, and is scheduled to start accepting waste in 1998. Over 6.5 miles of "drifts," or tunnels, and repository rooms, have been excavated. Under the pressure exerted by a half mile of overburden, salt deforms, or "creeps," to close any fracture which might form, thereby making the rock impervious to ground water. Over time, salt will actually fill in the entire repository, surrounding the barrels of waste. The plastic quality of salt, while essential for keeping the waste safely stored for at least 10,000 years, is also of concern to the geotechnical engineers responsible for keeping the repository safe for people and equipment during the twenty five of years of projected operation, before WIPP is sealed.

Ground Movement Measurement and Analysis

Over the past decade thousands of instruments have been installed underground by Westinghouse Electric Corporation, the MOC of WIPP, as well as by Sandia National Laboratories, the scientific advisor to the Department of Energy. Some of these instruments, such as extensometers, are buried deep in the rock, and measure the extension of the rock towards the exposed surfaces. Other instruments, such as load cells, are mounted on the end of roof-supporting rock bolts, and measure the load applied to those bolts. These instruments are connected electronically to computers which can automatically measure readings from the instruments. Other instruments are measured manually, such as tape extensometers used to measure the convergence of the roof and floor or opposite walls in the repository.

Geotechnical engineers are interested in the rate of closure of the underground spaces, in any changes in that rate at various locations, in any unusual ground movements, and in the correlation between ground movement and activities such as excavation. Understanding rock behavior guides the engineers in implementing mitigating activities, such as scaling portions of the repository surfaces which had begun to deteriorate, installing a steel mesh and a dense network of roof support bolts, and even permanently closing a portion of the mine to any further activities. Every instrument which has ever existed underground, and many have been destroyed through mining operations or have become otherwise unusable, has been plotted on a paper map. All of the maps are maintained in a CADD system. Most readings generated by these instruments, whether they are manually read by a technician, or are automatically measured by a computer, are entered into a dBASE database.

Until 1995, an engineer wishing to analyze a set of measurements from a portion of the mine, would have had to locate the correct set of paper drawings of the mine, identify the instruments from these maps, and note down their numbers. Next, the engineer had to manually enter these identification numbers into a dBASE application which came up with a set of readings. The engineer would then transfer the data to Excel, which did not usually reside on the same computer as the dBASE database. There the engineers would graph, chart, and otherwise study the results. This was an exceedingly tedious task, and reduced the number of times engineers were willing or able to inspect their data.

The SrGIS

In 1995, Knight Piésold LLC, working under contract to Westinghouse Electric Corporation, developed a prototype of the Spatially-referenced Geotechnical Information System (SrGIS), which will replace the manual techniques described above. The system, now under final implementation, consists of ArcView 3, Visual dBASE 5.5, Excel 5, and Delphi 2, all operating under Windows NT and Windows 95, and ArcInfo 7.0.4, operating in UNIX. The system utilizes a network of Pentium PCs and a single Silicon Graphics Pro Indigo2 workstation. The system is designed to give engineers an integrated software solution to the data access, analysis, and display requirements at WIPP.

The preexisting software packages, dBASE and Excel, were retained and incorporated into the SrGIS for two purposes: to provide stronger database and graphing capabilities than those provided within ArcView, and to make the most of the existing expertise present among the engineering staff in these software packages. The system's chief strengths are based on adding the spatial component to the system, tying the software packages together in a user-friendly fashion through Dynamic Data Exchange (DDE), and placing a common interface on top of these packages through forms and menus created in Delphi.

The SrGIS is designed to allow a user to identify instruments in the repository interactively, or through spatial query building, in ArcView. The attributes of these instruments are then studied or further refined in dBASE, with information passing back and forth behind the scenes, through Windows-based DDE technology. Conversely, a tabular query performed in dBASE is then displayed and further refined in ArcView. The results of the combined spatial and tabular query are then passed on to Excel, where they are charted and graphed. The resultant graphs are then passed back to ArcView, where they can be incorporated into a layout, and then printed. There are other adjunct software packages associated with SrGIS. For example, scanned images which are associated with instruments and underground boreholes (which are also mapped), are viewed not through ArcView's native image viewing software, but through Delphi DLLs designed especially for image retrieval. Metadata documentation is handled through a separate package, as are on-line documentation and help files.

ArcView in a Three-Dimensional Space

Using the old method, one of the chief obstacles to understanding ground movement behavior in the repository had been the fact that instruments were only mapped in two dimensions, in plan view. Although experienced engineers could tell that certain instruments were only typically placed in the roof of a room, for example, overall the distinction between instruments mounted in the roof, walls, or floor was difficult to discern. The SrGIS needed to represent these instruments, which are located in three-dimensional space, in a way that could help engineers in both instruments selection and data visualization. To do this, engineers had to be able to visualize precisely which surface an instrument is attached to or embedded in. This was to be done using technology that is not prohibitively expensive, thereby making it available to as many engineers in the group as possible.

ArcView 3, which like other GIS packages is not three-dimensional in nature, was programmed to handle this three-dimensional puzzle. Fortunately, the WIPP repository lies in a single stratum of salt, and consists of fairly level, and for the most part only north-south and east-west trending spaces. Therefore, it was possible to divide each space into its three components dimensions: plan views of the mine are represented in an XY coordinate space; east-west views are represented in XZ coordinate space; and north-south spaces are represented in a YZ coordinate space. In addition to a plan view of the repository, which is always visible to the user, there are also six optional views of any particular space: a floor view and a roof view (both seen from above), north wall and south wall views (both viewed from the south), and east wall and west wall views (both viewed from the east). Any instrument only appears in one of these directional views, thereby eliminating any question as to where an instrument is located. Whereas in the simple plan view it is unclear whether an instrument is placed in the roof or floor, in the directional views this instrument will only appear in the floor view.

All six directional views are tied to each other through Avenue scripts, so that panning or zooming in one view, also pans and zooms in all other directional views. This closely simulates actual movement through the repository. All instrument selection is also linked, so that selections made in one directional view also affect the selection in the other directional views and in the overall plan map of the mine.

DDE Communications with Visual dBASE and Excel

Because it was decided to capitalize on the primary strengths of three different software packages - ArcView for spatial data, dBASE for tabular data, and Excel for graphs - the SrGIS needed to facilitate seamless communication of data between these packages. This can be accomplished with Dynamic Data Exchange (DDE) or Object Linking and Embedding (OLE) Windows-based technologies. However, ArcView does not support OLE communication, so this left Dynamic Data Exchange (DDE) as the only viable method. Fortunately, DDE is effective for the type of data exchange needed in the SrGIS: the passing of data queries back and forth between the three packages. Records selected spatially in ArcView are also selected through similar queries in dBASE, as well as in Excel, and vice versa. For this communication to occur, each of the three software packages must be opened in Server mode, allowing the other packages to issue Client requests. In the SrGIS ArcView is the first package to start up, and it automatically initializes in Server mode. Then, prior to data being passed on to dBASE, for example, the user must make a menu selection which also starts dBASE in Server mode.

One of the issues encountered in implementing DDE connectivity had to do with the instability of Windows 3.1 and 3.11 for Workgroups during the initial prototyping of the system. It was demanding on the system to have all three software packages be active at the same time, in terms of memory and other resources. It was more difficult to actually maintain all three packages functioning for extended periods of time without crashing Windows. With the migration to Windows 95 and Windows NT, many of these problems were resolved.

Another issue was that of transferring the graphic results of each software back to ArcView for display in a layout. In the absence of OLE capabilities, which would solve this problem quite elegantly, graphics have to be saved in both dBASE and Excel, and then imported as graphics into ArcView layouts. Though an unfortunate disability, this has not posed a fatal flaw in the design of the SrGIS.

One final issue related to exchanging information between the three packages has to do with incompatibility in items types and indexing methods. Although ArcView and dBASE share the same .DBF files, they do not share indexing methods of these files. As a result, ArcView's searches are quite slow compared to dBASE's searches. An ability to utilize dBASE's faster indexing would be a welcome enhancement to ArcView. Also, dBASE and ArcView each possess certain item types which cannot be read by the other package: ArcView's Shape fields, and dBASE's image, sound, and note items. These items either appear blank or as nonsensical characters when viewed by the other software.

Delphi DLLs as GUI Components for the SrGIS

One of ArcView's most notable shortcomings is its inability to create elaborate forms. For this reason, Esri recommends that a third-party GUI tool be used, with Microsoft's Visual Basic appearing to be favored. Although the prototype of the SrGIS was created with Visual Basic forms, it was found that Borland's Delphi provided much stronger tools. The most significant advantage of Delphi is that its forms can be encapsulated in Dynamically Linked Libraries (DLLs), a Windows-based method for sharing code between different software packages. DLLs can be loaded directly into ArcView, at which point they can be treated as Avenue objects. The best that Visual Basic can offer in this regard is encapsulation in executable .EXE files. Visual Basic EXE files are not "self sufficient" in that they require other files to be copied into the computer and placed in specific directories, before they can function. Delphi appears to have a very rich set of custom controls, or widgets, available, and compiles very quickly. Its language, Object Pascal, is not as broadly known as Basic, but, as its name implies, is object oriented, and presents additional advantages. One item to consider when using Delphi-created DLLs is that ArcView running in a 32-bit environment (i.e. Windows NT and Windows 95) requires 32-bit compilations of the DLLs. This can be accomplished with Delphi version 2. The same application still running in Windows 3.1 or 3.11 will need the DLLs to be compiled for their 16- bit operating environment. This is a minor inconvenience considering the advantage of being able to create complex and "intelligent" forms in conjunction with ArcView.

RPC Connection Between ArcView and ArcInfo

The data conversion activities necessary to create the database for the SrGIS were carried out, almost in their entirety, in ArcView. This was not mandatory, and it is possible that ArcInfo would have provided more powerful tools for conversion. However, the conversion tools were designed in such a way that they will also be used for future data maintenance and update activities. By designing the conversion process in ArcView, a more flexible and intuitive user interface was created. The disadvantage of this approach mainly revolves around ArcView's limited topological tools. For this reason, certain conversion maintenance and quality control activities need to be performed by ArcInfo, and this is accomplished through Remote Process Call (RPC) technology. A single license of workstation ArcInfo, in Server mode, is available on the network at any time. Then, when an activity which requires ArcInfo is reached, a menu selection is made in ArcView, which submits the process to ArcInfo. The status of the job is returned to the user's screen. This is an economical way of utilizing ArcInfo, since the server function automatically queues requests arriving from different clients, and executes them in sequence. Only one license of ArcInfo is required in this configuration.

Multi-Programmer Development Using Source Integrity Version Control Software

The SrGIS was developed by a staff of three programmers and three analysts. Since ArcView projects consist of a single file that incorporates all components of the project, a method for allowing several programmers to work on the project simultaneously needed to be devised. Three methods were devised: modularizing the project, unloading Avenue scripts to ASCII files, and employing version control software to manage scripts, APR files, and even documentation files and user manual pages.

Modules in ArcView are necessary not only to allow multiple programmers to develop a single project at the same time, but also to reduce load time when the user starts up the project and to reduce the project's memory requirements when running. In ArcView 3 there is a method for creating Extensions, or modules, which can be loaded or unloaded into ArcView at run time. Since SrGIS was developed mostly in ArcView 2.1, a different method was devised to "load" all the components of a module into ArcView at run time. A module consists of an Object Database (ODB), which in turn consists of all the objects (documents, GUIs, scripts) required to run the module. ODBs look very much like APR files, and are structured in the same way. In order to utilize ODB modules, it was also necessary to modify the Save function of ArcView, so that if a user saves the project in a modified state, the currently loaded modules would not also be permanently saved into the project. This modified Save function first excludes the currently loaded modules' objects, before creating a modified APR file.

Because several programmers may work on the same module at the same time, and also because scripts from one module may need to be used in another module, it was necessary to create a method for automatically "unloading" all scripts from each module to ASCII files. This action takes place when a programmer finishes work on a module for the day. The next time the module is opened, these programs are reloaded. Any modifications created in the mean time by another programmer will now be loaded into the project. This process is also a prerequisite for the third method of multi-programmer development.

In a complex and dynamic application development environment, it is important to keep track of different versions of the project components, and to centralize a good version of the components. These functions, plus the ability to archive projects, "freeze" code at milestone events, to roll back through versions, and to branch off development, such as at a time when the same program needs to be modified differently for 16-bit and 32-bit environments, are accomplished with version control software. Knight Piésold selected MKS's Source Integrity to manage all components of the project. At pre-determined intervals each programmer and technical writer checks in the latest version of their documents, and then resynchronizes their workspace with the central repository of project files. Source Integrity works well in a networked environment, in a fashion that might be familiar to users of ArcInfo transactional libraries - only one person can edit a particular file at one time, but many users can view the file. An added feature of Source Integrity is its ability to write version history back to the header of each ArcView script, which is extremely useful to programmers.

Conclusions

The SrGIS stretches the envelope of desktop GIS technology in many ways. First, it applies what is known as a two-and-a-half dimensional software to a three-dimensional setting. SrGIS may well be the first true implementation of GIS in an underground mine, for the WIPP is essentially a mine. Second, it successfully connects many different software packages to ArcView, in a way that sounds good on paper, but is quite difficult to accomplish in practice. Even if the programming is sound, without the new 32-bit desktop operating systems it is doubtful if the SrGIS could operate in a stable fashion for more than a few hours at a time. Third, it is a demonstration of the ability to stretch the capabilities of ArcView from within, through the use of DLLs created by other software packages. This is an important test of this capability, since as ArcView gains in analytical capabilities, it will be ever more beneficial to be able to enhance ArcView in this way. Finally, the things that were possible to do with ArcView on a PC in the SrGIS, cannot be done in the UNIX environment. Although there is a desire to construct tools in ArcView which help maintain its cross-platform capabilities, this is a very limiting approach, in view of the numerous PC-based extensions which are available to the enterprising programmer, and which have made the SrGIS project a success.