Yew Kuan Choo and Chen-Chen Lee

Integrated Distributed Geographical Information Systems (IDGIS)

Interactive Distributed Geographical Information Systems (IDGIS) is a client-server Java mapplet designed for Intranet/Internet sites. IDGIS provides a user friendly GIS front-end to enable multiple local and remote clients to perform routine GIS functions, viewing, query, and spatial analysis, on distributed geographic data. Existing commercial GIS packages, ArcView and ArcInfo, are use to create maps, perform queries, and provide spatial analysis and overlay functions. The combination of Web technologies and the power of commercial GIS software enable land use and natural resource managers to analyze GIS data that resides across the Internet. This paper will focus on the design and architecture of IDGIS.

INTRODUCTION

Sharing of geographic information is vital because the more it is shared and used, the greater the society's ability to evaluate and address the wide range of pressing environmental, social and economics issues (Onsrud 95). There are extensive efforts to standardize and assist in the discovery and sharing of geospatial data. These standards and procedures include the Federal Geographic Data Committee (FGDC) Content Standards for Digital Geospatial Metadata, the Spatial Data Transfer Standard (SDTS), and the National Geospatial Data Clearinghouse. The advances of Web and GIS technologies are enabling GIS experts and laymen to use and analyze geographic data that resides across the Internet.

IDGIS is a client-server model based on the Java language. It is an integration of Web technologies and commercial GIS software. IDGIS is an effort to enable land use managers, natural resource managers, and public users to perform routine GIS functions, viewing, query, and spatial analysis, on geographic data that is distributed across the Internet.

COMPONENTS OF IDGIS

IDGIS is a three-tier client-server model based on the Java language. The interaction between different components of IDGIS is shown in Figure 1. IDGIS clients reside either on the same local area network (LAN) as the IDGIS server, or reside remotely across the Internet. The IDGIS server and the Web sever are running on the same host computer. There are currently two commercial GIS servers, ArcView and ArcInfo, running on different workstations. All the servers-IDGIS, Web, GIS-are on the same LAN and have access to the GIS data and working directory that resides on a network file system.

Figure 1. Components of IDGIS

1. IDGIS CLIENT

The IDGIS client is a Java based map applet (mapplet). An applet is a Java program that is downloaded over the World Wide Web and executed by a Web browser on the user's machine. The IDGIS client provides an intuitive user-friendly interface that enables multiple local and remote computers to access and analyze geographic data within an Intranet or across the Internet.

1.1 IDGIS Communication Model

The IDGIS communication model is based on a three-tier client/sever model as depicted in Figure 2.

Figure 2. IDGIS communication model.

The following is one of the most frequent communication route taken when a user, using the IDGIS client (IdgisClnt), makes a request:

IdgisClnt creates a new connection handler thread to handle communication between it and the IDGIS server (IdgisSvr).
IdgisClnt forwards the request to IdgisSvr.
On receiving a new connection request, IdgisSvr creates a new connection thread to handle the request, then continues to wait for more requests.
The connection thread checks for the availability of a GIS server. If none is found or available, a negative acknowledgement (NACK) is send back to IdgisClnt and the thread terminates. Otherwise, an acknowledgement (ACK) is return to IdgisClnt.
Depending on the operation of the client request, IdgisSvr's connection thread will submit the request to the appropriate GIS server through RPC. The connection thread will be blocked until the GIS server is finished with the operation, or until a timeout occurs.
Depending on the operation required, the GIS server can: (a) generate and format the output directly onto the network file system or database, or (b) spawn a system process if the operation requires further processing by an external program. An example of (a) is when the GIS server performs a query operation. The result of the query will be formatted as an HTML document directly. An example of (b) is when the GIS server generated a map in encapsulated Postscript (EPS). The EPS map will required an external program to convert it into gif format.
After the RPC request returns, the connection thread will start to "poll" for the desired GIS output or until a timeout occurs.
Once the desired output is found, the resulting information will be returned to IdgisClnt's connection handler thread.
On receiving the requesting result the connection handler will send a HTTP request to the Web server for the desired HTML document or gif map.
The requested HTML document or gif map will then be displayed on the Web browser.

1.2 Local Operations

IdgisClnt provides several supporting functions to enable interactive operations:

Coordinate transformation. Transformation between the map image coordinate to the real-world coordinate and vice-versa is the most frequently used operation. For example, the map feature query will require that the mouse coordinate be transformed into the real-world coordinate in order for the GIS server to process the query request.
Distance measurement. This tool uses the coordinate transformation function to calculate the segment length, the perimeter, and the area of the user defined region.
Zooming. This tool uses the coordinate transformation function to get the real-world coordinates of the user defined zoom region. It allows the user to zoom into or zoom out from the map.
User interface. IdgisClnt uses the java.awt package components and Java event handling methods to build its interface.

Future version of IdgisClnt will include more local supporting functions.

2. IDGIS SERVER

IDGIS server (IdgisSvr) is a multithreaded Java application that resides on the same computer as the Web server. It keeps a registry of GIS servers and their current status. GIS requests from remote clients are forwarded to one of the registered ArcView or ArcInfo GIS servers based on the operations required. The results from the request, either a map or an HTML document, are then returned to the remote clients.

2.1 BSD Version

The initial version of IdgisSvr is a concurrent connection-oriented TCP server using BSD sockets. In a concurrent connection-oriented server, the master server process does not communicate directly with clients. Instead, it waits for connection requests at a well-known port. Once a request is received, the system returns a socket descriptor of the new socket for the connection. The master server process creates a new slave process to handle the connection, and allows the slave to operate concurrently (Comer93). The process structure of a concurrent connection-oriented server is shown in Figure 3.

Figure 3. Concurrent connection-oriented server process structure.

The concurrent connection-oriented server has some shortcomings: complex synchronization and heavy weight processing.

2.1.1 Complex synchronization

IdgisSvr has to synchronize concurrent access to the status of GIS servers in the registry table. For example,

GIS servers might register (startup) or unregistered (terminate)
slave processes need to check the availability of GIS servers
slave processes need to update the status of a server after it is done processing a client request.

Unix supports three different styles of communication between processes: messages, semaphores, and shared memory. Messages are difficult to program and coordinate, and involve communication overhead when more than two processes exist. Shared memory is needed to implement the registry table, and semaphores are needed to coordinate sharing across multiple slave processes.

2.1.2 Heavyweight processing

Slave processes are created using the fork system call. However, these processes are an expensive to create and manage. Child processes created by the fork system call have identical copies of user-level context as their parent. There is only one processing activity associated with each process. This makes sharing between related activities awkward and expensive (Coulouris94).

2.2 Java Version

The latest version of IdgisSvr is a multithreaded Java application. Its architecture uses the object-oriented, multithreading, and exception handling features of Java. It also uses the java.net networking package of the Java class library for handling requests from remote clients. These features simplified the porting process from the earlier BSD version of the server. However, Java native methods had to be developed to handle ONC/RPC communications between IdgisSvr and the commercial GIS servers.

2.2.1 Multithreading and Synchronization

Multithreading is part of the Java language. This inherent feature makes it much easier for programmers to create thread-safe multithreaded classes. Multithreading involves multiple threads of control within a single program. A thread is a single sequence of execution within a program. The benefits of multithreading include better interactive and real-time response. Java implements a variant of monitor for synchronizing the concurrency activity of threads. C.A.R. Hoare introduced the concept of monitor in the Communication of the ACM journal in 1974. In Hoare's model, a monitor is a special purpose object, which enforces mutual exclusion to groups of procedures. A monitor ensures that only one thread is allowed to execute a procedure controlled by the monitor. Other threads that tried to invoke a procedure controlled by the monitor will be suspended until the first thread completes its call.

Every Java class and instantiated object has an associated monitor that comes into play if required. When a synchronized method or statement of an object is invoked, the monitor of the object is consulted. If no other thread is currently executing the region of protected code, the current thread is allowed to enter the monitor, otherwise it must wait until the other thread leaves the monitor. Monitors can also be used to coordinate multiple threads by using the wait and notify functions. The current thread is suspended and added to the condition variable wait queue of the object's monitor when wait is invoked. The thread is not removed from the wait queue until the object receives a notify from a different thread.

IdgisSvr uses monitors and condition variables to synchronize connection activities between clients and the server. A new thread is created for each connection request, and based on the operation requested further threads might be created as needed. For instance, a user wants to create a new map using IDGIS client. The new map request is first accepted by the SockServer thread, which creates a new Connection thread to handle the request. Based on the operation required, new map, a new AvServer thread is created to process the request, through RPC, with the ArcView GIS server. The resulting map information is then returned from the AvServer thread to the IDGIS client, which will then display the map on the Web browser.

2.3 RPC Native Methods

The commercial GIS servers that are used by IDGIS-ArcView and ArcInfo-support inter-application communication through Remote Procedure Call (RPC). IdgisSvr uses RPC native methods to interface with GIS servers. Native method is a mechanism that allows a Java application to interface with external C and C++ libraries. The process of developing a native method involve: generating headers and stubs using the javah program; implementing the native methods in C or C++; and generating dynamic shared library (or DLL for Windows).

3. GIS SERVERS

Commercial off-the-shelf GIS software, ArcView and ArcInfo, are used as GIS servers because of their functionality, scripting capability and their use of standard inter-application communication protocol. GIS servers will need to be registered/unregistered with the IDGIS Server (IdgisSvr) during startup/shutdown. Once registered, IdgisSvr will be able to forward requests from IDGIS clients to the first available GIS server. The inter-application communication between IdgisSvr and GIS servers are done using Sun ONC RPC.

3.1 Data Model

The data used by the GIS servers resides on local network file system. They are in ArcInfo coverage or ArcView shapefile format. The available data sets are grouped or logically linked under the corporate directory, which is indicated by the IDGIS_CORPGIS environment variable. Data output as a result from a client request are stored under the working root directory, which is indicated by the IDGIS_LOCALGIS environment variable. The output data are stored under the client IP address, and are categorized under:

maps. This directory contains maps generated as a result of display and map manipulation requests, i.e. map display, and zooming functions. The output maps are in gif format.
spatial. This directory contains ArcInfo coverages as a result of a GIS analysis and overlay functions, i.e. buffer, union, and intersect.
attrib. This directory contains output from database functions. The output files are either in HTML or text format.

The output working directory structure is shown in Figure 4.

Figure 4. Working directory layout.

3.2 ArcView GIS Server

ArcView software by Environmental Systems Research Institute (Esri) is a commercial mapping and GIS for desktop environments. Included with ArcView is Avenue, an object-oriented language for software customization and application development. A set of Avenue scripts was written to handle requests from IdgisSvr. The requests that are currently handled by the ArcView server include:

new map: create a new map.
add themes: add new ArcInfo coverages or ArcView shapefiles into an existing map.
zooming: zoom into or out of a region on the map.
query: query attribute data of a feature on the map.

3.3 ArcInfo GIS Server

ArcInfo by Esri is a commercial GIS software for professionals using UNIX and Windows NT. Incorporated into ArcInfo is the ARC Macro Language (AML) for task automation and application development. A set of AML scripts was written to handle spatial analysis functions request from IdgisSvr. The requests that are currently handled by the ArcInfo server include:

buffer: creates buffer polygons around features specified in the input coverage.
intersect: computes the geometric intersection of two coverages. Output coverage contains those features that are in the area common to both input coverages.
union: computes the geometric intersection of two coverages. Intersecting polygons will be split at their intersections and preserved in the output coverages.
erase: erases the input coverage features that overlap with the polygons of the erase coverage (Esri91).

SYSTEMS FUNCTIONS

IDGIS provides a user-friendly GIS front-end for natural resource managers and public users to perform routine GIS functions on geographic data that are distributed across the Internet. The IDGIS server will create a unique directory for each remote client according to its machine IP address. Requests from a remote client might generate maps, documents, and new coverages that will be stored in the unique directory.

Map

Allows user to create and display maps based on the user's selected distributed geographic data. The map is created by an ArcView GIS server. An example of IDGIS map output is shown in Figure 5.

Figure 5. Viewing distributed ArcInfo coverages using Netscape Navigator browser running IDGIS Java mapplet.

New Map: Enables users to create a new map from the available coverages or coverages generated from a spatial analysis function.
Add Themes: Allows users to add more themes (coverages and georeferenced images) to an existing map.
Update List: Updates the list of available themes for the user to display and analyze.

Distance

This tool measures the distance and area of user defined regions. The IDGIS client automatically keeps track of the corresponding geographic location in response to the mouse location, while in this mode.

Query

This function displays the attributes of themes selected by the user. The result is displayed as table(s) in a HTML document on a new browser window. The spatial query is currently handled by ArcView GIS server. Spatial Analysis

IDGIS supports the following spatial analysis functions: buffer, intersection, union and erase. The ArcInfo GIS server handles these functions. The resulting new coverage is stored in the unique directory created for the remote client. Currently, the user has to update the theme list in order to view the results of a spatial analysis function. An example of the result of a buffer analysis function is shown in Figure 6.

Figure 6. An example of IDGIS spatial analysis (buffering) and zooming functions.

CONCLUSION

IDGIS is a prototype for distributing geographic data across the Internet. IDGIS is an integration of Web technologies and the power of commercial GIS. It enables multiple local and remote clients to perform routine GIS functions, viewing, query and spatial analysis, on the distributed data.

A detail description of the IDGIS system components and their communication model was presented. The earlier BSD sockets version of the IDGIS server (IdgisSvr) was ported to Java. The Java based IdgisSvr was able to utilize Java's multithreading, synchronization, and object-oriented features, and classes packages in its design. Sun ONC RPC was used as the communication protocol between IdgisSvr and the commercial GIS servers, ArcView and ArcInfo.

The system functions and sample runs of IDGIS were presented. The current system functions are quite limited. Future extensions of IDGIS will include more functionality and a more intuitive user-interface (e.g. scrollable legend, image menu, etc.). System performance and the availability of GIS servers are the two possible bottlenecks. Future version of IDGIS will support multiple GIS servers and will incorporate data migration and load-balancing techniques to increase performance and availability.

REFERENCES

Aronoff S. (1993). Geographic Information Systems: A management Perspective, WDL Publications.
Bach M. J. (1986). The Design of the UNIX Operating System. Prentice-Hall.
Blommer J. (1992). Power Programming with RPC, O'Reilly & Associates, Inc.
Comer D.E. and Stevens D.L. (1993). Internetworking with TCP/IP Vol. III: Client-Server Programming And Applications (BSD Socket Version), Prentice Hall.
Esri (1991). ARC Command References, Environmental Systems Research Institute, Inc.
Esri (1995). Understanding GIS: The ArcInfo Method. Environmental Systems Research Institute, Inc.
Flanagan D. (1996). Java in a Nutshell, O'Reilly & Associates, Inc.
Huse S. M. GRASSLinks: A New Model for Spatial Information Access in Environmental Planning. URL: http://www.regis.berkeley.edu:80/sue/phd/.
JavaSoft White Paper. The Java Language: An Overview. URL: http://java.sun.com/doc/Overviews/java/java-overview-1.html.
Lemay L., and Perkins C. L. (1996). Teach Yourself Java In 21 Days, Sams.net Publishing.
Morrison M., et al. (1997). Java Unleashed (2nd Ed.). Sams.net Publishing.
Onsrud H. J. and Rushton G. (1995). Sharing Geographic Information, Center of Urban Policy Research, NJ.

Yew Kuan CHOO and Chen-Chen LEE
STARR Lab, Dept. RLEM
Texas A&M University
College Station, Tx 77843-2126
Tel: (409) 845-1553 Fax: (409) 845-9749

ykchoo@tamu.edu / athena@ivan.tamu.edu