abstract - blackboard learn abstract recent developments in mobile phone technology have enabled the...
TRANSCRIPT
i
Abstract
Recent developments in mobile phone technology have enabled the creation of a wide range of new
information services accessible to the user. Clear examples include the development of WAP, and its
succession by GPRS, and the development of 3G, and such benefits as video calling and high speed Internet
access. Another of area to benefit from these developments is that of location acquisition technologies.
These are found, user side, as Location-Based Services (LBS), services that are capable of providing
information relevant to the user’s location. This report will demonstrate how these services have been
studied in detail, and seen the development of a prototype Location-Based Service. The developed prototype
provides visitors to the University of Leeds campus with information about the campus relative to their
position.
The report will firstly demonstrate how a wide spanning survey of existing techniques and applications was
carried out. This section will prove to be valuable throughout the design and development stages of this
report. It will also be shown how while Location-Based Services are now freely available, current
developments are not highly developed, and that no tourist information service is currently derived from this
technique. With these lessons learnt, the report will then go on to describe a potential design of such a
system. This design is described in four key ways; location acquisition, route guidance, information storage
and provision, and deployment. Each of these aspects will be analysed in detail, with the key benefits and
problems with each design option outlined. The report will then go on to demonstrate how some aspects of
this design have been implemented into a prototype. Firstly, it will be described how, during the preparation
for this development, an investigation into GPS coverage within the University of Leeds discovered mixed
results. It will also be shown careful consideration of the map data used within such a system can be highly
beneficial to the eventual result. The report will then move onto describing how a route guidance and
information prototype was designed and developed using simulated data. As will be shown, the prototype
was developed in Java, and integrated with supported geographic data processing tools. It will be described
how this prototype may be simply extended for use on a mobile device. Following this section there will be
an in-depth analysis of the routing results produced by the prototype. This section will explain how
geographic data has been handled in order to attain improved results. The report will conclude by describing
the key successes of the project, as well describing the limitations met throughout the project. There will
also be some detailed discussion about the potential future directions this work might take.
ii
Acknowledgements
There are a few people I would like to extend my gratitude to for their help during the completion of this
project. Firstly, I would like to thank Dr. Anthony Beck for his help in directing me towards the methods
suitable for constructing my prototype with. His guidance was invaluable in introducing me to some
concepts with which I had had no prior experience. I would also like to thank the Ordinance Survey for
providing the MasterMap data used during this project, despite its not yet full release. As well, I would like
to thank the EPSRC for supporting me throughout not only this project, but the entire length of my Masters
degree. I would also like to thank my family for their support throughout my University career; this project
is dedicated to them. However, most of all, I’d like to thank my project supervisor, Professor Tony Cohn,
for help, support and guidance that he provided throughout the course of this project.
iii
Tables of Contents
1 Project Outline 11.1 Overview 11.2 Introduction 11.3 Overall Aims and Objectives of the Project 21.4 Key Approaches 3
2 Background Research 52.1 Mobile Device Location Technologies 5
2.1.1 Cell-ID 52.1.2 Timing Advance (TA) 62.1.3 Standard Triangulation Methods: TDOA, TOA and AOA 62.1.4 Enhanced Observed Time Difference (E-OTD) 72.1.5 Advanced Forward Link Trilateration (AFLT) and Enhanced 8
Forward Link Trilateration (EFLT)2.1.6 Summary of Mobile Device Location Technologies 8
2.2 Other Location Acquisition Technologies 92.2.1 Global Positioning System (GPS) and Assisted GPS (A-GPS) 102.2.2 Galileo 102.2.3 Infrared 112.2.4 Bluetooth 112.2.5 Wireless LAN (WiFi) 122.2.6 Radio Frequency (RF) 122.2.7 WiMAX 12
2.3 Location-Based Services and Applications 132.3.1 Mobile Location Data Applications 14
2.3.1.1 Mobile Phone Networks 142.3.1.2 Vendor-offered Services 152.3.1.3 Other Applications 16
2.3.2 Wireless Tourist Guides 172.3.3 Other Location-Aware Guidance Applications 20
2.4 Placement within Wider Context 202.4.1 Personalisation and Mashups 212.4.2 Moral and Ethical issues 22
2.5 Chapter Summary 23
3 Application Planning 243.1 A Location-Aware Tourist Guide 24
3.1.1 Location Acquisition 253.1.1.1 Orange API 253.1.1.2 Global Positioning System (GPS) 25
3.1.2 Route Guidance 263.1.3 Provision of Location-aware Tour Information 28
3.1.3.1 Storage of Tour Information 283.1.3.2 Provision of Information 30
3.1.4 System Deployment 323.1.4.1 Mobile Phones 323.1.4.2 PDA (Palm Top Computers) 33
3.2 Chapter Summary 33
4 Data Selection 354.1 Location Method Evaluation 35
4.1.1 Orange API 354.1.1.1 Research 35
4.1.2 Global Positioning System 36
iv
4.1.2.1 Method 364.1.2.2 Results 364.1.2.3 Analysis 37
4.1.3 Comparison of Methods 384.2 Map Data 40
4.2.1 Requirements of the Data 404.2.2 Map data options 41
4.2.2.1 OS Land-Line.Plus 414.2.2.2 OS MasterMap 434.2.2.3 Other data formats 45
4.2.3 Choice of product 454.3 Chapter Summary 46
5 Prototype Development 475.1 Specification 47
5.1.1 Route Construction tools 485.1.1.1 ArcMap 485.1.1.2 MapManager 485.1.1.3 Spatial and Network Analyst 49
5.1.1.3.1 Least Cost Path – Spatial Analyst 495.1.1.3.2 Network Analyst 495.1.1.3.3 Rationale 50
5.1.2 Application Development 515.1.2.1 Arc MapObjects – Java Edition 515.1.2.2 Arc Engine 525.1.2.3 ArcObjects 525.1.2.4 ArcGrid 52
5.2 Design 535.3 Implementation 54
5.3.1 Data Preparation 545.3.1.1 ArcGIS Methods 545.3.1.2 Importing OS MasterMap data 545.3.1.3 Preparation of a MasterMap Travel Mask 55
5.3.2 Prototype Development 575.3.2.1 Data Conversion 585.3.2.2 Arc-based Data Processing 585.3.2.3 AML Scripts and External Execution 605.3.2.4 MapObjects and Data Display 61
5.3.2.4.1 Data Display 625.3.2.4.2 Capturing Points 625.3.2.4.3 Provision of other Location-aware data 62
5.4 Chapter Summary 63
6 Testing 646.1 Test 1: North of campus to South of campus 646.2 Test 2: West of campus to East of campus 656.3 Test 3: Inside Campus – Northern region 666.4 Test 4: Inside Campus – Southern region 666.5 Test 5: Inside Campus – St Georges Field 676.6 Test 6: Outside of campus, into the centre of campus 676.7 Chapter Summary 68
7 Evaluation 697.1 Weighting problems 69
7.1.1 Test 1: North of campus to South of campus 727.1.2 Test 2: West of campus to East of campus 727.1.3 Test 3: Inside Campus – Northern region 74
v
7.1.4 Test 6: Outside of campus, into the centre of campus 747.2 Map Data Problems 75
7.2.1 Test 4: Inside Campus – Southern region 767.3 Resolution Checks 797.4 Extensions on Current Design 81
7.4.1 Adding Descriptors 817.4.2 Changing the Map Data 81
7.5 Limitations of Approach 847.6 Chapter Summary 85
8 Conclusions 868.1 Summary and Discussion 868.2 Review of Aims and Objectives 888.3 Future Work 898.4 Project Constraints 92
9 References 94
10 AppendicesA Personal ReflectionB Objectives and DeliverablesC Comments of Mid-Project ReportD GPS Accuracy Map
Unreachable Areas by GPSE Original DataF Weighted Map (Vector)G Weight Map at 20m ResolutionH Weight Map at 10m ResolutionI Weight Map at 5m ResolutionJ Weight Map at 3m ResolutionK Weight Map at 1m ResolutionL Arc Route Construction CodeM Cost Distance MapN Cost Direction MapO Example of a PathP AML, Java and Batch file CodeQ Prototype CodingR Revised WeightingsS Manual ChangesT New Weightings Map with manual alterations
1 of 98
1 Project Outline
1.1 Overview
The following report details the stages in the development of an application to provide mobile device users
with location-aware information services. The report will demonstrate this concept through detailed
discussion of the considerations needed in developing such an application for visitors to the University of
Leeds campus. It will be shown how such an application was designed, and aspects of which implemented
in the form of a prototype. In carrying out this process, it will be shown how it was possible to gain a more
in depth understanding of the requirements of the system, thus providing an excellent platform from which to
develop this application further in the future. Although this particular example specifically looks to employ
mobile network location technologies, full research and discussion is offered concerning a wide range of
such technologies, and their potential placement within such a system.
1.2 Introduction
The development of mobile phones has become one of the fastest moving industries within the bracket of
‘technology’. Although the widespread use of these devices has only come around in the last ten years,
many now rely on their mobile phone in conducting the most simple of activities. As is often the case, the
development of such technologies is often fuelled by their popularity, and as a result the functionality in
many respects has leapt enormously since their conception in the 1980s. In this report, one particular
development, that of location acquisition technologies, will be explored in some detail.
Location-Based Services (LBS) provide the user of a handheld device, usually a mobile phone, with
information concerning their current location. There are a number of ways in which these systems have been
implemented, and a range of applications to which they have been applied. The area of LBS can be
considered quite broad, taking in not just the cellular network location, but also other technologies such as
GPS or radiolocation methods (including radio frequencies and Infrared). By acquiring the position of the
mobile device, the provider of the service is able to offer any number of location-based information services.
Such common examples, usually offered by the network provider, include services to identify the users
nearest bus stop or cash point. It is the view of this author that the current range of services do not fully
utilise the capabilities of the technology. Therefore, in view to this, the report will offer discussion
concerning the feasibility of extending these services to develop, specifically, a location-aware tourist
information.
The investigations within this project are centred upon the development of a tourist information service for
the University of Leeds. When people visit the University, their general aim to find out about the place and
what it has to offer them. The campus is a big place, and may be understandably daunting if they have not
2 of 98
visited this or any University before. Usually guidance is offered by a tour guide, who leads a group of
students and possibly parents around a set path telling them a little about the key features of the campus.
However, is this all that can be offered? What about the people who visit and want to explore the University
at which they might be spending three years? What about the people who want to find out a bit more about
certain parts of the campus which are not covered in much detail on the tour? What about the people who do
not like being shown around in a group, and would prefer to take their time looking around? The options for
this kind of tour are limited, and there is not enough tourist information positioned around campus to suitably
guide a visitor. This is where location-aware technology can provide a service. By picking up where the
user is positioned, the service could be able to offer information about their specific surroundings. This
information might be about a building, a department or a service – for whatever is within the campus
boundaries there can be information made available.
The target of the project is to investigate the feasibility of such an effective application being developed and
offer methods for how this might be done. There is a great deal of potential within such a service.
Incorporation of the user’s interests, time limits or the department they are visiting can all help to scale the
information to make it more relevant to that particular person. The range of technology to support these
developments will also be discussed. XML-enabled technologies enable structured information to be
handled in numerous ways, even allowing assumptions about a user’s interest in a particular aspect of the
campus to be constructed. A full exploration of the possibilities attainable to this development will be
offered during the report.
The mobile phone is an excellent canvas for the development of this kind of system. They provide a wide
range of possible methods for communication with location acquisition services, including GPRS-enabled
access to the Internet. The development of J2ME (Java 2 Micro Edition) and related tools have provided the
necessary techniques required to develop fairly complex applications for mobile devices. While their
portability, ease of use and established position in people’s every day lives mean they are an excellent
platform from which to establish a system such as this.
1.3 Overall Aims and Objectives of the Project
At the inception of this project, a number of overall aims and objectives were laid out to ensure certain
aspects were delivered. As the project progressed it was seen fit to make some alterations to these. These
changes were carried out in agreement with the project supervisor, Prof. Tony Cohn, during a mid-project
review. The revised goals are offered here. The overall aim of the project was as such:
“To examine approaches for the design and development of a location-aware
geographical information service, based on mobile device, and to illustrate some of
these concepts in a prototype”
3 of 98
This main aim will be tackled through the completion of the following key objectives:
Evaluation of wireless location methods to determine the potential benefits and accuracies of
adopting a particular technology for use within the system
Demonstrate how Geographical data can facilitate the provision of location-aware information
Develop a prototype location-based visitor information service, using simulated or real location data
In support of these aims and objectives, two clear minimum requirements were also provided:
Survey existing location-aware technologies and how they have been implemented in both
commercial and academic environment. Determine suitable environment for development of
prototype.
Implement prototype capable of using real and/or simulated mobile phone location data to provide a
user with at least one location-aware information service.
1.4 Key approaches
As explained in the overall aim of the project, a large degree of this report will feature on examining the
approaches for the development of a location-aware tourist information system. As a result, this
investigation places a large emphasis upon the research and design aspects, in terms of understanding the key
issues associated with developments of this nature. The prototype application provides some ‘proof of
concept’ to the issues discussed during the design considerations. In keeping with the second minimum
requirement, the prototype will include at least one location-aware information service.
The investigative nature of the report has been largely imposed due to a lack of access to mobile phone
location data. This access was arranged to be provided by Orange, but a failure to provide this access meant
that new approaches had to be taken. Had this data been made available then more consideration would have
been offered to examine how effectively a system, based on this technology, may potentially operate within
the campus environment. Instead, hopefully, this report exists as a guide towards future developments of this
nature. In place of the location data, greater emphasis has been placed on establishing an extensive system
design that has the potential for the incorporation of other developing mobile phone technologies. In
addition, emphasis has been placed upon examining the important considerations that need be analysed
during the development process, and the pitfalls that must be avoided. The report also extensively analyses
the range of technologies that may be used to help construct location-aware services, while speculating about
the future development of such applications.
In summary, while it is regrettable that the location data was not available for the development process of
this project, it has allowed a range of other wide-spanning factors that have been covered that might not have
4 of 98
been otherwise. These will help provide a wide ranging investigation of the key issues associated with this
kind of development.
5 of 98
2 Background Research
The first section of this report will concentrate on establishing a solid base from which application design and
development can be commenced. The nature of this investigation enforces that the research carried out be wide
ranging and in-depth to ensure that full potential for this system can be met. The first part of this section will,
therefore, address the range of current and developing technologies and methods capable of providing the
location of a mobile device. By exploring this range of methods early on, an understanding of the potential
technologies that may be utilised in this application can be established. This work will not only examine the
mobile device location techniques but also extend to looking at other similar methods, including GPS, WiFi and
WiMAX. Following this section, there will be an analysis of the currently available applications that fall into the
bracket of providing location aware information. This study will include looking at the current uses of mobile
phone location data, as well as examining the current trends in the development of location-aware tourist
guidance systems. The final part of this chapter will examine the placement of location-aware technologies
within the wider context, in terms of their relationships with developing web technologies and in terms of the
moral and ethical issues raised by their increasing prevalence in society.
2.1 Mobile Device Location Technologies
In comparison to other methods, particularly those using satellite location data, location acquired from cellular
network data is a little inaccurate. Despite this, these methods are often favoured for their ability to provide
location within buildings. The common methods implemented here are based upon the device location in
relation to the known locations of network Base Transmission Stations (BTS). This section will address the
methods most applicable to this case, those that operate on the GSM (Global System of Mobile Communication;
also known as 2G) network, and extending to look at how the UMTS (Universal Mobile Telecommunications
System; or 3G) network, with its higher data transfer speeds, has seen the development of new, more accurate
methods of device location. Following this section, other methods currently available on mobile device will be
examined, including GPS (Global Positioning System), and how its satellite-acquired accuracy compares to
those derived from network data.
2.1.1 Cell-ID
Cell-ID is the most common and most basic of cellular location methods, and is currently the method used by all
UK networks to determine the position of GSM network mobile phones. This system works by determining
which network cell the device is currently within on the GSM or UMTS network. Cellular networks are made
up of numerous cells, shaped together in honeycomb fashion (Dornan 2000), with cell sizes usually based upon
6 of 98
the level of communication ‘traffic’ in that area (Strahan 2002). Therefore, it’s usually found that cells within
urban areas are smaller (more concentrated) than those in more rural parts. As a result, the accuracy of this
method can vary widely, with accuracies widely quoted as being as low as 100 metres in some UK cities and in
the range of kilometres in accuracy in rural areas (Wilde 2002).
The system works, more specifically, by keeping a record of the cell within which the device is located at the
network Mobile Telephone Switching Office (MTSO) (Strahan 2002). Whenever the device changes cell, in
other words its signal becomes greater in one cell than its current, a ‘handover’ is made and the MTSO database
is updated. When a location request is made, the position of the current cell is provided in land co-ordinates with
the accuracy taken from the size of the cell.
According to the Telematica Instituut in the Netherlands (TI 2006), the Orange network in the UK has 97 cells,
with an average cell size of 270 metres. The UK average is around 246 metres. However, this data would not
necessarily correspond to location results, so for more reliable results ground testing will be carried out.
Because of the accuracy issues associated with the Cell-ID method, efforts have been made to help improve
results without the need for large modifications to device or infrastructure. These developments have tended to
use triangulation methods (as will be explained later) between the positions of transmission stations; however,
the majority of these have been better implemented outside of the UK. The first method to be examined is that
of Timing Advance (TA).
2.1.2 Timing Advance (TA)
Timing Advance uses basic methods to check how near the mobile device is to the current cell’s BTS. By
enforcing handovers between base stations triangulation is possible. However, the main design purpose of this
method is to check whether the device is connected to its nearest cell, and so does employ methods that increase
the accuracy of the Cell-ID method significantly (GSM 2003).
2.1.3 Standard Triangulation Methods: TDOA, TOA and AOA
These three methods use simple, network-side calculations based on a devices proximity to surrounding BTS
locations to determine the approximate location of the device. This method, known as triangulation, uses the
approximate distances between mobile device and BTS in a minimum of two directions to obtain a location. The
accuracy of the methods depends largely on the positions of the base stations in comparison to the unit. Despite
their similarity in general method, the networks on which they operate differ. While the Time of Arrival (TOA)
and Angle of Arrival (AOA) methods can work on GSM networks, the Time Difference of Arrival (TDOA)
7 of 98
technique requires infrastructure changes that are only available on the UMTS network, introducing increased
start-up and maintenance costs (Strahan 2002, Openwave 2002, SnapTrack 2003). As a result, the availability of
TDOA is largely dependent upon the network making these adjustments (the UMTS network is available on all
of the UK’s major network providers).
The Time Difference of Arrival (TDOA) method, the simplest and most common of the UMTS (3G) network
techniques, compares the differences in time it takes for a device signal to reach a minimum of two base stations.
By incorporating a third base stations it is possible to triangulate the approximate position of the device, with
accuracy thought to be between 100 and 300 metres (Markzof 2005). This method requires tight time
synchronisation between the base stations, bringing high start up costs and is only feasible on the UMTS
network.
Synchronisation is also a requirement of the Time of Arrival (TOA) technique which, instead of requiring
improvements in the network technology, uses the absolute time taken for a signal to reach a specific BTS from
a device. Then instead of comparing times, a third base station is used to increase the precision of the initial
location calculated from the time data taken at the two other base stations (Mock 2002).
The Angle of Arrival (AOA) method requires the use of specifically configured antennae to determine the angle
by which a device signal is received at a base station. This method requires a minimum of two base stations to
determine the location of a device. However, of the three, this is the most costly, requiring expensive equipment
to handle uncertainty introduced through signals bouncing off objects (Mock 2002). The TOA and AOA
methods are often used in conjunction due to their differences in location specification, as shown by Proietti
(2002).
2.1.4 Enhanced Observed Time Difference (E-OTD)
The Enhanced Observed Time Difference method offers an extension on the triangulation methods offered
above. It is claimed to offer greater accuracy in its results but requires adjustments to the mobile phone software
with a lesser impact upon the network infrastructure, meaning it is able to operate on the GSM network and
without the need for UMTS (inCode 2005, Frasco 2006). It is often viewed as being the compromise between
the slightly less accurate TDOA and Cell-ID/TA methods and the more expensive GPS/A-GPS systems
(described later). E-OTD accuracy is estimated variably, with some suggesting 50-200 metres (Openwave
2002), some 100-500m (StarTrack 2003), and some at 100-250m (inCode 2005).
The process, in fact, is similar to the TDOA method, in that location estimations are made according to the
device proximity to multiple base transmission stations. In a similar way to the TDOA method, the position is
8 of 98
triangulated according to the time that a signal burst is received from the known location of a specific base
station. However, it is the amended device software (not a feature of TDOA) that which enables this process
despite unsynchronised base stations. Again, a minimum of three base stations are used to estimate a location.
A useful graphical representation of this method is offered by Cambridge Positional Systems (CPS 2006)
As hinted at earlier, some suggest the E-OTD method does not offer any better results than the TDOA
(SnapTrack 2003). However, given its placement on the conventional GSM (or 2G) network and the only need
for modifications centred on the device software (thus decreased maintenance costs), it is often favoured by the
networks as the preferred method of locating devices (Openwave 2002). It will be shown later how the
Enhanced 911 initiative is beginning to implement both TDOA and E-OTD in tracking mobile devices in
emergency situations.
2.1.5 Advanced Forward Link Trilateration (AFLT) and Enhanced Forward Link Trilateration (EFLT)
Two methods that are worth mentioning briefly are the Advanced Forward Link Trilateration (AFLT) and the
Enhanced Forward Link Trilateration (EFLT) systems, both of which only operate on UMTS networks. As
mentioned earlier, UMTS networks operate with strong cross-network synchronisation. This technique again
utilises this feature by measuring the time taken to transfer a signal to determine an estimated distance. Multiple
base stations are used to make this calculation, meaning the process is similar to the triangulation methods seen
in TDOA and EOTD. While the results tend not to be as positive as GPS, AFLT accuracy usually sits between
50 and 100 metres (Openwave 2002).
2.1.6 Summary of Mobile Device Location Technologies
Before moving onto non-cellular network based methods, and by way of summary, the table below highlights the
key features of the methods discussed above:
9 of 98
NetworkMethod
GSM? UMTS?
Software Amendments?
Network Amendments?
General Method / Accuracy
Cell-ID Yes Yes No NoBy the cell the device is within,
varies
TA Yes Yes No NoTriangulation, time from base
station, poor
TDOA No Yes No YesTriangulation, requires network side synchronisation, 100-300
metres
TOA Yes Yes No NoClassic triangulation of time
signal takes to reach base station, average, better when
combined with AOA
AOA Yes Yes No Yes, costlyMeasures angle to form
triangulation, average, better when combined with TOA
E-OTD Yes Yes Yes NoMeasures signals from known
locations to triangulate at device, good
AFLT/EFLT No Yes No NoTriangulation network side
using UMTS synchronisation, good
2.2 Other Location Acquisition Technologies
While the increasing accuracy of mobile phone network data is promising for the development of this
application, it may be certainly worthwhile looking at the other technologies available to mobile device. The
most obvious example is that of GPS, a function often found on high specification devices. Infrared, Bluetooth
and Radio Frequency are or have been used to determine location in a range of applications. While there has
also been research into the use of Wireless LAN data (WiFi) as a method for locating connected devices.
Whereas these methods may not necessarily be appropriate for wide area roaming, their applicability to tourist
guiding systems might still be relevant. These systems tend to utilise other methods such as proximity and
Scene Analysis (viewing from one point), rather than the triangulation technique as seen in the methods above.
In addition to these methods, some attention will also be given towards developing technologies that could well
have an effect on the delivery of location-based service in the coming years.
10 of 98
2.2.1 Global Positioning System (GPS) and Assisted GPS (A-GPS)
The most well known and widely used positioning method, GPS relies much more upon device capability than
the methods detailed above. The GPS network consists of 24 satellites circling the earth on very precise orbits.
Position is calculated using triangulation methods similar to those mentioned above, however accuracy is very
much dependent on the device location in respect to the position of surrounding satellites. At best, GPS is able
to determine location to within a few metres, with an ability to specify both location and altitude. One clear
drawback of GPS is the need for clear ‘line of sight’ – while objects like cloud and glass won’t cause too many
problems, buildings will prevent direct connections between device and satellite, and usually prevent any kind of
result. This makes its use within an urban environment problematic. GPS also tends to take longer to establish
positioning, taking up to a few minutes to do so, this is far greater than the seconds taken to establish location on
a GSM or UMTS network.
One of the latest developments of GPS is specific to mobile devices. Assisted GPS (A-GPS) uses the device’s
mobile network (either GSM or UMTS) to specify the GPS search area. This method usually operates network
side, with an A-GPS Location Server capable of combining both network-based data (from Cell-ID, TDOA or E-
OTD positioning) and GPS data to predict the position of the device. In combining this information, the mobile
device is able to operate with a weaker GPS receiver, cutting costs and battery drain (SnapTrack 2003, Djuknic
& Richton 2001). The benefits of this hybrid system are wide-spanning, presenting greater accuracy than any
other network-based service, without the specification of a synchronous network, and increasing GPS start up
times considerably (From 1-2 minutes down to 5 seconds; SnapTrack 2003). Further, the Server maintains
constant contact with the device thus making roaming not a problem, and with the addition of mobile network-
acquired data, some positional information can still be obtained when the device is within a building.
Unfortunately, A-GPS requires both hardware (GPS Receiver) and software alterations on the mobile device, as
well as the installation of a Location Server on the network. However, the reduced need for device receiver
accuracy means that costs are not as great as may otherwise be expected.
Assisted GPS stands in good stead for the future. For its division away from using mobile networks allows it to
operate with any other network-based location method, in the form of a hybrid method (Openwave 2002). Its
superior accuracy, along with the decreasing costs of GPS, and resulting prevalence in new mobile devices,
mean that it is likely to become the location method of choice for the future.
2.2.2 Galileo
The Galileo positioning system is currently being developed by the European Union with aim to providing
Europe with a more accurate positioning system that the current standard, GPS. It is due to be completed in
11 of 98
2010. It will provide 4 to 8 metre accuracy through the standard free service, decreasing to below 1 metre
accuracy for Commercial Service, for which a fee will be charged (EC 2003). Other features include better
penetration into Urban centres and through trees (BBC 2005), and five ‘levels of service’ including enhanced
information for commercial (fee paying), search and rescue services and accuracy dependent operations (such as
aircraft positioning). It is also thought that Galileo will provide a more reliable and independent locator method
for Europe than the US military-controlled GPS. It is predicted that, because of the increased accuracy, Galileo
will eventually take over from GPS as the location method of choice in Europe.
This section has provided a look at the device location methods currently used to locate cellular devices. As
demonstrated the move from GSM to UMTS networks has seen the development of more accurate network-
based location methods. However, it still seems that the best accuracy is acquired through handset-based
methods such as E-OTD, GPS and A-GPS. The next section will examine a few other location acquisition
methods, however, moving away from mobile devices to examining use in a wider context. One particular
method of interest is WiMAX, a technology that could potentially compete with the existing UMTS network in
the next few years.
2.2.3 Infrared
Infrared technology offers the opportunity to develop simple, inexpensive tracking systems for confined areas.
A typical system would involve the ‘beaming’ of unique Infrared signals to be collected and identified by local
sensors. By positioning sensors through a building, say, it is possible to keep track of the movements of the unit,
be it attached to a person or an object. One example of Infrared in action is the Active Badge system (Want et al
1992).
2.2.4 Bluetooth
As an inexpensive and widely used method of wireless
communication, Bluetooth offers the potential for providing
information for confined area location-based services.
Location data is provided by determining which nodes
(Bluetooth signal broadcasters) the Bluetooth device is within
the radius of. By comparing which nodes ‘see’ the device it is
possible to determine an area in which the device currently is.
A useful diagram of how this method works is shown to the
side (Gonzalez-Castano & Garcia-Reinoso 2002).
12 of 98
2.2.5 Wireless LAN (WiFi)
With WiFi becoming a more prevalent feature of IT provision, it makes sense to use the coverage to provide
location based services. Although the scale again may be small, simple services such as printing to the nearest
printer or providing guidance through a building can be very beneficial. One such system, developed by
Microsoft, called RADAR uses the WiFi signal range to determine location to within 3 metre accuracy (Bahl &
Padmanabhan 2000). The method uses a calculation comparing signal strength and signal-to-noise ratio received
at three base stations to map a 2D image of the building. However, the system can fail in two respects; firstly, if
the use moves between floors, and secondly if there is a movement of large objects, perhaps people or filing
cabinets, for example. The latter can require the rebuilding of the location database, which can take some time.
The problem of multiple-floored buildings has been addressed by others, notably PinPoint (Hightower &
Borriello 2001), whose 3D-iD system also uses the WiFi radio frequency (IEEE standard range of 802.11). This
system measures the travel time of a signal, requiring specially adapted antennae which brings with it increased
costs.
2.2.6 Radio Frequency (RF)
Another similar method to those mentioned above is that of using Radio Frequency to determine location. While
very similar to W-LAN methods (which, as a necessity, operates using the IEEE 802.11 Wi-Fi Standard
frequency range), it has been proven to be popular in the commercial world for keeping track of a range of
objects (Hightower & Borriello 2001). The most well known use of these products are RFID tags, used
predominantly to track goods shipments. Usually RF tags are scanned using local sensors helping form a record
of object movement, however, RF tags have also been employed on similar ways to the Active Badge system
seen earlier (Bahl & Padmanabhan 2000). In such cases, proximity measurements are made from base stations,
calculated from signal strength and noise, providing a location that will usually be within a building or confined
area. This method provides good accuracy; in some cases to within a few metres (Microsoft’s RADAR system
and the PinPoint 3D-iD system claims this), allowing smooth real-time review of movements.
2.2.7 WiMAX
While WiFi is the current method of choice for small area wireless communication, and UMTS as the method
for advanced mobile device communication, WiMAX has the potential to eclipse both. It utilises similar
standards to WiFi (IEEE 802.16) but with a far greater bandwidth and longer lasting connections between client
and server, and is able to function though existing network towers with only small, low cost adjustments,
providing coverage of around a 30 mile radius (TheRegister 2003). The actual potential speed of such a network
is unclear, with theoretically 70 Mbps possible. However, in recent tests, Pipex determined that indoors speed
13 of 98
was around 2Mbps only 1.2km from the base station, comparing to 10Mbps outside (ZDNet 2006). The speed
and method of use present two key potential applications; a link between broadband access providers and the end
user, and high speed communication (similar to UMTS) for cellular devices. The indoor speeds determined by
Pipex might mean that, in terms of the former, there might be need for WiFi to deliver WiMAX inside buildings,
rather than competing against it. There are already plans to implement WiMAX as a provider of wireless
broadband access in Milton Keynes (ABC 2006), while Samsung and Motorola have already developed
prototypes of WiMAX based phones (Esato 2006, ZDNet 2005).
Given that WiMAX is only a recent development, and tests are clearly still being carried out, it is no surprise that
there has been little research into its potential use within location-based services. However, the signs are
promising. Its long range distribution capabilities (only bettered by cellular networks) twinned with long
connection times suggests that there is certainly potential for the development of excellent location acquisition
technologies.
2.3 Location-Based Services and Applications
The above review has provided a look at the methods used for locating devices using wireless technology. As
noted previously, the methods of most interest are those utilising the mobile phone networks. However, an
examination of other methods has helped show where mobile network methods may be disadvantageous and
how in other situations a greater accuracy may be preferable. It will now be useful to look at how mobile phone
location data has been used in the past to provide a range of services, as well as the range of applications that
correlate with this one.
In response to the rise in popularity and effectiveness of the location tracking technologies examined earlier,
Location-Based Services (LBS) are becoming increasingly more central to mobile phone networks overall
packages. A great deal of potential resides in this technology. As seen recently, predominantly on the Internet,
the personalisation of services is seen as an important way of attracting those people who are perhaps fearful of
technology. Twinned with the rise in popularity of mobile phones, location-based services are very much at the
forefront of this movement. Already available on all networks are services such as finding the nearest cash
point, restaurant or taxi rank. The extension of these services by both networks and external vendors is already
underway; a few examples of such work will be looked at in the next section.
Other recent developments of relevance to this project include the increasing use of wireless technology to
provide information to tourists. A range of methods have been tested, with some now well established in certain
places. The majority of these products use expensive and bulky PDAs (Personal Digital Assistants) with
14 of 98
specifically designed programs based on location derived from GPS information. Other digital methods have
seen recorded audio guides played through mobile phones. A fuller examination of these products will again be
offered later.
2.3.1 Mobile Location Data Applications
In this first section, current applications utilising mobile phone location data will be looked at. Firstly the
commercial applications available in the UK will be examined, those offered by the network providers and then
systems that have been developed by external companies based on these services. Following this there will be a
brief look at how such data has been used across the world in a range of other applications.
2.3.1.1 Mobile Phone Networks
The mobile phone networks have all, within the last couple of years, begun developing location based services,
using network location data, for both their standard and business customers. The complexity of these services
has increased, and now a range of web (through the networks mobile home page) and text-based services are
available. Below are listed the ‘flagship’ services offered by the major UK networks to their standard users:
Orange: Find Nearest text service – offers almost 30
categories to choose from, including nearest Pub, Indian
Takeaway and Dentist. Instructions on how to reach the
destination (walking or driving, depending on choice) are
offered in text format. Available through all phones,
charge for each transaction (Orange 2006a).
Vodafone: A Find and Seek, and Directions services –
similar to Orange but interface based and so provides a
map with the information. Only available to Vodafone
Live! Users, but does not charge (Vodafone 2006a) The
screenshot to the side shows the interface offered to users
seeking directions (3G.com 2006)
T-Mobile: t-zones – Again, similar to the other services, offered through the t-zone interface, includes
map service as well as reviews of nearby bars (T-mobile 2006)
15 of 98
O2: Trafficline 1200 – The only LBS offered by O2 locates which road you are travelling on when you
phone he given number, it will then provide information as to any problems reported along that road (O2
2006).
3: As would be expected, 3 joins Vodafone in providing the most extensive use of location-based data.
In this case, Out & About services that allow the location of nearby objects (such as restaurants,
cinemas, pubs etc), with the provision of a map with zoom through an interface. They will also provide
addresses and telephone numbers for those items identified (3 2006).
Examples of the use of location data in business are not so extensive, with the main usage in tracking shipments
and employees (Orange 2006b) from company head offices. For this particular purpose, for example, Vodafone
opted for a GPS/GPRS tracker service (Vodafone 2006b).
2.3.1.2 Vendor-offered Services
Leading on from the business services mentioned above, development in network-independent services has been
less about information on your own location and more on information about other’s location. There are now a
large number of companies offering web users the ability to track other people movement by their mobile phone
location. Market leaders include FollowUs, ChildLocate, Track-A-Mobile and Verilocation, who tend to market
to worried parents who might want to see where their children are playing, or worried managers who might want
to see where their employees are hiding. These services utilise access provided by the networks to their location
APIs, a fee is charged by the networks for this access. The results are generally provided, as you might expect,
on a map with a buffered accuracy (see below for an example taken from the ChildLocate wesbite), there is also
an option with some to have the result sent via text message to a mobile phone. The user of the mobile phone
must first grant access to allow tracking before these services can operate. However, there have been some
serious questions raised about the security of access granting process, some of which have been voluntarily
addressed by the vendors, but these will be looked at in more detail in later sections.
There has been less of a move by vendors to introduce phone-based
location services. This is probably because the potential output would
not compete with the networks, which can provide free or cheap WAP or
GPRS access to their websites. However, some have tried to compete.
GetMeThere offer ‘Where Am I Now?’ and traffic report maps via WAP
Push (GetMeThere 2006), although these are expensive at £1 per
request.
16 of 98
2.3.1.3 Other Applications
Looking at the use of this technology in a wider context introduces a range of other innovative applications. In
particular, the Enhanced-911 system in the US is a unified effort between public safety agencies and mobile
phone vendors to provide the location of 911 mobile phone callers if required (FCC 2006). The system is
deployed using TDOA and E-OTD methods, with an aim is to reach an accuracy of between 50 and 300 metres -
officially the aim is 50 metre accuracy 67% of the time where GPS is contained within the handset, and 100
metre accuracy for 67% of the calls when network triangulation is used (Marzolf 2005). Coverage across the US
is currently varied, and depends mainly upon the deployment by mobile phone networks.
Another application of network location data is the development
of location-based mobile games. These involve people ‘acting
out’ games in open areas with mobile phones to guide them,
sometimes with large sums on money on offer. The majority
have been developed using high accuracy techniques such as GPS
and W-LAN. There is one example of network data use however.
The BotFighter game (Wired 2002) has been played all over the
world, with the aim to find and ‘kill’ your opponents (who are
also using mobile phones), represented on a game map, based on
geographic data, on the device screen – an example is shown to the side. This application was developed in Java
2 Micro Edition (BotFighters.com 2006).
Finally, there has also been some movement within the network providers to utilise device location data to
benefit their processing methods. One particular application of this is the localisation of SMS handlers.
Increasing SMS traffic has lead to network providers having to rethink the handling of these messages, which
has previously been handled by centralised servers. However, in a move to increase efficiency of these
processes, work is being carried out to distribute processing servers so that only locally sent messages are
handled by the particular server (Cisco 2004).
This section has helped provide an idea of the current developments in the commercial world with mobile phone
location data. There seems to be still a lot of potential for progression in this sector, some of which will be
addressed, in respect to this project, later in this report. The next sections will concentrate on some of the
specific aspects associated with the development of a location-based tourist guide. This study will therefore
include an examination of other wireless, although not necessarily mobile phone network based, tourist guidance
systems and a literature survey of papers covering the development of such systems. This will help provide a
better understanding of the requirements of such systems.
17 of 98
2.3.2 Wireless Tourist Guides
This section will take a look at how others have used wireless technology to develop tourist applications
delivered through handheld devices. This study will take in both those developing in academia and those that
have been launched on a commercial basis.
Probably the best example of a academia-based development is the Campus Aware system developed by a HCI
research group at Cornell University in the US. The system operates on customised palmtop computers, using
GPS as the method for location. The system offers a map of the campus but no specific routing, and does not
provide specific tourist information; instead it allows users to leave their own information and opinions on that
particular part of campus (NY Times 2003). The idea is that following users can then view what people
(including those who have studied at the University) have written about the site they stood at. The so-called
Graffiti system then synchronises notes between palmtops at the end of every day. Of course, it’s a risky move
to not only put your University on the shelf for people to potentially put down but also risk not having any
information attributed to a particular feature. However, Jenna Burrell and fellow researchers (2002) at Cornell
reported that in a test of 129 notes gathered in just one hour, 70 were factual, 59 were opinion, 33 were a
snapshot of people’s relationship with the feature and only 4 were left in error. Overall they found a positive
response, with users finding the content useful and interesting (Burrell et. al. 2002).
The system has since been further developed and extended into a commercial operation, namely Spotlight
Mobile based in Portland (Spotlight 2006). This company have developed a range of location-aware PDA-based
tourist systems, using both pre-defined and user-entered tourist information. Additional features have included
the ability to store user movement and content access, providing valuable information for the managers and
curators of tourist sites. Below are two screen shots taken from a tourist guide for the US Botanical Gardens
(taken from demos from the Spotlight Mobile website). This system identifies which room the user is in and
shows the position of different plants by dots on screen (picture of the left), on clicking on one these points the
user is given audio information about that plant (the interface to which is shown on the right):
18 of 98
These screenshots help provide an idea of how advanced some of these systems have become, and indeed some
ideas to take on to the planning and design stages of this project.
Gulliver’s Genie takes user interaction in a different direction by implementing a multi-agent system which
delivers tourist information according to the user’s personal preferences (O’Hare & O’Grady 2003). In essence,
the output is similar to other PDA systems, outputting a map with marked location with a mixture of text and
multimedia information. However the big difference is that movement is constantly being tracked by a
centralised server which produces tourist information only for objects that it believes the user will be interested
in. The agent will also learn from user requests and constantly update its ‘beliefs’ about the user according to
their activity. Communication between server and client PDA is provided by High Speed Circuit Switched Data
(HSCSD), a communication subset of the GSM network. The actual location tracking, however, is conducted by
GPS, as the researchers felt that mobile network location method provided enough accuracy for the task.
Another system, similar to this one is the CRUMPET system which again incorporates user preferences into the
information provided (Schmidt-Belz et. al. 2002). Within the multi-agent system is contained an ontology that
represents the concepts associated with the specific tourist service. Exploiting the user’s interests in respect to
this structure, it is also possible to extend to making assumptions into what the user may be interested in. The
system also employs inferences in the handling of queries, such as “near by” equating to near to the user’s
position and “how do I get there?” leading to the offering of directions to the user’s known destination. The
paper also raises some interesting general points about the future direction of location-aware device-based tourist
systems. Such suggestions include the incorporation of semantic web technologies, particularly ontologies, in
developing links with agents, such as hotel room and restaurant booking agents. They also suggest that such
developments should take into account the user preferences built up through repeated use.
Another academia-based system, developed in Germany, concentrates on providing blind and partially sighted
users with PDA based tourist information. In this system, each point of interest is given a ‘Hearcon’, a specific
19 of 98
ambient sound that indicates which specific feature is near by. By varying the loudness of the Hearcon
according to the user’s proximity to it, they are able to build up a mental picture of the place they are visiting.
Location is determined by W-LAN tracking and so is designed to work on a smaller scale than the GPS systems
described above. Tourist information is then provided at each point of interest they reach. The system is also
available to sighted users, whose guided by map on the PDA. The locations of other users are mapped onto this
screen, and people are encouraged to cooperate to ensure everyone receives the same tour (Klante et. al. 2004).
One final system of note is a development at the University of Glasgow that enables tourists to share a wide
range their experiences of an area with people watching from the comfort of their own home (Bell et. al. 2005).
Researchers developed software to operate on tablet PCs that not only tracked users by GPS location, also
enables them to add photographs at a particular feature, and communicate their opinions via Voice-over-IP
technologies. Home users were also able to instruct their mobile counterparts in their tour, asking them to take
photographs or give better descriptions by the VoIP connection. Another feature allows users to attach websites
to specific features in the area, one suggestion are Wikipedia articles for people represented by statues for
example. Gradually the system builds up a large quantity of resources for future users visiting (or staying at
home) to access to enhance their personal experience. The work concentrates how certain aspects can benefit
research into collaborative ubicomp, the collaboration of users near and far through mobile or embedded
devices.
A wider range of tools have been developed that are contained on wireless devices, but do no utilise location-
aware technologies. As a result, the majority of these systems are audio based, and delivered through mobile
phone or supplied unit, and with usually no personalisation of the data provided and often require the user to take
a specific route between features. Applications of this method vary, from tourist attractions (AntennaAudio.com
2006) to cities (BeyondGuide.com 2006), with a large number available on the Internet in podcast directories,
for example. If the user prefers to get off the regular tourist track then another option is to download e-guide
books and city maps, such as Rough Guides, to their PDA (PocketGear.com 2006).
This section has helped gain a footing in what kind of work is being carried out within academia in the area of
location-aware tourist guides. As shown above, many of these systems operate using GPS as a location
technology, and many incorporating client-server links between PDA and central processor. Maybe at this point
it should be noted that none of these systems have been deployed to mobile phone, or utilised mobile phone
location technologies (although the Gulliver’s Genie system did incorporate GSM as a way of communicating
between client and server). The survey has helped also gain an understanding of the general trend in these
technologies, plainly the delivery of information relevant to position, but also the need for user’s to have an input
into what information is delivered. It has also been noted the trend towards integration between wide spanning
services responsive to the user, particularly the links the semantic web can deliver. In addition, there seems to
20 of 98
be, in a similar way, a recognition of the importance of collaboration between users of the system in helping to
achieve a greater sense of context.
2.3.3 Other Location-Aware Guidance Applications
Although these technologies might not necessarily direct the way in which this application is eventually
designed, analysis of other location-aware technologies may identify ideas that could be applied in this context.
The key example here is car navigation systems.
Car navigation systems have become very popular over the last few years. Their ease of use, simplicity and
accuracy – all vital ingredients of an effective and accessible IT development – have all contributed towards this
trend. Functionality between models can vary, but in general vehicle position is located using GPS tracking and
mapped onto the road network. If the receiver determines that the vehicle has moved off a selected route then it
is able to recalculate the quickest way to reach the target location. Position is supplied through a customisable
map interface, often with text and audio instructions offering guidance along a route. As suggested above, the
system works using a network of road information, simply connecting two selected positions on the network in
the best possible way. Within the network data is included other information, such as the nature of the road (its
size and restrictions), average speeds, laws applying to the road (e.g. one-way systems) and the position of
junctions (including traffic lights, roundabouts and other road features). Using this information it is also possible
to enforce requirements on the output, such as for it to avoid motorways, or to pick the quickest route (as
opposed to the shortest). The nature of the network method, with its fixed structure, means that current position
in comparison to the next instruction can extracted and used to provide further information. Examples of this
include warnings to drivers about approaching junctions or turnings in their route. In essence, because the route
is ‘known’ more information can be provided to support the guidance between points. In their simplicity, such
systems are also highly portable. Many of the systems are provided through specific units that are fitted to the
car dashboard, however TomTom (2006) have also made their application available for PDA and mobile phone
(although fairly high specification devices), while Blaupunkt (2006) and Becker (TheBassbin 2006) have both
developed navigation applications that operate through an interface in the car radio system.
2.4 Placement within Wider Context
The research up to this point has helped generate a more complete picture of the way in which a location-aware
tourist application might operate. There has been an examination of various location acquiring technologies, as
well as looking at how these have been applied in the past to provide location-based services. At this point, it
might be worth moving away from the application-specific details and towards issues on a wider scale. This
21 of 98
section will therefore feature two key interests; firstly, the placement of location-aware services within a general
movement towards personalisation and service integration, and second, the ethical and moralistic questions risen
by the increasing prevalence of these technologies.
2.4.1 Personalisation and Mashups
The development of location-aware services tie in someone with a move towards creating more user-centric web
based applications. Gone are the days of building a system without user interaction, for with the Internet, and its
massive consumer base, becoming more and more important in people’s everyday lives has come a requirement
for greater, more relevant information. There are many aspects to this movement. On a user level, people are
able to select RSS feeds from which to form their own information source (such as Google News), whilst
websites such as Flickr allow users to ‘tag’ their photos, which, with the high volume of use, enables the website
to determine the strength of links between tags (known as ‘tag clouds’), introducing more relevance to searches.
This idea has been picked up all over the web and combined with other integrations. One good example of this
is LastFM.com which installs a plug-in to the user’s home PC that logs which songs they listen to. By
combining this information with tags, the website can offer a user viewing a particular group or bands page a
range of other acts they might be interested in. Again, LastFM supports the user ‘tagging’ of information.
The above applications are based on the passing and handling of metadata, written in XML code, that, provided
there is a known structure by which the data must be passed, then any volume of data can be extracted and
processed. This movement is generally encapsulated by the term Semantic Web, which differs from the World
Wide Web (and its HTML-based content) by transferring standardised data so that it is machine understandable.
Once the data has been transferred then its user-side processing could vary in a multitude of ways. However, it
is the integration of sources of XML data that really opens up the possibility of services previously
unimaginable. This might include the combination of a dentist’s schedule and your own, to find the most
appropriate time to book an appointment. This is true personalisation of services. And, further, it is not
necessarily only available through a PC; XML is highly transferable and easily handled therefore allowing
Internet accessible handheld devices, such as mobile phones and PDAs, full access to such services. Indeed, the
combination of this technology with location data is another big development in the making. How about being
booked into your nearest four-star hotel? Or arranging registration and booking an appointment at your nearest
dentist? The range of application is immense.
The Semantic Web capabilities have been further enhanced by the development of ontologies. Ontologies,
extensions of XML, map the structure of an area of interest (or domain) in terms of the XML data. The structure
allows for more meaning to be introduced to the interpretation of a single XML file. By understanding the
placement of the XML data through the ontology structure, the computer is able to make assumptions about its
22 of 98
nature. This technology is vital where large volumes of complex XML are being handled, but also, because of
the structure, allow for other suggestions to be made relating to the last data. Examples might be recommending
a book to read following a recent purchase, for example. Again, the improved interpretation of the XML data
enables even further personalisation.
Finally, a brief word on Mashups. These were touched upon earlier when LastFM was mentioned, they are the
integration of application content to form a new hybrid application. The prominence of Mashups have grown
with the development of XML-related technologies, aided by the release of APIs by leading web developers.
There are now APIs available for Google (including Google Maps), Flickr, Yahoo, Ebay, Amazon and MSN
Messanger to name a few, that allow access and integration of the application code. The developments are wide
ranging and often very innovative. MashupFeed.com provide a directory for access to a wide number of
resources and previously developed Mashups. Examples include plug-ins for Google Maps that indicate where
the current major stories are taking place in the UK (using the BBC RSS feed) (O’Neill 2006), SMS feeds from
Amazon (Choo 2006) and even National Geographic article and photo plug-ins for Google Earth. Although
these may be rather trivial applications, they do give an idea of the way in which these APIs may be combined to
form new functionality, including in combination with location-aware technologies.
2.4.2 Moral and Ethical issues
The final section of research will look at the moral and ethical associated with location-aware technologies. This
is a subject that has been picked up by a few news agencies and so is worth considering as another aspect. The
big issue concerns privacy, and whether people know they are being tracked. Ben Goldacre in
‘How I stalked my girlfriend’ (Goldacre 2006) explains how quick and easy it was for him to set up a track on
his girlfriend’s mobile phone, through one of the websites discussed earlier, without her knowing. In this article,
Goldacre suggested that to begin tracking all he had to do was to send one reply from the phone, and delete one
warning message sent at the same time. However, TheRegister.com determined that additionally, as part of the
OFCOM Code of Practice, the tracking providers were bound to send out ‘periodic messages’ – although the
frequency of these messages is not disclosed to the public – in order to prevent such unauthorised tracking taking
place (The Register 2006). Further, it was also found out that there are laws in place to stop people deleting
other’s text messages, a law that can carry up to two years imprisonment.
So there are some laws and regulations in lace to help prevent the Average Joe tracking someone else’s mobile
phone, however, the laws restricting the networks usage seem to be visible. For one, and something the most
mobile phone users are probably not aware of, network providers record 12 months of location data for each
mobile phone. This process, which is voluntarily conducted, allows to be accessed by a range of government
authorities according to the Regulation of Investigatory Powers Act 2000 and Anti-Terrorism Crime and
23 of 98
Security Act of 2001 (Gorra 2006). However, the lack of real guidelines about the use of this data has been
questioned in the media (Rasch 2005, BBC 2003). This echoes the familiar moral dilemma of privacy in the 21st
Century – whether the viewpoint of ‘if you have done nothing wrong, then you have nothing to worry about’ is a
healthy one.
This is not an argument to get into in this project, but at least this section has helped raise some of the issues
related to the tracking of mobile phones. Clearly there are some issues that have been answered, while others
perhaps still need addressing.
2.5 Chapter Summary
This stage of the report has been about building up a bank of knowledge from which to develop a location-aware
tourist application for the University of Leeds campus. Not only has it helped understand better the task in hand,
but also the placement of the current technology in comparison to developing cellular based methods and other
wireless methods. Perhaps more importantly, the current range of mobile phone based location-based services
was analysed, along with the functionality offered by current location-based tourist systems. The research
helped determine that while there are some mobile phone based services that offer users guidance towards
locations, these have not been extended to form full tourist applications. The study of existing location-aware
tourist guides will help ensure a more informed design phase. Finally, two further issues concerning the
development of this system were looked into. Personalisation of services and Mashups are two examples of how
integration through the Semantic Web is improving functionality for end users. The potential for adoption of
these technologies into a system including location-aware technology presents an exciting new direction for this
field. The moral and ethical issues surrounding the capturing of a mobile phone users location were also looked
at, including the laws and regulations currently in place to help protect the user’s privacy.
This section provides an excellent basis to move on from into the design phase of development. However, it is
important to remember that this work has only provided a background from which to move onwards, so there are
likely to be points in the next few stages where further, more specific research is required.
24 of 98
3 Application Planning
The following section will build on the research carried out in the last section, to analyse the requirements of
building a location-aware tourist information service. The approach taken here is a wide spanning one, and
partially ignores some of the external restrictions places on the project, as described in the project introduction.
Therefore, included in this discussion are references to how such a system would be developed around location
data. The issues concerning the eventual deployment onto mobile phones will also be examined, while some
attention will be given to PDA application development, in case mobile device deployment is deemed
impractical.
3.1 A Location-Aware Tourist Guide
As location-based services become more prevalent on handheld devices, their necessity for providing guidance
in unfamiliar surroundings will become better affirmed. This idea is already set in certain environments, in
particular car navigation systems. Many people, particularly travelling business for example, probably can not
think how they coped with just maps to guide their way to strange and foreign destinations. Such system’s
practicality, aided by their ease of use, provides the user with a sense of comfort in that they are unlikely to get
totally lost.
This concept can certainly be adapted on the micro scale. Let’s take the fairly obvious example of a tourist
guidance system. If someone visits a place of which they are not familiar, a tour guide is very useful in helping
you understand the area and its key features. However, what if the visitor to the area wants to explore, break
away from the standard ‘tourist’ route, see features specific to their interests, or perhaps take things at their own
pace? There is no easy way of doing this. Therefore, there is a clear requirement for tailored tourist guides.
Obviously anyone can tailor a visit by themselves; walk around a bit, look at the buildings, take in the air, but in
a few hours will they actually learn much about the area? The answer is likely to be no – some kind of guidance
is required.
Location-aware services can fill this gap in tourist information provision. In this sense, there are two ways in
which this can be done. The first is route guidance – directing the visitor between points they would like to visit.
The second is location aware information – providing information about where they are, and the features around
them. Both of these aspects can be widely adapted to suite the visitor’s requirements. In this next section, these
two aspects will be looked at in further detail, investigating they way in which they could be used, and the range
of applications to which they may be applied. The technical aspects will not be looked at just yet, and such
25 of 98
processes will be treated as black box (the input and output are known, but the inner processes are not). The aim
is to provide a full system plan for a location-aware tourist guidance service for the University of Leeds.
3.1.1 Location Acquisition
The system, as described in the objectives of this project, will be primarily structured around the determination
of location of the user by external means. The incorporation of location data provides a method by which
information can be made relevant to the user. It was discussed in the first section the various ways by which
location can be acquired, the way in which they work, and some examination was made of commercial and
academic applications of these currently available. In this section more emphasis is placed upon its
implementation within this application, and how it might influence the functionality of the complete system.
With the access to the mobile network location API as described in the Project Outline, as well as looking how it
could be incorporated within this application, the use of GPS as a locator will also be discussed.
3.1.1.1 Orange API
The Orange Location API operates via the exchange of XML data between requestor and server. The request is
made using XML-RPC, where the XML is sent using standard HTTP transport routes to the Orange API Server.
Within the request must be included the user name and password (provided once access has been granted), the IP
or proxy address of the requestor device and the MSISDN (mobile number in 447834150147 format) of the
device you wish locating. This process could be executed from a mobile phone, providing there is a GPRS
Internet access (WAP does not assign mobile phones an individual IP address). If the request is a success, the
response is returned by XML-RPC with details of the device x, y coordinates, the accuracy of the reading (metre
radius) and the time and date the reading was taken. If there is a problem with the request process the returned
XML will detail the problems with the request. Problems might include poorly formed XML code, invalid user
credentials or service unavailability. The structure of the returned call means that the code can be parsed using
standard XML and XML-RPC reading libraries. This means that the results are relatively easily and quickly
handled once received from the Orange server, and allows the request and response mechanism to be simply
incorporated within the rest of the application.
3.1.1.2 Global Positioning System (GPS)
A GPS-oriented system would operate slightly differently. Instead of receiving the location data from an
external source, the computation is completed within the device, meaning reliance upon Internet connection and
service registration is removed. The execution of these requests can be made using J2ME (Java 2 Micro Edition)
within the combined MIDP (Mobile Information Device Profile) and CDLC (Connected Limited Device
26 of 98
Configuration) runtime environment, all now freely available (described in more detail later), and contain
standard libraries capable of extracting data from built-in GPS receivers.
3.1.2 Route Guidance
In this context, route guidance could take a number of forms. The two broad methods are text based, where the
user is guided in relation to visible objects (such as paths or buildings), and graphics based, where the route is
mapped in front of the user. There are benefits to both methods. The text approach is accurate, and easier to
follow than an overhead graphic, given that instructions are offered that relate to the things they see. While
graphical approach is arguably more flexible as it enables the user to see what is around their route as opposed to
be restricted to following text ensuring that you don’t miss a turning. The decision to choose between the two
has, in the past, been relatively straight forward – use both (as demonstrated by some of the products studied in
the last section). This ensures the accuracy and applicability of the text based approach, along with the
flexibility of the graphical approach. During the prototype development stage this subject will be revisited,
where only one of these methods will be used. During that analysis a greater consideration will be given to the
technical aspects related to the implementation of each.
Whatever route guidance operation is used, the starting point will be generated from location data. The location,
taken from GPS or mobile network triangulation, would act as the starting point for the user to go somewhere. It
is the way in which this destination is chosen that presents the biggest design choice.
Again, there are two options at this stage. The first is the pre-selection of the route by which the visitor wishes
to take. This allows the user a substantial amount to time to think about what aspects of the campus are
important to them prior to visiting. The most appropriate way for this to be implemented is to offer a website
through which people can pick their route. The website would offer basic information about the various features
of campus, and probably be slightly tailored to which department they are visiting. The website would also offer
a range of ‘packages’ related to certain interest areas, such as sports facilities, libraries, bars etc. The user would
be allowed full flexibility as to the full length of tour and positioning of breaks, however the amount of
flexibility allowed around the schedule would be down to the user. Certain events, such as in-school talks, may
be automatically added to the tour and not open for reschedule. The scale of information provided to the user
during each stage of the tour would depend on the weighting or amount of time the user has dedicated to that
feature (a more detailed examination of the way information could be distributed will be looked at later in this
section). The ‘design’ of the individual’s tour would then be transferred to the handheld device. This process
would most likely, in the current environment, be carried out on campus onto PDAs rented out by the University.
However, it is not unforeseeable that simple Java applications, including the tour data, be loaded quickly onto a
Java-enabled mobile phone by Bluetooth or Infrared transfer (again something that will be covered in more
27 of 98
detail later on). During the tour, paths would be mapped between current location (acquired from GPS/Network
data) and their next chosen destination. As explained earlier, the length of the tour stage and amount of
information provided can be tailored according to the interests of the visitor.
As suggested above, this kind of system would allow the visitor a great degree of pre-planned consideration as to
the nature of their visit. This would particularly useful to those who see the value of having their own decisions
about what they see, or those who have tight time restrictions such trains to catch and the like. However, what if
the user does not know their plans for the day, or do not have enough time (or maybe desire) to pre-plan their
trip? In this case, a more ad-hoc system would probably suit, where more emphasis is given to providing the
user with a simple and flexible interface to their tour.
In the case of this system, the user would complete no prior planning and generic, non-customised devices would
be distributed to visitors. This would allow much more flexibility for the user, who would be able to choose
their next destination by selecting on screen. One drawback of this method could mean that the scale of
information may not be tailored so effectively to the user’s visit of a certain feature. This is because there is no
anticipation about the length of each stage. In this case maybe information could be offered all at once or time
delayed, offering more details information the longer the user stays at that location. In addition, because of the
generic nature of this application, the user would have to schedule in their own required stops, such as talks and
demonstrations organised by their department. However, the flexibility of this method would allow more time
for people to adjust their tour to how they feel at the time. It could be that the visitor wishes to take a break at a
café, or go to the toilet, both of which may be pointed out and guided to through the interface, from their current
location. Much of same logistical considerations, attaining to the distribution of software and handheld devices,
relate to this method as much as the last.
The two methods discussed here deal with two approaches to the tour route guidance system. There are those
who appreciate the time to consider their route, and there will be those how do feel they need to. There will also
be those who would prefer flexibility in their schedule, while others who prefer to keep on time. There will also
be some users who need pre-planning structured within their tour. For example, disabled visitors would require
guidance along the disabled routes (although this is something that might be better handled by reconfiguring the
routing algorithms). It seems there would be a general requirement to offer both systems along side each other,
as both compliment different approaches to the tour.
28 of 98
3.1.3 Provision of Location-aware Tour Information
This next section will discuss the ways in which information may be stored and distributed to users, according
with the nature of their visit. Obviously, the way the data is stored within such a system should take full
consideration of the way in which it will be used. As discussed above, the ideal would be to offer users scaled
information depending on the length of time they have devoted to one particular place. Storage methods must be
identified that represent the data in a way by which this process can be executed fluently and efficiently.
3.1.3.1 Storage of Tour Information
The nature of the way the University is constructed means that any information relating to a particular area could
link in to numerous categories of information. For instance, if the user was near to the EC Stoner Building,
information produced could relate to the building itself, the individual departments within, or even the food
outlets and toilets inside. Indeed this problem, the necessity of data layers can apply all across campus, with
potentially further specification within categories. The key to handling this problem is to store the data using in
a way which enables the extraction of particular sets of information, depending on the user requirements. If this
isn’t done, then the information delivered can not be properly specialised, and risks delivering information
overload. Two methods that might help ensure this does not happen will now be looked at.
The first option is the development of an ontology. Ontologies are hierarchically structured representations of a
given domain. The increased prevalence of ontology has been twinned with the development of the semantic
web, born from the realisation of a need for simple data exchange between different platforms. They are often
used where clear definitions can be made between objects within the environment. Within each class division,
further specification in class detail can be made, while the child classes inherit features from the parent, until all
individuals are classified. This is a concept that sits well with the description of a University campus. By way
of helping explain and examine how an ontology could be applied to this situation, some of these hierarchies are
listed below:
Faculties, Departments, Research Areas and Research Groups: Firstly, academic structures. The University
of Leeds is split into ten faculties, which then have control over a varying number of Schools. The School of
Computing, for example, sits within the Engineering Faculty. Within the School of Computing there are
three key research areas – Artificial Intelligence, Multidisciplinary Informatics and Theory of Computing.
Within these three groups fit research groups that contribute to these research goals.
Buildings: While a true hierarchy may not be actually apparent, the nature of buildings on campus does off
some specification. The divisions in this case might be into Academic, Accommodation, Venues (perhaps
with further specification between lecture theatres, concert and exhibition venues), Services and
29 of 98
Administration. Such a specification would then allow information to be better directed, depending on the
nature of the building.
Facilities: Facilities may be divided broadly into Food & Drink, Shops and Toilets. Further than this, Food
and Drink may be separated into Restaurants, Bars and Cafes.
Further features might also be included within an overall University structure that do not encourage further
specification. Examples might include Sports Facilities, Car Parks, Entrances and Park land.
The specialisation of information, according to the hierarchies shown above, would certainly aid in providing the
user with greater relevance in the information they receive. For the user, who is viewing the information would
not just see what is in front of them, but also what relates above and below within that hierarchy. It could be that
the user is offered information about the EC Stoner Building. From there they would view that it is an academic
building, and perhaps be offered information about the departments within this building. They then might
choose to examine the information on the School of Computing more closely, at which point they would also see
how they school fits in with its parent faculty, and view their research goals. It is this structuring of the
information, the interrelatedness, whilst demonstrating this to the user, which enables the user to gain a better
understanding of the complete structure of the University. Without this structure, it is possible that people would
not really get a full understanding about how the University operates.
As discussed earlier, for some it would be useful to have a degree of specificity within the data offered to the
user. This is another feature that would benefit from the incorporation of an ontology-based information
structure. In terms of application development, if the option was available to tailor the information provided to
user depending on their interests, the in-built layering of information would be a must. Without this, there would
be no way by which the provision of information could be altered by interest. Say, for example, a visitor comes
to the University who’s visiting the School of History and has an interest in the Sports facilities. However, when
they pass by the School of Civil Engineering they almost certainly would not wish to be offered information on
that school’s research objectives. Whereas if they passed the School of English (who are within the same
faculty), it might be interesting to know it’s relation towards that Faculty’s approach. The structure basically
allows some a degree of inference into the interests of the individual, achieved through an understanding of the
relationships between objects within the campus domain.
The development of an ontology takes careful research and iterative design, therefore extending upon the ideas
of hierarchy discussed above might be something for a later date. However, the principles of an ontology within
such an application have been demonstrated, and the possible merits outlined.
The second method worth discussing as a way of containing the tour information is the construction of a
relational database. In many senses, relational databases and ontologies are very similar. Both are capable of
30 of 98
creating a structured conceptualisation of a given domain and both are able to recognise the hierarchical
relationship that might exist between components. However, the application of each may be quite different.
Relational databases tend to be more specifically task-specific and application-oriented (Spyns et al 2002),
whereas one aim of using ontologies is to enable independence and multi-platform coherence. In practical terms,
relational databases therefore introduce strict integrity onto the data, with all rules between objects explicitly
declared. This compares to the inferences capable from an ontology, as discussed above.
In the case of this application, because the relationships tend to be fairly explicit (e.g. the links between
buildings and departments, departments and faculties etc. are quite clear) the choice between an ontology and
relational database comes down to a matter of its potential integration with the rest of the system. Both methods
enable fairly straight-forward extension should that be required. And sizes on disk are unlikely to be massively
different between the two. The question comes down to whether the system is required to integrate with a wider
system, such as the preplanning website talked about earlier. If this is the case then the ontology would, with its
broad aims at contributing towards common structures for data exchange and its founding upon the cross-
platform web-oriented language XML, operate far more effectively at enabling cross system functionality. If an
ontology was to be implemented into such a system, then users would be directed into selecting features to visit
that exist within the ontology structure. If a relational database were to be used for this operation the complexity
and code duplication would be far greater. Therefore once again the choice comes down to the method selected
for the whole system. However, in light of the argument laid down above, it might be a better option in terms of
future development and integration with web services to contain the information within an ontology structure.
3.1.3.2 Provision of Information
The way in which the tour information might be fed to the user has already been discussed in some part earlier.
However, it is important to add to this to ensure that a full picture of the system is developed. As described
earlier, there is a need for layers of information pertaining to a particular object. It has also been described how
this need may be supplemented by the development of an ontology (or relational database). It would now be
worth looking at how this underlying structure might be used.
The development of an ontology provides us with a structure within which each object on campus can be placed,
in part contributing to an overall picture of the University campus. Therefore, and as hinted at earlier, the degree
to how much the links within the ontology structure are emphasised must depend on the strength of the link
between your target (or home department) and that object. For example, if a user is walking towards a library,
say the Brotherton Library, and they walk passed the Edward Boyle Library, the user would be told that that
building is another library, then extending to other information such as about its study facilities, its IT facilities
and perhaps what subjects it covers. This is because there is a strong link to be inferred between the target
31 of 98
object, and the object they user is passing by. The user is still on their way towards the Brotherton Library and
they pass the Student Union (of course you would hope the routing methods would direct the user towards the
Brotherton Library better than passing the Union on route from the Edward Boyle Library!). The user does not
have a marked interest in the Union facilities (bars, union events, etc), and it is not their home destination (the
department they are visiting). In this case, the user would only be offered the building information, that it was
the Union building with not much more on top) – because the user’s interest is not formally recognised, this
extension in information, this inference, is not made.
With this aspect of the application now slightly better explained, and before moving onto looking at the
deployment of the application, it might be useful to examine how the overall system might be constructed
diagrammatically. The diagram demonstrates how the system would operate with pre-selected tour information,
as described earlier:
Ontology Location Request
Current TargetHome Department Expressed Interests
Location Returned
Determine Location’s Relationship with Relevant Objects
Central Process
Request Answered by External Process
‘Description’ of University
Selected Information Returned to User
Visitor Preferences
Data Extraction
Data Source
Routing Function
32 of 98
3.1.4 System Deployment
With the location acquisition, routing and information storage and provision aspects of the system discussed, it
makes sense to move on to how the application might be delivered. Tying in with the overall objectives of this
project, this section will concentrate on how the system might operate on a mobile phone, but also extend to look
at development on PDAs.
3.1.4.1 Mobile Phones
Recent developments to mobile phones have seen the ability to accept and execute Java applications become
commonplace. These Java-enabled phones allow the user to develop a Java application and run it on their
phone. Such moves have been supported by the development of tools such as J2ME (Java 2 Micro Edition), and
the runtime environment created by Mobile Information Device Profile (MIDP) and Java Wireless Toolkit for
CLDC (Connected Limited Device Configuration), both has been specifically designed to cater for the
development of small device applications. There are also numerous mobile phone SDKs and emulators available
that allow programmers to develop around the functionality of the device and test their applications prior to
handset launch. In addition to this, as will be shown later with Arc MapObjects, software companies are
recognising the importance of developing scaled versions of their software that can be operated on handheld
device. For the increasing power and capabilities of mobile devices means that more and more is being made
possible.
The transfer of applications to mobile phone is also relevantly straight forward, with a number of options
available. Bluetooth, Infrared and data cable are common across most modern handsets, and should be
considered as part of the launch of a complete system of this nature. For, as described earlier, if there is to be
some ‘customisation’ of the information offered to the user prior to starting the tour there must be a way of
transferring these preferences to the device. In addition, modern mobile phones also contain GPRS capabilities
that would enable communication with external sources. Using these methods it would be possible to transfer
requests and responses in XML code that could deliver the device position quickly and efficiently. Some mobile
phones also offer GPS as an extra feature. Its potential involvement in this project will be discussed in the next
chapter.
From the descriptions above it would seem that the mobile phone could represent the perfect platform for the
development of this application. As well as being small, light and easy to use, they also offer development of
Java applications, with a range of toolkits now available, and provide a numerous methods to enable
communication with external sources. However, there are some other points to consider. Firstly, and quite
important to this application, is the size of the screen. As discussed earlier, the system aims to provide users
33 of 98
with mapped details of their route, as well as presenting information on one or more areas of interest. This is
quite a lot to fit onto a small screen. Examples of GIS software in action on mobile phones (with standard sized
screens) are currently few and far between so careful planning and consideration would have to be granted to the
nature of the GUI during design. The second potential problem is the amount of data freely available on the
phone for development. However, this is becoming less of a problem with the introduction of data card slots
into the devices (on a recent check, all of the new Nokia, Samsung, Motorola and Sony Ericsson offered this
function). Despite this, consideration should be given to data sizes during development to ensure that undue
costs are not incurred on having to purchase extra memory. In consideration of these issues, it may be
worthwhile also exploring the development possibilities within the PDA environment, and how some of these
issues may not be as prevalent on these devices.
3.1.4.2 PDA (Palm Top Computers)
The other option available to this application is a launch on to palm top computer. These devices tend to offer
more computational capacity, and therefore probably greater processing speed, and do not have the same screen
size problems as associated with mobile phones. The development tools available for PDAs tend to match and
even better (because there has been more development in the past in PDA applications) those available for
mobile phones. As a result, there are more examples and a wider resource base to draw from for development in
this area.
However, obviously there is one big draw back. Palm Tops can not utilise the mobile network location API.
Standard PDAs tend to be standalone, with no SIM card connecting to a mobile phone network. Many do,
however, offer GPS capabilities which, as we will show in the next section, might be a worthy replacement for
the network acquired data. One solution to this problem might be the so-called Smartphones, which contain SIM
cards and much of the PDA functionality (notable models include the BlackBerry, palmOne Treo 600 and the
iPAQ h6315). There are development toolkits for the BlackBerry (BlackBerry 2006) and palmOne Treo
(TreoCental 2006) that would also help provide a basis for development of the application.
3.2 Chapter Summary
This chapter has introduced four of the key components concerned with the planning of a device-based location-
aware tourist information service. Although the design, in this case, has been focussed upon an application for
the University of Leeds campus, and has thus adopted with it the restrictions of developing in this environment,
many of the aspects discussed could be equally applied at any location-aware tourist information system. The
first section, location acquisition described the implementation of only mobile phone location data and GPS as
34 of 98
these are only two methods currently available, on a wide scale, to a project of this kind. This section described
how both methods could be implemented within the application environment. The next section, on Route
Guidance, introduced the concept of user preferences, and how these might be handled. There were two
suggestions – one, allow the user to record what aspects of University life they are most interested in prior to
visiting the campus, or two, allow the user to decide for themselves on the day. The potential implementation of
both was described in detail, and both clearly have their benefits to different groups of users. This section
emphasised the importance of fully considering the needs of the user when developing a system such as this.
The next section discussed how best to handle the storage and access to tourist information. Two methods were
described, one the use of an ontology, the other a relational database. It was described how the nature and depth
of information attached to each part of campus may be varied according to a user’s perspective, and how both of
these technologies are capable of providing a representation of this. It was decided that, in view of the
previously discussed movements towards web integration, that to develop using an ontology would leave an
application of this nature in good stead for integration with future web developments. The completion of this
section helped mould a general system design incorporating location-aware technology, user preferences and
ontology mapping.
The final section of this chapter examined the potential for application deployment by mobile phone. It was
described how mobile phones are now very capable of supporting quite advanced applications, and how a
number of toolkits have been made available to support mobile phone application development. However, it was
noted that processing power and screen size could restrict an application such as the one described above. It was
determined that such a development might be better suited on PDA or Smartphone.
The next section will move away from the design side of this development, to focus on the practical
requirements of such systems. This will include an evaluation of the location methods that might be employed
within this application, as well as the availability of map data to support this development.
35 of 98
4 Data Selection
The previous sections have looked at the issues concerning the development of a location-based tourist
information system and the technologies that might help support that development. The following sections will
move onto explore the practical elements of developing the system. This next chapter will be split into two
sections. The first will test the accuracy of location acquisition services around the University of Leeds, with a
view to estimating how well such a system might operate in this environment; with the second section looking at
how geographic data may be used to support the development of such an application. The next chapter will
detail how a prototype has been developed to demonstrate some of the issues discussed in this and previous
chapters.
4.1 Location Method Evaluation
4.1.1 Orange API
As explained from the outset, access to the Orange API has not been secured. As a result, no testing has been
carried out into the accuracy of the method around the University of Leeds. However, there are some datasets
available that suggest what readings might be expected. Before continuing, however, it should be noted that, as
mentioned during the Background Research section, accuracy of the Cell ID method can vary widely depending
on the cell density in that area.
4.1.1.1 Research
Mateos & Fisher (2005) conducted a study comparing accuracies provided by the service against ‘true’
accuracies (determined by GPS) in an UK city environment. They found that companies providing this service
(based on O2, T-Mobile and Vodafone networks) supplied far greater radii than the comparisons measured by
GPS. Indeed, in some cases they found accuracies that were reported by the providers to be 5250 metres but
actually were only around 250 metres. Overall they determined an average ‘true’ accuracy of 800 metres.
However another paper, written by Hato & Asakura (2001), determined that actual accuracies averaged at 3615
metres. These are interesting issues to consider.
As part of the documentation available to developers using the Orange API (Orange 2006c), is listed an example
batch of results from using the facility. The accuracy measures vary between 745 and 4638 metres, with an
average of 2011 metres for the 20 results. It is not clear, however, where these measures were taken or whether
they are a real dataset.
36 of 98
Another issue, and again one investigated by Mateos & Fisher (2005), is that of time difference between the
request and the time at which the location was measured. They found that on around 87% of occasions the
measurement had been made within the last 5 seconds. However, they also found that in a small percentage the
measurement timed at over 8 hours earlier. In their documentation, Orange does not provide any guidance as to
how this aspect might vary through their server. This study again highlights the potential pitfalls of adopting this
approach, yet it has been not possible to test this under this environment.
These studies help provide a general idea of the level of accuracy that might be acquired through these methods,
but do not complete the picture in terms of this project. Accuracy testing using the Orange API around the
campus is a must in order to get a proper idea of whether this method could work in this case.
4.1.2 Global Positioning System
It was discussed in the last section how GPS might be the best way of replacing mobile network location data
within the structure of this system. In response to this, it makes sense to carry out some testing on the GPS to
determine whether it represents a useful tracking method within the campus environment. The testing was
conducted to test for discrepancies between position on the ground and the position provided by a GPS receiver.
4.1.2.1 Method
The test was conducted in two parts, with 149 points covering most of the campus. During both parts, on
separate days, the weather was similarly cloudy but not overcast. The testing was carried out using a Garmin
Etrex GPS receiver, although different models were used for the two stages of testing, however on checking their
battery strengths were similar. The tests were carried out by moving to a position, marking it on a large scale
map of the campus, then taking a GPS reading from that position. The GPS receiver was held at chest height
and angled upwards whilst always facing north (as determined from the map). The GPS receiver was given until
its readings evened out, normally around a minute would suffice to make the reading. The position of
measurements was taken to produce a spread of points across campus and, in some cases, to test the GPS
effectiveness in concealed areas (i.e. near to tall buildings, arches etc.).
4.1.2.2 Results
A map of the location the readings were taken from, along with the GPS measurement and accuracy reading can
be found in Appendix D. In this section, there are also extracted areas of the map where it was found that no
GPS recordings could be taken.
37 of 98
4.1.2.3 Analysis
Considering the height some of the buildings on campus, the results of the GPS testing tended to be very good,
averaging an accuracy of around 29 metres. However, one concern is the large discrepancies found between the
locations from which the reading was taken and the position suggested by the GPS receiver. In these cases the
actual position is found outside of the accuracy buffer provided with the GPS reading (some examples of this are
circled above). This difference was more apparent in areas of low signal, such as between the Parkinson
Building and Rupert Beckett Lecture Theatre, where the GPS receiver calculated a position within the
Emmanuel Centre, where the difference between the points was over 60 metres and far outside the provided
accuracy reading. The problem, however, was notable in its presence only within the first set of results gathered.
While it might be expected that difference conditions might produce variation in accuracy, one would not expect
the ‘true’ location to fall outside of the accuracy buffer surrounding the GPS coordinate. However, this issue has
both positive and negative connotations. On one hand, although the first set of results varying in quality, the
overall accuracy of the testing was very good. In addition, none of the problems described above were found in
the second set of recordings. However, these problems introduce doubt into the results found during this
investigation. It can certainly not be suggested that this problem, be it due to a fault in the GPS receiver or
general system on that day, may be a one off event. There is certainly the possibility that should GPS be used
within such a system, and within this environment, that the same problems might occur. In summary, while the
results are positive in some respects, further, more in-depth investigations should be carried out to assure the true
effectiveness of GPS in this situation.
In addition to the discrepancies identified in the results, there were some issues associated with the general GPS
method. Firstly, and this is a problem natural to the GPS method, is the lack of coverage in some parts of
campus. In this development a lack of location means a lack of information, thus rendering the system useless
under some conditions. Perhaps it is interesting to remember that these points would be covered by the cellular
network data, which remains relatively unobstructed by buildings. Another issue, and one certainly quite
pertinent to this kind of application, was that sometimes, when moving GPS accuracy remained either very high
(up to 120 metres at times) or would not settle on a particular accuracy. This would mean that if the user were
moving the information provided could be inaccurate. This would probably require some kind of instruction
within the application to ensure the user receives the most relevant information on the areas in which they are
interested in. Finally, it was also noticed that the receiver required a few minutes to start up and connect to the
surrounding satellites. This is a problem, again, specific to the GPS method.
Overall, while the results may have been position, this investigation has helped identify the problems associated
with the GPS system. While the accuracies may remain better than many of the other options, the results are not
38 of 98
entirely conclusive. It may be interesting, as a side point, in future work to investigate the A-GPS and Galileo
methods in comparison, should (and when) they become available.
4.1.3 Comparison of Methods
This evaluation is fundamentally flawed without the testing being completed for the Orange Location API,
however, previous research, as outlined above, gives us some idea of what might be expected from use in an
urban environment. Firstly, despite the GPS measurements varying between stages the results tended to be very
accurate, certainly in comparison to what has been described of the mobile phone location data. Whereas the
GPS accuracy (measured by the receiver) average around 29 metres, the lowest accuracy found mobile phone
data was 800 metres. This means that potentially at any given point the user could be within an 800 metre
radius. As described above, there was a strong tendency to overestimate this accuracy by the companies
providing the data. To help understand this distance better, the two maps below represent in the form of a path
across campus, the accuracy of the two methods. With these maps, perhaps a better understanding for the
distances involved can be granted:
30 Metres – GPS – Length across the Pond next to the Roger Stevens Building
800 Metres – Mobile Phone location data (Mateo & Fisher 2005) – Route from the top of campus near to the
Chemical Engineering Building, passed the Parkinson Steps, through Campus, underneath the Sociology
Building, down passed the back of the English and Music departments, then to the back Level 7 entrance of
School of Computing.
Roger Stevens Building
30 Metres across ‘Cooling Pond’
39 of 98
Clearly the second map represents worrying information in respect to the development of a tourist guide that
needs relatively accurate location information. This kind of distance, which if drawn straight south from the tip
of campus would reach the Leeds General Infirmary, is far to great to offer any kind of firm information on
location across campus. The kind of data required would have to recognise the difference between standing next
to, say, the Edward Boyle Library and the School of Computing - any distances greater than this would lead to
troubling uncertainty. Clearly the GPS unit produces results that would match this requirement. However, from
the results found during testing it can not be concluded that the GPS receiver necessarily presents the correct
accuracy. In this case also further testing would be required to affirm its effectiveness in this situation.
The other issue to consider is the speed of request to result. As mentioned in the earlier section, Mateos and
Fisher (2005) found that a small percentage of results showed the position of the mobile phone far in the past. It
Top of Campus Near Chemical Engineering Building
Level 7 Entrance to School of Computing
Passed the Parkinson Steps
Through Campus
40 of 98
was described earlier, however, how GPS on the other hand has its own problems in this respect. These findings
suggest that, although not being detrimental to the use of GPS in this system, there should perhaps be some
consideration to this problem built into the process.
It may be said that the results are both conclusive and inconclusive. On one hand, it appears that poor accuracy
of the mobile phone location data would leave this option unworkable. Whereas the GPS accuracy provides,
overall, what seems to be an excellent method for tracking devices within the campus environment. Yes, there
are some areas on campus where no reading can be found, but compared to the accuracy of the mobile phone
data this hardly matters. However, on the other hand, how are we to trust the accuracies provided for the mobile
phone location data? After all, this average accuracy was derived from O2, Vodafone and T-Mobile networks,
the Orange API may present far better accuracy. Yes their example results suggest an average of over 2000
metres, but how do we know that these results aren’t fake, or conducted in a rural environment? There are also
questions over the true accuracy of the GPS data. While it says it is at one point on the campus with a certain
accuracy, it is actually somewhere else. This disparity needs further investigation. Therefore, in conclusion, on
face value the results appear to be very clear, and one might say ‘there is no smoke without fire’ in respect to the
mobile phone location data. However, if we dig a bit deeper the results become more blurred and it’s clear that
the suitability of both methods is questionable.
The section has helped somewhat towards helping determine which method of location acquisition would be best
suited to this task. Although the results are not wholly conclusive, they have helped towards shaping the picture
of how and whether such a system would operate in the campus environment.
4.2 Map Data
The next section of this chapter will look at how geographic data can, as the location acquisition methods would,
support the development of this system. The geographic data plays an important ‘backseat’ role in bringing the
application together. For, as mentioned in the last section, a visual output for this kind of application is essential
in helping the visitor understand their location on campus. In this part we will describe the requirements of the
data, look at the various options available, and make some justification for selection. Obviously, throughout
there must be consideration given to the requirements described in the Application Planning section.
4.2.1 Requirements of the Data
There are two broad objectives that the geographic data must support. It must firstly help support the routing
mechanisms described in the Application Planning. There is not a need for the data to contain details of what
41 of 98
each building is, as this would be handled by the ontology, but there must be a way of defining between
buildings in order to allow recognition that the user is next to a particular building.
In terms of the first objective, this means that the data must adequately represent the areas that one can pass
through, and those that they can not, independent of how this definition is made. In other words, and tying in
with the second objective, there should be a way of defining areas by their ground data. If these definitions are
not made to the requirements of the project then there should also be the option to edit the map data to ensure
better results. Finally, the data must also be a clear representation of the area, and something by which a visitor
to the area can quickly draw information from despite their unfamiliarity with the area.
4.2.2 Map data options
This next section will look at the range of geographic data products available to tackle the requirements laid
down in last section. Particular focus will be passed to the Ordinance Survey Land-Line.Plus and MasterMap
formats. One beneficial feature shared by both is that they are both customisable using a database manager such
as Microsoft Access. This is because each aspect of the data (e.g. object areas, contour lines, annotations) are
extracted as individual classes, a very useful feature that will be explored in later sections.
4.2.2.1 OS Land-Line.Plus
As required, Land-Line.Plus data makes definitions between objects as part of the geographic data. The data is
prepared by extracting the line data from Ordinance Survey maps and recording what the lines represent. The
lines are coded according to this definition, representing items such as buildings, walls, roads, boundaries etc,
there are 63 categories in total. The scale in urban areas such as this is around a very detailed 1:1250. An
example of the Land-Line.Plus data on the University of Leeds is shown below, the lines are coloured according
to the feature they represent:
42 of 98
However, on testing of the data a potential problem appears. As specified above, in order to complete a path
around the objects one can not pass through there must be some definition of objects (i.e. buildings). In this
case, the lines may represent the edges of objects, but there is not recognition of the edges representing a
particular object. But there is the question of whether you need the solid object, after all the only part of the
building the user will be interested in, in this scenario, will be the edge of the building (as this is as far as they
can go into the building). Instead of blocking or weighting entry through the object this can be applied to the
lines representing the boundaries of an object. Users can be routed within the correct channels, and guided
through the lines where the boundaries do not matter so much (i.e. paths through fields). So in essence the data
is no different to representing the objects.
The nature of the line format does present a problem for the purposes of routing however. Despite allowing
customisation, there are numerous areas on campus where lines would stop the any path running through. Some
of these lines can be deleted without problem (arches for example) and some can be weighted to encourage path
flow through them (such as paths through parks). However, some can not be rectified this way as some lines
represent a number of actual surfaces. An example of this is shown below.
43 of 98
The arrows show areas which are ‘passable’ in
reality but restricted by the line data. In other
cases it could be possible to weight these lines
so that a route would be encouraged to be
mapped through them. However, in these cases
it would change a large area of changeable
boundary. What actually are walls become
ignored by the routing algorithm.
This problem can be rectified be editing the database. However, the process would involve a great deal of work
dividing the lines by coordinates and creating new segments for each entrance. This option is still worth
considering, but should be compared to the amount of editing required with other data formats.
Another drawback of this data is its presentation. The lack of solid object definition means that the data is less
clear. Some buildings are easily recognisable as buildings, but other objects might be confused for roads or
paths without knowing what each line colour represented. For presentation purposes the blocks could be filled in
using Paint or a similar program, but this would ultimately save the data as an image file, and thus not contain
the coordinate data required for plotting paths.
Size of database representing campus data: 5.6 MB
4.2.2.2 OS MasterMap
MasterMap Topology, which at the time of writing is not on full release, builds on Land-Line.Plus by
representing objects as solid objects. Instead of say four lines representing a building, this is symbolised by a
polygon with which a range of data is held, generally in greater detail than its predecessor. The result means that
objects can be defined as individually, without the generalisation made by edge data. Two examples of this are
shown below:
44 of 98
This example shows the ‘Cooling Pond’ next to the Roger Stevens Building. In the MasterMap data, on the left,
it is represented as a separate object (represented by colour here). Whereas the Land-Line.Plus (on the right)
boundaries represent it as having the same boundaries as the ramp above (again note the colour). Although this
particular example might not be adopted in this project (you wouldn’t like someone to walk off the edge of a
ramp probably as much as you would want them walking through a pond), the example demonstrates how the
handling of areas can allow a greater flexibility in the way the data is processed.
This second example shows how archways may be handled using MasterMap. In the Land-Line.Plus data they
are represented by numerous lines that, to tackle this problem of blockage, would probably be deleted. In the
MasterMap data they can be handled separately and left on the map, therefore not creating a false picture of the
actual situation. It also might help the user, if they are unfamiliar with the environment, to look for arches as a
way of recognising their position in relation to other objects.
At this point, one would be right in thinking ‘hold on, what about those lines in the MasterMap data, wouldn’t
they cause the same blocking problem as in the Land-Line data?’ It’s a good point, but the lines only actually
represent the boundaries between polygons, and would not form a block across a path. Crossing between
objects, in this context, would depend upon what that object represented. This means that less editing work
would have to be completed prior to launching the routing operation to break up these lines. In addition, as
45 of 98
described above, in many cases where objects may have just been deleted from the Land-Line.Plus data, they can
be weighed accordingly, as the arches above would be to match the ‘ease of path’ along the road beneath.
Its representation of objects as solid also helps improve the readability of the map. For the classifications of
objects provided within the data can be used to colour the objects differently for display. This can be seen in
effect in an example of MasterMaps use in section 4.1.3.
Finally, there is one slight draw back. The size of this data, for the University campus, is four times that of the
Land-Line.Plus data, at 21 MB. This would mean consideration would have to be given to the amount of disk
space available on the device.
4.2.2.3 Other data formats
There is range of other data formats available, which could be used for display purposes. These sources tend not
to have the same kind of micro area definition as available in the MasterMap and Land-Line.Plus data, with little
individual representation of buildings as would be required here. The closest available product by scale is
probably the 1:10000 Raster which, as a raster, is only an image file and does not contain geographic data about
there area (although its placing in the coordinate system is held within an attached ASCII file). There is also the
Meridian 2 (1:50000) and Strategi (1:250000) datasets which, as Vector files, do offer some distinction between
geographic objects. Unfortunately the amount of detail required is not reached here.
In conclusion then, these datasets maybe useful in some circumstances, but not here. They are either not detailed
enough to focus on the campus, or do not contain the required distinction between objects.
4.2.3 Choice of product
From the descriptions above, the choice seems fairly clear. Only two formats really provide the object
definition, customisation and detail required for the task. However, Land-Line.Plus does have its flaws, and
MasterMap, aside from its large size on disk, provides all of the features required without the need for drastic
editing. It is also very clear in its definitions of objects, and the way in which they have been geocoded (how the
geographic data has been assigned to objects) means that similar objects can be displayed similarly making a
map much easier to read. The nature of this geocoding, and the extent of detail used to distinguish between
objects, means that the routing algorithms have more detail to go on, and thus make better and more relevant
choices (see the archway example above). A complete display of the MasterMap data for the University campus
can be found in Appendix E.
46 of 98
4.3 Chapter Summary
This section has covered two of the key aspects associated with the development of a tourist guide application
for the University of Leeds. It was firstly described how, despite not having access to mobile phone location
data to test on campus, some data was found to suggest broadly the accuracy of the method. It was shown that
the lowest ‘true’ accuracy figures found presented an average of 800 metres. It was demonstrated that this
accuracy is not good enough for this environment, given that it would cover most of the campus itself. Accuracy
testing was completed using GPS. This was found to be far more accurate than the mobile phone network data,
although some questions were raised about the actual accuracy of the GPS receivers. Overall the results were
inconclusive for a lack of mobile phone location data means a fully educated selection can not be made at this
point.
The second part of this section moved on to looking at the map data required for the route processing and display
purposes of the application. Two key options were explored, with OS MasterMap data appearing the better
option. It was recognised that the data needed to be easy to understand, it needed to represent objects
individually at a large scale level, and needed to allow customisation of the data. Other options were discussed
and reasons for not adopting these explained.
47 of 98
5 Prototype Development
Thus far the majority of this study has looked at how an application that uses location-aware information might
be developed to help guide visitors around the University of Leeds campus, and provide pertinent information
according to their location. This concept has been analysed in two senses, the nature of the application and what
it could provide, and the geographic data and location services required to enable this development. In this next
section, the development of a prototype to demonstrate the implementation of some of these aspects will be
demonstrated. To stress the point, and as explained from the outset, the development of the prototype is to
demonstrate the concepts of delivering such a system, and will not necessarily relate to the structure of a final
delivery.
5.1 Specification
As mentioned above, the key aim of the prototype is to provide a proof of concept of some of the functionality
described during the Application Planning stage. This short section will now provide a more exact description of
the system as well as examining the tools required to complete the task.
The broad aim of any prototype in kind of project must be to provide some kind of location-based service. In
relation to the design, there are two clear ways in which this has been done – through route guidance and
provision of location-pertinent information. Therefore, the aim of this ‘proof of concept’ was to implement one
or both of these services.
The way in which this was best done was obviously affected by the kinds of constraints under which this
prototype was being developed; some of these will be examined now:
Access to Location Technologies: With the problems found with acquiring Mobile Phone location data
(as described earlier), and the lack of access to GPS equipment that can be connected to a computer,
there was little chance of acquiring real location data, at least before the end of the project. Therefore it
was decided that location would be best simulated.
Geographic tools: A full analysis of the tools available will follow; however, some analysis would have
to be carried out to determine the best way in which the route might be mapped. This is clearly
restricted to the available software only.
Time and knowledge base: There were a wide number of aspects to this project, including potentially
coding in a number of languages that had been previously unknown to the user. This, inevitably, has an
effect on the extent to which an application of this type can be developed.
48 of 98
With these constraints in mind, an examination of the available software, with which the application may be
developed, was undertaken. The approach to this was two-fold: Firstly, the identification of available methods
by which to construct the route between two simulated points, and secondly, the identification of tools to support
development and enable execution of the prototype. With this information, a more precise specification of
design could be provided.
Before continuing, the last section discussed how OS MasterMap data had been made available for the
development of this prototype. Consideration for this was a key part in the identification of the following tools.
5.1.1 Route Construction tools
The ArcGIS Desktop package provides a wide set of tools for the handling of geographic data. The package
includes tools for handling the data in a number of different ways. These tools are capable of providing a range
of datasets derived from the values of an original file. Within this package were identified two methods for route
construction. The tools required to handle the MasterMap data, and to execute the route construction are
discussed below, with justification concerning the choices made provided later.
5.1.1.1 ArcMap
The ArcMap application is primarily used to combine, display and present geographic data. It enables a range of
data types (including raster grids, vectors coverages and points etc.) to all be represented together through shared
coordinates. It also offers excellent display and symbology options, allowing users to present their findings in
many different ways. As well as having a wide range of presentation capabilities, it also brings together a range
of simple tools for complex data processing. The range of tools include the spatial analyst functions that we will
use later on, although in a different way. The full range of tools available can be accessed through the
ArcToolbox within ArcMap.
5.1.1.2 MapManager
MapManager is capable of handling many of the data formats in which geographic data is distributed. In this
case, MapManager will be used to extract the MasterMap data and convert it into database format (each layer of
data is exported as a class, enabling handling using database manager such as Microsoft Access). From this
format, it is then possible to query and extract certain portions of the dataset, as will be demonstrated later.
49 of 98
5.1.1.3 Spatial and Network Analyst
With the range of tools available from the ArcGIS package, and the flexibility of the geographic data, taken into
account, a number of ways were presented by which the routing task could be approached. As mentioned above,
the Spatial and Network analyst tools offer a range of methods capable of determining relativity between
different points in a geographic dataset. Of particular interest to this task, were the Least Cost Path function
from Spatial Analyst, and the Network Manager from the Network Analyst toolset. These two options will now
be briefly discussed, with rationale for the choice of method given:
5.1.1.3.1 Least Cost Path – Spatial Analyst
This method calculates the path of least ‘resistance’ between two or more points in a geographic dataset. The
path formation would be constructed around the costs contained in a raster, in this case, based on the cost of
moving across or through different ground conditions (e.g. Paths, Buildings, etc.). The method operates firstly
by constructing two rasters from a given point based upon a supplied cost ‘mask’, where the greater the value,
the less likely it is that a path would be directed through the object.
The first of the rasters calculates the distance cost of travel from the given location, ensuring that the shortest
path and one that does not pass through high cost areas of the mask are most preferable. The results can mean
that it may be less ‘costly’ to go further around a building than to go through it, for example. The second raster,
the back link raster, offers data on the direction a path should take to the location from any other given location
in the data, to ensure it remains least costly. The result is a definition for each cell of the dataset, directing the
path in one of eight directions (e.g. Up, Upper-Right, Right, Lower-Right etc.).
Once these two rasters are formed, based upon the cost mask and starting point, a least cost path can be
calculated to any other point in the given area. By using this method, the user could be presented with a path
through campus by which they may follow to their destination.
5.1.1.3.2 Network Analyst
The network analyst function operates around a structure developed to represent the possible routes within an
area. Such a structure is most likely to be developed manually, separate from standard geographic data, although
OS MasterMap Road data, which represents the road and path networks in the UK, is currently limitedly
available. In the case of this project, a network would be developed in ArcMap, which matches the path
networks around the campus.
50 of 98
The routes are constructed from paths and nodes, the latter of which acting as junctions between paths and
enable storage of information about a given location. The nature of this system of nodes means that paths may
cross yet remain disconnected from each other, such as when a bridge crosses over a path beneath. Additionally,
the network development features also allow for the mapping of a hierarchy of route type, enabling the definition
of route preference. With this network in place, the network analyst determines the quickest route between
points on the network, quickly and easily. While, similarly to the Least Cost Path method, it would be possible
for the defined route to be mapped onto screen, the network system may also allow for the generation of
directional instructions on how to reach the location (e.g. a left turn at node 6 could be transferred into a more
relevant instruction).
5.1.1.3.3 Rationale
It is clear that both methods could work well in this kind of project, what is important is to analyse which would
offer the best solution given the restrictions of the technology and environment.
Comparing the two, clearly the network method could offer greater specificity within objects, such as particular
buildings, instead of the masking by type of object, which would have to be conducted in the Least Cost Path
method. However, the network rigidity that enables this could be a disadvantage in the campus tour
environment. When someone is looking around a place for the first time it is unlikely that they would like to feel
as if their movements were constricted. When you visit the zoo, you don’t want to stay on the paths, you want to
go and play with the animals (except if they’re lions I suppose) – the same principle applies here. If the network
method was to be adopted, whenever someone went off the network they would have to find their way back on,
or near to, the path in order to receive guidance. The Least Cost Path method utilises the full extent of the area
therefore, feasibly, you could be anywhere and still get a path to where you want to go.
In terms of technology, the two location methods we have looked at are both potentially inaccurate to variable
scales. If the case was that the user was located away from a network path when they were in fact not, the
results might seem confusing leaving the user feeling confused or uneasy. Alternately, the Least Cost Path
method would display a path starting from the approximate position of the user. In this case, from here the user
would be able to identify the discrepancy and still navigate using the offered route.
Another consideration with these methods is the processing involved in generating the route guidance. The
Least Cost Path method seems certainly more processor heavy, with 2 maps and 2 point generations for each
request. The Network method uses a single defined network and offers a quick and simple route resolution
given a start and end point.
51 of 98
To summarise, the Least Cost Path method offers a more appropriate option for this project and thus will be
adopted for use here. Despite its processing benefits and good features, the network system is more suited for a
larger scale guidance system, such as those seen in car guidance systems. The potentially large processing
requirements of the Least Cost Path method were carefully observed during the construction and testing of the
application, to ensure processing times did not become excessive
5.1.2 Application Development
The second key development choice was how to implement the execution of the Least Cost Path method into a
prototype application. It was decided, given past programming experience, that the development would be made
in Java. Therefore, methods were identified to enable the integration of the Arc functions and Java. Three tools
for integration were found, however none of which offered the complete answer initially.
5.1.2.1 Arc MapObjects – Java Edition
The MapObjects API offers users the ability to implement some of the Arc package functionality into a Java
application. Included in the software are Java Bean classes that enable the customisable display of maps as seen
in ArcMap, and methods to enable the extraction and querying of geographic data from map datasets. The
emphasis behind this release is on the development of lightweight cross-platform applications, with the display
methods favouring display through Applets. In addition, MapObject applications can be easily adapted for
implementation on PDA or Mobile Phone. Indeed, a specific MapViewer package has been developed to allow
just that.
While MapObjects seems like a great prospect on paper, its ability to participate in extensive Java packages is
lacking. What are offered are basically the tools for displaying geographic data. Unfortunately, and particularly
in the case of this project, the processing methods that make Arc so valuable are missing. Indeed, cost path
analysis is not available through MapObjects. In addition, the API does not offer the handling of raster or
database derived geographic data, conversion of this data in shape or image files must be carried out before
being displayed through MapObjects.
As outlined above, MapObjects can be useful in some respects, but will not provide the Arc capabilities required
to run the path analysis needed here. Despite this, MapObjects will be adopted into this prototype for its
geographic display capabilities, with the data processing carried out by other Arc applications.
52 of 98
5.1.2.2 Arc Engine
ArcGIS Engine is a far more advanced version of MapObjects. It offers a wide range of geographic processing
capabilities, including the spatial analysis packages required for this project. Applications can be developed in
Visual Basic.NET, Java and C++, but require the presence of the ArcGIS Engine Runtime environment,
restricting applications to desktop. Unfortunately, the ArcGIS Engine is really aimed at large-scale multi-user
enterprises, and is thus priced to match (around $15000 for the Developer Kit and more for the Runtime
Environment). As a result, the ArcGIS Engine will not be used to develop this prototype.
5.1.2.3 ArcObjects
ArcObjects enables the customisation of the existing Arc Package. It allows the user to add, amend and restrict
functionality to users of applications such as ArcMap, ArcCatalog and ArcScene. And because it is based upon
these existing applications, the full range of Arc capabilities is available. However, the aim of this prototype is
to develop an application similar to the one a user might eventually see on a mobile phone or PDA, meaning that
a degree of separation from pre-existing applications is required. As a result, the ArcObjects route will not be
taken any further here.
The lack of a suitable Arc package to integrate fully with Java presents a slight problem. For the aim of the
prototype should be to demonstrate the application of the path construction mechanism, with a degree of
separation from the processing application. The only option remains is to execute the Arc commands from Java,
using the existing available Arc applications. It was identified that ArcGrid might provide the interface to enable
this integration; an outline of this application is offered below
5.1.2.4 ArcGrid
ArcGrid is a command-line based application of the Arc package. It operates through the input of raster grids,
and running mathematical algorithms on the grids on a cell-by-cell basis, in order to provide some kind of
output. It was also identified that included in the ArcGrid functions were the commands required to execute the
Least Cost Path function. After researching the issue further, it was also determined that it was possible to run
Arc command line interface from typing commands into the Run line, suggesting that its execution from external
applications was possible.
Another feature of ArcGrid and the other Arc command-line interfaces is their ability to handle the input of
multiple commands at one time, for sequential execution. This input is provided using Arc Macro Language
53 of 98
(AML). This functionality would enable the input of the commands required to generate the least cost path in
one execution.
This configuration provided the necessary link between function and application, and with the methods
identified for development a full design could be laid out. Later, exact details are provided on the nature of the
commands used to generate the information using the methods discussed here.
5.2 Design
With the constraints recognised and the available software selected, the next stage involved designing a system
that would represent a good proof of concept of the original application plan. The design is shown below in
graphical form:
From this design it is clear to see that the location and destination is firstly extracted from the map, provided by
the MapObjects interface. These points will probably be selected by mouse clicks. The points are then sent to
ArcGrid for construction of the route (a full explanation of how this is actually done is provided later). Once
Location Selected
Destination Selected
Map Display and Processing
Map DisplayedMapObjects enabled
X, Y Coordinate
X, Y Coordinate
Route Processing
Location and Destination X, Y Coordinates
ArcGridMap Route
X, Y CoordinatesAML Script
Mapped Route
Mapped Route
Location Selected for Information
Information Request andLocation
Information exported to interface
Tourist Information on Location
54 of 98
generated, the mapped route is then added back to the display. If a request for tourist information is received,
again this service will again be provided through mouse clicks, the location is looked up and the appropriate
information extracted and output to the user interface. The design is fairly simple, however, as will be shown in
the next section, the integration between interfaces is rather more complicated.
5.3 Implementation
With the suitable tools identified and acquired, and the design of the prototype constructed, the next stage
involved the implementation and construction of the plans. This process was split into two key parts; data
preparation, and the development of the prototype.
5.3.1 Data Preparation
This section will document the methods used and the decisions taken during the preparation of data required for
processing within the prototype application. Following this section, a full explanation of it’s incorporation
within the application will be provided.
5.3.1.1 ArcGIS Methods
In order to attain a Least Cost Path between two points, a number of different Arc methods were used, firstly to
prepare the raw data, and secondly to execute the Least Cost Path technique. The following section details the
various techniques, applications and modules employed to acquire a path between two points from the original
OS MasterMap dataset for Leeds University.
5.3.1.2 Importing OS MasterMap data
The MasterMap data is supplied in binary format, within a gzip file. In order to access the data using Arc
applications, and to allow maximum customisation of the data, the binary file was transferred into a Personal
Geodatabase. This operation was conducted using MapManager 9, an application capable of handling the
MasterMap data. From the extraction options offered by MapManager, all data features were converted. The
resulting database, accessible through Microsoft Access, offered each aspect of the map data as individual tables,
including area, outline and map annotation data. As explained earlier, the MasterMap data offers excellent
insight into the nature of the topology seen on the map data, therefore offering the opportunity for refined data
extraction. This refinement was executed in Microsoft Access
55 of 98
5.3.1.3 Preparation of a MasterMap Travel Mask
As explained previously, the Least Cost Path method operates most appropriately when there are areas where
routing preference is variable, in other words, there are areas where you want the path to go and there are areas
where you don’t. When it comes to creating the mask for this project, it is clear that the decisions made will
have a large effect upon the functionality of the end product. In this case, much of this decision process is based
around the capabilities of the technology in hand. For example, the nature of GPS suggests that the user could
not be offered visitor information if they were indoors. As a result, the mask would have to be the extraction of
buildings from being routing through by the Least Cost Path algorithm. A fuller discussion is now offered on the
choices made during the construction of this mask.
The Least Cost Path method does not require simple yes or no answers to whether access is available to a certain
area of map; instead it is possible to vary the favourability of a route being constructed through a particular area.
However, before making these decisions, an exploration of the available divisions was undertaken.
The most basic divisions were identified in the Area table, within the Theme attribute, which separated each
defined area of the data into either Buildings, Land, Roads, Tracks and Paths, Structures and Water. While this
division may seem acceptable at surface value, no access to Buildings,
Paths fully defined for example, on closer inspection of the data problems
arise.
This section of the map shows area definition around the School of Art
and Design near to the Student Union (a copy of the original MasterMap
data can be found in Appendix E). Point A shows where an archway
passes, and Point B is a set of Stairs into the building. These are both
significant as, in the case of Point A, if a mask was to be applied to exclude buildings, the free access through
this archway would be ignored and paths would be routed around it. Slightly differently, Point B represents an
area which may be of use in terms of application functionality, by identifying stairways on campus it may be
possible to reroute disabled users around these points.
In seeking to address these problems the DescGroup attribute was identified as a possible point of resolution.
While offering slightly more information about the nature of Land, something which may be useful when
constructing the mask, it did not address the problems above. Despite this, it was decided that these attributes
introduced enough significant information, and so were kept on. A simple select query across the two attributes
presented the following combinations:
A
B
56 of 98
Theme DescGroup
Buildings BuildingBuildings GlasshouseLand General SurfaceLand LandformLand Natural EnvironmentLand UnclassifiedRoads Tracks And Paths PathRoads Tracks And Paths Road Or TrackRoads Tracks And Paths RoadsideStructures StructureWater Inland Water
The final distinction was made using the DescTerm attribute which offered Archway, as well as Step, as a
distinguishing features, thus introducing greater potential specification into the mask. Again, a simple select
query left the following combinations of attributes for mask weighting:
Theme DescGroup DescTerm
Buildings BuildingBuildings Building ArchwayBuildings GlasshouseLand General SurfaceLand General Surface Multi SurfaceLand General Surface StepLand Landform SlopeLand Natural Environment Nonconiferous TreesLand Natural Environment Nonconiferous Trees; ScrubLand UnclassifiedRoads Tracks And Paths PathRoads Tracks And Paths Road Or TrackRoads Tracks And Paths Road Or Track Traffic CalmingRoads Tracks And Paths RoadsideStructures StructureStructures Structure Upper Level Of CommunicationWater Inland Water
Each attribute combination was then weighted according to how appropriate the surface was for routing through.
Clearly, scores for buildings were set high to prevent routes through these, but much of the weightings were set
with reference to the object as shown in ArcMap. These prevented some potential issues, including the case of
the term Structure which represented a number of bridges and objects on top of buildings, therefore the weight
was set to the same as paths. Those objects deemed ‘inaccessible’ to this project were given very high values to
prevent any paths being mapped through them. The weightings are shown below; they were set according to the
descriptions offered by the MasterMap database. The values assigned to the weightings were done so without
57 of 98
any specific analysis of the relationship between the weightings. Instead it was deemed that an iterative process
carried out during the Testing and Evaluation stages would be a better process for setting these values firmly. In
terms of the values, it was decided to set inaccessible objects (e.g. buildings and water) to a very high weight of
1000, to ensure no paths passed through these areas. A weight of 1 was assigned to all preferred areas, with
accessible non-path areas given scores of 5. Slopes and steps, which would make the area harder to cross, were
given scores of 10, while undesirable yet still accessible areas, were given 20 as a score.
Theme DescGroup DescTerm Weight
Buildings Building 1000Buildings Building Archway 1Buildings Glasshouse 1000Land General Surface 5Land General Surface Multi Surface 5Land General Surface Step 10Land Landform Slope 10Land Natural Environment Non-coniferous Trees 20Land Natural Environment Trees; Scrub 20Land Unclassified 5Roads Tracks And Paths Path 1Roads Tracks And Paths Road Or Track 1Roads Tracks And Paths Road Or Track Traffic Calming 1Roads Tracks And Paths Roadside 1Structures Structure 1Structures Structure Communication 1Water Inland Water 1000
With this table creates in Microsoft Access, an append query was then written to add the Weight attribute to the
Area dataset where Theme, DescGroup and DescTerm matched. With this query executed and results verified it
was then possible to view the weightings in ArcMap, the Weighted Area map can be found in Appendix F.
5.3.2 Prototype Development
This section describes how the development of the application was undertaken. Details will be provided on how
an application was constructed to execute the methods discussed earlier within the Java environment. It will also
be demonstrated how the Arc processes were executed in order to convert the weight data, described above, into
a path between two points.
58 of 98
5.3.2.1 Data Conversion
As described earlier, ArcGrid is capable of executing the Least Cost Path commands as an external operation.
The application, however, requires the input of raster grid data in order to function. Therefore, the first step
involves the conversion of this data into raster format.
The weighting map requires only one conversion, as it remains the same no matter where you are moving to and
from. However, consideration has to be passed as to the resolution at which the data is converted. The greater
resolution, the larger the mask file size and the longer time it takes to reprocess the Least Cost Path. To ensure
the best possible resolution was used, the quality of the resulting map was compared to the time it took to
generate the image. It can be assumed that, because the techniques to be used work on a cell-by-cell basis, that
the greater the processing time, the far greater time it will take to create a path from the data. The results are as
follows (as Appendices G-K show, resolution strongly affected data accuracy):
20m Resolution: Processing time - 1 second
10m Resolution: Processing time - 2 seconds
5m Resolution: Processing time - 5 seconds
3m Resolution: Processing time - 9 seconds
1m Resolution: Processing time - 17 seconds
In the end, it was determined that, while the resolutions are 1 and 3 metres offer good visible accuracy, they
would take too long to calculate (such a system should not be waiting minutes to receive a result). As a result,
the 5 metre resolution was selected, offering good accuracy while only take a short time to compute.
5.3.2.2 Arc-based Data Processing
Other conversions to raster would have to be made every time a request was made for a new Least Cost Path.
Firstly - the mapping of start and destination points. The most suitable method here was to create the points in
Arc’s point format then convert them to raster grids for processing. The point was created from British Grid X,
Y coordinates. The code used to create these points can be found in Appendix L-A
In order to operate the Least Cost Path process as planned (through ArcGrid), the points can not be in simple
point format. Instead they must be then converted to grid points, using the POINTGRID operation. This
conversion was carried out using the commands show in Appendix L-B.
59 of 98
This function offers two options for dealing with the data within the grid surrounding the converted point, the
choice depends very much on the requirements of the resultant grid. In this case, because the surrounding data
would be taking no part in the Least Cost processing, it was set to NODATA (the equivalent of null).
The Least Cost Path methods require the construction of a number of different feature grids prior to execution.
Indeed, the start and finish point grids shown above are two such datasets. The COSTPATH method, that maps
the path, uses two particular grids to draw information from. These are the Cost Distance and Cost Direction
grids. Both of these grids can be constructed from the same function, shown below, with both being based
around the location, or accessibility, one of the two points created above.
To create the Cost Distance grid, an accumulated cost is calculated for each cell of the grid, as a function of the
distance from a given point and the ‘weight’ of the land the cell is representing. This part of the operation helps
to ensure that the eventual paths mapped represent the least distance, for the least ‘cost’. The Cost Direction grid
(or Back Link grid) is calculated from the direction a path would need to go from each cell to get to a point.
Each cell is given a value of 1 to 8, representing the 8 main directions on a compass (starting with 1 = East going
clockwise to 8 = North-East). In essence, the two grids are static representations of the information you would
need if you wanted to get to the given point – the distance telling you how near you are (in terms of cost), the
direction telling you which way to go.
The function used to create these grids requires one of the location points (in this case we will use the destination
point) and the travel raster created earlier. This code for this execution can be found in Appendix L-C; take note
that although the function is run to create the Cost Distance grid, the Cost Direction grid is created during this
process:
The resulting Cost Distance and Direction Grids can be found in Appendices M and N. With these two grids
created, was then possible to calculate the Least Cost Path between the original points. As explained above, the
Distance and Direction grids are based around one of these points, in this case the destination. The COSTPATH
function takes the other point, and the information from the Direction and Distance grids, to map the shortest
path between the two. The coding for this operation can again be found in Appendix L-D.
The resulting output is a grid containing one or more lines representing the best route or routes between the two
points. This output can now be displayed as a layer on top of a map to provide a visible link between the two
points for the user seeking this information. An example of this in action can be seen in Appendix O.
The commands explained above were all executed through the ArcGrid interface, a method that would not be
very appropriate for use by an average end user. Instead, these commands must be grouped together and
60 of 98
executed through an interface, where the user is able to see a direct link between their position and where they
want to get to, mapped out in front of them. The next section of this report will examine the development of a
prototype application to demonstrate the use of these path creation algorithms within the context of a tourist
guidance system.
5.3.2.3 AML Scripts and External Execution
AML script is the programming language of the Arc package. It features many of the standard programming
operations such as loops, data containers and output. However, it also allows a user of the script to execute
multiple Arc operations together. In the case of this prototype, there are two clear groups of operations that need
to be completed, through Arc, to provide the output required. The first is the creation of the location and
destination Arc vector points from given map coordinates. And the second, to run the commands explained
above – converting the points to grids, creating the cost direction and distance grids, and then finally running the
cost path operation.
The reason for executing these two operations separately is because they would have to be handled slightly
differently. On one hand you have the cost path algorithms which are fed points and output a path, with no
diversion from this operations, while on the other, the scripting required to create the points will be different
every time, because of the varying locations and destinations set by the user. As a result, while the path creation
scripting need only be written once, the point creation script must be written at every execution.
The AML scripts used in this prototype do not vary much at all from the Arc commands explained earlier. In
fact, on top of these commands, only simple additions are made to the AML script to properly configure the Arc
session. The exact scripting can be found in Appendix P-A.
As explained earlier, these commands are executed in ArcGrid, producing raster grid data files that enable this
kind of processing. However, during the construction of the Java application, it was determined that in order to
display the resulting path through a MapObjects interface, the data format would have to be vector. As a result,
before ending the path generation script, a GRIDSHAPE command was added, as shown below, that converts
the grid data into an Arc Shape file format, and one that can be display by MapObjects:
pathshape = GRIDSHAPE(path)
As explained above, the other script, to create the points from the given coordinates, would have to be written at
each execution containing the exact coordinates. The Java scripting for this operation is provided below, using
61 of 98
the standard file writing utilities to write the AML script containing the passed coordinates. Again the exact
AML scripting can be found in the Appendix in section P-B
To execute AML, one usually has to execute a Run command from within an Arc interface. In this case,
however, the requirement is to execute the script externally from the Arc command line. This is possible in Java,
by opening an Arc session and feeding it the Run command. The Arc session is begun by executing a batch file
from Java that contains the Arc configurations and calls the command through the Arc interface. A similar
method is executed for both scripts. An example of the batch file scripting used to execute an AML file is
shown in Appendix P-C.
The example batch file above can be used to execute both AML scripts. As hinted at earlier, original execution
of the batch comes from with the Java program. This operation is carried out using the Runtime and
Process classes, imported from the standard java.lang library. The combination of these runs the batch
file, which in turn executes the AML by launching an Arc session. A BufferedReader command is also
used to output the progress of the operation to the command line. The whole process is contained within an error
handler. A sample of the script used in this section is found in Appendix P-D.
The processes described here provide the link required to generate a path from two given input points. One
further batch file and AML script was also setup to delete created layers following their creation in the path
generation process. Given that the software being created would only be a prototype, there is no requirement to
index and save the data produced during this process, and thus the decision was taken to remove the data
following its use in the application. The method used is shown in Appendix P-E, however the AML script
differs, deleting firstly the raster grids, then the remaining data files, including the path Shape files and the ad-
hoc point generation AML script:
5.3.2.4 MapObjects and Data Display
Clearly one the most important aspects of this prototype is the user interface. For it is through the interface that
the location-aware services will be delivered. It was explained earlier that MapObjects provides many of the
useful display tools of the Arc package for a Java environment. The MapObject aspects are called from a Java
Beans API, and were placed within an Applet written using the standard AWT (Abstract Window Toolkit) Java
library. This next section will provide a technical explanation of the data and display operations within the Java
prototype, and how MapObjects was used to handle some of internal geographic processing.
62 of 98
The application consists of four main parts; the display of the data, the capturing of location and destination
points, the generation of a path between the points (explained above), and the provision of data for certain areas
of the University campus. These will now be handled in turn.
5.3.2.4.1 Data Display
The map display aspects of the prototype interface were provided by the com.esri.mo2.ui.bean package.
The initial map display is provided by a map window, with its primary layer being a Shape file of the
University campus. This shape file, converted from the MasterMap data, contains all of the data required for the
identification of what each polygon on the map represents. In addition to the map area is a ScaleBar which is
adjusted to show scale by centimetres to metres, and displays the mouse X and Y map coordinates. Finally, a
ZoomPanToolBar enables the user to zoom in and move around the map. Buttons are provided for execution
of features described later, and labels to aid user guidance around the system.
5.3.2.4.2 Capturing Points
Immediately from launch of the application, the user is invited to select ‘to’ and ‘from’ points between which a
path will be calculated. The user selects the points by clicking on the map, markers are placed according to the
position they select. Only two points are recorded, with subsequent points being ignored. Points are recorded by
taking the screen X and Y coordinates and converting them to the map coordinates, according to the coordinate
information held within the map panel. If the user decides they would like to change the position of these points
before configuring the path they may click the Redraw Points button enabling them to do so.
Once these points are recorded, the user clicks the Generate Path button, which launches firstly the generate
points AML script then the path construction script. Information as to the progress of this operation is written to
command line. Obviously if this were not a prototype this might be handled slightly differently. Once the
scripts are complete, the map display is updated with a red line indicating the suggested path. The user is
instructed of the results through text display at the base of the window.
5.3.2.4.3 Provision of other Location-aware data
Once the line has been output, the user is invited to search along the path for information on the buildings they
will pass. This information is provided by the user clicking on the buildings near to the path line. On doing so,
information is provided about the building. This function is provided by firstly extracting the geographic data
from the area where the mouse was clicked (geographic location is determined using the same methods as the
63 of 98
point extraction above). Using the unique polygon identifier held within these fields, it is possible to determine
which building has been selected. For example, if the identifier equalled 1000032582394 then the user has
selected the Edward Boyle Library. Using this simple identification a wealth of information (perhaps including
both text and images) can be provided to the user about the Edward Boyle Library.
Clearly, if this were not a simulated prototype – and the user’s position was derived from location-based data
and subsequently updated along route – then the information delivered at this point would perhaps be more
pertinent to the user’s requirements. However, this method provides at least an indication of what might be
possible when the user has been provided their route in an area in which they are not familiar.
The full application programming can be found in Appendix Q.
5.4 Chapter Summary
This section of the study has examined the use of existing geographic tools in the development of a prototype
that demonstrates some of the aspects associated with delivering the full scale system described in this report.
During this development process it was established the ranges of tools and applications that were available to
help create this prototype. The eventual design consisted of a Java application, supported by Arc MapObject
JavaBeans, used for display and geographic data handling. Route construction was carried out with the external
execution of AML code within ArcGrid, batch files were constructed to run this code. The resulting output, a
route between two points, was constructed depends on the obstructions between the two objects. These
obstructions were weighted according to the ease by which they may be crossed. These weightings have been
initially based upon MasterMap data definitions; however, the following Testing and Evaluation sections aim to
further develop these definitions. In addition to the provision of a route as a location-aware service, some
provision of tourist information was implemented into this prototype.
As described above, the prototype does not necessarily match the exact requirements of such a system, but does
demonstrate the stages through which the development of such an application would have to go through. The
next stage of this report will examine the effectiveness of the path algorithms used in this prototype, and
investigate how changes to map data could affect the results produced by these algorithms.
64 of 98
6 Testing
The last section explained how a prototype was developed to test the route mapping algorithms created
between two points on campus. A particular interesting part of this development was the assignment of
weightings to 17 different categories of map data, based on a combination of data from three attributes of the
geographic data. The assigning of categories was done by the information extracted from the database alone,
without reference to the features represented on the map. Therefore, as well as offering an opportunity to
improve on these weightings, this section will also test the accuracy of the OS MasterMap data.
Before commencing testing, two important points of reference are the weighting assignment table in Section
5.3.1.3 and the original map data in Appendix E.
These tests will examine the paths formed between various points on campus to help build a picture of the
general tendencies the paths take. The paths were generated using the prototype and have been mapped onto
the travel weighing map (displaying a green (1) to red scale (1000) indicating the weighting). Do note
however that, although there lines between objects on the maps shown, these just definitions of boundary,
and do not have an effect on the flow of the path (as demonstrated in Section 4).
6.1 Test 1: North of campus to
South of campus
This test examines the path formed when moving
from the north to the south of campus. It is quickly
noticeable that, instead of going through campus, the
path has taken a longer route around. It also seems
that instead of mapping through the campus, where
the majority of the ground is given a weighting of 5,
the preference is to take weighting 1 roads the whole
way. Further analysis will help gain an
understanding of whether this is simply a matter of
moving between these points, or a tendency dictated
by the current weighting system.
Actual Path
Predicted Direction of Path
65 of 98
6.2 Test 2: West of campus to East of campus
This test is similar to test 1 but tracks the path made between the West and East of campus. However, yet
again there seem to be the same problems as in the last test. The generated path is mapped along the low
weighted roads around campus, as opposed to running through campus. This is somewhat more surprising as
one might expect, if the dependence on roads is so strong, that the path would run along road A (as indicated
on the map) as it runs almost half the distance across to the destination. The tendency is now even clearer,
and is something that should be addressed in the weightings.
With the understanding of a too greater weighting given to the roads instead of the paths inside of campus a
given, it might be worth trying to examine the other weightings within campus. These tests will help give a
better understanding of how a route might run within the campus boundaries.
Predicted Direction of Path
Actual Path
Road A
66 of 98
6.3 Test 3: Inside Campus – Northern region
This test demonstrates the true nature of the application.
The path runs underneath the archway near to the
Geography building, as designed. However, there
appear to be two problems. Firstly, as indicated by the
circle, the path moves through an area where there is a
fenced off steep hill and up a high wall – this clearly
isn’t possible and is something that needs addressing.
Instead the path should move underneath the Sociology
building as indicated. The other slight problem is the
path flow around the stairs near to the Edward Boyle Library, again this is something that should perhaps be
readdressed.
6.4 Test 4: Inside Campus – Southern region
This test is again similar to the test above, testing the weightings inside campus. In this case, some more
specific problems are noticed. The path takes a far longer route than really would be required. This seems to
be because of the definition of the map data, where archways are not actually marked as archways. These
areas are marked on the map below. The suggestion here seems to be the need to either alter the weightings
or the actual map data, depending on what is found.
Actual Path
67 of 98
6.5 Test 5: Inside Campus – St Georges Field
This test provides an interesting viewpoint of the nature of the ground data in relation to the weightings
determined from the OS data. In this case the focus is on St Georges Field. This field has two (real) paths
running across it that appear to be very similar in structure (they’re both paved). However, they appear to
have different descriptions according to the OS data, which would lead to the difference in weightings.
Indeed, on checking the map data, the Path A ‘Theme’ attribute is defined as ‘Road, Tracks and Paths’, while
Path B is denoted as ‘Land’. This difference is perplexing, and perhaps indicates a need for alterations to the
map data.
6.6 Test 6: Outside of campus, into the centre of campus
This test checks what the result would be if one were to move from far outside of campus into the centre in a
west-east direction. The results are favourable, and in this case demonstrate the most likely route to the
destination. However, one final point should be made that was also noticeable on other path maps, this is the
case of routing across roads. There are points on the path where the user is seemingly instructed to walk
along the middle of the road (indicted by arrow A). There are also parts of the path that tell the user to cross
the road a number of times in a short space of time (indicated by arrow B). These are likely to be associated
with the resolution of the cost direction grid; however a fuller investigation into this will be delivered in the
next section.
Path B
Path A
68 of 98
6.7 Chapter Summary
The testing stage, by examining various areas of campus, has helped identify a number of problems with the
current configuration of the weighting scheme. Although the weightings were drawn from what appears to
be simple OS definitions of areas, clearly these do not correspond to the true ground data. In the next section
these problems will be examined in further detail in an attempt to identify the exact problems and address
these. A number of other methods for resetting this configuration will be discussed, as will way by which to
take this work forward.
AB
69 of 98
7 Evaluation
In the last section, testing was carried out to determine the quality of results achieved from the path
construction algorithms contained within the prototype. There were a number of problems identified,
particularly associated with the assignment of weightings to the different areas of map data. In this section
these problems will be looked at in more detail, in an attempt to understand why these problems occurred
and how they may be best tackled to produce better results. Three methods by which alterations can be made
will be presented. Given the original weightings assignments based around the MasterMap data, this
analysis will also provide a good viewpoint from which to judge the applicability of the selected map data to
serve this purpose. In doing so, there will be some discussion offered describing how simple adjustments to
the map data may enable increased functionality. The final section of this chapter will address the over
limitations of the prototype’s general design, with some discussion of its potential adaptation for deployment
on handheld device.
7.1 Weighting problems
In the last section, Tests 1 and 2 helped identify a strong tendency for the paths to be mapped along the roads
running around campus. By simply examining the paths mapped in these tests it is plain to see that the paths
created were not the most efficient routes to take. However, in examining the travel weight map created
from the original assignments (see Section 5.3.1.3) there clear reason is that the paths inside of the campus
are marked with too great a weighting. The map below best demonstrates this problem, where again the
more favourable weights are marked in strong green, the least favourable in red. What this shows it that
while road and small tarmaced or paved outside of campus (marked by arrow A), or through areas of Natural
Land, are given a weighting of 1, those inside of campus, that appear to have the same structure, have been
given a weighting of 5.
This problem is associated with the way the weighting assignments were made. Looking back at that
process, it seemed straight forward enough to base these upon three description attributes. One of the broad
definitions was based around the Theme attribute entry ‘Roads, tracks and Paths’, which was assumed to
include the central areas of campus. On further investigation this appears not to be true. In fact, those areas
marked with arrow B are described in the Theme attribute as ‘Land’ and then in the DescGroup attribute as
‘General Surface’, thus marking these areas with a weighting of 5. This is clearly not how the definition
should be made. One would suspect that the reason for this is that, while the paths maybe in themselves very
similar, they are privately owned by the University, so do not technically constitute a road or path. The
quick solution would be to change the weighting for this group to 1, to ensure the paths do not continue to
run around the outside of campus. However, there could be an issue in this for this blanket approach could
contain too broad a selection. From simple examination of the area it is clear that there are some big
70 of 98
differences between some of the areas captured by the current ‘Land’ – ‘General Surface’ definition. Take,
for example, the differences between B1 and B2. B1 is a grassy field while B2 represents the roads and
paths running through campus. However, using the current combination of attributes they are, by all
accounts, the same. There is obviously a need for the inclusion of further data to help make the distinction.
In order to make this distinction, the geographic data, contained within a database, was re-examined.
Continuing with the current example, a significant difference was noticed between the two datasets. In
another field, the ‘Make’ attribute, B1 was described as ‘Natural’, while B2 was described as ‘Manmade’.
Using this attribute as a way of making this distinction, the weights were reassigned using the same
methodology as described in Section 5. As can be seen below, changes were only made to those attribute
combinations that required alteration, others were left as they were. This new weighting scheme should be
compared to the previous weight assignments as seen in Section 5:
A
A
A
B1
B2
B2A
71 of 98
Theme DescGroup DescTerm Make Weight
Buildings Building Manmade 1000
Buildings Building Archway Manmade 1
Buildings Glasshouse Manmade 1000
Land General Surface Manmade 1
Land General Surface Natural 5
Land General Surface Unknown 5
Land General Surface Multi Surface Multiple 5
Land General Surface Step Manmade 10
Land Landform Slope Manmade 10
Land Natural Environment Trees Natural 20
Land Natural Environment Trees; Scrub Natural 20
Land Unclassified Unclassified 5
Roads Tracks And Paths Path Manmade 1
Roads Tracks And Paths Road Or Track Manmade 1
Roads Tracks And Paths Road Or Track Traffic Calming Manmade 1
Roads Tracks And Paths Roadside Manmade 1
Roads Tracks And Paths Roadside Natural 1
Roads Tracks And Paths Roadside Unknown 1
Structures Structure Manmade 1
Structures Structure Communication Manmade 1
Water Inland Water Natural 1000
The new travel weight map can be viewed in Appendix R. The differences, certainly between the B1 and B2
marked regions are clear to see. So, using these reconstructed weights, the previous tests were re-run, again
using the prototype.
72 of 98
7.1.1 Test 1: North of campus to South of campus
It’s clear to see that the results of this test certainly
appear favourable, but do not quite match what was
hoped. The path runs along the outside of campus as
opposed to running across St Georges Field and
through the central areas. However, this is not
necessarily wholly negative for there are still issues
to be tackled along side the alterations of the
weightings. As shown by the white arrows, these
areas, as discussed in Test 4, would block passage
through these regions and suggest why the path
around the outside was taken. This issue will be
looked at in more detail later.
Another feature to point out from this map is the
effect the alterations have made on the paths in St
Georges Field. In Test 6 it was discussed how the
paths (circled) were defined differently within the
map database. The alterations made here have now
seemingly solved this problem, and you expect the
correct results were the test to be re-run.
73 of 98
7.1.2 Test 2: West of campus to East of campus
The results of this test are certainly favourable, and make a massive improvement on the previous weighting
scheme. Indeed, this route, past the front of the Union is most likely the route one might take to the Rupert
Becket Lecture Theatre. The test shows how the reconstruction of the weights now encourages routing
through the central areas of campus.
Before moving on from the reassignment of weights, there were two other issues raised during testing that
can perhaps be tackled using these methods. The first issue, identified in Test 3, was the avoidance of steps.
The first configuration awarded steps with a weighing of 10, however in hindsight this was perhaps
unnecessary. For, while in theory one would probably like to avoid steps, they’re a necessity for getting
around the majority of the campus. Therefore, it makes sense that they are reassigned to value where they
are not completely avoided. The value to be assigned at this point will be 2. The reason for this is that, on a
small scale, they are more preferable to walking on the grass or down a slope, but a paved route would be
preferred if possible. This obviously only applies to those are walking around campus, later on consideration
will be given to disabled users of the system.
The second point was identified in Test 6, where paths were being constructed down the middle of roads.
This clearly isn’t very practical, and given the opportunity from the current attributes available to make a
definition between road and roadside, the weights should be adjusted accordingly. However, it is important
to make sure to not weigh the roads so highly that they are never crossed. Therefore, it makes sense to keep
the ‘Roadside’ weighting at 1, but increase the ‘Road or Track’ weighting to 2, therefore ensuring a path
along the roadside takes preference.
These two adjustments will now be tested using the same methods as above.
74 of 98
7.1.3 Test 3: Inside Campus – Northern region
As can be seen from the newly created map, the path
now runs down the stairs next to the Library as would be
expected, as opposed to avoiding them. The issue
concerning the path crossing over to a lower level road,
as identified in initial testing, will be handled in the
following stages. However, it appears that this
reassignment is a correct one.
7.1.4 Test 6: Outside of campus, into the centre of campus
The results from the second test are somewhat of a mixed bag. While the path flows along the roadsides as
would’ve been hoped, it takes a rather strange route between. The two areas in question are circled. Circle
A indicates the grounds of a school (the perimeter of which is fenced), while Circle B indicates a Car Park.
These are both areas that you would not perhaps instruct a visitor to the area to travel through. However, the
reason for this is that much of these areas fall into the familiar ‘Land – General Surface’, whose weighting
was reassigned earlier from 5 to 1 to ensure a greater passage through the centre of campus. With no other
descriptor attributes within the data to introduce, this indicates a problem with the data that may not be
solved by further reweighing, but instead suggests a need for individual alterations of the map data. This
issue will be handled in the next section, when other similar issues identified during testing will be discussed.
One final point about the roadsides. It is unfortunate that there is a lack of definition on the map of road
crossings. If this were so, they would obviously be weighted to 1 and ensure an accurate path across the
roads. However, this distinction is not made in this data, and while editing the data could solve this problem,
it would require the creating and readjusting of possible hundreds of polygons thus deeming it not
worthwhile at this stage.
A
B
75 of 98
This section has examined and altered the original weighting scheme according to the results found during
testing. It has also helped identify the failings of the map data to correctly identify certain areas, although it
is possible there are valid reasons for this classification. The next stage will examine the further work that
needs to be carried out to help amend the other problems identified during testing.
7.2 Map Data Problems
While the problems discussed above could be put down to
a lack of clarity from the map data, or perhaps a lack of
consideration for how private paths would be handled,
there are some areas of the map where the data must be
changed manually in order to tie in with the true situation
on the ground. There were two clear occasions in which
this was identified during the testing phase and another
noticed when weightings had been adjusted. The first
concerns the definition of archways within the data, the
second, problems bought about by the lack of recognition
for boundaries in the map data. These will now be handled
in turn.
As demonstrated during the design stages of the prototype,
there is a combination of attribute values that constitute an
archway. However, there are also areas of the map where
you might expect the definition of an archway but this isn’t
given, with the cross over being marked as a building
instead. This means that, although the route is passable, a
path is not constructed this way due to a perceived
obstruction. The map to the side demonstrates the difference, with defined archways pointed by blue arrows
and those not shown with purple arrows. Looking at the differences the issue doesn’t seem as confusing as
first thought. For those ‘undefined’ archways appear, in most cases, to represent parts of the buildings,
walkways between buildings or overhangs. Nevertheless the problem still remains that passage is required
through these areas.
For this problem, and given that it is on a relatively small scale, the solution is fairly straightforward. For
each instance the weight of the individual component will be changed to 1 within the map database. This
will allow fluid access through these areas but continue to represent them as parts of their respective
A
76 of 98
buildings. This is particularly important for the ‘archway’ represented by arrow A, for that component is
part of the Sociology building, and so would require that recognition when people are trying to find it.
Changes to the data in this respect were made all over campus (about 15 alterations were made), however it
is important to note that the true conditions were checked before and changes were made, to ensure
correlation. With these changes made to the data, the raster data was recreated and Test 4 rerun.
7.2.1 Test 4: Inside Campus – Southern region
The alterations again produce a result more in keeping with the reality on the ground. The ‘unblocking’ of
this area from the pathways running above it mean that there is now no sweep around the top of campus to
reach the destination. As you would expect the path moves off the grassy area to the nearest path and
continue on the pathways all the way to the destination. The changes to the map data are noticeable by the
change in colour (indicating weighting) in the image.
The handling of the next issue is slightly more complex as it involves the changing elevation of the campus.
There are areas of the campus, some of which have been indicated in the map to the side, that run below the
‘normal’ walkways and would very unlikely be the kind of paths a tourist would wish to take. However, it is
a tricky issue to ‘remove’ areas of map data from such an application. The problem stems from a lack there
being no fence or wall data within the map data. This is not a problem when there is a clear change in
ground condition, such as seen around and within St Georges Field, however it is a problem when a fence
has been constructed to stop people falling off a large drop.
77 of 98
As explained earlier, although the data in the map to
the side suggest there is edge data, this is not the
case for all the lines indicate are the sides of
polygons. When the data is converted to raster for
processing, these lines are lost.
It appears the only way to solve this problem is
again with the ad-hoc alteration of map data.
However, the question is how to best represent these
changes. As there are no polygons for fences it
appears that the changes must be made to the
existing polygons themselves.
However, while this is fine for the areas where you
do not necessarily want people to pass through, if
this method were to be used in the areas indicated by
a star this would cause big problems for other path
constructions. The answer in this case is to create
the fences to stop passage through these areas, with
the new polygons receiving a weighting of 1000 (the
same as buildings). These changes will be created
on the map data temporarily, in order to create the
weight mask for the path construction algorithm, however they must not be shown in the user interface in
order to prevent confusion. The results of these custom alterations are shown below with annotations.
In this area the service road has been marked with a
weighting of 1000, as it is expected that there is
little tourist interest in this area. A ‘fence’ has been
constructed, again with a weighting of 1000, along
side the steps next to the library, to ensure that a
route is not constructed off the edge of the drop.
Large Drop, Fenced *
Large Drops, Fenced *
Service road to Union
Bridge over Service road
Service Road –crossing now concentrated over the bridge
New fence
Inaccessible Areas
78 of 98
In the lower half of campus, similar changes were made,
according to the nature of each area. Similar fences
were constructed around the drops by the School of
Computing. While the dropped ‘service’ area, which
appears to hold no real use to tourists was marked as
with a weighting of 1000.
The final problem, identified after changes to some of
the weightings, requires a solution very similar to that
just been discussed. It was shown earlier that the
alteration of the ‘Land – General Surface’ attribute
combination, that covers most the pathway within the
campus, created areas where passage was encouraged
but in the real world not preferable. These are the areas
which are either not accessible or less accessible than
they current assigned to be. Again, the only real way of
sorting this problem out is to approach it on an ad-hoc
basis. The approach taken was simple – to study the
current map data and reweigh individual polygons whose current assigned weight did not make sense. The
following adjustments were made:
Car Parks – where there was suitable or natural ways around them – were reweighed from 1 to 5 (in
keeping with similar ‘Land’ classifications). Incidences: 6, see Appendix S
‘Closing off’ of large areas of private property, to prevent crossing – reweighed from various to
1000. Incidences: 7; Primary School off campus, Church off campus, Fenced off water reservoir off
campus, car park of flats opposite campus; current building site of Leeds Metropolitan University,
Bowling Greens on Woodhouse Moor, Car parks for buildings down from Leeds Art College to the
Student Medical Practice.
Inner Ring Road (motorway) value set from current road weight of 2 to 1000.
Changing weight for Roundabout opposite the Union from 1 to 10 (in tying with similar surrounding
objects).
Adjusting of land surrounding some buildings from 1 (highly preferable) to 5 (less preferable but
passable), dependent on suitability. Incidences: 3; Around the School of Geography (not including
steps into building), Around accommodation on Lyddon Terrace, behind the Chemical Engineering
department.
So ends the alterations to the map data. The finished article can be found in Appendix T.
New fences
Dropped areas marked out of bounds
79 of 98
7.3 Resolution Checks
The next section will investigation a potential issue hinted at following the results of test 6 in the last section
– the effect of data resolution on the resulting path. The testing will reuse the location and destination from
Test 6, and identify whether there are major differences in the path construction. The resolutions to be tested
are the standard 5m resolution (which as explained earlier offered the most appropriate processing speed),
1m resolution and 15m resolution. The usual method was used, and the results are as below:
1m Resolution
5m Resolution
15m Resolution
The results are interesting in a number of respects. It should be remembered that while constructing the path
the distance and direction raster datasets (that ultimately route the path) are created on a grid cell by grid cell
basis. At each cell, the data within is that area is generalised to correspond with the value with the most
80 of 98
coverage (e.g. is a cell is made up on 60% Weight 1000 and 40% Weight 1, the resulting grid cell would
have a weight of 1000). The size of these cells depends on the resolution entered into the routing algorithms.
This is the reason why the 15m Resolution result looks so strange. The size of the circled buildings is not
large enough to form a block this path, after all the shortest route is still the aim of the algorithm.
Perhaps more interesting is the difference between the results of the 1m and 5m resolution. While the 5m
result is perfectly acceptable, the 1m result seems to make more sense and would probably be the exact route
one would take between location and destination. The reason for the difference is not apparently clear, and
the overall cost difference is probably very small; nevertheless, the 1m results are better. So why not use the
1m resolution to generate the path data? Because the size of the data meant that it took 15 minutes to
calculate this route using a fairly high spec PC. However, what about looking at other resolutions and
examining those results? The rasters were recreated with resolutions of 3 and 4 metres. As you can see
below the calculated path runs along the same route as the 1m resolution calculation, suggesting the minor
differences caused by the larger cell size, in this case at least, have been removed. The two resolutions were
also tested for the length of time they took to compute, it was found that the 3m resolution took too long to
calculate, whereas the 4m raster produced a result in under a minute, close to the time received from the 5m
results. The 4m resolution result is shown below, and a recommendation is that this resolution is used to
make these calculations in future work.
All of the problems identified during the testing phase have now been addressed. As a result, an improved
weighting mask has been produced at a resolution that appears to offer more accuracy, with only a slight
increase on processing requirements, than the originally selected 5m resolution. The next section will
examine the potential for extension of the current application. After these aspects have been addressed
further work in a wider context will be discussed.
7.4 Extensions on Current Design
There are a number of ways in which the developed prototype might be further developed to offer greater
functionality. However, rather than discussing the actual functionality of the application, discussion will
81 of 98
centre on how changes might be made to the existing map data to enable these extensions. For it is the map
data that may ultimately be extracted from this application and placed within another environment, such as
an application developed for a handheld device.
7.4.1 Adding Descriptors
The title to this section is intended to be rather broad, as it indicates the potential for the addition of further
descriptor fields within the current geographic database. As explained during the Data Selection and
Prototype Development stages, the data used in this application included only one alteration from the
received OS MasterMap data. This was the addition of a travel weighting value. As discussed above,
however, the generality of the data within this dataset caused some problems in terms of creating an
automated path that represented the route that would be taken in reality. It is felt that the addition of further
descriptor fields might have alleviated the need for ad-hoc alterations to the map data. The reason for this,
and as discussed above, was partly the design decisions taken by OS to assign areas such as the inside of
campus to represent Land, as opposed to Paths or Tracks. It is felt that this problem could have been avoided
with the addition of an extra descriptor field. An extra field could have offered an indication of whether the
land had restricted or open access, as a better way of indicating the access to a ‘Private’ area. Another
descriptor might indicate other differences between areas falling into the ‘Land – General Surface –
Manmade’ category, how about a field indicating its general use. This might include terms, and these are
just ones significant to the campus area, such as ‘Car Park’, ‘Restricted access pathway’ or ‘Private
Grounds’, each of which would offer the small extra detail needed to distinguish within a currently very
broad description.
Another useful addition would be the recognition of where fences are used to prevent people falling from one
height down to another. In many cases the need for fence data is not really a requirement, however, in some
cases they are necessity, and so should be marked within the data. During this development the few cases of
required fencing were created to prevent routes being constructed along that way. However, the lack of
elevation data within the dataset could ultimately cause problems in other applications. It’s true that if
elevation is a big issue then the contour-specific data should be extracted; however, the MasterMap data
should perhaps have some reference to elevation as seen in other OS topology datasets.
The suggestions above are those which could be tackled by OS at the source; however there are also a couple
of additions that can be made to the data to increase functionality in this case. For example, in the prototype
the identification of a building was done by comparing the extracted the selected polygon’s ‘Toid’ code from
the data and comparing against which building it corresponded to. This process of comparison could be
removed by adding a field to the database that contains the name of the building or area. Obviously, in a
greater extension of this prototype this data would be contained within an ontology, as discussed earlier,
however such an addition would provide just a broad indication of the nature of each building or area. Other
82 of 98
fields could indicate whether the polygon was within the campus boundaries or not associated with the
University, and if inside, which region of campus it falls into.
7.4.2 Changing the Map Data
The majority of this section of the report has addressed how the map data may be manipulated to render
better route mapping results. One aspect that has not been addressed so far is the specification of the current
polygon arrangement to meet the requirements of the user. It was described in the Application Planning
section how users would be able to move from a particular area of campus to a destination that has some
relevance. This might be from say, the Parkinson Steps to the School of Computing. This is all very well
until specifying where the School of Computing actually is. The maps below demonstrate (the maps are
displayed by feature code groupings, and not the weight scheme):
The problem is that the School of Computing, as with many other departments across the University, share
their buildings (in this case represented as single polygons) with other departments and services. For
instance, polygon A contains both part of the School of Computing and ISS, while department B contains
both Computing and Physics, as well some other services on Level 10. The problem is that the top down
view offers no exploration into the differences between floors in the building. This would be something very
important for the tourist to understand if they were trying to find a department within a shared building. The
best thing to do in this situation is to make the divisions where possible, explain which floor the department
is upon, and/or otherwise direct the user towards the main department reception for further guidance. The
case shown above is quite useful, as broad divisions can be made from a top-down viewpoint.
Are all of these areas the School of Computing, or do they represent something else as well?
83 of 98
These boundaries are obviously quite broad, but do represent where the majority of the departments are
situated within these buildings. Using this simple division, further information can attributed to each
polygon, such as the name data suggested earlier. In addition, should it be necessary, data can be attached to
these newly formed polygons that indicates which other departments, and which of their facilities, can be
found within this area. More research would obviously have to be carried out to gain a fuller understanding
of how best to make these divisions across campus.
Another aspect to topic is the possibility for the creation of new data objects within the map database. This
simple process would involve simply adding a record to the database containing the location coordinates,
description data and travel weighting of the object to be added. There are a number of objects that might be
of interest:
Polygon to represent the ‘Red Route’ running through the EC Stoner Building and to Roger Stevens
Lecture Theatre. Offers a useful tour around the inside of these buildings, along with access to cafes
along the way. If mobile phone location data were used tracking would continue while the user is on
this path.
Entrances to buildings added to the map, and options to locate to these.
Location of Tourist Information tents (only applicable on University wide open days).
Descriptions for services off campus (such as cafes, bars and food outlets).
Other aspects can be built into the design of the application, including location of nearest toilet or café;
however, those listed above provide the extra visible aspects that might be of use to a tourist.
Another, fairly small extension of the application could be a function to allow the user to manually pick their
destination from a list. This would be easy to implement, and could perhaps be a simple extraction of
instances from the ontology data (as discussed in Application Planning). This simple introduction would
enable the user more freedom in the nature of their tour. In the same way, a cursor and select option should
also be available, similar to the design seen in the prototype, to allow the user to visit a part of campus that
ISS
School of Computing
School of Physics
84 of 98
they may want to visit (e.g. grassy areas to eat lunch etc.). The same functionality should also allow
information extraction on a selected object.
The final suggestion, in regards to the extension of the product’s functionality, is to include an option for a
disabled user’s tour of the campus. This would involve the reweighing of some aspects of campus, such as
the stairs, in order to direct these users along accessible routes. There would also be some attention given to
the reweighing of other areas, such as grassland, to ensure routes were not constructed across these areas. In
this case, the application would include two travel weight maps, the one discussed above and one for
disabled users. Data extensions to include information about lift access between levels would also be a
useful addition here also.
This section has helped identify the range of ways in which the map data may be edited to provide new
functionality. It is important that any functions added to the application are supported by the geographic
data, in order to make things clearer for the user and to minimise data duplication. This section has also
helped outline the problems found with the standard OS MasterMap data, and how this could be improved to
better meet the needs of this application. The final section of this evaluation of the prototype will focus on
the limitations of the approach used. As described earlier, the developed prototype is a proof of concept and
is not meant to represent what was described during the Application Planning phase. The next section will
therefore discuss the potential for extension of the current prototype design to meet with the designs laid out
earlier.
7.5 Limitations of Approach
The development of the prototype has helped supplement many of the ideas explored during this project.
However, how easily could the prototype be extended to allow its use on a portable handheld device? In its
current state, the conversion would not be possible. The prototype, as has been explained, draws on the path
mapping tools available in Arc, specifically ArcGrid. The Arc package is too extensive for the current batch
of handheld device, and so this kind of processing would not be available. Further, even if ArcEngine, and
its fully portable development environment (as discussed in Section 5.1.2), were available, it too would be
too expansive for a PDA or mobile phone. This means that, using the current methods, there is no way of
incorporating the Arc path generation tools onto handheld device.
However, all is not lost. As explained earlier, MapObjects is transferable to mobile phone and links well
with J2ME. This at least provides some of the mapping services required to produce a meaningful output to
the user. In fact, if configured carefully, using MapObjects an interface that matches if not extends that seen
in the prototype may be produced. Further, because location requests, be it from GPS or Mobile Phone
location services, can be transferred using XML, the identification of location should also be possible
85 of 98
through the handheld device. The remaining problem lies with how to run a path generation algorithm.
Probably the best way to do this would be to incorporate imported Java shortest path algorithms, such as
Floyd’s or Dijkstra's Algorithm.
7.6 Chapter Summary
This chapter has examined the development of the prototype, as well as some review of the potential for
extension on the current design. This stage has helped gain a better understanding of the requirements of the
data needed to effectively map a route through the campus, with the given restrictions. This investigation
also helped highlight the ways in which the data used to generate the land ‘weights’, OS MasterMap data,
can, and in some cases must, be altered to produce better results. It was shown that that combination of
adding new attributes to generate the weighting score and manual adjustments made to the data helped
produce far superior results than to what was shown during testing.
There was also time to accept some of the limitations of the prototyping approach in regards to the larger
scale designs offered earlier on in the report. However, it was shown that with some amendments, the
current prototype application may be fairly easily adapted for use on a handheld device.
86 of 98
8 Conclusions
The final section of the report will address the key points raised during the course of the project. During this
chapter there will be discussion of the key successes from the project, a look at whether the original aims and
objectives have been met, and a documentation of what constraints were faced during the project. Following
this some discussion will be offered concerning the future directions in which this project could take.
8.1 Summary and Discussion
This project has been a presented a detailed examination of the key concepts and methodological
considerations that must be taken during the development of a location-aware tourist system. At each stage
of the report, strong emphasis has been placed on ensuring that a consideration has been offered for each
potential method or choice. This approach has helped ensure the design of a well thought out system, with
some aspects being implemented into a prototype application.
The report began by detailing the broad research that was carried out at the beginning of the project. It felt
necessary that, in order to help develop well-considered designs, the research should examine a wide range
of methods and applications existing within the general field of location-aware technologies. The research
firstly considered the range of location tracking technologies currently available, how each of these operates
and with what accuracy. This study helped determine, in outline, which methods would be appropriate for
the tracking of a user in the University environment. Although only GPS tracking has been available for
testing in this project, this section helped understand the potential effectiveness of a range of other
technologies. It was noted that two methods not released yet, Galileo and, in particular, WiMAX, could be
very effective in system such as this. It was also demonstrated, later in this section, how the mobile phone
location methods have been employed in other situations. Of particular interest here was the development of
the Enhanced-911 (E-911) system in the US, a cross-organisation effort to employ quite advanced mobile
phone tracking techniques to identify where emergency callers are situated. It was also noted that currently
there are few very advanced uses of mobile phone location data in the UK. The research also outlined the
work carried out in the development of other location-aware tourist information systems. Many of these
were found to be quite advanced, with some researchers suggesting that integration with semantic web
technologies is very much achievable in the coming years. Finally, the research examined further the
potential for links between location data and web developments, with a final section addressing the moral
and ethical issues these technologies introduce.
The background research section provided an excellent platform from which to move into the design phase
of the project. Although some of the ideas discussed during this section were not eventually implemented
into the prototype, the development options were carefully examined with view to future developments. This
section introduced two key methodological considerations: how to handle the tourist guidance, and how to
87 of 98
contain and provide information to the tourist, all in regards to the use of location data. These two areas
were examined in detail, and a design for an overall system constructed. It was also described how a range
of technologies are now available to enable software to be developed for handheld devices. However, along
with the discussed benefits was a consideration for the design issues that developments for handheld devices
introduce.
The Data Selection chapter provided an analysis on two the key aspects associated with the development of
location-aware services. Firstly, it was described how GPS had been tested to limited success around the
University campus. It was also demonstrated how some UK-based sources suggested that the currently
available cellular network location methods might not produce the accuracy required for a development of
this type. It was concluded here that, despite some results being acquired, further testing of both methods
would have to be conducted in order to ensure the best method were selected. The second half of this
chapter examined the range of geographic data sources available to support a development of this nature. It
was decided that the OS MasterMap data would be implemented into the prototype to test it’s effectiveness
in providing this information.
The fourth key section of the report discussed the process conducted in developing a prototype application of
the designs discussed during this project. Although only certain parts of the original design were
implemented (the constraints on this development will be discussed later), the process helped examine the
range of the considerations that were required throughout the course of development. Such factors included
the method by which to guide users, how the routes may be constructed and how various tools can be utilised
to support the development. The design process also described how the range of tools capable of delivering
such an application was quite limited, and why the prototype would be developed as it was. The resulting
application provided a route-based location-aware information. The application was developed in Java, but
incorporated links with the Arc MapObjects JavaBean library, as well as integrating with external processes
through the use of two further programming languages (AML and Batch scripting). Although the output did
not extend to include detailed location-based tourist information, the methods required to integrate the
various toolkits meant that the development of the application was quite a complex process.
The testing and evaluation sections helped explore the effectiveness of the prototype in providing an accurate
location-aware route guidance service. While, initially, testing identified that the routes laid out by the
application were often erroneous or unnecessarily long, these issues were addressed by the evaluation
section, which recognised the need for more in-depth data processing prior to the launch of the application. It
was also explored how other alterations to the map data may introduce simple, yet highly beneficial further
functionality into the system. Finally, it was discussed that while the system in its present form may not be
implemented as described in the design phase, the nature of the development ensured that small alterations
would the application to be deployed on handheld device.
88 of 98
8.2 Review of Aims and Objectives
By way of ensuring that all of the targets have been met during this report, the original aims and objectives
will be revisited to outline what has been done to complete these. The original aim of the project was:
“To examine approaches for the design and development of a location-aware
geographical information service, based on mobile device, and to illustrate some of
these concepts in a prototype”
A wide range of concepts and design issues have been discussed, particularly during Sections 3 and 4. These
examined in detail the approaches taken towards the development of a location-aware geographical
information system. Some concepts from this analysis, particularly the route guidance aspects, were then
implemented into a prototype. There was also discussion centred on the considerations of developing on a
handheld device, as well as suggestions on how the current prototype might be extended for use in this way.
The aim was to be completed through the meeting of three Objectives. These were as follows:
Evaluation of wireless location methods to determine the potential benefits and accuracies of
adopting a particular technology for use within the system
Demonstrate how Geographical data can facilitate the provision of location-aware information
Develop a prototype location-based visitor information service, using simulated or real location data
The first Objective was tackled in a number of ways. While Section 2, the Background Research, provided a
general idea of the range of technologies available for the use within this system, there was further analysis
of the two key available technologies, Mobile Phone Location data and GPS, in Sections 3 and 4. In Section
3 there were discussions about the implementation of both, and how a handheld device would handle the
request and acceptance of the data. Section 4 explored the accuracies of these two methods in detail, through
a combination of research and practical experimentation.
The second Objective was explored in detail during the preliminary investigations in Section 4, with greater
exploration of specifically MasterMap data during the Testing and Evaluation stages. During these stages it
was identified that a number of manual alterations to the data were required in order to provide more
meaningful results. It was also demonstrated, through the methods used to develop the prototype, how
geographic data may be handled in order to extract specific polygon information.
The final Objective, again was simply met through the development of a prototype, based on simulated data.
This prototype provided routing information, based on current location and desired destination, as a location-
based service. It was also shown how geographic data could be extracted from the MasterMap database in
89 of 98
order to obtain another location-based service. The constraints section later will explain the reasons why
extension to utilising real location data was not possible.
Finally, there were two further Minimum Requirements that were set to ensure the completion of certain
specific tasks. These were as shown below:
Survey existing location-aware technologies and how they have been implemented in both
commercial and academic environment. Determine suitable environment for development of
prototype.
Implement prototype capable of using real and/or simulated mobile phone location data to provide a
user with at least one location-aware information service.
Both of these requirements have been met, the second, obviously as described above, during the
development of the prototype. The first requirement was carried out through the initial Background
Research, and later during the design specification in Section 3.
8.3 Future Work
As discussed at the start of this report, the structure laid out throughout may appear a little confusing. The
prototype developed, and detailed during section 6, was intended to be a proof of concept of the general
subject researched and written about here, the development of a tourist application for the University of
Leeds campus. As a result, included also was an Application Planning section that described the design for a
full implementation of the system. The resulting prototype was an abstraction of this design. In some
respects, therefore, this chapter may have seen an extension on what was eventually developed. Because,
however, the Application Planning stage was more of a broad description of the general design, and the
prototype obviously more technical, the future work can be looked at in terms of way in which the product
may be further developed, and ways in which the overall process may be extended. The nature of these
developments mean that the extensions discussed here will be done so in respect to both the product and
process.
Firstly, an extension upon the general design mentioned during the Application Planning phase. During this
section, it was suggested that two versions of the system be deployed, one containing the user’s preferences,
one a generic, yet flexible system allowing the user to explore at their own leisure. This extension involves
the extension of this first, customised design, to include customisable scheduling of their tour design.
Scheduling would be customisable in terms of speed and detail, and research would be conducted to
determine the best way to achieve this for each feature of campus. The timings for each option, identified
during this research, would then be used to construct an accurate schedule. Obviously more user prompts
would be required to make sure the user stayed on schedule – although options would be available to drop or
90 of 98
add in new aspects of the tour. The reason for this addition would be to enable other functionality. This
could include the booking in to lectures, talks and perhaps face-to-face tours of certain areas of campus (such
as libraries or the Union). The tools for completing this schedule would be available through the website
described earlier. Bookings, and similar schedule-related services, would be handled through the transfer of
XML requests to a central web server on campus.
Another extension of this application could be to offer routes through text descriptions rather than through
the current map interface method. This would be done using the network method as described in Section 6.
This would mean that the whole campus path network would be constructed, restricting users to stay on these
routes. However, it would present an interface that would be easier to deploy. The necessity of high-end
Java-enabled mobile phones or PDAs would not be removed, with the only requirement being the ability to
display text instructions. Such a method would require accurate GPS readings in order to locate the user
exactly, for a position-marked map would be unavailable for consultation when accuracy was low. Testing
would have to be carried out to ensure that the speed and accuracy of the instructions were quick enough to
provide a route that was clear, even when a number of instructions were required across a short space of
time. However, this design would represent system that could be implemented more easily, should the
University be looking to do so.
It was mentioned during the Background Research work that has been carried out to develop tourist
applications for the blind (Klante et. al. 2004). This, again, is another potential area from which this
application could be developed. Such an application would involve the implementation of the network
method, as mentioned above, and the provision of instructions and information through an audio output. The
incorporation of the network method would enable the audio output to be provided in a clear and structured
format that would be beneficial to blind tourists.
Moving away from the text instructions, and back towards the map based approach, there is certainly the
opportunity to add in a wider range of detail, possible extending to multimedia. Including in this bracket
might be the addition of student comments about each area of campus, or links to web pages associated with
buildings (e.g. School pages), providing the device has the display capabilities. In addition, a simple
extension would be to include photographs of featured buildings, within the description pages of each, or
also added as a layer on top of the map data (with option to remove the photos to allow navigation). Such an
addition could offer users that extra information they need in order to properly gain an understanding of their
location. The use of satellite data as a display layer, as seen in Google Earth and Microsoft Visual Earth,
could be another option to achieve this, depending on licensing prices. Extending the multimedia aspects
even further, introductory videos by Recruitment staff or from the Head of the School the user is visiting,
would also be a nice touch. Clearly, such extensions would be more draining on processing and memory
capabilities, and therefore might be more suited to a PDA-based application.
91 of 98
Another extension, that was touched upon during the Application Planning stage but not really expanded, is
the possibility of a ‘Where’s My Nearest?’ function. Such a feature would allow the user to quickly generate
a path to their nearest café, food outlet or toilet. This would be best implemented by the recording of points
for the position of each of these items, then running a function to calculate the nearest from the current
location.
During the Prototype Evaluation section above it was discussed how the multi-level nature of the University
is not well represented by the current use of top-down data. While it is possible to direct the user to an
entrance of the building at any level, any information concerning their position within the building and in
regards to the rest of the department, can only be provided in text format. Therefore, a major extension of
the current design would be to open up the interior of the campus buildings to the tour, providing floor plan
and information guidance within these areas. The areas within these buildings offered for access could be
restricted to specific routes, such as to lecture theatres or meeting rooms used on the tour. The work,
nevertheless, would involve a lot of research and amendments to the current map data, but would produce an
impressive output. One further consideration, in the case of this extension, would be the mapping of
multiple levels. This has not been a necessity of the current design given that the key walkways around
campus continue regardless of elevation (i.e. there are no key over or underground walkways). However, the
mapping of just one level, that being the level from walkway to building would be restricting and confusing.
Therefore, in theory, once the user enters a building there must be a flexibility to display the appropriate
floor plans for that level alone, along with information detailing the user’s position and level within the
building. If the user is heading to a room two floors up then they should be guided towards and up the stairs,
the provided further graphical information once they reach the next floor.
This is certainly a tricky task in terms of development alone, but also might be problematic in terms of
locating the user. GPS can not function indoors, and current mobile phone location technologies, although
some can provide elevation data, do not have the accuracy to provide information in such acute
circumstances. Therefore, what technology is there to turn to? The installation of Infrared sensors to
provide a location within buildings could provide the answer, and in combination with a client-server
configuration path construction could be centrally controlled. However the set-up and integration costs
could well outweigh the benefits of this functionality. With the introduction of WiMAX in the next few
years, and its ability to be used on a wide scale, inside and out, there may be one way to integrate accurate
multi-level guidance. However, this depends on the development of location acquisition methods that are
capable to reaching the required accuracy needed here. Therefore, while the idea of an integrated indoor and
outdoor guidance system is good in principle, there are a number of factors holding back development. The
next few years, with the development of WiMAX and its likely competitors, is likely to see the rise of wide
scale boundary-breaking location technologies and with it the potential for low cost developments of this
nature.
92 of 98
The implementation of a client-server configuration was discussed during the last extension suggestion. It
was seen during the Background Research that many of the existing location-aware tourist systems had
implemented client-server based approaches to introduce a number of extra features. Such systems would
involve the central handling of location-based services, including provision of information and route
construction. The inclusion of a server would reduce the load placed upon the device, which may well have
comparatively low processing power. The central location of the server would also mean less data need be
stored on the device, whose main activity would be organising the user interface. In the same way, central
control of the tourist information means that any changes to the campus layout (such as areas blocked by
building work) or to tourist information (updating department information for example) requires only one
change, as opposed to having to commit the changes across numerous devices. Additional features might
include tracking where people move around campus and identification of the places people take most interest
in, so provide management information about how the system is being used. Communication between
device and server could be conducted in a number of ways including GPRS or W-LAN (although coverage
maybe unreliable on some parts of campus). Indeed, it is certainly conceivable that in a few years time
WiMAX could be used to provide the location and data transfer capabilities that such a system requires.
This section has helped identify some of the specific and broad ways in which the planned application might
be developed in the future. Indeed, while some would be simple additions to functionality, some require
technology that isn’t currently widely available. Clearly there is a lot of scope for this project, and certainly
need not be restricted to this example. The use of a location-aware services has a wide range of applications,
as, it is hoped, has been made plain during this report.
8.4 Constraints
Although the project has presented an interested investigation into the process of developing a location-based
service, there have been a number of constraints under which the project has been placed, that have meant it
might not have reached its full potential.
Clearly, the most obvious constraint was the lack of mobile phone location data. At the start of the project, it
was expected that Orange would be provided access to their Location API from which an application would
be developed. However, this agreement was not met, leaving no available location technologies from which
to base the application on (no GPS receivers that would connect to a laptop could be acquired either). As a
result of this, this aspect of the prototype had to be simulated, and a point-and-click interface was created to
achieve this. Clearly, the necessity for this meant a lack of consideration for the effect of accuracy on the
results produced from the prototype. While the GPS accuracy investigation helped provide an idea of impact
across campus, these only covered 149 points and so could not have represented the effect of this factor
93 of 98
across the whole of campus. The provision of some kind of live link with location data would have enabled
the presentation of more meaningful results.
The second aspect to be discussed at this point is associated with the development of the prototype. The
prototype offered methods for how some of the key functionality associated with the design might be
tackled. However, the process of development was far more difficult than it might appear. The author had
some knowledge of Java, and of some functions within ArcGrid – but had never used the path creation
functions, not linked Java with any external applications prior to this development. The process of learning
how to write AML, write batch files, and implement their execution through Java took a great deal of time.
This process was also hindered by a lack of documentation for the MapObjects package. While an API was
provided, there was no documentation on how to implement these tools into the application. As a result,
much of the program was developed through a mixture of luck and judgement. There was some integration
of tourist information, however, by that point there was little time to implement more than the routing
algorithms into the package. In addition, features such as colouring the polygons of the map display turned
out to be impossible without further documentation. There were books available for purchase through the
Internet to help with development in MapObjects, but by the time these were found they would have arrived
too late to help in this case. MapObjects may have taken a long time to learn, but there were little other
options available. In spite of this, the final output presented a good deal of functionality, something that
might have been missing without the use of this library, and hopefully the coding can help others developing
in MapObjects in the future.
94 of 98
9 References
(3 2006) 3. 2006. Planet 3: Service Detail: Out & About. Accessed 2006. <htt p://www.three.co.uk/planetthree/detail.omp?cid=1139512467608>
(3G.com 2006) 3G.com. 2006. Vodafone LIVE MapWay. Accessed 2006. <http://www.3g.co.uk/PR/July2003/5670.htm>
(ABC 2006) ABC News. 2006. UK city to pilot high-speed WiMax wireless broadband. Accessed 2006. <http://www.abc.net.au/news/newsitems/200608/s1718851.htm>
(AntennaAudio.com 2006) AntennaAudio.com. 2006. Homepage. Accessed 2006. <http://www.antennaaudio.com>
(BeyondGuide.com 2006) BeyondGuide.com. 2006. Homepage Accessed 2006. <http://www.beyondguide.com>
(Bahl & Padmanabhan 2000) Bahl P. and Padmanabhan V. 2000. RADAR: An In-Building RF-Based User Location and Tracking System. Proceedings of IEEE Infocom 2000. Los Alamitos, California. pp. 775-784. IEEE CS Press.
(BBC 2003) Scullion A. – BBC News. 2003. Smart cards track commuters. Accessed 2006. <http://news.bbc.co.uk/1/hi/technology/3121652.stm>
(BBC 2005) Amos J. – BBC News. 2005. Q&A: Europe's Galileo project. 28 December 2005. Accessed 2006. <http://news.bbc.co.uk/1/hi/sci/tech/4555276.stm>
(Bell et al 2005) Bell M., Chalmers M., Brown B., MacColl I., Hall M. & Rudman P. 2005. Sharing photos and recommendations in the city streets, 1st International Workshop on Exploiting Context Histories in Smart Environments. Munich, Germany. Accessed 2006. <http://www.ipsi.fraunhofer.de/ ambiente/echise2005/ papers/echise2005-s19SharingPhotosAndRecommendationsBell+etal.pdf#search=%22Sharing%20photos%20and%20 recommendations%20in%20the%22>
(BlackBerry 2006) BlackBerry. 2006. Developer Resources. Accessed 2006. <http://www.blackberry.com/developers/resources/index.shtml>
(Blaupunkt 2006) Blaupunkt. 2006. TravelPilot E System. Accessed 2006. <http://www.blaupunkt.com/uk/nav_sys_81.asp>
(BotFighters 2006) BotFighters. 2006) Accessed 2006. <www.komialt.dk/Downloads/pervasive_gaming/botfighters.ppt>
(Burrell et al 2002) Burrell J., Gay G., Kubo K. & Farina N. 2002. Context-Aware Computing: A Test Case. Conference on Ubiquitous Computing. Gothenburg, Sweden. Accessed 2006. www.hci.cornell.edu/pubs/Context Aware_Burrell.pdf
(Choo 2006) Choo A. 2006. TicTap. Accessed 2006. <http://www.programmableweb.com/url/148>
(Cisco 2004) Cisco. 2004. A Study in Mobile Messaging: The Evolution of Messaging in Mobile Networks, and How to Efficiently and Effectively Manage the Growing Messaging Traffic. Accessed 2006. <http://www.cisco.com/en/US/netsol/ns341/ns396/ns177/networking_solutions_white_paper09186a008020e2a8.shtml>
95 of 98
(CPS 2006) Cambridge Positioning Systems. 2006. Accessed 2006. <http://www.cambridgenetwork.co.uk/pooled/profiles/BF_COMP/view.asp?Q=BF_COMP_1221&page=BF_NEWSART>
(Dornan 2000) Dornan A. 2000. GSM and TDMA Cellular Networks. IT Architect. Accessed 2006. <http://www.itarchitect.com/article/NMG20000517S0169>
(Djuknic & Richton 2001) Djuknic G.M. and Richton R.E. 2001. Geolocation and assisted GPS. IEEE Computer, pp. 123-125, February 2001.
(EC 2003) European Commission. 2003. The Galileo Project. Accessed 2006. <http://ec.europa.eu/dgs/energy_transport/galileo/doc/galilei_brochure.pdf>
(Esato 2006) Esato. 2006. Quick test of Samsung SPH-M8000 WiMAX phone. Accessed 2006. <http://www.esato.com/news/cebit2006.php?sd=41>
(FCC 2006) Federal Communications Commission. 2006. Enhanced 911 - Wireless Services. Accessed 2006. <http://www.fcc.gov/911/ enhanced>
(Frasco 2006) Frasco B. 2006. Enhanced Observed Time Difference (E-OTD). Accessed 2006. <http://www.fcc.gov/911/enhanced/releases/ae rial.pdf>
(GetMeThere 2006) GetMeThere. 2006. MobileLost. Accessed 2006. <http://www.getmethere.co.uk/cgibin/gmt_prod.dll/gmt/jump.jsp?BV_UseBVCookie=Yes&id=MobileLost>
(Goldacre 2006) Goldacre B. – The Guardian. 2006. How I stalked my girlfriend. Accessed 2006. <http://www.guardian.co.uk/g2/story/0,,1699080,00.html>
(Gonzalez-Castano & Garcia-Reinoso 2002) Gonzalez-Castaño F.J. and Garcia-Reinoso J.J. 2002. Bluetooth Location Networks. IEEE Globecom International Conference. Vol.1, pp. 233-237, 17-21 November 2002. Taipei, Taiwan.
(Gorra 2006) Gorra A. 2006. Tracking me, tracking you – an observational study exploring mobile phone location data and privacy. Leeds Metropolitan University. Accessed 2006. <http://www.leedsmet.ac.uk/inn/im/RIP2004-10.pdf>
(GSM 2003) GSMWorld. 2003. Location Based Services. Accessed 2006. <http://www.gsmworld.com/documents/lbs/se23.pdf>
(Hato & Asakura 2001) Hato E. & Asakura Y. 2001. Utilization of travel locus chart using mobile communication systems for GIS-T. Asia GIS 2001, 20-22 June. Tokyo.
(Hightower & Borriello 2001) Hightower J. & Borriello G. 2001. Location Systems for UbiquitousComputing. Computer, 34(8):57--66, August 2001. Accessed 2006. <http://www.intel-research.net/Publications /Seattle/062120021154_45.pdf>
(inCode 2005) inCode. 2005. White Paper: The next step for Location Based Services. Accessed 2006. <http://www.incodewireless.com /media/whitepapers/2005/WP_TheNextStepForLBS-(Feb.pdf>
(Klante et al 2004) Klante P., Krosche J. & Boll S. 2004. AccesSights - A Multimodal Location-AwareMobile Tourist Information System. 9th International Conference on Computers Helping People with Special Needs. Paris, France.
96 of 98
(Marzolf 2005) Marzolf S. 2005. Wireless-911 Accuracy Testing. 911 Conference Accessed 2006. <www.911conference.org/programs/apco%20acc uracy%20testing.ppt>
(Mateos & Fisher 2005) Mateos P. & Fisher P.F. 2005. Accuracy of current Mobile Phone Location:Limitations on the New Cellular Geography. 13th Annual Conference of GIS Research UK (GISRUK). Glasgow. 6-8 April. p. 136
(Mock 2002) Mock D. 2002. Guide to Wireless Location Technology. Accessed 2006. <http://www.unstrung.com/document.asp?doc_id=150 60&print=true>
(NY Times 2003) Carrier J. – NY Times. 2003. Among the Ivy, a Campus Tour Guide That Beeps. The New York Times. 14th August 2003.
(O2 2006) O2. 2006. Trafficline 1200™. Accessed 2006. <http://www.o2.co.uk/ services/alertsinformation/trafficline12000153>
(O’Hare & O’Grady 2003) O'Hare, G & O'Grady, M .J. 2003. Gulliver's Genie: A Multi-Agent System for Ubiquitous and Intelligent Content Delivery, Computer Communications. Vol. 26, Issue 11, pp. 1177-1187. Elsevier Press.
(O’Neill 2006) O’Neill B. 2006. BBC News Map. Accessed 2006. <http://www.programmableweb.com/url/273>
(Openwave 2002) Openwave. 2006. Overview of Location Technologies. Accessed 2006. <http://developer.openwave.com/omdtdocs/location_studio_sdk/pdf/Intro_to_Location_Technologies.pdf>
(Orange 2006a) Orange. 2006. Find Nearest Keywords. Accessed 2006. <http://www1.orange.co.uk/multimedia/place_keywords.html>
(Orange 2006b) Orange. 2006. Case Studies: Location Specific Technology - Location API. Accessed 2006. <http://www.business.orange.co.uk/servlet/Satellite?pagename=Business&c=OUKPage&cid=1144404016286>
(Orange 2006c) Orange. 2006. Orange Location API. Accessed 2006. <http://www.orangepartner.com/site/enuk/develop/v_devcentre/network_interfaces/api/l_location_api_sdk.jsp>
(PocketGear 2006) PocketGear.com. 2006. http://www.pocketgear.com/software _detail.asp?id=16201. Accessed 2006.
(Proietti 2002) Proietti M. 2002. Comparison of Location Technologies for Phase II Wireless E-911. Accessed 2006. <http://www.technocom-wireless.com/pdf/COMDEX_Fall2001.pdf#search=%22Proietti%20toa%22>
(Rasch 2005) Rasch M. 2005. Tracked by cellphone. Accessed 2006. <http://www.theregister.co.uk/2005/12/22/tracked_by_mobile_phone/>
(Schidt-Belz et al 2002) Schmidt-Belz B., Stefan P., Nick A. and Zipf A. 2002. Personalized and Location-based Mobile Tourism Services. Mobile HCI: Workshop on Mobile Tourism Support Systems. Pisa, Italy. Accessed 2006. <http://dookie.geoinform.fh-mainz.de/~zipf/mobileHCI-crumpet.pdf>
(Strahan 2002) Strahan R. 2002. Location Sensing Technologies. E=mC² Project. University College Dublin. October 2002.
97 of 98
(SnapTrack 2003) SnapTrack. 2003. Location Technologies for GSM, GPRS and UMTS Networks. Accessed 2006. <http://www.cdmatech.com/download_library/pdf/location_tech_wp_1-03.pdf>
(Spotlight 2006) Spotlight Mobile 2006. Accessed 2006. <http://www.spotlightmobile.com>
(Spyns et al 2002) Spyns P., Meersman R. and Jarrar M. 2002. Data modelling versus ontology engineering, ACM SIGMOD Record, vol. 31, no. 4, December 2002.
(TheBassbin 2006) TheBassbin.com. 2006. Becker Traffic Pro 7945 - Satelite Navigation. Accessed 2006. <http://thebassbin.co.uk/shop/ product/products_id/2061.html>
(TheRegister 2003) Wireless Watch – TheRegister. 2003. WiMAX trials speed up. Accessed 2006. <http://www.theregister.co.uk/2003/12/09/wimax_trials_speed_up>
(TheRegister 2006) Outlaw – TheRegister. 2006. Mobile phone tracking, girlfriend stalking and the law. Accessed 2006. <http://www.theregister.co.uk/2006/02/02/mobile-phone_tracking>
(TI 2006) Telematica Instituut. 2006. GSM Cells. Accessed 2006. <http://www.lab.telin.nl/~koolwaaij/showcase/gsmcells>
(T-Mobile 2006) T-Mobile. 2006. T-Zones – Highlights. Accessed 2006. <http://www.t-zones.co.uk/en/Highlights/search.html>
(TomTom 2006) TomTom. 2006. Mobile Navigation. Accessed 2006. <http://www.tomtom.com/products/category.php?ID=2&Language=1>
(TreoCentral 2006) TreoCentral. 2006. Java comes to Treo 600. Accessed 2006. <http://www.treocentral.com/content/Stories/297-1.htm>
(Vodafone 2006a) Vodafone. 2006. Vodafone Live: Travel and location. Accessed 2006. <http://www.vodafone-i.co.uk/live/travel_location.html>
(Vodafone 2006b) Vodafone. 2006. Vodafone Locate You. Accessed 2006. <http://onlin e.vodafone.co.uk/dispatch/Portal/appmanager/vodafone/wrp?_nfpb=true&_pageLabel=Page_ProductDetails&pageID=BS_0701&Content_Id=AZ_072>
(Want & Schilit 1992) Want R., Hopper A., Falcão V. and Gibbons J. 1992. The Active Badge Location System. ACM Transactions on Information Systems, Jan 1992, pp. 91-102.
(Wilde 2002) Wilde G. 2003. Performance Implications of Wireless Location Technologies –The Effect on Location-based Ser vice Revenue Growth. Wireless Technology 2003. December 2002.
(Wired 2002) Wired, Stroud M. 2002. Have Cell Phone, Will Fight. Accessed 2006. <http://www.wired.com/news/wireless/0,1382,50205,00.html>
(ZDNet 2005) Reardon M. – ZDNet. 2006. Motorola, Intel team on mobile WiMax. Accessed 2006. <http://news.zdnet.com/2100-1035_22-5917562.html>
(ZDNet 2006) Best J. – ZDNet. 2006. Results are in from Pipex's WiMax experiment. Accessed 2006. <http://news.zdnet.co.uk/communications/0,39020336,39281022,00.htm>
98 of 98