ABSTRACT
This paper describes the practical application of a linkage between MINUTP and ArcView regarding network development and maintenance. MINUTP networks can now be converted into a set of shapefiles that can subsequently be imported by ArcView. This linkage is composed of two parts: a shapefile conversion utility for MINUTP networks and a set of tools that facilitate editing the converted networks in ArcView. This paper also includes a case study that demonstrates the practical implementation of this linkage as it applies to subarea model development.
The accuracy of travel forecasts produced by a travel demand model is governed significantly by the quality and accuracy of network data used in model development (such as link distances and the positioning of centroids and connectors). Better accuracy could be achieved if compiled geographic information (such as TIGER or the National Transportation Atlas Database) were utilized. This is difficult if travel demand model networks cannot be maintained in the same coverage that contains the geographic information.
Capabilities have been developed within MINUTP (a PC-based highway and transit transportation forecasting software) to easily develop and maintain travel demand model networks in ArcView, a popular "desktop" GIS software. Since the network is a significant data item in travel demand modeling (carrying and communicating model assumptions and results), a network linkage represents a major step to true model/GIS integration.
This paper outlines the features and capabilities of the software enabling the MINUTP/ArcView network linkage. In addition, a case study involving subarea network development is presented. This approach utilizes the software in a practical setting, providing a methodology as well as an illustrated application.
Two software components were created to aid transportation analysts in incorporating geographic information into travel demand model network development: a shapefile translation utility for MINUTP networks and a set of tools that facilitate editing the converted networks in ArcView. The translation utility is featured as a separate module, "MUARCV", which is packaged with the MINUTP suite of tools - designed to facilitate travel demand modeling. The ArcView editing tools ("Network Tools") were written in AVENUE, and aid the analyst that is not familiar with ArcView's editing procedures. The tools closely mimic those used by MINUTP's network editor.
MUARCV converts a MINUTP network file to a set of shapefiles (and vice versa) can subsequently be imported into ArcView. MUARCV also allows updating shapefile feature attributes (associated with a converted network) with variables from a "loaded" (assigned) MINUTP network. There are three types of shapefiles (the filename extension designates the type):
*.SHP - contains feature definitions (MINUTP links). Only "polyline" features are utilized in MINUTP network conversion.
*.DBF - database file (DBASE format) containing information about the attribute variables associated with the polyline features in the SHP file.
*.SHX - file containing indices relating records in the SHP file to records in the DBF file.
In many cases, the analyst will wish to convert a MINUTP network so that it will overlay directly on an existing geographic coverage. Most likely, the two sets of coordinates will be different: MINUTP will contain non-specific coordinates (1-32767), whereas the geographic coverage may have any range of coordinates utilizing positive and negative numbers. The coverage coordinates could be expressed in values from a local planar system or global system (latitude and longitude). The module MUARCV, provides a way to approximately transform coordinates (used to define the MINUTP network) into values that are compatible with the coordinate system used in a given geographic coverage.
Specifications for coordinate transformation are provided to MUARCV via a set of point/node equivalencies. These equivalencies are established by noting the coordinates of a physical reference point in the MINUTP network, and equating it to the coordinates of the same reference point in the geographic coverage. Many equivalencies may be specified. Typically, a subset of points is utilized, representing a uniform sample throughout the coverage. Although the equivalents are represented as X-Y pairs, the "X" and "Y" components are processed independently. The coordinate transformation process used in MUARCV utilizes varying linear transformations to obtain coordinate system equivalency.
When coding transformation equivalents, a MINUTP point can be specified as either a node name (a single number) or an ordered X-Y pair. The same set of point/node equivalencies should be used when converting network data in either direction (MINUTP network to shapefiles or shapefiles to MINUTP network).
The MUARCV module operates in three modes:
The MINUTP to shapefile mode reads a MINUTP network and writes the three shapefiles (*.SHP, *.SHX, *.DBF). Only directional links are written. The polyline feature records in the SHP file will contain only two points: the transformed coordinates of the link's A and B nodes. The SHX records will point to the links in direct order. The DBF records contain all the variables that exist in the network, and one additional variable named LINEPOST. LINEPOST is a character variable that will contain either a value of "A" or "B" value indicating "normal" ArcView posting should be placed Above or Below the polyline (link). The LINEPOST variable, in concert with the "posting tool" (one of the developed ArcView tools), allows the display of directional link attributes (obeying the "right-side" posting convention).
The shapefile to MINUTP mode reads the shapefiles and writes a MINUTP network. (Note that if data in ArcView is in a format other than shapefile (ARCINFO), this information must be exported from ArcView as a shapefile for MUARCV processing). The output MINUTP network will contain dummy links (for one-way links), and directional data revisions (variable REV). The polyline feature records (contained in the input shapefiles) may contain shape point information, but only the coordinates of the polyline endpoints (points defining MINUTP "links") will be used in generating the MINUTP network. This consideration ensures that the resulting MINUTP network will retain its schematic nature, avoiding memory limitations and processing time associated with subsequent MINUTP network processing. Floating point numbers (coordinates and link attributes) are truncated for inclusion in the output MINUTP link records.
The remaining mode of operation for the module MUARCV is the update shapefiles mode. In this mode, each shapefile feature attribute record is read, and if there is a matching MINUTP network link, the variables in the feature attribute record are updated with attributes from the MINUTP network link. If the MINUTP network contains variables that do not exist in the shapefile attribute table, the attribute records are expanded to include them. Coordinate transformation equivalencies are not used. A common use for this mode of operation is updating a geographic coverage (that was originally developed from a MINUTP network) with the results of a travel demand simulation.
Network Tools are designed as an aid to editing converted MINUTP networks in the ArcView (version 3.0 or greater) environment. These tools provide the capability to add, delete, and move links and nodes, split links; as well as edit and post directional link attribute variables. Shapefiles generated by the MUARCV module (as a result of MINUTP network conversion) form "dual", overlapping networks when imported into ArcView - each network representing one direction of travel. This structure is transparent to the network tools (with the exception the "Edit Vertex Tool"). Editing can proceed with the analyst considering each link that is visible to be either a, one-way link or a two-way link (as in NETVUE).
These tools were designed to aggregate common network editing functions in one location in the ArcView environment. This facilitates network editing by analysts that are not familiar ArcView's editing capabilities. The network tools were developed in AVENUE, an object-oriented language used for applications development in the ArcView environment. In some combinations of network size and editing operations, these tools may not operate as quickly as comparable NETVUE functions. The analyst that finds this performance unacceptable is advised to proceed with editing operations via ArcView's "native" editing capabilities (some of these editing capabilities may be faster than afforded by the Network Tools).
Access to the network tools manifests itself in the ArcView interface via a "pull-down" menu labeled MINUTP and through "tool buttons" located in the lower right hand side of the interface/panel area of the screen.
The ArcView interface displaying the MINUTP menu is shown below.
The following information describes the nature and use of the MINUTP menu items.
Delete Links
The Delete Links menu item removes selected links from the MINUTP network. The link layer must be editable to perform this operation. Links may be selected using the query builder or any of the selection tools. When two-way links are selected using a selection tool, Delete Links will delete both directional links.
Edit Attributes
Link attributes may be edited by selecting links (one or more may be selected) and then selecting the Edit Attributes menu item. This menu item opens an attribute table and highlights the selected records. The table or link layer must be "editable" in order to edit attributes. If the attribute table is already open, Edit Attributes will highlight the selected records and move them to the top of the table. Attributes may be subsequently modified using standard ArcView table editing procedures. Note that each record represents a one-way link.
Post Links...
The Post Links menu item allows the analyst to post directional link attributes in the view. Post Links will open a dialog box from which the analyst can choose the attribute to be posted. Attributes are posted on the right side of the link. Label size and color are selected using the Show/Symbol/Window... menu item under the Window menu. Specify the label size and color before posting attributes.
Update "LinePost"
The Update "LinePost" menu item recalculates the values of the variable "LinePost". As previously mentioned, the "LinePost" field is created when converting MINUTP networks into ArcView shapefiles. the values of "LinePost" are "A" or "B" and instruct ArcView to post attributes Above or Below a link depending on it's directionality. Run Update "LinePost" after new links are added or existing links are reshaped to ensure that labels are posted on the right side of the link.
Show Nodes
The Show Nodes menu item adds a node layer to the view. This feature allows nodes associated with the converted MINUTP network to be displayed. It can also be used to view nodes at any time in your editing session. The link layer must be active. If no node layer exists, a new one is created. If there is already a node layer in the view, it will be updated to reflect edits to the link layer. When a node layer is created or updated it is not visible in the view. Click the visibility button to make the nodes layer visible. Note that vertices or shape points associated with a link (polyline) are not displayed unless they are endpoints. This coincides with MINUTP's definition of nodes.
Post Nodes
The Post Nodes menu item labels the node layer with node numbers. The node layer must be active. Label size and color are specified by selecting the Show/Symbol/Window... menu item under the Window menu. Specify the label size and color before posting attributes.
Three "tool" buttons are also available to perform network edits. The location of these tools with respect to the ArcView interface is shown below.
Tool button function can be determined by placing the mouse over a tool button and noting the tool description that appears at the bottom of the ArcView screen. The tool buttons are described below as they appear in the interface from left to right:
Add Link Tool 
The Add Link Tool button is used to draw new links in the network. It is strongly recommended that the analyst understand the "General Snapping" and "Interactive Snapping" functions in ArcView in order to use this tool effectively. The link layer must be editable. Click the left mouse button to start the link and to add shape points or vertices. Shape points are added by a single click of the left mouse button. Double click the left mouse button to end the link. The direction of a link is based on the direction in which it is drawn. The first node will be designated the "A" node and the last node drawn will be the "B" node. A dialog box prompts the analyst to specify if the link is one-way or two-way (for two-way links an identical link will be created, drawn in the opposite direction). The link attribute table opens and the last link drawn is highlighted. At a minimum, the analyst should specify the "A" and "B" node names at this time - as attributes for the added link(s).
Split Link Tool 
The Split Link Tool is used to split links - inserting a new node. The link layer must be editable. Use the mouse to draw a line, intersecting the link where you want it to be split. Multiple links can be split using this tool. Link attributes are retained in the new links. The analyst will need to update "A" and/or "B" nodes and distance values for the newly defined links by editing the link attribute table.
Edit Vertex Tool 
The Edit Vertex Tool is used to add, move and delete vertices (shape points, nodes) for any given link (polyline). The link layer must be editable, and note that for this tool one directional link layer can be operated on at a time. Use the cursor to select a link. As the cursor is passed over the selected link it will change to a cross hair display. Position the target and click the left mouse button to add a new vertex. To move an existing vertex to a new location, position the cursor over the vertex you want to move. Hold the left mouse button down and drag the vertex to move it to a new location. An existing vertex can be deleted by positioning the cursor cross hair over a vertex and pressing the DELETE key.
.
This case study represents a common procedure that is increasingly performed in the travel demand forecasting profession - subarea network development. Many states and metropolitan regions develop and maintain their own regional travel demand models. As a part of major investment studies, development impact assessment, and other planning activities; utilizing, evaluating, and refining information provided by a regional model is a common occurrence. Often information from many data sources are required to either evaluate the existing regional model or develop a subarea model through a process known as subarea focusing. A subarea focused model retains the same geographic coverage and model structure as is present in the regional model with one important difference - in the study area network and land use information are portrayed in more detail. One unifying factor this data has is a common geographic base. An intention of this case study is to demonstrate the practical application of using various kinds of data in a common geographic setting for the purposes of subarea network development.
We will be working in the Richmond metropolitan area, detailing a region that is a combination of established residences and undeveloped farmland. The map below delineates the study area (shown in yellow). This map was generated in ArcView. The associated roadway information (TIGER) will serve as a basis for evaluating the regional network that covers the study area. In this case, model refinement is required to evaluate the travel demand impacts of a proposed manufacturing facility on a major transportation corridor, Route 288; and the mixed land use development precipitated by the construction of that facility.
Using the software utilities discussed in the previous section, we will illustrate how the regional MINUTP network is incorporated into a geographic database that will containing a wide variety of information about the study area. The first step is to incorporate the MINUTP network into the database. We will then proceed through a series of steps designed to evaluate and identify needed refinements to the regional network, and finally implement them. This case study is by no means a definitive narrative on subarea network development - the intention to convey how data, sharing a common geographic basis, can be utilized.
Regional travel demand model networks are commonly coded in a state planar or other local coordinate system. Dependent on the coordinate system(s) other geographic data reside in, the travel demand model network should be transformed to a system compatible with the assembled geographic information. In our case, this is the global (lat/long) coordinate system of the TIGER roadways. The first step in network transformation is determining locations representing coordinate equivalency (tic points). Locations of features in the reference coverage (the TIGER roadways in this case) that are readily identifiable in the MINUTP schematic network, such as major intersections bridges, and unique roadway alignments are utilized. Conversely, locations in the MINUTP network whose locations are well known in the street coverage, such as external stations and bridges are used as well. The number and location of tics should be governed by the location and size of the subarea window. Established tic point locations need to be present in both the street coverage and MINUTP network. Once these locations have been determined and tic points established, a coordinate equivalency file is created for use in MUARCV. The equivalency file states the relationship between the respective coordinates of established tic points in the coordinate systems of both the street coverage and MINUTP network.
Our first step in establishing tic point locations is to convert the regional MINUTP network (RI9020.DAT) to shapefile format using MINUTP's MUARCV shapefile conversion utility. We compose the necessary MUARCV script and execute without specification of coordinate equivalencies. A detailed explanation of MUARCV module syntax can be found in the MINUTP technical manual. The script used for this shapefile conversion is shown below.
$ This script file directs the MUARCV to convert
$ the MINUTP network RI9020.DAT to shapefile format. No coordinate
$ transformation is performed.
$
*PGM MUARCV
FILE MUINPUT=RI9020.DAT,AVOUTPUT=RI9020
*>COPY *.PRN RT288.LST
*>DEL *.PRN
*
This MINUTP script converts the network file "RI9020.DAT" to shapefile format. Three files are produced, with the file name "RI9020" with file extensions "SHP", "SHX", and "DBF". The purpose of the above script (shapefile conversion) is not coordinate translation; but to provide a form of the MINUTP network that will be examined as a theme in ArcView to aid in establishing tic points.
After shapefile conversion of the MINUTP network, we utilize ArcView. ArcView is used to establish tic point locations and to create a coordinate equivalency file (via an AVENUE script, "COORDEQV"). We start a new application and establish View 1,adding shapefiles or ARCINFO coverages of key geographic features depicting the region (such as lakes and rivers) and roadways. Political boundaries may also be used to further delineate the region. In this case study, we use TIGER (1990) as a source of coverages for roadways, county boundaries, lakes, and rivers west of the Richmond metropolitan area. All data is in shapefile format (global coordinates), however ARCINFO coverage files may be used as well.
We open a new view (View 2) and add, as a theme, the shapefile representing the MINUTP network. We next tile the view windows for an easy comparison of the roadway and MINUTP network views. This facilitates determination of "equivalent" tic point locations in the two views. Using the ZOOM tool, we frame both views to approximately cover the study region. The graphic below shows ArcView with the two views displayed
.
Notice that locations of nodes in the MINUTP network are displayed. This helps if nodes are used to define tic point locations in the MINUTP network (defined nodes offer a more accurate coordinate location in the MINUTP network when equating these points to locations in the street coverage). Nodes are displayed by choosing the "Show Nodes" item from the MINUTP menu. Calculation of node locations can take several minutes depending on the size of the network. After the calculation is complete, a new theme "Nodes.shp" appears in View 2. Note that the "nodes" theme needs to be marked "visible".
Using PAN and ZOOM controls, we can view potential locations for tic points. Tic points are added as point features on the themes named "Tics1" and "Tics2" respectively, for the two views. We edit the tables associated with these themes, creating numerical fields named "Tic1_id" and "Tic2_id" for the two themes (Tic1_id associated with the view showing TIGER roadways and Tic2_id with the MINUTP network view). These fields serve to store identification (ID) labels for the tic points. We establish six (6) coordinate equivalency locations adding six tic points (each view should have six point features). When adding each point, we designate a tic ID for the point by editing the appropriate tic theme attribute table. The same ID for the "equivalent" tic must be used in the complimentary view. Locations of the six established tic points in both views are shown below, along with their attribute tables.
When establishing equivalency locations and adding tic points, for purposes of preliminary coordinate transformation, it is important to remember to use a minimal number of locations. The objective of preliminary coordinate transformation is to produce a MINUTP network that is roughly equivalent to the street coverage. This allows the analyst to identify a larger set of equivalency locations for use in the next, more detailed coordinate transformation.
In our next step we create a coordinate equivalency file and perform the preliminary coordinate transformation and shapefile conversion of the MINUTP network. (You may note that we have already converted the MINUTP network to shapefile format, however, no coordinate transformation was performed. The purpose of that conversion was to provide a representation of the MINUTP network so that preliminary equivalency locations can be established.) After adding tic points in both views, we close editing functions in the respective views ("stop editing"). We next open the application window, select the script "COORDEQV", and execute (run). This script creates an attribute table (EQUIV.DBF) that contains information on the tic points in both the geographic coverage and MINUTP network views. The table contains the following fields:
Tic_id - identification number of tic point
Minutp_X - "X" coordinate associated with MINUTP network (View 2)
Minutp_Y - "Y" coordinate associated with MINUTP network
Ref_X - "X" coordinate (or longitude) associated with the reference street coverage (View 1)
Ref_Y - "Y" coordinate (or latitude) associated with reference street coverage
Below the table "EQUIV.DBF", is shown (in the ArcView window) indicating equivalent coordinates for the six tic points.
We export this table as ASCII text to a DOS file, "COORD1.EQV" and edit the file. Consulting MUARCV documentation for proper syntax, we produce the following text which comprises the coordinate equivalency file.
CONFLATE 12925-12510=-77.51637-37.60506
CONFLATE 12607-12938=-77.53593-37.62922
CONFLATE 11883-13650=-77.58319-37.67117
CONFLATE 9865-12323=-77.71251-37.60145
CONFLATE 12454-13892=-77.54066-37.68121
CONFLATE 10732-12466=-77.66141-37.60476
Note that the X/Y coordinate pairs in both the MINUTP network and geographic feature coordinate systems must both be ascending or descending. If coordinates are sorted in "X" order, and the "X" coordinate for a particular tic point in the MINUTP network increases/decreases with respect to the "X" coordinate of the next tic point (in sorted order) - then the "X" coordinates of the tic points (with the same ID), in the geographic feature coverage, must also increase/decrease. The same must be true of the "Y" coordinates in both views. If this criterion is not met, the execution of MUARCV will result in a fatal error.
If this fatal error occurs, the following considerations should be made. The coordinate equivalency file should be checked for errors that might have been introduced when editing the exported EQUIV.DBF, creating the equivalency file used in the MINUTP network to shapefile conversion. Tic point locations should also be reviewed to ensure that tics with the same "Tic_id" actually refer to the same physical location in both views. If there are no indications of errors at this stage, the X/Y coordinate order problem is most likely due to significant coordinate system rotation between the MINUTP network and the reference street coverage. At present, the coordinate transformation feature associated with MUARCV does not accommodate significant rotation between coordinate systems.
A way to verify the X/Y coordinate order of equivalent tic points (while in ArcView) is to sort both tic tables by their "X" coordinates and observe the "Tic_id" order of the respective tables. If the order is the same then the criterion is met for the "X" coordinate. Perform the same procedure for the "Y" coordinate. If the criterion is met for the "Y" coordinate then the tic point equivalencies should be processed by MUARCV without any errors. Note that this verification procedure still does not ensure that the tic points in both views actually refer to the same physical location.
We next perform the preliminary coordinate transformation by executing MINUTP script that directs the MUARCV module to convert the network to shapefile format as well as transform the coordinates associated with the network. This process yields SHP, SHX, and DBF files describing the MINUTP model network in the coordinate system of the geographic feature coverage. The MINUTP script used for coordinate transformation is similar to that used in the initial MINUTP network shapefile conversion, with the exception including a "READ" statement (in bold):
$ This MINUTP driver file directs the MUARCV module to convert
$ the MINUTP network RI9020.DAT to shapefile format while performing
$ a coordinate transformation. Note the inclusion of the coordinate
$ equivalency specifications contained in the file COORD1.EQV.
$
*PGM MUARCV
FILE MUINPUT=RI9020.DAT,AVOUTPUT=RI9020
*READ COORD1.EQV
*>COPY *.PRN TRANS1.LST
*>DEL *.PRN
*
Now that the preliminary coordinate transformation is complete, it is easier to determine more tic point locations. These additional locations will be used in establishing a more refined coordinate equivalency in the study area. At this stage we are able to get a "sense" of the schematic nature of the MINUTP network as compared to the physical configuration of roadways in the geographic feature coverage. The graphic below shows the recently transformed MINUTP network shapefile as a theme over the TIGER roadways.
Looking closer at the study area, note the similarities and differences of the respective networks. Note that the initial tic points, established in the MINUTP network and street themes, are exactly coincident while the networks become less coincident as distance from the tic points increases.
Proceeding with the refined transformation, we need to add tic points emphasizing locations in the study area. We use ArcView as in the preliminary transformation - as a tool to facilitate the definition of tic point locations. We utilize two view windows. The first one shows reference TIGER roadways, the recently created MINUTP network shapefile, tic points used in the previous conflation, and other geographic features (same view as displayed in the previous graphic). The other window (View 2) shows the un-transformed MINUTP shapefile with the tic points established for the first transformation. View 2 is focused on the same coordinate window as View 1.
Using the same technique as previously described for the preliminary transformation, we determine additional locations of coordinate equivalency and add tic points in the respective view windows. We create an updated coordinate equivalency file, COORD2.EQV. We use this file in another application of MUARCV to produce another shapefile representation of the MINUTP network. This shapefile more closely resembles (in the study area) the shape and dimension of the TIGER roadways. The graphic below illustrates the refined coordinate transformation of the MINUTP network.
We further conflate this shapefile manually using ArcView. This manual conflation process yields a travel demand network representation in the study area suitable for refinement in subarea focusing. Using ArcView we set up a view window containing the following components (bottom to top): geographic features (lakes, rivers...), TIGER roadways, transformed (refined) MINUTP network shapefile, network nodes, and the tic point layer associated with the last, refined coordinate transformation. We make the roadway coverage and network visible. Using the vertex-editing tool provided in the MINUTP Network Tools extension, we edit the MINUTP network by moving network "nodes" (polyline endpoints). We also insert shape points so that network "links" are coincident with their TIGER roadway counterparts. The graphic below shows the network (after manual conflation) over the TIGER roadways.
Refinement of the regional network supports development of a subarea focused model. Developing a subarea focused model provides a tool that is a more accurate estimator of travel demand within a defined geographic area in the original regional model. The map below shows the study area (highlighted in yellow) with the following themes visible:
Note that with the regional model network fully conflated in the study area, roadways and water features provide for easy location reference. Once a MINUTP network is fully conflated over an entire metropolitan region, continued network maintenance (updates and edits) can be performed more efficiently and accurately in a GIS environment. Several considerations are involved when refining a network in preparation for developing a subarea model. Some are general in nature, others specific to working in a GIS environment. One must consider the needed level of network detail, information/data available, the implications and difficulties of data conversion to the required GIS format, and most importantly time and budget.
The overall objective/product of the subarea-focused model needs to be kept in mind (on which roadway facilities will accurate forecasts be needed) when gaging the amount of network detail needed. In general, the refined subarea network should contain one facility type or functional class of roadway below the most minor facility for which forecasted volumes are required. If facility type data is present in the MINUTP network, this information can be mapped thematically to show the adequacy of the roadways represented in the study area. How much network detail and through what technique it is added will depend on the availability and format of available geographic information and data (speeds, capacities, and observed volumes) describing the physical roadways in the study area.
The availability of base year/horizon year socioeconomic data (geographic and attribute) and at what geographic level it is available will impact the level of detail to which the TAZ system can be refined. If zone-to-network compatibility is to be assured, the availability of socioeconomic data will also dictate subarea network detail.
Another important consideration; the ability to use or incorporate network, roadway, socioeconomic, and other information in a GIS format (such as shapefiles); must be assessed. If some information such as geographic and attribute information describing regional TAZs is not "GIS-ready", considerations for digitizing data and constructing databases need to be explored. In general, the availability of "GIS-ready" data needed for travel demand model network development is increasing rapidly. Public domain information sources such as TIGER, the National Transportation Atlas Database (NTAD), the Census Transportation Planning Package (CTPP), and a myriad of proprietary sources are increasing the availability of geographic information. Moreover, many states and municipalities are creating and cataloguing geographic information in conjunction with regional demand model and infrastructure management system development.
Time and budget associated with the project must be considered. Study area size, number of forecast horizon years, and limited availability of geographic information may require labor and time intensive activities that could render GIS development of a subarea travel demand modeling network impractical.
In our case study, we have assembled information needed to refine the TAZ system associated with the regional model in the study area. TAZ refinement provides a basis for refining our travel demand model network while at the same time establishes a guide for creating revised land use records. These records, reflecting the new TAZ structure are used by the subarea-focused model, in the estimation of travel demands in the study area. The information we need for TAZ refinement entails geographic and attribute information (describing land use contained in the regional model, including TAZ and census tract boundaries, and roadway information from the CTPP and TIGER), various planning documents, and aerial photographs. Planning documents include growth management and master plans for the study area indicating future transportation structure and land use. Regional TAZ boundaries and associated land use character are shown below.
Two considerations need to be made when refining TAZs in the study area: distribution, character of existing, and future land use, and the location of existing and future roadway facilities. The refined TAZ structure should provide a means of improving trip generation estimates by delineating homogeneous areas of land use, and afford a more accurate portrayal of land use access to adjacent roadways. Since the objective of this subarea focusing process is to produce a base year network (1990), for use in developing Year 2020 forecasts, existing and future data must be considered.
As previously mentioned, the subarea model being developed needs to forecast travel demand associated with mixed-use development and a major roadway (Route 288) to be located west of Tuckahoe Creek (Goochland County) in the study area. Using information concerning location and character of the mixed-use development, and the location of Route 288, we subdivide TAZs 355 and 358 (in accordance with the parcel structure outlined in the master plan). In addition, we subdivide TAZs in the residential area in Western Henrico County (west of the proposed John Rolfe Parkway and east of Tuckahoe Creek) taking into consideration character and distribution of land use. We perform these edits to the regional TAZ boundary shapefile in ArcView, taking into account the location of existing and future roadways. The map below shows the ArcView display that provides information concerning the location of regional TAZs, the regional MINUTP network (offset by direction and colored by facility type), and TIGER roadways (colored by facility type). With additional land use information provided by master plans and the aerial photographs, ArcView provides a powerful integrated platform for making decisions concerning the new subzone structure.
The seven regional zones comprising the study area are subdivided into 34 TAZs. These new zones will provide a guide for subsequent network refinement and serve as a record of this aspect of the subarea focusing exercise. The subzone structure and apportioned land use are shown in the maps below.
When creating a subarea focused model, it is important to include enough roadway structure in the network such that "smooth" traffic assignments are produced on the lowest class facility for which travel demand information is needed. In our case study the subarea model needs to portray as accurately as possible route choices between Patterson Avenue and Broad Street Road, and the future demand impact of the new travel corridor connecting these two facilities: Route 288. It is important therefore to include all roadways connecting Patterson Avenue and Broad Street Road, including supporting collector roadways. As indicated earlier, these needs are balanced with available data concerning the existing and future operating characteristics of roadways in the study area.
Zone-to-network compatibility also needs to be ensured. Since our case study involves the subdivision of seven regional zones into over 30 smaller zones, network refinements are extremely important. If the roadway network is too course (not accurately representing possible travel routes and access to adjacent land use) with respect to the TAZ system, over simulation of travel demand on some of the study area links will occur. If too much network detail is represented, under-simulation will result. We utilize the Network Tools to add, move, and edit MINUTP network links in the study area.
After refinements are completed, adequately representing the study area network; new zone (subzone) centroid connections are added. The map below indicates the benefit of determining centroid and centroid connector placement on a geographical platform. Using the TIGER roadway network as a guide, centroid connections and position can be accurately determined by observing the configuration of local roadways in the TIGER roadway coverage and by assuming that development density is proportional to roadway density.
A final refinement, designed to accurately reflect minimum path choices by the model, is checking the accuracy of coded link distances with respect to actual roadway distances contained in the geographic coverage. Links that have been added to the network during refinement can have their distances calculated readily by ArcView.
Now that the subarea network is complete, we can convert the network shapefile back into MINUTP network format for model execution in MINUTP. Once the model is executed, the established subarea shapefile network, developed in this case study for the base year, can be updated with assigned traffic volumes. The map below shows the base year (1990) daily travel demand, graphically displayed by bandwidth. Used this way ArcView can thematically display and provide a platform for analysis with respect to model validation.
William W. Thomas, III, Project Manager, (410) 571-6450
Anthony G. Hofmann, Planner, (410) 571-6467
Affiliated with Michael Baker, Jr., Inc., 180 Admiral Cochrane Drive, Suite 210, Annapolis, MD 21401