Delivering public information

The city of Indianapolis has been using geographic information system (GIS) software for its public utility management and urban planning since the mid 1980s. Over time, the software system matured from decentralized individuals in separate departments into a dedicated division called IndyGIS. As the division expanded over the years, ever-increasing layers of information were added to the GIS. Soon, various city departments came to rely on the GIS system, including Public Works, Urban Planning, and Parks. What was once an on-demand map shop evolved into an enterprise-wide system, providing more than 400 data layers to more than 500 GIS users throughout the city and Marion County, Ind. Inevitably, IndyGIS began to experience the typical growing pains that come from an explosive demand for these types of services: Too many disparate systems with too many owners made it increasingly difficult to maintain.

Enterprise GIS system, Indianapolis



Product application

Modular service-oriented architecture provides scalable GIS system using integrated enterprise data.

In 2002, IndyGIS selected Woolpert, a GIS consulting and application development firm, to provide consulting services for its existing GIS environment and to architect a system that could bring GIS to its citizens and city staff. Project leads from both IndyGIS and Woolpert collaborated to create a standardized approach for needs assessment, requirements gathering, planning, and implementation that could be scalable for both immediate and future initiatives.

As the city gathered requirements for the enterprise GIS, city staff recognized the need to increase responsiveness to requests while providing improved visibility into the status of those requests. Realizing that vast amounts of existing data were contained in the various GIS layers, IndyGIS sought to harness this power for maximum benefit across multiple disciplines and applications. It was clear that a delivery mechanism was needed to distribute GIS information and functionality across the enterprise and to the public, without the end users necessarily even knowing it.

“Our goal was to develop Web-based applications for our citizens that provide transparency into the city’s services and offer access to information that will enable them to take advantage of all the city has to offer,” said Chuck Carufel, systems development manager with the city of Indianapolis Information Services Agency. “We also wanted our city staff to optimize their own processes with applications that help them improve efficiencies and be better servants to our citizens.”

Beginning in January 2003 through the present, Woolpert has provided programming, system integration/architecture, data services, project management, and oversight of more than 120 separate technology initiatives.

Figure 1: Service-oriented architecture model depicts how the GIS core Web services interact between the enterprise data sources and client applications.

SOA extends GIS capabilities
To integrate various enterprise systems and applications with the GIS, Woolpert instituted a modular approach to backend automation and integration of systems by deploying a service-oriented architecture (SOA). The SOA has enabled the exposure, consumption, and integration of data and functionality between an enterprise geodatabase and enterprise database systems (see Figure 1). In doing so, the SOA supports integration with Web-based applications built using various development technologies such as Flex, JavaScript, and Silverlight. It’s an approach that enables custom applications to draw from shared databases using Web services to report that data to the end user, whether it’s a staff member or private citizen. The modular flexibility of the SOA is a scalable model that supports expansion and future growth of GIS applications.

What’s more, the SOA provides the ability not only to share GIS data with internal agency users and systems, but also to utilize the power of GIS to query, analyze, and validate information before it is sent to a respective system. The Web services Woolpert created allow the calling system or application to query information from the GIS to determine location data, including intersecting polygons and finding the nearest features position within a designated area.

Woolpert deployed a service to validate an address against the enterprise master address database. This allows third-party systems or applications to consume these Web services and take advantage of the GIS functionality. For example, one system may want to validate an address first and then select features from the GIS based on that validated location. A similar type of integration was used on a number of systems throughout the city’s enterprise, including permitting, asset management, and its customer relationship management (CRM) system. These systems were enhanced to validate addresses as customer service staff enter them for a particular case or request. Upon validation, the application obtains information from the underlying GIS layers via other Web services, and then populates with screen content that otherwise would have been entered manually or looked up.

Communication with these Web services from the various systems is performed via simple object access protocol (SOAP) calls, but these Web services also have a representational state transfer (REST) interface making them accessible from custom Web applications built using some of the latest Web development technologies. Regardless of the client-side front-end, the SOA cloud allows these clients to interface with the same existing Web services.

Automated mapping services and data flow
An automated mapping services (AMS) workflow was deployed that enables connected systems to submit address information and related data of an item to be mapped, and to apply a rigorous workflow to those cases so that they appear in near real time in the city’s main GIS database. The AMS serves as a common core that supports three similar but separate workflow services required by the city of Indianapolis/Marion County: permitting, customer relationship/service request, and asset/work order management. Once captured by the AMS workflow, items will be transformed into points, simple polygons, or linear features for viewing and querying via any GIS-enabled client application. And with one or more workflow services using this common core, AMS encapsulates the insertion and update of GIS map features in a centralized database by the particular application using the Web service.

Though the AMS core defines the structure and functionality necessary for the overall Web service, the internal workflow requirements often differ depending on the calling system. For example, the end result for all of these services may be to create GIS features based on the respective work item. In the case of Accela, a permit creation and workflow service, XY coordinates will be provided, thus eliminating the need to geocode an address. Later in the process, building information must be inserted into the master address database (MAD), and a notification must be sent to various parties if a permit is related to a certain zoning type.

A Siebel CRM service request, however, requires geocoding because only an address is provided, but does not require the insertion of information into the MAD. A request from the Hansen Work Management system may include a completely separate workflow to retrieve the necessary information to populate the respective GIS feature, as well as different processes and functions. Therefore, it is necessary to inherit the basic and common functionality from the AMS core, but also be able to extend the service to perform the operations and activities necessary to the calling system workflow.

As part of these various system workflows, some individual mapping services will continue to use existing GIS Web services maintained by the city and county for performing specific GIS operations, including address geocoding and spatial analysis and selection services (i.e., Point in Polygon, Find Nearest, Find Within Radius, et cetera). In addition, other existing services will be utilized to gather information from system services relating to databases, including MAD and property system.

End-user experience
As development progressed into user-centric Web applications, the concept of automated workflow orchestration was integrated into those applications as well. Typically, each Web application built today for the Indy enterprise contains some sort of advanced process or workflow for querying/retrieving data, pushing data elsewhere, or performing some type of analysis. Since the SOA cloud contains a powerful suite of Web services exposing GIS functionality, these workflows can be automated and calls to existing Web services orchestrated based on user interaction with the Web application. In the scenario where an application has multiple front-ends, such as a Web client and mobile, this approach allows for a single source for performing the backend business logic.

Following are a few of the applications that were developed for the public and the city or county staff that utilize the SOA or AMS workflow:

Figure 2: My Neighborhood is a public website that gives citizens access to local resources depending on their addresses.

The My Neighborhood website (; see Figure 2) was developed for the citizens of Marion County to provide generalized neighborhood and address-specific information related to resources available to citizens living in Marion County. Visitors start by entering their specific address, and then select from a comprehensive list of options to access information about everything from trash pickup day to where the nearest health care facility is located. The site ties several Web services together to query the information requested by the end user.

Figure 3: SnowFighter portal provides Public Works staff with a way to track and monitor resources during a snow event.

The SnowFighter portal (internal; see Figure 3) gives Public Works staff a Web-based solution to dispatch, monitor, and track resources during snow events (known as a snow fight). The application ties to the city’s Hansen computerized maintenance management system to track the creation of work orders as well as employee, vehicle, and materials costs accrued during a 12-hour shift. This is a significant improvement compared with the previous system in that it utilizes the latest GIS services and no longer requires creation of a new work order each time a crew is dispatched to a route. This reduces the amount of interaction that occurs between the SnowFighter portal and Hansen, as much of the snow fight data is stored within a custom tracking database from which most of the reporting is generated.

Figure 4: RequestIndy provides an online interface through which citizens can report issues or request service.

RequestIndy (; see Figure 4) is an online citizen response system through which residents can report problems such as stray animals, abandoned vehicles, and potholes directly to the Mayor’s Action Center Siebel CRM system. The portal allows residents to pinpoint the exact location of any incident, categorize it to expedite routing to the appropriate department, and then track the request through to its resolution. To report an issue, residents access the RequestIndy site and create a service request from a list of existing categories, such as illegal trash dumping, high weeds, traffic signal outages, and potholes.

Joe LaCombe is project manager with Woolpert Inc. He can be contacted at

Posted in Uncategorized | January 29th, 2014 by

The comments are closed.