Brian Biggs, Eric Olsen, Kimberly Patraw, Tom Van Niel, Allan Falconer, and R. Douglas Ramsey

Removing Dilbert from GIS - Creating a User-
Friendly Management Tool for Military Installations


Paper Subject: ArcView applications, Programming with Avenue

Abstract:

Geographic Information Systems are notorious for their UNIX-like command line interfaces. Such systems typically require a "Dilbert" computer whiz to operate, and products or analyses from them are often viewed with black box skepticism by the resource manager. This entire mind set is now changing with the introduction of the ArcView software package combined with the Avenue scripting language. Applications may now be created in a user-friendly windows environment where the resource manager has access to analyses tools without having to learn cumbersome command line syntax. A highly functional management application has been created for use by military installation managers. Behind the scenes scripting facilitates real-time operations that would normally take several hours under a command line format. Some features include: adding themes with intelligible nomenclature and optional preformatting, complete access to metadata and on-line help, standard one-touch map layout printing, GPS locational pinpointing, and full-featured spatial database analyses with chart display and statistical verification. Lastly, the application is written to CDROM to improve quality control and minimize accidental erasure.

Introduction:

In 1993, the Army National Guard Bureau (NGB) contracted with the Department of Geography and Earth Resources at Utah State University (Allan Falconer and R. Douglas Ramsey, Principal Investigators) to design and build a "Nationwide Decision Support System Using GIS". This contract stemmed from the Integrated Training Areas Management (ITAM) program in response to the requirement of bringing together diverse, multi-scale land management data for use in mediating training and environmental needs at NGB installations.

This project, here on referred to as the National Environmental Database (NED), has collected several gigabytes of national, ecoregional, state, and installation level data; see Ramsey et.al., (1995). Over the past few years, the project team has developed a sophisticated suite of ArcInfo AMLs to create a highly user-friendly menu driven display and analysis system. While this approach worked well in the research arena, it became increasingly apparent that the system had drawbacks towards implementation.

The largest obstacle faced by the AML interface was its requirement of costly ArcInfo software. While the Department of Defense is often characterized as overflowing with money, equipping each of 250 plus installations with ArcInfo and a qualified technician is not within their budget. Secondly, programming for multiple platforms in the AML language is not a trivial task. Solving this problem by equipping each installation with a workstation would not fall within budget. Finally, AML routines were not designed with the intent of building a high level graphical user interface. This makes programming extremely cumbersome and time consuming.

ArcView 2:

With the release of ArcView 2.0 combined with the object-oriented Avenue programming language, the NED team decided to convert the entire project to the new software. While this task seemed daunting, we were pleasantly surprised to find the ArcView interface very straight forward and the Avenue language high level enough to make the conversion nearly painless.

We decided to focus on the installation as the scale of primary interest as most training decisions and environmental impacts are focused at this level. The pre-conversion NED database had data and scripts available for three installations: Camp Williams, Utah; Orchard Training Are, Idaho; and Camp Ripley, Minnesota. Within six months time we were able to convert these installations, add three more (Camp Roberts, California; Camp San Luis Obispo, California; and Camp Grayling, Michigan), and vastly improve the functionality over the previous AML interface. Six installation CDROMs were sent to Esri for production and packaging in March, 1996.

At the beginning of the conversion process, work was divided into three tasks: interface design, analysis development, and data processing. The interface design is discussed in this paper, and included the development of the application structure, the creation of data access tools, and the customization of the ArcView interface. The analysis development is discussed in a sister paper (Patraw et.al., 1996), and included the design of sophisticated Avenue scripts which could process and display results from existing Land Cover Trend Analysis (LCTA) data sets. Finally, continued data gathering and conversion (primarily from GRASS) was performed.

Programming Obstacles:

With the eventual goal of producing some 250 plus installation CDROMs, application portability was identified as the most important issue in the conversion process. Other factors of concern were database size, application size, and program memory requirements. The entire data set needed to be under 600 Mb in size and it needed to be able to run on a low end PC with minimal RAM.

Portability was by far the largest challenge to the team. Even with relatively few prototype installations, time spent copying scripts and editing ArcView project (APR) files became impressive. To remove this time drain and increase the portability of the scripts and application, all components of the application were compartmentalized. The APR file could then be reduced to a few necessary scripts. All possible variations among installations were compiled into a very small global variable script. In this way, APR files were reduced to under 150K, and the time to process a new installation APR (excluding data) was reduced to about ten minutes.

In order to compartmentalize the various pieces of the application, object database (ODB) files were used extensively. An ODB file is an ArcView specific document that saves all of the necessary components of a view, theme, menu, etc., outside of the APR file. Any customized portion of the application is saved as an ODB file and is loaded when required by the application. For example, each installation has a separate "Installation View" that contains basic data layers such as the installation boundary, impact are, roads, and streams. Under normal ArcView procedure, this view would be saved in the APR file and loaded at the onset. If this method were used, each installation would have a non-generic APR file, and any change in this view would require that the APR be changed. Also, if all views, menus, etc. were saved in the APR, it would become prohibitively large, and take too long to load. Some installations have six or seven separate views each containing separate coverages with corresponding symbology. If all of these views were saved in the APR file, it would be megabytes in size, take over ten minutes to load, and consume all of the available RAM. By saving each view as an ODB, these problems are avoided.

Installation View

As with views, accumulations of Avenue scripts in the APR file poses a problem. Scripts are not necessarily a load time or memory challenge, but updating generic scripts in multiple APR files can be extremely time consuming. Any small change needs to be updated in each APR file, and both the time consumed and the possibility of missing one APR file increases as the number of installations increases. The following solution has been taken. The majority of scripts are generic to all installations, so we store the generic scripts in a single directory and create a logical link to them from each installation database. When an installation APR is loaded, it loads the generic scripts from the single directory. This method removes the scripts from the APR, decreasing its size, and disallows the possibility of forgetting to save any of the updated scripts in any of the APRs. For any script specific to an installation, a special script directory is available. We have also initiated a script check out policy where a person updating any script runs a program that records their name and the script name in a table. If another person tries to check out the script, he is informed that it is already checked out. This procedure eliminates the possibility of two people editing the same script at the same time.

Similar to views and scripts, menus and menu items may be generic or installation specific. Each customized menu or menu item is saved as an ODB and loaded as required by the application.

Tables posed an initial challenge to the analysis script team. All of the tables were first saved with the APR file. This again increased the size of the APR file and made updating the APRs extremely cumbersome. ArcView loads tables into RAM causing memory challenges and aliases field names containing special characters. This causes havoc to programmers not familiar with this procedure. As a solution, all tables are left out of the APR, and accessed solely by their VTabs (obtained by filename) or FTabs (obtained directly from a theme).

Lastly, themes had to be dealt with in both a user- and programmer-friendly manner. We decided to separate themes into four categories: cultural, environmental, military, and state. The first challenge was to provide the user with a recognizable theme name. Since the applications were designed for use on the PC, the 8.3 naming convention was adopted. This convention leaves little room for comprehensibility, and we did not want the user to have to interpret "gdwatcont" as being "Ground Water Contours". We solved this problem by creating a table containing both the filename and a comprehensible name for each coverage. Next, metadata is provided so the user can know the source, projection information, and processing history of each coverage. Finally, since many coverages have multiple classes within a given field, we added the ability to save symbology with the coverage.

Choose Theme Type

Choose Theme

Each installation APR is composed almost entirely of a start-up script along with a couple routine scripts. The start-up script first displays a banner image of the location of the installation, and then proceeds to load in the necessary initial application items (e.g., general scripts, Installation View, etc.). An important function of the start-up script is to verify that two specific environmental variables are set. These are the "HOME" and "WORK" variables. The "HOME" variable (preceded by the three letter installation code such as "ROBHOME" for Camp Roberts) is the directory path to the installation CDROM. This variable allows the scripts to access the data. The second variable (e.g., "ROBWORK"), is required so that some of the scripts may write temporary files to disk, and save output files. If these variables are not set, or are set incorrectly, they must be entered into a message box and they are then set by the script for the user. The start-up script also runs a preset script of global variables unique to each installation.

Set Environmental Variables

Script Summary:

For the project, almost 40 general scripts containing over 2600 lines of code were composed. The following is a brief description of some of the more important scripts:

Chart Maker

The Chart Maker button is available from the Chart GUI, and allows the user to create a standardized layout of a chart. The user is prompted for a title, subtitle, and paper dimensions. The script then creates a layout which can be printed by typing the name of a printer on the "Printer:" line and pressing "OK".

Map Maker

The Map Maker button allows the user to create a standardized map from the current view. The user is prompted for a title, subtitle, paper dimensions, and view format. A layout is created and can be printed by typing the name of a printer on the "Printer:" line and pressing "OK".

If the user selects "YES" for the "Preserve view frame?" option, Map Maker draws the current visible portion of the view as large as possible given the chosen map dimensions. The alternate choice (preserve scale) draws as much or more of the visible portion of the view as possible given the chosen map dimensions, and the current scale

Map Maker

Meta Data

The Meta Data button (labelled DATA) retrieves the metadata text file for the first Active Theme in the Active View. This allows the user to examine the origin and processing history of the data layer of interest.

Photo View

The Photo View button brings up a list of available photos, allowing the user to choose one. The chosen photo is loaded as an ArcView view and displayed.

Script Load

The Script Load script is an internal application script which allows Avenue scripts to be loaded directly from disk.

Surface Danger Zone

The Danger Zone tool (labelled DZ) starts a script which calculates and draws a standard surface danger zone/range fan for a variety of artillery and other weapons. To use, either click and hold the left mouse button on a firing point and drag the cursor to create a trajectory, or click once in the view window to enter a UTM origin and bearing.

Danger Zone Location

Danger Zone Choice

Danger Zone Draw

Theme Add

The Theme Add button allows the user to load cultural, environmental, military, state, and other data themes. The program first searches the user-defined WORK directory (e.g., for Orchard Training Area this would be OTAWORK) for symbology saved with the Theme Save menu item, and then for updated coverages. If nothing is found in the WORK directory, the script loads the theme from the HOME directory (e.g., for Orchard Training Area this would be OTAHOME) with symbology if it exists, or with ArcView default symbology otherwise.

This means that if you want to update a coverage you can place a copy of it in the WORK directory. In addition you can save default symbology for any coverage in the WORK directory by using the Theme Save function.

Note that you can access the standard ArcView Theme Add function from this button.

Theme Save

The Theme Save menu item (in the Theme Menu) allows the user to save the ArcView symbology for any theme. The saved theme will be in a file with the same disk name as the theme with the extension ".thm"; for instance if the theme to be saved is named "soils" the theme save file would be named "soils.thm". The default location for this file is the user defined WORK directory (e.g., for Camp Roberts this would be ROBWORK).

Theme Load

The Theme Load menu item (in the Theme Menu) allows the user to retrieve theme symbology saved using the Theme Save function.

View Save

The View Save menu item (in the View Menu) allows the user to save any ArcView view to disk. The saved view will be in a file named with the first eight letters of the view name with the extension ".vw" added; for instance if the view to be saved is named "Bivouac Areas" the view save file will be named "bivouaca.vw". The default location for this file is the user defined WORK directory (e.g., for Camp Ripley this would be RIPWORK).

View Load

The View Load menu item (in the View Menu) allows the user to retrieve an ArcView view saved using the View Save function.

UTM Location

The UTM Location button (labelled XY) allows the user to enter a UTM location, whereby this function then pans the active view to center on that location, zooms in to a 1:25,000 scale, and places a red dot to mark the location.

UTM Location

Zoom to Location

Conclusion:

Due to the enormous learning curve for highly advanced GIS systems such as ArcInfo, spatially explicit environmental data has mostly been available to only highly trained researchers. Those in charge of managing land resources have been at the mercy of the researcher to supply maps and analyze data for land management decisions. Without any hands-on training with the GIS system, products are often viewed with scepticism by the land manager, and may even be disregarded to be replaced with "tradition" and "experience". With the creation of the highly user-friendly ArcView GIS, researchers are now able to design sophisticated analysis routines that are accessible to the land manager. With the land manager at the keyboard, management scenarios can be created at will, and the output will have a greater chance of being implemented over what has simply been "common practise".

A suite of software has been developed to customize ArcView for trainers and land managers of Army National Guard installations giving them access to a multitude of data. These applications are now being packaged for distribution and will provide access to previously unavailable data as well as provide analysis options for existing data that was nearly shelved due to lack of use. A new era has begun in which land managers will have options at their fingertips that they had merely dreamed of in years past.

Acknowledgments:

Funding was provided by the Department of Defense National Guard Bureau (NGB-ARE/ARO) through a contract (Research and Development for a Nationwide Decision Support System Using GIS and Remote Sensing) with Allan Falconer at the USU Department of Geography and Earth Resources.

The interface was designed by Brian Biggs (USU / NED), Eric Olsen (USU / NED), and Kimberly Patraw (USU / NED). The majority of the programming for the NED Interface was done by Brian Biggs and Eric Olsen.

The majority of the programming for the Analysis Package was done by Kimberly Patraw (USU / NED) and Tom Van Niel (Camp Williams). Additional programming was also done by Brian Biggs (USU / NED), Joel Godfrey (USU / Camp Williams), Eric Olsen (USU / NED), and Burk Royer (USU / NED).

The functional design of the analysis tools was aided by consultations with Joel Godfrey (USU / Camp Williams), Doug Johnson (Camp Williams), Jim Long (USU / Camp Williams), Nick Nydegger (Orchard Training Area), Dana Quinney (Orchard Training Area), and Leila Schultz (USU / Camp Williams).

The several Installation Databases were constructed by Brian Biggs (USU / NED), Merland Halisky (USU / NED), Eric Olsen (USU / NED), Kimberly Patraw (USU / NED), Richard Spencer (USU / NED), and Tom Van Niel (Camp Williams). Quality control was done by Eric Olsen.

Primary data for the GIS Layers and Database Tables generally came from the Environmental Office of the Installation (converted/digitized, where necessary, from GRASS/hard-copy format by the NED team). Additional layers were obtained, where available, from USGS, DMA, Gap Analysis, the state Department of Natural Resources (or its equivalent), Esri ArcUSA, and other sources.

References:

Ramsey, R. Douglas, Kimberly Patraw, Brian Biggs, Allan Falconer, Tom Van Niel, Merland Halisky, and Richard Spencer. 1995. GIS For Environmental Management: A Hierarchical Database Structure. Esri 1995 User Conference Proceedings. Esri: Redlands, CA.

Patraw, Kimberly, Tom Van Niel, Jim Long, John Crane, and Allan Falconer. 1996. Land Condition and Vegetation Trend Analysis Using ArcView 2.1 and Avenue. Esri 1996 User Conference Proceedings. Esri: Redlands, CA.

Author Information:

Brian Biggs, Graduate Student and Research Associate
Eric Olsen, Staff Associate
Kimberly Patraw, Graduate Student and Research Associate
Allan Falconer, Professor and Department Head
Department of Geography and Earth Resources
Utah State University
Logan, UT 84322-5240
Ph: (801)797-1790
Fax: (801)797-4048
Email: ned@nr.usu.edu

Tom Van Niel, Staff Associate
Department of Forest Resources
Utah State University
Logan, UT 84322-5200