Leigh Palmer, Litton-TASC
Key considerations in the development of an enterprise-wide geographic information system (GIS) include the storage, management, and maintenance of spatial data. The Combat Terrain Information Systems (CTIS) program addresses these issues under its Map Server effort. The Map Server will store spatial data in a master Relational Database Management System (RDBMS) using ArcSDE and the geodatabase object model, while snapshots of data will be downloaded to remote locations. These data, which may have been updated, will then be reloaded into the master database. Through lessons learned, this paper focuses on the database management/architecture issues and solutions discovered during the CTIS development effort in ArcInfo 8, ArcSDE, and the geodatabase object model.
The Digital Topographic Support System (DTSS) provides an integrated, independently deployed data manipulation, analysis, and output capability designed to provide commanders and staff with topographic engineering support at various army echelons (Brigade, Division, Corps, and Theater). The DTSS missions include the generation and collection of geospatial information, the analysis of geospatial data, and a suite of ad-hoc capabilities providing users with terrain analysis products and special map reproduction. The current DTSS is designed and deployed using ArcInfo 7.x and ERDAS on a UNIX platform. However, over the past year, this system has been re-engineered using Component Object Model (COM)-based development for the ArcInfo 8 environment on Windows NT.
Throughout the life cycle of the DTSS, the major issue was the availability, storage, and retrieval of base geospatial data. The primary source of data is the National Imagery and Mapping Agency (NIMA), which provides these products on either Compact Disks (CDs) or another Direct Access Storage Devices (DASD), from a central location. The problem is then to copy this information to each system at each of the echelons as needed. Initially, manual means of copying this data to removable hard drives with subsequent distribution was tried, but was found to be resource intensive. Instead, automated mechanisms for the distribution of maps and related data were required. The Map Server provides for the acquisition, storage, and retrieval of NIMA product data while maintaining terrain data integrity.
The Map Server is a data repository for NIMA format data for use in dynamic environments, and the associated Map Client provides a mechanism for users to query and request spatial data holdings based on an Area of Interest (AOI). There are five categories of requirements for the Map Server:
1. Load Data. The Map Server must load NIMA format data and metadata into an RDBMS.
2. Store and Replicate Data. The data must be stored and maintained within the RDBMS. Automated replication of the data must be feasible so that no single point of failure exists.
3. Locate data by Area of Interest (AOI). Users must be able to query the spatial data holdings based on a user-defined AOI. Metadata will be queried, and users will be able to request data for download based on AOI and metadata query results.
4. Transfer Data. Data will be transferred to the user’s file system based on a user’s AOI and metadata request.
5. Unpackage Data. Following data transfer, unpackage routines will put the data in directories and formats compatible with legacy systems and Government Off-the-Shelf (GOTS) products, such as the Joint Mapping Toolkit (JMTK), for use on the client system.
ArcIMS, Informix, and the Geodetic Data Blade for Informix integrated with ArcSDE were chosen for the server side architecture for the Map Server. Informix and the Geodetic Data Blade are already used by several Army systems, and the use of Esri Commercial Off-the-Shelf (COTS) products like ArcIMS and ArcSDE will provide future integration with the DTSS and geodatabases used by the DTSS. Integration with the DTSS will also allow for the publishing or sharing of specialized products created with the DTSS to all other Map Server users.
All client/user requests to the MapServer will be through a Web browser, and all requirements discussed in the previous section will be fulfilled using this approach. Using a Web-based approach, routine system administration and training costs are significantly reduced. Figure 1 illustrates this high-level system architecture.
A prototype system was developed and has been deployed to the technology-testing center for the Army. This prototype focuses on database issues and proves that the concept of providing data servers to mobile forces is feasible.
The prototype, although successful, does not have a mapping-based front-end of data retrieval. Investigations of COTS solutions that can meet these goals have led to an ArcIMS/ArcSDE solution. These products will allow the robust user front-end that is needed while allowing for future integration with the DTSS system and geodatabase object model used for this system.
The Map Server project has been collaborating with programs within the Army and other agencies, such as NIMA. This collaboration will allow a sharing of resources and will provide a common look-and-feel for several systems used by the operator in the field. Figure 2 is an example of the future Map Server system.
The Map Server system follows an iterative software development cycle. The first release, deployed in the fall of 2000, will have minimum required functionality; future functionality will be added in later build cycles. This enhanced functionality will include:
· Sub setting of vector and raster data at finer resolutions than the tile level, which reduces file sizes and network traffic. This will allow an operator to receive only the data required, not data based on pre-determined tile boundaries.
· Increased functionality within the browser. For simple analysis, the operator will be able to perform the spatial functions within the browser that will further reduce the amount of data required to transfer to the client system.
Throughout the prototype development and deployment and the first build of Map Server, several basic lessons were learned:
1. Take small steps.
· Create a build schedule with functionality included, and stick to it. If increased functionality creeps-in the schedule and timelines will increase as well risking success at early stages of the project. It is important to show early successes with basic functionality, and build on these in the future.
· Consider tackling the hardest requirements out in the project build cycle, and focus on requirements that are easiest to tackle to show early success. It is important to keep all requirements in mind for design sessions, but in order to get early feedback, requirements must be kept in scope.
2. Collaborate between organizations and projects to allow for sharing limited resources towards a common goal. Several organizations have the same basic requirements to serve mapping data. Although time-consuming to set up and maintain working relationships across organizations, these relationships are very important over the life cycle of the project.
3. Keep stakeholders involved in all cycles of the process. Getting end-user feedback early is invaluable. Let users critique screen shots before development begins, but prevent design by committee sessions from occurring in user feedback sessions. No system will encompass all user preferences -- these sessions must find the middle-ground.