1.0 Abstract

The City of Philadelphia is building the largest integrated municipal GIS in the world. This paper is an attempt to characterize the emergence of our GIS, the magnitude of the tasks facing our GIS managers, and the interdependencies that went into building some of our key coverages. It includes a description of the following development projects and several applications which are representative of what the City has been able to accomplish using GIS.

The Philadelphia Streets Department Centerline File

The Philadelphia Water Department’s Digital Orthophotography Project

The Department of Records Parcel Conversion Project

GIS in Sanitation Operations

Using GIS to Retrieve Historical Data at the Water Department

Crime Analysis using GIS at the Philadelphia Police Department

 

 

2.0 Introduction and Background

PHILADELPHIA’S GIS

In 1992 the City of Philadelphia began building a GIS system to map and record its land information and infrastructure with the expectation that this system would contribute to more efficient operations and facilities management and would provide the basis for unprecedented analytical capabilities. Today the system is the largest distributed, integrated municipal GIS in the country. It is truly an enterprise wide system to which individual departments contribute by creating data or building applications that are shared Citywide and it is currently being used effectively by almost every department to for mapping tasks that range from catching criminals to landing airplanes.

The development of the GIS as an enterprise-wide system is not something that can be tracked on a gantt chart. Pieces of it emerged as various departments attained both awareness of the potential of GIS and the resources to take advantage of it. It was built without a Citywide implementation plan. Instead we started out with some strong fundamental concepts and a set of standards. A GIS Task Force led by the Philadelphia City Planning Commission (PCPC) and made up of Commissioners and Deputy Commissioners from the major departments was formed by the Mayor in 1993. The Task Force provides general guidance and sanctions the standards which include hardware, software, coordinate system, accuracy, database structure, and land records data, including addressing and street codes. The Mayor’s Office of Information Services (MOIS) took responsibility for enforcing the standards and coordinating the technology, making sure the pieces all fit. While departments "own" specific data sets, which means they are responsible for maintaining and updating those particular data layers, the data are used by departments and agencies throughout the City. MOIS also took responsibility for determining and building the network infrastructure capable of supporting a distributed GIS (ref. Paper no.558, 1997 Esri User Conference Proceedings). Now, even though this GIS was built with advice from multiple consultants, includes coverages created in a variety of cities and countries, sits on multiple servers, and drives an increasing number of very different applications, Philadelphia’s GIS functions as one integrated system.

 

 

3.0 GIS Database Development 

3.1 Street Centerline

Philadelphia’s centerline coverage had its origin at the Philadelphia City Planning Commission (PCPC). PCPC contracted with Esri to rectify the US Census Bureau TIGER file to fit within the street rights-of-way of PCPC’s parcel coverage. The centerline was then turned over to the Philadelphia Streets Department (Streets) for additional editing and enhancements as well as long term maintenance.

Streets, with help from ADR Associates, a private consulting firm located in Pennsauken, NJ, added traffic flow information, missing street names, and the five digit street codes standardized Citywide for each of the street segments. Every effort was made to add, delete or modify the over 43,000 arcs with the goal of accurately representing all the streets in the city, plus the few walkways that have addressed properties. Common driveways (a.k.a. back alleys) were also added to accommodate Sanitation collection. The centerline represents 2736 miles of city streets and 160 miles of common driveways.

Streets contracted with ADR Associates, a private consulting firm located in Pennsauken, NJ for help adding traffic flow information, missing street names, and the City’s standard five digit street code for each of the City’s 43,762 street segments. In addition, Streets Department staff performed a massive physical QC and arcs were added, deleted or modified to meet the goal of accurately representing all the City’s streets, as well as the few walkways that have addressed properties. Common driveways (a.k.a. back alleys) were also added to accommodate Sanitation collection. As an additional measure of Quality Control we had a nodeless centerline coverage created. This coverage has a one to one correspondence between arc and physical street (with the exception of instances of streets with non-contiguous segments which were so coded) and provided a unique perspective on both the coverage and on our street code list.

Because we knew the centerline coverage would be constantly used by the City for scores of geo-referencing applications we also wanted the address ranges as accurate as possible. Outside of Center City, the street network pattern is unruly and no department or agency in the City kept an "official" address range list. This was particularly problematic for streets on which there are no addressed properties. We recognized that the highest standard for accuracy would be driven by the need to correspond to the address ranges used by emergency services and public safety because our expectation was that police and fire would be using the coverage for incident location and routing. Again with help from ADR Associates, we programmatically identified as many missing or questionable address ranges as possible and conformed them to the address ranges used by the Philadelphia Fire Department. We will also be cross-referencing these address ranges with those used by the Philadelphia Police Department.

We are currently in the process of improving the positional accuracy of the centerline coverage by rectifying it to the center of the City’s streets as depicted by the orthophotography described below. When that task is complete the centerline coverage will represent 2,736 miles of city streets and 160 miles of common driveways with two foot absolute accuracy.

3.2 Philadelphia’s Digital Orthophotography Project

The Philadelphia Water Department (PWD) is one of the largest and oldest municipal utilities in the country, providing water, wastewater, stormwater, and biosolids services for over 1.6 million people. The water system is made up of 3,300 miles of main with a service area of 130 square miles. There are 3,000 miles of stormwater conduits and sanitary sewers with a wastewater service area of 360 square miles.

Adapting to the rapid pace of today’s technology can be an enormous task for a 200-year old municipal utility of this size, however, over the past year the PWD has taken major strides in the area of information science and technology. During 1997 the PWD began to assemble the pieces of what will be one of the largest water, wastewater, and stormwater GIS in the world. The first step in this GIS program was the creation of a base map to which all of the existing infrastructure could be geo-referenced. The PWD elected to use digital orthophotography as the means to create the base map for its GIS.

HISTORICAL BACKGROUND

The responsibility of inlet cleaning was passed to the PWD in 1968 and since then stormwater management has been a recognized component of the cost of sewer services and facilities. The costs for collecting and treating stormwater and maintaining 80,000 inlets are offset by user charges for stormwater based on the size of the customer’s water meter. This methodology was challenged during rate hearings in the 1980’s and the PWD decided to reevaluate this methodology.

A Stormwater Charge Allocation Community Advisory Committee (CAC) was formed in 1994 to evaluate the methodology used by the PWD to allocate stormwater costs. The CAC found that gross area and impervious area are the two most important factors of stormwater runoff. Using these factors in formulating a new policy would be a more accurate approach of allocating stormwater charges to over 550,000 properties, than an approach based on water meter size.

This more rational approach will better approximate the costs of stormwater management because the property owners will be charged based on the amount of runoff they contribute to the system. Digital orthophotography was chosen by the PWD as the means to generate the necessary impervious area, gross area, and other information that will be used for the new stormwater charge methodology.

The PWD’s GIS Program began in March 1996 when Air Survey Corporation (ASC), a private contractor from Sterling, Virginia, flew the city and began the creation of the landbase for the GIS. This project, estimated at $2.5 million, will create the base map that all city agencies (Streets Department, Records Department, and the Mayor’s Office of Information Services) will use for their GIS and therefore involved an extensive amount of coordination. All Orthophotography production and planimetric compilation was completed in April 1998, approximately two years from the date the project initiated. The scope of work for this project involved:

Production of Citywide digital orthophotography at a scale of 1"=200’ at a ground resolution of size of 0.5 foot per pixel (approximately 29 GB of data).

Digitization of planimetric features such as; impervious features, curblines, building footprints, elevated structures, hydrologic features, railroads tracks, fire hydrants, stormwater inlets, street light poles, traffic signals, and stop signs.

Preparation of Digital Terrain Model (DTM) and contour coverage of the city at 2’ intervals in both ArcInfo line and point coverages and ARC/TIN coverage format.

SCOPE OF WORK

Digital Orthophotography

To obtain photography that would be useful for mapping purposes, the city had to be flown when foliage is at a minimum (between December and mid-April) and between 10:00 AM and 2:00 PM to minimize shadows. Furthermore, the photographs had to be taken on a day without cloud cover and the ground had to be free of snow, haze, fog or dust. Finding an opportunity to fly was extremely difficult considering that the winter of 1995-96 was the worst in Philadelphia history. Also adding to the difficulty was that the specifications stated that the Center City area (approximately 400 square blocks) had to be flown on a Sunday, when traffic was at a minimum. Finally, after months of waiting, the snow melted and ASC flew the city on a clear Sunday in mid-March 1996.

ASC shot over 470 photographs at a scale of 1"=800’ covering all 140 square miles of the city. Photo overlaps were specified at 60% photo overlap between consecutive photos along each flight path and a 30% overlap of photos between adjacent flight paths. Prior to the flight, 62 existing city survey monuments and 86 additional locations were set and targeted using Global Positioning Systems (GPS) to provide ground control for the photography. Targets were then located on each photo so that each photo could be geo-referenced to Pennsylvania State Plane Coordinates (NAD ’83). Draping the images on a digital terrain model (DTM) surface and rectifying, "flattening out", the images created orthophotos.

Photogrametric Compilation

Analytical stereo plotters were then used to compile planimetric features from the digital orthophotographs in ArcInfo format. The features captured for this project include curblines, building footprints, elevated features, hydrologic features, railroad tracks, fire hydrants, stormwater inlets, and street poles (light poles, traffic signals, and stop signs). In addition to stereo compilation, field crews walked every mile of the city to compile detailed attributes for each hydrant, inlet, and street pole.

In conjunction with the stormwater allocation project, ASC is providing photogrametric digitization of impervious features such as buildings, travelways, sidewalks, patios, and parking areas. Any surface with an area of 100 square feet or greater is being compiled and categorized as long as it is identifiable from the aerial photography.

PROJECT MANAGEMENT AND QA/QC

A project of this size involved a massive amount of quality assurance and quality control (QA/QC) and the PWD was responsible for managing the QC efforts of two consultants and various city agencies. GIS and digital orthophotography are technologies that were new to PWD. Therefore, a consultant, CH2M Hill from Reston, Virginia, was brought on board to assist with project management; provide technical expertise in GIS, photogrametry and cartography; and also for QA/QC. CH2M Hill’s Reston, Virginia and Redding, California offices were responsible for database review, stereo model review, orthophotography review, and field data testing.

Ogden Environmental & Engineering Services, a private engineering firm from Greensboro, North Carolina, provided QC services for the review and acceptance of the impervious surface coverage. Ogden staff randomly reviewed portions of the city on desktop workstations using ArcView and also provided field reviews of the impervious coverage for large commercial properties.

The Streets Department provided such QC services as field data testing and on-screen reviews of all street pole data. The PWD coordinated the efforts of all parties and was also responsible for final review and acceptance of all deliverables.

PROJECT ISSUES

NAVD 1988 vs. Philadelphia Datum

Philadelphia uses a vertical datum that was established in 1682 by its founders. All Philadelphia curb heights are fixed by law and can only be changed by an ordinance of City Council. North American Vertical Datum (NAVD ’88), the datum used for targeting and control requirements, differs from City of Philadelphia datum by -4.63 feet. It was important that all vertical data be relative to NAVD ’88 for future integration with other state and government data. However, it was also important to display topographic contours in Philadelphia Datum because all of the PWD’s and City’s records reference this datum. An addendum was added to the Analytical Aerial Triangulation Report explaining the datum differences and ASC was compensated for the additional changes in the scope.

Field Data Collection

One of the most difficult tasks encountered during the project was the field location and classification of approximately 30,000 hydrants, 80,000 inlets, and 200,000 street poles. The original contract called for these features to be located using the stereo plotters during the planimetric compilation. However, both the Streets Department and PWD wanted to obtain attribute information about the features and a price was negotiated with ASC to acquire the attributes using field data collection methods.

ASC assumed that their compilers would locate most features in the office and that the field crews would spend most of their time attributing these features not locating them. It quickly became evident that compiling inlets and hydrants using stereo compilers at 1"=200’ scale would be difficult due to high-rise buildings, parked cars, and dense tree canopy. Field crews had to spend more time and cover far more area than expected locating utility features. The PWD worked with ASC to help reduce the costs associated with fieldwork by reducing the number of attributes assigned to each feature.

 

3.3 Department of Records Parcel Conversion Project

The City of Philadelphia Department of Records (PDOR) is currently in the process of automating over 600,000 property parcels from over 4,800 Registry Maps. This project will provide a ready to use ArcInfo database of every parcel in the City, as well as maintain a growing archive of historical data. The data will be stored on a server that will be maintained by the Records Department, but made available to all the Departments within the City once the database has been completed.

The implementation of the automation process has been divided into two parts, with two phases each. The first part is the Rasterization Process. This process consists of a Scanning Phase and a Georeferencing Phase. The Vectorization Process consists of a Parcel Vectorization Phase and a Parcel Attribution Phase.

THE SCANNING PHASE

All maps were scanned at 300 dots per inch (dpi), on a Vidar TruScan 800 scanner. Care was taken to ensure the proper contrast for each map. Since the maps themselves contain a very high spatial accuracy between features on the same map, great care was taken to ensure that this accuracy level carried over into the raster environment. Each map was evaluated and given a quality classification from 1 to 5 depending upon age, density of features, number of text touching line work, and completeness of the map itself. A Class 1 map is of the highest quality, can be easily interpreted and poses no scanning or accuracy challenges. A Class 5 map, on the other hand, is generally old and worn, may be torn or faded, and can not be made to produce a legible raster image.

THE GEOREFERENCING PHASE:

The Registry maps posed some particularly difficult challenges for geo-spatial alignment. During traditional georeferencing, an operator or cartographer will locate a minimum of four control points that can be directly associated with features on the ground or geo-spatial coordinates. Links will be built from these control points to their output coordinates. The image will then be rectified to align to the output coordinate system. This is generally a very straight forward process.

With the Philadelphia Records Department maps, however, there were no ground control points that could be identified. To further complicate matters, even if ground control could have been obtained, in all likelihood if it was used it would have distorted the data within the individual maps unacceptably. The Philadelphia Registry Maps are extremely accurate, proportional to themselves, but not proportional to the real world. It was necessary that they be aligned to the real world without changing the shape of the map itself.

After many failed attempts to devise a method for registering the images, we finally struck upon the solution. The Philadelphia Water Department had already begun the process of obtaining orthophotography for the entire city of Philadelphia. From these photographs, planemetrics were to be created, including curblines. We knew that nearly every map was of a consistent scale unto itself, so each image could be easily scaled to real-world coordinates. The rest of the information required to georeference came from the orthophotos and the planemetric curblines. To determine the correct location, we made the assumption that the centroid of a curbline polygon will be very close to the centroid location of a parcel block. We knew that it would not be precise, but it provided enough information to move the image to the correct location within the City. We also made the assumption that house lines run parallel to curblines. This is not always precisely the case either, but it made the original alignment very close. Features from the orthophoto could then be used as evidence to better align the image.

A tool was developed to guide the user in the georeferencing process. First, the image was scaled from measurements taken off the map. Then a parcel block outline was digitized from the image using ArcScan. Next, the correct curbline block was selected from the planemetric data. Finally, a rotation angle was determined by selecting a Registry Map block edge and a planemetric block edge. With all this information in the computer, it was then just a matter of pressing a button within the Tool to align the image to the orthophoto. Once this was done, the alignment was verified on screen, and fine adjustments were made as needed. The fact that everything aligned so well to the orthophotos was a testament to the quality and accuracy of the original source.

THE VECTORIZATION PHASE:

Once the raster images were placed into real-world coordinates, ArcScan was used to capture the outlines of every parcel. There were 4,880 maps, averaging 150 parcels per map. Care was taken to ensure that the vector lines overlaid the raster data precisely. The challenge to the vectorization was determining which lines to capture and which lines to omit. This process only included capturing parcel boundaries and right-of-ways. Reference lines, discontinued parcel lines, and other features that might appear on the map were omitted. Since some of the maps were very old, they had been through several generations of updates. This meant that they were not always cartographically consistent. It required a great deal of map interpretation to determine which lines should be captured and which should be left off. ArcTools was used as the interface to ArcScan for vectorization.

THE ATTRIBUTION PHASE:

Once all the data was aligned to the real world and the boundaries of the parcels and right-of-ways had been captured, parcel numbers and address information had to be assigned to each parcel. This was not quite as simple a process as one might think. Right-of-way boundaries may cross into parcel areas, and parcel areas may even share boundaries. It was determined that a region sub-class must be created for parcels and rights-of-way in order to capture every feature correctly.

Also, since the maps themselves were not always legible, it was necessary to obtain information from other sources to assign the attributes. Nearly every parcel in the City is contained in an analog database referred to as a Land Title File. This file contains full registry number and address information, but has no spatial reference. The PCPC had previously created a database of parcel and address polygons, but at a much smaller scale and these data did not have registry numbers. We found that by using the Land Title File in conjunction with the PCPC Data, we could vastly economize the attribute assignment time while ensuring greater accuracy in the data. If the Registry Map was legible, the parcel attributes were always automated from that, but we were able to populate most of those attributes automatically from the PCPC Data and the Land Title File through address matching. Once the address match was complete, is was merely a matter of verifying the attributes for each parcel, fixing any errors that might have occurred, and assign a Match Flag attribute which indicated the quality of the address match and location of PCPC parcel centroids.

QUALITY CONTROL PHASE:

Extensive Quality Control is performed on all data as each phase of automation is complete. The Scanning Phase was QC’d on screen where images were checked for completeness, reasonable legiblity, and correct resolution. The Georeferencing Phase was QC’d both on screen against the orthophotos and plotted over the planemetric curblines. The Vectorization Phase was QC’d strictly via plot, as this is the best method for determining line work errors.

A special tool was created to perform Attribute QC. The QCTool is a statistical tool that uses a Standard Deviation to select a representative sample of parcels to be checked, and then calculates the amount of error based on errors found within the random sample. The number of parcels selected in the sample depends on the amount of error that accumulates with each iteration of the QC Statistics and the number of records in the current data set. In order to use the QCTool effectively, it is first necessary to perform 100% QC on the entire data set. This is done on a map by map basis as soon as the attributes are assigned. Then, several maps are appended together to obtain the representative sample. It is necessary that there be at least 1000 records in the data set for the QC Statistics to have any meaning when taken from the random sample. In this way, we ensure that we have a 98% confidence that the data are 98% correct.

4.0 Sample Applications

4.1 GIS in Sanitation Operations

The Sanitation Computer Assisted Routing Project was the first major GIS application in an operational department in the City of Philadelphia. The goal of the project for the Sanitation Division was to create balanced, fair and clearly defined work assignments for each of the rubbish and recycling crews and to have a tool for creating maps and routes for other functions, as well. A broader goal for the Streets Department was to establish a GIS foundation for the rest of the Department. For the City, a broader goal was to establish a responsibility center for the Street Centerline coverage.

It all began in 1992 with a decision from the Streets Department Data Management Committee, backed by the Streets Executive Committee, to embrace GIS and bring it to life in the Sanitation Division. In 1993 and 1994 the following start up work occurred:

  • Staff was hired in the Sanitation Division.
  • A loan was taken out from the productivity bank
  • A contract was executed with RouteSmart Technologies, Mineola, NY, for the customization of the Routing Software to accommodate Philadelphia’s need for multiple truck types.
  • Hardware was purchased. (IBM RISC/6000 with five X-terminals)
  • GIS software was purchased. (Esri’s ArcInfo)
  • A massive data collection effort was undertaken to verify the street centerline and gather the data for one way streets, the location of small streets, and common driveways which are used by sanitation collection vehicles.  Currently, there are 1.8 million pieces of information attached to the street centerline.
  • A contract was executed for data development to support RouteSmart.
  • PCPC’s parcel maps were used to create a customer database, after intensive quality control efforts.

A pilot area was completed in West Philadelphia and the first routes were generated and used in the field in December 1994. Since then over 1000 routes have been created for recycling and rubbish trucks. These routes will be evaluated and revised as needed over the next year and than modified as conditions change. These conditions include changes such as new collection vehicles, new housing developments, and changes in recycling participation.

RouteSmart gives managers the ability to create quality maps that can be easily modified as changes occur. GIS has been used in Sanitation for following:

  • Analyze truck routes
  • Give out hard copy maps of route assignments to drivers and supervisors
  • Balance routes
  • Adjust routes to fit new equipment and changing conditions
  • Household counts
  • Revised boundary maps
  • Revised routes
  • Maps for distribution of flyers for public notice
  • City wide map showing boundaries for each week of collection
  • Individual maps representing each day’s work
  • Tons/collection day
  • Cost/ton for collection day
  • Recycling rates per day, district, area

The collection vehicle routing project allows managers to experiment with different scenarios on paper before implementing them in the field. The computer calculates the number of households, the projected amount of material and the projected amount of time that it takes for each vehicle to complete the assigned task. The computer can be used to balance on time. The input can either be 1) a certain number and type of trucks for which the computer will come back with the approximate time that each truck will need to work; or 2) the desired number of hours for which the computer will identify the number and types of trucks required to perform the task. As with all computer programs, the answers that the computer gives are only as good as the data that it has to work with. The data for the location of streets and service is extremely good, and for the number of households is fairly good, but the data for time and quantity is only fair. The improvement of this time and quantity data is our current focus.

Initially the program was run with averages for the whole City, based on a number of field surveys. These numbers have been refined in recent months, and will continue to be refined as we gather more information. Our studies show a tremendous amount of variation in time and tonnage even within the same truck route with the same crews. We have been working to understand this variation and to improve the data that we use as input into the RouteSmart system so that it can better predict the time and tonnage we would expect to see, on average, for each truck route. We have determined that the travel speed between stops seems to be related to the distance between stops, and whether service to a street occurs in one pass or two. The generation rate per household seems to be seasonal to some extent but also erratic within each season.

It is extremely important that the software not be used in isolation and that route solutions are developed in conjunction with field supervisors. They are the ones that really know the subtleties of the neighborhoods and the specific collection requirements of each street.

The Department made an initial investment of a million dollars for the hardware, GIS software, routing software and the data development. This investment has resulted in the Streets Department having the first fully functional large scale GIS project in the City. It has also established the Streets Department as the Department responsible for the maintenance of the centerline file. However, the best testament for the success of this effort is that the Streets department has decided to expand the use of GIS and create a second GIS Unit in its Transportation Division to develop GIS based transportation and facilities management systems. Streets has also put in place a contract with Gannett Flemming, an engineering consulting firm from Camp Hill PA, for a full scale GIS Strategic Plan.

 

 

                   4.2 Philadelphia Uses GIS to Retrieve Historical Data

HISTORY

When William Penn founded the city of Philadelphia in 1682 his master plan was to build a city between two bodies of water: the Delaware and Schuylkill rivers. This plan, as shown in Figure 1, consisted of a 22x8 block grid pattern including four public squares that defined each of the city's sectors, as well as a center square (now the site of City Hall). At that time, the territory that would become Philadelphia was a fertile land consisting of more than 50 streams, creeks, brooks, and runs that contributed to the two major rivers.

P5492.JPG (50427 bytes)

Figure 1:  Master Plan of Philadelphia Created by Thomas Holme, Surveyor General 1683

Over the next two centuries many of these streams were filled in, turned into sewers, or otherwise abandoned due to urban expansion and the need to protect against the spread of epidemics. One by one names like Mill Creek, Beaver Creek, Gunner’s Run, and Ship Brook went from thriving water bodies to neighborhood legends. On occasion one of these underground legends comes back to haunt residents of the city in the form of a flooded basement or an unexpected sinkhole.

INTRODUCTION

The material used to fill in these natural watercourses was usually cinder refuge (generated from coal burning), found in abundance at the turn of the century and believed to be acceptable backfill material. Today we know that cinder refuge is not a good backfill material especially when water mains and sewers are located within it. When a water main breaks in a fill area there is a chance of a potential sinkhole occurring as soil becomes liquefied and washes into the nearby sewer through an open joint or crack.

Throughout the years it has become increasingly evident that fill areas are more susceptible to erosion of soil. Fluctuations of the water table and the flow of water through former stream channels are natural conditions that can increase the chance of subsidence of soil. A small diameter water main break in a fill area can exacerbate these natural conditions and potentially cause a significant disturbance to the surrounding pavement, utilities, and building foundations. The repair of the infrastructure due to a disturbance of this nature can be costly and almost always a burden on the public in the form of property damage and street closures.

Furthermore, fill material has a tendency to be more compressible than most soils and combined with its higher erosion properties, has been the cause of some large diameter water main breaks as it settles. These large diameter water mains are usually cast iron pipe with joints that were not designed for significant rotation or stress. The magnitude of stresses induced by pipe settlement can cause a break in the bell of the joint (see Figure 2).

Figure 2:  48" Water Main Break in June, 1994

An engineering study performed by Thorton-Tomasetti Engineers of large diameter water main breaks in fill areas in Philadelphia determined that the most probable cause of main failures is differential settlement along the mains. Calculations have indicated that a settlement of only 1�" can induce enough stress in a pipe joint to cause rupture. Based on the results of these professional engineering studies, the Philadelphia Water Department implemented a Fill Area Study.

FILL AREA STUDY

It is impossible to determine the exact limits of where fill material may exist. However, it is possible to determine which areas in the city potentially contain fill by researching two data sources and utilizing geographic information systems (GIS). The primary source of information was a series of "stream maps" prepared in 1934 by the Bureau of Building Inspections to show both city streets and the approximate location of former streams. The secondary source of data in determining the potential limits of fill was sewer contract drawings.

In order to fill in the streambeds, developers had to divert the existing stream flow into a proposed sewer. As a result, the old sewer contract drawings represent both preliminary and final development topography. The problem with the contract drawings was that they were developed to detail the construction of a new sewer and not to display the exact limits or extents of fill material. The sewer drawings concentrated on the design of a sewer located within the city right-of-way and therefore contained insufficient information as to what was occurring outside of those limits. Areas in the vicinity of former streambeds that could not be substantiated by old contract drawings were denoted as "suspected" fill areas.

ZONE OF INFLUENCE DATABASE

The research of the "stream maps" and old sewer contract drawings led to the creation of a "Zone of Influence" Database. This MS Access database of suspected fill areas contained information such as: on street, from street, to street, drawing number, depth of fill, water main size, and sewer size. With the additional capabilities of (GIS), the Department was able to create an application that could link the "Zone of Influence" Database to an existing street centerline coverage.

A coverage of the former streambeds was then created in ArcView by digitizing the lines from the "stream maps". The stream coverage was then overlaid on the street centerline coverage and a conservative buffer zone of 1000 feet was created and used as an assumed "zone of influence" for the old streams (see Figure 3). Using ArcView it was easy to determine which streets were located within this "zone of influence". Any streets that were not already contained in the database were then added.

P5494.GIF (50831 bytes)

Figure 3:  Using ArcView to Create a Buffer Zone Around Former Streams

DOCUMENT MANAGEMENT APPLICATION

Coverages such as old streams, "zone of influence", and street centerlines with address ranges will allow for the development of new criteria for infrastructure maintenance and replacement. Customer complaints, water main break locations, sewer examinations, and capital replacement are just some of the many types of data that can be analyzed in these "zones of influence".

The first application that the Department has developed using this data is a document management system for retrieving scanned images of the "stream maps" and/or old sewer contract drawings. The user can select street segments that are within the "zone of influence" of an old stream and view all of the plans that are associated with that segment.

MAP OBJECTS

Understanding that its primary purpose would be to link a library of scanned images to graphical map data, the application was a perfect model for utilizing the features of Map Objects. Throughout development, the staff of programmers kept in mind that the application was to be simple, yet effective. As a result, the final program was to include three key components (see Figure 4): a map view, a plan drawing view, and an attribute table view.

Figure 4:  Zone of Influence Application GUI

The operation of the application involves only a few simple procedures. By first initializing the city map and selecting a street segment contained within a "zone of influence", the attribute table is immediately activated. The routine marks the record in the table view that corresponds to the map’s graphical selection. Then, a request is instantaneously sent to the drawing library of stored images, which consists of a multiple-disk, CD-ROM tower on the Water Department’s local area network. The requested image file is retrieved and automatically displayed in the plan view. If the selected street segment references more than one drawing file, the user is presented with a matching number of corresponding thumbnail images that can be enlarged by a single mouse click. The user can easily navigate within the plan and map views, collecting any relevant data needed to conduct a "zone of influence" analysis.

In addition to basic image retrieval, the application also provides querying capabilities for all of the displayed map data (see Figure 5). For instance, if geographical information was needed for the area surrounding Honey Creek, the user could very easily enter a search expression that would result in the following:

Figure 5:  Sample Query Results

Not only is the area of interest located, but the user is provided with the ability to customize the selection by changing its color and line thickness. The map view could then be printed or even exported to software better designed for high quality cartographic productions, such as ArcInfo or ArcView.

VISUAL BASIC

The entire "Zone of Influence" application was created using Microsoft Visual Basic 5.0. Visual Basic provided Department programmers with the unlimited power to develop a creative and easy-to-understand graphical user interface (GUI). These capabilities where extended to an even higher level once the Map Objects component had been implemented. This effective language and map component combination allowed for the creation of some very impressive forms and modules (see Figure 6).

P5496.GIF (47913 bytes)

Figure 6:  Visual Basic Forms and Module

Each of the three views, or "child" forms, are contained within a single "parent" form. The parent form is the home to all main menu commands, such as File, View, Window, and Help. The child forms are bound to the extents of the parent form, but can be resized and relocated to suit each individual user. Such a setup gives the application its seamless appearance.

The image retrieval function is powered by the Jet Database Engine. This component provides the capability to establish various connections to the "Zone of Influence" Access Database; thus, allowing the user to display data based on any field (on street, from street, to street, drawing number, depth of fill, water main size, and sewer size).

The applications simplicity, its unified setup, and the Jet Database functionality make this application a very useful tool for inspecting and analyzing various areas of the city.

CONCLUSION

Through the design, construction, and implementation of the "Zone of Influence" application, the Philadelphia Water Department set out on a mission to expose design engineers to the powerful features of a GIS. We succeeded in this first of many assignments, and as a result have strengthened our intent on providing the City of Philadelphia with further upcoming applications that will use GIS to enable users to become more time and cost effective workers.

 

 

 

4.3 Crime Analysis using GIS

INTRODUCTION

The Philadelphia Police Department (PPD) annually takes 4.2 million calls on its 911 system. This results in approximately 2 million unique events to which a police officer must respond. Of that number, about 120,000 are so-called Part 1 crimes (homicide, rape, aggravated assault, robbery, burglary, theft and auto theft). With this enormous workload and far fewer personnel than it had in the 1970's, the PPD brass realized it needed to use what resources it had far more intelligently. In 1996, the Information Systems Division applied for a technology block grant from the NIJ. Part of this money was allocated for the establishment of a crime analysis unit.

The Crime Analysis and Mapping Unit of the PPD was officially launched in September 1997. It currently consists of two civilian GIS professionals and one police officer who meet the crime mapping needs of 7,000 police officers and 2,000 thousand civilian personnel. The area covered by the Unit's work is that of the City/County of Philadelphia.

While the PPD had never systematically done any GIS work, the Unit was up and running in a remarkably short period of time. The ability to rapidly become productive was by-and-large possible through the City of Philadelphia's significant progress toward an enterprise-wide GIS infrastructure. An extremely high quality street centerline file as well as annotation layers, hydrological features, and parks eliminated several important steps involved in making the Unit productive. Several other layers relevant to police work have since been added by the unit, but it has been possible to do this work incrementally as needed. The fact remains that the Crime Analysis Unit would continue to spend enormous amounts of time updating street files, developing coverages and other spatial data administration activities in the absence of a Streets Department that is continuously upgrading its centerline file and a Mayor's Office of Information Services overseeing the city-wide GIS implementation. This de-centralized structure with centralized oversight was been an important ingredient in the success of our work.

This work can be broken down into three categories: 1) Production of crime analysis maps on a regular schedule, 2) Analysis of patterns in the data, and 3) Applications Development.

PRODUCTION AND ANALYSIS

The PPD holds crime analysis meetings on a rotating weekly schedule with two to three divisions scheduled per week and all divisions covered over one month. The Crime Analysis and Mapping Unit produces maps for these meetings that are sent out to each office two days prior to the meeting. These maps cover the most recent 30 days rather than a calendar month in order to keep the analysis as current as possible. Large format (Arch E) maps are produced for district and detective captain and letter size maps are produced for members of the Crime Analysis Committee. Currently, the maps include separate sheets for:

Homicide and Aggravated Assault

Property Crimes (burglary and theft from auto)

Vehicle-related Crimes

Rapes and Robberies

Narcotics (Possession vs. Sales)

However, this production schedule is frequently altered in response to items in which the Crime Analysis Committee in interested. Other maps produced on this schedule have included density of gunshot reports, narcotics and fleet accidents.

In addition to the weekly crime analysis meetings, the Unit responds to ad hoc requests from special units as well as patrol districts. Special units serviced by the Crime Analysis and Mapping Unit include Homicide, Narcotics, Sex Crimes, Highway Patrol and a mobile strike force.

While we see analysis as a separate function, for staffing reasons, we have found it necessary to roll analysis into the production process. Given adequate staffing, we would assign people to just search for patterns and map those that are found. This is not currently possible, however. Rather, we identify clusters of events, link related incidents with lines (diad analysis) and use raster analysis as needed.

Most of the production work is done using ArcView GIS 3.0a with the Spatial Analyst extension. Work is often automated with Avenue and Visual Basic. Data is held on an IBM mainframe at a remote location. This is currently downloaded on a regular basis and stored in an Access database. However, the volume of events is such that the Access approach is becoming unwieldy. We are considering migration to a proper client-server RDBMS that would serve as a data warehouse of the transaction level data on the mainframe. The greatest unknowns on this front are related to LAN-to-host connectivity, currency and the updating process. We remain undecided on how to approach these questions.

APPLICATIONS DEVELOPMENT

When not doing production and database administration, the unit is largely engaged with applications development. This process began with attempts to automate the production process but the vision has always been the decentralization of mapping functionality to the district offices, allowing any officer or detective to map the results of ad hoc queries.

Our first crack at the incident mapping challenge began with ArcView. The View GUI was stripped down to the bare essentials and series of dialog boxes added to allow the construction of a SQL query. This was quick to set up, but in the end unworkable for several reasons: ArcView requires a fairly robust piece of hardware in order to run well on large datasets such as the incident database. The district offices are not well equipped with workstations, and installing ArcView in each office would require expense equipment purchases. Moreover, the limited dialog design functions in ArcView made the query construction process cumbersome.

We began to ameliorate ArcView's limitations by collapsing all of the query construction dialog boxes into a single Visual Basic form [see illustration]. We considered Dialog Designer for this, but since, in the long run, we did not think we would be using ArcView for deployment of applications, we felt that Visual Basic applications would be more adaptable to other situations. The query form communicates with ArcView using a DDE conversation. The SQL query is sent to the Access or SQL Server database through an automated ODBC connection. The resulting table is displayed and then geocoded. Finally, the results are added to the display.

After the incident query form was completed and tested, we were set to begin work with MapObjects. The first application was a simple Narcotics mapping application but was more a proof of concept to convince our supervisors that this approach was a viable one and preferable to ArcView. We have since designed and completed an Incident Mapping application, a Domestic Violence mapping application, and a Digital Beat Book. We are also working on a Firearms Tracing application, a Sex Crimes suspect tracking application and have several others on the drawing board.

The decision to go with MapObjects was not just a software choice. The entire component software approach has allowed us to rapidly construct several small focused applications with customized interfaces and capabilities outside that of ArcView. We feel this path of constructing several small mapping and analysis applications is more likely to have an impact in the long term than a single monolithic implementation of an all-inclusive application.

APPLICATION DISTRIBUTION

Once the applications were being built, we were left with the question of distribution. While MapObjects does not require the system and hardware resources necessary to run ArcView, it does require a 32 bit Windows operating system and the PPD is standardized on Windows 3.1. Unless several workstations were upgraded to Windows 95 or NT, we would be unable to install any of the MOapps in the district offices. While the PPD would eventually upgrade to a later version of Windows, it was not clear when this would be happen. Moreover, we could foresee a relatively large systems administration burden on the Crime Analysis and Mapping Unit if multiple mapping applications were installed in each of the district offices.

We decided to try MapObjects Internet Map Server. While there was no experience with this particular approach, after evaluating several other possibilities, we concluded this was going to be the best solution available at the time. While the development costs would be somewhat higher for the MO IMS solution, it would allow centralized administration of both data and applications and would release us from any reliance upon a particular client platform. Multiple applications could be served from a single server to any number of clients. As the number of clients rises, we would be able to easily scale the system to handle the additional load by spinning off the database functions to a separate server. Other solutions we considered included: upgrade to 32bit Windows, thin clients/network stations from IBM, Citrix WinFrame, and the forthcoming Windows Terminal Server (Hydra). The elimination of these options was based on the high cost of hardware and OS upgrades to all district offices, the low bandwidth available to some district offices (56K at best), the lack of availability, training or experience with various thin client solutions, and the current difficult of deploying thin windows clients from a single server across multiple subnets (requiring boot servers in each office).

The MO IMS solution will be deployed using the existing network infrastructure with a dual chassis NT Server running MS IIS as web server, SQL Server or Oracle as RDBMS, and multiple instances of MapObjects applications. At the time of writing this paper the hardware specification has been completed but the application distribution has not begun. We expect an alpha version implementation by the end of June.

NON-STANDARD APPLICATIONS

All of the above is pretty much standard fare for crime analysis – incident query and display applications, digital beat book, some automation to distribute applications and some more advanced analysis done at a centralized location. The whole operation eventually distills down to questions of geocoding accuracy, data access, interface design, performance – all relatively technocratic issues that usually have solutions if one can come up with the money. But how might we push the GIS in terms of public safety applications? In particular, how might we turn still relatively reactive applications into proactive solutions?

We see two avenues – the first is around prediction and forecasting. However, while this is exciting, Esri is already involved with a advance crime analysis tools development project with the NIJ and a second one with the Omega Group. We are involved with the beta testing program on the former and look forward to seeing the results of the latter. Moreover the really interesting work here involves neural networks and cellular forecasting which require quite massive computing power and long periods of time, even given today's powerful desktops. Moreover, we do not have the theoretical training to make good use of such methods. The second item we saw as equally interesting, but an as yet under-explored approach is that of simulation gaming. This is a variation on scenario planning but is far more playful.

People enjoy games. Despite all of the productivity-oriented applications on the market, many personal computers are primarily used as game machines. It might even be argued that Solitaire is the most popular desktop application used in the contemporary office that if Microsoft Corp. had only distributed more and better games with Windows, they would have arrived at their monopoly position far sooner. Solitaire certainly receives a great deal of attention at police headquarters.

But games are not just useful for wasting time; it can be used to build effective, useful models as well. Simulation gaming attempts to model reality by working on the basis of players' decisions. Good simulation games incorporate roles, goals, activities, constraints and consequences that arise from actions by the players and other elements in the system (including chance). Simulation games can both help us understand very complex systems and concepts and serve as a catalyst for further inquiry into the phenomena they attempt to model.

We were convinced that games are effective because they are fun. Now the question was how to inject an element of fun in the very serious work of mapping and analyzing crime. Our opportunity came when, redistricting became a hot political topic for the PPD. For a variety of reasons, Philadelphia has not redrawn its police districts for several decades. While we knew it was unlikely a GIS application would be immediately accepted as being helpful for this project, we felt it was a good opportunity to demonstrate what might be possible.

We were interested in taking this a step beyond conventional redistricting tools, however, by designing a custom application that included not only standard functionality but also the ability to do the redistricting process as a game. This MapObjects based game is intended to fulfill the following requirements. 1) simple, 2) interactive, 3) choice of static (serious) and dynamic (random events change the conditions), 4) drag and drop interface, 5) fast feedback, 5) ability to adjust a set of 'weights' that adjust the outcome and scoring,, 6) embody the concerns of the conventional redistricting process

It remains to be seen how well our attempt at fun and humor will be accepted. The real game of policing is one of life and death. Perhaps more importantly, the real game of redistricting is a political one, and any attempt to make light of it may be frowned upon. But while this is deadly serious business, we need innovative methodologies to do it better. We always run the danger of taking ourselves so seriously and not allowing potentially helpful approaches to surface. We need fresh, creative strategies for policing our societies, and there is an important place for play and fun in this scenario. It is unlikely that the antiquated legislative apparatus will provide this kind of unconventional thinking, but we do know that games, play, and humor are some of the most important sources of creative thinking. There is fertile ground here for innovation in government.

CONCLUSION

What we have presented sounds like a bit of a laundry list. We believe, however, that rather than one large monolithic system or a killer app that takes years to develop and deploy, we stand a better chance of rapidly increasing the sophistication of Police Department processes by developing several lightweight applications customized to a particular use. We are promoting evolution rather than revolution.

 

 

5.0  Conclusion

There are many other GIS projects currently underway in Philadelphia including the construction of an enterprise server to hold all the City’s coverages and serve as a super search engine allowing mass access. We have strategic planning underway in Streets, PWD, and Licenses and Inspections to create GIS "front ends" for operational and facilities management needs ranging from permitting to street light maintenance. City staff involved in environmental planning, neighborhood planning and redevelopment, commerce, health and human services, and safety have all begun to use GIS and are clamoring for more. There is no vision of a finished GIS for the City of Philadelphia. Because of the success of GIS so far, our expectation is that we will continue to be able to add more data sets, build new applications and continue to grow the system and take advantage of new technologies. What we do see in the future is GIS becoming a tool as familiar as word processing to most of City’s desktop and serving as a foundation for decision making into the next century and beyond.

 

 

6.0 Authors Information

Liza Casey, GIS Manager

Jim Querry, GIS Technical Coordinator

Louis A. Rodriguez, PE, GIS Coordinator

Patrick J. Thompson, GIS Specialist/Programmer

Marion Storey, GIS Manager

Robert Cheetham, GIS Programmer/Analyst

Kevin Switala, GIS Programmer/Analyst

Adrien Litton, Scanning Specialist

Kevin Ruggiero, Applications Specialist