Integrating GIS and Oracle for traffic analysis
A RDBMS was part of the City’s plan for upgrading existing data management systems and
modernizing record keeping. The City wished to move towards an organization wide approach
to managing information. Integrating a powerful GM and RDBMS system was a critical step
towards the goal of making information assessable. The City made the same type of strong
commitment to data management in respect to development tools, specialized staff and training
211.when it purchased Oracle in 1994. As with the GIS system, Oracle applications are distributed
over a network environment to multiple end-users. All databases with a GIS component will be
developed using Oracle.
Traffic analysis Applications
Development Issues
Bloomington has a rapidly expanding urban area. Several factors make it an attractive place to
live and work. Bloomington is in close proximity to a major metropolitan area and several
national and regional recreational sites. It is home to a major university with an enrollment of
30,000+. The University helps support an active cultural community and provides a strong
economic presence. The Urbanized Area population increased 13.2% from 1980 to 1990 and
population projections for the next 10 years indicate more of the same. (See Figure 2) Growth
has stressed the area’s transportation system and made planning issues more complex.
Year: 1990 1995 2000 2005
Population: 80,332 85,994 91,782 96,271
Figure 2: Population Projections for the Bloomington Urbanized Area
(Source: City of Bloomington Planning Department 1996 Bloomington Area Transportation Study)
The City of Bloomington Plan Commission is the contracting authority and the City Planning
Department is the designated staff agency of the Metropolitan Planning Organization (MPO) for
the Bloomington Metropolitan Planning Area. The Bloomington MPO consists of
representatives from local, regional, and state governmental organizations with interests in
transportation issues. MPOS are responsible for implementing the six management systems --
pavement, bridge, safety, congestion, public transportation, intermodal transportation, and traffic
monitoring -- required under the Intermodal Surface Transportation Efficiency Act of 1991
(ISTEA). A huge amount of information must be collected, stored, and retrieved in order to
fulfill ISTEA’s requirements for these management systems. The MPO’S organizational
structure necessitates continuous coordination of efforts and information across several entities.
Bloomington saw many benefits to using GIS to fulfill some of these transportation data needs:
- The Federal Highway Administration presents GIS technology as integral part of ISTEA
management systems.
- The City GIS already had a road network with attribute data including data from the Indiana
Department of Transportation (INDOT).
- Other map layers representing road edge of pavement, rail roads, bridges wherein place.
- ISTEA indicates that the MPO can be a funding source for GIS.
- GIS was a proven method for managing and displaying information associated with the City’s
utility networks.
The Bloomington MPO incorporated several GIS functions into its FY 1995 Overall Work
Program (OWP). The City’s GIS system would be involved in coordination and implementation
212.of the Roadway Pavement, Highway Safety, Traffic Congestion, and Public Transportation
Facilities and Equipment management systems.
The Planning Department uses third-party agreements for some elements of its work program
due to its limited staff. The City Engineering Department was the responsible party for several
elements requiring intensive data collection. A GIS Implementation and Coordination sub-element
called for digitizing or -- otherwise incorporating into map layers -- information related
to US Census data, Traffic Analyze Zones, Thoroughfare Plan, transit routes, traffic counts,
pavement management data, traffic signals, and traffic accidents. Figure 3 contains a summary
of end products and management efforts relating to GIS or geographically reference data for the
1996 OWP. All responsibility for GIS sub-elements fell to Engineering’s GIS Staff.
Traffic count map at end of each counting cycle
- Quarterly traffic counts
- Condition diagrams for critical intersections
- Database of accident reports by location, including an ongoing maintenance program
- Annual accident report for the Urbanized Area
- Data inventories of RR crossing and turning movement counts
- Digitized layers for transit routes and stops
- Coordination of intersection condition diagrams, RR crossing inventory, turning movement
counts, intersection capacity analysis and accident analysis information for the Traffic
Congestion Management Plan
- Implementation and coordination of a Public Transportation Facilities and Equipment
Management System
Figure 3: Summary of FY 1996 Overall Work Program Geographic Data End Products and
GIS Coordination Elements
Data Desire Process
City Engineering, Engineering GIS, and Planning established a working group to define and
coordinate data efforts for FY 1996. Plans focused on information pertaining to traffic accidents,
traffic counts, and intersection capacity analysis. The group looked for existing data sources
whenever possible and would rely on field collection when necessary. Previous work included
incorporating Census blocks and tracks, Traffic Analysis Zones, and the current Thoroughfare
Plan into GIS. Map layers and ancillary data for these components would be available through
the City’s GIS GUI. GIS staff would work on moving data to Oracle at a later time. The GIS
staff was responsible for working with the City’s Information Services Department to develop
Oracle tables and forms for managing the data. A goal was to provide the ability to view and
manipulate traffic data through a GIS interface or through an Oracle PC form application.
There were multiple benefits to using Oracle for the MPO’s traffic data. Because the City was
already developing Oracle applications in house, a consistent interface could be provided for
users to add, update, query and produce reports on information. Likewise, this uniformity could
be extended to those accessing information through a GIS GUI. Users could find and sort
records based on any available field or combination of fields. It is possible to move between
related data forms when additional information is needed even if this information was developed
for a different application. Oracle decreases the need to collect and maintain redundant
information. Master tables containing address and road network information from GIS already
existed in Oracle. The City developed standards concerning this information to increase data
integrity. Oracle traffic tables validate street names based on the master road database and when
possible, list-of-value pick lists were used to force consistency. As an end result, search and
report capabilities are greatly improved.
All traffic and transportation data would be gee-referenced to the GIS road centerline (RCL)
network and in some cases, other map layers created to display specific traffic features. The
Oracle traffic databases contain fields for street segment (RCL line feature tag) or intersections
(RCL point feature tag) to tie it to a road map feature. Using the current RCL network had
preference over creating additional map layers for maintenance reasons. Including the RCL
identifier allowed the possibility to connect to other road related Oracle information concerning a
specific street or intersection.
