The goal of this paper is to describe a method for using ArcInfo's dynamic segmentation data model and well-defined event tables (e.g., number of lanes, facility type) to create inputs for building a simplified highway network for a travel demand model. Once the model has been run on the simplified network, the output data (e.g., volume, time, speed) can easily be reattached to a geographic road base. This allows for the travel model data to be analyzed and displayed based on the correct spatial geography. In addition, because event tables store data in a non-redundant, reusable, stable, and flexible format, the data used as inputs for the modeling process can also be used for a number of other processes without time consuming conversion or duplication of effort.

Transportation planning organizations of metropolitan areas are responsible for providing technical information to decision makers regarding future demands for large, capital intensive transportation projects. As a result, these organizations keep track of existing transportation facility data, such as the number of lanes or facility type of a particular road. In addition, planners must evaluate proposed future projects based on their probable effectiveness in satisfying projected demands for transportation within the region. The travel demand model is the primary tool used to forecast future traffic volumes and conditions on existing and/or planned transportation facilities.

Simplified representations of real world highway and transit networks are used to provide the model network with information regarding the supply of transportation. Similarly, the model takes into consideration the distribution of these facilities and services over space, as well as, demographic and socioeconomic data forecasts to assign information on the location and intensity of future activity or demand. This activity is allocated to Transportation Analysis Zones (TAZ). In the model, TAZs are represented as points, or centroids, which connect into the model network via zone centroid connectors. Attributes describing detailed characteristics of the transportation infrastructure must be coded onto the appropriate components of the model network. These attributes include, but are not limited to, facility type (e.g., freeway, expressway, principal arterial, minor arterial, collector, and centroid connector), area type (e.g., CBD, fringe, urban, suburban, rural), number of lanes, and distance. In general, once the model input files (i.e., highway network, transit network, and demographic data) are coded with the appropriate information, the mathematical models, which make up the travel demand model, are used to replicate the transportation system. The basic model consists of the following parts:

• Trip Generation
• Trip Distribution
• Modal Split
• Assignment

This structure mirrors the sequence of decisions faced by travelers:

• Whether to make a trip
• What mode to use
• What time of day to travel
• What route will be taken

Basically, Trip Generation forecasts the number of trips that will be made. Trip Distribution determines the zone-to-zone travel volumes. Modal Split determines the amount of travel that will take place on each available mode of transportation. Highway and transit assignment models are used to estimate the volume of travel on each individual component of the transportation system.

Although model inputs for varying software packages are basically the same, this process has been developed in conjunction with MINUTP file standards. In addition, it should be noted that travel models are often customized and do not always use the same attributes or attribute definitions.

Historically, data regarding characteristics of existing roads and future projects has been managed in duplicated or redundant formats. For example, this data may have initially been managed as a text file, spreadsheet or database. However, before the data is used in a model network, it must be re-entered, or coded, into a format that can be understood by the model. Finally, in order to analyze, visualize, and report model output, the model data must be converted into a format that can be understood by a GIS. (Figure 1)

Because moving data from one format to another requires a significant amount of time and resources, it is desirable to store data in such a way that facilitates the data's accessibility for various uses. Once this data is organized appropriately, it can be manipulated and processed using GIS and database tools to create files that are required as inputs for the model. After the model is run for a given scenario, the results can easily be displayed on a spatially correct GIS coverage. Finally, the data can be projected into a normal, relational database format to insure data accessibility, flexibility, and integrity.

ArcInfo's dynamic segmentation data model allows linear referenced data, like the number of lanes or facility type of a road, to be stored in a normal, relational database structure outside of a GIS. This paper will first describe the necessary dynamic segmentation components used in this process; a geographic road network, a route system, and event tables representing model attributes. Next, the paper will describe how these event tables can be merged into one, spatially correct highway network that can be edited using ArcView or custom Avenue tools. Subsequently, the paper will introduce a process for generating a simplified, "stick figure" highway network as a model input and, inversely, a process for attaching, or "loading," model output data back onto a spatially accurate road network. Finally, a process will be explained for converting and segregating this "loaded," Arc coverage into an event table structure for each entity (Figure 2). Along the way, common model/GIS issues will be addressed including directions, interchanges, and zone centroid connectors.

As an early phase in developing this process, information was gathered regarding how others in the industry are using GIS and dynamic segmentation to code or manage model network data. The basic findings of this small survey were that organizations have used different components of GIS and dynamic segmentation for different portions of their model editing and data management procedures.

In general, other organizations have created or edited model highway networks as an arc road coverage in ArcInfo, as a route system in ArcInfo, or as a "stick figure" network in the model's native editing environment. Many creative techniques have been developed to convert various formats of model data onto a spatially accurate GIS coverage using elements of dynamic segmentation. However, no processes have used event tables as the source data for building model highway networks.

Several characteristics make the process described in this paper unique. Perhaps the most significant characteristic of this process is that a simplified highway network can be created by the GIS, based on unique events, that can readily be displayed on a spatially correct GIS road coverage. All of the highway network data, like number of lanes, is stored as separate event tables in a database. This means that attributes can be assigned with limits that occur anywhere on an arc, not just at existing nodes. As a result, the event, or attribute, defines the model link. The link does not limit the extent of the attribute. As later sections explain, this method for storing data creates a flexible environment which improves data editing, accessibility, and integrity. However, in order to set up this data storage environment, an initial investment in time and resources must be spent in preparing the core components of a working dynamic segmentation system.

There are three primary components required when using dynamic segmentation.

• Arc-Node Topology
• A Route System
• External Database Event Tables

The arc-node topology is built upon an internal ArcInfo file; the Arc Attribute Table (AAT). The AAT describes the arc, including the from and to nodes of the arc, the length of the arc, and the unique ID of the arc. The AAT can also have hard coded attributes such as road name and address information. To add functionality and flexibility into the described process, the AAT must not contain erroneous road name attributes or topology.

First, a physical clean up of the arc-node topology must be done to insure linear connectivity. This is done in ArcInfo and consists of cleaning the coverage, visually checking dangle nodes, and correcting overlaps and other connectivity problems. Because the route system uses the arc coverage and will be used for creating model networks including future year scenarios, proposed roads must be digitized into the coverage and flagged as proposed. A flag is also added to the AAT defining whether or not to include the arc in the model route system. This is done partly because the road base coverage includes all facility types of roads, while the model network only requires a subset of these roads (i.e., collectors and above), as well as a roads proposed as future projects.

After the physical clean up of the network the road name attribute data must be checked. Road name conventions must be chosen and all arcs must comply with the conventions. This will insure that the limits of the event data along the route may be described using the road name of any road in the arc coverage that intersects the route. Again, to add flexibility, it is recommended to parse all road name data (i.e., an item each for prefix, name, and suffix). Included with the road naming conventions must be naming conventions for interchange ramps and for one-way pairs which have the same road name but are physically two arcs. There may be a need to add alias road names to new fields if the legal road name is different than the commonly known name.

A route is a linear feature on which attributes (events) can be located. The Route Attribute Table (RAT) and section table, define the route system. The RAT has a one-to-one relationship with the route and contains the route ID or name. The section table is the intermediate table connecting the RAT to the AAT and gives the route measures. In most cases, the section table has a one-to-one with the AAT.

After the laborious effort involved with cleaning and checking the AAT, the creation of the route system is easy. The route system is built in bulk based on road name, or a redefined item using prefix, name and suffix. Only the links flagged to be included in the route system are included. The route measures start in the lower left position, following standard surveying logic, South to North, and West to East.

It is important to note that the event tables are not part of the coverage and not hard coded to the arc. These events are simply attributes that can be tied to the route system based on measure. Events can be point data such as accident data or linear data such as number of lanes. The event tables are in normal form and there are four required fields in each; route id, from measure, to measure, and the data item(s) or event(s). The model network items such as facility type, number of lanes, and toll penalty are all separate event tables. For directional attributes, such as number of lanes, there are two tables maintained.

There are several fundamental problems that arise when moving linear referenced transportation data between software packages. As described in Figure 2, the process defined in this paper stores transportation data in a database, converts the data into a GIS format for processing, translates processed GIS data into a model format, and performs a final conversion to create event tables from the model's output data. During these conversions, problems arise because the data models' of each software package handles specific data concepts differently. Examples of these data concepts include the treatment of directional attributes, the meaning of nodes at arc intersections, and the idea of local road representation (i.e., centroid connectors). The following sections elaborate on these problems and offer solutions.

Direction is an issue with the overall process because there are attributes that differ depending on the side of the road. The GIS maintains one arc for link AB. The arc has a direction defined by the from node (FNODE#) and the to node (TNODE#). The arc direction, or FNODE# and TNODE#, is the result of the direction that the arc was digitized. For arcs, attributes for different sides of the road are maintained in different fields, but in the same record (2 directional fields for one link). In comparison (Figure 3), the model network must have one link per direction between nodes; link AB and link BA. In this case, attributes for different sides of the road are maintained on their respective links records in the same field (1 directional field for 2 links).

Editing in the native model environment is straightforward, as there is a one-to-one relationship between the AB and BA link. Direction is known because editing is done on one and only one link; AB or BA. Editing in the GIS, on the other hand, consists of editing database event tables. The event tables are tied to the route system with route measures. The measures define the distance along the route. The measure always ascends from the starting position of the route. Based on these measures, each event is flagged with a directional indicator.

The GIS road coverage and events used to define the model network require clean topology. Therefore, all arcs in the coverage intersect causing connectivity that may not exist. In the real world there are roadways that do not intersect such as overpasses and underpasses. Because of this, a process was developed to select those prohibited turning movements.

The process to identify prohibited turning movements uses a polygon coverage to select the arcs of those roadways that should not cross in the real world. The selection process is run before the model network files are produced and a turning penalty file is made. The turning penalty file is made for all "A-to-B-to-C" turning movements that are prohibited in the real world (Figure 4). Note that A-B-D and C-B-E and vice versa are allowable. The turning penalty file is a model input file as well. The polygon coverage can be modified by the editor of the network for cases when adding or deleting these selection polygons is needed.

TAZ Centoid Connectors

The GIS road coverage consists of all roads, including local roads that are not literally used in the model. In the model network, local roads are represented as centroid connectors and their function is to allocate trips to and from the highway network. The TAZ is a polygon feature in the GIS and a point feature in the model. In the initial coding of the routes, no routes were made for which to define centroid connector events. This is primarily because centroid connectors are representations of all local roads in the TAZ. A second reason is that the location where the centroid connects to the network changes between scenarios.

In order to incorporate centroid connectors into the data model, the location where the centroid connector connects to the route is stored as a point event in an event table (Figure 5). The event data stored is the TAZ number. Using general travel demand modeling rules, the distance of the centroid connector is determined based on the area of the zone. Lookup tables exist to store speed and speed penalties based on the area type of the TAZ. Using these lookup tables and the centroid connector event table, all of the attributes for centroid connectors can be calculated and output to the files needed for the model network. For a visual arc to appear in the edit environment, the coordinates of the event and the coordinates of the TAZ point are used to generate a temporary arc. The model generated data is then joined to the centroid connector event table.

Traditionally, custom editing applications that are created by model software developers, are used as the main tool for building, editing, and visualizing model networks and data. MINUTP's native editing software is NETVUE. While NETVUE is a handy editing device for "stick figure" model networks, it lacks significant functions that exist in GIS. For example, only one link can be selected or edited at a time. In addition, common GIS spatial analysis like, overlaying multiple geographic coverages and comparing several network scenarios, cannot be performed in NETVUE. Furthermore, as this software was created primarily for editing simple, "stick figure" networks, spatially accurate visualization cannot be achieved, thematic displays of data are poor, labeling is inflexible, and plotting capabilities are difficult to use. Also, as NETVUE was not created to manage data, querying and managing data is difficult. To add flexibility in working with model networks, the data is managed differently and GIS has become the primary tool for editing and analyzing the network.

Because time was taken to clean up (i.e., parsing, spelling, consistency checks) the road names in the ArcInfo road coverage, legal and alias road names were used to create the routes. By intersecting these routes with all roads in the coverage, points can be generated which contain information regarding the measure along the route they occur on, as well as the road name and alias of the intersecting arc. Essentially, this means that a point event table can be made which acts as a Road Name/Measure Equivalency Table (RMET). As a result, a user can specify the limits of a linear or point event using legal or alias road names or offsets from these names. This significantly improves editing and selection capabilities when coding model networks. In addition, the RMET facilitates the conversion of any data with road name limits into event table format by adding route measures to each limit. While the RMET enhances database capabilities, the nature of dynamic segmentation combined with ArcView and Avenue tools, enhances the visual editing environment. For example, GIS editing tools allow the selection of a chain of links which can be edited concurrently, by direction. In addition, the user has several choices of how to select data; point-and-click, select shortest path between links, or query using actual road names. Furthermore, in GIS, global changes or corrections can be made on several networks simply by editing common links in multiple, overlaid networks.

As mentioned above, event tables for each model attribute are organized as separate event tables that can be accessed by this model network building process or any other GIS/database application. The maintained event data is in normal form and does not relate one-to-one with the network links, or to other event data for that matter. Therefore the events are overlaid and intersected to form the one-to-one relationship needed for the model network. From this event table, an ArcInfo coverage is created. The cleaning of this coverage creates network links between all intersected events and at all physical breaks such as roadway intersections.

To accommodate for MINUTP's data structure, the following modifications are made to the coverage. In MINUTP the zone centroids are required to have sequential numbers and must start with the number one. This requirement creates the need to add two new items to the coverage; ANODE and BNODE. ANODE and BNODE are calculated from the FNODE# and TNODE# of the ARC coverage. The use of ANODE and BNODE insures that the centroids will always be numbered 1 to X and all other node numbers will be greater than X. Because MINUTP uses integers and the coordinates are restricted to a range from 1 to 32767, the ArcInfo coordinates are recalculated to new items XCOORD and YCOORD in a usable format. The result of this process is the coverage that is used to build the model network.

For every one link in the ARC coverage two links are output for the transportation network. If the link attributes are a directional attribute such as number of lanes, they are automatically flagged with a directional indicator in the event tables. This determines whether to output the attributes on link ANODE to BNODE or link BNODE to ANODE. The directional indicator is also added as a new attribute on the model network links. This is done so that the model's generated directional attributes will be correctly joined and represented when brought back into the GIS.

There are two text files used by MINUTP in building a model network, an XY coordinate file containing the XCOORD and YCOORD attributes, and a link attributes file containing all of the attributes. The XY coordinate file is optional and only created so that, if needed, a "stick figure" map can be displayed. Both files contain the ANODE and the BNODE for joining the files together. In order for the attributes generated by the model to be joined back to the event table, the ARC_ID is also output to a new attribute in the link attribute file.

Upon completion of a model run, the attributes are still in one-to-one, AB/BA format. Using the ARC_ID and the directional indicator, model data can be joined back to the arc coverage. Each new model item is then aggregated together and split into its own event database containing the following attributes: route, from measure, to measure, event, and the directional indicator. The normalized event data for building the model network and the data that was generated by the model is now available in the database and in GIS for other applications.

There are three major pieces to this puzzle, the data being stored in the database as event tables, the model needed for the specialized and complex mathematical models, and the GIS needed to bring the process together. The data from the database is used to build the model networks and the data from the model networks is then made into event tables. Once this cycle is complete the GIS can be used to perform analysis with the data, make maps with spatial accuracy, and compare network scenarios. On the database side, queries and reports can be performed on the data that actually made the model network. From a data management perspective, the model source and output data is stored very efficiently and without redundancy in other platforms.

April 2, 1998
Prepared for the Eighteenth Annual Esri User Conference
San Diego, California
July 27-31, 1998

Dustin W. Montoya
GIS Specialist
Denver Regional Council of Governments
2480 W. 26th Ave. Suite 200B
Denver, CO 80211-5580
Telephone: (303) 480-6737

Kevin L. Thomas
GIS Specialist
Denver Regional Council of Governments
2480 W. 26th Ave. Suite 200B
Denver, CO 80211-5580
Telephone: (303) 480-6775