Ken Feldman

Integrating Tactical Decision Aids in ArcInfo 8

The Combat Terrain Information Systems (CTIS) program is responsible for developing and fielding the Digital Topographic Support System (DTSS).  A primary function of DTSS is to create Tactical Decision Aids (TDAs), such as Intervisibility, Data Query, and Mobility products for battlefield commanders.  DTSS is currently migrating from UNIX to Windows NT platforms.  Required TDAs will be integrated into DTSS on Windows NT using Microsoft Component Object Model (COM), ArcInfo 8.   This presentation will focus on the successes and issues uncovered while designing, developing, and integrating TDAs in the new DTSS Windows NT environment


Introduction

DTSS provides computer-based tools enabling the Army’s Terrain Analyst to generate TDAs.  TDAs are integrated terrain products used by commanders and their staffs to improve the tactical decision-making process.  Robust Commercial-off-the-Shelf (COTS) Geographic Information System (GIS) software products and National Imagery and Mapping Agency (NIMA) standard data bases, imagery, direct reconnaissance, intelligence, and other available sources are used to produce TDAs such as Intervisibility, Data Query, and Mobility products.

The current hardware platform for DTSS is a Sun ULTRA 2 running the Solaris operating system.  The TDAs are currently created using COTS software such as ArcInfo 7.2.1 and ERDAS Imagine 8.3; government-off-the-shelf (GOTS) software; and custom-developed code.  Work has begun on a DTSS release for the Windows NT operating systems.  TDAs will be developed using COM and ArcInfo 8.  This paper will focus on the successes and issues uncovered while designing, developing, and integrating TDAs with ArcInfo 8 in a Windows NT environment.  Although several TDAs are scheduled to migrate from the UNIX platform to NT, this paper will focus primarily on the development of DTSS mobility software. 

Mobility Analysis in DTSS

An important component of DTSS are the Mobility TDAs.  These produce a variety of terrain analysis products that depict the output of the NATO Reference Mobility Model II (NRMM II) developed by the US Army Corp of Engineers’ Waterways Experiment Station (WES).  NRMM II uses vehicle, terrain, and scenario information as input to a set of inference algorithms for predicting various mobility characteristics for a given area.  Output includes maximum on-road and off-road speeds, on-road and overland route analysis, gap crossing analysis, trafficability, surface degradation, and others.

FORTRAN libraries, and later C Application Programmer Interfaces (APIs), were developed by WES to serve as an interface to the NRMM II model.  The FORTRAN libraries are integrated into the current UNIX DTSS platform.  DTSS allows users to select NIMA Interim Terrain Data (ITD) for processing with APIs.  The ITD, coupled with user-defined parameters including vehicle type, weather, surface condition, slippery condition, and speed ranges, are fed to the NRMM II model through the FORTRAN code.  NRMM II returns GO/NOGO, speed, and reason information.  Polygons and lines are generated from the output for display.  DTSS provides the ability to overlay newly created polygons and lines on existing topographic data for display within DTSS or hardcopy output.

UNIX Implementation of Mobility Analysis

As previously stated, the UNIX builds of DTSS use ArcInfo 7.2.1 and Imagine 8.3 as the primary COTS products for producing TDAs.  Imagine frames customized with ERDAS Macro Language (EML) scripts and the C-toolkit are used to navigate the Terrain Analyst through a data preparation and parameter selection workflow.  Arc Macro Language (AML) scripts are used for preprocessing of data sets for input to the model and post-processing of data output from the model.

Data Preparation

When the Terrain Analyst selects the ITD data set for mobility analysis, the code executes an ArcInfo ARC session.  AML scripts are used to process the ITD features and attributes into logical terrain units.  ITD layers (obstacles, vegetation, slope, surface materials, transportation, and surface drainage) are rasterized and combined using ARC GRID functions.  Grid cells are aggregated based on groups of  “like” ITD features and attributes.  An ASCII file is created from the aggregated cells containing a terrain unit identifier and the features and attributes from each ITD layer for the terrain unit.  The FORTRAN libraries and AMLs are used to ascertain location information for inferring weather and surface conditions.  The ASCII file created from the aggregated cells, along with information provided from the parameter selection process, is sent to the NRMM II models.

Parameter Selection

After the data preparation is completed, mobility TDAs can be generated for the selected ITD data set.  The Terrain Analyst uses the customized Imagine frames to select a mobility product and the parameters to apply to the model. For example, a Terrain Analyst may choose to create an off-road speed product from a previously prepared ITD data set using the following parameters -- historical weather for January, dry surface condition, no slippery factor (referring to recent rain fall) -- for an M1A1 tank.  They then prepare the speed values for display in five equal ranges between 0 and 50 KPH and greater than 50 KPH.  This information is handed to the FORTRAN libraries for processing in the NRMM II model.

Product Generation

The information gathered in the parameter selection and data preparation process is fed to the NRMM II model using the FORTRAN libraries.  Speed and reason codes for each terrain unit are returned from the model.  AMLs are used to create polygon and line coverages from the gridded data prepared in the data preparation process.  During this coverage creation process, a shade value is assigned to each polygon for symbolizing speed ranges or reason code answers from the models.  Customized Imagine frames and Imagine Map Composer templates are then used by the Terrain Analyst to overlay other data for map display and hardcopy production.

Windows NT Implementation of Mobility Analysis

The next major release of DTSS will be for the Windows NT platform using ArcInfo 8. Additionally, the software engineers at WES developed new C-language-based APIs to work with the NRMM II models.  All of these necessitate a significant design change for TDA development and integration, particularly with respect to Mobility analysis. 

NT Mobility GUI

The ArcMap module and Microsoft Visual Basic (VB) replace ERDAS Imagine as the Graphical User Interface (GUI) for DTSS mobility analysis in Windows NT.  Instead of leading the user through Imagine frames, a wizard approach using VB was designed.

Through the use of ArcInfo extensions written with COM, the ArcMap interface is customized with additional tools and options.  The Mobility Wizard is launched from a menu option on the ArcMap main menu.  

The wizard allows the Terrain Analyst to select the data set and parameter information following the same basic concepts as in the UNIX build, with two notable exceptions: the data preparation and parameter selection processes are not separated as in the UNIX build, and speed ranges are not a required parameter.  The Terrain Analyst selects the data set and the parameters through the wizard.  A summary of the data set and parameter selections is displayed; after that is accepted, the mobility-processing engine is launched.

NT Mobility Processing Engine

When the Mobility Wizard launches the Mobility Process Engine, it passes all required parameters to the engine.  This process is performed by a series of methods in a custom COM interface.  Once all of the parameters have been set in the Engine, the mobility process is started.

AMLs are still necessary to process the selected data set into terrain units. This requires that three AMLs be called successively from C++ code.  The first AML, started in ARC, is used to convert the selected geodatabase layers into coverages and then into grids.  The second AML, launched in ARC GRID, is used to convert the null values in each of the gridded layers to 0, to combine the gridded layers into one stacked grid, and to create the terrain unit coverage.  The last AML, launched again from ARC, ascertains and writes location information to an ASCII file for inferring weather and surface conditions and creates an ASCII file containing the terrain unit information.  The terrain unit ASCII file is created in much the same way as in the UNIX build.  When the stacked grid is created, cells are aggregated by all the “like” combinations of features and attributes created by stacking the feature layers from the data set.

The terrain unit ASCII file and the location information are passed into the WES APIs for processing with the NRMM II model.  C++ code opens the ASCII file containing the location, information storing the contents to a location structure.  Next, C++ code is used to open the terrain unit ASCII file.  Each line of that file contains the feature and attribute values for each data layer for that terrain unit.  Each line is fed to models using the APIs.  A corresponding line is written to a new ASCII file containing the speed and reason for that terrain unit, based on the location information and the parameters handed to C++ from the VB wizard.

The speed and reason ASCII file is added to the Polygon Attribute Table (PAT) of the terrain unit coverage created earlier in the process.  The coverage, along with associated features and attributes, is uploaded to the geodatabase.

During the mobility calculations and data processing, feedback is given to the user on the progress.  This is done through the COM method called “Connection Points.”  This method allows the Mobility Engine to transmit status messages back to the Mobility Wizard GUI, which can then show these messages to the user in a dialog box or status bar.

Map Display

Once created, the terrain unit geodatabase or terrain unit coverage can be displayed in ArcMap or stored as a new independent data set.  Using ArcMap, the Terrain Analyst may display the terrain unit data with other available data.  The Terrain Analyst may adjust the speed ranges or display speeds as unique values without rerunning the models making the NT product much more flexible than the UNIX release. (In the UNIX release, the Terrain Analyst must rerun the Mobility TDA each time a new speed range is desired.).  A custom map template is provided to the Terrain Analyst for hardcopy production. 

Development Issues

Development of this DTSS TDA using ArcInfo 8.0 has highlighted several issues related to processing the data for use with the Mobility Wizard.  As previously stated, data for the system are stored as geodatabases.  The process to create the terrain units for mobility, however, requires that several vector data sets be combined into a single “stacked” gridded data set for use with the WES APIs. 

Currently, there is no easy way to convert data from a geodatabase to an ArcInfo grid, each data layer must first be converted to an ArcInfo coverage and then to an ArcInfo grid.  The ARC GRID combine command is then used to “stack” the individual grids into a single combined gridded data set.  AMLs were written to facilitate this process.

However, using the AMLs within the ArcInfo 8.0 environment was not as straightforward as with ArcInfo 7.2.1.   In ArcInfo 8.0, ARC GRID commands cannot be accessed from AMLs initiated from ARC, nor can ARC GRID be called from ARC within AML.  Separate AMLs containing only the ARC GRID functions and commands to work with the grid portion of the process had to be written.  As a result, many more lines of code are required to process data than are necessary in the comparable UNIX software build.

Conclusions

The NT build of DTSS provides a more intuitive and flexible interface for Terrain Analysts to create TDAs, and COM technology allows the loading of components on different systems without having to reload the entire suite of software.  In the future, more TDAs will be added as components of the DTSS.  As the geodatabase technology matures, and as ARC and ARC GRID commands become available through ArcObjects, the goal is to maintain the data in geodatabases throughout the entire process and to drop AML scripts for data processing altogether.


Ken Feldman
Senior MTS, Litton TASC, Inc.
kdfeldman@tasc.com