SATURN MANUAL (V10.

9)

Network Coding – A General Description

5. Network Coding – A General Description

Section 2.3 introduced the distinction between simulation and buffer networks.
Section 5.1 following gives further information on how simulation networks are
specified, 5.2, 5.3 and 5.4 carry out a similar function for buffer networks, while
5.5 describes how, for certain functions the two are combined together into
“assignment” and “map” networks.

Section 5.6 gives very general advice on how users should - or could - create
networks, either starting from scratch or from existing data sources.

A “supplementary” form of network data, the “GIS file”, is described in 5.7.

5.1 Simulation Networks

This section provides a series of explanatory notes on how simulation networks

are coded. Specific coding details are given in Section 6.

Some of the information in this section also applies to buffer networks, e.g., node
numbers, but other sub-sections, e.g., 5.1.4 on turns, is specific to simulation
networks. Extra information on buffer networks is given in Sections 5.2 to 5.4.

5.1.1 Junctions/Nodes

Each junction is represented by a node in the simulation network. These are sub-
divided into „internal‟ and „external‟ nodes.

Internal simulation nodes must be specified in full as described in 6.4.1. They may
be further subdivided into 4 “types”: traffic signals, priority junctions, roundabouts
and „dummy‟ nodes. Traffic signals should be self-explanatory and includes
pelican crossings. A „priority‟ junction includes all form of „give-way‟ junctions
including, for example, merges and uncontrolled junctions. Roundabouts are sub-
divided into two sub-types: those where U-turns are explicitly allowed (type 5) and
those where they are not (type 2).

Dummy nodes require further explanation. Traffic flows through dummy nodes
are unrestricted (except for banned turns and U-turns) and without delay.
Basically they represent a „quick-and-dirty‟ node coding and THEIR USE IS NOT
TO BE RECOMMENDED.

They do, however, have their uses. Dummy nodes need to be defined where
there would otherwise be two distinct links between the same two nodes in order
that the two links have separate identities. This occurs, for example, where an
exclusive bus lane is to be distinguished from the normal link. They may also be
used to identify the access point of a centroid connector more precisely, e.g., on a
very long link, or to represent points where new intersections are to be introduced
in modified networks.

5101396 / May 11 5-1

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

They are also often used to indicate intermediate points on curved links (a
previous recommendation) but the use of the GIS files (see 5.7) to describe link
shapes is highly preferable.

External Simulation Nodes

External simulation nodes represent intersections on a cordon surrounding the

simulation network and may be further broken down into two categories:

(i) “true boundary nodes” which are connected directly to an external zone at the
edge of the network, and

(ii) “internal” joint buffer-simulation nodes which represent those points in the
network where the level of coding detail changes from simulation to buffer
(see 5.2 below).

In the first case they essentially identify points at which trips enter and/or leave the
(simulation) network from the outside world and may therefore be purely notional
intersections. In the second they normally represent “real” intersections which
have a “dual nationality” as part of both the simulation and buffer networks.
(Similarly there may be true boundary nodes at the edge of the network which are
defined within the buffer network only but those nodes are not otherwise
distinguished from other buffer nodes.)

In principle an external node could have both functions, i.e., it could be connected
to an external zone and continue into the buffer network but such a representation
may lead to problems and should be avoided; see Section 15.11 for further
details.

Links from an internal to an external simulation node have no delays calculated at

downstream stop-line (i.e., at the external node itself) as part of the simulation,
although link-based speed-flow curves may be defined for ”out-bound” external
links which give an equivalent delay - see Section 15.13. Indeed if the external
simulation link does lead into the buffer network a speed-flow curve is strongly
recommended. (On the other land “in-bound” simulation links from an external
node do not necessarily require a speed-flow curve since delays are calculated for
each turning movement at the internal simulation node.)

Less input information is required for external nodes - only the starred data (*) in
6.4 and indeed using the AUTOX option (Section 15.12) they need not be
explicitly coded at all.

External nodes need not be „physically‟ external - for example, an internal parking
lot might be represented by an external node as illustrated in Section 16.6.6.

5.1.2 Node Numbers

Nodes, whether internal or external, are identified by node numbers. In SATURN

node numbers need not be strictly sequential, i.e. 1, 2, 3 ..., but may take any

5101396 / May 11 5-2

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

values desired by the user; indeed some form of hierarchical or informative node
numbering system is highly recommended.

Node numbers must (normally) be in the range 1 to 99998, i.e. up to 5 digits.

(99999 is excluded as a valid node number since it is commonly used to signify
the end of data sets.) However the use of 4-digit simulation node numbers
(maximum) is strongly recommended – unless, of course, the total number of
nodes is so large that 5-digit numbers are unavoidable.

Note that, if a parameter DUTCH is set equal to T in &PARAM in a network data

file (see 15.20) then node numbers may be up to 8 digits long.

In addition to the numerical identification nodes may also be given an “alpha-

numeric” name, e.g., node 1513 might be “Hyde Park”. These names are
contained within the GIS file (optionally) associated with each network file. See
Section 5.7 for general details and Appendix Z for specific format details.

5.1.3 Roads

Roads between intersections are represented by “links”, which are numbered

sequentially in a clockwise direction about successive nodes. The actual link
numbers are calculated by the computer and remain largely invisible to the user,
to whom a link is specified by the nodes A and B at its upstream and downstream
ends respectively (A-node and B-node). However the user must ensure that the
links at each junction are correctly input in clockwise order (or counter-clockwise if
drive on the right - Section 15.6); otherwise largely uncheckable errors result.

As with nodes links may also have “alpha-numeric” names, e.g., link (1512,1513)
might be “Grosvenor Terrace”. These names are contained within the GIS file
(optionally) associated with each network file. See Section 5.7 for general details
and Appendix Z for specific format details.

Both directions of a “road” must be coded, even if the road is one-way. One-way
links are represented by specifying zero lanes (LANES below) to the non-existent
direction. For example a one-way road from node A to node B must be included
as a link at A from B (with positive lanes) and also as a link at B from A (with zero
lanes).

Generally speaking travel times on simulation links are assumed to be fixed at

their “free flow” values and link capacities, to be, in effect, “infinite”; i.e. much
greater than the junction capacities at their downstream end. However this
assumption may be relaxed and link speed-flow curves and explicit link capacities
modelled; see 8.4.4.

The minimum data required by the simulation stage for a road (e.g. times,
distances) is coded on the “Link Description Records”, Section 6.4. However note
that additional link data, e.g., a capacity index, which is not needed for the
simulation may also be defined using the buffer data records described in Section
6.6. See Sections 15.13 and 15.14 for a more complete description.

5101396 / May 11 5-3

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

5.1.4 Turns

In addition each potential turning movement (including banned turns - see below)
is explicitly represented in the (simulation) network. Turns are assigned sequential
numbers which, like link numbers, are essentially invisible to the user who refers
to turns by a sequence of three node numbers A-B-C. It is essential that turns be
defined in strict clockwise order from each link, starting with the first turn to the left
(or counter-clockwise starting with the first turn to the right for drive on the right -
see Section 15.7.2).

The user must define a saturation flow (6.4.6) for each turn; banned turns are
therefore coded by setting this turn capacity to 0.

U-turns are generally banned at simulation nodes and therefore need not be
explicitly coded EXCEPT for roundabouts coded as junction type 5 where they are
automatically generated. N.B. U-turns may also crop up in the slightly different
context of the border between simulation and buffer networks as explained in
Sections 18.9.1 and 16.6.4.

Unlike links turns have flow-dependent delays and flow-dependent capacities

determined by the simulation process. Further details may be found in Section 8.

Turning movements which must give way to other streams of traffic, for example
turns from a minor road giving way to the major arms at priority junctions, are
indicated by a series of „priority markers‟. The degree to which these turns are
impeded depends on both the „major‟ flow and the „acceptance gap‟ defined by
the user. Detailed equations are given in Section 8.2.2. The main features of the
relationship between the „minor‟ and „major‟ flows are qualitatively illustrated in
Figure 5.1 which plots the minor road capacity C as a function of the major road
flow V for two different GAP values.

5101396 / May 11 5-4

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

Figure 5.1 – Minor Road Capacity C versus major road flow V

SAT is the „saturation flow‟ from the minor arm with zero opposing traffic. Clearly
as traffic on the major arm increases the flow from the minor arm decreases, and
as the required gap increases the minor arm capacity decreases as well

5.1.5 Restricted and/or penalised movements

Roads and/or turns may be restricted to certain “user classes” of traffic (see 5.8.1
with other user classes banned). In particular roads or turns may be set as “bus
only”; i.e. buses following fixed routes may use these turns/links but the vehicles
which are assigned routes within the assignment may not.

For detailed coding instructions please see 6.4.4 for bus-only restrictions or 6.7 for
more general restrictions which include bus-only as a special case.

Restrictions also include “penalties” where a penalty is an extra perceived cost

associated with using a particular link or turn and applied to the definition of
generalised cost within route choice. Penalties may be either “notional”, e.g. an
extra cost levied on uninformed drivers using a non-signposted rat run, or “real” in
the sense of a monetary toll imposed on drivers or an extra time added to lorries
travelling down a windy road. As with bans they are very often user-class specific.

In addition penalties may either be defined in pure time units (seconds) or in

monetary units (e.g., pence), in which case they represent tolls imposed on
(certain classes of) drivers as with road charges; see section 20. In either case
they are included as an element within the “fixed” link costs for assignment
purposes as opposed to the variable “time” component. Time penalties are
converted into generalised cost units as and when necessary using PPM

5101396 / May 11 5-5

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

(although, since most of the time, generalised cost works in units of generalised
seconds, no explicit conversion is required). See 7.11.1.

Under certain circumstances it may be desirable to explicitly include time penalties

as part of “normal” time, e.g., for the purposes of skimming O-D times (15.27). On
the other hand, if the penalty times are more “notional” than “real”, they may be
excluded from, e.g., time skims. See 15.24.2 and 15.24.4.

5.1.6 Centroids / Zones

In addition to the “real” network nodes and links the user must also define
centroids and centroid connectors. (Although the use of the AUTOZ option as
described in Section 15.12 may reduce the actual input required.)

Centroids are often referred to as zones and the terms are virtually
indistinguishable.

The conventions used within SATURN may differ somewhat from those used in
other suites. Firstly, centroid or zone numbers or “names” do not need to be
numbered sequentially; as with nodes any numbers may be used. In addition
nodes and zones may have the same numbers; i.e., you may define a zone 15
and a node 15 without fear of confusion within SATURN (although the user might
well be confused!). The general convention adopted within SATURN programs to
distinguish “real” nodes from zones in input files is to include the character “C” in
the first input field; see, for example, 6.8.

Since zone “names” are not sequential the maximum zone “name” may be greater
than the number of zones. A parameter MAXZN, set by the user under &PARAM
(6.3.2), defines the maximum zone name (or an upper limit) used although its
value may be over-ridden by the network inputs. Thus if you explicitly define
MAXZN = 100 but later define a zone numbered 150 within either the simulation or
buffer network data then MAXZN is changed to 150. It is therefore not a
particularly critical parameter.

There is, however, (post SATURN 10.3) one exception to this rule which is when
the user sets NO333C and/or NOXYC = T in &PARAM. In these cases MAXZN is
used to distinguish when a node number used within, respectively, the 33333 or
55555 data records is a zone or a node and therefore the value defined in
&PARAM must be correct in the first place.

Zone numbers may normally have up to 5 digits (i.e., be numbered up to 99999)

although the use of 5 digits is not normally recommended. It may, for example,
create problems with certain data input fields (see 6.8) where a C followed by the
zone number is used to distinguish between zones and nodes and the complete
field must be contained within 5 columns (although these problems are not
insurmountable). In addition the matrix manipulation program MX generally uses
5-column fields for the input of zone numbers and in output formats. With buffer-
only networks with DUTCH = T (implying 8-digit node names) 8-digit zone names
may, strictly speaking, also be accepted within network programs but matrix
manipulation would still be extremely difficult.

5101396 / May 11 5-6

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

Zero or negative zone numbers are definitely not allowed in networks (fatal errors)
although, strictly speaking, it may be possible to introduce them into matrices.
However the practice is certainly not recommended and will be made fatal ASAP;
see 10.2.2.

The total number of zones is limited to, e.g., 400 (see 15.28) within certain matrix
programs although the main simulation-assignment programs are not restricted in
this way.

Zone numbers or “names” must also be defined on the trip matrix data input
described in Sections 4 and 10.2.2. Thus if the lowest zone number is 5 this
information should be included as the first input number for the first row.

Clearly it is best if both network and matrix adopt the same system of either
sequential or named zones to avoid any possible confusion. However SATURN
programs which use both a network and a trip matrix (e.g., SATALL) will overlook
certain differences but not all.

For example, it is permissible to have “names” in one and sequential numbering

in the other (as long, of course as the number of zones is the same in both);
SATURN assumes that the two sets correspond one-to-one. Equally, it is (just)
acceptable for both to have “names” but a different “system” of names in each
case (e.g., 1, 3, 5 in one, 10, 20, 30 in the other) - although highly questionable
and it should provoke a Serious Warning at least.

However, a Fatal or Semi-Fatal error will result if the same zone name appears in
different positions in both network and matrix. For example, if the network zones
are 1,3,4,5 … and the matrix zones are 1,2,3,5… then zone 3 appears as either
the 2nd or the 3rd zone. Highly suspicious! And new in 10.6.

It is possible to change the zone names in a trip matrix to match those in a

network by using MX as explained in 10.3.3.

As with nodes zones may also be given an “alpha-numeric” name, e.g., zone 5
might be “Mayfair”. These names are contained within the GIS file (optionally)
associated with each network file. See Section 5.7 for general details and
Appendix Z for specific format details.

It is also possible to define the geographical boundaries of zones as “polygons”

within GIS files although as yet this information is not directly used in any outputs
or analyses.

5.1.7 Sectors

A further optional level of zonal definition, “sectors” which are aggregates of

zones, was introduced with SATURN 8.2. Although the number and hence the
size of the sectors is arbitrary the basic intention is that they should NOT be
“large” such that the study area should be divided into 10 or fewer sectors. With

5101396 / May 11 5-7

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

more than 12 sectors it is sometimes difficult to print full sector-to-sector matrices

on terminal screens.

Unlike nodes or centroids in SATURN sector values of 0 are permitted (and, see
below, is used as a default). The normal program array limits permit sector
numbers in the range 0 to 20; hence a total of 21 sectors but not sector 21 itself.

Sectors may be defined most easily if you use a “hierarchical” zone numbering
system, e.g. such that zone 680 is by definition in sector 6, zone 564 in sector 5,
etc. Thus a single parameter IROCKY (pronounced “hierarchy”!) - 100 in the
above example - is sufficient to define the conversion of sector to zones. Note
here that, e.g., zone 50 would be in sector 0.

Otherwise the correspondence may be explicitly defined using either the „555‟
network data records - see Section 6.8 - or the GIS file - see Section 5.7.

In either case all zones whose sectors have not been explicitly defined will be
assigned the default sector of zero. This may cause some confusion if you are
explicitly assigning sector 0 to some zones since the explicit and default settings
may be confused; this practice is not recommended and generates a warning
message in SATNET.

As with zones sectors cover both buffer and simulation networks - and indeed are
independent of the level of network definition. The only explicit property
associated with sectors, apart from their constituent zones, are co-ordinates - see
6.8. These are used by P1X in plotting sector row and column totals.

Note as well that the concept of sectors applies to both network and matrices so
that the matrix program MX may also use sector definitions for both display and
manipulation, e.g. factoring; see 10.2.5.

5.1.8 Simulation Centroid Connectors

Within the simulation network centroid connectors are connected to links, not to
nodes as in most conventional assignment suites. Thus if zone 7 is connected to
link (67, 80) this is taken to imply that trips into zone 7 do so by exiting the link
directly FROM node 67 at the upstream end of the link. Similarly trips out of zone
7 are assumed to enter the network at the downstream - node 80 - end of the link,
again as though they had parked on the link. In effect, they may be thought of as
parking somewhere between 67 and 80 (and in that direction) although their
contribution to flows on that link entering and/or leaving are ignored.

Diagrams in Sections 15.16 and 16.6.1 illustrate the geometry envisaged.

We note that simulation centroid connectors are not the only source of “entry
flows” and “exit flows” on simulation links: bus flows (see 6.9.2) and flows passed
from a previous time period under PASSQ (see 17.3.1) may also contribute.

5101396 / May 11 5-8

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

Centroid connectors are uni-directional so that, for example, two connections

would be necessary to represent vehicles parking on both sides of a link. The
effect is similar to attaching centroids to „dummy‟ nodes in the middle of links, a
common practice in conventional models, but of course here it is not necessary to
include an extra mid-link node.

The one exception to these rules is where the link defined is an “external” or
“cordon” link, i.e., a link in which one node is an external node. In these cases
trips are assumed to both enter and leave the network at the “external” node, e.g.,
at the network cordon. Examples of these coding conventions are shown in
Sections 16.6.2 and 16.6.3 - in both these cases the connector IS two-way (unlike
the internal connectors described above) so that only a single link needs to be
specified to allow for both in-bound and out-bound traffic. (Though clearly if the
external link is one-way only the appropriate movement will be coded.)

Equally clearly external zones will not need to be included at external nodes when
the network continues into a buffer network - see Section 5.3.

5.1.8.1 Spigot Centroid Connectors

If desired, users may code all simulation centroid connectors via external zones
and external simulation links by creating artificial “spigot links” which connect an
(extra) external node to an (extra) internal node created in the middle of the
simulation link with the zone attached to the external node (as shown in Section
16.6.2).

The (perceived) advantage of spigot simulation connectors as above is that the

flow(s) on the simulation link are more unambiguously defined (see 15.16). The
disadvantage is that it requires two extra simulation nodes to be defined, with
consequent increases in RAM and cpu requirements, and may, arguably, make
the network plots look less realistic. (N.B. Centroid connectors, whether internal or
external, are represented by dashed lines in network plots which may be
optionally suppressed if desired to improve the appearance of plots (see section
11.6.4, note 7).

In terms of actual assigned flows there may be very little difference between the
two methods since, in topological terms, both methods force flow leaving an origin
zone to appear at the downstream end of a simulation link where it may then
choose one of the alternative turns. And similarly with exit flows. On the other
hand, if a zone has more than one centroid connector, the choice between them
may be influenced by the precise method of coding.

Some users prefer to define all internal simulation centroid connectors via spigots,
others do not. It is very much a question of personal preference. My own (DVV)
view is that all forms of centroid connectors from zones which represent a
dispersed area (as opposed to, e.g., point source zones such as car parks or
specific connections from self-contained developments) are approximations which
almost inevitably distort the locally assigned flows and, as such, there is no point
in trying to be overly sophisticated. I.e., connect to links; there are lots of other
issues to worry about in network coding.

5101396 / May 11 5-9

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

5.1.8.2 Centroid connector properties

Under most circumstances simulation centroid connectors are purely “notional”

links and therefore have no time or distance associated with them and, in effect,
infinite capacities. The one exception to these rules are centroid connectors to
links which block back and a portion of the blocked back queue is transferred onto
the centroid connector; see 8.5.2.

On the other hand centroid connectors within the buffer network (defined under
33333) may have a time, distance or toll associated but any time is considered as
fixed, i.e., it cannot have a speed-flow curve associated.

5.1.9 Link Capacity Indices

Every “link” in a SATURN network, whether a simulation or a buffer link, may have
a numerical “capacity index” associated with it. The term “capacity” is probably
somewhat misleading since, as we see below, the indices used may have very
little to do with capacity per se. However historically they were originally used in
conjunction with capacities and the name has stuck.

Capacity indices are used to distinguish groups of links with some common
attribute which might be, e.g., either geographical or physical. For example, they
might be used to define a “jurisdiction code” based on location or else a “link type”
(e.g., motorway/A-road/B-road); the definition and the system of indices used are
purely at the discretion of the user.

Indices have several applications. For example network summary statistics may
be printed disaggregated by index, or they be used in P1X to define which links
are to be displayed and which suppressed. Equally they may be used to define
link colours and widths on P1X graphical output.

The index is usually defined within columns 43-45 of the „33333‟ data records,
usually associated with buffer links, but in this case equally applicable to
simulation links; see Section 6.6. It may also be defined directly for simulation
links using the added mid-link capacity restraint record, or the network X-file; see
6.13.

Indices may also be associated with the (simulation) turns out of a link so that the
summary statistics above include turn delays in addition to link-based delays. To
request this option set the parameter BEAKER to TRUE. See 17.8.

In general the value of an index does not directly affect the way in which a link is
modelled, one possible exception being where capacity indices are used to define
“default” speed-flow curves for either simulation or buffer links as described in
Section 15.9.5. The default values “replace” blank values on input cards and
therefore set link characteristics.

Indices must be in the range 1 to 999 but are generally limited to a maximum of
199 used values. In addition each index may be assigned a “text” name of up to

5101396 / May 11 5-10

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

20 characters (CINAME - see 6.3.4). Links which have not been assigned an
index have a default value of zero such that, for example, summary statistics may
be printed for “Capacity Index 0”.

5.1.10 Node Co-ordinates

Each node or zone in the network is assigned a geographical X,Y co-ordinate

where X represents its east-west position and Y, its north-south. Strictly speaking
co-ordinates are optional but, given the wide use of graphical outputs with
SATURN, they are virtually essential for most applications.

Co-ordinates are input as part of the basic network .dat files using the rules given
in section 6.8.

The choice of the system used to define the co-ordinates, i.e., where is the 0,0
origin located and what scale is used, is essentially arbitrary and up to the user to
decide. However we strongly recommend that for all “realistic” networks (i.e., not
a network of 4 nodes created for demonstration purposes) some form of “rational”
system be adopted. In particular we would recommend the use of a system based
on Ordinance Survey (OS) or equivalent conventions, not least to enable the
transfer of data to and from other data sources such as GIS systems.

The “units” used to define co-ordinates are again arbitrary although the use of
metres (or 10‟s/100‟s etc. of metres) is equally strongly recommended. Note in
particular that if the co-ordinates defined in the network .dat files are in units of
10‟s of metres than the parameter XYUNIT should be set equal to 10.0, or 100.0 if
the units are 100‟s of metres, otherwise certain features of the graphical displays,
e.g., the apparent widths of roads, may be out of scale by a factor of 10 or 100.

Note that the same set of co-ordinates is also used to define the location of
“bitmap” images which may be used to provide a background to P1X network
plots and, generally speaking, this is much easier using a co-ordinate system
based on OS. See 15.43.

5.1.11 Flow Metering and Blocking Back

Two of the most important properties of simulation networks (which help

differentiate SATURN from other traffic assignment models) are the way in which
the simulation models “flow metering” and “blocking back”.

Thus “flow metering” refers to the phenomenon whereby, if a flow V enters a link
with capacity C where V > C (so that the link is a “bottleneck”), then the exit flow
(rate) must equal C which will therefore be less than the total “demand flow V”.
And, equally, all further links downstream along those O-D paths used by the
flows caught in the bottleneck will suffer reduced flows. See Sections 8.2.7 and
17.2 for more complete explanations of the process.

By contrast, “blocking back” works in the reverse sense in that if a queue forms on
a link which is physically longer than the length of that link then that queue will

5101396 / May 11 5-11

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

spill back into the junction upstream and reduce the capacity of traffic to enter the
blocked link. Clearly blocking back on one link may then cause further blocking
back on one or more links upstream with potentially much wider impacts on delays
and hence route choice. See 8.5 for a more detailed explanation.

We note that neither of these effects is properly catered for within buffer networks
as described next.

5.1.12 Link Chains of Continuous Sub-links

A common coding practice in SATURN, for good reasons or bad, is to sub-divide

a “real” road between two “real” junctions A and Z into a series of sub-links by
including one or more intermediate 2-arm (typically dummy or priority) nodes B,
C, D ... as illustrated in Fig 5.2a). One reason for coding intermediate nodes is to
give a link its correct “shape” in network plots – whereas, as all good users know,
a much better way to provide a link shape is to use GIS files (see 5.7.1). Better
reasons are to represent sub-sections of the link which include bus lanes, reduced
lanes due to near-side parking or flared lanes.

Figure 5.2 – Examples of Link Chains

We refer to such a string of sub-links as a “link chain”, the essential property of

which being that traffic entering at Z must proceed directly to A with no chance of
any exit or entry traffic en route (and, generally but not necessarily, no delays at
intermediate nodes).

Including such sub-links may solve particular problems for the user but they may
also create additional problems for the modelling of delays and capacities. For
example, we would expect that a queue which forms at the head of a chain would
queue back “seamlessly” into the preceding sub-links so that it would be most
natural to treat that queue as a single queue between Z and A rather than as a
series of individual link queues. Equally it would be best to represent the delays
associated with that queue as a single delay on one link rather than trying to
subdivide them into a set of shorter delays per sub-link (in the pious hope that the
sum of the sub-delays would correctly equal the total delay).

The intermediate nodes B, C, D etc. may be junction type signals, priority and/or
dummy simulation nodes but not roundabouts (why would one code a roundabout

5101396 / May 11 5-12

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

with 2 arms?) while externals would also not be permitted for reasons of
geometry.

There can be more complicated examples of the same basic phenomenon. For
example, Figure 5.2(b) represents a link with a central bus lane between D and B
which has been coded as a set of two links D-C and C-B in parallel with the “main”
road.

Figure 5.2(c) illustrates a 2-way link into a roundabout which, near the point of
entry, has been split into two short one-way links to represent the physical
separation of the entry and exit points at the roundabout. In this case Z-B-A
represents a chain as does R-B-Z.

Figure 5.2(d) a 4-arm junction at B which basically boils down to two straight-
through chains A-B-D and C-B-E.

5101396 / May 11 5-13

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

In addition combinations of all the above examples may be created “in series” to
create sets of “super-chains”.

Note that chains are always a set of directional links even if the individual links
themselves are not one-way. Thus in Figure 5.2(a) we could have one chain from
Z to A and another from A to Z if all the links were 2-way (having a combination of
1-way and 2-way links between A and Z would be a fatal error). Note also that a
chain may not have any centroid connectors to intermediate links.

In order to help identify such possible adverse modelling conditions post 10.9 a
routine has been included within the network build program SATNET to identify in
advance any presumed occurrences of chains so that they may be consistently
handled within the later simulation and assignment phases of the model. A list of
all chains located is included within the .LPN file.

Applications of chains to blocking back are referred to in Section 8.5.5 and to

random delays in 8.6.4. Chained links may be displayed as a link data item via
P1X.

Breaking Chains

Post 10.9.18 a new rule has been introduced to allow asset of links which would
not normally be defined as a chain to be “broken” by defining a negative link
stacking capacity (see 6.4.11). Thus, in Fig 5.2.(a) above, if the stacking capacity
on link D-C were input with a negative value then C becomes a “genuine” node
through which a chain cannot proceed. So in this case links Z-D and D-C would
be one chain, C-B plus B-A would be another.

This mechanism is often useful if the capacity at C is likely to be less than that A,
for example if the link goes from 3 lanes down to 2, or if some other form of “flow
metering” is being applied.

See Section 8.5.5 for an application to blocking back.

5101396 / May 11 5-14

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

5.2 Buffer Networks

The buffer network facility allows the user to define a much larger network than
would normally be done using a simulation network. For example the user might
wish to study traffic management schemes in one small area of a large city, but to
take into account possible implications of local measures on the traffic flow in the
city as a whole. In order to do so the network is divided into two regions:

 An “inner” or “simulation” network coded in great detail; and

 An “outer” or “buffer” network coded in much less detail.

The resulting network may therefore be thought of as a doughnut with the

simulation network in the middle. The essential difference is that the simulation
network has both junction and link data; the buffer has only link data.

An alternative, and much less convenient, method to test network-wide impacts of

local schemes would be to use a large-scale network to test the long-range
effects, and then to cordon off a sub-matrix of trips for the central area and to
“simulate” this network. Apart from obvious problems with differences between
the two networks this method can be both time consuming and complex. The
buffer network removes such problems.

It is also possible to use SATURN to model purely link-based networks by totally

excluding the simulation network. This option might be of interest to users wishing
to model very large networks, even say national road networks, where the specific
properties of junctions are relatively unimportant. Section 15.8 illustrates the
network coding.

A further potential use of a buffer networks is to describe a network of “walk links”,

e.g., in a pedestrianised area. In this case the trips might represent ultimate
destinations such as shops and the trips would reach these trips via routes which
would take them through the simulation network to an external node
(representing, for example, a car park) through a section of so-called buffer
network, the links of which represent walking links and are coded with appropriate
travel times.

Note as well that the data input used to define the buffer network may also be
used to define additional data for simulation links - see Sections 15.13 and 15.14 -
as well as providing a useful starting point for re-defining buffer nodes as
simulation nodes - see Section 11.9.2.

5.3 Defining the Buffer Network

The buffer network data required by SATNET consists of link-based data only
without any node-based data. Note that there is no provision for coding banned
turns or turn-specific delays (although they may be effectively included by certain
coding “tricks”).

5101396 / May 11 5-15

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

In addition centroid connectors are defined from zones to nodes as opposed to

the simulation network where they are (optionally) coded to links (5.1.8).

More specifically the data associated with a buffer link - and hence the data that
must be incorporated in the input .dat file - may be summarised as follows. Each
link requires:

 An “A-node” (the upstream end of the link)

 A “B-node” (the downstream end of the link)

 The link distance

 The link capacity

 The travel time (or speed) under free-flow conditions

 The travel time (or speed) at capacity

 A “power” n for the cost-flow curve - see 5.4

 A capacity index (optional)

See Section 6.6 for format details.

The buffer network is integrated with the simulation network as a single

assignment network; see 5.5.1. O-D routes are based on the assignment network
and therefore can use both buffer and simulation links.

The simulation and/or buffer networks share a single zoning system. Thus it is
not, for example, permissible to have zones with the same names in the two
different sections. In addition the total number of zones defined in both sections
must equal the total number of zones defined in the trip matrix. Very often users
who have started with a conventional network and coded part of it as a simulation
network will find it necessary to “expand” the simulation zones into a series of finer
„sub-zones‟. In these cases it will also be necessary to “expand” the trip matrix for
these zones; this can be done using procedures within MX, see 10.16.3 and 10.4.

There are limits placed on the size of the buffer network which depend on the size
of the simulation network as well as the actual array dimensions within the
programs. If your network exceeds one of the limits this may be corrected most
easily by changing certain array dimensions within the program. See 15.28.

Problems may arise in coding a joint simulation/buffer network; further useful

information is contained in Section 15.11.

5101396 / May 11 5-16

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

5.4 Capacity Restraint in the Buffer Network

5.4.1 Buffer Flow-Delay Curves

Capacity-restraint in the buffer network is handled by link-based flow-delay curves

whereby the travel time on a link is assumed to be a function of the flow on that
link (and that link alone). The analytical form of these flow-delay curves MUST
correspond to the “standard form” assumed for simulation turns in SATURN (see
Section 8.4.2); i.e., it must follow an equation of the form:

Equation 5.1
t  AV n  t0 V C (a)
t  AC  t0  B V  C  / C
n
V C (b)

where

to is the free-flow travel time (in seconds),

C is the link capacity (in pcu/hr; see 15.17.1), and

B is a constant worked out by the program equal to one half the time
period being modelled.

(Numerically: B = 30*LTP where LTP is in minutes and B in seconds.)

(But see 15.38 for an option to allow the “power law” segment of the curve to
apply over the full range of link volumes.)

For turning movements A and n are calculated by the program; for the buffer
network n is defined for each individual link, either input directly on the link record
or indirectly via the default value of BCRP (Note 4, section 6.6). A and t o are
calculated from the free-flow and capacity travel times input by the user. In fact t o
exactly equals the free-flow travel time and A is chosen so that the curve passes
through the capacity travel time when flow equals capacity. (For a more technical
discussion of the “units” of A please see 8.4.2.)

Travel times and capacities are reasonably well-defined variables, but the role of
the power n may be less well understood. Its purpose is essentially to control the
rate at which congestion affects travel time. Thus if a large number is chosen, say
5, travel times remain near their free-flow limit until flow approaches capacity, at
which point they increase rapidly to the congested values. On the other hand with
a low value of n, say 1 or 2, the transition is much more gradual. In general terms
high values of n are appropriate to high-capacity links without junctions at the end
to limit capacity, e.g., motorways, while lower values are more appropriate to low-
capacity urban roads where the effects of congestion are mainly associated with
the junctions. It should also be stressed that the choice of n values can strongly
influence the assignment results and that some care should be exercised in
setting them.

5101396 / May 11 5-17

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

While the above relationship is essentially a link-based curve there is no reason

why it should not reflect delays at intersections as well, in so far as that it is
possible using a power curve. Thus the travel times input should include the
times to traverse the junction at the end of each link in addition to the link travel
time. (They therefore differ in that respect from the link travel times defined for
simulation links.) In addition the shape of the curve above capacity is specifically
set to represent the queuing behaviour on an over-capacity link, assuming that the
queue builds up linearly over the time period (LTP) simulated.

Section 15.9 describes ways in which existing speed-flow curves may be

converted into the “best” values of n.

We note that the V<C component of the cost-flow curve, eq. (5.1a), may also be
written in a “parametric” form as:

t(V) = to + (tc – to) (V/C)n (5.2)

where tc = t o + ACn is the travel time at capacity. This form is sometimes easier
for user manipulation since it uses only basic variables and removes the necessity
to calculate the value of the coefficient A.

5.4.2 Queues and Bottlenecks in Buffer Networks

Buffer networks differ from simulation networks in the manner in which they model
flows which are in excess of capacity. Thus in simulation networks, as described
in 5.1.11, flows downstream of “bottlenecks” are reduced to take account of the
maximum flow that can get through the bottleneck, while queues at bottlenecks
can equally “block back” to reduce capacities upstream. Neither effect is
represented adequately within buffer networks.

Thus, if a link in the buffer network has been assigned a “demand” flow V in
excess of its capacity C, then it is assumed that a permanent queue forms on that
link and increases its length at a rate V – C. The consequent delay to traffic is
represented by the last term in Equation 5.1(b). However, the flow downstream of
that bottleneck Is not reduced and, if the next link downstream has the same
capacity C, then a second identical queue and delay will be modelled on that link
as well.

Hence, within buffer networks, there is a danger of V>C delays being “double-
counted” such that the total delays / travel times in the buffer network may be
significantly over-estimated. (Indeed this is a problem which all “conventional”
assignment models face and, generally speaking, fail to deal with adequately.)

Clearly the problem only manifests itself in assignment problems where there are
flows in excess of capacity so that, for relatively uncongested networks, a buffer
network level of detail may be perfectly adequate. However, for heavily congested
networks (or for heavily congested sections of network), the simulation approach
is recommended.

5101396 / May 11 5-18

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

The problem of double-counting may be reduced, though not completely removed,

by the use of the “UNIQUE” parameter described in Section 15.48. UNIQUE was
first introduced in release 10.7.

5.5 Assignment and Map Networks

This section describes two levels of network representation within SATURN

which, although not directly coded or accessed by users, are central to many
operations within SATURN and a general appreciation of their structure may be
useful

5.5.1 The Assignment Network

For the purpose of assigning origin-destination trips the simulation and buffer
networks are amalgamated together into a single “assignment network” which, in
topological terms at least, is a simple network made up of nodes and directional
links connecting them. Assignment network nodes consist of:

 zones (whether simulation or buffer)

 buffer nodes

 one node at either end of each simulation link

The assignment links consist of:

 centroid connectors

 buffer links

 simulation links

 simulation turns

Thus within the simulation network each simulation node is “expanded” in order to
create a set of “mini links”, one per permitted turning movements, which connect
the assignment node at the end of the entry link to the assignment node at the
head of the exit link. See Figure 5.2 where 8 “mini-nodes” are created at a 4-arm
node with (up to) 12 “mini-links”. Only the 3 turning movements (assuming no U-
turns) from arm A are illustrated. Banned turns therefore do not appear within the
assignment network.

Various arrays and/or procedures exist in order to map assignment nodes and
links with their counterparts in the simulation network and vice-versa.

5101396 / May 11 5-19

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

Figure 5.3 – A 4 arm node N and its expanded assignment network representation

By contrast in the buffer network there is a one-to-one correspondence between

buffer nodes and links and assignment nodes and links. In fact the buffer network
only exists as part of the assignment network whereas the simulation network has
“dual nationality”.

Listings based on assignment links occur at various points within SATURN, e.g. in
the SATDB outputs or the SATNET .lpn files. See 11.10.4 for an explanation as
to how they may be interpreted.

5.5.2 The Map Network

A further network description is created in order to deal, primarily but not

exclusively, with graphical displays in PIX. Like the assignment network the map
network is a simple topological network consisting of nodes connected by links.
Map nodes consist of:

 Zones

 Buffer nodes

 Simulation nodes (i.e. the junctions themselves, not expanded forms)

while each map link joins two map nodes. They therefore correspond to the
“lines” plotted on a PIX network and represent roads and centroid connectors
directly.

5101396 / May 11 5-20

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

For technical reasons all map links are two-way whether or not the road they
represent is one-way or not. Various matching arrays are also included within the
map definitions in order to provide the correspondence between map links and
assignment links and vice versa. Map links may therefore be matched to
simulation links via the assignment network.

Note that simulation turns are not directly included within the map network
although clearly if, say, a route is traced in the map network from nodes A to B to
C then it is possible to identify the simulation turn A-B-C.

5.5.3 Fixed Flows

Although the main function of SATURN is to assign trips from a trip matrix to O-D
paths in order to obtain (assignment network) link flows there are other
components of link flows which are effectively “fixed” independent of network or
trip matrix conditions. Fixed flows may arise from (and are the sum of) any or all of
the following

 Pre-loaded flows (15.5);

 Bus flows (6.9.1);

 PASSQ flows (17.3.1)

In general an assignment starts with the link flows as given by the fixed flows (if
any) and, if none, from zero flow. Note that it is sometimes necessary to carefully
distinguish between fixed and assigned flows, for example, when defining target
link flows to be matched by assigned link flows from a trip matrix under SATME2
(see 13.1.4) which should, by definition, exclude any fixed flows.

Since the fixed flows as seen by the assignment are simply the sum (in terms of
pcus/hr) of all the above three contributions it may be possible/convenient to
define bus flows as pre-loaded flows or vice-versa (15.5.5). For example, if you
have a very large number of low-frequency bus routes it may be simpler to simply
aggregate all their individual flows by link and input them as fixed pre-loaded
flows. However, as noted below, bus flows may have certain properties that
distinguish them from other flows, e.g., bus lanes.

Note as well that bus flows may be further sub-divided into buses that use the
same lanes as “normal” traffic and buses that are assigned to bus-only lanes. The
latter flows are, in effect, totally distinct from “normal” link flows and there is no
interaction between the two. For example, buses on bus-only links do not make
any call on the modelled link capacities nor do they affect link travel times,
whereas other bus flows (and, indeed, all other fixed flows) do. See 15.39 for
further details.

5101396 / May 11 5-21

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

5.5.4 Network and/or Trip Matrix Connectivity

In general one would expect that in any “real” road network it should be possible
to travel from any one node to any other node in the network; if this is not possible
then it is more likely to be an error in the network coding rather than a genuine
property of the network. (N.B. There are certain exceptions to this rule: e.g.,
“origin-only” or “destination-only”l zones which are connected by one-way links to
the network proper and which, by definition, are not accessible to/from all other
parts of the network or banned turns designed to prohibit entry to certain sections
of the network.)

SATURN therefore contains various checks for a lack of connectivity in input

networks and trip matrices. These exist at two levels: (a) checks on the network
topology and (b) checks on the trip matrix.

Under (a), SATNET performs two separate but similar sets of checks based on:
(1) the “map network” (see 5.5.2 above) in which all one-way links and banned
turns are ignored and (2) on the assignment network in which they are included. In
both cases a “tree” is constructed from zone 1 in order to determine whether there
are any points in the network which cannot be reached. If there are any under (1)
then a non-fatal error 278 is generated which, if WRIGHT = T, is upgraded to a
semi-fatal error. Under (2) any examples generate a warning message 47 only
since a lack of connectivity may simply be due to one-way streets and/or banned
turns although they may sometimes be symptomatic of more serious coding
problems.

Under (b) SATNET attempts to build a path from origin to destination for every
non-zero cell in the trip matrix over all user classes in order to detect any positive
cells for which no permitted path exists. Any such occurrences generates non-
fatal error 277 which, if WRIGHT = T, is upgraded to a semi-fatal error. In this test
one-way links and banned turns are taken into account. If the trip matrix has not
been defined within SATNET then the same test is repeated within the first
assignment carried out within SATALL.

5.6 Building Networks: The Beginner's Guide

5.6.1 Getting Started

By now it should at least be clear that there are two essentials for running
SATURN, a network and a trip matrix. There are many variations on each of
these, of course, but at their simplest both network and matrix will be for a single
class of vehicle. So how should you go about setting these up? Here we try to
answer this question.

The network and matrix together represent a scenario, which may be a Base case
or a “What if” type of test where either or both of the network and matrix are
assumed to change from the Base. In starting a new project and defining
appropriate networks and matrices, you can work either from existing versions of
each (if available), or from scratch. With the latest versions of SATURN, the

5101396 / May 11 5-22

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

procedures to follow in each case are designed to be similar, with a strong

emphasis on interactive and graphical editing, particularly of networks. Our
approach is described below

5.6.1.1 Network Building and Editing

In early versions of SATURN, network building was simply a case of settling down
with a network plan and coding, in strict ASCII style using a text editor, a series of
nodes and links which described the structure and detail of the network. The
format for such a coding procedure is described in full in Section 6 of this manual.

Happily, there is now an easier alternative using P1X, which allows the user to
input network detail through a graphical editor on the screen and to see the
network develop progressively. Although a single philosophy underlies the
procedures for both creating networks from scratch and for editing existing
networks, it will be helpful to start by describing the first of these on its own.

5.6.1.2 Starting from Scratch

To start the network editor without a prior network, type:

PMAKE newnet

Where newnet.DAT will become your new network file on exit from PMAKE. (Just
to confuse you, PMAKE will actually take you into P1X but PMAKE is used to
differentiate the commands between building from scratch and modifying existing
networks - see also later.)

You will be asked to define maximum and minimum screen co-ordinates and
whether you wish to import a bitmap as a back-screen to network building, or just
proceed with a blank screen. Continue takes you to the network building screen.
Here you can set both &Option and &Param parameter values (Section 6.3) which
will control the operation of the model and subsequent runs. More importantly, you
can start to build your network.

The philosophy adopted in SATURN network building is for the structure to be

defined initially at Buffer level, where nodes exist only as places at which links
join, with detail for nodes added subsequently by converting them from Buffer to
Simulation. Both activities are accomplished using PMAKE/P1X, but we must as a
first step define the structure of the network purely in terms of node positions and
their connectivity.

Click on Node Edits in the banner. The choice will be to define Nodes or (Buffer)
Zones. Choosing nodes allows you to position nodes with a single click. Active
options are shown in capitals in the banner, and you may switch between user
defined node names and the Auto-definition of names as required. A further option
allows links to be defined automatically between successive nodes, but see also
link definition options below.

5101396 / May 11 5-23

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

Clicking on the Zone option in the banner allows the placement of zones in an
identical fashion. If you now continue, you will find that further options are now
open to you, including the ability to delete, re-number and re-position nodes and
zones. You will also be able to add further areas of network in future sessions
using these tools.

5.6.1.3 Defining Links

Return to the Master Menu and select Link Edits. Links are defined by clicking on
successive pairs of nodes until the network is complete. Further options exist to
delete and change link directions. Splitting links is possible from both link and
node sub-menus.

5101396 / May 11 5-24

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

5.6.2 Editing Existing Networks

Once a network structure has been defined as above, you are in the same
position as if you had entered P1X with an existing network and Continue takes
you to the usual Master Menu of P1X. The options include those to change files,
devices, window and displays, as well as SATLOOK and SATDB choices.

Here we are concerned foremost with the EDIT Banner option. Click on this and
the options shown below are revealed.

Two options, in particular, are of interest. The first, conVert buffer, allows any of
the already defined nodes to be converted into simulation and applies equally to
networks just constructed in PMAKE as it does to imported networks. The second
allows structural changes to be made using the node and link definition and edit
options described above as part of PMAKE. The operations available under each
option are described below.

5.6.3 Converting Nodes

Selecting the Convert Buffer Nodes option leads you to a menu which asks you to
choose a buffer or external simulation node. You do this by clicking on the node
on the screen. Your node will be displayed, ready for editing.

External nodes mark the boundary of the simulation network, and as such are a
special type of simulation node. Where externals are connected to both simulation
and buffer nodes, they can be converted to buffer as the simulation area is
extended. Note that in such a case, the adjacent buffer nodes will themselves be
required to become external nodes, a process which can be automated through
setting namelist AUTOX =T.

5101396 / May 11 5-25

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

Once selected, you are asked to choose the type of node you want. The example
below follows the creation of a signalised junction, the first screen involving the
choice of a stage time for the movements to be defined next. In this example, a
30 second first stage is defined. An inter-green time will also be requested.

Allowed movements within each stage are defined by moving the mouse over the
relevant turning movement in the right-hand banner, the movement being shown
on the junction display as a bold red arrow. Clicking the mouse will place the
highlighted movement in the stage box at top left. Other movements are added
until the stage is defined, whereupon following stages can be defined. If a mistake
is made, stages can be edited once input is complete.

Once all stages have been defined, continue and you will be faced by the node-
editing menu in the banner. Here, you can select to edit node variables, such as
minimum gaps and modelling steps, link values, such as distance or number of
lanes, or turn details, such as lane allocations, priority markers and saturation
flows. Where links or turns are involved, the active one is always shown
highlighted on the junction plan in centre-screen, as shown below.

5101396 / May 11 5-26

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

When complete, Quit and Save the node data (remembering also to Save the
node to an internal data file) and continue to the next. Note that by clicking on
Print you can view the node coding at any time.

5.6.4 Structural Changes in PMAKE

The edit functions in PMAKE are designed to allow structural changes to be made
to a network. Once selected, the network edit options allow the user to edit Nodes,
Links and (simulation) Centroid Connectors. Further choices include the
modification of Namelist control Parameters.

Under Node Edit, the user can choose to Add or Delete Nodes, Split Links (ie.
Add a new node between two existing nodes), Renumber and move nodes.

Within the Link Edit facility, users can Add and Delete Links, change properties
(both Buffer and Simulation) and split links. Where new links are created into
junctions (changing, for instance, the number of arms at a junction), the user is
prompted to review the junction coding and input the necessary changes to
ensure its correct functioning, from turn allocation to lanes to signal phases and
timings.

Centroid connectors may also be changed interactively, with the options to add,
delete or modify all available

5101396 / May 11 5-27

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

5.6.5 Completing the Edit Session

At the end of your editing session, continue to exit the node edit section and, in
the banner, save the file as a .dat ready for use in SATNET. You are also allowed
to save as a UFS file at this stage, but we strongly recommend that the additional
safety checks built into SATNET be used before progressing to assignment. From
a command line prompt, type:

SATNET netname

where netname.dat is the name of the saved network data file. The most likely
thing to go wrong at this stage is that, with new simulation nodes created, you will
have connections straight from buffer nodes to simulation nodes without
intervening Externals. The easy way round this, as described earlier, is to set
AUTOX = T in the PARAM namelist section at the head of the netname.dat file.

Once a successful network build has been achieved, you are ready to assign your
trip matrix, although creating the trip matrix may be a bit more complicated than
simply drawing on the screen.

5.7 Geographical Information System (GIS) Data

5.7.1 General principles

GIS files (where GIS stands for Geographical Information Systems*) are
supplementary files which contain essentially “background” data to be included,
for example, in network plots. Thus GIS files describe both “topological” data
such as political boundaries, geographical features such as rivers, railway lines,
stations, etc. and “text” data such as names to be associated with nodes or links.
Their use enables plots to more closely resemble actual maps rather than
idealised representations of road networks - and hence more acceptable for
presentations.

The precise definition and specification of what GIS files contain is still somewhat
fluid but certain broad principles have been established. Thus:

 GIS files refer to areas, not to specific networks. You do not need to create a
new GIS file each time you add a new link to your network or change from a
“do nothing” to a “do something”.

 The data in GIS files is applicable to matrices as well as to networks, e.g., the
alpha-numeric zone names.

* GIS files in SATURN should not be confused with “proper” GIS files as in MAP - INFO or ARC-
INFO. In fact a more accurate, if less impressive, acronym would be something like BIF for
Background Information File.

5101396 / May 11 5-28

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

 GIS files are “text” or “ascii” files as opposed to “binary” files. It follows that
data can also be “translated” from other data sources by essentially “re-
formatting” without going through a SATURN program.

 Data has a “hierarchical” structure which controls the order in which the data
is displayed in P1X plots. Hence text is displayed AFTER in-filled areas so
that the name of a zone will over-print the coloured area.

Although primarily intended to be used by P1X the data within a GIS file is also
relevant to a number of other programs; thus SATLOOK, SATED, SATDB and
MX can all access GIS files.

More precisely the following sets of data can be included within a GIS file (such
that (a) is at the bottom of the hierarchy and is plotted first);

a) Closed “polygons” which enclose an area; e.g. a zone

b) Sets of contiguous straight lines - “polylines” - used to represent rivers or

railways, etc;

c) “Ikons”, i.e. standard symbols such as the BR symbol to represent a

railway station;

d) Text;

e) Alphanumeric link, node, zone and sector “names”;

f) Polyline data to display links as “curves” or as “arcs” of a circle rather than

straight line segments (see 5.7.3);

Node co-ordinates (which are also stored on network files but are included on GIS
files partly for convenience and partly so as to be accessible for matrix
applications).

Data sets (a) to (d) have certain “characteristics” associated with them. Thus they
have a choice of colour, areas can be in-filled or not, lines can have a width
(defined either in mm on the screen or in metres “on the ground” which is
translated into an equivalent width “on the screen” when displayed), and ikons and
text can have a size and colours. And of course all of them have spatial
coordinates. All of these are set by the user on the GIS file.

GIS files are “formatted” - thus fixed columns are used to define each
characteristic; the current conventions are specified in Appendix Z.

The filename of the GIS file to be associated with a network may be defined within
the network or matrix .dat file using the Namelist parameter FILGIS and that name
is then carried forward on the UF* files. Thus those programs which require data
from the GIS file can open the file automatically. Alternatively interactive
programs allow a GIS file to be defined from the Files Menu.

5101396 / May 11 5-29

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

Within P1X the GIS data to be included in the plot may be selectively requested
(11.6.10); e.g., you can have the polygons but not the polylines, but you then get
all the polygons.

5.7.2 Creating/Editing GIS Files

A GIS file, being an ascii data file, can be created either from scratch using an
editor or by re-formatting other data sources, e.g., geo-coded zonal boundaries.
Starting from scratch and following the formatting conventions given in Appendix Z
is NOT recommended - hard work! Re-formatting existing data sources is
sometimes a very good idea, particularly when a lot of very precise data is
required, as with zonal boundaries. It should, for example, be relatively simple to
extract data from “proper” gis systems such as mapinfo, etc. and to reformat as
required by SATURN GIS files.

However a mouse-based option to create or edit (augment) a GIS file is provided

within the edit functions of PIX (11.9). This is particularly recommended for
operations such as adding alpha-numeric names for either nodes or zones -point
to the node and type in a name; precise co-ordinates are not needed.

A typical GIS display used with network annotation (a forest of routes from origin
zone to destination zone) in P1X is shown below.

5101396 / May 11 5-30

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

5.7.3 Curvature Poly-lines, Arcs and Circles

“Curvature” refers to any method by which a link from A to B is not represented by

a straight line but by a curved line. There are two basic methods by which this
may be done:

a) The link is defined as a “poly-line” of 1 or (generally) more intermediate

points between A and B; or

b) As the “arc” of a circle such that both A and B lie on the circle

Under (b) it is only necessary to define the co-ordinates of the centre of the circle,
the program then, in effect, creates a poly-line which follows the arc from A to B.

(Geometrically the centre of the circle must lie on the “right bisector” of the line A-
B, i.e., the line which runs at right angle to A-B and passes through their mid point.
This ensures that both A and B lie on the circle. If the centre is a long way from A-
B then the arc will be relatively flat; if the centre is near the mid-point of A-B the
curvature will be very pronounced.)

A variation on (b) is that of a “full circle” where all links in a closed loop are
individually defined as arcs with the same centre of curvature so that the closed
loop is plotted as a circle. The most obvious application of this is when a
roundabout has been broken down into a series of sub-nodes (e.g., essential for a
large and/or signalised roundabouts) and it is desired to plot each sub-link as part
of a circular roundabout.

The two sample plots below demonstrate an expanded roundabout with the four
sub-links on the roundabout plotted as straight lines (bottom) and with the links as
part of a GIS circle (top). Link flows are being annotated as bandwidths. Note that
the plot could be further improved by introducing curvature to some of the other
links, e.g., the entry links onto the roundabout.

5101396 / May 11 5-31

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

When curved links are created interactively within P1X three options are provided:
poly-lines, (single) arcs and circles.

5101396 / May 11 5-32

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

5.8 User and Vehicle Classes

5.8.1 User Classes

Multiple user classes (MUC) are used within the assignment to refer to trips which
differ with respect to either

 vehicle type;

 their criteria for route choice;

 network restrictions;

 demand characteristics (e.g. elasticities)

For example, lorries and cars would constitute different classes as would
cars/drivers seeking minimum time routes and minimum distance routes. Equally
cars and taxis would be different classes if there were taxi-only links. MUC
assignment is therefore the problem of assigning a number of different user
classes to the same road network.

Restrictions in this context may include class-specific bans but also class-specific
time penalties or monetary tolls so that one may use user classes to distinguish
various groups of drivers paying different parking charges, for example.

 Similar problems may also arise within the demand (elastic) models
interfaced with SATURN assignments where (7.9) we may wish to distinguish
between two or more groups of trip makers who respond differently to costs in
terms of whether to travel by road or not but who may be identical in terms of
route choice.

 The number of user classes is set by the parameter NOMADS with the default
value of 1 for a single user class and an upper limit of 32. Their rules for
route choice are specified within the network specifications, e.g. sections 6.7
(link restrictions) and 6.11 (generalised costs).

Note that user classes, although normally referred to by their sequential numbers
1, 2, 3… NOMADS, may also have short (up to 40 character) text names
associated with them via the namelist parameters UCNAME ( ) input to SATNET
(6.3.4). These are used in, e.g., output LP files.

User class specific link flows may be displayed, e,g., within P1X, by using the
normal menus. They may also be obtained by using a “trick” involving DA codes
such as 3808; see Section 15.21.4.

5.8.2 Vehicle Classes

The concept of a “vehicle class” was first introduced into SATURN 9.5 but, at the
time of writing, is still relatively little used.

5101396 / May 11 5-33

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

Vehicle classes are defined purely with respect to the physical characteristics of
the vehicle and are unrelated to the driver characteristics. Examples would be
petrol cars, diesel cars, heavy lorries (HGVs), single-decker buses etc. Cars
driven by, e.g. time minimisers and distance minimisers would be the same
vehicle class although different user classes.

Vehicle classes may be defined for each user class (within the 88888 network
data records; see 6.11) or bus company (see IBUSVC, 6.9.3) and multiple user
classes may be assigned to the same vehicle class. For example, if a user has
defined 5 user classes – say, cars (resident), cars (non-resident), taxis, LGVs and
HGVs then it might be natural to define 3 vehicle classes where class 1 would
include both car user classes plus taxis, class 2 would include (and be
synonymous with) LGVs and class 3 would be HGVs. Buses could be included
with either of the 3 vehicle classes above or assigned their own vehicle class
(e.g., class 4)

The number of vehicle classes used is not defined by an input parameter - as are
user classes by NOMAD - but is determined by the highest value used (up to a
maximum of 32). Like user classes they may be given text names - VCNAME( ) in
6.3.4 - of up to 40 characters to be used within outputs.

The long-term intention is that different vehicle classes will have different emission
and fuel consumption characteristics and some development work on the former
is now included in SATURN; see 15.33. Equally they may be used in the
calculation of tolls - see 20.4.1 – and in the updating of matrices within SATME2 –
see 13.4.6.

Note that it is not possible to have more than one vehicle classes per user class.
For example, if all car drivers are assumed to be identical in terms of their
generalised cost but drive a mix of vehicles then, in terms of assignment, it is most
efficient to define them as a single user class. On the other hand, in order to
model the different emission characteristics of different vehicles, it would be useful
to be able to split them into different vehicle classes. However, disaggregation into
vehicle classes may be only done by disaggregating the user classes as well -
which is not particularly efficient in terms of assignments. A compromise solution
would be to define car drivers as a single vehicle class but to define their emission
and fuel consumption coefficients by an appropriate weighted average.

Vehicle classes (and hence, indirectly, user classes) may also be assigned PCU
factors VCPCU (see 6.3.3 and 15.17.2), i.e., the values of pcu‟s per vehicle which
are used as required to convert flows in pcu‟s per hour into vehicles per hours.
[Recall that all trip matrices and therefore link flows in SATURN are defined in
units of pcu‟s or pcu/hr so that VCPCU is used to convert them to vehicles when
required] VCPCU values are used, for example, in the calculation of total toll
revenues from pcu flows since, one assumes, tolls are levied per vehicle rather
than per pcu; see 20.4.1.

We note that the same PCU factors should also have been used if trip matrices
originally obtained in units of vehicles per hour had been factored into matrices of
PCUs per hour; see 4.3

5101396 / May 11 5-34

10_09_24_Section 5.doc
SATURN MANUAL (V10.9)

Network Coding – A General Description

5.9 Version Control

JOB NUMBER: 5101396 DOCUMENT REF: Section 5.doc

Revision Purpose / Description

Originated Checked Reviewed Authorised Date

1 Re-formatted (Final to DVV) TF / BG NS IW IW 06/05/06

2 DVV Changes

3 Upgrade to v2 Template 22/06/06

3.2 Web release – Sept 06 DVV NP IW IW 08/09/06

3.3 Web release – Jan 07 DVV NP IW IW 04/01/07

3.4 SATURN v10.7 Release DVV NP IW IW 12/03/07

3.5 Web release – Jul07 DVV NP IW IW 19/07/07

3.6 SATURN v10.8 Release DVV NP IW IW 26/01/08

3.7 Web release – Jul08 DVV NP IW IW 07/07/08

3.8 Web release – Dec 08 DVV NP IW IW 12/12/08

3.8.21 Web release – Feb 09 DVV NP IW IW 16/02/09

3.8.22 Web release – Jun 09 DVV NP IW IW 16/06/09

10.9.10 SATURN v10.9 Release DVV DG IW IW 04/09/09

10.9.12 SATURN v10.9 Release (Full) DVV DG IW IW 22/10/09

10.9.17 Web release – Jun 10 DVV NP IW IW 22/06/10

10.9.22 Web release – Dec 10 DVV AG IW IW 06/12/10

10.9.24 SATURN v10.9 Release (Full) DVV AG IW IW 06/05/11

5101396 / May 11 5-35

10_09_24_Section 5.doc