WMS and GML based Interoperable Web ... - ACM Digital Library

WMS and GML based Interoperable Web Mapping System * Shashi Shekharl, Ranga Raju Vatsaval ‘lj2, Namita Sahayl, Thomas E. But-k”, Stephen Lime 3 ‘Department of Computer Science and Engineering, University of Minnesota EE/CS 4-192, 200 Union Street. SE., Minneapolis, MN 55455. [vatsavailshekhar] Qcs.umn.edu ‘Remote Sensing and Geospatial Analysis Laboratory Department of Forest Resources, University of Minnesota 115, Green Hall, 1530 N. Cleveland Ave, St. Paul 55108. [vw~~T#Jw~] @gis.umn.edu Minnesota Department of Natural Resources, St. Paul, MN 55155 [steve.Zime]@gis.umn.edu tion of multiple documents in a distributed environment, DOM based parsing offers a better solution.

ABSTRACT Recently the World Wide Web has become a popular vehicle for information distribution and web based geographic information systems (GIS) are rapidly evolving and adapting to these new environments. The main hindrance for building true interoperable distributed geographic information systems is the lack of any standard exchange mechanism between the diverse GISes connected over the web. Recent efforts by the OpenGIS Consortium have resulted in several specifications to alleviate these problems. Web Map Sever (WMS) and Geographic Markup Language (GML) are such standards for developing interoperable web based Geographic Information Systems (Web-GIS). GML is an XML (extensible Markup Language) encoding for the transport and storage of geographic information, including both geometry and properties of geographic features. In this paper we describe a WMS compliant map server and GML based client. This integrated system leads to a true interoparable Web-GIS. GML based client for the first time offers client side query processing capabilities and at the same time provides several challenges. The parsing techniques have performance considerations since the size of GML documents is generally huge and often the queries result in multiple passes over these documents. In this study we also evaluated the two well known parsing approaches - simple API for XML (SAX) and the document object model (DOM) for single and multiple passes. Our study shows that SAX performs better than DOM for single pass; thus for simple applications like visualization, subsetting, the SAX model is superior. However, for intensive applications involving queries requiring multiple passes over documents or integra*Supplementary material http://mapserver.gis.umn,edu/

can

be

found

Keywords WMS, GML, XML Schema, GIS, DOM, SAX, DTD, XSLT.

1. INTRODUCTION The Internet and the Web are changing the ways in which spatial data are accessed and disseminated. Initial efforts have resulted in map visualization [6], and quickly followed by query capabilities [13], [5]. The continued efforts have resulted in server centric GISes like [ll], [9], etc. These systems were based on Common Gateway Interface (CGI) wrappers to the server-side standalone geographic information systems (GIS). This resulted in thin-client/fat-server system. The entire query and geo-processing is performed on the server and often the results were converted into static images (e.g. GIF, JPEG). An overview of Internet GIS architectures can be found in [lo]. Apart from performance issues [14], the major limitations with these systems were the interoperability. Recent efforts by OpenGIS consortium have resulted in two standards that address the interoperability, viz. Web Mapping Sever (WMS) [8] (also called as Web Mapping Testbed (WMT)), and Geographic Markup Language (GML) [7]. WMS specification standardizes the way in which maps are requested by clients and the way that servers describe their data holdings. These maps are generally rendered in a standard format like Graphics Interchange Format (GIF), Portable Network Graphics (PNG), etc. On the other hand GML is an XML encoding for the transport and storage of geographic information, including both the spatial and non-spatial properties of geographic features. XML is fast becoming standard of data exchange between web applications. HTML (Hypertext Markup Language) and XML are both subset of SGML (Standard Generalized Markup Language). However there is a subtle difference between HTML and XML: HTML tags serve the purpose of describing how the data items should be displayed, while XML tags describe the data itself. This difference is very important, because the self-describing nature of XML allows the programs to interpret the data in XML documents. Recent research has been focused on modeling the data stored

at

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. GfS’Ol, November 9-10,2001, Atlanta, Georgia, USA. Copyright 2001 ACM l-581 13443-6/01/0011...$5.00.

106

in XML documents, e.g. semi structured data models [l], [12], standardizing the query language for XML [2], [16], optimization and compression. Interpretation of data stored in XML documents is possible due to the existence of Document Type Descriptors (DTDs) or XML Schema. GML will have a great impact on the ability of organizations to share geographic information with one another and to enable linked geographic datasets. GML also provides several challenges in terms of query processing, indexing etc. Previous studies have [3], [4] have considered wrapper based XML solutions for web mapping. To the best of our knowledge based on literature survey, there are no previous studies addressing the computational issues related spatial query processing on GML documents.

1.1

metadata. MapServer was designed originally as a map and spatial query engine so generic metadata storage was added to MapServer configuration files to fully support WMT requirements.

MAP

NAME ‘example’ SIZE 300 300 IMAGECOLOR 255 255 255 IMAGETYPE PNG EXTENT 427400 5228000 451800 5254000 PROJECTION +init=epsg:26915 END WEB METADATA vms-title ‘Example WMT application’ wms_onlineResource ‘ h t t p : / / . ’ wms_contactPerson ‘John Doe’ urns-contactOrganization ‘Acme, Inc. ’ urns-contactVoiceTelephone ‘123-456-7890’ vms_contactFacsimileTelephone ‘098-765-4321’ ‘johnOacme.com’ urns-contactElectronicMailAddress END END LAYER NAME ‘water’ DATA ‘/usr/data/shapefiles/water’ CLASS COLOR 0 0 255 END END END

Contributions of this paper:

In this paper we describe a WMS compliant map server and GML based client. WMS compliant MapServer is an extension of original UMN MapServer. This server is natively extended to support WMS features as opposed to wrapperbased approaches. This server directly generates GML output, which will then be parsed and rendered by GML Client. GML client also allows client side queries. We compare the performance of SAX and DOM parsers for GML, to support spatial single scan (point, range) and multi-scan (e.g., join) queries. We provide algebraic cost models for single scan and multi-scan strategies in processing queries. Finally we provide regression based experimental results for these algebraic cost models.

1.2 Outline and scope The remainder of this paper is organized as follows. Section 2 describes the WMT compliant MapServer architecture. Section 3 introduces GML and parsing techniques. In Section 4 we describe GML client, provide algebraic cost models. Section 5 provides experimental results. Section 6 provides brief conclusions and future research directions. The scope of the paper is limited to a comparison of SAX and DOM parsers for supporting spatial queries on GML datasets. We have limited the comparison to response time measurements on in-memory processing of spatial queries and have not measured memory uses, which are significantly different for SAX and DOM. Furthermore, we have not analyzed communication or I/O costs, nor have we explored query language issues for GML or considered other XML representations for spatial datasets.

Sample MAP file MapServer applications are built using a single configuration file called a “map file” (see example provided above). Map files are used to control virtually all aspects of an application such as what layers are to be drawn, how they are rendered, and how they are queried. This file becomes the means for a MapServer developer to add WMT compatibility to an application. The WMT functions work off the map file to develop content matching the users WMT request. Any standard browser (or client system) can ask a WMS compliant server for one or more of the following services: map images (GetMap), service-level metadata (GetCapabilities), and optionally information about particular features (GetFeatureInfo). These requests are submitted to the sever in the form of Uniform Resource Locators (URLs). URLs are formed using a set of standard parameters [8](e.g., width, height, bbox, srs, etc.), based on the user interaction with client system. For e.g., a request to a AVHRR hurricane image may translate into the following URL for MapServer: http://terrasip.gis.umn.edu/mapserver.cgi?VERSION= l.l.O&REQUEST=GetMap& SRS=EPSG%3A4326& BBOX=-97.105,24.913,78.794,36.35S&WIDTH=560& HEIGHT=350& LAYERS=AVHRR-09-27& STYLES=default&FORMAT=image/gif. WMT request handling is managed through a simple broker function that examines the parameters passed into a MapServer application. This function then determines which, if any, type of WMT request needs to be processed. If no WMT compliant request is made then control is handed back

2. WMT COMPLIANT MAPSERVER The MapServer [5] is a system for developing web-based GIS applications. The core of the system is a Common Gateway Interface (CGI) application that allows developers to rapidly build and deploy web applications based on GIS databases using simple text-based configuration and presentation templates. In addition to the CGI interface MapServer features a scripting interface, MapScript, to the low level C API. MapScript allows developers to use scripting languages such as Perl, Python and Tk/Tcl to build custom applications. The goal of the MapServer/WMT integration effort was to develop native WMT compatibility into the MapServer in such away that would allow users of the CGI application and those writing custom applications using MapScript to take advantage of it. WMT capabilities requests require the presentation of service and

107

to the calling function for normal processing. In this wa.y WMT functionality can easily be added to any MapServer application even though that application may also be a normal MapServer application. Individual WMT request ham dling (e.g. g&Map, g&Capabilities or getFeatureInfo) is done using helper functions written in C using the MapServer API. The resulting spatial data is converted into GIF format (as requested, see FORMAT tag in the above URL) and is returned to the client. This representation has the advantage that the maps can be viewed in a standard browser, but client side query processing cannot be achieved. Recent GML standard allows client side query processing and interoperability. In GML enabled mode, MapServer generates output in GML format. Basic architecture of enhanced MapServer is shown is in Figure 1. More details on architecture can be found in [14], we concentrate cm client side rendering (GMLView) and query capabilities in rest of this paper.

/Clients

information, which includes both the geometry and properties of geographic features [7]. The initial release of GML conforms to OGC’s “Simple Features” specification. GML provides support for the geometry elements corresponding to the Point, Line&ring, LinearRing, Polygon, MultiPoint, MultiLineString, MultiPolygon, and GeometryCollection. It also provides coordinate element for encoding coordinates and Box element for defining spatial extents.

3.1 Parsing Parsing is the process of assigning structure to sentences with a given grammar. There are two basic models for XML document parsing, namely SAX and DOM. A general comparative analysis of DOM and SAX, which differ significantly in origin, scope, and programming style can be found in [15]. The models are not in direct competition with each other; each has strengths and weaknesses and can even be combined in certain applications. The most important difference between SAX and DOM is that SAX presents the document as a serialized %vent Stream” (a sequence of calls to a handler function as each chunk of XML syntax is recognized) rather than a ‘tree’ as in DOM. A major disadvantage of this approach is that SAX does not support random-access manipulation of the document To access the data after parsing is done, it is the responsibility of the application to store the data. But this disadvantage turns into an advantage where the user can discard information that will not be needed. Therefore the use of SAX can result in reduced memory overhead compared to DOM, which requires to retain the complete document as a tree in memory. It is possible to combine SAX and DOM within a single system. We used Xerces Java Parser 1.2.0 which supports the XML 1.0 recommendation and contains advanced parser functionality, such as XML Schema, DOM Level 2 version 1.0, and SAX Version 2. We have chosen the Xerces parser mainly because of its easy availability, functionality, and, more importantly, the close integration with the Apache web server. GML maps generated form the MapServer are validated using this parser.

(Std. Browsers~

Geospatial Analysis

iL Database Access Layer

4. Figure 1: WMS Complient

MapServer Architecture

3. GML AND PARSING XML, the eXtensible Markup Language, has recently emerged as a new standard for data representation and exchange on the Internet. The basic ideas underlying XML are very simple: tags on data elements identify the meaning of the data, rather than, for example, specifying how the data should be formatted (as in HTML), and relationships between data elements are provided via simple nesting and references. Yet the potential impact is significant: Web serxrs and applications encoding their data in XML can quickly make their information available in a simple and usable format, and such information providers can interoperate easily. Information content is separated from information rendering, making it easy to provide multiple views of the same data. XML is simple, easily parsed, and self-describing. GML is an XML encoding for the transport and storage of geographic

I08

GMLVIEW AND SEARCH COST MODELS

In this section, we present the design and implementation of a prototype client to support single scan and multi-scan query processing strategies on spatial data in GML form to support map rendering over the Internet. Here we provide the implementation details of the proposed GMLView; the applet for rendering GML documents in a web browser environment; and the cost models for point, range, and join queries an GML documents for search strategy based on SAX and DOM models. We have implemented single scan and multi-scan searches using both SAX and DOM. First we formally define the parsing and rendering as follows: Given A GML document and a Query Window Find Select the elements within a user defined query window Objective Select the suitable parser (DOM or SAX), parse and construct internal data structures. Render the map using a java applet. Provide a cost model for point and range query and join operation for DOM and SAX models

Constraints XSL is not sufficient for geographic applications. Converting vector data to raster data, e.g., GeoTIFF/JPEG gives a static representation of the map and not suitable for client side queries.

documents that match conditions defined on document content and structure, and can construct new documents based on what is selected. Different queries, such as point and range queries can be performed on GML documents. For example, ‘list the capital of Minnesota’ is a point query. An example of a range query is to find all rectangles whose area is greater than ‘a’. A join operation can be used to query names of cities whose population is greater than the population of Minneapolis. Point query and range are basically a single scan query. In a single scan query, a record (tuple) in the table (relation) being queried has to be accessed at most once. Thus the worst-case scenario, in terms of time, is that each record in the table will be accessed and processed to verify whether it meets the query criterion. For a join operation, a nested loop strategy is applied which requires multiple scans over the GML document. Because a record in one table can be associated with more than one record in a second table, records may have to be accessed more than once to complete the join. Here we present the computational cost models for single scan and multi-scan strategies for processing queries using SAX and DOM parser models. In the cost model, we calculate the average time to search elements in a single pass and in multiple passes. Let n be the number of nodes in document object model of a GML file, p be the average parse time required for a node, m average memory access time for tree/object, x be the number of passes, and T be the time required to search an element. Since p and m are the average parse and memory access times for a node, we can consider these two parame ters as constants in our model. Single pass: For a point query, SAX will search the element as it parses the document. Thus, on average it needs to parse half a document to get that element. Therefore, we

4.1 GML View We used DOM for rendering the map from the GML document. It is easy and efficient to traverse the tree generated by parsing using the DOM and render the map on the basis of node information extracted from the tree. Therefore, we choose DOM in lieu of SAX for map rendering of a GML document. Parsed map can be either rendered directly or can be converted into static images. Advantages and disadvantages of these approaches can be found in [lo]. Conversion to standard image does not require any client support, but client side querying and processing are limited. On the other hand GMLView directly takes GML data from the MapServer and renders the map in a client browser using applets. This approach is flexible and allows client side processing like query and integration of maps from different map servers.

4.2

Spatial Computations on GML data (Client)

Queries operate on single a document or fixed collections of documents. They can select a whole document or a subset of documents based on what is selected. Different queries such as point, range, and join queries can be performed on GML documents. Queries can be broadly divided into two categories: single scan query (point query, range query) and multi scan query (join query). In a single scan query, a record (tuple) in the table (relation) being queried has to be accessed at most once. Thus the worst-case scenario, in terms of time, is that each record in the table will be accessed and processed to verify whether it meets the query criterion. E.g. “List the names of all hotels which are within 15 miles of the Minneapolis downtown,” is an example of a single scan query. The result of this query will be all hotels, which intersect 15 miles centered on the courthouse. In rendering the map from the GML document, the coordinates have to be extracted from the GML document. This operation is a special case of range query where the data subset that fits inside a viewport is selected. A join query is basically an example of a multi scan. Because a record in one table can be associated with more than one record in the second table, records may have to be accessed more than once to complete the join. In the context of spatial databases, when the joining attributes are spatial in nature, the query is referred to as a spatial join query.

4.3

get

0) T( SAX+-scan) where

= i(P*C(SAX,s--scan))

B(SAX,s-scan) and C(SAX,s-scan)

a& A(sAx,~-=~~)~

are constam

For a range query, SAX will scan the whole document. Therefore

(2)

Search for query elements using the DOM and SAX model

T( SAX,s-scan)

= A(sAx,~-scan)

where B;SAx+-sca,&) =

+ +AX,s-scan) * n

p*C(SAX,s--scan) and A(sAx,~--~~~~),

B;SAX,s-scan) and C(SAX,s-scan)

We designed and implemented the software prototype in Java to support single scan and multi-scan query processing strategies on spatial data in GML form to compare the performance of DOM and SAX.

4.4

B(sAx,~-~~~~)

= A(sAx,~-scan) + B(SAX,s-scan) * n

are const=ts.

For a point query, DOM will first parse the whole document and then search the element in the tree representation of the document. We get

Computational complexities and cost model

(3)

In this section we present algebraic cost models for single and multi-scan strategies for processing queries on GML documents. The computational cost is the response time on in-memory processing of spatial queries. The communication and I/O costs have not been analyzed. Queries operate on a single document or fixed collections of documents. They can select a whole document or a subset of

T( Do.w,s--scan)

where B(DOM

,s

= A(DoM,~--scan)

- scan)

=

+ +JOM,~-scan) * 7~

2‘C (DOM,s--scan)(2

*

p

+ m) and

and c(DoM,~-~~~~) are constants For a range query, DOM will first parse the whole document and then search all elements in the tree representation of the document. We get A(Do,vI,~-~~~~),

109

B(DoM,~-~~~~)

( 4 ) T(DOM,s-scan) where

= A(DOM,s-scan) + B;DOM,s--scan) * n

B;D~M,s-scan) = c(~~~,s--scan)b+m)

B;DO.&,f,~--scan)

and A(DoM,~--~cuL),

drawn from the results obtained from these experiments. These graphs clearly show the behavior of SAX and DOM for single and multi-scan search strategies. These results were used to calculate the actual values of the constants of the cost models

and C(DOM,s-scan) we constants.

Multiple passes: To search x elements, SAX needs x passes. It will parse the document x times and on average it needs to parse half the document in each pass. Therefore, we get ( 5 )

T(sAx,~-scan)

=

C(SAX,n-scan) + &AX+-scan) *x + +AX,s-scan) * 2 * 75

where B(SAX ,m-scan) = ;P *C(SAX,s-scan)

and -‘+sAx,~-scan)~

B(SAX,s-scan), C(SAX,m-scan) and C(SAX,s-scan)

are constants

To search x elements, DOM will first parse the whole document and then search x elements in the tree representation of the document. Thus, it needs to parse the document only once and therefore

(6)

T( DOM,m--scan)

= A(Do~,rn-scan) + B(DOM,m--scan)~ +C(DOM,m--scan) *x * n

where B(DOM ,m-scan)

= p*C(DOM,m--scan),

C(DOM ,m-scan)

=

fm * C(DOM,m-scan) and A(~~~,n--scan), B(DoM,~-~~~~), C(DOM ,m-scan) and C(DOM,~-~~~~) are constants.

From the above expressions, we see that if n, i.e., the number of nodes in the GML file is large, the SAX model is better for searching a single element than the DOM model; the DOM search model starts a search operation only after it has parsed the whole document. However, for multiple passes, i.e., when x is large, the DOM model is better since it needs to parse the document only once, and all x searches can be performed on the same tree structure of the document, which resides in memory. Since memory access time m is very small as compared to average parse time for a node p, so m in equation (6) is negligible as compared to p and, therefore, search time is proportional to parse time np. For the SAX model, from equation (5), we see that the search time for x elements is proportional to x times np. We also see that for very large n, the in-memory representation of the DOM tree may sometime make the DOM model less efficient.

Figure 2: Effect of varying number of objects

5.1

Effect of number of passes (x) on average search time (T)

We varied the number of nodes in the GML file and measured search time vs. number of passes for SAX and DOM. Figure 2 shows graphs for search time vs. number of passes for different number of nodes/objects. As can be seen, for a single pass, search time for SAX is less compared to that for DOM. For multiple passes, search time is almost constant for the DOM model for different numbers of passes. However, for SAX search time increases with the number of passes. This figure also shows that after two passes, the DOM model performed better in terms of search time than the SAX model. This is because of initial overhead for constructing DOM tree.

5. EXPERIMENTAL EVALUATION In this section, we present the experimental results of the map rendering over the Internet and the search query processing using the DOM and SAX models. We designed and performed experiments to compare the performance of DOM and SAX for single scan and multi-scan query processing strategies on spatial data in GML form. The calibration of parameters in the algebraic cost models was done through multivariate regression analysis of measurement results. We implemented the client side query processing using the SAX and DOM model in Java. We varied the number of objects in the GML file and measured search time for single and multiple passes. The results are shown in Figures 2 and 3. For this experiment, we also extracted a part of the Minnesota GML file and performed single and multiple pass searches. The performance graphs (Figures 2 and 3) were

5.2

Effect of number of objects (n) on average search time (Tavg)

We also plotted search time vs. number of objects/nodes for different passes, as shown in Figure 3. It was observed from the results that for single pass, for any number of objects, time to search an element for SAX is small as compared to DOM. But for multiple passes, DOM performance is always better than SAX.

6.

CONCLUSION AND FUTURE DIRECTIONS

We implemented a WMS compliant MapServer and GML based client. This integrated system provides a truly interoperable Web-GIS environment. The client can locally process GML data and render maps in a standard Web browser

110

ratory Cooperative agreement number DAAH04-95-2-0003/contract number DAAH04-95-c-0008 and by the cooperative agreement with NASA (NCC 5316) and by the University of Minnesota Agriculture Experiment Station project MIN-42-044. We would like to thank our research group members at Remote Sensing and GIS Lab, and Spatial Database Research Group for their help and useful comments. We would like to thank Ajay Pandey for his help during the development of GMLView.

8.

REFERENCES

P. Buneman. Semistructured data. In In Proceedings of ACM SIGMOD/SIGACT Principles of Database Systems. PODS, 1997. PI A. Deutsch, M. Fernandez, D. Florescu, A. Levy, and D. Suciu. Xml-ql: A query language for xml. 1998, http://www.w3,org/TR/NOTE-xml-ql/. 131 A. Gupta, R. Marciano, I. Zaslavsky, and C. Baru. Integrating gis and imagery through xml-based information mediation. In Proceedings of Integrated Spatial Databases, Digital Images and GIS, LNCS 1737. Springer Verlag, 1999. A. S. Jianting Zhang, Muhammad Javed and 141 L. Gruenwald. Prototype for wrapping and visualizing geo-referenced data in a distributed environment using xml technology. In In Proceedings of the eighth ACM symposium on Advances in geographic information systems. ACMGIS 2000, Washington D.C. USA, 2000. 151 MapServer. Mapsever home page. http://mapserver.gis.umn.edu/. MapViewer. Xerox part map viewer. http://mapweb.parc.xerox.com/map/. [71 OGIS. Geography markup language (gml) ~2.0. http://www.opengis.net/gml/Ol-029/GML2.html. OGIS. Web map server interfaces implementation specification. http://www.opengis.org/techno/specs/00-0 PCI. Spans webserver. http://www.pcigeomatics.com/product-ind/spweb.html. Z.-R. Peng. An assessment of the development of internet gis. In Proceedings of the ESRI User Conference, 1997. REGIS. Grasslinks 3.1. http://www.regis.berkeley.edu/grasslinks/. D. Suciu. An overview of semistructured data. Sigact News, 29(4):28-38, 1998. 1131 USCB. Tiger mapping service. http://tiger.census.gov/. 1141 R. R. Vatsavai, T. E. Burk, B. T. Wilson, and S. Shekhar. A web-based browsing and spatial analysis system for regional natural resource analysis and mapping. In In Proceedings of the eighth ACMGIS, Washington D.C. USA, 2000. 1151 W3C. Architecture domain, document object model faq. http://www.w3.org/DOM/faq#SAXandDOM. W3C. Conference on standardization of xml query languages. 1998, http://www.w3.org/TR/NOTE-xml-ql/.

PI

Figure 3: Effect of varying number of passes environment. We provided algebraic cost models for point, range and join queries based on two parsing models. Based on the analysis, we observer that: (a) for point and range queries, the SAX model is better, but, for join, the DOM model is better, (b) for very large XML documents, the inmemory representation of the data by the DOM tree may sometime make the DOM model less favorable. But for processing the data it is more relevant, (c) SAX is more efficient for web applications such as producing a subset of data or parsing a very large GML document where in-memory representation of the data will affect the performance of the application. It requires fewer system resources to perform the task as compared to DOM. The present research also brings into focus several key research issues: (a) developing indexing techniques to reduce scanning overhead on GML documents so that the queries can be performed more efficiently, (b) comparing buffer needs for spatial query processing, (c) developing a query language (in lines of XML-QL) suitable for GML documents, (d) developing techniques for topological queries over GML documents, (e) query optimization techniques. We know that it is important to have spatial indices for efficient query processing, so it would be interesting to study the optimization techniques in the absence of any spatial indices and on tree representation of GML data. We conclude by saying that there are great research opportunities in terms of developing a suitable query language that supports user defined predicates, and developing query optimization techniques for successful use of GML in Web-GIS environments.

PI PI

PI

PO1

[Ill

[I21

WI

7. ACKNOWLEDGEMENTS This research has been supported in part by the Army High Performance Computing Research Center under the auspices of Department of the Army, Army Research Labo-

III

Conference on