Network Management

BKRCast employs Python scripts to generate EMME databanks for various time periods from the ground up. This process involves the creation of EMME databanks, the establishment of EMME project folders (and files), and the subsequent construction of EMME models. The code imports networks, attributes, and extra attributes, such as traffic counts, into the databanks to form a comprehensive modeling framework.

The network files, encompassing attributes, functions, and traffic counts, are essential components of the network input files. These files, in conjunction with other relevant data, collectively constitute BKRInputs, supplying the necessary input information to BKRCast. All input files are stored within base_inputs folder.

To ensure consistency across different horizon year and scenarios, we have opted to manage the auto, transit, and non-motorized network within a centralized EMME database known as the 'network master database'. All upcoming projects, irrespective of their opening year, are categorized under a single scenario. Project attributes are meticulously documented, capturing both current values (prefixed with @exist_) and improved values (prefixed with @imp_).

For any modifications to the model network, the established protocol involves accessing the master database. Subsequently, the Populate Network and Export Extra Attributes tool, designated by EMME modeler, are employed. These utility tools effectively generate network input files and attribute files for various time periods. In essence, any modifications to the model network are centralized in the master database, and the Population Network tool is then executed and followed by Export Extra Attributes to produce a new set of network and attribute files accordingly. This streamlined process ensures that the network remains synchronized across different temporal scopes and scenarios.

Network Master Database

Currently the future projects including CIP and TFP projects have been incorporated into the master network database. Several link extra attributes are used to store the existing conditions and the future improvements. The following table lists those attributes.

Data	Existing Attribute	Improvement Attribute
lanes	@exist_lanes	@imp_lanes
lane capacity(ul1)	@exist_lanecap	@imp_lanecap
vdf	@exist_vdf	@imp_vdf
speed (ul2)	@exist_speed	@imp_speed
@tolllane	@exist_hot	@imp_hot
@biketype	@exist_biketype	@imp_biketype
tpf	@exist_tpf	@imp_tpf
up1 (turn standard attribute1)	@exist_turn_lanes	@imp_turn_lanes
up2 (turn standard attribute 2)	@exist_turn_factor	@imp_turn_factor

notes:
up1 and up2 are used in turn penalty functions.

Other relevant attributes are listed below.

Attribute	Description
@bike_year	bike facility project year (for non-motorized only)
@project_label	project label
@project_year	project year (for auto mode only)
@turn_project_year	turn project opening year

@tolllane/@exist_hot/@imp_hot values:
1: I405 north section, leaving Bellevue downtown
2: I405 north section, going Bellevue downtown
3: I405 south section, leaving Bellevue downtown
4: I405 south section, going Bellevue downtown
5: HOV
6: HOV2+ free (for SR167)

Node

When creating a new node, need to make sure the following attributes are correct:
@bkrnode

Links

When creating a new auto link, need to make sure the following attributes shouldn't be zeros, or have blanks or default values):
@exist_vdf, @imp_vdf, length, mode, type, @class
@exist_lanes, @imp_vdf @exist_speed, @imp_speed
@exist_lanecap, @imp_lanecap
@exist_biketype, @imp_biketype

the following attributes, in general, should be zeros, unless we have counts on that specific link:
@slid, @slcnt_pm_2014, @slcnt_am_2014, @slcnt_pm_2018, @slcnt_am_2018
@local_cnts_pm_2014, @local_cnts_am_2014, @local_cnts_pm_2014, @local_cnts_am_2018
@slcnt_md_2014, @local_cnts_md_2014
@kirkland_slid
@red_tube_cnt_tag, @red_tubecnt_am_2018, @red_tubecnt_pm_2018
@revlane, @revlane_cap
@rdly

values of the following attributes are dependent on locations:
@bkrlink, @subarea, @belcbd, @exist_hot, @imp_hot

Coding for bike trail

Mode of bike trail needs to be wk. @exist_biketype and @imp_biketype cannot be zero at the same time.

Attribute for Flagging CIP & TFP Projects

@cip_tfp and @bike_cip_tfp	Description
1	CIP
2	TFP
3	unfunded projects
99	unfunded project but excluded when populating unfunded projects.

notes: The project completion year can refer to @project_year for auto modes and @bike_year for bike facilities.

Transit Line

A comparable approach is employed in transit line coding to encompass all forthcoming transit lines. The pertinent attributes for transit lines are outlined below. This ensures a consistent and systematic method for incorporating future transit developments into the modeling framework.

Attribute	Description
ut1	AM headway
ut2	MD headway
ut3	PM headway
@nihdwy	NI headway
@tstart	start year (data valid from and including this year)
@tend	end year (data valid up to but not including this year)

@tactive is only used for flagging transit lines that would be active in horizon year when network is populated, and there is no need to manually update its values.

Base Year

The existing condition, denoted as Year 2014, serves as the reference point. As future projects emerge, they should be encoded in the master database, incorporating the specified attributes.

VDF

To ensure that VDF remains nonzero, the @exist_vdf value for a link created in a future year should be set to 24. VDF 24 guarantees a sufficiently high travel time, preventing any trips from being assigned to those links.

Reversible Lanes on I-5

It is important to note a slight variation in the auto network across each time of day, primarily attributed to the presence of I-5 reversible lanes, The attribute @revlane serves to flag these reversible lanes, with 1 indicating northbound and 2 indicating southbound.

Link Shape

The coding of link shape is imperative for accurate representation in the model. All these considerations collectively contribute to a comprehensive and nuanced modeling approach.

Network Files

File	Description	Inputs Folder
am_transit.in	AM transit network	[base_inputs]/networks
md_transit.in	MD transit network	[base_inputs]/networks
pm_transit.in	PM transit network	[base_inputs]/networks
ni_transit.in	NI transit network	[base_inputs]/networks
am_roadway.in	AM roadway network	[base_inputs]/networks
md_roadway.in	MD roadway network	[base_inputs]/networks
pm_roadway.in	PM roadway network	[base_inputs]/networks
ni_roadway.in	NI roadway network	[base_inputs]/networks
am_linkshapes.in	shape file for AM roadway network	[base_inputs]/networks
md_linkshapes.in	shape file for MD roadway network	[base_inputs]/networks
pm_linkshapes.in	shape file for PM roadway network	[base_inputs]/networks
ni_linkshapes.in	shape file for NI roadway network	[base_inputs]/networks
am_turns.in	AM turn penalty file	[base_inputs]/networks
md_turns.in	MD turn penalty file	[base_inputs]/networks
pm_turns.in	PM turn penalty file	[base_inputs]/networks
ni_turns.in	NI turn penalty file	[base_inputs]/networks
sc_headways.csv	transit headway file (including headways for four time periods)	[base_inputs]/networks
transit_stops.csv	stops locations for transit submodes bus, ferry, commuter_rail, light_rail, and express	[base_inputs]/networks
vdfs6to9.txt	VDF file for AM	[base_inputs]/vdfs
vdfs9to1530.txt	VDF file for MD	[base_inputs]/vdfs
vdfs1530to1830.txt	VDF file for PM	[base_inputs]/vdfs
vdfs1830to6.txt	VDF file for NI	[base_inputs]/vdfs
vehicles.txt	vehicle definition file	[base_inputs]/networks

The network input files should be copied to [base_inputs].
Attributes can be exported by another utility Export Attributes. The attribute list is here.

Exceptions:

1. As of EMME 4.3.5, outputs from function export tool cannot be imported back by import tool. INRO is aware of this problem and a fix is coming in the upcoming update. Before the fix, EMME console mode should be used to export functions.