-
Notifications
You must be signed in to change notification settings - Fork 5
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:
- Nodes – network nodes, with the attributes required in Node Attributes.
- Main Nodes - network nodes representing intersections at arterials coded as one-way streets. See Auto Network Coding for details.
- Links – network links, with the attributes required in Link Attributes. See VDF Definition for how link attributes are used in the volume-delay function.
- 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. 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.
- 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.
- 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.
- Stop Points – Physical transit stops, with no required attributes.
- 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.
- 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. 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.
- 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.
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 | |
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. |
Field | Description |
---|---|
No | 1-7 external; 100+ internal |
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 |
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 |
FROMFAREZONE | TOFAREZONE | FARE |
---|---|---|
GP | GP | 100 |
GP | RV | 200 |
RV | GP | 100 |
RV | RV | 200 |
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 | 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 |
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.
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.
- Getting Started
- RunModel bat file
- Networks and Zone Data
- Auto Network Coding
- VDF Definition
- Transit Network Coding
- Non-motorized Network Coding
- Editing Land Use Data
- Running the Population Synthesizer
- Input Checker
- Analyzing Model Outputs
- Commercial Vehicle Model
- External Model
- Model Cost Inputs
- Value of Time
- Person Type Coding Logic
- MSA Feedback
- VMT Computation
- Shadow Pricing Mechanism
- Methodology for Developing TAZ Boundaries
- Methodology for Developing MAZ Boundaries
- Methodology for Developing TAPS
- Source of Land-Use Inputs
- Major University Model (Optional)
- Running Transit Everywhere Scenario
- Building the ABM Java Program
- Debugging ABM Python Code
- ABM Cleaning Protocol
- Updating to New Visum
- Troubleshooting and Debugging