Share

Main Window - Menus

Parameters Menu

Terms

A Term is a named window in time. It has:

  • a start time, normally specified as HH:MM

  • an end time, also normally specified as HH:MM

  • a day of the week, by default “Any Day”, but can be something more specific.

    A Term is “on” or applicable for any time between these end points on a matching day. The day can be a particular day or it can be a day type (weekday or weekend). The association of a day can be useful, for example, if you want to define a demand for a weekday and a different demand for the weekend. When you run the simulation, or generate trips, the Terms associated with profiles or other time-varying functions will be checked to ensure you have all the correct simulation components enabled for any particular run. You can have as many Terms defined for your network as you require. They can overlap, or be sequential. A lane restriction can be defined to have one term (for example “buses only” defined for 07:30 to 09:30) while a demand profile is defined to have another (for example “AM Peak” defined for 07:00 to 10:00). There are two special terms, which are always present:

  • Always – Where a term is required, selecting Always ensures that the parameter to which the term is attached applies all the time, even if the simulation term is changed. The Always term cannot be modified.

  • Simulation – This is editable, although the name cannot be changed. This term defines the start and the end of the simulation period.

Behaviors

A Behavior defines a number of parameters, controlling decision made by each person. Behaviors are assigned to person-types; each person generated has one of these types.

A group of Behaviors is called a Mob (Mix Of Behaviors), and this is described at the end of this section. The Mobs window can be accessed by a button at the bottom of the Behaviors window

Behaviors are also associated with Vehicle Types, but this is relevant for the following types of Vehicles only:

  • Taxis
  • Drop-Off Vehicles
  • Pick-Up Vehicles
  • Zone to Zone (background traffic) vehicles
  • For other Vehicles, the Behavior is adopted from the Person that gets into the Vehicle and becomes the driver.

Separating Behavior from the Type of the Person or Vehicle allows you to separate the physical constraints from behavioral constraints. For example, you could define an aggressive behavior and a passive behavior, and then go on to associate each of those behaviors with a range of physical vehicle types, such as car, van and truck.

Another advantage of separating behavior from physical constraints is that the Behavior can be retained when modeling a multi-stage journey. For example, if a journey is made up of a car trip followed by a pedestrian trip (walking from the car park to the station) followed by a public transport trip, all three trips can be modeled using an agent with a consistent behavior See the help on Types for more information on assigning Behavior to Types.

The Behaviors window is divided into several tabs, as described below.

Mode Choices Tab

This tab contains the “master switches” that control which modes are available to each behavior If you want to define a behavior that will always drive, rather than taking public transport, then this is the place to do it. Similarly, you can define behaviors for people who prefer to cycle, or take a taxi, or are lucky enough to have someone available to drop them off at their destination. The switches available are:

  • Can Walk: True if a person of this behavior can use walking as a mode of travel in the model.
  • Can Drive: True if a person of this behavior can drive to a parking zone or a transition zone in the model.
  • Can Ride: True if a person of this behavior can take public transport
  • Can Taxi: True if a person of this behavior can take a taxi, if taxis are available. Even if this is true, the cost of taking a taxi will still be taken into account in the calculation of the lowest-cost route to the destination. Setting this to false will rule out the option of taking a taxi.
  • Can Cycle: True if a person of this behavior will cycle, and a cycle vehicle type exists
  • Can Be Dropped Off: True if a person of this behavior can be dropped off at a designated drop-off zone. This implies that this person has a car and driver available to drive them to their destination, and thus will not need to spend money on parking. This may often be the cheapest option for traveling to a destination with pay parking, but in many cases only a small fraction of the population will have a car and driver available to them.
  • Can Be Picked Up: True if a person of this behavior will be picked up at a designated pick-up zone. If this flag is True then no other mode will be considered (apart from walking from the origin to the point of pick-up).

Walking Costs

  • Can Walk: True if a person of this behavior can use walking as a mode of travel in your model.
  • Walk Cost per second: The value of time for walking, specified in small currency units (pence, cents, etc.) per second.
  • Walk Cost per distance: The value of distance for walking, specified in small currency units (pence, cents, etc.) per long distance unit (km, mile).
  • Walk Cost Base: a base walk cost, used to bias short trips against long ones.

Driving Costs

  • Can Drive: True if a person of this behavior can drive to a parking zone or a transition zone in the model.
  • Drive Cost per second: The value of time for traveling in a private vehicle (car, van, truck, etc.) The cost value is specified in small currency units (pence, cents, etc.) per second.
  • Drive Cost per distance: The value of distance for traveling in a private vehicle, specified in small currency units (pence, cents, etc.) per long distance unit (km, mile).
  • Drive Cost Base: a private vehicle cost, used, for example, to model the base cost of ownership

Transport Costs

  • Can Ride: True if a person of this behavior can use public transport as a mode of travel.
  • Ride Cost per second: The value of time for traveling on public transport, specified in small currency units (pence, cents, etc.) per second.
  • Ride Cost per distance: The value of distance for traveling on public transport, specified in small currency units (pence, cents, etc.) per long distance unit (km, mile).
  • Ride Cost Base: a base public transport cost, used, for example, to model the base fare payable.
  • Wait Cost per second: The value of time for waiting for on public transport, specified in small currency units (pence, cents, etc.) per second

Parking

  • Park Duration: A time, in hours, used to calculate the cost of parking. The premise for this parameter is that a person with this behavior is planning an outward-return journey, and intends to park for the specified duration. For example, a person working in a city center may park for 8.5 hours during a working day. A business traveler going to an airport may be staying at their (air) destination overnight, and be planning a stay of 36 hours at the airport, from 07:00 Monday to 19:00 Tuesday.
  • Parking Vehicles: A (demand) division of vehicle types to use when selecting from parked vehicles. A demand division has % values to generate vehicles in proportion when there are no parked vehicles to choose from in a "normal" parking zone the zone is a transition zone or an instant parking zone
  • Optimist: if this is on, the driver will always assume that there is still a free bay in the most popular area. If it is off, the driver will take the first available space

Driving

  • (Speed) Compliance: A multiplier, by default 1.0. This is used for vehicles to specify the “perceived” speed limit on any road. Multiply the signed speed limit by this parameter to obtain the perceived speed limit that will be used as the maximum speed a vehicle will attain if unconstrained by other vehicles or lane geometry.
  • Minimum Gap: A distance, in meters, used to specify the minimum spacing between stationary vehicles in congestion.
  • (Target) Headway: a time, in seconds. This is used in the vehicle- following algorithms
  • Reaction Time: a time, in seconds, used in the vehicle-following algorithms
  • Safety Margin: used to calculate stopping distance. The absolute minimum stopping distance is derived from current speed and (constant) maximum deceleration is multiplied by this safety margin.
  • Lane (Change) Gap: a time, in seconds, used for the lane changing algorithm. A larger value means that a larger gap will be required, making lane changing more conservative. A smaller value for lane changing gap will make lane changing more aggressive.
  • Variability: a number between 0.0 and 1.0. The variability of: (speed) compliance, reaction time, target headway and minimum gap distance defined in terms of standard deviations relative to the mean. So a value of 0.1 would mean that a distribution would have -1SD to +1 SD from 0.9x mean to 1.1x mean. Set this to a non- zero value to make the behavior of your agents less uniform.

Routing

  • Drive Spreading: for road routes, the relative increase in cost of an alternative route over the least cost route that an agent may consider acceptable in choosing a route [Sometimes referred to as the “perturbation” value.]
  • Walk Spreading: as for Drive Spreading, but for walkway routes
  • Cost of price: the perceived value of money for any agent with this behavior This is applied to any tolls or other charges along the length of the route before these are included in the generalized cost equation.
  • Dynamic Routing: If this is on, then any agent with this behavior will receive cost feedback updates, if cost feedback is enabled in the appropriate routing window (Assignment → Vehicle Routes or Assignment → Person Routes). You might use this to model two sets of vehicles; one whose drivers receive updates during their trips (perhaps by radio) about the state of the traffic, and another whose drivers have a static view of the cost information on the network.

Temperament

  • Aggression, Awareness, Patience, Familiarity: Values in the range 0 to 100%, by default 50%. These are not used in the core algorithms, but are available to the API for use in plug-ins.

Restrictions

A Restriction is applied to a surface (a lane or a walkway), in order to control the types of people or vehicles that move on that surface. The people or vehicles are selected for a restriction by behavior A related concept is that of a Speed Control which applies only to roads, and selects vehicles by behavior. A Restriction has the following fields:

  • Name: A numeric name for the restriction which is created automatically and is unique.
  • Description: A descriptive name for the restriction, of any length, which need not be unique, but for clarity, a unique description is better.
  • Color: A Color for the restriction, used when the appropriate Feature is enabled in the Layer Pane.
  • Term: A time period defining when the restriction applies.
  • Mob: A single behavior or group of behaviors to which the Restriction applies.
  • Permission: Either Barred, Allowed or Mandatory. This setting means that you can create a restriction to bar all behaviors in the mob or to allow all behaviors in the mob. Mandatory applies to lanes only, and forces all behaviors in a mob to use that walkway or lane, even if alternatives exist. Thus you can create a bus lane and make it mandatory for bus drivers to make sure that all buses drive in that lane.
  • Pocket: (Roads Only) A distance from the end of any lane at which any vehicle may use the lane. For example, if the left hand lane is a bus lane, but pocket is defined as 50 meters, left-turning cars may use that lane for the last 50 meters before the stop line. To create a restriction for a group of behaviors, you must first create a Mob to give a name to the selected group of behaviors If you want to apply a restriction to a single behavior, it is likely that a Mob containing only that behavior already exists, as one is automatically created, with the same name, when a behavior is created. For example, to create a "Staff-Only" restriction:
    1. In the Behaviors window, create all the behaviors you wish to
    2. model. For this example, assume you have six behaviors,
    3. A,B,C,D,E and F, but only types C & D are classified as "Staff"
    4. create a Mob named “Staff” containing behaviors C & D
    5. create a Restriction and change the Description to “Staff-Only”
    6. set the color for this restriction
    7. if the restriction applies only at certain times, select a term for the
    8. restriction, otherwise leave this at “(Always On)”.
    9. under “Mob”, select “Staff”
    10. under “Permission”, select “Allowed”

You could create an equivalent restriction by creating a Mob called "non- Staff", containing behaviors A,B,E & F, and then creating a restriction where Mob=non-Staff and Permission=Barred

Speed Controls (Variable Speed Limit)

A Speed Control can be applied to a lane to change the speed limit on that lane, by user class, or by time of day. Each has several fields:

  • Name: A unique number, created automatically, not editable
  • Description: A descriptive name, of any length, which need not be unique, but for clarity, a unique description is better.
  • Color: A color, used when the appropriate Layer is enabled in the Layer Pane.
  • Term: Start, end and day of operation.
  • Mob: The behaviors to which the speed control applies.
  • Speed: The speed limit that is applied

It is normally the case that you would set either a Mob or a Term for a Speed Control, or both, so that it applied only to some of the vehicles in the simulation, or only for a part of the simulation period. If neither of these are set, then the speed control will be applied at all times, to all vehicles, which is the same effect as changing the speed limit directly for that lane. There are some standard speed controls defined, which have neither field set, but these are intended for use by tools or plugins, where some external logic would apply a speed control at a specific time. For example, the Lane Control plugin uses this functionality to implement managed motorways.

Vehicles (Vehicle Types)

Each vehicle in the model has a Vehicle Type. The Type specifies parameters which control the size, the movement and the display of the vehicle in the model. A group of Vehicle Types is called a Fleet. Fleets are described in more detail at the end of this section. The Fleets window can be raised using a button at the bottom of the vehicle types window. The simplest Traffic Analyst model uses a single private vehicle type, the standard car. However, any model that includes goods vehicles will need at least one other type for a generalized truck. More commonly, a model will have several vehicle types defined, a typical set would include:

  • Small Car
  • Medium Car
  • Large Car
  • Van
  • Small Truck
  • Large Truck
  • Cycle
  • Motorbike

The parameters for a vehicle type are edited in several tabs, as described below.

Description Tab

  • Name: A unique number, created automatically, not editable.
  • Description: A textual description for the type, of any length, which need not be unique, but for clarity, a unique description is better. An example might be “Generalized Car” or “Small Truck”.
  • Behavior: The Behavior associated with this vehicle type, which is used only if this vehicle is not being driven by a Person object. A vehicle will adopt a new behavior when a Person gets into that vehicle as its driver. However, the behavior associated with a vehicle is important for the following types of vehicles:
    • Taxis
    • Drop-Off Vehicles
    • Pick-Up Vehicles
    • Zone to zone (background traffic) vehicles Color: A color for identifying vehicles of this type. If the color is black, then the vehicle is colored according to the layer. It is also possible to color a vehicle by its driver type, using an option on the Tags window, accessed from the Display menu. Solid Shape: This is used to set the 3D shape used in Solid display mode. If it is not set, a solid shape will be assigned based on the size of the vehicle and the name of any shape group Shape Group: This is used to associate a type with a set of 3D shapes, in order that all instances of a type do not look the same in the Detailed display mode. When a vehicle of this type is created, it will select one of the shapes from the group at random. Taxi: A taxi type can queue in a taxi rank, pick up a passenger at the head of the rank, and drop off a passenger at a drop-off zone. Cycle: Cycle vehicles are counted separately to other vehicles. Emergency: Emergency vehicles have different rules for lane use, and can exceed the posted speed limit.

Size Tab

  • Length, Width, Height: The mean dimensions of the agent (localized short distance units). To generate a distribution of sizes, see Size Variation. In general, regardless of any visualization rendered onto the agent, a vehicle is modeled as a cuboid
  • Mass: The mass (“weight”) of the vehicle (kg or lb).
  • Size Variation: A value specified as a fraction of each of dimension, used to specify the standard deviation of a normal distribution for each dimension. For example, if the mean length of a vehicle type is 4.0m and the size variability is 0.1 or 10%, the lengths of vehicles of this type will follow an approximate normal distribution of mean 4.0 meter and standard deviation (SD) 0.4 meter (The distribution is clamped to 3xSD around the mean to avoid unexpected values such as negative or zero lengths.)
  • Side Gap: the minimum gap to the side of a vehicle when passing another vehicle in the same lane
  • Extras: the number of extra people to count for this vehicle. It is not necessary to include a value here for the driver of a taxi or a drop-off or pick-up vehicle, as these are counted automatically. This field should be used for additional people, that you want to count in the Extras section of the trip summary statistics.
  • Load Base: The vertical distance up from the road surface defining the base of the load are, for freight or people carried by this vehicle.
  • Load Front, Back: The horizontal distances from the leading edge of the vehicle to the load, and from the trailing edge of the vehicle to the load.
  • Load Side: The horizontal distance in from the sides of the vehicle to the load area. Set this to any non-zero value to display people.
  • Load Capacity: The maximum mass of the load (kg or lb).

Dynamics Tab

  • Engine: The Engine defines the maximum speed, acceleration and braking rates for vehicles of this type. There are a number of standard engines defined, but if you have data you wish to use, you can also define your own engines.
  • Tyre Friction: This value controls the maximum speed at which a vehicle can turn a corner. The default value for this parameter (u) is 0.8. Setting a lower value will cause vehicles to slow down more on curves. The maximum speed is calculated from: vmax = guR where g = 9.81 m/s/s u = the tire friction co-efficient R = the turn radius
  • Gap Factor: This multiplicative factor is used to increase or decrease the gap to other vehicles behind vehicles of this type. You might use this to increase the distance of queuing vehicles behind large trucks. In effect, this parameter makes vehicles of this type appear longer than they are to other drivers.
  • Conflict Factor: This multiplicative factor is used to increase or decrease the cross and merge times where streams intersect, on a per-type basis. So you can use it to adjust the gap acceptance at intersections on a type- by-type basis. See also the Cross and Merge time parameters for a Stream.
  • Keep: the preferred side of the lane. Normally, this is set to None , which indicates that a vehicle will aim to drive along the center of the lane in the absence of other traffic. However, for some vehicle types, such as cycles, you may want to set this to Left or Right

Attachment Tab

Attachments are used to create multi-part vehicles, such as a truck-trailer combination.

  • Controls: The leading agent has this field set, describing the other type that it is pulling or controlling.
  • Attachment Angle: The angle of attachment, clockwise in degrees, of the attached type, relative to the direction of motion. For a trailing vehicle, this would be 180.
  • Attachment Distance: the distance from the periphery of the leading type at which the attached type will pivot. An articulated truck might behave best if this is set to a negative number, which makes the trailer overlap the cab. The total length of this cab-trailer combination is the sum of the lengths of the two types, plus the attachment distance. So for example, if the cab is 5 meters long and the trailer is 12 meters long, and the attachment distance is -1m, the total length will be 5 + 12 – 1 = 16 meters
  • Attachment Count: This is set to 1 by default if there is an attachment, but it can be set higher if you want to repeat the attachment. For example, to create a road train with one truck and 2 trailers:
  1. define a Trailer type
  2. define an truck type with fields:
  • Controls = Trailer
  • Attachment Angle = 180
  • Attachment Distance = 0
  • Attachment Count = 2

Engines

An Engine is an object that defines a maximum speed, and acceleration and braking rates.

Each vehicle type has an associated engine definition. A simple model might define a single car type, with one of the standard petrol car engines, and a single truck type (“heavy goods vehicle” or HGV) with the standard diesel truck engine. A more detailed model might define six vehicle types: small, medium and large car types, a van or light goods vehicle type, and a two heavy goods vehicle types. It is impossible to say what the correct level of detail is for any particular model: it is up to you to decide how much detail you want, after deciding what is important for your particular area of study.

An Engine definition contains two tables of information:

  • acceleration rates: values in m/s^2 for a range of speeds and gradients. Typically, a vehicle has its highest acceleration in the lower middle range of its speed. Also, the effect of gravity means that the maximum possible acceleration is higher on a down slope (negative gradient) and lower on an up slope (positive gradient). The standard engine definitions modify acceleration to take account of both these effects, but it is impossible to provide a definition that is correct for all circumstances, and you should verify that the engine specifications you use are of an acceptable accuracy for your model. In many cases, it is a comparison between two or more options that is important, and the absolute value of any particular output may be of lesser importance. It is also worth noting that the car following model employed will not necessarily use the maximum possible physical acceleration.
  • braking rates: in real life, maximum braking (deceleration) rates are not a function of the engine, but are a function of the braking system on a vehicle, typically disc brakes. However, the engine definition is a suitable place to store maximum deceleration values. These are specified in the same way as acceleration, in a matrix of speed by gradient.

Fleets

The Fleets window can be accessed by a button at the bottom of the Vehicle Types window, opened using Parameters / Vehicles then Fleets.

A Fleet is a group of vehicle types. A Fleet can contain any number of vehicle types, and Fleets can overlap. That is, a vehicle type can be in any number of Fleets. When a new vehicle type is created, a new Fleet will be created automatically, with the same name, containing only that vehicle type. You don't need to keep each Fleet, but it is often useful to have one for each vehicle type. Lane choice, stream choice and route choice rules use fleets,as do some types of reporting functions, such as those for Loops. If you want to create a lane choice rule that applies to more than one vehicle type, you should create a Fleet that contains those vehicle types.

For example, imagine you have a model that has five vehicle types: Small Car, Large Car, Taxi, Bus, Truck. If you want to create a rule that applies only to cars, then you would create a fleet containing those two vehicle types, perhaps calling the fleet “Cars”. Then you would select that fleet in the Lane Choice rules window.

Calibration (*)

  • Advanced Functionality – see Manual for Mobility Simulation

Time Distributions (*)

  • Advanced Functionality – see Manual for Mobility Simulation

Term Variations (*)

  • Advanced Functionality – see Manual for Mobility Simulation

Network Menu (*)

Trails (*)

  • Advanced Functionality – see Manual for Mobility Simulation

Control Menu

Control – Intersections

An intersection is a set of one or more nodes where there is conflict between traffic streams. An intersection may be signalized or unsignalised. If it is signalized, then it will have a Controller. Unsignalised Intersection.

An unsignalised intersection can be edited by selecting any part of the intersection surface and then selecting the Adjust action. It is easier to select the intersection if Streams are not displayed. The Intersection Editor for an unsignalised intersection has a single tab containing all the turns on that intersection.

  • Unsignalised Turn: a Turn is a collection of Streams, all having common entry and exit roads , where a Stream is the connection between an entry and an exit lane across an intersection. The parameters for each Turn on a Unsignalised Intersection are:

  • Fixed Signal: The sign or signal visible to traffic on the approach to this turn. Select from the following options, listed in decreasing order of priority:

    • Free Flow: Approaching traffic is on the main road, has priority, and does not need to check for conflicting traffic.
    • Yield: Approaching traffic is on the main road, but must cross an opposing stream, and must slow down on approach.
    • Give way: Approaching traffic has a Give Way sign, and slows down accordingly
    • Stop Sign: Approaching traffic has a STOP sign, and slows down to a stop before proceeding
    • Barred: The turn is closed to all traffic
    • Restriction: a restriction for the turn, for example to allow buses and taxis to make a turn, but not other traffic.
    • Preference: (For Turns inside a Parking Zone) Set this to 1 for the preferred turn for a vehicle that is looking for a parking bay.
  • Signalized intersection & Controller: a Controller is a device that holds information about the signal control at an intersection. There is one controller per intersection, and one intersection per controller. However, this is not really a limitation, because an intersection in the model is defined to be a group of one or more nodes, and does not necessarily have to be limited to a single physical intersection. To include additional nodes into the definition of an intersection, select the intersection and the node you want to include, and use the action Intersection > Include Node. The key limitation is that any signalized movement may be controlled directly by one controller only. This does not exclude the possibility of controllers communicating in order to synchronize, and in that sense a controller may influence the setting of a signal belonging to a neighboring controller. A Controller retains a record of all Turns, Groups, Phases, Plans and Rules for an intersection, and all of these can be edited using the Intersection / Controller Editor window. The Controller is also aware of a list of Loops that are connected to the intersection. However, a Loop “belongs” to a Lane, not to a controller, so if you want to add a Loop, you should do this by first selecting a Lane. You can edit the properties of a Loop by calling the Adjust action on a selected Loop. For a signalized intersection, it is often easier to select and adjust the parameters by selecting the controller. This can be made visible using the Controllers Layer.

  • Signalized Turn: A Turn is a collection of Streams, all having common entry and exit roads , where a Stream is the connection between an entry and an exit lane across an intersection. The parameters for each Turn on a Signalized Intersection are:

    • Fixed Signal: set if this turn does not have a variable signal, but has a signal fixed for all time. An example is where a turn to the curb side has a Give Way or Yield sign.
    • Direct Group: unopposed movement - vehicles given a green signal will proceed without checking other traffic streams. This is sometimes known as the “primary”.
    • Filter Group: opposed movement – vehicles given a green signal will proceed if there is a suitable gap in opposing traffic. This is sometimes known as the “secondary”.
    • Filter Signal: if the turn has a Filter Group, then you can set the signal that is applied to the turn when the Filter Group is active. Normally, the Filter Signal is Green Yield, which causes vehicles to slow before turning across an opposing traffic stream, if a suitable gap exists. You can also set it to Green Stop, which causes vehicles to come to a complete stop before turning when the Filter Group is on red. This allows you to code Right-Turn-On-Red signals.
    • Restriction: a restriction for the turn, for example to allow buses and taxis to make a turn, but not other traffic. In almost all cases, there is only one Turn for each entry-exit pair of roads. However, occasionally, an entry-exit pair will have two turns (sometimes known as “auxiliary” group). An example is where there is a special bus- signal for a movement, and this would have its own Turn to differentiate it from other traffic streams making that movement. To create this type of extra Turn, select the Stream that has its own signal group, and then call the Action Stream > New Turn. This turn can then be given its own signal group, so that the bus lane can proceed on green while other traffic on the same approach is held on red.
  • Group: A Group is either: a set of vehicle Turn movements, or a pedestrian walk. If a Group is defined as a Walk, it can have an associated Walk ID number, or it can apply to all walks. The latter case is also known as a “scramble” phase; it is used to stop all vehicle traffic and allow pedestrians to walk in any direction across an intersection. A Group has a signal state defined for each phase, and may also have an initial (“T=0”) state. If the initial state is not specified, it defaults to red. You can add or delete Groups on the Groups tab of the editor. Groups are numbered sequentially from 1, but you can change the number if required. it may be your convention to number vehicle groups from 1 to 8, and pedestrian groups from 9 to 16. Once you have created the correct number of groups you need, you can then add phases, and set the state of each group in each phase. To select a Phase for editing or deletion, use the Phases tab. Once you have created the Groups, you should return to the Turns tab and assign a direct group or filter group, or both to each turn. If an intersection is controlled by an external controller (such as SCATSIM), then the groups do not require any phase specification, as groups will be controlled directly by the external controller.

  • Phase: a Phase is a set of signal states for all groups on a controller. Commonly, a phase is thought of as a collection of groups that are at the “green” state, but more formally, a phase encodes a set of groups that are green, a set that are off, and the remainder as red. While there is no implementation reason that a phase could not encode other signal states (Green Yield etc.), these are not offered as alternatives in the user interface in order to simplify the range of choices.

  • (Phase) Timing: The timing for each phase is shown in a separate tab in the user interface. The timing parameters are:

    • Green: the default value, in seconds, for the green time, which can be varied by each plan. You cannot edit the green time here, you should edit it in the Plan tab.
    • Yellow: Yellow time for this phase for all plans.
    • Red: Red time for this phase for all plans.
    • Min: The minimum green time for this phase, which is zero by default, but can be set higher to stop the vehicle actuation rules from reducing the green time below that minimum.
    • Max: The maximum green time for this phase. This can be set to any value that is larger than the minimum,
    • Stretch: Set to true if the green time of this phase can be extended by a vehicle-actuation rule, where the balancing phase is not explicitly defined. [Note for SCATS users: 'Stretch' applies here to the phases described as
    • the stretch phase and time gain phases in SCATS.]
  • (Phase) Plans: A Plan specifies the cycle time, offset, phase order and green splits of a sequence of phases. The cycle time (in seconds) specifies the total time for all phases in the plan, including time for red and yellow. The total green time per cycle or “cycle-green” equals the cycle time less the sum of all yellow and red times. The green split percentage values are expressed as a fraction of the cycle-green time. The offset time (in seconds) is useful for synchronizing a set of intersections all having the same cycle time. For example, if intersection 1001 has an offset of 0 and intersection 1002 has an offset of 30, then intersection 1002 will start its cycle 30 seconds after intersection 1001. If intersections do not have the same cycle time, then the offset time is not particularly meaningful. The phase order must be at least one phase, but has no maximum length, and may contain repeats. For example, if the phases defined for an intersection were A, B, C and D, a phase plan could define the sequence [A, B, A, C, D]. You can have as many plans for an intersection as you like, and switch between them using the “Current Plan” selector. The green splits for each phase in a plan are specified as a sequence of numbers. For example, if a plan has three phases A,C,D then the green time specification should have three numbers, in order, for example 40, 35, 25. The values are expressed as percentages, so should sum to 100%. However, for convenience, you can enter absolute values, and they will be normalized when you press Apply. The percentages refer to the proportion of the cycle-green time given to each phase, not a proportion of the total cycle time.

  • (Signal) Loops: There can be any number of loops associated with an intersection and its controller. The loop does not have to be on a lane leading up to the intersection, but commonly this is the case. These loops can be used for signal control logic, particularly where the intersection is controlled by an external controller. You can associate loops with an intersection by naming them according to the convention (intersection)_(index). For example 1001_2 associates a loop with intersection 1001, giving the loop an index of 2 on that intersection. If you select a loop, then use Action Adjust, you can set the controller for a loop, or check its current assignment. If you change the controller to which a loop is assigned it will automatically be given a new loop ID, and rename the loop according to the convention described. The fields in the Loop tab are:

  • Name: The name of the loop

  • Lane: The lane on which the loop is located

  • To Stop: The distance from the downstream edge of the loop to the stop line on its lane

  • Occupied: Has a value of 1 if occupied, 0 otherwise

  • Occupancy: The occupancy ratio (time occupied / total time) since the last loop reset

  • Override: Select this to mark the loop as permanently occupied, which can be used to test signal control

  • Signal Rules – for Vehicle-Actuated Signals There can be any number of signal rules defined for a controller. These rules can be used to implement demand-sensitive changes to the signal control, such as vehicle-actuation or pedestrian-actuation. Each rule has a Plan , an Action Phase , an Action, a Test condition, and may have a Balancing Phase. The Action defines what will happen if the test is true.

  • Terminate: terminate the action phase (with yellow and red). The remaining green time may be given to another phase, determined in order as follows(a)a specified Balancing Phase (even if not stretch). (b)the first following phase marked as stretch. If no phase is identified, the remaining time is discarded.

  • When Tested: every second during the Action Phase green. Example: if the phase order is A,C,E,E1,E2, with both E1 and E2 having zero green time by default, and a rule is defined for E with balance phase E2, then the rule will terminate E and go directly to E2, missing out E1 Skip: skip the action phase. This action is similar to Terminate. It uses the same procedure for identifying the Balancing Phase.

  • When Tested: just before the Action Phase is due to run.

  • Extend: extend the Action Phase by one second (plus any Time Parameter value). If a balancing phase can be determined then subtract the extension time from that balancing phase. As above, a balancing phase is determined as: (a)a specified Balancing Phase (even if not stretch). (b)the first following phase marked as stretch

  • When Tested: just before the Action Phase green finishes, when there is one second of remaining green time. The Test for each rule is a conditional expression using parameters:

    Loop gap[N] the time, in seconds, since loop N was last occupied. If the loop is occupied, this parameter returns zero. occ[N] the time, in seconds, that loop N has been occupied. If this loop is unoccupied, this parameter returns zero. flow[N] the flow rate, in vehicle per hour, on loop N speed[N] the mean speed of vehicles crossing loop N density[N] the mean traffic density on loop N count[N] the number of vehicles that have passed loop N people[N] the number of people that have passed loop N Crossing push[P] the number of button pushes registered for crossing with walk ID = P since the last time the crossing was open. Each push corresponds to one person arriving. For example, push2 > 0 Phase elapsed (lap) the elapsed green time on the phase to which the rule applies. This will be zero if the phase is not running remaining (rem) the remaining green time on the phase. If the phase is not running, this will hold the green time for the next running of this phase, including any adjustments made by giving or taking time to or from another phase Controller pi[C] the current phase index of controller C, returning 1 for phase A, 2 for phase B and so on. This test can be used to co-ordinate intersections.

Examples

push2 > 0 tests if there are any people waiting on crossing 2
gap3 > 5 tests if loop 3 has been unoccupied for 5 seconds or more
occ7 < 10 tests if loop 7 has been occupied for less than 10 seconds
pi2004 = 3 tests if controller for intersection 2004 is currently on phase C
Available operators for number comparison are: > < = >= <=
Operators available for logical combination are: AND OR

An example test is

(gap7 > 5 AND gap8 > 5) OR occ7 < 10

The Plan specification can limit the rule to a single plan, or if set to zero, causes the rule to be tested during all plans. The Action Phase determines when the rule is tested, and which phase will receive the Action if the Test condition is true. The Balancing Phase can be used to retain the cycle time, as described under Action. The order of the rules is significant, and the rules can be re-ordered using the up & down arrows beside the rules table. The Log Tests and Log Actions options can be selected while testing the rules. These will generate diagnostic messages in the Log window, which can be accessed from the lower right corner of the main window. These options are not saved with the model. They generate a lot of diagnostic text, which can slow down the model significantly, so it is necessary to select them whenever the diagnostic output is required.

Rules Example:

Consider the following intersection, with phase B active. To get this phase to gap out when there is no demand for it, then this requires a test for a gap on all of loops 6, 7, and 8. If an acceptable gap threshold is 5 seconds, then the rule would be defined as follows:

Description Gap-Out-B
Plan 1
Phase B
Action Terminate
Test gap6 > 5 AND gap7 > 5 AND gap8 > 5
If there was a separate phase for the right turn movement on loop 7, and a
rule was required to make that phase terminate on no demand, then the
test would need to look at gap7 only.

Boom Gates (*)

Advanced Functionality – see Manual for Mobility Simulation

Ramp Metering (*)

Advanced Functionality – see Manual for Mobility Simulation

Timing Playback (*)

Advanced Functionality – see Manual for Mobility Simulation

Demand Menu

For each model, you must specify the total number of people and vehicles that will try to use the network of roads and walkways. This is called the demand. The demand can be directed , where totals are specified between each origin and destination, or it can be undirected , where totals are specified by origin only. Trip tables must be generated from the demand before the simulation begins, if there are to be any agents (pedestrians or vehicles) in the model. All the randomness required to effectively simulate people and traffic is contained within the Trips tables. The Demand Editor allows you to specify the demand and the Trip Generator allows you to create new Trip tables from the currently active Demand specification. A demand table is aggregated, and quite compact. A set ('page') of trips tables contains all the disaggregated information for a simulation, with separate sets of tables for pedestrians and vehicles, and within those, separate tables for directed and undirected trips. Each table contains a number of rows, with one row for each trip. Each row defines all required fields for a trip, including:

  • a unique name for the trip
  • the departure time (to the millisecond)
  • agent type (for vehicles - car, van, truck, etc.; for pedestrians – adult, child, etc.)
  • trip origin (area/zone identifier)
  • trip destination (area/zone identifier, for directed trips only)
  • the trip “DNA”, a block of randomly distributed variables, for use by the core simulation engine and any plug-ins.

Undirected Demand (Zone Counts and Turning Counts)

Undirected demand is simpler than directed (or O-D) demand, as you need only a single value for each origin zone, rather than a set of values, one for each destination. As there is only a single demand value for each origin zone, this type of demand requires a one-dimensional column of values (a volume ) rather than a two-dimensional matrix. However, if there are any route choices in your network, you need to specify the turning counts at each route choice location for each possible destination. If your model is fairly simple, and has only one route between each origin and destination pair, for example a corridor model, then this method of specifying demand may be suitable.

Each route choice location automatically creates a “Split” object, that by default assigns an equal proportion of all incoming traffic to each of the available exit options. At a 4-way intersection, an incoming agent has a choice of left, right or straight ahead, and the default split object will stochastically assign the agent to one of those exits, each with equal probability of 1/3. This means that if there is a loop in the network, an agent may be directed around the loop, arriving back at the same point. With typical splits, the probability of this happening is low, and in some networks, following a loop around may reflect reality, for example where a vehicle is looking for a parking space, or a pedestrian is window shopping. Some worked examples on the following pages illustrate the probabilities of following a loop.

The Split function is very simple; if more complex routing rules are required, then the route choice tool allows you to create rules that assign the exit (left, ahead, right) based on origin zone, agent type, current lane, sign settings, etc. The outcome of a route choice rule can be a single exit or a stochastic distribution across multiple exits, similar to a Split.

Directed Demand (OD Matrices)

Directed demand requires a two-dimensional origin-demand matrix (OD matrix). This fully specifies all trips between each origin and each destination. This data is often the most difficult to collect for the modeling process, because an accurate matrix requires either:

  • a roadside survey, asking drivers to disclose the start and end point of their journey, and if possible also the time of departure. This option is expensive, and normally only surveys a small sample of the total network traffic
  • an electronic monitoring system, for example one recording license plates or automatic toll payment cards. These systems are often unpopular due to privacy concerns, and, like roadside surveys, seldom provide more than a patchwork of cover. In most cases, because collection of accurate data for a full matrix is not possible, often due to cost, a matrix is estimated. This process commonly starts with a pattern matrix, which is an initial estimate of relative demand between pair of zones. The pattern matrix is often derived from historical data. The pattern matrix is then modified using growth factors for each zone and verified against measured counts on the network. Matrix estimation can never produce a result that is known to be correct, because for any realistic network, there are too many unknowns. The demand matrix is frequently the largest source of error in all of the data used for a simulation model. Therefore, before deciding to use a matrix, make yourself aware of the error margin that you will introduce, and consider the alternatives, such as undirected demand in combination with turning counts.

Divisions

A Demand Division is a weighted group of Types. You can define any number of divisions, each of which can contain any number of types. Divisions are used by the trip generation process to apply a demand matrix or a volume in given proportions to a group of vehicles. Divisions are also used to select vehicles for parking. This is also a type of demand allocation, because it decides the proportions of vehicles to generate in a parking zone if none are available. Divisions may overlap, that is, any one type may be contained in any number of divisions. A division may contain a single type. The Division Window shows a table with all types as columns, and all divisions as rows.

  • To create a new division: press the “New” button and edit the name for the division. Then enter the percentage values for each type. The percentage for the last type will be adjusted automatically so that the sum for all types is 100%.
  • To delete a division: select the division in the table by clicking on its name, then press the “Delete Division” button.
  • To rename a division: click on the name of the division and type the new name.
  • A Fleet is similar to a division, but has check boxes to included or exclude each type rather than percentage values. Fleets are described in more detail in the section on Vehicle Types.

Profiles

A Profile is a set of weights that sums to 100%, where each weight applies to a time interval. The weights are applied in sequence to generate a time varying quantity. The Term defines the start and end time. A profile is use to vary the number of trips generated over the course of a term. It is often lower at the start and end, and higher in the middle to represent a peak hour. A profile can have any number of intervals; all of the time intervals are of the same length. If for example, you have an hourly demand, but want to weight the demand by some 5-minute counts, you would define a profile with 12 x 5-minute intervals, and set the corresponding 12 weights according to the count values. The Term applied to a Profile can be independent of all other Terms. For example, it does not need to coincide with the Terms defined for restrictions or signal timings, or even for other profiles. The default profile, named Flat applies a constant weight, of value 100%, all the time. Apart from their main use with Demand, Profiles can also be used by Plugins, for example to set the toll cost on a time-variable road pricing model.

1 x 100% is not the same as 4 x 25%

If you define an hour in the simulation (for example AM Peak) to have 4x 15-minute intervals, with 25% assigned to each, you will not get the same results as 1x 60 minute interval @ 100%. The difference will be most noticeable where there are small numbers of trips. If you have 1 trip defined in your matrix between A and B, then you are asking for a quarter of a trip every 15 minutes, which is not possible. At the end of the matrix term, extra trips are generated to try to make the row totals correct, but it is not possible to make all 4 15-minute interval totals correct as fractional trips cannot be created. By creating 4 intervals in your profile, you are effectively creating 4 matrices, one for each interval, each scaled by the factor applied to that interval.

Using the Profiles Window

To define a new profile:

  1. Press the “New Profile” button in the top left corner
  2. Enter a name, for example “AM Peak”
  3. Choose a Term for the Profile, or define a new one using the drop-down selector
  4. Define the number of intervals within the Profile. The list on the left allows you to select a profile for editing. The number on the right hand side below the buttons shows you how many intervals are in the current profile. You may need to scroll the central pane left or right to see all the weights.
  5. To accept a new or edited profile, you must tick the “Sum to 100%” ( ∑ = 1 ) box. This will normalize the weights so that their sum is 100%.

After creating a Profile, you can:

  • add an interval using the “New Interval” button top right
  • delete an interval
  • reset all the weights to be equal using the “Reset” button. For example if you have 4 intervals in the profile, reset will set all 4 weights to 25%
  • adjust the weight for any single interval by moving a slider, or by typing in the box below the slider.
  • If you move the slider and the ∑ = 1 box is ticked, then all the other weights will be adjusted to keep the sum at 100%
  • If you type a value into the box below a slider, the ∑ = 1 box will be cleared for you.
  • you can paste a row of values from a spreadsheet into the weight value boxes. Click into the first (leftmost) box and then paste using Control-V.

Demands (Demand Editor)

The Demand Editor has three tabbed panes, one for undirected demand, one for directed demand and the other for (Public) Transport demand. Before proceeding, if you do not understand the difference, please refer to the section that explains the difference. Directed and Undirected Demand Tabs.

These two tabs have the same general layout. Directed demand uses OD matrices, where demand between all OD pairs is known. Undirected demand uses traffic volumes from origin zones in combination with turning counts. Undirected demand with turning counts can be used to estimate origin-destination demands by running the model and saving the arrivals matrix.

  • List Panel: on the left side, contains a list of the demand sources within the model. You can add a new source of demand by pressing the Add button above the list, or delete a source by selecting it and pressing the Delete button below the list.
  • Contents Panel: in the center of the panel, shows a table containing details of any source currently selected in the List Panel. This table contains a breakdown of the demand by origin (and destination, for directed demand only).
  • Mode Indicator: shows the mode of the demand source, either Pedestrians or Vehicles. This is not editable.
  • Profile Selector: allows you to vary the release of the demand over time.
  • Division Selector: allows you to restrict the demand to a subset of all available types for the Mode.
  • Generate Trips: allows you to apply a weight to trip generation, expressed as a percentage.

Observations (*)

  • Advanced Functionality – see Manual for Mobility Simulation

Assignment Menu (*)

Route Classes (*)

  • Advanced Functionality – see Manual for Mobility Simulation

Route Cost Factors (*)

  • Advanced Functionality – see Manual for Mobility Simulation

Routes (*)

  • Advanced Functionality – see Manual for Mobility Simulation

Lane Choice (*)

  • Advanced Functionality – see Manual for Mobility Simulation

Stream Choice (*)

  • Advanced Functionality – see Manual for Mobility Simulation

Route Choice (*)

  • Advanced Functionality – see Manual for Mobility Simulation

Gateway Choice (*)

  • Advanced Functionality – see Manual for Mobility Simulation

Trail Follower (*)

  • Advanced Functionality – see Manual for Mobility Simulation

Validation Menu (*)

Validator (*)

  • Advanced Functionality – see Manual for Mobility Simulation

Obstructions (*)

  • Advanced Functionality – see Manual for Mobility Simulation

Auditor (*)

  • Advanced Functionality – see Manual for Mobility Simulation

Reporting Menu (*)

Level of Service (*)

  • Advanced Functionality – see Manual for Mobility Simulation

Traffic Reports (*)

  • Advanced Functionality – see Manual for Mobility Simulation

Signal Reports (*)

  • Advanced Functionality – see Manual for Mobility Simulation

Economic Evaluation (*)

  • Advanced Functionality – see Manual for Mobility Simulation

Display Menu

Content

This window displays the 2D and 3D content used to add context to the display. Such content includes images and structures that have been loaded into the current model and also shows a list of all available images and structures in the central shape database.

  • Shape: A collective term used for both two-dimensional images and three-dimensional structures.
  • Image: A 2-dimensional image, imported from a range of image formats, including JPG, PNG, GIF, BMP, TIF.
  • Structure: A 3-dimensional structure, used as scenery or a fixed obstacle or to give a body to an agent. Import formats include 3DS.
  • Central Shape Database: this binary-format database contains compressed image and structure data that can be used in any network. When uncompressed, it consumes memory and processor resources, so by default, none of the images or structures are included in a new network. Include only the structures you need for each model, otherwise you may find the application becomes sluggish, depending on your hardware.
  • Central vs Local Shapes: A central shape is one that is loaded into the database, and available for all networks on the installation on one computer. A local shape is one that is contained in the model definition file (the .AZA file) and can be easily transferred to another computer or another user in that file. An example of a local shape might be a JPEG-format aerial photograph image used as a background underneath a network. This is compressed automatically before being included in the .AZA file. The standard installation includes several hundred standard images and structures (including road signs, pedestrians, vehicles and buildings) but it is also possible to import additional images or structures to the central database on your installation. However, be aware that if you do this, and then use one of those shapes in a model, those shapes will not be visible if you transfer the model file to another computer, unless you also import the additional shapes into the central database on that installation.

Pedestrians Tab

To use a new character frame from the central database in your model, press the Add button in the top left corner. In the window that is raised, to include all frames for a character, select all rows in the table with the same character name (for example Character1) and press OK. To include all characters, you can use Control-A to select all frames of all characters. The standard database contains a number of characters, each having 11 frames. Of these 11 frames, the first, numbered 00, is a standing figure, while the others, numbered 01-10, are walking figures in 10 phases of a “walk cycle”. When moving, the walk cycle will be adapted to the forward moving speed of the pedestrian.

The individual cells of the table on the Pedestrians tab are not editable, they are there for information on the size of each frame structure. The first column, Status, is the most important. After loading it should show a green tick. On first opening a network that has already included some shapes, the icon may be a red cross, but this may be only because the shape has not yet been accessed. Try clicking on the row and this may cause the status to change. All shapes are not automatically loaded when a network is opened, as this would delay network loading unnecessarily. Such shapes will be loaded on demand.

Select a row in the table to temporarily display that character frame in the graphics panel. The figure will be drawn “life size” so you may need to adjust the zoom level. Recommended settings are Tilt = 45 and Zoom = 3. Use the arrow keys on your keyboard to move the selected row up or down the table. When you do this you should see each character “walk”.

Use Control-Select to de-select the character frame so that it is no longer drawn on the graphical display.

Vehicles Tab

To use a new vehicle shape from the central database in your model:

  1. Press the Add button in the top left corner.
  2. Select the class of shape, then select the vehicles you want to include.
  3. As with any selection, you can use the shift and control keys to select a range or toggle selections on and off. You can also use Control-A to select all. Most of the cells in the table on the Vehicles tab are not editable, they are there for information on the size of each shape. The first column, Status, is the most important. After loading it should show a green tick. [If not, see Pedestrians Tab section for explanation.]
  4. Select a row in the table to temporarily display that vehicle shape in the graphics panel. The shape will be drawn “life size” so you may need to adjust the zoom level. Recommended settings are Tilt = 75 and Zoom =
  5. Use the arrow keys on your keyboard to move the selected row up or down the table.
    • Group: this column is editable, and sets the shape group for the shape. Vehicle shapes are assigned to vehicle types in the model according to the group name. If the shapes you chose to include were cars, they will automatically be in the “Car” group. If you open the Types window from the Parameters menu on the main window, and switch to the “private vehicles” tab, then scroll the window to make the last few columns visible, you will see that one of them is “Shape Group”, and in the row for the Standard type definition, contains the word “Car”. This means that any vehicle of the Standard type released will be assigned a shape in the “Car” group. This matching is done by text matching alone – a group can be named anything you want it to be, and is created automatically when you change the group of a shape to the new name. So for example, to create three car groups, named “Small Car”, “Medium Car” and “Large Car”, you would assign one of those names to each of the car shapes you have included, then create three types in the type window, and perhaps also change the length parameter on the type definition to suit.

Structures Tab

To use a new fixed structure from the central database in your model:

  1. press the Add button in the top left corner.
  2. Select the class of shape, then select the structures you want to include. Structures can be used as scenery, taking no active part in the simulation (for example buildings, or trees, beside a road), or they can be used as obstacles, to be avoided by pedestrians. The individual cells of the table on the Structures tab are not editable, they are for information only. The first column, Status, is the most important. After loading it should show a green tick. [If not, see Pedestrians Tab section for explanation.]
  3. Select a row in the table to temporarily display that structure in the graphics panel. The shape will be drawn “life size” so you may need to adjust the tilt and zoom settings. Use Control-Select to de-select the character frame so that it is no longer drawn on the graphical display. Import: This button, below the Add button allows you to import a shape (for example, in 3DS format) into the local model file only, and not in the central database. If you have a 3-D model that you would like included in a particular model, perhaps a local building or landmark then you should use this option. You need to do this only once; after that the data for the model is included in your .AZA model file. Important: Adding a definition of a structure in this window does not add any instances of the structure to your network. Once you have added a definition, you should then use the action Display > New Structure at Cursor to add an instance of the structure.

Images Tab

Images can be used for map-style overlays, road markings (bus lane etc.) or as flat vertical road signs for viewing in 3D. Images take no active part in the simulation, but are used for annotation and illustration. Important: This tab allows you to import a definition of an image but does not add any instances of the image to your network. Once you have added a definition, you should then use the action Display > New Image at Cursor to add an instance of the image. In some cases, you may want to add multiple copies of an image (for example a common road sign) to your network, and this two-stage process cuts down on the amount of storage that would be required.

  1. To use a (vertical) Road Sign or (horizontal) Map or Road Marking in your model, press the Add button in the top left corner.
  2. Select the class of image, then select the images you want to include. Road Markings are in the Map class, as this relates to horizontal images. The individual cells of the table on the Images tab are not editable, they are for information only. The first column, Status, is the most important. After loading it should show a green tick. [If not, see Pedestrians Tab section for explanation.]
  3. Select a row in the table to temporarily display that image in the graphics panel. The shape will be drawn “life size” so you may need to adjust the tilt, zoom and bearing settings.
    • For road signs, suggested settings are Tilt = 90, Bearing = 0 and Zoom = 5.
    • For road markings suggested settings are Tilt = 0, Bearing = 0 and Zoom = 5.
  4. Use Control-Select to de-select the character frame so that it is no longer drawn on the graphical display. In many cases, the same image appears twice in the list, with the suffix -Sign to indicate it will be drawn vertically, and with the suffix -Mark to indicate it will be drawn horizontally. However, you may move the images (using the handles on the surrounding box to be at any position in the network, or rotate them around a vertical axis, to suit your requirements.
  5. Once you have added an image definition, go back to the main window and select the action Display > New Image at Cursor to add an instance of one of the images just defined. This instance can then be dragged, rotated, scaled, etc. just like any other object. If the image is the wrong size, select the image and use the action Display > Scale Image to change the size. A popup window in the top-right hand corner of the main window will allow you to type in a new scale, or you can press and hold the arrow buttons to change the scale.

Advanced Tab

The Advanced Tab allows you to modify the central shapes database or to change settings for the 3-D rendering engine.

  • Shape Class: Each image or structure has a shape class, to make it easier to find in the database. This attribute is primarily a search key for the database, but is also used to identify particular types of structures for specific purposes.
  • Import 2D: press this to add a 2-dimensional image to the central shapes database. Browse to the file you want to use (in format JPG, PNG, GIF, BMP or TIF). Set the shape class, orientation and initial scale factor, and press OK. After successful importation, the image will be available for selection if you switch to the Images tab and press Add.
  • Import 3D: press this to add a 3-dimensional structure to the central shapes database. Browse to the file you want to use. Set the shape class according to the intended use for the structure. For example, if you want to use the structure as a shape for cars in the simulation, you select type “Car”. For certain shape classes, you may also be asked to set the spin rotation around a vertical axis (so that the car shapes know which end is the front). After successful importation, the image will be available for selection on either the Pedestrians, Vehicles, or Structures tab.
  • Refresh: Press to scan the database for up-to-date contents
  • Merge: this merges two databases into one.
  • Modify: this allows you to delete or rename shapes in the database.
  • Drawing: Set the level of detail in drawing images and shapes. To view images, such as aerial photographs, you must set this to “Detailed”. You can also change this setting on the tool bar on the main window.
  • Shading: This calculates normals to points or triangles, allowing the OpenGL rendering engine to apply shading to 3-dimensional objects. This is a computationally intensive operation.

Modify Shapes

This window allows you to rename or delete the shapes contained within the central database. You cannot change any of the other attributes of a saved shape.

  • Rename: To rename a shape, type the new name in the rename column. Renaming a shape requires the entire database to be re- indexed, so it is faster to enter all new names at one time, and then press OK, so that the indexer has to run only once. After you have entered all new names, press OK.
  • Delete: Select all the shapes you want to delete, then press OK.

Tags

Tags are used to highlight some people or vehicles of interest. A tag is drawn as a small triangle above the person or vehicle that is tagged. There are two steps to using tags:

  1. Define the tag by origin, destination, fleet or mob or a combination.
  2. Turn on the Tag Layer in the Layer pane

Defining Tags

  1. Select Display / Tags to raise the Tags window
  2. Press [+] to add a new tag
  3. Set the color
  4. Set an annotation label (optional)
  5. Set one or more of Origin, Destination, Fleet or Mob. The Origin and Destination fields can accept Zone, Area or Sector names or descriptions.
  6. Type in the name, then press Apply to check that it has been recognized. If the cell is blanked out then it has not been recognized

Tag Controls

  • Single Tag / Multiple Tags: If single tag is selected, each vehicle or person will have at most one tag. If multiple tags is selected, a vehicle or person may have more than one tag, according to the match criteria for each Tag definition.
  • Annotation: select this option to display the Annotation label for each tag

Other Controls

  • Color by Driver: If a vehicle has a driver, and the driver has a color defined in the Person Type window, then the vehicle will be colored according to the driver color This option is not directly dependent on tags, but it is another way of identifying or “tagging” vehicles.

Text

This window allows you to change the font and the size of the text displayed in the graphical window.

Font

The Basic font is a vector font, designed to be be fast to draw. It is not particularly pleasing to the eye, but it is effective and fast. The list of other fonts depends on your computer, but should contain at least one Serif font (commonly Times New Roman) and one Sans-Serif font (commonly Arial). Any font other than the Basic font requires a lot of graphical computation, for a process known as Tessellation. It is recommended that fonts other than Basic are used only when simulation speed is not particularly important, for example when taking screen snapshots for reports. It is also possible to skip the Tessellation process by viewing in Outline mode.

Text Size

The Size controls allow you to change the size of the text for a range of different objects in the network. The text for these objects is normally off, but it can be switched on in the Layer panel if you select All or Text from the selector at the top of the panel, then switch the relevant Text Layer on in the current Aspect.

Surfaces

This window allows you to change the way that surfaces are colored, to help understand the behavior of the model. Surface coloring will not be effective in Outline mode, use Flat, Solid or Detailed mode.

For each coloring option, the object selected will be colored in a temperature-styled color ranging from blue (cold) through green (neutral) to red (hot). The numeric values to the right hand side of the selector control the extents of the range. Any surface whose value is equal or lower than the minimum value will be blue; any value equal or higher than the maximum will be red. Any surface whose value is equal to the midpoint value between minimum and maximum will not be colored.

Lane Coloring Options

  • Height: use lane center point height
  • Gradient: use lane gradient
  • Speed: use lane speed (speed limit)
  • Route Speed: use route speed (for free-flow time calculation)
  • Speed Diff: difference between lane speed and route speed
  • Price: price (normally zero)
  • Cost Factor: route cost factor (normally 1.0)
  • Route Class: uses the index number of route class
  • Lane Index: lane index number, used for lane choice and stream choice rules. This option is recommended to check lane index continuity.
  • Headway Factor: headway factor (normally 1.0)
  • Reaction Factor: reaction time factor (normally 1.0)
  • Following Model: uses the index number of the following model applied to the link

Walk Coloring Options

  • Height: use lane center point height
  • Gradient: use lane gradient
  • Route Speed: use route speed (for free-flow time calculation)
  • Price: price (normally zero)
  • Cost Factor: route cost factor (normally 1.0)
  • Route Class: uses the index number of route class
  • Draw Walls: Select this option to display walls on walled walkways
  • Depth: This option, and the variable value allows you to display surfaces with vertical sides, with the given depth (height). This is useful when capturing screen shots, but causes many more polygons to be drawn, so will tend to slow down the progress of the simulation, unless you have a very fast graphics chip.
  • Display When Closed: Continue to Display the Surface Coloring, even after the Surface Coloring window has been closed.
  • Reset: Reset Lane Coloring and Walk Coloring selections to Normal

Was this information helpful?