The Reality of a Pie-in-the-Sky ArcIMS Implementation

The City of Indianapolis/Marion County GIS embarked on an ambitious ArcIMS endeavor in 2001. During the implementation of the initial ArcIMS plan, many challenges arose that were unforeseen. These challenges and how the team overcame them changed the course of the implementation. This paper will focus on how the Indianapolis GIS team modified their implementation tactics to fit within the limitations of the project.

Background

Since May of 1999, the City of Indianapolis/Marion County GIS division has published several Internet mapping applications. The first few were completed using Esri’s MapObjects IMS (Internet Map Server). When Esri came out with ArcIMS, the City of Indianapolis/Marion County GIS Division researched the product and decided that ArcIMS would be a good software choice to meet the needs of the users in the City/County enterprise. After the decision was made to use ArcIMS, a plan was put together to implement the new software and develop applications. The goal of the City of Indianapolis/Marion County GIS was to develop a comprehensive web-mapping interface that would serve the needs of their users with the ability to expand down the road when necessary.

Interviews

The first step in the process was to conduct user interviews. A total of 20 interviews were conducted over a three-week period representing 19 different City/County agencies and departments within the enterprise. The interview notes were compiled and sent back to the interviewees for verification. As each application comes up for development the group is re-interviewed before the application is started. The re-interview is used to confirm that the original ideas are still wanted and provides a place to begin documentation.

Use Case Development

The ArcIMS team decided to use Unified Modeling Language (UML) to develop use cases from the interview notes. A Use Case represents an interaction between a software system and an actor (a user playing a particular role). The team believed that the use case approach would ease the modular development process if each application was broken down into functional processes.  From this process 52 different use cases were identified in 22 separate applications.  As expected, a pattern started to emerge with common overlapping components in the user’s desired applications.  The use case process had found the commonality between the users needs. Figure 1 below is an example of one application broken down into the Use Cases that comprise it.

Figure 1. Use Case Diagram

Prioritization

After determining all the use cases, each use case was assigned a number. The use cases were then tallied up throughout the various applications. As a means of prioritizing them, a use case was determined to be a higher priority the more times it appeared. The applications were then prioritized into a development order. The applications fell into four natural development stages. Coincidentally, the first set of applications to be developed also represented different user groups in the enterprise. This made the development schedule palatable to the diverse group of representative departments and agencies. A preliminary schedule for developing applications was set, however, the prioritization level of the applications was anticipated to change after the initial applications were developed.

Initial Plan

Phase 0

General Map Viewer

An initial General Map Viewer application was deployed immediately using out-of-the-box ArcIMS functionality. This out-of-the-box functionality includes the following: displaying a map; map navigation (panning and zooming); turning map layers on and off; turning a locator map on and off; setting an active layer; identifying features in an active layer; selecting features in an active layer; querying features by attribute in an active layer; buffering features in an active layer and geocoding (address locating).

Phase 1

Public Safety Incident Report Viewer

This application allows a user to view incident reports in the vicinity of a user entered location. It includes the ability to geocode a location, zoom to that location and then allow the user to identify incident report details by clicking on a point on the map. The user has map navigation capabilities and can turn a locator map on and off.

Zoning Information Browser

This application allows a user to view zoning information about a selected parcel. It includes the ability to geocode a location, zoom to that parcel and display the zoning associated with the parcel. Hyperlinks allow the user to view the on-line zoning ordinances and download on-line forms that can be faxed or mailed to the appropriate agency. The user has map navigation capabilities and can turn a locator map on and off.

Wellfield Locator

This application lets a user know if a particular property is wholly or partially within a wellhead protection area. It includes the ability to geocode a location, zoom in to that parcel and display whether or not it falls within a wellhead protection area. It also includes the ability to select permitted facilities within wellhead protection areas based on permit number and zoom to those facilities.

Parks Project Viewer

This application allows a user to determine what Parks’ projects are underway within a given geographic area. It includes the ability to specify an area by choosing a named area such as a park, township, or neighborhood or by defining the area on-screen.

Phase 2

Enhanced General Map Viewer

This application will include all the functionality of the General Map Viewer deployed in Phase 0. In addition, it will include the ability to generate custom map layouts in which the user will be able to specify paper size, orientation and text elements to be placed on the map. It will also include the ability to select different Map Services (sets of layers) to be displayed.

New Homeowner’s Application

This application shall display information about a given address similar to the subdivision checklist. It includes the ability to geocode a location and zoom to the parcel. It will then display varied tabular information of importance to a new homeowner.

Neighborhood Association Browser

This application will work with the existing neighborhood website to produce a map with neighborhood search criteria. It includes the ability to geocode a location or select by an attribute such as neighborhood organization name. It also includes the ability to download on-line forms that can be printed out and submitted to enter a neighborhood organization, business organization, crime watch area, or homeowners association in the database for notification purposes.

Phase 3

Park Locator

This application will find parks within a specified radius from a given address. The user will be able to specify search criteria such as amenities/programs available. It will then display additional information available such as hours, manager, park name, and address of the park. It shall also include the ability to print custom maps as described in the Enhanced General Map Viewer above.

Park Viewer

This application will be a variation on the Enhanced General Map Viewer optimized for Parks. In addition to the features of the Enhanced General Map Viewer, it shall include links to Internet cameras located in the parks and on the Greenways and the ability to submit an on-line work request form.

Planning Data Viewer

This application will allow a user to select via query and display sub-area plans based on geocoding a location or selecting by a neighborhood name.

Township Administrator’s Viewer

This application will add point-in-polygon analysis (i.e. what council district, school district, etc. am I in?) and find-within-radius analysis (i.e. what streets are closed within ½ mile of my house.) to the general viewer.

Air Quality Application

This application will allow a user to type in an address and find the permitted source locations within a specified radius, then show the emissions data associated with each source in a tabular form. It will also allow the user to select an air quality monitor and display the data gathered by that monitor.

Liquor License Notification Application

This application will generate a notification list for liquor license applications based on an input address.

DPW Engineering Design Viewer

This application will display traffic count, accident, and other traffic related information. It includes capabilities to summarize accident and census data in user-defined and pre-defined areas. It also includes links to Internet attached traffic cameras.

DPW Street Maintenance Viewer

This application will link GIS layers with the Pavement Management database. An internal version will link to the property system to allow generation of notification lists for street and sewer projects.

Phase 4

Water Monitoring Application

This application will display user selected pollutant parameters for a user selected monitoring site near their home or work. The pollutant information will be summarized for a user-defined date range. It will also include the ability to add custom cartography and annotation to the map display.

Route Mapper Application

This application will allow a user to generate a route and/or directions for getting from one location to another within Marion County. The user will be able to select the transportation mode as well as other routing parameters.

Demographic Data Viewer

This application will allow the user to summarize and display demographic data for user specified polygons.

IndyGo Maps & Trip Planner

This application will display IndyGo bus routes and allow a user to plan a trip from one location to another within the IndyGo service area. In addition to the routing functions from the Route Mapper application, this application will allow the user to constrain the arrival or departure times.

Polling Place Locator Enhancements

This application will allow the user to determine where they go to vote. It will also determine whether the user is registered to vote at their current address. It will generate a list of candidates for the user’s polling place. Using the routing functions from the Route Mapper application, it will provide a route map and/or directions to get to the polling place from the user’s home. It will also generate a list of polling places for a given district.

Mayor’s Office Communicator

This application will consist of internal and external versions. With the internal portion the user will geographically associate digital correspondence to the appropriate areas where they apply across Marion County. The external portion will display the digital correspondence based on a geocoded location or neighborhood name.

Mayor’s Action Center (MAC) On-line Request Submittal

This application will allow a user to submit a service request on-line to the MAC database, validating the location of the address.

Challenges

The ArcIMS team experienced a number of stumbling blocks in the scheduled application development process that led to delays in production.  Several factors contributed to these delays. One factor was the learning curve of the ArcIMS team. The first four applications were developed by modifying or creating new JavaScript in the HTML viewer. Prior to beginning the development, no member of the team had JavaScript experience. Through a training class and the practice of developing code, the team members were able to acquire JavaScript experience. Theoretically, application development from this point forward should be quicker.

About the time the team was feeling comfortable with JavaScript, a decision was made to migrate to ASP and the Active X connector to customize the applications. The reason for the switch stemmed from a common complaint about some of the applications. The complaint was that the applications took a long time to download initially over a dial-up connection. In order to solve this problem, and make the users happy with their applications, the decision was made to make the architecture switch. Using ASP and the Active X connector would eliminate the long load time of the application, since there would not be a large amount of JavaScript for the client to download. Once again, the team did not have much experience using these tools and, therefore, another learning curve was experienced in the second round of applications.

Other factors that contributed to slower development than anticipated involved the departments. A lack of departmental cooperation along with some departmental data issues contributed to some delay in development. In one instance an application was completed for months before the final approval signature was given to put the application on the Internet. In the case of another application, one department, although enthusiastic about the potential of this application, failed to provide the necessary data to run the application. The department had a lack of resources and switched priorities during development of the application. However, an assumption had been made at the beginning of the development process that the department would be responsible for supplying the data. Although this application is complete, the data is still not ready and therefore the application cannot be deployed.

Another factor in the slow development process was that the initial schedule was relatively aggressive for the resources available. The team members knew the schedule was aggressive in the beginning, but did not have a benchmark to determine if the schedule was realistic or not. In the revised schedule the team recognized the need for additional resources. The team looked at contracting the work that they are unable to do. For instance, no member on the team has experience with Java programming, therefore, the City/County has hired a contractor to do work on the internal Java browser. Another area the team is lacking in expertise is in graphic design. This work has also been contracted. Realizing the lack of expertise in certain areas and the need to acquire additional resources to complete some of the projects, the team has planned and incorporated this in the new revised schedule.

The recent loss of a team member has also contributed to slower development time.  The work that had originally been divided amongst three people has now been divided amongst the two remaining team members.  Naturally, this has slowed development.  Upon the team member's departure, a few of the projects were left uncompleted.  One of the remaining team members took over these projects, but had to spend time finding out what had already been completed and where work was still needed.    

Another factor that contributed to the slower development was the amount of time spent on documentation. The ArcIMS team felt that documentation was a necessary part of the development process and the time spent developing it was time well spent. The documents produced eliminated miscommunication between the users and team members. Everything that was to be built for the user was based upon the interviews and then compiled into functional requirements and design requirements. Both of these were presented to the user for sign off before the coding began. At the end of the documentation process, there should be no question on the user’s part as to what they are going to receive in their application. Once those documents were completed, the team began a detail design document that explains all the logic in the coding. Although this took time in the beginning, the team felt this was a beneficial step and down the road would be useful if modification became necessary. Although the documentation was a useful and necessary process, the time to compile the documentation was not figured into the initial schedule. After six months of development the team could easily see their goal was not going to be reached. At this time a revised deployment plan and schedule was prepared and presented.

Revised Plan

Since the initial interviews, some of the applications have either changed scope or been incorporated into others.   New applications have also been identified.  The applications that have recently been completed or are near completion are the Zoning Information Browser, the Registered Community Organization Browser (Neighborhood Association Browser in initial plan), and the Polling Place Locator Upgrade (Polling Place Locator Enhancements in initial plan).  These applications are essentially the same as described in the initial plan document with the exception of the Zoning Information Browser, which has incorporated most of the New Homeowners Application.

In addition to these applications, three enhancements to the General Data Viewer were quickly completed. These include a Custom print function, the ability to switch between different map services, and a reuse address function.

In addition to the applications already completed, development of these three applications and two enhancements will be complete phases 0, 1 and 2 of the initial deployment plan.

Additional enhancements to the general viewer to be completed this year include point-in-polygon and find-within-radius analysis capabilities (previously identified as the Township Administrator’s Viewer).

The Parks Viewer and Park Locator applications described in the initial deployment plan overlap each other to a large degree. The ArcIMS team felt it best to combine these two applications into one.

In addition to folding the New Homeowners application into the Zoning Information Browser and dropping it, two other applications dropped off the application list. These applications include the Mayor’s Office Communicator and the MAC On-line Request Submittal. The former was dropped as the sponsor of the application has left City government and the need for the application is no longer perceived to exist. The latter was dropped since it requires integration of the MAC’s operations with the operations of other City and County departments and agencies.

The remaining applications identified in the initial Application Iteration Plan are still in line for development. The order of application development now takes into account availability of resources and should be a better approximation of when the applications will actually be developed.

New Applications/Enhancements

Seven new applications and enhancements have been identified and added to the deployment plan. They are:

Address Reuse

This enhancement to all the ArcIMS applications that do geocoding will add the ability to store and reuse an address from application to application. It will store the address, intersection or parcel number entered by the user in a cookie in the users’ Web browser. If the user switches to a different Indianapolis’ ArcIMS application during their current browser session and initiates a geocoding function, the application will read the address from the cookie and fill in the geocoding form with the stored information.  As described above, this has been completed.

Enhanced Site Appearance

This enhancement to the General Viewer includes changes to the application layout, tools and overall graphic appearance of the General Viewer. These changes will be designed to make the site easier to use and more distinctive. Design changes resulting from this effort will be carried through other applications when appropriate so that all the Indianapolis ArcIMS sites will be consistent in appearance.

Migrate to ASP

This enhancement to the General Viewer is a re-write changing the application from an HTML/JavaScript based application to an application based on ASP. This should result in an application that has a smaller footprint and loads quicker into a web browser, especially over a slow dial-up connection. There are no changes in functionality anticipated as part of this enhancement.

Java Intranet Browser

This new application is designed to act as a replacement for the ArcView Data Viewer for casual users. Functionality will include:

• The ability to switch between multiple map services.

• Single-click operation to set a layer visible or invisible.

• Fallback geocoding (geocoding first against parcels, then against centerlines.)

• Custom layout creation.

• The ability to add local data as well as data from the Geography Network into the browser.

• Map navigation (pan, zoom in, zoom out, zoom to full extent, zoom to active layer, zoom to previous extent [with 5 levels available]).

• Identification of features.

• Labeling of features

• Selection and clearing of selections.

• Measurement capabilities.

Inter-application Links and Site Integration

This enhancement to all the applications shall provide the ability to jump directly from one ArcIMS application to another without needing to go back to the GIS home page. The intent is to make the site more unified. If an application is map-centric, jumping to another map-centric application will display the new application zoomed in to the same extent as the original application.

Economic Development Application(s)

This application, or applications, will be designed to support economic development activities and opportunities in the Indianapolis area.

Barrett Law Project Viewer

This application shall allow a user to input their address and see if they live in an approved and funded Barrett Law project area.

The tables below give a summary of the current progress on the initial applications and the inclusion of the new applications with the revised schedule.

Table 1 – Status of initial applications as of June 2002

Table 2 – 2002-3 ArcIMS deployment schedule.

Conclusion

The process of implementing an enterprise wide ArcIMS web mapping interface proved to be a challenging project. Several months into the project, the ArcIMS team members recognized the need to modify the existing pie-in-the-sky implementation plan to a more realistic plan.

Several lessons were learned throughout the implementation process. The first lesson being that ArcIMS is more difficult to customize than was anticipated, despite the fact that it is an easy tool to use out-of-the-box. A fair amount of time was spent reading through the existing code and deciphering it, before any progress could be made on modifying the application. In addition, because so much of the code is reused, modifying one function often had unexpected adverse effects in another function.

The second lesson is there is no substitute for experience. As the team became more familiar with JavaScript the coding was completed faster, but the time spent in the beginning learning the JavaScript certainly could have been avoided if the experience was already in place. In this situation these were the limitations of the staff members. From this lesson the team has contracted help in the areas in which expertise is lacking.

Lesson number three is to allot sufficient time to document requirements and design. The initial plan did not account for the documentation process, but the team found this was time very well spent and is a critical component of the development process.

Lesson number four is very simple. Murphy rules: Plan for the inevitable problems. In the case of the ArcIMS project this happened with changes in the client’s priorities.

Not all lessons learned in this project were negative. The team decided that the Use Case approach worked well for this project. The newer methodology was beneficial to the development process.

Another positive lesson was the flexibility that the team acquired in dealing with the different organizational personalities among the clientele. Some of the clients were more technologically savvy than others. These clients tended to have more input into the design process.

The ArcIMS project is a continual learning process. The team knew in the beginning that the schedule would change. After six months of development a revision was done and the team will continue to review and revise the plan as necessary. Together, with all lessons learned, the team hopes to move forward in a productive manner on a realistic schedule.