Research Project by Veneshree Naidoo Student Number

1

Research Project by Veneshree Naidoo

Student Number: 9811455W

Supervisor: Dr. S Merlo

School of Geography

MSc GIS/Remote Sensing Project

Title

Developing a mobile phone GIS-based application to assist in automobile least

cost route planning. A case study of the City of Johannesburg municipal area.

2

Abstract The use of cellular phones pervades most technological aspects in daily life. More than 80%

of users use their mobile phones for some form of navigation. The objective of this project

was to develop a standard automobile routing application for Android mobile phones. The

application development process was constrained to a minimal financial budget. This was the

main parameter that informed the use of open source application development software and

mapping data service providers. The purpose of the routing application is to allow the user to

choose the type of routing preferred between shortest path or fastest time. The study area

was focused on the City of Johannesburg. OpenStreetMaps has an updated and

comprehensive road network which can be relied on for the City of Johannesburg. The

application was created for an Android operating system since this is the more common smart

mobile phone operating system. The application was built in Android Studio using the Map-

box plugin which is focused on open street routing and pulls from the Open Street Routing

Machine for the actual route. The application allows for most standard features such as traffic

flow information, geolocation and turn-by-turn directions.

Keywords: OpenStreetMaps, Geographic Information Systems, Android Studio, Map-Box,

Java scripting, Shortest-path routing

3

Contents Abstract .................................................................................................................................................. 2

Chapter 1. Introduction .......................................................................................................................... 7

Chapter 2. Literature review ................................................................................................................ 10

2.1. The mobile phone software development process ............................................................ 10

2.2. Open Source or Proprietary Mapping Data Sources ........................................................... 11

2.3. OpenStreetMaps and GIS ..................................................................................................... 12

2.4. Quality of open source data ................................................................................................. 12

2.5. Google Maps Data Source .................................................................................................... 12

2.6. Cartography and online mapping ........................................................................................ 13

2.7. The cartographic styles of Google Maps and OSM data ..................................................... 13

2.8. Network data structures and OSM data .............................................................................. 14

2.9. Shortest path or quickest time routing ............................................................................... 14

2.10. The Open Source Routing Machine ................................................................................. 15

Chapter 3. Methodology ...................................................................................................................... 16

3.1. Procedures ............................................................................................................................ 18

3.2. Summary of the methodology ............................................................................................. 19

Chapter 4. Results ................................................................................................................................ 20

4.1. The Design Phase in mobile application development ....................................................... 20

4.1.1. Major mobile phone operating systems ..................................................................... 20

4.1.2. Choice of mapping data source and API ...................................................................... 21

4.1.3. Summary of decisions impacting software design phase ........................................... 24

4.2. Development Component of Mobile Software Development ........................................... 24

4.2.1. The SDK setup and usage ............................................................................................. 24

4.2.2. Configuring the Mapview ............................................................................................. 25

4.2.3. Obtaining the start and end points .............................................................................. 25

4.2.4. Determination of user’s location ................................................................................. 26

4.2.5. Adding in traffic information ....................................................................................... 26

4.2.6. Selection of Least Cost Route: determination of the two routes provided .............. 27

4.2.7. The Routing API and OSRM .......................................................................................... 27

4.2.8. User Interface Design ................................................................................................... 27

4.3. Iterative Testing Phase ......................................................................................................... 32

4.3.1. Results from benchmarking exercise ........................................................................... 32

4

Chapter 5. Conclusion .......................................................................................................................... 35

5.1. The functional and the non-functional aspects of the application ................................ 36

References ........................................................................................................................................... 38

Appendix I – Code ................................................................................................................................ 43

5

List of Abbreviations

API - Application Programming Interface

ETA - Estimated Travel Time

GeoJSON - GIS data based on JavaScript Object Notation

GIS - Geographic Information System

HTML - HyperText Markup Language

IDE - Integrated Development Environment

KML - Keyhole Markup Language

SDK - Software Development Toolkit

OS - Operating System

OSM - OpenStreetMaps

OSRM - Open Street Routing Machine

VRP - Vehicle Routing Problem

Vs. - versus

6

List of Figures

Figure 1. Map of Gauteng illustrating the municipal boundaries of the City of Johannesburg (Google

Maps, 2017). ........................................................................................................................................... 8

Figure 2. OSM of the Turfontein Area for comparison of visual elements .......................................... 13

Figure 3. Google Map of the Turfontein Area for comparison of visual elements ............................... 14

Figure 4. The mobile application development framework implemented in this project ................... 16

Figure 5. Application design.................................................................................................................. 19

Figure 6. Image illustrating interface of Google Maps application ...................................................... 28

Figure 7. Image illustrating interface of Waze application ................................................................... 29

Figure 8. Starting screen of application – located on user’s position .................................................. 30

Figure 9. Input location and the two routes traced .............................................................................. 31

Figure 10. Traffic Data Overlay ............................................................................................................. 31

Figure 11. Turn by Turn text instructions on a different screen. .......................................................... 32

Figure 12. Prototype illustrating the shortest (blue) and fastest (red) route ....................................... 33

Figure 13. Shortest route (ETA and Kilometres) ................................................................................... 33

Figure 14. Fastest route (ETA and Kilometres) ..................................................................................... 33

Figure 15. Google Maps shortest route (ETA and Kilometres) ............................................................. 34

List of Tables

Table 1. Datasets and libraries required for use in the prototype ....................................................... 17

Table 2. Comparison of Android and iOS operating systems (Martin, 2018) ....................................... 20

Table 3. Comparison of Google Maps and OSM (Marder, 2018). ........................................................ 21

Table 4. Feature Comparison between Google Maps and OSM (Marder, 2018) ................................. 22

Table 5. Evaluation of Mapbox against list of required libraries .......................................................... 23

Table 6. List of functional and non-functional components of application .......................................... 36

7

Chapter 1. Introduction Least Cost route analysis is a common technique used in distance analysis to determine the

optimum route between two points. An optimum route can be a combination of different

factors that come together, as determined by the user, to attain the best path between two

points (Bonsall, 1992; Kim, 2003). In the City of Johannesburg, motorists intentionally seek

optimum driving routes. This definition of ‘optimum’ can vary according to criteria such as

time, distance, traffic, presence of e-tolls, number of traffic intersections. In the world of

logistics and transport, least cost routing can equate to lower costs for transport companies

(Qingyou & Qian, 2015). An efficiency-route test prior to departure would assist in

determining the most cost-effective path. This could be especially useful to fleet management

companies or businesses where a large portion of the operating costs are a result of time

spent on the road. There are many commercial and free navigation systems that set out

routes. The most common and widely-used GPS systems are Garmin GPS system, and Tom-

Tom. However, with an app placed on a mobile phone, the need for additional devices is

negated.

There are many mobile navigational applications available in the market (Google Play, 2018).

The premise of the application developed for the purpose of this report, was that it may serve

as a proof of concept and basis for further development such as a plugin for fleet

management. Unlike other navigational apps on the market, this proof of concept does not

require the user to accept terms and conditions of use. In order to make use of Google Maps,

the user has to accept section 4.5 of the terms and conditions, which imply that data collected

from users of Google Maps agree to potential data mining by the company (Google, 2018).

This application does not collect or retain user information.

The study focused on the City of Johannesburg, located in the Gauteng province of South

Africa. According to StatsSA census (StatsSA, 2011) the City of Johannesburg ranks first in

terms of population density and population size in South Africa (4,43m people in 2011).

According to the National Traffic Information System (eNatis, 2018), there are approximately

4,4m vehicles on the Gauteng roads as of February 2018. This equates to 38% of the total

number of vehicles in South Africa. The reasons for choosing Johannesburg as the test area

for the mobile application are as follows:

1. According to StatsSA (2013) 38% of Gauteng’s population had a driver’s license in 2013.

StatsSA (2013) indicated that 38.4% of people country wide make their way to work via

private car usage.

2. It is a region of high economic importance, with many logistic companies operating in the

province (Global Africa Network, 2017). Private road users in this area would likely

demonstrate the appetite for an application that can assist in potential costs savings

based on a least cost path.

8

3. High traffic volumes or longer routes could add another consideration to mobile

navigation application usage. Since Johannesburg accounts for a large portion of the total

vehicles in South Africa (eNatis, 2018), this holds true for the City of Johannesburg.

4. Road users in Johannesburg tend to travel further and more often due to higher

population density in the city’s business hub (IOL, 2017). Vehicle navigation applications

would be useful in this city due to long travel distances between start and end points.

The aim of this project is to create a mobile application that tracks the user’s current location

to assist motorists deciding on the most efficient route to reach their destination.

In order to achieve the aim of the project, the study has the following objectives:

1. Determine the most appropriate design method to follow and the best development

environment to build the prototype application.

2. Develop the application to include the following sub-activities:

2.1. Choose the most applicable algorithm in calculating the shortest distance and

shortest time paths;

2.2. Calculate the effect that traffic will have on the path;

2.3. Output at least two possible routes.

3. To test the application for design flaws followed by iterative re-design and development.

Figure 1. Map of Gauteng illustrating the municipal boundaries of the City of Johannesburg (Google Maps, 2017).

9

Due to time constraints, this project was restricted to being a desktop project; therefore, the

testing phase with actual users was not be carried out. The project was limited to the author

testing the prototype on a mobile device and an Android Studio emulator.

10

Chapter 2. Literature review The literature review below was carried out to assist the author develop an understanding of

the vehicle routing problem and the different aspects of this technology proof of concept

project. The main topics that were reviewed were mobile application process development,

mapping data sources (Open Source and proprietary) and the algorithms typically used to

calculate routes based on shortest path or quickest time. These components assisted the

author in understanding the key considerations when designing the mobile application, the

data sources, platforms, and basic mechanics behind routing.

2.1. The mobile phone software development process

Mobile phones have become an essential part of modern life. In a short space of time (little

more than a decade), mobile phones are now viewed as a necessary basic item from being a

new high-end product (Røpke, 2003; Wilhelm, et al., 2015). It was estimated that in 2007,

mobile phone sales amounted to 1.2 billion units (Silveira & Change, 2010; Wilhelm, et al.,

2015). An application available on a cellular phone could be relatively easier for smaller supply

chain management companies to roll out due to widespread use of mobile phones. It is also

more affordable to the individual road user who use smart phones for a variety of reasons.

By using road data provided by either Google or other proprietary data services; costs of

updating road network information is also lowered as compared. the traditional GPS service

providers. The author believes that portability is another key reason for a mobile phone

application.

The inherent complexity of software design implies that specific steps are required to break

up the problem into manageable units. Prior to any coding or actual development – the

conceptualisation and design phases must be undertaken (Flora & Chande, 2013).

The development of a mobile application is similar to that of traditional web-based

development, in that, a design process is followed (Flora & Chande, 2013). Mobile phone

application development has a shorter lifespan but essentially follows the process of iterative

conceptualisation and planning, design, development and testing (Zaragoza, et al., 2016) .

Vithani and Kumar (2014) proposed a similar lifecycle for mobile application development

with a separate phase for the prototyping of the application post the development stage. The

process detailed by Vithani & Kumar (2014) revolved around the “Identification, Design,

Development, Prototyping, Testing and Maintenance” stages. The report under review aligns

with the Vithani and Kumar (2014) and Zaragoza, Kim and Han (2016) research pieces. For the

purpose of this proof of concept, the live testing and maintenance phases were not carried

out. The Identification or conceptualisation phase of the life cycle proposes the developer

focus on the idea behind the application, it’s worth or value in the market and the mobility of

the application. These parameters must be addressed in the initial phase of app development

(Gómez, 2017). The design phase focuses on the user experience and specifically the user

11

interface. Questions such as how the user will interact with the application must be addressed

upfront (Gómez, 2017; Vithani & Kumar, 2014).

The development stage encompasses the actual application build. Some of the key decisions

to make that has an impact on this phase include whether the app will follow a Native, Web-

based or Hybrid approach (Burns, et al., 2016; Dua, 2018). Each method has its own strength

and weaknesses. The Native approach is reliant on expert knowledge of the developers and

can take considerable time which is costlier (Dua, 2018). However, Native applications are

faster, more responsive and more robust (Dua, 2018). The choice between which platforms

to support also has to be made upfront (Burns, Umbaugh and Dunn, 2016). Since the two

major operating systems for mobile devices are Android and Apple based, the decision for

this prototype was limited to two options. Together these operating systems make up over

98% of all smart phone operating systems (Vincent, 2018). Android is said to dominate the

market with circa 80% of all mobile phones, according to Gartner (2017). Typically, developers

either specialise in one or the other operating systems (Burns, Umbaugh and Dunn, 2016).

Choice of development software is also a key consideration. By exploring the different

available options of GIS and SDKs, the author may determine which environment is best

suited for the prototype development. Key considerations are likely to be costs involved,

integration with available GIS development platforms, conversion considerations to mobile

phone application development platforms. Gavalas & Economou (2011) proposed a matrix

for the comparison of the three facets being operating systems, runtimes and application

frameworks in conjunction with development languages. Gavalas and Economou (2011)

discussed the use of Java, .NET Compact Framework, and Android. In this proposal, the use

of the Google and Mapbox APIs will be discussed.

The prototyping/testing stages of the lifecycle is the space in which the app is tested and

major bugs fixed (Vithani & Kumar, 2014).

For the purpose of this project, the application testing was limited to the author, the

simulated Android device on Android Studio and benchmarking carried out by way of a

comparison on two routes with Google Maps app

2.2. Open Source or Proprietary Mapping Data Sources

For a real-time navigational mobile application, the map data source is of critical importance.

A large part of the design considerations for this project stemmed from the choice between

freely available data sources or proprietary information. The positives to using proprietary

data are that the product can be more stable, there is a large team that can assist when there

are problems with the data (Optimus Information, 2015). Accessing the data could be easier

due to the rigour and investment to enhance the user experience (Optimus Information,

2015) . The negative to using this information, includes sometimes arduous terms and

conditions that have to be accepted prior to use, possible opaque structure and workings of

software and the cost of the data or software (Singh, et al.,2015). Singh, et al. (2015) noted

12

on the other hand, open source software or data is typically associated with little or no cost

implications, the end user agreements are transparent and there are a large community of

developers that one can access for support. However; due to the open source nature – the

quality of data may not be as high or interface as user friendly as paid-for systems (Optimus

Information, 2015). The two major online data sources researched for this app development

were OpenStreetMaps and Google Maps.

2.3. OpenStreetMaps and GIS

OSM has become one of the main data sources of Volunteered Geographic Information on

the internet (Foody, et al.,2017). Foody, et al. (2017) further proposed that OSM is no longer

just an online mapping, but is a spatial database that is crowdsourced. OSM has developed

into a GIS software that in some cases form the basis of other mapping and GIS tools. For

example, there are now many commercial software applications that are based on OSM data

and its complex routing engine. Mapbox, Mapquest and Leapfrog are names of a few such

commercial software development companies that are focused on spatial solutions using

OSM. In terms of data fees, OpenStreetMaps offers the use of the map tiles free of charge.

OSM allows easy customisable data with no restrictions. This is by far one of the bigger

advantages of OSM data (Buczkowski, 2015).

2.4. Quality of open source data

Foody, et al. (2017) addressed quality assurance, which is one of the main concerns when

using open source data. For a routing application this can be of particular importance. OSM

data may not be able to satisfy all stakeholders’ specifications; it is however able to withstand

scrutiny according to the authors of “Mapping and the Citizen Sensor” (Foody, et al., 2017).

There are scientific and regulatory bodies that peruse the database to ensure standards are

met (Olteanu-Raimond et al., 2017). There are also quality assurance tools that data providers

produce such as OSM inspector by Geofabrik and OSM Map Compare.

2.5. Google Maps Data Source

Since its release in 2005, Google Maps has continuously evolved over time to remain one of

the most commonly used online source of mapping data (Plantin, 2018). The Google Maps

platform has very data quality standards and the company has invested heavily in maintaining

its high definition satellite imagery and complex algorithms to integrate captured information

into its platform (O'Beirne, 2018). One of the negatives in terms of data use by developers, is

that you are bound by the Google Terms of Use agreements. These are very lengthy with

many conditions and as a developer, one would need to consider the implications of using

the service for a commercial for-profit website (Google Maps Platform, 2018). In terms of

advertising which falls under section 4.3c of the Terms of Usage, Google reserves the right to

include advertising on the maps that are used as part of the built application under the ‘Free’

API use. In order to opt out of advertisements, the developer needs to upgrade to a paid usage

agreement or discontinue the service usage (Google Maps Platform, 2018).

13

2.6. Cartography and online mapping

According to Smith (2016), the interactive online mapping environment and advancements in

the field of cloud computing and open source data has reduced hurdles in terms of

cartography. While Smith (2016) paper’s main aim was to review thematic socio-economic

online mapping resources and GIS, it did touch on the visual representation of maps online.

More can be done to include a wider array of cartographic visualization functionality in online

mapping and spatial databases; however, this requires advanced programming knowledge

and be cost effective for the developers of the databases. These generally tend to be the

software industry whose main customers are different and economic viability maybe limited.

2.7. The cartographic styles of Google Maps and OSM data

The area around the Wemmerpan water body was selected and loaded on both the OSM

server and Google Maps. Figure 4 and Figure 5 below illustrate the visual aspects of the way

in which both servers represent the same data. The scales of both maps are different however

scalability is not the focus of the comparison. The first thing that is noticeable, is that OSM

data represents national roads in a much different colour than is typical seen. The Google

Maps representation is more familiar. The definition on the OSM map is crisper and sharper

compared to Google Maps. It appears that Google Maps is more up to date in terms of the

features surrounding the Wemmerpan water body. Google Maps does provide more features

than the OSM map – this is however to be expected given the variation in budgets of the two

data providers. The OSM map represents the railway line far clearer than the Google Map. In

terms of aesthetics of both maps, the author prefers the use of OSM data.

Figure 2. OSM of the Turfontein Area for comparison of visual elements

14

Figure 3. Google Map of the Turfontein Area for comparison of visual elements

The comparison of cartographic styles was based on some features as represented by

O'Beirne (2010) which focused on depiction of water bodies, highways and railways.

2.8. Network data structures and OSM data

According to Curtin (2013) Network data structures are relatively old but remain an important

part of ongoing study. Network analysis has its roots in graph theory and topology that use

GIS data structures to represent its outcomes. Network data structures within GIS must store

information of lines, edges and vertices. It must also store the relationships between these

sub-structures or topological information (Fischer, 2003). This can also more specifically be

defined as a transportation network (Bell & Lida, 1997). According to Mapbox (2018), features

are described using vector type structures. Nodes, Ways and Relational objects form the basic

geometries for real world representations. Tags are also used to describe features. Tags are

uncommon in the spatial community and do not form part of the standard GIS spatial data

structures. According to Mapbox (2018) Nodes are used to describe points in OSM, Ways are

used to represent a connection between nodes. In other words, Ways can be lines or

polygons. Mapbox (2018) further explains that Tags are used to differentiate what the Node

or Way represents. For instance, a Node or a point could be a school or a church or a store.

The Pag defines what the node represents. Relations are used to group Nodes and Ways into

more complex objects. For example, a bus route can be comprised of many Ways.

2.9. Shortest path or quickest time routing

There are many aspects to the optimal path in a routing algorithm. The first aspect being the

shortest distance that has to be calculated. Bellman’s-Fords and Dijkstra’s shortest path are

the two simple approaches to solving the shortest distance aspect (Storandt, 2012). Another

aspect to consider in routing problems is the shortest time a vehicle could take. Edge Cost

functions become useful in this calculation (Storandt, 2012). For real-time vehicle routing,

traffic can cause unexpected delays from the initial chosen path. Therefore, the optimal path

should be re-evaluated upon latest major traffic updates (Nha, et al., 2012). According to Nha,

15

et al. (2012), there are three groups of Dynamic Routing Algorithms. These are the Optimal,

Heuristics and Hybrid Algorithms. Where the Optimal algorithms explore the full set of

solutions, the Heuristic processes explore only a subset of all the available solutions to find

the optimal solution. The Hybrid method, uses the strengths of both the two algorithms (Nha,

et al., 2012). Another more recent approach to dynamic routing but with fuel consumption

being the primary objective is the Monkey King Evolution algorithm (Meng & Pan, 2016).

According to the study, the Monkey King Evolution algorithm fares better in tests for fuel

efficiency than both the A* and Djikstra algorithms.

Choi & Nieto (2011), demonstrated a process map of incorporating different factors affecting

least cost routes for haul trucks on a mining or construction site. Whilst this study is not

directly related to a mobile phone routing application, it does provide a process map, which

can be modified for this vehicle route navigation application. In the case of reviewed paper,

the main processes involved understanding the destination in relation to the starting point,

the analysis of the directional costs of each path to the destination, the input of data relating

to terrain, time and fuel consumption inform the analysis and finally the output of the least

cost path (Choi & Nieto, 2011).

2.10. The Open Source Routing Machine

The Open Source Routing Machine forms the backbone of the routing service offered by OSM

for navigation purposes (Foody, et al., 2017). OSRM is based on the C++ programming

language and is used to find the quickest path. This routing machine supports different modes

of transport such as walking, cycling and automobile routing. It is said to be easy to customize

by developers and many such commercial companies use the OSRM such as GraphHopper,

Mapquest and Mapbox. Mapbox (2018) provides a routing class that accesses the OSRM.

There are different parameters that may be specified to achieve varying results. For example,

by focusing on highways in a given route, the fastest route will be achieved despite sometimes

having a longer distance. In order to achieve the shortest route between two points, the

parameter telling the OSRM to avoid highways has to be specified. This forces the routing

engine to look for the shortest route. In this way, the shortest path and the fastest path are

examples of least cost routing.

After conducting the literature review, the author had an introductory base on the

components of the project to focus on. It was important in the development of mobile

applications to choose the development paradigms most suited to the desired outcomes. In

this case it was to develop a navigational mobile app quickly and at the least possible

monetary cost. It was important to gain an understanding the algorithms typically used to

create the paths to build a navigational GIS and the development styles (native, web-based

or hybrid) as well the platforms to be supported. The map data source used in the application

should be updated regularly and widely available for use and have few terms of usage

attached.

16

Chapter 3. Methodology

The mobile application development process was utilised to provide structure for the design

and build of the project (Vithani & Kumar, 2014).

Figure 4. The mobile application development framework implemented in this project

Figure 4 above represents the main tasks and procedures that took place in each stage of the

application development. The initial phase focused on understanding the idea for the

application. In this case, it was to create a mobile navigational application. The design phase

focused on designing the user interface, the decision to go web-based (customised for mobile

phones) or native, the operating system to support, the map data source, supporting APIs and

finally the design of the application. The development phase involved the setup of the IDE,

further research on libraries to be included and the actual programming. Finally, the testing

phase involved iterative app testing and debugging. Once the application was compiling and

running correctly a small benchmarking exercise was carried out against another application

to assess accuracy of routing.

Prior to the start of development, the choice of map data sources, operating systems and

associated development platforms had to be made. The decisions were based on criteria such

as cost implications to the author of the study, ease of use and availability of existing data for

the area in question (JHB and surrounds).

The operating system choice was between iOS (for apple phones) or Android (for most other

smart phones). The map data selection was a choice between Google Maps and the

OpenStreetMaps environment. The report focuses on a selection between Google Maps and

Conceptualisation

The Idea, Mobility of

project

Testing

Iterative testing of

prototype,

debugging and

benchmarking

Design

User Interface, Platform

decision, OS choice, Map

data source choice,

application architecture Development

Sourcing of data, Register

for API keys, Platform

setup and programming

17

OSM. The reasoning for the selection of OSM and Google Maps was due to Google Maps being

the most popular proprietary source on the market and OSM due to its open source nature.

There are pros and cons to using either of these map services. These are listed in the Chapter

4, sub-section 1. The development platforms were limited to packages that either integrated

with OSM or Google Maps data. For the purpose of this project, the two platforms assessed

in detail were Mapbox and the Google API. The Mapbox SDK (Software Development Toolkit)

can be used within the Android environment and integrates well with OSM whilst Google

Maps data may only be accessed via the Google API.

The design of the interface, route calculation options and display of selected routes were

based on the libraries and options available in the selected SDK.

Table 1 below summarises the main dataset and libraries that were required for the prototype

build. In order for the application to provide the routing functionality, the app requires data

such as the GPS coordinates of the user’s current location and the location of the destination.

A GPS tracking module and geolocation library are therefore required. Navigation is carried

out by a routing module which requires the start and destination coordinates to calculate the

routes.

Table 1. Datasets and libraries required for use in the prototype

Major Datasets and

Libraries required

Usage in Prototype

Map tiles A source of mobile map data was required.

GPS tracking module Smart phones typically offer a GPS tracker. The API will access

the tracker and supply real-time coordinates to the module.

Geolocation module This module is passed the destination address as a parameter

and locates the address or point of interest or general location in

the chosen mapping database. The coordinates of the

destination address are then passed back to the API.

Navigational module A navigational module was required to use the start coordinates

supplied by the GPS tracker and the destination coordinates to

calculate the two routes based on time and distance.

18

3.1. Procedures

The three main areas of the study were the design of the application, the actual

development and the assessment of the application. The design relates to the needs

analysis of the developer and the major decisions on data sources and related supporting

software. The development phase entailed the environment set up and coding whilst the

assessment entailed answering of questions based on the shortest and quickest routes

displayed. These are the outcomes that the user wishes to receive. The three areas are

explained in greater detail below.

3.1.1. A developer needs analysis was conducted to assist in the choice of targeted

operating system, IDE (integrated development environment – java or python,

etc.), choice of peripherals (example: ease of interface with Bluetooth, accessing

voice prompts), choice of Application Programming Interface (API). Since this was

a prototype-based project only, the user’s needs were conducted via a short

desktop analysis of existing applications. The prototype incorporated data entry

for the route start and end point inputs and selection from pre-defined criteria

for least cost analysis. The user could consider a fastest route or a shortest route.

The least cost route was different, depending on the selection of the user. The

main parameters that was considered were distance, number of turns, and

highways.

3.1.2. Mapbox or Google API for the calculations of shortest route based on time or

distance. The routing methods will assist in calculating the least cost network

path. The items that the development should incorporate included

I. Set up the SDK

II. Configure the SDK to interface with the API

III. Import the relevant classes and methods such as GPS tracking, Directional

methods,

IV. Set up a virtual device for testing

V. Performing the analysis and displaying the results

3.1.3. In the third part of the project, the application will aid in answering the

following questions:

I. What is the Estimated Arrival Time of the selected route from a choice of two

routes?

II. What is the impact of traffic on ETA?

III. How does the routes calculated by the prototype application compare with

Google Maps?

19

Figure 5 below refers to the application architecture. The application, on start-up

automatically detects the user’s current location and display’s onscreen. The key user input

is the end point of the route. The least cost routing was based on either a shortest distance

or fastest time. A geolocation module, involves accessing the current GPS coordinates,

accessing on-the-fly map data and traffic data (where available) and the production of the

grid and tiles and updating the user’s location. The user may select a route and the turn-by-

turn results are retrieved. Voice prompts can be used in the application and the user’s real-

time position is tracked.

3.2. Summary of the methodology

In summary, the methodology set out above followed the mobile application development

process. The major design decisions that were made included the choice of the targeted

operating system, the map data sources that can be used with the selected OS and associated

APIs. The design proposed allows the application to communicate the user’s current location

(start point) and allows for input of the destination (end point). The start and end points are

displayed over the map, whilst the app retrieves the appropriate tiles, calculates the position

in space, calculate two paths (these being shortest distance and quickest time), and output

the routes using turn-by-turn routing and voice navigation. Iterative testing informed the

development process and was carried out using a simulation of the route on the Android

emulator and a mobile phone.

User Interface

Send GPS

location to

track start

position

Send Address

to OSM server

via Mapbox

Georeferencing

Module – finds

the address or

returns an error

If no error, then Navigational module

calculates and returns two routes

Selected route is drawn onscreen. Voice

commands are accessed and turn-by-

turn navigation is available

Figure 5. Application design

20

Chapter 4. Results

According to the mobile software development process guidelines, the design phase

encompasses the design of user interface, platform and OS choices, map data source choices

and application architecture. The analysis and comparisons and eventual design decisions are

the outcomes of the design phase and have been included in this Chapter on Results.

4.1. The Design Phase in mobile application development

4.1.1. Major mobile phone operating systems

The two major mobile phone operating systems today are Google’s Android and Apple’s

iOS. Combined they have a market share of over 90% of all mobile OS in operation

(Vincent, 2017) and (Gartner, 2016). However; Android leads with 82% share with iOS in

second place. (Gartner, 2016) There are pros and cons to each operating system. The big

drawback of iOS is that it is incompatible with external storage which implies that one

cannot use an SD card to increase the phone’s capacity. Whereas with Android storage

does not pose a problem. The positive of having an iOS phone is better security (there are

much less issues with malware than Android phones). Table 2 shown below is an outline

of the pros and cons of each system.

Table 2. Comparison of Android and iOS operating systems (Martin, 2018) ANDROID IOS

Used by more mobile phone operators Can only be used with an Apple phone

Partly Linux and open source based Apple owned and created

Can have malware issues although security is still very good

Superior security and fewer malware attacks

Takes external storage Does not allow for external storage

Apps that are free to download do not attract a fee from Google. However; those that are commercial

in nature attracts fees from Google. The app creators have to pay Google a percentage of the

download fee.

All apps have to be sold via the Apple Store (iTunes). And a developer fee is payable

Software from unknown sources may be installed

One is limited to what is available on iTunes in one’s country only. (excluding the option to jailbreak the

phone)

Android phones can be cheaper to purchase One of the more expensive phones or buy cheaper second hand

GREATER FLEXIBILITY IN TERMS OF ACCESSING

DATA ON YOUR PHONE LESS TO NO FLEXIBILITY IN ACCESSING YOUR PHONE’S

DATA IN THE MANNER YOU CHOOSE

21

The Android operating system was chosen for the purpose of this prototype since it is easier

to test applications. Android also has a larger market share therefore it is more accessible.

Also, given the author’s knowledge, Android was the more appropriate option to select.

4.1.2. Choice of mapping data source and API

The choice between which mapping data to use depended on the level of detail the source

had for Johannesburg. For this project the mapping data was limited to what is easily

accessible on the internet and which did not need a specific device (such as a Garmin or

tom-tom). OpenStreetMaps and Google Maps were considered for the source of map

data.

Both have detailed maps of City of Johannesburg and are easily available. A Comparison

of Google Maps and OpenStreetMaps was carried out and the results are below. The

features compared follow on from what Marder (2018) illustrated.

Table 3. Comparison of Google Maps and OSM (Marder, 2018).

CRITERIA GOOGLE MAPS OSM

Support Plentiful mapping and development support from Google itself

Development support is good however most is done via 3rd parties. OSM does not have very good data coverage in some areas; however, for the City of Johannesburg; the level of detail is

sufficient

API Interface The API is easy to interface with 3rd parties provide user friendly APIs. Updates Maps are updated frequently

Little commercial update exercises undertaken

Integration Easy to integrate into websites

Integration can be a bit more

challenging for those unfamiliar with OSM.

Geocoding

Geocoding is required to change an address to a specific coordinate or vice versa. In Google

Maps, the API is fairly well developed which means that there is a high level of accuracy and just about any address will be convertible to a

coordinate. However, there are usage rates that apply and going above these will incur a fee from Google. The geocoding of Google Maps

however is superior. Google provides as a free a Place API which can be easily integrated into an

application.

Geocoding is not that simple with OSM data.

In many cases OSM is just a map source with limited functionality for

development. The same capability is provided by a 3rd party such as Mapbox, Skobbler and MapQuest. These are not available as widgets however; as is the

case with Google Maps.

Routing engine

Directions class or methods: Google provides the superior API (in all features). The directions

OSM itself has similar capabilities in that it has its own routing engine – OSRM.

22

method or class typically is supposed to calculate the distance between the start and

end points, work out a route and draw this onto the map and also have the capability to output

the turn – by – turn directions as text.

However, the engine is not as sophisticated as the Google directions routing engine. For instance, there is little functionality to choose between shortest distance and fastest time in

OSRM. This can be done with some 3rd party routing engines such as

GraphHopper but not with other (Mapbox)

Data Layers In terms of Data Layers and overlays, again

Google Maps comes out as superior having support for different data types (KMLS Traffic, vector polygons and a well-stocked drawing

library).

OSM does not directly provide these and have to be accessed via 3rd party

such as leaflet. However, the 3rd party services generally are free to a point as

well. Licensing The major disadvantage of Google Maps is that

usage is subject to many conditions and all code remains propriety of Google. From a

developer’s perspective this leaves little space for customisation.

With OpenStreetMaps, customization is much simpler. There are also far fewer

issues with licensing and authorisations.

Table 4 below is derived from Marder (2018) and demonstrates the technical

differences between Google Maps and OSM. OSM contributors and developers have

done much to ensure the professionalism and functionality of the open source GIS.

Google however does come out as the better system; in terms of services such as live

traffic and a fuller library of Points of Interests. The major drawback is that it is not

open source and is an expensive paid service should an application become widely

used. The level of developer control is also impacted when using Google Maps since

Google is periodically amends how the information or methods can be used.

Table 4. Feature Comparison between Google Maps and OSM (Marder, 2018)

Feature Google Maps OpenStreetMaps

Supporting mobile operating systems

iOS and Android iOS and Android

Max Zoom Level

22 19

Map Types 6: Map with traffic data (separate transit and bicycle view), Satellite with Traffic Data (3D LiDar for certain places not present in most places), Hybrid

5: Standard Map, Transport Map, Cycle Map, Humanitarian

3D Mode Yes No

Direction Service

Google Direction API Using Third Party Services

23

Reverse Direction Service

Yes Using Third Party Services

Bicycle Directions

Yes Using Third Party Services (Limited areas)

Contact Integration

Yes No

Live Traffic Information


Turn-by-turn navigation


The evaluation of the APIs’ that interfaced with OSM data was based the required libraries and

datasets outlined in table 1 of Chapter 3. There are a number of APIs available which provides access

to OSM tiles for real-time geo-location and vehicle routing applications. Some of the APIs include

Skobbler, Mapquest, GraphHopper and Mapbox. Mapbox was eventually selected as the API of choice

due to its large online developer support network and many tutorials on how to interface with the

Android SDK. Mapbox was also a low-cost option and at the design phase of the project; it was

believed that traffic for Johannesburg was available. This premise however; proved to be incorrect in

the development phase. Table 5 below outlines the functionalities of Mapbox against the required

libraries set out in table 1 of Chapter 3.

Table 5. Evaluation of Mapbox against list of required libraries

Major Datasets and

Libraries required

Functionality in Mapbox

Map tiles Mapbox interfaces directly with OSM and does not charge for

use of the map tiles

GPS tracking module Smart phones typically offer a GPS tracker. The API will access

the tracker and supply real-time coordinates to the module.

Mapbox has the necessary libraries to access the phone’s GPS

data once permissions set to allow the application access.

Geolocation module This module is passed the destination address as a parameter

and locates the address or point of interest or general location in

the chosen mapping database. The coordinates of the

destination address are then passed back to the API. Mapbox

24

provides a geolocation functionality that uses the Android

libraries as a basis.

Navigational module A navigational module was required to use the start coordinates

supplied by the GPS tracker and the destination coordinates to

calculate the two routes based on time and distance. These

libraries are able to access the OSRM for actual routes. The

classes provided by Mapbox passes the coordinates of the start

and finish points to the OSRM and specifies whether the shortest

path of fastest path must be prioritized.

4.1.3. Summary of decisions impacting software design phase

It was decided that OpenStreetMaps would be used for the purpose of this prototype development. Due to fewer restrictions on licensing and options to customise the application. There is also now much greater support for the open source mapping and navigation

The Android OS was selected as the target market. In terms of the SDK, it is the Android SDK that was selected due to it support and ease of use with interfacing with the Google OS. The Mapbox API was selected to interface with OSM and it also interfaces well with the Android SDK.

4.2. Development Component of Mobile Software Development The development aspect of the project involved the largest allocation of time and analysis spent on

the project. This component included Registrations for API keys, Platform setup, the learning phase

on how to use the different platforms and understanding of Object Orientated Programming and the

actual programming itself.

4.2.1. The SDK setup and usage

The Mapbox tutorial guides were used greatly to setup the Android SDK and the Mapbox

plugins incorporated and formed the basis of the prototype development.

In order to use the Mapbox plugins – the user had to become familiar with the Android

SDK first and install and setup. Java is also a requisite for use of Mapbox. The author of

this report had to familiarise herself with object orientated programming basics and basic

programming knowledge.

According to (Mapbox, 2018) the Mapbox maps SDK for Android is the plugin into the

Android SDK and uses vector data type to achieve map rendering.

In order to use the Mapbox software; the Android Studio and its dependencies must first

be installed. An Android project must be setup and then the Mapbox classes and

libraries can be included to drive the project.

25

There are four main screens that have to be created in an Android project, these are listed and explained below:

I. Main activity: This is a Java file where Mapbox classes and methods, (Mapbox, 2018) are specified

II. Build gradle: “Android Studio uses a toolkit called Gradle to compile resources and source code into an APK. This plain text file is used to configure the build and list dependencies, including the Mapbox Maps SDK for Android” (Mapbox, 2018).

III. Manifest: Components of the application, including Mapbox-related permissions are described in this screen (Mapbox, 2018).

IV. Activity_Main.xml: Properties of the MapView, the destination Marker and InfoWindow are specified in this screen (Mapbox, 2018).

The four tabs listed above, contain the different components that are required by a compiler to create the map application. The main classes that were required to setup a map application from Mapbox were the Mapbox, MapView, the MapboxMap and the OnMapReady Callback classes. These classes had to be initialised before the project could be built.

4.2.2. Configuring the Mapview

Using the Mapbox tutorial (Mapbox, 2018), the application was created to start up with a view focused on Johannesburg. The MapView class was used to select the style and the attributes of the application. The attributes were configured using the source code (GitHub, 2018). The appearance of the map itself used the properties as follows:

The settings for the style of the map was changed from the default to traffic view. Mapbox comes with six settings being: Streets, Outdoor, Light and Dark, Satellite, Satellite Streets and traffic (Mapbox, 2018). The setting selected for this project was traffic since in this setting the traffic flow was easily highlighted automatically. One could also select a self-style setting by calling a URL with the style setting defined.

The application was given the functionality of using a marker to denote the destination. A geocoding method translates the address of the end point into a coordinate and this coordinate is passed to the marker class addMarker().

4.2.3. Obtaining the start and end points

The start point has been taken to mean the current location of the user. This is accessed via the mobile phone GPS and the tracking module within Mapbox. The GPS coordinate is passed to the tracker class which then can locate it on the map.

The finish point uses a geocoding plugin. There were two ways in which this could be done – through the Mapbox geocoding class which is based on the Android class. Or on the Android geocoding class itself. The former was chosen in this regard and integrated within

26

Android Studio. In order to convert an address into coordinates, the following code was used (Mapbox, 2018):

MapboxGeocoder client = new MapboxGeocoder.Builder()

.setAccessToken(MAPBOX_ACCESS_TOKEN)

.setCoordinates(longitude, latitude)

.setType(GeocoderCriteria.TYPE_ADDRESS)

.build();.

The function of the geocoder entered was to take the address entered via the keyboard or touch screen, convert to coordinates and pass the coordinates to the direction class. The directions class is a built-in library within Mapbox whose functionality is to provide turn by turn navigation directions.

4.2.4. Determination of user’s location

The Mapbox Location layer plugin was used to locate the user on the displayed map. The

routine accesses the phone’s permissions to track the GPS coordinates and relay’s that

information to the location engine in Mapbox. The Mapping engine draws the user’s

position using the symbol. When an instance of the Mapbox map is created. The Mapbox

object uses the location passed to it as the centre of the map. According to Android (2018),

there are a few strategies to determine a user’s location. The best and most accurate is

using GPS coordinates relayed via cell towers. However; this method can make battery

usage inefficient. Mapbox telemetry class makes use of the Android.location base

methods (Android, 2018).

The process used by Android location service is to listen for the user location (via GPS or

via cell towers and Wi-Fi signals).

4.2.5. Adding in traffic information

Traffic data can be added as a layer to the existing base map. This is done via an additional

plugin which has to be initialised and instantiated in Android Studio. This plugin adds data

to current Mapbox rendered maps (which are based on OSM data). The plugin will render

congestion levels (colours to denote traffic intensity) on both sides of a two-lane road.

Updates occur approximately every 8 minutes. The module used is Mapbox Traffic v1.

There are instances when the plugin crashes on certain Android phones. This has been

reported as a bug however as yet, a second has not been released. It should be noted

that Mapbox as yet does not have traffic information for Johannesburg. This fact was only

learned when testing the traffic module. There are certain cities that are covered; and

unfortunately, the author learned too late into the development and testing phases to

consider another OSM navigational API into Android. The South African National Roads

Agency was contacted as its website states that developers may use their traffic data. On

further investigation, it was discovered that the output of this iTraffic system was a Json

format. In order to integrate with the Mapbox API – a GeoJson format was required. An

improvement could have been to check if the Nokia map data service provider could

27

export their traffic module data in GeoJson format. There may likely be associated costs

with this option. The traffic data shown in this project refers to a US city where the data

is available.

4.2.6. Selection of Least Cost Route: determination of the two routes provided

The functionality within Mapbox to show alternative routes is relatively new with the API.

The code used, as provided on GitHub for Mapbox developers, gives the user a choice of

two routes. The primary route is still the fastest route; however, the other route is

highlighted in different colours so as to not cause confusion. Once the route is selected

(Fastest or otherwise), the other routes maybe toggled off screen and the alternatives are

no longer highlighted (GitHub, 2018).

The implementation in this project was carried out by using the directions API which

outputs the fastest path. After the address is passed to the geocoder to find the latitude

and longitude of the origin and destination variables, the getRoute() function is called. In

the case of the Shortest Path altRoute() takes in the Latitude and Longitude and creates

the shortest route between the input and the origin. This uses Mapbox directions API. It

takes in the latitude and longitude and creates a position (a GIS variable type which

locates its position in space) from the coordinates. Then a new directions class is created

with the coordinates for the destination and origin and the profile is set to shortest route.

4.2.7. The Routing API and OSRM

The Mapbox directions API pulls directions from the OSRM (Open Street Routing

Machine). According to online documentation – OSRM is based on “Contraction

Hierarchies” (Luxen & Vetter, 2011). According to (Geisberger, et al., 2008) , the Open

source routing machine is a C++ implementation of shortest path routing for road

networks. This implementation of the shortest path algorithm is specifically for

OpenStreetMaps. The Contraction Hierarchies algorithm enables complex continent-wide

calculations to be done in seconds. Much of the calculations is then spent on annotations

and transmitting the polygons over the network.

4.2.8. User Interface Design

A short review of two of the most popular applications on Google Play was undertaken. The user interface designs were compared for common elements. These common elements were then considered for replication in the development of this research report. The Maps compared were GoogleMaps and Waze.

One of the first things noticed on click of both apps – the maps load with the GPS automatically detecting the user’s location.

28

The start and end functionality can be input either by clicking the maps and using markers or by entry of a start and finish address.

Both maps have functionality of highlighting the driving path on the map itself and giving turn-by-turn voice and written instructions.

Traffic overlays are much better defined in the Waze application. One of the big draws of Waze is to dodge traffic. There are features which allow users to connect with other users and even send ETA via text or email. Google Maps has a good visual representation of the traffic overlay on the screen by using red or orange to denote severity of traffic on route. Once zoomed out – the user may also see the traffic in the area marked by red dashed lines.

The other functionality which Google Maps has is the use of offline maps which allow the user to still retrieve directions (no traffic updates) and conserve data.

A feature on Google Maps is that it automatically switches to night mode after sunset.

Both map applications have the map as the bulk of the screen space. The next turn directions are viewed at the top whilst a detailed list of turn by turn instructions are given on another screen. The start screen typically has the user already geo-located and the address input bars are located near the top of the screen.

Once the end point has been located, these two text input boxes disappear, making way for the ‘next turn’ guide at the top of the screen. Figures 6 and 7 below illustrate screenshots of the applications described above.

Figure 6. Image illustrating interface of Google Maps application

29

Figure 7. Image illustrating interface of Waze application

For this project the user interface was based on the common elements of both navigational

applications. The app is able to geolocate the user on entry into the program as shown in

figure 8 below. The start and end waypoints appear on the first screen once the address has

been entered. The end point is then marked on the screen and a route is plotted and

highlighted on the map itself, as illustrated in figure 9 below. Figure 11, demonstrated the

turn-by-turn instructions are given on click of the ‘next-turn’ hint at the top of the screen.

A traffic layer can be put onto the route with red indicating high congestion, as illustrated in

figure 10 below. However in this case; since Mapbox does not cover Johannesburg for traffic

input; an international city was used to illustrate that the functionality has been developed in

the app.

30

Figure 8. Starting screen of application – located on user’s position

31

Figure 9. Input location and the two routes traced

Figure 10. Traffic Data Overlay

32

Figure 11. Turn by Turn text instructions on a different screen.

4.3. Iterative Testing Phase Whilst the bulk of this phase takes place simultaneously with the development phase, it was

worthwhile extracting the benchmark study as a standalone component for this report.

4.3.1. Results from benchmarking exercise

In order to determine ‘how good’ the calculated routes of the navigation app developed for this

project were; the results of a selected route was compared to the results of Google Maps. The

routes were benchmarked according to approximate length of routes and estimated arrival times.

The benchmarking exercise was carried out on a POI. In this case the POI was Midrand Police

Station.

The POI was input into both Google Maps and the prototype developed for this report. The results

indicated that the length of the routes for the shortest and the fastest routes were similar whilst

the ETAs were similar during low traffic periods and vastly different during peak traffic conditions.

This is due to the lack of suitable traffic data in Mapbox. The average speed limit along the route

is used to determine the ETA. Google Maps makes use of actual speeds of users along the route

to determine the ETA. In areas where traffic is available – the results were similar with respect to

ETA in peak traffic conditions as well.

33

Figure 12. Prototype illustrating the shortest (blue) and fastest (red) route

Figure 13. Shortest route (ETA and Kilometres)

Figure 14. Fastest route (ETA and Kilometres)

34

Figure 15. Google Maps shortest route (ETA and Kilometres)

35

Chapter 5. Conclusion

The aim of the project was to develop an automobile navigation application for the mobile

phone user. This has been achieved as this is a working application that is based on an

operating system that is commonly used by many smart phone users.

The objectives stated at the start of the project were as follows:

a. Determine the most appropriate design method to follow and the best

development environment to build the application.

b. Develop the application to include most applicable algorithms in calculating the

shortest distance and shortest time paths; calculation of the effect that traffic will

have on the path and the output at least two possible routes giving the pros and

cons of each.

c. To test the application for design flaws followed by iterative re-design and

development.

The objectives in the author’s view were for the most parts achieved by the project. This

statement is supported by the following reasons:

a. The mobile software development process assisted the author in timeous and

cost-effective design and iterative development. This design and development

methodology informed the major choices in OS, Map data source, API and SDK

choices.

b. This objective was in part met by the project. The Mapbox API already included

implementations of the shortest path and fastest time algorithms. The complexity

in implementing these algorithms was under-estimated at the onset. One of the

short comings of this project was that, Mapbox does not include traffic data for

the City of Johannesburg. While the author was able to successfully implement

the code that enabled traffic, the actual data does not pertain to this city. Efforts

to obtain free data were unsuccessful due to an issue of data type integration. This

area speaks to an area for improvement and also reflects what happens often in

the world of software development. The initial requirements may not always be

met by the final product and will often involve further version revisions and

objective revisions.

c. This objective was successfully achieved due to continuous testing using simulated

routing and testing. The application was successfully development.

The three questions which navigational app was designed to answer were outlined in sub-

section 3.1.3 were 1. What is the Estimated Arrival Time of the selected route from a choice

of two routes? 2. What is the impact of traffic on ETA and 3. How does the routes calculated

by the prototype application compare with Google Maps? The application answers these

questions by providing an estimated ETA based on maximum allowable speeds of the route

36

calculated and the routes themselves compare well with that of Google Maps on distance;

however, the estimated time of arrival can differ considerably due to Google Maps using live

traffic information.

5.1. The functional and the non-functional aspects of the application

The mobile application that was developed achieved most of the objectives set out at the

start of the project. However; there were components that were not achieved during the

duration of the project. The table below summarises the components that were operational

and non-operational.

Table 6. List of functional and non-functional components of application

Functional 1. Locates the user’s position automatically on the application start up. 2. Georeferencing of specific addresses, POIs and general locations are available. 3. Calculates the shortest and the fastest route between the start and end positions. 4. Displays the ETA of the selected route by using the specified speed limits on the route. 5. Provides turn-by-turn voice prompts as the user travels along the route.

Non-functional 1. The application is not able to provide live traffic feed for the City of Johannesburg, as it is unavailable on Mapbox at this time. The traffic component is however functional for cities were data is provided. 2. The specific optionality that allows the user to choose between avoiding routes with e-tolls or routes with too many traffic intersections is not available. While these criteria are considered as part of the algorithm that calculates the shortest and fastest routes; they are not functional as standalone options.

In conclusion, the development of a standard mobile vehicle navigation application involves

the integration of many fields of expertise such as programming, GIS and network analysis.

One of the key learnings in GI Science that the author wished to achieve was to integrate

mobile application development with GI Science in order to create a small GIS. This project

has gone some way to assist in that.

Use of Google and Mapbox APIs, JDK and Android SDKs were limited to the basic ‘for-free’

commercial packages. Mapbox does have a more complete geocoder plugin that is a paid

37

service; however; for the purpose of this project, the free geocoder was utilised. Mapbox has

limited traffic congestion functionality for OSM on Android. The API does have good support

for traffic congestion using HTML instead. However due to the aim of developing this

application for Android – and did not focus on the HTML solution.

38

References

Android, 2018. Location Strategies | Android Developers. [Online]

Available at: https://developer.Android.com/guide/topics/location/strategies.html

[Accessed 1 February 2018].

Bell, M. & Lida, Y., 1997. Transportation Network Analysis. England: Wiley (John) & Sons, Limited.

Bonsall, P., 1992. The influence of route guidance advice on route choice in urban networks.

Springer, 19(1), pp. 1-23.

Buczkowski, A., 2015. Geo Awesomeness. [Online]

Available at: http://geoawesomeness.com/why-would-you-use-openstreetmap-if-there-is-google-

maps/

[Accessed 28 May 2018].

Burns, A., Umbaugh, B. & Dunn, C., 2016. Introduction to the Mobile Software Development Lifecycle

- Xamarin. [Online]

Available at: https://docs.microsoft.com/en-us/xamarin/cross-platform/get-started/introduction-to-

mobile-sdlc

[Accessed 29 July 2018].

Choi, Y. & Nieto, A., 2011. Optimal haulage routing of off-road dump trucks in construction and

mining sites using Google Earth and a modified least-cost path algorithm. Automation in

Construction, 20(7), pp. 982-997.

Ćmielová, B. & Panek, J., 2016. Visual Comparison of Web Map Changes of OpenStreetMap and

Commercial Online-Map Providers: A Research Note. pp. 40-54.

Curtin, K. M., 2013. Network Analysis in Geographic Information Science: Review, Assessment, and

Projections. Cartography and Geopgraphic Information Science, 34(2), pp. 103-111.

Demarcation Board, 2018. Boundary data file of local municipalities. [Online]

Available at: http://www.demarcation.org.za/index.php/downloads/boundary-data/boundary-data-

main-files/local-munics/11453-local-munics

[Accessed 18 March 2018].

Dua, K., 2018. A Guide to Mobile App Development: Web vs. Native vs. Hybrid. [Online]

Available at: https://clearbridgemobile.com/mobile-app-development-native-vs-web-vs-hybrid/

[Accessed 10 July 2018].

eNatis, 2018. Live vehicle population per registering authority. [Online]

Available at: http://www.enatis.com/index.php/statistics/71-live-vehicle-population-per-registering-

authority


Fischer, M., 2003. GIS and Network Analysis. s.l., European Regional Science Association.

39

Flora, H. & Chande, S., 2013. A Review and Analysis on Mobile Application Development Processes

using Agile Methodologies. International Journal of Research in Computer Science, 3(4), pp. 9-18.

Foody, G. et al., 2017. Mapping and the Citizen Sensor. In: G. Foody, et al. eds. Mapping and the

Citizen Sensor. London: Ubiquity Press, pp. 1-12.

Gartner, 2017. Gartner Says Worldwide Sales of Smartphones Grew 7 Percent in the Fourth Quarter

of 2016. [Online]

Available at: https://www.gartner.com/newsroom/id/3609817


Gavalas, D. & Economou, D., 2011. Development platforms for mobile applications:Status and

trends'. IEEE Software, 28(1), pp. 77-86.

Geisberger, R., Sanders, P., Schultes, D. & Delling, D., 2008. Contraction Hierarchies: Faster and

Simpler Hierarchical Routing in Road Networks. Berlin, Springer.

GitHub, 2018. mapbox/mapbox-gl-native. [Online]

Available at: https://github.com/mapbox/mapbox-gl-

native/blob/master/platform/Android/MapboxGLAndroidSDK/src/main/res/values/attrs.xml


GitHub, 2018. Mapbox-navigation-Android. [Online]

Available at: https://github.com/mapbox/mapbox-navigation-Android/blob/master/libAndroid-

navigation-

ui/src/main/java/com/mapbox/services/Android/navigation/ui/v5/route/NavigationMapRoute.java


Global Africa Network, 2017. Gauteng's metors are driving growth and investment. [Online]

Available at: http://www.globalafricanetwork.com/2017/10/12/company-news/gautengs-metros-

are-driving-growth-and-investment


Gómez, M., 2017. Mobile App Development. Software Engineering Course - Summer Semester,

Semantics Scholar.

Google Maps Platform, 2018. Google Maps Platform. [Online]

Available at: https://developers.google.com/maps/terms


Google Maps, 2017. Google Map of the City of Johannesburg. [Online]

Available at: http://www.google.com


Google Play, 2018. Google Play. [Online]

Available at: https://play.google.com/store/search?q=naviagtional%20apps&c=apps&hl=en


40

Independent News Online, 2017. How the time of morning affects commute times. [Online]

Available at: https://www.iol.co.za/motoring/industry-news/how-the-time-of-morning-affects-

commute-times-11213294


Kamboj, D. & Kumar, V., 2016. Optimum Route Selection for Vehicle Navigation. International

Journal of Advanced Computer Science and Applications, 7(2), pp. 142-148.

Kim, D. S., 2003. A dynamic route diversion model on urban freeway OD pattern predicton. Journal

of the Eastern Asian Society for Transportation studies, Volume 5.

Kono, K., Fushiki, T., Asada, K. & Nankano, K., 2008. Fuel Consumption Analysis and Prediction Model

for "Eco" Route Search. New York Ciity, Transport Research Board, p. 9.

Losada, B., Urretavizcaya, M. & Fernández-Castro, I., 2013. A guide to AGILE development of

interactive software with a "User Objectives" driven methodology. Science of Computer

Programming, 78(11), pp. 2268-2281.

Luxen, D. & Vetter, C., 2011. Real-time routing with OpenStreetMap data. Chicago, ACM.

Mapbox, 2018. First steps with the Mapbox Maps SDK for Android. [Online]

Available at: https://www.mapbox.com/help/first-steps-Android-sdk/


Mapbox, 2018. Introducing the Geocoder Library for Android - Points of Interest. [Online]

Available at: https://blog.mapbox.com/introducing-the-geocoder-library-for-Android-b19c191c9c92


Mapbox, 2018. Styling the Map | Android Documentation. [Online]

Available at: https://www.mapbox.com/Android-docs/map-sdk/overview/styling-map/


Mapbox, 2018. The OpenStreetMap data model. [Online]

Available at: https://www.mapbox.com/mapping/osm-data-model/osm-data-model/

[Accessed 26 August 2018].

Marder, A., 2017. Bing Maps vs Google Maps: Comparing the Big Players. [Online]

Available at: https://blog.capterra.com/bing-maps-vs-google-maps/


Martin, J., 2017. Android vs iPhone: which is best?. [Online]

Available at: https://www.techadvisor.co.uk/feature/google-Android/Android-vs-iphone-which-is-

best-3625657/

[Accessed 25 February 2018].

Meng, Z. & Pan, J.-S., 2016. Monkey king evolution: A new memetic evolutionary algorithm and its

application in vehicle fuel consumption optimization. Knowledge-Based Systems, Volume 97, pp.

144-157.

41

Nha, V. T., Djahel, S. D. & Murphy, J. M., 2012. A Comparative Study of Vehicles’ Routing. Dublin,

Institute of Electrical and Electronics Engineers, p. 27.

O'Beirne, J., 2010. A brief comparison of Google Maps, Bing Maps & Yahoo! Maps. [Online]

Available at: https://www.justinobeirne.com/brief-comparison-of-google-maps-bing-maps-yahoo-

maps/


Optimus Information, 2015. Optimus Information. [Online]

Available at: http://www.optimusinfo.com/downloads/white-paper/open-source-vs-proprietary-

software-pros-and-cons.pdf

[Accessed 28 05 2018].

Papinski, D. & Scott, D. M., 2011. A GIS-based toolkit for route choice analysis. Journal of Transport

Geography, 19(3), pp. 434-442.

Perez, S., 2015. Waze Interface Picture. s.l.:Tech Crunch.

Plantin, J.-C., 2018. Google Maps as Cartographic Infrastructure: From Participatory Mapmaking to

Database Maintenance. International Journal of Communication, Volume 12, p. 489–506.

Qingyou, Y. & Qian, Z., 2015. The Optimization of Transportation Costs in Logistics Enterprises with

Time-Window Constraints. Discrete Dynamics in Nature and Society, p. 10.

Rebolj, D. & Sturm, P. J., 1999. A GIS based component-oriented integrated system for estimation,

visualization and analysis of road traffic air pollution. Environmental Modelling & SOftware, 14(6),

pp. 531-539.

Røpke, I., 2003. Consumption dynamics and technology change - exemplified by the mobile phone

and related technologies. Ecological Economics, 45(2), pp. 171-188.

Silveira, G. T. & Change, S.-Y., 2010. Cell phone recylcing experiences in the United States and

potential recycling options in Brazil. Waste Managementr, 30(11), pp. 2278-2291.

Singh, A., Bansal, R. & Jha, N., 2015. Open Source Software vs Proprietary Software. International

Journal of Computer Applications (0975 – 8887), 114(18), pp. 26-31.

Smith, D., 2016. Online interactive thematic mapping: Applications and techniques for socio-

economic research. Computers Environment and Urban Systems, Volume 57, pp. 106-117.

StatsSA, 2013. National Household Travel Survey. [Online]

Available at: http://www.statssa.gov.za/publications/P0320/P03202013.pdf


Storandt, S., 2012. Algorithms for Vehicle Navigation, Stuttgart: Universitat Stuttgart.

Tavares, G., Zsigraiova, Z., Semiao, V. & Caravalho, M. G., 2009. Optimisation of MSW collection

routes for minimum fuel consumption using 3D GIS modelling. Waste Management, 29(3), pp. 117-

1185.

42

Torres, I., 2018. Waze User Interface. Texas: Android Community.

Vincent, J., 2018. 99.6 percent of new smartphones run Android or iOS. [Online]

Available at: https://www.theverge.com/2017/2/16/14634656/Android-ios-market-share-

blackberry-2016


Vithani, T. & Kumar, A., 2014. Modeling the Mobile Application Development. Hong Kong,

International MultiConference of Engineers and Computer Scientists.

Wilhelm, M., Hutchins, M., Mars, C. & Benoit-Norris, C., 2015. An overview of social impacts and

their corresponding improvement implications: A mobile phone case study. Journal of Cleaner

Production, Volume 102, pp. 302-315.

Zaragoza, M., Kim, H. & Han, D., 2016. Mobile Application Development, Approaches, Advancement

and Process. International Journal of Software Engineering and Its Applications, 10(10), pp. 79-88.

Zhu, S. & Levinson, D., 2015. Do people use the shortest path? An empirical test of Wardrop's first

principle. PLOS OONE, 10(8), pp. 1-18.

43

Appendix I – Code

package com.veneshree.masters;

import java.util.List;

/// classes for Android compatibility

import Android.content.Context;

import Android.graphics.Color;

import Android.os.Bundle;

import Android.support.v7.app.AppCompatActivity;

// classes needed to initialize map

import com.Mapbox.geocoder.MapboxGeocoder;

import com.Mapbox.geocoder.service.models.GeocoderResponse;

import com.Mapbox.Mapboxsdk.annotations.PolylineOptions;

import com.Mapbox.Mapboxsdk.plugins.traffic.TrafficPlugin;

import com.Mapbox.services.Android.navigation.v5.navigation.NavigationUnitTy

pe;

// there are two versions of directions criteria so had to include full name

import com.Mapbox.services.api.directions.v5.DirectionsCriteria;

import com.Mapbox.services.commons.models.Position;

import com.Mapbox.services.commons.utils.PolylineUtils;

import com.Mapbox.Mapboxsdk.Mapbox;

import com.Mapbox.Mapboxsdk.maps.MapView;

// classes needed to add location layer

import com.Mapbox.geojson.Point;

import com.Mapbox.Mapboxsdk.maps.MapboxMap;

import com.Mapbox.Mapboxsdk.maps.OnMapReadyCallback;

import Android.location.Location;

import com.Mapbox.Mapboxsdk.geometry.LatLng;

import Android.support.annotation.NonNull;

import com.Mapbox.Mapboxsdk.camera.CameraUpdateFactory;

import com.Mapbox.Mapboxsdk.plugins.locationlayer.LocationLayerMode;

import com.Mapbox.Mapboxsdk.plugins.locationlayer.LocationLayerPlugin;

import com.Mapbox.services.Android.location.LostLocationEngine;

import com.Mapbox.services.Android.navigation.ui.v5.NavigationViewOptions;

import com.Mapbox.services.Android.navigation.v5.navigation.MapboxNavigation

Options;

import com.Mapbox.services.Android.telemetry.location.LocationEngine;

import com.Mapbox.services.Android.telemetry.location.LocationEngineListener

;

import com.Mapbox.services.Android.telemetry.location.LocationEnginePriority

;

import com.Mapbox.services.Android.telemetry.permissions.PermissionsListener

;

import com.Mapbox.services.Android.telemetry.permissions.PermissionsManager;

// classes needed to add a marker – current location and desitiona

import com.Mapbox.Mapboxsdk.annotations.Marker;

import com.Mapbox.Mapboxsdk.annotations.MarkerOptions;

// classes to calculate a route

import com.Mapbox.services.Android.navigation.ui.v5.route.NavigationMapRoute

;

import com.Mapbox.services.Android.navigation.v5.navigation.NavigationRoute;

import com.Mapbox.api.directions.v5.models.DirectionsResponse;

44

import com.Mapbox.api.directions.v5.models.DirectionsRoute;

//

import retrofit.Retrofit;

import retrofit2.Call;

import retrofit2.Callback;

import retrofit2.Response;

import Android.util.Log;

// classes needed to launch navigation UI – use this to see turn-by-turn //

navigation

import Android.view.KeyEvent;

import Android.view.View;

import Android.view.inputmethod.EditorInfo;

import Android.view.inputmethod.InputMethodManager;

import Android.widget.Button;

import Android.widget.EditText;

import Android.widget.TextView;

//classes needed for Navigation

import com.Mapbox.services.Android.navigation.ui.v5.NavigationLauncher;

public

class MainActivity extends AppCompatActivity implements LocationEngineListen

er, PermissionsListener {

// in the main activity, the first step is to creat a variable for the map

view

private MapView mapView;

// variables for adding location layer

private MapboxMap map; //variable for map

private PermissionsManager permissionsManager;

private LocationLayerPlugin locationPlugin;

private LocationEngine locationEngine;

private Location originLocation;

// variables for adding a marker

private Marker destinationMarker;

// these are variables for original and destination cordinates

private LatLng originCoord;

private LatLng destinationCoord;

// variables for calculating and drawing a route

private Point originPosition;

private Point destinationPosition;

private DirectionsRoute currentRoute;

private static final String TAG = "DirectionsActivity";

/// create variable for map route

private NavigationMapRoute navigationMapRoute;

/// these two create button and text box for navigation launch and destination

//input

private Button button;

private EditText DestBox;

private com.Mapbox.services.api.directions.v5.models.DirectionsRoute route;

45

@Override

// This is a new method to create a new instance of the map

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

Mapbox.getInstance(this, getString(R.string.access_token));

setContentView(R.layout.activity_main);

mapView = (MapView) findViewById(R.id.mapView);

mapView.onCreate(savedInstanceState);

// Add user location to the map

Position position = Position.fromCoordinates(2.2869, 48.8590);

// Use this menthod when map is ready to be used

mapView.getMapAsync(new OnMapReadyCallback() {

@Override

public void onMapReady(final MapboxMap MapboxMap) {

map = MapboxMap;

// create a new instance of the traffic plugin and enable the view

TrafficPlugin trafficPlugin = new TrafficPlugin(mapView, map);

trafficPlugin.setVisibility(true); // Enable the traffic view

// enable location and get current position

enableLocationPlugin();

originCoord = new LatLng(originLocation.getLatitude(), originLocati

on.getLongitude());

if (destinationMarker != null) {

MapboxMap.removeMarker(destinationMarker);

} // create a market at current position

// get Long and Lat from the position

originPosition =

Point.fromLngLat(originCoord.getLongitude(), originCoord.getLatitude());

// create instance of a text box to enter values into

final EditText DestBox =(EditText) findViewById(R.id.editText);

DestBox.setOnEditorActionListener(new TextView.OnEditorActionListen

er() {

@Override

// this will run whenever there is anything entered into the text box

public boolean onEditorAction(TextView v, int actionId,

KeyEvent event) {

boolean handled = false;

if (actionId == EditorInfo.IME_ACTION_SEND) {

String search = new String(v.getText().toString());

// Creates variable search and assigns the string in the text box after the enter

or send key is pressed

InputMethodManager imm = (InputMethodManager)

getSystemService(Context.INPUT_METHOD_SERVICE); // this hides the keyboard after

send is pressed

46

imm.hideSoftInputFromWindow(DestBox.getWindowToken(), 0

);

executeSearch(search); // this runs the user created

execute search function using the keyboard input as a variable

handled = true;

}

return handled;

}

});

};

});

}

//user created function that accepts a string as an input variable – does the

reverse geocoding

private void executeSearch(String query){

//create new instance of the Mapbox geocoder with these next few lines

MapboxGeocoder client = new MapboxGeocoder.Builder()

.setAccessToken(getString(R.string.access_token))

.setLocation(query)

.build();

// enqueues the response from the geocoder API in the new Mapbox geocoder instance

client.enqueue(new retrofit.Callback<GeocoderResponse>() {

@Override

//the following method will run whenever a new response is received from the API

public void onResponse(retrofit.Response<GeocoderResponse> response,

Retrofit retrofit) {

// Features, basically, is a list of search results

// get the first one

// get latitude and longitude

// response.body is the full response package. From this, extract the features,

//then the zeroth element and then the latitude of the zeroth element of the above

//queue. This process applies to lat and long

double latitude =

response.body().getFeatures().get(0).getLatitude();

double longitude =

response.body().getFeatures().get(0).getLongitude();

destinationPosition = Point.fromLngLat(longitude, latitude);

//create destination coordinate out of the text search results.

destinationCoord =new LatLng(latitude,longitude);

destinationMarker = map.addMarker(new MarkerOptions().position(dest

inationCoord)); //add marker at the coordinates found above

getRoute(originPosition, destinationPosition); // finds the fastest

route between the origin and desination

altroute(longitude,latitude); // finds the shortest route between

the origin and destination

button = findViewById(R.id.startButton); // create instance of

button and run whenever it is clicked.

button.setOnClickListener(new View.OnClickListener() {

public void onClick(View v) {

Point origin = originPosition;

Point destination = destinationPosition;

47

// Pass in your Amazon Polly pool id for speech synthesis

using Amazon Polly

// Set to null to use the default Android speech

synthesizer

String awsPoolId = null;

boolean simulateRoute = true; //simulates the route to

illustrate turn by turn

//new instance of navigation options to set parameters for navigation

MapboxNavigationOptions navigationOptions =

MapboxNavigationOptions.builder()

.unitType(NavigationUnitType.TYPE_METRIC)

.build();

NavigationViewOptions options =

NavigationViewOptions.builder()

.origin(origin)

.destination(destination)

.awsPoolId(awsPoolId)

.shouldSimulateRoute(simulateRoute)

.navigationOptions(navigationOptions)

.build();

// Call this method with Context from within an Activity

NavigationLauncher.startNavigation(MainActivity.this,

options);

}

});

}

@Override

public void onFailure(Throwable t) {

}

});

}// End executeSearch ///this whole code was for fastest route

//Alternative route takes in the Lat and Log and creates the shortest route between

the input and the origin. This uses Mapbox directions API. This takes in the lat

and long and creates a position from the coordinates. Then a new directions class

is created with that lat and log for the destination and origin and set the profile

to shortest route. The enqueueCall runs when we get a new response.

private void altroute(double lng,double lat){

Position origin =

Position.fromCoordinates(originLocation.getLongitude(),originLocation.getLatitude()

);

Position destination = Position.fromCoordinates(lng,lat);

com.Mapbox.services.api.directions.v5.MapboxDirections DirClient

= new com.Mapbox.services.api.directions.v5.MapboxDirections.Builder()

.setAccessToken(getString(R.string.access_token))

.setAlternatives(true)

.setOrigin(origin)

.setDestination(destination)

.setProfile(DirectionsCriteria.PROFILE_CYCLING)

48

.build();

DirClient.enqueueCall(new Callback<com.Mapbox.services.api.directions.v5.mod

els.DirectionsResponse>() {

@Override

public

void onResponse(Call<com.Mapbox.services.api.directions.v5.models.DirectionsRespons

e> call, Response<com.Mapbox.services.api.directions.v5.models.DirectionsResponse>

response) {

///this section takes the zeroth value in the queue and assigns it to a route

variable. If it returns an exception it turns the navigation button red. Which

means it couldn’t resolve the text.

try {

route = response.body().getRoutes().get(0);

}

catch (Exception e) {

button.setBackgroundResource(R.color.Mapbox_navigation_route_al

ternative_congestion_red);

return;

}

//creates a new polyline and casts it as a list or array of positions. (position is

a variable type)

List<Position> waypoints =

PolylineUtils.decode(route.getGeometry(), 6);

LatLng[] points = new LatLng[waypoints.size()]; // this tells use

number of values in array. Points[i] = the lat and long of each way point of i.

for (int i = 0; i < waypoints.size(); i++) {

points[i]

= new LatLng(waypoints.get(i).getLatitude(),waypoints.get(i).getLongitude());

}

// Draw Points on MapView. Once we have all the points we add a new

line to the map passing through all those points and set it red and create the

width. This is the alternate shortest path route

map.addPolyline(new PolylineOptions()

.add(points)

.color(Color.parseColor("#e52d27"))

.width(5));

}

@Override

public

void onFailure(Call<com.Mapbox.services.api.directions.v5.models.DirectionsResponse

> call, Throwable t) {

}

});

}

//get route is the original fastest route

private void getRoute(Point origin, Point destination) {

NavigationRoute.builder()

.accessToken(Mapbox.getAccessToken())

.origin(origin)

.destination(destination)

49

.build()

.getRoute(new Callback<DirectionsResponse>() {

@Override

public void onResponse(Call<DirectionsResponse> call,

Response<DirectionsResponse> response) {

// You can get the generic HTTP info about the response

Log.d(TAG, "Response code: " + response.code());

if (response.body() == null) {

Log.e(TAG, "No routes found, make sure you set the

right user and access token.");

return;

} else if (response.body().routes().size() < 1) {

Log.e(TAG, "No routes found");

return;

}

currentRoute = response.body().routes().get(0);

// Draw the route on the map

if (navigationMapRoute != null) {

navigationMapRoute.removeRoute();

} else {

navigationMapRoute = new NavigationMapRoute(null, mapVi

ew, map, R.style.NavigationMapRoute);

}

navigationMapRoute.addRoute(currentRoute);

navigationMapRoute.showAlternativeRoutes(true);

}

@Override

public void onFailure(Call<DirectionsResponse> call, Throwable

throwable) {

Log.e(TAG, "Error: " + throwable.getMessage());

}

});

}

@SuppressWarnings( {"MissingPermission"})

private void enableLocationPlugin() {

// Check if permissions are enabled and if not request

if (PermissionsManager.areLocationPermissionsGranted(this)) {

// Create an instance of LOST location engine

initializeLocationEngine();

locationPlugin = new LocationLayerPlugin(mapView, map, locationEngine);

locationPlugin.setLocationLayerEnabled(LocationLayerMode.TRACKING);

} else {

permissionsManager = new PermissionsManager(this);

permissionsManager.requestLocationPermissions(this);

}

}


private void initializeLocationEngine() {

locationEngine = new LostLocationEngine(MainActivity.this);

locationEngine.setPriority(LocationEnginePriority.HIGH_ACCURACY);

locationEngine.activate();

50

Location lastLocation = locationEngine.getLastLocation();

if (lastLocation != null) {

originLocation = lastLocation;

setCameraPosition(lastLocation);

} else {

locationEngine.addLocationEngineListener(this);

}

}

private void setCameraPosition(Location location) {

map.animateCamera(CameraUpdateFactory.newLatLngZoom(

new LatLng(location.getLatitude(), location.getLongitude()), 13));

}

@Override

public void onRequestPermissionsResult(int requestCode, @NonNull String[]

permissions, @NonNull int[] grantResults) {

permissionsManager.onRequestPermissionsResult(requestCode, permissions,

grantResults);

}

@Override

public void onExplanationNeeded(List<String> permissionsToExplain) {

}

@Override

public void onPermissionResult(boolean granted) {

if (granted) {

enableLocationPlugin();

} else {

finish();

}

}

@Override


public void onConnected() {

locationEngine.requestLocationUpdates();

}

@Override

public void onLocationChanged(Location location) {

if (location != null) {

originLocation = location;

setCameraPosition(location);

locationEngine.removeLocationEngineListener(this);

}

}

@Override


protected void onStart() {

super.onStart();

if (locationEngine != null) {

locationEngine.requestLocationUpdates();

}

if (locationPlugin != null) {

51

locationPlugin.onStart();

}

mapView.onStart();

}

@Override

protected void onStop() {

super.onStop();


locationEngine.removeLocationUpdates();

}

if (locationPlugin != null) {

locationPlugin.onStop();

}

mapView.onStop();

}

@Override

protected void onDestroy() {

super.onDestroy();

mapView.onDestroy();


locationEngine.deactivate();

}

}

@Override

public void onLowMemory() {

super.onLowMemory();

mapView.onLowMemory();

}

@Override

protected void onResume() {

super.onResume();

mapView.onResume();

}

@Override

protected void onPause() {

super.onPause();

mapView.onPause();

}

@Override

protected void onSaveInstanceState(Bundle outState) {

super.onSaveInstanceState(outState);

mapView.onSaveInstanceState(outState);

}

}

Documents

Research Project by Veneshree Naidoo Student Number