A generic tool for enhancing Mapserver Administration Klaus BOEHM*, Rainer SCHUETZE+

*OGM Laboratory LLC

6825 Pine Street, Omaha, NE 68106,

USA kboehm@ogmlabs.com

+ i3mainz, University of Applied Sciences,

Holzstraße 36, 55116 Mainz, Germany

schuetze@geoinform.fh-mainz.de

0. ABSTRACT

The trend of utilizing Internet-GIS products has increased significantly in the last years. Web mapping allows the deployment of GIS related data of the intranet and internet. This paper addresses the administration of GIS based internet applications with special emphasis to ArcIMS solutions. Two shortcomings for the administration were identified and a solution is proposed which consequently decouples the GIS content and the corresponding client functionality. The proposed solution was implemented in a test application for the City of Ralston (NE, USA).

Keywords: ArcIMS, XML, ESRI, CMS

1. INTRODUCTION Web Mapping applications allow the deployment of GIS data and functionality over the intranet and internet. The utilization of this technology has been increasingly popular in last years |BUHMANN E., WIESEL J. (2005)|, e.g. corporations and public authorities are combining more and more of their existing data sets with spatial information and present it in map related contexts. Numerous technologies for the realization of web mapping applications have been available for years, such as commercial products as ArcIMS from ESRI but also non commercial solutions for instance the UMN map server. The ArcIMS is currently the most common internet map server |BUHMANN E., WIESEL J. (2005)|. In all cases a server application processes the client requests and calculates a map representation as well as the query results according the users input. The results are typically presented at the web browser by HTML related technologies |ZHONG-REN P., MING-HSIANG T. (2003)|. We analyzed the process of establishing and administrating web mapping application with regard to the data maintenance and the connection between the data and the client functionality. As the result we identified two potential

shortcomings: First, the data which is published in the internet through a map server is typically a subset of a larger, significant more complex and sometime even confidential “main” dataset. Consequently the dataset to be published in the internet needs to be reduced and adapted manually from the original data. This therefore leads to redundant data management. All updates have to be processed in the original and the reduced internet data set or the updated version of the main dataset hast to be reduced again. Second, a drawback for most implementations is the close coupling of the data and the functionality available at the client. For instance, the query functionality or the query result presentations are typically tailored to the dataset available. In consequence, the maintenance of the system, e.g. changes of the functionality usually requires programming at the client and server software. Requests for changes are quite frequent, caused by general updating procedures or by adding or removing certain datasets. For instance, the data administrator may wish to add a new layer to the map. The user, consequentially, should be able to access and to search for attributes on this new layer. This functional enhancement requires changes at the client application, e.g. a new search form has to be added. Furthermore, programming adaptations at the server side may be necessary as well. The objective of our research is to overcome the problems mentioned above by decoupling the dataset, the client/server functionality and the client presentation. The approach is to store an abstract description of the functionality and the related connected GIS datasets. Based on this abstract description, the client user interfaces and the related functionality is generated. This approach was implemented for an ArcIMS Web Map Server environment and tested at a Web Mapping application for the City of Ralston, NE, USA. The remainder of the paper is structured as follows: first we analyze typical ArcIMS applications with regard to the maintenance. In the following chapter we outline our concept of decoupling the dataset and the client/server functionality. Chapter 4 describes the realization of our concept. In chapter 5 we validate the results achieved and provide on outlook for future aspects.

2. STATE OF THE ART In this chapter we will address briefly the typical process for publishing GIS data over the internet with special focus on ArcIMS technology. Moreover, in the second part of this chapter we will identify deficiencies of the common approach.

2.1. TYPICAL ARCIMS DEVELOPMENT PROCESS

A typically process for publishing GIS data in the internet through a map server is given in fig. 1. The example is based on ESRI tools and also further described in the ArcIMS Map Server white paper |ESRI (2004)|.

Figure 1: Simplified Workflow to publish a geographic data over the internet

The data source is typically given by a set of shape and raster files which are the result of preprocessing and analyzing work performed. By utilizing authoring tools such as ArcIMS Author or ArcMap (embedded in ArcInfo and ArcView) a map configuration file is created. This process covers also the cartographic aspect. By connecting the data source (e.g. layers) with these programs, the symbology definition, scale dependencies and other mapping parameters can be customized. This process includes among others:

• Setting feature labeling

• Change the raster visualization (pseudo color)

• Set line types, Set Point types, Set Polygon filling The map configuration file is used by the ArcIMS server. The user accesses maps and the geographic data via a web browser application. These applications can be of different scale and complexity. The article |IGIS (2005)| classifies four different categories of ArcIMS applications types: “out-of-the-Box”, “customized out-of-the-box, “Custom Server side ArcIMS Web Applications” and “Embed ArcIMS into Larger Web Applications”. The first two categories make extensive use of server and mostly client side functionality which comes with the ArcIMS. The latter categories require the development of a web application by utilizing the common web development and scripting technologies such as servlets, server pages and JavaScript. 2.2. DEFICIENCIES

Two potential deficiencies with regard to maintenance can be identified when programming the web mapping applications as described above.

2.2.1. Multiple map configuration files

The dataset used and the cartographic appearance are determined in the map configuration file which is used in various applications. The datasets, however, are typically developed in and used for complex (desktop) GIS analysis tasks. The dataset which is presented in the internet is usually a subset of the original data. As show in the fig. 2 the GIS administrator has to reduce the data source and has to generate and especially maintain a second configuration file. In particular the maintenance will request discipline and additional effort.

Figure 2: Workflow to publish a geographic data over the internet with data reduction

2.2.2. Close Coupling of Functionality and Data

The second potential deficiency is a close coupling of the data and the functionality available at the client (see fig. 2). This is the case when the HTML/JavaScript client program and the server side logic are tailored to a dedicated data set. All changes of the dataset require reprogramming on the client and server side application.

3. CONCEPT The objective of our research is to overcome the problems mentioned above by decoupling the dataset, the client/server functionality and the client presentation. The approach is to store an abstract description of the functionality and the related GIS datasets and to maintain this information

with a dedicated administration front end. Fig. 3 shows that the original Map Configuration file is utilized. The administration tool processes the data and generates and maintains the abstract description mentioned above. Based on this abstract description, the client user interfaces and its functionality is generated.

Figure 3: Workflow to publish a map over the internet with data reduction by the

administration tool

The abstract description is represented in a XML file (see fig. 4 “Fusion-File”). The file contains automatic generated descriptive information of the datasets from all layers and the settings made by the administrator. The admin tool scans the map file descriptions and synchronizes it with the Fusion-File. Changes, additions or removals of or within the layers are adapted to the Fusion-File. The web based user interface of the admin tool allows the administrator to browse through the layer definitions; activate queries for layers and features and to determine the data which will be presented as results. The client component will be automatically generated according the description of the Fusion-File, so will be the functional behavior.

Figure 4 Conception of the ArcIMS Administration Tool

4. REALIZATION The realization of the concept described above is outlined in this chapter. It addresses the admin tool and the realization of the client functionality based on the Fusion-File. 4.1. ADMIN TOOL

The admin tool is based on a clear defined XML-file structure for the Fusion-File and combines import and synchronization methods as well as the administration front-end. 4.1.1. Fusion File

The Fusion-File is an abstract description of the map definition file and contains the configuration parameter for the application. The structure of the fusion file is defined as follows:

<?xml version="1.0" encoding="iso-8859-1"?> <layers> <layer name="layerName" [identify= ("false" | "true") ]> <title>layer title</title> (<description/> | <description> desrcitption </description>) [ <features> <feature name="NAME"> <title>Feat. Title</title> <query>(false | true)</query> <identify>(false | true)</identify> </feature> </features> ... ] </layer> ... </layers>

• Title of a layer. The layer title provides an intuitive phrase of the layer. The layerName is the name of a layer used in the ArcView or

ArcExplorer projects. It is defined in the map configuration file and could be very cryptic, e.g. short names with words separation by '_' (underscore). The layer title is used instead of the layer name in our application.

• Description of a layer: The description is an additional option to provide to the end-user brief information of what the layer contains.

• Feature title. The feature title provides an intuitive phrase of the feature name. The feature name, which is the item attribute header of a layer, is always stored in layers in upper chase. The feature title is used instead of the feature name in our application.

• Query feature. The query setting defines if a feature title should be shown in the search form and if the user should be able to search by its attribute. If all features on a layer are selected as “not query-able”, the layer itself is “not query-able”.

• Identify feature. The administrator can define if the user can identify a feature attribute on the map. If all feature attributes of a layer are selected as not be “identify-able”, the layer itself is not “identify-able”.

4.1.2. Import, Synchronization and Front-End

The synchronization of the map definition file with the fusion file is performed during the initialization process of the admin tool. The administration tool lists all layers of the map definition file in combination with the settings information from the Fusion-File (see fig. 5). All adaptation and configuration made by the administrator are saved in the Fusion-File (fig. 5 right) and is thus used for the client functionality. The partial listing of the Fusion-File in fig. 5 shows that information is stored only for those layers which are marked as “identify-able” or “query-able”.

Figure 5 Administration User-Interface

4.2. EMBEDDING THE FUSION FILE IN THE CLIENT FUNCTIONALITY

The test application environment is a web mapping demonstrator for the City of Ralston (NE, USA). The left part of fig. 6 shows the web client. The right part of fig. 6 depicts the elements of the client user interface, which are controlled by the admin tool. In particular these are the following elements:

• Search form; The search-form allows the selection of features by there attributes.

• Layer list; The Layer-list allows the user to set a layer on the map visible/ invisible and shows also which layer are identify-able.

• Identification functions; The identify-functions allow the user to select one or many elements on a layer to get attributive information.

• Result set; The result set lists the outcome of a query or selection but includes only the identify-able feature

Figure 6: Application of the results of the administration at the IMS site of the City of

Ralston, NE, USA.

The correlation between the interactive client components and the Fusion-File is explained based on the “query-component” for parks as shown in fig. 7.

Figure 7: Automatic generated query component according to the fusion file

5. VALIDATION AND FUTURE WORK The solution described above provides significantly improved support for the maintenance of the Web-based mapping application. Even though no

user study was conduced, the advantage is evident. For instance if the administrator wants to perform changes on the query options; it can be done with zero programming by selecting different check boxes in the admin tool (see fig. 5). A solution without an admin tool would have required hours of HTML/JavaScript programming. There are commercial products available as well, which provide customization of ArcIMS applications. Examples of these products are GEOSMART.NET, Freeance and OnPoint™. The functionality is partially vast and allows the user to tailor a complete ArcIMS application with little to no programming. The functionality of these products goes beyond to the functionality of the admin tool developed within this research project. However our approach was from the beginning to develop a lean tool which can be further integrated other frameworks. An ideal combination from our point of view is the blending of our admin tool with the functionality of a content management system (CMS) for web application development (see |SCHUSTER G. (2003)|). This merges the GIS oriented administration functionality of the admin tool with the editing and publication functionality of a CMS. Consequently this allows the administrator to interactively add or remove elements from the application, or rearrange the layout. Moreover it is possible to change the look-and-feel rapidly. In addition the CMS inherent user management can be utilized for user tailored access to datasets. For a first prototype the CMS DotNetNuke |WALKER S., ET AL. (2005)| was used to explore the feasibility of the approach chosen. Figure 8 shows the interactive editing process using the CMS DotNetNuke.

Figure 8: Combination of admin tool and the CMS DotNetNuke

The feasibility examination showed us the potential of this integration. The challenges, however, are the integration of the fusion file with the CMS specific data repository. As a next step we foresee tackling these challenges in order to consequently merge the admin tool into a CMS environment.

6. REFERENCES

BUHMANN E., WIESEL J. (2005), “GIS-Report 2004“, Bernhard Harzer Verlag GmbH, Karlsruhe 2005, ISBN 3-9808493-4-1

ESRI (2004), “ArcIMS 9 Architecture and Functionality”, http://www.esri.com/library/whitepapers/pdfs/arcims9-architecture.pdf (status 01-07-2005)

IGIS (2005), “Are you qualified to build your ArcIMS Site?”, http://www.igist.com/PDF/EA_ArcIMS_v4.pdf (status 07-07-2005)

SCHUSTER G. (2003), “Entwicklung von Komponenten eines Geoportal-Frameworks”, http://www.zopecms.de/zopecms/loesungen/WebGIS/-pdf_pool/diplomarbeit_schuster.pdf (status 07-08-2005)

WALKER S., SANTRY P. J., BRINKMAN J., ET AL. (2005), “Professional DotNetNuke ASP.NET Portals“, Wrox Press Ltd., Birmingham 2005, ISBN 0-76459563-6

ZHONG-REN P., MING-HSIANG T. (2003), “Internet GIS: Distributed Geographic Information Services for the Internet and Wireless Networks”, John Wiley and Son Inc., Hoboken, NJ. 2003, ISBN 0-471-35923-8