Abstract

Elected officials & senior City/County staff frequently meet with citizens and neighborhood groups who wish to know "What have you done for me lately?" or "What is happening in my neighborhood?" Integration of GIS with Customer Relationship Management (CRM), permitting, work management and Capital Improvement Project systems makes it possible to answer these questions and convey the answers via maps. However, those officials meeting with the citizenry generally don't have the time or skills to create these maps and reports themselves. In response, IndyGIS developed a Map Subscription Service which allows users to choose to receive by e-mail maps and reports of various types on a periodic basis. This paper describes this ArcGIS Server based application, the reasons behind its creation, the technologies used and lessons learned during the project.

Background

Reasons for Application

Local government is personal government in many ways. Issues dealt with by local government have immediate effects on the population. Law enforcement, fire fighting, trash removal, snow removal, zoning and housing code enforcement, potholes and community development are all issues that citizens are passionate about. Unlike higher levels of government, local elected officials are constantly in the community. City County Council members generally hold full time employment in addition to their Council duties. Other elected officials meet regularly with community leaders and with regular citizens who come to their offices. Senior City/County staff attend frequent community meetings. In these encounters with the public, questions like "What is happening in my neighborhood?", "When are you going to repave my street?" and "What are you doing to help our community?" come up frequently. Because these questions deal with the particular areas of the City where the questioner lives, they are a natural fit for GIS. As a result, staff and officials attending community meetings often go supplied with maps that can provide answers to these types of questions. However, those officials who meet with the citizenry generally do not have the time or the skills to create these maps themselves. That task is usually delegated, often on short notice. As a result, the maps used in some meetings are of less than stellar cartographic quality.

The GIS Division (IndyGIS) of the Indianapolis/Marion County Information Services Agency (ISA) saw a need for a tool which could deliver high cartographic quality maps to senior staff and elected officials on a regular basis. A related need was also identified for a tool to allow City/County staff to produce high cartographic quality maps on demand without the need for desktop GIS software. These tools were seen as a way to leverage the cartographic talents of IndyGIS staff as well as a means to promulgate a consistent look for City/County maps and to expand usage of GIS data without increasing software costs.

Initial Plan

The initial concept was to develop 2 separate applications, a map subscription service and a wizard-type application for producing maps on demand. The plan was to develop the subscription service first then the wizard. IndyGIS staff would publish the maps that would be available for subscription. The wizard application would come later as developer time became available. This new wizard would replace an ArcView 3.x map wizard extension that was popular among users.

Revised Plan

As the concepts were being fleshed out, IndyGIS staff met with user representatives to help determine the functionality needed in the applications. The concepts behind both application ideas were explained to the users. They expressed their desire that the wizard application be completed first. Their reasoning was that people would be more apt to use the subscription service if they could first see the types of maps that it would deliver. From that conversation, the idea emerged to combine the two applications into one and deliver it in phases. The first phase would include the map wizard with later phases to add the ability to save map definitions and to subscribe to receive maps based on those saved definitions. In this manner, definitions for map specifications could be created either by users or by IndyGIS staff.

Application description

Definition of requirements for the initial phase of the application were completed in late January, 2005. Design of the first phase of the application was completed in late April, 2005 with work on code started by Woolpert, Inc. immediately following. An initial delivery of the first phase of the application was made on May 31, 2005 with final delivery of the first phase scheduled for late June, 2005.

The first phase of the system consists of a web-based, database-driven application to generate high cartographic quality maps on demand, a maintenance application for maintaining the database and a cleanup service to periodically remove PDF files generated by the Map Wizard.

Map Wizard

The Map Wizard is the main face of application. This web-based application steps the user through the process of creating a map and does so without displaying a map until the wizard process has completed. First it prompts the user to select a template for their map, specifying the size and orientation. (See Figure 1, below.)

Figure 1. Choosing a map template.

In the next step the user selects a set of base layers for the map (see Figure 2, below.) These base layer sets have been set up by IndyGIS staff with particular uses in mind and set up with symbology, scale thresholds, labeling and annotation preset for high quality display at any scale.

Figure 2. Choosing a base layer set.

In the next step the user chooses an overlay layer which will be the main focus layer for the map (see Figure 3 below.) Choices are limited based on the set of base layers chosen ensuring that the user gets the quality level they are expecting.

Figure 3. Choosing an overlay layer.

The user can then make a selection from the focus layer. The selection may be either a simple selection based on predefined query types (Figure 4) or a complex SQL-based query defined through a query builder (see Figure 5, below.)

Figure 4. Simple query entry.

Figure 5. Query builder.

In the penultimate step the user can chose to zoom the map to a specific geographic area such as a council district or neighborhood (see Figure 6, below.)

Figure 6. Choosing an area of interest.

Once the user has made all their choices, the system generates the map in PDF format and stores the map on the web server. The application provides a link to the PDF file on the web page of the wizard which the user can then click on to open the PDF file. The PDF can be printed or saved to the local hard drive of the user.

Maintenance Application

The maintenance application allows IndyGIS staff to modify the database tables (see Figure 7, below) that store the choices made available to users through the Map Wizard.

Figure 7 - Database design.

The application provides tabs for maintaining each of the main tables in the database. The first tab allows the maintenance of the table of map templates (see Figure 8, below.) Map templates are created from MapServer objects served by the ArcGIS Server. Each MapServer object served by ArcGIS Server may be the basis for a map template in the Map Wizard application.

Figure 8 - Maintenance page for map templates.

The second tab allows the maintenance of the sets of base GIS layers for the maps (see Figure 9, below.) This maintenance includes selecting group layers created in ArcMap and stored in an Oracle database using the ArcMap extension, called Catalog Interface, previously developed for IndyGIS by Woolpert. This tab also allows the administrator of the system to determine which overlay layers (the main focus layers for the maps) can be used with a particular set of base layers. This allows IndyGIS staff to ensure that maps created by the Map Wizard don't have conflicts such as a layer in a base layer set symbolized the same as the overlay layer used in the map.

Figure 9 - Maintenance page for base layer sets.

Additional tabs provide for maintenance of the overlay layers, including defining what columns from within those layers may be queried, and layers used to define the geographic extents of maps produced.

Cleanup Service

Since the Map Wizard will be generating files on our web server, we included a cleanup service in the definition of the system. This NT service removes the PDF files generated by the wizard from server on periodic basis.

Technologies and skills used

To IndyGIS and Woolpert staff members who worked on it, this system is exciting because of the mix of technologies used and the products and skills leveraged. The Map Wizard and Maintenance applications are ASP.NET applications, while the cleanup service is an NT service developed using VB.NET. The map generation is done by ArcGIS Server with data coming from an ArcSDE database. The templates are MapServer objects served by ArcGIS Server. The definitions for the base layer sets are created in ArcMap as group layers with the layer files then stored in an Oracle 10g database using a Catalog Interface extension to ArcMap developed by Woolpert. Metadata for the base layer sets, overlay layers and area of interest layers are retrieved from an ArcIMS metadata service via a lightweight ASP.NET application developed by the author.

Components of the application run on five different servers. The database tables used are stored within the same Oracle database as our SDE data on a Sun Solaris server dedicated to serving Oracle/SDE databases. ArcGIS Server resides on a Windows 2003 server. The web applications run on another Windows 2003 server running IIS. This server is also our ArcIMS Application server while the ArcIMS Spatial server components running on two Sun Solaris servers process the metadata requests.

Deploying the application successfully required skills in several different areas: The cartographic skills of IndyGIS's best map maker were required in designing map templates that were flexible enough to serve different user needs while maintaining a professional appearance. The same skills were needed to put together group layers to be used as base layer sets for the application. These group layers needed to be designed such that clear maps would be produced whether the user chose a map size and extent that forced 1:1200 scale maps or 1:175,000 scale maps in an application where the end user had no ability to choose which layers would be visible or how they would be symbolized or labeled. Considerable time was put into developing annotation layers using the Maplex extension to ensure that appropriate annotation would be available for inclusion in those group layers. Metadata had to be created for each of the group layers created as base layer sets and overlay layers. Finally, database design and programming skills were needed to actually construct the application. Seven different IndyGIS and Woolpert staff members contributed to this project.

Next steps

Once the initial phase of the system is completed work will begin on completing the vision for the system. The first step on the path to completion will be to enable users to save their map definitions and regenerate maps based on the same parameters but covering a different time period. This enhancement to the application will entail changes to the database design, providing a table to store map definitions. It will also entail adding some means of user authentication and account creation to the application. From a work flow standpoint, the map wizard would function the same up until the point where the map was created. At that time, the user would get another step in the process prompting if they want to save their map definition and if so, whether they want the map definition to be available to all users or to be kept private.

After the ability to save map definitions is added, we will add an application that will allow users to subscribe to receive maps on a periodic basis. This step will require additional modifications to the database providing tables to store email addresses, what maps a user wishes to receive, how frequently they wish to receive them and for how long. Once the user has subscribed to a map, the system would generate the map as requested by the user. The application would include a "renewal notice" that would accompany the last three "issues" of the map informing the user of the upcoming expiration of their subscription.

The final phase envisioned for this system would add the ability to generate reports based on selection criteria defined for a focus layer. The reports generated could be in addition to or in place of a map based on the same selection criteria. As with the map wizard, reports would be generated by selecting a focus layer, adding selection criteria and defining an area of interest. The report would then be generated as a PDF file and a link provided to the user. The reports would be deleted on the same frequency as the maps so generated.

Challenges overcome and lessons learned

In working on this system there were a number of challenges that needed to be overcome. In facing those challenges, IndyGIS and our partner Woolpert have learned some valuable lessons. The challenges faced can be broken down into three categories: technical, cartographic and project management.

The single largest technical challenge to overcome involved security issues revolving around the deployment of an application using ArcGIS Server. Since the ArcGIS Server software is deployed on one server and the web server and application are deployed on another, establishing the correct security context has proved to be difficult. Documentation regarding this issue has been difficult to locate with either ESRI or Microsoft sources. As of the time of the writing of this article (early June, 2005) a work-around is in place that entails impersonating the author's account within the application. This work-around is less than ideal and a more permanent solution to the issue is being sought.

An additional technical challenge also involves deploying the applications making up the system. Since the application makes use of ArcGIS Server but runs on a different machine than the server where ArcGIS Server is deployed, it was necessary to install the ArcGIS Server Runtime on the web server where the application was installed. This required installation of the Microsoft.NET SDK. The application also makes use of certain ArcObjects not deployed as part of ArcGIS Server, which entailed installation of ArcGIS Desktop on the web server as well. These issues were identified during the initial test deployment to a test environment, and while not major, they have made installation of the applications more complicated than desired. We believe that we will have found the means to reduce the footprint of the applications prior to final deployment into the production environment.

Cartographic challenges revolved around the need to make cartographic decisions in abstract, general terms. The cartographer on the IndyGIS team needed to choose layers, symbolization, labeling and annotation options and scale thresholds that would result in maps that would be clear and intuitive at any scale between 1:600 and 1:250,000. Additionally, it was decided to limit the contents of the legends of maps produced to the overlay or focus layer only. Thus symbolization and annotation for layers included in base layer sets needed to be self evident. Finally, the combination of base layer sets, overlay layers and area of interest layers would not be known until maps were produced. This meant that a great deal of time and thought needed to go into the cartographic choices made for all these layers to ensure that layers would work well together. Overcoming this challenge meant a lot of trial and error work in ArcMap, trying different permutations of choices until they were deemed acceptable. Use of the Catalog Interface extension to ArcMap helped in this process. This extension allows our cartographer to try various combinations of layers then publish the results so that those layer sets can not only be used by the map wizard application, but also by ArcMap users as well. This helps in standardizing the appearance of maps produced by Indianapolis/Marion County staff.

Project management challenges revolved around the scope of this project. While IndyGIS has undertaken projects that were larger and more expensive than this project, this project was the most complex undertaken to date. Seven out of ten IndyGIS staff were involved in one way or another with four Woolpert staff involved as well. Coordinating schedules and ensuring tasks were completed on time required constant monitoring. Including users in the project was also important as early feedback from users changed the direction of the project, improving it in the process.