16. Simulation Network Coding Example

Transcription

1 16. INTRODUCTION Section 6 is complemented here by means of examples on how to code each of the five types of intersections that can be handled by SATURN plus examples of coding centroid connectors Traffic Signals Figure 16.1 A Schematic Traffic Signal Assuming that node 44 sketched above represents a signalised intersection its coding for SATURN input might be as follows: X FIRST RECORD (RECORD TYPE 1) - NODE DESCRIPTION Cols. Nos. Input Remarks Node number 10 4 Number of links (N.B. This includes the out-bound only link to node 45) 15 3 Node type (traffic signal) 20 4 Number of signal stages Relative offset of first stage / Mar

2 Cycle time at this junction 35 0 Default value of NUC is selected here Minimum acceptable gap of 4.5 seconds blank Default value of GAPM used here. SECOND RECORD (RECORD TYPE 2) - DATA FOR THE LINK FROM NODE 45 TO 44 Col. Nos. Input Remarks Node at the other end of the link 15 0 Number of entry lanes equal to zero here means a oneway outbound road 20 0 * 25 0 * * Link times and lengths are not relevant for one-way streets nor is it necessary to code any information regarding turns which clearly do not exist. THIRD RECORD (RECORD TYPE 2) - DATA FOR THE LINK FROM NODE 16 TO 44: Col. Nos. Input Remarks 1 5 blank Stacking capacity for this link is to be estimated by default as 2 x 200 / ALEX (2 = lanes, 200 = dist A-node for this link 15 2 Two approach lanes Link free run time is 25 seconds The link is 200 meters from middle of 16 to middle of Left turn to node 43 is banned 31 blank No priority marker and 33 blank no lane specification needed for 35 blank missing turns Sat. flow for straight-ahead movement 41 blank No priority marker required 43 1 This turn can only be made 45 1 from lane Sat. flow for right turn to node X Opposed right turn 53 2 This turn can only be made from / Mar

3 55 2 lane 2. The fourth and fifth records contain similar data for each of the other two links to node 44 in clockwise order, i.e. 43 and 55. SIXTH RECORD (RECORD TYPE 3) - SIGNAL STAGE DESCRIPTION Col. Nos. Input Remarks This stage lasts 19 seconds followed by 20 4 an inter-green of 4 seconds duration Number of node entries to follow The movement is green As is the movement And the movement (N.B. The coding above could have been simplified by specifying 43 in cols. 29 & 30 and zero in column 35 as this would imply that all turns from 43 were green. In this case NGM in column 25 would be 2.) Records 7, 8 and 9 for this node contain similar data for the subsequent stages. The effect of the stage definition records is briefly as follows. During the first stage all three movements from node 43 are permitted, but after 19 seconds the straight- ahead and right turns go red. After a further 4 seconds a right filter arrow is displayed for turn , this display continuing for a further 10 seconds. Note therefore that the left-hand turn is continuously green for 33 seconds from the start of the cycle, i.e., it is green during the first inter-green period of 4 seconds. Since there are no common movements between stages 2 and 3 all displays must be red for 7 seconds. The inter-green time of 0 in stage 3 implies that stages 3 and 4 run smoothly from one to another, the only difference being that movement becomes red during stage 4. Finally since there are no common movements between stages 4 and 1 the 5 second inter-green period after stage 4 is red for all movements Roundabouts Considering the same junction sketch and assuming that node 44 represents a roundabout without U-turns we would code it as follows: / Mar

4 FIRST RECORD Col. Nos. Input Remarks 5 44 Node number 10 4 Number of links 15 2 Node type 20 4 It takes 4 seconds to fully circle the roundabout Maximum permitted flow at any point on the roundabout. 26 on blank Default values for LCY, NUC, GAPR and GAPM to be used at this node. The next four records (Record type 2) contain the link data for the four links as described in Since it is a roundabout records Type 3 are not required. Notes: 1) All turn capacities from a single link should either be equal to the link exit capacity or zero if they are banned turns. This is because the program assumes that all turning movements have equal entry onto the roundabout and hence that no one turn can have a greater capacity than any other. 2) Note that the roundabout capacity, 3600, is greater than any of the individual entry arm capacities. This will have the effect of always allowing some flow to enter from an arm even if the flow across the arm were at the nominal capacity of its entry arm. For example if there were an assigned flow of 3000 pcu/hr from node 43 to node 16 (with no cross flow at its entry point so that the actual flow would also be at capacity) entry from nodes 55 and 45 would not be entirely blocked. If however the maximum roundabout flow had been defined as 3000 there would be no entry permitted from either node. 3) The lane allocations are not in fact used yet by the program although it is anticipated that eventually they will be. 4) None of the priority markers refer to roundabouts. 5) Note that no stacking capacities have been explicitly given in columns 1-5; hence they will be calculated by default from the number of lanes, the link distances and ALEX. 6) Had the node been coded as junction type 5, roundabout with U-turns, no extra data would have been required on the link data records - the program would automatically generate U-turns to and from nodes 55 and 16 since these are 2-way roads. 7) The coding above would almost certainly generate a Serious Warning 138 because the saturation flow from 2 lanes from 16 is 1,700 whereas for two lanes from 43 it is 3,000; i.e., 850 per lane vrs 1500 per lane. While this is not an impossible on the ground situation it is unlikely that two different entry arms at the same roundabout would have such different saturation / Mar

5 flows per lane; i.e., they would be constructed with much more similar engineering design Priority Junctions Figure A Schematic Priority Junction To code node 5 as a priority junction one would proceed as follows: G G X 2 2 FIRST RECORD Col. Nos. Input Remarks 5 5 Node number 10 3 Number of links 15 1 Node type blank N.B.This field not used at all by priority junctions blank N.B.This field not used at all by priority junctions Cycle time of 50 seconds blank Use default value of NUC Replace GAP by 2.5 seconds SECOND RECORD Col. Nos. Input Remarks 1-5 blank Stacking capacity calculated by default 10 3 Link from node 3 to node Number of approach lanes Free run time Link length Saturation flow for turn / Mar

6 31 blank No priority marker; i.e., a major arm 33 1 This turn can only be made from 35 1 lane Saturation flow for turn blank which must also be from a major arm This turn can use either lane 1 (which it 45 2 shares with the other turn) or lane 2. THIRD RECORD Col. Nos. Input Remarks 1-5 blank Stacking capacity calculated by default 10 6 Link from node 6 to node Two lanes 20 7 Free run time is 7 seconds And the link length is 50 meters Saturation flow for turn G Turn is a give-way turn from a minor link First lane used by turn 35 1 Last lane used by turn Saturation flow for turn G This is a give-way turn out of link This turn can only use lane 2 FOURTH RECORD Similar to the above two; note that the X implies that the turn from node 4 toward node 6 is an opposed right turn off a major road and therefore gives way to turns and 3-5-4, but not to turns out of 6-5 which is a minor link / Mar

7 16.4 External Nodes Figure A Schematic External Junction Assuming that node 58 above represents an external node connected via a (2- way) road to an internal node 1 it might be coded as: FIRST RECORD Cols. Input Remarks Name of the node Connected to one other node External node blank No other data required SECOND RECORD Cols. Input Remarks Connection with node Link 1-58 has 1 lane, A travel time of 50 seconds, and Is 500 meters long blank No further data required. In this case one would expect either that node 58 would be directly connected to a zone via an external simulation centroid connector as illustrated in or that it would be part of the buffer network. But preferably not both! And certainly not just to another simulation node as this is a fatal error; see / Mar

8 16.5 Dummy Nodes Figure A Schematic Dummy Junction Assuming that node 5 is a dummy node inserted in the middle of the two-way road between nodes 4 and 6 it could be coded as: FIRST RECORD Cols. Input Remarks Name of the node entry links implies that 5 is a dummy SECOND RECORD Cols. Input Remarks 1-5 blank Stacking capacity to be calculated by default The link from 4 to 5 has a single lane a travel time of 50 seconds and a distance of 500 meters The first turn, i.e , exists with a (nominal) capacity of 1500 pcu/hr, and uses lane 1 only 35 1 The third record is similar in content to the second. Note that the capacities given for the turns - in this case just the straight ahead movements - are purely nominal since the model assumes no delays at dummy nodes, i.e., effectively an infinite capacity. However it is necessary to insert some positive value in order to identify permitted movements; a banned turn, presumably into a one-way street, would be identified by a capacity of / Mar

9 16.6 Simulation Centroid Connectors This section demonstrates the definition of simulation centroid connectors to represent three different situations: Zones connected to an internal link Figure A Schematic Centroid Connector The coded data under in this case would read: and would imply that zone 5 is connected to link (3,5). In terms of traffic movements the implication is that traffic TO zone 5 leaves from a point just beyond node 3 and that traffic FROM zone 5 enters the link at a point just before node 5, as indicated in both cases by the dashed lines. The effect is as though traffic were parking on the link somewhere between nodes 3 and 5. Note that in this case we have a zone numbered 5 (denoted by a triangle) and a node numbered 5. Since these numbers appear in quite different positions in the input the computer at any rate will always be able to distinguish them. Nevertheless the user may become confused by exactly what 5 does represent, so that the practice of having identical node and zone numbers is not necessarily recommended. (Although there might well be situations where the zone is very closely associated with one node so that it would be useful to give them the same numbers.) As indicated above link (3,5) is a one-way street from 3 to 5. The movements to and from the zone would be the same if (3,5) were a two- way street - a separate connector would need to be defined to allow for entry to the zone from node 5 and exit to node 3. In this case the coded data would read: However, were the link one-way in the opposite direction an error would result since in that case there would be no such one-way link as (3,5) / Mar

10 Zones connected to an external simulation link (22222) Figure A Schematic Centroid Connector In the diagram above we shall assume that 7 has been coded as an external node but that nodes 3, 6 and 5 are all internal, so that one might think of there being a cordon cutting link (7,6) with the simulated network of interest lying to the right. In this case the centroid connector may be defined under by either: or In either case it would be assumed that traffic from zone 5 enters the network at node 7 and proceeds along link (7,6), while traffic to zone 5 exits from node 7 after taking link (6,7). Note that in this case we are assuming that (7,6) is in fact a two-way link. Were it a one-way link in the direction 7-6 then only one centroid connector representing traffic leaving zone 5 would be created, and similarly if it were one-way in the opposite direction only the entry connector would be created. In such cases the link could be coded as either (6,7) or (7,6) since, having identified node 7 as external, the computer will make the appropriate checks as to whether the link is one-way. As above we use 5 to denote both a zone and a node, although in this case it would appear to be more sensible to denote the zone by 7 since that is the cordon point node at which it enters and/or leaves. Note that this configuration corresponds to a spigot centroid connector as described in section Zones connected to an External Simulation Link via a Buffer Node (33333) The (spigot) configuration depicted in Fig 16.6, where zone 5 is connected to an external simulation node 7, may also be achieved by including node 7 within both the simulation and the buffer network definitions with the actual centroid connector set within the data records, not the records. Thus node 7 would be included as an external simulation node within the records (possibly making use of AUTOX = T) while the data set would include a record such as: C 5 7. (times, distances etc. to follow) / Mar

11 No entry would be necessary under (Alternatively, and topologically equivalent, the link 7-6 could also be included in the buffer network rather than the simulation.) In this case zone 5 would be connected directly to a buffer node 7 which, in turn, would be connected via dummy links to the expanded sub-nodes (see Fig. 16.7(a) below) at both the upstream end of link 7-6 and the downstream end of 6-7. (We assume here that node 7 does not figure anywhere else within the buffer network data and that its only function is to facilitate the centroid connector.) External Simulation Zones: Differences between and 3333 In terms of the expanded assignment network representation the general situation when the external centroid connector is coded under is illustrated in Fig. 16.7(a). The expanded mini-nodes C1/C2/C3 represent the node C which is both an external simulation node and a buffer node (node 7 in Fig above), Z represents the zone (5 above) and A, the internal simulation node (5 above). Minilinks C 1 -C 3 and C 3 C 2 are the dummy links. The equivalent expanded network where the centroid connector Z-C has been included within the data is illustrated in Fig (b). Editoral correction: introduce nodes A1 and A2 at the left and Z on the right, plus change the directional arrow on the lower link. 16.7(b) would exclude C 3 and have direct links between Z and C1/C2. Figure 16.7A - Expanded assignment network representation of a combined external simulation and buffer node coded under Figure 16.8B - Expanded assignment network representation of an external simulation node coded under When viewed at the level of the map network (i.e, as plotted by P1X) both the and inputs would appear to be exactly the same (e.g., as in Fig. 16.6). In both cases traffic leaves the zone and enters the simulation network proper along link 7-6 and conversely, exits the network and enters the zone along / Mar

12 However there are subtle differences. Thus in Fig. 16.7(a), coding, it is possible for traffic to make (in effect) a U-turn A1 to C1 to C3 to C2 to A2. By contrast when the connector is defined within 22222, Fig. 16.7(b), node C 3 does not exist and direct links C 1-Z and Z-C 2 do not permit a U-turn at Z. Since, generally speaking, U-turns are undesirable the representation of Section is to be (strongly) preferred to an entry under It also worth noting that as the final link to the zone is in the buffer network, rather than the simulation network, any queued traffic travelling to this particular zone and held up in the simulation network will re-appear on the buffer link (see section 8 for more details on downstream flow metering that only occurs in the simulation network). There are also extra overheads created by having an extra buffer node within the assignment network and (up to) 2 extra assignment links; for example it increases the assignment CPU time necessary to build and load minimum cost O-D routes by, typically, a few percent. On the other hand it is easier using the records to ascribe specific properties of time, distance and, e.g., tolls to a centroid connector whereas the representation implicitly assumes zero time and distance. Note that this does not, however, apply to KNOBS data defined via an external file; see section Directionality of Spigot Centroid Connectors A further difference between coding centroid connectors to spigot links (e.g. the link 7-6 in above; see ) under or is that under the directionality (i.e., one-way or two-way) of the centroid connector is determined by the directionality of the link 7-6, whereas under the centroid connector may be either 1-way or 2-way as defined under Note that an error (Serious Warning 167) will occur if the directionality of the centroid connector( s) differs from that of the spigot link; e.g., an out-bound only centroid feeds a two-way spigot link. The error occurs whether the spigot link is part of the simulation or the buffer network Zones representing Internal Parking Lots It is often useful to recognise that external nodes such as node 7 in need not be physically external, only conceptually external. Thus zone 5 might in fact represent an internal parking lot fed by link (7,6). If the link were one-way from 6 to 7 then this would represent a one-way entrance, and presumably there would have to be another connection defined to represent the point of exit from the car park. Finally we notice that if all the links in are two-way and 5 is indeed an internal car park then the codings illustrated in and are roughly equivalent since in both cases traffic entering zone 5 does so by leaving node 3 in the direction of node 5 while traffic leaving zone 5 appears at node 5 in the direction from 3. Indeed in some circumstances a car park off link (3,5) could be adequately coded as in Where the two representations differ is that allows explicitly for delays to traffic at the entry/exit to the car park, node 6, and / Mar

13 defines the point of entry/exit much more precisely than This extra precision is very often useful if, for example, one has counts on the entry/exit flows at the car park which one wishes to use to estimate the trip matrix using SATME2. In one cannot unambiguously associate these flows with a link, in one can. This form of coding also allows one to assign a time to link 6-7 to represent, say, a parking charge on entry, or even to assign a link capacity-restraint curve as described in Sections and respectively. Another example of a case where one might wish to use the more precise location of zone connectors would be where link (3,5) was a relatively long link with exit/entry mainly near one end. A further disadvantage to the internal style connections is that the actual flow on (3,5) is underestimated by ignoring the beginning and ends of trips. Again, if the link is a particularly long one, this may lead to significant understating of travel times and distances. See Section (An alternative, and in some respects simpler, coding solution to the above problem is to code two dummy nodes in the middle of a long link with a very short dummy link in between to which the zone is connected.) 16.7 Motorway Links The SATURN simulation routines were not originally designed with motorwaystyle roads (i.e., divided highways with grade- separated entries and exits) in mind, since such roads are not common features in networks to which traffic management techniques are usually employed. However it is possible to include them in SATURN simulation networks, although the level of accuracy is probably not as good as with other types of roads and junctions. The following points are suggestions as to how best to handle motorway links in simulation (as opposed to buffer) SATURN networks: 1) While not absolutely essential it is much simpler to code divided motorways as two distinct series of one-way links with one node at each entry and exit point. 2) Each node on the motorway will therefore almost certainly have 3 one-way arms - the motorway entering, the motorway leaving and the exit/entry arm. The node should be coded as a priority junction with only 2 out of the 6 possible turning movements given positive saturation flows - i.e, the turn from the entering to the exit motorway and the turn from the entry slip road onto the motorway (or the converse for an exit). Entering traffic would normally be coded as a merging movement (with no priority marker for the on-motorway flow), while an exit junction would normally have no priority markers on all turns. 3) Separate links need to be defined to represent the entry/exit arms with one end at the 3-way motorway node and the other at a normal intersection. Again these should all be one-way links. 4) Since the cruising speed/travel time on all links is assumed to be fixed within SATURN independent of flow these inputs should be selected to allow for the expected assigned flow, not set at the maximum or free-flow speeds / Mar

14 Thus if the user anticipates (or observes) speeds of, say, 50 km/h on a motorway as opposed to say the speed limit of 100 km/h he should use the former value. Alternatively one may use the option to define link speed-flow curves (6.4.12) to represent the relationship between speed and flow on the motorway link (as distinct from junction delays); indeed this facility was created largely with motorways in mind. 5) Weaving sections between a motorway and a slip road (joint entry and exit) may be modelled using a W turn priority marker; see / Mar

15 16.8 Version Control JOB NUMBER: DOCUMENT REF: Section 16.doc Revision Purpose / Description Originated Checked Reviewed Authorised Date 1 Re-formatted (Final to DVV) TF / BG NS IW IW 06/05/06 3 Upgrade to V2 Template IW 22/06/ Web release Sept 06 DVV NP IW IW 08/09/ Web release Jan 07 DVV NP IW IW 04/01/ SATURN v10.7 DVV NP IW IW 12/03/ Web release Jul 07 DVV NP IW IW 19/07/ SATURN v10.8 Release DVV NP IW IW 26/01/ Web release Jul 08 DVV NP IW IW 07/07/ Web release Dec 08 DVV NP IW IW 12/12/ Web release Feb 09 DVV NP IW IW 16/02/ Web release Jun 09 DVV NP IW IW 16/06/ SATURN v10.9 Release DVV DG IW IW 04/09/ Web release Jun 10 DVV NP IW IW 22/06/ Web release Dec 10 DVV AG IW IW 06/12/ SATURN v10.9 Release (Full) DVV AG IW IW 13/05/ SATURN v11.1 Release (Full) DVV AG IW IW 31/03/ SATURN v11.2 Beta Release DVV JS IW IW 07/12/ SATURN v11.2 Release (Full) DVV JS IW IW 17/03/ SATURN v11.3 Release DVV EN IW IW 31/03/ / Mar