Christopher R. Steere
The purpose of this paper is to give an overview of the methods used to integrate ArcInfo and ERDAS Imagine to satisfy the requirements of the Digital Topographic Support System/Quick Response Multicolor Printer (DTSS/QRMP). The DTSS/QRMP is a battlefield system whose purpose is to enable the U.S. Army's terrain teams to analyze terrain and produce topographic products in a more timely and automated manner than is currently possible.
Based on an analysis of the two commercial products' strengths, ERDAS Imagine is used for the creation of hardcopy products and much of the graphical user interface (GUI) and ArcInfo is used for the vector analysis. Due to this assignment of tasks, a means of communication between the two software packages was required. Custom code was written that passes messages from the analysis code, written in ARC Macro Language (AML), to the GUI, which was written in ERDAS Macro Language (EML) and Imagine's C Toolkit package. Another problem encountered was the differences between the methods used by each product to define vector symbols. Custom code was written to convert ArcInfo lookup tables into ERDAS vector symbology (EVS) files.
In conclusion, the DTSS/QRMP is proof that a system can be designed and produced that integrates the analysis tools of ArcInfo and ERDAS Imagine in a manner that enhances the strengths of both products.
The function of the U.S. Army's terrain teams is to provide battlefield commanders with terrain analysis products to support tactical decisions. In the past, these products have been created manually through a process that is time consuming and requires a great amount of skill on the part of the analyst. The Digital Topographic Support System/Quick Response Multicolor Printer (DTSS/QRMP) is a system designed to automate the process of producing tactical decision aids so that these products can be made in a less time-consuming manner (Graff 1997). Project Director, Combat Terrain Information Systems (PD, CTIS), located at the U.S. Army Topographic Engineering Center (TEC), Alexandria, VA, is in charge of developing these systems. The prime contractor is Lockheed Martin Corporation (LMC), Fort Washington, PA.
The core functionality of the DTSS/QRMP is built around two Commercial-Off-the-Shelf (COTS) packages: Esri's ArcInfo and ERDAS Imagine. Although the software for the system is made up of several functional modules, the one that involved the most integration of these two packages is the Tactical Decision Aids (TDA) module. The functionality in this section allows the user to construct many different terrain analysis products including masked area plots, flight line masks, vehicle movement predictions, and data queries. The basic steps used to construct these products are presented to the user in the TDA Workflow interface. This interface is the same regardless of which type of product is being created: Data Setup, Parameter, Footprint , and Finalize. During Data Setup, the user selects the data to be analyzed to create the specific tactical decision aid. In the Parameter step, all of the parameters that are required to perform the analysis are entered. The Footprint step provides a default page layout for the map objects along with a graphical user interface that permits the user to edit this layout. The last step, Finalize, allows the user to make any last-minute changes to the product and generate the hardcopy plot.
The operations performed within the Footprint and Finalize steps are the same for all products. This provides a consistent interface for the user when editing the layouts of the products and generating the final hardcopy plot while also maximizing reuse of the code that was written for these steps. The operations within the Data Setup and Parameter steps are unique for each product type because each analysis algorithm requires a different set of parameters.
Based on an analysis of the two COTS products, the following assignment of functionality was
made: ERDAS Imagine was utilized for raster analysis, the production of hardcopy products, and
much of the graphical user interface (GUI); while ArcInfo was used for vector analysis and
minor portions of the GUI. The code for products that require the analysis of raster data, e.g.,
masked area plots and flight line masks, utilizes functions available in ERDAS Imagine and,
therefore, is written with ERDAS Macro Language (EML) and ERDAS Imagine's C Toolkit.
Other products, such as data queries and vehicle movement predictions, rely on code written
with ArcInfo's ARC Macro Language (AML) because they depend heavily on ArcInfo's
vector analysis capabilities. There were three main issues that needed to be addressed in order to
integrate ArcInfo and ERDAS Imagine in this manner: (1) the calling of AMLs from ERDAS
Imagine's C Toolkit, (2) the communication between the software packages, and (3) the display
of ArcInfo coverages in ERDAS Imagine.
One of the most important pieces of code that was written for the TDA module is the Product Manager software. The code was written using ERDAS Imagine's C Toolkit with the purpose of controlling the creation of the many different products available on the system. The ERDAS Imagine's C Toolkit was used to access ERDAS Imagine functionality and AML was utilized when ArcInfo functionality was required. Therefore, Product Manager had to be able to make calls to procedures written in both languages. Since Product Manager was written using the C Toolkit, it was simple to call procedures written in the same language. Calling pieces of code written in AML was more complicated.
The Product Manager software accesses ArcInfo functionality in two different ways depending on the type of product being created. Some product types can be created completely with vector analysis and are therefore produced using ArcInfo functionality. For these product types, all lower-level user interfaces and analysis code are written using AML. When the creation of such a product is initiated, a new ArcInfo session is opened to execute the required AMLs. This allows the user to create multiple products simultaneously, a high-priority requirement of the DTSS/QRMP. Simultaneous product creation would be impossible using a single session because of the singular threaded nature of ArcInfo.
Other product types require both ERDAS Imagine and ArcInfo functionality to be created. The masked area plot product type uses C Toolkit functions to extract elevation data from a digital file stored in Imagine's .img format. These elevations are then analyzed to produce the boundaries of the masked area polygons and write them to a text file in ArcInfo's GENERATE format. This file is then processed using ArcInfo functionality to produce a polygon coverage with appropriate symbology. In this situation, the portion of code that is written in AML is relatively short and requires no user interaction. For these reasons, the AML is submitted to an ArcInfo session configured as a server through ArcInfo's Inter-Application Communication (IAC) package. This session is started when the TDA module is initiated and is always running in the background.
The criteria for determining which AMLs are submitted to IAC and which ones are executed in
their own ArcInfo session are simple. If the software requires user interaction or a large
amount of time for execution, a separate session is used. Otherwise, the AML is submitted to
ArcInfo through IAC. Since a server session of ArcInfo is still a single thread, the AMLs
are executed in the order they are submitted. A backlog of AMLs can occur if an AML that
requires lengthy processing is sent to the server. By separating the AMLs in the manner
described, this danger can be avoided while still utilizing the benefits of the IAC server
functionality.
Once calls are made to the underlying procedures, Product Manager has to be able to receive messages back from those procedures. Implementing a method of communication for the procedures written with the C Toolkit was simply a matter of devising a series of unique messages that both Product Manager and the procedures understood and passing those messages back and forth through typical C constructs. The construction of the message handler for the AMLs was not as simple.
In designing Product Manager, two methods of having an AML pass messages to the system
were considered. The first was for the AML to write the messages to a text file and have the
Product Manager software periodically check this file. This idea was discarded because of the
potential difficulties with file permissions and the relatively slow file I/O capabilities of AML.
The second method, and the one used in the system, was to create a program that connects to the
AML process through a UNIX pipe and monitors everything written to standard output searching
for messages. The format of the messages is similar to that used by the C Toolkit functions.
When an AML needs to pass a message to Product Manager, the "&type" directive is used to
send the appropriately formatted text string to standard output. Product Manager then receives
the message and performs the required action. This method of sending messages allows the two
programs to communicate in a quick and efficient manner without any unnecessary writing and
reading of system files.
Due to Imagine's more advanced map composition GUI, it is used to construct and plot the system's final products. Through the use of custom software written in C Toolkit, the process of arranging map elements on the page has been semi-automated. This allows the user to produce output maps that conform closely to the standard map layouts defined by the National Imagery and Mapping Agency (NIMA). Other benefits of this automation are an increase in the speed of production and a consistency of product appearance among different terrain teams.
The software written to function as the tool for creating and editing the system's final products is called Final Product Review (FPR). The functionality within FPR encompasses the last two steps of the TDA Workflow - Footprint and Finalize. Since the output from the analyses performed in the previous steps of the TDA module are ArcInfo coverages, FPR needs to display these coverages and manipulate their symbology. One of Imagine's native functions is the ability to display ArcInfo coverages. However, to utilize different symbols for various features, this symbology must be defined in the form of an ERDAS Vector Symbology (EVS) file not an ArcInfo lookup table. It is not possible to create an EVS file with code written in AML. Therefore, the AML creates a lookup table then custom software was written that converts this lookup table to an EVS file.
This convertor was written in two parts: an AML that breaks down each symbol in the lookup table into its components and a C Toolkit function that uses those components to generate the correct symbol definitions within the EVS file. The AML uses the ARCPLOT commands LINEINFO, MARKERINFO, and SHADEINFO to obtain the defining attributes of the symbol. This information is then written to a text file located within the same directory as the lookup table. The C Toolkit function reads this text file and uses the symbol information to generate an EVS file containing the appropriate symbols.
The use of this convertor is one of the ways that the system makes the integration of ArcInfo and ERDAS Imagine transparent to the user. Even though the two COTS packages utilize different symbology schemes, the user is unaware of this because all product creation software, whether written with the C Toolkit or AML, presents the user with the same choice of symbols.
Using ERDAS Imagine for the purpose of displaying and manipulating ArcInfo coverages
had some serious limitations from a developer's point of view. These limitations refer to the use
of ERDAS Imagine v.8.2 with ArcInfo v.7.0.4. Currently, it is unknown if any of these
limitations will change with the release of newer versions of the COTS packages. The first
limitation is that ERDAS Imagine can only display ArcInfo point, line, and polygon
coverages. It cannot handle complex feature types such as routes and regions. This can result in
the need to create multiple coverages with simple feature types where a single coverage with a
complex feature type could have sufficed. Another limitation is that ERDAS Imagine can
display only ten coverages at any one time. When displaying a coverage, ERDAS Imagine
leaves the coverage files open for easier access. This results in the operating system having only
enough file handles for ten coverages to be open. The final limitation deals directly with
symbolizing ArcInfo coverages in ERDAS Imagine. ERDAS Imagine allows only one EVS
file to be defined per coverage. However, since an EVS file can only contain symbology
information for one feature type, this means that only one feature type per coverage can be
symbolized. For this reason, the product creation software builds a coverage for each feature
type even though ArcInfo allows more than one feature type per coverage.
The purpose of the DTSS/QRMP is to allow terrain teams to produce tactical decision aids in
support of their mission. The use of ArcInfo and ERDAS Imagine as the foundations for this
system has increased the efficiency with which these products can be created. Through the
development of this system, it was found that the strengths of the two COTS packages
complement each other and that integrating them will produce an analysis tool of enormous
usefulness. Any difficulties encountered during integration were definitely outweighed by the
benefits achieved and, as the developers of both packages work towards increasing their
compatibility, the process of integrating Esri's ArcInfo and ERDAS Imagine should become
even easier.
Graff, Linda H. 1997. State-of-the-Art Terrain Analysis Capabilities for Today's Army. In Volume 3: Remote Sensing & Photogrammetry: Technical Papers of the 1997 ACSM/ASPRS Annual Convention & Exposition in Seattle, Washington, April 7-10, 1997, by the ACSM/ASPRS. Seattle, Washington: ACSM/ASPRS, 716-725.
Christopher R. Steere
Lockheed Martin Corporation
1301 Virginia Dr., Suite 305
Fort Washington, PA 19034-3226
Telephone: (215) 283-6969
FAX: (215) 283-6970
steere@fwo.mds.lmco.com