SATURN MANUAL (V10.

9)

P1X: Interactive Analysis of Results

11. P1X: Interactive Analysis of Results

11.1 Introduction

The SATURN network analysis program P1X combines together the functionality
of four original analysis programs, P1, SATLOOK, SATDB and SATED, plus extra
functions such as network cordoning (SATCH), signal optimisation (SATOFF) and
network building (SATNET) into a single multi-purpose network analysis program.

In brief SATLOOK caters for alpha-numeric output and analysis of .ufs files, P1
provides graphical analysis and network editing, SATED edits simulation nodes
and SATDB provides spreadsheet-like facilities. Since the four basic functions
are relatively distinct it is often useful to refer to them by separate program names.
SATLOOK and SATDB (plus, strictly, SATED although it has been largely phased
out) exist as separate programs although they may also be accessed directly
through the top menu in P1X.

P1X (plus SATDB and SATLOOK) runs primarily in an “interactive mode”, i.e.,
with all requests for options, etc. input directly via menus as opposed to the “batch
mode” with instructions pre-set in a control file. Basic principles are described in
Section 19. However all these programs can also be run in a “quasi-batch” mode
by setting up a “key” terminal input file with the desired responses in the correct
order (See 14.5).

Function-specific information is given in Sections 11.2 to 11.15 and technical

specifications in 11.16 to 11.19. These sections are fairly general in nature since
the programs are designed to be “self-documenting” in that the menus should be
self-explanatory and these in turn are backed up by a “help system” as explained
in 19.11.

To run any of these programs under DOS or Command Prompt simply type the
program name followed by one or more “command line” parameters to request
certain network files, e.g.

P1X LIV93

to examine the network file LIV93.UFS. For full format instructions type P1X etc.
on its own. (See also 14.1)

Note that all interactive programs automatically produce “line printer” files which
contain a permanent record of most of the interactive steps, relevant inputs and
outputs etc.

11.2 Network Plotting (P1X): The Master Menu

The graphics program P1X contains virtually all the analysis functions provided
within SATURN, including those functions previously available only in SATED,

5101396/ May 11 11-1

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

P1X: Interactive Analysis of Results

SATDB and SATLOOK as well as the cordoning program SATCH. The SATDB
and SATLOOK sub-modules, which are text - as opposed to graphics-based - are
entered from the main P1X menu; documentation for them is found in sections
11.10 and 11.11 respectively. SATED-style node graphics options are entered
either from the top menu or from within network editing.

On first entry to a run of P1X and on subsequent returns the “master menu” allows
access to a large set of sub-menus which may be classified into (with further
information given in the sections noted) :

1) System/device definitions; 11.3.

2) File control; 11.4.

3) Network Windowing; 11.5.

4) Basic network display (including GIS, 5.7.1); 11.6.

5) Validation options; 11.7.

6) Analysis Options; 11.8.

7) Information Options; 11.8.4

8) Convergence statistics, 11.15

9) Edit options (including both network, GIS and PMAKE); 11.9.

10) SATDB-based facilities; 11.10.

11) SATLOOK-based facilities; 11.11.

12) Node graphics (SATED) display; 11.12.

13) Network cordoning (SATCH); 11.13.

14) (Pure) Matrix graphics; 11.14.

Certain of these facilities may also be accessed at points in the program other
than the “master” menu by commands in the menu bar. For example you may
change the network window, the network display options and (some) system
parameters from most locations within PIX. See 19.5. In addition a number of
other functions are only available through the menu bar; see, for example, 11.5.3.

To return to the master menu from any sub-menu within P1X click on “Master
Menu” under “Back” in the Menu bar and further select any of the 13 standard
“top” menus listed above (or the master menu itself) via the sub-list.

5101396/ May 11 11-2

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

P1X: Interactive Analysis of Results

11.3 System/device Definitions

11.3.1 The Graphics Device Definition file GRAF.DAT

Users of 32-bit SATURN need probably not read this sub-section as under e.g.
WINDOWS 98 or NT, output to graphical devices makes use of WINDOWS
drivers which, thankfully, are largely self-sufficient. Thus output goes either to the
“screen” or the “printer” (the “alternative” device), whose essential properties are
available through the operating system. Hence the file graf.dat becomes largely
optional. However a certain amount of “fine tuning” in graf.dat may be useful for
SATURN users, e.g. to control the size of output text-note (v) below.

Before P1X (or any other graphics program) can produce graphical output it
requires certain minimal information about the device(s) to which the output is
directed. For example, it may need to know the device dimensions in order to
correctly scale the plot. This information is contained in a supplementary file with
the standard name ‘GRAF.DAT’ which contains all the information necessary to
“tell” the program about the output devices available to it. It is therefore
installation-specific.

The following data needs to be supplied for each potential device:

(i) Whether it is a vdu screen or a hard copy device. (A “screen” is any device
for which column 30 on the first record for that device contains a 1 or greater
whereas a “printer” contains a zero.)

(ii) Its maximum X and Y dimensions, both in physical millimetres and in

(device) pixels.

(iii) The number of “pens” (/colours) available (SATURN programs assume 16

but the output device may have fewer, in which case it is necessary to “map”
the 16 SATURN colours into the smaller set.)

(iv) “Pen mappings”, either for the above reason or if, say, you wish to have
output in red when SATURN thinks it is outputting in green.

(v) Various universal scaling parameters to, for example, make the output text
characters bigger or smaller.

For a full description of the contents of GRAF.DAT, its format etc the reader is
referred to the file itself which, after the initial data set, contains documentation.

A standard version of GRAF.DAT is supplied with SATURN with a number of

standard device definitions; users may well need to modify this file to suit their
own available devices. If for any reason a SATURN program cannot locate
GRAF.DAT an internal default set of device definitions is used. This contains
specifications for common device types - the screen and printer under 32-bit as
mentioned above - and should therefore be sufficient for most users’ applications.

5101396/ May 11 11-3

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

P1X: Interactive Analysis of Results

11.3.2 The Primary and Alternative Devices (Screen and Printer)

P1X (and any other programs that use graphics) define two “active” devices, a
“primary” and an “alternative” or “secondary” device. Output is directed initially to
the primary device which, logically, must be the monitor screen. However output
may also be sent to the alternative device which, equally logically, must be a
printer or other hard copy device (or a file destined for hard copy); see 11.3.5.

On entering the program the first two devices in the GRAF.DAT list or its internal
default become the primary and alternative devices. The default makes them
“screen” and “printer”. Either may be changed within the System/Device menu -
see 11.3.3 - although the primary device must always be a terminal (so little
choice there) but the alternative device will need to be changed as output is to be
directed to a different device.

To send output to the alternative device use the “Print Graphics” option under
Files in the menu bar (or, very occasionally, select the appropriate option in the
banner, generally either A for Alternative or P for Print).

Another form of “alternative” output is output to bitmap files or the clipboard

(11.3.6), the difference being that in these cases the “device” being used is fixed,
not user set.

11.3.3 The System/Device Menu

Having initialised the primary and alternative devices and their characteristics the
System/Device Menu allows one to either select other devices (primary or
alternative) or to redefine certain properties of the current devices. Under 32-bit
SATURN only the latter functions are generally relevant as the default devices -
screen and printer - are fine for most purposes.

The choices within the System/Device menu may be summarised as follows:

(i) Definition of the primary and alternative devices (11.3.2).

(ii) Parameters for the primary and/or alternative device. (11.3.4)

(iii) General properties of the “pens” or colours; e.g. choice of the background
colour. (11.3.7)

(iv) Colours/pens used in the banner. (11.6.9)

(v) Choice of the “root” filenames used by bitmap files (11.3.6)

(vi) Choice between mouse and keyboard control (19.4).

(vii) Left vrs. right-hand drive (available elsewhere as well).

5101396/ May 11 11-4

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

P1X: Interactive Analysis of Results

Note that a reduced version of this menu - with the device choices removed - is
available under “Show” in the menu bar (32-bit version).

11.3.4 Device Parameters

The parameters submenu controls the interface between the commands issued by
the program and what appears on the screen/printer. It is, for example, most
useful if the characters on the screen appear to be too large or too small or if the
size of, say, node shapes are disproportionately too small or too large.

Separate menus for the primary and alternative devices are provided.

The following “parameters” are (potentially) relevant to both:

(i) the physical width and height of the device (in mm)

(ii) the maximum “shrinkage” acceptable for characters (e.g. 0.5 implies that
characters may be reduced in size by 0.5 in order to fit the space provided
before they are likely to become indecipherable.)

(iii) The desired standard height of characters (in mm).

(iv) A correction factor (which ideally should be 1.0 but often needs to be 1.35)
for all character sizes.

(v) The ratio of character width to height.

(vii) The pixel resolution of the device being used

(viii) A “rotational shift” to empirically correct problems with annotation which is

rotated from the horizontal or vertical.

(ix) The standard pen definitions (11.3.7)

(x) Font controls including “DIY” fonts (11.3.8)

11.3.4.1 Device Height and Width

Height and width values are important so that the program “knows” if it is sending
output to, e.g., an A4 or an A0 device. For example, if a program wishes to draw
a box 20mm wide and it “thinks” the device is 200mm wide it draws it as 10% of
the width; if the actual width were 400mm then the box will come out as 40mm.
Getting the dimensions right is therefore most critical with “non-standard” devices
such as A0 plotters.

To help in getting the dimensions right (for the secondary device, e.g., printer)
users may alternatively define the device “size”, i.e., A0, A1, etc., plus whether or
not it is “landscape” or “portrait” (although it is quite likely that the Windows driver

5101396/ May 11 11-5

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

P1X: Interactive Analysis of Results

itself will decide which way a plot best fits an output device). The program then
supplies the appropriate standard width and height automatically.

11.3.4.2 Character Heights and Sizes

The standard character height (5mm by default) and the correction factor play
similar roles in that both can change the size of characters plotted. Our advice
would be to set the standard height to whatever you do want and then, if the
resulting characters are too large or small, correct via the correction factor (see
below).

The ratio of width to height should be adjusted if, say, the node numbers within a
node shape are the right height but are too wide/not wide enough.

11.3.4.3 Correction Factor

A common situation, illustrated below, is that characters in the banner are too
large and may both overlap vertically as well as not fitting horizontally into the
(nominal) 40 mm width of the banner; in this situation the correction factor needs
to be reduced. Alternatively (not illustrated) the characters in the banner may be
too small, in which case the correction factor needs to be increased.

The correction factor compensates for poor communication between the programs
and the device drivers and is related to the device/screen resolution. Ideally the
correction factor should be 1.0; however, empirically, a value of 1.35 appears to

5101396/ May 11 11-6

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

P1X: Interactive Analysis of Results

be required for the majority of screen settings to which SATURN is applied and
that is therefore (currently) the default.

Generally the problem of over-sized characters occurs with low-resolution screen

settings; therefore one solution to the problem may be to increase your screen
resolution. If this is not feasible or does not work the only alternative is to adjust
the correction factor within P1X. From the menu enter “Primary dev”, select
Correction Factor and input a new value. Some trial and error testing may be
necessary.

Since the default value, i.e., the 1.35 above, is read from the graf.dat control file
users may also wish to change graf.dat. This may however be a bit difficult with
networked computers if the same central version of graf.dat is being used by a
number of different machines.

The same considerations apply to the alternative (i.e., printer) devices if output
characters are universally over- or under-sized; either change the correction factor
for the secondary device interactively prior to printing or (preferably) ensure that it
is changed in graf.dat. Unlike terminal screens, however, a default value of 1.0 is
probably fairly safe.

11.3.4.4 Rotational Shift

The “rotational shift” parameter is provided as an empirical fix to a problem which

may occur with certain devices (both screen and printer) when annotating text at
an angle (e.g. annotation along a link in P1X). Thus you may observe that the link
annotation, which should appear “just above” or “just below” the line may, be
shifted away/towards the line. The rotational shift parameter (defined as fractions
of character heights) moves the text up or down depending on the sign. N.B. It
has no effect on either horizontal or vertical annotation where the problem does
not occur.

A more drastic solution to the same problem is to use a set of SATURN “DIY”
fonts as described in 11.3.8.

11.3.4.5 Pixel resolution

The pixel resolution should, in theory, be for information only since a clever
computer plus program should be able to work it out for itself. It is provided on the
basis that if nothing else works then changing the pixel resolution may improve
your outputs. Use with caution!

Changes made here should probably be made “permanent” for your installation by
editing them into your version of GRAF.DAT; otherwise you may need to repeat
the changes every time you enter P1X.

5101396/ May 11 11-7

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

P1X: Interactive Analysis of Results

11.3.5 Hard Copy and/or File Outputs

Hard copy output from SATURN graphical programs may either go “directly” to a
device such as a printer or plotter which is connected “on line” or “indirectly” via a
file which is subsequently spooled to an appropriate device. Clearly in the latter
case multiple copies may be created as desired.

Hard copy output is selected using “Print Graphics” under File in the Menus Bar
which then brings up a standard Windows Printer Dialog Box. Use this to select,
e.g., whether the output is to go directly to a file or to a device; in the latter case
you may need to nominate the device if more than one is available.

The “characteristics” of the hard copy device are set by default within GRAF.DAT
but may be over-written within the program (11.3.4). In particular, note the
importance of defining the physical width and height of the device correctly as
they may affect the “quality” of the output.

Hard copy output normally includes everything that appears on the screen
although if the output device is bigger than the terminal screen you may get more
numbers annotated because there is more space available. However, optionally,
using a parameter set within the Banner Display Menu (11.6.9), the menu choices
displayed within the banner may be excluded from the output hardcopy/file.

Certain problems may occur with hard copy outputs to printer; see 11.3.9 for
further details.

11.3.6 Bitmap Files: Output and Input

Salford FTN77 compilers include options to “dump” the screen image into an
external “bitmap” file. These files may then be re-read by certain programs and
re-displayed on the screen. For example they may be accessed by the
“paintbrush” program with Windows and by Harvard Graphics and, if necessary,
re-directed to hard copy devices via these programs.

Equally bitmap files may be used as inputs to P1X and displayed, e.g. as
“background” to SATURN plots.

Bitmap files open up all sorts of interesting applications, for example directly
inserting SATURN graphics into word-processed documents or putting your own
logo onto a SATURN plot. However there are restrictions as to the type of files
which FTN77 can import and export so that SATURN is effectively restricted to
“pcx” and “bmp” files and screen images sent to and from the clipboard.

To create an output bitmap file choose either pcx, bmp, jpg (post release 10.8.20)
or clipboard through the menu bar (under Files). If pcx, a file with extension “.pcx”
is then created. The initial part of the “pathname” is composed from a “root” which
may be set within the Systems/device menu (11.3.3) and a sequential number.
Thus, if your root name is “harry”, the output files are, in succession, harry1.pcx,
harry2.pcx, etc. Similarly, if bmp, the output files will be harry1.bmp, etc etc.

5101396/ May 11 11-8

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

P1X: Interactive Analysis of Results

Optionally, using a parameter set within the Banner Display Menu (11.6.9), the
menu choices displayed within the banner may be excluded from the output
bitmap file.

SATURN also allows bitmap files to be read as input files and displayed on the
screen so that they may be used as a “background” to a P1X plot. Thus you may
superimpose P1X plots on, e.g., OS-style plots of the same area. See Section
15.43 and under PMAKE, section 18.

Note that, at the moment (release 10.8.20), only .bmp and.or .pcx files may be
input, not .jpg. It is hoped that jpg inputs will be made available shortly.

11.3.7 Pen/Colour Definitions

SATURN plots normally use 16 colours (defined with standardised palettes) and
each plotted element uses one of the 16. It is possible for users to select different
colours in two different ways:

♦ global changes;

♦ individual applications.

Thus under global pen changes it is possible to “map” one pen into another. For
example if the standard pink pen (#13) is very faint on your device it may be
mapped into, say, the red pen (#4) using the Pen Definitions menu under
System/Device.

Alternatively if one particular application uses a colour you don’t like, for example
the pen colour used to annotate nodes on link plots, then there are menus where
particular pen definitions may be changed without making that change global. In
particular, the “background colour” of the plots (which defaults to white) may be
re-set within this menu.

11.3.8 Alternative Fonts

Generally speaking the “fonts” used to display alpha-numerics to the screen or

printer are those supplied by the device driver as activated via the program using
Salford FTN77 commands. These are largely outside the control of the user.

However it has been found that with certain hard copy devices (apparently only
those larger than A4) annotation which is being written “at an angle” (i.e. neither
on the horizontal or vertical) sometimes (not always and not always consistently!)
appears in the wrong position with the wrong orientation. And nobody in Salford
can explain why! Part of the problem may be solved using the Rotational Shift
(11.3.4) but empirically this is not fool-proof.

To deal with this problem an empirical fix has been added (Version 10.3) which
uses an alternative set of character fonts for hard-copy annotate-at-an-angle only.
These fonts are based on relatively simply DIY principles of drawing characters as

5101396/ May 11 11-9

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

P1X: Interactive Analysis of Results

a sequence of short lines so that they lack the sophistication of “proper” fonts.
However they do at least appear where they are meant to appear and at the
correct orientation and are damn sight better than the alternative!

To select the DIY font for the secondary device “toggle” the appropriate option
within the menu Parameters: Second dev. under the System/Device menu. Note
that the option does not appear for the primary device since the problem does not
occur there.

By default the characters drawn by the DIY font are one pixel wide which, for most
devices, is rather faint. Therefore a finite “thickness” may be set to improve
legibility; generally speaking values of the order of 0.3 mm should be sufficient.

11.3.9 Problems with Hard Copy Outputs

Certain problems may arise when plotting to the printer (PrintGraphics under Files
in the Menu Bar). For example, sometimes (at random) instead of giving you a
dialog box it, in effect, returns Cancel and nothing gets plotted. Empirically this
appears to happen more frequently in certain specific situations, e.g., trying to
print select link flows.

We have put in an empirical fix so that once you have been through the printer
dialog box once if, subsequently, an erroneous return of Cancel occurs the
program goes ahead and plots using the same plotter parameters as previously
set. So, e.g., you cannot select a different plotter without the dialog box.

The only problem is that you may get the Cancel return the first time you ask for a
plot, in which case there is nothing to go back to. The solution is to do at least
one plot to your desired device as early as possible to make sure that the device
is correctly recorded. If it returns Cancel keep trying until you do get a dialog box.
You might need to exit the program and re-run it but as far as I know nobody has
had to go that far yet.

With an A0 output device this may mean producing one large plot that you don't
need. One way around this (untried as far as I know) is to send the output to a
file, rather than the A0 device directly, and only spool those print files that you
really need. But quite how you spool printer (.prn?) files later on I have no
experience with.

11.4 P1X External File Control

The choice and control of external files within P1X is largely handled within the
“files sub-menu” 1 which in turn is sub-divided into inputs and outputs.

1 Certain options may either read or create external files on an “open-and-close” basis; the files
referred to here generally exist throughout the program.

5101396/ May 11 11-10

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

P1X: Interactive Analysis of Results

Under 32-bit the “top” files menu also allows one to set the “default” definition of
bitmap files - pcx, bmp or the clipboard; see 11.3.6.

11.4.1 Input Files

Input files include at least one network .ufs(/ufa/ufn/etc) file (“network 1”) which
determines the basic display plus, optionally, up to three further network files.
Typically the latter files could represent alternative scenarios of the same basic
road network and therefore they may differ either topologically (i.e. more or fewer
links) or by attribute (i.e. different flows).

Of these only “network 2” can be directly used in the actual network plot; for
example you may ask for the plot to be a “union” of networks 1 and 2, in which
case any extra links in network 2 which do not appear in network 1 appear on the
plots as links with a different colour; see also 11.6.4.

However data from all 3 (as defined) alternative networks may be accessed using
the SATDB-based sub-options within P1X and their attributes viewed “indirectly”
by the P1X graphical and annotation displays. See 11.6.2.3.

Further (optional) input files include:

a) Two matrix files associated with the network(s) plus a further matrix file
which is the trip matrix used in the network assignment. Initially, by default,
matrix 1 is also the trip matrix, but it is perfectly possible to have up to three
separate matrices defined within a single run.

b) The original .dat file from which network 1 was created in SATNET is also
read in (if possible) and copied into an internal direct access file for editing
purposes; see 11.9.2.

c) A “.xy” file containing updated co-ordinates. (Node co-ordinates are

generally obtained from the input network 1 file but they may also be over-
written by inputting a .xy file. See 11.9.7. Thus it may be much simpler for
users to work with “temporary” .xy files with updated co-ordinates than to
have to continually revise the original .dat files and to re-run a complete
SATURN procedure before re-entering P1X.)

d) A GIS file (see 11.6.10).

e) A bitmap or pcx file which may be used as a background to the network plot
(see 11.3.6).

f) A “.wxy” file which contains old plot window definitions; see 11.5.2.

11.4.2 Output Files

The following files (in addition to plot files) may all be output from P1X via the files
menu (or elsewhere):

5101396/ May 11 11-11

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

P1X: Interactive Analysis of Results

1) An updated network .ufs file; see 11.9.2

2) An updated network .dat file; see 11.9.2

3) An updated preference file (P1X0.DAT; see 11.4.3)

4) A file of (updated) X,Y co-ordinates (11.9.7);

5) A “re-created” version of the original network .dat file obtained from the data
contained in the input .uf* file.

6) A text (ASCII) file containing, one record per real node (i.e., excluding zones),
the node “name” and its internal sequential map number.

Option 5) is basically useful when the original .dat file has been “lost”. It is
possible to prevent this option being available, for example if you are intending to
“lend” a .uf* file to a colleague but don’t want them to have the .dat file
information, by setting the network input parameter SECRET (6.3.1) to .FALSE.

Clearly if the original .dat file is available to the user/P1X then the value of
SECRET is immaterial. For example, setting SECRET = T will not prevent a user
dumping a .dat file as part of the Network Editing options but this option is only
available if P1X has access to the original .dat file in the first place.

Option 5) should be used with great care since it is difficult to re-create the exact
form of the .dat file used in the original input to SATNET just working from .ufs file.
For example, it is never very clear whether a variable which is equal to the default
value has been explicitly defined in the correct location in the .dat file or whether it
was left blank/zero and the default value substituted. Equally any comment
records and insertions in the original file are lost using this option.

The difference between options 2) and 5) is that option essentially copies an input
.dat file – and includes any editing changes – whereas option 5) effectively starts
with a blank sheet of paper.

Option 6) is most useful when there are two input network files and the map
displayed is a “union” of the two networks such that the output file contains a
reference to all nodes which occur in either file (11.4.1). In turn this may be used
as an input to SATCOBA (15.42.6) where it is desired to create a COBA file which
contains a common node numbering system for two networks.

In addition various forms of ASCII sub-files, .ufm matrix files etc. may be output
during the course of various sub-options within the program.

11.4.3 P1X Preferences file: P1X0.DAT

P1X requires a “preferences” or an “initialisation” control file P1X0.DAT in order to

set default values for various parameters which control for example, the size of
arrows in node graphics.

5101396/ May 11 11-12

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

P1X: Interactive Analysis of Results

The general principles are described in 15.2. Thus if you wish to permanently
change arrow dimensions you must use the appropriate menus to change the
values within that particular program run; then, at some later stage of the same
run, output an updated version of the preferences file such that the new parameter
values become the defaults.

Note that some care is needed with file management here in that a new output
preferences file is, by default, stored in your current sub-directory whereas the
default file read on input may be stored in another specific sub-directory. You
must therefore either explicitly create the new file in that sub-directory or else copy
your output file into it after the program run.

The preferences file P1X0.DAT is rather long and what the parameter “names”
represent is not always obvious. Version 10.5 has added short explanations as
“comments” on the right-hand side of each definition record but the list is still only
partial. All queries to DVV.

11.4.4 P1X Resume File: LAST_P1X0.DAT

In addition to the main preferences file P1X0.dat each run of P1X automatically
produces a “quasi” preferences files last_p1x0.dat which contains a full list of the
current parameter choices, including the full set of windows co-ordinates, at the
conclusion of that run. By choosing the option “Resume Last” at the start of the
subsequent run of P1X the conditions at the end of the previous run are
reproduced exactly, including the final window.

Equivalently the “resume last” option may also be invoked by including the key
word “RESUME” on the command line.

Note that the resume file also contains all the saved windows from the previous
run, including any which have been saved in a .WXY file.

11.5 The Network Window

11.5.1 The Main Window

P1X plots a rectangular area or “window” of the network, the precise definition of
which may be determined in several different ways, e.g.:

1) The entire network is plotted.

2) A “central” node plus radius.

3) The “corners” are set by direct manipulation, e.g. by moving the window or by
defining them with the mouse.

Once set up the “window” may be moved or re-defined using a range of options
described next.

5101396/ May 11 11-13

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

P1X: Interactive Analysis of Results

At the simplest level the window may be shifted UP, DOWN, LEFT and RIGHT by
standard amounts or expanded/reduced (PAN/ZOOM) by key commands (Note
that “Pan” is used as the opposite of “Zoom”.)

A new form of shifting the window, denoted by MOVE, has been introduced in
10.8. MOVE allows the window to be shifted in any direction and by a variable
degree. The direction of shift is determined by the position of the mouse relative to
the centre of the plot and the amount of overlap by its distance from the centre. By
contrast, LEFT, RIGHT, etc. can move in four directions only by fixed amounts.

The “BOX” option allows the user to set a sub-window within the current window
by first clicking on a corner with the mouse and then clicking on the opposite
corner. The new boundaries are displayed as “rubber bands”. Selecting outside
the current window is not permitted.

“DRAGing” is accomplished by first selecting a node on the current plot (point and
click) and then clicking on a new point within the current window for that node to
be moved to. This is particularly useful when a bitmap background map is being
used and you wish to correctly locate the plotted map on the background.

In a similar way the “SCALE” option allows two nodes to be located at their
desired position, in which case the plot is not only shifted but scaled up or down
as well.

In all cases the (user) co-ordinates of the four corners of the plotted window are
held in variables Xmin, Xmax, Ymin and Ymax where X refers to the horizontal
and Y to the vertical. For more precise positioning these variables may be set
explicitly (useful for selecting the same area as in a different run, although see
11.5.2 below for an alternative method).

In general the window is contained within an outer rectangle with the banner to the
right or top as requested. However in the case of, say, a long narrow window this

5101396/ May 11 11-14

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

P1X: Interactive Analysis of Results

will not use the full screen so an option exists such that the rectangle plus banner
use the full width/height of the screen and the network plot is centered within the
available space. This is selected by “toggling” between “full screen” and “part
screen”.

Alternatively if the network plot does not occupy the “full” window “fill screen”
extends the X, Y boundaries to fill the space available.

11.5.2 Recording Windows and .wxy Files

Once defined up to 10 window definitions in terms of Xmin etc. may be “saved”

internally within the current run of P1X so that the user may return to them at a
later stage. Choices on offer include the original window, the immediately
previous window or any other saved window.

Each “saved” window may also have a text “name” added (up to 32 characters) to
help in identifying that window at later stages.

In addition the current set of “saved” windows (co-ordinates plus text) may be
permanently saved by “dumping” them to an external ASCII file whose standard
file extension is wxy. Wxy files may also be input to other runs of P1X (11.4.1)
such that a useful window created in one run can be repeatedly accessed in the
future.

11.5.3 Returning to Previous Windows

As an alternative to explicitly remembering selected windows P1X automatically

records the previous 10 windows so that the option “lasT window” will return you
to the previously defined window. However any windows beyond 10 are not
saved, hence the potential need to “save” them as per 11.5.2.

11.5.4 The Auxiliary Network Plot

In addition to the main “window” plotted an “auxiliary” network plot may also be
displayed by clicking “Aux.Net.Graph” under Show in the menu bar. The auxiliary
network plots either the entire network or an area with the current main window at
its centre (depending on which one is smaller) at a reduced scale in the lower right
hand corner and with only links displayed as straight lines; i.e., no annotation,
node information etc.

The useful bit however is that the current main window is illustrated as a red
rectangle within the plot, thus showing you where the current window is located
within the full network. See below.

5101396/ May 11 11-15

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

P1X: Interactive Analysis of Results

If the window is changed in any way then the “new” auxiliary plot will appear
automatically. However if any other operation is requested the auxiliary plot is
minimised.

The auxiliary network plot also functions within node graphics (11.12), in which
case the currently selected node is marked as the centre of a red rectangle within
a larger section of the network.

11.5.5 Navigation Options in the Menu Bar and On-screen

The basic “shift the window” operations may be requested not only via selections
from the standard banners on the right-hand side of the plot but also via a series
of “navigation” options included within the Menu Bar at the top of the screen. Thus
clicking on Nav-R shifts the window to the right, Nav-D shifts it down, etc. etc.

Alternatively by clicking on the small green arrows in the middle of each face the
window may be shifted up, down, etc. Equally small arrows in the corners allow
shifting at 45 degrees and 2 small red circles with +/- signs zoom in/out.

Users should find these facilities simpler and more intuitive than operating through
the banner or via the pull-down options under Window simply because the mouse
does not move after the click-request so that if, for example, you wish to
continually zoom in more than once it is simply a question of locating the mouse
over Nav-Z and clicking repeatedly to zoom in continuously.

5101396/ May 11 11-16

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

P1X: Interactive Analysis of Results

Note that it is normally quite helpful to turn on the auxiliary network plot (see
11.5.4) whilst re-defining the window as this gives an instant indication as to
where the current window is in relation to the full network.

11.6 Basic Network Display

A “basic” (see below) network plot requires (up to) ten sets of information to be
specified.

a) Data which restricts the links which are to be displayed, the “select links”
procedure

b) The choice of link based data to be annotated

c) Parameters to control the annotation of link data

d) Link-specific display parameters

e) Parameters to control the display of nodes (including “highlighting”; see

11.6.5.4);

f) Parameters to control the annotation of turn-based data;

g) Parameters to control the display of matrix data;

h) General display parameters.

i) Parameters to control the contents and format of the “banner”

j) GIS background information.

k) Bitmap background options.

These are described within the following sub-sections 11.6.1 through 11.6.11.

By “basic” above we refer to the network display which always appears, although
with some options extra information will be added. For example information
relating, e.g., to trees or select link flows will be superimposed on to the basic
network plot but disappears once that option is completed.

11.6.1 Link Selection

11.6.1.1 Selection by (Numerical) Attribute

The Select facility allows the user to restrict the links to be displayed by specifying
conditions which must be satisfied. For example one might wish to plot only those
links where the flow (in either direction) exceeds, say, 500 pcu/hr. This could be

5101396/ May 11 11-17

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

P1X: Interactive Analysis of Results

done by, firstly, selecting the variable FLOW from the menu, next specifying the
condition as ‘GT’ and finally specifying the critical value as 500. In this case links
where the flow (in both directions) was less than 500 would not appear at all and
the selected links would appear as per normal

Alternatively one may “highlight” selected links, e.g., by drawing them as thicker or
wavy lines, in which case the other links remain as part of the map. The
conditions which the highlighted lines must satisfy are specified as above.

It is also possible to select links that satisfy more than one condition by specifying
further conditions. These may be either in the form of “AND” conditions, e.g.,

FLOW GT 500 AND SPEED LT 30

so that the plotted links would need to satisfy BOTH conditions, or “OR”
conditions; e.g.,

FLOW GT 500 OR SPEED LT 30

in which case any link satisfying either of the above conditions would be
“included”.

In addition to GT and LT tests further numerical conditions include “EQ” and “NE”,
in which case an additional “plus-minus” parameter needs to be specified. Thus
12.05 is not, strictly, equal to 12 in the sense of 12. 0000 but it is equal to 12 in the
sense of 12 + 0.5. By default equality or non-equality is based on rounding off
both quantities to the nearest integer, i.e. + 0.5, but tighter (or even looser) limits
may be specified.

Tests such as GT or LT also require numerical values such as 500 or 30 in the

above examples. However it is also possible to specify a test as “GT 0” directly
without specifying both GT and 0.

Ranges may also be selected, for example, all speeds in the range 20.0 to 40.0.

Less obvious conditions are the “Top Ten” and “Bottom Ten” whereby those links
which have the 10 maximum or 10 minimum values in some sense are selected.
For example, you may select the 10 worst converged links (as also printed by
SATALL, see (1) in 9.9.1.2) using the GEH convergence as the link attribute and
Top Ten as the criteria.

The link attribute used in the tests may also be specified as either its actual or its
absolute value.

11.6.1.2 Alternative Selection criteria

Other criteria may also be used to select links (sometimes temporarily via various
other sub-menus). Thus the user may select links which are part of nominated
bus routes or on the minimum cost path from an origin to a destination (a “tree”).

5101396/ May 11 11-18

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

P1X: Interactive Analysis of Results

If two networks are being examined a “MATCH” option can, say, select links which
exist in network 1 but not in network 2, in other words to highlight where changes
in the network structure have been carried out. Again all these types of requests
may be added as additional AND/OR conditions.

Finally, a new addition in 10.3, the links to be selected may be nominated by

pointing and clicking on them with the mouse. A link thus identified is either
selected in both directions (if two way) or only in the direction implied by the
mouse position depending on whether the option is entered with either the 2-way
or 1-way toggle selected.

11.6.1.3 Selection in P1X and SATDB

Note that the system used to record selected links for display purposes in P1X is
synonymous with the system used within SATDB; see 11.10.2. Thus any
selection made within SATDB will affect what is seen on the P1X graphical
displays and vice-versa.

11.6.1.4 “Selection” by Capacity Index

It is also possible, post 10.3, to select those links (where “links” here includes both
real links and centroid connectors) to be plotted by virtue of their capacity index.
For example, you may permanently exclude all links with capacity index 0.
Selection of indices is done via a window whereby each index used may be
toggled “on” or “off” via a radio button.

Note that this is not “selection” in the full sense described in 11.6.1.3 in that it
applies only to which links appear in the plot, not those links which are
selected/not selected for SATDB operations (11.10.2). Equally any form of
“highlighting” does not apply. In this sense the selection is much more similar to
the “link inclusion” options as described in note 6 of 11.6.4 and indeed menu
access to this option is available both under Link Selection and Link Display.
However I suspect most users would be inclined to look for an explanation within
this section of the Manual

By default all capacity indices are “on” although it is possible to set the default to
“off” by setting a negative width for the capacity index within the preferences file
P1X0.DAT; see note 4 in 11.6.4.

11.6.2 Annotated Link Data

11.6.2.1 Choice of Annotated Link Data

Each (directional) link may have one or more data values (e.g. speed, flow)
associated with it and these data values may then be displayed (“annotated”) in
the network plots in a variety of formats. The annotated data may be generated in
a number of different ways.

5101396/ May 11 11-19

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

P1X: Interactive Analysis of Results

Data may be chosen either from: (a) a list of “names”, e.g., “DISTANCE”,
“ACTUAL FLOW”, etc.; (b) more generally via a Dirck Access array number (see
15.21 or App. J) or (c) from data columns previously created and stored within the
data base.

The list of “names” is divided into (up to) 5 sub-lists corresponding to:

♦ General properties such as link distance, number of lanes etc.;

♦ Flows;

♦ Time and/or speed-based variables;

♦ Bus data (including bus flows);

♦ Emission data.

The precise contents of each depend on the input network so that, for example,
“LANES” would not apply to a buffer-only network.

There is also a choice of a “full” list including all items under (a) to (e) above but,
generally speaking, the full list is long and unwieldy.

A full list of all possible data items in the standard lists is given in Appendix I.1with
an explanation of what each contains plus, where applicable, their equivalent DA
code.

In general and where appropriate the flows listed explicitly differentiate between
actual and demand flows but in the case of five “sub-flows” - bus flows, pre-loaded
flows, passq flows, (total) fixed flows and entry flows from centroids - there is an
explicit 3-way choice under Options to request either demand, actual or queued
upstream flows to be created.

Equally annotated link data may be generated via, for example, Select Link
Analysis (11.8.1), tree building (11.8.3), etc. etc. Bus routes are annotated by
writing the number of the route along the constituent links.

A further form of link annotation - which must be “text” - is that of link “names” as
available under GIS displays. See 11.6.10.

11.6.2.2 Handling Annotated Link Data

Once created, link data is either displayed directly (effectively once and only once)
- the “pick‘n’plot” mode - or displayed and stored in the permanent data base (in
which case, see below, they are displayed on every subsequent plot until
cancelled).

5101396/ May 11 11-20

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

P1X: Interactive Analysis of Results

We note that P1X and SATDB share a common internal data base (see Section
11.10.1) such that data selected for display under non Pick’n’Plot is added to the
data base exactly as though it had been generated within SATDB. Conversely this
means that the analysis options from SATDB may therefore be accessed from
within P1X, e.g., the ability to create new data columns via FORTRAN equations
or to look at the data numerically on the screen.

Note that “link data” selected by P1X does not only refer to data to be annotated
on links by P1X since a number of the items also apply to simulation turns, e.g.,
link flows, in which case if the data is stored as a data base column the turn data
is also there to be viewed and/or manipulated via SATDB.

By default all data items in the permanent data base (independently of how they
were created) are displayed in all network plots although under the
“housekeeping” options plotting may be suppressed.

More than one variable may be annotated at once, although with numerical
display the program checks whether or not enough space is available and
suppresses any figures that would “over-run” the link. However before
suppressing any numbers the program first tries to “compress” the annotation by
writing smaller numbers; the system parameter SHRINK (set under the “current
device parameters” sub-menu within the system/device menu; 11.3.4) sets a limit
to the compression, so that if SHRINK = 0.7 the smallest permitted characters are
70% of the normal size.

11.6.2.3 Annotating Multiple Networks

If a second network file “NET2” is defined it is possible to create and annotate

data from either NET1 or NET2 separately, both together, their differences or their
ratios. This is very useful, for example, to illustrate the differences in link flows
between two networks.

Nine options are provided:

1) Annotate data from NET1,

2) Annotate data from NET2,

3) Annotate the differences (defined as NET2 minus NET1),

4) Annotate data from both networks together (or, if there are more than 2 input
network files, data from all networks),

5) Annotate the relative differences as a percentage - defined as (NET2 minus

NET1)/NET1,

6) The ratio NET2/NET1 expressed as a per cent,

7) The absolute difference between NET2 and NET1,

5101396/ May 11 11-21

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

P1X: Interactive Analysis of Results

8) The GEH statistic for the difference between Net1 and NET2 expressed as
an absolute value,

9) The GEH statistic as 8) but with a + or – sign.

It is not essential that the files on NET1 and NET2 have identical network
structures. NET1 defines fully the link/node structure plotted, but where a link in
NET1 also appears in NET2 data from both (or either) files may be displayed. A
match is also possible between ‘buffer’ links in one network and the equivalent
‘simulation’ link in the other.

On the other hand links in NET2 which are not “matched” by a link in NET1 cannot
be annotated on a network plot.

Note that the “sense” of the operation implied by options 3, 5 and 6 above can be
reversed; i.e., you may also choose to plot NET1 - NET2. In addition, using the
SATDB-style data manipulation options you may create any other “difference
statistics” you wish and involve link data from networks 3 and 4 as well.

Figure 11.1 - Bandwidth Plot of Flow Differences (Option 3 above)

11.6.2.4 Unmatched Links in Multiple Networks

If a (directional) link occurs within the first network defined in P1X but not in the
second (/third/fourth) then the “difference” statistics 3, 5 and 6 defined above are
not, strictly speaking, well defined. However it is possible (post 10.5) to define a
“default” value for the missing entries, the most obvious value being zero. Thus, if

5101396/ May 11 11-22

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

P1X: Interactive Analysis of Results

you are plotting the differences in flows between a “do-something” and “do-
nothing” networks, then it is logical to assume that the flow on a newly created link
is 100% growth (i.e., the previous flow was zero). On the other hand it is difficult to
compare the speed on a new link to an obvious reference point.

11.6.2.5 Annotating Multiple User and/or Vehicle Classes

In a network with more than one user class up to the first three user class flows
are explicitly listed. Alternatively there are options available under “Options” to
either take data for a single “nominated” user class or for all user classes, in
which case a set of NOMADS data (up to a maximum of 4) is created. Changing
the option changes the text messages that appear in the lists.

Thus, in order to display data for user class 4 or beyond, set that user class as the
nominated class.

The same principles apply, post 10.9, to annotating flows by vehicle classes (i.e.,
summations of user class flows).

11.6.3 Link Annotation Display Options

These options control how link data, once selected, “appears” in the plots.

Note that these options apply to all annotated link data, i.e., not just link data as
selected via the “Choice of Annotated Link Data”, 11.6.2.1, but also other options
for creating link data such as Select Link Analysis, Trees, etc. etc.

11.6.3.1 Display Modes

Link annotation can either be via:

♦ numerical values - the default - printed along the line;

♦ numerical values entered horizontally in a “box” attached to the middle of the

(directional) link, or

♦ “geometrical” shapes which represent in some sense the values of the

variable(s).

In all cases the data appears on the “correct” side of the link in the sense of “drive
on the left” (or on the right if LEFTDR = F).

11.6.3.2 Geometrical Display Modes

Four geometrical options are available:

5101396/ May 11 11-23

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

P1X: Interactive Analysis of Results

1) “Bandwidth blocks” with the full link as a base and the width proportional to
the value;

2) Bands of fixed width along the full link but with a variable degree of
“intensity” (see 11.6.3.8);

3) Blocks of fixed width whose (absolute) length along the link is proportional to
the annotated value.

4) Blocks of fixed width whose (relative) length along the link is proportional to
the annotated value.

All geometric options can display more than one set of data entries at a time and
use different colours for each (see 11.6.3.4 below). In addition positive and
negative numbers are plotted as different colours. This is very useful when, for
example, displaying the differences in flows, etc., between two different networks.

Each option has a corresponding proportionality parameter which may be

changed whether or not that option is currently invoked; for example, under (1)
above a parameter value of 100 units/mm would imply that a link whose data
value was 376 would have a band of width 3.76 mm displayed.

The different geometric options are useful in different circumstances. Thus

options (1) and (2) are useful to display characteristics such as flows or speeds
which have a constant “intensity” anywhere along the link, but less useful for
displaying travel times since the long links would automatically tend to be most
prominent. Generally the bandwidths “look better” than the variable intensities.

5101396/ May 11 11-24

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

P1X: Interactive Analysis of Results

Option (4) is best used to represent queues, in particular with the variable “Q/S”
(average total queue length divided by the stack) and the proportionality constant
set to 100.0. Thus if the queue takes up the full stacking capacity of the link, so
that Q/S = 100%, the solid block will extend the full length of the plotted link; if Q/S
= 50% the block extends 50% of the link length, etc. Thus a link with, say, an
average queue of 20 vehicles and a single lane would have a longer block than a
link with 20 vehicles spread over 4 lanes.

Equally option (3) can also be used to display queues but in this case it should be
an absolute queue that is plotted, e.g. QUEND or QBAR, not a relative queue. It
can also be usefully used to display delays.

Values for the proportionality constants in all cases should be chosen with regard
to the probable absolute values to be displayed; thus if the values are large, so
should be the constants, in order to keep the lengths/widths to a reasonable size.

11.6.3.3 Numerical Selection

Numerical selection rules allow the user to display only values within a certain
range. For example you may wish to suppress the printing of very low data values,
in which case a “lowest value” is set and the “maximum value” is either set to a
very large value or, more easily, left “unset”. If the data consists of both positive
and negative values (e.g., differences in flows) the test can be based on absolute
values rather than actual. Selection applies to both numerical and geometrical
displays.

Similarly the numerical values displayed may be “rounded off”, e.g., to the nearest
units of 10’s or 100’s etc.

11.6.3.4 Colour and/or Range Definitions

The colours (or pens) which are used to display geometrical link data (but not
numerical link annotation) may be set in a number of different ways:

♦ At the simplest level all annotation uses a single colour.

♦ Alternatively, if more than one item of link data is being displayed, each item
may have a different colour.

♦ Different colours may denote positive and negative entries per data item.

♦ The colours may depend on “range bands” such that, e.g., all data values in
the range 0 to 100 are plotted in red, 100 to 200 in blue, etc. etc. with different
pen colours/ranges for different data sets (see 11.6.3.6).

♦ Alternatively the colours of each individual data item may be defined by the
range bands of another single “master” data item (see 11.6.3.7).

5101396/ May 11 11-25

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

P1X: Interactive Analysis of Results

The most basic choice is between basic pen definitions which depend only on
data item plus positive/negative and those which are range-based. The default is
the former with pen choices which differ by both data item and by
positive/negative, although these may be changed by the user to be based more
on single uniform colours.

Colour choices in P1X are made by entering “Pen and/or range defs” under Link
Annotation Display Options where the following basic options are presented:

• Basic positive/negative pen definitions per data item (11.6.3.5);

• The choice of range bands or single colours per data item (11.6.3.6);

• The precise definition of pen colours and range bands

• The definition of range bands only

• The choice of a “master” data item to define colour bands for all data
(11.6.3.7).

11.6.3.5 Single (Uniform) Colours per Data Item

By default each data item is assigned a single colour for positive values and a
different colour for negatives. Thus data item one is represented by pen 1 (blue)
for positive values and pen 2 (green) for negative values; data item two uses pens
3 and 4 (cyan and red), etc. etc. These definitions may be changed interactively
within the program.

11.6.3.6 Defining Colour-based Ranges

Range definitions used to define the colour of annotation (principally bandwidth

annotation) may be further subdivided into:

a) uniform bands, and

b) explicitly defined bands

Thus under (a) the user defines a minimum starting value (generally zero) and an
increment. If they are, say, -50 and 100 respectively then this would set the first
band (i.e. first colour) to be all data values up to and including -50, the second
band would be from -50 to +50, the third from 50 to 150, etc. etc.

Under (b) the user may explicitly define each of the “break” points which may not
follow equal increments; e.g. 0-100 could be one colour, 100 to 500 another, 500
to 5000 a third, etc. etc.

In either case each band is associated with a colour/pen which is user set (or
taken from defaults – see 11.6.3.9), the maximum number of bands is 10 and the

5101396/ May 11 11-26

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

P1X: Interactive Analysis of Results

bands are “open ended” in that all possible values less than the first value are
included in band 1 (i.e. minus infinity up to that value) and all values greater than
the final value are included in the last band. (Which implies in fact that the 10th
break point is irrelevant since all values above the 9th must lie in the final band.)

To set range definitions select “Range bands or uni-colours by data set:” from the
“pen and/or range options” menu. Thus, for each data item displayed there is a
basic choice between display by a single colour (or 2 colours for +/-) or display by
multiple colours set by bands; if the latter there are further choices between
“uniform bands” or “explicitly set bands”, options a) and b) above, and all the
necessary parameters may be input interactively.

Once set the current colours and/or range limits may be displayed along with the
plot via the A-Z banner (11.6.9).

Note that they may be preserved for future applications by storing them on a new
preferences file – see 11.6.3.9.

11.6.3.7 Defining (Transferring) Colours from Another Data Column

It is also possible to “transfer” colours by range from one item of data to another.
For example, you might wish to display the flow (data set 1) as multiple-colour
bandwidths but using colours determined by ranges of the V/C ratio (data set 2).
To do this, nominate data set 2 (V/C) as the “master” set and define the
appropriate range bands for that set: both data items will then have the same
colour on each link. (The presentation may well be improved if the master item,
i.e., the V/C ratios in the above example, is not displayed so that you have flows
only plotted in colours determined by their V/C ratios.)

Selecting bandwidth colours by using speed as the controlling variable is another

very common example; i.e, link data is displayed as bandwidths with different
colours for different speed bands. A further application using speed is described
next.

11.6.3.8 Fixed Width, Variable Colour Link Bars

It is sometimes very useful to be able to indicate links whose, e.g., speeds are
within a certain range by a set of colours. This can be done by combining the
“variable intensity” display option - (2) under 11.6.3.2 - with the colour/range
definitions in 11.6.3.6.

Thus, under variable intensities, if the proportionality constant is set to zero, all
link data will be displayed at maximum intensities and therefore appear as solid
rectangles of fixed width. This, therefore, provides very little useful information
UNLESS the colours of the rectangles are variable (see 11.6.3.6), in which case
different ranges of link data properties will appear as different colour bars.

5101396/ May 11 11-27

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

P1X: Interactive Analysis of Results

11.6.3.9 Storing Range/Colour Details on the Preferences File

It is sometimes useful, having set up a complicated system of range bands and

colours, to be able to store that data for later use, e.g., on a different network. This
may be done by creating a new preferences file since the final (optional) data
segment on a preferences file, headed by a record beginning “PEN-RANGES”
stores all the necessary data, both universal parameters and parameters
applicable to individual data sets.

Documentation on the structure of these records is given by “comment cards” at

the head of the data segment.

11.6.3.10 Averaged and/or Summed Link Data

The basic link data to be annotated is always stored in a “directional” sense, i.e.,
the data for link (A,B) is distinct from that (B,A) on two-way links. However it is
possible to display link data as either the average or the sum of both directions
(where for one-way links both average and sum are interpreted as the value for
the existing direction).

In the case of bandwidth notation averaged data appears (equally) on both sides
of two-way links and on the “correct” side of one-way links. For summed data the
bandwidths always “straddle” the link whether it is one-way or two-way.

For all other display modes, i.e., numerical presentation and geometrical options
(2) to (4) under 11.6.3.2, averaged data appears as per bandwidths but summed
data on 2-way links appears on one side of the link only (where the choice of side
is decided by link numbers).

11.6.4 Link Display Options

By default a link is represented as a straight line joining its A-node and B-node
(generally) in black on a white background. However several variations are
possible:

1) The default pen colour may be altered to any other standard pen colour.

2) The links may be plotted either as lines or as in-filled “blocks” of a finite

width.

3) Similarly the width and/or colour of a link may optionally be determined by its
link capacity index; e.g., motorway links may appear as solid blue lines, etc.
Default widths/colours may be entered in the default parameter file
P1X0.DAT or edited interactively using a screen edit window.

4) Negative link widths by capacity index may also be used to remove certain
links from the plot; i.e., any link whose capacity index has a negative width is
never plotted, independent of whether or not the option to set by capacity
index is invoked.

5101396/ May 11 11-28

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

P1X: Interactive Analysis of Results

The effect is equivalent to using the capacity index to de-select links

(11.6.1.4) for display. One advantage of this method is that it can be made
semi-permanent by using the parameter file P1X0.DAT to set default
negative widths.

5) “Selected” links (11.6.1) may be highlighted, e.g. by the use of “zig-zag”

lines or by solid in-filled bands whose width and colour are user-set.

6) Links may be drawn as “curves” as opposed to straight lines using data

contained in the GIS file such that links are drawn as “polylines”, i.e., straight
line segments linking a series of intermediate points between the A-node
and B-node. If these points are sufficiently frequent the line approaches a
smooth curve. Polylines are selected by a sub-option within either the
General Display Menu or the GIS menu. See section 5.7.2 for instructions
as to how to create polyline data.

7) Centroid connectors may be excluded from plots (or, less usefully, only
centroid connectors may be plotted); by default both “real” links and centroid
connectors are included. Equally links and/or centroid connectors may be
excluded from the plots by virtue of their capacity indices; see also 11.6.1.3.

8) Links in the simulation network may be drawn - as an alternative to options 2

and 3 above - with the number of lanes in each direction explicitly marked
and with bus lanes marked in red. This is indicated by “Kerbs marked” in the
banner. (If the lanes appear too large or too small by a factor of 10 it
probably means that the parameter XYUNIT has been incorrectly defined.)
It is logical to combine this form of link representation with the representation
of simulation nodes by lane-based diagrams; see 11.6.5.1 (4) below.

Note that, if lane display is “on” the width of the lane, which defaults to
3.75 metres “on the ground”, may be re-set to provide more or less
“width” as required

9) One-way links are (by default) indicated by arrows at the mid point in the
appropriate direction; the length of the “barb” may be adjusted or, in the limit,
set to zero in order to suppress the arrows totally.

11.6.5 Node-Based Annotation

11.6.5.1 General Node Display Options

Information relating to nodes or junctions may be included within network plots via
one of five “main modes” which display a variety of numerical and/or geometric
information:

1) Single numbers representing node properties such as the node number, V/C
ratio, etc. and/or shapes representing junction types;

2) “Bandwidth” circles with radii proportional to node data.

5101396/ May 11 11-29

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

P1X: Interactive Analysis of Results

3) Boxed data”, i.e. one or more data values contained inside a box.

4) “Tubies” representing turning data (but only if turn data has been selected,
see 11.6.6).

5) Diagrams representing lanes and lane markings.

N.B. All the above are annotated “at the point”, i.e., centered at the intersection.

In addition node numbers may be written “offset” from the actual intersection point
and node “names” from the GIS file (11.6.10) may be annotated above the node
position.

NODE SHAPES

Under option (1) above (ONLY!) different junction types are represented by
geometric shapes and/or colours. Thus simulated roundabouts are represented by
circles, traffic signals by squares, priority junctions by rectangles, external nodes
by pentagons while dummy nodes are either (post 10.8) given by a number only
or by a star. In the buffer network all “real” nodes are represented by a hexagon.
Zones, whether in the simulation or buffer networks, are represented by triangles.

In addition each shape can have its own unique colour and be either “solid” (i.e.,
in-filled) or “open”. If, however, numerical node data is included then the shape
must be open in order to accommodate that data; see below.

Various options are provided to: (a) suppress node shapes altogether; (b), to use
a single pen colour for all node types and/or to distinguish different node types by
different colours; (c) to distinguish zone sectors by distinct colours; and (d) to
factor the size of the shapes up or down by a user-set factor (default 1.0).

NUMERICAL NODE DATA

Under option (1) above numerical values are written inside the shapes (if they
exist). The most obvious node property to annotate is its number; however it is
also possible to substitute a wide range of node “input properties” such as the
offset or cycle time at signalised nodes as well as a wider range of “output” node
data, e.g. V/C ratios, and total through flow. These may be selected from a
standard list (with certain elements available for simulation nodes only) or
extracted from the node data base (11.10.5) where you may have previously
created your own node data sets. See Appendix I.3 for a full list of available node
data.

The same numerical data may also be represented by in-filled circles, option (2),
whose radius is proportional to the value of the particular node’s data with a
proportionality constant set by the user. Bandwidth displays require a
“proportionality” factor to be defined to convert the value “at the node” into a
radius. For example, if you are displaying %V/C you may wish to define a 1 mm

5101396/ May 11 11-30

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

P1X: Interactive Analysis of Results

radius to equal a %V/C value of 10. In addition the colour used in the circle may
be determined by the value being annotated (see 11.6.5.2 below).

Bandwidths may be either “background” or “foreground” depending on whether or

not the lines representing the links are plotted over the node shapes or, in effect,
underneath.

An example is shown below with a single colour used.

“BOXED” NODE DATA

Option (3), data in boxes, can, unlike the other four options, display more than one
set of node data at a time BUT the data to be displayed must first be set up with
the SATDB node data base; see 11.10.1.

GEOMETRIC NODE DISPLAYS

Options (4) and (5) are based on the detailed node graphics routines described in
11.12.2, but here are plotted (at a much smaller scale) for each simulation junction
(only) in the plot. Unlike options (1) to (3) neither (4) nor (5) display node data
values.

Option (4) annotates a selected turn variable, e.g., turning flows or delays, as
“tubies” or curved bandwidths of proportional width. To a large extent this option
duplicates the turn-based options described in the following section and relies on
data selected there. The main difference is that here the data is displayed “within”
the node; under 11.6.6 it is displayed “along” the entry link.

5101396/ May 11 11-31

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

P1X: Interactive Analysis of Results

Option (5) produces line diagrams for each simulation junction, similar to those
produced for individual junctions but at a much reduced scale as illustrated below.
(If the scale is clearly wrong it probably means that the parameter XYUNIT has
been incorrectly defined.) It is logical to combine this form of node representation
with the representation of simulation links by lane-based diagrams; see 11.6.4 (7)
above.

Note that, if a link entering a node has been described in the GIS data as a
“curved” link (see 5.7.1) then the angle of the exit arm in the node drawing reflects
the initial angle of the curved link, rather than the direct “crow-fly” direction to the
adjacent node.

11.6.5.2 Node Bandwidth Colours

The colours used to depict node data via bandwidths may be determined by a
variety of rules. The simplest is to use a single colour (or, strictly speaking, a
single colour for positive values and another for negative). Alternatively, as with
node shapes, a bandwidth colour specific to the junction type may be set.

Alternatively the colour may be determined by the annotated value using range
bands with either fixed and equal increments or with variable ranges set by the
user. Thus, in the former case, if the fixed increment is 100, all nodes with
(absolute) values 0 to 100 will be displayed in pen 1, all with values in the range
100 to 200 in pen 2, etc. etc. In the latter case the user could stipulate that all
values below 50 would be in pen 1, all values between 50 and 90 in pen 2, 90 to
100 in pen 3 etc. etc.

5101396/ May 11 11-32

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

P1X: Interactive Analysis of Results

Note that with the fixed increment option it is the absolute value of the node data
that is used to set the colour; in the case of user-set ranges the sign of the data
value is taken into account and the range values may similarly be either positive
or negative.

11.6.5.3 Node Selection

Node annotation may be “selected” (i.e. to appear or not to appear) in two basic
ways:

♦ whether space permits

♦ whether the node satisfies certain criteria.

Both may be applied simultaneously. Rule ii) may also be applied to turn-based
annotation (11.6.6).

The space rules are based purely on whether or not there is sufficient space
between a node and all of its neighbours and/or boundaries to allow node
annotation without overlap. If not the notation may be “shrunk” to a certain
minimum, below which it is excluded. Selection in this sense therefore depends
very much on the “size” of the output device and may appear differently on the
screen or on the printer. However selection by criteria is device-independent.

The criteria may in turn be specified in several ways:

a) By the type of junction;

b) By numerical tests on the node data to be displayed;

c) By selecting inside/outside a range of node and/or zone numbers;

d) By selecting inside/outside the current plotting window;

e) By selecting with the mouse;

f) By comparing nodes between network 1 and network 2.

g) By reading node numbers from a text (ASCII) file.

h) By selecting those nodes which are retained in a “spider web network” (see
15.56.2)

i) By selecting those simulation nodes which may be treated as “moons” in

terms of the order in which simulation nodes are simulated (see 8.3.5)

5101396/ May 11 11-33

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

P1X: Interactive Analysis of Results

In addition the selections may be built up as a sequence of “AND” or “OR”

conditions; e.g. you may select nodes which are both traffic signals AND have
entry flows of more than 1000.

Thus under a) one might select only signalized simulation nodes, all junctions
excluding zones etc.

Option b) can select, e.g. nodes where the delay is greater than x seconds, etc. In
this case the “property” on which the test is applied may be:

♦ (most commonly) the node data currently annotated (if there is one),

♦ a data field in the node (SATDB) data base, or

♦ a newly selected data item from the standard list of node data.

The numerical criteria on which the test may be based are similar to those used
for link selection by numerical attribute; see 11.6.1.1. Thus not only may they
include “GT 30”, “LT 0” etc. they may also include “Top Ten” so that one might
select the 10 worst converged simulation nodes.

Option c) simply tests on the basis of numbers; e.g., select those nodes whose
numbers are between 100 and 200.

Option d) provides a somewhat crude “select by location” using the definition of

the current plotting window to “cordon off” a set of nodes/zones. A more
sophisticated selection may however also be done using the cordon options
proper within P1X as accessed from the master menu (11.13).

Option e), new with Version 10.2, allows the user to select nodes by point-and-
click with the mouse which may be extremely convenient if a small number of
nodes are to be selected and/or the basis for their selection is otherwise difficult to
specify.

Option f), network comparison, may either work at the rather crude level of
selecting nodes which, e.g., appear in network 1 but not in network 2, etc. It may
also use a more precise system of selecting common nodes by identifying
simulation nodes which are coded differently between the two networks.

Note that the node selection rules in P1X are, post Version 10.2, identical with
those applied within the SATDB node data base (11.10.5) so that selections made
here will affect, e.g., the node data tables as printed by SATDB and vice-versa.

11.6.5.4 Highlighted Nodes

A slightly different form of node annotation consists of “highlighting” certain

selected nodes where the nodes are indicated by a small red circle at the node. In
particular this technique is used to highlight nodes where certain errors have been
detected while building the network in SATNET.

5101396/ May 11 11-34

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

P1X: Interactive Analysis of Results

Thus one may opt to highlight all those nodes where, e.g., one or more Serious
Warnings have occurred – or, in greater detail, one may display only nodes where
one particular Serious Warning occurred. The objective of the exercise is to make
it easier for users to identify where errors have occurred and, hopefully, to correct
them.

Similarly data from .ERL files (see 15.58) may be used to highlight nodes where
certain forms of coding errors have been detected, the difference in this case
being that not necessarily all errors detected by SATNET are displayed, only
those that are suitably identified within the .ERL file as controlled by the user. Full
details are given in 15.58.2.

The highlight options may be entered either by clicking on “Highlight Errors”, “1st
ERL Field” etc. under Display Options in the Menu Bar or on “highlight Errors” etc.
in the banner under Display Options. In either case the user is prompted with a
menu to select, e.g., all Serious Warnings, one particular Serious Warning by
number, etc. etc.

A further highlighting option selects those simulation nodes where there are
differences in the coding between networks 1 and 2, e.g., different signal timings.
This is a useful option to identify where changes have been made to a network,
e.g., by an over-zealous colleague when you are away on holiday! A full listing of
differences may also be obtained within SATLOOK; see 11.11.18.

This option is extremely useful for network debugging in that it enables the user to
quickly identify where in the network particular errors have occurred rather than
trying to identify particular error messages in a .LPN file and locating the
corresponding nodes using P1X.

Note that having identified a sub-set of nodes displaying a particular error it is then
possible to automatically “loop” over those nodes in order to view the source of
the error via node graphics. In addition, the same “loop” may be invoked under
Network Editing in order to be able to correct any coding errors immediately and
to produce a corrected .dat file.

Similarly nodes may also be highlighted (and looped over) within the Convergence
Menu “10 worst” options (11.15) so that, for example, the locations of the nodes
where the 10 biggest discrepancies in delays calculated by the simulation and
assignment sub-models have occurred are highlighted. This is also an extremely
useful tool in quickly identifying potential trouble spots in terms of assignment-
simulation convergence and correcting them. (Note, however, that the source of
the convergence problem may not be as immediately obvious or as easy to
correct as it might be with specific coding errors.)

11.6.6 Turn-Based Annotation

Turn data such as turning flows or delays may be selected from lists and
displayed either as a sub-option of the node-based display (option 2 under 11.6.5
in which case the data appears “within” the node) or alternatively “along” the in-

5101396/ May 11 11-35

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

P1X: Interactive Analysis of Results

bound links to every node. A full list of the data available may be found in
Appendix I.2.

In the latter case, described here, there are two “main” display modes:

a) data such as turning flows; or

b) banned turn indicators

(plus a third choice, the default, of no turn display)

Under a) turn data may be displayed in one of three distinct modes:

(i) As arrows drawn parallel to the link with the arrowhead in the direction of the
exit link and with numerical values at the end of the shaft;

(ii) As “tubies” - in-filled curved bandwidths whose widths are proportional to the
turn data displayed;

(iii) As “boxed data” with the values for each exit turn from a link printed
horizontally within a box attached to the relevant link.

Note that only simulation junctions have turn data associated with them. The data
to be displayed is chosen from a menu. It may also be “selected” based on the
selection rules for nodes (11.6.5.3).

Under b) an arrow with a perpendicular bar at the end is used to indicate all
banned turns.

(N.B. Prior to release 10.7 “Banned turns” in the context used here referred only
to turning movements coded with a zero saturation flow under 11111; they did not
include any turns which have been banned via the 44444 data inputs, primarily
since in the latter case the ban or bans may be user-class specific. However, post
10.7, turns which have at least one user class banned under 44444 are also
included.)

11.6.7 Matrix Display (Spatial)

As mentioned in 11.4.1 P1X may read from one or more matrix .ufm files
associated with the network, most commonly the trip matrix file. These may be
displayed either “spatially”, i.e. making use of the spatial position of the zones, or
as “general matrix graphics”, essentially as in MX. The latter functions are
described in Section 11.14.

11.6.7.1 Row and/or Column Totals

Matrix row and column totals (i.e. origins and destinations in the context of trip
matrices) may be displayed either numerically or as bandwidth rectangles whose

5101396/ May 11 11-36

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

P1X: Interactive Analysis of Results

height is proportional to their value and with their base at the location of the
relevant zone. When both rows and columns are displayed the row totals are on
the left and both are equally displaced from the zone position. The choice of
whether row totals, column totals or both are given and whether or not the network
map appears at the same time is controlled by the matrix menu “display mode”.

The vertical scale of the rectangles is determined by a proportionality constant

“UPMM” - ‘x’ units of totals become x/UPMM mm. on the screen.

A lower bound may also be set (see Options below) which suppresses the display
of small row/column totals.

11.6.7.2 Matrix Selection

Facilities exist to select certain “sub areas” within the matrix by nominating a
range of origin zones (rows) and/or destinations (columns). For example if we
had a 100 zone trip matrix we could choose origins 60 to 69 (inclusive) and
destinations 70 to 89, in which case the only matrix elements to be considered in
the row/column summations would be those in the “rectangle” containing the 10
origins and 20 destinations (200 o-d pairs). Selection therefore changes the
values of the numerical values displayed.

An alternative option allows us to use the same o/d ranges to define a “cross”
whereby all trips from origins 60 to 69 would be included (a horizontal strip) plus
all trips to destinations 70 to 89 (a vertical strip). In this case the row totals for
origins 60 to 69 would be the same as for the complete matrix as would the
destination totals 70 to 89, but all others would be potentially reduced.

In either case if the display mode were set to be origins only then the outputs
would be the totals of the elements within the rectangle/cross.

In the limit, by selecting a single origin or row from a trip matrix the corresponding
destinations are displayed so that one can examine individual cell values.

Indirectly selection may also “control” the zones which appear in the plots since a
zone with a row/column total of zero (or less than the lower bound) does not
appear; however its main purpose is to select the o-d cells which go into the
summations.

11.6.7.3 Desire Lines

An alternative method of looking at individual cells is to plot desire lines, i.e., lines
directly linking an origin and destination whose width is proportional to the trip
matrix element. Options also exist to direct the lines via an intermediate point so
that desire lines for a trip matrix representing trips through a road side interview
(RSI) station will actually pass through that point.

Note that there is an upper limit of 502 o-d pairs which can be displayed as desire
lines at any one time in order to prevent “information overload”. If there are more

5101396/ May 11 11-37

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

P1X: Interactive Analysis of Results

than 502 pairs eligible (i.e., selected and value above the lower bound) then the
502 pairs with the maximum (absolute) matrix values are selected. For most
matrices, e.g., those with more than 25 or 30 zones, this rule would be in force.
Note, however, that the same restriction would not apply to sector-to-sector desire
lines (see next) and therefore these give a more complete (and aggregated)
picture.

With desire lines selection directly controls which o-d cells are displayed and
clearly the values associated with those o-d cells are fixed independent of how the
selection is done. This contrasts with the row and/or column totals where
selection affects the values displayed.

11.6.7.4 Sector Displays

Finally, for networks where sectors are defined, it is equally possible to display
row/column totals or desire lines by sector rather than by zone. Recall that sector
X,Y co-ordinates are set in the input .dat file to SATNET (6.8).

Indeed, given the vast amount of data contained in individual o-d cells and even
row and column totals, displaying matrix data via sectors can often be far easier to
digest.

11.6.7.5 Miscellaneous Options

Other options include comparing two different input matrices as well as viewing
one “slice” of a stacked matrix file.

Note, in addition, the “lower bound” parameter which may be used to suppress the
display of small row/column totals or of small desire lines as appropriate.

11.6.8 General Display Parameters

These parameters control features such as

♦ Whether or not a blank border surrounds the plot

♦ The width of an extra blank border down the left-hand side (useful for
reports).

♦ Whether annotation is allowed to spill over inside the borders.

♦ The pen colours used for general drawing, e.g. link colours, the legend etc.

♦ Grid lines and their spacing.

♦ Access to general SATURN display parameters (e.g. the number of vertical

lines on the screen).

5101396/ May 11 11-38

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

P1X: Interactive Analysis of Results

♦ XYUNIT (which, if incorrectly set in the original network file, is a pain to reset
without rerunning the entire network).

♦ An option to suppress the exterior lines enclosing the window which may be
useful for plots to be transferred into reports.

♦ An option to use either the full available screen or to reduce the window to fit
the network window plotted.

In short, any parameters that don’t fit conveniently anywhere else go here!

11.6.9 Banner and/or Title Display

Banners in SATURN refer to the strip which appears (by default) to the right of the
network and/or node graphics plots.

They serve a dual purpose: to display a menu of choices and/or to provide

information as to what is currently being plotted. The former is the most common,
the latter in its purest form is provided by an “A-Z banner” which contains not only
file names but also, e.g. a list of the link variables which are currently annotated.
The A-Z banner is provided under Show within the Windows menu.

In certain circumstances both functions are combined, e.g. a select link analysis
banner may display the total number of trips assigned as well as listing a set of
options to follow.

The banner control sub-menu allows the user to select:

♦ where the banner appears (essentially on the right, on the top or not at all);

♦ whether inputs are via the mouse or the keyboard;

♦ whether and where a title appears on the main plot;

♦ whether the banner menu choices are included or not in output plots to the
alternative device or to bitmap files (11.3.5 and 11.3.6);

♦ choices as to what appears in the A-Z banner, e.g. whether or not you want
the WS Atkins/ITS logo to appear;

♦ the pen colours and standard character height as used in the banner.

11.6.9.1 Removing the Banner

There are circumstances when one does not want the banner display to appear
on a plot, e.g. for transfer to an external document. However removing the banner
does create the problem that the information on the next input menu choices is

5101396/ May 11 11-39

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

P1X: Interactive Analysis of Results

also removed. For this reason deleting the banner under mouse control is not
allowed (there would be nothing to point to!). Under keyboard control you will
need to “navigate blind” until the banner is restored, i.e. remember the sequence
of key inputs which you will need to execute next, presumably winding up back in
the banner control menu where an input of ‘B’ will toggle the banner back on.

11.6.10 Choosing the GIS Display

The constituent elements of a GIS file (see 5.7 for a general description) may be
toggled off or on within the P1X GIS menu. The components (in the order in
which they are plotted) are:

♦ Polygon

♦ Lines

♦ Icons

♦ Text

♦ Node names

♦ Link names

♦ Curved/straight links

Note that while the “names” set in a GIS file are normally titles such as “Hyde
Park” or “M62” they are essentially just text so that you may use this facility to
include comments such as “New Signals” or “Congested” on the plots.

By default all GIS displays are “off” but the default settings are in fact stored within
the P1X preferences file (11.6.10) such that if you turn, say, curved links “on” and
then store a new preferences file then curved links will be the default from, then
on. More specifically the Namelist “names” associated with the 8 options above
are of the form GIS1, GIS2, … GIS8; i.e. an entry of the form: GIS8 = T sets
curved links to “on”.

11.6.11 Background Displays

As discussed in section 15.43 it is possible to use an input bitmap (.bmp) file as

the “background” upon which the network plot is overlaid in a similar fashion to
using SATURN-set GIS data as background. Bitmap backgrounds have the
advantage of being “proper” map displays (assuming of course that they are
obtained from “proper” maps”.

The default is a blank screen.

5101396/ May 11 11-40

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

P1X: Interactive Analysis of Results

11.7 Validation Options

The validation options within P1X are based on the premise that there are two
basic methods by which modellers can validate a network model by comparing
model outputs with observations:

♦ By comparing observed and modelled flows.

♦ By comparing observed and modelled travel times.

These facilities are described within the next two sub-sections.

There are of course other methods available, for example comparing predicted O-
D routes with observed or expected routes but these analysis methods are mostly
contained within section 11.8

11.7.1 Count Validation

Goodness of fit statistics between modelled and observed flows may be obtained
in a number of different locations within SATURN and in a number of different
ways as explained in 15.6. Under P1X Validation both numerical statistics and
graphical scatterplots may be obtained with the full set of possible options and
level of disaggregation.

Count comparisons in P1X Validation may be applied either with (a) the set of link
flows input under the 77777 records of a network .dat file (see 6.10) or (b) using
counts input directly from an external file; see 11.11.13. (Within SATLOOK only
method (a) is available. An alternative method for introducing new count data into
a network file which has already been assigned using a “warm start” is described
in Section 22.4.)

If more than one 77777 set has been included, than the analysis may be done on
each set individually (“disaggregation”) and/or on the combined data set.
Alternatively (new in 10.5) only a single data set may be nominated under
disaggregation.

If more than one count field per link has been used (MCCS>1) than one particular
field may be used. Finally the analysis may be applied to links only, turns only or
(the default) all input records.

The modelled flow may be defined in a number of different ways, i.e. actual vrs.
demand flows, bus flows included or excluded and one/all user classes.

Full numerical output statistics are included in the .lpp file; summaries are
(optionally) sent to the screen. Optionally validation criteria as recommended by
the UK Department of Transport are set out; these include:

1) For flows > 700 pcu/h the percentage of modelled flow within + 15% of the
count.

5101396/ May 11 11-41

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

P1X: Interactive Analysis of Results

2) For flows <700 pcu/h the percentage of modelled flows within + 100 of the
count.

3) The percentage of counted links where the GEH statistic (15.6) is less than
5.0.

In all 3 cases the Department’s recommendation is that 85% of the counts should
satisfy the above criteria. (N.B. The flow split between 1) and 2) in SATURN is
based on flow units of PCU/h, not VEHICLES/h as strictly used by DETR.)

The scatterplots plot modelled vrs observed flows and (again, subject to options)
best fit lines of the form y = a + bx, y = bx and y = x with plus/minus GEH limits
included. Thus if you ask for y = a + bx only and GEH error = 5 then the linear
plot is given with upper and lower curves corresponding to modelled flows which
would be within a GEH value of +5.

Note that the same set of options may also be invoked under option 13 of
SATLOOK, 11.11.13.

Points in the scatterplot are plotted as small squares; optionally the count
“number” (as it appears in the full list of counts) may appear above and to the right
of the squares. Although probably not legible in a mass of points near the 45
degree line they are useful for quick identification of outliers.

5101396/ May 11 11-42

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

P1X: Interactive Analysis of Results

11.7.2 Travel Time Validation: Time vrs. Distance Charts

The comparison of observed and modelled travel times along routes may only be
invoked if timing points have been included within the 66666 route data input
section; see 6.9.5. (The option to input timed route data directly to P1X from files,
as is possible with counts, will be made available in the future.)

This facility is intended to be used in conjunction with standard moving car

observer surveys whereby a car follows a fixed route (generally more than once)
and the times to reach certain locations (in the limit every junction) are recorded.
By analysing the same route(s) in SATURN with the equivalent timing point
information generated by the modelled speeds/delays an estimate of how well the
model is estimating travel time (as opposed to pure flows) may be obtained.

11.7.2.1 The Definition of Timing Points

Note, as already specified in 6.9.5, that timing points are assumed to be

measured as the vehicle crosses the stop line, as opposed to reaching the end of
the queue. Thus they include the delay time associated with the particular turning
movement and therefore, if a route follows A-B-C, the assumed time to reach B is
dependent upon C.

There is, however, one possible exception to the above rule. If the final link in a
route is an internal simulation link where there is, by definition, no exit node
defined then the cumulative modelled time includes the cruise time on the final link
but – traditionally prior to 10.9.16 - no turn delay contribution; i.e., it is effectively
the time to reach the end of the queue, not the stop-line. However, post 10.9.16, it
is possible to include the average turning delay at the downstream stop line by
setting a parameter ADEL = T. ADEL may be set interactively within the joyride
options or pre-set within the preferences file p1x0.dat; its default is T.

11.7.2.2 Joy-Ride Displays

The outputs are not dissimilar to those produced by the Joy Ride or Bus Route
analyses. For example the routes may be displayed one link at a time with
cumulative data in the banner or the whole route may be displayed in one go. The
main difference here is that at those nodes where a timing point has been
provided a box appears on the plot with both the timing point and the cumulative
modelled time displayed top and bottom respectively. The same information is
also included as a more permanent record in the .lpp file.

Note that when a timed route begins within the simulation network, e.g. with nodes
A-B-C…, then the cumulative modelled times will either include or exclude the
travel time on the first link A-B depending on whether or not the parameter
UPBUS = T or F respectively or – post.10.9.24 – whether the coded route
frequency was zero or positive (see 6.9.5).

Clearly UPBUS and/or frequency should be set to coincide with the convention by
which the input timing points are measured. The most “natural” assumption is that

5101396/ May 11 11-43

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

P1X: Interactive Analysis of Results

the timing would begin at node A above, in which case UPBUS = T is preferable.
However, the value of UPBUS as set in the original network .dat file (see 6.9.2)
may well also be influenced by its application to “true” (positive frequency) bus
routes and indeed its default value is F. It is for that reason that the extra rule
(see 6.9.5) was introduced that if the route frequency is zero (which is natural for a
pure timing route) then timing always begins at point A independent of UPBUS.

Note that the value of UPBUS may also be changed interactively within P1X and
that if the route begins/ends at buffer nodes then none of these complications
occur.

11.7.2.3 Time vrs Distance Plots

At the end of each route traced a “time vrs distance” plot may be produced
(optionally) with the modelled time in minutes to each node plotted against the
distance in kms to that node. Travel time “on the link” and “in queues” (at
simulation nodes only) is displayed by plotting queued time as a vertical line; i.e. it
is assumed that no distance is travelled while the vehicle is delayed at the
junction. The queuing delay is of course average and specific to the turn (so that
at each link the delay depends on the next link chosen).

Also plotted is the observed time vrs distance plot. Note that this is assumed to
be the time to the stop line so it should be compared to the upper point at
simulation nodes.

The observed times may also contain “error bars”, i.e. vertical lines at each point
representing the spread of measured values if more than one observation run has
been undertaken (as should be highly recommended in practice). Spreads are
(optionally) input in the second input field within brackets in the network 66666
records (see 6.9.5).

Optionally the node annotation at each point may be displayed, in exactly the
same way that they are currently displayed in the network plots, for example as a
node shape with its node number offset. Similarly an option to include annotation
along each link, again as it currently appears in the network plots, will be
introduced “soon”.

Equally a short line whose slope represents the mean route speed (to the nearest
integer kph) is plotted in the lower right hand corner in order to provide a scale.

5101396/ May 11 11-44

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

P1X: Interactive Analysis of Results

11.7.2.4 Summary Statistics

If there are more than one route containing timing point data a summary table may
be produced (see Routes/Options) which gives, for all timed routes, the final
(only) input timing point, the comparable modelled time plus the absolute and
percentage errors.

The table also tests whether or not the modelled times satisfy the standard DfT
criterion of being within either 1 minute or +-15% of the observed times. The total
number of “OK” observations is also recorded.

11.8 P1X Analysis Functions

P1X contains a large number of network analysis operations, the majority of which
are best carried out using the mouse. These are entered from the ‘top’ menu;
subsequent choices are indicated by the menu in the banner.

In particular the user may:

♦ request select link assignment (11.8.1);

♦ define joy rides (11.8.2);

5101396/ May 11 11-45

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

P1X: Interactive Analysis of Results

♦ display trees, forests, etc (11.8.3);

♦ request link, bus or node-based etc. information for display in a text window;
ditto network-based information (11.8.4);

♦ Review output statistics from a run of SATME2 (11.8.5).

Further details are given in the above mentioned sub-sections.

In certain of these operations the link data created, e.g. forests, may be
permanently stored within the internal data base for later further analysis or
display.

11.8.1 Select Link Analysis (SLA)

11.8.1.1 Basic P1X SLA Options

Select Link Analysis within P1X may calculate and display graphically those O-D
flows which are assigned to:

♦ a single link (the simplest case);

♦ a centroid connector (a special case of (i);

♦ through a series of nodes;

♦ a “screen line” of several links (see 11.8.1.9);

♦ a selected origin or destination zone.

Note that the “series of nodes” is, in effect, an “AND” test in that to be selected a
route must pass through all the nodes in the correct sequence; whereas the
“screen line” is an “OR” test in that, in order to be selected, a route may go
through ANY of the selected links (but see 11.8.1.10 for alternatives to the latter
rule). Use three nodes in succession to identify a turning movement.

Note that the same basic calculations (but with slightly fewer options) may also be
carried out within SATDB; see 11.10.7.5.

11.8.1.2 General Principles

Basically any O-D trips which use paths which satisfy the selection rules (e.g.,
pass through the single selected link) are re-loaded and the total assignment
pattern of those trips (both before and after they pass the selection point) is
displayed. See Sections 15.19 and 15.23 for a more detailed discussion of the
principles involved.

5101396/ May 11 11-46

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

P1X: Interactive Analysis of Results

In particular please note the caveats in 15.23.2 that the routes which are
reconstructed in order to carry out a select link analysis do not necessarily
correspond exactly to those used within the actual assignment (e.g., if elastic
assignment or KOMBI or DIDDLE is invoked). Therefore the information
generated by the SLA may only be a first approximation to the “true” SLA: in
general the higher degree of overall convergence in the model, the better the
approximation will be. Please refer to the displays which list the SAVEIT Accuracy
for further information (See 11.8.4.7).

On the other hand it is always worth remembering that the precise route flows
generated by a Wardrop equilibrium assignment (and indeed for stochastic
assignment as well) are not unique, therefore neither is an SLA. Furthermore any
output data at this level of disaggregation should always be taken with a large
pinch of salt. We therefore recommend treating any SLA outputs as
“representative” rather than precise estimates.

In addition please bear in mind that the SLA flows arise only from the trip matrix
assigned and that they therefore exclude, e.g., bus flows or other fixed flows.
Hence SLA flows are very often significantly lower than the “total” flows - a
perennial source of confusion!

11.8.1.3 Matrix vrs. Flow Outputs

The output from a select link analysis may be in one of two forms: (i) either the link
flows as above or (ii) a matrix of the “selected” O-D trips saved as an output .ufm
matrix, in which case the flows on the links are not explicitly calculated or
displayed. The “Matrix - Yes” / “Matrix - No” option toggles between them.

Link flow data may be saved in the internal (SATDB) data base, either
automatically or optionally once created.

We note in this respect that there is a “Repeat SLA” option which is useful in the
situation where you require both flows and a matrix. Thus having defined and run
the “SLA” for, say, flows toggle to Matrix - In and simply repeat to avoid having to
redefine the links.

Users need to be aware of potential problems in simply trying to re-assign a SLA

matrix; see 11.10.7.7.

11.8.1.4 Full Statistics

Having carried out an SLA further details are available on screen (and reprinted in
the LP file) under “Full stats”. For example, the average travel time and distance
of all the selected trips is calculated plus (see 7.1.1.11) the flow-weighted supply
elasticity over those links used. In addition, if sectors have been defined, a
summary table of sector-to- sector movements using the selected links is
provided.

5101396/ May 11 11-47

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

P1X: Interactive Analysis of Results

Furthermore, unless the SLA were based on a screen line of multiple links, a table
of disaggregated entry-exit demand movements is provided giving the flows from
each possible entry point at the first node to each possible exit point from the last
node.

11.8.1.5 Flow Definition

If the network contains a simulation network the flows may be defined in one of
three ways:

(i) demand flow

(ii) actual flows

(iii) queued flows

Thus under i) the flow considered to cross the selected link(s) is the full flow
demand flow as given by the input trip matrix whereas under ii) if the routes pass
through over-capacity links or turns it is the actual (reduced) flow which reaches
the selected link that is monitored. Note that any reduction to SLA flows is only
applied to over-capacity turns between the origin and the selected link; what
happens to those flows after the selected link is not relevant.

Queued flow is essentially the difference between the demand and the actual
(expressed in units of pcus/hr).

The same flow definitions also apply to SLA matrices (11.8.1.3). Thus, for
example, an actual trip matrix for a particular link represents those flows that,
starting from their origins, actually reached that link; i.e., any flow reductions after
the link are not considered.

11.8.1.6 Multiple User Classes

If the network contains multiple user classes options exist to select an individual
class for analysis or all classes combined. However any flows arising from “fixed
flows”, e.g., bus flows, are excluded from the analysis (although the fixed flow on
a single selected link may be displayed).

Under matrix output with multiple user classes either the matrix for a single user
class will be output or, if all classes have been selected, a “stacked” matrix for all
classes will be created.

11.8.1.7 Multiple Networks

If more than one network has been input the select link analysis may be carried
out on any one of them provided that the network is structurally identical to the
“base” network 1. The choice is made from the main menu. Thus if you use

5101396/ May 11 11-48

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

P1X: Interactive Analysis of Results

network 2 the route proportions are taken from the .UFC (/.UFO etc.) file for that
particular network.

11.8.1.8 Multiple Trip Matrices

By default the trip matrix used to carry out a SLA is the trip matrix associated with
network 1. However it is possible to redefine the matrix if desired, subject to the
obvious constraint that the matrix must have the same number of zones, user
classes etc. as the network being analysed.

Note that changing the network does not automatically change the trip matrix to
that used by the new network; it must be explicitly user set.

11.8.1.9 Defining SLA Screen Lines

A “screen line” simply consists of a set of more than one links, traditionally
speaking a set of links which cross some form of geographical line; e.g., bridges
over a river. However screen lines as used within SLA could equally well
represent a “cordon” of links which surround a sub-area of the network, the set of
all links which are tolled, etc. etc. It is up to the user.

SLA screen lines may be defined in one of four ways:

1) by selecting links interactively using the mouse;

2) via a set of links input under the 7777 records;

3) those links currently “selected” (in the sense of 11.6.1);

4) via an external ASCII or text file.

Under options (2) and (3) turns may also be included. In all four cases links are
“directional”.

The external file consists simply of a set of individual records, each containing a
link A-node and B-node. The format is “free” in that the 2 nodes must be
separated either by a comma or a space. Thus standard “fixed 5-column”
SATURN link records (e.g., 6.10) are acceptable unless 5-digit node numbers are
used, in which case it is possible that column 6 will not be blank. The file is
(preferably) terminated by a 99999 record.

Options (2) and (3) are also available within SATDB (see 11.10.7.5).

11.8.1.10 Multiple Crossings on Screen Lines

With screen lines it is quite possible for a single path to cross more than one link
in the screen line whereas for single links, single turns etc. it is not. There are
therefore options available within screen line SLA to select only those trips that,

5101396/ May 11 11-49

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

P1X: Interactive Analysis of Results

say, cross two or more links or that cross two links exactly. These options were
first introduced in Version 10.5.

Two parameters may be set: (a) the “logical” choice between a minimum number
of crossings or an exact number; and (b) the number of crossings. Prior to 10.5
the rule was to include if the path crossed any of the selected links, i.e., minimum
and one above.

11.8.2 Joy Rides

A “joy ride” traces a trip through a specified set of nodes selected using the mouse
and keeps a running sum of time, distance, etc. Cumulative totals of, e.g. time,
distance and speed, appear in the banner but are also contained in the line printer
listings for subsequent analysis. Equally basic properties (time, distance, etc.) of
the current link and/or turn are displayed.

Note that “delay” as displayed within the banner is defined to be the difference
between actual “congested” time and the minimum time (i.e. the time under free
flow conditions) on links and/or turns. It might therefore be better referred to as
“additional delay”.

The nodes selected need not be consecutive, the program “interpolates” the most
direct sequence of nodes as necessary (see 15.18). In the case of non-
consecutive nodes the “route” may either “jump” directly to the next node selected
with the appropriate cumulative totals displayed or alternatively the route may be
stepped through to each intermediate node.

It is also possible to use this option to “select” - in the sense of section 11.6.1 -
those links in the route for subsequent analysis.

In the event that the joyride route contains “penalties” - as defined under the
44444 records - then these too are recorded. If there are also multiple user
classes then a single user class to which the penalties apply must be nominated.
Note that the penalties are further disaggregated into “time” penalties or “tolls” as
appropriate.

At the termination of the joyride a plot of the time along the route vrs the distance
along the link may be requested; see 11.7.2.

11.8.3 Trees, Forests and Arboreta

In order to display tree-based information it is first necessary to define: (a) and

origin and (b) - optionally but normally - a destination. If a destination is not
defined then the number of options available is limited to essentially building a full
tree (i.e., the set of all minimum cost paths from the origin).

5101396/ May 11 11-50

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

P1X: Interactive Analysis of Results

MAIN DISPLAY OPTIONS

Assuming both the origin (O) and destination (D) are set you may display either:

a) the minimum cost route (“tree”) from O to D (generally, but not necessarily,
using the same criteria employed by the assignment);

b) the complete tree from O to all nodes (including all zones);

c) the complete tree from O to all zones (with any zones that cannot be
reached, e.g., due to a disconnected network, indicated by a large X);

d) the minimum cost route as (a) but as a “joy ride”, i.e., link by link;

e) the complete set of O-D routes from an iterative assignment plotted iteration
by iteration (with either the screen cleared between each route or in
“overlay” mode where they are superimposed on one another);

f) the complete set of O-D routes plotted as a “forest”;

g) the full set of distinct routes, an “arboretum”;

h) as origin-based “isochrones” - see 11.8.3.3;

i) the set of least well converged O-D routes – see 11.8.3.4.

See Section 15.26 for further explanations of the concepts.

A summary banner which displays, e.g., the cumulative (“skimmed”) time, distance
etc. associated with the displayed route is included when appropriate.

With certain options, e.g. forests, it is possible to “store” the link data generated as
an extra column in the link (SATDB) data base, e.g., for further analysis.

5101396/ May 11 11-51

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

P1X: Interactive Analysis of Results

Trees may also be displayed “in reverse”, i.e. into a destination as opposed to out
of an origin. However the destination-based options are limited essentially to
building “full trees” from all nodes since specific O-D tree information is provided
only within the origin-based menu.

11.8.3.1 Tree Build Options

By default the O-D trees are built using identical criteria to those set for the
assignment; however these criteria may be adjusted to illustrate the effect of using
different criteria. Thus the “cost” used to define minimum-cost routes may be re-
defined or you may toggle to and from stochastic assignment, etc.

In the event of multiple user classes a single class must be nominated and the
trees etc. for that class are displayed. Note that at the moment it is not possible to
select “all” user classes to produce an automatic loop over all classes; this needs
to be done manually.

It is also possible when building a single O-D route to display the time vrs distance
plot for that route after the tree has been plotted, either automatically by setting a
parameter under options or, effectively as an after-thought, through the post-tree
display menu.

11.8.3.2 Trees and/or Forests using Alternative Networks

When more than one input network file is being used it is possible, under certain
circumstances, to view the routes as generated by, say, network 2 as opposed to
network 1 (which is the default). However this is generally only feasible when the

5101396/ May 11 11-52

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

P1X: Interactive Analysis of Results

two networks are structurally identical (such that a link in network 2 will appear in
the correct location when displayed on a network 1 map).

This facility only applies to those options which display the routes as built during
the assignment, i.e., arboreta and the complete sets of O-D routes. However, with
forests the comparisons may be taken further such that it is possible to construct
link data equal to, e.g., the difference in the forest values between networks 1 and
2, or to plot both simultaneously, etc.

11.8.3.3 Isochrones

A related display, still very much under development, shows “isochrones” of equi-
cost bands from the origin as overlapping in-filled coloured bands. These are
based not just on the costs from the origin to discrete points along the road but to
any point in the 2-dimensional space within the network by the additional
assumption of a “walking speed”. Thus the cost to reach any point (X, Y) is made
up of the cost to get to the “nearest” point on the road network plus the extra
time/cost to “walk” from the road (assuming the minimum crow fly distance).

Parameters to be set include:

♦ The definition of “cost” (e.g., minimum time, distance, generalised cost, etc.
etc.)

♦ the number of bands

♦ the “width” (in generalised seconds) of each band

♦ the walking speed in kph.

Destination-based isochrones may also be displayed with similar choices.

N.B. “Walking speed” may equally well be interpreted as “driving speed on minor
roads”, in which case a default value considerably greater than the default walking
speed of 3.6 kph should be set; e.g., 20 kph. (Change the namelist parameter
WALKPH in P1X0.DAT.)

5101396/ May 11 11-53

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

P1X: Interactive Analysis of Results

DISPLAYING ISOCHRONES AS NODAL DATA

It is also possible to display isochrones in terms of the minimum “cost” to every

node (or, similarly, every zone) in the network from the origin / to the destination.
In this case the cost is indicated by a variable coloured circle at each node/zone
such that all nodes in the same cost band have the same colour.

SAVING ISOCHRONES AS NODE DATA

New options introduced in 10.7.8 allow the calculated minimum costs to each
node (as above) to be stored either: (a) to an external ASCII (text) file, or (b) to an
internal SATDB node data column.

Under (a) the output file consists of 4 data items per record:
(1) Node number
(2) Its X (horizontal) co-ordinate
(3) Its Y (vertical) co-ordinate
(4) Its minimum cost

This data could then be fed into a “proper” GIS system which could then
produce “proper” line contours in whatever format is desired.

Under (b) the node data could be manipulated internally as desired; see
11.10.5. For example, the node minimum costs could be displayed using any
of the standard node display options (11.6.5). Alternatively, one could do
things such as calculating the isochrone minimum cost to several zones

5101396/ May 11 11-54

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

P1X: Interactive Analysis of Results

representing, say, hospitals so that taking the minimum over several data
columns would then give you the (minimum) cost from every node to the
nearest hospital.

11.8.3.4 Worst O-D Routes

These options allow one to identify which O-D paths are “furthest” from being in
Wardrop Equilibrium; i.e., those (positive flow) paths P ij where c pij – c ij * is
maximised.

The first option “All O-D Pairs” produces a table of the 10 worst paths by origin
such that for each origin zone the single worst O-D path is selected and then
worst paths are ranked by origin. For each origin the table lists the single
destination to which the worst path was found and the difference in costs for the
worst path.

The second option identifies the 10 worst paths for the current origin and, in this
case, lists the particular destinations plus total O-D flows (i.e. T ij , not T pij ).

Note that in neither of the first two options is the exact volume of traffic T pij on the
worst paths taken into account (as long as it is positive). Thus it may well be that
the worst paths identified may not be necessarily all that important in terms of the
overall lack of convergence (see eqn. 7.3 for delta) since the maximum value of
c pij – c ij * may be associated witb a very small path flow T pij which the assignment
algorithm is doing its best to reduce to zero. The link delta values described in the
following section are superior in this respect in that they are flow-weighted.

Costs per link – and hence by path – may be set either as calculated at the end of
the last assignment or as calculated at the end of the following simulation. In the
former case we identify those paths which make the maximum contribution to the
delta function; in the latter case it is the contribution to the combined gap function
which, in turn, may be used to indicate where the overall simulation-assignment
convergence is weakest.

11.8.3.5 Link-specific Gap and/or Delta Values

The contribution made by an individual link (A,B) to the delta/gap functions may
be calculated by the following equation:

δ AB = Σ pij∈AB T pij (C A * + C AB - C B *)
Where C A/B * is the minimum cost from origin I to node A / B
C AB is the cost on link (A,B)
T pij is the flow on path p from origin I to destination j
pij∈AB denotes those paths that use the link (A,B)

The “cost” term in the brackets represents the extra cost above and beyond a
minimum cost path that a vehicle from I to j would incur by using link (A,B) and is
therefore a measure of its departure from Wardrop Equilibrium. Under perfect

5101396/ May 11 11-55

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

P1X: Interactive Analysis of Results

equilibrium if the cost term is positive then T pij should be zero; if T pij is positive then
the cost term should be zero.

We may note that summing δ AB over all links would give us the same numerator
as the equation (7.3) for Delta (Section 7.1.4)
Link delta values may be further disaggregated by, e.g., only considering a single
origin. Equally we could produce an origin-specific delta value by summing over
all links with the origin i fixed.

The banner provides several options for calculation and display. Thus we may
calculate δ AB for the single selected origin or summed over all origins. (The former
is generally recommended for large networks since the cpu time required to sum
over all origins is roughly equivalent to carrying out a full assignment and, if you
choose an origin whose trips cover most of the network it should pick out those
links which have problems of convergence.)

Note that link delta values are set by assignment links which therefore, in the
context of a simulation network, contain both simulation roads and turns. In order
to view the full set they may be stored as a data base column and viewed
normally.

However, once set, link delta values are automatically displayed as link annotation
but, in this case, the value displayed for a simulation link (A,B) will have been
incremented by (a) all delta values for its exit turns (i.e., A-B-C) and (b) by all its
entry turns. The reason for this is that the turn values – which may well be more
significant than the pure link values – are otherwise not obvious. Large delta
values on, say, links A-B and B-C probably indicate a large contribution to both
from the turn A-B-C.

The times used in the calculation of generalized cost above may be either taken
post-assignment or post-simulation. In the former case δ AB is comparable to the
delta function (7.1.4); in the latter case it is comparable to the gap function (9.2.1).

11.8.4 Information Options

11.8.4.1 General Options

These options provide, firstly, basic data interactively on:

♦ Links

♦ Nodes

♦ Zones

♦ Bus routes

♦ Bus routes through a link (“Select Link Analysis”)

5101396/ May 11 11-56

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

P1X: Interactive Analysis of Results

♦ X,Y co-ordinates

Secondly, a range of options as otherwise provided by SATLOOK:

♦ Network parameters

♦ Simulation and/or buffer summary statistics

And, thirdly, various miscellaneous pieces of information:

♦ Flows making U-turns at external simulation nodes

♦ An assessment of the validity of the network parameters chosen

♦ Accuracy estimates under SAVEIT

♦ CPU time etc. statistics

♦ A list of all errors encountered in SATNET.

These are described in sub-sections 11.8.4.2 to 11.8.4.9.

11.8.4.2 Interactive Information: Links, Nodes, Zones and Buses

The user may, for example, select a specific link and a text window displays a set
of the most relevant statistics describing that link, e.g. distance, flows, speed etc.
A full listing of all bus routes through that link is also included (see below). Data
related to individual nodes and/or zones are displayed in a similar manner.

Two options are available with buses. Firstly, individual bus routes are displayed
using both numerical data (in the banner) and a link-by-link graphical (“joy ride”)
display (see the figure below). Secondly, all bus routes which pass through an
individual link (a form of “Select Link Bus Analysis”) are displayed by simply
“marking” all other links used by the selected services. (More complex data
display formats could be provided e.g., annotate the total bus flows per link;
requests to DVV.)

All these functions are “look only”, i.e. no editing is possible.

5101396/ May 11 11-57

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

P1X: Interactive Analysis of Results

11.8.4.3 X,Y Monitoring

X,Y monitoring allows the user to identify the user co-ordinates with points within
the plotted window by simply moving the mouse within that area; the
corresponding user co-ordinates appear within the banner. This facility is useful,
for example, in “calibrating” the corners of a .bmp file (see 15.43). To terminate
“monitoring” click the mouse at any point.

11.8.4.4 SATLOOK-style Network Statistics

Several of the options traditionally available within SATLOOK to provide network-

wide or aggregate information may also be accessed (in a window display format)
from within the P1X Information options. Specifically:

♦ Network parameters (e.g., numbers of nodes and links plus selected

parameter values);

♦ Simulation and/or buffer summary statistics

♦ Convergence plus error statistics

For more information see 11.11.7, 11.11.4 and 11.11.8 respectively.

Note that some of these options give less data than provided by SATLOOK, for
example simulation/buffer statistics disaggregated by user class, capacity index

5101396/ May 11 11-58

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

P1X: Interactive Analysis of Results

etc. However (new with 10.5) the table which compares simulation statistics over
multiple networks is available in window format.

11.8.4.5 Parameter Examination

This option assesses all current standard Namelist parameters (i.e., those
described in 6.3) and displays a list of warnings where the Grand High SATURN
Judges/Executioners feel that you may be doing something just a tiny bit stupid.
Or indeed very stupid.

11.8.4.6 U-turns at External Simulation Nodes

This option prints (to a window and to the .lpp file) a list of all external simulation
nodes where U-turns are possible and an estimate of the total flow making such
U-turns. See 18.9.

11.8.4.7 Accuracy of SAVEIT

The O-D routes re-constructed by P1X are not necessarily identical to those
generated by the assignment; this option outputs a table of goodness-of-fit
statistics as described further in 15.23.2.

11.8.4.8 CPU Time Etc. Statistics

This lists total cpu times split by network building/assignment/simulation stages

plus various other useful parameters and/or outputs such as elasticities that do
not naturally fit any place else.

11.8.4.9 List of Warnings etc. within SATNET

This option lists both the number of times each individual Warning, Serious
Warning, etc. etc occurred within SATNET with a one-line description of the error
(whereas the same numbers but with potentially longer descriptions are given in
.LPN files) plus the breakdown into 11111, 22222 etc. segments.

11.8.5 ME2 Data File Analyses

Following SATURN 10.5 SATME2 now outputs a “ME2” data file (see 13.8) which
P1X may read and carry out further analyses. Within P1X the user may either:

♦ display selected data fields from the .me2 file, or

♦ print summary statistics.

The data fields include both inputs to SATME2 such as the counted flows and
outputs such as the post-ME2 flows, the Xa balancing factors, etc.

5101396/ May 11 11-59

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

P1X: Interactive Analysis of Results

The summary statistics consist of Tables 4b and 5b as contained within the .lpm
output files and giving goodness of fit statistics between the updated matrix and
the target counts.

11.9 P1X Editing Facilities

P1X may edit either:

♦ the network; and/or

♦ the associated GIS data (5.7.2).

(P1X may also produce data-specific ASCII sub-files where, for example, one can
edit the co-ordinates in order to produce a file containing only the new X,Y co-
ordinates. However these applications are being progressively discontinued as
their functions are subsumed within the standard network and/or GIS editing
options.)

11.9.1 Network Editing

A full discussion of network editing is given in Section 18 and there is a

considerable degree of overlap between this section and 18. In particular Section
18 explains how network editing in P1X may be sub-divided into:

1) Changes to “properties” of the existing network, e.g. link capacities.

2) Changes to the network “topology”, i.e. additions or deletions of nodes, links

or turns.

Topological changes are handled by a routine within P1X referred to as PMAKE

as well as by option (2) below. These functions are described in Section 18.
Within this section we concentrate primarily on changes to properties.

Within the main edit menu options are provided to:

1) edit existing simulation nodes (as in SATED)

2) edit simulation centroid connectors (strictly speaking, topological changes)

3) edit existing buffer links

4) edit penalised or restricted links

5) change XY co-ordinates

6) edit bus routes

5101396/ May 11 11-60

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

P1X: Interactive Analysis of Results

7) edit counts

8) edit the generalised cost definitions

9) update namelist parameters/options

10) convert buffer nodes to simulation

11) make (global) changes to traffic signals including:

− optimise all signalised green stage times and/or offsets

− transplant signal settings between networks

− update stage times and offsets (which might have been altered within
SATALL, for example)

12) screen edit segments of the internal .dat file.

13) Edit “data fields”, e.g., link distances over all simulation links, using data
input from external data files.

Note that options (1) to (8 above correspond with data sections 11111 to 88888 as
defined in the data files input to SATNET (6.1) while (9) edits the namelist-based
records (6.1) and (6.3). Option (10) essentially adds to the 11111 records (while
effectively removing records from the 33333 buffer records). Options (11) over-
write the signal timings within the 11111 records.

These are described in sub-sections 11.9.3 to 11.9.17.

Note, finally, that PMAKE may also be entered directly from the master edit menu
(see 18.1) in order to make topological changes as may the GIS-edit option.
Finally various options to output (save) new files as described in 11.9.2 may be
accessed.

All changes made are continuously recorded to a .dat file which is stored as an
internal “direct access” file which initially is copied from the original .dat file from
which the main network was built in SATNET. That filename 2. At the end of the
program run, once all the editing changes have been carried out, the internal
direct access file may be copied (“dumped”) to a new output .dat file (see 11.9.2),
from which a new network may be built by running SATNET. This is the
recommended option. See also 18.2.2.

2 The .dat file name should be recorded within the .ufs file and therefore opened automatically,
but, if not, the user must supply the correct file.

5101396/ May 11 11-61

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

P1X: Interactive Analysis of Results

Thus, as stressed in section 18.1, the main function of editing within SATURN is
to produce a revised .dat file from which new assignment and analysis runs may
be initiated.

11.9.2 Saving Edit Changes

Network edit operations may be preserved in three different ways by producing:

♦ an updated .dat network file;

♦ an updated .ufs file;

♦ a new .ufn file as (re-)built from the .dat file.

The new .dat file would generally be invoked at the end of an edit run once all
changes have been made (although it is probably good practice to take frequent
copies of .dat files during editing to avoid accidents). Note however that an
updated .dat file may only be created if there were an input .dat file to be used as
the “template” for further changes.

New .ufs files are built partly as a direct copy of the old .ufs file (network 1) but
with some arrays updated in accordance with editing changes made during P1X.
However there are restrictions as to when they can be produced and what “new”
data may be included. Thus a .ufs file may only be output if there have been no
changes to the network “topology”, i.e. no nodes/links added or deleted, only
changes to “properties”. Secondly, not all the possible editing steps described
below affect the .ufs output file. At the moment only the XY updates, editing of
existing simulation nodes, optimised stage times and/or offsets and (optionally)
namelist parameters (11.9.11) are included 3.

Ufn files are commonly “re-built” during editing in order to check for errors in the
current data and to update the linkages between the various network components
(e.g., the simulation and assignment networks); detailed documentation is
contained in 18.2.4.

Please note that new files are not automatically created but must be specially
requested by the user (see the output options within the edit banner menu).

11.9.2.1 Editing and Saving $INCLUDE Files

As described in 15.30 the network .dat file may reference one or more external
data files via a $INCLUDE record. Thus it is possible that the particular section of
data which the user wishes to edit is not in the “master” .dat file but in an included

3 Note that certain options within P1X re-read simulation data from the input .ufs file and therefore over-
write any internal simulation data that has been modified; for example re-assignment options under
SATDB (11.10.7) based on networks other than network 1. Therefore if you wish to save an updated
.ufs file you are advised to do so immediately after editing.

5101396/ May 11 11-62

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

P1X: Interactive Analysis of Results

file. To allow for this the $INCLUDE files are explicitly copied into the internal .dat
file where they may be edited in the normal fashion.

If the original network file does contain included files, there is a choice of output
formats where either:

(a) “new” $INCLUDE file(s) are created with the same filename as before which
over-write the originals or

(b) they may continue to be explicitly incorporated within the new .dat file.

In the latter case references to the old $INCLUDE file names are retained but
commented out with a * in column 1. The user may manually recreate new
$INCLUDE files by using a text editor to cut’n’paste from the new .dat file or
simply leave them within the new .dat file. If the network editing proceeds by a
series of small steps it is very often easier to leave the $INCLUDE data within the
main .dat files and only re-create the final new $INCLUDE files at the end of the
process.

Unfortunately the user is not always given the explicit choice between methods (a)
and (b) and more often than not it is the programme that decides. For example,
we note that the automatic network editing procedure SIGOPT – see 15.31.6 –
which optimises the stage times and/or offsets automatically using P1X by default
uses method (b); i.e., it incorporates all the old sub-files within the new .dat file.

11.9.3 Editing existing simulation nodes

The simulation nodes to be edited may be selected either, individually, using the
mouse and/or keyboard input (node number) or as part of an automatic loop over
all nodes which have been either: (a) selected or (b) highlighted on the screen
(see 11.6.5.4). They may also be selected individually in certain situations by
double-clicking on the node in a network plot or by clicking on an adjacent A-node
number in a node plot.

Highlighting is very useful for correcting all nodes which exhibit, say, a common
error or a problem in terms of convergence. Note that, in the latter case, loops
may be initiated directly within this menu, e.g., by looping over the 10 worst delay
nodes, as opposed to having highlighted nodes prior to entering the node edit
options.

Once selected a simulation node is “displayed” as per standard node graphics

(11.12) and its various “non-topological” input properties such as lane definitions,
saturation flows, signal settings, etc., may be altered interactively.

The changes requested are recorded both within the internal simulation arrays
(from whence they would be dumped into a new .ufs file) as well as into a “mini”
dat file which contains the node, link and/or signal data for that node only as
described in Section 6.4. The mini data file is normally extracted from the “full” .dat
file but if, for some reason, it cannot be found in that file a “temporary” version is

5101396/ May 11 11-63

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

P1X: Interactive Analysis of Results

created. At the end of editing the “mini” dat file may be re-inserted into the full .dat
file (unless you wish to “quit” the edit) which, as mentioned above, may itself be
saved as an external file at the conclusion of all editing steps.

The screen display is updated at the same time as the stored data and the current
contents of the mini .dat file may be directly viewed under “List” or a standard
“interpreted” print-out on screen of the node data may be obtained under “Print”.

Data alterations are subdivided under node, link, turn and signal (if appropriate)
headings within the banner menu or, alternatively, data edits for an individual link
may be accessed directly by clicking on the “box” at the end of each arm. Once a
link has been selected turns may be selected by clicking on the box at the end of
the appropriate exit arm.

(Note that the data which may be edited also includes certain “non-input”
properties such as actual flows. Editing these will have no impact on the node’s
data base but are included so as to allow a certain degree of “experimentation” as
mentioned in 11.12.4 and 11.12.5.)

At any point the node may be re-simulated and the effect of the changes viewed
as under SATLOOK (11.11.1).

The “Error Listing” gives a list of those errors which would be detected within
SATNET if the current net node coding were input there, including errors to the
signal definitions (separately available within the signals sub-menu).

Current errors are also noted under the Print option where the numbers of
warnings, non-fatal errors etc originally detected at this node by SATNET are also
listed (but not the explicit messages); some of these may of course have been
corrected by the current editing. Note however that certain errors found in
SATNET may not be detected within the node graphics if they are only detected
as the result of the coding of two or more simulation junctions. For such errors the
.lpn listing from SATNET will need to be consulted.

11.9.3.1 Banned Turns

Editing, i.e., adding or deleting, banned turns allows topological changes at the
simulation node and the mini .dat file to be updated accordingly. However once
such changes are made the node is “re-created” as an additional node at the end
of the normal simulation nodes such that any further changes are no longer
applied to the .ufs data. For this reason editing banned turns are not permitted
within the “normal” node graphics (11.12).

Once changes have been made to banned turns (either additions or deletions) it
will no longer be possible to output the revised network as a .ufs file, only as a .dat
file.

5101396/ May 11 11-64

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

P1X: Interactive Analysis of Results

11.9.3.2 Screen Editing

The screen editing option within simulation node editing allows the “mini” .dat file
associated with that node to be edited directly on-screen via a standard Windows
edit box and any changes made therein to be re-incorporated back into the
internal node definitions. In a sense screen editing is the converse of the normal
editing steps described above where changes requested interactively are applied
directly to the internal memory and the program itself then edits the .dat file; here
the changes to the .dat file drive the editing process.

Screen editing may also be used to add “comment cards” to the node data set by
inserting records which commence with a *. By convention any comment cards
which immediately precede a node record are considered to be part of that node’s
records and are therefore included in the “mini” dat file extracted from the main
network .dat file. Clearly these records may also be edited and/or extended using
screen editing.

Note that the same general “relationship” holds with all the following segments
where direct editing of data file is permitted.

11.9.4 Editing Simulation Centroid Connectors

N.B. All the edit options described herein are “topological” in that all changes
made to the 22222 data records result in changes to the centroid connectors.
Strictly speaking therefore they are more akin to PMAKE than to, say, node
editing but they are documented here (as well as in 18.7) since they are accessed
from the same menu as node editing.

Centroid connectors within the simulation network (as defined by the network
22222 records, 6.6, and distinct from those in the buffer network) may be altered
in seven ways:

(i) By modifying an existing zone record (i.e. one that already exists within the
22222 records);

(ii) By deleting an existing 22222 zone record;

(iii) By adding a new 22222 record (from a zone currently connected within the
buffer network);

(iv) By creating a new zone plus simulation centroid connectors;

(v) By replacing an existing centroid connector to a link with a “stub” connection

to a new dummy node created mid-link (11.9.4.1);

(vi) By screen editing;

5101396/ May 11 11-65

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

P1X: Interactive Analysis of Results

(vii) By deleting any “duplicate” zones which have identical centroid connectors
and aggregating them into a single zone (where the remaining zone is the
zone with the lowest number).

In cases i) to iii) zones are neither created nor removed (this must be done using
PMAKE); thus with ii) the zone should presumably remain connected within the
buffer network while iii) is more a question of transferring an existing zone from
the buffer to the simulation network.

However invoking any of the options above will change the location of the centroid
connectors and hence the definition of the map network “topology”. Hence this
option is like PMAKE in respect to topology such that, once changes are made
here, certain restrictions on what further steps may be taken in P1X come into
force. Clearly iv) is also topological in that it creates both zones and connectors.

Under i) a listing of the current zone record appears on the plot as the “legend”
and is continually updated as changes are made. Under iii) once a new zone is
selected for addition a new blank record is created and option i) is automatically
entered. Those changes affect both the .dat file and the map network but not the
structure of either the assignment or simulation networks.

11.9.4.1 Creating ’Stub’ Connectors

A “stub” connector (also referred to as a “spigot” connector) in this context refers

to a zone which is connected to an external simulation node which itself is
connected to a node in the middle of an internal simulation link as illustrated below
using the example used in Section 16.6.

5101396/ May 11 11-66

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

P1X: Interactive Analysis of Results

Thus if the existing network were coded as in the upper diagram with zone 5
connected to simulation link (3,5) option v) would create two new nodes, 6 and 7
in the lower diagram and connect the zone to zone 7. Here node 6 would be a 3-
arm priority junction with all three arms being coded as “major”; clearly further
editing of that node would be desirable.

The node numbers (i.e., “names”) allocated to the two new nodes would be (as in
the above example) n + 1 and n + 2 where n is currently the highest node number
used.

Stub creation may be applied either to individually selected zones or, with some
caution, to all internal simulation zones. It does not however apply to “external”
simulation zones.

Note that stub/spigot connectors are prime candidates for “network aggregation”
as described in Section 15.56.2.3.

11.9.5 Editing Buffer Links

“Editing” here refers only to editing the properties of existing buffer links;
topological changes to buffer links (i.e. adding or detecting) can only be done
under PMAKE. (See 18.6.)

Thus after selecting a buffer link the appropriate record from the original .dat file is
accessed and displayed within the normal plot legend (default at the bottom of the
screen). The user is then presented with an edit box to make changes to the
time(s), distance, etc.

Note that link properties which are “added” within SATURN, such as flows or the
speeds/times at those flows, cannot be edited at this stage, only the input
properties as defined under 6.6.

Two further procedures are also optionally provided under buffer link editing:

1) An option to delete all “second line” KNOBS data records; see 15.14.7

2) An option to correct all duplicated link records by deleting the second

occurrence of a repeated A,B record (if any exist).

11.9.6 Editing Penalised/Restricted Links

Facilities here are similar to those provided to edit counts (11.9.9) in that links
and/or turns may have their “ban/penalty indicators” (see 6.7) either added,
deleted or edited. The modified data set is then re-inserted into the internal .dat
file.

If there is more than one set of 444 records a particular sub-set needs to be
selected.

5101396/ May 11 11-67

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

P1X: Interactive Analysis of Results

As with simulation node editing a screen edit option is also available

11.9.7 Editing Node Co-ordinates: .XY Files

Node (and/or zone) co-ordinates may be altered by selecting the node with the
mouse and pointing to the new position. These co-ordinates then apply through
the remainder of that program run.

They may be subsequently saved either within full .ufs or .dat files or by outputting
a new .xy sub-file which contains a complete list of all nodes, zones and sectors.

By default the output co-ordinates are in the same format as that specified for the
input .dat file (see 6.8) but, post 10.9.14, alternative formats may be set
interactively. Thus the number of (fixed) columns per X or Y may be increased or
a CSV format chosen (FREEXY = T). Alternatively the co-ordinates may be
multiplied by the implicit factor XYUNIT so that they are in metres (as strongly
recommended; see 15.43.2)

Such a file may be “edited” or “$included” into a network .dat file. See 11.4.2.

Indeed it is quite useful to create a standard data file containing co-ordinates

which can be “$included” within a large number of networks since it is common
practice for all networks within a particular study area to share a common
definition of nodes and co-ordinates. This saves the need to edit a wide range of
.dat files.

Note that a supplementary “.xy” sub-file may also be an input file to P1X. Any
value read in over-writes the current value as read from the .ufs input file. See
11.4.1.

11.9.8 Editing (Bus) Routes

Recall from Section 6.9 that “routes” may include both “bus routes” - the most
common application - and routes with zero frequency which may be used under
validation. Both may be edited here. Note however that any changes made here
will only be saved as .dat file -they have no effect on an output .ufs file.

Routes may be either:

1) added,

2) deleted

3) edited (i.e., for currently existing routes)

4) copied and edited to create new routes.

5101396/ May 11 11-68

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

P1X: Interactive Analysis of Results

When added under (1) the new route is defined by using the mouse to identify a
number of “key” junctions along the route (as under the interpolation option
described in 15.18) plus parameters such as a route name and frequency. Each
route thus defined is added to the internal .dat file.

Equally when a route is deleted its records are removed from the internal .dat file.

Editing an existing route (or equally a route which has been copied from an
existing route and renamed) has several sub-options which may be further sub-
divided into: (a) changes to the sequence of nodes which define the route, and (b)
changes to its various properties.

Under (a), the sequence of nodes:

1) The route may be extended at either end by adding new nodes;

2) The route may be shortened by removing nodes at either end;

3) A mid-section of the route may be removed and re-routed via a new set of
nodes

Under (b) the user may redefine, e.g., the text name of the route, its frequency,
etc.

The changes requested under (a) or (b) above are then reflected by changes to
the entries in the .dat file which describe the route. The records in that file may be
either listed to the screen or, as an alternative to (a) and (b) above, they may be
screen edited to introduce the same sort of alterations. (But, BE WARNED, screen
editing may also introduce coding errors which may go undetected!)

A further editing alternative, which sits somewhere between (a) and (b), is to
editing the “timing point” information associated with nodes along the route. See
6.9.5. Again timing points may be added, deleted or modified.

11.9.9 Editing Counts

Counts (whether on links or turns) may be either:

a) Added

c) Deleted

c) Edited.

In addition they may be grouped into “count sets” which may equally be edited as
necessary.

5101396/ May 11 11-69

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

P1X: Interactive Analysis of Results

Under additions new counts are set by (a) pre-selecting either links or turns, (b)
defining the link or turn and (c) defining a “count” (or “counts” if NMCC > 1) whose
units are assumed to be in pcus/hr. This information is then added as a new
record to the internal .dat file under the format required for 77777 data input to
SATNET (section 6.10).

Deletion follows steps (a) and (b) above with the proviso that only links/turns
which already have counts may be deleted, whilst editing also first selects an
existing count but then re-defines the count(s).

At any time the above operations are only applied to the “current” count set which
may be changed (if more than one set already exists) or new count sets may be
created (which then clearly should have new counts added).

Screen editing, using a standard Windows edit box, may also be used to update
entries for the current count set, in which case the new text is inserted directly into
the internal .dat file.

11.9.10 Editing Generalised Cost (MUC) Data

The generalised cost records as held under the 88888 data set records on
network .dat files (see 6.11) are edited using specially created Windows edit
boxes in which the user changes values on screen and the new values are saved
in the internal .dat file. Alternatively changes may be invoked either by screen
editing the full 88888 records or by explicitly setting new values in a single (user
class) line.

11.9.11 Namelist Changes

Menus here allow the various parameters defined under &OPTION and &PARAM
in the network .dat files (see 6.1 and 6.3 respectively) to be modified for output to
a new network .dat file.

By default the changes only apply to the output .dat file, not to the current network
settings within P1X or any output .ufs file. Thus changing a simulation-based
parameter such as LTP will not change the manner in which simulation nodes are
modelled anywhere within P1X. However, post 10.5, the changes may also be
applied internally and would therefore be included on an output .ufs file; a “toggle”
is provided within the relevant P1X banner. This may be useful if, for example,
one wished to change, say, ISTOP before doing a continuation run of SATALL
(9.12.1).

As in Section 6.3 the variables are subdivided into Logical, Integer, Real and
Character.

An “examination” option is also provided to check for any current parameter

settings – or combinations of parameter settings – which are likely to create errors
of some description within SATNET. You are not, however, obliged to change
them.

5101396/ May 11 11-70

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

P1X: Interactive Analysis of Results

11.9.12 Converting Buffer Nodes to Simulation

11.9.12.1 Basic Principles

An existing buffer node may be re-coded as a simulation node such that the
maximum amount of information is taken from the existing buffer network, e.g. the
numbers of the adjacent nodes, the link distances, one-way links etc, and the
minimum additional data supplied by the user.

The buffer nodes to be converted may be selected either: (a) interactively by the
user or (b), post 10.8, an external file may be input containing a list of all nodes to
be converted and their simulation junction type. File input is described further in
11.9.12.4 below.

Under the interactive mode, the user will first be required to define:

♦ a junction type (priority, signalised, etc.);

♦ whether or not link capacity restraint data is to be added by default (new in

10.5);

♦ banned turns;

♦ the number and layout of lanes;

♦ saturation flows (for roundabout arms)

♦ basic stage definitions (signals only)

Once this minimal data is provided further node editing, following standard node
graphics procedures as covered in 11.9.3, may optionally be applied in order to
define, e.g. priority markers, etc.

Note that default values for all the above node properties are set by the program
and, if unchanged, will appear in the output .dat file in the correct positions in the
data records. However it needs to be stressed that the default values are only
“intelligent guesses” at best, e.g. saturation flows are set equal to buffer link
capacities and are probably therefore underestimates. Users are strongly advised
to cross check these values and edit as necessary.

In particular adding link capacity restraint data – which basically reproduces the
buffer link’s speed-flow curve – is seen as a “quick and dirty” technique. It may
lead to a “double counting” and over-estimation of delays if the buffer speed-flow
curve (correctly) took into account junction delays and further junction delays are
introduced by the coding of the new simulation junction. If this option is used it
may be best to initially code the junction as a priority junction with all arms as
“major” arms so that there will be no junction delays (apart from over-capacity

5101396/ May 11 11-71

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

P1X: Interactive Analysis of Results

queues). Using dummy nodes in this situation is not recommended. When the
junction is “properly” coded the link capacity restraint curves should be removed.

At the conclusion of all editing a correctly coded node description will be

incorporated into the internal network direct access file for subsequent dumping
as an external .dat file (11.9.2) (N.B. This is not automatic, it must be requested
as “save this data”.)

This option works by adding the converted buffer node as an “extra” temporary
simulation node at the end of the normal simulation arrays. It may therefore not
be available if the simulation network dimensions are only marginally less than the
maximum provided by your program version. See 15.28. It is not possible to add
new simulation node data into an output .ufs file.

Those buffer nodes which have been converted may be identified on network
plots in that they are assigned a different node type colour from normal buffer
nodes. Thus the node display should have the options for, say, node shapes and
multiple colours turned on.

11.9.12.2 Extra Centroid Connectors

If the buffer node converted to simulation is connected to zones which are not
already connected to simulation nodes (NB: this should be the case since
simulation and buffer connections from the same zone do not “mix well”.) then
extra simulation centroid connector entries for that zone(s) are automatically
created within the 2222 data record segment of the new .dat file. These will be of
the format described under note 4 in section 6.5 where the buffer node is entered
as both A - and B - node.

Note that the new connectors appear only within the .dat file; no changes are
applied to the current map structure arrays which will display the zone and
centroid connectors as though they are still buffer connections, nor are they
deleted from the 33333 data segment. (The latter is not necessary since, once
they appear under the 22222 records, SATNET will ignore any entries from that
zone under the 33333 records.)

11.9.12.3 Extra Node Conversion

It is possible as a result of converting one buffer nodes into a simulation node that
its adjacent nodes will also need to be modified. This works in two ways.

Firstly, if the converted buffer node B is totally “isolated” from any other simulation
nodes than all the buffer nodes which are connected to B must also become
external simulation nodes, in addition to being buffer nodes. However this does
not mean that they needed to be coded within the 11111 records since if the
parameter AUTOX = T (see 15.12) then they will be automatically recognized as
external nodes by SATNET. It is therefore assumed that AUTOX will be T and no
extra entries are added under 11111.

5101396/ May 11 11-72

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

P1X: Interactive Analysis of Results

Secondly, however, if one of the buffer nodes A connected to the new node B is
already an external simulation node, e.g. if A has another neighbour C which is an
internal simulation node as sketched below, and A has no other connections.
Then leaving A as an external simulation node leads to fatal errors in the
assignment network (see 18.8). Under these circumstances A is automatically
converted into a priority node and either added to the 11111 data records or
suitably modified if it already exists there.

11.9.12.4 Buffer Node Conversion from File Input

The set of buffer nodes which are to be converted may also be specified from an
input text file which contains, one record per node, the number (i.e., “name”) of the
buffer node to be converted plus the junction type (e.g., 1 for priority) into which it
is to be converted. The format is free format; i.e., the two entries may be in any
columns as long as they are separated by either a space or a comma.

This option may usefully be combined with the data field editing procedures
described in 11.9.17.

11.9.13 Global Changes to Signals

These options allow changes to be made and saved to all signals as opposed to
changes to individual junctions as under 11.9.3. Options include:

♦ stage time optimisation,

♦ offset optimisation,

♦ re-simulation (following either stage or offset optimisation),

♦ “import/export” of signal timings via .rgs files (i.e., from another network)

♦ direct updates of all stage times and offsets on the .dat file.

These are described in the following sub-sections and in 11.9.14 (.rgs files).

11.9.13.1 Signal Optimisation

Signal optimization includes:

♦ optimising green splits (stage times)

♦ optimising the offsets

5101396/ May 11 11-73

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

P1X: Interactive Analysis of Results

at either all simulation nodes or at a selected subset (see 11.9.13.2) as opposed

to optimising a single set of signals via node editing. Either or both may be
selected in the above order.

Note that a further option then allows for a full network re-simulation since that
may in turn affect the signal optimisation and an iterative loop between
optimisation and simulation may be followed manually which, empirically, appears
to converge reasonably quickly. Note that this is not the same as allowing for a
full re-assignment (plus simulation) of traffic (see 15.31.1) where the feedback
effects may be more severe.

The green-split option follows that described in Section 15.31.2 to calculate and
save optimum green times for every green stage at every signalised node. The
new times are automatically recorded within the internal .dat file (and saved
externally if requested) and will be included within an output .ufs file.

The offset option follows the SATOFF procedures described in 12.2. Note that
the re-simulation loop described above essentially follows the “inner loop” of
Figure 12.2.

11.9.13.2 Signal Optimisation at Selected Nodes

A further option within both green splits and offsets permits optimisation to only be
carried out for selected nodes where the procedures for selecting nodes within
SATDB are described in 11.10.5. Alternatively – and probably very useful in this
context – one could select a subset of nodes by using the cordon procedures
(11.13.3). Thus in very large networks one could mimic the affect of a locally
optimised set of signals.

11.9.13.3 Signal .dat File Updates

Since signal stage times and/or offsets may be updated elsewhere within
SATURN other than P1X, for example, offsets in SATOFF (see 12.2.2) or stage
times and/or offsets in SATALL, but only saved within network .ufs files it is useful
to be able to transfer the new data from a .ufs file into an updated .dat file. The
“update” option simply transfers all current stage times and offsets as read in from
a .ufs file onto the (internal) .dat file, from which they may be later dumped into an
external .dat file. See also 15.31.5.

Note that the same basic operation may also be accomplished by “dumping” a full
.dat file (see 11.4.2) from a .ufs file but the Update operation above is to be
strongly recommended since it preserves the full data structure of the original .dat
file with the sole exception of the stage times and offsets.

A further alternative method to transfer updated signal settings is to make use of

the .rgs files by (a) dumping the settings to a .rgs file from P1X network editing
and then (b) transferring the .rgs file data to any other network. This method is to
be preferred if it is necessary to transfer the same set of optimised signals to more
than one network.

5101396/ May 11 11-74

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

P1X: Interactive Analysis of Results

11.9.14 Signal Transplants: .rgs files

Signal settings, i.e., cycle times, green splits, offsets, etc., may be transferred from
one network to another via “.rgs” files. Thus a file with extension .rgs is firstly
created by “dumping” all the relevant signal setting data from a particular network
- in effect it extracts all the relevant data records from its .dat file. This may either
be done as a “files output” option within P1X or it may be done at the network
build stage within SATNET by setting FREDDY = .TRUE. under &PARAM (See
6.3.1 and 6.4.3). Once created a .rgs file may be read by P1X (only) and its signal
settings used to replace those in the current network. (In a sense a .rgs file is a
bit like a $INCLUDE file in that it includes a specific sub-set of network data.)

Thus, if you have, say, an AM and a PM network which differ only in terms of their
signal settings and you edit the link data in the AM network it is normal to wish to
transfer those same changes into the PM network. This can be accomplished by
simply copying the “new” AM network file into a “new” PM network file, processing
the new PM network through SATNET and then using the signal transplant option
within P1X to copy over the signal settings from the “old” PM network and to
create a new output .dat file for the PM network.

Note that transplanting is only possible if the nodes have the same topology in
both networks. Thus if a node has been re-coded from a 3-arm signalised junction
into a 4-arm the old signal data will no longer be applicable and in this case the
changes will probably best be done “manually”.

The format of .rgs files has been changed in version 10.5 such that the cycle time,
in addition to the offset, is also stored per node. Older versions of .rgs files may
also be read by 10.5 but the converse is not true; i.e., a 10.5 .rgs file cannot be
read by the 10.4 version of P1X.

11.9.15 Comparing Two Networks

The simulation nodes as coded in two networks may be compared data item by
data item and all points of differences established. For example if a node is
identically coded in networks A and B apart from having a different offset in
network B this difference will be detected and the information listed in a table of
differences.

Differences may exist at different “levels”. Thus at the highest level a node in
network A may not exist in network B, in which case clearly it is not possible to
detect any further differences. Lower levels include node data, link data, turn data
and signal data - corresponding roughly to record types 1, 2 and 3 in the
simulation node data formats (6.4.1).

Differences at one level may preclude checking for differences at another level.
For example, if a node exists in both networks but has a different number of arms
it is still feasible to check for differences (such as the offset) on the “node record”
but not for differences between turns.

5101396/ May 11 11-75

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

P1X: Interactive Analysis of Results

11.9.16 Screen Editing

Screen editing in this context allows the user to transfer data directly from the
internal .dat file (by specifying the first line and number of lines) into a standard
Windows edit box where it may be edited as desired and, if saved, replace the
existing data.

Note that the editing here is only applied to the .dat file and is NOT processed by
the program itself. For example, if you add an extra line within the 333 data
records to add an extra buffer link that link will not appear on the plot or be
accessible to buffer link editing. However, by rebuilding the .dat file into a .ufn file
(see 11.9.2) the changes will then be incorporated into the network as viewed on
the screen and indeed screen editing in this context is most usefully applied in
conjunction with rebuilding.

We may further note here a distinction between screen editing the .dat file as a
whole and screen editing individual lines (or collection of lines) as may generally
be done within the specific data editing routines described in Section 11.9.2 to
11.9.10. Thus if you screen edit, e.g., the subset of link counts these are read by
the program and included within its internal “memory”.

11.9.17 Editing “Data Fields” via ASCII Text Files and/or Internal Data Base Columns

11.9.17.1 General Principles

With release 10.8 an extra option has been added whereby data for one particular
“data field”, e.g., the distance per simulation link as recorded within the 11111
data section, may be set “en masse” for any or all simulation links. This differs
from the normal editing of simulation nodes whereby any individual data item
associated with an individual node may be edited; this facility enables one to edit
a single data “field”, e.g., link distance as above, over all simulation nodes. In
effect the editing is “vertical” rather than “horizontal”.

11.9.17.2 Input Data Formats

The data to be added may be defined in one of three formats:

1) from an external ascii file or

2) from an internal data base column, or

3) as a single fixed “universal” value.

In case (1), for example, the input file might consist of a number of records of the
form “A B Distance” so that the value of “Distance” for simulation link A,B would
be recorded in the proper location on the link data record A,B under 11111. This
facility enables data to be transferred en masse from, e.g., external GIS data
bases into SATURN .dat files with minimal user intervention.

5101396/ May 11 11-76

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

P1X: Interactive Analysis of Results

In case (2) the data would be created by manipulation using the standard SATDB
options before it is ready for transfer. For example, to change the cruise speed for
all simulation links with, say, capacity index 5 to 44 kph one would create a new
data column with a global value of 44, then do a link selection by simulation link
AND index 5 and finally transfer that data column into the simulation link field
“time”.

Case (3) might be used, for example, to set the speed on all simulation links (or a
selected subset) to a fixed value, say 45 kph. This method is therefore simpler
than having to set an extra list of all desired links with the attribute 45.

Alternatively, the data may be created by a combination of methods (1) and (2)
whereby “raw” data is read into the internal data base and then manipulated
internally before it is added to the internal .dat file. See below for an example of
how to create turn saturation flows in this way.

The input data files may refer to either simulation nodes, links or turns and their
format must reflect the differences. Thus a node data file would be of the form “N
data1 data2 …” where N is a simulation node number, link data would be of the
form “A B data1 …” and turn data “A B C data …”. In all cases the “data” may
contain several different fields (e.g., link distance, link speed, etc. etc.) and the
user must then define each individual data item in the list.

Similarly node data must be transferred from the SATDB node data base
(11.10.5) but both link and turn data are accessed from the link data base.

11.9.17.3 Data Restrictions

If desired the changes may only be applied to a subset of nodes, links, etc. by
using the standard link or node selection rules within SATDB. This is particularly
useful with the global option, case (3) above, if the single value is not intended to
be applied to be all nodes, etc.

At the present time “data field editing” applies only to 11111 simulation data, e.g.,
not to 33333 buffer data, etc. etc. although it is planned to extend its range of
application in the future.

11.9.17.4 Available Data Fields

For simulation nodes (whether input is from an external or an internal file) the
following data fields may be updated:

♦ Junction type (integer 0 to 5)

♦ Roundabout circle time (seconds)

♦ Roundabout circulating capacity (pcu/hr)

5101396/ May 11 11-77

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

P1X: Interactive Analysis of Results

♦ Signal offset (integer seconds)

♦ Cycle time (LCY) (integer seconds)

♦ Number of time units (NUC) (integer)

♦ GAP – Minimum gap at priority junctions and/or roundabouts (In “real” units of
seconds, not integer tenths of seconds as per normal .dat files)

♦ GAPM – Minimum gap for merges (ditto re units)

Similarly under link editing the following fields may be updated:

♦ Link distance (metres)

♦ Link cruise time (seconds)

♦ Link cruise speed (kph)

♦ Number of lanes

♦ Stacking capacity (pcus)

♦ Capacity Index (as stored on the second link record unlike the first five which
are all on the “main” link record)

For turns the available data fields include:

♦ Saturation flow (pcus/hr)

♦ Turn priority marker (Integer 1 – 12 where 1 = blank, 5 = X (Priority), 6 = F, 7

= X (Signals), 8 = G, 9 = M, 10 = Q, 11/12 = W)

♦ Inside lane (Integer 1 - 7)

♦ Outside lane (Integer 1 – 7)

Note that with some input data fields additional data items within the .dat records
may be updated. For example, if one inputs link lanes and the number of lanes on
a particular link is increased then the last lane entries for each turn on that link are
also increased if appropriate. Equally turn saturation flows are factored to match
any changes in lanes.

5101396/ May 11 11-78

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

P1X: Interactive Analysis of Results

11.9.17.5 Discussion

Note that there are strong similarities within the use of X-Files to input data
directly under SATNET and indeed the same files might be used in either context;
see Section 6.13.

11.10 SATDB: Data Base Facilities

11.10.1 Introduction

The program SATDB brings together many elements of statistical analysis

packages, file editing systems, spread sheets and data bases in ways which are
particularly convenient for the specific task of analysing road networks.
Nowadays it may perhaps be best thought of as a poor man’s version of EXCEL!

The functions within SATDB may be accessed by either running SATDB as a self-
contained program or as a sub-program within P1X. The former is useful for
operations that do not require any graphical network plots or for jobs which are
being run in an essentially batch or off-line mode. When run within P1X there is a
certain overlap of functions; for example select link analysis can be done either
within P1X or SATDB, the main difference being the way in which the choices are
made.

At the heart of SATDB (and, equally, P1X) is the concept of an “internal data
base” which may be thought of as a matrix of rows and columns as illustrated
below:
(link) A B C D1 D2 D3 ...
1 a1 b1 d11 d12
2 a2 b2 c2 d21 d22
...
L

In the case of the “link” data base (as distinguished from the node data base, see
11.10.5) each row corresponds to an “assignment link”, the most basic level of
network definition within SATURN (see 5.5.1). These in turn may be sub-divided
into: simulation links (often referred to as “roads” to distinguish them from links
which correspond to the missing direction of a one-way road:), buffer links,
simulation turns and centroid connectors in both the buffer and simulation
networks. Thus “L”, the total number of rows, represents the total number of
assignment links.

The three “fixed” columns denoted A, B and C above identify links by node
numbers where C is only used in the case of a turn, or for a simulation centroid
connector where the zone is connected to a link. The letter C in front of a number
distinguishes a zone from a “real” node. (See 11.10.4 for more precise
definitions.)

5101396/ May 11 11-79

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

P1X: Interactive Analysis of Results

The remaining data columns D1, D2, etc. are created by the user either by
reading directly from the input .uf* file(s) or by a wide range of alternative options.
For example data column D1 might represent link flows and D2, link times. Hence
entry d 11 would be the flow on link 1, d 12 the time on link 1 etc. A third data
column to represent, say, veh-hrs could be created as the product of columns 1
and 2.

By default the links are ordered such that all centroid connectors come first
followed by simulation links (plus turns) and buffer links. However the order may
be changed such that, for example if one data column contains flows the display is
ordered such that the link(s) with the maximum flow appear at the head of the
display.

Once created the data base may be viewed either interactively from the terminal
screen or “dumped” to an external file. In addition a number of very important
options are provided to select the lines that are displayed, for example you can
choose to look only at data from links whose V/C ratio exceeds 1.1, or only at
simulation turns, etc. etc.

Data is displayed either in an integer format - no decimal - or a “real” format - 2

figures after the decimal. In addition certain data values may be “missing” in
which case they are displayed by an “m”; for example a data field which refers,
say, to simulation turn saturation flows would yield missing values for centroid
connectors. If desired, lines which contain all missing values may be suppressed
in the listings; See 11.10.11.

The basic idea therefore is to give the user complete control over what data is
displayed and the manner in which it is displayed.

An extension to the link-based data described above, introduced in SATURN 9.4,

has been to add an alternative node-based data base in which each row
corresponds to a junction (including zones) and the data columns consist of node
data, for example average delay. In this case the first three “fixed” columns A, B
and C may be reduced to just one, the node or zone number. The subsequent
options available to the node data base closely parallel those available to links.
Section 11.10.5 gives further details.

11.10.2 SATDB Options

To illustrate the available options within SATDB let us look at the options available
from the Master Menu (recognising of course that many more options become
available in turn within the various sub-menus). Further documentation is
contained in the sub-sections noted and within the Help system available
interactively.

1) FILES MENU

This option allows the definition and replacement of (up to 4) input files as
well as printing out basic file parameters (numbers of nodes, etc.). Note that if
the input files have different topologies then links in networks 2 to 4 are

5101396/ May 11 11-80

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

P1X: Interactive Analysis of Results

“matched” to those in network 1 with the same Anode – Bnode so that data
from the same link in multiple networks appears in the same record.
Conversely, if a link in networks 2 to 4 is “unmatched” data for the link can
not be stored in the data base. See also 11.4.1 and 11.6.2.3.

2) ENTER THE LINK SELECTION PROCEDURE

Link selection allows you to control the data that is printed. For example, you
can select only links whose flows exceed 2,000 vph, only simulation turns,
etc., etc. Note that selections made under SATDB apply equally to P1X and
vice-versa; see 11.6.1.

3) CANCEL THE CURRENT LINK SELECTION (I.E., INCLUDE ALL LINKS)

Display all links from now on.

4) READ LINK BASED DATA FROM THE UF FILE(S)

Read data from the input network file(s) which relates to the properties of
“links” (e.g., flows, times, queues, etc.) directly into data columns in the data
base based on DA codes (15.21). The analogous operations under P1X are
described in 11.6.2. Data created by SATDB from within P1X are
automatically displayed.

If the input data is based on a sub-set of the full set of assignment links (e.g.,
simulation link or simulation turn data) then the non-defined links are, by
default, assigned a “missing value” or, alternatively, default values such as
zero may be assigned.

In addition (post 10.8), the input link sub-set may be automatically included
within the “link selection rules”.

5) READ NODE BASED DATA FROM THE UF FILE(S)

Read data from the input network file(s) which relates to the properties of
“nodes” as opposed to “links”, e.g., the cycle time at traffic signals. For a link
A to B the data entry may optionally refer to the property of either node A or
B.

6) READ MISCELLANEOUS DATA INPUT (11.10.6)

The “Special Menu” offers a range of functions for inputting new data columns
from either uf* or other files, including:

♦ Link counts;

♦ Links on bus routes;

♦ Restricted links (i.e., banned or penalised movements);

5101396/ May 11 11-81

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

P1X: Interactive Analysis of Results

♦ Alpha-numeric link names (from a GIS file);

♦ Data read from an external ASCII (.txt) data file.

♦ (XY,Y) co-ordinates for each link’s A- and B- node.

♦ Link costs by iteration as read from a .ufc file (see 15.23).

♦ “Unpacked” link or turn data, e.g., lane allocations

♦ Bus lane flows

7) ASSIGNMENT/TREE BUILDING OPTIONS (11.10.7)

These include:

♦ Trees and/or forests for selected O-D pairs; (see also 11.8.3)

♦ All-or-nothing assignment;

♦ Full multiple route re-assignments;

♦ Select link assignment. (See also 11.8.1);

♦ “One song to the tune of another”.

8) CREATE NEW DATA COLUMNS FROM EXISTING COLUMNS (11.10.8)

This option allows the user to create new data columns, either via an algebraic
expression involving existing data columns or by invoking the time-flow curves
within SATURN to calculate the link times corresponding to flows in an existing
column.

For example to create a new data column which is the sum of, say, columns 1
and 2 the user would type in:

X1 + X2

Very similar procedures are available to create and manipulate new matrices
as described in 10.8.1.

Further options allow data to be “reversed” in the sense that the data for link
A-B appears for link B-A. This in turn allows, for example, the calculation of
two-way link flows from one-way.

9) EXTERNAL DIRECT INPUT AND/OR EDITING

5101396/ May 11 11-82

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

P1X: Interactive Analysis of Results

Essentially an indirect method to “screen edit” the existing data. The user
“dumps” the entire internal data base to a scratch file, temporarily exits from
SATDB in order to use a local edit program to change the scratch file, and
then re-enters SATDB in order to re-read the file and replace the old data
base. (But see Option 15 below.)

10) STATISTICAL ANALYSIS

Two forms of analysis are available: either a univariate analysis of a single

data column (mean, standard deviation, etc) or a comparison of two columns
(mean difference, etc.) Output is normally numerical but graphical options are
available (e.g. scatter plots).

N.B. The statistical facilities within SATURN are essentially basic, e.g. to
calculate the mean difference between modelled flows and counts. If you
want to do more complex statistical operations such as analysis of variance
you are advised to use SATDB to gather together the data you require and
then dump them to an external file for transfer to SPSS or EXCEL for
example.

11) REMOVE ONE (OR ALL) DATA COLUMNS

To reduce the size of the data base: useful, for example, since only a
maximum of six columns may be printed at once.

12) PRINT THE FULL DATA BASE ON THE LINE PRINTER

Spools the full (selected) set of link data records to the LPD file with suitable
column headers and pagination.

13) DUMP THE FULL DATA BASE TO AN ASCII FILE (11.10.9)

Spools the full (selected) set of link data records to an ASCII file. These
outputs differ from those under 12 in that they do not contain column headers
or pagination. These files, edited if desired, may be read back into SATDB
under option 6.

14) BASIC HOUSEKEEPING OF DATA BASE HEADER RECORDS (See

11.10.10)

Each data column has an alpha-numeric title associated with it; these may be
modified as desired. Equally display formats, whether to print/plot or not etc.
may be modified.

15) DISPLAY/EDIT THE DATA BASE ON SCREEN (11.10.11)

This option enters an “edit-like” environment whereby the user may “browse”
through the internal data base with a “window” equal to the terminal screen
which may be moved up or down through the data base. The order of printing

5101396/ May 11 11-83

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

P1X: Interactive Analysis of Results

may also be changed so that, for example, it is “sorted” according to one

column.

A “screen-edit” environment is also provided such that the values stored in

the data base may be altered on screen. To a large extent this renders option
9 above obsolete (except, for example, if multiple edits are to be performed).

16) CREATE A NEW SATURN UF FILE (See 11.10.12)

Having created new data columns within the internal data base you may
preserve this data in a new .ufs file.

17) SATURN GENERAL PARAMETERS MENU

This contains parameters such as the number of lines on the terminal screen
and which do not fit conveniently anywhere else.

18) ENTER THE NODE-BASED DATA BASE (11.10.5)

Or, if you are currently within the node data base, option 18 returns you to the
link data base.

11.10.3 Hints for Using SATDB

We give here a series of brief “hints” for various uses of SATDB which may not be
immediately obvious to new users. Note that all of these are not only available in
SATDB as a free-standing program but also within P1X invoking SATDB as a
sub-module. In addition a number of SATDB-based options are described in
greater depth elsewhere in the documentation; see 15.37.

1) SATDB allows you to create “new” data arrays from the basic data stored on
the input UF file(s). For example, UF files contain link time and distance but
not speed. You may use SATDB to work out link speeds (option 8) and then
“dump” them as part of an “extended” UF file created by the program (option
16). Thus you may set up “customised” UF files to contain special pieces of
data that you need but are not “standard”. See 11.10.12.

2) Furthermore you may make use of the “KEY” options within the standard
SATDB procedure (see Section 14.5) to make the process fully automatic;
i.e., at the end of every SATURN run you would run a standard SATDB
“macro” to create your own extra data arrays.

3) SATDB may also be used in a wide variety of ways to carry out non-
standard modelling steps. For example it has been used to introduce road
user charges into SATURN by taking an output .ufn file from SATNET and
adding user-defined charges (converted to equivalent generalised seconds)
to the relevant DA cost records before running SATALL. Equally SATDB
may be used as a “post processor” to analyse, e.g., total revenue from the

5101396/ May 11 11-84

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

P1X: Interactive Analysis of Results

charges. The SATURN .bat files can be modified to make processes such
as the above fully automatic.

4) Note that when internal SATDB data columns are “dumped” to a UF file then
any missing values (11.10.1) are essentially undefined and must be given a
user-defined default numerical value. Two values in particular are
appropriate: 0 for obvious reasons and -9876 since that value is interpreted
by programs such as P1X to which the new data may be passed as missing
values. Thus if you create a new data array containing counts, say, it is
clearly important that P1X can differentiate between “real” counts and
“default” values; the convention of using -9876 satisfies this requirement.

Generally speaking missing values and/or - 9876 are handled automatically

by the program and the user will be blissfully unaware of them. However in
certain circumstances they may surface unannounced.

5) One of the “create new data column” options allows you to “transfer” data
either from a link to its exit turns or from all turns to a link, e.g., to aggregate
turn data and to store it as link data. Thus one could aggregate primary
stops per turn to produce total primary stops per link, or divide link flow
between its turns. This opens up a range of operations which previously
could only be done by “programming”. See also 11.10.8.

6) SATDB provides the main mechanism within SATURN for the transfer of
network data to and from other suites of programs. Thus option 13 creates
selected data files in standard ASCII format which may be accessed by
other suites, while option 6 permits data input to SATURN. “Other suites”
could encompass not only the obvious example of other transport models
but also GIS models, pollutant dispersion models, etc. See also 11.10.9.

11.10.4 Interpreting SATDB Link Listings

The output listings from SATDB specifying the individual link or turn information in
the first three data columns employ certain conventions which may not be
immediately obvious. Similar listings occur in the output SATNET .lpn files. The
following table illustrates a number of “typical” representations. (The numbers on
the left are included for reference only.)
SIM A / BUF B NODES C
1. C 1 58 ( 1)
2. C 20 ( 48 ) 47
3. C 20 ( 47 ) 48
4. C 20 ( 52 ) 31
5. 27 ( 28 ) C 24
6. 58 1 26
7. 1 58
8. 2 3
9. 6 C 23

5101396/ May 11 11-85

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

P1X: Interactive Analysis of Results

Link 1 corresponds to a centroid connector from zone 1 (C for centroid) to

simulation link 58 to 1 with the traffic appearing at node 58. Here the second 1 is
in brackets since its main purpose is to define the direction of the link. In this
case, since the traffic appears at the UPPER end of the link, that link must be an
external link and node 58 must be an external simulation node. Note that both a
zone and a node have the same numerical “name”, 1.

By contrast link 2 is also a centroid connector into the simulation network but in
this case traffic joins link 48-47 at the node downstream 47 end; this therefore is
an example of a centroid connector to an internal simulation link. Link 3 is
connected to the same “street” but in the opposite direction, so that traffic enters
at node 48. Link 4 is another internal centroid connector in the simulation
network, from the same zone as link 3 but to a different simulation link.

Finally link 5 is an example of a centroid connector going OUT of the simulation

network; in this case it represents traffic leaving internal link 27-28 to zone 24.
Again 28 is in brackets to indicate the direction of the link since the actual point of
departure is assumed to be at node 27.

If you are still confused the diagrams in Section 16.6 may help!

Link 6 corresponds to the turn 58 to 1 to 26 in the simulation network whereas link

7 is the road from 1 to 58 in the simulation network.

Finally link 8 is the link in the buffer network from node 2 to 3 while link 9 is a
centroid connector in the buffer network from node 6 to zone 23.

11.10.5 The SATDB Node Data Base

The node data base within SATDB operates in very much the same fashion as
the link data base with the obvious difference that each row in the data base
corresponds to a node (or zone) and the data columns contain data related to that
node, for example the average delay at that node, total in-bound flow etc. For
obvious reasons the first three standard columns are reduced to a single column
containing the node/zone name.

Technically the set of nodes in the node data base consists of the nodes
represented in the map network, i.e. zones, simulation nodes (all types) and buffer
nodes. Thus simulation nodes are single entries, not “expanded” as in the
assignment network.

Otherwise most of the standard options available to the link data base are
available to the node data base. For example, you may create new data columns
via FORTRAN-style equations on existing columns, carry out basic statistical
analysis, select a sub-set of nodes, etc. One exception is that there are no
assignment-based options since their outputs are essentially link-based.

Note that node selection may also be carried out within the cordoning options
(11.13.3)

5101396/ May 11 11-86

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

P1X: Interactive Analysis of Results

Data input from one or more network files is by selection from a list of named
parameters (delay, flow etc) rather than via DA codes as is the norm with link
data. A much greater range of data parameters apply to simulation as opposed to
buffer nodes, given the extra data both input and modelled at simulation-nodes.
Data for zones is even more limited. Alternatively, as with the link data-base
columns, data may be read from external Ascii files (under Miscellaneous Data
Input in the node master menu).

It is also possible to create node data arrays by aggregating data from the link
data base. For example if you have created a link array of, say, select link
analysis flows, you may create an array in the node data base which adds
together all the link flow entering each node. A choice can be made on to whether
link data for link (A, B) is aggregated at node A or node B; turn data for A-B-C is
always aggregated at node B. See 11.10.8.4.

There are close connections between the creation and manipulation of data within
the SATDB node data base and their display or annotation within P1X (see
11.6.5), in that data created within SATDB may be annotated within P1X. The
system of node selection is common between the two.

11.10.6 Miscellaneous Data Inputs within SATDB

The following options provide various methods for reading “non-standard” link-
based data from the input network file(s) (as opposed to the standard inputs under
option 4) as well as from SATURN GIS files and external data files.

The data read will generally be numerical but in 2 cases below, bus routes and
link names, the data is alphanumeric text. A restricted set of miscellaneous data
inputs is also available within the node data base (11.10.5).

11.10.6.1 Link Counts

The link counts input are those defined on the 77777 network data records (6.10).
In the event of multiple count fields (MCCS>1) then one or all may be input. If
more than one 77777 data set was included one count set or all count sets may
be included. Links for which no counts have been defined are assigned “missing
values”.

11.10.6.2 (Bus) Routes (Alphanumeric)

The user is prompted to choose one route from those coded on the 66666
network data records (6.9); the corresponding route name (N.B. a 4-character
alphanumeric variable, not an integer number) is entered in the next DB column
for all links in the route. All other links are assigned missing values.

No distinction is made here between whether the route is a bus route or not (as
determined by its coded frequency; 6.9.2).

5101396/ May 11 11-87

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

P1X: Interactive Analysis of Results

11.10.6.3 Restricted Links

This option yields the coded link penalty and/or ban data from the 44444 network
data records (6.7) plus the equivalent negative values for bus-only roads or turns
as read from the simulation node data records.

11.10.6.4 Link Names (Alphanumeric)

This option reads the alphanumeric street names as recorded on the network GIS
file (see Appendix Z) for either simulation or buffer links. All other links/turns are
assigned missing values.

11.10.6.5 External ASCII (.txt) Data Files

This option provides the best mechanism within SATURN for importing external
link data sets, e.g., from another suite of programs or - see 11.10.9 - re-importing
SATURN data which has in some way been edited externally. The data in
question is read from an external ASCII (text) file defined by the user, each record
of which identifies an “assignment link” (e.g. road, turn, centroid connector etc;
see 5.5.1) followed by one or more (numerical) data items to be added to new
columns in the data base.

Thus each record consists of two “parts”:

(i) Link identifiers

(ii) One or more data values

with the format for each specified independently.

Optionally part (a), the link identifier, may be dropped so that the file contains only
data, in which case the line number is assumed to equal the correct assignment
link number. This option should be used with some care and almost certainly only
when the data file has been generated by a SATURN program.

Following traditional SATURN conventions, the link identifier may consist of either
2 or 3 (for turns) node numbers in fixed columns plus C’s to identify zones as
explained in 11.10.4, See 11.18.2 for the precise format.

The link data that follows is read in “free format” (although it may of course be in
fixed column blocks as long as each data block is separated from its neighbours
by either a blank or a column). Link data under free format may be either integer
(no decimals) or real (explicit decimal points).

However the node information may also be read as “free format” where each item
is separated from its neighbours by either a blank or a comma (“comma
separated” CSV). Note that if the nodes are in free format the records must either
contain only links (2 nodes) or only turns (3 nodes) and that must be pre-specified
by the user. (Otherwise the program will not know whether the third entry

5101396/ May 11 11-88

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

P1X: Interactive Analysis of Results

represents the C-node of a turn or the first data item). In addition centroid
connectors cannot be identified under free format (at the moment) since a
character C (or Z) cannot be recognized).

Links which are not included within the input data file are either assigned default
data values (e.g. zero) or identified as “missing entries” (see 11.10.1).

Note as well that this option may be used in conjunction with the main menu
option 13 (dump to an ASCII file) to transfer data from SATURN into a file which
may be edited externally and then re-input into SATDB. See 11.10.9.

11.10.6.6 X, Y Co-ordinates

X, Y co-ordinates are read from the input network UF file as originally defined
under the 55555 data records input to SATNET (see 6.8). For all “pure” links in
the SATDB data base (i.e. excluding turns) four columns are created containing
the X co-ordinate of the A-node (first node), the Y co-ordinate of A followed by X
and Y for the B-node.

This option is very useful if one wishes to transfer SATURN data to a GIS system
such as ARC-INFO where the node numbers as used in SATURN have no
significance, but the coordinates do. In these cases the “real” data to be
transferred e.g. flows, is added to extra data columns and the whole data base is
dumped to an external ASCII file (11.10.9).

11.10.6.7 Link Costs by Iteration

These costs are those used by each assignment iteration and saved on the
network .ufc file if SAVEIT = T. See 15.23.

11.10.6.8 (Un) Packed Link and Turn Data

In order to save RAM and reduce the size of UF* files certain integer properties of
simulation links and turns, for example the number of lanes, markers to indicate
bus-only roads, etc, are stored as “packed” variables with 5 or 6 within the same
DA array. The packed values appear meaningless; these two options allow
individual data items to be “unpacked” and entered in individual DB columns.

The full list of items (per turn) which may be unpacked includes:

♦ Priority markers (numerical or characters)

♦ Priority modifiers (numerical or characters)

♦ Shared lane indicators

♦ Bus lane indicators

♦ Nearside, offside and total number of lanes

5101396/ May 11 11-89

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

P1X: Interactive Analysis of Results

♦ Number of green stages

♦ Junction type (e.g., 3 for signals, etc.)

and per link:

♦ Distance

♦ A link capacity restraint marker (0 or 1)

♦ A bus-only road marker (0 or 1)

♦ A lane-mixing marker (0 or 1)

♦ Major/minor (1/0)

♦ Total number of lanes

♦ Merge indicators

♦ Junction type of the downstream or upstream nodes

11.10.6.9 Bus (Lane) Flows

Bus flows in the simulation network may be selected from (up to) 15 sets of
disaggregated definitions. Thus at one level we distinguish bus flows:

♦ in nearside bus lanes;

♦ in offside bus lanes, and

♦ mixed with normal traffic.

Furthermore we may distinguish buses that enter or leave the network at the
upstream end of the link for all three “lane” classifications above, ditto entering or
leaving at the downstream end, and finally traffic on the link itself.

Note that of these only one set - bus flows on the link mixed with normal traffic - is
available elsewhere, either as the bus flow on its own or as a component within
total fixed flows or total (demand) flow.

Further note that all these flows are defined in units of pcu/hr, (not buses per hour)
and are demand flows, not actual.

11.10.7 Re-assignment and Tree Building Options in SATDB

The re-assignment and tree building options within SATDB offer the following
basic facilities. Note that many of these same operations may be done elsewhere
in P1X, mainly under the Analysis options (11.8.3), the main difference being the
methods used to specify the operations and the display.

5101396/ May 11 11-90

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

P1X: Interactive Analysis of Results

A common feature of the following options which involve assigning a trip matrix is
that: (1) the matrix used need not be the original trip matrix file; (2) it may be
multiplied by random factors (a useful option to simulate day-to-day variability,
probably more an academic concern).

11.10.7.1 A Single Tree

A “TREE” refers to the set of shortest routes from one origin to one (or all)
nodes/zones in a network; see 15.26. The user must specify the origin zone
(/node - see below), the destination zone (if a single O-D route is required; else to
all zones/nodes) and the definition of link costs upon which the tree is to be
based. A value of 1.0 is stored in a DB column for all links in the tree, otherwise
0.0.

It is also possible to store DB columns containing the minimum cost from the
origin to (the downstream end of) each link or to “skim” an alternative property,
e.g. distance along a minimum time tree. See 15.27. By definition the minimum
and/or skimmed cost at the origin is always zero.

Destination Trees

Alternatively one may build a single tree into a destination zone, in which case the
tree will consist of the set of all shortest routes from any zone/node in the network
to the nominated destination zone. A destination tree is built only if an origin is not
specified. (If both are specified then the minimum cost O-D route should be the
same whether it is built out of the origin or into the destination; in this case the tree
is always built in an outbound sense.)

5101396/ May 11 11-91

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

P1X: Interactive Analysis of Results

Starting point: Nodes, Links or Zones

With 10.8 it is also possible to define the “root” or “origin” and/or “destination” of a
tree not only at a zone (which is the normal practice with traffic assignment
models) but also at a node or at either end of a link. Thus if one selects a buffer
node B then the tree is built outwards from B with the initial cost at the
origin/buffer node being set equal to zero. (Or, in the case of destination-based
trees, the tree is built into B.)

If a simulation node N is selected the tree starts with zero cost at any of the
expanded assignment nodes at the upstream ends of the exit simulation links;
e.g., from nodes B 1 ,C 1 etc. in Figure 5.2. For a destination-based tree then the
starting (zero cost) points would be the downstream ends of the entry links, e.g.,
A1, B2, etc. in Figure 5.2.

If a link is chosen then, in effect, routes are allowed to begin/end their journeys at
the end of a specific link rather than at a specific assignment node. If an “origin
link” A-B is chosen then the tree is built starting at (possibly) two assignment
network nodes: the node at the downstream end of A-B and also (if the two-way
option has been selected) at the (downstream) assignment node on B-A. If A-B is
a “destination link” then the tree is built inwards to the upstream ends of A-B
and/or B-A. Note that if A-B is a buffer link the start/end assignment nodes are the
same in both cases (i.e., the nodes at either end of the link) but if A-B is simulation
then the precise starting nodes differ since they are defined as expanded
assignment nodes.

However the starting point(s) are defined, they are always nodes within the
assignment network so there is no difference in the tree-building algorithms used.

Loading O-D Trip “Vectors” onto Trees

A further option introduced into 10.8 allows not only a tree to be built (outwards in
the case of origins, inwards in the case of destinations) but also a “vector” of trips
to/from all zones to be loaded “all or nothing” in the reverse direction along the
minimum cost routes. Thus, for an origin, the “vector” is equivalent to a row in an
O-D trip matrix and, for a destination, a column.

Note that the loading can only start at zones, not at nodes or links, although the
“base” of the tree can be either a zone or a node or a link as above. This enables
trips to be loaded to/from points in the network where currently there is no zone
defined, as would be the case (as discussed below) with a new development
which generates/attracts extra trips but is not sited at an existing zone.

In order to invoke this option the “vector” must first be loaded into the SATDB
node data base (11.10.5), i.e., at least one node data column must exist. How this
is done is up to the user; for example they may input using the option to read from
an ascii file which would consist of characters: “C zone trips” (where the C in
column 1 is necessary to identify the number that follows as a zone, not a node).

5101396/ May 11 11-92

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

P1X: Interactive Analysis of Results

Modelling Development Traffic: DEVTRIPS

The option to “load trees” as described above was originally developed in co-
operation with the Greater Manchester Transportation Unit GMTU as part of their
“DEVTRIPS” procedures for modelling the distribution and routing of traffic
generated by relatively small new developments such as supermarkets. Here
SATDB is called (twice) within a much larger modelling framework.

The objective of DEVTRIPS is to give a very quick estimate of the origins and
destinations of the newly generated traffic and the routes used by drivers
travelling to and from the site, given information about the site’s location within the
network and the total number of trips generated by the site. It avoids the need to
add a zone to the network and matrix and, because it assumes that the
development traffic will not significantly affect routing, avoids the need to re-
converge the network – a process that may take several hours given the size of
the Greater Manchester network. The system is designed to be used by those
with little or no modelling expertise to predict, given the creation of a new
“development” (e.g., shopping centre) within a network which will generate a
certain number of new trips to and from the site, where those trips will appear on
the network.

In the first call to SATDB, therefore, the site is used to define the origin for a
single tree build to determine the travel costs from the site to the other the zones
in the network. The procedure is then repeated with a “destination” tree in order to
create a column of costs to the new site. These two sets of costs are then
dumped to an external file which GMTU uses with a catchment area technique to
determine the origin and destination zones of the generated trips, which are then
saved as two columns of data representing the number of trips beginning and
ending in each zone.

In the second call to SATDB the matrix (or columns) of trips generated above is
input to the node database and the tree-build options repeated (twice – both to
and from the site), but this time with the loading option invoked. This will produce
two link data base columns containing the in-bound and out-bound link flows
which may then be added to together to produce the total generated trips per link.
All three flows (or just the totals) may now be dumped as Ascii files and read by
other DEVTRIPS procedures to carry out supplementary analysis of the flows.
Alternatively, the flows can be displayed graphically within P1X by saving the
information in the database as a new UFN/UFS.

11.10.7.2 A Forest of Trees

A “FOREST” is an aggregation of all the trees from a single origin over all internal
assignment iterations, weighted by the fraction of the trip matrix as ultimately
assigned to each iteration. See 15.26.

11.10.7.3 All-or-Nothing Assignment

This option carries out a single all-or-nothing assignment of the trip matrix set next
based on user-set link costs or taken by default to be the generalised costs from

5101396/ May 11 11-93

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

P1X: Interactive Analysis of Results

the input network. (N.B. In the case of a network which has been through an
assignment – the normal situation – the costs will be based on congested travel
times. The all-or-nothing assignment created here will therefore (probably) not be
the same as an all-or-nothing assignment carried out within SATALL – see 7.11.3
– which will have used free-flow travel times.)

In addition this option calculates a “delta” or “gap” function value for the
assignment as defined in 7.1.4 and/or 9.2 by comparing the total cost of travel for
the all-or-nothing assignment with that for the previously assigned flows
(correcting for the presence of “fixed” flows such as buses).

In networks with a simulation component the value calculated is more akin to a

gap value (9.2) since the times input to the generalised cost definition are taken
post simulation, whereas with a pure buffer network the measure is the delta value
as defined in 7.1.4 since all times/costs are post assignment. In either case of
course the assigned flows have been obtained from the assignment.

With multiple user classes the user may select only one of the user classes at a
time and therefore loop over all of them “manually”; there is not, as yet, an option
to automatically loop over all user classes and/or sum all user classes.

11.10.7.4 Full Multiple Route Re-Assignment (SATRAP)

The SATRAP (SATurn ReAssignment Program) duplicates the original

assignment in that it builds the identical trees at each iteration but the trip matrix to
be assigned need not be the same. See also 15.37 for further suggestions for
use.

Further options allow only “part” of each path to be loaded or only “part” of the
matrix.

The former option may be used to model, e.g. cold starts, by specifying that only
the first 1 kilometre of each path is to be loaded in order to produce a set of link
flows from “cold” vehicles. If a link lies between, say, 970 and 1070 metres from
the origin with a limit of 1,000 m then that link’s flow is factored by 0.3. An
alternative option (“warm running”) assigns beyond the first 1 km.

The latter allows a “sub-rectangle” of the full matrix to be assigned either by

specifying upper and lower zone limits for origins and/or destinations or, post 10.7,
by specifying upper and lower sectors. (More complex “selected” assignments
may be obtained by modifying the actual trip matrix to be assigned, e.g. using
MX).

Note that if, in the extreme, the user specifies a single origin zone and a single
destination zone then the loaded trips effectively constitute a forest (15.26). By the
same token specifying a single sector origin and destination provides a form of
sector-to-sector forest which may sometimes provide very useful information.

5101396/ May 11 11-94

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

P1X: Interactive Analysis of Results

11.10.7.5 Select Link Assignment

Select link assignment (SLA) duplicates the original assignment in that it builds
the identical trees at each iteration but the O-D elements are only loaded if their
route goes through certain nodes and/or links. See 11.8.1 for the same functions
specified and displayed graphically (with some extra options) and 15.19 for a
more general description.

If the node-based or “chain” option is selected and a set of nodes A, B, C ...

nominated then an O-D pair is only loaded if its path goes through all nodes A, B,
C ... in that order. For example if A and B define a link then the flows added to the
data base are the flows from only those trips that use AB. Similarly A on its own
defines a node while ABC may define a turn.

Under the “screen line” option O-D pairs are loaded if their route uses ANY one of
the nominated set of links. Typically, but not necessarily, the links form a closed
screen line so that this option picks up all trips crossing that line, the normal use of
the term “screen line”. However any other set of links is allowed, for example a
chain of successive links in order to pick up all trips using all or part of a route or
the set of all links where interviews have been carried out, etc. etc.

The “screen line” may be defined in one of two ways: (i) as the set of all currently
selected links (11.6.1) or (ii) as the set of links within a 77777 input segment of the
original network .dat file. If neither of these two options exist the screen line
option is not available.

An essential difference between the “chain” and “screen line” options is that the
chains use an AND test - the route must go through every node - while the screen
lines (under SATDB) use an OR test - only one crossing is sufficient.

Note that the interactive P1X version of Select Link Assignment allows alternative
options for defining screen lines (11.8.1.9) and alternatives to the simple OR test
above for dealing with multiple crossings (11.8.1.10).

With multiple user classes the analysis may be performed for one particular user
class, for each of the n user classes in turn (in which case n new data columns
and/or n new .ufm matrices are created) or for all user classes summed together
(i.e., one new data column, one .ufm matrix).

11.10.7.6 Turning Flows in the Buffer Network

This option has now been effectively made redundant by the introduction of the
parameter REFFUB which automatically calculates and stores all assigned turning
flows at buffer nodes. Briefly this option calculates the turning flows by
reassignment and enters them in successive data base column such that the first
column entry for a buffer link A,B gives the flow from A,B to the first (nearside) exit
link from B, the next column gives the turning flow to the next (nearside) exit etc,
etc.

5101396/ May 11 11-95

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

P1X: Interactive Analysis of Results

So although all the numbers are there their interpretation within the data base is
less than obvious. Having calculated them however the user may then print out a
matrix of turning flows at selected buffer nodes as may also be done with
SATLOOK (11.11.2) provided REFFUB = T. Best stick with REFFUB and
SATLOOK!

11.10.7.7 One Song to the Tune of Another

This long-time favourite panel game has a slightly different interpretation within
SATDB. Here it enables one trip matrix to be assigned to a network using the
routes calculated on the same network (topologically speaking) but with a different
trip matrix. The main application is in the area of “perturbation assignment” where
one wishes to examine the impact of small matrix changes without having to go
through a full SATURN run and with minimum "noise" (where noise refers to the
well-known phenomenon whereby two extremely similar networks may wind up
with quite large differences due to following two different patterns of
convergence).

The trip matrix to be assigned is nominated by the user with the additional option
of nominating a “GONZO” factor, i.e., a uniform factor which applies to the entire
trip matrix. The assigned flows (which will be “demand” as opposed to “actual”)
are then assigned to the next available column in the data base. Optionally these
flows may then be used to derive new corresponding link travel times (see also
11.10.8) which, however, are not added as an extra data base column but
included in the output file (see below).

As with SATRAP the assignment may either be based on full o-d routes or a
“partial-route” assignment may be carried out.

The assignment may be either “full” or “incremental”. In the latter case the matrix
assigned consists of the differences in o-d flows from the previous network so that
in this case negative trip elements are allowed. (N.B. No explicit check is made
that the sums of the old plus new trip matrix cells do not go negative, although link
flows are prevented from going negative.) If “full” then the fixed flows (if any) are
added explicitly to the assigned flows whereas with “incremental” the fixed flows
are already an implicit part of the base flows which are being incremented.

Finally a new output .ufa network file with the new flows - plus (preferably)
updated assignment travel times - is automatically created by this option. In effect
this operation performs a “pre-assignment” and may usefully be run prior to
SATALL in its “continuation mode”; see 9.12.1.

It may also be seen as an early form of “Warm Start” as described in Section 22.3
with, in this case, topologically identical networks but different trip matrices.

The procedures here overlap considerably with those in SATRAP; the main
distinction is that One Song produces an output .ufa file automatically and adjusts
travel times.

5101396/ May 11 11-96

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

P1X: Interactive Analysis of Results

Note that “One Song” is not particularly useful in re-assigning a trip matrix which
has been obtained by Select Link Analysis (11.8.1.3) since it will not necessarily
re-create the original flows on the selected link(s). Why? Consider a single o-d
pair with 10 trips which uses two routes 50:50, 5 trips on each. If a select link
matrix is created for a link on just one route it will contain 5 trips for that o-d pair.
When that o-d trip element is re-assigned under “One Song” it will be split equally
between the two routes and hence the selected link will only be assigned 2.5 trips,
not the original 5.

11.10.8 Creating New Data Columns

This option allows the user to create new data columns, for example via an
algebraic expression involving existing data columns or by invoking the time-flow
curves within SATURN to calculate the link times corresponding to flows in an
existing column. The basic options are described within the following subsections.

For all basic options the “new” data may either be created in a totally new column
added at the end of the data base or it may over-write an existing column.

In addition the new calculations may be applied to all links within the data base or,
if a selection is in force (11.10.2), only to those currently selected. Further options
then control what happens to the non-selected links; e.g., whether they remain as
they are (in the case of over-writing an existing column), are assigned a default
numerical value or are defined as “missing”.

11.10.8.1 FORTRAN Equations

For example to create a new data column which is the sum of, say, columns 1 and
2 the user would type in:

X1 + X2

Very similar procedures are available to create and manipulate new matrices as
described in 10.8.1; the syntax rules are the same in both cases.

In particular the “non-standard” function GEH which is used to compare link flows
(see 15.6.2) may be calculated directly by a statement such as:

GEH (X1, X2)

11.10.8.2 “Reverse” Directions

These options allow data to be “reversed” in one of three ways. Firstly, the new
data for link A-B may appear as the “old” data for link B-A. Secondly, the new
data column may be the sum of A-B and B-A to allow, for example, the calculation
of two-way link flows from one-way. Finally the new data may be the average of
both directions.

5101396/ May 11 11-97

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

P1X: Interactive Analysis of Results

In either case further options exist as to what action is to taken if a link does not
have a reverse, e.g., if it is a one-way link, or if, for whatever reason, the reverse
exists but the data entry associated with it is “missing”. Thus the non-existent
reverse link can either be considered to have a value of 0.0 or to be considered as
missing.

In the case of summed or averaged data if the “missing” option is chosen then the
new data will also be “missing”; if the 0.0 option is chosen then the reverse data is
always taken as zero such that the sum will simply equal the value (e.g., flow) on
link A-B and the average will be half that value.

11.10.8.3 Calculating Travel Times

A further option calculates link travel times from a column of “flows” based on the
standard assignment time-flow relationships as described in section 5.4. Note
that within the simulation network these calculations are applied to both turns and
links separately. However note that the times are based on the equations as used
by the assignment stage as opposed to being re-simulated. This operation
effectively mimics the “calculate new costs” steps within the assignment
algorithms (7.10.2).

We further note that the nominated column of input flows should be demand
flows, not actual, since the internal routine will automatically factor down the flows
from demand to actual using the appropriate ratios from the input .ufs file.

11.10.8.4 Data Aggregation/Disaggregation

“Aggregation” refers to the process whereby, for example, a turn-based data field
is transferred to links such that the value for link A-B is the sum of all turn values
A-B-C or link values are aggregated to nodes.

By contrast “disaggregation” might associate a data value for link A-B with all its
exit turns A-B-C. For example the travel time on a link may be associated with
each turn at the end of a link and then (separately) added to the turn delays to
produce the total time to make a turn out of its entry link.

In the opposite sense turn properties, e.g. delays, may be associated with the link
from which they have come either by: (1) pure addition, (2) as a flow-weighted
average or (3) as the maximum/minimum value. Option (2) could be used to help
determine an appropriate average turn delay out of a link, while option (3) might
be used to calculate the maximum V/C ratio for a turn and set that as a link
property.

Note that under the node data base link data may be further aggregated into node
properties using either of the 3 options above. Hence turn data might be
aggregated by link and then further aggregated by node. Equally turn data may
also be aggregated directly into node data.

5101396/ May 11 11-98

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

P1X: Interactive Analysis of Results

11.10.8.5 Replacing Missing Values

“Missing values” are used to indicate when a particular data entry for a particular
link does not exist, in the sense, for example, that turning flows are not defined for
centroid connectors. See 11.10.1. In certain situations it is desirable to assign
numerical values instead of missing values, e.g., when doing a numerical link
selection test. Option 6 allows numerical values to be substituted for missing
values in one or more data columns with a choice of the value used.

11.10.8.6 Mark Selected/Non-selected Links

If a selection is in force then this option simply writes one (user-set) numerical
value in all selected links and another value in all non-selected links. Most usually
the values used would be 1 and 0. For example, multiplying a full column of link
flows by a 1/0 column (using 11.10.8.1 and an “equation” such as X1*X2) would
create a data column containing flows for selected links only with zero entries
everywhere else.

11.10.9 Dumping to an ASCII (Text) Data File

The facilities included within option 13 of the Main Menu (Dump the full data base
to an ascii (e.g., .txt) file) allow users to transfer data from the internal data base
to an external ASCII (text) data file for, e.g. transfer to another suite of programs.
They mirror largely the options described under 11.10.6.5 to import data from
external data files. A more automatic batch file to do the same basic job is also
available; see dbdump, 15.46.

(Note as well the existence of Option 9 – External Direct Input and/or Editing –
which also outputs and/or inputs text files but which makes use of so-called “.dbd”
files. These facilities are similar to those under Option 9 but are now largely
redundant since the .dbd file format is a good deal more restrictive and SATURN-
specific than that for basic .txt files and its use is not recommended. The one
advantage of .dbd files is that, if they are dumped from SATDB, edited externally
and re-input, they retain their original “headers”.)

Thus, the output text file consists of one record per network link (with non-selected
links excluded) with each record split into two “parts”.

♦ A link(/turn) identifier

♦ Data values

Options specify how each part is formatted.

At the highest level the format choice is between full formatting into fixed columns
or “free” or “comma separated” CSV formats where each item in both a) and b)
appears separated by commas (best for transmission to spreadsheets such as
EXCEL).

5101396/ May 11 11-99

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

P1X: Interactive Analysis of Results

Under CSV output turns must always be identified by three entries (A, B and C-
nodes) while, strictly speaking, links only require two entries, A and B. However,
since it is generally easier for whichever system is to read the data files to have a
fixed number of entries per record, an option is provided to include a third “blank”
entry for all links; in essence this means that an extra comma is inserted after the
B-node.

At a lower level the link identification may either follow the basic SATURN
conventions described in 11.10.4 and 11.18.2 or they may contain simply two
sequential node numbers as used internally within SATURN (useful for
transferring data to other suites which number nodes sequentially). Within the
data values integer variables appear without decimals, real variables have them.
The precise format of real variables is either as determined under “housekeeping”
(11.10.10) or they may all appear as high precision values using the FORTRAN E-
format.

Further options exist to include or not column headers and/or comment cards at
the head of the output file.

Unlike output to the screen there is effectively no limit to the “width” of each output
record so that up to 24 data columns (the internal limit) may be included in each
record.

The order of the data records is either sorted by link type as is the default within
SATURN (i.e., all centroid connectors either inbound or outbound appear first) or
in strict numerical order by assignment link numbers.

11.10.10 Basic Housekeeping Operations

The housekeeping options enable the user to set a number of parameters

associated with each existing data column:

♦ its DA code;

♦ its (40 character “long”) title;

♦ its print format;

♦ whether displayed within SATDB listings;

♦ whether annotated within P1X plots.

The uses of the DA code are explained further under 11.10.12; basically the code
is only really relevant for output to a new .ufs file.

The title appears at the head of the column listings and in addition to (but not
always) when the data base column number is referenced elsewhere.

5101396/ May 11 11-100

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

P1X: Interactive Analysis of Results

The print format is based on standard FORTRAN conventions and determines:

♦ the “width” of the data, print outs (in terms of the number of characters);

♦ whether it is real or integer (i.e. with or without decimals);

♦ if real, the number of decimals.

Thus F10.2 fixes the output to 10 columns with 2 decimal places after the decimal
point.

The SATDB and P1X displays both toggle each data column between “on” and
“off”. Thus it is possible to exclude data columns from either the text listings within
SATDB or the link annotation within P1X by changing its print/plot status
respectively.

11.10.11 SATDB Screen Display/Edits

If the data base as a whole may be visualised as a (generally) very long rectangle
with one line per link then display mode is equivalent to a window of (typically) 19
lines which may be moved up and down the full rectangle.

Within this window a number of options are provided (as buttons under 32-bit, as
a set of key strokes under 16-bit):

♦ Quit (return)

♦ Up (move the window up 19 lines….

♦ Down (…or down)

♦ Home (move the window to the top

♦ End … or the bottom of the data base)

♦ Search (move the first line of data for a particular node)

♦ Select (Enter the select menu; see 11.10.2)

♦ Order

♦ Parameters

The last two require some extra explanation.

“Order” enables the user to change the vertical order of the links in the printed
data base, for example you may ask for them to be printed in descending order in
terms of the entries in column 2. Thus ordering requires: (a) a column: (b)

5101396/ May 11 11-101

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

P1X: Interactive Analysis of Results

whether descending or ascending and (c) whether based on actual or absolute

values.

Parameters allow the user the choices of whether or not to print lines based on
centroid connectors (or zones under the node data base) and/or lines which
contain all missing values.

11.10.12 Creating a New Output .ufs File

A new .ufs might be created if you have changed the values of some existing
components of the input .ufs file or if you have created totally new data columns
which you wish to preserve permanently.

Thus for each column in the data base the user chooses whether to output or not.
If output it may, potentially, be stored as either assignment links, simulation routes
or simulation turns (see 5.5.1 and 11.10.1). The default is the current “link type”
for that column. Equally each output column may be assigned a new DA code
and/or a new “title”.

Generally speaking data columns which have been read directly from the input
network file and not changed need not be selected for “output” since they will,
however, be copied. If an input data column has been changed it should probably
be output with unchanged "parameters", e.g. the same code and title although the
contents will be different.

Where decisions need to be made is with the output of new columns which have
been created within SATDB; for example you may have applied a formula to
calculate emissions per link and you wish to save those calculations for future
reference. In this case you need to select:

♦ the DA code

♦ choose assignment link/road/turn

♦ set a title (up to 40 characters)

The third choice is straightforward, the second should be obvious from the type of
data (if what you calculated is only defined for simulation turns and all other links
are “missing” choose simulation turns) but the first requires some knowledge of
SATURN.

The general principles of DA codes are explained in 15.21; a list of those already
in use in a particular file may be obtained within Option 4 (link data input) or a full
list of general codes is given in Appendix J. Generally one needs to choose a
non-standard and unused code but also one less than 5003. Recommended /
“reserved” values are in the range 3003 to 3293.

5101396/ May 11 11-102

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

P1X: Interactive Analysis of Results

11.11 SATLOOK: Interactive Text Outputs

The program SATLOOK is used to selectively examine results read from a

SATURN UFS/A file, generally the output UFS file from the full
simulation/assignment loop (e.g. from SATALL). In most cases the same outputs
are also available within other programs in the Suite - for example, summary
statistics from the simulation phase may be printed out by either SATALL or
SATSIM - and/or from elsewhere within P1X; e.g., option 1 is available within
node graphics.

The following menu lists the full set of options available within SATLOOK. Of
these options 1 to 14 only are also directly available within P1X.

1) EXAMINE INDIVIDUAL SIMULATION NODES

2) EXAMINE INDIVIDUAL BUFFER NODES

3) EXAMINE INDIVIDUAL ZONES

4) SIMULATION SUMMARY STATISTICS

5) ASSIGNMENT SUMMARY STATISTICS

6) BUS ROUTE SUMMARIES

7) NETWORK PARAMETERS FOR FILE n

8) ERROR, CONVERGENCE AND CPU SUMMARIES

9) SKIM FORESTS

10) PRINT COMPLETE SIMULATION NODE DATA

11) PRINT ALL ASSIGNED FLOWS AND TIMES ON THE LP

12) PRINT ALL OVER-CAPACITY LINKS

13) COMPARE MODELLED FLOWS WITH INPUT COUNTS

14) MINIMUM COST TREES AND/OR MATRICES

15) TAKE A JOY RIDE THROUGH THE NETWORK

16) GENERATE AN INTER-ZONAL CROW-FLY DISTANCE MATRIX

17) COMPARE TWO ARRAYS ELEMENT BY ELEMENT

18) COMPARE TWO FILES ELEMENT BY ELEMENT

5101396/ May 11 11-103

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

P1X: Interactive Analysis of Results

19) LOOK DIRECTLY AT ELEMENTS ON UF FILE 1

20) COMPARE THE SIMULATION CODING BETWEEN NETWORKS 1

AND 2

The majority of these options and the menus therein are felt to be sufficiently self-
explanatory that no further detailed documentation is required here. However
some further notes are provided for specific options.

11.11.1 Simulation Nodes

This option re-simulates the selected node and allows full access to information as
to how the simulation of delays, queues etc has progressed. For example one
may view full cyclical flow profiles (8.1), albeit in a somewhat dated computational
format, as well as full information on flows, queues, emissions, etc.

See Section 17.7 for an explanation of the tabulated delay plus flow data (option
2) and section 8.7 for a description of the lane choice output (option 12).

A new option in 10.5 prints the delays for each turning movement broken down
into its constituent components listed in 8.4.1 (i.e., fixed delay (TDEL), transient
(CFP) delay, random delay, circulating time at roundabouts and over-capacity
delay).

Further options include the ability to print delay and flow data (table 2) either as
originally constituted (if the node has been edited) or as contained in a second
input network file for comparison purposes. A further option involving data from
network 2 prints a full set of differences in the coding for that node between
networks 1 and 2 (introduced in 10.9). See 11.11.18 for the same option over all
simulation nodes.

Release 10.9 includes an option to list the standard simulation and/or simulation-
assignment convergence statistics per node/link/turn; see 9.9.1.2.

In using SATLOOK to examine simulation nodes users may notice either slight
inconsistencies in the outputs (e.g., OUT flows in excess of the ACCEPT flows) or,
e.g., slightly different capacities from those printed elsewhere. These problems
are due to a lack of convergence in the simulation of that particular node since
SATLOOK actually creates the data by re-simulating the node. However, such
discrepancies should be small in virtually all cases; if not please notify DVV.

11.11.2 Buffer Nodes

Output, having selected a buffer node, consists of two standard tables giving
times, distances, flows etc for all buffer links into and out of that buffer node. See
also 11.8.4.2.

In addition, if REFFUB = T, it is possible to print all turning flows at that buffer

node as assigned within SATALL either to the .LPL file or to an external text file.

5101396/ May 11 11-104

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

P1X: Interactive Analysis of Results

The turning flows may either be in a “matrix format” for all in and out links at a
particular buffer node or one record per every possible turn in the buffer network
in format A-B-C-Flow.

11.11.3 Zonal Information

Select a zone and (fairly limited) data on entry and exit flows plus times and
distances (often zero) are displayed. See also 11.8.4.2.

11.11.4 Simulation/Buffer Summary Statistics

This option prints network summary statistics, e.g. total pcu-hrs, pcu-kms etc, for
both the simulation and simulation plus buffer networks. See Sections 17.8 and
17.9 for an explanation of the tabulated data which is output.

Note that these figures may be obtained in three basic ways:

1) Using the aggregate data calculated within SATALL (or

SATSIM/SATEASY) and stored on the .ufs file;

2) Calculating the same totals explicitly here from, e.g. the basic flow and
time/distance per link arrays.

3) Using data from the .ufs file but not just taken from the “final” loop of the
assignment-simulation loops but, e.g., averaged over the final 4, from a
single previous loop, etc. See 17.9.

Note that both options 1 and 2 print more “tables” than option 3 (which basically
just reports the combined simulation and buffer total statistics as documented in
Section 17.9), although there should be more than enough numbers to keep most
users happy!

Summary Statistics by Sub-Networks

For full network statistics the first two (as well as “final” results from method 3)
should give the same results (allowing for possible rounding errors). However the
second method may also be applied to sub-networks as defined using the link or
node selection facilities within P1X and/or SATDB (11.6.1). One interesting
application of the latter is to use the cordon facilities within P1X (11.13) to define a
sub-network whose links are selected and then using this option to obtain
summary statistics for that particular area. Another is to use the node-based
selection to produce statistics for, say, all signalized junctions.

Disaggregated Summary Statistics

With all options the outputs may optionally be disaggregated over Capacity
Indices (if they exist within the network; see 5.1.9). E,g., you may obtain total
pcu-hrs by all links which have a Capacity index of 1, 2, 3 etc. etc. (N.B. the

5101396/ May 11 11-105

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

P1X: Interactive Analysis of Results

Capacity Index of a turn A-B-C is considered to be the Index of the entry link A-B.
All links without a Capacity Index are judged to have an Index 0.)

However, it is also possible with option 2 to disaggregate the outputs by any

integer link variable defined within the SATDB link data base. For example, to
disaggregate output statistics into “traffic boroughs” it is first necessary to create a
link data base column containing integer Traffic Borough numbers (e.g., by
inputting an ascii file of the form A B Ntb where link A-B is “in” Traffic Borough
Ntb). Then select the menu option for Disaggregation by Data Base Column and
the appropriate column.

Further notes: It is not always easy to specify a data base column as integer
since the default, e.g., from text file input, is to assume “real” (decimalised) values
with a DA code ending in 3. It may therefore be necessary to use Housekeeping
to change a column header from 3 into 4.

Furthermore these options are not available within “pure” SATLOOK, only within
P1X where the facilities within SATDB and SATLOOK may both be invoked
together.

Output .CSV Summary Statistic (Headline) Files

Post 10.8 an option exists to output the full (“headline”) set of summary statistics
as a text file in CSV format. Each record corresponds to a different set of flows
and/or a different level of disaggregation as above.

11.11.5 Assignment Summary Statistics

These statistics provide measures of total pcu-hrs, pcu-kms, pcu-pence (using the
values of PPM and PPK at face value to define “pence”) and an average speed for
links in the “assignment network” which, see 5.1, includes all centroid connector,
simulation links and turns plus buffer links.

To a large extent these duplicate the numbers given by the simulation / buffer
summary statistics (11.11.4). However, since the latter also includes buffer totals
and differentiates between travel within the time period and beyond -which the
assignment statistics do not -, the assignment statistics option is somewhat
redundant; the simulation statistics should be more useful as well as being more
precisely defined. The assignment statistics do however include data on trips
crossing the simulation/buffer cordon which the simulation statistics do not.

11.11.6 Bus Summary Statistics

These statistics trace each bus route and sum total travel times and distances -
disaggregated into buffer and simulation (and further disaggregated into road and
junction times). These are split by company (if used).

Appropriate summary statistics, plus disaggregations by company, are provided.

Note that these are in units of, e.g. bus-kms as opposed to pcu-kms so they may

5101396/ May 11 11-106

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

P1X: Interactive Analysis of Results

appear to differ from, e.g., simulation summary statistics which are based on pcu
flows.

Figures on the number of buses and bus-kms lost due to over-capacity queued
junctions in the simulation network are also calculated.

The over-capacity queuing referred to here relates ONLY to permanent queues

when V > C on a simulated turn and the bus frequency will be reduced
downstream from the queue. The % quoted is effectively calculated at the end of
the route so if, say, 10 buses per hour is the frequency at the start of the route
but, due to permanent queues anywhere along the route, the frequency at the far
end is down to 7 per hour then the queue reduction would be 30%. So that figure
does not depend on whether, say, the queue was on the first or the last link.

By contrast the bus-kms lost also refers to V>C queues but does depend on
exactly where the queue occurs since it sums up bus-kms downstream of the
queue up to the end of the route. So a 30% reduction on the first link in a route
would lead to many more bus-km lost than the same reduction on the final link.

11.11.7 Network Information

Network information lists, for any one of the input network files, information such
as which program created that file and when, the file names of any associated
files such as the trip matrix, basic network dimensions (number of nodes, links
etc) plus values for most of the parameter values set on the input network .dat file
within SATNET.

It also includes selected output parameters, in particular for elastic assignment the
empirical estimates of the elasticities (7.7.5).

The same information may also be obtained within P1X under “Information” - see
11.8.5.

11.11.8 Convergence, Error, Assignment and Cpu Summaries

These statistics may be divided into (up to) six sub-sections:

1) Error statistics listing the number of semi-fatal and non-fatal errors, serious
warnings and warnings (see 2.9) which occurred in SATNET and each
iteration of the assignment/simulation loops (independent of whether those
loops were within SATALL or part of a SATSIM/SATEASY loop).

2) Two tables of convergence statistics from the assignment /simulation loops:

effectively the same table which appears in the SATALL .lpt file and is
described in 9.2, plus that described in 9.9.1.1.

3) Cpu times as recorded with SATNET and as totalled over all assignments
and simulations. Note that “cpu time” is not a strictly accurate term as what

5101396/ May 11 11-107

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

P1X: Interactive Analysis of Results

is measured is actually elapsed time from the start to finish of an operation.

In a multi-tasking environment the two may be quite different.

4) Epsilon-2 statistics describing the degree of congestion in the network; see

7.2.6.

5) Supply elasticities (post 10.4) for the network as a whole; see 7.11.11.

6) SAVEIT accuracy statistics – see 11.8.4.7 and 15.23.2.

11.11.9 Skimming Forests

The procedures here extend those in 11.11.14 by taking average skims over a
forest of trees rather than over a single route tree (See 15.27.3). Two basic
options are available.

The first option allows the definition of the “quantity” which is to be skimmed (as
opposed to the “cost” used to build the forest which is, by definition, the cost used
by the assignment). By default the skimmed quantity is also the generalized cost
as used within the assignment such that the output matrix gives the average costs
of O-D travel as generated by the assignment. By defining a different quantity to
be skimmed, e.g., time, it is possible to obtain the matrix of O-D times averaged
over all used routes.

The second controls the output mode: by default output is to a .ufm file but it is
also possible to output the o-d skimmed data as ASCII text files, specifically in one
of the three standard formats required by the UK evaluation program Tuba (as
used by the SATURN procedure SATTUBA, see 15.41). Within text files there are
additional sub-options, e.g., to control the number of decimal places used.

Note that the default values for, e.g., output mode, may be user-set by making
changes to the preferences file, satlook0.dat.

11.11.10 Complete Simulation Node Data

This procedure prints selected simulation node data similar to that available under
11.11.1 to either (optionally) the line printer or the terminal. Data may be listed for
all simulation nodes or a subset, e.g. traffic signals only.

11.11.11 Assigned Flows and Times to the LP

This duplicates the print options in SATEASY (PRINTF=T) by printing the

assigned flows and travel times on all assignment links. The link listings are as
described in 11.10.4. Travel times/delays on simulation links/turns are as
calculated by the final simulation.

5101396/ May 11 11-108

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

P1X: Interactive Analysis of Results

11.11.12 Printing Over-Capacity Links

This is a good example of an “inflexible” listing in that it prints all those links (and
turns) where the volume exceeds the capacity as opposed to the more “flexible”
listings which may be obtained using SATDB where it is possible to print all links
where, e.g., the V/C ratio is greater than 1.2.

The listings are disaggregated into simulation and buffer links with (which is more
awkward in SATDB) suitable summary statistics printed.

11.11.13 Comparing Modelled Flows with Input Counts

This option compares the modelled assignment flows with those input on the
77777 network data input records (6.10). It mirrors the procedures under P1X
Validation; see 11.7.1 for full details.

The comparison statistics appear both on the screen and in the .LP files while a
further option allows them to be output in a “headline” format (i.e., one record per
count in .CSV format) to a separate file.

One point of difference between count comparisons in SATLOOK and P1X is that
in SATLOOK it is possible to alternatively read the count data from an input text
(ASCII) file rather than relying only on the original 77777 records. At the moment
this is not yet possible within P1X.

11.11.14 Minimum Cost Trees and/or Matrices

The tree information as provided here is partially redundant and, for simple
analysis and network validation, is much more conveniently catered for by the
pure graphics displays in PIX; see 11.8.3.

On the other hand this routine still provides the main mechanism by which
minimum cost and/or (simple) skimmed matrices may be obtained. See 15.27 for
a full explanation of the processes involved and the terminology used. For
example this option is used by the SATCOST procedure (15.27.4) to generate
minimum-cost O-D matrices.

N.B. The skimming facilities within this option must be treated with some caution;
see the warnings in 15.27.6.

11.11.15 Joy Rides in SATLOOK

Again, the purely numerical Joy Ride options within SATLOOK mirror (and pre-
date) the graphical routines in PIX (see 11.8.2) and are therefore largely
redundant. They do not, for example, allow the joy ride to be specified by non-
adjacent nodes with the intermediate nodes being interpolated as may be done
graphically.

5101396/ May 11 11-109

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

P1X: Interactive Analysis of Results

11.11.16 Interzonal Crow Fly Distance Matrix

This uses the input XY co-ordinate data to calculate the distance (in metres)
between each pair of zones using the Euclidean or crow-fly, distance. These are
then output to a .ufm file.

One possible application would be to calculate a crow-fly average speed by

calculating the actual travel time matrix and then using MX to divide one by the
other (with a suitable correction factor to account for units). Another might be to
take the ratio of actual travel distance to crow-fly again using MX.

11.11.17 Direct Access Array Manipulation in SATLOOK

The role of the Dirck Access (DA) file structure within SATURN is explained within
15.21 and the role of the four DA-programs based on them are described in 12.3
to 12.5. The SATLOOK options provide very similar functions to those in
DALOOK etc and are intended primarily for the use of developers. They are only
available within SATLOOK as a freestanding program, not within PIX.

11.11.18 Comparison of Simulation Node Coding

This option (first introduced in 10.9) compares the simulation coding at each
individual simulation node and prints a list of all nodes with differences between
the two; e.g., differences in the signal timings between the two networks. This is
very often useful for finding out what differences have been introduced in an
updated network, particularly if standards of documentation are not as good as
they should be!

The list of nodes numbers may be extended to a complete list of specific

differences, e.g., that two nodes differ only in terms of the distance coded for one
specific A-node.

Note that the differences listed are not necessarily comprehensive but stop at the
first “level of differences” encountered. For example, if the node coded in network
2 has 4 arms as opposed to 3 in network 1 then the listings only record that fact,
not that a link from a common A-node has different distances.

The same comparison data may also be displayed for individual nodes – see
11.11.1. See also 11.6.5.4 where similar information is provided under Node
Highlighting.

11.12 Node Editing and Graphical Display (SATED)

Simplified junction diagrams for simulation nodes may be displayed within P1X or
(historically) via the distinct program, SATED. However, as a distinct program,
SATED was effectively discontinued from 9.5 onwards and removed totally with
the release of 10.9 in 2009.

5101396/ May 11 11-110

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

P1X: Interactive Analysis of Results

11.12.1 Choice of Nodes

Within P1X the junction-display functions may be accessed either as “Node

Graphics” from the P1X master menu or, with slightly extended functions, through
the Network Editing routines. In the former case the emphasis is essentially on
the display of properties of simulation nodes (e.g. lane structure, simulated
delays, etc) as currently defined on the input .ufs file while in the latter the
emphasis is on altering the input properties such as the lane structure in order to
change the .dat file (see 11.9.3).

Within the main P1X menu nodes may be selected:

(1) using the mouse to select from the current network plot (click on mouse in the
banner and then “single-click” on the node);

(2) by numerically inputting the node number,

(3) by directly “double-clicking” on a node in the current plot (without a prior

choice from the banner) or

(4) by looping over all currently selected nodes.

The last option is particularly useful if the user wishes to look at all nodes with a
particular property in common, for example they may all have the same coding
error.

In addition, if you are already in node graphics (main menu), you can move to an
adjacent node by left-clicking on its node number.

11.12.2 Node Graphics Displays

Individual simulation junctions may be displayed graphically as a line-based

junction diagram occupying the full screen as illustrated below.

5101396/ May 11 11-111

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

P1X: Interactive Analysis of Results

Thus at the centre of the plot is a diagrammatic representation of the junction with
the lanes and turn markers on each arm displayed approximately to scale
assuming that each lane is 3.75 m and that the distance to the end of each arm as
shown is 40 m.

A flared lane, either nearside or offside, is represented by an extra lane at the stop
line which is terminated at a representative distance back – where
“representative” implies halfway for a flare length of two PCUs, increasing up to ¾
of the length of the arm as the flare tends to infinity or to ¼ as it tends to zero.

If, as in the illustration above, the junction is signalized each entry arm has a stop
line included; at priority junctions major arms do not have a stop line, minor do.

Permitted turning movements per lane are represented by arrows within the lane,
generally coloured green but with the convention that: (a) turns with a priority
marker X are in red, (b) filter turns (F) are orange and (c) merges (M) are light red.

Along each entry arm a “kerb line” is plotted in light gray while the background of
each “block” is filled in dark gray; both are optional as are the colours used.

In this example V/C ratios (as %) have been annotated for each turn with arrows
to indicate which turns are which.

The street names are obtained from an input GIS file as the “name” of the junction
(lower left, main plot). The junction number is given lower right.

Links which are blocking back, either into or out of the central node, are indicated
by red bars across the entry/exit link with the “space” in the centre of the bar
indicating how much of the capacity is left after blocking back has been applied.

5101396/ May 11 11-112

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

P1X: Interactive Analysis of Results

For example, if a link is severely blocking back such that it has a blocking back
factor of 0.2 – an 80% reduction in capacity – 80% of the bar will be red with 20%
blank in the middle.

At the top left hand corner the three sub-boxes represent the three stages of the
signals with the green movements in each stage depicted by a green “tubie”
arrow. In each box the number in the lower left is the (coded) green time and in
the lower right, the inter-green. The signal offset is written upper left in the first
box.

The numbers given upper right in each stage box represent the “factored stage
times” which differ from the “coded” green times since - in this particular case - the
cycle time has been set to 60 seconds but the sum of all the input green and inter-
green times is 90 seconds. Hence the stage green times are factored down such
that they sum along with the (unfactored) inter-greens to 60 seconds.

The banner (which in this case has been generated by “A-Z” as opposed to the
more normal list of available options) briefly summarises the contents of the plot.

11.12.3 Display Options

The ‘top’ banner or menu permits the following display options:

♦ Modify general display parameters, e.g. whether lane markings are included,
their width, etc.;

♦ Data displayed, e.g. turning volumes, general tables of link data; and its
“mode” (arrows, tubies, etc.);

♦ Animation option; e.g. to display signal stage sequences or the progression of

queues throughout the cycle or to carry out a microsimulation demonstration
run of the node using DRACULA (see also 11.13.8);

♦ Print a summary table within the banner of the most important properties of
that node (“Information”);

♦ Print standard tables of node data such as appear in SATLOOK using either
a text or window-based mode, including “table 2” (flows and delays) as a
standard option plus the last table displayed as a further explicit menu option;

♦ To “print” the node description as it would appear within a network .dat file
input to SATNET; see 6.4;

♦ Editing options; * see 11.12.4;

* (N.B. Within P1X node editing when accessed via “node graphics” is largely experimental in that
the changes are not saved; if you wish to save these changes on either a .ufs or .dat file you must
enter via network editing; see 11.9.3).

5101396/ May 11 11-113

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

P1X: Interactive Analysis of Results

♦ Re-define graphical system and/or device properties;

♦ Shift to another node, numerically either the next node up or down, or use the
mouse to “point” to a node at the end of an arm;

♦ Plot to other devices - bitmap files or to an alternative device;

♦ Display an “A-Z banner” detailing what is currently being displayed; see

11.15.

11.12.4 Node Editing (P1X)

P1X allows users to edit existing nodes in essentially two ways:

♦ They may interactively change data associated with existing simulation

junctions in a SATURN UFS file and examine their impact by re-simulating
that node in isolation.

♦ They may convert a buffer node as read from an input UFS file into a
simulation node.

Having edited one or more junction properties the node may be “re-simulated” and
the effect of the changes evaluated.

Note that in the “display mode” – as opposed to the “network editing mode”
(11.9.3) – any changes to node properties are not permanently stored in, e.g., a
network .dat file although they are stored temporarily. The menus, however, are
virtually identical.

The data to be edited may be selected in one of two basic “modes”. Thus,
originally, all choices were made through a series of banner menus such that if
one wanted to change, say, the distance on a particular link one would first select
“Link Data”, then nominate the link, then nominate distance and input the new
length.

Alternatively, post 10.9.20, the same operation may be affected by clicking a

“target box” at the end of an arm to select that link for editing and then clicking on
either Record 1 or Record 2 for that link in order to alter any of the standard basic
link properties such as distance, speed, number of lanes etc. using a standard
Windows “edit box”, or, equally, by clicking on a target box at the end of an exit
arm in order to edit turning properties such as saturation flow, lane choice etc. for
a particular turning movement..

11.12.5 Applications of Node Editing

Node editing is intended to be used in the following ways:

5101396/ May 11 11-114

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

P1X: Interactive Analysis of Results

♦ Network calibration, whereby the user can determine interactively the most
appropriate data values for an individual junction. For example the user might
wish to examine a change to the saturation flow for an individual turn or to its
lane structure, etc., etc. An alternative procedure to (1) would be to make the
changes in the basic network DAT file input to SATNET, re-run the entire set
of SATURN programs and examine the effect of the changes - a somewhat
cumbersome and potentially expensive operation. Using node editing effects
can be seen immediately. The difference between editing a single node and a
full SATURN run is that editing does not allow for any re-assignment in
response to the changes; the flows remain at their assigned values (although
it is also possible to investigate the impact of changing the flows on a
particular link or turn).

♦ User “education”, by which I mean that the user can experiment with, e.g.,
different values of gap acceptances to see the effect that changes to a
variable have on results.

♦ Interactive data input.

♦ Simulation, testing and design of individual junctions without the need to go

through the full SATURN procedures. In this way SATURN can be used as a
simulation model of isolated junctions, i.e., with its assignment capabilities
totally removed.

♦ To aid in the conversion of networks coded as buffer networks into simulation

networks. The relevant buffer link based data is extracted from the UFS file
while the additional junction-based data is input interactively. (See also
11.9.11)

11.13 Graphical Network Cordoning

11.13.1 General Principles

The cordon options within P1X duplicate most of the functions available within
SATCH (see 12.1); but in addition and more importantly assist the user to define a
“water-tight” cordon interactively specifying a set of “cut links” surrounding an area
of network. The cordon thus defined may be “dumped” into a control file as
required by SATCH.

The first menu within the cordon procedures specifies the cordon which may be
defined in five ways. The cut links may be defined either link-by-link, by “cut lines”
which join successive points and select the links they cross or by a rectangular
“box” which cuts selected links. It may also be set by a previously prepared
SATCH-input control file or via a “spine” - see 11.13.5. In either case the existing
set of cut links may be “edited” by either addition or deletion.

The next step in the definition is to nominate an “inside” node which is used to
distinguish the inside of the cordon from the outside; see the parameter MIDDLE
described in note 1 in 12.1.4. A “tree” is then built outwards from that node in

5101396/ May 11 11-115

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

P1X: Interactive Analysis of Results

order to identify those nodes which are “inside” the cordon. The links which are
used in that tree are highlighted for information purposes only.

11.13.2 Cordoning Sub-Options

Having fully cordoned off a sub-area of the network the following sub-options
become available.

♦ Cordon corrections which checks for redundant links in the cordon,

♦ (i.e., those which are either totally inside or totally outside the cordon) and
removes them. If there are none no changes are made. The number of such
errors is reported in the banner.

♦ Further editing of the cordon, e.g. to add extra links to “plug” any holes.

♦ Output a control file for input to SATCH; see 12.1.3.

♦ Produce a network .dat file for the cordoned area suitable for input to
SATNET (analogous to DONET in SATCH).

♦ Produce a .ufm trip matrix and/or print the matrix for the cordoned network
based on the routes used in the full network (analogous to DOMAT in
SATCH); see 11.13.6.

5101396/ May 11 11-116

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

P1X: Interactive Analysis of Results

♦ Produce a file specifying the assigned route flows inside the cordoned
network as per SATPIG (see 12.6); see 11.13.7.

♦ Run a short demonstration of DRACULA on the cordoned network. (11.13.8)

♦ Define capacity indices within the cordoned network (11.13.4).

♦ Use the cordon to “select” either those links and/or nodes inside or outside for
further analysis with P1X; see 11.13.3.

♦ If there are “holes” in the cordon the “tree trace” helps to detect them by
tracing a path from “outside” to “inside”. Return via the edit option to correct
the cordon.

It is recommended that the cordon correction option be run (if necessary) prior to
any output files being produced as there may be spurious zones created at the
redundant links. Equally the options to create matrices, route files etc. will not
function if there are any errors in the cordon definition.

Note that if both a cordoned network file and a trip matrix are created it should be
feasible to do a full run of SATURN on the sub-network without any further
intermediate steps. However please note the cautionary advice in Section 12.1.4
that the logic of the cordoning procedures may not be 100% fool-proof with
respect to, e.g., bus route definitions, so that some manual editing and cross-
checking may be necessary.

11.13.3 Link-Node Selection via the Cordon

Cordoning may be used to select links and/or nodes which lie either:

♦ inside the cordon

♦ on the cordon itself

♦ outside the cordon

Both links and nodes are selected for both P1X display (11.6.1) and for
analysis/display within SATDB (11.11.4). The set of selected nodes may also be
used within signal optimisation (11.9.13.1).

11.13.4 Setting Capacity Indices via the Cordon

Cordoning may be used to define capacity indices for those links which lie either:

♦ inside the cordon

♦ on the cordon itself

5101396/ May 11 11-117

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

P1X: Interactive Analysis of Results

♦ outside the cordon

The indices may or may not be extended to include turns and/or centroid
connectors which are, say, inside.

11.13.5 Cordons defined by a “Spine”

Cordons in P1X may also be defined via a “spine” which consists of a series of
consecutive links (in effect a “route” and selected as such ) and the cordon cut
links consist of all those links which enter or leave the spine. The most common
example of a spine is a section of motorway with the cut links corresponding to all
exit and entry ramps along that section.

The most common application of a cordon spine is to produce and print a trip
matrix which therefore gives the table of all entry/exit movements within that
section from the existing assignment.

Spines in P1X are closely related to the SPINE parameter in SATCH (see note 6
in 12.1.4) but extend the idea such that in P1X the spine may be defined by more
than 2 nodes so that the spine can “go around corners”.

11.13.6 Cordoned Trip Matrices

The cordoned trip matrix (or matrices in the case of multiple user classes) is
calculated by tracing all routes in the original network and recording all trips from
their entry point to their exit and/or internal zones. The matrix thus obtained may
optionally be output as a .ufm matrix or (new with 10.3) printed to a window.

The matrix may be based on either demand flows (which take no account of trips
caught in over-capacity queues upstream of entering the cordon) or actual flows
(which do).

In addition the matrix may be “Furnessed” (see 12.1.7) such that any errors in the
stored O-D routes are corrected and the input and output flows at the new zones
created at the cut points are matched exactly to the assigned flows.

11.13.7 Routes File Output

A “routes file” for the cordoned area may be output using the standard “.trp” format
as required by DRACULA. This therefore duplicates the function of SATPIG,
except that here the routes and associated flows are only those as used within the
cordoned area whereas SATPIG operates over a full network.

11.13.8 DRACULA Demonstration

By dumping a cordoned network .net file and the corresponding route file (.trp)
into standard files with the formats required by DRACULA it is possible to run a
short demonstration of the DRACULA micro-simulation model for the cordoned

5101396/ May 11 11-118

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

P1X: Interactive Analysis of Results

area. This option utilises both the “network output” and “routes files output”
options to generate the minimum data files required for a run of DRACULA.

A similar option, but for a single node in isolation, is also available through node
graphics animation (11.12.3).

11.14 Pure Matrix Graphics

These routines - which are in fact referenced from the top menu in P1X as
opposed to being part of the network-based display options - produce a (limited)
number of pure matrix graphical displays such as frequency distributions which
have no connection with the spatial location of the zones. Spatial display of
matrices is described in 11.6.7.

The pure matrix graphics essentially duplicate functions which are also contained
within MX and we refer to section 10.12 for further information.

As mentioned in 11.4.1 P1X can handle up to three input matrix files; any of these
may provide the data-base for the graphical displays.

11.15 Convergence Statistics

The “Convergence” sub-menu provides a number of tables which indicate not only
the levels of convergence achieved both within the assignment and/or simulation
sub-models on their own but also the convergence within the simulation-
assignment loop. Generally speaking they duplicate information provided
elsewhere in .lpt files, SATLOOK outputs, etc. etc., but brought together into one
location. Most outputs are therefore described elsewhere within the manual.

A secondary objective of the Convergence options is to indicate where

convergence is not being obtained, e.g., to print out the 10 least well-converged
simulation nodes or the points where blocking back is changing most rapidly. The
intention is to help the user to discover how to improve convergence by tackling
the weak points.

The lists of “worst” locations may be supplemented by an option to “highlight” (see

11.6.5.4) the locations of the nodes where they occur, following which the option
“Hilite Nodes Loop Graphix” allows the user to automatically “loop” over those
nodes in order to demonstrate, using node graphics, potential problems.

The options included within Convergence are (assuming a simulation component

in the network):

♦ A summary of all important convergence statistics (from all networks if more

than one);

♦ Tables 1 & 2 summarising the simulation-assignment convergence statistics

(see 9.4.1 and 9.4.2);

5101396/ May 11 11-119

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

P1X: Interactive Analysis of Results

♦ A list of the 10 worst nodes in terms of simulation convergence (8.3.3),

delays, “gaps”, capacities and assigned flows per simulation turn (9.9.1.2);

♦ The 10 largest changes in blocking back factors (9.9.1.1);

♦ A list of all instances where MAXQCT and/or MAXDTP were applied (if any)
(8.4.6);

♦ “All (convergence) statistics” as printed within SATLOOK (11.11.8);

♦ “ISTOP Statistics” – basically Table 1 above in a slightly different format;

♦ A summary of the errors, warnings etc. (also available under Information)

♦ Accuracy statistics from the SAVEIT assignment

11.16 P1X: Technical Specifications

11.16.1 P1X Files

Channel Remarks
Number
1 The “MASTER” input network UFS/A/T file (Mandatory)
2, 3, 4 Further input network files (optional)
5 Various input ASCII files (Optional)
6 The output LPP line printer file. (Mandatory)
7 Output ASCII files (Optional)
8 A scratch UFX file (Optional; required for more than 1 input file)
9 Second matrix UFM input file(s) (Optional)
10 First matrix UFM input file(s) (Optional)
11 Plot file to be sent to a hard copy device (Optional)
12 The input graphical data file GRAF.DAT; see 11.3.1. (Mandatory)
13 P1X Help file (P1X.HLP) (Mandatory)
15/14 Terminal input and output (Mandatory)
16 Optional terminal
19 A GIS input file (Optional)
21 An input trip matrix file (Optional)
25 An output LOG file (Mandatory)
26 An Output UFS file (Optional)
28, 29, 30 Output UFM files (Optional)
31...34 Input UFC files for networks 1..4 (Optional)
37 Scratch direct access copy of the network.dat file (Optional)

5101396/ May 11 11-120

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

P1X: Interactive Analysis of Results

38 Input network .dat file (Optional)

41...44 Scratch UFX files (Optional)
45 An input preferences file containing default parameter values
(P1X0.DAT); see 11.4.3.
48, 49 Scratch Direct Access GIS files (Optional)

11.17 SATLOOK: Technical Specifications

11.17.1 SATLOOK Files

Channel Remarks
Number
1 An input UFS/A file (Mandatory)
2 Second input UFS/A file
3 Third ditto
4 Fourth ditto (Optional)
5 A “preferences” file containing the control parameters as described
in 11.17.2 below; (Mandatory)
6 An output LPL line printer file. (Mandatory)
7 An output ASCII KP file. (Optional)
8 A scratch UFX file used for both input and output when more than
one network file is input. (Optional)
13 SATLOOK.HLP Help File (Mandatory)
15/14 Terminal (both input and output) (Mandatory)
19 A GIS input file (Optional)
25 An output LOG file (Mandatory)
28 Output UFM files containing the inter-zonal
29 Skimmed matrices, e.g., time, cost, etc.,
30 or crow-fly distances. The first matrix is output to channel 28, the
second to channel 29 etc. up to a maximum of 3 matrices. (Optional)
31..34 Input UFC files for networks 1..4 (Optional)
40 4th skimmed output UFM matrix used by skim_all for 44444 time
penalties
41 Scratch UFX file used for matrix skimming (Optional)

11.17.2 SATLOOK Preferences File (SATLOOK0.DAT)

For most current applications the preference or control file for SATLOOK should
be a “null” namelist file of the form:
&PARAM
&END
or, alternatively:

5101396/ May 11 11-121

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

P1X: Interactive Analysis of Results

&PARAM
MODET = 1
&END

where MODET = 1 sets the interactive mode.

The full set of the “normal” parameters which may be set in satlook0.dat are listed
and annotated within the version of the file supplied with the release (or created
when you output a preferences file from SATLOOK). An explanation of each of
the parameters is given as a comment at the end of each record.

Other parameters are in fact available and may be used to run SATLOOK in a
batch mode but this is largely a historical application which is no longer
recommended. Documentation is given in Appendix X contained in the very old
ASCII manual files only (not to be confused with the current Appendix X).

11.18 SATDB: Technical Specification

11.18.1 SATDB Files

Channel Remarks
Number
1 An input UFS/A file. (Mandatory)
2,3,4 Further input UFS/A files. (Optional)
5 Input ASCII files; see 11.18. (Optional)
6 An output LPD line printer file. (Mandatory)
7 Output ASCII files (file type .dbd) (Optional, depending on whether
any ASCII “dump” options are invoked.)
8 A binary scratch file, both input and output (Optional) (required with
>1 network file)
13 The SATDB help file (SATDB.HLP) (Mandatory)
15/14 Terminal (both input and output) (Mandatory)
19 A GIS input file (Optional)
21 An input trip matrix .ufm file (Optional)
25 An output LOG file (Mandatory)
26 An output UFS file (Optional)
28 An output select link trip matrix UFM file (Optional)
31 ... 34 Input UFC files for networks 1..4 (Optional)
42 A scratch randomised trip matrix UFM file used for both input and
output (Optional)
45 An input preferences file SATDB0.DAT; see 15.2 (Mandatory)

5101396/ May 11 11-122

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

P1X: Interactive Analysis of Results

11.18.2 SATDB ASCII Data File Input

The option to read link data directly from an external .DAT file into SATDB is
described in 11.10.6.5. Under “standard” SATURN format these input files may
contain more than one data entry per record and the data is given in “free format”.
The input file must be formatted as follows, one record per link/turn:
Cols. 1 - 5 The link “A-node”
Cols. 6 - 10 The link “B-node”
Cols.11-15 The “C-node” if referring to a turn (0 or blank otherwise)
Cols.16 … The data value(s) in free format (i.e., the values may be either
INTEGER or REAL and separated only by spaces or commas).

If either entry A or B refers to a zone (centroid) this is indicated by a C in column 1

or 6.

Data is terminated by 99999 in cols. 1 - 5. Initial records containing text, e.g.

namelist records, or records which otherwise lead to formatting errors when input,
are ignored.

The “standard” format for link/turn definitions as used in a number of places

elsewhere in the Suite; e.g., the ‘66666’ count data input to SATNET, which
requires a single integer link data value in (fixed) columns 16 - 20 therefore
satisfies this specification.

N.B. The required format differs if DUTCH is TRUE whereby the node entries
occupy 10 columns, not 5, and the data values commence in Column 31; see
Section 15-20.

11.19 SATED: Technical Specification of Files

Channel Remarks
Number
1 An input UFS file (Optional, required under the network editing
mode.)
5 Input DAT network data files (Optional)
6 An output LPE line printer file. (Mandatory)
7 An output KP ASCII file containing a description of the simulation
network. (Optional, depending on whether the “dump” option is
ivoked.)
12 The graphical data file “GRAF.DAT”; see 11.3.1. (Mandatory)
13 The SATED help file (SATED.HLP) (Mandatory)
15/14 Terminal (both input and output) (Mandatory)
19 A GIS input file (Optional)
21 An input .UFM trip matrix file for 1 node. (Optional)
25 An output LOG file (Mandatory)

5101396/ May 11 11-123

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

P1X: Interactive Analysis of Results

27 An output UFA file

28 An output .UFM trip matrix file for 1 node. (Optional)
45 An input preferences file SATED0.DAT; see 15.2 (Mandatory)

5101396/ May 11 11-124

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

P1X: Interactive Analysis of Results

11.20 Version Control

JOB NUMBER: 5101396 DOCUMENT REF: Section 11.doc

Revision Purpose / Description

Originated Checked Reviewed Authorised Date

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

2 L4L Added DVV 28/05/06

3 Upgrade to V2 Template IW 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.4.1 V10.7.10 Release DVV NP IW IW 24/04/07

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

3.6 SATURN v10.8 Release DVV NP IW IW 25/03/08

3.7 Web release – Jul 08 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 13/05/11

5101396/ May 11 11-125

10_09_24_Section 11.doc