Networks and Zone Data

The primary input for a scenario is the SOABM.ver VISUM master version file. This file contains the multiple zone systems, all zonal attributes, the highway network, and the transit network. Note that all dollar inputs are in $2010. The version file uses the following VISUM network objects:

1. Nodes – network nodes, with the attributes required in Node Attributes.
2. Main Nodes - network nodes representing intersections at arterials coded as one-way streets. See Auto Network Coding for details.
3. Links – network links, with the attributes required in Link Attributes. See VDF Definition for how link attributes are used in the volume-delay function.
4. Turns – network turns, with no required attributes except for setting TSysSet=empty for prohibited turns.
5. Zones – TAZS, with the attributes required in TAZ (ZONE) Attributes. TAZs in ABM are only used for auto 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.
6. Connectors – TAZ connectors, with TSySet and t0 (initial travel time) set. Only TAZ (auto) connectors are coded in the input file. The VISUM Python procedures code the MAZ and TAP connectors. Make sure to code nodes along walk and bike paths so MAZ connectors can be built.
7. Main Zones – MAZs, with the attributes required to run the ABM are stored in Mainzone (MAZ) Attributes. 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. The MainZone SEQMAZ field is calculated within the ABM run and is the MAZ identifying field exported to OR-RAMP as the MAZ ID due to a coding requirement in CT-RAMP where zone numbers need to be sequential. Therefore, the SEQMAZs must be numbered from 1 to X, with X equal to the number of MAZs, which is again handled internally within the code. The MainZone TAZ field is export to OR-RAMP as the MAZ’s TAZ. There are no external MAZs. The MAZ polygon needs to be drawn since the VISUM calculated attribute AreaMi2 is used for the MAZ area for the density measures.
8. Stop Points – Physical transit stops, with no required attributes.
9. Stop Areas – TAPs, with the attribute required in TAP (STOPAREA) Attributes. 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.
10. 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.
11. 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.
12. Line Routes – Transit lines, with a headway attribute for each time period Lineroute Attributes. 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 for more details on transit network coding.
13. 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.
14. 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.

Node Attributes

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).

Link Attributes

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
	SOVToll = Single-occupant toll vehicle
	HOV2 = High-occupant 2 person non-toll vehicle
	HOV2Toll = High-occupant 2 person toll vehicle
	HOV3 = High-occupant 3+ person non-toll vehicle
	HOV3Toll = High-occupant 3+ person toll vehicle
	Truck = All Trucks (note - the truck mode can be tolled in assignment, on the network, but the tolls will not impact destination choice or mode switching).
	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	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 $2010 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, see VDF.
MEDIAN	Type of median, to be coded by user. Median is used in the link capacity calculation, see VDF.
	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	TomTom speed 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.
FFSPEED	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]	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.
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.

TAZ (ZONE) Attributes

Field	Description
No	1-7 external; 100+ internal

Mainzone (MAZ) Attributes

Name	Description
NO	The MAZ number that the user interfaces with. The coding convention is the TAZ number followed by two digits. The first MAZ that falls in TAZ 101 would be 10101. The fourteenth MAZ to fall in TAZ 2387 would be 238714.
SEQMAZ	MAZ number for CT-RAMP. From 1 to N (number of MAZs). This field is calculated by the model procedures.
TAZ	TAZ number for CT-RAMP. Visum does not ensure that these TAZ numbers line up correctly with the TAZ numbers coded in the Zone layer. The user needs to ensure that these are kept up correctly. The TAZ numbers in SOABM follow a district series:
- RVMPO	100-1199 (last coded = 951)
- Other Jackson County	1200-1999 (last coded = 1356)
- Grants Pass	2000-2199 (last coded = 2172)
- Other Middle Rogue	2200-2299 (last coded = 2272)
- Other Josephine County	2300-2999 (last coded = 2393)
COUNTY	County, which is read by CT-RAMP
DISTNAME	District name, which is read by CT-RAMP
DISTID	District ID, which is read by CT-RAMP
	1=CENTRAL
	2=GrantsPass
	3=NORTHEAST
	4=NORTHWEST
	5=OtherJackson
	6=OtherJosephine
	7=SOUTH
EMP_CONSTR	Construction employment (NAICS 23)
EMP_WHOLE	Wholesale Trade employment (NAICS 42)
EMP_RETAIL	Retail Trade employment (NAICS 44)
EMP_SPORT	Sporting Goods, Hobby, Musical Instruments and Book stores employment (NAICS 45)
EMP_ACCFD	Accommodation and Food Services employment (NAICS 72)
EMP_AGR	Agriculture, Forestry, Fishing and Hunting employment (NAICS 11)
EMP_MIN	Mining, Quarrying, and Oil and Gas Extraction employment (NAICS 21)
EMP_UTIL	Utilities employment (NAICS 22)
EMP_FOOD	Food Manufacturing employment (NAICS 31)
EMP_WOOD	Wood Product Manufacturing employment (NAICS 32)
EMP_METAL	Primary Metal Manufacturing employment (NAICS 33)
EMP_TRANS	Transportation employment (NAICS 48)
EMP_POSTAL	Postal Service employment (NAICS 49)
EMP_INFO	Information employment (NAICS 51)
EMP_FINANC	Finance and Insurance employment (NAICS 52)
EMP_REALES	Real Estate and Rental and Leasing employment (NAICS 53)
EMP_PROF	Professional, Scientific, and Technical Services employment (NAICS 54)
EMP_MGMT	Management of Companies and Enterprises employment (NAICS 55)
EMP_ADMIN	Administrative and Support and Waste Management employment (NAICS 56)
EMP_EDUC	Educational Services employment (NAICS 61)
EMP_HEALTH	Health Care and Social Assistance employment (NAICS 62)
EMP_ARTS	Arts, Entertainment, and Recreation employment (NAICS 71)
EMP_OTHER	Other Services (except Public Administration) Religious employment (NAICS 81)
EMP_PUBADM	Public Administration employment (NAICS 92)
EMP_TOTAL	Total employment (a total of the 24 employment categories above)
ENROLLK_8	Grade School K-8 enrollment
ENROLL9_12	Grade School 9-12 enrollment
ENROLLCOLL	Major College enrollment (example SOU, attracts younger students)
ENROLLCOOT	Other College enrollment (Community College, attracts older students)
ENROLLADSC	Adult School enrollment (Trade School, attracts older students)
universitySqFtClass	Major university square footage classrooms, which is export for use by the major university student tour destination choice model
universitySqFtOffice	Major university square footage office, which is export for use by the major university student tour destination choice model
universitySqFtRec	Major university square footage recreation, which is export for use by the major university student tour destination choice model
ECH_DIST	Elementary school district. Used to constrain school location choice for K-8 students. Must have at least 1 MAZ with K-8 enrollment in each district. Numbers do not need to be sequential.
HCH_DIST	High school district. Used to constrain school location choice for 9-12 students. Must have at least 1 MAZ with 9-12 enrollment in each district. Numbers do not need to be sequential.
SCHDIST_NA	School district name. Name of district. Not used by code but can be useful for tracking\mapping.
SCHDIST	School district code. Not used by model but can be useful for tracking\mapping.
HOTELRMTOT	Total number of hotel rooms (not currently used, a placeholder field for a potential visitor model).
PARKAREA	Parking model code:
	0 - Unconstrained parking
	1 - Trips with destinations in this MAZ may choose to park in a different MAZ, parking charges apply (downtown)
	2 - Trips with destinations in parkarea 1 may choose to park in this MAZ, parking charges might apply (1/4 mile buffer around downtown)
	3 - Only trips with destinations in this MAZ may park here, parking charges apply (outside downtown paid parking, only show cost no capacity issue)
	4 - Only trips with destinations in this MAZ may park here, parking charges do not apply (outside downtown, free parking)
HSTALLSOTH	Number of stalls allowing hourly parking for trips with destinations in other MAZs. Note that number of stalls is used to calculate an average distance-weighted parking cost for each MAZ in mode choice, since the actual parking location is unknown when the choice of mode is made. Lots with more spaces will affect the weighted parking cost more than a lot with few spaces.
HSTALLSSAM	Number of stalls allowing hourly parking for trips with destinations in the same MAZ
HPARKCOST	Average cost of parking for one hour in hourly stalls in this MAZ, $2010 dollars
NUMFREEHRS	Number of hours of free parking allowed before parking charges begin in hourly stalls. A 0 indicates that parking charges begin immediately (most common).
DSTALLSOTH	Stalls allowing daily parking for trips with destinations in other MAZs
DSTALLSSAM	Stalls allowing daily parking for trips with destinations in the same MAZ
DPARKCOST	Average cost of parking for one day in daily stalls, $2010 dollars
MSTALLSOTH	Stalls allowing monthly parking for trips with destinations in other MAZs
MSTALLSSAM	Stalls allowing monthly parking for trips with destinations in the same MAZ
MPARKCOST	Average cost of parking for one day in monthly stalls, amortized over 22 workdays, $2010 dollars.
HH	Number of households. Note that this field does not need to be 100% consistent with synthetic population. It is used in destination choice model size terms and accessibility calculations.
POP	Total population. This field is used for accessibility calculations.
HHP	Total household population (exclude GQ pop) This field is used in CT-RAMP.
WRK_EXT_PR	Probability of working outside the region. Not currently used.
TERMTIME	Terminal time. Used in the code as a constant. Currently set to 2 in downtown (parking areas) and 1 minute everywhere else. If all zones get the same value, the impact of setting this input to a non-zero value should be minimal. CT-RAMP developers only advise using this variable if there are known terminal time differences in different areas of the model, example a down-town grid where travelers walk a few blocks to their vehicles.
PARKACRES	Park acres (active acres of park).
AreaMi2	VISUM’s zone polygon area attribute, which is used for density calculations

TAP (STOPAREA) Attributes

Field	Description
No	TAP number. From 1 to N (number of TAPs). This is not required to be fully sequential, but the code does run into issues if TAP numbers are too high, so the TAP numbers should be kept as close to sequential as possible, to ensure the model runs smooth and as fast as possible.
CanPnr	1 for park and ride available; 0 if not
FAREZONE	Linked is inputs\fares.csv. Any district identified in the from or to fare districts in "fares.csv" needs to be properly designated in the FAREZONE TAP attribute

Example fares.csv table

FROMFAREZONE	TOFAREZONE	FARE
GP	GP	100
GP	RV	200
RV	GP	100
RV	RV	200

Lineroute Attributes

Field	Description
EA_Headway	EA period headway in seconds (if route not available in the given time period enter 99999)
AM_Headway	AM period headway in seconds
MD_Headway	MD period headway in seconds
PM_Headway	PM period headway in seconds
EV_Headway	EV period headway in seconds

Time-of-Day Periods and Link Capacities

Time-of-Day	Description	Hourly Factor	VISUM Network Object
EA	3:00-7:00	4	Network\TOD_FACTOR_EA
AM	7:00-8:30	1.5	Network\TOD_FACTOR_AM
MD	8:30-16:30	8	Network\TOD_FACTOR_MD
PM	16:30-18:30	2	Network\TOD_FACTOR_PM
EV	18:30-27:00	8.5	Network\TOD_FACTOR_EV

Toll Coding Context

From Joel Freedman (RSG) 3-17-2020:

In SOABM, the mode choice models handle toll\non-toll choice. Its really toll eligibility; travelers in the SOV class can’t take a toll lane, travelers in the SOV-toll class might take a toll lane if it is a shorter generalized cost than the non-toll path. If you have a toll road, you would code it as SOV-Toll, and let the choice model see it as competition to the best non-toll path. Everyone who chooses toll would probably be assigned to the toll road, but some trips might detour around the road. This would be the same situation as a managed lane with a parallel free general purpose lane.

If you have a toll bridge which is unavoidable, you would code it as SOV and just put a toll cost on it. Then the SOV class would see it as the cost of using the bridge rather than as a separate choice.

Note that we’ve done a bunch more testing in San Diego and decided to simplify the choice models, taking out the toll\non-toll choice, and instead using value-of-time segmentation in assignment. We’ve found that the structure does a much better job of matching observed counts in the SR-125 toll road corridor than the previous model which used toll/non-toll choice.

Added context from Alex Bettinardi (ODOT) 4-10-20:

The truck demand segment comes from simpler models (that don't run through the ABM), those are;

• the External Model, and
• the Commercial Vehicle Model (CVM).

These models don't account for tolls, so there is just one demand segment for Trucks - Truck. It's not split into Truck and TruckToll, like SOV and the other auto modes are. If you want to code tolls for trucks, apply a toll to the Truck demand segment and the truck assignment will react to the cost of the toll. Truck demand (destination, mode choice, time of day...) will not react to the cost of the toll in the current setup.

Parking Coding Context

From Joel Freedman (RSG) 10-30-2019: (Context here - Alex Bettinardi is asking for a way to set a really high parking price to make a car free zone in a downtown)

Nobody would pay $100 or $1000 dollars a day – it’s not realistic, so we shouldn’t expect the model results to be reasonable with such inputs. Thus my advice not to put such costs into the model.

But, the model is capable of testing a “no-parking” zone. Here is how I would suggest testing such a policy: Define a parking constrained area as PARKAREA==1. Remove all the parking in this area, except for an outer ring where you add parking spaces at a reasonably high cost ($400/month, $25/day, $5/hour) – still within PARKAREA==1. The model would calculate a weighted cost of parking anywhere in the area as a function of the distance to the parking in the area and cost of parking in each area weighted by number of spaces. The cost would be fairly high and would strongly discourage auto trips to the area. You could make the PARKAREA 1 area even bigger and add even more peripheral parking. Unfortunately the model doesn’t have a weighted accessibility of walk/micromobility/transit for longer distance trips from very distant peripheral parking into the downtown core, but this would be fairly easy to introduce in the walk time calculator code.

I agree that the PARKAREA field is confusing. I’ve just looked over the code and noticed that some of the code that was created to represent different calculations between PARKAREA 1 and other PARKAREA types has been removed. I think we should just make this field (0,1), unless you think that there might be other parking types that don’t fit the example above that need to be represented.