AN INVESTIGATION INTO THE INCORPORATION OF LEADING …...An Investigation into the Incorporation of Leading Edge Mobile Technologies in the Recreation and Adventure Tourism Industries

AN INVESTIGATION INTO THE INCORPORATION OF LEADING EDGE MOBILE TECHNOLOGIES IN THE RECREATIONAL AND ADVENTURE TOURISM INDUSTRIES

Leisa Armstrong, Christopher Holme, Gautham Kasinath, Ajdin Sehovic, Yatish Vadera, Greg LeCoultre and Brendan John

An Investigation into the Incorporation of Leading Edge Mobile Technologies in the Recreation and Adventure Tourism Industries

ii

Technical Reports The technical report series present data and its analysis, meta-studies and conceptual studies, and are considered to be of value to industry, government and researchers. Unlike the Sustainable Tourism Cooperative Research Centre’s Monograph series, these reports have not been subjected to an external peer review process. As such, the scientific accuracy and merit of the research reported here is the responsibility of the authors, who should be contacted for clarification of any content. Author contact details are at the back of this report.

We'd love to know what you think of our new research titles. If you have five minutes to spare, please visit our website or click on the link below to complete our online survey. 0Sustainable Tourism CRC Tech Report Feedback

National Library of Australia Cataloguing-in-Publication entry Armstrong, Leisa. An investigation into the incorporation of leading edge mobile technologies in the recreation and adventure tourism industries. ISBN: 9781920965938 (pbk.) 9781920965945(pdf.) Notes: Bibliography. Subjects: Tourism. Tourism—Communication systems. Global Positioning System. Mobile communication systems.

Other Authors/Contributors: Holme, Christopher., Kasinath, Gautham., Sehovic, Ajdin., Vadera, Yatish., LeCoultre, Greg., John, Brendan., Cooperative Research Centre for Sustainable Tourism. Dewey Number: 621.3845

Copyright © CRC for Sustainable Tourism Pty Ltd 2008 All rights reserved. Apart from fair dealing for the purposes of study, research, criticism or review as permitted under the Copyright Act, no part of this book may be reproduced by any process without written permission from the publisher. Any enquiries should be directed to:

General Manager, Communications and Industry Extension or Publishing Manager, [email protected]

First published in Australia in 2008 by CRC for Sustainable Tourism Pty Ltd

Printed in Australia (Gold Coast, Queensland)

Cover designed by Sin Design

Acknowledgements The Sustainable Tourism Cooperative Research Centre, established and supported under the Australian Government’s Cooperative Research Centres Program, funded this research. Additional financial support was provided by Edith Cowan University and Western Australian Sports and Recreation. Support from the staff from the following organisations is also acknowledged: Edith Cowan University, Bibbulmun Track Foundation, and Western Australian Department of Environment and Conservation (DEC).

http://sustainabletourismcrc.cmail3.com/l/424209/s4i6d21/www.surveymonkey.com/s.aspx?sm=cCMy_2fyZbjAjkr2Vy5LopCg_3d_3d�

mailto:[email protected]�


iii

CONTENTS

TABLES _______________________________________________________________________________ 1V FIGURES ______________________________________________________________________________ 1V ABSTRACT ____________________________________________________________________________ 1VI

SUMMARY ___________________________________________________________________________ 1VII OBJECTIVES OF STUDY __________________________________________________________________ 1VII METHODOLOGY _______________________________________________________________________ 1VII KEY FINDINGS ________________________________________________________________________ 1VII FUTURE ACTION _______________________________________________________________________ 1VII

INTRODUCTION________________________________________________________________________ 19 PROJECT BENEFITS ______________________________________________________________________ 19

THE BIBBULMUN WALKING TRACK CASE STUDY ______________________________________ 111 TRACK DESCRIPTION ___________________________________________________________________ 111 TRACK RESOURCES AND INFORMATION REPOSITORIES _________________________________________ 111

Data Set Size and Composition _________________________________________________________ 111 Data Set Creation ___________________________________________________________________ 113 Data Set Costing ____________________________________________________________________ 113 Data Set Maintenance ________________________________________________________________ 113 Data Set Recommendations____________________________________________________________ 114

NETWORK SERVICES ____________________________________________________________________ 114 Mobile Network Survey _______________________________________________________________ 114 GPS and Satellite Coverage ___________________________________________________________ 115 Reconciliation of Dropout Spots and Safety Critical Spots ____________________________________ 116 Network Service Costing ______________________________________________________________ 116 Network Services Conclusions and Recommendation ________________________________________ 117

DELIVERY TECHNOLOGY ________________________________________________________________ 117 Device Selection Criteria______________________________________________________________ 117

ALTERNATIVE MOBILE DEVICES___________________________________________________________ 119 CDMA Mobiles _____________________________________________________________________ 119 GPS Enabled Devices ________________________________________________________________ 119 RFID Technologies __________________________________________________________________ 120

OTHER INFRASTRUCTURE REQUIREMENTS ___________________________________________________ 120 Possible Requirements________________________________________________________________ 121

DEVELOPMENT ENVIRONMENT ____________________________________________________________ 121 Overview of GPS Technology and GPS Usage _____________________________________________ 121 Software Development Environments and Paradigms _______________________________________ 122

OVERVIEW OF THE EGUIDE PROTOTYPE ______________________________________________ 124 EGUIDE USERS ________________________________________________________________________ 124 SCENARIO OF EGUIDE USAGE _____________________________________________________________ 124 OPERATING ENVIRONMENT ______________________________________________________________ 125 SYSTEM FEATURES _____________________________________________________________________ 126

Legal Disclaimer ____________________________________________________________________ 126 Main Graphical Interface _____________________________________________________________ 127 Help – User Demonstration____________________________________________________________ 127 Help – User Tutorial _________________________________________________________________ 127 LPS enabled tour guide (Using an Itinerary) ______________________________________________ 128 LBS enabled tour guide (without itinerary)________________________________________________ 130 Options ___________________________________________________________________________ 131 Help ______________________________________________________________________________ 131 Ad-hoc Tour Mode___________________________________________________________________ 131 Other Non-functional Requirements _____________________________________________________ 132

EGUIDE DESIGN AND IMPLEMENTATION ______________________________________________ 134 EGUIDE INTERFACE DESIGN ______________________________________________________________ 236

Graphic User Interface _______________________________________________________________ 236

http://sustainabletourismcrc.cmail3.com/l/424209/s4i6d21/www.surveymonkey.com/s.aspx?sm=cCMy_2fyZbjAjkr2Vy5LopCg_3d_3d�



iv

Audio Interface _____________________________________________________________________ 238 Design and Implementation Constraints __________________________________________________ 240

IMPLEMENTATION OF EGUIDE FUNCTIONALITY _______________________________________________ 241 Navigation _________________________________________________________________________ 241 Content Delivery ____________________________________________________________________ 241 Customisation of User Interfaces _______________________________________________________ 242

RESOURCE UTILISATION _________________________________________________________________ 247 ADDITIONAL IMPLEMENTED FUNCTIONALITY OF EGUIDE SOFTWARE ______________________________ 247

Navigation _________________________________________________________________________ 247 Content Delivery ____________________________________________________________________ 247 Voice Simulation ____________________________________________________________________ 247 Integration with ePortal ______________________________________________________________ 247 Resource Utilisation _________________________________________________________________ 248 Security ___________________________________________________________________________ 248

EPORTAL DESIGN AND IMPLEMENTATION ____________________________________________ 249 EPORTAL FUNCTIONALITY _______________________________________________________________ 249 EPORTAL USERS _______________________________________________________________________ 251 EPORTAL FUNCTIONALITY _______________________________________________________________ 251 GENERAL FUNCTIONALITY _______________________________________________________________ 251 DATA MANAGEMENT ___________________________________________________________________ 252

Maps and Point-of-interest Categories ___________________________________________________ 252 Preview and Export __________________________________________________________________ 252

EPORTAL ARCHITECTURE ________________________________________________________________ 253 EPORTAL SECURITY ____________________________________________________________________ 253

Database __________________________________________________________________________ 253 Application Security _________________________________________________________________ 253

DATABASE DESIGN _____________________________________________________________________ 254 EPORTAL IMPLEMENTATION ______________________________________________________________ 254

Scenario of ePortal Usage_____________________________________________________________ 254 Future ePortal Iterations______________________________________________________________ 261

STRATEGIC PLANNING FOR EGUIDE SYSTEM __________________________________________ 262 ALTERNATIVE EGUIDE SYSTEM MANAGEMENT _______________________________________________ 262

Option 1: New External Entity _________________________________________________________ 263 Option 2: Bibbulmun Track Foundation __________________________________________________ 263 Option 3: DEC or WA Sports and Recreation______________________________________________ 264 Option 4: ECU University _____________________________________________________________ 264 Option 5: Combination _______________________________________________________________ 265

PRODUCT PACKAGING __________________________________________________________________ 265 CUSTOMISATION OF PRODUCTS AND SERVICES________________________________________________ 266 PARTNERSHIPS AND CONTRACTUAL ARRANGEMENTS __________________________________________ 266

APPENDIX A: NETWORK COVERAGE___________________________________________________ 267 APPENDIX B: MOBILE DEVICES________________________________________________________ 274 APPENDIX C: EPORTAL DESIGN _______________________________________________________ 279

REFERENCES________________________________________________________________________ 284 GLOSSARY ___________________________________________________________________________ 285

AUTHORS_____________________________________________________________________________ 287



v

Tables 1Table 1 Examples of Possible Data sets required for eGuide application._____________________________ 212 1Table 2 Summary of Features of Available Network Services ______________________________________ 217 1Table 3 Comparison of Development environments for Bibbulmun Track Electronic Tour Guide __________ 223

Figures Figure 1 CDMA coverage in the South West Region of Western Australia ____________________________ 15 Figure 2 Telstra mobile network coverage in the South West Region of Western Australia________________ 16 Figure 3 eGuide Use Case Diagram__________________________________________________________ 26 Figure 4 eGuide Software Architecture _______________________________________________________ 34 Figure 5 eGuide Software component design ___________________________________________________ 34 Figure 6 State Diagram of eGuide System _____________________________________________________ 35 Figure 7 Gui Navigation Diagram for eGuide __________________________________________________ 38 Figure 8 eGuide Screen shots _______________________________________________________________ 39 Figure 9 The original basic GUI interface _____________________________________________________ 43 Figure 10 Alternative GUI Interface design for eGuide __________________________________________ 44 Figure 11 Alternative GUI Interface design for eGuide __________________________________________ 45 1Figure 12 Generalised view of the ePortal system 50___________________________________________ 46 Figure 12 Generalised view of the ePortal system _______________________________________________ 49 Figure 13 Screen shots of ePortal Prototype ___________________________________________________ 50 Figure 14 ePortal Use Case Diagram ________________________________________________________ 52 Figure 15 Database Design for the ePortal System ______________________________________________ 54



vi

Abstract The project investigated the feasibility of delivering wireless Location Based Information (LBS) services in a regional Australian adventure tourism context. The services were delivered through the use of Global Positioning System (GPS) satellite technologies. The research project aimed to:

• determine the most appropriate technology for the delivery of such services based on network and device constraints;

• establish a proof of concept Location Based Services (LBS) system to deliver user customisable, language specific information services; and

• develop appropriate strategies to overcome logistical and technology constraints for the delivery of such services.

The project findings established the feasibility of service delivery and will contribute to the establishment of a regional mobile implementation strategy for LBS in the adventure tourism industry. The outcomes of the project include:

• a strategic plan for the delivery of LBS services over handheld devices; • a proof of concept generalisable solution; and • formal partnerships with the tourism and recreation industries.


vii

SUMMARY

Objectives of Study The objectives of the study were to:

• Develop a proof of concept application that can be used to demonstrate a generalisable solution for the delivery of Location Based Information (LBS) services in a regional Australian adventure tourism context. The services will be delivered through the use of Global Positioning System (GPS) satellite technologies.

• Produce a position paper which outlines the appropriate strategies needed to overcome logistical and technology constraints for the delivery of such services.

Methodology The following activities were carried out during the project:

• A survey of phone network coverage and infrastructure in remote locations of the South West Region of Australia was undertaken to determine the proposed LBS system constraints.

• An examination of alternative technologies for the delivery of location specific information to determine the most appropriate hardware and software technologies for remote Western Australian (WA) locations.

• The design, development and testing of a proof of concept LBS system (guide) using sample information services for adventure tourism. The system’s development was based on criteria developed from initial findings from the survey and examination of alternative technologies.

• The construction of the sample information data sets for GPS using available Geographic Information System (GIS) data sets and information services using geographic and biodiversity information based on one Bibulous track sector.

• The deployment and field testing of a prototype system on preferred sample mobile devices for one Bibbulmun track sector.

• The implementation and analysis of the findings of a focus group study using a prototype system in one Bibbulmun track sector.

• The development of a strategic plan for the delivery of information services using LBS in a remote, regional setting using GIS data sets and appropriate information services.

Key Findings Key findings to emerge from the project were:

• A location based mobile tourism guide for bushwalkers using GPS enabled technology is feasible for this Western Australian situation.

• For the foreseeable future, a GPS enabled Personal Digital Assistant (PDA) enabled mobile guide is considered to be the most appropriate technology to deliver the mobile tourist guide.

Future Action Future actions identified by the project are that:

• Further work is needed to develop a commercialisable solution for the LBS enabled mobile tourism guide.

• Formal partnerships need to be put in place to ensure access to rich media content for the guide based system including the maintenance of maps and information repositories.

• Some examination needs to be made to standardise the point-of-interest data contents for the system.


viii


9

Chapter 1

INTRODUCTION

This research project aimed to develop a proof of concept software application to demonstrate a generalisable solution for the delivery of wireless Location Based Information Services (LBS) in a regional Australian adventure tourism context. The software application will deliver services through the use of Global Positioning System (GPS) satellite technologies. Specifically, the software application will provide a mobile tour guide experience to bushwalkers using the Bibbulmun track. This software application will provide an alternative to the currently available pamphlet based tour guide. The bushwalker’s experience will be further enhanced by providing a means for navigation, location of Points of Interest (POI) and provision of information related to the POI along the walking track. The proof of concept is designed to provide information about one representative section of the Bibbulmun track, the Mundaring section.

Project Benefits The proof of concept establishes the feasibility of location based tourism services for Australian adventure and ecotourism by delivering a proof of concept LBS software system which can provide real-time, customisable services in an adventure tourism or ecotourism setting. The continuing evolution of wireless data communications suggests that location sensing and awareness will become common capabilities in all mobile devices, software applications and user services. The application of LBS to tourism has been heralded by a number of researchers as a critical development in eTourism (Benjamin, 2003; Buhalis, 2003; Kanerva, 2004; Oertels, 2002; Strangeways, 2003). The European tourism industry is a current world leader in the application of mobile data systems within the tourism industry. Benchmark projects include Project PALIO which provides location aware services to tourists using complex systems with user-friendly and personalised interfaces; and Project CRUMPET which provides value-added services for nomadic users across mobile and fixed networks using agent technologies.

The project has designed and implemented a location aware software solution which will allow for the delivery of customisable solutions which provide both enhanced tourist experiences and safety services for adventure and eco-tourists. It is envisaged that the system can be commercialized to provide customizable solutions for different settings (e. g. walking and canoeing trails, etc). The delivery of a system that enhances tourism experiences by delivering customisable language specific information with different contextual emphasis (e.g. botanical, historical or cultural interest) and additional safety and emergency services might increase the number of tourists visiting such adventure and ecotourism settings. This will improve the sustainability and quality of such services by utilising alternative mechanisms to provide customisable information services in a location aware context. The main organizations to benefit from the LBS solution include Ecotourism and adventure tourism operators, national parks and recreation agencies and foundations. The LBS software solution may be used in conjunction with other tourism research projects. For example, the implemented LBS software solution could be used in a research study to establish the adoption and sustainability of delivering mobile tourism services and strategies to enhance tourist experiences.

The expected benefits to the users of the Bibbulmun track arising from the deployment of the proof of concept software are listed below:

• enhanced walking experience • easier to locate POI • easier to stay on official routes • improved access to location specific information • enhanced walker (tourist) safety • provision of readily accessible and guided first aid information • improved accessibility to conservation and safety information • greater ability to manage the route and the users of the walking trail when there are identified transient

dangers such as fire.


10

Other benefits to the users of the system include:

• projected increase in advertising revenue • potentially increased usage of the track by international and other user groups • a reduction in resources required to respond to lost or endangered walkers and tour groups • increased revenue with the production of customisable modules for walking sections and specialist

groups (botanists, bird watchers, cultural and heritage groups).


11

Chapter 2

THE BIBBULMUN WALKING TRACK CASE STUDY

This case study project, using the Bibbulmun Track as a proof of concept aimed to establish the feasibility of delivering an eGuide system (i.e. a wireless LBS) in a regional Australian adventure tourism context.

Track Description The Bibbulmun track is a walking and adventure trail which is considered to be one of the world’s greatest long distance walk trails, stretching nearly 1000 kilometres from Kalamunda (Perth Hills) to Albany (South Coast) through the heart of the scenic South West of Western Australia. The Bibbulmun track is managed by the Western Australian Government Department of Environment and Conservation (DEC) with the assistance of the Bibbulmun Track Foundation (BTF). Print based maps and other related information based materials about designated sections of the walking track are available to users. At regular intervals along the track there are a number of campsites and facilities for bushwalkers.

Track Resources and Information Repositories Recognition of the information needs and requirements for the delivery of an LBS for the Bibbulmun Track is an essential starting point. This helped to establish what kind of information can be provided and assessed the feasibility of providing such information. This analysis also focused on the development and maintenance costs connected with the data set. An examination has been made of the factors which need to be taken into account in the delivery of information to the user in the form of audio, video and graphic media, to determine the accessibility and availability to the data in order to develop the data set, the cost of developing the data set and the maintenance of the data set.

Data Set Size and Composition It was proposed that the system will use a GPS data set to provide location and geographical information to the user. The creation of a rich data set was required to enable utilisation of appropriate data set layers. It was determined that the creation, correct formatting and digital storage in comma separated variable form of the data set would enable ease in search and formatting functions. DEC advised that currently there are no digital Geo–referenced maps available for the Bibbulmun track. The memory requirements for a complete 1:50,000 scale digital map is approximately 1MB. Since the Bibbulmun track is covered by a total of eight maps, approximately 8MB of memory is required to store the map data. These 1:50,000 scale maps are available from the Bibbulmun Foundation in Perth.

There is potential to develop several technological avenues from a GPS database. Test data can be obtained from the BTF. Data collected could then be incorporated into a large GIS rich database set. Additional existing GPS data could be integrated later to provide additional practical information. Development of this technology to use and develop a GPS database could potentially generate further projects, such as adding data to the rich data set and retrieving data from a main rich GPS database.

The following list details the possible categories of the type of data that may be used by the system:

• maps • information on shelters and their surrounding facilities • photos of the shelters and their surrounding facilities • photos of the towns • town information data (history etc.) • photos of flora and fauna • flora and furan information and data • photos/video of birds and wildlife • birds and wildlife information and data • first aid information and procedures (provided through text, photos, dialog and video) • commentaries of surroundings of important or historical locations (including towns)


12

• list of landmarks (sometimes accompanied with photos) • emergency contacts and first point of call (police and hospital etc.) • planning assistance information and pictures • advertisements (photos and video) • location of communication points (information and photos) • weather information and photos (general forecasts as no real-time data transfer is available) • safety critical points information and video • information and photos about shops (can be from paid like advertisements) • information and location on water collection points • location of garbage disposal points • jokes of the day • Aboriginal history information, video and photos • music

Table 1 displays a suggested minimum data set size for the eGuide system. However the actual size and composition of the data set can be manipulated so as to fit the memory requirements of the chosen device. For example, audio or video can be removed and replaced with pictures or text, if memory capacity was limited. It is recommended that the video and audio be used selectively. In the meantime, it is evident from the above that a data set would be of an appropriate size to be used on mobile devices.

Table 1 Examples of Possible Data sets required for eGuide application.

Item Details Item size Total (kb) Maps 8 maps, 700 mm x 300 mm in size 1 MB

each 8000

Information and data (towns, birds and wildlife, flora and fauna, shelter and surrounding facilities)

Text information see – Sum of all text

0

Shelter photos

At least 48 JPEG format, 200 x 168 pixels, 60% compression

9 kb each 432

Flora and fauna photos

Around 100 JPEG format, 200 x1 68 pixels, 60% compression

9 kb each 900

Birds and wildlife Photos/movies

Around 100 JPEG format, 200x168 pixels, 60% compression

9 kb each 900

Around 4 min video. Data rate: Quicktime Sorenson 28 kbps. Frame size: 160 x 120 pixels. Frame rate: 7.5fps de-interlaced

220 kb/min

880

First aid information

Text information see – Sum of all text

0

Around 5 min video. Data rate: QuickTime Sorenson 28 kbps. Frame size: 160x120 pixels. Frame rate: 7.5fps de-interlaced

220 kb/min

1100


9 kb each 270

Commentaries Around 30 min audio. Bit-rate 32 kbps (Mono AM Radio quality)

234.375 kb/min

7032

Landmarks Text information see – Sum of all Text 0 Around 50 JPEG format, 200x168 pixels,

60% compression 9 kb each 450

Emergency contacts Text information see – Sum of all Text

0

Around 15 JPEG format, 200 x 168 pixels, 60% compression

9 kb each 153


13

Planning information Around 30 JPEG format, 200x168 pixels, 60% compression

9 kb each 270

Text information see – Sum of all Text 0 Advertisements Can be allocated 1 MB 1000 Communication points Around 50 JPEG format, 200x168 pixels,


Weather information Text information see – Sum of all Text 0 Weather photos (photo forecast for 5 days)


9 kb each 153

Safety critical points information and video

Text information see – Sum of all Text 0

Around 4 min video. Data rate: QuickTime Sorenson 28 Kbits/sec. Frame size: 160x120. Frame rate: 7.5fps de-interlaced

220 kb/min

880

Shop information and photos Text information see – Sum of all Text 0 Around 30 JPEG format, 200x168 pixels,


Water collection points Text information see – Sum of all Text 0 Garbage disposal locations Text information see – Sum of all Text 0 Jokes Text information see – Sum of all Text 0 Aboriginal history Around 50 JPEG format, 200x168 pixels,


Text information see – Sum of all Text 0 Sum of all Text: 5,000,000 characters in a .txt document

around 5 MB, 1500 pages 5000

TOTAL 28590

Data Set Creation The creation of the data set for the eGuide system will largely be the responsibility of the industry partners DEC, WA Sports and Recreation (WASR) and the BTF. The availability and creation of rich media content for the eGuide systems will be a major determining factor of its success. Industry partners have agreed to assist in the development of the data set if required. Potentially, main contributions would come from DEC and BTF.

Data Set Costing A preliminary assessment of the cost of setting up the data set has been made. Initial cost assessment is twofold. First, adequate GPS mapping software must be available to scan maps for each section of the Bibbulmun track. Second, resources for the following activities are required: data entry, photo/images uploading, database design and ePortal development, way points and special location identification on maps.

Such initial cost outlay may allow for either the development of a restricted data set of the entire track or an extensive data set for one section of the track. It is important to note that these projected costs may change if a more extensive data set is developed or if the categories of the data set are added to or changed. It is likely that following the development of the initial data set, it would be expanded considerably to produce a valuable sized data set. This is significant because further development of the initial data set will add to the overall development and deployment of a commercial solution costing. This may require financial support from potential industry partners.

Data Set Maintenance The issue of maintenance of the data set is integral to the success of the eGuide system. This would depend upon the nature of the future business structure established to provide the service. These options are discussed in Chapter 6. The major responsibilities would include:

• data set maintenance (looking after existing data) • data set updating (adding new data or removing unwanted data)

The organisations in the best position to maintain the data set would be the BTF, WA Sports and Recreation and DEC as each has good access to information and may assist in the development of the original data set.


14

Cost of Maintaining the Data Set The main costs involved with maintaining the data set is related to cost of employing personnel. Time will be spent modifying the data set, inserting new data into the data set and removing out-of-date information. There is also a cost related to gathering current and new information.

The related cost will be dependent on the business structure that is established later. For example, the BTF has a large community and volunteer base that looks after the physical state of the track and this group may assist in gathering new information for the data set. On the other hand, WASR and the DEC are always gathering information for other purposes and such information may also be included in the data set. The abovementioned projected costs, not unlike the development costs identified earlier, may prove to be grossly underestimated. For instance, maintenance costs may prove to be a large expense if the initial data set is not extensive. Hence the viability of the project from this perspective is only feasible if industry partners and/or in-kind support cover much of these costs.

Data Set Recommendations An examination of the information data sets needed for the eGuide software indicates that there is a need to manipulate the actual size and composition of the data set to fit the memory requirements of the chosen device. It is recommended that video and audio be used selectively. The data set should be of an appropriate size for use on mobile devices. The final operation data set if stored on a flash memory card can be of an extremely large size possibly reaching several Gigabytes in size.

At this stage, DEC, WASR and the BTF have agreed to assist in the development of the data set if required, with main contributions potentially coming from DEC. The feasibility of wider applications of the service relies on the cost effectiveness of developing a useful data set. Once initial data sets have been developed extensively for a track, maintenance cost should be controlled to a feasible and profitable level.

Network Services Network services analyses was based on identification and description of the nature of network coverage in the South West region. Having investigated the extent of coverage and estimated usage costs of current mobile phone (e.g. CDMA etc.) and GPS enabled networks, a set of recommendations for selection of a suitable network for the eGuide is proposed. The recommendation is based on the following criteria: extensiveness of network; reliability; cost of use; and coverage in safety critical locations.

Mobile Network Survey The network survey undertaken included three existing networks: CDMA, GSM and GPRS. The current CDMA network is considered to be unsuitable for reasons of signal fade and dropout caused by terrain and issues with poor triangulation resultant from inadequate base stations. A survey of current CDMA coverage by mobile phone network providers including Optus, Telstra and 3 networks in Western Australia is shown in Appendix A. Telstra network has the greatest coverage; however a large portion of the Bibbulmun track remains out of range. In addition, where there is some coverage it has low reliability. A survey of GSM based networks concluded that these networks do not provide anywhere near enough coverage to make use of this network viable (see Appendix A).


15

General Packet Radio Services (GPRS), a packet-based wireless communication service, promises fast data rates and connection to the Internet for mobile devices that are GPRS capable. The use of this network would be ideal as the two-way data communication uses packets. This would make implantation relatively easy. However, the GPRS network services with an overlay of the GSM network has insufficient coverage for our purposes. Further details on the Telstra GPRS services are outlined in Appendix A.

An examination of planned mobile network coverage suggests that no existing mobile network providers have forecasted that they would be able to provide adequate coverage, in the South West Australian region within which the Bibbulmun Track is located in the foreseeable future.

Figure 1 CDMA coverage in the South West Region of Western Australia

GPS and Satellite Coverage An examination of the satellite network and GPS coverage found these to be adequate in the South Western region and also indicated that such coverage provided greater reliability than CMDA or GSM. The GPS network is currently provided by the USA military and is not connected to Australian telecommunication providers. However Telstra and Optus both provide satellite services, and their respective range of service coverage is shown in Appendix A. It must be noted that the GPS satellite network only provides location coordinates and not two-way data communications.

Optus provide a mobile phone satellite service that covers the required areas. However, this service does not provide the mobility required as it is designed for vehicle-mounted service. Since the Optus technology uses GPS to provide the phone service, it offers an inefficient service option for this project. A more suitable option would be to provide the service directly using GPS connectivity. Appendix A provides further details.

Telstra provide a similar satellite service as Optus, using the Iridium satellite network. Further information on this technology is provided in Appendix A. There is a possibility that this service could be used in this situation. However, the mobile devices require multiple accessories and the compatibility with other devices (apart from the devices the service is designed for) is unknown. The service can provide a 2.4 kbps connection speed and act like a dial-up connection for a laptop. It is possible that this network may be used, but the locating abilities of the network are unknown (that is, the ability of the devices and satellites to work out a physical location).

CDMA Cell


16

Figure 2 Telstra mobile network coverage in the South West Region of Western Australia

Reconciliation of Dropout Spots and Safety Critical Spots A reconciliation of dropout spots and safety critical spots would be useful if CDMA or GSM networks covered the track. However, CDMA and GSM cover so little of the track it is of no benefit to complete the reconciliation. As GPS covers the complete track it would incorporate any safety critical spots.

Network Service Costing The cost of using a CDMA network depends on the provider and on what product services one is connected to (Table 2). Such costs have not been further investigated, as the network coverage is inadequate.

Likewise, the cost of GSM also depends on the provider and on what product services one is connected to. Again, these costs have not been further investigated, as the network coverage is not adequate. The cost of using the Optus satellite service is provided in Appendix A. Further discussion is not warranted as using this service would be inefficient.


17

The cost of using Telstra satellite services is shown in Appendix B. These costs make using the network unfeasible. The cost of GPS services is limited to the purchase of hardware. There are no network connection fees.

Table 2 Summary of Features of Available Network Services

Criteria CDMA GSM Telstra Satellite

GPS

Extensiveness of network < 80% coverage Poor coverage Total coverage

Total coverage

Reliability Poor Poor Good Good Coverage in safety critical locations

Poor coverage Poor coverage Total coverage

Total coverage

Cost of use N/A N/A High Null

Network Services Conclusions and Recommendation It is concluded that the CDMA and GSM networks do not provide adequate coverage currently, nor are they likely to do so in the foreseeable future to be considered as viable network media for the eGuide system. As GPRS relies on the GSM network, it is also not considered to be a viable alternative network media. Moreover, since CDMA and GSM networks cover so little of the track it was considered to be of no benefit to complete a reconciliation of dropout spots and safety critical spots. Although Optus and Telstra satellite networks provide the required coverage, their costs are too high and provide inadequate flexibility around hardware options. It is considered that GPS provides the best and cheapest coverage but does not allow for data communications.

It is therefore recommended that the best network media alternative for the eGuide system is the use of a GPS network.

Delivery Technology A range of possible delivery technologies that could be used for the Bibbulmun Track eGuide solution were investigated. Details of this are supplied in Appendix B.

Device Selection Criteria There are a number of criteria that need to be considered when selecting a suitable technology, including data attributes, accuracy of position, GPS channels and other criteria detailed below.

Data Attributes There is a need to establish the requirements of the technology in relation to the list of attributes required by the user to describe their location.

Accuracy of Position Fixed positioning will require that an adequate level of accuracy be established. In addition, differential correction of position fixes was deemed necessary in order to increase accuracy from tens of metres to less than a metre. This differential correction will need to be processed in real time or at some later stage of processing (post processing).

To be able to differentially correct the position, a second GPS unit will be required to act as a base station. For real time corrections, special equipment such as radio transmitters and receivers will be required. For post processing of fixed positions, GPS units that are capable of logging positions of a minimum of once a day are recommended however the device must be able to manage and store the data effectively.

GPS Channels At least four GPS satellites are required to obtain an accurate three dimensional position fix, the greater the number of satellites in range the greater the accuracy. GPS devices work in two different ways: a single channel and a multi-channel. Single channel GPS units have to track all the satellites and receive other important information on the one channel by constantly switching between the satellites. Multi-channel GPS units can


18

track the satellites and receive information simultaneously on different channels which results in greater efficiency. Mid-range GPS units have between six and twelve channels which means they can use up to as many satellites to obtain a positional fix.

GPS Connections and Cables Additional cabling and connectors may be needed to connect GPS receivers with external antennas and other computers and controllers. Many of the handheld computers today offer clip-on GPS receivers, compact flash and PCMCIA adaptor GPS units that require no cable attachments. Antennas may improve accuracy by boosting the signal.

WAAS Capable WAAS (Wireless Augmentation System) is a system of satellites and ground stations that provide GPS signal corrections to produce improved position accuracy, up to an average of five times. AWAAS enabled GPS device does not require additional receiving equipment.

GPS Wireless Connectivity The majority of mobile devices carry inbuilt Bluetooth technology, enabling a personal area wireless network. Although Bluetooth has a limited range of coverage, this capability on a mobile device could be useful as it would allow users to download information at a nearby Bluetooth kiosk along the track.

Data Management and Storage The amount of data able to be stored by a particular GPS unit is a vital consideration. The selected GPS unit should have enough memory to allow storage of data for at least one full day of waypoints and preferably several days worth, particularly if downloading of data will only be possible at infrequent intervals. GPS units come typically with 1 to 16 MB of data storage. Some newer personal handheld computers typically have 16 to 64 MB data storage. There are also various storage cards to keep track of record keeping data. This can be very helpful in a scenario where the battery of the device runs down and any data stored directly on the handheld may be lost.

Screen Quality and Size The unit’s display is very important; the user should be able to view information displayed on it at any time of the day. The screen should not dim to a point of unreadability. A screen and keypad that have backlight capabilities are helpful for ease of use in the dark. The handheld device should be equipped with a stylus pen that can be used to point and click on the screen. Some screens are best used during daytime while others are more suited for night time use. The ideal device should cater for use during the day and at night with good screen readability capability.

Battery Life Battery life of the device is of greatest importance. The battery capacity should be able to supply sufficient power for at least two or more days. Accessories are also available and sold separately to help users power up and charge such devices. These accessories may include key chain charges and solar chargers. Furthermore, the battery itself should be of some type of standardised battery that is easily available enabling users to carry spare batteries just in case. The time needed to recharge the device should be short yet very efficient in recharging the battery.

Audible Features Audible alarms can be very useful for users providing a sense of alert. For example, an audible sound is played on reaching a specific location or indicating off-course travel when navigating through the field. The audible sound should be played periodically and the user should be able to confirm in some way that the sound was heard; this capability erases out when a sound may be played but the user never heard it and due to this the user may await the sound and extend the journey.

Mobile Software Considerations The software that is going to be used on the device should be light, meaning it should not consume the vital limited resources such as memory and processing power of the device. Known operating systems for mobile devices are Palm OS, Windows Mobile. The device must be chosen based on the usability and best interface.


19

Compatibility The device should be compatible with other devices that other team members or users use while in the field. This would benefit the users in terms of data processing. In this way users will be able to save time, resources and costs.

Cost Selecting the device may be very easy but it is scary; the cost factor needs to be considered and looked at very closely. The more features a device has, the more expensive it may be, ranging from a few hundred dollars to tens of thousands for more complex ones. Therefore an examination was made of what functions and features are of most importance and are of high usage by the user. The ideal device should be of the lowest cost that provides basic functions and features. A few complex features may be available for the advanced users. Lastly, quality of the device should not be compromised.

Memory Cards Memory card quotes are at appendix M. A one gigabyte SD Flash card is valued around $40.00. It is recommended using this memory size as it allows for an expanding data set without the need for replacing the memory cards.

Delivery Recommendations This section recommends the use of an independent Bluetooth GPS and Bluetooth enabled PDA. This takes advantage of the low cost of the devices when purchased individually, the advantage of separate power sources and the availability of the expansion slot for a memory card.

Alternative Mobile Devices This section examines possible alternative electronic devices and their feasibility for providing dynamic information to tourist for various recreational pursuits. The prototype provides users (walkers) with an electronic device that can provide information (audio, video and graphic) on points of natural interest, including geography and terrain, and a navigation capability. The device must be functional from a user’s perspective, have sufficient battery endurance, easily rechargeable, be light weight with reasonably inexpensive short range wireless connectivity ability, sufficient memory capacity, moisture resistant and robust.

CDMA Mobiles The use of mobile phone devices in remote areas is characterised by signal fade and drop out due to terrain (valleys) and with the lack of sufficient base stations. In addition, locating positions through phone tower triangulation is problematic.

Battery life for most mobile phones varies between several hundred hours standby mode to a few hours talk time. And these times are dependant on signal strength between base station and mobile. In areas of weak signal strength, a mobile will automatically increase its’ transmit power to maintain a communication link with the base station. This will dramatically reduce battery endurance. In a continuous mode of operation battery life will be reduced to short periods (several hours) before requiring recharging. However, the mobile phone can provide communication access for emergencies from a suitable vantage point i.e. high ground.

The use of a mobile phone as a position/information device is considered unsuitable in this specific situation due to the following: insufficient battery life for extended periods of continuous use and insufficient communication infrastructure to support a continuous communications link.

GPS Enabled Devices These types of devices will provide real-time co-ordinate/navigational information, and are considered to be being well suited for use in Western Australia. In this state, the low density of forest and lack of high mountains would allow for uninterrupted reception of satellite positioning data. There is only a slight deterioration in position accuracy in cloudy/rainy conditions; this would be insufficient to prevent its use as a navigational instrument. The combined use of GPS and PDA can provide a position co-ordinate system that can reference a database system to provide pre-determined relevant information to a user. The GIS database information would suit this application well.


20

Advantages

Information Upload A PDA can have database information installed by several methods. Memory capacity would be the limitation on how much information can be carried at any one time.

• Bluetooth short range wireless technology which is available on PDAs can be used to upload relevant data to the PDA at waypoints if memory limitation is a problem. This can be accomplished by having a PC with the relevant database and Bluetooth Wi-Fi on board at a waypoint. When the PDA comes into range, the upload begins automatically.

• A flash memory card that has the specific database information pre-installed could be provided to the PDA user. Memory cards with eight gigabyte capacity are available and larger capacity cards will become available as technology improves.

• Direct cable connection from PC/laptop to PDA cradle. Relevant information can be downloaded direct from a PC. This can occur at waypoints or pre arranged locations. Computers installed at waypoints only need to be the PC box installed in a secure housing with data access points.

Battery Life PDAs can provide up to 12 hours of continuous operation under ‘normal’ indoor conditions. However, outdoor use in bright daylight may require the screen backlighting brightness increased to see the display, this will reduce battery performance. The main power drain in PDA systems is the screen brightness level, memory usage (audio and video) and Bluetooth wireless communication with the GPS unit. A software power save mode could be developed to interrogate the GPS at regular intervals as opposed to continual monitoring to prolong battery life. It should be noted that an initial satellite fix can take up to 45 seconds, for cold start, less (eight seconds) for warm start. Battery life for the Bluetooth GPS module is reported to be eight hours in continuous usage. Battery recharge time for these devices on average varies between one and three hours. This would have to be done experimentally. Improvements in battery technology for mobile devices are predicted.

Robustness PDAs are reasonably robust devices, and will endure knocks and bumps (similar to mobile phones). Protective covering/sleeves are available for them which will protect them against damage from dust, moisture and rough handling.

Light Weight On average, depending on the PDA, they weigh approximately 150 grams. The GPS module weighs approx. 95 grams.

RFID Technologies RFID tags can be used in association with PDAs. The tags can be as simple as ID (number) tags or the more complex type that can have data written to them. The use of the ID tags in pre-determined locations can provide a system that associates the ID with database information for that location. This type of system may be developed independent of using the GIS database.

Other Infrastructure Requirements This section investigates the feasibility of the possible infrastructure needs for the Bibbulmun Track eGuide. It examines the costs involved in setting up and maintaining required infrastructure.


21

Possible Requirements The infrastructure required for the eGuide system is outlined below.

• Recharge stations at major rest points/campsites along the track—enabling the recharging of mobile devices for people on longer walks.

• Central server—this is to store a database of the information provided by the service.

• Connection from mobile devices to server—this connection (wireless or wired) is to allow updating of information on the mobile device.

• Main office location—this location is needed for people to pick up and drop off mobile devices (if hiring out mobile devices, with the program installed, is chosen as the preferred way of providing the service), receive payment and provide help desk services.

• Help desk phone service—required for help desk service, booking, or other enquires.

• Point-of-Sale (POS) infrastructure—required to receive payments from customers.

Infrastructure There are 48 shelters along the track within a day’s walking distance apart. It is recommended that at least some of these shelters, recharge points are installed. This could be achieved through the use of solar power. This would be a major infrastructure development. Connection from mobile devices to server is required. However in order to allow multiple devices to be connected to the server at once a ‘hub’ of some kind is needed. Wireless routers are considered the most appropriate. It allows a much larger number of devices to connect and is much cheaper. However the devices need to have wireless capabilities. If the chosen devices do the wireless router is best; otherwise, the two USB hubs would be the next best choice.

Responsible parties Consideration is needed as to where the hardware infrastructure will be located and who will maintain/update it. It is clear that whoever eventually provides the service will maintain and ‘house’ the infrastructure. The options for this are discussed further in Chapter 6. The main areas of infrastructure responsibility are:

• physical infrastructure location

• physical/logical infrastructure maintenance

• physical/logical infrastructure support

• physical/logical infrastructure updating

It is likely that ECU will be responsible for maintaining the source code for the application that provides the service.

Infrastructure recommendation The estimated cost of needed infrastructure is minimal. Most of the available infrastructure depends on the final business structure implemented. This also applies to the responsibility of maintaining, supporting, locating and upgrading the infrastructure—the final business structure will determine whom the responsibility lays. It is recommended as a long-term goal that power supply of some kind is installed at shelters along the track. This would be a major infrastructure development; however it is not an immediate necessity.

Development Environment

Overview of GPS Technology and GPS Usage Global Positioning System (GPS) uses time signals transmitted by satellites and the exact positions of those satellites at the time of transmission to calculate the position of the GPS receiver at any time. GPS usage is restricted to outdoor areas where a significant proportion of the sky is visible. Accuracy of the supplied positioning data is governed by the number of satellites that the GPS receiver can detect and their positions relative to each other. Since GPS uses triangulation to arrive at position data, accuracy is higher when detected satellites are further apart.


22

GPS receiver hardware generally uses National Marine Electronics Association (NMEA) sentences to communicate with the host device. These sentences are usually transmitted over a serial link to the host device, an example of an NMEA sentence is

‘$GPRMC,225446,A,4916.45,N,12311.12,W,000.5,054.7,191194,020.3,E*68’.

(National Marine Electronics Association, 2007).

Where $GPRMC is the device type (GP for GPS) and sentence type (RMC for recommended minimum transit data), *68 is the checksum for the sentence and everything in between the data fields. The minimum data supplied by GPS is latitude, longitude and altitude. Other data such as speed, heading and magnetic deviation are derived from the computed position and almanac data stored within the GPS receiver.

Applications making use of GPS data must open a channel of communication between the GPS hardware and the host device. This usually takes the form of opening the com port that the GPS hardware is attached to and listening for sentences. GPS hardware may be programmed with sentence types and waypoint data but it is not necessary to do this in order to achieve minimal functionality (supply positing and course data). Format of sentences used to program GPS hardware varies with manufacturer. It is necessary to know the manufacturer of the hardware before successful programming may be undertaken.

Accuracy of data supplied by the GPS hardware may vary considerably, any data that the hardware may be able to gather is supplied by means of the com link without regard to accuracy. Some sentences sent by the GPS contain dilution of precision (DOP) arguments which are a relative measure of the accuracy of the data being supplied. The host application must examine these DOP values to determine whether the data is accurate enough for use by that application. Further research on GPS accuracy is discussed in an article by Blewitt and Taylor (2002).

Software Development Environments and Paradigms Several development platforms were considered for the Bibbulmun Track eGuide system. These were Sun’s Java, Microsoft Visual Studio and Symbian OS. A comparison of the alternative environments is outlined in Table 3.

Sun and Java Sun uses 1J2ME for programming resource constrained devices such as PDAs and phones. Location awareness is supported by means of the 1location API (JSR179), Sun Microsystems (2003). The1 location API supports several methods of positioning; the method of interest is GPS. Although J2ME supports positioning, in practice, it is hard to implement due to poor support from Sun for J2ME on other operating systems and poor support by device manufacturers for J2ME in general. Although examples supplied with Suns Wireless Tool Kit have been shown to work, it is not possible to test them with real GPS hardware at this time.

1Serial support has only been realised in J2SDK 1.5 and no third party virtual machine (VM) that may run on a PDA and supports 1.5 has been discovered by the technical team. This lack of support for serial communications on PDA makes it very hard to open and manipulate communication ports from a J2SDK app running on a PDA. In addition, no GPS enabled location development for constrained devices using J2ME has been discovered by the technical team.

On the plus side is the fact that Java IDEs are free and very usable, 1Wireless Tool Kit lacks only a source code editor and 1Netbeans is a fully integrated and very polished IDE. Additionally, most of the project team is familiar with Java development.

Microsoft and Visual Studio Microsoft has produced the 1compact framework for development on resource constrained machines. This is their equivalent of J2ME. The current Compact Framework version is Version 2. The VS2005 emulator may be mapped through to this virtual comport so that a compact framework application may read the data. VS2005 has native support for serial communication via the 1serial port class and also abstracts GPS usage.


23

Symbian Symbian OS is specifically for smaller, resource constrained devices such as PDAs and smart-phones. Symbian is written with C++ but has inbuilt Java support. Other languages and tools such as OPL, Python, Mobile Visual Basic and Macromedia Flash are also supported (Symbian 2007). In recent years Symbian has gained a significant share of the smart-phone market and this share is increasing. 1Symbian OS SDKs are available and appear to be device or user interface specific.

Palm OS PALM OS is an operating system developed by PALM for PALM devices and caters for the mobile computing market. Most PALM applications are written in C; however, developers may also use C++, Visual Basic or Java. More information may be found at 1http://www.palmos.com/dev/start/. Some research has been carried out on the use of PALM as a Host OS for the Bibbulmun Track Electronic Tour Guide Project. SDKs and developer support are available from Palm. Garmin have released several PDAs with integrated GPS. At least one of these is powered by Palm OS, notably the 1Garmin IQue 3600.

Table 3 Comparison of Development environments for Bibbulmun Track Electronic Tour Guide

OS/paradigm Supports Resource Constrained Devices

Supports Locationing

Native GPS Support

Third party GPS Support

Demonstrable Support by Device Manufacturers

Working Simulated Examples

Sun and Java Yes J2ME Yes Location API Yes Location API No Not Found Yes

Microsoft VS2003

Yes CF1.0 No No Yes, OpenNetCF

No Yes

Microsoft VS2005

Yes CF2.0, CF1.0

Yes Yes Yes No Yes

Symbian Yes, specialist OS

Yes, through Java Unknown Unknown Yes, Nokia Unknown

Palm OS Yes, specialist OS

Yes Yes Unknown Yes, SDKs and Data

Unknown

OS/paradigm Working

Examples Native Support for Serial Communications

Third Party Support for Serial Communications

Technical GPS Development Using This Paradigm Discovered

Working Development and Test Method Discovered

Technical Team familiar With Development Paradigm

Sun and Java Unknown Only J2SDK 1.5, unusable on CDC

None No Yes

Microsoft VS2003

Yes No Yes, OpenNetCF Yes Yes Yes

Microsoft VS2005

Yes Yes Yes Yes No Yes

Symbian Unknown Unknown Unknown No No No Palm OS Unknown Unknown Yes Yes No No


24

Chapter 3

OVERVIEW OF THE EGUIDE PROTOTYPE

This chapter will describe the overall functionality of the eGuide prototype. The major functions which are performed by the proof of concept eGuide software are as follows:

Tour Guide

• presentation of tourism information

o tourist oriented information concerning the immediate area, and

o conservation and safety education material.

• selection of tour itinerary from a list of points of interest (POI)

• navigation to POIs

Integrate with Map/POI Management software

• The software can interact with another application which manages information concerning the track;

o this interaction consists of transferral of data from the store to the device operating the software.

• The Map/POI management software has a component whereby users responsible for managing the contained data may access the application remotely such as being able to access via the Internet from the user’s place of work.

eGuide Users It is assumed that there will be only three classes of user of this tour guide software:

• a bush walker on the track, who wishes to make use of a GPS enabled electronic tour guide (eGuide) to navigate to POI and to enhance their walking experience and safety requirements,

• a bush walker on the track, who wishes to make use of a GPS enabled electronic tour guide to enhance their walking experience and safety requirements but not for navigation, and

• a person or persons employed to manage the content of the server database and to modify the data content stored on the tour guide device prior to handover to the bush walker.

Scenario of eGuide Usage This section provides an example as to how the eGuide system will be used by a bushwalker on the Bibbulmun Track.

The eGuide will provide a tutorial or demonstration (user chooses none, one or both), which will instruct the user in the use of the software. After completing a tutorial or viewing a demonstration (if required), the user will be able to choose between a guided tour and an unguided tour. Unguided tours will take the form of wandering along the trail and either manually accessing Location Specific Information (LSI) or having it presented automatically. Users who choose the guided tour option will be able to browse POI in their immediate area and to choose an itinerary based on where members of the tour group wish to go or what they wish to see. The user must be able to switch between guided and unguided modes while walking on the track.

The itinerary will be able to be adjusted by the walker as they move along the track. For example, the user if they wish will be able to edit the itinerary and so change the content of the tour as it progresses. After the


25

itinerary is selected, the software will then display a graphical image and voice prompts which the user may interpret as their current location and directions to the next POI this information will contain an estimate of the time and distance to that POI.

As the bushwalker or tour group makes their way along the track, the software will provide audio visual content (enabled categories) informing them about such things as local flora and fauna and historical events that occurred close by. Advertising content may be presented to the user in a similar way.

If the bushwalker or tour group deviates from the preferred path then the software will be able to inform the tour group of this and guide them back to the preferred path, information about the deviation should include graphical and audio estimations of the:

• amount of deviation in metres; and

• estimated time required to regain the preferred route based on the groups average travel speed when moving.

If the tour group continues to remain off the preferred route then the software will be able to regularly update the best way to rejoin that route. If the user leaves the area detailed by the information contained within the software then the user will be informed and provided with audio and graphical directions back to that area.

In the event that the user enters an area that is recognised by the software as dangerous (bush fire risk, rock falls, ravines, quick sand, bull ant nests etc.) then the user must be informed of the nature of the danger and a course of action that may minimise that danger.

In the event of GPS failure, the user must be able to manually navigate using map images supplied by the software. All map view facilities are accompanied by zoom and map drag functions (map drag is analogous to viewing part of an image through a frame, the image can be moved around under the frame to enable viewing of the whole map, zoom is the ability to change the size of the image and so change the size of the area viewed and the amount of detail required).

A depiction of the how the eGuide is used is displayed in Figure 3. The eGuide can be used by a tourist user who can perform the following functions: Manage Itinerary, Conduct a Live Tour, an Adhoc Tour, Options, and Help.

Operating Environment The software can run on a GPS enabled portable computing device and will perform services normally supplied by a human tour guide. The tour guide software can operate on a GPS enabled mobile device running Windows Mobile 2005. The software can interact with Map/POI management software which manages information concerning the track; this interaction consists of transferral of data from the store to the device operating the software. This Map/POI management software has a component whereby users responsible for managing the contained data may access the application remotely such as access via the Internet from the user’s place of work. Further information on the Map/POI management software is found in Chapter 5.


26

Figure 3 eGuide Use Case Diagram

System Features The following section outlines in detail the features of the eGuide system. The section describes the functions that each eGuide feature and the interactions between the eGuide user (stimulus) and the response from the system.

Legal Disclaimer A splash screen is the first state that the software enters. This screen displays a legal disclaimer and two options; accept and decline. Users who are members of a tour group may access all functionality provided by the tour guide software once they have accepted the legal disclaimer. Before the user may execute any functionality presented by the tour guide software they must accept a legal disclaimer absolving members of the Bibbulmun Track Electronic Tour Guide Working Group and any organisation that they may work for of any legal obligation concerning use or misuse of the software. They may not access the database contained within the mobile device with any means other than the tour guide software. Additionally, they may not modify data within the mobile device or the associated server side applications.

Stimulus Response Accept disclaimer Display Main Graphical Interface Decline disclaimer Close Electronic Tour Guide Software


27

Main Graphical Interface The initial state is the graphical interface. Options are displayed for initiating the following sequences:

• Help =>demonstration, tutorial and textual help

• Manage itinerary

• Guided tour

• Ad hoc tour

• Software options

• Exit

Stimulus Response Help Display choice of textual, tutorial, or demonstration help. See

sections 4.3, 4.4 and 4.5 Manage itinerary Display itinerary list and these options:

Return to previous mode

Move POI up order of places to visit (not active when itinerary is empty or contains one entry)

Move POI down order of places to visit (not active when itinerary is empty or contains one entry)

Browse POI

Guided tour mode See below Ad-hoc tour mode See below Software Options See below

Help – User Demonstration A non interactive demonstration of the capabilities of the software User may initiate the demonstration and then stop it at any stage of the playback.

Stimulus Response User initiates demonstration mode

Software enters demonstration mode and shows an audio graphical representation of its capabilities then returns to its previous state.

Help – User Tutorial An interactive version of the software demonstration instructs the user on correct operation of the software.

Stimulus Response User initiates tutorial mode

Software enters tutorial mode and interactively guides the user through its capabilities then returns to its previous state.


28

LPS enabled tour guide (Using an Itinerary) The user can browse POI and select a subset to visit; the software can then guide the user too each POI in turn.

Stimulus Response Enter tour mode Obtain GPS data and display initial position graphically display

options to:

Exit tour mode,

Manage tour itinerary. Exit tour mode Software returns to initial state. Manage itinerary Display itinerary list and these options:

Return to tour mode,

Move POI up order of places to visit (not active when itinerary is empty or contains one entry),

Move POI down order of places to visit (not active when itinerary is empty or contains one entry),

Browse POI,

Delete POI (not active when itinerary is empty). Exit Manage itinerary If tour has not started

Calculate route to next POI

Present start instructions to user

Else

Replace tour instructions on screen (re-assert tour mode)

End if Move selected itinerary entry up order

If it is not the first entry then swap the entry with the one preceding it in order of POI to visit.

Move selected itinerary entry down order

If this is not the last entry then swap it with the one succeeding it in order of POI to visit.

Select itinerary entry Highlight the entry. Delete selected itinerary entry

Remove all selected entries from itinerary; if the current POI (the next one to visit) has been removed then select the first in the list as the current POI.

Browse POI Display a list of POI in order of distance along the track route starting with closest first. All entries that are already on the itinerary are highlighted and the first or next POI to visit is flashing.

Display a return option. Select/Deselect POI If the entry is not on the itinerary then

highlight it and (if enabled) present location specific


29

Stimulus Response information (LSI) concerning the POI

else

remove highlighting from entry

End if Discontinue POI browsing

Remove all entries from itinerary that are no longer selected in the list of POI. If a deleted POI is the current POI then select the first in the list that has not been visited as the current POI.

Add all selected entries in list of POI to itinerary and sort itinerary based on distance from present location.

Return to manage itinerary state. New GPS position data received (not a new packet with the same data)

Check that new position is on the preferred route.

If yes:

If the next POI has not been reached then update graphical representation of position, direction traveled and speed. Else, present any location specific data concerning POI, mark the POI as visited, then calculate directions to next POI and present.

Check for intersections with the preferred route 50 - 100 meters of the current position and in the direction of travel. If there are any and the user has not already been notified then audio graphically advise the user of distance to intersection and exit to take.

Check for intersections with the preferred route 20 - 50 meters of the current position and in the direction of travel. If there are any and the user has not already been notified then audio graphically advise the user of distance to intersection and exit to take.

Check for intersections with the preferred route within 20 meters of the current position and in the direction of travel. If there are any and the user has not already been notified then audio graphically advise the user of exit to take.

If this feature is enabled; check for location specific data (within 100 M and ahead) stored in the device and present it to the user. Includes tourist, ecological, conservation, and danger information

If no:

Sound alarm and audio graphically inform the user of the deviation,

Calculate direction back to preferred route, and

Present audio graphical information to guide the user back to the preferred route.

POI reached Mark POI as visited and calculate route to next POI GPS disabled or becomes unusable

Initiate or return to Ad hoc tour state


30

LBS enabled tour guide (without itinerary) The user can receive LSI when not following an itinerary. For example, some users will not want the restriction of a set tour; LBSs may still be presented to the user but in a limited fashion. Since no itinerary is used, every part of the track will be considered part of the route (off route warnings will still be presented if the user leaves the area of the track). Information concerning intersections with the track will still be presented in order that the user does not leave the track. LSI will be presented as the user enters the vicinity of noteworthy items.

Stimulus Response Enter tour mode Obtain GPS data and display initial position graphically

Display options to:

Exit tour mode,

Manage tour itinerary. Exit tour mode Software returns to initial state. New GPS position data received (not a new packet with the same data)

Check that new position is on the track.

If yes:

Check for intersections with the track 50–100 metres ahead of the current position. If there are any and the user has not already been notified then audio graphically advise the user of distance to intersection and exit to take in order to remain on the track.

Check for intersections with the track 20–50 metres ahead of the current position. If there are any and the user has not already been notified then audio graphically advise the user of distance to intersection and exit to take in order to remain on the track.

Check for intersections with the track within 20 metres of the current position and in the direction of travel. If there are any and the user has not already been notified then audio graphically advise the user of exit to take in order to remain on the track.

If this feature is enabled: check for location specific data (within 100 M and ahead) stored in the device and present it to the user. Includes tourist, ecological, conservation, and danger information

If no:

Sound alarm and audio graphically inform the user of the deviation from the track

Calculate direction back to the track

Present audio graphical information to guide the user back to the track.

GPS Disabled or becomes unusable

Initiate or return to Ad hoc tour state


31

Options This is a mechanism whereby the user can configure these items:

• sound levels • enable/disable the GPS • alter the radius of the circle which is the nearby area • choose categories of LSI to be presented by the software • choice of voices

Stimulus Response Enter Options dialogue Display volume control

Display list of LSI categories with mechanism for choosing or ignoring (perhaps advertising should be permanently enabled)

Alter sound volume Set device volume to user desired level Select/Deselect LSI category

Mark category as presentable or not

Enable/disable GPS GPS hardware is turned on or off Alter nearby Radius Alter size of circle to search for nearby POI/LSI within

Help The help system contains context aware information concerning the procedures for correct operation of the software. The user can access this help file from any state of the software. Information concerning the present state of the software can be presented to the user along with ability to browse other sections.

Stimulus Response User activates help utility Software opens a window containing context sensitive help

(similar to F1 functionality on a PC). The first information displayed relates to the last actions by the user. Mechanisms whereby the user can browse the rest of the help utility and exit that utility will also be available.

Close help The help window is removed from the display and the previous state is reasserted.

Browse help A list of topics is displayed so that the user may make a choice of topics to read.

Choose help topic Help information concerning the user’s choice of topic is displayed in the help window along with mechanisms whereby the user can browse the rest of the help utility and terminate the help session.

Ad-hoc Tour Mode The user may enter a mode whereby all LBS functionality is turned off, in this state the software acts like an electronic book. The user may browse POI and LSI in a similar fashion to printed material. In addition, if the user wishes to be guided to a specific point representing a POI or to an area associated with LSI then they may initiate guided tour mode from ad-hoc tour mode.


32

Stimulus Response User activates ad-hoc tour mode

Software opens a window containing a map of the immediate area and an option to browse nearby POI/LSI. The map will be draggable and zoomable

Browse POI/LSI A window is displayed containing nearby POI/LSI and options to return to the map and to initiate guided tour mode with the selected POI/LSI as the next destination.

Enable guided tour The GPS is turned on, the selected POI/LSI is added to the itinerary and guided tour mode is enabled.

Other Non-functional Requirements Other general requirements have been considered as important in the development of the eGuide system. These relate to the following categories:

• Performance • Safety • Security • Software Quality

Performance The following performance requirements exist for the eGuide system:

• User requires timely computation of position and route information; information must be provided fast enough so that the tour group does not have to pause the tour while the software is catching up;

• User requires LSI before or as they are reaching the relevant location. The tour group should be presented with LSI before they pass the relevant location so that they may anticipate and observe the subject of the information;

• Device batteries must last for the duration of the walk, and • Device display must be visible in sunlight.

Safety The following safety and reliability issues have been addressed for software:

• the device running the tour guide software will be battery powered and subject to power failure due to flat batteries. Existing hardcopy should still be carried by the tour group

• GPS data may not always be available due to dense tree canopy or severe weather conditions; users must be able to use the software to navigate manually (as a paper map).

Any walker on the track who makes use of this software should also carry the alternative paper based guide material and any emergency location equipment that is currently available.

Security Location specific data used by the software will belong to an organisation (DEC WA and the BTF). This data must be stored on the device in such a way that it can not be extracted and reused for other purposes.


33

Software Quality The software produced as the eGuide is:

• Customisable—The software can be used at different locations and for different tours (different sections of the track, different tourist routes such as the golden pipeline)

• Scaleable—the software can exhibit improved performance when migrated to more powerful hardware. • Maintainable—information contained within the device can be updated to reflect the latest known

conditions in the area covered by the eGuide. As different parts of the system change due to introduction of new technologies or usage guidelines (such as changing laws) the other parts of the system must not be adversely affected.

• Portable—any software developed as part of the eGuide system can run on different devices and under different device operating systems with no change in functionality.

• Easy to use—the user must be able to learn to operate the device quickly; navigation through the various states of the software should happen in an intuitive way. Interface design should follow a common theme such as that used for windowing in order that the user (if familiar with windowing) will recognise the method and be already familiar with techniques required.

User Documentation • The software is delivered with four documentation components including: • Demonstration—an audio visual experience which demonstrates all of the capabilities of the software. • Tutorial—similar to the demonstration mode, the major difference is that the tutorial is interactive and

requires input from the user while the demonstration requires only observation. • xhtml help files—at every state of the eGuide software, the user can access context sensitive help

available in a separate window. • Hard copy—documentation components one, two and three are soft copy or application components.

The software will be accompanied by a booklet containing instructions on the use of the hardware platform and paper versions of components one, two and three along with current pamphlets and safety equipment.


34

Chapter 4

EGUIDE DESIGN AND IMPLEMENTATION

The eGuide software was designed to be deployed on a GPS enabled mobile device (PDA or mobile phone). The overall architecture of the eGuide system is displayed in Figure 4. The software is designed to store Point-of-interest (POI) and Location Specific Information (LSI). This software can be deployed from a Map/POI Management System (ePortal) via a Server Data Store. The software is designed using a service oriented architecture software component approach to facilitate flexibility for use on different mobile devices. This is shown in Figure 5, where depending on whether the software is deployed in a GPS or cellular network environment, the software can be deployed using different location and user interface components.

Figure 4 eGuide Software Architecture

Figure 5 eGuide Software component design


35

The eGuide software application is designed to be used in a variety of states. A depiction of the states of the eGuide system is shown in Figure 6. These modes correspond to the user interfaces displayed to the user. These modes include the following:

• Initial state • Help mode (demonstration, tutorial and textual help) • Manage itinerary mode • Guided tour mode • Ad hoc tour mode • Software options mode • Exit mode

Figure 6 State Diagram of eGuide System


36

eGuide Interface Design The eGuide system will interact with the user via graphic user interface and audio interface.

Graphic User Interface The Graphic user interface (GUI) to be used in the eGuide system is presented in Figure 7.

Disclaimer splash screen After starting the software the user sees a splash screen asking them to read and accept a legal disclaimer. They must choose the accept option before they may access any functionality offered by the tour guide software. Choosing the decline option will result in the software closing.

Main frame This will be the first graphical component that the user sees after starting the software and accepting the disclaimer. It consists of a full screen frame with a background image and buttons to navigate to help, software options and tour interfaces. Another option to exit the software will also be displayed.

Help Frame This frame is displayed when the user selects the help option in the main frame. Buttons allow for the navigation to a tutorial frame; software demonstration frame; textual help files; and back to previous frame.

Tutorial Frame This frame is accessible from the help frame and provides an interactive audiovisual to familiarise the user with the software.

Demonstration Frame This frame is accessible from the help frame and is a non-interactive audio graphical means of familiarising the user with the software.

Textual Help Frame Textual help can be accessed from any state of the program; and consists of an index of subjects and topic area along with a search function.

Options Frame When the user wishes to change settings which affect the behavior of the software they can navigate to the options frame from the main frame. Controls are be displayed which allow the user to manipulate sound levels, voice types (male/female) and the content types presented in LSI. In addition, the user can customise the area size which triggers inclusion of a POI in the nearby list and enable or disable the GPS.

Guided Tour Frame This frame is where all tour related information is presented to the user. Information presented includes:

• a representation of the user’s current position, speed, direction and whether they are on or off the preferred route;

• an indication of the distance to the next intersection and the exit they will take; and • the next POI to visit and the distance and time remaining.

The user can navigate to textual help and itinerary management frames from the tour frame. In addition, when the software detects that the user is approaching an area that is associated with enabled LSI or a POI that is on the itinerary then the software will present relevant LSI. At any time the user must be able to disable guided tour mode and enter the ad hoc tour mode.


37

Itinerary Management Frame The user can use options on this frame to create and manage an itinerary. A list of POI (the itinerary, which may be empty) is displayed along with buttons to move itinerary entries up or down and to delete them. Other buttons include options for browsing a complete list of POI relevant to the area of the walk and to return to the tour frame.

Browse POI Frame The user can navigate to this frame from the tour frame in order to add POI to the itinerary. A list of POI relevant to the area of the walk is displayed. All POI already on the itinerary can be highlighted; the user is able to select or deselect POI and hence modify the itinerary. A button that returns the software to the tour state is also be displayed.

Ad Hoc Tour Frame In addition to guided tour functionality there is a mode whereby the user may use the software as an electronic guide book—GPS navigation functionality will be disabled. The tour group can progress along the track in their own fashion while browsing the database of POI and LSI. If the user wishes to be guided to a specific location then they may enable the GPS and enter guided tour mode.


38

Figure 7 Gui Navigation Diagram for eGuide

Audio Interface As any visual information will be rendered hard to see when sunlight falls on the display of the mobile device running the tour guide software, all graphical information can be accompanied by an audio commentary.


39

Provision of audio commentary will allow a much bigger tour group to access LSI and hence gain more enjoyment from the tour guide experience.

Communications Interfaces The device running the tour guide software will connect to the Mao/POI data store to enable the modification of location specific data stored within the device and accessed by the software. Any commonly available communications standard will suffice; options are USB, RS232, Bluetooth, WiFi, and infrared. Removable media such as SD or MMC may be used to facilitate this exchange. Connections using the Internet or otherwise public information domains will make use of encryption algorithms to safeguard possibly sensitive data. The eGuide software interacts with the user via screens and audio interface. An example of some eGuide GUI interfaces is shown in Figure 8.

a) Main Menu b) Tour Itinerary

c) Options d) Tour

Figure 8 eGuide Screen shots


40

Design and Implementation Constraints It is expected that that the target device for the tour guide software should provide the following features:

Integrated GPS hardware The device must use integrated GPS hardware with the minimum specifications:

• twelve channel GPS receiver • location accuracy of less than 10 meters 90% of the time • be able to detect movement at 0.1 MS-1 or greater • 64 MB of reprogrammable memory for program storage • integrate removable storage media such as a Secure Digital (SD) card or Multimedia Memory Card

(MMC) for data storage • integrated rechargeable battery that may operate the software and the GPS hardware for a minimum

of eight hours.

Adequate Battery Power System It is expected that an additional battery pack might be attached to the back of the target PDA in order to extend battery life without violating device weight constraints. Another method of supplying power to the tour guide device would be operation of a hand cranked device to supply electricity to the device in order to recharge the integrated battery. The device should weigh less than one kilogram so that it is small and lightweight enough to be carried while bush walking.

Integrated Hardware for Communication Integrated hardware that enables communication with another device or system is required. Most PDAs support USB and infra red communications as a minimum; other technologies such as wireless LAN and cell phone may be present on high end PDA devices.

The PDA should have the following minimum specifications in relation to communication hardware:

• have audio output with the following minimum specifications such as mono audio output or external headphone jack

• be able to play .wav and .mp3 format audio files • be able to recognize and react to input from the user, a minimum of a touch sensitive screen is

permitted, other functions such as buttons and toggles should be supported

Adequate User Display The device must use a display large enough to display interpretable graphical information; the display will have the following minimum specifications;

• 35 mm x 41 mm viewing area, • 320 x 240 pixel resolution, • support more than 50,000 colours, and • be able to support windowing and display of xhtml files, video clips and still images.

Colour schemes employed by the software shall be harmonious but distinctive. The use of red, orange and yellow shall be minimised in order to relieve colour blindness problems.

Software Development Environment It is expected that the following development environment constraints will exist:

• C# has been chosen as the development language for the tour guide. • Compact Framework 1.0 is the environment that will be used to develop the tour guide software.


41

Implementation of eGuide Functionality The following features have been successfully implemented in the first iteration of the eGuide Prototype software:

Navigation

Static Map Usage The Ad-hoc tour mode (no automated navigation) functionality is complete and allows the user to use a map in similar fashion to paper map (map may be dragged around on the screen in order to view other parts; map may also be zoomed in or out.

GPS positioning A number of features have been implemented to allow for GPS positioning of the eGuide user. The GPS locationing and manual GPS setup is working on most test devices, implemented, tracking of present position and independent navigation facility implemented.

The eGuide will ensure that the user stays on designated track. This is achieved by the eGuide checking and recording the track against user’s current position. If the user strays from the track then an audio visual alarm and visual directions back to track are provided. The eGuide also provides direction assistance to the user where the trail branches. For example, when the user approaches a fork or crossing in the trail provide audio visual prompts as to the proper fork or branch to travel.

Accuracy of Positioning The eGuide software provides a means to filter position data based on accuracy. Any position data received from the GPS hardware is filtered based on accuracy before being used to display geographic position. At present the acceptable accuracy of supplied data has been hard coded to approximately plus or minus 30 metres. If the GPS hardware loses its position fix, the user is notified and all position indication by the eGuide software ceases until a new, more accurate fix is received

Notification of Position The notification of proximity to enabled point-of-interest can be configured; enable/disable and notification distance. The mechanism for notification of available LSI is available. This allows a user to choose from movies, text, audio or slideshow concerning POI when they are close to that POI.

Content Delivery A number of features have been implemented to deliver rich media content to users of the eGuide. These features allow for rendering of maps and media content on the screen, selection of location specific information, provide user help functionality and alternative delivery of content via voice simulation.

Rendering of Maps and Media Content The delivery of map content through the use of vector graphics was attempted with limited success. The compact framework development environment was found to have very limited support for vector graphics. At current, no existing formats are supported for vector graphics rendering. Consequently, Scaleable Vector Graphics (SVG) was chosen. A custom SVG parser was developed specifically for the eGuide software as it was not included in the compact framework development environment. Testing of the eGuide using the SVG parser resulted in a number of issues relating to poor performance. The execution speed of new parser is was very slow, with one frame being rendered every three to four minutes. The reasons for these problems were identified to be related to the computing power needed to parse and render SVG drawings being considerably high. Another contributing factor was that the features on sample maps supplied by DEC are dense and data intensive. Similar problems were encountered when the map was rendered on a desktop machine, with the process taking several seconds to render this map using state of the art parsers supplied by ADOBE.


42

As a result of the difficulties faced with the use of Vector Graphics the implementation of the rendering of maps and images was refocused towards the use of the alternative raster drawing (bitmaps). This was found to be successful in terms of the faster speed in rendering maps and the smaller resource utilisation.

Selection of Location Specific Information The selection of individual location specific information categories by the eGuide user allows users to view customised information on the map. In addition, users are able to browse a variety of media including audio, pictures and movies.

Help Mode–Demonstration The eGuide software also provides help functionality in the form of a demonstration tutorial, which is accessible from the help form. Textual help functionality is also available to the user. User help functionality is accessible from all user interfaces.

Delivery via Voice Simulation The delivery of an audio interface has been implemented. eGuide provides a mechanism to choose voice types, however only one voice type is available in the first iteration of prototype. An examination was made of alternative voice simulation technologies. A number of Speech APIs are available for developing audio interfaces for mobile devices. However, these third party implementations are costly.

Customisation of User Interfaces In order to develop a customisable solution for the eGuide prototype, a number of alternative user interfaces were designed. These were developed in order to showcase the different themes that could be user could have to personalise the application. A basic GUI design was used for early prototyping (Figure 9). Further work was carried out to improve the GUI consistency and design. Customisation was based on different themes, resolutions and usability in varying light conditions.


43

Figure 9 The original basic GUI interface

The need to provide for a level of user customisation of the GUI has been examined. This customisation will allow users to personalise the application. Three versions of the user interface have been developed. A lightweight version has been produced based on the original basic GUI concept (Figure 10). It can be used on older devices with minimal resources for graphics. The second version is comparable with the first and includes a different colour scheme to improve visibility in different light conditions. The third version is a heavy version and uses more graphics. This version is aimed at devices released with greater than 64MB of RAM, and has a number of customised icons. Users will be able to alter the colour themes, font type and size, the voice output and volume (Figure 11).


44

Figure 10 Alternative GUI Interface design for eGuide


45

Figure 11 Alternative GUI Interface design for eGuide


46

1Figure 12 Generalised view of the ePortal system Error! Bookmark not defined.


47

Resource Utilisation An examination was made to assess ways to improve resource utilisation by the eGuide. This issue was considered to be important in determining the usability of the eGuide application in remote bushwalking trail situations, where recharging of the device may be difficult. Improvement in the use of resources could be made by addressing the following; improving program execution speed, rendering images based on screen size; customising GUI themes based on available RAM; and improving the initiation of components.

One of the benefits of the .NET Framework is the straightforward ability to determine what is available to the application. A determination of the screen area of a particular device (smart phones and PDA) can be used to cater for different form factors and image sizes. The screen sizes most commonly found in current devices are 240 x 320, 240 x 240 & 480 x 640. As the screen real estate changes, we can dynamically change the size and positioning of the on-screen components. Other issues that could be considered in later prototypes are the use of theming or skinning of the application. For example, the eGuide application could be defaulted to show high contrast themes depending on resources on the device.

Additional Implemented Functionality of eGuide Software Further development of the eGuide system will be necessary in order to develop it for commercial release. The following section outlines the additional functionality that needs to be implemented in order to improve on the first iteration of the eGuide system. The following functionality needs to be included in the next iteration of the eGuide prototype.

Navigation • Implementation of automated navigation facility • Implement automated GPS setup • Automated navigation mode is not implemented, functionality to provide list of waypoints to

navigate to is not implemented • When user leaves designated route an audio visual alarm is given along with directions back to

allowed route

Content Delivery • Incorporate vector based graphics to remove pixellation effects when zooming • Collation and inclusion of tourist data • Compose and include disclaimer notice • Compose and include splash screen • Alter the appearance of all forms to incorporate a common look and feel • Mechanism to browse POI and LSI has not been implemented. • Provided location specific info is for test purposes only and provides an indication of intended

functionality

Voice Simulation • Record and include two voice sets for audio interface

Integration with ePortal • Integrate mobile agent and Information server functionality


48

Resource Utilisation • Some parts of prototype run slowly (e.g. options and tour forms takes too long to open)

Security • Encryption of files stored on mobile device • No mechanism for safe guarding data is present in the first iteration of prototype, emphasis has been

on achieving desired functionality • As such, all data is available in accessible formats such as text files or .jpg images • Future iterations will address the need to protect the copyright owner’s property from being copied • Possible protection methods include encryption and storage of data in data bases which do not

provide click and view functionality


49

Chapter 5

EPORTAL DESIGN AND IMPLEMENTATION

The administration and management of map and POI data for the eGuide system is considered to be an important factor in the feasibility of the system. A prototype ePortal system has been developed which will manage the delivery of the eGuide software. This system provides an easier method for managing maps and track data in central area, accessible over the network. Figure 12 displays a generalised view of the system design.

Figure 12 Generalised view of the ePortal system

ePortal Functionality The ePortal prototype software is a secure client server application which can be accessed via the Internet. It provides the facilities to manage maps, POI and LSI and exporting of tours. The ePortal is designed to allow users to manage the selection of maps and points of interest information. The ePortal software provides a means to manage the rich media content associated with each point-of-interest. Figure 13 shows a series of screen shots from the first iteration of the ePortal prototype.


50

Map Selection b) Map Display

c) View Point-of-interest d) Add Point-of-interest

e) add Multimedia/ Audio Files

f) Add Tour Itinerary

Figure 13 Screen shots of ePortal Prototype


51

ePortal Users There are three classes of users in the ePortal system:

• Admin—Those that can perform user management, and map management, view all information, and download data to removable media;

• Editor—Those that can perform map management, view all information except user details, and download data to removable media; and

• Viewer—Those that can view only map related information, and download data to removable media.

ePortal Functionality The ePortal software was designed as an auxiliary system to facilitate the management of the maps and point-of-interest data. The ePortal system is designed to manage map and point-of-interest data and provide a data retrieval point of sale application for the eGuide software. The system can remotely access data stored on the database, modify maps, and export the data to removable media as needed. The system also includes a simple security sub-system to protect unwanted disclosure of the data. Figure 14 displays the use case diagram for the ePortal system.

General Functionality The ePortal system is designed to have the following general functionality:

• Access is protected by security logon (username and password). • It has a user friendly user interface that is clear, well designed, help enabled robust and well

presented. • The system should facilitate access of the data from a remote location. • The system should be tested to ensure that it works to specifications. • The application should contextual help, or additional documentation. • The system should have the facilities to manage the users of the system; including adding and

deleting and editing users.

The ePortal system will contain the following general data store features:

• The data is protected from undesired external access. • The data is accessible from external locations for authenticated users. • The system stores the related map data. • The system stores the related point-of-interest data. • The system stores the related multimedia data. • The system stores the related user management data.


52

Figure 14 ePortal Use Case Diagram

Data Management The software should have the following features to manage maps, point-of-interest categories, location specific information and preview and exporting of data.

Maps and Point-of-interest Categories The software must allow the user to manage map and points of interest categories. Users should be able to:

• select available maps and add and delete maps • select and edit categories of interest and add and delete categories • associate an icon with a category • manage POI / LSI on selected map (add, delete, edit) • manage media information (add, delete, select, copy) and associate this media.

Preview and Export The system is designed to provide a means to access data from a remote location. The user will be able perform the following functions:


53

• view the available maps • select from the categories for a map • select from the points-of-interest for a map • export the associated data for a map.

ePortal Architecture The application was written in C# on the .NET platform. The architecture of the application was developed in layers to provide abstraction, and therefore improve ease of maintenance. An outline of the details of the design is available in Appendix C. The design is divided into three main areas:

• Data Access Layer—classes required for interfacing between the application and external data sources • Model—classes that encapsulate the data of the real-world entities • User Interface—classes required to act upon the actions of the user, and present a view of the

underlying data model to the user.

ePortal Security

Database The application uses the root user to store and retrieve data. The user details and password are stored in the settings of the application. This should be further refined to use a non-root database user, restricted to insert, select, update and delete for the relevant data tables, and execute for the relevant stored procedures only. All access to the database uses the same user.

Application Security The application utilises a simple role based security system. Users exist in the User table. A user uses a password and user name to authenticate, comparing the supplied details to those stored on the database. This should be improved to hash the password stored in the database, or ideally, utilising integrated Windows security instead. This could then use Active Directory groups for security.

Users belong to one of the following roles:

• ADMIN—can make changes to the maps, export data, and change user details within the system; • USER—can only export data; and • EDITOR—can make changes to the maps, and export data, but cannot modify user details.


54

Database design The MySQL 5.0 database was used for the data management. Figure 15 displays the database design.

user

PK user_id INTEGER

user_name VARCHAR(20) user_password VARCHAR(20) user_display_name VARCHAR(50) user_role VARCHAR(20) user_disabled TINYINT

movie

PK movie_id INTEGER

movie_name VARCHAR(50) movie_data VARBINARY(0)

poi

PK poi_id INTEGER

FK3 map_id INTEGERFK2 cat_id INTEGER poi_latitude VARCHAR(20) poi_longitude VARCHAR(20) poi_announcement VARCHAR(50)FK1 audio_id INTEGERFK4 movie_id INTEGERFK5 slideshow_id INTEGERFK6 text_id INTEGER

audio

PK audio_id INTEGER

audio_name VARCHAR(50) audio_data VARBINARY(0)

category

PK cat_id INTEGER

cat_name VARCHAR(50) cat_icon_name VARCHAR(50) cat_icon_data VARBINARY(0)

slideshow

PK slideshow_id INTEGER

slideshow_name VARCHAR(50)

image

PK image_id INTEGER

image_name VARCHAR(50) image_data VARBINARY(0)

slideshow_image

PK,FK2 slideshow_id INTEGERPK,FK1 image_id INTEGER

order_rank INTEGER

map

PK map_id INTEGER

map_name VARCHAR(50) map_data VARBINARY(0) map_width INTEGER map_height INTEGER map_x_scale VARCHAR(20) map_y_scale VARCHAR(20) map_top_left_latitude VARCHAR(20) map_top_left_longitude VARCHAR(20) map_under_construction TINYINT

text

PK text_id INTEGER

text_name VARCHAR(50) text_data VARBINARY(0)

Figure 15 Database Design for the ePortal System

ePortal Implementation This section displays details on the implementation of the prototype ePortal system. It provides screen shots of the ePortal system and description of how it can be used with the eGuide system.

Scenario of ePortal Usage ePortal is an application designed to simplify the management of map-related information for the eGuide project. This section provides a guide to how the usage of the ePortal system. It is assumed that the user is familiar with the concepts involved in the eGuide project, including the concept of maps and multimedia as a basis for an electronic tour guide.

Log in

After starting the application, you will be presented with a dialog box to enter your user name and password. Enter your user name and password and click ‘Logon’ to proceed.


55

Map Editing a) Load a map

To load a map for editing, select the ‘Map’ tab—this will show the editing screen for maps. Click on the map drop-down box and a listing of the maps will be shown. Then click on the load button to retrieve the map.

b) Add a map

To add a map, enter the details of the map in the bottom left, ensuring that a map image is also loaded for the new map. When all details are entered, click the Add button.


56

c) Updating a map

To edit details for a map, firstly, select and load the map to edit. Change the details as required and then click on the update button.

d) Delete a map

A map can be deleted but first it must be selected and loaded. Then by clicking the delete button and confirming that you wish to delete, you will have deleted the map.


57

e) Display a point-of-interest

The points-of-interest will appear in a grid on the right hand side when the map is loaded. Simply click on any part of the line and the details will be display on the area to the bottom.

f) Adding a point-of-interest

To add a point-of-interest, type in the details at the bottom section and click add.

g) Add multimedia to a point-of-interest


58

To add multimedia, click on one of the add buttons to the right. A small window will appear. You can select the item from the window, or you can click the ‘Add file to list’ button to retrieve a file from disk. Clicking ‘OK’ will add the item to the point-of-interest.

h) Deleting a point-of-interest

A point-of-interest is deleting by first selecting the point-of-interest, then by clicking on the delete button.

i) Updating a point-of-interest

Similarly a point-of-interest can be edited. Select the point-of-interest and update the details. Click the update button to save the changes.

j) Editing a category

Select a point-of-interest, and then select the edit button at the lower part of the screen. This starts a window to edit categories. The category name can be edited, and by clicking the ‘Add Icon’ button, a new bitmap can be associated to the category. The ‘OK’ button finalizes the change.

k) Add a new category

Similarly a new category can be created. Firstly the user must select the “<new category>” entry within the category drop-down box. The ‘Edit’ button changes to the ‘Add’ button, and if clicked it will show the window to create a new category.


59

Exporting a) Exporting data

To export data, firstly the ‘Export’ tab must be selected. Then select a map and click ‘Load’ to load the details. A hierarchical listing of categories with the child points-of-interests will appear. The desired categories and points-of-interest should be selected. Please note that a group of points-of-interest can be selected by selecting the parent category item.

Then by clicking on the ‘Export to disk’ button, a folder browser window will appear. Simply select the destination drive or folder and click ‘OK’ to commence the export.


60

User Management a) Displaying user details

Firstly, select the ‘Users’ tab to display a list of the users in the system. Select the desired user and the details will appear to the right.

b) Adding a user

To add a user, enter the details in the relevant area and click ‘Add’.


61

c) Updating a user

To update a user, the user must first be selected. The details can then be changed on the right. To finalize the changes, select the ‘Update’ button.

Future ePortal Iterations The next iteration of the ePortal will provide a full screen preview of a selected map with points of interests appearing on the map and have the ability to add, change, and remove users from the system.


62

Chapter 6

STRATEGIC PLANNING FOR EGUIDE SYSTEM

This section investigates the possible business structures that could be applied to ensure the continuity of the service and financial sustainability of the eGuide System. The issue of the intellectual property of the source code is considered outside the scope of this study. It is envisaged that the intellectual property will become the property of industry partners who contribute financially to the development of the product.

The following have been identified as important issues in determining a business setup:

• need to ensure the current revenue of the Bibbulmun Track Foundation is not negatively affected by the eGuide software

• profit capacity and financial sustainability • legal security /information and physical security • ease of administration • responsibility of maintaining the service • how the service is provided to users (the product package) • associated costs • access to information • The role the industry partners can/have play in the development of the service

Alternative eGuide System Management There are a number of options available in terms of how the eGuide system could be commercialisable.

• Option 1: setting up a new external entity to administer the service • Option 2: the Bibbulmun Track Foundation administers the service • Option 3: DEC or WA Sports and Recreation administers the service • Option 4: the University administers the service • Option 5: a combination of the above


63

Option 1: New External Entity The first option is to set up a new external entity separate from the university, the Government agencies and the BTF. This entity would be setup as a company or incorporated organization and will have the sole purpose of administering the service. People wanting to use the service would deal with this entity.

Pros Cons • isolates possible financial risks • may provide returns to external stake

holders • ease of raising capital • structure can be constructed to suite

business requirements

• jeopardize the Bibbulmun Track Foundation’s revenue

• setup costs in money and personnel • no community support network • unknown brand • low access to information and data • high maintenance cost • returns not reinvested into the

Bibbulmun track • requirement of breaking even may

increase costs for users • tax implications

Option 2: Bibbulmun Track Foundation The second option is for the BTF to administer the service as an extension to their current operations. They would maintain the service and receive revenue it produces.

Pros Cons • structure already set up • large community support network • already maintain track information

services (in the best position to maintain track data)

• high access to information and data • aware of the larger working environment

and focus • brand power (people know about the

foundation and already contact them when going on walks)

• personal motivated focused on the Bibbulmun track and its preservation

• possible returns would all be invested back into the Bibbulmun track

• limited financial capabilities • possible Financial risk could impend on

current services • possible limited IT expertise • possible small changes required to

internal structure


64

Option 3: DEC or WA Sports and Recreation The third option is for a government department to administer the service as an extension to their current operations. This may be done by the department of Sport and Recreation or CALM for example.

Pros Cons • large personal base • large capital and funding base • ability to provide the service at a

subsidised cost (no requirement to breakeven)

• associated expertise and support • best position if any litigation was to arise • high access to information and data

• jeopardize the Bibbulmun Track Foundation’s revenue

• public service administration considerations

• previous established agendas and goals • possible small changes required to

internal structure

Option 4: ECU University The forth option is for the university to administer the service. Student from different faculties within the university could carry this out with the assistance of full time staff.

Pros Cons • free student labour • provides good experience for students

studying in a variety of disciplines • high access to information and data • low maintenance costs

• jeopardises the Bibbulmun Track Foundation’s revenue

• lack of continuity from year to year (as students graduate)

• continuity of the service throughout the year (as students go on holiday)

• higher risk of mistakes • lack of financial resources • requirement of breaking even may

increase costs for users (unless funding can be received)

• possible small changes required to internal structure


65

Option 5: Combination In this fifth option a combination of the above options could be used. A possible combination could be a joint venture (jointly controlled operation) between the BTF and a government department. In this option the contract between the two parties can define their relationship so as to complement the positives of each entities structure and circumstance.

Pros Cons • increased financial capacity • reduction of financial risk to any one

organisation • no jeopardy of the Bibbulmun Track

Foundation’s revenue • wider personal and skill base • larger access to information and data • still include large community

participation • still be aware of the larger working

environment and focus • keep brand power (people know about

the Foundation and already contact them when going on walks)

• access to people with a personal motivated focused on the Bibbulmun track and its preservation

• possible returns could still be invested back into the Bibbulmun track

• utilisation of current infrastructure and assets form both entities

• Infrastructure maintenance responsibilities can be shared and delegated to the most suitable entity

• internal structure of each party may need to undergo small changes

• set up costs and time • negotiation hindrances • financial reporting considerations

The last option is considered to be the most attractive. It provides the larges number of positives with the least number of negatives. However it relies on the successful negation of a contract between the parties. In all business structures it is likely that ECU will maintain some ownership of the intellectual properties and some control over the product deployment and use. Further details of this are outside the scope of this document.

Product Packaging Some consideration has been made to how the eGuide service product can be packaged for users. The following alternative ideas have been considered:

• Idea I: provide a GPS enabled mobile device for hire that has the service program and data installed. Also other accessories (spare batteries etc.) can be available for hire.

• Idea II: provide the service program and data on the Internet which people can down load for a fee onto their own mobile device.

• Idea III: provide the service program and data on a flash memory card which people can purchase or hire to be used with their own mobile device

• Idea IV: provide a combination of options: hiring of the mobile device and/or the service program and data on a flash memory card.


66

Idea II requires the least amount of capital outlay as no hardware needs to be purchased and no insurance of devices being hired is required. This idea however restricts who can use the service, as they need to purchase the hardware outright. It also poses problems of software piracy, website security and a lack of control over product quality and reliability.

Idea III is also cheap with regards to capital outlay and insurance, with the only requirement being the purchase of the memory cards. This idea as with idea II, restricts who can use the service to users who own a GPS enabled mobile device. It does have an advantage of having the program only on the memory disk, which reduces the risk or piracy (it does not eliminate the risk).

Both ideas II and III would pose problems to users with regard to the compatibility of mobile devices. That is, the service program may only run properly on a small number of devices. Also the installation of the program into the device may be problematic for inexperienced users reducing quality and reliability.

Idea I and idea IV product packaging ideas require the most capital outlay but provide the user with superior product and flexibility. It also requires an insurance outlay on the devices being hired out. If industry partners can assist in the capital outlay for the devices and memory card idea IV should prove the best with regards product quality and reliability. It also could enable product flexibility by providing the options of users hiring a mobile device or alternatively using a memory disk.

Additional accessories may also be hired to provide greater revenue, flexibility, quality and reliability. It must be noted that the service should be provided and encouraged as a supplement to existing products (like paper maps and guide books).

Customisation of Products and Services The eGuide system has been developed to allow for customisation for different users and adventure tourism trails. The system could be delivered with different subsets of information to cater for user preference. For example birdwatchers may wish to only have information related to birds known to be present in the geographical area. Different subsets of information could be priced accordingly. For example, those wishing to have auditory functionality may need to pay more for a particular module.

Partnerships and Contractual Arrangements It is recommended that a formal partnership be established between WA Departments of SR and/or DEC and the BTF, Sustainable Tourism CRC and ECU in order to continue with the commercialisation of the eGuide system. This setup provides the largest flexibility and ability to reduce costs most importantly in the area of maintenance. It also allows for greater capital and financial resource, utilisation of current infrastructure and a complement of the positives of each entities structure and circumstance. It is recommended product package idea IV provide a combination of the hiring of a mobile device and/or the service program and data on a flash memory card with the option of additional accessories. This combined with the recommended business structure will provide a flexible, reliable and quality product with the greatest revenue earning capacity in addition to security over the intellectual properties of the system. It has been noted that the service should be provided and encouraged as a supplement to existing products and not totally relied upon.


67

APPENDIX A: NETWORK COVERAGE

3 Network Coverage maps


68

Optus GSM Coverage maps Accessed 11 February 2008 from 1http://www.optus.com


69


70

Optus Satellite Coverage Maps Accessed 11 February 2008 from 1http://www.optus.com


71

Accessed 26 August 2005

Telstra Coverage maps Accessed 11 February 2008 1www.telstra.com.au


72


73


74

APPENDIX B: MOBILE DEVICES

The following investigates a small selection of device options that are available as solutions. The devices are grouped buy PDA with GPS support, PDA only and independent GPA and PDA devices. The last two groups can be combined to create the desired solution.

PDA with GPS Support The devices looked upon here are Personal Digital Assistants that support the Global Positioning System. The major advantage of this type of product is that it has mostly all the functions that we need built in and leaving the slots for use of extra memory storage. When choosing the ideal device, I have looked at three major products available in Australia, please note new devices are brought into the market on a regular basis, when ready to purchase a similar device please look at its specifications and cost of product.

ACER N35 Mio 168 Plus Garmin iQ3600

PDA only The devices that have been analysed here carry only the Personal Digital Assistant. These devices mentioned below don’t support any form of communication as such i.e. GPS, GPRS or CDMA. The main purpose of looking at these devices is that they can accommodate external GPS receivers via the empty slot but as soon as that slot is used up, we are left with the inbuilt memory to play around it. Future expansions of memory storage or increasing the memory are not applicable.


75

Independent GPS and PDA Devices Having a personal digital assistant with no GPS capabilities connected to a GPS device can be a very cheap and reliable solution. Bluetooth GPS devices are as cheap as $300. This solution has a major advantage of two power supplies, one for each device. Though the concept is cheap and can be a good solution, it does have its drawback.

The major drawback is having the user to carry two devices and the major advantage is that the two devices have their own independent battery sources giving more work time between the devices. It can be a cheap solution but the users need to be willing to carry two devices with them along the walk. Alternatively you can have External SD and Compact Flash Cards installed on the PDA device however this has a major draw back as it uses the one and only power source from the PDA. This suggestion can have less clutter when it comes to handling of the device.


76

CDMA Mobile Phone Pros

• reasonably inexpensive ($300 - $400) • compact • Robust • Communications capability

Cons

• not reliable in remote areas for position fixing. • small screen • battery life only a few hours • recharging access

PDA with Bluetooth GPS Pros

• each unit has its own battery supply—not relying on one battery for both devices

• each device uses Bluetooth to communicate—no physical connection

• Bluetooth Wi-Fi for up and down loading data—no cradle required

• robust • battery life—up to 12 hours for PDA and 8 hours for GPS • rechargeable

1

11

Cons

• initial capital cost ($1500 per set including added extras) see quote

• two devices could be miss-placed as they are not physically connected

• required Wi-Fi on both PDA and base units for uploading data • recharging access

http://www.amazon.com/gp/product/images/B0002DV9DC/ref=dp_product-image-only_0/002-5000816-0672806?%5Fencoding=UTF8&n=172282&s=electronics�


77

PDA and Flash GPS Pros

• suit any PDA with a flash slot • flash GPS reasonably inexpensive ($200)

1 Cons

• PDA battery powers both devices – reduced battery life • memory expansion for PDA not possible as flash slot is

used for GPS device • not robust if dropped, GPS easily broken • not all PDA’s have Bluetooth—require appropriate

connectivity to upload data • recharging access

PDA non BlueTooth GPS Pros

• available for most PDA’s • compact, all-in-one. • very robust

Cons

• shares PDA battery power —? battery life • cradle reasonably expensive ($500) • cradle can only used with same model PDA • recharging access

http://cgi.ebay.com.au/ws/eBayISAPI.dll?ViewItem&category=34290&item=5764078117&rd=1�


78

PDA with Flash RFID reader

1

Pros

• suits any PDA with a flash slot • RFID reader reasonably inexpensive • RFID tags are inexpensive e.g. $0.20 (tags used at

specified locations as ID).

Cons

• initial capital cost ($1100 - $1200 per set) • PDA battery powers both devices—reduced battery

life • memory expansion for PDA not possible as flash slot

is used for GPS device • nt robust if dropped, RFID reader easily broken. • not all PDA’s have Bluetooth—require appropriate

connectivity to upload data.

NAVMAN

Pros

• all-in-one unit • robust • memory expandable by flash card

Cons

• initial capital cost ($900–$1000) • single battery powers both devices—reduced battery life • poor support—no response from suppliers to queries.

http://www.socketcom.com/images/450x450/RF5300-542.gif�


79

APPENDIX C: EPORTAL DESIGN

Data Access Layer The class design for the data access layer is displayed in Figure 1, 2 and 3 and Table

1, 2 and 3.

Figure 1 C# Class Diagrams for the interface in the Data Layer

Table 1 Description of the design classes used for interface in the Data Layer

Class Description DAOFactory Abstract class that minimally implements the factory to create objects for

transferring data DAOFactoyMySQL Implementation for MySQL. Creates the connection, and creates transfer objects DataLayerException Exception thrown for general exceptions in the data layer IUserDAO Interface definition for user transfer objects UserDAOMySQL Implementation of user storage/retrieval for MySQL. UserDAOException Exception thrown with user storage/retrieval.


80

Figure 2 C# Class Diagrams for the data sources in the Data Layer

Table 2 Description of the Design classes used for data sources in the Data Layer

Class Description IAudioDAO Interface definition for audio transfer objects AudioMySQL Implementation of audio storage/retrieval for MySQL AudioDAOException Exception thrown with audio storage/retrieval ITextDAO Interface for text transfer objects TextDAOMySQL Implementation of text storage/retrieval for MySQL. TextDAOException Exception thrown with text storage/retrieval IMovieDAO Interface definition for movie transfer objects MovieDAOMySQL Implementation of movie storage/retrieval for MySQL MovieDAOException Exception thrown with movie storage/retrieval ISlideshowDAO Interface definition for slideshow transfer objects

Figure 3 C# Class Diagrams for the Category and POIs in the Data Layer


81

Table 3 Description of the Design classes categories and POIs in the Data Layer

Class Description IMapDAO Interface definition for map transfer objects MapMySQL Implementation of map storage/retrieval for MySQL MapDAOException Exception thrown with map storage/retrieval ICategoryDAO Interface for category transfer objects CategoryDAOMySQL Implementation of category storage/retrieval for MySQL. CategoryDAOException Exception thrown with category storage/retrieval IPoiDAO Interface definition for POI transfer objects PoiDAOMySQL Implementation of POI storage/retrieval for MySQL PoiDAOException Exception thrown with POI storage/retrieval

Model The class design for the model layer is displayed in Figure 4 and 5 and Table

4 and 5.

Figure 4 C# Class Diagrams for the media content in the Model Layer

Table 4 Description of the Design classes for media content in the Model Layer

Class Description Audio Audio multimedia for points of interest Image Images for slideshows Text Text multimedia for points of interest Slideshow Slideshow multimedia for points of interest Movie Movie multimedia for points of interest


82

Figure 5 C# Class Diagrams for the entities in the Model Layer

Table 5 Description of the Design classes entities in the Model Layer

Class Description User A user that logs into the ePortal system Map A map of a geographical area POI Points of interest that exist on maps Category Categories associated to points of interest

Interface The class design for the interface layer is displayed in Figure 6 and Table 6.

Figure 6 C# Class Diagrams for the entities in the Interface Layer


83

Table 6 Description of the Design classes entities in the Interface Layer

Class Description ICommand Interface defined for commands UserListCommand Implementation command for retrieving a list of users MapListCommand Implementation command for retrieving a list of maps GetMapCommand Implementation command for retrieving a map CategoryListCommand Implementation command for retrieving a list of categories DeleteMapCommand Implementation command for deleting a map LogonCommand Implementation command for processing the logon LogonException Exception thrown within logon processing AudioForm Form for associating audio multimedia to points of interest CategoryForm Form for creating and editing categories EPortalTreeNode Helper class for improving functionality of the data export tree view nodes LogonForm Form for processing the logon Main Main form for user interface, includes functionality for editing maps,

exporting data, and user management Program Initial program start point that initialises the main form SplashForm Introduction form shown on startup TextForm Form for associating text multimedia to points of interest


84

REFERENCES Bemjamin, L. (2003). Today’s wireless investment, tomorrow’s bookings? Paper presented at ENTER 2003:

Tenth International Conference On Information Technology and Travel & Tourism—IFITT’s Global Travel & Tourism Technology and eBusiness Forum. Helsinki. 29th–31st January 2003. Retrieved 28 December, 2004 from 1http://www.ifitt.org/member/index.html

Blewitt G. and G. Taylor (2002) Mapping Dilution of Precision (MDOP) and map-matched GPS Int.. J. Geographical Information Science. V16(1) p 55–67. available from 1http://www.nbmg.unr.edu/staff/pdfs/blewitt%20and%20taylor.pdf accessed on 5/22008.

Buhalis, D. (2003). eTourism: Information Technology for strategic tourism management. Harlow, Essex. Pearson Education.

Kanerva, L. (2004). The Pocket Traveler Project. Paper presented at ENTER 2004: Eleventh International Conference On Information Technology and Travel & Tourism—IFITT’s Global Travel & Tourism Technology and eBusiness Forum. Cairo. 26th–28th January, 2004. Retrieved 28 December, 2004 from 1http://www.ifitt.org/member/index.html

National Marine Electronics Association, (2007). 1http://www.nmea.org/

Oertel, B. (2002). Mobile Multimedia Services for Tourism Economic Potentials, Key Applications and Scenarios. Paper presented at ENTER 2002: Ninth International Conference On Information Technology and Travel & Tourism—IFITT’s Global Travel & Tourism Technology and eBusiness Forum. Innsbruck, Austria. 23–25 January, 2002. Retrieved 28 December, 2004 from 1http://www.ifitt.org/member/index.html

Strangeways, O. (2003). Mobile Services for E-travel behavior. Paper presented at ENTER 2003: Tenth International Conference On Information Technology and Travel & Tourism—IFITT’s Global Travel & Tourism Technology and eBusiness Forum. Helsinki. 29th–31st January 2003. Retrieved 28 December, 2004 from 1http://www.ifitt.org/member/index.html

Sun Microsystems (2003) JSR-000179 Location API for J2ME. 1http://www.jcp.org/aboutJava/communityprocess/review/jsr179/index.htm. accessed 5/2/2008.

Symbian (2007) 1http://www.symbian.com/symbianos/index.html


85

Glossary Term Definition

Electronic A system comprising hardware and software elements that may direct a person or persons on a tour of places of interest

Human tour guide A person who fulfills the functions of a tour guide POI Point-of-interest Bibbulmun Track A walk trail that from Perth to Albany; the trail has historical

significance and is popular with walkers IEEE Institute of Electrical and Electronics Engineers ECU Edith Cowan University Audio/visual information Information conveyed by sound and or vision Tour group One or more persons undertaking a sight seeing excursion User A person who is operating the electronic tour guide Itinerary A list of destinations to visit GPS Global Positioning System Preferred path The official route for the Bibbulmun track Partial System Failure One or more of the functions offered by the software is no longer

useable; e.g. The GPS hardware can not obtain a position fix due to dense tree cover or inclement weather. This would result in the software not being able to provide accurate directions.

Map zoom The ability to magnify or reduce the map image Map drag The ability to view a different portion of the map image by “dragging

it” with a mouse or stylus across the view window Terminus An end point J2ME Java 2 micro edition; a software development environment for small

devices such as personal digital assistants and mobile telephones. Virtual Machine Software that enables other software to run independent of the type of

physical hardware. CDC Connected Device Configuration; a subset of J2ME used to program

larger small devices such as a personal digital assistant MB Megabyte; A measure of the amount of memory that a particular

system has Windowing That mechanism whereby a display of information is divided into

separate areas for grouping similar information Xhtml files A format for storing information electronically API Application Programming Interface; a collection of software utilities

that may assist a programmer in a specific task CLDC Connected Limited Device Configuration; a subset of J2ME used to

program larger small devices such as mobile phones MIDP Mobile Information Device Profile; a subset of the CLDC which is

used for mobile information sharing USB Universal Serial Bus RS232 A protocol for serial communication of data Bluetooth A radio communications protocol for electronic devices WiFi A radio communications protocol for electronic devices LBS Location Based Services LSI Location Specific Information Packet A package of data that is transmitted in some way, it includes

housekeeping information attached to the front and/or the rear of the data

Floating point data type A representation of numbers containing decimal places for storage within and manipulation by an electronic device

List data type A representation of a list of items for storage within and manipulation by an electronic device

CALM Conservation And Land Management


86

GUI Graphical User Interface PDA Personal Digital Assistant KVM Kilobyte Virtual Machine; a java virtual machine for CLDC, it requires

less than one KB of memory Category The class of related LSIs, that is, a group of LSIs that have a common

element or characteristic. For example, wild flowers may be a category that includes several LSIs that have locations of desired wildflowers

Points of Interest (POI) A specific point on the map to denote significance of this position Location Specific Information (LSI)

A specific area of interest with details that relate to the specific location. Synonym for Point-of-interest

Software Te the application developed by this project group which runs on a GPS enabled portable device and will provide an electronic tour guide experience

Tour group A group of people who are walking on the track and who are using the

software as a guide

User A member of the tour group who is manipulating the device running

the software Itinerary The list of places that the tour group wishes to visit in the order that

they wish to visit them

Human tour guide A person who is responsible for leading a tour group on an itinerary

and for imparting information concerning the local area and POI


87

AUTHORS

Dr. Leisa Armstrong Leisa Armstrong is a School of Computer and Information Science Lecturer in computer science with a focus on mobile and internet technologies. Leisa has more than ten years experience in Agricultural Science and Environmental research. She has worked on a number of successful externally funded agricultural industry projects in Western Australia. Leisa also has a strong background in environmental science and plant biodiversity/ecology. Over the last five years Leisa changed research focus towards computer science related research. Leisa also has recent experience in the development of environmental sensor network technologies and mobile enabled applications in agriculture. Her research interests include data mining and mobile systems.

Email: [email protected]

Christopher Holme Chris Holme is employed by the School of Computer and Information Science at Edith Cowan University as a Research Engineer. He has more than ten years experience with software manufacture and more then five years experience with electronics design and firmware manufacture. Chris' research interests are broad and range from mobile agents and the platforms they run on to the automation of anything. Chris is expert in sensor network technologies, short range digital radio communications and digital electronics.


Gautham Kasinath Gautham is an experienced software architect and programmer with experience with OO software application development in Java and .Net environments. Gautham has a Research Masters in Computer Science awarded from Edith Cowan University, Western Australia. His research interests include XACML and open source technologies.


Ajden Sehovic Ajden has experience in the area of software design and C# application development and was awarded Bachelor of Computer Science from Edith Cowan University.

Yatish Vadera Yatish has experience in the area of wireless technologies and was awarded Bachelor of Information Technology (1st class honours) from Edith Cowan University.

Greg LeCoultre Greg has experience in the area of wireless technologies and was awarded Bachelor of Information Technology from Edith Cowan University.

Brendan John Brendan John has experience in the area of networking and application development and was awarded Bachelor of Information Technology from Edith Cowan University.

Chairman: Stephen GreggChief Executive: Ian KeanDirector of Research: Prof. David Simmons

CRC For Sustainable Tourism Pty LtdGold Coast Campus Griffith University Queensland 4222 Australia ABN 53 077 407 286

Telephone: +61 7 5552 8172 Facsimile: +61 7 5552 8171Website: www.crctourism.com.auBookshop: www.crctourism.com.au/bookshopEmail: [email protected]

coMMercIALIse

reseArcHANd

deVeLopMeNt

educAtIoNANd

trAINING

utILIse

coLLABorAtIoN

coM

Mu

NI c A t I o N

I NN

oV

AtI

oN

• Travel and tourism industry• Academic researchers• Government policy makers

• New products, services and technologies• Uptake of research finding by business, government and academe• Improved business productivity• Industry-ready post-graduate students• Public good benefits for tourism destinations

I N d u s t r y p A r t N e r s u N I V e r s I t y p A r t N e r s c o M M e r c I A L I s A t I o N

EC3, a wholly-owned subsidiary company, takes the outcomes from the relevant STCRC research; develops them for market; and delivers them to industry as products and services. EC3 delivers significant benefits to the STCRC through the provision of a wide range of business services both nationally and internationally.

TOURISM NT NORTHERN TERRITORYAUSTRALIA

K e y e c 3 p r o d u c t s

CRC 8007 Tech Report Cover.indd 1 17/11/08 4:28:36 PM

Sustainable Tourism Cooperative Research Centre (STCRC) is established under the Australian Government’s Cooperative Research Centres Program.

STCRC is the world’s leading scientific institution delivering research to support the sustainability of travel and tourism—one of the world’s largest and fastest growing industries.

IntroductionSTCRC has grown to be the largest dedicated tourism research organisation in the world, with $187 million invested in tourism research programs, commercialisation and education since 1997.

STCRC was established in July 2003 under the Commonwealth Government’s CRC program and is an extension of the previous Tourism CRC, which operated from 1997 to 2003.

Role and responsibilitiesThe Commonwealth CRC program aims to turn research outcomes into successful new products, services and technologies. This enables Australian industries to be more efficient, productive and competitive.

The program emphasises collaboration between businesses and researchers to maximise the benefits of research through utilisation, commercialisation and technology transfer.

An education component focuses on producing graduates with skills relevant to industry needs.

STCRC’s objectives are to enhance:the contribution of long-term scientific and • technological research and innovation to Australia’s sustainable economic and social development;

the transfer of research outputs into • outcomes of economic, environmental or social benefit to Australia;

the value of graduate researchers to • Australia;

collaboration among researchers, • between searchers and industry or other users; and

efficiency in the use of intellectual and • other research outcomes.

Documents

AN INVESTIGATION INTO THE INCORPORATION OF LEADING …...An Investigation into the Incorporation of Leading Edge Mobile Technologies in the Recreation and Adventure Tourism Industries