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 MainZones 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.
- Main Nodes - network nodes representing intersections at arterials coded as one-way streets (or more complex intersections). See Auto Network Coding (link coming) for details.
- 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.
- Main Zones – MAZs, with the attributes required to run the ABM are stored in Mainzone (MAZ) 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. There are no external MAZs.
- 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, 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 a very large number such as 99999. Line routes code the sequence of links and stop points for each line. The lines are currently coded as round trip line routes due to the Google transit import. Line routes can be coded by direction if desired. 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.
Planned Values for the Metro Region
| Time-of-Day | Description | Hourly 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 |
| Field | Description |
|---|---|
| No | Link number, managed by VISUM. |
| Xcoord | X coordinate of the node |
| Ycoord | Y coordinate of the node |
| 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). |
| 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. |
| TSysSet | Allowed transport systems (i.e. modes, transit systems descriptions are found here): |
| SOV = Single-occupant non-toll vehicle | |
| HOV = High-occupant 2 person non-toll vehicle | |
| Truck = All Trucks (might split this into Medium/Heavy if needed by Metro) | |
| Bike* = Bike mode allowed | |
| Walk* = Walk mode allowed | |
| It should be noted that CT-RAMP uses TSysySet 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. | |
| Length | Link length in miles |
| V0PrT | Free flow speed |
| CapPrT | Currently the SOABM Description. Link Sectional Capacity (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. To help the user assess bottlenecks the minimum capacity (the minimum value where both mid-link and intersection approach capacities are considered) is stored for the given assignment period as one of the final model steps. This results in the user having access to an informative capacity value and resulting volume to capacity ratio in the final Visum version files. 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. |
| PlanNo | Facility type |
| 1=Interstate | |
| 3=Principal Arterial | |
| 4=Minor Arterial | |
| 5=Major Collector | |
| 6=Minor Collector | |
| 7=Local Road | |
| 30=Ramp | |
| Toll_PrTSys(DSEG) | Toll for each demand segment in $2025 dollars. See extra Note on how to code Tolls below. |
| 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. | |
| PROGRESSION_FACTOR | Set between a value of 0.5 and 1.2, default is 1. A value of 0.5 indicates a corridor where the signals are so well coordinated that the Uncongested Signal Delay (the delay imposed by the fact that there is an at grade crossing) is cut in half. 1 represents the average condition - isolated signals with no coordination. 1.2 would be a corridor so badly timed that the signals were adding 20% more delay to the system beyond the baseline condition of an isolated signal. |
| MID_LINK_CAP_ADJ | This value is a setting to allow the user to add local knowledge and judgement to the network. The default value is 0. A value of zero means no adjustment and the capacity is calculated using the input vdf_lookup_table.csv. A value greater than zero for specific links is subtracted from the value assigned by the lookup table. The capacity adjustment should never be over 500 for a given link. |
| [TOD]_Speed | I think this is fully removed for SimOR - I don't think we keep this. Base year observed speeds by time-of-day, used for initial skimming. If set to 0, the speed will be calculated by VISUM scripts based on the linkSpeeds.csv input table. Users should consider setting to zero in all future year scenarios. |
| Lanes_[TOD] | Lanes by time-of-day, which is set equal to NUMLANES by the time-of-day TAZ skimming and assignment procedures. This attribute does not need to be edited by the user. The code does not currently allow for the number of lanes to change throughout the day, but these fields were kept so that the functionality of having a different number of lanes by period could be quickly added back in. A question for the OMSC - do we want this kept in for scenarios like shoulder running in the peak? |
| FFSPEED | I think this is fully removed for SimOR - I don't think we keep this. Used to store and get V0PrT since V0PrT is overwritten by the initial TomTom speed skimming procedures. Cannot be coded by the user as it is updated during the model run. |
| Speed[Day] | I think this is fully removed for SimOR - I don't think we keep this. TomTom historic speed data. Does not need to be coded by user. Documentation field. |
| 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. |
| AUTO_COST | An internal calculation field for TAZ assignment in the ABM to hold distance and toll time penalties for the auto mode. Does not need to be coded by user. |
| TRUCK_COST | An internal calculation field for TAZ assignment in the ABM to hold distance and toll time penalties for the truck mode. Does not need to be coded by user. |
| 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