8. Bridging GRAPHS (NISystem Core Utilities)

8.2. NIS Database management module

8.3. Database links
8.3.1. Direct links using C++ routines
8.3.2. Direct links using VB 5.0 routines
8.3.3. Object Database Connectors (ODBC)
8.3.4. Network Integration: LAN, WAN and the Internet

8.4. From geographical oriented to network oriented
8.4.1. NIS Definition for Transport Databases
8.4.2. Defining Classes of Objects (Entities) in a Transport oriented NIS according to GTF
8.4.3. Elements of NIS architecture. Basic definitions

8.5. Software implementation of Bridges NIS Utilities
8.5.1. Database Management of Transport objects
8.5.2. Basic DBS/GIS concepts within NIS
8.5.3. CAD, GIS and NIS Management of Transport objects

8.1. Objective: Advanced network oriented utilities

The purpose of developing "core functionalities" or internal utilities, in the Bridges context, was not to contradict the open multi-system strategy by duplicating and replacing external applications (such as commercial Database Managers, GIS, Statistical packages, Spreadsheets, Modelling packages etc.) by core utilities. Instead, the paramount goal was to develop specialised graph management utilities lacking in commercial GIS applications, for example utilities providing graph editing, checking or matching etc. A second objective was to achieve maximum flexibility in customising powerful and intelligent user interfaces, independent from any particular software application. The third objective was to get a number royalties free utilities which could be used for the dissemination of the default options of existing systems to a larger number of potential users (e.g. connecting all PC's of an Intranet or making hundred of copies in CDRom at no extra cost). Finally, ongoing analysis of how to make Bridges technology Internet-compatible largely rely in the capacity of Bridges to send to any web visitors free executable files containing default functionalities and encrypted databases. All this could greatly improve user's interactivity with Bridges systems through the Internet.

As development criteria, five paramount goals were adopted to develop Core functions:

1. Use of mature technology, procedures and algorithms,
2. Focus on specific transport needs, e.g. management of the supply of data attached to graph structures,
3. Compatibility and complementarity with the GTF data model,
4. Emphasis on providing on-line interaction with the user, so developing tools able to be integrated in the user interface level and
5. Use of royalties free software development tools, whenever feasible.

These development criteria resulted in the following software design decisions:

• For Database management functions, easy viewing and common management tools have been developed in Visual Basic using Microsoft ACCESS as the engine. Efficient access to large or remote database sets may require these functions to be supplemented with more sophisticated software, such as SQL Server, ORACLE or others. For example, Bridges GIS functions are supported by specific binary structures. The only exception to the use of royalty's free tools is the implementation of Microsoft Graph (a Microsoft component able to produce graphics) together with Bridges database routines.
• For CAD functions, no digitalisation procedures were developed but advanced tools, not available in any commercial application known to us, for editing graph entities and checking graph properties were implemented.
• For GIS functions, no raster image processing or automatic geographical projection manipulations have been developed. This simplification of conventional GIS has made the Network specialised tools much more efficient and powerful at managing transport graphs than other commercially available applications. However, some GIS capabilities, such as geographical analysis and grid structures, have been implemented to enhance graphic analysis related to graphs.
• For Thematic mapping, transport specialised mapping (e.g. mapping of flows) has been developed but conventional mapping facilities are available as well, because of the low additional programming effort required.
• For statistical modelling, only conventional descriptive indicators and basic linear regression tests (e.g. T-student, Kolmogorov) have been developed, supplementing those available in standard spreadsheet applications. Other algorithms (e.g. for optimisation based on Genetic Algorithms, linear programmes etc.) have also been developed.
• For transport modelling, network assignment procedures based on standard methodologies (DUE (Deterministic User Equilibrium), Frank-Wolfe and MSA convergence methods) were implemented, and a large number of alternative path and routing algorithms, as well as other algorithms for network analysis. The structure of these network routines allows linkage of other modelling routines in the future (e.g. for network calibration based on optimisation routines, modal split as part of assignment process etc.)

NISystem utilities are organised into a number of "modules", each one is a stand-alone application enjoying its own user-interface, which can be included in a system like any other stand-alone application. However, each module is modular in itself, so it is relatively easy for Bridges/NIS developers to build new modules by aggregating already available functions or upgrading existing modules by adding new functionalities. The main Bridges/NIS modules are as follows:

• To define "projects" (the data structure of a system: create, remove or modify classes and type of objects)
• GIS/NIS visualisation (to view cartographic elements, assign graphic attributes, manage maps etc.)
• CAD management (to draw and erase elements, adjust projections, carry on geometric analysis etc.)
• Database management
• Graph analysis (to edit graphs, apply quality controls, generate automatically graph elements subject to conditions, carry on analysis such as shortest path algorithms, shortest path algorithms under node and link constraints, assign flows etc.)
• Statistical analyses (to compute basic descriptors, linear regressions, Pearson coefficient and t-student, error tests, Kolmogorov analysis etc.)
• Modelling
• Mathematic algorithms (e.g. optimisation processes such as Genetic Algorithms, mathematic functions etc.)
• Thematic mapping (to provide desktop mapping such as pies, bars, circles and network-related ones, such as flows. etc)
• Decision support (e.g. Multicriteria, decisional-trees, cost-benefit)

Not all NISystem modules are at the same level of development. While some are relatively advanced (e.g. Graph analysis, providing utilities which are sub-optimal or non-existent in commercial packages), others, which provide utilities that can be obtained from existing software or are less relevant in fulfilling the Bridges Vision, are less developed (e.g. Modelling, because advanced models are intended to be developed by external experts and then "bridged" to the system, needing only basic capabilities).
The following sections contain the description of these modules. It is divided into three sections to make the description more synthetic: first the database module is presented in Section 8.2 and then the links it has with other database managers (developed in Visual Basic and based on Microsoft Data Access Objects) in Section 8.3; finally, all other modules are presented in Section 8.4. All of them are developed in Borland C++, and share some common functions and data structures internally.

Bridges core functions were partially based on reprogrammed routines and functions from the UTS/GIS System developed by Mcrit (1996) for EC/DGVII. UTS/GIS remains a fruitful inspiration source for the development of Bridges user interfaces since it was a friendly application with powerful GIS visualisation capabilities. Generally speaking, UTS+ DOS functions have been extremely useful for defining and advancing the early stages of Bridges development, in particular in relation to graph management tools; however, there is an essential conceptual difference between the two approaches:

• UTS was a closed C++ stand alone pre-Windows application to provide user friendly GIS viewing of regional impact indicators based on strategic modelling results.
• Bridges is not a single application focused on a particular user but a set of components able to support open systems. Bridges provides links ("bridges") between different software applications (such as database managers and GIS) and transport models, so that they may be assembled and personalised according to any potential user needs.
• UTS/GIS, because of its integration of Database management, GIS and modelling options in a user friendly interface, can be characterised as an individual Bridges Work Space with limited analytic capabilities but relatively good viewing facilities.

Bridges database utilities are based on the ACCESS DLL engine. VB5.0 basically provides all the royalties free functions needed to drive the ACCESS engine even if the actual ACCESS application is not installed.
The thirty Bridges Database Core routines, integrated into the DATABASE management module, provide all those capabilities needed to define and manage network oriented databases, in particular transport related ones. These core routines enable the user:

• To define the structure of a database: number and type of classes or entities, name and location of attached files, metadata etc.
• To establish the hierarchy and topological relations between objects from different entities or classes
• To import databases from ACCESS, EXCEL and DBASE with direct DAO links
• To import databases from any DBM application through ODBC drivers (the user has to indicate the ODBC driver needed when declaring all the Databases of the project).
• To view actual data attached to each class in each database and table, in grid form, even from very large databases (a dynamic system for viewing large databases has been implemented to save viewing time)
• To modify the structure of any table by adding or removing variables
• To define personalised queries to any set of tables included in the base of each class of objects
• To personalise formulas and calculations
• To analyse basic statistical indicators (a C++ module was developed including basic statistical descriptors and histograms as well as analysis of variable independence by multiple regression: R2, t-student, Kolmogorov test to check the normality of error distribution etc.)
• To produce graphics and tables (Microsoft Graph)
• To create new database structures on graph matching options
  

The common goal of Bridges Database DAO/ODBC data links has been the development of efficient import-export links, database viewing and management, capable of working as a stand alone application and open to other DBM applications and Bridges components.

The use of Internet technologies to access any remote database (such as Java database Connectors - JDBC and others) has been tested but remains non-operational. It is however one of the most promising areas in which the research could move ahead. The opportunities to use Internet technologies will be explored in the near future in relation to those Bridges components in which the Internet connection is, in principle, of special interest.
Four work areas were defined:

• Direct links (using Borland C++ routines to read/write in DBASE and ASCII formats).
• Direct links (using DAO on Visual Basic 5.0 routines, to read/write ACCESS, EXCEL, LOTUS and DBASE)
• Indirect links when direct links are not feasible (using ODBC calls, to read/write ORACLE, SQL Server etc.)
• Links to remote databases (using JDBC, IDC etc.)

Beyond these four areas, and closely co-ordinated with them, already existing Bridges Database utilities have been improved and extended. More specifically, the Bridges database engine has been designed as a Visual Basic stand alone application linking bases stored in their original DBASE, ACCESS or EXCEL formats through DAO and all other formats through ODBC (each class of objects has three attached files: a single alphanumeric base with an unlimited number of tables, a "linkage" file with graphic identifications of objects to establish the GIS/NIS relation, and a CAD file containing the graphic elements attached to each object, if any).

The main value of using C++ routines is to provide efficient, fast access to large databases. Algorithms and analytical routines included as core utilities, all developed in C++, will use these routines to import and export data from/to databases. Algorithms and analytic routines cannot access large databases through queries to the database manager (in VB5.0) because this would require the transfer of many complex BRIDGES messages between the components involved in the process, causing serious delays when managing very large datasets. On the other hand, C++ routines will be very useful for import/export of ASCII files with transport data structured according to the GTF format.

Most of these routines were developed internally by Bridges partners during previous work and only minor adaptation was needed to integrate them into the Bridges framework.

Routines to link BRIDGES Core to the following applications have been developed in Visual Basic: ACCESS (.mdb), EXCEL (.xls) and DBASE (.dbf) taking advantage of DAO functions (VB 5.0). BRIDGES Core has thirty specialised VB5.0 functions to facilitate direct links to these three applications and to carry out specialised Database management tasks.
These thirty VB 5.0 functions use the full functionality of Windows Data Access Object (DAO). DAO is composed of a set of Microsoft royalties free Dynamic Linked Libraries (.DLL), for example MSEXCL35.DLL for EXCEL or MSXBSE35.DLL for DBASE. Therefore, all DLLs used to establish direct links between Bridges Core and DB applications will be included together with the remaining Bridges components when Bridges System is disseminated (DAO library files are usually installed together with the Visual Basic language compiler; users without this compiler installed will need to receive these specialised DAO DLLs with the remaining BRIDGES software). In addition to the already mentioned DLLs, other more general DLLs must be included within the BRIDGES software package.

It is important to note that DAO functions allow viewing and management of the data stored on the commercial DBM applications listed. They maintain active links to the server applications where the data is actually stored. Therefore, any Bridges user modification in the database will be automatically updated by the server DBM applications Some DBM applications may constrain the user's capacity to modify the data, even if Bridges provides the capacity to do so. For these cases, data has to be imported to ACCESS using BRIDGES interface options before it is managed (subsequently, the modified database could be exported to the original DBM applications if necessary).

DAO provides functions to link more powerful Database Managers, such as ORACLE or SQL Server, only through ODBC. On the other hand, Borland C++ functions can only directly read ASCII and Binary fields. Difficult programming work is required to define import and export functions in Database manager formats. VDBT (Visual Database Tools) was tested to establish links to Paradox and DBASE but MCRIT's own C++ lower-level libraries were faster and more efficient for BRIDGES purposes. MCRIT C++ routines manage DBASE files (the closest format to ASCII), and this format has been used as default exchange format between BRIDGES components; however, the greater productivity and ease of VB 5.0 in creating Data links through DAO strongly recommended its use instead of Borland C++ or even Microsoft Visual C++ (which uses DAO as VB 5.0).

ODBC is composed of a set of drivers (one for each Database Manager application) which facilitate the transfer of data between DBM applications (import/export options according to predetermined arbitrary user queries). Each ODBC driver is a DLL developed by the software provider of the DBM applications. Microsoft Windows includes all drivers together under a single user interface which allows any user to meet all the parameters that each driver requires: Each call to a particular file of any Database Manager applications will therefore need a specific configuration of the ODBC driver to be properly channelled.

Each Bridges user will have to configure the ODBC driver of the DBM application. For the source of the data files, to meet the particular requirement, BRIDGES Database utilities check if the proper driver is available and then allow viewing of the database file. Once the Bridges Core has received the database file (coming from ORACLE for example), it can be exported to any Database Manager with direct links (such as ACCESS, EXCEL and DBASE).

DAO provides links to multiple users working on Local Area Networks (LAN) and World Area Networks (WAN) but it does not provide Internet links.

The use of still immature and low-productivity technologies, such as Microsoft Internet Database Connector (IDC) or JDBC (Java Database Connector) has been tested to develop Internet links but still remains non-operational.

As stated in previous chapters, GIS utilities are insufficient to manage transport graph structures efficiently. To overcome several of the identified problems, a set of specific utilities was developed. NIS utilities can be understood as re-programmed GIS utilities able to handle transport topologies as defined by GTF.

8.4.1. NIS Definition for Transport Databases

The need to define Transport Databases in NIS arises from the constraints on managing the complex topologies of Transport Systems within the framework of conventional GIS applications and led to useful indications on how to overcome these constraints, particularly in relation to "formats". This led to the definition of the GTF.

Transport Systems' database structures cannot be properly handled by existing GIS formats and utilities. However, GIS utilities facilitate a large number of useful transport information management processes, especially those related to transport infrastructure and environmental impacts, aspects directly linked to geographical features. These utilities constitute the starting point for the NIS definition.

Transport entities (or Classes of objects) are defined by topological structures which can only be partially associated with their infrastructural and geographical dimensions. Information related to categories of transport users, type of services, available vehicles and carriers, turns on intersections, infrastructure sections, terminals etc. must comply with specific interdependency rules in order to guarantee that it is consistent and represents the real system. Transport entities and rules must follow "graph topologies" (abstract network representations) in order to model the networked interrelations of transport systems information.

From a data model point of view, NIS is fundamentally different from GIS. NIS is based on "Classes of objects" (defined by database structures and topological attributes) rather than on "Levels" (with graphic attributes). Often, "classes of objects" and "levels" may coincide, and all objects belonging to the same class could be associated to the same level and vice-versa but there is a fundament difference between them that leads to a very different internal software architecture:

• All objects in a class share database structures and topological rules among themselves and other classes. Classes cannot have any attached graphic information or viewing attributes.
• All symbols in a level are viewed or printed together (according to the order in which they were created) in the sequence of all levels in the map. Symbols in a level cannot have any database attachments.
  This conceptual change implies a trade-off: NIS has an easier graph database organisation but less intuitive mapping and graphic viewing than GIS and, of course, Desktop Mapping. Mapping "levels" may contain elements with particular symbols but no topological rules or even data attached, and only share the order of viewing in relation to other levels of the map. Levels usually become items in the legend of the map (this will be used as the foundation for "NIS thematic levels", independent from "NIS classes of objects" but linked to them.
  

For the sake of consistency, it is important that all elements belonging to a "NIS Class" share the same visual attributes and topological properties. In order to personalise the symbols of a group of objects belonging to any class, "thematic levels" must be created. A series of thematic levels could be associated to a class and be viewed instead of or in addition to the "graph levels". While any graphic editing of thematic levels has no implications for the database structures (only the display is affected), the editing of "graph levels" implies changes in the database structures and therefore protection is provided.

Generally speaking, an NIS will have special problems in being fully efficient in dealing with raster images (it would have to include, in addition, normal GIS utilities to develop raster processing tools, not essential from a purely NIS point of view) or in being linked to GIS raster processing routines if needed.

Table 2 presents a simplified representation of the characteristics of NIS in relation to GIS. Needless to say, there is a long list of GIS applications and options for personalisation and linking to DBS managers, so the following table should be seen in terms of facilitating a conceptual description of NIS rather than specific operational explanation of it.

The definition of a given NIS database project includes the following general elements:

• Classes of Objects: They constitute a "network topology" or a "graph" and have databases (MDB, XLS, DBS etc.) [close to Database managers]
• Thematic or Symbolic Levels: Symbols attached to objects with graphic attributes depending on arbitrary selection of variables. They are created through "Thematic mapping" options in a library of symbols. A predetermined "default" symbolic level is defined to be attached to the objects database itself. [close to Desktop mapping applications].

A given thematic or symbolic level is defined as a group of different type of symbols linked to objects of any set of classes. The thematic mapping interface asks the user to define, one by one, the classes of objects to which symbols are to be attached. All the objects of a given class will share the same type of symbol but the parameters defining it (width, colour, size etc.) may change from one object to another (depending on the value of the variable selected or created for viewing). Each symbol in a thematic level is itself a "virtual object" linked to a real "object". A symbol can be moved and clicked, opening the table of the database linked to the object where the thematic variable is stored. The Thematic levels are stored following the same binary internal structures of classes of objects, up to 50 different levels, and can be viewed in any window together with any "Object class", "Vectorial layer" or "Raster layer" (see below).

• Vectorial Layers: They have no information attached (DGN, DXF etc.) [close to CAD applications]
• Raster Layers: They have no information attached. Cannot be superimposed over other elements (BMP, TIFF) and require particular utilities for zooming, scaling, printing etc. [close to Graphic design applications]
  

GIS is based on the same elements but manages them in a different manner to NIS, as has been already explained. Let us define "Class of Objects" more precisely:

• Class of objects: Any group of objects ("such as Airports") sharing the same topological attributes and rules. All objects in a class have common graphic attributes as a default, called "by_class".
• Classes: Any group of objects belonging to a class ("French Airports", "Regional European Airports" etc.). Individual objects may belong simultaneously to different classes. Each class usually has Databases coming from different sources. [In order to personalise the way each class or even each individual object is viewed, additional graphic attributes "by_object" are allowed; these personal graphic attributes of each individual object can be produced and stored through the options included within "Thematic mapping"].
  Tables: Composed of any group of objects belonging to a class associated to a list of variables (ideally, all tables within a class database should have the same objects). A Database may have an unlimited number of tables.
• Hyperclasses: aggregations of classes belonging to different classes under arbitrary conditions ("Airports" and "Roads" with private financing). As classes, they may have classes and tables.
• Superclasses: aggregations of classes which share fundamental topological attributes (nodes, links, polygons)
  Hierarchy of objects (based on classes): Superclasses, classes and hyperclasses, classes and table-contained objects follow hierarchical dependence relations.
• Hierarchy of variables (based on themes): All variables contained in all tables of the whole Database can be organised according to their thematic similarity.
• Metadata tables: Each database project must have metadata information. This metadata information is related to the table itself and should be linked to the source which provided it. Link to Source providers: each table is associated to a single source provider. Its address and full reference must be contained in a separate "Database of Sources" (supplementary and/or associated to the Digital Data Guide, DDG).
  

8.5.1. Database Management of Transport objects

Because its openness, as a default database manager Microsoft ACCESS has been used (SQL Server in Microsoft Office'2000 is being analysed currently to substitute ACESS, and Oracle to add spatially-related queries and efficient access to remote databases through Internet).

In ACCESS a "Database" is contained in a file (DBSNAME.MDB) which contains an unlimited number of "Tables". Each table contains an unlimited number of registers (rows) and a maximum number of attributes (columns). The capacity constraints of ACCESS are 1 Gigabyte for each database and 125 columns in each register. In addition to tables, a database file contains an unlimited number of "Queries". There are two basic types of possible query: queries to select all objects verifying a given condition and queries to create new attributes and store them in already existing or new tables. Queries cannot be made between different databases.

ACCESS can be easily integrated into open platforms since its Visual Basic 4.0 programming language uses it as a default Database manager. A stand alone Visual Basic application may enjoy ACCESS utilities even if the ACCESS application is not available on the hard disk or LAN itself.
Links to ORACLE and other more powerful Database managers will be analysed later on but ACCESS is an unavoidable first choice for development of the BRIDGES environment.

Within Bridges NIS, a "DBS Project" is defined therefore as a set of databases, tables and queries adapted to the catalogue of transport entities and objects:

The "DBS project" is constituted by a series of databases plus a "Project DB" which contains "Reference Tables" (RF) related to the addresses of all databases in the project and "Dynamic Tables" (DY) as data transfer tables between ACCESS files and the remainder of the NIS or external applications.

Within each database, different types of elements are considered: Source Tables (SR), Code Tables (CD), Queries (QR), Working Tables (WK) and Metadata Tables (MT).

• Source Tables (SR) contain data as supplied from each source, with the same codification and attributes.
• Code Tables (CD) contain equivalences between the object codification of different sources and the official standard ones (ISO, UN, IATA etc.).
• Queries (QR) are pre-programmed routines needed for integrating source tables into working tables using the equivalences in the code tables.Conditions for attribute assignment, checking etc. are included in the query tables
• Working Tables (WT) are those tables for use in modelling and other work.
• Metadata Tables (MT) contain information related to the sources providing the information stored in each source table, and queries applied for each working table. Further information related to the characteristics of each particular variable etc. must be obtained through access possibly to the source itself via the Internet.
  

Each Table contains data for a single class of object and it has a single source: Each register in the table represents a particular object and each column an attribute. Three attributes are required in all cases: Name, Code and CAD_Link (where it makes sense).

Bridges NIS utilities are based on two separate families of routines: graphic-oriented [MGIS] (C++) and alphanumeric [MDBS] (Visual Basic). Linkage between both sets of routines is assured by interactive calls through the Bridges Communication System.

NISystem contains a number of routines, programmed in Borland C++ allowing the management of transport entities as such. The following sections provide for a reference to their capabilities.

Editing graphs

A number of pre-defined graph elements are available for editing. They are based on three objects: "Nodes" (associated to a single point, x, y, z co-ordinates), "Links" (associated to lines defined by two points) and "Groups" (associated to a list of nodes and links).

Based on these fundamental entities, transport specific entities, such as "services" can be defined (e.g. as a groups). Bridges NIS interface provides the user with a list of transport entities he can select when editing a graph. Bridges NIS automatically generates the data structures related to these entities.

Graph Generation

Procedures to create networks automatically, based on predetermined conditions (for example based on identifying missing links, on pre-existing lines such as roads from CAD maps).

Graph Checking

A number of utilities have been programmed to verify topological conditions between NIS entities automatically (e.g. checking whether all rail stations are connected to rail and road infrastructure links and identifying those connected to other types of link, e.g. rail stations within airport terminals connected to air services). Checking utilities display the identified objects on screen, facilitating correction by the user.

A list of checking utilities is available for the user to check imported graphs.

Graph Matching

Two matching files are needed to transfer data attached to one graph to another with different segmentation: CAD match (equivalence between elements in the origin graph and the target graph) and DBS match (logical or analytical procedure to transfer variables attached to the elements in the original graph to the equivalent elements in the target graph, as the in the target graph, the elements will get the average, weighted average, minimum or maximum values of the equivalent elements in the original graph.

Graph Analysis: Minimum Shortest Paths

• Dijkstra Algorithm
• Ford Algorithm
• Always Forward (one step back) Algorithm
• Always Forward (two steps back) Algorithm
• Shortest path with node and links requirements
• Shortest path with crossing points and transhipment requirements
• Trees from a given centroid
• Circles (Salesmen problem)

Flow assignment

• All or Nothing assignment
• Deterministic User Equilibrium (Frank-Wolfe algorithm)

Statistical and mathematical functions

General statistical functions have been programmed: Normal, Lognormal, Weibul, and basic utilities to adjust histograms to any of these functions
A set of data (x, y) can be loaded from the Database manager in order to adjust it to a mathematical function with predetermined parameters. Errors are statistically analysed: for a level of significance to be fixed by the user the module evaluates whether the errors can be characterised by a Normal distribution. It provides the Pearson coefficient (R2).

A histogram can be loaded in order to adjust statistical functions (Normal, Binomial, Poisson, Uniform, Exponential, Lognormal, Weibul, Gamma, Beta, Fisher, Student, Chi square and Rayleigh). Parameters can be adjusted statistically (in the case of Normal, Exponential, Uniform) or predetermined by the user. For a level of significance, it calculates whether a given statistical distribution models the loaded data acceptably.

Mathematical functions editor

An editor of mathematical functions y=f(x) (polynomial, trigonometric, exponential, logarithmic, potential and statistic). The user can fix the free parameters of each type of function and obtain a graphic representation of it (the scale of representation and a number of

Only basic combinatory functions can be calculated: Variations, Permutations and Combinations, with or without repetition, according to the number of elements, positions and groups chosen by the user.
This function applies the well-known "Simplex" algorithm to obtain the maximum or minimum of a linear function under linear conditions (or constraints). The user interface facilitates the process of defining both the objective function (to be maximised or minimised) and the constraints.
A Markov process is based on three elements: a number of alternative "states", the probability of each state initially (matrix of probabilities, to be fixed for the first step) and the probability of a change from one state to any other (transition matrix of conditional probabilities). The parameters are the matrix of initial probabilities and the of transition matrix.

A Queue algorithm analyses a channel (single or multiple) with a (limited or unlimited) number of arrivals following a Poisson distribution. Given the ratio of arrival and departure in the channel, there is a probability that a number of those arrivals remain in queue while others pass through it. The algorithm calculates the intensity of traffic through the channel and the average time in the queue.

Basic entropy measures (simple, conditional and joint entropy) have been programmed, as well as interactive parabolic and logistic functions to explore the emergence of chaotic behaviour from the dynamic iteration of very simple functions.

Genetic algorithms have been applied to support some internal routines (for example to create Eulerian tours, to allocate a set of individuals to groups, to optimise the set of parameters needed to achieve equilibrium between trip generation and distribution in "four steps models"). This option will give users the possibility of defining a "genetic process" in each of its steps (reproduction selection, crossover and mutation) under different rules (elitism, ranking).

Thematic mapping

The following options (with similar capabilities of Mapinfo and Arcview) are available:

• Highlight
• Bar
• Pie
• Pattern
• Flows
• Figures
• Isozones
• Lines

Elements to be represented can be grouped according to a Discriminant Analysis (based on Genetic Algorithms).

Thematic maps are stored as independent classes and remain alive even if the data and formulation creating them are removed.

Cost Benefit

Cost Benefit Analysis provides a complete analysis, including the financing and interest rates of intermediate cash flows. From a list of costs and benefits the routines provide a list of standard CB indicators

Multicriteria algorithms

After defining a list of alternatives, criteria and weights to evaluate them, the module provides three aggregation methods: Qualitative Concordance, Numeric Interpretation and Permutations, to be used depending on the kind of valuations established (quantitative, qualitative or mixed).

Decision trees

Decisions are related to "actions" to be taken in different "states". The best action is the one with maximum "utility". There are initial states (each with its probability of occurrence conditioned by each action) and secondary states (with probabilities conditioned by initial states). Utilities are a function of actions, states and secondary states to be fixed depending on the problem.

info@mcrit.com