Richard L. Petrecca, Jr.
The City of Indianapolis - Marion County has had web-based GIS applications on line since 1998. When ArcIMS was released the City County GIS division saw huge potential for web-based GIS technology. However, resources especially in terms of staffing, were very tight. This paper will explore the ways in which the GIS division is dealing with these issues in creating a set of solutions for its customers.
The City of Indianapolis and Marion County have been using AM/FM/GIS technology since 1986. In 1992, the City/County began using Esri’s ArcInfo. ArcView was added soon afterwards. In 1998, the City of Indianapolis and Marion County began deploying several GIS applications on the World Wide Web using MapObjects IMS. The initial Web GIS applications deployed by the City were not "typical" GIS applications, in that the applications were not map centered. GIS technology was used in the background of the applications to answer questions for users.
The City/County has made a large commitment to the use of GIS within the enterprise and currently have over 500 installations of ArcView 3.2 as well as 17 licenses for ArcGIS 8.2. The GIS division of the Marion County Information Services Agency (ISA) supports this user community with a staff of 10 employees. The staff is supplemented by 3 on-site employees of SchlumbergerSema, 2 temporary staff and 2-3 interns. SchlumbergerSema staff in their Denver office provides additional aid for development and project management. The City/County is a member of the Indianapolis Mapping and Geographic Infrastructure System (IMAGIS) consortium, whose 5 employees are responsible for annual updates to aerial photography and planimetric data. Collectively this group makes up the Indianapolis/Marion County GIS Team. General IT services are provided to the City/County by Affiliated Computer Services (ACS) under contract to ISA.
As can be imagined, support for such a large installed base can be expensive, both in terms of licensing and maintenance costs as well as staff time. One of the realities encountered in Indianapolis is the level of use of the ArcView licenses. The user base can be split into three approximately equal groups. One third of the users have ArcView installed on their PCs, but never use it. One third use it occasionally, but not enough to remember how to accomplish any but the most basic tasks. The final third use the product regularly. Each of these groups presents different challenges to the GIS Team in terms of support. In the case of the first group, staff wastes time and money installing a product that is never used. For the second group, considerable staff time is spent re-training users on relatively simple tasks. With the final group, the challenge is to keep data current and accurate as well as providing tools and techniques to make the users tasks easier and improve functionality.
In order to minimize future support costs, the GIS Team made a strategic decision in the fourth quarter of 2000 to deploy Web based GIS on a much larger scale than has been done previously. This decision was based in large measure on the opportunities provided by the ArcIMS product. It was decided that those users who regularly used ArcView would be migrated over time to the ArcGIS 8.x environment. Most would move to ArcView 8.x, but some, depending on their needs, would be moved to ArcEditor 8.x or ArcInfo 8.x. For the remaining two thirds, the GIS Team would provide Web based GIS tools that would allow them to accomplish their GIS related tasks.
Having made the decision to deploy ArcIMS, the GIS Team now had to decide how to deploy the technology. Previous applications development work had been split between SchlumbergerSema staff and GIS division staff with most desktop development being done by SchlumbergerSema and most web development being done by GIS division staff. After considering the fluid nature of Web needs, available resources and future directions for the GIS division, it was decided to keep the Web development in-house with some money being available for contracting additional resources. This posed a challenge of its own due to the small size of the GIS division staff. Three members of the GIS division were tasked as web based GIS development staff (ArcIMS Team), the author, who had done most of the previous web development, and two additional staff members with limited development experience.
Traditionally, GIS application development in Indianapolis had been done on an application by application basis with each application standing on its own. While this development methodology resulted in robust applications that met the needs of the users, it also resulted in a significant amount of overlap between applications and rewriting of similar code for different applications. Use of ArcView extensions reduced this redundancy somewhat, however no systematic architecture had been put into place for previous development. The ArcIMS team decided that embarking on the implementation of a new technology provided an opportunity to employ a more systematic approach to development.
In order to develop this systematic approach, the ArcIMS team conducted 20 separate interviews with over 50 representatives of 19 different agencies and divisions supported by the GIS Team. Through these interviews the ArcIMS team identified 22 different applications for Web based GIS. Using Unified Modeling Language (UML), the ArcIMS team broke those applications down into 52 different use cases. Use cases represent distinct interaction between the application and external actors such as users of the system. In breaking the applications down in to use cases, the ArcIMS team was able to see the overlapping needs. The use cases allowed the development team to identify specific components that could be developed separately and quickly combined to create new applications.
Once the use cases and applications had been identified, the use cases were tallied by application. The more applications a particular use case was part of, the higher its priority. Compiling the results of this analysis gave the ArcIMS Team a list of 10 core use cases that were part of nearly all applications. The applications themselves broke naturally into four development phases, the first phase using only core use cases and each successive phase using more use cases and less frequently repeated use cases.
In addition to developing component-based applications, the ArcIMS Team recognized that users and management desired results relatively quickly. This was due in part to the speed of evolution of all things web and part to the fact that needs change. As a result, the ArcIMS Team decided that an iterative approach to development would be better than a more traditional development approach. This approach combined well with the phased development envisioned as early iterations of some of the applications in the latter phases could be deployed once the components comprising them had been developed.
Once the ArcIMS Team decided on a development methodology, the ArcIMS Team turned its attention to the customization environment. Budgetary considerations dictated using a single Windows based server as both web-server and spatial server. Consultation with the Internet Division of ISA and ACS eliminated Cold Fusion as supported technology. While the author had VB development experience, the other team members did not, so the ArcIMS Team decided to base its development on customizations to the HTML viewer using JavaScript. In addition, the team recognized that some of the needs for internal use application would require functionality available only through a Java client of some sort. Thus, it was decided to partner with a contractor who had experience in Java development for those applications.
Once all the development decisions had been made a series of plans were written up communicating all the decisions to the users. These plans included: 1) a Hardware Architecture Plan, laying out the server and networking environment and the expected migration paths for the future, 2) a Software Architecture Plan, specifying the various software components and their configuration, 3) an Application Iteration Plan, documenting how the applications were identified, prioritized and scheduled. The development schedule envisioned in the original plan was very aggressive and assumed that all 22 applications identified in the original interviews would be completed by the end of July 2002.
Actual work on development of ArcIMS solutions began in May of 2001 after the server was installed, and a development methodology and customization platform was chosen. An initial deployment of the HTML viewer was made with a few customizations to frame locations with essentially out-of-the-box functionality. This General Viewer was to be the basis for future development efforts. The team quickly ran into what, in retrospect, should have been painfully obvious. Modifying the JavaScript shipped with the HTML viewer was not going to be simple. With nearly 200 different JavaScript functions in roughly 20 different files, the HTML viewer is quite a sophisticated application, written by someone else. An additional problem was following the flow necessitated by the Request/Response architecture of ArcIMS with the XML processing taking place on the client side. Each of the members of the ArcIMS Team was working on a different application, concentrating on particular use cases previously identified.
As the team began work on the applications, it became apparent that while the initial interviews were sufficient to broadly define an application need, they were not sufficient to actually start coding the applications. Thus, as work began on each of the applications, a group of users were assembled to advise the team on the requirements for the application. Additional meetings were conducted to define a common vision for each application and to define the requirements and design of the application. The result was a Design Requirements Document for each application detailing exactly what the application would do and how it would appear. These documents were signed off at the executive level by the sponsoring department or agency and the head of the ArcIMS Team. Formal requirements and design documentation had been standard practice for the GIS Team for the previous 5 years and has proven invaluable in meeting, as well as managing, users’ expectations.
By July, 2001 the ArcIMS team had deployed the initial General Viewer and work was completed on the first application, an Incident Viewer for local law enforcement agencies. The next two applications were finished in December 2001. Deployment of both applications was delayed due to delays on the part of the sponsoring agencies in compiling key data needed by the applications.
By December of 2001 it was clear that the original schedule was far too aggressive for the resources available. It was also apparent that continuing to develop based on the HTML viewer would not be in the best interest of the project. The decision was made to switch development efforts to use ASP and the ActiveX Connector. This decision was based on three factors: 1) the amount of time needed to download all the JavaScript was a concern to our users, 2) the amount of code required to do equivalent tasks was far less with the ActiveX connector, 3) writing new code put the ArcIMS Team in control of its own destiny. In making this change, the ArcIMS Team realized that it would cause delays while staff learned ASP development and the intricacies of the ActiveX Connector.
A revised application deployment plan was written taking into account what had been learned about the realities of developing and deploying ArcIMS applications. In addition, some applications were dropped from the schedule and others were added based on user input and new policy directions. The new schedule stretched out the development from a period of 13 months to 27 months. This schedule was seen as much more realistic by all involved.
In March, 2002 the ArcIMS team began working on defining requirements for a Java-based viewer for use on the City/County Intranet. SchlumbergerSema sub-contracted with The Schneider Corporation (Schneider), a local engineering, architecture and surveying company, to do this development work for the GIS Division. The ArcIMS team put together a representative group of users and defined the requirements for the application. Schneider will complete the development and the ArcIMS Team will perform the QA/QC.
As of mid-June, 2002 the team has completed and deployed four ArcIMS applications. One of the original applications developed by the team is still awaiting key data from the sponsoring agency. Two additional applications should be deployed in July of 2002. The project is currently slightly behind the revised schedule due to the departure of one of the team members.
Through the process of implementing ArcIMS, the Indianapolis ArcIMS Team has learned a number of lessons. Some of the lessons have been painful, some pleasant. Most of the lessons learned apply to any software development project, whereas some are more applicable to projects with small staffs.
Probably the single most important lesson to take away is to plan for the future carefully. Looking ahead is always a risky proposition; however, with a small staff it is imperative. You must know where you are going, where your customers are going and where your vendors are going. Overall, we have done well in planning this project. Even though we had to revise our schedule, we had anticipated doing so. Going into the project there were several known uncertainties. We anticipated difficulties and planned the approaches we would use to deal with them.
A lesson for those using ArcIMS is to take the time to decide what it is that you intend to do with ArcIMS. A lot can be accomplished with the out-of-the-box functionality. Before you decide to proceed with that or to do something different you need to look very carefully at the needs of your users. Do not let the fact that you can put up a site in 5 minutes persuade you that you should. Even if you stick with out-of-the-box functionality, it will still take a good bit of time to get your map services set up well.
Another lesson we learned was to pick our fights. A small staff cannot do everything for everyone, all at the same time. Take the time to decide what applications can be created given the staff and resources available. Look at the tools available to do the development and pick the appropriate ones for your needs. This means that you may not be making visible progress initially. Given that ArcIMS includes tools that make it easy to put a site up quickly, it can be frustrating.
Data work is necessary for a successful ArcIMS deployment. Large data sets will give you heartburn. They will also cause end users to abandon your applications. Take the time to massage your data. Drop fields that will not be used by your applications. Make sure you set thresholds appropriately. If possible, generalize your data for large-scale presentation. Consider SDE for storing your data.
While it is important to plan, it is equally important to be flexible, especially in a political environment. Policy changes at the executive level translate into project changes in the trenches. New applications may be identified and need to be included in the project. Sponsors of some of the applications can move on and as a result you may need to drop applications from the plan. In order to accomplish what we set out to do, we had to change from one development environment to another. We have also had to deal with losing 33% of our staff on the project. A project plan is a guide to get you where you are going, not a rigid set of rules set in stone.
If you have the opportunity to do so, pick your staff carefully. Do so after the development approach has been chosen and make sure the staff you choose have the necessary skills to complete the tasks. Understand the skill and learning styles of the staff you choose. If programming is needed, make sure that the staff you choose are skilled in the languages needed or talented enough to learn them quickly.
With a small project staff, it is important to delegate tasks that are time intensive but not skill intensive. For example, you could put together a user group and give them the task of defining standards for layer symbolization and thresholds. Or, you could have the sponsoring agency create the custom data sets on which their application depends. Delegating tasks in this manner effectively increases the size of the staff on the project and gives those to whom the tasks are delegated some ownership in the project.
If you have the opportunity to contract out some of the work, choose your contractors carefully. Vendors exist that run the whole gamut from hosting your site for you, through doing the development to go onto your web site, to providing staff to do the work at your location. Know what you need before you start the procurement process and make sure the vendor you select fits your needs.
The final lesson is that it is imperative to communicate. Be sure you know what your users’ requirements are. Be sure that they know what their requirements are. Communicate what will be delivered and when it will be delivered. Make sure your users know what responsibilities they have. Make sure you know if the users are meeting their responsibilities. The same goes for your vendors. If your project will be a long term one, make sure you give regular progress updates. This includes both updates on individual applications as well as the overall project. Delays are inevitable. When they occur, make sure you let everyone involved know what the delay is, why it occurred and what you are doing about it.
The City of Indianapolis and Marion County has had a long history of GIS usage and supports a large base of GIS users. The City/County has made a commitment to Web-based GIS but has minimal staff available for the implementation. In order to make best use of the resources available, the City/County has had to plan carefully while remaining ready to adapt to changing circumstances. The City/County has also partnered with users and contractors to leverage staff and accomplish more. While the implementation of Web-based GIS is ongoing in Indianapolis, the project is bearing fruit and more successes are anticipated.
Richard L. Petrecca, Jr.
Senior GIS Analyst
Information Services Agency
City of Indianapolis/Marion County