Intersection (Junction) Calculator Documentation

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 won’t 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 won’t 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 aren’t 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 won’t 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 won’t 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 isn’t 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). That’s it, run it as normal. You’ll 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
It’s 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 aren’t valid intersection (you needn’t remove the prohibitors for modeled intersections, the duplication doesn’t 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 doesn’t 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 IXTYPE’s 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 won’t 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 can’t 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 it’s 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 it’s 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 IXTYPE’s 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 wasn’t 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 IXTYPE’s 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, it’s a single lane approach and it doesn’t 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: I’m 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, I’m coding into a 4 way intersection but the link on the left isn’t in the network, I code all the approach lanes anyway as 10201. The computer changes this to 00301 since lefts aren’t 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 isn’t 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 you’ll get a message to this effect, however, if you don’t change the default capacity calculator parameters you won’t 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 IXTYPE’s 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 you’ve 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