Enterprise GIS Integration in Indianapolis
Skip Ribbon Commands
Skip to main content
Enterprise GIS Integration in Indianapolis
Richard L. Petrecca, Jr., Project Manager, Indianapolis - Marion County ISA
Joe LaCombe, GIS Programmer, Woolpert, Inc.


This presentation focuses on the GIS development that has taken place over the last three years in the City of Indianapolis and it's evolution into an integrated, enterprise GIS. During this time, numerous applications have been developed using ESRI's server-based software. These applications address problems and processes occurring on a daily basis as well as ways to make those processes more efficient. While developing these applications, IndyGIS has strived to develop functional, efficient and cutting-edge applications using the latest technology available, such as ArcGIS Server and Microsoft .Net. This technology was used to develop GIS applications and functionality that communicate with existing systems within the City environment thereby creating a fully integrated enterprise GIS. As a result, this integration has provided the power of GIS both knowingly and unknowingly to the users citywide. This presentation will discuss the following topics:

  • Integrated components of the enterprise GIS and how they work together
  • Technology that was used
  • How the enterprise GIS affects all City staff
  • Hurdles involved in implementation
  • Future evolution of the enterprise GIS


GIS in Indianapolis began with the IMAGIS consortium formed in 1986 to share the cost of creating and maintaining a digital base map. The consortium was made up of three City Departments and several utilities. While the cost of creating and maintaining the base map layers were shared, the day to day mapping operations were done on a departmental basis. This departmental GIS was loosely coordinated through the IMAGIS consortium and within City/County government by relationships between the GIS technicians. By the mid-1990s the City had formed a cross-department GIS Team eventually co-locating all team members together. In 2000 the GIS Team members were all transferred into the Information Services Agency as the GIS Division of ISA.

As these organizational changes were taking place leading us towards an enterprise view of GIS, technological changes were taking place enabling an enterprise implementation of GIS. The original repository of the IMAGIS data was Synercom. City members used that platform for their operations while other members used AutoCad, Microstation or other tools. In 1991 the City GIS Team decided to add ESRI's ArcInfo to our toolbox. Consolidation of multiple Local Area Networks running various network operating systems to a standard Novell NOS as well as the introduction of ArcView allowed the City to deploy 500+ copies of ArcView accessing centrally maintained shape file data from a single network share utilizing a common user interface by 1998. In 1999 the City deployed ArcSDE and ArcIMS, two of ESRI's server technologies designed for centralized data management and web-based mapping respectively. Working with the Convergent Group (later SchlumbergerSema) the City of Indianapolis Integrated Permitting System (CIIPS) was deployed in 2000. This integration of ArcView, Tidemark's Permit Plan and FileNet document management system was the City's first major GIS integration project. CIIPS made use of a first generation implementation of the Master Address Database or MAD which has since been expanded upon as the basis for further integration with other systems. This expansion was begun in 2003 with Woolpert creating tools for maintaining the MAD as well as creating a SOAP compliant web service for validating addresses. This Address Validation Web Service was the first of several web services created using ESRI's ArcGIS Server product.

As projects ensued, ArcGIS Server and server-based technology such as the SDE Java API has allowed the City and Woolpert to continue the development of web services and server-based solutions for automated data analysis and creation. Woolpert and the City of Indianapolis have worked as a team to integrate these solutions, web services, and database systems using the latest technology available to develop a true enterprise-wide GIS.

Siebel Integration example

The Challenge

An example that illustrates the magnitude and relational nature of this integration centers on the city's implementation of Siebel's Customer Relationship Management (CRM) system. As a citizen calls into the Mayors Action Center for a particular request, a CSR fields that call, logs necessary information and generates a service request. Previously, any integration between Siebel, GIS and other systems was performed manually and in many cases through duplicate data entry. Data retrieval regarding a particular service request location was extremely inefficient and time consuming which inevitably led to delayed responses to service requests. Due to the geographic nature of service request locations, a quickly evolving GIS and advances in technology, the City determined that integration between the various systems could be achieved through the development of automated web-based and server-based applications. As a result, a series of web services, server solutions and web applications have been developed over the last three years that work together to provide an effective integration.

The Solution

To perform the integration and achieve the desired results, a diverse group of applications needed to be developed. These applications each perform a unique piece of functionality, however, the work together to create a highly integrated and efficient solution.

Address Validation (AVWS)

The AVWS was developed as a SOAP compliant Web Service that will allow a calling application to submit an address to be verified against the Indianapolis/Marion County Centerline geodatabase and Master Address Database. The web service accepts as inputs a properly formatted address string. Optional inputs include a string to indicate the desired validation level - unit (future implementation when data has been developed), building, parcel, or street (default), a boolean to indicate if possible matches should be returned (Validation with Candidates) and a lower limit for the match scores of returned possible matches. If the address submitted is valid to the level specified by the user, the web service returns the standardized, validated address as a concatenated string as well as a parsed set of fields and the match score in the form of an XML document. If not, the web service returns a list of possible matching addresses (concatenated and parsed) along with their match scores or a designated response if possible matches were not requested.

Point-in-Point Analysis (PIP)

The PIP web service was developed as a SOAP compliant web service. This web service allows a calling application to submit a pre-verified address and a valid XML request document and perform an offset geocoding procedure against the Indianapolis/Marion County Centerline geodatabase to obtain a point location using an ArcGIS Server Geocode Server. The application also allows the user to specify the X and Y coordinates and a projection and then creates a point object from this information.

Once the point feature is obtained, the application accesses an ArcGIS Server Map Server object, which uses the point to intersect against the collection of specified layers in the XML request. The web service returns the submitted XML request with values appended, as XML elements, for all requested fields grouped by layer name.


The 311PointLocator application employs ASP.Net and ESRI ArcIMS services to process, generate and return image maps corresponding to service call points within the Siebel framework. The application is passed in an address plus an ID and call type of a customer service request and it returns a map of the service request and its surroundings.

Siebel Automated Geography

Application SAGA is a server-based application developed as a Java-stored procedure and executed via a set of triggers within a Siebel database. The java application is stored within an Oracle database schema on the City's enterprise SDE server. Upon creation of a service request, the SAGA application triggers a link to the SDE server and executes the Java procedure that creates geographic data based upon the service-request information gathered from the Siebel database. For service requests updated within Siebel, an update trigger is executed that queries the matching GIS feature within a "Request for Service" layer and updates the necessary attributes.

Automated Mapping Engine

This application allows users to create maps and reports based upon spatial data using a Map Wizard and Reporting Wizard. The Map Creation Wizard is a web-based, database driven application that guides the user through a systematic process of creating a map. Initially, the user chooses the desired map layout from a list of templates and specifies the map dimensions. This process then allows the user to select from a set of pre-defined base layer sets, and choose from a list of overlay layers available for the chosen base layer set. The user specifies date range and attribute query criteria for the chosen overlay layer, selects a geographic area of interest, or extent for the map, and provides title and author information for the map. The application then takes the specified parameters and uses them to create a high cartographic quality map using ArcGIS Server. The application accesses the ArcGIS Server object corresponding to the chosen map layout. The application then retrieves the necessary layers, loads them into the map document through ArcGIS Server, performs the attribute and spatial queries for the given date range and zooms to the chosen extent. Once the desired information has been defined, the application creates a PDF version of the map layout and displays to the user. Similar in functionality to the Map Wizard, the Report Wizard is a web-based application that allows a user to step through and create a report displaying data obtained from a spatial query, using ArcGIS Server functionality. The end result is a PDF version of the report. Once users have saved particular map and report definitions within the database, the application allows users to subscribe to those maps and reports. Users have the ability to subscribe to multiple maps and reports. Upon selecting a map/report to subscribe to, users are able to define the frequency at which they would like to receive the report and the length of their subscription. Developed as a windows service, this component executes a regular intervals and retrieves all subscriptions from the database that are due to be submitted on that date. Based upon the parameters specified by the user and retrieved from the database, the application will calculate access the related ArcGIS Server object, load all layer information, perform the necessary date range, attribute, and spatial queries as defined in the database and generates the map/report using ArcGIS Server functionality. Once the map or report has been created, the application then automatically emails the resulting PDF to the user.

How it all works together

As citizens call in requests to the Mayor's Action Center, dispatchers enter the address into the Siebel CRM application.

  1. The Address Validation web service is called and is passed the address string and level of desired validation. The AVWS then validates this address against the centerline geodatabase and the Master Address database and returns the standardized, validated address string.

  2. Once the address is validated, the CRM application calls the Point-in-Polygon web service to perform the spatial selection of data and return attributes for display in the CRM interface.

  3. Once the information for the service request has been entered the user can click on a Map tab in the Siebel interface and view the map created by the 311PointLocator.

  4. As the information is saved and a new service request is created within the Siebel system, a trigger is executed calling the SAGA application. The SAGA application is passed a series of attributes, including an address. The SAGA application geocodes this address and creates a new point feature at the geocoded address within the Request for Service layer in SDE. Necessary attributes are then assigned to the new feature. This layer is continually updated as new services requests are created resulting in near real-time mapping of service requests.

  5. As the Request for Service layer is continually updated with service request data, the Automated Mapping Engine provides the ability to provide up-to-date, high cartographic quality maps displaying the service request information. This application is design for the non-GIS user in mind, and is intended to provide the full power of desktop mapping in an easy-to-use, web-based environment. For example, a City Councilman may request a map of all service requests in their district for the last week. Rather than going to GIS staff, requesting the map, and then having to wait a couple days for it, the councilman can then access this application and let it guide them through creating the desired map. The councilman will then choose to map service requests, select a date range of "previous week", then select their council district. The Automated Mapping Engine will then load the layers into the map, select all service request features from the Request for Service layer that were created in the week previous to the current date. From that selection, the application will spatially select those features that are within the chosen council district.

    The map is then exported as a PDF. The councilman can then choose to save the map definition into a database so that they can generate the same map at a later time. Also, the councilman can choose to subscribe to this map on a regular basis, i.e. weekly, and have that map automatically generated and emailed to them.

The above process identifies how a series of server-based applications using various technologies, software environments, and functionalities can be designed and developed to work together and create a true enterprise system.

Other examples

In addition to the Siebel integration, the City of Indianapolis has integrated GIS into several other workflows. The CIIPS project, mentioned earlier, integrates ArcView 3 with Tidemark Permit Plan and FileNet document imaging software as well as a MS Visual Basic application called Table Editor to provide a comprehensive permitting application. Permit techs can jump from within Tidemark to ArcView to determine if the location being permitted is located within any restricted districts. From ArcView, they can jump to the FileNet system to find any scanned documents relating to the parcel for which a permit is being sought.

The CIIPS system includes a core linkage to our Master Address Database. The MAD is one of the foundation stones of our enterprise GIS architecture and vision. It is built upon the principle of having a single, centrally maintained, authoritative source for address data in Marion County. It currently provides addressing information for our permitting system as well as for our CMMS systems used by the Departments of Public Works and Parks and Recreation. As was mentioned in the discussion of the Siebel integration, the MAD is used for validating addresses in other systems including a new system that Probation is using to track probationers.

The Tidemark Automated Geography Generator (TAGG) is a server-to-server integration between the Tidemark permitting database and our SDE database. TAGG is designed to automatically create features in two geographic layers whenever new cases are entered into the permitting system. This happens completely behind the scenes with no user intervention whatsoever. The results are two layers updated in near real time with the locations of all permit cases and all building permits applied for.

The Department of Public Works contracted with AMEC for the creation of a Capital Improvements Program (CIP) application that ties together an Oracle database of CIP information with a CIP project layer and a web-based application that allows users to see both where projects are located as well as all the details regarding the projects.

Architecture & Technology

To perform the desired integration and achieve maximum benefit across multiple disciplines and applications, a diverse and advanced development approach needed to be used. This approach combined the use of the latest standards and processes in application development and design with the latest technology provided by Microsoft, Oracle and ESRI to create a highly integrated and advanced system.

Web Services

The City and Woolpert worked to utilize a "modular" Server Oriented Architecture (SOA) approach for development of these web services. The goal of this approach is to improve service delivery to internal GIS customers and be more responsive to the public while targeting getter using GIS resources and minimizing redundant code. Using Microsoft .Net as the development platform and XML as a means to communicate, these web services were developed with the intent to perform a specific piece of functionality and return a standard response. As a result, these web services can be called by numerous applications that need spatially queried or validated information for use in their respective application environment, without the need to customize each calling application. Therefore, a single application and common code-base performs the specific functionality and removes the need to build redundant code into multiple applications.


Within the above mentioned examples, as many as five separate databases residing on three separate servers were accessed. These include:

Siebel Server

Siebel – Oracle 9i database for the Siebel CRM application. The SAGA application is triggered from within this database.

Tidemark Server

Tidemark – Oracle 9i database for the Tidemark permitting system. The TAGG application is triggered from within this database.

Enterprise Server

Master Address – Oracle 9i database containing the addressing data utilized by the Address Validation Web Service

Catalog Interface – Oracle 10g containing symbolized and customized GIS layer files, stored as a "blob" data type.

SDE Geodatabase – Oracle 10g and ArcSDE 9.0.

Map Engine – Oracle 10g database containing configuration and map generation criteria for the Automated Mapping Engine.

In order to effectively communicate with each as well as between databases, a network of Oracle packages containing numerous PL/SQL stored procedures was developed. To communicate between databases residing on separate server, database links were created to perform this communication and database triggers were developed to initiate the communication. Because of the modular nature and standardized approach of oracle PL/SQL, these procedures can be called from various applications thereby using a common code-base. In addition, a common .Net library was developed allowing development staff to easily connect to and execute database procedures without the need to re-write the same code.

For the SAGA and TAGG applications, Java stored procedures were developed to perform GIS functionality against SDE using ESRI's Java API. These Java procedures can be stored and executed within an Oracle database; therefore these applications are contained within Oracle 10g on the SDE Geodatabase server. This solution allows advanced GIS functionality to be performed wholly within the database environment.


To provide even more integration and commonality, Microsoft's .Net platform was used to develop all of the web-based and desktop GIS applications. Specifically, the web service and automated mapping engine applications were developed using ASP.NET To program against the GIS using ESRI's ArcObjects Desktop and Server application programming interface (API). By having the ability to interface with the GIS and other systems through additional API's, .Net provides a common ground for integration. As a result, this technology has enabled the deployment of service oriented applications.


In some cases, such as the SAGA example stated above, it was necessary to employ the use of Java as a programming environment when performing some of the GIS functionality. This is made possible by ESRI's SDE Java API and the ability for Oracle to store and execute Java procedures. As a result, the City and Woolpert determined that this was the best technology to utilize for developing the automated geography generation applications.

ArcGIS Server

It is through the use of ArcGIS Server and its Application Development Framework (ADF), that this integration was made possible. ArcGIS Server allows us to develop web-based applications that utilize ArcObjects to perform advanced, fine-grained GIS functionality. Essentially, ArcGIS Server accesses a defined map document (MXD) or address locator as Map Server objects and Geocode Server Objects, respectively. Through this technology, ESRI has enabled the ability to work against Map Server and Geocode Server objects using ArcObjects. Therefore, this has provided us the ability to develop applications that work with the GIS with other systems through a common code-base.

A collection of geocode server objects were generated for access by the web services enabling them to perform geocoding and spatial selection functionality. These server objects are pooled server objects, meaning they are "waiting" on the server to be used. This allows for faster initialization and processing performance.

For the Automated Mapping Engine, a separate setup was necessary. Because each user creates a unique map, the "state" of the server object is changed. If using pooled server objects, this can cause synchronization and conflicting issues with the server objects in the pool and other user using the server objects. As a result, a set of non-pooled server objects were created for each map template. As a use accesses the server object, a separate and unique state of that object is created in memory pertaining to that user. This allows a user to change the state of the object without affecting other users. However, this approach can lead to slower initialization and processing performance.

Effects of integration

The effects of integration have been many and varied. For the most part the effects have been positive, but there are some drawbacks as well. On the positive side the biggest effect has been increased productivity. As an example, in the Siebel integration one of the pieces of the puzzle was including the Point in Polygon web service with the CRM application. Prior to this when a citizen would call in to ask when their trash pickup day was, the CSR would have to take all the information from the citizen to record the call, then re-enter the citizen's address in a separate application to determine what the day of pickup was. Now the CSR takes the information and simply clicks a different tab on the interface to see the results of the point-in-polygon query displayed. The TAGG and SAGA applications eliminate the need for users to independently geocode thousands of records from the CRM or permit databases in order to see where activity is taking place around the county. The Map Wizard allows end users to create very high quality maps with little effort or training and the addition of the map subscription service will automate that process even more.

In addition to increasing our productivity, integration of GIS into the enterprise has led to increased accuracy of our data, both geographic and tabular. When a call is received in the MAC we validate the address as part of the process ensuring that if a service crew is dispatched, they can find the location of the problem and fix it. By making sure that the permitting system can only use addresses that are in our MAD, we can ensure that the permit techs have accurate location information on which to base their decisions.

These increases in productivity and data accuracy lead in turn to better customer service for both our internal and external customers. Government runs on data and most of that data has a location component. By ensuring that our internal customers have accurate information that is tied to their work processes, they are able to make decisions quicker and deliver services more effectively to citizens. In turn, by automating many of the routine functions and enabling end users to do for themselves, it allows the GIS Division to focus on higher value analysis functions rather than routine data maintenance and map making.

All these gains do not come without a price. As more systems are integrated the overall system becomes more complex. This increased complexity in turn leads to increased fragility of the overall system. Currently most of the City GIS integrations are dependent on data stored in a single SDE database. If that database is unavailable either because it is down or because of a network problem, then several systems are disabled. This fact has increased the need for GIS systems to be treated like the enterprise systems that they are and has hastened the absorption of the GIS professionals working for the City/County into the formal IT organization.

Future direction

So what is the future direction for the City/County? Five main trends will continue as we move forward:

  1. Continued integration of enterprise applications We and our users continue to come up with areas where integration of GIS with other applications and systems make sense. We have worked with PBS Solutions who are creating a new application for Probation that will use our address validation web service and our point-in-polygon service to determine if probationers are supplying valid addresses and if so, to what probation officer should they be assigned. In the future they wish to use a Find within Radius service we are developing to determine if certain offenders are living too close to a park or school. We are working with the Division of Compliance of the Department of Metropolitan Development on a means of automatically assigning a zoning inspector to new zoning investigation cases created in Tidemark. This work will call the point in polygon web service from within a trigger in the Tidemark database. It is anticipated that this will take a process (assigning an inspector) that now takes three days and reduce it to near real time.

  2. Continued creation of integration tools There are additional integration tools that we need to develop. These include tools to do routing on our transportation networks, both single-mode and multi-mode. We have a web application that tells a voter what their polling place is based on their address. We would eventually like to add to that the ability for the user to get directions from their home to the polling place ether by car, on foot or by public transportation. Similarly, we have a parks application that can tell you what the nearest park with a skating rink is, we like to be able to tell users how to get there. We'd like to develop a web service to do buffer analysis so that function can be integrated with other applications. We'd like to develop some type of catalog service, an expansion on existing metadata services we offer. Our current point in polygon, find nearest and find within radius services depend on knowing the names of layers within our SDE database and the names of fields within those. Determining some means of allowing programmatic detection of that information would improve the usability of the web services we have already developed.

  3. Increased integration of geospatial tools As we move forward we will be tying our geospatial tools more tightly together. We have already begun this process by beginning to integrate ArcIMS based application with the ArcGIS Server based web services. The latest version of the Polling Place Locator mentioned earlier uses a geocode web service and the point in polygon web service as well as ArcIMS for mapping capabilities. We will be rewriting all of our ArcIMS applications to take advantage of these tools where it makes sense to do so. We are also moving forward with an integration of Pictometry with ArcIMS. Pictometry imagery has proved to immensely popular with our users. By adding the ability to access the Pictometry data from within an ArcIMS application we believe we can provide an even better experience for our users.

  4. Implementation of New Technologies As development progresses on new and existing applications, changes shall be made to incorporate advancements in technology. In the next year, the Woolpert and City of Indianapolis development team will develop new and update existing applications using the ArcGIS 9.2 and Microsoft .Net 2.0 frameworks. ArcGIS Server 9.2 will provide enhancements in functionality and performance, which should address a handful of issues with existing applications as well as provide further avenues for integration within the overall enterprise GIS. Many of the existing ArcIMS applications will be rewritten using ArcIMS 9.2. ArcIMS 9.2 provides a new .Net web Application Development Framework, allowing developers to generate mapping websites using drag and drop controls in a matter of minutes, rather than days. Because of this, advanced ArcIMS development can be performed directly from the .Net environment. This will enable developers to develop against ArcIMS and other system API's in a single code base, therefore providing more effective integration between the City's various ArcIMS websites, systems, and.Net based web services. Finally, Microsoft has released their new Visual Studio 2005 development environment and .NET 2.0 framework. Visual Studio 2005 provides enhanced application development and design functionality leading to a tighter integration between UML code design and actual code development. The .Net Framework 2.0 includes new functionality and controls for web form design, such as a wizard control and a new login component library. This all provides for more effective an efficient code development.

  5. Continued integration of GIS into ISA From an organizational perspective GIS will continue to be more and more a part of the overall IT organization. The GIS efforts in the City/County have a history of being leading edge, sometimes bleeding edge. Increasingly the tools needed to provide the leading edge solutions our customers have come to expect are provided by other members of the IT organization. While GIS is still a specialized body of knowledge, it cannot stand alone. Database administration, application development, systems administration, networking and many other skills are needed to make GIS work. In a large enterprise like the City of Indianapolis, those skills need to be provided by others in the organization in order for the GIS professionals to be able to continue to shine. In recent IT board meetings, executives have singled out GIS for praise. Our success depends on the success of the rest of the IT organization to which we belong.

Richard L. Petrecca, Jr.
Project Manager
Indianapolis/Marion County Information Services Agency
200 E Washington St.
Rm. 2441
Indianapolis, IN 46204
Phone – (317) 327-4792
Fax – (317) 327-4954
Email - rpetrecc@indy.gov

Joe LaCombe
GIS Programmer
Woolpert, Inc.
7140 Waldemar Dr.
Indianapolis, IN 46268
Phone – (317) 223-2264
Fax - (317) 291-5805
Email - joe.lacombe@woolpert.com