Intersection (Junction) Calculator Documentation

Introduction and Purpose of Intersection Modeling

This document briefly describes the intersection calculator functionality which has been added to the ODOT capacity calculator. The
purpose of the intersection calculator is to automatically generate a Voyager format junction file using link information that was coded
as part of the capacity calculator level of detail 3 update. By providing a junction file to a traffic assignment, HCM intersection
modeling procedures will be applied during each iteration of traffic assignment to the turning movement at the modeled intersections.
These models produce turn penalties which are applied to the next iteration. Thus the intersection modeling can be viewed as nothing
other than dynamic turn penalties. The benefit of this is a more accurate representation of system operation than is obtained from the
link based BPR style volume delay curves. Another benefit is the eventual capability to export Voyager junction information to
Dynasim to conduct operational level traffic microsimulation. Thus using only the LOD 3 information already coded to the 2000
networks, all the information needed to begin microsimulation would be in place.

Besides calculation of an intersection file there are a couple of other differences to the overall process that should be kept in mind.
When applying the intersection calculator, the calculated capacities will instead be saturation flow rates which should look very
similar to the uninterrupted flow capacities usually used in rural areas. These capacities are still used by Voyager to adjust link free
flow speeds during the assignment process, however, the adjustment wont be as great since the capacities will be higher (in urban
areas). The speeds written to the network when intersections calculations are selected in the calculator script will be run time speeds
rather than the total time speeds coded previously. The difference between the two is that intersection stop delay was removed from
the speed study data to compute the run times. If the speed calculator is run separate from the capacity calculator, it is important that
the RUN speed option be selected if intersection modeling will be desired. Finally, turn penalties typically wont be used when using
an intersection file. The turn prohibitor file is an input to the intersection calculator and are reflected in the intersection definition,
other turn penalties arent needed since they are redundant with the penalties that voyager calculates from the intersection model.

Use of Intersection Calculator

The intersection calculator is actually just a component of the latest version of the capacity calculator, CAP2000J. The latest
USER.TPL should reference this program versus the previous CAP2000T. If intersection modeling is not selected, CAP2000J will
give the same results as CAP2000T. The program was designed to be used with little additional training. No new link network
information is needed though coding intersection type (IXTYPE) which was previously not required under the LOD 3 standard will
greatly improve the results as discussed later. To use simply make sure you have the CAP2000J.EXE file in the directory where you
maintain the capacity calculator and download the newest USER.TPL into your CUBE directory. Then select the capacity calculator
or network calculator from the drop down on the CUBE Run-Process Template menu as before. The same options entry window will
come up as before with a few new options as shown below:

To run, type in the file names of your input/output networks and turn prohibitor files as normal. Enter an output turn penalty file only
if you wont use intersection modeling. If you will use intersection modeling, check the Use Intersection Modeling box. If this box
is checked, even if you type a turn penalty file name it wont be created. Next enter the output intersection file if you checked the
above box. You can also enter an input intersection override file which is a Voyager format ASCII junction file containing
intersections you have set up using the CUBE graphical intersection editor. There is a new field called optional count field for
INTYPE. If you specify a field here (such as AADT) then your coded counts in that field will be used by the calculator to help it
determine intersection type when it isnt coded. In the current version its main purpose is to determine which links have stop signs at
stop sign controlled intersections. Finally, if you have IXTYPE coded on your network and you want to use it, check the Use
Intersection Type check box otherwise the calculator will determine the intersection control based on the functional class comparison
and areatype (and optionally the counts). Thats it, run it as normal. Youll need an assignment script geared to using the junction file
which looks something like this (generally the model will be set up ahead of time for you to either have this or not):

RUN PGM=HIGHWAY
MATI="unity.mat"
NETI="lim03c.net"
JUNCTIONI=lim03.ind, N=1-9999, SET=2, PERIOD=1440
NETO="load.net"
JUNCTIONO=outputintersections.int
PHASE=LINKREAD
DISTANCE=LI.DIST
SPEED=LI.POSTSPD
C=LI.CAP24 * 1.0
ENDPHASE
 PHASE=ILOOP
PATHLOAD PATH=TIME, PENI=2, VOL[1]=MI.1.1
ENDPHASE
ENDRUN

Note that additional options not shown here can be accessed by scrolling this window down, however, they are unchanged from
previous versions and are not discussed here. One thing you may want to note, however, is that the capacity calculator program
should point to CAP2000J.EXE at the bottom as shown here:
How it Works

Its not the intent of this document to go into exhaustive detail on how the intersection calculator works, however, several notes are
necessary for the user to understand why it gives the results it does and how to properly code the network to achieve the desired
results.

The intersection calculator only calculates information for nodes that it considers valid intersections. Other nodes are left unmodeled
and because of this you should still use your turn prohibitor file with assignments to account for prohibitors at nodes that arent valid
intersection (you neednt remove the prohibitors for modeled intersections, the duplication doesnt hurt anything). A valid intersection
is a node which meets the following criteria:

Has 3 or 4 total links

Has 3 or 4 noncentroid links
Has at least 2 noncentroid entrance links (thus a one way link out from the node doesnt count)
Has at least one link of functional class 4, 5 or 6
At least one of those noncentroid entrance links has an IXTYPE other than 3 or all IXTYPEs are blank (thus if you want to
exclude an otherwise valid intersection node, code IXTYPE = 3 on all links entering that node or on 1 approach with all
others blank and it wont be treated as an intersection). Note the use of the second method to exclude the extra node at 5 way
intersections in the following figure.
The Voyager junction model requires that APPROACH1 be defined for each intersection. This approach is used for 2 purposes. First,
at 2 way stop controlled intersections it defines the major street. The approach1 link has no control at such an intersection. The next
link CCW has a stop sign, the next no control and the last (if any) a stop sign. It is a limitation of Voyager (and HCM methodologies)
that this is the only configuration, you cant for example, have 2 links in a row with stop signs and the next with no stop sign. The
other purpose of APPROACH1 is to define which link at a 3 legged intersection has through-right turning movements (and thus no
left). The remaining links are always numbered CCW from APPROACH1 in the junction model. To accommodate this definition, the
intersection calculator determines APPROACH1 as follow:

If its a three legged intersection, APPROACH1 is calculated based on the angles between links, it is the link 1 CW from the
link opposite the largest angle between the 3 links. This can then be over ridden by a functional class comparison, if 2 links
have the same functional class which is lower (better) than that of the third, then the link 1 CW from the higher (worse) link
is APPROACH1. If the optional count field has been specified and they are present on both the major and minor street then
APPROACH1 will be set similar to the functional class over ride as the link 1 CW from the lowest volume link. Finally, if
IXTYPE is coded, then APPROACH1 is the link 1 CW from a link (if any) with IXTYPE = 2. If 2 links have been coded
IXTYPE = 2 then the third will be APPROACH1. This calculation is made without regard to any centroid connector that
might be at the intersection and ramps and freeway links are considered arterials for the functional class comparison purpose.
If its a four legged intersection the link with the lowest (best) functional class is APPROACH1. In case of ties, the one with
the lowest ANODE/BNODE sort is selected. If the optional count field has been specified then APPROACH1 is either the
link with the highest count or the one directly opposite (it depends how the result of the previous test on functional class
came out, the count only causes a shift if the highest count is found on the minor street). It should be noted that the count
comparisons here and in the previous bullet are only made if nonzero counts exist on both the major and minor street and no
IXTYPEs are coded (in other words IXTYPE coding trumps everything else).
Either of the above two conditions can be over ridden if the selected APPROACH1 link is not IXTYPE 3 but some other link
is. In this case the last other link (by ANODE/BNODE sort) with IXTYPE 3 is selected as APPROACH1.

The Voyager junction model allows several types of intersections including: pretimed signals, adaptive signals, 2 way stop, all way
stop, yield (it calls these priority junctions) and roundabouts. In addition, for some of these types they provide 2 modeling methods, 1
based on HCM and one based on methods from Great Britain. The intersection calculator only uses 3 types: adaptive signals, 2 way
stop and all way stop. Adaptive signals is their terminology for actuated signals, however, this methodology also allows pretimed
signals to flex in the future since ranges of cycle length and green time are given to it. Thus this method was chosen over pretimed to
allow the signal timing to adapt to traffic conditions in the forecast years, the idea being that even if the signal is pretimed it will be
adjusted some time in the next 30 years if necessary. The intersection type for each node is selected by first looking at IXTYPE
coding. This part of the process is dependent on the IXTYPE on APPROACH1 only which resolves any inconsistencies in the
IXTYPE coding. Also, if the Use Intersection Type check box was not selected IXTYPE is set to 9 on all approaches which is not
used in this process. If IXTYPE was only coded on some links, it is possible that APPROACH1 will not have IXTYPE coded, in
which case the minimum value of IXTYPE from the other entrance links (excluding 2) is used. The process is as follows:

IXTYPE = 0 or 1 on APPROACH1, intersection=signal (if IXTYPE is 1 which indicates coordinated signals, the
RANDOMNESS parameter is changed which adjusts the platoon ratio for that approach only)
IXTYPE = 2 or 4 on APPROACH1, intersection = all way stop (Note that if any link at the intersection had IXTYPE 3 then
APPROACH1 would have IXTYPE 3 thus if APPROACH1 has IXTYPE 2 there is an inconsistency in the link coding which
results in the intersection being treated as all way stop). If some other link had IXTYPE 2 and APPROACH1 wasnt coded,
then the intersection is 2 way stop.
IXTYPE = 3 on APPROACH1, intersection = 2 way stop.

If the IXTYPE criteria is not met then the intersection type is determined based on functional class and areatype comparisons (and
possibly counts if used). For the purposes of this computation, the intersection areatype uses the following priority order: rural, cbd,
urban, suburban, thus if any link is rural the intersection is rural, all links must be suburban for the intersection to be. The process of
determining intersection type is as follows:

If the intersection is rural and the main road (defined by APPROACH1) is lower (better) functional class than the minor the
intersection is 2 way stop on the minor road.
If the intersection is rural with equal functional class and nonzero counts exist on both the major and minor streets then the
intersection is 2 way stop on the minor road, all other rural intersections are all way stop (ie those with equal functional class
where counts are not available).
 All nonrural intersections between local main and local minor are 2 way stop on minor if nonzero counts are available to
define the minor street, otherwise all way stop.
All nonrural intersections between collector main and local minor are 2 way stop on minor.
All suburban intersections between arterial main and local minor are 2 way stop on minor.
All suburban intersections between collector main and collector minor are 2 way stop if nonzero counts are available to
define the minor street, otherwise all way stop.
All others are signalized.

These functional class/areatype (and count) based intersection types were based on an analysis of the Toledo network which has
complete IXTYPE coding. The actual IXTYPEs were cross referenced by functional class and areatype and the most common type
chosen. One problem with this methodology, however, is that the all way stop cases above all had 2 way stops as the most common
intersection, yet in cases of equal functional class there is no way to determine which road should have the stop and which not. For
this reason, the count based method was added as an option for determining this. However, it is best if IXTYPE coding is be used to
correct this. Once the counts were added to the methodology, a test was made assigning intersection control type using sign and signal
volume warrants, however, in the Toledo and Lima tests it was found that there are about twice as many signals in reality compared to
what is warranted. Functional class was found correlate better with actual intersection control type with the counts simply used to
determine the major street once the control type was determined.

The lane configurations written to the junction file need some explanation. First, the 2 way stop intersection model does not use
precise lane configurations so information like turn lane coding is not used at those nodes. For the other types, the Lanes, IXTHRU,
TURNLANE and MEDTURN fields are used similar to their use in the original calculator. A difference, however, is that only
adjustments 1, 2 and 5 from the following list of lane adjustments made in capacity calculator are made to the junction lanes:

1. If IXTHRU not 0 then through lanes (TH) is IXTHRU, else TH is equal to LANES
2. If PARKING greater than 0, subtract PARKING from TH
3. If exclusive Rights (RT) >0 and there are no right turning movements from the link then if RT>TH, TH=RT and if exclusive
lefts (LT) = 0, LT=1
4. If LT >0 and there are no left turning movements from the link then if LT>TH, TH=LT and if RT = 0, RT=1
5. If MEDLANE =1 and LT=0, LT=1

Additional adjustments are made in the junction calculator itself as detailed below.

The capacity calculator only accommodated 1 exclusive turn lane in each direction and thus the TURNLANE coding reflected this
with the 0-3 coding representing no turn lanes, 1 left turn lane, 1 right turn lane and both left and right turn lanes. The intersection
calculator can accommodate multiple exclusive turn lanes thus an optional method of TURNLANE coding has been added. Five digit
turn lanes can now be coded where the first digit is the exclusive lefts, the second is shared left/though, the third is through, the fourth
is shared right/through and the fifth is exclusive rights. Currently only a maximum of 2 exclusive turn lanes and 1 shared lane in each
direction are supported. The old coding still works and the two can be mixed and matched. When five digit coding is used, none of
the capacity calculator adjustments listed above are used. In addition, LANES, PARKING, IXTHRU and MEDTURN are all ignored
when 5 digit TURNLANE is coded, however, LANES, PARKING and MEDTURN still affect the computation of saturation flow rate
and should thus be maintained, IXTHRU is not needed when 5 digit coding is used

The following adjustments are then made in the junction calculator itself to account for illogical lane coding (these adjustments are
made in the junction calculator rather than capacity calculator because it more accurately knows the allowed turn movements based on
the orientation of APPROACH1 defined earlier and the existence of one way streets and turn prohibitors):

If the total coded lanes is 1, its a single lane approach and it doesnt matter where you coded it.

If there is only 1 allowed turn movement all coded lanes are summed and become exclusive for that movement.

Example: the only movement allowed off a link is right turns due to the presence of one way streets, under the old coding LANES=2,
PARKING=1 and TURNLANE=1, thus available lanes is 2 1 + 1 = 2 exclusive rights, under new coding, user has coded
TURNLANE = 10112, there are thus 5 exclusive rights in this case.

If there is no left turn allowed (but through and right exist) and left (or shared left) lanes are coded, then if there were no right
(or shared right) lanes coded all lanes are simply shifted over 2 places (left becomes through, shared left/through becomes
shared right/through, and through becomes right). If there were also right (or shared right) lanes coded, then all left and
shared left lanes are added to through lanes. This same process occurs in reverse if there are no right turns allowed.
Example 1: Im coding into a T-intersection, I think the link to the right is the base of the T and thus through and right will exist so I
code 00102 for my 3 lane approach, however, the computer decides the other link is the base of the T so I really have through and left,
computer changes lane configuration to 10200.

Example 2, Im coding into a 4 way intersection but the link on the left isnt in the network, I code all the approach lanes anyway as
10201. The computer changes this to 00301 since lefts arent available. Notice that the total lanes coded is always maintained. Had
my configuration been 10200 in this case, the computer would change it to 00102 which probably isnt what I wanted, this points to
the need to properly include all approaches to any modeled intersection in the network.

If there is no through movement allowed (but there are left and right) and left (or shared left) lanes are coded but no right (or
shared right), then the through lanes are moved to exclusive right. The opposite occurs if rights are coded but not lefts. If
rights (or shared rights) or lefts (or shared lefts) are coded or both are coded, then the through, shared left and shared right are
summed and half are added to exclusive left and half to exclusive right with any remainder becoming a shared left. When
there are no through movements, the shared left field represents shared left/right instead of shared left/through, the shared
right field is not used.

Example 1, coded 00300 but no throughs, computer changes to 11001.

Example 2, coded 11201 but no throughs, computer changes to 21002.

Example 3, coded 11200 but no throughs, computer changes to 11002.

One last note about intersection lane coding, the default assumption is always that the furthest right through lane is a shared
right/through and the furthest left through lane is a shared left/through (unless exclusive turn lanes are coded). Thus, when using 5
digit turn lane coding, it is only necessary to code the shared left and shared right fields if a shared lane exists in addition to the
exclusive lane. Thus if I have an exclusive left and a shared right/through, I can code 10100 or 10010 and get the same result.

As noted previously, when the intersection has a signal it is modeled as an adaptive signal. The calculator uses a simple phase plan
that should suffice for 95% of intersections as follows:

Phase 1, Protected Left on Major Street (if exclusive left turn lanes on both approaches of major)
Phase 2, Right, Through, Permitted Left on Major Street
Phase 2 or 3, Protected Left on Minor Street (if exclusive left turn lanes on both approaches of minor, also note that the minor street of
a T intersection will never get a protected left phase)
Phase 3 or 4, Right, Through, Permitted Left on Minor Street

If other types are desired, over ride intersections would need to be coded using the CUBE graphical intersection editor. It should be
noted that the CUBE model does not allow nonsequential phases for a given turning movement so it is not possible to code this type of
phasing. Because the signals are adaptive, the amount of green given to each phase is variable. The calculator uses the following
ranges:

Cycle Length from 60 to 120

Through Phases from half the initially specified green time to 90
Protected Left Phases from 0 to 40

The initial settings determine the settings for the first iteration and are set according to the values of the cycle length and green ratio
parameters that are entered on the CUBE input form. These are the same parameters used by the capacity calculator. If the cycle
length is set outside the 60 to 120 range it will be set to 60 or 120 as necessary. If the input green ratios are lower than 0.25 or higher
than 0.75 they will be reset to these values. If the input green ratios on the opposing streets result in more green time than is available
from the cycle then they will be adjusted down to less than the cycle length. In all these cases youll get a message to this effect,
however, if you dont change the default capacity calculator parameters you wont need to worry about this.

Finally a note on ramps and centroid connectors. As noted previously, ramps (and freeways) are considered arterials for the purpose
of determining the functional class override at 3 legged intersections when determining APPROACH1, however, they are not used to
satisfy the criteria for having at least 1 functional class 4, 5 or 6 link to make an intersection. Ramps are considered lower than local
for determining APPROACH1 at 4 legged intersections to ensure that the ramps get the stop sign on 2 way stop intersections (unless
their IXTYPEs have been set up to over-ride this). Centroid connectors are not considered at all when determining APPROACH1.
This ensures that the major street will never include the centroid connector (actually almost never, there is a case where the 3 legged
intersection functional class over-ride would cause the link opposite the centroid connector to be APPROACH1 but it would be rare).
They are treated as local roads after that.

Once youve done the assignment using the intersection file, if you specified the JUNCTIONO file as shown in the script example
above, you can read this into CUBE using Intersection-Open Output Intersection File (you need to have your highway network active
when you do this). The HCM analysis of the intersection can then be displayed showing volumes (total period or hour), V/C ratios,
delays and LOS. Some examples are shown below:

Delay and Level of Service (this delay is the turn penalty being used by the model)
Daily Volume

V/C Ratio