Brett G. Cameron


AN ARCVIEW TOOL FOR SEARCH PRIORITIZATION

Many military and Intelligence analysts have a need to search for specific types of targets. Often broad area search reduction can be accomplished rapidly by applying spatial operators on specific site data. A generic tool that allows a user to flexibly define the search parameters, based on personal experience and current intelligence, is of great benefit. This paper discusses a generalized approach to developing a multi-purpose search tool within the ArcView environment. Topics included: the use of a development environment such as Galaxy to build a custom window; the implementation of an ArcInfo server to perform GRID analysis; and the use of Remote Procedure Calls to accomplish inter-application communication (IAC) between ArcView, ArcInfo, and Galaxy.


INTRODUCTION

The Search Prioritizer application is a tool that allows a user to automatically evaluate the best locations for a specified target or facility within a region or country. To accomplish this task, the application prioritizes the search areas based on various geographic factors using spatial analysis tools. By prioritizing the search areas, the user is able to focus investigations over a smaller subset of an assigned region. The priority assignment is essential to enable the focus of more sophisticated information gathering tools and techniques on the highest probability areas.

Overview Diagram

BACKGROUND

The Search Prioritizer application was developed to prioritize areas of search for a specific type of facility. The primary focus of the project was to develop search models for prioritizing areas where those facilities are likely to be located. The logistic regression probability model was chosen to accomplish this goal. Logistic regression does not predict the actual location of unknown sites but rather the probability that a given geographic area, with locational traits, contains a site. The logistic regression package (SPSS/PC+) output the key site factors within an equation using the data collected for known and random sites. The resultant equation was then used to build the search model using ArcInfo's Grid module. When tested against a test set of known facilities not included in the logistic regression process the model demonstrated a 94% hit rate and a reduction in the area to search of 84%.

An ArcView application was developed to allow the user to create, view and query the search models concurrent with the research and development of the search models. Additional functionality was also incorporated, including a "generic" search function allowing tailoring of input parameters based on personal experience to provide users with the ability to create models dynamically from within the application. The "generic" search function provides a "what-if" analysis tool to allow users to generate various scenarios of what might be the best search areas. This functionality is in contrast to the static nature of the models generated from a separate logistic regression model. To modify the logistic regression model requires a strong background in statistics and familiarity with a statistical package that supports logistic regression.

This paper discusses, in detail, the development of the "generic" search functionality within the Search Prioritizer application. Specific focus includes an overview of: the system architecture; the user interface and its component parts: ArcView, Galaxy, and ArcInfo; the data structure; and the Inter-Application Communications.

Issues

The Search Prioritizer was developed in ArcView 2.1 prior to the beta release of ArcView 3.0. As a result, several of the solutions implemented for this application may be modified to take advantage of new functionality in the upcoming release of version 3.0. At the conclusion of the paper there is a discussion of potential modifications that could be made to the Search Prioritizer application when implementing version 3.

SYSTEM ARCHITECTURE

There are three components to the system architecture of the Search Prioritizer: the ArcView environment, the ArcInfo environment, and the Galaxy environment.

The majority of the development was accomplished within the ArcView development environment using the Avenue scripting language. Two functional requirements could not be adequately met using Avenue. The first requirement not met by ArcView and Avenue was the generation of GRID models using grid algebra. ArcInfo, specifically the GRID module, had to be used to generate the models to accomplish this functionality. The second requirement was the Search Criteria input window. The functionality desired within the Search Criteria window could not be implemented with the message box class provided within Avenue. Visual Basic was not an option, since the development was being performed in a UNIX environment. The Galaxy development environment was chosen because it met the development requirements to build the search criteria window and TASC had prior development experience using this tool. It should be reemphasized however, that the controlling user interface was developed in ArcView with calls to ArcInfo and Galaxy.

The Search Prioritizer application was developed on a SPARC 10 running Solaris 2.3, using ArcView version 2.1, ArcInfo version 7.03, and Galaxy version 2.0, rev 2.

USER INTERFACE

The "generic" search function within the Search Prioritizer application was developed to provide a user with the capability to perform search area reduction based on input parameters. There were four specific requirements that had to be supported within this function. The first was to provide the user with a method for including data for the country or region as it came available (expandability). The second was to provide a method for the user to input site factor parameters (in the initial version - maximum distance and a weighting factor). The third was a method for delimiting the area to be searched. The fourth was a method to provide the capability for saving and loading the search parameters into a search model parameter file.

This section describes the three components (ArcView, Galaxy, ArcInfo) that make up the interface supporting the "generic" search function.

ARCVIEW User Interface

The ArcView user interface for the "generic" search function is made up of two parts. The first is the method for accessing the Search function. To access the Search function the user selects the SEARCH menu from the menubar and clicks on the Search Criteria option. The second is the message box that appears on the screen upon completion of the grid processing that prompts the user to name the model prior to adding it to the view as a theme.

Galaxy User Interface

The Galaxy user interface consists of the Search Criteria Window, that allows the user to input the parameters for the search. The following graphic shows the layout for the Galaxy window.

Screen Shot

The user is allowed to input the maximum distance for each of the available distance grids (valid values are .01 through 50 kilometers). The user can also apply a weighting factor to each of the distance grids (valid values are 0 through 10). The user assigns a weight of zero to that grid if they do not want to include a specific distance grid as part of the model. In addition, the user has the capability of modifying the search area by adjusting the coordinates captured from the mapextent and displayed near the top of the window. If the user modifies the coordinates of the search area, the mapextent of the view will not automatically adjust. The user also has the capability to input a description of the model to be included in the model file for future reference.

Upon completion of inputting the search parameters, the user must save the model file prior to generating the model. The user also has the capability to load a model file that has been saved previously. This capability allows the user to recreate a model without the overhead of storing the search model. This can be important if there is limited disk space on the machine. Another use may be to modify one parameter without reentering the remainder.

The two buttons at the bottom of the screen are the generate and cancel options. The generate command submits the model request to the ArcInfo server (after some addition processing from an avenue script to convert the model file into an AML). The cancel button allows the user to exit the function to the Search Prioritizer application without generating a model.

ArcInfo User Interface

The ArcInfo user interface consists of an icon containing the status of the ArcInfo server. This icon appears at the start of the Search Prioritizer application. The icon can be

opened to show current status of the ArcInfo process. The search model AML that is written for each model includes an &echo &on statement to allow the user to monitor the progress of the grid processing being performed on the ArcInfo server.

DATA STRUCTURE

Spatial data can be categorize into three types within the Search Prioritizer Application: Theme data used as reference data within a country or region View; Model input grids used as the source model generation; and Search model grids the actual models generated from the Search Prioritizer application. The first two types of data are organized on a country or regional basis. The following graphic gives a pictorial example:

Data Structure Diagram

Search model grids that are generated within the Search Prioritizer are created for a specific user for a specific reason, therefore the search model grids are stored in a directory called "models" under each user's home directory (not pictured in the above diagram).

Theme Data

The source of the Theme data for each region or country is varied based on what was the best available for the region or country (e.g. Vector Interim Terrain Data (VITD), Digital Chart of the World (DCW), VMAP level 1, City Graphics, etc.).

Model Input Grids

The model input grids were created from the Theme data available for each region or country View. Two customer requirements influenced the method by which the model input grids were created: all coverages and grids were to be in decimal degrees, and the unit of measure of the model input grids was to be in meters. To meet both requirements the following method was used to create the model input grids:

	grid_alloc = euallocation(test(grid_input,"value > 0"),grid_dist,#,#,#) 

The model input grids were created manually. Future releases will incorporate a method for creating model input grids within the ArcView Search Prioritizer application for the initial version of the Search Prioritizer.

INTER-APPLICATION COMMUNICATION (IAC)

To integrate the ArcView, ArcInfo and Galaxy components of the Search Prioritizer application, the Inter-Application Communications (IAC) functionality provided by Esri (in both ArcView and ArcInfo) was utilized. IAC utilizes Remote Procedure Calls (RPC) to perform the actual communication between the components. Esri's IAC implementation of RPC only supports the use of strings, though RPC supports many different types of structures. ASCII files were created to store the information (e.g. Search Model parameter file or the AML used to generate the search model grid) for the more complex types of data passed among the three components.

Employing the IAC functionality within the application required the establishment of three servers: a Galaxy RPC server, an ArcInfo server, and an ArcView server. These three servers are created at the start of each Search Prioritizer session through the use of a startup script.

The Galaxy RPC server is used by the application to access the Galaxy window. To accomplish this, ArcView establishes itself as a client to the Galaxy RPC server. The communications between the Search Prioritizer application and the Galaxy window is modal for the initial version of the application. Parameters passed in a string to the Galaxy RPC server include the name of the default parameter file associated with the active view and the minimum and maximum X & Y coordinates that define the current mapextent of the active view. The Galaxy RPC server passes in a string back to the ArcView client the status of the request and the name of the search model parameter file that was created by the user in the Search Criteria window upon completion of user input into the Search Criteria window. The following is an example of a search parameter file:


BOSNIA

Default Search Model for Bosnia

124.078|36.974|130.756|43.9223

Road|1|1

Rail|1|1

Drainage|10|3

City|5|1

Lake|1|1


The first line of the file is the country, the second is a description, the third is the search area coordinates, and the remaining lines are the available distance grids for region or country. Each line contains the name of the distance grid, the maximum distance, and the weighting factor.

The ArcInfo server is used to generate the grid model based on a Arc Macro Language (AML) script that is dynamically written by an Avenue script based on search model parameter file created by the user through the Galaxy window. ArcView establishes itself as a client to the ArcInfo server when the user initiates the Generic Search function. The ArcView client to the ArcInfo server is closed once the AML has been sent to the ArcInfo server via an &run statement contained in the RPC string that executes the AML. The reason for closing the connection is that Avenue is modality. If the connection was not closed, the user would not be able to perform any other operations with the application until the ArcInfo process was complete.

Only one ArcInfo server is required for multiple users. The requests are queued in the ArcInfo server as users submit search models to be generated. This can be an important feature if the customer has a limited number of ArcInfo licenses. Using this approach can create some challenges within the Search Prioritizer application, however, since prior to submitting a request to the ArcInfo server the Search Prioritizer application must first check to see if the ArcInfo server is up and running.

It is possible that the user may exit out of the application prior to completion of the generation of the model on the ArcInfo server if the request to generate a model requires a large amount of processing time, or there are many requests lined up in the queue. If this happens, the ArcInfo server will try to notify the appropriate ArcView client of completion. If the client is not active, the ArcInfo server moves on to start the next request. When this occurs it is the user's responsibility to load the completed model into the appropriate view upon re-starting the Search Prioritizer application.

There was a requirement to have the ArcInfo server notify the Search Prioritizer application upon completion of generating the grid model because the connection between the ArcView client and the ArcInfo server has already been closed. To accomplish this, the AML that was submitted to the ArcInfo server includes a command to establish the ArcInfo server session as a client to the ArcView server. Establishing the ArcInfo process as a client allows the AML script to issue a request to the ArcView server executing an Avenue script to notify the user of the successful completion of the search model grid. The following is a sample AML script that was dynamically written by the Search Criteria Avenue Script:


&echo &on

&watch /usr/home/bcameron/model1.wat

&if [exist /usr/home/bcameron/models/test1 -grid] &then KILL /usr/home/bcameron/models/test1 ALL

&workspace /disk02/searchappl/data/bosnia/models

GRID

SETWINDOW 12.887 41.632 19.924 47.087

wt1 = SCALAR ( 1.0 )

max1 = SCALAR ( 1.0 * 1000 )

wt2 = SCALAR ( 1.0 )

max2 = SCALAR ( 1.0 * 1000 )

wt3 = SCALAR ( 3.0 )

max3 = SCALAR ( 10.0 * 1000 )

wt4 = SCALAR ( 1.0 )

max4 = SCALAR ( 5.0 * 1000 )

wt5 = SCALAR ( 1.0 )

max5 = SCALAR ( 1.0 * 1000 )

DOCELL

dist1 = SCALAR ( Road )

IF ( dist1 > max1)

BEGIN

dist1 = SCALAR ( max1 )

END

constraint1 = SCALAR (( 100 - (( dist1 / max1 ) * 100 )) * wt1 )

dist2 = SCALAR ( Rail )

IF ( dist2 > max2)

BEGIN

dist2 = SCALAR ( max2 )

END

constraint2 = SCALAR (( 100 - (( dist2 / max2 ) * 100 )) * wt2 )

dist3 = SCALAR ( Drainage )

IF ( dist3 > max3)

BEGIN

dist3 = SCALAR ( max3 )

END

constraint3 = SCALAR (( 100 - (( dist3 / max3 ) * 100 )) * wt3 )

dist4 = SCALAR ( City )

IF ( dist4 > max4)

BEGIN

dist4 = SCALAR ( max4 )

END

constraint4 = SCALAR (( 100 - (( dist4 / max4 ) * 100 )) * wt4 )

dist5 = SCALAR ( Lake )

IF ( dist5 > max5)

BEGIN

dist5 = SCALAR ( max5 )

END

constraint5 = SCALAR (( 100 - (( dist5 / max5 ) * 100 )) * wt5 )

TEMP = SCALAR ( ( constraint1 + constraint2 + constraint3 + constraint4 + constraint5 ) / ( wt1 + wt2 + wt3 + wt4 + wt5 ) )

/usr/home/bcameron/models/test1 = TEMP

END

QUIT

&s srv [IACCONNECT squid 5FFFFFFE 1 status]

&if %status% ne 0 &then &return 

&s in = %srv% 1 'av.Run( "sp.ModelLoad" ,{ "Bosnia", "/usr/home/bcameron/models/test1" , "/usr/home/bcameron/model1.aml" })' status2 

&type %in%

&s req [IACREQUEST %in% ]

&type %status% %status2% %req%

&s status3 [IACDISCONNECT %srv%]

&watch &off

&echo &off

&return


The following diagram illustrates the interaction between the various components of the system.

RPC Diagram

ArcInfo Grid processing

The approach taken to create a generic process to generate the search model grids incorporated the following grid equation:

	Model = (((100 - ((Grid Layer1 / Max Dist1 ) * 100 )) * Weight1) +

		((100 - ((Grid Layer2 / Max Dist2 ) * 100 )) * Weight2) +

		((100 - ((Grid Layer3 / Max Dist3 ) * 100 )) * Weight3) +

		...) / ( Weight1 + Weight2 + Weight3 + ...)

Though the equation does not have a statistical basis, it does allow the user to select the maximum distance and weighting factor for each of the distance grids that are available for a specific region or country. The implementation of the equation is flexible enough to support the addition of new distance grids for a region as they become available.

IMPACT OF ARCVIEW 3

At this time, ArcView 3.0 is currently in beta release. ArcView 3.0 includes new functionality not available during this development effort. Based on literature and limited experience with ArcView 3.0 capabilities, there are two major areas that could affect the future of the Search Prioritizer application or similar applications development.

The first is the new ArcView extension, Spatial Analyst, that provides a user with a majority of the functionality currently offered in ArcInfo's Grid module. A logical modification to the Search Prioritizer application would be to utilize the spatial analyst functionality to replace the functionality currently supported by ArcInfo's GRID. This provides several benefits including: reducing the complexity of the application by eliminating the need to manage an ArcInfo server (i.e. an additional point of failure); allowing the user the capability to generate addition model input grids within the ArcView environment; and provide ad hoc grid manipulation capability within the application. Unknown at this point however, is how to address the notion of modality between the grid processing and the other functions within the Search Prioritizer application. The ArcInfo server method allowed the search model grid processing to proceed independently from the rest of the application. This is potentially a critical factor depending on the size of the area to be processed since the grid processing time for large areas can take hours.

The second area is the new ArcView concept known as extensions. The extension class, a subclass of the ODB object, can provide a means by which the developer can transport and distribute Avenue code without relying on the use of the project file. This new functionality could provide a large benefit in the way the Search Prioritizer application would be implemented in the future.

CONCLUSIONS

The Search Prioritizer application development effort demonstrates the capabilities of ArcView for integrating multiple software development environments into a single application. The result of this integration is a flexible "generic" search tool that provides a broad area search reduction function for users to apply to their specific needs.

This paper described in detail TASC's approach to incorporating Galaxy and ArcInfo processes within the ArcView application via the use of remote procedure calls using Esri's inter-application communication functionality. Through this effort TASC has demonstrated effective integration of varied development tools (GIS and non-GIS) to permit optimum solutions for the user achieving an intuitive user interface paradigm.


Brett G. Cameron, Manager, Systems Architecture Section

TASC, Inc.
12100 Sunset Hills Road
Reston, VA 22090
Telephone: (703)834-5000 ex 2335
Fax: (703)318-7900

E-mail bgcameron@tasc.com