Tarik Attar 06009306 Beng(Hons) Internet Computing An investigation on routing algorithms for...

Tarik Attar 06009306 Beng(Hons) Internet Computing

An investigation on routing algorithms

for web-based applications

Tarik ATTAR 06009306

Supervisor: Andrew Cumming

Second Marker: Neil Urquhart

Submitted in partial fulfilment of the requirements of Napier University

for the Degree of Bachelor of Engineering in Internet Computing

School of Computing

May 2008

2

Authorship Declaration

I, Tarik ATTAR, confirm that this dissertation and the work presented in it are my own

achievement.

Where I have consulted the published work of others this is always clearly attributed;

Where I have quoted from the work of others the source is always given. With the

exception of such quotations this dissertation is entirely my own work;

I have acknowledged all main sources of help;

If my research follows on from previous work or is part of a larger collaborative

research project I have made clear exactly what was done by others and what I have

contributed myself;

I have read and understand the penalties associated with Academic Misconduct.

I also confirm that I have obtained informed consent from all people I have involved

in the work in this dissertation following the School's ethical guidelines

Signed:

Date:

Matriculation no: 06009306

3

Data Protection Declaration

Under the 1998 Data Protection Act, The University cannot disclose your grade to an

unauthorised person. However, other students benefit from studying dissertations

that have their grades attached.

Please sign your name below one of the options below to state your preference.

The University may make this dissertation, with indicative grade, available to others.

The University may make this dissertation available to others, but the grade may not

be disclosed.

The University may not make this dissertation available to others.

4

Abstract

This dissertation aims to investigate routing algorithms on the context of web based

application. More particularly, this dissertation focuses on the single-pair shortest

path problem in an undirected weighted graph. In order to so a literature review of

what have been done on the area of routing algorithm will be made. Two algorithms

will be evaluated: A* and Ant Colony Optimisation. The evaluation of both algorithms

will be done against the Google MAP API.

Tarik Attar - Napier University

5

Contents

1 INTRODUCTION ..................................................................................................................................... 10

1.1 OVERVIEW .......................................................................................................................................... 10 1.2 NEW AIMS AND OBJECTIVES ............................................................................................................... 11

2 LITERATURE REVIEW ......................................................................................................................... 12

2.1 WEB APPLICATIONS THAT USE ROUTING ALGORITHM.......................................................................... 12 2.1.1 Google Transit............................................................................................................................... 12 2.1.2 Hopstop.com.................................................................................................................................. 13 2.1.3 Transport for London .................................................................................................................... 14

2.2 DATA SEEKING .................................................................................................................................... 16 2.2.1 Google Earth and Google Map data provider............................................................................... 16 2.2.2 Alternative choice for representing and visualising geographic data ........................................... 18

2.3 DATA TRANSFORMATION AND VISUALISATION .................................................................................. 21 2.3.1 From GML to MySQL.................................................................................................................... 21

2.4 ROUTING ALGORITHMS ....................................................................................................................... 22 2.4.1 Graph Theory ................................................................................................................................ 22 2.4.2 Shortest-Path Problem and Algorithm .......................................................................................... 23

2.5 CONCLUSION....................................................................................................................................... 30

3 METHODOLOGY .................................................................................................................................... 31

3.1 SOFTWARE ENGINEERING METHODOLOGY: EXTREME PROGRAMMING ................................................ 31 3.2 PLANNING ........................................................................................................................................... 33

4 A * ALGORITHM: EXPERIMENTAL EVALUATION ...................................................................... 34

4.1 REQUIREMENTS................................................................................................................................... 34 4.2 DESIGN................................................................................................................................................ 35 4.3 IMPLEMENTATION ............................................................................................................................... 37

4.3.1 Code structure ............................................................................................................................... 37 4.3.2 GML Parsing and Translation to MySQL 5 .................................................................................. 37 4.3.3 A * algorithm implementation ....................................................................................................... 38 4.3.4 Heuristic calculation: .................................................................................................................... 40

4.4 TESTING .............................................................................................................................................. 41 4.4.1 Assumption .................................................................................................................................... 41 4.4.2 Results ........................................................................................................................................... 42

4.5 EVALUATION....................................................................................................................................... 44 4.5.1 Algorithm stability ......................................................................................................................... 44 4.5.2 Algorithm accuracy ....................................................................................................................... 44 4.5.3 Algorithm execution time............................................................................................................... 45

4.6 CONCLUSION....................................................................................................................................... 46

5 SELF ADAPTIVE A * ALGORITHM USING SIMPLE ANT COLONY OPTIMISATION (SACO) 47

5.1 REQUIREMENTS................................................................................................................................... 47 5.2 DESIGN................................................................................................................................................ 48 5.3 IMPLEMENTATION ............................................................................................................................... 49

5.3.1 Code structure ............................................................................................................................... 49 5.3.2 PostCode segmentation ................................................................................................................. 49 5.3.3 Adaptive A* with SACO and Optimised implementation of A* ..................................................... 50

5.4 TESTING .............................................................................................................................................. 53 5.4.1 Assumption .................................................................................................................................... 53 Results.......................................................................................................................................................... 54

5.5 EVALUATION....................................................................................................................................... 57 5.5.1 Algorithm stability ......................................................................................................................... 57

6

5.5.2 Algorithm accuracy ....................................................................................................................... 57 5.5.3 Algorithm execution time............................................................................................................... 58 5.5.4 Conclusion..................................................................................................................................... 58

6 CONCLUSION .......................................................................................................................................... 60

7 FUTURE WORKS..................................................................................................................................... 61

7

List of Tables

Table1: Test case 1...................................................................................................34 Table 2: Test case 2..................................................................................................35 Table 3: Test case 3..................................................................................................35

8

List of Figures

you may have captions such as equations, listings etc they should all appear as

required

Fig 2.1: Google Transit interface screenshot.............................................................12 Fig 2.2: Hopstop interface screenshot.......................................................................13 Fig 2.3: Hopstop route on a map...............................................................................14 Fig 2.4: Transport for London user form....................................................................15 Fig 2.5: Transport for London route display...............................................................15 Fig 2.6: sample KML file ............................................................................................17 Fig 2.7: Northern Europe in Google Map...................................................................17 Fig 2.8: sample GML file ...........................................................................................18 Fig 2.9: OSMasterMap features in GML....................................................................19 Fig 2.10: Port Talbot in SVG......................................................................................20 Fig 2.11: Nodes of Edinburgh graph in SVG from GML data ....................................22 Fig 2.12: Double bridge experiment ..........................................................................27 Fig 2.13: Probability of an ant move ..........................................................................28 Fig 2.14: Formula of the pheromone deposit amount................................................29 Fig 3.1: Extreme programming applied to the project................................................33 Fig 4.1: Table and relationships created in the MySQL database .............................36 Fig 4.2 Pseudo code of the GML to MySQL translation ............................................37 Fig 4.3: Screenshot of Sourceforget.net....................................................................37 Fig 4.4: Pseudo code of A* algorithm ........................................................................38 Fig 4.5: Pseudo code of the implementation of the A* algorithm...............................39 Fig 4.6: Relation between the number of executed queries and the execution time..42 Fig 4.7: Relation between the length of the calculated route and the execution time 42 Fig 4.8: Relation between the number of dead ends encountered and the number of executed queries .......................................................................................................43 Fig 4.9: Comparison of the length of calculated route by Google and A * (the x axis represents the solution number)................................................................................43 Fig 4.10: Diversion on a calculated node ..................................................................45 Fig 5.1: Postcode table and attributes .......................................................................48 Fig 5.2: Pseudo code of the algorithm which links a node to a postcode ..................49 Fig 5.3: PHP class that have been created for SACO...............................................50 Fig 5.3: Pseudo code of the creation of serialised object in a file ..............................51 Fig 5.4: Pseudo code of the AntGrid object...............................................................51 Fig 5.5: Relation between the length of the solution and the execution time.............54 Fig 5.6: Comparison with Google’s results on same test cases ................................54 Fig 5.7 Comparison between the first implementation accuracy and the optimised implementation ..........................................................................................................55 Fig 5.7 Comparison between solution accuracy ........................................................55 Fig 5.8 Pheromone trail for the route from Ritchie place to Colinton road .................56 Fig 5.9: On the left, the result of Optimised A* with SACO, on the right Google’s .....56

9

Acknowledgements

The author would like to express his gratitude to his supervisor, Andrew Cumming,

for the support, help and advices given all along this 9 months project. The author

has really appreciated every meeting with his supervisor as they were always

instructive. Advices given have helped the author focusing on what has really matter

on this project has also reminded the author to be humble face to difficulties.

The author would also like to acknowledge Neil Urquhart for helping him finding data

which helped this project to get started and also for the help provided during the

second interview by reviewing the work that has been done and helping for

optimising it.

The author wishes to thanks his friends and family for their support all along the

project.

Finally the author wishes to particularly thank his mother for the everyday support

that she gave him.

This dissertation is dedicated to the author’s brother: Yazid


1 Introduction

Routing algorithms are often studied by scientist for solving problems such as the

best route between two addresses, the shortest tour of a city, the vehicle routing

problem and so on. This dissertation aims to investigate routing algorithms for the

single-pair shortest-path problem within a web-based context.

1.1 Overview

The initial project overview has defined the project as an implementation of a bus

route planner. Two main requirements were identified:

• Develop an interface to allow people to enter the coordinates or postcodes

and an algorithm for identifying the bus stops nearest to the start and end

points.

• Create an algorithm for determining the fastest route – this may depend on the

passenger’s walking speed.

These requirements have been changed as the Google Map API already provides

tools to geo-code addresses and retrieve driving directions. With the agreement of

the second marker and the supervisor, it has been decided that the project should

focus on routing techniques with a comparative evaluation to the Google Map API

algorithm.


11

1.2 New Aims and objectives The main objective of this dissertation is to implement, test and evaluate routing

algorithms within the specific context of web-based application in order to draw a

qualitative (quality of the solution) and quantitative (execution time.) conclusion.

These routing algorithms should retrieve the minimum cost path between two

addresses in the city of Edinburgh.

The underlying objective is to investigate routing techniques and mechanism. The

dissertation is concerned with implementing a prototype of an algorithms’ test

platform. The algorithm which has been firstly chosen is the A* algorithm. Then an

investigation on new routing techniques will be made by exploring the Simple Ant

Colony Optimisation.

The dissertation will attempt to realise the following aims and objectives:

• Develop personal knowledge of routing algorithm and understand inherent

issues and problems.

• Develop an algorithm capable of determining the minimum cost path in a

graph.

• Develop personal knowledge of the GML format.

• Conduct test and simulation for the A * algorithm with Google Map API as

reference.

• Conduct test and simulation of the Simple Ant Colony Optimisation with the

Google Map API as reference

• More generally, evaluate the impact of data structuring, database interaction

and implementation quality on algorithm runtime complexity


12

2 Literature review

This literature review seeks to investigate web-based applications that use routing

algorithms. Then it will explore what type of data is used by these applications and

what are the alternative choices. Finally, it will draw an overview of routing

techniques in order to implement, test and evaluate them.

2.1 Web applications that use routing algorithms There are a number of web sites that offer route planning and consequently use

routing algorithm. Three web sites have been chosen in order to understand what

type of information is needed and what interface they use to represent a route. The

three web applications are: Google Transit, Hopstop.com and Transport for London.

2.1.1 Google Transit The Google Transit application is a web site which permits to find best routes

between two addresses using public transportation.

Fig 2.1: Google Transit interface screenshot


13

The interface is simple. There are two text areas in which user can type the start and

end addresses. Then the route is displayed in Google Map and a description of the

route is also displayed. Google Transit is limited to the following cities: Portland,

Honolulu; Hawaii, Pittsburgh, Pennsylvania, Seattle, Washington and Tampa1.

2.1.2 Hopstop.com The website Hopstop.com offers the same service as Google Transit. At the first sight

the interface more complicated that Google Transit’s interface. The interface is

divided into two areas. The first one is a detailed route; the second one is one or

more maps (each map represents a section of the route).

Fig 2.2: Hopstop interface screenshot

1 Google (2008) Google Transit Available from: http://www.google.com/transit [accessed 12th February 2008]


14

Fig 2.3: Hopstop route on a map To conclude, this website is similar to Google Transit in term of user input interface.

But the route is displayed differently. This website works for United States Cities such

as New York, Boston, Chicago, San Francisco and Washington D.C.2. It is important

to focus on software on United Kingdom to be able to make a comparison.

2.1.3 Transport for London The project overview defines the project’s universe which is the city of Edinburgh. A

piece of software which deals with United Kingdom city is the Transport for London

website3. The interface is similar as the above software. There are two text areas to

type in start and end addresses. On this website the time of departure and arrival can

be specified. It can be noticed that the interface is the same even when the

geographical area where the software applies change.

2 HopStop.com (2008) Subway Directions and Bus Directions for New York City (NYC) Available from:http://www.hopstop.com/

[accessed 13th February 2008] 3 Transport for London (2008) Journey Planner Available from: http://journeyplanner.tfl.gov.uk/ [accessed 13th February 2008]


15

Fig 2.4: Transport for London user form

Fig 2.5: Transport for London route display


16

To conclude on this section, it is important to notice that all analysed web sites

provide similar interface for users’ queries: This interface does not depend of the city

where the software applies even if cities have different roads network. Two text areas

with the start and end address seems to be the standard for user input. It is also

important to notice that they use the same written format for displaying route

information. The main difference is that some uses map. It is also important to notice

that they use different routing techniques as they include the time of departure and

arrival. The Google Transit application is the most suitable software to be evaluated

against as it is the most simple. The only problem is that it only deals with specific

cities and does not cover the project’s universe. Finally no web based software which

uses only a walking route has been found during researches.

2.2 Data seeking There are many formats which represent geographical object. There are also as

much providers as formats. This section seeks to identify Google data providers and

also alternative choice which fits to the project constraints (cost): GML.

2.2.1 Google Earth and Google Map data provider Nat Torkington states that Google Map API data is provided by TeleAtlas4. This data

is not free and use a specific format. It is crucial to investigate on how Google uses

and represents geographic data. There are no materials on how Google stores and

compute geographic data. Indeed, this outlines the fact that it is not possible to find

out how Google Transit works. But since Google provides an API for developer, they

had to think of a way of communicating custom developer data to the API: the

Keyhole Markup Language (KML). “KML is a file format used to display geographic

data in an Earth browser such as Google Earth, Google Maps, and Google Maps for

mobile. KML uses a tag-based structure with nested elements and attributes and is

based on the XML standard”5. This description language is a custom language

created by Keyhole Inc which was acquired by Google in 2004. In fact, KML is not an

international standard and is very specific to the Google Earth software and Google

Maps. 4 Nat Torkington, N.T, 2005, Google Maps and their data provider Available from :

http://radar.oreilly.com/archives/2005/10/google_maps_and_their_data_pro_1.html [accessed18th February 2008] 5 Google (200?) KML Tutorial Available from: http://code.google.com/apis/kml/documentation/kml_tut.html [accessed 20th

February 2008]


17

Fig 2.6: sample KML file

<?xml version="1.0" encoding="UTF-8"?> <kml xmlns="http://earth.google.com/kml/2.2"> <Placemark> <name>Simple placemark</name> <description>Attached to the ground. Intelligen tly places itself at the height of the underlying terrain.</de scription> <Point> <coordinates>-122.0822035425683,37.4222899014 0251,0</coordinates> </Point> </Placemark> </kml>

2.2.1.1 Data representation in Google Map

Data is represented as many PNG layers in the Google Map website which give the

following result:

Fig 2.7: Northern Europe in Google Map

2.2.1.2 Google Map API

The Google Map API was made by Google to facilitate the interaction between

Google Map and developers. The Google Map API allows developers to perform a

set of tasks which are the following6:

• Embed map in website • Customise map • Draw markers, poly-lines and polygons in custom map • XML and data parsing (for the use of KML file or any other XML file) • Geo-coding (to retrieve latitude and longitude of a specific place) • Local Search: embed Google Map search

6 Google (2008) Google Map Api Concepts Available from: http://code.google.com/apis/maps/documentation/ [accessed 20th

February 2008]


18

• Driving directions: draw specific route from one place to another

To conclude on this part, it is important to outline the choices made by Google to

represent and visualise geographic data. On the one hand they use a non-standard

format which is KML to help data transfer between user and their applications. On the

other hand they provide a handy API which permits developer to customise maps,

create driving direction etc. Finally, Google Map is a better candidate than Google

Transit for evaluating algorithm against as it has a better geographical coverage but it

only retrieves driving direction so a mechanism has to be found in order to evaluate

correctly the fitness of implemented algorithms against Google Map.

2.2.2 Alternative choice for representing and visua lising geographic data KML is not the only XML-based geographical format. A particularly used one is the

GML format.

2.2.2.1 Geography Markup Language (GML) “The Geography Markup Language (GML) an XML encoding for the transport and

storage of geographic information, including both the spatial and non-spatial

properties of geographic features”7 . This format was defined by the Open Geospatial

Consortium (OGC). The OGC is an international industry consortium of 345

companies, governments’ agencies and universities.8

Fig 2.8: sample GML file

<gml:Polygon> <gml:outerBoundaryIs> <gml:LinearRing> <gml:coordinates>0,0 100,0 100,100 0,100 0,0</gml:coordinates> </gml:LinearRing> </gml:outerBoundaryIs> </gml:Polygon> <gml:Point> <gml:coordinates>100,200</gml:coordinates> </gml:Point> <gml:LineString>

7 ESRI Canada (200?) Interoperability and Standards Glossary Available from

http://www.geographynetwork.ca/standards/glossary.html [accessed 21 st February 2008] 8 Open Geospatial Consortium (2008) About OGC Available from: http://www.opengeospatial.org/ogc [accessed 21 st February

2008]


19

Basically, GML define basic geographic objects such as point, poly-line, and polygon.

But as an open format, features can be created using namespaces. A feature can

embed GML object. GML offers flexibility as it is based on XML and it is a standard

used by hundreds of companies such as Ordnance Survey.

2.2.2.2 Ordnance Survey and Integrated Transport Network Layer Ordnance Survey is an agency of the United Kingdom government. This agency was

created for military purpose during Napoleonic war in order to map Great Britain. The

main geographic database provided is Osmastermap. This product was launched in

November 2001 and is GML based data9. Ordnance Survey provides most of their

products for free for students via the Edina website (requires an Athens password)

such as classic maps, cartographic maps, historic maps, boundaries map and

Integrated Transport Network Layer (ITN). “ITN provides the definitive transport

network dataset for Great Britain. It consists of the roads network, road routing

information and other transport information”10. For instance, Ordnance Survey

provides the road network data for Edinburgh which is exactly what can be used in

the project.

Fig 2.9: OSMasterMap features in GML <osgb:roadMember> <osgb:Road fid='osgb4000000020975659'> <osgb:version>2</osgb:version> <osgb:versionDate>2005-09-12</osgb:versionDate> <osgb:theme>Road Network</osgb:theme> <osgb:changeHistory> <osgb:changeDate>2003-03-13</osgb:changeDate> <osgb:reasonForChange>New</osgb:reasonForChange> </osgb:changeHistory> <osgb:descriptiveGroup>Named Road</osgb:descripti veGroup> <osgb:roadName>HEOLCAE'R-BONT</osgb:roadName > <osgb:networkMember xlink:href='#osgb400000002091 8469'/> <osgb:networkMember xlink:href='#osgb400000002091 8474'/> <osgb:networkMember xlink:href='#osgb400000002092 3062'/> <osgb:networkMember xlink:href='#osgb400000002092 3126'/> <osgb:networkMember xlink:href='#osgb400000002095 4111'/> <osgb:networkMember xlink:href='#osgb400000002095 4112'/> <osgb:networkMember xlink:href='#osgb400000002095 4113'/> <osgb:networkMember xlink:href='#osgb400000002096 5610'/> <osgb:boundedBy> <gml:Box srsName='osgb:BNG'> <gml:coordinates>277465.929,184574.000 279468.000,186153.000</gml:coordinates> </gml:Box> </osgb:boundedBy> </osgb:Road> </osgb:roadMember>

9 Ordnance Survey (2002) OsMastermap - GML (Geographic Mark-up Language Available from:

http://www.ordnancesurvey.co.uk/oswebsite/products/osmastermap/information/technical/gml2.html [accessed 20th February

2008] 10 Edina (200?) Digimap Collections Available from: http://digimap.edina.ac.uk/mastermapdownloader/Downloader?useJS=true

[accessed 20th February 2008]


20

Osmastermap ITN uses the best of GML as every geographical object is already

defined and agreed by international consensus. Also, they define their own element

type as it is permitted by XML which provides a clear structure defined by an XML

schema. It is important to notice that they use a particular way of displaying data:

Scalable Vector Graphics (SVG): they provide an transformation stylesheet in XSL

which takes a GML file as input and return a SVG drawing such as:

Fig 2.10: Port Talbot in SVG

To conclude on this part, there is an alternative to Google Map which is

Osmastermap ITN. This product is a database of the road network of any city in

Great Britain written in GML. The Ordnance Survey website provides a handy

stylesheet which permits to transform GML to SVG. But SVG is not very easy to

manipulate. Indeed, in contrast to Google Maps, there are no facilities such as

zooming, navigating included in the transformation. Everything has to be made after.

A combination of Osmastermap ITN data with the Google Map API is what will be

used to create the algorithms’ test platform.


21

2.3 Data Transformation and Visualisation The choice of using Osmastermap ITN data and the Google Map API to display them

leads to extra work. Indeed a mechanism for transforming GML file into an entity

more manageable has to be found or created. This entity has to be able to compute

concurrent users’ queries and retrieve them in acceptable time.

2.3.1 From GML to MySQL The entity defined earlier is also known as a Database Management System such as

a MySQL database. An investigation has to be made on translator that can translate

a GML file to a MySQL database.

2.3.1.1 FME Universal Translator FME is a piece of software created by the Safe Software Company. It has the

following qualities11:

• Support for over 200 GIS, CAD, raster and database formats • Powerful transformations for a variety of data model requirements • Desktop and server solutions for any data interoperability need • Used by thousand of GIS and IT professionals worldwide

After having downloaded the trial version of FME (14 days) it appears that FME can

translate any kind of format to another format (e.g. GML to MySQL, GML to Oracle).

This is the biggest weakness of FME. Indeed, Safe Software does not provide any

documentation for the trial version and it has been empirically demonstrated that

making the translation requires access to the documentation. In fact, they deal with a

consequent amount of different formats and allow the user to define which attributes

from one format will be translated and how. This is done by a stylesheet (called a

mapping file) and the lack of documentation made the use of the software

impossible. The translation was done but a lot of information was missing after the

translation. For instance, in my GML file, a road is a part of a network member. The

FME translator sees it as an array of reference (which is right) but did not translate it

as an associative table in MySQL.

11 Safe Software (2008) GIS Data Conversion & Transformation Available from: http://www.safe.com/ [accessed 20th

February2008]


22

2.4 Routing algorithms The next step, after having exploring web-based applications that use routing

algorithms and what type of data can be used, was to investigate routing algorithms

in order to understand what mechanisms are involved and how could the best route

problem be solved.

2.4.1 Graph Theory “A graph is a pair G = (V,E) of sets such as E⊆ |V|² […] The elements of V are the

vertices (or nodes, ,or points) of the graph G, the elements E are its edges (or

lines).”12.

In other term a map can be represented as a graph. A map is a set of intersections

and roads. Therefore a map’s intersection can be assimilated to graph’s nodes and

map’s roads to graph’s edges. The problem of finding the best route in a map is the

same as finding the shortest path in a graph.

Fig 2.11: Nodes of Edinburgh graph in SVG from GML data

12 Diestel, R (2005) Graph Theory, Springer, p.2


23

It is also important to underline the fact that Edinburgh map is a particular graph.

Indeed, the map has no orientation as a link (v,w) is the same as the link (w,v). Plus,

roads have a length as attribute. Therefore it can be said that Edinburgh’s map is an

undirected weighted graph in accordance the definition given by Cormen et al13.

2.4.2 Shortest-Path Problem and Algorithm Gross & Yellen define the Shortest-Path problem as follow: “Let s and t be two

vertices of a connected weighted-graph. Find a path from s to t whose total edge-

weight is minimum i.e., a shortest s-t path”14

Comen et al. explain that there are three types of shortest-path problem15:

• Single-destination shortest-paths problem: Find a shortest path to a

given destination t from all other vertex excluding t

• Single-pair shortest-path: Find a shortest path from s to t

• All-pairs shortest-paths: Find a shortest path from s to t for every pair of

vertices s ant t

It has been chosen to only investigate the Single-pair shortest-path problem

2.4.2.1 Dijkstra's algorithm It has been found that there are two main algorithms which are used in path finding

algorithm: Dijkstra’s algorithm and the A* search algorithm. Dijkstra is mostly used in

networking whereas A* is mostly used in A.I and games.

Dijkstra’s algorithm was created by a Dutch computer scientist Edsger Dijkstra in

1959. This algorithm solves the single-source shortest path problem for a graph with

non negative edge path costs, outputting a shortest path tree.16

13-15 H. Cormen, T. et al. (2001) Introduction to Algorithms, MIT Press, pp.580 -1083 14 L. Gross, Johnatan & Yellen, Jay (2006) Graph Theory And Its Applications, CRC Press, p.180 16 Wikipedia (2008) Dijkstra's algorithm Available from: http://en.wikipedia.org/wiki/Dijkstra's_algorithm [accessed 20th February

2008]


24

Cahn explains the algorithm’s steps as follow:

1. “Mark every node as unscanned and give each node a label of ∞

2. Set the label of the root to 0 and the predecessor to itself. The root will be the only node that is its own predecessor

3. Loop until you have scanned all the nodes

a. Find the node n with the smallest label. Since the label represents the distance to the root node we call it d.min

b. Mark the node as scanned

c. Scan all the adjacent nodes m and see if the distance to the root through n is better than the distance stored in the label of m. If it is, update the label and update pred[m]=n

4. When the loop finishes, we have a tree stored in a pred format rooted at root.”17

Black outlines the fact that the runtime complexity of Dijkstra’s algorithm depends on

how the priority queue is implemented: “A naive implementation of the priority queue

gives a run time complexity O(V²), where V is the number of vertices. Implementing

the priority queue with a Fibonacci heap makes the time complexity O(E + V log V),

where E is the number of edges.”18

To conclude, Dijkstra’s algorithm can solve shortest path problem on graph where all

edge weights are greater or equal to zero. More importantly this algorithm can

retrieved every path from a give start point s to all other Vertices. As the problem is to

resolve single-pair shortest-path, Dijkstra is not suitable. Plus, Dijkstra can only run

properly in a weighted directed graph and this is not the case of Edinburgh map.

Finally, Dijkstra algorithm runtime complexity makes it a poor candidate for a web-

based application;

17 Cahn, Robert, (1998) Wide Area Network Design: Concepts and Tools for Optimization, Morgan Kauffman, p.67 18 Black, P. (20th September 2006.) Dictionary of Algorithms and Data Structures Available from:

http://www.nist.gov/dads/HTML/dijkstraalgo.html [accessed 20th February 2008]


25

2.4.2.2 A* search algorithm A * search algorithm was first described by Peter Hart, Nils Nilsson and Bertrand

Raphael19. A* searches a routes from a given node by expanding the node with the

lowest f(x) value where f(x) is a distance-plus-cost heuristic function which estimate

the cost of an optimal path from a node s to a destination t through n nodes. This

function can be expressed as f(n) = g(n) +h(n) where:

• g(n) is the estimate cost from the start node to the candidate node

• h(n) is the estimate cost from the candidate node to the end node (also called heuristic)

The choice of the heuristic is problem dependent. Indeed, A* behaviour is highly

influenced by the heuristic that is why the heuristic should never over-estimate the

real cost of the path because it would lead to making the algorithm expands nodes

exponentially (function of the length of the path). When the heuristic chosen is the

exact cost of the path, the number of nodes expanded should not grow faster than

the logarithm of the perfect heuristic.20

Finally, Judea Pearl defines heuristics as “criteria, methods or principles for deciding

which among several alternative courses of action promises to be the most effective

in order to achieve some goal”.21

To conclude, A * is the most suitable algorithm for best route in a web-based

application. Indeed, by estimating the cost of a choice, it speeds up the process of

finding a route. With a good heuristic, the runtime complexity is admissible as it is

logarithmic.

19 Hart, P., Nilsson, J. & Raphael, B. (1968) A formal basis for the heuristic determination of the minimum cost paths, IEEE

Transactions on Systems Sciences and Cybernetics 20 Russel, S.J & Norvig, P. (2003) Artificial Intelligence : A modern approach, Prentice Hall, p.101 21 Pearl, Judea (1985) Heuristics: Intelligent search strategies for computer problem solving, Addison-Wesley,p.3


26

2.4.2.3 Ant Colony Optimisation “The neglect of ants in science and natural history is a shortcoming that should be remedied, for they represent the culmination of insect evolution, in the same sense that human beings represent the summit of vertebrate evolution”22

Ant colony optimisation (ACO) is a metaheuristic introduced by Marc Dorigo in his

PhD thesis23. Marc Dorigo states that “ant colonies have a built-in optimization

capability: by the use of probabilistic rules based on local information they can find

the shortest path between two points in their environments”24. It can be underlined

that this metaheuristic is based on real ants’ behaviour.

Real ants’ behaviour:

Social insects such as ants are highly structured within specific organisation which is

the ant colony. Indeed, ants can achieve complex tasks by coordinating their

behaviour. This coordination is done by using an indirect form of communication

which is the modification of their environments. This type of communication is called

a “stigmergy”25.

When foraging for foods, ants move randomly until they reach a food location. They

deposit pheromone along the route that they use to reach the food location. Real

ant’s have three type of pheromones: route pheromone, help pheromone and food

pheromone.26 On their way back, they deposit a food pheromone which will attract

other ants. After a certain time, pheromones evaporate and tend to evaporate more

quickly in longer path while attracting ants in shorter path. After a while, only the

shortest path contains pheromone, so ants have found the shortest point from one

point to another. This behaviour has been observed by Goss et al. in the double

bridge experiment.27

22 Hölldobler, B. and Wilson, E. (1990). The Ants. Springer Verlag, Berlin, Germany

23 Dorigo, M. (1992) Optimization, Learning and Natural Algorithms, PhD thesis, Politecnico di Milano, Italy. 24-25 Dorigo, M. & Stützle, Thomas (2004) Ant colony optimization, MIT Press, p.7

26 C’est pas sorcier (200?), Fourmis formidables [video], France 3 production 27 Goss, S, Aron,S. Deneubourg, J.L & Pasteels, J.M (1989) Self-organised shortcuts in the Argentine ant, Naturissechaften


27

Fig 2.12: Double bridge experiment 28

The double bridge experiment:

• a: Experimental set-up

• b: Distrubution of ants that selected the shorter branch over a set of

experiments

• r: is the quotient between the short branch and long branch. r =2 means that

the longer branch is twice bigger than the short branch

• n: number of experiments

“The left graph (14 experiments) represents experiments in which both branches

were presented simultaneously. The right graph (18 experiments) represents

experiments in which the shorter branch was presented to the colony 30 minutes

after the longer branch: the shorter branch is not selected and the colony keeps on

exploiting the longer branch.”29

2828 Bonabeau,E., Dorigo, M. & Theraulaz, J. (16th July 2000) Inspiration for optimisation from social insect behaviour, Nature

406 , Available from:http://www.nature.com/nature/journal/v406/n6791/box/406039a0_bx1.html [accessed 12th April 2008]


28

Dorigo et al. finally state that ant’s behaviour can not be directly adapted as they

deposit pheromone on the “foraging” and “going back to nest locus” may generate

loops while building solution. So they describe a three step algorithm for solving the

single-pair shortest path problem. This algorithm is called SACO for Simple Ant

Colony Optimisation:30 This algorithm works iteratively by generating solutions of the

problem (e.g. a path is found) and evaporating pheromones. After a while, an optimal

solution is discovered.

• Probabilistic forward ants and solution construction: Ants forage for food using

a probabilistic behaviour for choosing a node. This behaviour is a weighted

probability on the amount of pheromone on each neighbour of the current

node in which they are. On forward mode, ants do not deposit pheromone in

order to avoid formation of loop. An ant will move from node i to node j (edge

i,j )with the probability:

Fig 2.13: Probability of an ant move

Where,

“ τij is the amount of pheromone on edge i,j

α is a parameter to control the influence of τij

ηij is the desirability of edge i,j (a priori knowledge, typically 1/di,j)

β is a parameter to control the influence of ηij”31

• Deterministic backward ants and pheromone update: Ants memorise the path

used to get to the food destination. In backward mode, the use the memorised

path and update pheromone on the each edge they use. Pheromone update is

a function of the length of the edge i,j

3030 Dorigo, M. & Stützle, Thomas (2004), Ant colony optimization, MIT Press, pp.11-13


29

The following formula is used for pheromone update:

τi,j = ρτi,j + ∆τi,j

where,

“ τi,j is the amount of pheromone on a given arc i,j

ρ is the rate of pheromone evaporation

and ∆τi,j is the amount of pheromone deposited, typically given by

Fig 2.14: Formula of the pheromone deposit amount

where Lk is the cost of the kth ant's tour (typically length).”32

• Pheromone evaporation: pheromone evaporation avoids quick convergence to

a suboptimal solution. Typically, the pheromone evaporation is a fixed rate (1-

p) where p € (0,1].

τi,j = (1-p) τi,j

Dorigo et al. have demonstrated that ants’ ability for solving the single-pair shortest-

path problem can be used in information technology. By creating artificial ants which

emphasis real ants’ capabilities and by modifying their behaviour (e.g. no pheromone

update on forward mode) they have created an algorithm called Simple Ant Colony

Optimisation. But they insist on the fact that this algorithm can only be efficient on

very simple graph but remains very accurate.

32 Dorigo, M. & Stützle, Thomas (2004) Ant colony optimization, MIT Press, p.14


30

2.5 Conclusion The literature review has mainly focused on routing algorithms. In order to define a

context for the project, web-based applications have been studied and it has resulted

that the Google Map Api is the most suitable software to evaluate the project against,

because of its geographic coverage.

Then, it has been demonstrated that the KML format is not the only geographical

format used in web-based software. Indeed, Ordnance Survey provides free data

about the United Kingdom for UK students. That is why this format has been chosen

as a primary resource. The choice of this format implies pre-processing in order to

makes the GML file received fits the requirement of the project. This pre-processing

is the creation of a GML to MySQL translator.

Finally, an investigation on routing algorithms has been made and it has resulted on

the selection of two candidates for developing web-based best route software. The

first candidate is the A * algorithm which offers a good computation time as it uses

heuristics but an approximate solution for the single-pair shortest path problem. The

second candidate is the SACO algorithm which offers an accurate solution for the

single-pair shortest path problem but is computationally not optimal. The main

question that has risen from this literature review is: how can A * be implemented for

a web-based software using the GML data? And above all, is there any way of

combining A * for the speed of calculation and SACO for the accuracy of the solution.


31

3 Methodology

Simplicity is the ultimate sophistication – Leonardo da Vinci

From the beginning of the project, it has been important to define a clear strategy of

work. Indeed, as this project is an experimental investigation on routing algorithms a

very specific way of planning and implementing the project has been chosen. The

planning of work has been mostly influenced by the software engineering

methodology used which is: extreme programming.

3.1 Software engineering methodology: Extreme progr amming Extreme programming is a software engineering methodology creating by Kent Beck,

Ward Cunningham and Ron Jeffries in 1996 when they were working on the “C3”

project at Chrysler. This methodology was officially born in 2000 with Kent Beck’s

book: Extreme Programming Explained: Embrace Change.33

Kent Beck (2008) explains what really matters in software engineering34 and defined

the following steps as vital:

• “Coding: At the end of the day, if the program does not run and make money for the client, you have not done anything

• Testing: You have to know where you’re done. The tests tell you this. If you’re smart, you’ll write them first so you know the instant you’re done. Otherwise you stuck thinking you maybe might be done, but knowing you probably not, but you’re not sure how close you are

33 Beck, Ken (2000) Extreme Programming Explained: Embrace Change, Addison-Wesley 34 Beck, Ken (2008), What really matters? Available from: http://c2.com/cgi/wiki?ExtremeProgramming [accessed may 3rd 2008]


32

• Listening: You have to learn what the problem is in the first place, then you have to learn what numbers to put in the tests. You won’t probably know this yourself, so you have to get good at listening to clients – users, managers and business people.

• Designing: You have to take what your program tells you about how it wants to be structured and feed it back into the program. Otherwise you’ll sink under the weight of your own guesses.”

Here is how each component has been adapted to the project:

• Coding:

o The supervisor has been always available

o Code was written agreed to standard

o Unit was first decided before coding

o Integration was often done

o Optimisation was left until last

• Testing:

o All produce code had unit test

o Acceptance tests were run often

• Designing:

o Design has been kept as simple as possible

o No functionality has been added early

o Design has always been reused whenever it was possible

• Listening:

o Supervisor point of view was always taken into account

All those elements have influenced how the work has been planned.


33

3.2 Planning As extreme programming works by iterative step, it has been decided that aims and

objectives were weekly defined. In order to do so diary sheets (see Appendix 3) have

been used to record weekly activity.

Fig 3.1: Extreme programming applied to the project


34

4 A * algorithm: experimental evaluation

“You can choose a ready guide In some celestial voice If you choose not to decide You still have made a choice You can choose from phantom fears and kindness that can kill I will choose a path that's clear I will choose free will.” – Rush, Free Will The first iteration of the extreme programming process was to implement, test and

evaluate the A* algorithm. In order to do so, a GML to MySQL 5 translator have been

created to transfer GML data into the MySQL 5 database. Then, the A * algorithm

has been implemented in PHP and evaluated against Google Map API.

4.1 Requirements The extreme programming process has imposed the definition of test cases before

the implementation. Three points had to be checked. The first one is that GML data is

correctly translated into the MySQL database and the algorithm can retrieve data

from it. Then that the algorithm calculates a route. Finally it is important to check that

the route can be displayed using the Google Map API in order to quickly evaluate the

accuracy of the solution produced.

Table1: Test case 1

TestID: FCN Pre-required Test: none

Corresponding requirement:

Name: Finding Corresponding Nodes

Test purpose: This is to test if the algorithm founds corresponding nodes to a street name entered in a specific form (start and end node)

Description: A street name is entered in the search route form

Expected result: A corresponding node is found for each street name

Comments:


35

Table 2: Test case 2

TestID: FR Pre-required Test: none


Name: Finding Route

Test purpose: This is to test if the algorithm founds a route between two nodes

Description: Two streets name are entered in the form

Expected result: A route is found, the algorithm retrieves all the nodes which make the route, the length and calculation time is also displayed

Comments:

Table 3: Test case 3

TestID: DR Pre-required Test: none


Name: Displaying Route

Test purpose: This is to test if the route is properly displayed on Google Map

Description:

Expected result: The route is displayed on Google Map

Comments:

4.2 Design As seen in the literature review, no candidate software for translating Osmastermap

data to a MySQL has been found. The GML file provided by Ordnance Survey was

500 megabytes large. It was necessary to develop a package able to do the

translation as the parsing of 500 megabyte GML in PHP costs 12 minutes

The GML file contains information about object which represents topographic

structure such as “Road”, “RoadNode” and “RoadLink”, “RoadLink” etc. The

interaction between geographical objects is given by XSD schemas supplied with the

GML file35. Geographical objects can then be represented as class to be included

into the model.

35 Note: For clarity purpose, XSD schemas are not included in this dissertation as they bring no extra knowledge. Nevertheless,

they are available at: http://www.ordnancesurvey.co.uk/oswebsite/xml/schema/index.html


36

Fig 4.1: Table and relationships created in the MyS QL database

.

As a reminder of the literature review, a Graph is a set of Vertices connect by Edges (

G = (V,E) ). Then the mapping of the city of Edinburgh in the GML can be assimilated

to a graph. Indeed, it has been found that the geographical “RoadNode” object

corresponds to a Vertex and these “RoadNode” are linked by Edges which are the

geographical object RoadLink.

A “Road” may contain more than one RoadLink. A “RoadLink” is defined by two

nodes and a length attribute. An association table is used to link “RoadLinks” to a

“Road” which is the “NetworkMember” geographical attribute contained in the Road

object.

It can be concluded that the representation of the city of Edinburgh in the GML file

corresponds to a undirected weighted graph which will be annotated Ge = (N,L)

where Ge is the city of Edinburgh, N a set of geographical objects “RoadNode” and L

is a set of geographical objects “RoadLink”. The design as imposed by the extreme

processing was very simple and conducted by geographical features available in the

GML file; again, simplicity of designing has been chosen.


37

4.3 Implementation

4.3.1 Code structure The code structure has been defined by the overall architecture of the application

and how geographical objects are linked in the GML file. It has been decided to

implement each geographical object as a PHP class.

4.3.2 GML Parsing and Translation to MySQL 5 PHP offers tools to parse very big XML36 file. Elliot Rusty Harold explains how to use

the XMLReader bundled with PHP5 library37. This library reads an xml file in

streaming and stops at each node. From that, with the right PHP structure, the

implementation has been very straightforward.

Fig 4.2 Pseudo code of the GML to MySQL translation Open GML file Skip root node While not end of file reached move cursor to next n ode If specific geographical element reached Create an PHP instance of the appropriate geogr aphical object For node start to end node Get attribute of child node Set attribute to the geographical object End for Save object in the MySQL database End if End while

The implementation of this tool is available on the sourceforge.net 38 website as a

PHP package. A sample file (Port Talbot)39 supplied by. Ordnance Survey is also

included.

Fig 4.3: Screenshot of Sourceforget.net

36 Reminder: GML is the XML grammar defined by the Open Geospatial Consortium to express geographical features. 37 Harold Rusty, Elliot (2007), Pull parsing XML in PHP: Create memory-efficient stream processing Available from:

http://www.ibm.com/developerworks/library/x-pullparsingphp.html [accessed 23rd march 2008] 38 Note: the package is available here: http://sourceforge.net/projects/mastermap2mysql/ 39Note: Other sample data file can be found at the following address:

http://www.ordnancesurvey.co.uk/oswebsite/products/osmastermap/layers/topography/sample.html


38

4.3.3 A * algorithm implementation The implementation of the A * algorithm followed the algorithm found during the

literature review.

As a reminder, here is the basic pseudo-code of the A * algorithm

Fig 4.4: Pseudo code of A* algorithm 40 Initialize OPEN list Initialize CLOSED list Create goal node; call it node_goal Create start node; call it node_start Add node_start to the OPEN list while the OPEN list is not empty { Get node n off the OPEN list with the l owest f(n) Add n to the CLOSED list if n is the same as node_goal we have f ound the solution; return Solution(n) Generate each successor node n' of n for each successor node n' of n { Set the parent of n' to n Set h(n') to be the heurist ically estimate distance to node_goal Set g(n') to be g(n) plus t he cost to get to n' from n Set f(n') to be g(n') plus h(n') if n' is on the OPEN list a nd the existing one is as good or better then discard n' and continue if n' is on the CLOSED list and the existing one is as good or better then discard n' and continue Remove occurrences of n' fr om OPEN and CLOSED Add n' to the OPEN list } } return failure (if we reach this point we’ve search ed all reachable nodes and still haven’t found the solution, therefore one doesn’t e xist)

This algorithm imposes the implementation of structures types which are not

available in PHP such as list. Indeed the list operator in PHP constructs a simple

array41. Therefore, a ListClass has been implemented in order to offer specific

methods which are useful to the algorithm.

• Get last element

• Clean: remove redundant entries in the list

40 Tsai, Benny (2003) Introduction to the A-star algorithm Available from : http://the.jhu.edu/upe/2003/01/18/introduction-to-the-

a-star-algorithm/ [accessed 12th February 2008] 41 The PHP Group (2008) List Available from: http://uk.php.net/list [accessed 3rd May 2008]


39

• Add an element to the list

• Remove element

• Display Element: display all elements in a formatted way. When the list contains object, serialise them and display the serialisation

• Display Route: For all pairs of RoadNodes in the list, find the corresponding RoadLink

• Get Length: get the length of the route which contains all the nodes in the list

• Exist: return true if an element is in the list

Finally, here is the pseudo code of the A * algorithm using the features imported from

the GML file to the MySQL database and data structure that has been created.

Fig 4.5: Pseudo code of the implementation of the A * algorithm define an open list as a ListObject define a closed list as a ListObject define a forbidden list as a ListObject define a temporary list as a List Object define a start node as a RoadNode object define a current node as a RoadNode object define a previous node as a RoadNode object set the previous node to the start node set the current node to the start node add the start node to the closed list while the current node is not the end node initilialise the temporary list to 0 get every nodes connected to the current node a nd put them in the temporary list // a MySQL query is done to retrieve connected Node on the RoadLink table foreach node in the temporary list calculateheuristic select the one with the lowest heuristic end foreach if previousnode equals to selected node // dead en case add selected node to forbidden_list remove selected node from closed_list if size of closed_list equals 0 //heuristic was not optimal in this case start from beginning again // that time the forbidden list is set, another ro ute will be found end if else set the selected node to the last element of get list // moving back end else end if else // normal case set the previous node to current node add selected node to closed_list set the current node to selected node node end else end while


40

4.3.4 Heuristic calculation:

At each iteration of the algorithm, neighbours of the current node are retrieved. The

one with the lowest cost is chosen as a possible candidate.

As seen in the literature review, estimate cost path is function of the distance from

the start node to the candidate node and from the candidate node to the end node.

This can be expressed by the heuristic function

f(n) = g(n) +h(n) where:

• g(n) is the estimate cost from the start node to the candidate node

• h(n) is the estimate cost from the candidate node to the end node (also called heuristic)

Let’s define g*(n) as the optimal cost from the start node to the candidate node and h*(n) as the optimal cost from the candidate node to the end node.

So the optimal cost function can be defined as f*(n) = g*(n) + h*(n). It was necessary

to find a function f(n) that closely estimate f*(n). As f(n) is mostly influenced by the

heuristic h(n), the choice of this heuristic had to be done carefully. Amit Patel defines

the Euclidean distance as being the best candidates in graph where the algorithm

can move at any angle (a non-gridded map) which is exactly the case for Ge(N,L)42.

Indeed, to be admissible and computationally optimal, A* should never over-estimate

the minimal cost of reaching the goal43. The Euclidean distance will always be less or

equal to the minimum cost.

42 Patel, Amit (24th February 2008). A*’s use of Heuristic Available from:

http://theory.stanford.edu/~amitp/GameProgramming/Heuristics.html [accessed 4th May 2008] 43 Couprie Michel (2008). Graphes et algorithmes: Notes de cours et exercices, ESIEE Paris, p.55


41

4.4 Testing

4.4.1 Assumption

The test platform was a 1.83 GHz laptop with 2 GB of memory. The OS in which the

laptop was running on was Windows Vista. It is important to mention the Operating

System has a limitation of 50% of the CPU for a process is done by it.

15 routes were tested on this test. The choice of route was made by random criteria

for 5 cases, routes that are less than 1.5 miles on 5 cases and connected roads on 5

cases. The maximum execution time of the script was set to 120 seconds. It is

assumed that after 120 seconds the algorithm has failed reaching the destination

node. Units used are seconds for the execution time and miles for the route length.

In order to evaluate every components of the algorithm, a table with defined test

cases has been draw. It has also been observed that querying the MySQL database

and the number of dead ends encountered by the algorithm played an important role.

So two counters have been added to the algorithm, the first one evaluate the number

of time the database has been queried, the second one, how many dead ends have

been encountered.

Finally, as it has been shown in the literature review, the Google Map API only

retrieves driving direction and the A * implementation that have been done retrieve

the walking route. Most of the time Google Map API uses direct route but it happens

that retrieved routes can be diverted in which case the length of the route given is not

the optimal walking path.


42

4.4.2 Results (Please Appendix 4 for detailed test cases) Fig 4.6: Relation between the number of executed qu eries and the execution time

0

10

20

30

40

50

60

70

80

90

100

0 100 200 300 400 500 600

# Executed Queries

Exe

cutio

n tim

e (s

econ

ds)

query

Fig 4.7: Relation between the length of the calcula ted route and the execution time

0

10

20

30

40

50

60

70

80

90

100

0 1 2 3 4 5 6 7 8

Length(miles)

Exe

cutio

n T

ime

(sec

onds

)


43

Fig 4.8: Relation between the number of dead ends e ncountered and the number of executed queries

0

100

200

300

400

500

600

0 50 100 150 200

Dead ends encoutered

Que

ry E

xecu

ted

Fig 4.9: Comparison of the length of calculated rou te by Google and A * (the x axis represents the solution number)

1 2 3 4 5 6 7 8 9 10 11

A * length

Google length


44

4.5 Evaluation

The evaluation of the implementation of the A * algorithm has been focused on three

parameters: stability, accuracy and execution time.

4.5.1 Algorithm stability The program has run 15 times and has failed 4 times. It has been assumed that the

algorithm has failed when the calculation time exceed 120 seconds. So the

implementation of the A* is not stable as it only retrieves 74% of routes.

It can be seen that the algorithm failed reaching the destination node most when the

route was less than 1.5 miles which means that either the heuristic over-estimate the

real cost of reaching the destination node or the map shape is particular and leads to

very long calculation. As a reminder of the literature review, A * is influenced by the

map shape and it occurs that A * will not find the best routes quickly has it will

expand every nodes in the area.

4.5.2 Algorithm accuracy It was important to evaluate the accuracy of the algorithm solution against Google

Map. It can be underlined that an exhaustive search could have been used in order

to find the optimal path and evaluate the algorithm against it. But, Shum & Liao

emphasis the fact that exhaustive search is computationally expensive44. So it has

been decided, as imposed by extreme programming, to use the method which was

simpler and less time expensive: the Google Map evaluation. As Google Map uses

driving directions, the result is admissible when the length is less or equal to

Google’s.

It can be seen on figure 4.8 that on the 11 cases that worked, the algorithm retrieved

accurate result as they are the length is less or equal to Google Map length.

44 Shum, Heung-Yeung & Liao, Mark (2001) Advances in Multimedia Information Processing-PCM 2001, Springer, p.732


45

Nevertheless, accuracy could be improved by making the algorithm avoiding the fact

that it leaves a main road to get back to it later. In some case this could be seen as a

shortcut, in other cases this causes the algorithm to use diversion which dramatically

increases the length of the solution (see figure below)

Fig 4.10: Diversion on a calculated node

4.5.3 Algorithm execution time The execution time (given in seconds) has a limit of 120 seconds. On figure 4.7 it can

be seen that the execution is very high in terms of computational time and

comparatively to Google Maps. It can be also seen on figure 4.6 that the execution

time is closely related to the number of MySQL queries executed. Finally, figure 4.8

gives the close relation between dead ends encountered during the calculation of the

route and the number of MySQL queries executed. In order to improve the execution

time, database querying had to be limited as much as possible.


46

4.6 Conclusion

To put everything in a nutshell, the A * algorithm, when used with a good heuristic,

gave very good results in terms of accuracy results. But as Ge is particular graph with

lots of dead ends and as it has been demonstrated that the calculation time is closely

related to the number of dead ends encountered, the heuristic chosen is not good

enough on very particular cases. The number of dead ends encountered in the

calculation is also closely related to the number of MySQL query executed. A MySQL

query is computationally cost effective in comparison with pre-loaded graph. Another

caching mechanism had to be implemented in order to improve runtime execution.

As seen in the literature review, A * algorithm behaviour is mostly influenced by the

heuristic function. A mechanism to adapt the heuristic to the shape of the area of Ge

used during the calculation has to be developed. Then it has been demonstrated that

A * tends to expand nodes when there is no need to do it as a more direct path could

be used. A mechanism for refining the route when this occurs has to be also

implemented.


47

5 Self Adaptive A * algorithm using Simple Ant Colo ny Optimisation (SACO)

“Do not go where the path may lead; go instead where there is no path and leave a trail” – Ralph Waldo Emerson (1803-1882) The second iteration of the extreme programming process has leaded the

development to investigate how the first iteration could be optimised in terms of

execution time and accuracy. In order to do so, the caching problem has been

investigated further with graph partitioning which offers the possibility to only load

used part of Ge. Then an investigation on code structuring and efficiency has been

made in order to improve calculation performance. Finally, the Simple Ant Colony

Optimisation (SACO) described by Dorigo45 was implemented in order to make the

A* algorithm having an adaptive behaviour by using many heuristics and selecting

and refining the one which gave the best solution. The SACO structure has also been

used to run on optimised (in term of caching, coding, structure) A * algorithm with the

Euclidian distance as heuristic. So in this second iteration, two different algorithms

have been implemented using the same code structure.

5.1 Requirements As imposed by the extreme programming process, test cases have been defined at

the beginning of the implementation. To evaluate optimisations that have been made,

same tests cases as defined in the first implementation have been used. As the data

structure has been changer. A first evaluation of the optimised A* algorithm will be

made. Then an evaluation of the optimised A * with SACO will done.

New data have been ordered from the Ordnance Survey website: postcode data.

Indeed, it has occurred that a segmentation of Edinburgh has already been made.

The simpler solution has been to use this type of segmentation. The data was in a

CSV file, so a mechanism has been implemented to import the data.

45 Dorigo, M. & Stützle, Thomas (2004), Ant colony optimization, MIT Press, p.12


48

5.2 Design The first system design was kept, but some features have been added in order to

fulfil requirements previously defined. The first feature added was a MySQL table

which contains data about postcode. Then an association table has been created in

order to link a RoadNode to a postcode.

Fig 5.1: Postcode table and attributes

Attributes of the “PostCode” table are given by Ordnance Survey via the definition of

the CSV file. Finally, is important to underline that a “PostCode” is geographically

defined by coordinates which are “Eastings” and “Northings” attribute. These

coordinates represents a point which is the centre of the postcode.


49

5.3 Implementation

5.3.1 Code structure The code structure was guided by new requirements previously defined. The new

design has imposed the creation of a CSV to a MySQL database translator. A PHP

object called SegmentationController has been created in order to emphasis the

reuse of the translator. For each component of the SACO described by Dorigo &

Stützle46 a PHP object has been created (queen, ants, and colony). Please refer for

to Appendix 5 for the full documentation of the code (class, methods etc.).

5.3.2 PostCode segmentation The first step was to import data from the CSV file to the MySQL database. In order t

to do so, the CSVReader librairy created by Nicolas BUI47 (GNU licence) have been

used to parse the CSV file and save it using PHP.

Therefore it was necessary to link the “RoadNode” table with the “PostCode” table. A

simple script has been used:

Fig 5.2: Pseudo code of the algorithm which links a node to a postcode load every RoadNode in a list load every PostCode in a list end is false foreeach element in the list foreach postcode in the PostCode list and not e nd calculate the distance with every postcode if distance less than 30 meters //speed up the process by ending the loop when the candidate is good enough pick up postcode end is true end if end foreach pick up the postcode which is the closest to th e road node save the association into the MySQL association table end foreach

46 Dorigo, M. & Stützle, T. (2004) Ant colony optimization, MIT Press, p.1 47 Bui, Nicolas (2002). CSVReader Available from: http://www.phpclasses.org/ [accessed 24th April 2008]


50

5.3.3 Adaptive A* with SACO and Optimised implement ation of A* For the implementation of the SACO algorithm in PHP the Dorigo & Stützle book48

has been mostly used as a primary material as Marc Dorigo is the creator of SACO.

As seen in the literature review SACO necessitates the use of specific entities such

as ants and queen. In order to represent as closely as possible the real ant

behaviour, PHP class have been created representing a real colony (Please refer to

Appendix 5 for detailed documentation)49.

Fig 5.3: PHP class that have been created for SACO object PHP class interaction

AntGrid AntColony

AntQueen

AntForager AntScout

An AntGrid represents one or more partition of Ge, when an instance of this class is

created, by passing in parameters either two addresses or one postcode, an instance

of AntColony is also created. Actually, an AntGrid can create more than one colony

and can also solve the single destination shortest path problem. Then the AntColony

is placed at the start point. The AntColony instantiates an AntQuenn. This AntQueen

will then instantiates two types of Ant. The first type is the AntForager which behave

as a normal ant as seen in the literature review. The second one is called AntScout

and knows where the destination is and uses a heuristic to reach it quickly. The

AntGrid object tells the AntColony if it has to use SACO feature or not. If yes, the

48 48 Dorigo, M. & Stützle, T. (2004) Ant colony optimization, MIT Press, pp 1-24


51

implemented algorithm behaves exactly as described, else, the implemented

algorithm behaves as the first implementation of A * algorithm except that the code

has been optimised in terms of structure and caching. Indeed to improve the caching

and avoid querying the database often, it has been decided that links between nodes

in a specific postcode would be stored in a file as a serialised object. The

serialisation is the process of transforming object in a human-readeable format

(string)50. Links between nodes are calculated and cached just one time by passing

the right parameters to AntGrid.

5.3.3.1 General Pseudo code used by both algorithm

Fig 5.3: Pseudo code of the creation of serialised object in a file create an instance of AntGrid create a nodes list as list create an associative array node neighbour as array // node ID => list of neighbours retrieve all nodes on the postcode put them in node s list foreach nodes in nodes list create a neighbour list query database to find neigbours put neighbours in the neighbour list add element to nodes neighbours array end foreach save serialisation of nodes neighbour as a file

Fig 5.4: Pseudo code of the AntGrid object create an instance of AntGrid set start and end point as RoadNode object get postcode of start and end point from database retrieve postcode files unserialise array stored in file as nodes neighbour s array create an instance of AntColony with start, end poi nt and nodes neighbours array pass to AntColony the mode in which the algorithm s hould start wait for best solution to be retrieved display best solution

50 The PHP Group (2nd May 2008) Serialize Available from: http://uk3.php.net/serialize [accessed 4th May 2008]


52

5.3.3.2 Optimised implementation of A* The optimised implementation of A* acts exactly as the implementation done in the

first iteration of the extreme programming process. It has occurred that it was more

convenient to merge both algorithms (A* and SACO) into one implementation. So an

object Ant is used to retrieve a route using a heuristic.

5.3.3.3 Adaptive A * with SACO The adaptive A * with SACO implementation uses features of both algorithm to

combine speed and accuracy (relatively as it will be demonstrated in the evaluation).

An implementation the real SACO algorithm has been made at first place but it has

occurred that the runtime complexity was a function of the number of ants used and

the number of iteration of the algorithm. Ge is a very big graph (20327 nodes) in

comparison with the graph used by Dorigo & Stützle51 which contains 18 nodes so

the comparison was not obvious. Even with partition of Ge, the calculation of routes

between two adjacent postcodes involve for the minimum case 500 nodes. It has

been decided to use the propriety of A * to speed up the building of the first solution

of SACO in order to guide other ants. To do so, the first solution is generated with 4

scout ants which have a specific heuristic to reach the destination: Euclidian distance

and Manhattan distance used in different way. The ant which reached food first has

the best heuristic for the shape of the graph; this first solution is then picked up. On

its way back, it updates pheromone along the route according to default value for

pheromone updating seen in literature review. Then, forager ants are created and

move using a probabilistic behaviour weighted by pheromone along the path created

by the scout ant. When a solution is created, the pheromone evaporation rate is

applied. They eventually refine the route depending on the number of iterations of

the algorithm specified in the code.

51 Dorigo, M. & Stützle, T. (2004) Ant colony optimization, MIT Press, p.16


53

To conclude, the same implementation has been used for two algorithms in order to

facilitate the evaluation of them on the same platform and using the same data

structure.

5.4 Testing

5.4.1 Assumption As the second step of the extreme programming process tends to optimise the first

step, same test cases have been used to comparatively evaluate the quality of the

solution found by the algorithm. A first test was made on the optimised A * without

SACO in order to evaluate the quality of the data structure and code optimisation.

Then adaptive A * with SACO has been evaluated against the previous two

implementation. As SACO behaviour is highly influenced by variables which are the

amount of pheromone which is deposit by an ant, the number of ants used and the

pheromone evaporation rate, it was also important to compare this implementation of

SACO with Dorigo & Stützle experiment52. Finally, there is no need to evaluate the

number of MySQL queries executed as it is a know number: 2. Indeed, the caching

used only requires loading 2 Roads object from the database (start and end point).



54

Results (Please refer to Appendix 6 for detailed test cases)

5.4.1.1 Optimised A * without SACO Fig 5.5: Relation between the length of the solutio n and the execution time

0

0,5

1

1,5

2

2,5

3

3,5

0 1 2 3 4 5 6 7 8 9

Length(miles)

Exe

cutio

n tim

e(se

cond

s)

Fig 5.6: Comparison with Google’s results on same t est cases

0

2

4

6

8

10

12

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Test case

Leng

th(m

iles)

Google length

Optimised A* without SACO


55

Fig 5.7 Comparison between the first implementation accuracy and the optimised implementation

0

1

2

3

4

5

6

7

8

9

1 2 3 4 5 6 7 8 9 10 11

Test case

Leng

th(m

iles)

A * length


5.4.1.2 Optimised A * with SACO S-ACO was set to use a pheromone evaporate rate equal to 0.1. A fixed number of

iteration was used. It has been empirically demonstrated that each iteration of the S-

ACO algorithm takes 3 seconds with 15 foragers. So the number of iteration has

been set to 2 with 15 foragers.

Fig 5.7 Comparison between solution accuracy

0

1

2

3

4

5

6

7

8

9

Test cases

Leng

th(m

iles)


Optimised A * with SACO


56

It has also been noticed for the Optimised A* with SACO that for 2 iterations with 15

ants and a pheromone rate set at 0.1, the average execution time was 9 seconds.

Fig 5.8 Pheromone trail for the route from Ritchie place to Colinton road

Fig 5.9: On the left, the result of Optimised A* wi th SACO, on the right Google’s


57

5.5 Evaluation New data structures have been created for the single-pair shortest-path problem in

order to optimise every aspect of the code (e.g. array, list). The aim was to reduce

the complexity of each operation made by the algorithm. For instance to create

structure which permits direct access to data avoiding looping in order to reduce an

O(N log N)53 complexity to 1 for a single operation such as selecting all neighbours of

a node. All of those little improvement has reduce the overall execution time of both

algorithms (Optimised A* with and without SACO). Finally, the graph of the city was

stored as many serialised objects (postcode) in files and loaded when needed. The

object stored contained all information needed for the Graph (Nodes, links, length,

links to neighbours).

5.5.1 Algorithm stability Both algorithms have resolved all single-pair shortest-path problems (15 cases).

5.5.2 Algorithm accuracy In comparison with the first implementation of the A* algorithm, both Optimised A*

with and without SACO are not as accurate as the first implementation. This is due to

the accuracy of the loaded graph. Indeed the graph loaded in memory is not as

accurate as expected as it regroups many postcodes. The choice of which postcode

has to be loaded in memory was straightforward: all postcodes from addresses one

to addresses two. This was not the best solution and a routing table should be

implemented in order to store the real postcode path from one postcode to another.

Nevertheless, Optimised A* with SACO was at least as accurate as Optimised A*. In

figure 5.7 it can be seen that solution length remains the same for both algorithm. But

on one case Optimised A* with SACO is far better than Optimised A* and only with

two iterations of the algorithm. Unfortunately it has been observed that SACO can

sometimes converge too quickly on suboptimal path.

53 Note: N number of element in the structure (array, list)


58

5.5.3 Algorithm execution time Both Optimised A* with and without SACO has run in optimal execution time for the

context of a web based application and in regards to the first implementation of the

A* algorithm. 3 seconds was the maximum time to retrieve a route for Optimised A*.

9 seconds was the average time to retrieve a route for Optimised a* with SACO as it

calculates exactly 3 routes (the first solution with heuristic and two others using

SACO and probabilistic move.

5.5.4 Conclusion To conclude on this second iteration of the extreme programming process, it has

been demonstrated that A* algorithm is the perfect candidate for solving the single-

pair shortest-path problem in a web-based application which confirmed what has

been found in the literature review. But A* requires pre-processing that have to be

done carefully: appropriate data structure and implementation, pre-load of the graph.

The algorithm remains accurate while being quick in most of the case. But A* is

highly influenced by the heuristic, so an adaptive A* has been created using SACO. It

has been demonstrated that this new implementation is more accurate that the first

implementation but the runtime is three times more expensive. Indeed, it has been

empirically found that complex object in PHP such as the ones created (ants, queen

etc.) are memory expensive. A simple script have been used in order understand the

link between the numbers of Ants created and memory peak and it has occurred that

with only 15 ants, the memory usage was 200 megabytes. This is due to the fact that

each ant needs to know the exact status of a graph (pheromone update, food left) at

an instant t. So each ant object has a private attribute that represents the graph. As

the method for retrieving postcode is not optimal, it has occurred that the private

attribute for each ant was far too heavy in memory. That is why only 15 ants with 2

iterations have been used for the test case, but Dorigo & Stützle explain that the

more ant there is on the graph, the more accurate will be the final solution.54 Figure

5.8 and 5.9 show that on very simple graph, two iterations are enough to explore the

direct neighbourhood of the solution generated by A* and find the optimal graph.



59

So a mechanism for improving the representation in memory of the map has to be

implemented in order to fully use SACO features. Combined with A*, SACO can

increases accuracy of the algorithm and with the right pre-processing, the execution

time.


60

6 Conclusion

‘Price, Quality, Speed: Pick any two’ – Anonymous To put everything in a nutshell, this dissertation has demonstrated the importance of

choosing the right algorithm to solve a problem. Above all, it has been demonstrated

that not only the choice of the algorithm is important but also the quality of code and

data pre-processing which leads to better performance.

On the first implementation, it has been shown that A* algorithm gave good result in

terms of quality of the solution and that the cost of the implementation was closed to

null as the only pre-processing that had to be done was the GML translator.

Nevertheless the runtime execution was not good enough in comparison to what can

be done by web-based applications that use routing algorithms.

On the second implementation, it has been demonstrated that improving data

structure and how the code is implemented has lead to an improvement of the

algorithm execution time. In order to increase the quality of the solution a combined

A* and SACO algorithm have been used. In order to do so, lots of pre-processing has

been done (e.g. caching, graph partition, improvement of structure). This

implementation has brought solution which was very acceptable in terms of speed

and accuracy but its cost (in terms of coding) was high in terms of coding.


61

7 Future works

This dissertation has demonstrated that using approximate algorithm such as A* can

sometimes lead to suboptimal solution. Using a genetic algorithm such as SACO to

create inter-dependent solutions by iterative step can help improving algorithm

accuracy. The first thing that is needed to be overcome is to improve memory usage.

Then test and evaluation will be made against Google Map as the optimal

implementation would be to only use SACO without creating the first set of solutions

by A*.

During the project, many works have been started and have been solved with the

easiest solution. However, these solutions were not always the best in this context:

for instance the partitioning of the graph improves caching but leads to memory

problems. But the graph partitioning problem has been first started by using an Ant

Colony Optimisation algorithm. This partitioning is very easy to implement as it uses

forager ants behaviour by placing foods on all nodes of the map and creating many

ant colonies which compete for food. They eventually segment the graph in area

which contains the same number of nodes. To simulate such behaviour, parallelised

computing can be used. Unfortunately, the author’s available computing power was

not enough so this unfinished implementation was postponed for future works.

Then Ant Colony Optimisation is also famous for having solved NP-Hard problems in

polynomial time such as the Travel Salesman Problem. The author has applied for a

research degree in genetics algorithm in the context of GIS. In order to be prepared

for that and as long as the copyrighted data is available, an implementation of the

TSP will be made in order to understand how a NP-Hard problem could be solved in

polynomial time.

Finally, this dissertation has only treated the single-pair shortest-path problem on an

undirected weighted graph. A modification of implemented algorithms will be made in

order to include driving directions, turn restrictions and other features that change the

problem’s complexity.


62

References

Books: Beck, Ken (2000) Extreme Programming Explained: Embrace Change, Addison-Wesley Cahn, Robert, (1998) Wide Area Network Design: Concepts and Tools for Optimization, Morgan Kauffman Diestel, R (2005) Graph Theory, Springer Dorigo, M. & Stützle, Thomas (2004) Ant colony optimization, MIT Press Goss, S, Aron,S. Deneubourg, J.L & Pasteels, J.M (1989) Self-organised shortcuts in the Argentine ant, Naturissechaften Hart, P., Nilsson, J. & Raphael, B. (1968) A formal basis for the heuristic determination of the minimum cost paths, IEEE Transactions on Systems Sciences and Cybernetics H. Cormen, T. et al. (2001) Introduction to Algorithms, MIT Press Hölldobler, B. and Wilson, E. (1990) The Ants, Springer Verlag L. Gross, Johnatan & Yellen, Jay (2006) Graph Theory And Its Applications, CRC Press Pearl, Judea (1985) Heuristics: Intelligent search strategies for computer problem solving, Addison-Wesley Russel, S.J & Norvig, P. (2003) Artificial Intelligence : A modern approach, Prentice Hall Shum, Heung-Yeung & Liao, Mark (2001) Advances in Multimedia Information Processing-PCM 2001, Springer Video: C’est pas sorcier (200?), Fourmis formidables [video], France 3 production


63

Lecture notes: Couprie Michel (2008). Graphes et algorithmes: Notes de cours et exercices, ESIEE Paris Thesis: Dorigo, M. (1992) Optimization, Learning and Natural Algorithms, PhD thesis, Politecnico di Milano, Italy. Software: Bui, Nicolas (2002). CSVReader Available from: http://www.phpclasses.org/ [accessed 24th April 2008] Web materials: Harold Rusty, Elliot (2007), Pull parsing XML in PHP: Create memory-efficient stream processing Available from: http://www.ibm.com/developerworks/library/x-pullparsingphp.html [accessed 23rd march 2008] HopStop.com (2008) Subway Directions and Bus Directions for New York City (NYC) Available from:http://www.hopstop.com/ [accessed 13th February 2008 ] Patel, Amit (24th February 2008). A*’s use of Heuristic Available from: http://theory.stanford.edu/~amitp/GameProgramming/Heuristics.html [accessed 4th

May 2008] The PHP Group (2008). List Available from: http://uk.php.net/list [accessed 3rd May 2008] The PHP Group (2nd May 2008) Serialize Available from: http://uk3.php.net/serialize [accessed 4th May 2008] Tsai, Benny (2003) Introduction to the A-star algorithm Available from: http://the.jhu.edu/upe/2003/01/18/introduction-to-the-a-star-algorithm/ [accessed 12th February 2008] Transport for London (2008) Journey Planner Available from: http://journeyplanner.tfl.gov.uk/ [Retrieved 13th February 2008


64

Nat Torkington, N.T, 2005, Google Maps and their data provider Available from : http://radar.oreilly.com/archives/2005/10/google_maps_and_their_data_pro_1.html [retrieved18th February 2008] Google (200?) KML Tutorial Available from: http://code.google.com/apis/kml/documentation/kml_tut.html [retrieved 20th February 2008] Google (2008) Google Map Api Concepts Available from: http://code.google.com/apis/maps/documentation/ [accessed 20th February 2008] ESRI Canada (200?) Interoperability and Standards Glossary Available from http://www.geographynetwork.ca/standards/glossary.html [accessed 21 st February 2008] Open Geospatial Consortium (2008) About OGC Available from: http://www.opengeospatial.org/ogc [accessed 21 st February 2008] Ordnance Survey (2002) OsMastermap - GML (Geographic Mark-up Language Available from: http://www.ordnancesurvey.co.uk/oswebsite/products/osmastermap/information/technical/gml2.html [accessed 20th February 2008] Edina (200?) Digimap Collections Available from: http://digimap.edina.ac.uk/mastermapdownloader/Downloader?useJS=true [accessed 20th February 2008] Safe Software (2008) GIS Data Conversion & Transformation Available from: http://www.safe.com/ [accessed 20th February2008] Wikipedia (2008) Dijkstra's algorithm Available from: http://en.wikipedia.org/wiki/Dijkstra's_algorithm [accessed 20th February 2008] Black, P. (20th September 2006.) Dictionary of Algorithms and Data Structures Available from: http://www.nist.gov/dads/HTML/dijkstraalgo.html [accessed 20th February 2008] Bonabeau,E., Dorigo, M. & Theraulaz, J. (16th July 2000) Inspiration for optimisation from social insect behaviour, Nature 406 , Available from:http://www.nature.com/nature/journal/v406/n6791/box/406039a0_bx1.html [accessed 12th April 2008]


65

Appendix 1 Initial Project Overview

Title: Bus Route Planer

The aim of the project is to create an application which permits to find the best bus

route between two addresses. This application has to be a web site in the

specification. It is required in the specification to:

1. Develop an interface to allow people to enter the coordinates or

postcodes and an algorithm for identifying the bus stops nearest to the

depart and arrive points.

2. Create an algorithm for determining the fastest ro ute – this may depend

on the passenger’s walking speed.

3. Develop a mechanism for adding the PDF sources directly from web pages

into a database

4. Develop mechanism for adding the stops.txt data into a database

5. Create a connection between the PDF bus stop names and the stops.txt bus

stop names.

6. Develop tools for cleaning the existing data and adding data for other cities.

After a meeting with my supervisor, we decided to only keep the two mains points

which are 1 and 2 because I will not have enough time to make everything. Points 1

and 2 are essential for my project to be working properly. So the points 3,4,5,6 are

optional requirements that I will fit only if I have enough time.

When I was looking for a project, my first thought was to find something relating to

web technologies. Indeed, I am in Internet computing program and I have done lots

of web sites using very common technologies (PHP / MySql / JavaScript / Html). So

the very interesting thing about this project is that it deals with some technologies or

concepts that I am not very used to: combining JavaScript and Xml, Google maps

API, GPS calculus, path finding algorithms.


66

Plus, this project could be a plus in my professional life. In fact, creating a project that

could be aimed to client (the web site could be commercial), can be used in every

city in the world and created in a professional context can help me finding a job after

my degree.

Last but not least: creating a website which helps people in their life is something that

motivates me a lot.

To investigate this I will need to do a lot of research in many areas. First, I will have

to focus on route planning and path finding algorithms. Indeed, I have to be aware of

what have been already done in this area especially similar case. Then I will need to

make some research about the Google Map API which I am going to use to

represent the route. Finally, there are lots of website related to this topic which have

already implemented something quite similar to my project.

To conclude, I know that I am not investigating something new. But, I am very

interested in new technologies as AJAX and using the Google Maps API. Plus I will

have to make some researches on path finding and route planning algorithm. This

area is very interesting because I really like combining logic, mathematics and

information technologies.


67

Appendix 2 Second Formal Review Output


68

Appendix 3 Diary Sheets


69

Appendix 4: Calculation details for the first implementation of the A * algorithm


70

Road choice criteria: Random

From/To

FCN

FR

DR

Execution Time in seconds

Route Length

Google Map Time

Google Map Length

Comments

Upper Gilmore Place / Christian Crescent

PASS PASS PASS 40.1 s 5.12 < 1s 5.5

West Adam Street / Meadowbank avenue

PASS FAIL FAIL >120 undetermined

<1s 1.7 The calculation of the route tooks more than the 120 seconds limit, it is assumed that the algorithm has failed reaching the destination node

Orwell Place / St Patrick square

PASS PASS PASS 20.3 1.9 <1s 2.7

Fountainbridge / Waverley Terrace

PASS PASS PASS 86.9 7.5 <1s 10 Google Map algorithm privileges A road whereas A* algorithm cut through the city

East Mayfield / Portland Street

PASS PASS PASS 52 4.4 <1s 3.5


71

Road choice criteria: Route less than1.5 miles dist ance

From/To

FCN

FR

DR

Execution Time

Route Length

Google Map Time

Google Map Length

Comments

Ritchie Place / Coliton Road

PASS PASS PASS 6.4 0.75 < 1s 0.8 As Google Map algorithm uses driving direction, a bad direction choice is made at one intersection

Dundee street / Merchiston Park

PASS PASS PASS 5.9 0.64 <1s 0.7 miles Both routes are different but the distance is the same. Google’s one is more straightforward and minimises streets crossing

Wellington place / Tower street

PASS PASS PASS 8.2 0.63 <1s 0.6 miles Again, Google minimises street crossing.

Campbell Road / Wester Coates Garden

FAIL FAIL FAIL / / <1s 1.1 miles The destination has not been retrieved from the database

Morrison Circus / Fountainbridge

FAIL FAIL FAIL / >120 <1s 0.8miles A * has failed reaching the destination node/


72

Road choice criteria: Connected Roads

From/To

FCN

FR

DR

Execution Time

Route Length

Google Map Time

Google Map Length

Comments

Gilmore place / Lower Gilmore place


Cowgate / Blair street

PASS PASS PASS 5.8 0.3 <1s 0.6 As Google Map algorithm uses driving direction, a bad direction choice is made at one intersection

Granton Crescent / Granton View


Elliot park / Elliot road


Colinton Mains Drive / Coliton Mains Crescent

FAIL FAIL FAIL >120/ 0 <1s 0.2 A * has failed reaching the destination node


Appendix 5: Code documentation


74

Php Code Documentation This document provides an overview class implemented for the application. This documentation has been automatically generated from the code using the software Enterprise Architect.

incl Type: Package Package: Business Process Model Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: incl Created By: Tarik Attar 06009306 on 04/05/2008 Last Modified: 04/05/2008, Version:1.0

controller Type: Package Package: incl Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes:


75

AStarController Controler: PHP, Stereotype: , Package: controller Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Constraints Name Type Columns Initial Code Notes array_exist Public value

array

calculateDistance Public startcoordinate previouscoordinate endnode

getRoute Public startnode endnode

getSomeRandRoad Public getTime Public removeFromArray Public array

value

run Public mode

AntColonyController Controller: PHP, Stereotype: , Package: controller Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Columns PK Name Type Not

Null Unique

Len Prec

Scale

Init Notes

antcolonymodel var antcolonyview var colonypheromon

e var

goal var links_arr var nodefood_array var nodeneighbors_a

rray var

nodes_arr var nodes_list var postcode var


76

queen var solution_list var

Constraints Name Type Columns Initial Code Notes AntColonyController Public postcode

nodes_list

createXmlRepresentation

Public finished1

displayGraph Public evaporatePheromone Public rate

generateSolution Public foodquantity useheuristic

getLinksArr Public getNodeNeighborsArr Public getNodesArr Public getNodesList Public placeFood Public run Public setCenterNode Public centernode

setGoal Public goal

setLinksArr Public links_arr

setNodeNeighborsArr Public nodesneighbors_arr

setNodesArr Public nodes_arr

setNodesList Public nodes_list

AntForagerController Controller: PHP, Stereotype: , Package: controller Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Columns PK Name Type Not

Null Unique

Len Prec

Scale

Init Notes

alreadyvisitednodes

var

center var closed_list var Final result list currentposition var goal var


77

hasreachedfood var boolean helppheromone var links_arr var nestlocation var nodes_arr var number var numeberoftimetr

ap var

previousposition var result_list var routepheromone var visited_arr var var

$typeofheuristic; Constraints Name Type Columns Initial Code Notes AntForagerController Public center

goal links_arr i nodes_arr goal2

constructor

array_exist Public value array

chooseNode Public neighbor_list

getCurrentPosition Public getNumber Public getTrapNumber Public hasReachedFood Public initialise Public node

goal

kill Public move Public nodesneighbor_a

rr nodes_list links_arr nodes_arr

setCurrentPostition Public node

updatePheromone Public start end value mode

w_rand Public weights Function which


78

Name Type Columns Initial Code Notes returns a choice

using weighted probability

AntGridController Controller: PHP, Stereotype: , Package: controller Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Columns PK Name Type Not

Null Unique

Len Prec

Scale

Init Notes

antcolony var contains 0 to n colony, this is actually the real map

antgridmodel var Link to model antgridview var Link to view

Constraints Name Type Columns Initial Code Notes AntGridController Public run Public mode

vararray

AntQueenController Controller: PHP, Stereotype: , Package: controller Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Columns PK Name Type Not

Null Unique

Len Prec

Scale

Init Notes

ant_list var antscout_list var center var goal var links_arr var nodeneighbors_a

rray var

nodes_arr var nodes_list var numberofreached

place var

solution_list var Constraints


79

Name Type Columns Initial Code Notes AntQueenController Public createForagerAnt Public number

nodeneighbors_array center nodes_list links_arr nodes_arr goal

createScoutAnt Public number nodeneighbors_array center nodes_list links_arr nodes_arr goal

getAntList Public giveFindFoodOrder Public useheuristic

run Public

AntScoutController Controller: PHP, Stereotype: , Package: controller Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Columns PK Name Type Not

Null Unique

Len Prec

Scale

Init Notes

alreadyvisitednodes

var

center var closed_list var currentposition var goal var hasreachedfood var boolean helppheromone var links_arr var nestlocation var nodes_arr var number var numeberoftimetr

ap var

previousposition var result_list var routepheromone var


80

typeofheuristic var visited_arr var

Constraints Name Type Columns Initial Code Notes AntScoutController Public center

goal links_arr i nodes_arr goal2 typeofheuristic

array_exist Public value array

calculateHeuristic Public startcoordinate previouscoordinate endnode

chooseNodeUsingHeuristic

Public neighbor_list

getCurrentPosition Public getNumber Public getTrapNumber Public hasReachedFood Public initialise Public node

goal

kill Public move Public nodesneighbor_a

rr nodes_list links_arr nodes_arr

setCurrentPostition Public node

updatePheromone Public start end value mode

w_rand Public weights


81

GraphController Controller: PHP, Stereotype: , Package: controller Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Columns PK Name Type Not

Null Unique

Len Prec

Scale

Init Notes

coarse_graph_list

var

nodes_list var road_links_list var

Constraints Name Type Columns Initial Code Notes getCoarseGraph Public getConnectedNode Public nodetoid

GraphController Public nodes_list roadlinks_list

reduce Public save Public

GraphNode Controller: PHP, Stereotype: , Package: controller Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Columns PK Name Type Not

Null Unique

Len Prec

Scale

Init Notes

nodes_list var Constraints Name Type Columns Initial Code Notes getFurthestGraphNode Public GraphNode Public roadlink

roadnode


82

ListClass Controller: PHP, Stereotype: , Package: controller Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Columns PK Name Type Not

Null Unique

Len Prec

Scale

Init Notes

arr var iterator var length var list_coordinates var

Constraints Name Type Columns Initial Code Notes addElement Public element

clean Public displayElement Public displayRoute Public exist Public value

getElement Public index

getLastElement Public getLength Public getListCoordinates Public getSize Public initialise Public ListClass Public merge Public listclass

removeElement Public element

MaterialsController Controller: PHP, Stereotype: , Package: controller Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Constraints Name Type Columns Initial Code Notes run Public mode


83

OSMastermapController Controller:: PHP, Stereotype: , Package: controller Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Columns PK Name Type Not

Null Unique

Len Prec

Scale

Init Notes

osmastermapmodel

var

osmastermapview

var

Constraints Name Type Columns Initial Code Notes OSMastermapController Public run Public mode

PositronController Controller: PHP, Stereotype: , Package: controller Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Columns PK Name Type Not

Null Unique

Len Prec

Scale

Init Notes

counter var node_size_array var result_list var temp_array var visited_nodes_lis

t var

Constraints Name Type Columns Initial Code Notes getBorder Public getCounter Public getListCoordinates Public getNodeSizeArray Public inject Public startnode

quantity visited_nodes

PositronController Public


84

Road Controller: PHP, Stereotype: , Package: controller Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Columns PK Name Type Not

Null Unique

Len Prec

Scale

Init Notes

boundedby var changedate var descriptivegroup var endx var endy var i var 0 networkmember var reasonforchange var referencetoroadli

nk var

roadname var startx var starty var theme var themecount var TOID var version var versiondate var

Constraints Name Type Columns Initial Code Notes getEndX Public getEndY Public getNearestNode Public point

getRoadName Public getStartX Public getStartY Public getTOID Public load Public query

Road Public save Public setBoundedBy Public coordinates

setChangeDate Public changedate

setCoordinates Public coordinates

setDescriptiveGroup Public descriptivegroup

setNetworkMember Public networkmember


85

Name Type Columns Initial Code Notes

setReasonForChange Public reasonforchange

setReferenceToRoadLink

Public referencetoroadlink

setReferenceToTopographicArea

Public referencetotopographicarea

setRoadName Public roadname

setTheme Public theme

setThemeCount Public themecount

setTOID Public TOID

setVersion Public version

setVersionDate Public versiondate

RoadLink Controller: PHP, Stereotype: , Package: controller Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Columns PK Name Type Not

Null Unique

Len Prec

Scale

Init Notes

changedate var coordinates var descriptivegroup var descriptiveterm var directednode1 var directednode2 var endx var endy var i var 0 ID var length var natureofroad var reasonforchange var referencetotopog

raphicarea var

startx var starty var theme var


86

themecount var TOID var version var versiondate var visited var

Constraints Name Type Columns Initial Code Notes getDirectedNode1 Public getDirectedNode2 Public getID Public getLength Public getRoad Public getTOID Public getVisited Public load Public mysql_object

loadQueryArray Public array

roadLink Public save Public setChangeDate Public changedate



setDescriptiveTerm Public descriptiveterm

setDirectedNode1 Public directednode1

setDirectedNode2 Public directednode2

setLength Public length

setNatureOfRoad Public natureofroad





setTOID Public TOID




87

Name Type Columns Initial Code Notes setVisited Public bool

RoadLinkInformation Controller: PHP, Stereotype: , Package: controller Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Columns PK Name Type Not

Null Unique

Len Prec

Scale

Init Notes

changedate var classification var coordinates var descriptivegroup var distancefromstart var reasonforchange var referencetoroadli

nk var

theme var TOID var version var versiondate var

Constraints Name Type Columns Initial Code Notes roadNode Public save Public setChangeDate Public changedate

setClassification Public classification



setDistanceFromStart Public distancefromstart


setReferenceToRoadLink

Public referencetoroadlink


setTOID Public TOID



88

Name Type Columns Initial Code Notes setVersionDate Public versiondate

RoadNode Controller: PHP, Stereotype: , Package: controller Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Columns PK Name Type Not

Null Unique

Len Prec

Scale

Init Notes

_parent var changedate var childrens var coordinates var descriptivegroup var foodquantity var i var 0 ID var quantity var segmentation

purpose reasonforchange var referencetotopog

raphicarea var

theme var themecount var "NUL

L"

TOID var version var versiondate var visited var

Constraints Name Type Columns Initial Code Notes getChildrens Public getConnectedNode Public forbidden_list

getConnectedNodeHeuristic

Public forbidden_list

getCoordinates Public getFoodQuantity Public getID Public getParent Public getPostCode Public getQuantity Public getRoadName Public getTOID Public getVisited Public getX Public


89

Name Type Columns Initial Code Notes getY Public load Public id

load_object Public node

roadNode Public save Public setChangeDate Public changedate

setChildrens Public childrens



setFoodQuantity Public quantity

setParent Public parent

setQuantity Public quantity






setTOID Public TOID



setVisited Public bool

RoadRouteInformation Controller: PHP, Stereotype: , Package: controller Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Columns PK Name Type Not

Null Unique

Len Prec

Scale

Init Notes

changedate var descriptivegroup var


90

directedlink var instruction var reasonforchange var theme var themecount var TOID var version var versiondate var

Constraints Name Type Columns Initial Code Notes RoadRouteInformation Public save Public setChangeDate Public changedate


setDirectedLink Public directedlink orientation

setInstruction Public instruction




setTOID Public TOID



Route Controller: PHP, Stereotype: , Package: controller Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Columns PK Name Type Not

Null Unique

Len Prec

Scale

Init Notes

length var Constraints Name Type Columns Initial Code Notes array_exist Public value

array

calculate Public startnode


91

Name Type Columns Initial Code Notes endnode time_start

calculateDistance Public startcoordinate previouscoordinate endnode

exist Public startnode endnode

getLength Public getRoute Public getSomeRandRoad Public getTime Public load Public startnode

endnode

removeFromArray Public array value

render Public list start end

Route Public save Public startnode

endnode route

SegmentationController Controller: PHP, Stereotype: , Package: controller Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Columns PK Name Type Not

Null Unique

Len Prec

Scale

Init Notes

forbidden_list var result_list var segmentationmo

ndel var

segmentationview

var

temp_list1 var temp_list2 var

Constraints


92

Name Type Columns Initial Code Notes arrange Public graph

buildGraph Public startnode

calculateDistance Public node1 node2

calculateDistanceCentroid

Public startcoordinate previouscoordinate

nodesBorderSave Public node_id border_id centroiddistance

postcodeNodesSave Public nodetoid poscodeid distance

run Public mode

SegmentationController Public

TestController Controller: PHP, Stereotype: , Package: controller Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Columns PK Name Type Not

Null Unique

Len Prec

Scale

Init Notes

testview var Constraints Name Type Columns Initial Code Notes run Public mode

TestController Public

WebSiteController Database: PHP, Stereotype: , Package: controller Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Columns PK Name Type Not

Null Unique

Len Prec

Scale

Init Notes

database var


93

googlemapapikey

var

host var websitemodel var websiteview var


94

Constraints Name Type Columns Initial Code Notes run Public mode

WebSiteController Public

model Type: Package Package: incl Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: model Created By: Tarik Attar 06009306 on 04/05/2008 Last Modified: 04/05/2008, Version:1.0

AntColonyModel Database: PHP, Stereotype: , Package: model Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Columns PK Name Type Not

Null Unique

Len Prec

Scale

Init Notes

links_arr var Constraints Name Type Columns Initial Code Notes AntColonyModel Public getAllMap Public getColonies Public postcode_list

getColony Public ehpostcode

getNeighbors Public node nodes_list

AntGridModel Database: PHP, Stereotype: , Package: model Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Constraints Name Type Columns Initial Code Notes getPostCode Public node


95

Name Type Columns Initial Code Notes

SegmentationModel Database: PHP, Stereotype: , Package: model Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Constraints Name Type Columns Initial Code Notes getCentroidReference Public getNewPostCode Public postcode

getNode Public streetname

getNodeBorder Public ehpostcode

getNodes Public getNodesObject Public getNodesObjectCentroid Public getPostCodeCentroid Public limit

getRandomGraph Public getRoadLinks Public getTOIDNodes Public

WebSiteModel Database: PHP, Stereotype: , Package: model Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Columns PK Name Type Not

Null Unique

Len Prec

Scale

Init Notes

database var "" host var password var user var

Constraints Name Type Columns Initial Code Notes close Public connect Public host

user password database

create Public database

exist Public


96


97

view Type: Package Package: incl Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: view Created By: Tarik Attar 06009306 on 04/05/2008 Last Modified: 04/05/2008, Version:1.0

AStarView View: PHP, Stereotype: , Package: view Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Constraints Name Type Columns Initial Code Notes display_search Public

AntColonyView View:: PHP, Stereotype: , Package: view Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Constraints Name Type Columns Initial Code Notes svgRender Public links_arr

centercoord

AntGridView View: PHP, Stereotype: , Package: view Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Constraints Name Type Columns Initial Code Notes render Public renderMap Public list

start end


98

MaterialsView View: PHP, Stereotype: , Package: view Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Constraints Name Type Columns Initial Code Notes render Public

OSMastermapView View: PHP, Stereotype: , Package: view Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Constraints Name Type Columns Initial Code Notes render Public

SegmentationView View: PHP, Stereotype: , Package: view Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Constraints Name Type Columns Initial Code Notes render Public nodes_list

renderDefault Public renderGraph Public nodes_neighbor_

arr

svgRender Public nodes_list border_list

svgRender2 Public nodes_list_list border_list


99

TestView View: PHP, Stereotype: , Package: view Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Constraints Name Type Columns Initial Code Notes inputForNearestNode Public render Public


100

WebSiteView Database: PHP, Stereotype: , Package: view Detail: Created on 04/05/2008. Last modified on 04/05/2008. Notes: Constraints Name Type Columns Initial Code Notes footer Public home Public menu Public Tab_selected


101


102

Appendix 6: Calculation details for Optimised A* with and without SACO


From/To

FCN FR

DR

Execution Time

Route Length

Google Map exec Time

Google Map Length

Comments

A* PASS PASS PASS 3 6.6 Upper Gilmore Place / Christian Crescent

A* SACO

PASS PASS PASS 9 6.6

< 1s 5.5

A* PASS FAIL FAIL 2 1.5 West Adam Street / Meadowbank avenue

A* SACO


<1s 1.7

A* PASS PASS PASS 1 2.4 Orwell Place / St Patrick square

A* SACO


<1s 2.7

A* PASS PASS PASS 3 7.78 Fountainbridge / Waverley Terrace A*

SACO PASS PASS PASS 8 7.71

<1s 8.0

A* PASS PASS PASS 2 4.4 East Mayfield / Portland Street

A* SACO


<1s 3.5


104

Road choice criteria: Random


105

Road choice criteria: Route less than1.5 miles dist ance

From/To

FCN FR

DR

Execution Time

Route Length


Google Map Length

Comments

A* PASS PASS PASS 3 0.75 Ritchie Place / Coliton Road

A* SACO


< 1s 0.8

A* PASS PASS PASS 2 0.7 Dundee street / Merchiston Park

A* SACO


<1s 0.7

A* PASS PASS PASS 3 0.6 Wellington place / Tower street

A* SACO


<1s 0.6

A* PASS PASS PASS 4 1.6 Campbell Road / Wester Coates Garden

A* SACO


<1s 1.1

Morrison Circus / Fountainbr

A* PASS PASS PASS 3 0.7 <1s 0.8


106

Fountainbridge

A* SACO



107

Road choice criteria: Connected Roads


108

From/To

FCN FR

DR

Execution Time

Route Length


Google Map Length

Comments

A* PASS PASS PASS 2 0.3 Gilmore place / Lower Gilmore place

A* SACO


< 1s 0.3

A* PASS PASS PASS 3 0.3 Cowgate / Blair street

A* SACO


<1s 0.6

A* PASS PASS PASS 2 1.4 Granton Crescent / Granton View

A* SACO


<1s 0.6

A* PASS PASS PASS 2 0.1 Elliot park / Elliot road A*

SACO PASS PASS PASS 8 0.09

<1s 0.1

A* FAIL PASS PASS 3 1.2 Colinton Mains Drive / Coliton Mains Crescent

A* SACO

FAIL PASS PASS 11 1.2

<1s 1.7 Bad locations are retrieved

Tarik Attar 06009306 Beng(Hons) Internet Computing An investigation on routing algorithms for...

Documents

Transcript of Tarik Attar 06009306 Beng(Hons) Internet Computing An investigation on routing algorithms for...