A Geographic Information System (GIS) is a combination database, graphic, and spatial analysis tool. The data maintained in a GIS is typically in three forms: point data, such as an intersection or accident location; linear data or arcs, such as street or river segments; and areal data or polygons, such as political or traffic analysis zone (TAZ) boundaries. Each of these data forms can have descriptive or quantitative data related to the geographic attribute, i.e., the polygon can contain total population or housing units by census block, street attributes can maintain speeds limits and traffic counts, and point data can describe the type of intersection (4 way stop) or accident (disabling or fatal).
What separates most GIS's from other types of mapping systems is the ability to perform spatial analyses. A CAD is a mapping system, yet most, if not all, lack the ability to perform spatial overlays, grid analyses, dynamic segmentation of roadways, or connect map features to a relational data base. Most popular GIS software packages can perform network analyses such as allocating resources along a route (transit planning) or determining the probability of interaction between points (market share analysis). However, a GIS cannot assign traffic volumes to links or road segments. The gravity model in the most popular GIS's is simply not sophisticated enough to model traffic flows or assign volumes to links.
Because most administrative jurisdictions maintain a lot of spatial information beyond that needed for traffic analysis, they have developed GIS's for these other needs. Many jurisdictions developed GIS layers and databases from locally gathered sources (parcel maps) or from TIGER files available from the U.S. Bureau of the Census. The advantages of TIGER files are cost and availability. In a very short time a city or county can process the TIGER and census data to create a crude, yet useable, GIS. The question is whether or not TIGER files (roads) or road center line files are suitable for a transportation model. The answer is no, most are far too detailed for traffic modeling purposes. However, GIS road layers can be used for traffic modeling if they are suitably prepared. Extraneous roads must be removed, link attributes such as speed, functional class, or number of lanes must be input, and the proper connectivity/geometry established.
The best transportation models at this time are built through a judicious use of a street network, including those links which will most likely carry real traffic flows. Furthermore, vehicle traffic must originate and destine in appropriate places. Census tracts are often poorly situated for use as TAZ's, because they are often bounded by the very roadways which TAZ's should surround. Some of the strengths of a GIS for transportation modeling include its ability to store land use and population data by TAZ structures which can be used as inputs to the modelling process, high quality cartographic output, integration of the traffic data with other layers in the system (land use, utilities, transit, population), and even a connection to air quality models.
To take advantage of the power of a GIS and traffic model, the obvious step is to pass information back and forth between the systems. An automated linkage between the two systems would yield significant advantages in productivity and quality of the analysis. A GIS can provide TMODEL2 with all the model inputs: land use, link (speed, lanes, volumes, etc.), and node attributes. TMODEL2 can in turn supply a GIS with data concerning link and node volumes. This requires establishing a common network with an identifier in both the GIS arc/node coverage and TMODEL2 link/node files. Through this common identifier data can be easily passed between the two systems.
The GIS may have several arcs (links) that must be combined into one transportation planning model link. This is because TMODEL2 requires relatively few shape points for its link network. Conversely a GIS relies heavily on these shape points for graphic display. It is important to remove as many shape points as possible in the GIS road coverage before exporting the link network to TMODEL2. Failure to pass a clean network to TMODEL2 will require a considerable amount of editing to reestablish the connection between the two systems. A unique identifier system is also used for the nodes.
The actual exchange of data is simply a matter of exporting the GIS arc/node file and reimporting the TMODEL2 forecast volumes by file transfer. The arc and node X-Y coordinates in the GIS may need to be edited so they work within the TMODEL2 structure. This is an easy process with most major GIS packages. Once the data is passed out of the GIS, the absolute coordinates no longer matter. What is important is that the common identifier is maintained in both TMODEL2 and the GIS to allow the link/node attribute data (input) and volumes (outputs) to connect to their proper road segments.
By keeping these unique identifiers, the transportation planning model link and node structure can be revised, and the ability to exchange data with the GIS is retained. It is important to document the agreement with the GIS manager which describes the procedures you both will follow to update data when links or nodes are added or deleted.
We are implementing an import/export module in TMODEL2 to allow the transfer of data between the two systems when the identifier numbers match. The primary connections that are foreseen for this process are to obtain basic network data such as functional classification, roadway type, number of lanes, 1 or 2 way, speed limit, other capacity constraining features, and traffic volume counts.
When importing one-way streets, use caution; many GIS systems are not concerned with directionality. There may also be semantic difficulties concerning the number of lanes in a street versus those in a directional link. The primary data we expect to be exported to the GIS are forecast volumes. These volumes can then be displayed using the GIS graphics and can be used as a layer with the other spatial data when analyziing the impacts of change.
Another approach implemented in TMODEL2 is to use data such as the census TIGE files to display background maps of roadways or census tract and block data in the network graphic editor. You may then insert nodes and links to build a network on the screen over this existing system of geographic reference features. Of course, you still will need to enter the link and node attribute data for the streets and intersections. We have found that in many cases it is quicker to enter this data using the buffer command than it is to import it from GIS or other sources and then "clean" it for modeling purposes. You would still have to devise a method, such as unique identifiers, of transferring the resulting data to the GIS, if that is desired.
Most of us pay an inordinate amount of attention to the network when the land use is what really drives the model. The more detailed the zone system, the more critical the accuracy of the land use. GIS's provide the capability of compiling data on the land use and future zoning buildout for the model TAZ system.
Typically, collecting the base year land use data is the major time constraint in beginning the calibration process. Many planning departments have been developing address or parcel based land use inventories which can serve as data sources. Generally, as a planning department acquires parcel based coverages they no longer use TIGER files. However, in order to utilize the 1990 census data the administrative component of the TIGER, census tract/blockgroup/block, must be maintained. This provides a ready resource in addition to the base year land use data.
[This article was prepared by TModel staff with generous assistance provided by Dr. Mike Vachon of the Yakima Valley COG.]