Integrating GIS and Traditional Databases with MapObjects Technology
Presented December 5, 2001
National Park Service 2001 Spatial Odyssey

Danielle Berman
Department of Rural Sociology
University of Wisconsin-Madison
420 Agriculture Hall
1450 Linden Drive
Madison, WI 53706
Previously, GIS/Database Specialist
Cultural Resources GIS Facility
800 North Capitol St, NW Suite 310
Washington, DC 20001

The expanding presence of GIS offices within organizations has helped to enhance the availability of GIS data and expertise, but not always to the benefit of the entire organization within which it is working. The separation, and frequently, isolation, of GIS specialists within agencies, institutions, and organizations often limits the potential usefulness of GIS technology. Establishing a GIS office requires significant financial investment in infrastructure, software, and highly trained professionals and can seem unjustified when the benefits of the technology are not shared with the organization in general. However, there are many obstacles to achieving a wide user base for GIS. One primary obstacle is the expense of purchasing or licensing software for the entire organization and training employees in the use of this specialized technology. Another is the lack of perceived relevance or applicability of GIS to the work of other staff members and administrators. The third and often most problematic complication, is personal resistance to the use of computer technologies in general or GIS specifically, often due to a perception of their complexity and difficulty. The experience of developing integrated tools for accessing the data that will comprise the Consolidated American Battlefield Information Network (CABIN), and more specifically the data creation and management tools developed for the Revolutionary War and War of 1812 Historic Preservation Study (Rev1812HPS), provide informative examples of expanding the user base of GIS to the benefit of both the GIS office and other offices in the organization.

When the GIS office does not achieve widespread integration with the organization within which it exists, both the GIS office and the organization at large may suffer. The separation between staff members contributes to divergent specialization and emphases of not only the individual employees, but also of the projects they undertake. This can lead to data creation and organization schemes that are increasingly incompatible and difficult to reconcile. With the rate of technological change, the impact of uncoordinated data compilation can severely restrict future use and integration of information or demand extensive reorganization of data at a future date. When only specialists use the GIS data the benefits of a large organizational expenditure are limited to a small group of individuals and may never serve the organization as was initially intended. It may also be the case that without widespread and on-going organizational reliance on GIS, the quality of the data and its long-term management practices may be compromised as the need for systematic and standardized practices are not readily evident. This experience can contribute to the problems of legacy data (data that is no longer able to be used due to format, metadata, or other technical problems), inefficiency in data sharing, and conflicting assumptions about desired data availability.

The integration of GIS functionality in the database software used by staff outside the GIS office can help to address some of these problems. In this way, the costs of widespread adoption with respect to software purchasing (and often the requisite upgrading of hardware to accommodate new software) as well as training can largely be avoided. While the initial investment in custom software may be high, this can also be minimized and the benefits optimized by working in-house to develop custom tools. Many organizations already use custom database systems for administrative and other day-to-day tasks. The addition of GIS functionality to a technology that is already in use can limit the need for training as the introduction of GIS does not require learning a new software package, only the few new functions and tools that are relevant to the work already being done. Particularly when the development occurs in-house, the relevance of the technology can be assured, as only those functions that would be useful to the organization are made available. The perception of the complexity of GIS technology and resulting reluctance to use it can also be addressed in the development process and mitigated by embedding it in a familiar tool. The ability to automate data access and common tasks can also help to lessen the sense that the technology is difficult to use.

The process of working with personnel in offices outside the GIS office to development the software may reveal a larger desire for GIS functionality than was previously assumed. Increased coordination between offices can help to illuminate shared goals and needs for GIS data and functionality. This dialogue can improve the coordination of data collection and management efforts throughout the organization to better ensure future and on-going integration of information. Increasing interdependence of data encourages standardization of data collection and on-going communication and coordination of data development efforts. With widespread use diverse program needs and perspectives are brought to bear on the work done by GIS specialists allowing them to better target their efforts and to improve their ability to share the benefits of GIS with the larger organization. This increased understanding and appreciation of the relevance of GIS increases the value of these efforts and the return on the organization’s investment.

The example I will use to illustrate this process is the work I was involved with to develop the Consolidated American Battlefield Information Network (CABIN) as well as the Revolutionary War and War of 1812 Historic Preservation Study that will contribute to a large share of the network’s data. CABIN is intended to integrate the wide variety of data available, and currently being created, about the Nation’s battlefields and associated historic sites, not only regarding their historic importance, but also their geographic location and preservation status. The data fall largely into two categories: Geographic and Tabular, with additional related digital files such as photographs, planning documents, and digital publications.

It also happens that these categories fall, for the most part, under two different offices within the National Park Service: The Cultural Resources GIS (CRGIS) and the American Battlefield Protection Program (ABPP). The other primary intention of CABIN is to make these data available to a wide range of users including other NPS offices, Battlefield parks, State Historic Preservation Offices, and the general public.

The task then, was, and still remains, to bring all of the data together in digital formats that could be linked, easily accessed, and systematically maintained. Much of what will become the bulk of the tabular data currently exists only on paper, or has not yet been generated at all. The ABPP needed a database system that would allow them to continue to use and add to existing data while providing the functionality they need for their everyday work of grant administration and public outreach. The addition of a GIS component to this system, and process of discussing the potential for such a component, revealed a real desire and need for true data integration.

In order for the GIS component to work in a straightforward manner the GIS data needed to be organized and coded according to standards that made files easy to locate. This involves reorganizing and documenting the bulk of battlefield related data compiled over the last ten to fifteen years including the data gathered from the Civil War Sites Advisory Commission (CWSAC) study. A long and time-consuming process, this will be an on-going project into the future. In coordination with this effort, many records of preservation projects and grant recipients are also being cleaned up and organized to ensure compatibility. All data related to any particular battlefield or site is coded to enable linkages across data and file types. The first (beta) version of CABIN was designed in Microsoft Access© and made accessible to both offices on the Intranet. It incorporates the functionalities that the ABPP relied on from their previous database and adds modules for collecting additional data as well as accessing GIS data within the same system. It will also eventually include tools to assist in website maintenance to keep the data presented on the web in synch with the data updated and generated by the ABPP or CRGIS offices.

The experience of working to organize and standardize the data collected prior to the establishment of CABIN helped to inform the methods of data collection incorporated into the Revolutionary War and War of 1812 Historic Preservation Study. It was clear from the beginning that the data collected through this study would be a large part of the CABIN and here was the unique opportunity to collect the data in a way that would facilitate incorporation into the system. The Rev1812HPS relies on surveyors trained by the CRGIS and ABPP staff to gather and submit the required data on their assigned battlefields and historic sites. With approximately 70 surveyors in the field it was imperative that their data collection methods be standardized. By providing the surveyors with a custom database and a MapObjects based GIS tool the data was ensured to not only be consistent, but digital as well. The database in use by the CRGIS staff to assemble the data from the various surveyors as it comes in from the field also has a MapObjects component to allow for the automation of repeated functions and to test the functionality in preparation for its incorporation into CABIN.

A pared down toolbar at the top provides data loading and basic GIS functions such as zooming, panning, and identifying features. The main tasks that need to be done in the process of assembling the data submissions are calculating the area of the boundaries, calculating the centroid position of the study area to add to the shapefile that will contain point locations for each site, and establishing the UTM zone so that data will display properly for other users automatically. Each of these tasks is automated and requires only clicking a button and selecting the relevant polygon. Additionally the database itself provides functions to catalog other associated GIS files including the appropriate Digital Raster Graphs (DRGs) and the other shapefiles submitted by the surveyors. These shapefiles may contain GPS data collected in the field or digitized defining features and troop movements.

For those interested in the technical specifics and challenges of creating an integrated system, it is important to emphasize that these databases were created in Access97 using the VBA scripting language embedded in that software. The database does not convert easily into newer versions of Access and this, admittedly, limits its versatility over time. Also, for some reason Access, at least the 97 version, is incompatible with the legend object available from ESRI. This necessitated some additional coding to turn a list box into a functioning "table of contents" for layer management. It would probably be best to design the interface completely in Visual Basic and refer to a back-end database system in Access or otherwise.

The automation of data access, which is a key aspect in making the GIS data readily accessible to non-GIS users, is completely dependent on filename and organization standards. The use of file naming conventions based on codes contained in the database and organized in a standard way made it possible to have all associated shapefiles loaded for the current site at the click of a button. This also depends on the LAN structure that provides access for all users to the data server. In order to deal with data that will be maintained off line on CDs, due to lack of data storage space and the relatively infrequent accessing of particular files, the cataloging system was introduced and provides a way to indicate what data is available for each site and where in the office it is located. The CDs can then be retrieved and the data loaded manually for viewing or use.

One last technical note regarding MapObjects is the complexity of dealing with projected data. The way these systems deal with the issue is by assuming the UTM projection and setting the relevant zone in advance of general use. This can be done largely because all the data digitized by the surveyors were in relation to background DRGs that display in UTM. This was a means of limiting the complexity in use as well as programming without sacrificing data accuracy. Data projected in other projections can still be displayed in the MapObjects component but in order for data of varying projections to overlay, additional programming would be required.

My intentions in developing this integrated system were based in a desire to bridge the gap between the two offices in terms of data access, coordination, and development. By improving the access to the data, I hope that its relevance becomes more apparent to the work of non-GIS specialists and that this sense will translate into future coordinated efforts of data creation and analysis to better serve the program needs of both offices. The availability of the information will also improve the efficiency and accuracy with which the ABPP can respond to both internal and public requests for information. In this way the value of GIS to the organization could be greatly enhanced.

Though I no longer am involved directly in these projects, I hope that development continues on them in a way that further integrates the information around the content rather than file or data type. Whether by maintaining and building on the Access databases or migrating them to more robust systems, I think that the usefulness of this kind of technology is clear. As program professionals, as opposed to technology specialists, have more exposure to and involvement with GIS, its use will become more sophisticated in addressing the problems and needs of the organization itself, rather than being an adjunct technology to display information or produce isolated reports. When both, or in other cases, multiple offices work together in developing custom tools like this one, often the process itself can be informative and help to foster a cooperative and interdependent working relationship that improves the capacities of all involved. As CABIN progresses and moves to the web, the combined input of both offices will be critical in making the information not just available, but meaningful and relevant to its audience of agencies, organizations, and the general public.

In conclusion, it will be interesting to see how the organizational relationship embedded in the software tool will shape future projects and impact the role of GIS in battlefield preservation efforts. By taking advantage of current technologies that allow for integration of these advanced systems in ways that make them accessible to non-specialists, organizations can expand the utility of GIS and address many of the issues that contribute to the disconnect between technology specialists and program staff. This can have big returns, not only in financial terms, but also by improving the capacity of the organization in general to apply the relevant aspects of GIS to their everyday work.