Roadway Network
This was copied from SOABM - it was updated for SimOR, but there will be details that are more SOABM than SimOR
Editing networks requires an understanding of the model inputs. Model users should familiarize themselves with the various elements that make up the network before editing. One should also be familiar with network editing in VISUM before attempting to modify the network.
Typically network editing involves adding, deleting, or modifying nodes and links. Whenever one adds, deletes, or modifies links, there is a need to make sure that all of the required values in the Link Attributes table are populated.
Unlike a traditional trip-based model, which has one zone system, the ABM has three zone systems. Since VISUM’s network data model only supports one zone system for skimming and assignment, the VISUM Zones need to be changed on-the-fly from TAZs to MAZs. This means that each version file created during the model run may have a different set of zones and connectors depending on the purpose. Thus, it is important to always start with the input master version file when making editing since it contains all three zone systems. The VISUM Zones are TAZs and the VISUM PedestrianZones POI are MAZs.
The ABM model network is based off an all-streets (all-paths) network that includes local and in some locations even private roads. Therefore, given the overall scale of the model network, all manual network coding is only performed for roadways and intersections containing at least a collector classification street or greater (arterial, ramp, interstate).
The primary input for a scenario is the VISUM master version file. This file contains the multiple zone systems, all zonal attributes, the highway network, the transit network, and multimodal network attributes (and paths). Note that all dollar inputs are in $2025. The version file uses the following VISUM network objects:
- Nodes – network nodes, with the attributes required in Node Attributes.
- Links – network links, with the attributes required in Link Attributes.
- Turns – network turns, with no required attributes except for setting TSysSet=empty for prohibited turns.
- Zones – TAZS, with the attributes required in TAZ (ZONE) Attributes (Currently no attributes are required at the TAZ level). TAZs in ABM are only used for auto/Transit skims and assignment and therefore do not contain land use data. External TAZs are numbered 1-99 and internal TAZs are 100+. Note that MAZ's are smaller than TAZs, but are stored in Main Zones instead of zones because MAZs don't require connectors, and TAZs do.
- Connectors – TAZ connectors, with TSySet and t0 (initial travel time) set. Only TAZ (auto/transit) connectors are coded in the input file. The VISUM Python procedures code the MAZ connectors. Make sure to code nodes along walk and bike paths so MAZ connectors can be built.
- PedestrianZones POI Object – MAZs, with the attributes required to run the ABM are stored in POI Attributes (still working on finalizing MAZ list). The ABM generates all trips to and from MAZs, which requires all land use data to be coded at the MAZ level as well, additional information can be found on the Editing Land Use page.
- Stop Points – Physical transit stops, with no required attributes. (note all transit pieces need to be reviewed and commented on by Metro).
- Stop Areas – TAPs, with the attribute required in TAP (STOPAREA) Attributes (to be defined). The Stop area ID is used as the TAP ID in OR-RAMP. There can be multiple stop points per stop area in VISUM, but this is currently not the case since the network was imported from Google transit.
- Stops – Groups of stop areas. There can be multiple stop areas per stop in VISUM, but this is currently not the case since the network was imported from Google transit.
- Lines – Transit lines, with no required attributes. The line name is currently set to the Google transit operator and route number. The available Transport Systems for transit lines are Bus, Streetcar, Commuter Rail, Express Bus, and Light Rail.
- Line Routes – Transit lines, with a headway attribute for each time period Lineroute Attributes (to be defined). The headway needs to be coded in seconds. If the line is not available in a time period, then set the headway to 0. Line routes code the sequence of links and stop points for each line. See Transit Network Coding (needs to be defined) for more details on transit network coding.
- Time Profiles – Transit line link run times and stop dwell times. The transit line run and dwell times are updated after highway assignment using the VISUM procedure – Set Run and Dwell Times. Even though Google transit schedules were loaded into the version file in order to calculate headways, they are not used in the model.
- Network – Each version file has a master Network object that all network objects inherit from. The ABM network has a link capacity time-of-day factor for calculating time period specific link capacities from the input link attribute one-hour capacity.
- Transport Systems - Defines the mode options for users in the model system, at the vehicle level. Different from "Modes"
- Modes - Defines the mode options for users in the model system, at the trip level.
- Demand Segments - Defines the breakdown of trips by time of day and mode.
Planned Values for the Metro Region
| Time-of-Day | Description | Hourly Capacity Factor | VISUM Network Object |
|---|---|---|---|
| EA | 0:00-4:59 | 5 | Network\TOD_FACTOR_EA |
| AM | 5:00-8:59 | 3 | Network\TOD_FACTOR_AM |
| MD | 9:00-14:59 | 8 | Network\TOD_FACTOR_MD |
| PM | 15:00-18:59 | 3 | Network\TOD_FACTOR_PM |
| EV | 19:00-23:59 | 5 | Network\TOD_FACTOR_EV |
The following attributes must be defined by the user when adding/editing network objects for the roadway network.
These network attributes are given default values in the Network Attributes table, so they can be left alone and will never be updated by model code.
| Field | Description |
|---|---|
| Walk_Speed | Defines the walk speed for wlk and w transport systems over network connectors - Used in transit skimming |
| Connector_Vehicle_Speed | Defines the vehicle speed over network connectors - Used in transit skimming |
| Intrazonal_Vehicle_Speed | Defines the vehicle speed for intrazonal trips - Used to set INTRTIME on the zones and then used for matrix diagonals |
These attributes must be considered when adding/editing links.
| Field | Description |
|---|---|
| TSysSet | Allowed transport systems (i.e. modes, transit systems descriptions are found here): |
| s = Single-occupant non-toll vehicle | |
| sr2 = High-occupant 2 person non-toll vehicle | |
| sr3 = High-occupant 3+ person non-toll vehicle | |
| mt = Medium Trucks | |
| ht = Heavy Trucks | |
| k = Bike* | |
| wlk = Walk* | |
| *It should be noted that TSysySet is used to create bike and pedestrian networks. Bike and walking is only allowed where TSysSet is coded for those modes. See the Non-Motorized page for additional information. | |
| TypeNo (Metro) | Facility type (Metro) |
| 1=Transit | |
| 2=Walk to transit (asserted length) | |
| 3=Walk to transit (actual length) | |
| 10=Freeway | |
| 19=Freeway HOV Lane | |
| 20=Highway | |
| 30=Arterial | |
| 40=Intersection expansion link | |
| 51=Intersection approach (uses Metro's custom Volume-Delay Function) | |
| 61=CBD Grid | |
| 70=Off-Ramp | |
| 71=Metered Ramp | |
| 79=On-Ramp | |
| TypeNo (SKATS) | Facility type (SKATS) |
| 11=Ramps | |
| 12= ramps (directional) | |
| 20= Principal (Interstate) | |
| 21= Principal (State Highway) | |
| 22= Principal (Parkway) | |
| 31= Major Arterial (Parkway) | |
| 32= Major Arterial | |
| 33= Rural Arterial | |
| 41= Minor Arterial | |
| 51= Collector - Urban | |
| 52= Collector - Rural Major | |
| 53= Collector - Rural Minor | |
| 61= Local - Urban | |
| 62= Local - Rural | |
| 68= Urban street | |
| 69= Rural street | |
| 71= Driveway | |
| 99= No Cars | |
| [TOD]_[Mode]_TOLL | Toll by period and mode, can be left at zero |
| FWY_CAP_1HR (Metro) | 1-hour freeway capacity (required on freeway links) |
| APP_CAP_1HR (Metro) | 1-hour approach link capacity (required on TypeNO = 51 links) |
| MB_CAP_1HR (Metro) | 1-hour midblock capacity (required on non-freeway, non-TypeNO = 51 links) |
| [TOD]_METER (Metro) | Period ramp meter link capacity, can be left at zero |
| HOURLY_ROADWAY_CAP (SKATS) | 1-hour roadway capacity |
| Field | Description |
|---|---|
| No | Link number, managed by VISUM. |
| Xcoord | X coordinate of the node, managed by VISUM |
| Ycoord | Y coordinate of the node, managed by Visum |
| ControlType | The type of Control at the Intersection, available options: |
| unknown - this is the default setting and is used for all local intersections and shaping nodes. The large majority of nodes are left as unknown. | |
| Uncontrolled - currently uncontrolled is used in a similar way as unknown, but ideally the network would be cleaned to a point where the Uncontrolled label was only used for intersection known to have no control (so the default should remain unknown, unless the intersection is specifically uncontrolled. | |
| Two-way stop - the user needs to ensure that the major flow is properly set (see VDF Network Coding for more details). | |
| Two-way yield - currently very few exist on the network. Only use in known locations of a yield sign. As with Two-way stops, the major flow needs to be reviewed and properly set. | |
| Signalized - all signalized intersections need to be coded properly, with the major flow reviewed and a number of other details as specified in VDF Network Coding. | |
| All-way stop - All-way stops should be captured, no other additional detail is needed at all-way stops. Currently coded for collectors and above. | |
| Roundabout - currently not used, but it's hoped that roundabouts will get a unique congestion treatment with further development. So the intersections with roundabout should be faithfully coded. Roundabouts drawn with more than one node should be aggregated using a main node. | |
| Note that all controlled intersections drawn with more than one node should be aggregated using a main node (see VDF Network Coding for more details). |
| Code | Name |
|---|---|
| a | brt |
| b | bus |
| c | car |
| e | streetcar |
| h | hov |
| ht | heavy truck |
| i | kiss-and-ride access |
| k | bike |
| l | light rail |
| mt | medium truck |
| r | commuter rail |
| s | sov |
| sr2 | shared ride 2 |
| sr3 | shared ride 3+ |
| t | truck |
| w | walk to transit |
| wlk | walk PrT (walk as transportation) |
| Code | Name |
|---|---|
| c | car |
| h | hov |
| ht | heavy truck |
| k | bike |
| KnR | Kiss-and-ride |
| mt | medium truck |
| PnR | Park-and-ride |
| PuT | Public transport |
| s | sov |
| sr2 | shared ride 2 |
| sr3 | shared ride 3+ |
| t | truck |
| wlk | walk PrT (walk as transportation) |
| Code | Name |
|---|---|
| amhpe | AM heavy truck |
| ammpe | AM medium truck |
| amPuT | AM public transport |
| amsov | AM SOV |
| amsr2 | AM shared ride 2 |
| amsr3 | AM shared ride 3+ |
| Repeat the demand segments for all time periods (ea, md, pm, ev) for a total of 30 |
The following attributes are automatically set by the model when running.
| Field | Description |
|---|---|
| No | Link number, managed by VISUM. |
| FromNodeNo | From node |
| ToNodeNo | To node |
| TypeNo | Link type. VISUM uses TypeNo to index into the VDF lookup grid in the procedures settings. During the VDF data prep step, the TypeNo is set equal to the PlanNo (facility type) since there is a separate VDF configuration by facility type. Therefore, this field is updated by the ABM process and should not be set by the user. Each VDF configuration makes use of the one VDF DLL developed for this ABM. |
| Length | Link length in miles |
| V0PrT | Free flow speed |
| CapPrT | Visum's internal capacity field (across all lanes). There are a number of fairly complex internal steps and aspects that go into the ABM's VDF. Therefore Capacity is not a simple user input like in most static assignment models; instead capacity is derived from a number of inputs. This resulting capacity is stored in CapPrT, which allows for the internally calculated VolCapRatio fields in Visum to be populated properly. Therefore, capacity cannot be coded by the user as it is calculated and updated during the model run. |
| HOURLY_ROADWAY_CAP (Metro) | 1-hour roadway capacity |
| Toll_PrTSys(DSEG) | Toll for each demand segment in $2025 dollars |
| NumLanes | Number of lanes. |
| AUX_LANES | Number of auxiliary lanes on freeways. Auxiliary lanes are used in the link capacity calculation. |
| MEDIAN | Type of median, to be coded by user. Median is used in the link capacity calculation. |
| 0 = No-Median/Outside the TAZ boundaries | |
| 1 = Raised Median | |
| 2 = Striped Median | |
| 3 = Two-way left turn lane (TWLTL) | |
| Note that all roadways with a physically coded median (i.e separate nodes and one-way vehicle links for each direction) are coded as MEDIAN = 0. | |
| AddVal1,2,3 | Used for internal calculations. Does not need to be coded by user. Users should be aware that these fields are dynamically updated so any data saved in these fields will be lost. |
| EA_TTC | Early AM Congested Travel Time |
| AM_TTC | AM Congested Travel Time |
| MD_TTC | Midday Congested Travel Time |
| PM_TTC | PM Congested Travel Time |
| EV_TTC | Evening Congested Travel Time |
| Field | Description |
|---|---|
| BIKEFAC | Bike Facility Present;
|
| BLTS | Either BLTS 1-4 directly, or a proxy, described further below. Generally;
|
| SLOPE | Calculated average slope over the link segment. Suggest calculating automatically from local DEM data. Note if slope is overly complicated, note that the user can consider this input in four bins; less than 2%, which could be the default (0 slope), 2-4% (3%), 4-6% (5%), greater than 6% - could code as 8%. Note that only upslope needs to be coded, negative slope should have a negative or kept as zero. |
The table below is from Chapter 14 of ODOT's Analysis Procedures Manual. Please see Chapter 14 for a full contextual discussion on BLTS.
| BLTS | Description |
|---|---|
| LTS 1 | Represents little traffic stress and requires less attention, so is suitable for all cyclists. This includes children that are trained to safely cross intersections (around 10 yrs. old/5th grade) alone and supervising riding parents of younger children. Generally, the age of 10 is the earliest age that children can adequately understand traffic and make safe decisions which is also the reason that many youth bike safety programs target this age level. Traffic speeds are low and there is no more than one lane in each direction. Intersections are easily crossed by children and adults. Typical locations include residential local streets and separated bike paths/cycle tracks. |
| LTS 2 | Represents little traffic stress but requires more attention than young children would be expected to deal with, so is suitable for teen and adult cyclists with adequate bike handling skills. Traffic speeds are slightly higher, but speed differentials are still low, and roadways can be up to three lanes wide for both directions. Intersections are not difficult to cross for most teenagers and adults. Typical locations include collector-level streets with bike lanes or a central business district. |
| LTS 3 | Represents moderate stress and is suitable for most observant adult cyclists. Traffic speeds are moderate but can be on roadways up to five lanes wide in both directions. Intersections are still perceived to be safe by most adults. Typical locations include low-speed arterials with bike lanes or moderate speed non-multilane roadways. |
| LTS 4 | Represents high stress and suitable for experienced and skilled cyclists. Traffic speeds are moderate to high and can be on roadways from two to over five lanes wide for both directions. Intersections can be complex, wide, and or high volume/speed that can be perceived as unsafe by adults and are difficult to cross. Typical locations include high-speed or multilane roadways with narrow or no bike lanes. |
“MEDIAN” should be populated with an integer between 0 and 3, indicating the following treatments: - 0 = No Median - 1 = Raised Median (Jersey Barrier, curb, or raised pavement area) - 2 = Striped Median (Hatched painted median shadow, etc.) - 3 = Two-Way-Left Turn Lane (TWLTL)
Currently, the volume-delay function does not differentiate between the different median treatments; it only matters whether there is a median or not.
Examples of each of the four median treatments are shown below.
“AUX_LANES” should be populated with an integer representing the number of auxiliary lanes along a freeway segment. Note that the auxiliary lanes should not be included in the Visum “Lanes” attribute, but only in the “AUX_LANES” attribute. An example of a freeway auxiliary lane is shown below. Note that there are no auxiliary lanes in the base-year SOABM auto network.
Intersection edits focus on the Node and Turns Visum network elements. The following four VDF attributes should be coded at the intersections (nodes or main nodes) for all intersections that include a minimum collector classification or higher:
- Intersection control type
- Direction of free flow or major movement (unsignalized intersections or two-way stop only)
- Lane lengths (signalized intersections only)
- Intersection Configurations (signalized intersections only)
In addition, some intersections require special attention due to separated through links. These intersections are addressed with Main Nodes, as discussed in a following section.
Intersection control type can be identified from base-year Google Earth aerial imagery or based on traffic engineering judgment for future facilities. The following types of intersection control are coded on the Visum node “ControlType” attribute:
- Signalized
- All-way stop
- Two-way stop
- Two-way yield
- Roundabout
- Uncontrolled
- Unknown (default)
The figure below shows examples of each type of control used in the ABM network.
For all signalized, two-way stop controlled, two-way yield controlled intersections, the free flow or major movement must be coded to correctly represent the correct traffic control condition. The free flow direction is coded using the “Major Flow Manually” tool in the Visum Junction Editor. The figure below shows how to use the “Major Flow Manually” too to code the free-flow movement correctly at a two-way stop controlled intersection.
Signalized intersections require additional network detail, including auxiliary turn lanes and storage lengths. The lane data is coded into the turn attributes from the junction editor, which is opened by double-clicking on the target node while in editing mode. The figure below shows an example how to code additional lanes and lane lengths at an intersection using the junction editor.
In additional to turn lanes and storage lengths, the ABM model requires all signalized intersections to have the correct allowed movements. The allowed movements for a specific lane can be visualized for editing with the following steps:
- Open junction editor for the target intersection (node)
- Click on the “Geometry” tab of the junction editor viewer (this typically opens in a separate view from the junction editor itself)
- Click on the “Lane turns” tab within the junction editor window (see figure below)
- Click on the “Mark leg” button (the pink square) on the approach leg where you wish to edit
- Visualize the allowed movements for a specific lane by clicking on the “Mark movement” button (white box, turns yellow when active for editing)
- Use the “x” button to close and the “+” button to open an allowed movement.
All movements are allowed by default when they do not conflict with another allowed movement on their approach leg. A dashed line represents a closed movement, and a solid line represents an open movement. When opening and closing allowed movements, be cautious of which buttons are associated with each movement. Zoom in on the movements for better visualization. Note that by default the network should be set to close U-turns when editing.
Some networks may have situations where links are separated by direction at intersections. This situation typically occurs on major arterials with raised medians. In these locations, the Visum “Main Node” network elements are used to consolidate the signalized intersections to the appropriate movements required for the VDF functions. The figure below shows an example of how to apply a main node to an intersection with links separated by direction of traffic flow. Note - Main Nodes are not a required network element. They only need to be consider if the network can not be simplified to only use one node to represent an intersection. If an intersection is represented with more than one node and that location can not be simplified to a single node, it's likely that Main Node treatment will be needed to properly represent intersection movements.
Overall, Main Node coding should follow the same guidelines as outlined for regular node intersections, using the Visum “ControlType” attribute to indicated signalized intersections, and adding turn lanes and modifying movements in the Main Node junction editor. However, Main Nodes do have added complexity. Some key editing guidelines include:
- Only include nodes directly associated with intersection movements within the Main Node boundary. Accidentally including any nodes that simply split links (shaping nodes) will prevent correct movement editing and result display after the run.
- Make sure that the control type is set to “unknown” for all nodes within the Main Node boundary. Only the Main Node is assigned the field control type (Signalized, Two-way Stop, etc.)
- U-turn movement are typically allowed by default for a main node on all approaches with multiple links. Unless the intersection allows for U-turns in real life, these allowed movements should be closed.
More detail on “Main Node” editing can be found in Section 15.20 (pages 1208 – 1231) of the PTV Visum 18 – Manual.
After editing the auto or non-motorized network, it is a good idea to check network connectivity. To do so, run the following steps:
- Go to Calculate + Network Check
- Unclick all the procedure except for Check network consistency between “All zones” for each transport system edited
- Run the procedure
- Click the ! to review the errors (i.e. OD pairs that are not connected)
- Close Calculate + Network Check
- Go To Graphics + Shortest Path Search (Network Shortest Path Search Check)
- Try to find a shortest path for the transport system edited for an OD pair that is not connected. Use distance for walk and bike and t0 for auto modes.
- Work from the origin zone or destination zone toward the other end of the trip to find the unconnected links, turns, or nodes.
- Repair the connection and repeat until all OD pairs are connected.
The highway network is shown in below, with a detailed view of Medford and Grants Pass also shown.
VISUM HIGHWAY NETWORK
MEDFORD HIGHWAY NETWORK
GRANTS PASS HIGHWAY NETWORK