Valerie Raybold Yakich

GIS as a Gateway to Analysis of Accident Patterns -
Creation of a Geographic Integration Application

Abstract

As the South Dakota Department of Transportation (SDDOT) and local Planning Districts work to complete an extensive set of road network information (using GPS), applications are being developed to take advantage of the new resource.   This presentation will walk through the process of creating one such application for the Office of Accident Records.   The new application integrates the GPS road network, a legacy database, multiple relative coordinate systems and an existing analysis program.   This paper may assist other agencies in planning and implementing their own applications using GIS as an integration technology.

This paper documents a successful example implementing GIS as an integration technology.   It aspires to provide guidance to developers considering similar projects.

Goals:

SD DOT maintains and improves the safety of South Dakota streets by analyzing traffic accident patterns, identifying hazardous locations, researching the sites, and proposing solutions.  They rely on maps, textual summaries, collision diagrams, and original police accident reports to assist in the identification of hazardous areas in need of remediation.   Procedures for creating analysis material previously called for an extensive time commitment from Accident Records’ personnel.  Accessing accident data required referencing information by a set of relative county coordinates.   Transportation and GIS staff initially defined the following goals for a development project:

Phase Division:

The Accident Records office of SD DOT frequently creates and uses map overlays, collision diagrams, and summary pages when they study accident patterns at a given intersection.  Map overlays visually identify clusters of accidents.   Collision diagrams visually depict the directions of travel for each accident at an intersection and are labeled with dates and accident identification numbers.   Summaries quantify certain aspects of the accidents at a given location (for example, severity of accident, time of day, road and weather conditions, and driver contributing circumstances).  These analysis tools support informed decisions on where and how to focus prevention and remediation efforts.  Before beginning any application development to the improve speed and quality of the analysis tools, this project was fully defined and divided into the following manageable phases:

Phase I - Accident Maps 

Previously the only method of creating maps indicating the frequency of accidents at intersections involved running a batch mainframe process to create transparent overlays for hard copy county or city maps.  Numeric values on the overlays identify the number of accidents at any given intersection.  The area shown and the scale chosen for each map are predetermined.  Accident Records maintains their own set of maps and independently updates them with new streets.  Each map is used to determine custom county coordinates for locating accidents.  Whenever an Accident Records employee creates collision diagrams or summary reports using mainframe programs, he/she must first reference a paper map to find and then enter the relative county coordinates.  The project team decided on displaying the quantity of accidents at intersections as a visually appealing first step in the development project.  The integration required to implement phase one could be accomplished in a relatively short period of time.  Meeting the deadline for completion of the first phase was deemed critical to the continuation and success of the project.

Phase II - Intersection Collision Diagrams 

Personnel in the Accident Records Office have used Intersection Magic™ software for years to speed the process of creating collision diagrams for a concise view of the number and car positions of accidents at a given intersection.  Intersection Magic was not designed for referencing accidents by relative county coordinates; however, Pd’ Programming® modified it with custom scripts allowing South Dakota users to perform ad-hoc queries.  The queries use a bounding box of coordinates, user defined date range, county number, and filter to select only accidents listed as “in the intersection” or “intersection related.”  The process consumes time because the user must first identify the intersection on a paper map, approximate the location coordinates, and then enter numerous parameters into the program.  The diagram did not inherently "know" the county name, city name, or intersection name.  The user had to type all those values into comment boxes for each diagram.   Users working with a number of intersections sometimes spent all day just typing in parameters to create intersection diagrams.  Such extensive procedures were not particularly efficient or user-friendly.  Phase two sought to remedy the situation by allowing users to create familiar diagrams with one mouse click at the intersection of any two streets.

Phase III - Intersection Summary Pages 

Prior to development of the accident records application, summary reports were entirely alphanumeric.  These three page reports essentially contained the desired information, but users misinterpreted how certain values were calculated.  The old procedure for creating a summary report included entering bounding coordinates for the desired area, as well as date range, and title information.  The procedure was time intensive for the user and, as with collision diagrams, it was necessary to first determine relative county coordinates.  Access to mainframe data and the reporting scripts was limited by network connectivity and familiarity with the mainframe environment.   Replicating (and enhancing) summary reports for the project interface became phase three.

Implementation:

Having established goals and clear phases, the project began in earnest.  Below are some of the priorities that kept development running smoothly and built the foundation for future enhancements:

Management Support - Users and developers sold managers on this project early by stating exactly how the project would proceed, clearly defining expected benefits, and establishing self-imposed deadlines.  Presentations to management focused on time savings for current state empoyees and the ability to expand the utility of available data with an intuitive GUI (graphical user interface).   Metrics, such as current and anticipated time requirements and anticipated costs, provided managers with sufficient information to decide whether or not this project should be implemented.

Audience - Understanding the audience, primarily transportation engineers, and expected data uses drove the form of interaction required.   This is a technologically savvy group who wanted simple custom tools for common actions, but who were unlikely to be daunted by the fully flexible ArcView application.   These users were already familiar and happy with software from Pd'Programming, so ArcView scripts simply set necessary parameters and called Intersection Magic to create collision diagrams.

Cooperative Design - Cooperative design among users and programmers assures that the final product benefits from the experience of all the individuals involved.  It also virtually guarantees that the users will effectively take advantage of the resulting application.  SD DOT employees thoroughly understood their data.  Developers have training and experience in designing efficient code.   Regular communication and prototyping made a powerful combination from a team of individuals with varied backgrounds.

Modularity - Good programming style allows for the reuse and extensibility of code.  Modular scripts using parameters rather than global variables meant that code pieces could easily be reused or enhanced.  For example, numerous charts on the summary page were created using a single charting script with parameters for the title, the field to be charted, values associated with each label, and whether an "other" category should be included on the chart. 

Plan Ahead - Consideration of future development saves programming time.  For example, phase one only required mainframe extraction of intersection accident counts; however, all the data (excluding information restricted for privacy) was pulled out into an externalled INFO format that simplified creation of summary pages in phase three.  Although this application primarily intended to benefit state employees, an intention to eventually distribute this tool to municipal and regional governments drove the early decision to replicate mainframe data as text rather than  in a relational database product.

Results:

The completed ArcView application contains custom menus, buttons, tools, and dialog boxes.  Customizations build upon the initial ArcView interface; so all the original functionality of this powerful GIS system is still available.  Added menus and buttons allow quick access to specific functions for daily activities.  Users can view and print maps, collision diagrams, and summary reports from a single intuitive interface without ever referencing relative county coordinates or accident identification numbers.  This application is designed to be immediately useful, allowing sequential creation of multiple summary reports, collision diagrams, or accident report prints by selecting the names of the intersections from a list.  The mapping functionality becomes possible for counties as data collection procedures progress.  Although familiarity with ArcView software gives the user great flexibility, a user guide details simple steps for creating each of the analysis tools discussed.

Accident Maps are dynamically created county data views, which may be easily customized.  Scale and page size can be adjusted.  Any useful extent can be mapped, instead of having to create a single map of an entire county or city.  Users can zoom-in to a focus area.  The maps intuitively identify problem areas.  Symbology was specially chosen to reasonably print either color or black and white maps.  Through digital mapping technology, maps are not only more flexible, they can be made more widely available at limited costs.  The accident map views provide a gateway to the other analysis tools in this application.

Intersection Collision Diagram creation is now greatly simplified.  No longer must a user be familiar with the relative county coordinate systems.  The user defines a standard collision diagram in a point-and-click environment.  The locations (intersecting street names) are clearly identified on the diagram, coordinates are consistent with those determined by Accident Records to be most useful, and the danger of typographic errors is eliminated.  Additionally, the user can quickly sort intersections on the name of the intersection or the number of accidents.   One of the most useful features of the interface is the ability to create multiple diagrams with limited user input -- just select the intersections, request the diagrams, and move on to other analyses.

Intersection Summary Page creation is nearly identical to that for collision diagrams.  No longer must the user switch between Intersection Magic in the LAN environment and mainframe requests on the mainframe to get both analysis reports for a particular intersection.  The whole process is integrated into one extendable application.  The user selects intersections and then presses a button to create summary reports.  Consideration to the usability of the summary pages resulted in a redesign of the reports.  The most accessed chart in the report moved from page three to the beginning of the summary.  Working closely with the users facilitated reducing the summary to a single page without losing any required information. 

Conclusion

Concisely: this project fulfilled the original goals.  The application saves considerable time for users analyzing more than one intersection in a county.  The time saved is better spent determining remediation strategies.  Even before the intersection maps become available for certain counties, users save time by selecting from a list of intersections to view and print collision diagrams and summary pages.   The interface reduces the complexity of creating analysis packets that aid in analyzing the quantity, types and conditions associated with intersection accidents.   Managers, law enforcement officials, and local traffic engineers simply choose the county, choose the intersections and request analytical information.  This project serves as a successful example upon which DOT and other departments at the State of South Dakota hope to build.

Acknowledgements

I readily extend my thanks to Creighton Miller, Larry Dean, and Cliff Reuer for great support in not only accepting, but welcoming the change this application makes in their work-flow.  They proved themselves a great resource regarding existing data and procedures as well as visions of how and to whom this application would be useful.   Thanks also to Janet Deibert who provided invaluable constructive criticism and scripted programs to extract mainframe data into custom file structures.

Author Information

Valerie Raybold Yakich

AmBit Technologies
Senior Staff Consultant / GIS Specialist
to State of South Dakota
Bureau of Information and Telecommunication
523 E Capitol Ave
Pierre, SD 57501

(605) 773-5688