Mapping Your Documents:

Issues Integrating GIS with Document Management

Abstract: The Division of Permits of the City of Indianapolis - Marion County, processes over 70,000 permits every year. Since 1995, this agency has made major investments in three major types of software in conjunction with a major business process reengineering effort. The Division has invested in their Building Permits Client-Server software, their City/County GIS System and in a Document management system for storing and retrieving records. Bringing these three systems together has required the resources of several different agencies and the complex integration of at least four software packages. This paper addresses some of the key technical and management issues involved in creating a workable, combined system.

The subject of this paper is a City of Indianapolis project that involved the integration of a GIS system with a document imaging system for building permit documents. The timeframe of this project spans almost the entire decade of the 1990s, from 1992 to present. There have been three stages of implementation: a planning stage (1992-1994), an initial implementation stage (1995-1997) and a secondary implementation stage (1998-2000). The final stage of the project is still in progress.

This project has already involved three agencies, four different Permits Division administrators, four project managers (one internal and three from outside firms), two different major systems integrators, six data processing service providers, two scanning vendors, and at least five different software manufacturers.

The financial scope of this project is large as well. Our contractual costs for document imaging from 1995-1997 amounted to about 1.1 million dollars. Our annual systems support costs since 1997 have been about $150,000 while our annual scanning expenditures have been from $150,000 to $200,000. The proposed costs of converting the data required for the systems integration effort has been estimated at $174,000.

In summary, this has been a significant project involving a large number of people and a significant investment by the City of Indianapolis.

Who We Are and What We Do

This project has involved three City divisions. The Division of Permits is a joint operation of the Department of Metropolitan Development (DMD) and the Department of Capital Asset Management (DCAM). The Current Planning Division is solely a division of DMD.

The Division of Permits’ work is regulating the development of land in Marion County. Permits Division processed over 70,000 permits last year (1999). These permits include structural and craft permits for construction, zoning review approvals, wrecking permits, permits for connecting to sanitary sewer locations and permits to dig in the street rights-of-way.

As a function of the permit issuance process, the Division of Permits reviews and approves land use, landscaping, sewer and drainage plans for new subdivision development. Since the early 1980’s, we have processed approximately 250 new subdivisions per year in Marion County.

In addition to permit issuance and development review, the Division is responsible for two other important development activities. First, the Division monitors permit and land use compliance. They perform over 50,000 inspections per year. Finally, the Permits Division issues and monitors builder and contractor licenses. The Division maintains active licenses for between 6000 and 7000 individuals as contractors or contractor representatives.

The Current Planning Division’s work is establishing and enforcing the rules for land development in Marion County. Current Planning staff process approximately 2,500 land use petitions each year. While some of these processes allow for administrative actions, most involve a public hearing process. There are separate petition processes for rezoning, variance approval, special exceptions, subdivision platting, and right-of-way vacations.

Our Documents

To support our land development regulatory activities, we process approximate 60,000 new documents per year containing some 225,000 pages. Many of these documents, such as permit applications, are generated internally. The public, however, generates our larger documents. These documents include building and site plans. These plans average about 11 pages per document and normally are drawn on C, D, or E - size drawings. To support the review process, we require applicants to submit three sets of plans. Because each set of plans may contain different sets of comments, we sometimes maintain all three sets.

Following Indiana state records guidelines, we retain paper documents for three years. Prior to 1995, we would microfilm the paper documents, store the images on either 16mm or 35mm microfilm, and then destroy the originals. Before destroying any copying and destroying any record, we are required to obtain the approval of our County Records Commission. Since 1995, we have secured approval from the County Records Commission and the Indian State Archivists office to replace our microfilm process with our document imaging process.

Why use a map to index your documents?

Before getting into detail discussing the development of the City’s GIS and Document Management systems and their integration, we must first address the question: Why? Why use a map or other geographic description to index a document?

The concept of creating a mapping index for documents came from observing Division of Permits’ staff practice. While records were kept in either case number order (petitions), address order (structural and craft) or project name (industrial cases), the primary index or finder systems to these records were sets of maps.

Figure A is an example of one of these map finders. In this case, the map was used to record the location of industrial projects in the city. The typical map finder was based on maps developed for the City by the Sanborn Map Company in 1954 and updated by the City's Planning drafting section through 1987. The Public Works department used a different set of base maps for their map indexes. Figure B is a photo showing a rack of DMD map indexes.

 

 

Figure A Figure B

 

Map indexes were not built for all records. Building and maintaining a map index was costly. The manual map index systems required frequent update. In some cases, the case or project location was recorded on as many as 4 different map indexes. Individual staff members kept their own records to indicate the location of the projects they handled.

The existence of a map index for a particular document set was related to the need for document retrieval. Map indexes were not built for records that were less important such as structural records or for the non-zoning, land use petition records. For these less important records, an address for each case or permit was used as the primary index.

As we explored the Division’s use of map indexes and their respective document sets, we discovered several reasons for automating the practice. From a practical perspective, location is often the most effective way of locating a document. Because development documents contain so much information, the geographic location is sometimes its simplest index. And, while the location might be the simplest index, the geographic location might be fairly difficult to describe. The more complex or difficult the geographic location, the more appropriate a map is for describing that location.

Often, permit review depends on one or more spatially dependent regulatory documents. Municipalities often have historic districts, well field protection areas, zoning restrictions and other regulatory regions that control the nature of activities in those areas. Legally approved documents describe the regulations and recommendations for those specific geographic areas. Some departmental documents such as plats and rezoning documents contain additional development requirements. A full spatial indexing of the appropriate regulatory and administrative documents is necessary to enable staff to make appropriate recommendations.

Map indexes are an effective way of establishing maintaining non-geographic associations between two documents or sets of documents. As new permit documents are submitted, a GIS system can allow staff to efficiently add non-geographic indexes, such as subdivision project numbers, to the new document. This is a tremendous aid to finding associated documents later. In a way, this is analogous to creating a file folder for a project. Complete spatial indexing of both the new permit document and the appropriate project documents gives staff a better chance of creating this association.

To summarize, the benefits of using a map-based or GIS interface to create a geographic index to a set of documents depend on the importance of a document set to the permitting process and the complexity of the geographic attributes of the permit activity and of the document set. The decision to create and maintain a map index should, therefore, but made based on the risks of not creating a given index; how often a mistake might be made without the index and the potential cost of that mistake.

Early Systems Development (Before 1992)

Permits Automation

The City of Indianapolis established its first automated permits systems in the late 1970’s. This system was an IBM showcase system and cost between 4 and 5 million dollars to develop. The County Information Services Agency developed the application using the COBAL programming language. This initial automated system helped manage structural and craft permits, permits inspections, and contractor licensing.

By 1991, it was apparent that the original Permits system had become obsolete. The system had not been expanded to accommodate other permits or even common permits review functions, such as the site zoning review required for each permit. Separate systems for that process and other permits, such as ROW excavation and sewer connection permits had sprung up. By 1992, there were at least 5 separate automated systems generating permits.

GIS

While the Permits Division was developing its automated tools, the development of another automated tool, GIS, was taking place along a parallel path. The GIS base map for Indianapolis/Marion County was developed as a part of the Indianapolis Mapping and Geographic Infrastructure System (IMAGIS). This photogrametric-based, vector GIS data set was initially delivered to the City in 1989.

The City’s use of GIS tools was prompted by a need to support better wastewater management. Those agencies responsible for storm water management, transportation, and long-range city planning also became quickly involved. The permitting and regulatory divisions were not initially involved. Over time, however, because of the scope of the City’s GIS system and the desire for the City to leverage its GIS expenditures, new systems initiatives began to be scrutinized to see if they would ‘fit" with our GIS systems. When the Permits Division began looking for a new automated system in 1992, GIS staff played a key role in the eventual selection of the software.

The DMD’s use of GIS began with zoning. Very gradually, the DMD GIS staff developed the ability to maintain the electronic base map. By 1992, Current Planning staff were relying on the GIS staff to run difficult petition legal descriptions and input subdivision boundaries. The pressing need to maintain the zoning base maps led to efforts in 1992 to update the 1987 zoning maps using a CAD system fed with data from the GIS system. Because of funding issues and some experimentation, this project would not be completed until 1995.

Imaging

During the mid-1980’s Permits’ management began to realize that much of the information not stored on that system was stored on different permit documents. Permits’ therefore began considering the use of the emerging document imaging technology with the hope of someday managing our paper documents in a digital environment.

The Permits Division actually had money budgeted for the development of document imaging as early as 1991. The Permits Division put off that investment in deference to an enterprise-wide document imaging coordination effort. Another agency, the County Recorder’s office was selected as the initial pilot in that effort and the Permits Division waited.

 

Management Initiatives 1992-1994

Business Process Reengineering (BPR)

While our new automated permits software was selected in November of 1992, the Permits Division did not actually begin using that software until March of 1996. During those four years, the Division underwent a full-scale reengineering process. The primary catalyst for applying BPR to our permitting process was a constant pressure to reduce staff that began with a hiring freeze in 1990 and culminated with a large-scale downsizing in 1992. Approximately 30% of staff positions in the Planning and Permitting Section were eliminated between 1992 and 1995. This steady attrition severely limited the ability of staff to perform many of their existing tasks.

As a part of the BPR process, the City held a three-week workshop involving all permitting staff in January of 1993. That workshop eventually resulted in the realignment of all permitting functions. During that workshop, both permits management and technical staff examined the information systems and information processes required for processing a permit. The consensus developed during that workshop formed the basis for the introduction of document imaging technology to the permits process, highlighted the need for systems integration, and provided a focus for that integration – customer service.

One addition result of the BPR process eventually had a significant effect on our document imaging process. Before the BRP process, we were handling nearly 500,000 document pages per year. During the January 1993 workshop, Permits staff identified numerous instances of form duplication and began a process to redesign all permit forms. The result was dramatic. As a result of this process, the number of document pages dropped by 50%, to about 250,000 per year. This drop made the costs of moving to document imaging much more feasible.

Outsourcing

There was another business trend influencing IT implementation at the City in 1994. In that year, the City administration announced its desire to outsource the provision of IT services. The services to be outsourced included mainframe, midrange and desktop computer support, network support and applications development. The administration’s position was that IT services were not a core function of local government. This administrative position had a significant impact on the City’s implementation of document imaging.

 

Building an Imaging System, 1994-1998

Beginnings

In the early 1990’s, the author was a GIS systems analyst for the DMD Long-range Planning Division and was a DMD representative to the 1991 enterprise-wide effort. Part of my responsibilities involved looking at zoning and other land use petition layers and potential applications for those layers. During 1994, an examination of potential zoning related applications revealed that much of the information require to make effective rezoning decisions was stored either on paper or on microfilm. Combining document imaging with GIS seemed to be a logical way of increasing user access to that information.

First, though, we had to build an imaging system.

What Kind of Imaging System?

A full examination of the appropriate steps required to design a document imaging system is beyond the scope of this paper. One of the most basic decisions that must be made, however, concerns whether one intends to use "live" or "retired" documents. A system that supports the development review activity by moving an active (or "live") document in a workflow requires a much more robust system than a system that houses an archive of historical ("retired") documents to be used for research.

One must be aware, however, that while the system demands of an archival and research system are less than that of a "live" document system, a research application may require far more records to be converted before becoming truly effective. This requirement has the effect of increasing both implementation time and cost. Because we already had serious systems support issues in the spring of 1994, we opted for a "retired" document or historical application.

Potential Benefits

The most precious commodity in the development community is time. Our retrieval time for historical documents on microfilm is anywhere from 30 minutes to 4 hours. If the document is checked out, the retrieval time may approach a week. For cost-benefit purposes, we used an average of 3 hours. We also estimated that we do about 7000 document searches per year.

We predicted savings of approximate one hour per search. This would amount to about 3.5 FTE of our organization’s time or about $105,000 per year (assuming an FTE worth $30,000). In a traditional cost-benefit analysis, that might be considered to be the total benefit. However, we felt that the customer’s time was more valuable than staff time and a legitimate benefit variable for a city agency. We calculated an expected benefit of $35.00 for every hour of customer time saved. At one hour of savings for 7000 searches, savings to our customers would amount to an additional $245,000.

In addition to time-based savings, we used two additional benefits to justify our document imaging efforts. The first concerned flexibility of document retrieval. We wished to be as flexible as possible for the delivery of public services but were constrained by our need to access our physical records collection. In addition, we estimated that eliminating the space required by physical document storage of our records would give us approximately 1000 square feet for servicing customer needs.

Finally, we were concerned about the preservation of some of our records. There was a perception that our records collections were in poor condition. Permission was granted in the fall of 1994 to evaluate the condition of the land use petition files with the aim of converting those documents to an accessible digital format. The collection proved to be in fairly good condition. Some items were in disrepair, but the record set was fairly complete. The collection of finders, or map indexes was functional as well. There were, however, numerous zoning map indexes that were in various stages of disrepair. The decision was made in late 1994 to proceed with an RFP for a system to convert these documents to an appropriate digital format.

Request for Proposals

An RFP was developed in the spring of 1995 and was somewhat unique in its approach. The RFP did not contain hardware and software recommendations. Our internal MIS agency had no expertise in document imaging and the attitude of the administration tended to discourage the creation of an entire new functional group of city employees. Instead, the RFP contained a request for a set of professional services that would constitute what would today be considered an Application Service Provider or ASP. The RFP contained a request for document scanning and indexing services and for the storage and provision of electronic access to those scanned documents.

We received three responses to our RFP. The winning RFP was a three-year proposal with the local systems integration group of a regional accounting firm. Under the original contract, which ran through December 1997, this firm was paid a monthly service fee together with a unit fee for scanning and indexing the documents. For the service fee, the firm purchased, set up, and administered the hardware and software necessary to provide document access to the City. The firm also hired that scanning firm and managed the scanning of City documents offsite.

Project Implementation

Our first crisis came shortly after the contract with our vendor was signed. The document imaging software did not have a way of creating a multi-key index. One of our primary indexes was property address, a significant multi-key index. Our vendor was able to create an Oracle-based, client server solution to this problem in less than thirty days.

Once this new system had been created, our vendor was ready to implement on site, but had to wait about twelve weeks for appropriate personal computers and monitors to be purchased, for new network lines to be established and for supporting index data to be assembled. In addition, the City had completed outsourcing their data processing operations on January 1, 1996 and was planning for the major permit system implementation on March 6, 1996. The imaging system had to wait.

Once the document management system went live on March 6th, 1996, conversion began. We converted about 3 years worth of building permit records in 1 year. In the late summer of 1996 we began converting zoning and other current planning documents, beginning with paper records from 1992 and microfilm records from 1985-1991. We did these back-file conversions of old documents at the same time as we processed new documents. As of March of 1997, there were approximately 3 million images representing approximately 200,000 documents.

We had our first major project glitch as a result of the scanning of the microfilm. The vendor scanned far more microfilm than we had asked them to. This resulted in both a budgetary problem and a processing problem. We eventually agreed to accept the scanned microfilm, but the slowness of the delivery and the difficulty of carrying out quality control on the processed documents delayed the acceptance of the scanned records until March of 1997. This delay in acceptance led, in turn, to a major payment problem that was not resolved until early 1998.

On Our Own

At the end of 1997, when the original contract ended, the City took possession of all software and hardware. This meant that the City also had to take responsibility for the administration of those systems. Our original vendor had found an excellent local vendor to replace the original scanning vendor and we continued our relationship with this new scanning vendor through a direct contract. It was not until the spring of 1998, however, that we were able to establish contracts for software maintenance and for document imaging systems administration.

We had intended to continue working with our original vendor for the ongoing systems administration and systems integration work on the system. Unfortunately, that vendor fell out of favor with the City administration, and we were not allowed to contract with them. We found some local assistance through our scanning vendor and continued to look for new solutions. We were ready for systems integration.

 

GIS and Document Imaging, 1998-2000

In the summer of 1998, the Permits Division received another push from the administration to reduce the number of paper documents used in permit review. Eventually this led to the involvement of our GIS vendor. Interestingly, our GIS vendor had been the consulting agency for our enterprise document management project in 1991.

The City made a major new investment in the document systems, both in terms of software and hardware, but also in terms of conversion. We upgraded all of our software and completed important systems administration agreements with our MIS firm. During the fall of 1998, we also converted all zoning and land use petition documents generated from 1993-1997.

Once again, we had a problem absorbing all of the converted data. The problem lay in our ability to provide an expedient quality acceptance program. This led to long delays in our acceptance of the scanned documents. This time, however, we avoided the financial problems that we had encountered in 1997.

Beginning in 1999, our GIS vendor began a project to fully integrate our GIS, Permits and Document management systems. Called the City of Indianapolis Integrated Information System or CIIPS, this new effort is based on four pieces of software; our permits software, our document management software, our GIS software, and a new software package that the author discovered at a conference in the summer of 1998. That software package provided the link between our GIS package and our document management software.

CIIPS is essentially complete as of this writing, although we are currently (June 2000) having difficulties with our document-imaging server. We believe that these problems will be solved by the middle of this summer and that the Permits and Current Planning divisions with have full access to the document-imaging portion of the software. A number of enhancements to the application are planned for either this fall or for the first quarter of 2001.

 

Summary

Our systems tests have indicated that we will achieve our initial expectations. In fact, with the additional GIS integration to the Building Permit systems that our GIS vendor has implemented, some of our searches are taking between three and six minutes. The system has an addition potential to save more money as it tightens up the variance in document retrieval time by removing search extremes due to lost or checked out documents. If we began saving an average of two hours per search, the system would have a full payback for our customers in a little more than four years ($1.96 million in benefits in four years versus approximately $2.0 million for total systems development and operations so far).

We have begun the process of making our system "live": creating a workflow of active documents. As a part of that effort, we have begun exploring the submission and management of digital development plans. We are examining the continually changing nature of documents. We already process 50% of our right-of-way permits using a web-interface to our permits system. Many of our existing tools will support this effort and we are cautiously optimistic about our ability to implement the concept.

We are also actively working at putting our documents in the field. That too, is an ambitious enterprise and will need to wait for us to improve our ability to provide just the right documents at just the right time for the right inspector. One way of describing this system might be "Just-in-Time Docs".

For now, we are busy finishing our integration efforts. Our data cleanup should be finished by late fall of 2000. Once we have cleaned up our data, we will be able to fully evaluate the impact of our combined systems on our customers. Because our current imaging file server will be obsolete at the end of 2000, we will have to purchase a new server. Purchasing a new service may trigger a new data conversion effort.

This project, despite many obstacles, is still alive. Even as project steps are completed, technology and business changes move rapidly. To deal successfully with rapid change requires the patient dedication of staff and management to customer service and the careful selection of good partners. To date, we have been fortunate enough to have all of these elements of success.

Acknowledgements

I would like to acknowledge the cooperation of Division of Permits staff, especially Rosalie Hinton and Rhonda Fields during the compilation of this paper. I’d also like to thank current project manager Kathleen Cain of the Convergent Group for her timely information.

 

Andrew D.Swenson
Principal Planner, Information Resources and Policy Analysis
City of Indianapolis, Division of Planning
200 East Washington Street, Suite 1841
Indianapolis, Indiana 46204
Phone: 317-327-5132
FAX: 317-327-5103
Email: aswenson@indygov.org/aswenson@iquest.net