THE UNIVERSITY OF ZAMBIA SCHOOL OF NATURAL SCIENCES DEPARTMENT OF COMPUTER SCIENCE
THE ZED TRANSIT MAPPING PROJECT OPEN PUBLIC TRANSIT DATA FOR BETTER CITY NAVIGATION
i
BY SIBUSISO NGOMA AND PRINCE SHAMAMBO
CSC 4000 Final Year Project A thesis submitted in partial fulfillment of the requirements for the award of a Bachelor’s Degree of Computer Science.
i
THE ZED TRANSIT PROJECT OPEN PUBLIC TRANSIT DATA FOR BETTER CITY NAVIGATION
BY SIBUSISO NGOMA AND PRINCE SHAMAMBO
i
ZedTransit project – open public transit data for better city navigation. By Sibusiso Ngoma and Prince Shamambo
© 2016 The University of Zambia, School of Natural Sciences, Department of Computer Science
Internal Supervisor (Project Proposal): Mofya Phiri Internal Supervisor (Project Implementation): Mofya Phiri External Supervisor:
October 2016
DECLARATION We, the undersigned hereby declare that the ZedTransit project our own work, that it has not been submitted for any degree or examination in any other university to our knowledge, and that all sources we have used or quoted have been indicated and acknowledged by complete references.
Name: Sibusiso Ngoma Signature: Name: Prince Shamambo Signature: Supervisor Name: MOFYA PHIRI. Signature: ii
ACKNOWLEDGEMENTS All honor and glory goes to Elo-him El Shaddai for granting us the opportunity to pass through University of Zambia. We would like to express our gratitude to our families and to the Department of Computer Science (All members of staff) at the University of Zambia. We would not want to forget those of our friends and advisors who have also contributed to this paper. Lastly we thank our supervisor for the resourceful advice and instructions.
DEDICATION We dedicate this thesis to all Zambians in particular Lusaka residents. Hoping that this information may be used to better the public transport system in the city.
1
FIGURES TABLE Figure 1 : An entity relationship diagram of the GTFS dataset ............................................................. 16 Figure 2: A successful validation by feedvalidator ................................................................................ 28 Figure 3: HTML report produced by feed validator .............................................................................. 29 Figure 4: Screenshot of route testing using schedule viewer ............................................................... 30 Figure 5: Screenshot of a visual of the routes from indiemapper ........................................................ 31 Figure 6: Screenshot of the prototype Transit map produced for Lusaka using adobe illustrator ...... 32 Figure 7: Screenshot of a route being tracked using TransitWand ...................................................... 34 Figure 8: Screenshot of a route being tracked using OSMand ............................................................. 35 Figure 9: Screenshot of a route being tracked using MyTracks ............................................................ 36 Figure 10: Screenshot of Transit App interface .................................................................................... 52 Figure 11: MOOVIT user interface ........................................................................................................ 53 Figure 12: Google Maps user interface ................................................................................................. 55 Figure 13: Ally App user interface ......................................................................................................... 57 Figure 14: City Mapper mobile application user interface ................................................................... 59 Figure 15: City Mapper web application user interface ....................................................................... 60 Figure 16: RouteSout user interface ..................................................................................................... 61 Figure 17: Showing the system architecture. ....................................................................................... 67 Figure 18: The traffic feeds database ................................................................................................... 69 Figure 19: System Domain model for both Web and Android Application .......................................... 72 Figure 20: Sequence diagram showing how a bus route is fetched and displayed .............................. 73 Figure 21: General sequence diagram showing how a bus stop is located on the system .................. 74 Figure 22: Sequence diagram showing how a route is displayed between two bus stops. ................. 75 Figure 23: Screenshot showing the Trip planner and routing page without an inputted values. ........ 76 Figure 24: Results after user input. ....................................................................................................... 76 Figure 25: Results of the user’s current location after clicking the ‘my location’ button .................... 77 Figure 26: ZedTransit traffic dashboard ................................................................................................ 77 Figure 27: Results of the find search places page. ................................................................................ 78 Figure 28: Home page of the ZedTransit App ....................................................................................... 79 Figure 29: Navigation and Map page of the ZedTransit App ................................................................ 79
2
3
Table of Contents ACKNOWLEDGEMENTS ................................................................................................................ 1 DEDICATION .................................................................................................................................... 1 FIGURES TABLE .............................................................................................................................. 2 ABSTRACT ........................................................................................................................................ 6 CHAPTER 1 .............................................................................................................................................. 7 1 INTRODUCTION ................................................................................................................................... 7 1.1 Project Background ....................................................................................................................... 7 1.2 PROBLEM STATEMENT ......................................................................................................... 10 1.3 AIMS........................................................................................................................................... 10 1.4 OBJECTIVE ............................................................................................................................... 11 1.5 SCOPE ........................................................................................................................................ 11 CHAPTER 2 ............................................................................................................................................ 13 2 LITERATURE REVIEW AND METHODOLOGIES .................................................................................. 13 2.1
What is Public Transit data? ............................................................................................. 13
2.2 What is open source data ........................................................................................................ 14 2.3
What is General Transit Feed specification? .................................................................... 14
2.4 RESEARCH METHODOLOGIES............................................................................................. 24 2.4.1 Data Collection ........................................................................................................................ 24 2.4.1.1 Identifying already existing routes ........................................................................................ 24 2.4.1.2 Physical data collection ......................................................................................................... 25 2.4.2 Data Formatting ....................................................................................................................... 26 2.4.3 Developing General Transit Feed Specification data ........................................................... 26 2.4.4 Map Development ................................................................................................................ 30 2.5 REVIEW OF POSSIBLE DEVEOPMENT TOOLS AND SOFTWARES ............................... 33 2.5.1 Possible Data collection tools .............................................................................................. 33 2.5.1.2 OSMand ............................................................................................................................ 34 2.5.2 Possible data editing tools .................................................................................................... 37 2.5.3 Possible Transit Map development tools ............................................................................. 39 2.6 POSSIBLE WEB TECHNOLOGIES ..................................................................................... 41 2.7 POSSIBLE ANDROID APPLICATION TECHNOLOGIES ................................................ 44 2.8 RELATED PROJECTS .......................................................................................................... 45 2.9 RELATED SYSTEMS AND APPLICATIONS .................................................................... 50 CHAPTER 3 ............................................................................................................................................ 62 3 REQUIREMENTS ANALYSIS .................................................................................................... 62 4
3.1 Software Development Methodology ..................................................................................... 62 3.2 Development Tools Used ........................................................................................................ 62 3.3 Requirements and Constraints ................................................................................................ 63 3.4 Functional Requirements ........................................................................................................ 64 3.4.1 The Navigator or User Requirements .................................................................................. 64 3.5 Non Functional Requirements ................................................................................................ 65 CHAPTER 4 ............................................................................................................................................ 66 4 SYSTEM DESIGN ........................................................................................................................ 66 4.1 System Architecture ................................................................................................................ 66 4.2 System Algorithm Flow Chart ................................................................................................ 68 4.5 User Interface Design.............................................................................................................. 69 4.6 Database Design...................................................................................................................... 69 CHAPTER 5 ............................................................................................................................................ 70 5 SYSTEM DEVELOPMENT ......................................................................................................... 70 5.1 Use Case Text for the Requirements ....................................................................................... 70 5.2 Domain Modelling .................................................................................................................. 71 Domain Sequence diagram of the web and android applications ................................................. 72 5.3 Sequence Diagrams ................................................................................................................. 73 5.4 Screen Shots of web application ............................................................................................. 76 5.5 Android Application screen shots ........................................................................................... 79 CHAPTER 6 ............................................................................................................................................ 80 6 TESTING AND VERIFICATION ................................................................................................ 80 6.2 Analysis of Test Results .......................................................................................................... 80 CHAPTER 7 ............................................................................................................................................ 82 7 CONCLUSION .............................................................................................................................. 82 7.1 DISCUSSION ......................................................................................................................... 82 7.2 RESULTS AND ANALYSIS ..................................................................................................... 84 7.3 Limitations and Problems ....................................................................................................... 86 7.3.2 Challenges in the application development process............................................................. 87 7.3.3 Challenges in the Transit Map development ........................................................................ 87 7.4 Future works and Recommendations ...................................................................................... 87 References ............................................................................................................................................ 88 APPENDICES .................................................................................................................................. 94 APPENDIX 1 ................................................................................................................................ 94 APPENDIX 2 ................................................................................................................................ 94 5
APPENDIX 3 ................................................................................................................................ 96
ABSTRACT Smart cities around the world are built on the availability of information concerning the city, such information could include transit. Unfortunately for many developing cities around the world, transit information does not exist or is not open to the public. As a result developing cities have little or no real time transit intelligent systems to help people in transiting their city. The city of Lusaka has not been an exception in the unavailability of its transit information. This study used the capability of mobile technology (cell phone GPS and GPS trackers) to collect real time information on Lusaka's transit system and determine whether the collected data could be standardized into a formal structure that would be made open source and readily accessible. The format chosen to standardize the Lusaka transit data was GTFS. General Transit Feed Specification. [1]The General Transit Feed Specification (GTFS) defines a common format for public transportation schedules and associated geographic information. GTFS "feeds" allow public transit agencies to publish their transit data and developers to write applications that consume that data in an interoperable way. The study sort to illustrate 1) How Lusaka’s transit data would be standardized and the need to have standardized transit data. 2) How to apply the standardized General Transit Feed Specification data of Lusaka to provided real time information on transit and developing of transit applications to ride on this data. 3) How to develop a platform through which the public can share current traffic trends in the city.
6
CHAPTER 1 1 INTRODUCTION
1.1 Project Background Having a smart city is a dream for every city planner and citizen. However to turn a city into a smart city various things need to be done. E.g. The transportation system needs to be digitalized. The transit system needs to be clearly mapped and documented. Access to data is part of a broader agenda of leveraging technology and analytics to make cities including their transit systems “smart” [2]. The whole concept of a smart city is all centered on communication between electronic devices, and hailed as transforming how we will live our lives, this could be smart healthcare, smart sewers, smart buildings and smart transport. This paper focuses on smart transport and how we can make transport data in Lusaka open source for the development of mobile and web based systems to assist in transiting around the city. For millions in the developing world, citywide transportation options are often limited to semiformal networks of bus or minibus operators [3]. Often referred to as paratransit, these systems constitute the backbone of mass transit for the majority of citizens in the rapidly growing cities of Africa, Asia and Latin America. Semi-formal bus networks are composed of many private actors which, like taxis, operate for profit and are owned either by the drivers themselves or by businesses of varying size. Due to the rapid growth in the population of major cities around the world, [4]it is imperative to improve potential riders’ satisfaction with public transportation, because of its societal benefits. Transit provides mobility to those who cannot or prefer not to drive, including access to jobs, education and medical services. Studies have shown that having a good system of [5]Transit reduces congestion, gasoline consumption and the nation’s carbon footprint. This is due to the fact that more people will prefer to ride on public transport (buses and trains) than on their own automobiles, hence having more people in one automobile than those same people in different automobiles but going to the same place. A practical example would be, if a bus has a capacity of 16 people and a private vehicle has a capacity of 5 people, we will require 3 private vehicles to transport 16 people as opposed to one bus transporting 16 people. This will lead to more vehicles on the road. 7
Public transit in the form of semiformal mini-buses has seemingly been popular among developing cities. However, little to no digital information is typically available on routes, bus stops, passenger boarding, service frequency or scheduled trip times [6]. Cities that rely on these bus systems can benefit from the generation of digital data on these systems for planning and passenger information purposes. Perhaps more importantly, this data can provide the ability to generate citizen-based information tools, such as transit routing applications for mobile devices widely discussed in the smart cities dialog. In Nairobi, Kenya a project called Digital Matatu sponsored by Columbia University, MIT and University of Nairobi and Groupshot Design Consultancy having seen the importance of having documented open source transit data [7]sent researchers with smart phones around the Kenyan capital city to collect data on some 130 matatu routes, covering more than 3,000 stops. The open-source data was transformed into a stylized paper map, now widely popular, and used to create a searchable transit function in the popular Google Maps application. Digital Matatu used cell phone technology to collect transit information they say [6], “through our work in Nairobi, this paper shows that cell-phone technology that is ubiquitous in most countries can be used to generate a dataset in an open standard, GTFS. Citizens can then leverage open source tools made for that standard, enhancing access to information about the transit system. We argue that one of the most important components of our work in Nairobi was the engagement process that created trust in the data and knowledge of its existence for the development of civic technologies. The lessons learned in Nairobi can be translated to other areas with the potential to use mobile applications to develop data on essential urban infrastructure and to extend the use of that data by sharing it with a larger community.” For the quote extracted from Digital Matatu, it can be observed that the beginning of smart cities and intelligent transit information systems is the availability of transit data. In recognition of Transit data Google have come up with a standard format in which Transit data can be represented called GTFS. A definition dabbed from the GTFS web pages defines it as The General Transit Feed Specification (GTFS) defines a common format for public transportation schedules and associated geographic information. GTFS "feeds" allow public transit agencies to publish their transit data and developers to write applications that consume that data in an interoperable way [8].
8
Apart from Nairobi, Kenya a few other cities that have opened their transit data into GTFS. Sao Paulo and Mexico City are two more cities that have standardized their transit information into GFTS. The opening of transit data in these two cities has brought about the development of intelligent transit applications on the market. An extract from the website TheCityFix read as follows: ”While the move towards open data remains a struggle, some developing cities have opened their GTFS with positive results [9]. For example, Sao Paulo has had a functioning GTFS since 2009, but chose to make it public in 2013 when they opened it to developers. Shortly after, several transit apps entered the market, such as Moovit, which claims to have 400,000 users in Sao Paulo. Another example is Mexico City, which developed and opened their GTFS feed in 2013, covering all publicly operated modes (Metro, RTP buses, STE, Metrobus, Tren Suburbano). However, despite its extensive coverage, Mexico City’s data does not contain information on the approximately 30,000 microbuses that carry a bulk of the demand (8.7 million trips a day). This was not a matter of oversight—collecting data from informal modes like microbuses is not an easy task.” The citation from the magazine site TheCityFox is just proof of the importance and value addition of having open source transit data. Narrowing down to Lusaka’s public transport system. Lusaka’s Public Transport system is mainly comprised of Mini-Buses [10](small buses seating a capacity of 14 to 16 passengers). It also consists of Taxis which are costly to ride on but no railway system exists. The infrastructure of the transport system includes bus stations, bus stops and bus routes. Every route has its origin in either the townships or suburbs into the main Bus Station in the Central Business District. Currently on the council documents there are 4 major bus stations in Lusaka, namely Kulima Tower, City Market, Millennium and Intercity Bus Station. The road network of Lusaka does not follow a regular pattern, it is mainly radial leading into the Central Business District. According to the Lusaka City Council there are major five (5) road plus Kanyama that lead into the Central Business District. The authorities responsible for Route Network Planning are the Lusaka City Council and the Road Transport and Safety Agency (RATSA). Bus routes are formalized through requests from residents through the councilors or the Ward Development Committees and where Lusaka City Council sees need. 9
The Bus Terminals have no proper outlined system and information of the infrastructure of the whole transport system is unavailable to the public. Due to the unavailability of information and tools to aid in the transiting of the city Lusaka’s transit is so tedious and unfriendly to navigate. This project seeks to solve some of the problems been experienced which have been highlighted. These problems include the unavailability of transit information and tools such as applications to assist commuters in making informed decisions on how to move around the city.
1.2 PROBLEM STATEMENT How can mobile devices be leveraged to collect Lusaka’s informal public transit information in a bid to establish, how this transit information of an informal bus system can standardized to General Transit Feed Specification, which can be used by urban city planners to design transit maps, government organizations and developers to develop routing and trip planning applications?
1.3 AIMS The ZedTransit project seeks to see how best navigating Lusaka using public transport can be improved by: ● Illustrate how we can leverage Cellphones for Way finding and Journey Planning in Lusaka’s Semi-formal Bus Systems by making Lusaka’s transit data open source. ● Illustrate how Lusaka’s transit data can be formatted into the universally accepted transit data format GTFS. ● Illustrate how to use GTFS data in developing a Transit Map for the city of Lusaka. 10
● Build an Application that will ride on the General Transit Feed Specification. ●
Offering a platform crowdsourcing of traffic feeds can improve transit.
1.4 OBJECTIVE This project’s set objects seek to achieve the primary aim of the project which is using mobile devices for way finding and journey planning. Through the project we will: ● Collect transit data using mobile technology and develop A transit map for the city of Lusaka ● Clean the collected data so as to come up with a transit format to represent Lusaka’s Transit Data. ● Use the open data format General Transit Feed Specification to represent Lusaka’s Transit Data. ● Validate and make open source Lusaka’s General Transit Feed Specification Data. ● Update the Google maps image of Lusaka to include Transit data. ● Develop applications (similar to trip planners), a web and android application that will make use of the transit data from the Google Servers.
1.5 SCOPE The project has a tight but wide scope to achieve the objectives and aims. The bounds of the project are: 1.
Data collection of at most 80 percent of the actual designated routes in Lusaka. These routes are the major routes that cover all four divisions of Lusaka.
2.
We have chosen to tackle at least 80 percent of Lusaka’s designated routes out of the over 50 bus routes in Lusaka due to a number of constraints on our part. These are: ● Limited financial resources ● Limited man power to adequately cover all the routes accurately and without error. ● The limited time frame we have between data collection, data editing, standardization to GTFS and Application development. 11
3.
Develop a web and mobile transit application. These applications will be used for way finding, journey planning and knowing the current traffic updates.
4.
The project will develop a prototype of a Transit Map for Lusaka.
12
CHAPTER 2 2 LITERATURE REVIEW AND METHODOLOGIES In this section of the paper we look at previous research done on the technologies used in this project in Zambia and Internationally. The main technology and main aspect of the entire project is the use of Public Transit data in the form of General Transit Feed specification and how this data can be made open source data. We will zoom in on what really General Transit Feed Specification (GTFS) is and the genesis of it. We will also look at what open source data is and the importance of having open source data in the form of Transit feeds. We will address these three aspects in the form of three (3) questions. These are: 1. What is Public Transit data? 2. What is open source data? 3. What is General Transit Feed Specification Data?
2.1 What is Public Transit data?
According to the oxford dictionary Public can mean open to or shared by all people in a community or country [11]. Transit or Transportation means a system or means of conveying people or goods from place to place [12]. Hence combining the two public transport would mean the means and ways of transport that are available to the public. They are various forms of public transport these range from cars, commuter trains, van pool services, paratransit services for citizens with disabilities, subways, ferries and water taxis [13]. Depending on the country you are in you are able to find different forms of public transport. Public Transport Data (Information) is just the information concerning a particular kind of public transport system. This information can range from the routes available, the stops available and the trips. Where to catch your public transport is other information too. In developed countries this information is available but in most developing countries this information is not readily available. This is the essence of such projects. To ensure that this information is kept up to standard even after making it open source 13
data a universal standard called GTFS was introduced. It is discussed later on in the paper.
2.2 What is open source data
Open data would mean any piece of content or data that is free to use, reuse, and redistribute — subject only, at most, to the requirement to attribute and share-alike.” Generally, this means that the data should be released in a format that is free of royalties and other IP restrictions [14]. There has been a call to make Public transport information of cities open data. This will help improve a number of aspects it can benefit public transport users by improving journey experience, users can save on time because they know exactly where to catch a ride [15]. The economy benefits through innovation and competition, skilled employment and new business opportunities for third parties and developers hence increasing country revenue [15]. In a bid to make public transport information open data the General Transit Feed Specification was developed. 2.3 What is General Transit Feed specification?
The General Transit Feed Specification is a specification that defines a common format for public transportation information which include schedules, routes and other geographic information [16]. GTFS enables public transit agencies publish their transit data. This transit data can then be used by developers, city planner and the general public. Developers use GTFS to write trip planner applications, while city planner can use the GTFS to plan the transit network of a city. The GTFS feeds are represented in a series of text files that are compressed into a ZIP file [16]. The files include information such as fixed route schedules, routes, and bus stop GIS data. GTFS datasets are used in a variety of types of applications, including trip planner such as Google Maps, mobile applications, timetable generation software, tools for transit planning and operations analysis, and other categories of applications [16] [17].
14
GTFS data is stored in Comma Delimited Files (CSV). [18]CSV file were chosen as the standard format for GTFS because it is easy to view and edit the data in CSV file using spreadsheet documents and Text editors which is helpful for small agencies seeking to come up with their own GTFS. It is also easy to generate from most programing languages and databases which is good for larger publications. Diagram 1.0 shows the GTFS data model.
15
Figure 1 : An entity relationship diagram of the GTFS dataset
16
2.3.1
Background History of GTFS
GTFS has not always been there. [19] It took the initiative of TriMet of Portland, Oregon. TriMet is a transit agency based in Portland, Oregon. In 2005 TriMet approach Google and a few other platforms with the view of making their Transit data available on those platforms [19]. Google were the only platform that responded to TriMet, this partnership saw a new beginning in the public Transport world. TriMet and Google faced some challenges in maintaining sustainable data, in order to provide quality trips, the trip planner would need quality transit schedules, routes, and stop data in an electronic format that was constantly up-to-date [16]. TriMet worked with Google to format their transit data into an easily maintainable and consumable format that could be imported into Google Maps [16]. In 2005, TriMet and Google launched the Transit data into what was called Google Transit [19]. GTFS then Google Transit Feed Specification, became the standard for all Transit information. If a Transit agency wished to make its Transit data open source they had to format their data into Google Transit Feed Specification. Google Transit data continued to grow as more agencies saw the need to make their Transit data open source. [16]Since its creation in 2005, GTFS has become the most popularly used data format to describe fixed-route transit services in the world. Many agencies have decided to share their GTFS data openly with the public, while others choose to restrict access only to select partners (e.g. Google Maps). Application developers have also noticed the use of GTFS, hence they have now began to develop systems and services based on GTFS data. Because of the widespread use of GTFS it has now been changed to General Transit Feed Specification. Third party software’s have been developed for various uses, these include trip planners, Transit maps, timetable creation, mobile data and even providing real time Transit data.
17
2.3.2 Importance of General Transit Feed Specification
General Transit Feed Specification plays a very critical role in the development of a good and available Transport network. They are many areas of application of General Transit Feed Specification. Important areas are discussed further.
Trip planning and maps – they are a number of trip planning apps and websites that include transit information obtained from GTFS to make transit information accessible, and reach as many customers as possible [20]. One example is Google Maps Trip Planner, Google offer Transit agencies the ability to upload their Transit data through the Google Transit Partner Program [20]. Another trip planning service is Open Trip Planner, this is an open source multimodal trip planner and analysis system [20]. Open Trip Planner provides a range of passenger information and transportation network analysis features using infrastructure for finding itinerates combining transit, pedestrian, bike, and car segments [21]. Bing Maps, this is a map service run by Microsoft, they recently began offering Transit information for a handful of Cities in 2010. Bing uses GTFS data which in incorporates into its Maps and offers trip planning services. Other trip planner systems include MapQuest, Rome2rio, Hopstop etc [20].
Ridesharing –”Some transportation organizations are interested in helping people connect with ridesharing opportunities. Ridesharing, also commonly called “carpooling,” is when two or more individuals share a private automobile to make the same or similar trip (to one or nearby destinations). Ridesharing can supplement public transportation services, and can reduce single-occupancy vehicle trips. There is emerging software that allows people to search for fixed-route transit services and rideshare opportunities through one interface [20].”
Data Visualization - GTFS data has enabled the visualization of Transit networks on maps. With the Geographic Information System (GIS) data it contains, software’s
18
have been developed to help in visualization. ArcMap is one such tool that enables visualization using the GTFS visualizer extension [22]. Maps have also been developed using GTFS data. The system of Nairobi under the digital matatu project developed a Transit map [22]. In Cairo a group of mappers have also developed a Transit map for their city [23].
Improved Transport network – with the help of GTFS data Urban City planners are able to have an overview of the transport network in a city and how they can improve it. For developing cities like Nairobi city planners for the first time were able to identify areas in the city that had no bus services.
2.3.3 Composition of GTFS
As has been shown from the diagram, GTFS is composed of various files. Some files are mandatory while others are optional. This files co-work together in order to provide the required output. The following are the files and there purpose in the GTFS format. 2.3.3.1 Route.txt (Required file)
The routes.txt is the list of basic information of the routes.
route_id is a unique number assigned to each route. The coding rules is flexible, which can be defined by the data collector.
agency_id should be consistent with the agency.txt file.
route_short_name will be filled with the route number.
route_long_name will be filled with the “origin – destination” information.
route_type are all set to 3 as all the routes are bus lines.
19
route route
agenc
route_short
route_long_n route_d
route_t
route_ _col
route_tex
_id
y_id
_name
ame
ype
url
t_color
esc
or
CAU RAO CD
BC 1
1 DU NGHIA
3
BEN BINH TT VINH BT
BC 2
2 BAO
3
BUU DIEN BD
BC 3
3A DO SON
3
KHACH SAN DAU KHI - DO KD
BC 4
3B SON
3
2.3.3.2 Agency.txt (Required) The agency.txt is the list of all the bus company information. The attributes are straight forward. Agency_id
Agency_name
ZedTransit(UNZA) ZedTransit(UNZA)
agency_url
agency_timezone
http://unza.cs.zm
CAT
2.3.3.3 Stop.txt The stops.txt is the list of all the stops information in the city area.
stop_id is a unique number assigned to each stop. The coding rules is flexible, which can be defined by the data collector.
stop_id
stop_name this is the name of the actual name of the specified stop.
stop_lat/stop_lon this is the column that defines the geolocation of the particular stop.
stop_code
stop_nam
stop_
e
desc
stop_lat
stop
zon
stop_
location_
direc
_lon
e_i
url
type
tion
position
20
d S1
45.4205
122.
95
676
Arcades
S2
45.4193
122.
86
665
UNZA
Marshland S3
45.4207
122.
03
675
s
2.3.3.4 Trip.txt
The trip.txt is the list of all the trips in all routes. For example, Bus line 1 runs between A to B, then there will be two trips for this route, one is from A to B, and the other one is from B to A. Trip.txt here is basically presenting the information for each direction of each route. Please see the data template in a separate file.
route_id
service_id
trip_id trip_headsign
direction_id block_id shape_id
R1
FULLWEEK T1
Konga
0
11
R2
FULLWEEK T2
Chilenje
1
12
R3
FULLWEEK T3
Kamwala
0
21
R4
FULLWEEK T4
Chelstone
1
22
2.3.3.5 Calender.txt
calendar.txt is the definition of the service days in a week. It is connected with trips.txt via service_id. Since the buses are running for all days, there is only one record for calendar.txt as below.
service_
monda tuesda wednesd
thursda frida
saturda sunda start_da
end_da
id
y
y
y
te
y
ay
y
y
te
21
2.3.3.6 Shape.txt
shapes.txt is a list of the GPS points of each route. It helps to present the geographic alignment of the route on base maps.
shape_id is the unique number for each shape. It is linked to trips.txt to identify the alignement for each trip.
shape_pt_lat and shape_pt_lon are the coordinates for each GPS points in the shape. These points are collected by the application been used to track the routes. They can be obtained from the shape file.
shape_pt_sequence is the order of the points in each alignment shapes.
shape_id
shape_pt_lat shape_pt_lon
shape_pt_sequence
shape_dist_traveled
170517
45.52291
-122.677372
1
0
170517
45.522921
-122.67737
2
3.7
170517
45.522991
-122.677432
3
34
170517
45.522992
-122.677246
4
81.5
170517
45.523002
-122.676567
5
255.7
170517
45.523004
-122.676486
6
276.4
170517
45.523007
-122.676386
7
302
170517
45.523024
-122.675386
8
558.4
170517
45.522962
-122.67538
9
581
170517
45.522922
-122.675383
10
595.6
170517
45.52288
-122.675394
11
611.2
170517
45.522703
-122.675478
12
679.2
2.3.3.7 Stop_times.txt
Stop_times.txt is the most important information in GTFS data set. It records the stops sequence in each route and the stop times at each stop throughout the day. 22
trip_id is consistent with the one in trip.txt which presents the trip that this stop_time record belongs to.
arrival_time is the list of the arrival time at this specific stop throughout the day.
departure_time is the list of the departure time at this specific stop throughout the day.
stop_sequence is the order of the stops in each trip, the order number can be simply as 1,2,3,4…
arriva trip_i
l_tim
departur
stop stop_se
stop_he
pickup drop_of shape_dist
time
d
e
e_time
_id
adsign
_type
point
3963
6:47:
496
00
3963
6:48:
496
18
3963
6:50:
496
13
3963
6:52:
496
11
quence
f_type
_traveled
131 6:47:00
70
1
763 6:48:18
1
2
762 6:50:13
5
3
761 6:52:11
2
4
23
2.4 RESEARCH METHODOLOGIES The transit mapping project can be divided in processes based on the objectives documented. The various processes of the Transit mapping project incorporated different methods and technologies to achieve the objectives set. The stages include: 1. Data Collection 2. Data Formatting 3. GTFS development 4. Map development 5. Web and Mobile application development
2.4.1 Data Collection The data collection process involved a. The identification of already existing routes b. The physical boarding of public buses with mobile devices and notebooks to aid in documentations.
2.4.1.1 Identifying already existing routes Before we could go out on our own to physically collect data on the Lusaka routes, we visited a number of local authorities in Lusaka. This was to establish if at all the Lusaka City Council, Ministry of Transport and the Road Transport and Safety Agency had any documentation on the Transit system in the city of Lusaka. The Zambia Institute of Policy Analysis and Research was also visited to establish if any research had been done on the Transport Network system in Zambia. From the visits to these institutions it was difficult to get hold of Lusaka’s transit GIS data documented well because: 1. These institutions were not open to availing the data they had which is outdated.
24
2. Most of these institutions did not have proper documented GIS data on the layout of Lusaka’s transport system. They do don’t have documents of stop locations and route shapes. Upon concluding on the institutions we opted to go directly to the main bus stations in Lusaka which are Kulima Tower, Lumumba, Millenium and City Market. The purpose of this approach was to get direct information from the actual bus drivers, though they did not have documented information but there information was more valuable than from the regulatory institutions. The information collected from these places included mainly the route names of the Lusaka. It was discovered that these stations shared routes but also had their own unique routes. A total of about 35 routes were identified. These are the routes that start from the city center. From the research work done by ZIPAR a total of approximately 50 routes were recorded. These are routes both from the city center and outside. This information gave us the ground break of the data collection that we were supposed to do. Some challenges were observed by the bus drivers included: 1. Most bus drivers complained about the unavailability of Route information to them. They suggested a more centralized location to find all information about the Lusaka routes. 2. The drivers suggested that this information be made open source even to passengers.
2.4.1.2 Physical data collection Upon the evolution of the already existing data about Lusaka’s transit network it was established that we conduct refresh data collection which included GIS data so as to come up with new fresh and up to date data about Lusaka’s transport network. 25
The data collection was done by the physical boarding of buses from the main bus stations and following them to their end destination. This process was done with the aid of software tools that were able to capture GIS data at a particular point using GPS. They are a variety of tools which are explained later in this paper but we only picked two tools to work with these are OSMand and Transitwand. OSMand provided easy exportation of the tracked polyline route in GPX format to open street maps and GPS visualizer for visualization and editing. The operations of these two applications is explained in detail below. 2.4.2 Data Formatting Upon the collection of raw GPS data, this data had to be formatted for easy understanding and visualization. The raw GPS data included the bus stop points and the shapefiles in GPS exchange (GPX). Just like in data collection they are a variety of software applications that can be used to assist in formatting the collected data. A detailed description of the different software applications is given later in this paper. The applications used in this project were GPS visualizer and Excel spreadsheet.
2.4.3 Developing General Transit Feed Specification data Your methodology in developing GTFS data is something you have to critically think through. They are so many ways and tools out there used to develop GTFS data. The possible tools are discussed in the methodology section. This section of this paper seeks to explain the methods and tools we used to develop a complete GTFS dataset. It will also suggest other approaches to developing GTFS data for a city. The approach we took was: 1. Devise a GTFS protocol to use in identifying and documenting the collected routes. 2. Analyze the collected data and correct errors if there was need to and Form ids of routes and stops to create specific GTFS dataset files. 26
3. Data Validation 2.4.3.1 The GTFS design protocol The protocol in developing GTFS data are just the steps taken to come up with the final end product. This steps may not necessarily be compulsory but to achieve uniformity throughout the project some protocol needs to be established. When conducting this project we first sort to collect all the data. All the data meaning all the bus routes and stops along the routes we picked out. Though it would have been no harm to collect data on certain routes and then immediately develop GTFS datasets for those routes but we sort to finish the whole data collection process and move on to the next phase of the project. We chose this routine because of the limited time we had in collecting the data. Some of the tools used in the data collection process were borrowed these tools were Samsung Tab 2s and one GPS unit tracker, hence we were bound to finish our data collection and return the tools we borrowed. 2.4.3.2 Analysis of collected data and allocating of IDs Using the methods discussed in the previous section raw data was collected. This raw data included the bus route geo coordinate lines and the bus stop coordinate points. Using the tools discussed in the data formatting section we were able to retrieve the coordinate points from the .shp and gpx files. This retrieved data was then arranged in the GTFS data formate. Each route was given a unique ID (Identifier). The route IDs were simple R_XX. Where R stands for Route and XX stands for the route number. Each route had a start point and an end point marked as one complete trip, each Trip had a return trip. According to the GTFS standard each trip was given a unique Trip ID the naming system for the Trip IDs was TA_XX or TB_XX, where T stands for Trip and ‘A’ or ‘B’ stands for the direction of the trip. ‘A’ showing the Start to the End and ‘B’ showing the end to the start point. The XX represented the route code number which was given in the routes.txtx file. The stops geolocations were placed in a stops.txt file. Mapped to the coordinated is the stop name and the unique identifier of the stop. The stop identifier S_XX , where S simply means stop and XX means the stop number.
27
2.4.3.3 Data Validation and GTFS testing Google and the agencies that have been instrumental in the development of GTFS data have developed open source tools and software to help contributors to GTFS data validate and correct error in there datasets before publicizing it. This tools are open source and include feed validator and schedule viewer. Feed Validator is a command line tool built in python that counter checks a GTFS feed for errors and generates an HTML reports describing the error detected in the feed. By running this tool on your transit data feed and fixing the issues that it finds can save you from display and routing problems down the road [24]. Google provides an executable windows version of feed validator on github [24]. To use feed validator a user has to drag a GTFS zipped file or directory onto the feedvalidator.exe. A command line window pops up showing the validation test results. Below is a snapshot of a result after dragging the GTFS feed onto feedvalidator.
Figure 2: A successful validation by feedvalidator
28
Figure 3: HTML report produced by feed validator
Schedule viewer is a Python program used for viewing the contents of a GTFS feed on a map [25]. It's a diagnostic program intended for those creating a feed, it enables the visualization of each route and each stop on a map. Google Transit provides the schedule view tools on github. Below is a snapshot of schedule viewer.
29
Figure 4: Screenshot of route testing using schedule viewer
2.4.4 Map Development The GTFS data that was developed was to be used in the development of a Transit Map for the city of Lusaka. There were different tools used in the development the Transit map these wer indiemapper and adobe illustrator. The following were the steps we followed in developing the transit map: 1. Visualization of the routes collected using indiemapper. 2. Design transit routes using adobe illustrator. 2.4.4.1 Visualization of routes tracked The information collected on the routes had to be displayed on a base map for the development of a Transit map to begin. Indiemapper is on such tool that enabled the visualization of each route from the geospatial data collected. The file containing the geospatial information was exported into the online web based indiemapper application to produce polyline routes as shown in the figure below.
30
Figure 5: Screenshot of a visual of the routes from indiemapper
The figure shows routes (blue lines) and stops (red dots). From the visualized image it can be noted that Lusaka has a radial transport system, all routes converging at the city center. Indiemapper provides saving of images produced in .svg file format. This file format is easily exported into adobe illustrator for further editing. SVG stands for Scalable Vector Graphics. 2.4.4.2 Design of Transit Map in Adobe illustrator The second step in the development of the Transit Map is exporting the .svg file from indiemapper to adobe illustrator. In Adobe illustrator the following steps were followed: 1. Giving color codes to each route for easy drawing and identification. 2. Trace each polyline route with the color code line and convert each polyline route a 45 and 90 degree angles. The color codes given are based on the designer’s discretion and the angles are based on the route traces. 31
Below is the final end product of the Transit Map in adobe illustrator.
Figure 6: Screenshot of the prototype Transit map produced for Lusaka using adobe illustrator
32
2.5 REVIEW OF POSSIBLE DEVEOPMENT TOOLS AND SOFTWARES In the approach and progression of this project there were a number of technologies used to come up with the finished products of this project. These technologies include 3rd party applications, programing languages. As the project had 3 phases which were the data collection, the Transit map development and the web, mobile application development. Various technologies were used in each phase. 2.5.1 Possible Data collection tools They were a variety of tools that would have been used for the data collection process. Each tool is explained in detail. . 2.5.1.1 Transitwand Transitwand is an open source web and mobile application for collecting transit data. It is used to create GTFS feeds, capture passenger counts and generate GIS datasets [26]. It is considered to be one of the simplest Transit data capturing applications. It allows a user to capture a trip, which will record the GPS coordinates as you ride public transport. It also allows a user to mark points of the trip such as stops, you can mark the stops as the bus you are in makes a stop [27]. Upon completion of the trip recording it is able to plot out the route on a map, with markers of the stops recorded. The data if correct can be uploaded to the Transitwand server. For one to upload the data they should have registered the device they are using to obtain a 6 digit number. You are able to view all the routes you have exported by going to the website and typing in your 6 digit number. Transitwand allows the user to then download the route and shapefile data. It registers the phone’s IMEI on the server and gives you a 6-digit identifier [27]. This is the 6-digit number that you use on the TransitWand website.
33
Figure 7: Screenshot of a route being tracked using TransitWand
2.5.1.2 OSMand OSMand is an offline mobile tracking application that helps track and navigate a given location. It offers the services of a map and navigation application with access to the free, worldwide, and high-quality OpenStreetMap (OSM) data. All map data can be stored on your device's memory card for offline use. Via your device's GPS, OsmAnd offers routing, with optical and voice guidance, for car, bike, and pedestrian. All the main functionalities work both online and offline (no internet needed) [28]. Some main features of OSMand that were helpful during the data collection included:
Offline navigation. This feature offered us the ability to use the application will being offline this helped in areas where internet connectivity was bad.
Map viewing. This feature provides the ability to have a base map appear and show your point of location. It is also able to provide GPX tracks drawing the route a person is passing.
It also offers the ability to export your GPX file directly to your OpenStreet account.
Upon the completion of tracking a route, a GPX file (GPS Exchange format) was created which we exported to our individual Open street map accounts for further editing. 34
Figure 8: Screenshot of a route being tracked using OSMand
2.5.1.3 MyTracks My Tracks is a small and powerful GPS android application to keep track of your route while you travel around [29]. MyTracks offers the user the ability to digitally record stop names as the user is riding. It also snaps latitude and longitude points to the Google base dataset 160 that is used as the map interface for the program. Below is a snapshot of the MyTracks application. Unfortunately Google, the developers of MyTracks announced that after 30th April 2016 it would shut down MyTracks [30].
35
Figure 9: Screenshot of a route being tracked using MyTracks
Advantages of MyTracks
It allows for the easy collection of latitude and longitude data to the roadways
Allows modification for addition of other data elements.
Allows for easy visualization of the collected data immediately
Allows for the digital collection of stop names.
Disadvantages of MyTracks
For conversion of shape files to GTFS data, other tools are required like ArcGIS.
2.5.1.4 Open Data Kit Open Data Kit is a free open source set of tools which helps organizations author, field, and manage mobile data collection solutions [31]. It can be used to build multi-media rich mapping tools for data
36
collection. Open Data Kit was not used in the data collection because of the lengthy time involved in modifying it for geospatial data collection.
Advantages of ODK
It allows for customization
It allows for latitude and longitude collection on phones which can be exported to excel files.
Disadvantages of ODK
It requires users to have a programming background for use in the flied.
2.5.2 Possible data editing tools 2.5.2.1 GPS Visualizer GPS Visualizer is an online tool that creates maps and profiles from geographic data. It is open source and easy to use. Input can be GPS data, driving routes, street addresses, or simple coordinates [32]. With GPS visualizer you are able to read files from various data sources, including Garmin's eTrex, GPSMAP, Oregon, Dakota, Colorado, & Nüvi series, GPX, Google Earth(.kml/.kmz), (.plt/.wpt), TomTom(.pgl), Google maps routes(URLs) and tab-limited or comma-separated text [32]. For this project we used GPS Visualizer to convert the .GZ files to Comma-separated text (CSV). The, GZ files are the files that were created by OSMAnd after exporting the GPX track to Open Street Maps. The .GZ files were downloaded from Open Street Maps and used in GPS Visualizer to do develop the GPS coordinate points of a route and the CSV file to keep the GPS coordinate points. The CSV file of a route is created from the site and can later be downloaded.
2.5.2.2 Open Street Maps Open Street Maps is an open source map that that was designed under the Open Street Map project to create a map that is editable by the public [33]. It is a digital map database of the
37
world built through crowdsourced volunteered geographic information [34]. The data available on open street maps is added there by volunteer mappers. The more volunteers an area has the more detailed the map of that area. The strength of Open Street Maps is its adaptability and the freedom it offers for people to use it for whatever purpose they wish [33]. OpenStreetMaps in a way works like Wikipedia in that By registering with the OpenStreetMap website a user is able to use the mapping platform to map your own area. There are communities dedicated to improving the maps, and they have organized mapping projects that any person can join [33]. OpenStreetMap itself does not provide an equivalent to Google's “My Places”, which enables you to create a simple map using your own data. However, you can use Ushahidi to display information about incidents and events on top of maps taken from OpenStreetMap. You can also use OpenStreetMap to make your own map using free software like QGIS that you can install on your computer. However, this is not straightforward to do and will require some technical knowledge [33]. To get data onto OpenStreetMaps on can use direct editing or export GPX file from a Tracking application. In this project we used OSMAnd to create GPX files that we exported to the OpenStreet Platform. The GPX files contained the coordinates of trip recorded. These GPX files were later downloaded and converted to CSV files using GPS visualizer. Using openstreet maps has its own advantages and disadvantages.
Advantages
There is no cost to use the data. In some locales, OSM may be the only freely available source of high-resoulution GIS vector data [34].
The source data is available for download and use in derived cartographic products. OSM differs from Google’s similar crowdsourced map called Map Maker. Cartographers cannot download and reuse Google Map Maker data [34].
The fact that OSM allows users to easily add to the development of the map features means that it has a richer source of data in certain areas [34].
OSM data is flexible and can quickly be updated if certain features in an area change. 38
Disadvantages
Due to the openness in updating data, the data on open OSM may not be fully reliable. There is no Quality analysis of the data added.
OSM is subject to contributor biases. Depending on what the user feels is important in their area they will put that as a point of interest.
Getting focused data from OSM apart for just getting a default map tile requires more technical skills.
OSM is used for various purposes by different people. It can be used as a basemap in tracking applications. It can also be used as a platform to edit collected data. 2.5.2.3 Excel Spreadsheet Excel is an Electronic Spreadsheet Program [35]. An electronic spreadsheet is a computer software program that is used for storing, organizing and manipulating data. The history of spreadsheets dates back The use of Excel compared to other spread sheets was because of the easy accessibility of Excel Spreadsheet and the user friendly interface it offers. Excel was used to help in arranging the collected data and formatting it into the required specification. Different files were created for the GTFS required files. According to the GTFS standard as previously explained requires in the Literature review, 7 files are required. Hence seven CSV files were created as the base for developing and formatting the data into the required specification. These base files where agency.csv, routes.csv, stops.csv. shapes.csv, trips.csv, stop_times.csv and calendar.csv.
2.5.3 Possible Transit Map development tools 2.5.3.1 Indiemapper Indiemapper is an open free online application that allows for the creation of thematic maps from geographic data [36]. It enables for the creation of static maps from professional cartographic design and style. A user does not need to register to use the services provided on indiemapper. Below is a snapshot of results from idiemapper after feeding in GTFS data.
39
Advantages
The learning scale is better compared to ArcGIS
It is free and does not require any licensing
It is online and does not require any installations.
Disadvantages
It does not offer as many features as compared to ArcGIS.
2.5.3.2 ArcGis ArcGIS is a software tool used for working with maps and geographic data. GIS experts use it to create maps, analyze geographic data and manage geographic information in a database. ArcGIS is not an open source software but it has a free trial version with limited features [37]. Advantages
ArcGIS is a complete Geography software offering many features.
Disadvantages
It is not an open source software.
2.5.3.3 Adobe Illustrator Adobe Illustrator is a vector graphics software from the adobe software package. It is a graphics app that allows for the creation of logos, icons, drawings, typography and complex illustrations from any medium [38]. Advantages
There is support documentation available on how to operate it.
It is readily available and popular
Disadvantages
It is a big software in terms of space. One requires a big hard disk drive and fast RAM to run it. 40
2.6 POSSIBLE WEB TECHNOLOGIES 2.6.1 Hyper Text Markup Language (HTML) and CSS HTML is a markup language that is used to structure Web pages. The building blocks of HTML are elements which are represented by tags [39]. CSS is a language that is used to describe the style of an HTML document. CSS describes how HTML elements should be displayed [39]. 2.6.2 Javascript This is an object oriented scripting language [40] developed by Netscape to enable Web authors design client side interactive sites [41]. Javascript is a small and lightweight language, inside a host environment (web browser), it can be connected to the objects of its environment to provide programmatic control over them [40]. Javascript shares many of the features and structures of the object orientated language Java. It is able to interact with HTML code, enabling web authors to spice up their sites with dynamic content. It should be noted that Javascript is an open language and does not need a license to be used [41]. “JavaScript contains a standard library of objects, such as Array, Date, and Math, and a core set of language elements such as operators, control structures, and statements. Core JavaScript can be extended for a variety of purposes by supplementing it with additional objects; for example:
Client-side JavaScript extends the core language by supplying objects to control a browser and it’s Document Object Model (DOM). For example, client-side extensions allow an application to place elements on an HTML form and respond to user events such as mouse clicks, form input, and page navigation.
Server-side JavaScript extends the core language by supplying objects relevant to running JavaScript on a server. For example, server-side extensions allow an application to communicate with a database, provide continuity of information from one invocation to another of the application, or perform file manipulations on a server.” [40]
41
Javascript is a free typed (dynamically typed) language compared to Java. You do not have to declare all variables, classes, and methods. You do not have to be concerned with whether a method is public or private or protected and you do not have to implement interfaces [40]. In this project javascript was used in the design of the interactive aspect of the client side. The use of the Google maps javascript API which is fully javascript influenced the heavy use of javascript. The use of javascript enables client side loading when a request is made on the application. This includes routing on the map and location identification. One major disadvantage with using javascript is that it leads to slow loading of pages when requested from the server. The page is only able to load if all the javascript has loaded. Due to this if the page is filled with javascript it will be slow in loading.
2.6.3 PHP The acronyms PHP stand for Hypertext Preprocessor. It is considered to be the most popular scripting language on the web. It is used to enhance web pages. PHP is known as a server sided language. PHP does not execute on the user’s computer but on the computer you request the page from [42]. “PHP is an interpreted language. This means that you will write code statements (lines of code) and when a page is requested, the PHP interpreter will load your PHP code, parse it and then execute it. This differs from other languages, such as Java or C#, where the source code is compiled and then executed. This is useful for web development in the fact that you do not have to re-compile your source code for trivial code changes and the changes have immediate effect on all subsequent requests.” [43] Because PHP is a server side programming language. When a user requests a web page that contains PHP code, the code is processed by the PHP module installed on that web server. The PHP pre-processor then generates HTML output to be displayed on the user’s browser screen [44]. PHP works by delivering web pages to which are files to the user upon request. When the user types in a URL into the web browser’s address bar, the user is sending a message to the web server at that URL, asking it to send back an HTML file [45]. A request can be made to the web server when the user clicks a link in the web page.
42
In PHP, statements are processed, only the output, or anything printed to the screen is sent by the web server to the web browser. PHP statements that do not produce any output to the screen, are not included in the output sent to the browser. So the PHP code is not normally sent by the user. PHP is written as standard text files with the .php extension. PHP files are often saved within a folder in a web server’s public directory (or a web root directory) [43]. In this project PHP has been used in the processing of a form, posting information to a database and pulling data from the database. It was used in conjunction with websocket technology to develop real time posting. 2.6.4 Bootstrap Framework The bootstrap framework is a popular HTML, CSS and Javascript framework for creating responsive mobile first applications [46]. It comes with a variety of themes that are free and others that are not free. In the development of the web application bootstrap was used to ensure a responsive site. Compared to the other web frameworks available bootstrap was picked because of the vast support and references in has. 2.6.5 Foundation 5 Foundation is a front end frame work that is used to develop front end responsive interfaces. It is based on CSS, Javascript and HTML [47]. 2.6.6 WebSockets This is a technology that allows an interactive communication session between the user’s browser and the server. The user is able to send messages to a server and receive responses without making a poll to the server for a reply [48]. When a websocket connection is established the connection stays open until the client or server closes the connection. During the time of the open connection the client and the server can interact in real time [49]. There are a number of php websocket library’s available that can be used. For this project Ratchet Websockets for PHP WAS used. Ratchet is a loosely coupled PHP library providing developers with tools to create real time, bi-directional applications between clients and servers over WebSockets [49].
43
2.6.7 Google Maps Javascript API The Google Maps API allow for the embedding of Google Maps onto web pages of outside developers, using a simple JavaScript interface or a Flash interface. It is designed to work on both mobile devices as well as traditional desktop browser applications. The API includes language localization for over 50 languages, region localization and geocoding, and has mechanisms for enterprise developers who want to utilize the Google Maps API within an intranet. The API HTTP services can be accessed over a secure (HTTPS) connection by Google Maps API Premier customers [50].
2.7 POSSIBLE ANDROID APPLICATION TECHNOLOGIES The android application that was developed after testing and comparing technologies with which other transit applications and trip planner planners use. Some of the technologies and tools evaluated include: 2.7.1 Ionic Framework Advanced HTML5 Hybrid Mobile App Framework The Ionic mobile app framework is a free and open source library that uses mobile-optimized HTML, CSS and JavaScript components tools for building highly interactive native and progressive web apps. The framework is built with Sass and optimizes for AngularJS. Due to the fact that the Ionic mobile app framework use the Web technologies such as HTML, JavaScript and CSS, it is quite easy to learn it and also to develop interactive applications using it. However, this was not the technology which was used in the development of the application because of the following reasons: The Ionic framework is uses a lot of other plugins such as Cordova in order to access the services of the Google Maps Android API, once the plugin is corrupted, then message passing between the application and the Google Maps Android API will be interrupted.
44
2.7.2 Android Studio with Java The Android Studio platform is now the official integrated development environment (IDE) for Android platform development. It replaced Eclipse Android Development Tools (ADT) as Google's primary IDE for native Android application development and is itself based on on JetBrains' IntelliJ IDEA software. Java is the main programming language used and the java Standard library used consists of many classes that provide several functionalities.
2.8 RELATED PROJECTS The growing need for an improved transport system in major cities around the world has led to various organizations and city authorities conducting projects that will contribute to the improvement of transit in their cities. The use of technology in the public transport sector has been of great research to many IT specialists thus notable technology companies have come on board to help in the contribution of better public transit in cities, companies like Google have developed platforms that enable users view transit information in real time. The first aspect handled has been to make transit data open source through the development of a universal transit data standard called General Transit Feed Specification (GTFS). A number of transit city agencies have been working towards developing transit data for their transit schedules. Mostly these projects have been conducted in cities with an ordered formal transit system structure. Over the years cities with ad-hoc informal transit structures have been trying to develop an alternative transit data structure that would fit the ad-hoc systems. Various transit conferences have been held such as GTFS FOR THE REST OF US [51] this conference various stakeholders sat to discuss how to revise the GTFS standard format which was designed to suit formal transit. Lusaka city falls under the informal transit cities, there are a number of cities around the world that have similar transit systems to that of Lusaka which have developed GTFS for their cities. There is so much to learn from how these city formulated GTFS data for their informal transit systems. Many of such projects are explained in detail in this section of the paper. The first project discussed is the project that lead to the development of General Transit Feed Specification.
45
2.8.1 USA, Portland, Oregon and TriMet transit agency The TriMet transit agency and Google project is what lead to the introduction of General Transit Feed Specification. Portland in partnership with Google is the first city in the world to have had their Transit data in GTFS format [52]. After traveling internationally in the summer of 2005, Bibiana McHugh, an IT Manager at Portland's TriMet transit agency, was frustrated that she couldn't access transit information on a mapping program like Mapquest and certainly couldn't plan a trip by transit with the same ease as a driving trip. When she returned stateside, she sent inquiries to Mapquest, Yahoo!, and Google, asking each if they had plans to incorporate transit data into their mapping services and if TriMet could partner in the endeavor [52]. Of all the mapping platforms contacted Google responded to Bibiana McHugh. Google through Chris Harrelson, a software engineer at Google was the main contact between TriMet and Google. He and a group of engineers had been working on a Google Transit prototype. Google at that time had the idea and infrastructure but they also required a government agency to collaborate with to provide them the transit data (routes, timetables etc.) [53]. The Google Transit Planner launched on December 7th 2005, TriMet was the only city with its Transit data until about September 2006, and five more cities got on board. Various Transit applications developed from this data, google maps also updated their transit data.
2.8.2 The Digital Matatu Project Kenya The digital matatu project was a transit mapping project carried out in Kenya, which by using cell phones and other GPS unit, General transit Feed Specification open source data for the Nairobi’s semi-formal bus system is developed. The open source data collected by the cell phones and GPS units is then translated into the General Transit Feed Specification data standard for wider use. The works carried out in the development of the digital matatu project in Kenya showed that: 1. Mobile technologies, particularly mobiles can be used effectively to collect and deliver data in a modified GTFS format for semi-formal transit. 2. GTFS data collected can be adapted to semi-formal system and be used by other cities with such transit systems and applications. 3. In the recent past, there has been a high demand for GTFS data from many technologists, application developers, city planners and even the transport communities. 4. Since the GTFS data is open source, it can help to encourage the development of transportation application and other applications that use the open source GTFS data. 46
Upon completion of the Digital Matatu [6]the release of the data showed the demand for the data by planners and researchers working in Nairobi. They received multiple requests for the data from transportation consultants including the Institute for Transportation and Development Policy (ITDP) which was creating a bus service plan for a proposed Bus Rapid Transit (BRT) corridor, and required knowledge of existing routes. Providing the data saved the organization much time as a lot of work went into investigating the various matatu routes along the corridor which was the primary emphasis for their study. They used the data and map to select routes and locations on these routes to conduct ridership capacity and frequency surveys (ITDP and UN-Habitat 2014). The matatu owners and drivers instantly saw the potential of the map and used it to demonstrate the logic of new routes that would help improve traffic circulation. [6]A number of software developers including those we included in the early discussions about the project used the data to develop trip planning applications for cell phones.These included the popular trip planning application Ma3route which also gives traffic alerts and allows you to rate your matatu driver. FlashCast Sonar was another trip planning application that also gave some real time information for a subset of the matatus in Nairobi. The Digital Matatu trip planning app was created for Windows, named presumably after this research project and another trip planning app called Matatu Map was created.
47
2.8.3 Philippine, Manila Transit project Nearly 70 percent of all trips made by the 12 million residents of metropolitan Manila are via public transit. It was not until 2012, that Manila had no map of its transit system-hence no efficient way for passengers to locate routes or transfers or faor transport planners to know whether transit services were reaching target populations. In 2012, the World Bank and the Philippines Department of Transportation and Communications began a project to develop the first multimodal transit map by collecting and maintaining transit service data. The World Bank sort to devise a mechanism for Manila on how they would cheaply collect and maintain Manila’s transit data. In line with this the World Bank devised a technical solution relying on three open transport principles.
Open data standards – the team adopted the General Transit Feed Specification data standard.
Open source software – the team supported the development of an open source mobile phone application, TransitWand, with which transit agency staff members could generate route data in the GTFS format at a substantial low cost.
Open data – the department of Transport and Communication made its GTFS data publicly available on its website, this supported the growth of local third party applications to help passengers ride around the city well [54].
This project brought a number of benefits to Manila. Before passengers got transit directions by word of mouth, but now passengers have access to multi-modal route maps. The changes in fare prices are now communicated electronically and are now available centrally. This project also now helps the government in times of disaster find alternative transit routes for people to use [55].
2.8.4 Mexico City Transit project The City of Mexico is home to over 32 million vehicle trips a day, of which over 20 million are via public transport. These use 12 subway lines, four rapid transit lines, eight trolleybus and light rail lines, a suburban rail line, a hundred of formal bus routes and over 1400 minibus routes, along 260 public bike stations [56]. Dating back as far as the 1970s, five agencies have supervised this network, group under SETRAVI, Mexico City’s public transport authority.
48
In November 2012, the Bank’s Latin America and Caribbean Transport Unit with support from the Energy Sector Management Assistance Program, began providing SETRAVI with technical assistance to develop a digital system to collect and manage urban transport data. Representatives were enrolled by SETRAVI to crisscross the capital, using TransitWand. The Mexico City project experienced a few hurdles one being the rigid GTFS structure. The GTFS standard was too rigid to incorporate data related to nonscheduled services. Hence the World Bank initiated a pilot project called GTFS-lite. This GTFS standard was designed for cities with flexible route and stopping points. This project benefited the city of Mexico in a number of ways. Urban City planners now have access to visualized route configurations to determine where best to add or eliminate services. The development of GTFS for Mexico City has also lead to the development of real-time tracking tools that inform users of disruptions in the system and provide route change options [56].
2.8.5 Dhaka (Bangladesh) project: New Data Collection Technique with Smartphones A project in Dhaka was undertaken to test the viability of flocksourcing by co-developing and seeding those technologies with a local resident led flock who targeted a segment of the bus system. This project was conducted for 8 weeks. It showed that flocksouring can be a viable way of collecting transit data in some of the most challenging urban cities in the world. The bus system in Dhaka can be described us adhoc, hence the challenges experienced by various users. Flocksourcing attempts to address the bus crowdsourcing dilemma in developing city contexts by (1) relying more on face-to-face contact and less on online altruism to motivate and organize participants and (2) endowing the technology and the “know-how” to the flock members. Whereas traditional crowdsourcing relies on a pool of largely anonymous online volunteers, flocksourcing (at least in our Dhaka experiment) incorporates social organization to set targets and hold a (usually smaller) group of individuals accountable. This experiment needed to test three key technical elements in Dhaka:
the accuracy of the location sensing,
the speed of the mobile data network, and
Any performance limitations of locally-available hardware, specifically the screen size and resolution (since the touch screen is the input mechanism for some measurements).
A number of design approaches were followed in transit data collection process in Dhaka.
They sort to minimize the cost of data collection by using free and open global tools. 49
Icons were used to simplify the user interaction.
Streamlining the number of steps required for a user to start data collection.
The coordinators of the Dhaka project established at the end of the project that the volume and data collected during the project promising, especially in a data sparse environment [57].
2.9 RELATED SYSTEMS AND APPLICATIONS With the various projects on Transit data in the world developers have also jumped on the wagon of improving navigation and transit information through the development of Transit applications. The various projects conducted have mainly stopped at making the cities GTFS data public. This GTFS data has made it possible for application developers to integrate and utilize this data. Application developers have built user friendly platforms that provide good visual of GTFS data and make it useful to the ordinary person. Transit applications are slowing gaining ground providing static and real time information concerning particular cities of interest. Cities with General Transit Feed data can be easily integrated into most mobile transit applications. One aspect of this project was to develop a platform that would make use of Lusaka’s GTFS data. With concepts picked from the various Transit applications which are discussed in this section of the paper, a web and mobile application were developed.
2.9.1 TRANSIT APP Sam Dionne and Guillaume Campagna are the developers behind the designing of the Transit application. Their main aim of creating this successful application was to make the navigation of public transport easier. The Transit App assists those unfamiliar with transit systems in foreign cities as well as those who are familiar. The user friendly App basically shows the routes used by the public transport and what time the next one will be available within the users’ area. [58] Transit App currently works in 125 metropolitan areas and is available on both iPhone and Android. [59] It is therefore necessary to check what city it supports before downloading the
50
application. Once the application is running, a big blocky interface will appear on the screen with icons and it will automatically detect the users’ location. Nearby mode and Directions view are the two primary modes on the App. The nearby mode lists the stops within the users’ location and how long before the next mode of transport is to arrive at its designated stop. Taping the listings will offer four options. These are: i.
Map view; which shows the users’ location on the map and the full train/bus routes
ii.
Direction toggle; this is where the route directions can be switched according to the user
iii.
Favourites; routes can be selected as favourites by the user which will appear at the top of the route lists
iv.
Schedule; it shows complete schedules and departure times.
Directions view is where the user enters his/hers destination. It will then suggest four available routes and transit options which can be filtered depending on which mode of transport is preferred. This can be done by entering the starting point and destination, then taping on route option. To specify the desired departure time, the clock icon can be used. Once that is completed, the first available route overviews shown on a map and departure times will be shown. The user can then select from the options. [60] For handy gesture shortcuts, pull to the right of the screen for the map and pull to the left of the screen to switch directions. To quickly see the next two times, tap and hold the time indicator and for the distance to the station, tap and hold the route number. Transit App acts efficiently by remembering the last route that was taken and offers a reverse route back. Information is stored up and updated on a daily basis reducing the issue of connection problems because the recent updates can be cached locally. [58] In spite of its efficiency, the application has its users facing some challenges. It seems more geared towards people familiar with the areas. [61] And limited locations are supported. [58] This popular free application still makes it easier to navigate public transport in big cities.
51
Figure 10: Screenshot of Transit App interface
2.9.2 MOOVIT APPLICATION Moovit, an Israeli public transport navigation application was founded in 2011, and on March 2012 it was launched. Like any other navigation application, its aim is to assist the user in planning movements and providing routes. However, a great deal has been added by the developers like a Voiceover and talkback support. As well as a search box that allows users’ to search for a destination or to get directions to where they need to go. It’s a free application paired with the internet connectivity on the users’ smartphone that is kept open whilst taking a ride on whatever mode of transport. Users can custom-set their work or home address and Moovit will pull up options for schedules and routes for transportation. [62] The keys features are: i.
Step by step navigation
ii.
Journey planner: routes comparison to destination
iii.
Live arrivals: search for a specific line
iv.
Real time service alerts
v.
Static maps for popular metro/underground/rail systems
52
To begin using the Moovit application, the user needs to enter the starting point. This could be a home address or a current location. According to the selected departure time, Moovit will select the suitable bus route to use or alternative directions. Alternative directions could be where one could walk to the nearest bus station. With the application kept open it collects speed and location data to offer more accurate information to its users. [63] Notifications can be set to be announced even whilst the application has been closed if the phone is being used for something else. From the users’ current location, it also gives turn by turn directions once they disembark from the mode of transport to their ultimate destination. Using the touch screen reader on the users’ phone, the application will regularly give an alert to which street is being approached and how many feet needed to turn to the left or right. [64] People can also choose to report on whether the bus is crowded, air conditioning is on/off or if the Wi-Fi is down. In spite of its efficiency, the application users facing some challenges. It seems to have inaccurate timings of transportation sometimes and the application crushing during usage.
Figure 11: MOOVIT user interface
53
2.9.3 GOOGLE MAPS Lars Rasmussen and Jens Rasmussen are the co –finders of the web based service that provides satellite views of different places and detailed information on geographic regions called, Google Maps. It is the most well-known map service on the net. Google Maps offers satellite images and street maps which are hybrid view as well as basic street maps and terrain maps. It is easy to navigate and has options to print out or save maps. Business landmarks can also be made for everyone else to view. As part of a large web application, Google Maps offers the following services: i.
A view and navigation through vertical and horizontal panoramic street level images of different cities around the world.
ii.
Users of public transport, bikers, drivers and walkers are offered a router planner for those who intend to make a trip from location to the next.
iii.
The Application Program Interface (API) enables the web site administrators to insert Google Maps as a community service page or real estate guide.
iv.
A location service for motorist who the use the Global Positioning System (GPS) on mobile phones. [65]
The maps that viewed on Google Maps are compiled by a private company called Tele Atlas which is in partnership with Google. Tele Atlas are leaders in navigation and location based services. With highly accurate maps, they are credited for mapping the terrain of extreme rural areas. Google Maps coordinates with a number of in-house applications like Google Earth. These two services utilize each other’s data for the coordination of the satellite images and updating newly developed areas. ‘’My Maps’’ is a feature that allows users’ to highlight their own places of interest, local businesses or areas where photos have been taken. The individuals invited to view the maps are able to view that information. ‘’My Maps’’ can be made useful when creating a family tree or working out a large project. Mapplets is similar to Map Application Program Interface, which allows the user to add new features to Google Maps or connect information. For example, a real estate agency can connect all their property for sale. This feature is suitable for companies or businesses.
54
Developers can also utilize the API to create their own maps for personal use. Mapplets are similar to Maps API, although the two are different. Using Mapplets is merely building on top of an already existing product. [66]
Figure 12: Google Maps user interface
55
2.9.4 ALLY APPLICATION The Ally application story began as allyrder. This was a transit app for Germany, the UK and Switzerland. Attention turned to transit systems in emerging cities once the application was well established in London and Berlin. They were the first app to integrate external applications back in 2009 which has now become a clear trend in the application world. At the end of 2014, Minibus by allyrder was built in Istanbul as their first step in the transit journey. The aim of the app was connecting the dots of the hundreds of unrecorded minibus routes in Istanbul. The developers faced new challenges as the transports’ agency Application Program Interface could not be used because the routes were completely unrecorded. In addition to that, some parts of the roads and streets where missing or inaccurately maps. OpenStreetMaps data (a Wikipedia of maps) had to be improved. This is where contributors can fix or add to maps if they find anything missing or inaccuracies, which make OpenStreetMaps gradually accurate. [67] To discover the best location around you, Where To? Is an application that offers assistance by showing the nearby places where the user can eat, shop or relax? Where To? App collaborated with Ally App to show users how to get to their desired location. The user can then select the best route through different modes of transport that Ally offers. Ally application adds something different to the modes of transport available. On Where To? Routing options show public transport, car sharing, bike sharing and taxi options. If the user does not have Ally app they are linked to the application store where it can be downloaded for free. [68] After Apple introduced the Apple Watch, Ally application offers its users the best way to get home or to work without actually removing their phone from their pocket. Two icons that appear on the screen of the watch are the work and home icon which can be tapped to see the most appropriate route to be used. Swiping to the left or right will be to flick between the different modes of transport similar to mobile devices. Swiping up on the lock screen of the Apple Watch opens the Ally app, showing all the routes information in full detail.
56
Figure 13: Ally App user interface
2.9.5 CITY MAPPER This urban navigation application was founded by Azmat Yusuf a former Google employee. Citymapper, a sleek green application displays information on journey times and prices. This application began its life exclusively for Londoners but has since expanded to cover more than 30 cities. Citymappers’ algorithm pulls in major data to offer users a range of transport options like Uber, metro, train and bus. It appears quiet regarding user numbers but often features on the top of the transportation application download charts for android and iOS. [69] Citymapper has a menu hierarchy and offers the user the ability to jump sections very easily. Even before selecting a route, a location map and tube map are made available on the 57
homepage. If the user intends to return to the main menu after opening a number of windows, tapping and holding the back button at the top left will take them back to the main menu. The holding of the button is important till an animation is seen after pressing the button for a few seconds to be taken back to the menu. Beginning a journey at a different destination is made possible on Citymapper especially if the user has just arrived at a station and the application cannot identify where exactly the users’ location is. The search window is there to insert where the users journey begins from, making it easy to select a starting points. ‘’Get me home’’ is a fantastic option that speeds up the search even further. Setting an arrival time is possible on Citymapper by changing the time on the result window. The user must tap on the ‘’set arrival time’’ and a date picker will slide up to allocate the appropriate time and date. Once the time and date have been selected, the interface will then inform the user as to what time they will be required to leave. The label will appear in a yellow colour written ‘’leave by’’. Citymapper also allows users to save and track suggested routes. This is very useful especially with bus arrivals, as it informs the user when the next bus is arriving at the first bus stop. Saved journeys will appear on the main window in a yellow box. This is to an advantage as the saved journeys will be updated with the latest information the next time the users decides to launch the application, whereas normal searches will no automatically update the information. Walkers are not left out as travel time is made available in minutes as well as the calories that have been burnt during the walk. This also applies to the cycle option. The application has a star icon that is used to bookmark the most used stations and stops as favourites. All the modes of transportation available on the application can be saved as favourite on the top corner on the star icon, grey in colour. These favourites are easy to access and departure times are able to be viewed without navigating to the relevant stations. To be able to receive notification alerts, on the main menu, tap the ‘’i’’ on the top right corner and notification settings can be changed. [70] The application saves up recent searches which is particularly helpful when offline. City mapper has both web and mobile (android and iPhone) applications.
58
Figure 14: City Mapper mobile application user interface
59
Figure 15: City Mapper web application user interface
2.9.6 ROUTESHOUT RouteMatch software, led by a dedicated team has brought innovation to passenger transportation technologies through Routeshout. The application provides instant access to arrival times, schedules changes, service disruptions as well as traffic delays of buses .Using Global Positioning System, Routeshout finds the closest stops to the users’ location. Signals which can sometimes be disrupted by large buildings, has not hindered stops and routes to be searched for using the magnifying glass icon. [71] The application can easily be downloaded from smart phones, tablets or other wireless devices. A secure web-based system that makes users satisfied by texting a designated number or scanning a QR code gets the available bus times. A teaser advertisement is also
60
received at the bottom of the message if the stop has an advertisement booked for it. Informing the user they can purchase coffee while they wait to their bus to arrive. A list of the nearest bus stops appears on the screen. Selecting a stop will broadcast upcoming inbound and outbound bus arrival times. When the user is outdoors or indoors, multiple types of digital signs are displayed to inform the user of the information required. [72] Routeshout is available on any web browser with an interactive map which allows users to view bus moving in real-time as well as to sign up for alerts on the online web portal features. Schedules, bookings and general bulletins are retrievable through the applications Interactive Voice Response (IVR). This is done on a phone without communicating with a customer care representative. [73] Routeshout Management console is a tool used to track, manage and analyse the usage of the application system. Graphical heat maps are displayed to show the areas that are concentrated with people using particular modes of transportation, popular bus stops and the times. [71]
Figure 16: RouteSout user interface
61
CHAPTER 3
3 REQUIREMENTS ANALYSIS 3.1 Software Development Methodology The development of the web and Android applications was done in an iterative approach, in which the Agile software development process was used. This involved the entire processes of: 1. Application specification, in which we defined what the applications were supposed to do and what features we were to add to the system. 2. Application Design and Implementation, this involve defining how the application was to be organized in term of interfaces, data management and access, and also security and stability of the entire system. 3. Application Validation, this process was carried in order to verify if the applications were developed met the initial requirements set for it. In most of these process, increment developments were done for each process and the application components were done in an iterative manner.
3.2 Development Tools Used The data collection tools that were used to collect the bus geospatial data were Android Samsung Tablets. On them was installed OSMand and TransitWand, these are the two applications that were used in the data collection, because of their user friendly nature as compared to the other applications previously discussed in the possible data collection tools. As explained from the possible development tools to be used there are a number of tools that would have been used in the development of the web and the android application. For the web application Javascript was heavily used. The reason for choosing to work with javascript is that the Google Maps API works with javascript to provide web services. For the interface the framework Bootstrap was chosen over Foundation 5. This is because Bootstrap offers more support compared to Foundation 5. Another reason is that there are a variety of free Bootstrap templates available online compared to Foundation 5. 62
3.3 Requirements and Constraints 3.3.1 Stakeholder analysis The following are the stakeholders of the Transit map data and application. The Navigator or User City Planner Developer Data collector
3.3.1.1 A Navigator or User The Navigator or User is the person who will use the functionalities of the application to be developed. Roles and Goals Locate the desired bus stop from any location Located a route to the particular bus stop from their current position or from any other position. To get the total cost of travel or the total bus fare from one bus stop to the other bus stop. To identify the most suitable root to use to get to their desired destination Know the approximate time it would take to move from one bus stop to the other.
3.3.1.2 City Planner The person that will use the transit map data that will be collected to make decisions on how to allocate bus commuters around the city. Roles and Goals To access the transit Map data using any available source, e.g. via a web application, android application or hard copy transit map.
63
Make suggestions on how to allocate buses around the city with help from the information on the developed transit map. Update their current data with the new data collected.
3.3.1.3 Developer The person that will develop the application Roles and Goals Develop the application Deploy and maintain the application.
3.3.1.4 Data Collector The person that will go in the field to do the actual collection of the data Roles and Goals Identify the routes whose data is to be collected Collect all the necessary data about each route that has been identified, i.e. bus stops on the route, fares etc.
3.4 Functional Requirements 3.4.1 The Navigator or User Requirements The user should be able to search for a desire bus stop from the system The user should be able to search for a route from the current to a particular bus stop The user should be able to know the total fare charge needed to move from one bus stop to the next. The user should be able to know the approximate time it will take to move from one stop to the other. 64
3.4.2 City Planner The City planner should be able to view the data collected from any available platform The City planner should able to update their current transit data with the new data collected.
3.4.3 Developer. The Developer should be able to develop application The Developer should be able to meet the requirements of the clients The developer should be able to make money out of the developed system.
3.4.4 Data Collector The data collector should be able collect the necessary transit data for the system.
3.5 Non Functional Requirements The application should be developed to run on a web browser and another to run as an android application. The transit application to provide functionality of viewing Lusaka’s transit information Application should integrated the Global Positioning System technology. The application should be efficient.
65
CHAPTER 4
4 SYSTEM DESIGN
This Chapter will decide the software patterns and techniques that were used in the design and analysis of the system.
4.1 System Architecture The Model – View Controller (MVC) was the architectural pattern that was used in the development of the system. The MVC architectural pattern divides or separates the functionalities of the system into three interconnected ways and hence making the separation of responsibilities of each part possible. Below is the description of the Model View Controller Design pattern. 1.
The model: - the Model, which directly manages the data, logic and rules of the
application. 2.
The View: - The view determines of the user interacts with the system.
3.
The Controller: - the controller enables the exchange of user inputs and also
responsible for the provision of valid feedback from the system. The model view control was chosen as the pattern to be used in the system because it easy can manage the type of data we were dealing with: The Google Maps Service: these are the servers on which the GTFS data will be place. These hence were considered are the Model of the system. The Routing Applications: These were considered to be the View part of the application The Google Maps API: This was the controller used in the system.
66
Client (HTML, CSS and JAVASCRIPT) GOOGLE TRANSIT SERVERS General Transit Feed Specification
Figure 17: Showing the system architecture.
67
4.2 System Algorithm Flow Chart
Diagram showing the algorithm flow chart
Submits to Google Maps Servers and geocodes the inputs
User inputs origin and Destination Stop
Submits to Google Maps API
68
The Figure above depicts the flow of activities from the time enters the origin and destination bus stops till the system returns the feedback. When the user inputs the origin and destination bus stop, the system submits to the Google Maps Servers via the Google Maps API. The Google Maps Servers then return the feedback or results to the user after geocoding the town stops and developing a transit route between them.
4.5 User Interface Design We opted to design the user interface mock ups of both the web and the android application on paper. For the web application we use a free bootstrap template with we modified to fit our requirements. For the android application we used android studio XML. 4.6 Database Design
Figure 18: The traffic feeds database
The database that was design was used for the traffic feeds only. The database only had three columns. Which where:
Id this was the primary key. An auto generated ID.
Posts this was the column that held the posts sent in by users.
Created_at this was the column that held the time at which the post was sent to the server.
69
CHAPTER 5 5 SYSTEM DEVELOPMENT
5.1 Use Case Text for the Requirements 5.1.1 The Navigator or User Roles Use Cases 1. Locating a desired bus stop from any location User: Inputs a desired bus stop or any other place of interest System: displays a map marker pin pointing the desired bus stop on the base map.
2. Viewing a desired route User: Inputs the origin and inputs the destination System: Displays a colored polyline starting from the origin to the destination, with text results of how many stops are on the route, the time of the journey and the distance between the two points. Also displaying the fare charge of the route. 3. Posting and viewing traffic posts (web application) User: Loads the traffic updates page System: Displays recent posts by other users. User: Makes a comment on the traffic condition and posts. System: Displays the post sent by that user.
70
5.2 Domain Modelling
Identifying the nouns from Use Case User System Bus stop Fare charge Route Time Search Bus Stop option Google Maps Servers
71
Domain Sequence diagram of the web and android applications
Figure 19: System Domain model for both Web and Android Application
72
5.3 Sequence Diagrams
Figure 20: Sequence diagram showing how a bus route is fetched and displayed
The sequence diagram above is a depiction of the general methods invocate in the system when a user makes a query to view a route. This work layout is both for the android and the web based application.
73
Figure 21: General sequence diagram showing how a bus stop is located on the system
The sequence diagram above is a depiction of the general methods invocate in the system when a user makes a query to find a particular bus stop. This work layout is both for the android and the web based application.
74
Figure 22: Sequence diagram showing how a route is displayed between two bus stops.
The sequence diagram above is a depiction of the general methods invocate in the system when a user makes a query to view a route between two bus stop locations. This work layout is both for the android and the web based application.
75
5.4 Screen Shots of web application
Figure 23: Screenshot showing the Trip planner and routing page without an inputted values.
The figure shows the trip planner and routing page of the ZedTransit web application. This screen shoot has no user input in the ‘enter an origin’ and ‘enter a destination’ text field.
Figure 24: Results after user input.
76
The figure shows the results of a trip a user is interested in. Here the user wants to know the Kulima Tower to UNZA bus stop route.
Figure 25: Results of the user’s current location after clicking the ‘my location’ button
Figure 26: ZedTransit traffic dashboard
The ZedTransit dashboard where users can post about current traffic conditions on the road they are using. By typing in the ‘post your update here’ and clicking the send update button.
77
Figure 27: Results of the find search places page.
The figure shows results of the location of the UNZA bus stop are a user placed a search query.
78
5.5 Android Application screen shots Android Application 1. Home Page
Figure 28: Home page of the ZedTransit App
2.
Navigation and Map
Figure 29: Navigation and Map page of the ZedTransit App
79
CHAPTER 6 6 TESTING AND VERIFICATION 6.1 Test Cases This section will now outline the test cases of the system. For each test case, a test case ID, requirement, test approach and pass criteria is shown. The test approach outlines the method implemented to test the each of the requirement. The pass criteria will help determine whether or not the requirement has been achieved.
Test
Requirement
Approach
Pass Criteria
User must route between two
Human
User Routing between the two bus
bus stops
trial
stops
User Must be able to locate
Human
User locating individual bus stops
individual bus stops
trial
User must be able to post current
Human
User writing a traffic update and
traffic updates
trial
posting it
User must be able to view traffic
Human
Upon loading of traffic dashboard
updates posted by other users
trial
recent post must be viewed in time
ID Z1 Z2 Z3 Z4
order
6.2 Analysis of Test Results This section will now display the results once the test case are implemented on the applications Test
Requirement
Approach
Pass Criteria
Result
Comments
User must route
Human
User Routing
Pass
This test was passed
between two bus
Trial
between the
for both applications,
two bus stops
were both gave the
ID Z1
stops
80
same result. Z2
User Must be able to
Human
User locating
locate individual bus
trial
individual bus
stops Z3
User must be able to
Human
User posting
post current traffic
trial
current traffic
for the web application Pass
This test was passed for the web application
updates
User must be able to
Human
User viewing
view traffic updates
trial
post made by
posted by other users
This test was passed
stops
updates Z4
Pass
Pass
This test was passed for the web application
other users
81
CHAPTER 7 7 CONCLUSION
7.1 DISCUSSION All the events surrounding the planning, the execution of this project have culminated into the first every GTFS data for Lusaka. Inspite of the minor hiccups the collection of transit data was inevitable as this was the first step for the whole project. Without the data collection this whole project would have been null and void. The essence of the project was in the data collection process. Hence data was collected on Lusaka’s paratransit system. The data collected was raw data which comprised of the geolocations of bus stops. The purpose of collecting the geographical positions of the bus stops was to have a better accurate view of how Lusaka’s bus stops are distributed. This information the Lusaka City Council does not have. Another reason was to enable pin pointing of bus stops and assist users of the transit application have an overview of what stations are available along the route they have specified. The shapes of the routes allocated as transit routes were marked. This was to have an extract of the transit routes. The shapes of the routes were used in coming up with the Lusaka Transit map. This map provides a visual overview of how Lusaka’s transit system is distributed. From the stop points collected a database can now easily be built of the points and the names of the stops. This database can provide a summary of the stops, their names and were it was possible, information about whether the stop is a designated stop or it is an undesignated stop. All the transit information collected was required for the formation of General Transit Feed Specification. According to the universal standard specification the bus stop geolocations, the shapes of the routes and the trip schedules are required. In Lusaka due to the adhoc informal public transport system the development of General Transit Feed Specification was faced with some challenges. However a number of projects around Africa and other parts of the world seeking to provide General Transit Feed Specification data for systems with adhoc transit systems proved helpful in that, the methods they used were the same methods we were going to use. As earlier discussed one such project was Digital Matatu, these people advised us on a number of issues. 82
The emphasis on the tools to use in the data collection. The Digital Matatu crew provided us with a variety of mobile applications to use in the data collect process.
The emphasis on the kind of protocol to adopt in developing stop IDs and route IDs which were to be used in the design of Lusaka’s General Transit Feed Specific.
The emphasis on the need to make this data open source. One important thing that Digital Matatu advised was to publicize the General Transit Feed Specification data so that various entities like software developers and already existing mobile applications could add Lusaka to their systems.
As software developers our secondary goal was to test how the data we collected would work on web and mobile transit applications before we publicized it to the public. We did the testing by developing our own web and mobile application which would provide routing capabilities. The quality of the data was determined from the results it produced on these routing applications. As discussed third party applications that have been developed for the purpose of validating General Transit Feed Specification data were also used. This applications provide a comprehensive report of the whole General Transit Feed dataset. Producing error that may have occurred due to repeated IDs, short distance between named stop locations which may just represent the same stop. The quality of the feed is vital to the processing of routing results hence it was an important part of the project. Third party routing application use algorithms based on the General Transit Feed Specification standard to provide routing graphs. Hence the need to have high quality datasets by those providing transit data. During the project more time was spent in correcting errors in the raw data collected. A number of errors were discovered which had to be rectified lest the General Transit Feed data was going to be of low quality. Most routing applications are particular with the quality of General Transit Feed Specification which is fed into the system. Getting the General Transit Feed Specification onto routing platforms was a task that we had to seriously think through about. They are so many routing platforms available but we chose to go with Google Transit Servers. This decision was reached after coming to a conclusion that Google Transit server provided the most user friendly API. We applied for the Google Transit partnership dashboard. This partnership dashboard is the platform where transit agencies wishing to have their information on the Google platform. The platform provides for 83
transit agencies to manage their data and make any updates when necessary. The platform also provides for validation and reports on the validation of the information that is prior to the publicizing of the data. The process between uploading the data and the quality analysis that is conducted by Google is a long process. Upon uploading the data to the dashboard test queries of the data were carried out, this was to test if the data was sufficient enough and able to provide the user with standard and accurate information. In our transit applications we were able to use the Google maps API to provide routing capabilities, this was after feed the Google servers with the Lusaka GTFS dataset. The applications were able to query the Google servers for routing information for both web and android platforms. The Google servers provide an easier but efficient way of pulling transit details from the GTFS exchange and displaying the results as either text or visuals on a map. The text is details of the route, directions, the stops and the fares if provided in the GTFS dataset. The visual is a polyline track of the route on a base map.
7.2 RESULTS AND ANALYSIS The Transit mapping project sort to have an outcome that will be the base for other similar transit projects in Zambia. Its intention is to be the ice breaker and a base where other projects can build up from. To achieve this there were a number of deliverables that had to be delivered as end products of the project.
The development of GTFS data
Sensitization of the importance of GTFS data to a city
The publicizing of the developed GTFS data
The development of a platform that would utilize the GTFS data
The development of a Transit map prototype using the GTFS data
84
7.2.1 The development of GTFS data One major accomplishment was the development of GTFS data for 45 routes in Lusaka. A majority of these routes start from the city center at the four different bus stations. As earlier discussed some bus station share the same destinations so it was more economical to pick one station as being the starting station than get a bus from all the four stations to the same location. The GTFS datasets have been made available on the project website for use by the public which includes developers and those wishing to add to the existing data. With the launch of Lusaka’s GTFS data we hope to see in the near future the city of Lusaka appear on various major Transit application such as Transit App, Moovit and Ally app. 7.2.2 Sensitization of the importance of GTFS data One other accomplishment was education of what GTFS data is. GTFS data is a new thing to Zambia and so educating the public was one key thing. This education was accomplished through the development of a project website. The website contains an introduction to what the whole project was all about. 7.2.3 Publicizing of GTFS data to Google and on the project website The GTFS data that was has been developed was intended to be made open source for public use. Through project website downloading of the files was made possible. Other transit application will be able to use this data in their applications. The GTFS data was also made available to Google through the Google Transit Partnership platform. Google validated that data using there in house validation tools and integrated it into their Transit platform.
7.2.4 Development of routing applications to use the GTFS data and a crowdsourcing platform Upon the development of GTFS data, one objective of the project was to develop routing applications that would be able to use the data developed. Two routing applications one web based and one mobile were developed. The applications used the Google servers which held the GTFS data that was published to Google. The data was pulled from the servers and used to provide bus route details of a desired route. The details are displayed in both text and graphically on a map. Through the application a user can see the direction the bus takes and know the estimated time, the distance and the bus fare.
85
The web based application also provides a dashboard through which users can post details of traffic conditions on various roads in Lusaka. This platform allowed for crowdsourcing of information from various individuals. The information posted can be used to enlighten users of the traffic pattern in the city. This information if collected and analyzed can be useful to Traffic authorities like RATSA.
7.2.5 Development of the Lusaka transit map From the GTFS data a transit map for the city of Lusaka was developed. This map visualizes the structure of Lusaka’s public transit system similar to subway maps offered in developed cities. The map can be used by the general public to offer them an overview of the city’s transit system. The map can be publicized to visitors and local citizens. The map can also be used to offer visualization of parts of the city that are not covered by public transport.
7.3 Limitations and Problems All three phases of the project had major challenges. These challenges will be discussed phase by phase. 7.3.1 Challenges in the data collection process During the process of data collection we encountered a number of challenges both nontechnical and technical that slowed down our data collect process. Initially we opted to have an overview of the already existing routes in Lusaka from the Lusaka City Council, but this effort proved futile because the Lusaka City Council does not have any available geospatial information of the Transit system in Lusaka. This was expected of the Lusaka City Council but it was also considered a major challenge for us because it meant we had to start our data collection without any prior information to reference to. Another non-technical challenge experienced in the process of data collection was the availability of hardware tools to use. Most of the third party applications used in the process of data collection that have already been discuss (OSMand and Transitwand) are android platform applications. This was a restriction in that we had to all have android platform phones. One technical challenge experienced was that the applications used in the data collection process required access to the internet in order to start the tracking process. At times the internet connectivity would be very poor resulting in GPS taking long to finally pin point the 86
actual start point of the route, this would lead to the tracking process only tracking part of the whole journey hence retracking the route had to be done. Another technical challenge cause by cloud cover was that the accuracy of the GPS signal would be poor in the project we experienced an average accuracy of 5 to 8 meters. This was not good for the visualization of the polyline tracks on a Lusaka base map. The polyline tracks with poor accuracy would be viewed to be further from the actual road displayed on the map. The battery life of the android devices used was reduced due to the GPS of the phone being on. This challenge slowed down the process of tracking in that we were unable to track as many routes as we wished to track in a day. 7.3.2 Challenges in the application development process The software development technology adopted was the Model View Controller. The Google maps API was our controller. The web and mobile applications had to pull data from the Google servers in order to provide routing results. This information that was provided to Google before being uploaded onto the servers had to be validated by the Google Transit partnership team. The process of validation was a lengthy process because of the fact that the GTFS standard was primarily built for cities with a structured public transport system. The type of Transport system in Lusaka is informal hence the GTFS data had to be fine-tuned to fit Lusaka’s ad-hoc system. This whole process required clarifications and corrections from Google Transit Partnership team. Due to this the availability of Transit routing on the web and mobile application was delayed.
7.3.3 Challenges in the Transit Map development One challenge experienced in the development of the Transit Map was the waiting of the GTFS validation results from the Google Partnership team. We opted to use the validated data in coming up with the Transit map. But due to the delay in validation of the GTFS datasets the Transit map development was delayed. Another challenge experiences was that due to the fact that the people conducting the project had no geography background the Transit Map that was developed could not be detailed. Natural features found in Lusaka could not be included on the map.
7.4 Future works and Recommendations The Transit Mapping project can be further advanced in the following areas: 87
Scaling the project to include various government stakeholders such as the Lusaka City Council and the Road, Transport and Safety Agency. This institutions can adopt the project and utilize the findings to better the Public Transport System in Lusaka. The addition of a fare calculation algorithm that can calculate the bus fares based on the distances and amount of fuel consumption. This can help provide a standard fare chart based on distance and profit that the bus operators can gain. The use of the information from the traffic feeds to display real-time analysis of the track pattern in the city. Development of a crowd-sourcing platform on which users can contribute to the further mapping of Lusaka. This crowdsourcing platform can enable users add health facilities, schools to the map of Lusaka. The setting up of a committee to look into updating the GTFS datasets every after a specified time interval, say every 6 months. The participating of Geography experts to come up with a Transit map that will include natural features in the city.
References [1] [Online]. Available: https://developers.google.com/transit/gtfs/?hl=en. [2] D. A. Townsend, "Smart Cities: Big Data, Civic Hackers, and the quest for a new Utopia," WW Norton & company, New York, 2013. [3] M. Sarah Williams, M. Adam White, P. Peter Waiganjo and P. Daniel Orwa, "The Digital Matatu Project: Using Cell Phones to Create an Open Source Data for Nairobi's SemiFormal Bus System," Digital Matatu Technical Paper, pp. 1-28, 2014. [4] A. P. T. Association, "Public Transportation Facts at a glance," 2008. [5] T. H. M. Davis, "Public Transportation’s Contribution to US Greenhouse Gas Reduction," 2007. [6] S. W. P. W. D. O. a. A. W. Jacqueline Klopp, "Leveraging Cellphones for Wayfinding and Journey Planning in Semi-formal Bus Systems:Lessons from Digital Matatus in Nairobbi," in Planning Support Systems and Smart Cities, Springer International Publishing Switerland 2015, 2015, pp. 227-241. [7] E. INSTITUTE, "State Of The Planet Earth Institute | Columbia University," 26 August 2015. [Online]. Available: http://blogs.ei.columbia.edu/2015/08/26/map-app-helps-people-tracktransit-in-nairobi/. [Accessed 29 January 2016]. [8] "Google Developers," Google, [Online]. Available: https://developers.google.com/transit/gtfs/. [Accessed 8 January 2016]. [9] D. Canales, "TheCityFix," 22 October 2015. [Online]. Available: http://thecityfix.com/blog/whydeveloping-cities-should-standardize-and-open-their-transit-data-diego-canales/. [Accessed 8 88
January 2016]. [10] B. L. Luanga, "PUBLIC TRANSPORT SYSTEM IN LUSAKA, ZAMBIA," [Online]. Available: http://www.cities-formobility.net/documents/wc08/cfm_world_congress_workshop_a_lusaka.pdf. [11] "Oxford dictionaries," [Online]. Available: https://en.oxforddictionaries.com/definition/public. [Accessed 01 10 2016]. [12] "Oxford dictionaries," [Online]. Available: https://en.oxforddictionaries.com/definition/transport. [13] "Public Transportation Benefits," American Public Transport Association , [Online]. Available: http://www.apta.com/mediacenter/ptbenefits/Pages/default.aspx. [Accessed 01 10 2016]. [14] M. Chernoff, "What "open data" means—and what it doesnt mean," Opensource.com, 10 December 2010. [Online]. Available: https://opensource.com/government/10/12/what%22open-data%22-means-%E2%80%93-and-what-it-doesn%E2%80%99t. [Accessed 01 October 2016]. [15] "advancing public transport," [Online]. Available: http://www.uitp.org/benefits-open-data. [Accessed 01 10 2016]. [16] "TransitWiki," [Online]. Available: http://www.transitwiki.org/TransitWiki/index.php?title=General_Transit_Feed_Specification. [Accessed 7 January 2016]. [17] "Google Transit APIs > Static Transit," [Online]. Available: https://developers.google.com/transit/gtfs/. [18] B. McHugh, "Beyond Transperency," [Online]. Available: http://beyondtransparency.org/chapters/part-2/pioneering-open-data-standards-the-gtfsstory/. [Accessed 28 07 2016]. [19] M. Roth, "STREETSBLOG SF," 5 January 2010. [Online]. Available: http://sf.streetsblog.org/2010/01/05/how-google-and-portlands-trimet-set-the-standard-foropen-transit-data/. [Accessed 7 19 2016]. [20] S. J. B. Aaron Antrim, "THE MANY USES OF GTFS DATA – OPENING THE DOOR TO TRANSIT AND MULTIMODAL APPLICATIONS," [Online]. Available: https://www.locationaware.usf.edu/wpcontent/uploads/2010/02/The-Many-Uses-of-GTFS-Data-%E2%80%93-ITS-America-submissionabbreviated.pdf. [Accessed 28 07 2016]. [21] "Open Trip Planner," [Online]. Available: http://www.opentripplanner.org/. [Accessed 2016 7 28]. [22] "The digital Matatu Project," [Online]. Available: http://www.digitalmatatus.com/map.html. [Accessed 30 07 2016].
89
[23] "Transport for Cairo," [Online]. Available: http://transportforcairo.com/transit-map-designworkshop/. [Accessed 07 30 2016]. [24] "google/transitfeed," GITHUB, [Online]. Available: https://github.com/google/transitfeed/wiki/FeedValidator. [Accessed 01 10 2016]. [25] "google/transit," [Online]. Available: https://github.com/google/transitfeed/wiki/ScheduleViewer. [Accessed 01 10 2016]. [26] [Online]. Available: http://transitwand.com/. [Accessed 01 08 2016]. [27] "Pleasant Programmer," [Online]. Available: http://pleasantprogrammer.com/posts/transitwand.html. [Accessed 01 08 2016]. [28] "gitHub," [Online]. Available: https://github.com/osmandapp/Osmand. [Accessed 31 07 2016]. [29] "Google Play," [Online]. Available: https://play.google.com/store/apps/details?id=com.zihua.android.mytracks&hl=en. [Accessed 02 10 2010]. [30] "Mobi Health News," [Online]. Available: http://www.mobihealthnews.com/content/googleshut-down-its-activity-tracking-app-my-tracks-spring. [Accessed 02 10 2016]. [31] "Home," OpenDataKit, [Online]. Available: https://opendatakit.org/. [Accessed 03 10 2016]. [32] "GPS Visualizer," [Online]. Available: http://www.gpsvisualizer.com/. [Accessed 03 08 2016]. [33] "Visualising Information for advocacy," [Online]. Available: https://visualisingadvocacy.org/resources/tools/openstreetmap-osm. [Accessed 03 08 2016]. [34] "PENNSTATE ,GEOG 585 OPEN WEB MAPPING," DEPARTMENT OF GEOGRAPHY COLLEGE OF EARTH AND MINERAL SCIENCES, [Online]. Available: https://www.eeducation.psu.edu/geog585/node/738. [Accessed 03 08 2016]. [35] T. French, "About Tech," [Online]. Available: http://spreadsheets.about.com/od/excelformulas/ss/What-is-Microsoft-Excel-and-WhatWould-I-Use-it-for.htm. [36] "Indiemapper: Create professional maps from geographic data," fppt.com, [Online]. Available: http://www.free-power-point-templates.com/articles/indiemapper-create-professional-mapsfrom-geographic-data/. [Accessed 02 10 2016]. [37] "esri," [Online]. Available: http://www.esri.com/software/arcgis. [Accessed 06 10 2016]. [38] "adobe.com," adobe.com, [Online]. Available: https://helpx.adobe.com/illustrator/howto/what-is-illustrator.html. [Accessed 02 10 2016]. [39] "W3SHOOLS," [Online]. Available: http://www.w3schools.com/css/default.asp. [Accessed 05 10 2016].
90
[40] "MOZILLA DEVELOPER NETWORK," [Online]. Available: https://developer.mozilla.org/enUS/docs/Web/JavaScript/Guide/Introduction. [Accessed 13 08 2016]. [41] V. Beal, "Webopedia," [Online]. Available: http://www.webopedia.com/TERM/J/JavaScript.html. [Accessed 13 08 2016]. [42] "HOME & LEARN," [Online]. Available: http://www.homeandlearn.co.uk/php/php1p1.html. [Accessed 14 08 2016]. [43] "How does PHP work with the web server and browser?," Stillat, 2 04 2016. [Online]. Available: http://www.stillat.com/blog/2014/04/02/how-does-php-work-with-the-web-server-andbrowser/. [Accessed 15 08 2016]. [44] S. Balkhi, "What is: PHP," wpbeginner, [Online]. Available: http://www.wpbeginner.com/glossary/php/. [Accessed 15 08 2016]. [45] S. S. a. J. Valade, "How PHP works," For DUMMIES, Making Everything Easier, [Online]. Available: http://www.dummies.com/how-to/content/how-php-works.html. [Accessed 15 08 2016]. [46] "w3schools.com," [Online]. Available: http://www.w3schools.com/bootstrap/. [Accessed 05 09 2016]. [47] "FOUNDATION," [Online]. Available: http://foundation.zurb.com/. [48] "Mozilla Developer network, WebSockets," [Online]. Available: https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API. [Accessed 05 09 2016]. [49] "Ratchet," [Online]. Available: http://socketo.me/docs. [Accessed 05 09 2016]. [50] "ProgramableWeb," [Online]. Available: http://www.programmableweb.com/api/google-maps. [Accessed 05 09 2016]. [51] A. Oursler, "Center for sustainable development Earth Institute University of Columbia," 27 11 2013. [Online]. Available: http://csud.ei.columbia.edu/2013/11/27/gtfs-for-the-rest-of-usworkshop-leads-to-a-new-way-to-capture-paratransit-data/. [Accessed 04 10 2016]. [52] M. ROTH, "STREETS BLOG SF," 05 January 2010. [Online]. Available: http://sf.streetsblog.org/2010/01/05/how-google-and-portlands-trimet-set-the-standard-foropen-transit-data/. [Accessed 2016 Febuary 2016]. [53] B. McHugh, "Beyond Transparency," [Online]. Available: http://beyondtransparency.org/chapters/part-2/pioneering-open-data-standards-the-gtfsstory/. [Accessed 05 08 2016]. [54] H. Krambeck, "Mapping Manila Transit, A new Approach to solving Old challenges". [55] H. KRAMBECK, "TRANSPORT FOR DEVELOPMENT. Open Data+ Urban Transport," THE WORLD BANK, 09 12 2012. [Online]. Available: http://blogs.worldbank.org/transport/open-data-urbantransport. [Accessed 08 08 2016]. 91
[56] "Mexico City Open Database Improves Transit Efficiency, Helps Commuters," THE WORLD BANK, 05 11 2013. [Online]. Available: http://www.worldbank.org/en/news/feature/2013/11/05/mexico-city-open-databaseimproves-transit-efficiency-helps-commuters. [Accessed 08 08 2016]. [57] P. C. Z. K. I. M. Albert Ching, "A User-Flocksourced Bus Experiment in Dhaka," New data collection Technique with Smartphones, pp. 2, 14, 16, 17, 19, 24, 2012. [58] R. Ritchie, "iMore," 21 June 2012. [Online]. Available: http://m.imore.com/transit-app-iphonereview-#vhm3. [Accessed 9 August 2016]. [59] "Transit App," [Online]. Available: htt://transitapp.com/regions. [Accessed 9 August 2016]. [60] R. Broida, "clnet," 13 June 2014. [Online]. Available: content://com.sec.android.app.sbrowser/reading/0808232301798.mhtml. [Accessed 10 August 2016]. [61] F. Ion, "Greenbot," 19 February 2015. [Online]. Available: http://www.greebot.com/article/2882562/transit-vs-moovit-can-either-public-transit-app-beatgoogles-maps.html. [Accessed 10 August 2016]. [62] B. Kimball, "The Appzine," 15 April 2015. [Online]. Available: http://ww.theappzine.com/content/using-public-transport-moovit-will-help-plan-your-route. [Accessed 10 August 2016]. [63] K. Kloosterman, "Israel21c," 13 May 2013. [Online]. Available: content://com.sec.android.app.sbrowser/readinglist/0810125651914.mhtml. [Accessed 10 August 2016]. [64] B. Holton, "American Fund for the Blind," [Online]. Available: http://www.afb.org/community/announcements/getting-around-with-the-moovit-local-transitapp-for-ios-and-android-smartphones/1. [Accessed 10 August 2016]. [65] M. Rouse, "Whatls.com," February 2013. [Online]. Available: http://whatis.techtarget.com/definition/Google-Maps. [Accessed 12 August 2016]. [66] D. Sherwin, "Makeuseof," 22 February 2010. [Online]. Available: http://www.makeuseof.com/tag/technology-explained-google-maps-work/. [Accessed 13 August 2016]. [67] "ally," 11 May 2015. [Online]. Available: content://com.sec.andriod.app.sbrowser/readinglist/0819191622663.mhtml. [Accessed 19 August 2016]. [68] "ally," 3 February 2015. [Online]. Available: content://com.sec.andriod.app.sbrower/readinglist/0819191411935.mhtml. [Accessed 19 August 2016]. [69] S. Shead, "Business Insiders," 21 January 2016. [Online]. Available: http://uk.businessinsider.com/citymapper-has-raised-32-million-for-its-urban-navigation92
app2016-1. [Accessed 20 August 2016]. [70] L. Porter, "about travel," 24 August 2015. [Online]. Available: content://com.sec.andriod.app.sbrowser/readinglist/081919523305.mhtml. [Accessed 20 August 2016]. [71] "Route match software," [Online]. Available: http://www.routematch.com/aboutroutematch/leadership/. [Accessed 20 August 2016]. [72] "Routeshout," [Online]. Available: content://com.sec.android.app.sbrowser/readinglist/0819201711323.mhtml. [Accessed 20 August 2016]. [73] September 2013. [Online]. Available: https://www.routematch.com. [Accessed 20 August 2016].
93
APPENDICES APPENDIX 1
GTFS – General Transit Feed Specification. This is a common format for representation of public transport information and its geographic information. Routing and Trip planning Application – This is an application that aids users plan their journeys in advance. Giving them detailed information of how to get to their desired location. Smart City – This is a city that seeks to use Information Communication Technology to solve social, environmental and economic problems a city is experiencing.
APPENDIX 2 How to locally install the ZedTransit Web application To run the ZEDTransit application from a localserver one need to install:
WAMP(Windows Apache MySQL PHP) OR XAMPP(X-OS Apache MySQL PHP) Install Ratchet php websocks
Installing XAMPP I. II. III. IV.
Download XAMMP from https://www.apachefriends.org/index.html/ Run the XAMMP executable file Set the MySQL password Upon installing XAMMP start the apache and MySQL.
94
Installing Ratchet php websocket I.
Install composer. Composer is an application written in PHP that will manage external php libraries within a php project. Get the composer executable file from https://getcomposer.org/download/ next
Install Ratchet by typing into your terminal php ~/composer.phar install
II. III.
You are now ready to run ratchet Next cd to the zedTransit app folder in websocket\websocketapp\bin and run the ws-chatserver in your terminal.
.Configuring the application 95
I. Copy the ‘zedApp’ folder to the htdocs folder. II.
Edit ‘db.php’ file by setting the password to your set MySQL password.
I.
Run the application in your browser by typing localhost/zedApp/
APPENDIX 3 Snapshot of selected code for the web app
The router.js responsible for providing the routing capability $(document).ready(initMap()); // This function will initialize the map and set all required features function initMap() { //Creating a new instance of the directionsRenderer to display the results of the query var directionsDisplay = new google.maps.DirectionsRenderer; //Creating a new instance of the directionService to query the Google directions server var directionsService = new google.maps.DirectionsService;
96
// creating the div element that will display the text results of the route var display = document.createElement('div'); var alertMe = '
No directions
'; // making a control panel that will be resposible for holding all the control events on the map the input vaules var control = document.getElementById('floating-panel'); var gps_control = document.getElementById('gps'); var close_panel = document.getElementById('close-button'); // Create the search box and link it to the UI element. var input = document.getElementById('pac-input');
// Creating the map object and its properties var map = new google.maps.Map(document.getElementById('map'), { zoom: 7, center: {lat: -15.4082630, lng:28.2801423 } });
//binding the display results of the route to the map directionsDisplay.setMap(map); // binding the text results of the route to the panel so that they are visible directionsDisplay.setPanel(displayText(display));
user_input(map,directionsService,directionsDisplay,display,control); display_currentLocation(map,gps_control); closing(map,close_panel)
97
}
function calculateAndDisplayRoute(directionsService, directionsDisplay) {
document.getElementById('location').addEventListener('click', myLocation); // getting the entered value in the origin input field var start = document.getElementById('origin-input').value; //getting the entered value in the destination field var end = document.getElementById('destination-input').value; // directionsService.route({ origin: start, destination: end, travelMode: google.maps.TravelMode.DRIVING, transitOptions:{}, unitSystem: google.maps.UnitSystem.METRIC }, function(response, status) { if (status === google.maps.DirectionsStatus.OK) { directionsDisplay.setDirections(response); document.getElementById('right-panel').style.backgroundColor = 'white'; } else {
} }); } function displayText(display){ // if(display.innerHTML !="") {} //create a div to contain the text display of route display.id = 'right-panel'; display.style.height = '100%'; document.getElementById('sidebar-wrapper').appendChild(display);
98
return display;
}
function handleLocationError(browserHasGeolocation, infoWindow, pos) { infoWindow.setPosition(pos); infoWindow.setContent(browserHasGeolocation ? 'Error: The Geolocation service failed.' : 'Error: Your browser doesn\'t support geolocation.');
} function closing(map,close_panel){ map.controls[google.maps.ControlPosition.LEFT_CENTER].push(close_panel); } function display_currentLocation(map,gps_control){
var infoWindow = new google.maps.InfoWindow({map: map}); map.controls[google.maps.ControlPosition.RIGHT_CENTER].push(gps_control); document.getElementById('gps_button').addEventListener('click', function(){
if (navigator.geolocation) { navigator.geolocation.getCurrentPosition(function(position) { var pos = { lat: position.coords.latitude, lng: position.coords.longitude };
placeMarkerAndPanTo(pos,map); infoWindow.setContent('Location found. '); map.setCenter(pos);
}, function() { handleLocationError(true, infoWindow, map.getCenter()); 99
},{ enableHighAccuracy: true}); } else { // Browser doesn't support Geolocation handleLocationError(false, infoWindow, map.getCenter()); } }); } function user_input(map,directionsService,directionsDisplay,display,control){ //if (display.innerHTML !="") {}; control.style.display = 'block'; //Binding the created control panel to the map specified object map.controls[google.maps.ControlPosition.TOP_CENTER].push(control); var onChangeHandler = function() { calculateAndDisplayRoute(directionsService, directionsDisplay);
//adding a background color to the text view directions }; // creating an event listener that will display the route when the button is clicked
document.getElementById('submit').addEventListener('click', onChangeHandler); }
function placeMarkerAndPanTo(pos, map) {
var marker = new google.maps.Marker({ position: pos, map: map }); map.panTo(pos); infoWindow.open(map,marker);
100
} function myLocation(){ if (navigator.geolocation) { navigator.geolocation.getCurrentPosition(function(position) { var pos = { lat: position.coords.latitude, lng: position.coords.longitude };
placeMarkerAndPanTo(pos,map); infoWindow.setContent('Location found. '); map.setCenter(pos);
}, function() { handleLocationError(true, infoWindow, map.getCenter()); },{ enableHighAccuracy: true}); } else { // Browser doesn't support Geolocation handleLocationError(false, infoWindow, map.getCenter()); } document.getElementById('origin-input').value = pos.lat.concat(pos.lng);
}
The db.php file connecting to the traffic update database
![i[(^J-i0^) ], zeD](https://m.moam.info/img/260x300/ij-i0-zed_5c5cb21a097c478d4f8b461c.jpg)
