Semisequicentennial Transportation Conference Proceedings
May 1996, Iowa State University, Ames, Iowa

A GIS-based Accident Location and Analysis System (GIS-ALAS)

Michael D. Pawlovich and Reginald R. Souleyrette
Center for Transportation Research and Education

The Iowa DOT has developed one of the nation’s best accident location and analysis systems, and its PC-ALAS program has been well received by users. With its pull-down menu structure, PC-ALAS is portable and more user friendly than its mainframe predecessor. Users can obtain accident statistics for locations during specified time periods. Searches may be refined to identify accidents of specific types or involving drivers with certain characteristics. Output can be viewed on screen, sent to file, or printed using pre-defined formats. However, PC-ALAS remains rather difficult to use. Location “node numbers” must be identified from cumbersome node tables or paper/CAD maps. In addition, the presence of a node does not necessarily indicate the existence of historical accident data. Further, the text-based PC-ALAS does not utilize recent developments in computer graphics and spatial access methods such as geographic information systems (GIS). This paper reports on the development of a GIS-based ALAS. With advanced spatial query and display capabilities, a GIS-based system could reproduce current capabilities and, with marginal additional effort, enhance query and display features. Custom data requests could also be provided. Such a system, or GIS-ALAS, includes instant graphical access, enabling viewing and selecting of desired network locations (nodes and links). Node numbers no longer need to be specified. Query results are displayed on a map or in a table, thereby creating more easily understood displays of inputs (queries) and outputs (statistics). And while there are many potential benefits of the GIS-ALAS, costs include time and effort required for system conversion, required purchase and training for the GIS software, and potentially slower data access times (yet to be tested). In this paper, after a discussion of PC-ALAS capabilities and limitations, GIS is presented as a technology wi th potential for enhancing the accident data retrieval system. A GIS-based design is then proposed and discussed, including choice of GIS platform, database design, and problem identification and resolution. The paper is concluded with a section on benefits and costs of using GIS-ALAS, and recommendations for future research and system implementation.

Interest in a user-friendly, fast, portable system for accident data retrieval and analysis is widespread. Several organizations have expressed a desire for a system that uses clearly defined inputs (queries) to create understandable outputs (statistics) in a timely manner. The outputs should be in the form of both graphics and tables. The Iowa Department of Transportation (Iowa DOT) Safety Division, developer of the current PC-ALAS (accident location and analysis system), considers a GIS-based ALAS (or GIS-ALAS) to be a natural progression of its current product. Members of the Incident Management Subcommittee for the Des Moines Metropolitan Area Intelligent Transportation Systems Early Deployment Study have suggested that a GIS-ALAS would be beneficial to their study by providing accident data quickly and efficiently. And the Iowa DOT GIS Coordinating Committee has identified GIS-ALAS as a pilot implementation of GIS technology at the department. In addition to the Iowa DOT, PC-ALAS is used by many local transportation agencies throughout Iowa. Among these are municipalities, county agencies, Metropolitan Planning Organizations (MPOs), and Regional Planning Associations (RPAs). PC-ALAS can be obtained by accessing Iowa State University’s Center for Transportation Research and Education (CTRE) Bulletin Board System (BBS). Using the BBS, agencies can download PC-ALAS and the accident information for their respective counties. CTRE’s Transportation Safety Circuit Rider also distributes the system.


ALAS began as a mainframe-based system used to retrieve highway accident information (1). The original system was difficult to use and costly, required significant training, took hours or days to process execution, and produced lengthy output that was difficult to understand. A need for a quicker, more user-friendly system was realized.


PC-ALAS, the personal computer version of ALAS, was developed to replace the mainframe system (1). Representing a significant improvement over ALAS (especially for access), PC-ALAS requires much less training and cost to use. And, since the system no longer needs to reside on the mainframe, local agencies can run the system directly. Local agencies get quicker response to queries, and requests to the Iowa DOT are reduced. However, the system remains rather difficult to use. For example, to request information for a particular location, a user must specify a PC-ALAS node number comprised of a county number, a congressional township number, and a unique node specification (e.g., 85141347 is Story County (85), township 14, node 1347). Currently, node maps (paper or CAD) must be consulted to determine the node numbers (literal descriptions are available for nodes along primary highway and interstate routes). The node number determination process is even more highly involved for complex requests such as node string requests. Each node in the node string must be identified and, at times, it is difficult to tell whether certain nodes are actually two ends of a link or not. For example, a link may have nodes 8084 and 8096 as end points, but node 8088 is between them. A user cannot determine from the paper maps whether there is only one link between the 8084 and 8096 or two. Identification of a large number of nodes is cumbersome and time consuming. Given the node number, a user may use PC-ALAS to obtain the number of accidents occurring at that node during a user-specified time period. Queries may be further refined to give more specific information, such as limiting the results to those accidents involving pedestrians. The use of maps or tables to determine node numbers is a key limitation of the PC-ALAS system. Tables include only the primary and interstate systems, and maps are numerous and complex. The presence of a node on a map does not necessarily indicate that historical data exist for that location. For example, a node representing a bridge constructed in 1994 will have no data for years prior to 1994. With the current system, the availability and applicability of historical data is difficult to ascertain. In addition, specifying nodes along a highway link is problematic and not always a straightforward process. Adjacent nodes shown on the maps may not, in reality, represent adjacent nodes along a link. Along an interstate, for example, grade separation nodes may be mistakenly associated with the crossing road and not the interstate itself.


GIS-ALAS is proposed to utilize geographic information systems (GIS) technology to manage the accident retrieval and analysis system. Within GIS, selections for the various queries can be made. While searches could be made within the GIS to improve operating speed, external programs (in this case FORTRAN code) are provided to use the query specifications and perform searches. For example, instead of referring to a paper node map for the node number, a user locates the desired node, link, or interchange and highlights it on screen in the GIS. Parameters for refining the search can then be added before sending the information to the FORTRAN code. Once the search has been performed, the FORTRAN code creates a text file containing data which the GIS may then import and utilize to create tables and maps displaying the query results. Progression to the use of GIS for ALAS seems to be a logical progression of the existing system. Use of location is key to transportation data integration (2). GIS effectively provides this integration capability (3). Since accident data are spatially oriented, managing the data using a GIS makes sense.


In the development of a GIS-ALAS, several considerations arise. These include dealing with large data sets, developing appropriate spatial relationships, providing for system portability, accounting for updates (including road network changes), linking the system to other systems and projects, and designing the system for adequate performance and response time. Accident information data files provided from ALAS are comprised of a wide array of variables. These range from vehicle type to date of accident to location. Within Iowa there are roughly 400,000 ALAS nodes, all of which have at least some accident information related to them. These two features (i.e., length and width of database) specify a very large data set. To provide manageable data sets, the Iowa DOT "tiles" ALAS accident information files by county. A GIS-ALAS would do the same. However, if an agency required data for the entire state, the memory requirements would remain large. Alternatively, the data could be aggregated by system, allowing for statewide queries of interstate, primary, county-secondary, or municipal records. The ALAS node maps currently are produced from AutoCAD. The maps, while informative, have no spatial information associated with them. Thus, though they can be overlaid onto road networks within a GIS, they cannot be used to locate or reference data. The AutoCAD units of resolution (UORs) can be utilized, using conversion factors, to create spatial coordinates for each ALAS node, and a database consisting of the node numbers can be tied to the graphics. GIS-ALAS portability is an important feature allowing distribution to local jurisdictions. Here, file size is also an important consideration. Although this should not be an issue for an agency already capable of running PC-ALAS with its hardware, GIS databases typically add overhead (and size) to data sets (e.g., a 2 megabyte text database may increase in size to 5 megabytes simply by incorporating it into a GIS). Another consideration would be the availability of the GIS software chosen for the GIS-ALAS. If an agency has a different GIS platform, data may be readily transferred, but any code developed within the GIS environment (for queries) may need to be rewritten. To reduce duplication of effort, most of the GIS-ALAS code will be written in FORTRAN, external to the GIS. The only code internal to the GIS would be query identification, exporting the information to a text file, initialization of the FORTRAN code, importing of query results, and production of tables, graphs, and maps. Only the internal GIS code would need to be rewritten. Road network changes affect users of GIS-ALAS. As the road network changes road network map layers need to be updated. Users would rely on the Iowa DOT to provide updated map layers, or they may update the map layers themselves. However, when updating the map layers, the Iowa DOT may designate new node numbers. Maps updated by users would not contain node number changes. To avoid this, users could request new node numbers and attach them themselves. Another potential problem with user updates is the development of two or more versions of the GIS-ALAS. The implications of this situation will depend upon the intended uses of the system (e.g., for resolving legal issues, it is anticipated that development and maintenance of a single system would be preferred). Currently CTRE has contracted with the Iowa DOT to perform several GIS-related projects. Using GIS and a base map, the projects may be related and information displayed simultaneously. For example, the pavement management system could display condition ratings for sections of pavement and the congestion management system could display volume-to-capacity levels on a single map. GIS-ALAS could perform a query and display the results on the map as well. Displaying all three types of information in the GIS provides a common base between the projects where plausible causal relationships might become evident.


Alternative solutions for ALAS improvement include updating PC-ALAS, rewriting PC-ALAS, utilizing a relational database, and creating GIS-ALAS. While this paper describes the development of GIS-ALAS, the other alternatives bear investigation. Again, the reader is reminded that the current PC-ALAS system has been well received by users. Updates to PC-ALAS to create a faster and more user-friendly system seem feasible. Developing code to enhance a user’s understanding of inputs and outputs would be straightforward (e.g., help screens, tutorials). Other PC-ALAS limitations could be addressed similarly. However, node maps would remain the primary method of determining node numbers. Rewriting PC-ALAS would not replace the use of node maps, nor would utilizing a relational database. Through GIS-ALAS the inputs and parameters selections would be more intuitive to the user. The outputs would be displayed on a map, making them more effective. Once current PC-ALAS capabilities are reproduced in the GIS-ALAS, many more enhancements are made possible by the geospatial environment.


Conversion of PC-ALAS

There are several tasks involved in creating GIS-ALAS. The PC-ALAS nodes must first be defined and registered in the GIS environment. Currently, PC-ALAS nodes are available in an AutoCAD format with no real-world spatial coordinates which are required in GIS. To create spatial coordinates, a node text file with county number, township number, node number, and the XY units of resolution (UOR) values may be obtained. The XY UOR values then may be extracted and imported into a GIS (e.g., MGE) which can create spatial coordinates corresponding to the UOR locations. Once created, these spatial coordinates can be used to create node points within a desktop GIS (such as MapInfo). Later, node information may be tied to these points. The next step is to identify the current capabilities of PC-ALAS. Once determined, they must be recreated in GIS-ALAS. To do this, links between nodes must be created within the GIS. These links do not explicitly exist in PC-ALAS. If an accident occurs between two nodes, both nodes are noted in the accident files (a reference node and a direction node). To create the links, the accident records for a period of time, say the past ten years, might be utilized to define links utilizing reference node and direction node information. Using the past ten years of data should enable a great majority of the links to be created; however, links that had no accidents over that period will not be created automatically and must be added manually.

Resolving Limitations

Next is determination of PC-ALAS limitations and incorporating solutions into GIS-ALAS. Once identified, the limitations may be corrected. The corrections will involve additional coding within the GIS as well as outside the GIS (e.g., FORTRAN code). Programs may be written to address the limitations identified above in addition to other limitations that may be identified later. For example, currently PC-ALAS cannot determine whether two nodes can be used to specify a link on a highway. Currently, even if a user accidentally chooses two nodes on different roads to specify a segment, PC-ALAS returns a valid answer (i.e., an answer of zero is returned) even though no link exists. A user may mistakenly believe that no accidents have occurred there during the period of interest. GIS-ALAS could use spatial information to ascertain the validity of a link request. Perhaps the most significant limitation, as previously mentioned, is the necessity of using paper maps to identify node numbers for the nodes/links in question. GIS-ALAS could graphically display node numbers and allow a user to locate a desired intersection and corresponding node number(s) on the screen. And, for updating the ALAS maps, GIS could be used to enhance the process of node entry as well. Currently, PC-ALAS produces reports that are difficult to use outside PC-ALAS. The report format produced requires modifications before the information is usable for other purposes. GIS-ALAS could be coded to produce better formatted reports for use in other software packages.

GIS Enhancements

Enhancements based on powerful GIS geoprocessing capabilities may be identified and developed in the GIS-ALAS. Graphical selection of nodes, links, strings of nodes, or areas meeting certain criteria is possible. Using the ALAS nodes and links contained within the GIS, a user may request the desired ALAS data. Queries may then be performed to extract the desired information. An additional enhancement is graphical display of results. PC-ALAS is entirely text based, including the graphs. A GIS-ALAS would be capable of using query results to produce graphs, map displays, and tables. In addition, any query result information would be easily exportable to spreadsheet programs which could produce more sophisticated graphs. The map displays could be customized to illustrate more clearly what the information shows and the tables could be modified to remove extraneous information or be formatted to a user’s preferences. Finally, user-defined queries could be created within GIS-ALAS. For the user-defined queries, the ALAS node information and accident information files need to be contained within the GIS. The GIS would enable a user to access the accident information contained within the GIS.

System Evaluation

As a final task, GIS-ALAS should be compared to PC-ALAS. Measures of performance must be devised to evaluate the gains realized by creating the GIS-ALAS as opposed to remaining in the PC-ALAS environment. And, while GIS-ALAS features that reproduce PC-ALAS capabilities would be relatively straightforward to quantify, it should be noted that many of the benefits of the GIS-ALAS would depend on the user’s needs, capabilities, and interest.


Currently, GIS-ALAS is being implemented only on a test level. ALAS nodes have been created within the GIS (Figure 1). A coding effort has been initiated to replicate current PC-ALAS capabilities. An example of the envisioned GIS-ALAS product is illustrated in Figure 2. While the GIS-ALAS is not without costs, particularly those associated with data conversion and initial coding, an immediate GIS-ALAS benefit would be an increase in user-friendliness and intuitive access to data. Paper maps would no longer be required as the source of node numbers. Links would appear as links on the map display, and awkward link specifications would be obsolete. Nodes and links could be selected without having to input numbers derived from a complicated numbering scheme. Selections could also be made on multiple locations simultaneously. A final benefit will be an improved understanding of inputs and outputs, potentially resulting in better analysis and decision making.


  1. PC-ALAS User’s Guide for Version 2.3. Iowa Department of Transportation Engineering Division Transportation Safety, December 1994.
  2. Z.N. Hans and R.R. Souleyrette. GIS and Network Models: Issues for Three Potential Applications. Journal of Advanced Transportation, Vol. 29, No. 3, pp. 355–373.
  3. Transportation Research Board. Adaptation of Geographic Information Systems for Transportation. National Cooperative Highway Research Program 359, Washington, D.C., 1993.

CTRE is an Iowa State University center, administered by the Institute for Transportation.

Address: 2711 S. Loop Drive, Suite 4700, Ames, IA 50010-8664

Phone: 515-294-8103
FAX: 515-294-0467


Iowa State University--Becoming the Best