Skip to content

Bike Model

Brice Nichols edited this page Feb 19, 2019 · 4 revisions

Bike trips are adjusted in Soundcast by modifying the network with bike perception factors that affect assignment. The bike model includes two distinct portions:

  • network modification process, and
  • assignment and skimming.

Network Modification

Elevation change, bicycle provisions, and adjacent traffic volume and used to estimate a perceived travel cost along each network link. Work by Broach et al. (2012) in Portland provides the basis for a model that relates these three factors to perceived distance impacts. We use a simple elasticity calculation from this work to build a network attribute that represents considerations other than simple distance to assign trips. These attributes provide a more realistic representation of network conditions and provide a chance to test the impact of bike facility projects. Network modifications are performed on an Emme-formatted network. Slope calculations require a network shapefile. Soundcast contains these shapefiles in inputs/networks as an input for smoothing network links. A script is used to overlay an elevation raster with network links, calculating elevation at 10-foot intervals on each link. This process consumes quite some time, but only needs to be run once per network. The script produces an Emme attribute file (emme_attr.in) which is stored with other Soundcast inputs in the “bikes” directory. Currently the slope calculation script is housing in the psrc/travel-modeling/slope repository, and needs to be ported to Soundcast and error-checked. This script also attaches bike facility information to each link, based on the Bike Attributes table in the geodatabase. The Emme attributes file (emme_attr.in) contains two link attributes for the network (‘@upslp’ and ‘bkfac’). The first is directional upslope and the second is the numbered facility type, as defined in the geodatabase. Directional upslope is the total amount of incline in one direction along a link. It is not a simple sum of all increases and decreases between a node, but only a sum of the gained elevation. Thus, it measures the total amount of climbing that must be done along a link and disregards downhill travel. We do not consider downhill as a positive since there is no data on this from the Portland study on which we base our estimates.

Intersecting raster elevation and network data is a relatively simple, but time consuming process. It does require some cleaning after the fact to account for undesired representation of elevation changes across water bodies. Raster elevations represent changes under water, so bridge links appear to travel up and down the lake bottom or sea floor. To account for this we zero-out upslope on all bridges and ferry links. This is done using an intersection of a water body shapefile and the network shapefile, where slope values are amended programmatically. After this data is processed, a new file is created: emme_attr.in, which serves as the input to the assignment and skimming process.

Assignment and Skimming

The script bike_model.py performs all the assignment and skimming portions of the bike model, using ‘bike_configuration.py’ as a control file for input parameters. Part of the early processing of the script occurs on the daily emmebank because AADT is required for calculations, but assignment and skimming are currently only executed on the 7to8 time period.

The slope and bike facility attributes are imported into a project from the emme_attr.in attribute, which should be unique for each network. (This attribute file is created separately as described above.) The attribute file adds link attributes for directional upslope and a numeric bike facility type. Once imported, these values are converted to factors which calculate perceived travel distance. The factors are contained in the bike_configuration.py file and are currently based off Portland results. For slope, 3 tiers are defined based on the upslope.

Table 1: Slope Perception Factors, from Broach et al. (2012)

Link Elevation Gain Factor
2-4% 0.371
4-6% 1.203
>6% 3.239

The script separates links into these three bins and assigns each a factor, which will be combined with other factors to produce the perceived travel distance. The other additional factor is the bicycle facility type, which is calculated similarly, using the following bin definitions.

Table 2: Facility Type Perception Factors, based on Broach et al. (2012)

Bike Facility Type Perception Factor
Premium Off-street trail -0.160
Standard Painted Bike Lane -0.108
None 0

Note that we sorted PSRC facilities into designations of premium, standard, or none, since Portland and Seattle use different bike infrastructure designs and designations. The premium category represents optimal riding conditions for all ages and abilities, where riders are separated fully from vehicle and pedestrian traffic. Standard represents some basic facilities such as striped lanes. Notice that these factors are negative, suggesting that any mile traveled on a premium or standard facility would feel 16 and 10% shorter, respectively, than riding on a link with no bicycle provisions. The script adds a facility perception factor coefficient for each link, based on its type.

Finally, another coefficient is added for link AADT, to account for the influence of adjacent vehicle volume on the link. This is calculated using the following assumptions. These are only calculated for links with no bike facilities. It is assumed that links with bike facilities are unaffected by adjacent volume, though that may not be realistic.

Table 3. Auto Volume Perception Factors, based on Broach et al. (2012)

AADT Factor
10,000–20,000 0.368
20,000–30,000 1.40
>30,0000 7.157

Each link has a slope, facility, and AADT factor after this process. A perceived biking distance is then calculated by summing all these factors.

Weighting Calculation

The perception factors used by Broach et al. represent the relative values for different link attributes, but these must be modified for use in Emme. By Broach’s definition, a relative attribute value for links with slope between 2 and 4% is 0.371. This means that a person will equate 1.37 mile traveled on flat ground to 1 mile at 2 to 4% grade. In other words, someone would be willing to bike an additional third of a mile to avoid biking a mile on a moderate slope. All the perception factors used here can be interpreted similarly. Assuming that there are no interaction factors between the different attributes, the weights can be summed linearly, so the total perception factor on a link is calculated as such:

w_tot=w_facility+w_slope+w_volume (1)

However, in the original work, the standard street was taken to be a street without bicycle facilities, with low volume, and no slope. This means that links with bike facilities are given negative coefficients (representing links that feel shorter to ride). We cannot use negative values for assignment weights, so we need to normalize the results such that the base link type is the premium bicycle facility, on flat ground. The total weight calculation becomes this:

w_tot=-w_(premium_bike)+w_facility+w_slope+w_volume (2)

Where w_(premium_bike) is the attribute value of the premium bike facility. Thus, in the best case scenario, the perceived distance will equal the actual distance traveled. Total perceived travel time per link (tp¬) can be calculated from these results as follows:

t_p=t_0+t_0 (w_tot) (3)

where t0 is the shortest path travel time by bike. Note that the perception factors were estimated in terms of distance, but Emme assignment requires the factor in terms of time. Since the factors are relative, and represent percentages, it can be assumed that people would consider the time tradeoffs similarly to distance tradeoffs if a constant biking speed is assumed. In extended transit assignment, Emme uses a link weight for perceived travel time. To directly return a skim of perceived travel times between zones, it helps to rewrite (3) as follows:

t_p=t_0 (1+w_tot)

This is helpful because Emme calculated perceived travel time by multiplying a link factor by original travel time to derive perceived travel time. Thus, the input weight for Emme bike assignment is the total normalized link weight wtot plus one. This term (1 + wtot) is the bike weight that is exported as a link attribute @bkwt and saved as bwt.in and bike_attr.csv.

This attribute file is then read into Emme, which creates a new network bike weight for each link. This is the additional weight that people perceive when comparing links, relative to a base of a separated bike trail with no slope. In the bike assignment spec file, an auxiliary transit time perception factor is indicated as the link attribute @bkwt. Note that in Emme, non-motorized trips are assigned using transit assignment, and are considered “auxiliary modes.” Traditionally these modes were only used to access transit, but in this case since we only provide bike demand and no transit options, the assignment occurs only for bikes.

The total impedance is saved in a matrix called “bkpt”. This total impedance is the sum of perceived time and cost components, which in the case of traditional biking is simply the perceived travel time. The matrix name is shorthand for bike perceived time. In addition to this skim creation, an extended transit analysis produces additional skims. The actual auxiliary transit time is stored in the matrix “bkat” which represents the true travel distance and is shorthand for bike actual time. Note about using Broach study: Broach used these factors as portions of a route, we use them for a link-level analysis and assume the factors to apply in a binary way – either the entire link has a bike lane or it does not.

Assignment

Once all link attributes are computed and added to the network, bike demand is assigned using an extended transit assignment. Bike trips are assigned for all TOD where transit networks are available, since it is not possible to run a transit assignment (for bikes) without transit data, even if we are only evaluating the auxiliary transit mode. For now, these time periods include 6AM to 2PM

Clone this wiki locally