Implementing a Traffic Volume Database for a County Transportation Department

Jeff Barnett

ABSTRACT

This paper presents a custom traffic volume database for the Kane County Division of Transportation. The Division is responsible for maintaining multiple types of traffic volume data including Average Daily Traffic volumes, approach volumes and turning movement counts for multiple time periods and from many different sources. Currently this is done using various hard-copy reports and maps. CH2M HILL assisted the Division developing a GIS solution to easily determine volume availability and quickly display data in tabular or map formats. The paper will present the development process from problem identification to implementation.


INTRODUCTION

The Kane County Division of Transportation (DOT) is in the process of developing GIS capabilities in order to more efficiently plan for and operate the over 300 route miles of roads under the county's jurisdiction. This has included a GIS-based safety management system, an Average Daily Traffic (ADT) database and various infrastructure databases. Based on the results of a GIS strategic plan developed by the DOT, automating safety analysis tasks and keeping track of the various traffic volume data were the initial projects undertaken. Developing a traffic volume database would compliment any safety application by providing a crucial component for calculating crash rates.

The safety management system designed for the county is comprised of a commercial off-the-shelf software package, Pd Programming Intersection Magic, and two custom ArcView extensions. Intersection Magic was selected to automate the creation of collision diagrams, a task county staff had previously been performing manually. The first ArcView extension provides a crash data entry form. This form provides an interface for entering crash data and performing quality checks before adding the crash record to the database. The extension ensures a valid reference intersection is entered for the crash record. This is required to properly geocode crash locations. The data entry routine automatically selects the appropriate intersection identification number for the reference intersection or prompts the user to select one if more than one intersection exists with the entered street names. The intersection identification number ensures the crash is associated with a single location since the use of intersecting street names to identify a location could result in multiple matches. The extension also checks for valid dates and times, checks crash severity codes against the number injured and number of fatalities fields; collision type against number of vehicles; light condition against time of day; and number of vehicle involved against the number of vehicle-specific data fields with entered data. These and other checks help ensure data entry mistakes do not find their way into the crash data record stored in the crash records database. Crash records are stored in a MS-Access database table and can be exported and shared with Intersection Magic. The second ArcView extension, an ADT database and tool to calculate and export intersection entering volumes, was developed to supply traffic volume data to the safety management system for calculating crash rates. This paper presents the components of the ADT database.

DEVELOPMENT CONSIDERATIONS

The county has multiple sources for traffic volume data. One source are the ADT maps published by the Illinois Department of Transportation every five years. These maps contain daily traffic volumes derived from count data mostly along state maintained facilities. The Illinois State Toll Highway Authority maintains ADT volumes for their facilities. These volumes are useful to the county where Tollway ramps intersect with county roads. The county also has implemented a program for collecting 24-hours of counts throughout the county. This program collects data on an annual basis, rotating count locations every year. Lastly the county is provided intersection turning movement counts as part of developer prepared traffic impact studies. If this data could be entered and stored in a centralized database and more readily accessible it could be made more valuable.

An ADT database was selected for development first because this data was the most complete for the county. This advantage was weighed against using more accurate and up-to-date but less widespread 24-hour count data or turning movement volumes. The completeness of the ADT data even with its inherent problems including age was attractive to the county in order to calculate crash rates at almost all intersections on the county road system.

The ADT database was designed to accommodate change at the county. The county was in the process of conflating road names from a TIGER streets layer to a street layer with improved horizontal accuracy. The DOT had plans to develop an even more accurate road centerline layer in the future. Since the county was actively modifying street layers and had plans for more changes, the ADT database was required to work with these changes. If data were attached as an attribute of the streets layer and a layer with substantially different street locations replaced the original layer, these attributes may not be easily transferred to the new streets layer. Additionally the DOT was not ready to implement a linear referencing system at the time of this application development. Therefore a system to enter, map and calculate intersection entering volumes from ADT volumes had to be developed that could be applied to different street layers without using dynamic segmentation.

ADT DATABASE

A three-part ArcView extension was developed for the ADT database: an ADT volume data entry dialog, an ADT mapping routine, and the third for calculating intersection entering volumes from ADT values. The ADT database was designed specifically to provide intersection entering volume data to the safety management system for calculating crash rates.

A system was developed to link data stored in a separate database to the streets layers. This system relied on a node layer to accompany the streets layer. The node layer was developed to represent all street intersections, end points and mid-block name changes. For each intersection node an identification number was assigned and the street name, direction and one/two-way designation was entered for each leg of the intersection. Intersection nodes were used in conjunction with the street lines to identify segments over which ADT values were assigned. This data could then be used to display the ADT values onto a streets layer using its corresponding intersection node layer. The displayed ADT segments could then be used to calculate intersection entering volumes.

Data Entry Dialog

An ADT volume data entry dialog was developed to facilitate entering ADT volumes into the ADT database. The user can enter an ADT value, date and source for a street segment identified by a street name and a from- and to-intersection identification number. The data entry routine checks to ensure the from- and to- intersections intersect the same street among other quality checks before being added to the database. This data is stored in a MS-Access table.

ADT Mapping Routine

The ADT volume data had to be mapped on a streets layer in order to calculate intersection entering volumes. The mapping step was key to a flexible ADT database. By storing the ADT data separately from the streets layer, street locations could be adjusted and the ADT data from the MS-Access table could be attached to the new streets layer using the mapping routine. This works as long as the intersection node locations are adjusted along with the streets layer. The mapping routine uses a series of queries to identify the from- and to-intersection and the lines representing the segment between these two intersections. The selected lines are copied to a new layer and the ADT value and date are added as attributes.

Calculating Intersection Entering Volumes

Once mapped the intersection entering volumes can be calculated. The intersection entering volume calculation routine calculates the entering volume from the ADT values on the lines intersecting at an intersection node. For each line representing a leg of the intersection the ADT is manipulated based on whether the road serviced one-way or two-way travel and the entering volume for each leg of the intersection summed together. The routine assumed a 50/50 direction distribution of travel for two-way streets. The result was a list of intersections and their entering volume in vehicles per day that could be shared with Intersection Magic in order to develop crash-rates.

FUTURE STEPS

The county is still in the process of implementing a more robust traffic volume database in a GIS environment. A turning movement count database is being considered. This database would allow automating signal warrant analysis tasks. As the 24-hour count program continues and counts are available for more roads in the county, these counts could be used to calculate intersection entering volumes. The actual directional distribution could be determined from the 24-hour count data thus improving the accuracy of the intersection entering volume calculations. This data is also more current and collected on a regular basis.

ACKNOWLEDGMENTS

The author would like to acknowledge Kurt Lebo and Carl Schoedel at the Kane County Division of Transportation for their assistance during the development of the applications described in this paper. Beth Fucile performed the majority of Avenue programming associated with these applications.


Jeff Barnett
Transportation Engineer
CH2M HILL
jbarnett@ch2m.com