Report No: ACS9722 . Republic of the Philippines Transport Crowd-Source ICT Demonstration Final Report . October 2013 . EASPS EAST ASIA AND PACIFIC . . Document of the World Bank . Standard Disclaimer: . This volume is a product of the staff of the International Bank for Reconstruction and Development/ The World Bank. The findings, interpretations, and conclusions expressed in this paper do not necessarily reflect the views of the Executive Directors of The World Bank or the governments they represent. The World Bank does not guarantee the accuracy of the data included in this work. The boundaries, colors, denominations, and other information shown on any map in this work do not imply any judgment on the part of The World Bank concerning the legal status of any territory or the endorsement or acceptance of such boundaries. . Copyright Statement: . The material in this publication is copyrighted. Copying and/or transmitting portions or all of this work without permission may be a violation of applicable law. The International Bank for Reconstruction and Development/ The World Bank encourages dissemination of its work and will normally grant permission to reproduce portions of the work promptly. For permission to photocopy or reprint any part of this work, please send a request with complete information to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, USA, telephone 978-750-8400, fax 978-750-4470, http://www.copyright.com/. All other queries on rights and licenses, including subsidiary rights, should be addressed to the Office of the Publisher, The World Bank, 1818 H Street NW, Washington, DC 20433, USA, fax 202-522-2422, e-mail pubrights@worldbank.org. TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT Transport Crowd Source Information and Communications Technology (ICT) Demonstration Component 1 – Taxi Data Crowd Sourcing Platform October 2013 Produced by: Integrated Transport Planning Ltd 32a Stoney Street The Lace Market Nottingham NG1 1LL 25/06/2014 i TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT EXECUTIVE SUMMARY This document constitutes the final report of Component 1 of the Transport Crowd Source Information and Communications Technology (ICT) Demonstration project, which focused upon crowd-sourcing traffic data from taxi vehicles in Cebu City, Philippines, using replicable open source software tools and low-cost smartphones. The aim of the project was to explore the viability of using ICT (hardware and software) to create data feeds and analytical tools that would assist Cebu City Government with its day-to-day and strategic management of the city’s road network, whilst also assisting taxi operators and their drivers with their day-to-day taxi operations. The demonstration project was co-ordinated by the World Bank using funds from AusAid and the Korea ICT4D Trust, and implemented in partnership with Cebu City Government, the Philippines Department of Transport and Communications, Metro Cebu Taxi Operator Association. A summary of key findings related to the four project deliverables is provided in the table below: Applications / Tools / Objective Quantifiable Result Qualitative Result Training • TrafficProbe smartphone • Floating vehicle • Continuous city- app – used to collect data data collection for wide data from ‘floating’ vehicles. USD $20 per- collection and • TrafficProbe WebServer vehicle-per-month automated post- Develop a – used to aggregate and when implemented processing better proof of process collected data. over 3 years than 3 month concept low- • TrafficAlert web-based • Sample of 2 million survey timeframe cost, and tool – used to record roadway segments • Taxi driver simple, traffic incidents and alerts per month in Cebu compliance, in- means to • Training in how to install, • Almost 6 times vehicle power, collect traffic configure, deploy and use cheaper than a Android OS and data all data collection tools. manual journey 3G data network • Smartphone & app time survey issues limit real- installation guides time traffic data produced for CITOM viability • Traffic Alerts – online tool • 17,000 traffic alerts • Easy to input data to display Traffic Alerts. input during project and create map- • Journey Time Analysis – • City-wide journey based online tool to display time analysis using visualisations journey time and speed very high quality across multiple Use collected data data (R = 0.94 for users data to more • Software designed to be correlation within • Easily manage effectively intuitive, and included the dataset) traffic enforcer staff plan and prompts on how to use it • Sample of 750 locations manage local • ‘Walk-through’ training participating • Impossible to transport sessions delivered with vehicles required to replicate data systems key ‘point-people’ in the achieve live traffic collection scale COMMEL Traffic dataset manually enforcement team, • Opportunity for CITOM Transport historical analysis planning team and of newly created CITOM Scats team data feeds Use collected • TrafficProbe smartphone • 41% of taxi drivers • Improved driver’s data to app – messaging participating in perceptions of support function, panic button, project relied on safety when driving dispatching Traffic Alerts display and Traffic Alerts a taxi 25/06/2014 ii TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT Applications / Tools / Objective Quantifiable Result Qualitative Result Training services for GPS location. • 25% cheaper than • Improved taxi local taxi • Taxi Dispatch interface - locally-available customer operators vehicle tracking, dispatch GPS tracking option perceptions and and distance-driven • Average of 75/320 customer service counters. vehicles connected • Collaboration • In-person training (in to server every day between CITOM Cebuano) in how to use • No reported and taxi companies all software tools and genuine uses of • Dispatch tools of maintain smartphones panic button tool limited value in Cebu City • Driver compliance prevented accurate distance-driven analyses and vehicle tracking • Traffic Alert visualisation • 1 media briefing • Part of CITOM’s available at undertaken to strategy for public Establish an www.cebutraffic.org publicise presence engagement going information • In-person briefing for Att. of website forward platform to Raffy Yap, the Head of • Public Traffic Alert • Real-time support CITOM, on what data are view delivered at information service public being displayed publicly, end of for members of the participation to facilitate accuract demonstration public in transport responses to media project, so no • Reliant on action of system and enquiries quantifiable findings COMMEL officers network to report at CITOM development • Insufficient traffic data sample for live public traffic view Platform implementation costs The software tools implemented in Cebu City through this demonstration project represent low- cost ways that city governments can collect/input traffic and road network data on a continuous basis, and in a format which is immediately available for analysis through the software tools provided. The annualised total cost of replicating all components of the software platform are set out in the table below, and assume that ICT hardware costs are amortised over a three year implementation period: High value components of the demonstration project The Traffic Alerts data entry and visualisation tools represent both the cheapest, and one of the highest impact, components of the whole software platform tested in this project:  At a low implementation cost, the tools provided Cebu City Government with the means to digitally record all of the incidents and traffic congestion events that happen on the road network.  The tools represented both a substantial productivity improvement over existing (paper-based) incident reporting methods, and also facilitate easier management of traffic enforcement resources and an improved response to incidents occurring on the city’s highway network. 25/06/2014 iii TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT  Information feeds generated by this tool were highly valued by taxi drivers, who could see them via the TrafficProbe app, and are now available for download and analysis by CITOM’s transport planning team – presenting opportunities for improved network planning. The TrafficProbe smartphone application and web-server software tools demonstrated potential for such approaches to be successful:  These tools provide a feed of traffic data that can be used for both real-time Automatic Vehicle Location, and time-series analyses of traffic speed and journey time analyses across around 2 million roadway segments each month based on the sample achieved in Cebu City. If driver compliance and vehicle fleet operating environment issues experienced through the demonstration project in Cebu City are addressed, then there is scope for these tools to yield a richer sample of data that could also power real-time traffic data feeds. Achieving this would require a significantly larger sample of floating vehicles than was deployed in Cebu City - of the order of 750 participating vehicles connected to the server each day.  These implementation costs would reduce if the smartphone handset costs are removed. This could potentially be achieved through vehicle fleet operators meeting these costs, or by publicly crowd-sourcing the data collection effort (as both Google’s Traffic and Waze applications have done successfully).  Even if a city authority were to bear the TrafficProbe hardware and data costs itself, this approach is still around six times cheaper than manual survey techniques that are conventionally used to obtain traffic speed and journey time data. It is also more accurate, as data encoding errors are removed from the process. In its current guise, the TrafficProbe platform is most readily deployable in low numbers for purposive traffic speed and journey time data collection.  The team’s validation of the data collected through the demonstration project yielded exceptionally high correlation across all time periods (AM peak, Inter-peak and PM peak) with an R value of 0.94 substantially higher than existing data from manually collected sources.  The collaboration fostered between taxi operators and drivers, and CITOM, demonstrated that both parties were prepared to work together and share data for mutual benefit. While this presents a significant opportunity for sustaining the platform in Cebu City beyond the life of the demonstration project, it is also a key requisite for future replication in other cities using taxi vehicle fleets. Lower value components of the demonstration project  The small ‘real world’ sample of floating car data points achieved through this demonstration project is due to a combination of unreliable wireless data connectivity in Cebu City and low levels of taxi driver compliance that were, at least in part, driven by concerns of taxi operators and drivers over the value of the smartphones and the extent they made taxi drivers a greater target for violent crime. While concerns over smartphones being stolen appear to have been largely unfounded (6 devices out of 320 were reported stolen during the demonstration project) the reliability of 3G data networks and driver resistance to having their location tracked are difficult issues to overcome. These are considered requisites for successful replication in other cities.  A live traffic dataset was not achievable through the demonstration project in Cebu City as a result of the sample-size achieved. During the validation period the project team 25/06/2014 iv TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT observed an average of 75 vehicles participating per day. With this sample size during the hours of 8am-8pm only 1,100 road segments saw, on average, more than one velocity observation per hour. A segment observation rate of at least 10/hour is required to visualise live traffic, which would necessitate at least 750 vehicles participating per day to cover just main roads in Cebu City, and up to 2,500 vehicles on secondary and tertiary roads within the city core.  Using the city’s taxi fleet as a floating car sample resulted in a dataset that contains ~50% faster absolute average traffic speeds and journey times – variable by time of day – than those recorded by previous manual surveys that include public transit and/or attempt to circulate at the speed of general traffic flow in the city. Broadening the sample of vehicles in which the TrafficProbe app is deployed could resolve this, but would significantly add to the management challenge placed on CITOM if the software tools were deployed in their current guise.  The panic button tool was little-used by taxi drivers and operators during the course of the Cebu City demonstration project. Most drivers were aware that there was no formal monitoring or coordinated response, and therefore did not trust it as a mechanism.  Taxi dispatch functionality was also barely used through the course of the demonstration project, which appears mainly due to the high level of competition for taxi fares in Cebu City resulting from an over-supply of vehicles and licensed drivers. The small screens on low-cost smartphone devices deployed through the demonstration project, low literacy levels among some taxi drivers, and a city ordinance making using a ‘phone while driving illegal, also contributed to this outcome.  The availability of human resources and their capacity to analyse and use new data feeds is an issue presented by the introduction of the new sources of data provided by the TrafficProbe and Traffic Alert software tools. Sustaining and scaling up the software platform in Cebu City Encouragingly; 85% of the participating taxi operators, and 94% of their drivers, stated that they were keen to continue their involvement in the demonstration project, based on the value they have derived from the smartphone app and web-based tools to date. Based on the sample of smartphones currently distributed and managed by CITOM and the 190 remaining devices that are ready to be deployed in Cebu City:  The total annual cost of maintaining unlimited data plans, cloud hosting and technical support for the devices will be USD $87,600, or $14 per fleet vehicle per month.  Both the taxi operators and CITOM expressed an interest in equally sharing these costs in order to sustain the platform and the data feeds it generates.  Splitting these costs equally would see each participating taxi operator contributing $7.00 per vehicle per month ($84 per annum per vehicle) to CITOM in return for a real-time automatic vehicle location system, and extended loan of the smartphone devices distributed through the project. CITOM would require a budget of USD $43,800 to cover the on-going cost of maintaining this fleet of floating vehicle data probes, and a further $7,000 to maintain the Traffic Alert data entry and visualisation tools – representing a total annual budget of $50,000. A number of additional training needs were identified in order for the TrafficProbe platform to be sustained in Cebu City beyond the demonstration project. These centred upon improving the 25/06/2014 v TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT awareness and understanding of taxi operators and drivers in respect of their TrafficProbe smartphone and web-applications, addressing driver and operator compliance issues to ensure the ‘phones remain connected, ensuring COMMEL radio operators are routinely updating the Traffic Alerts map through day-to-day operations, and assisting CITOM’s transport planning team with detailed analyses of the journey time/speed and traffic incident data feeds created by the project. Some additional staff resources will be required to sustain the taxi crowd sourcing infrastructure. CITOM will ideally to ensure a minimum staffing level for the COMMEL team so that 4 people are working in the radio control room every daytime – thereby facilitating the routine updating of the public Traffic Alert map, and a 24/7 panic button monitoring service. The participating taxi operators will task maintenance staff with ensuring in-vehicle 12v DC charging ports are maintained, or hard-wired if required via a charging lead to the vehicle battery’s accessories output. Opportunities for scaling up the demonstration platform in Cebu City include:  Creating a public website visualisation/embeddable widget that shows live incidents on the road network in Cebu City.  Creating a public website visualising average traffic conditions at different times of day/day of the week to facilitate open public debate about traffic conditions in the city, and the action that can be taken in order to address identified issues. Estimated cost to develop: USD $5,000.  Creating a public smartphone application that visualises incident reports in Cebu City, and show them overlaid on an OSM map of Cebu City. Estimated cost to develop: USD $5,000 per smartphone platform.  Co-locating COMMEL and Traffic Control teams within CITOM to facilitate communication and coordination of monitoring activities and help make the traffic control centre operational 24/7.  Regular meetings between CITOM’s Operations Division (COMMEL, SCATS Traffic Control) and the planning teams could be beneficial as a way of requiring regular analyses and discussion of traffic speed and journey time data, and potential actions (e.g. using SCATS) to address identified issues.  Geographically extending the coverage of the Traffic Alert platform to neighbouring Talisay, Mandaue and Mactan cities. Recommendations for replication in other cities Based on the project team’s experience of deploying and validating a fully-supported taxi-based data collection platform in Cebu we have developed the following recommendations for re- deployment in other locations:  Recognise the challenges inherent in procuring, distributing and managing mobile handsets. This is both costly in terms of capital and in labour. Particularly, the long-term cost of configuring, distributing and maintaining deployed handsets must be considered as part of the overall project budget.  Taking on the procurement and distribution of devices adds significant risk related to the reliability of underlying hardware. As demonstrated as part of this project there are significant quality problems with low-cost mobile handsets. 25/06/2014 vi TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT  Consider the availability of existing vehicle fleets (both public and private) as well as opportunities for engaging the public directly in data collection activities. By tapping existing infrastructure this may eliminate the need to consider hardware as a component of the project.  Consider reducing the scope of the data collection activities, and extending the survey time period. Focusing on a smaller number of vehicles facilitates a sample sufficient for transport planning and evaluation over a period of time (weeks or months). With a smaller sample size the real-time data becomes less relevant, allowing batch processing either at the end of the project or on a period basis.  To the extent that data must be collected from the public, address the privacy implication by moving aspects of the inference to the phone. This allows users to return summarized velocity data rather than positional information. This data should be stored only in aggregate forms and not tied to user identifiable logs. Notwithstanding the points identified above, relating to the challenge of achieving a sufficiently large sample of deployed TrafficProbe handsets in order to achieve a real-time traffic dataset, we recognise that other cities may find the software platform valuable in the context of purposively collecting accurate floating vehicle data, and using the Traffic Alerts system to coordinate traffic network management/public information services. It may also appeal to taxi operators whose operations are based in more compliant environments and who wish to establish a low cost Automatic Vehicle Location platform. Lessons learned from key implementation challenges The lessons learned through the course of overcoming key implementation challenges whilst delivering this demonstration project in Cebu City are likely to be valuable to other city authorities or taxi operators wishing to replicate the TrafficProbe software platform in their local area:  Undertake field testing of all mobile software on the specific device on the intended local mobile network. Without testing the exact network/device/software combination there is strong chance of missing critical deployment related bugs.  Where possible use only fully unlocked smartphone/tablet devices with Google-deployed Android versions. Android modifications made by carriers/device manufacturers lead to additional operating system nuances that are not present in the Google-deployed Android OS versions, and also increase data charges due to the data traffic they generate.  Despite the complexity and expense, hardwired in-vehicle power connections are critical to ensure reliable maintenance-free device charging.  Build a strong working partnership with local cell phone providers in order to avoid network disruption and inconsistent connectivity such as that experienced during the demonstration project.  Based on observed driving patterns within the demonstration project’s sample of deployed TrafficProbe applications mounted in taxis, the project team determined that real-time sampling of roadway conditions is not feasible. The increased sample size required to support real-time collection calls into question the approach of deploying owned devices. However, a small number of devices operating over an extended period of time (weeks or months) can provide 25/06/2014 vii TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT meaningful and accurate observations of traffic conditions in aggregate to facilitate more detailed traffic analyses, or area-wide traffic model development.  The project fundamentally depends on OSM data as an input for tracking vehicle movements, the quality of the underlying data was a concern. However, the project team discovered early in the project that existing OSM data for the region was of sufficient quality to support the TrafficProbe applications. Ideas for future platform development A number of ideas for the future development of the software platform emerged through the course of the demonstration project in Cebu City. They include:  Smartphone-based traffic enforcement tools that enable in-street traffic enforcers to be permanently geo-located, place Traffic Alerts directly into the TrafficProbe database and Improve the geo-spatial accuracy of fault reports by leveraging GPS functionality on smartphones to pin-point the site of incidents.  Enhanced taxi dispatch functionality including conversation messaging mode, including a ‘For Hire’/‘Hired’ status function, logging of jobs accepted/rejected/serviced, integration of VoIP (e.g. Skype or Google Voice) calling within the app, and integrated routing recommendations based on local street network data in the OpenStreetMap.  Regenerative creation of OSM data from the crowd-sourced GPS traffic data.  Developing a fully open, crowd-sourced, traffic data collection infrastructure using TrafficProbe as a foundation. This project has demonstrated that the technical challenges are surmountable, but the primary question remains as to ‘How to incentivise public participation?’  Integrate Variable Message Sign activation and editing tools into the Traffic Alerts web- application. While there are many proprietary versions of this type of system, developing integration with the open-source TrafficProbe software platform deployed in Cebu City could enable city authorities to run their own VMS signage.  Improving junction transit time data to improve monitoring of queue related delay at junctions. By sub-dividing road segments to allow monitoring of transit times for only the portion of a segment approaching a junction it may, in certain situations, be possible to disaggregate junction related transit times from overall segment travel speeds. Further research is needed to validate this approach, as is a larger observation sample. The current sample size challenges prevent accurate estimates of transit times based on a meaningful frequency of junction crossings at the scale of a single junction. 25/06/2014 viii TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT CONTENTS Page 1 INTRODUCTION 1 Funding and implementation partners 1 Project objectives and their relevance to Cebu City 1 Structure of this report 2 2 HOW THE PROJECT OBJECTIVES WERE MET 3 a) Develop a low-cost, and simple, way of collecting traffic data 3 b) Use collected data to more effectively plan and manage local transport systems 15 c) Use collected data to support dispatching services for local taxi operators 24 d) Establish an information platform to support public participation in transport system and network development 31 3 THE VALUE OF OPEN SOURCE SOFTWARE DEVELOPMENT 33 GNU Library General Public License (LGPL) 33 Ease of replication in other locations 33 Opportunity for further customisation and enhancement of software tools 34 4 VALIDATION OF COLLECTED DATA 35 Simulation 35 Test data sample from the demonstration project 35 Sanity-check sample data 35 Comparison with travel survey data 36 Findings and next steps 38 Requirements to achieve a live traffic dataset 38 5 PROOF OF CONCEPT EVALUATION 40 Evaluation activities 40 Software platform implementation costs 41 What has worked? Identified benefits of implementing taxi crowd sourcing 42 What hasn’t worked as well? Sub-optimal outcomes of the demonstration project 48 Key learning points to-date 55 6 SUSTAINING AND SCALING-UP THE SOFTWARE PLATFORM 58 Sustaining the tools in Cebu City 58 Scaling-up the existing software platform in Cebu City 60 Guidelines for replicating in other cities 63 7 LESSONS LEARNED FROM KEY IMPLEMENTATION CHALLENGES 65 25/06/2014 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT Procurement of handsets and data-plans 65 Software platform and firmware selection 65 In-vehicle charging of smartphone handsets 65 Wireless connectivity in Cebu 66 Local capacity to maintain the Cebu-Traffic server and database 66 Working with compliant partners 67 Viability of using TrafficProbe to collect real-time traffic data 67 Quality of OpenStreetMap (OSM) data 67 8 IDEAS FOR FUTURE PLATFORM DEVELOPMENT 68 Smartphone-based traffic enforcement tools 68 Enhanced taxi dispatch functionality 68 Regenerative creation of OSM data from crowd sourced traffic data 69 Developing an open crowd sourcing version of TrafficProbe 69 Variable Message Sign integration 69 Improved junction transit time data 70 LIST OF TABLES Page Table 2-1: Breakdown of costs to replicate TrafficProbe data collection tools 10 Table 2-2: Manual and TrafficProbe journey time survey costs (in USD $) 11 Table 2-3: Transport planning opportunities provided by the software tools 19 Table 2-4: Breakdown of costs to replicate Traffic Alert data collection tools 21 Table 4-1: Correlation summaries for intra-data set comparisons of inferred Cebu Traffic data and existing travel survey data 37 Table 5-1: Whole software platform implementation costs per annum (in USD $) 41 Table 6-1: Training needs identified through project evaluation 59 LIST OF FIGURES Follows Page Figure 2-1: TrafficProbe system diagram 4 Figure 2-2: Illustration showing the density of GPS location points captured from participating taxis using the TrafficProbe application in Cebu City 6 Figure 2-3: Visualisation showing how TrafficProbe server inference engine evaluates the path of individual vehicle movements to derive speed and journey time 7 Figure 2-4: Paper log-books used by CITOM’s COMMEL team 8 Figure 2-5: Screenshot showing traffic incident data entry tools 9 25/06/2014 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT Figure 2-6: Access to the CITOM portal of the Cebu Traffic website 16 Figure 2-7: Active traffic alerts displayed for Cebu 16 Figure 2-8: Search showing road closures recorded in Cebu City during July 2013 17 Figure 2-9: Sample CSV report output for traffic enforcer locations in Cebu City 17 Figure 2-10: Sample journey speed and time analysis of a user-defined route 18 Figure 2-11: ‘Crash Map’ showing incidents at key junctions in Cebu City in 07/13 20 Figure 2-12: Taxi operators’ access to the dispatch portal of Cebu Traffic 25 Figure 2-13: Screenshots of the TrafficProbe smartphone application 26 Figure 2-14: Panic Button display in the Cebu Traffic Taxi Dispatch view 27 Figure 2-15: Web and phone interfaces demonstrating two-way messaging functions 27 Figure 2-16: Taxi operator dispatch and vehicle tracking view 28 Figure 2-17: Filtered view showing taxis with live/unread messages 28 Figure 2-18: Visualisation of average traffic conditions in Cebu City based on April 2013 data collected through the TrafficProbe software platform 32 Figure 4-1: Bi-modal distribution showing average journey speeds by hour and day of week (M-F, Sa-Su, and combined) 36 Figure 4-2: Comparing within data sets, inter-peak to pm peak. Intra Cebu Traffic comparisons show a R value of 0.94, compared with existing data with 0.38 37 Figure 4-3: Inter-data set comparison by observation period. 38 Figure 4-4: Map of street segments with observation rate greater than one per hour between the hours of 8am-8pm based on 75 vehicle per-day sample 39 Figure 5-1: Taxi driver techniques for identifying congested roads in Cebu City 43 Figure 5-2: Cebu City taxi drivers’ perceptions of safety when driving their taxi 44 Figure 5-3: Drivers that have ever had to call the police in relation to their safety while driving their taxi in Cebu City 45 Figure 5-4: Taxi driver strategies for finding fares in Cebu City 46 Figure 5-5: Taxi drivers’ pre- and post-implementation perceptions of congestion 47 Figure 5-6: Breakdown of TrafficAlert data points entered by COMMEL team (Percentage of 16,702 data entries from Jan – Aug 2013) 48 Figure 5-7: Most common locations of data transmission failures experienced in Cebu City 50 Figure 5-8: Comparison between anticipated and achieved floating data point sample 52 Figure 5-9: Cebu City taxi drivers’ self-reported incomes before/after the project 54 Figure 6-1: Cebu City taxi drivers’ perceptions of the TrafficProbe app’s future value 58 Figure 7-1: Daily handset count, showing a significant drop in mid-August following operator re- provisioning 66 25/06/2014 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT APPENDICES Appendix A: Memorandum of Understanding documents prepared on behalf of CITOM Appendix B: TrafficProbe smartphone app configuration and installation guides Appendix C: Traffic Probe and Traffic Alert platform Implementation Guidelines 25/06/2014 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT 1 INTRODUCTION 1.1 This document constitutes the final report of Component 1 of the Transport Crowd Source Information and Communications Technology (ICT) Demonstration project, which focused upon crowd-sourcing traffic data from taxi vehicles in Cebu City, Philippines, using open source software tools and low-cost smartphones. It summarises all the deliverables provided by the project team during the course of the demonstration project, and documents the challenges met, and lessons learned, through program implementation; as well as providing ‘How-To’ guidelines for other cities interested in replicating such a program. Funding and implementation partners 1.2 The demonstration project was co-ordinated by the World Bank using funds from AusAid and the Korea ICT4D Trust, and implemented in partnership with Cebu City Government, the Philippines Department of Transport and Communications, Metro Cebu Taxi Operator Association. The project’s consulting team is particularly grateful to the local delivery teams at CITOM and MICS, with whom we worked closely to develop, implement and validate the taxi crowd sourcing software platform and associated software tools. Project objectives and their relevance to Cebu City 1.3 The project objectives were developed by the World Bank Task Team Leader in response to identified local issues associated with the collection of transport network performance data and its subsequent application. Specifically, the objectives were to:  Develop a proof of concept, low-cost, and simple, means to collect traffic data. o Use collected data to more effectively plan and manage local transport systems. o Use collected data to support dispatching services for local taxi operators. o Establish an information platform to support public participation in transport system and network development. 1.4 These objectives are directly relevant to the local context in Cebu City. Traffic congestion is a significant and worsening problem attributable to the rapid urbanisation occurring across the Philippines, which is the fastest urbanising country in East Asia. Fuelled by in- migration and natural population growth, the urban population of the country has already surpassed 50% and is expected to rise to 75% of the country’s population by 2030. The rapid urban and economic growth currently being experienced in Cebu City, the Philippines’ third largest city with a population of 800,000, regularly sees peak-hour traffic speeds as low as 6-10km/h with an estimated economic cost of up to 4.6% of GDP. The city’s 4,800 registered taxi vehicles contribute significantly to this traffic congestion and, combined with Jeepneys (PUJs) and Pedal-Taxis represent the main forms of public transportation in Cebu. 1.5 While the causes of traffic congestion in Cebu are complicated and varied, some contributing factors include: a) lack of efficient data-driven dispatch, routing, or management systems for transit; b) multiple traffic signal timings that are unsupported by traffic flow data due to the poor state of repair of the city’s SCATS system; c) low penetration of taxi dispatch service; d) absence of emergency dispatch or notification 25/06/2014 1 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT systems for accidents; and perhaps most fundamentally given the rapid growth being experienced in Cebu City e) limited local capacity for data-driven traffic management and planning. 1.6 Furthermore, Cebu City’s urban transport planners do not possess the information technology tools required to ensure the accurate and consistently-updated collection of data for road asset and transport system management, or future planning. The city’s SCATS traffic control system is also functioning sub-optimally due to a lack of functioning induction loops and data transmitters. The consequent lack of objective data for informing policy and investment decisions, combined with general distrust of local politicians and disbursement of public funding (according to the WEF Global Competitiveness indices, the Philippines ranks 135th out of 139 countries in terms of diversion of public funds, and 134th for public trust of politicians), inhibits city planners’ ability to ensure transparent, data-driven transport management, policy and investment planning. 1.7 The overarching aim of this project was therefore to demonstrate proof of concept versions of a suite of basic ICT tools that drew on GPS data collected and transmitted in real-time from a sample of the city’s 4,800 licensed taxi vehicles. Taxi vehicles were selected because each vehicle covers an average distance of 300km per day while searching for, and transporting passengers around the city. By collecting and aggregating traffic speed data that are valuable to Cebu City Government’s transport planning team, whilst also making the current position information of taxi vehicles available to each respective taxi company’s owners (essentially a free GPS vehicle tracking service for the life of the project), the project team sought to ensure a basis for collaboration whereby live traffic information was collected by taxis moving around the city on behalf of the city government. Structure of this report 1.8 The remainder of this document has been structured as follows:  Chapter 2 explains how the project delivery team met each of the 4 project objectives and details the software applications, innovations, and training and capacity building delivered through the project.  Chapter 3 demonstrates why open source software and open data are so valuable to both Cebu City Government and the World Bank.  Chapter 4 explains the validation activities undertaken through the course of the project, and sets out the findings from the data collected by the project team.  Chapter 5 details the various evaluation activities undertaken through the project, and sets out the findings from the data collected by the project team.  Chapter 6 provides commentary on how the demonstration software platform that was deployed in Cebu City could be sustained and scaled up in its current context, as well as replicated in other city contexts. A separate ‘How to’ Guide has been appended to this report to assist anyone interested in replicating the project in their local context.  Chapter 7 details the key challenges met, and lessons learned, through this project.  Chapter 8 concludes by setting out ideas for the future development of the software platform created through this project. 25/06/2014 2 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT 2 HOW THE PROJECT OBJECTIVES WERE MET 2.1 This chapter of the report examines each project objective in detail, and explains how the delivery team working on behalf of the World Bank collaborated with colleagues at Cebu City Government and local taxi operators to develop and implement the Cebu Traffic software platform. a) Develop a low-cost, and simple, way of collecting traffic data Cebu City’s SCATS traffic control system has the potential to provide a rich seam of traffic data for the whole city. Data is retained in the SCATS database for a 2 year period and could provide sufficient information to develop a city-wide transport plan for Cebu. However, 68 of the 77 signalised intersections in Cebu City have defective detector loops, which would generate this data, meaning that SCATS is not a reliable source of traffic data for transport planning activities and the signal timings have defaulted to test-plans. Instead CITOM officers currently gather data about the performance of Cebu City’s road network through manual traffic counts. These counts are commissioned on an ad-hoc basis and are required to provide a better understand of specific, isolated traffic problems that are the subject of amendments to the traffic system (e.g. Converting a street to one- way traffic) proposed by the CITOM board. Manually-collected traffic data are used to record traffic volumes, journey delay, turning counts at intersections, average journey times and classified vehicle counts. These traffic count reports are labour-intensive, and time-consuming to prepare. The workflow for preparing a report for the CITOM Board is illustrated below: 1) Proposal: 2) Data gathering 3) Spreadsheet model 4) Report E.g. Convert a street to Use manual traffic counts to Using the data gathered Data model is used to one-way traffic flow, demonstrate issues with through the manual traffic prepare a report for the usually originating from performance of the existing counts to model likely CITOM board who will review the CITOM Board or traffic network . Typically outcomes of altering the traffic it and decide whether to Mayor’s office. involves 6-8 personnel. flow in a specific location approve the proposal. 3 months to gather data and prepare report 1 month to review Software tools developed and target users 2.2 Three different sets of open-source software tools were created in order to facilitate more effective traffic data collection in Cebu City:  TrafficProbe smartphone app – used to collect data from ‘floating’ taxi vehicles.  TrafficProbe WebServer – used to aggregate and process the collected data.  TrafficAlert web-based tool – used to record traffic incidents and alerts. 2.3 The system diagram shown in Figure 2-1 illustrates how these data collection and processing activities relate to one other, and how they combine to provide data feeds for the web-based tools that are described later in this chapter. The remainder of this section describes in-turn each of the software tools developed and their target users. 25/06/2014 3 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT Figure 2-1: TrafficProbe system diagram Internet GPRS/3G Server GPRS/3G Database for Server GIS, GPS, and Incident Data Data Access API GPS Taxi • Congestion Map Taxi Operator CITOM Other Users • E-Market • Dispatch Map • Congestion Map • 3rd Party Apps • Panic Button • O&M Reports • Data Analysis Tools • O&M Alert • Field Report • Field Report Mapping Mapping 2.4 TrafficProbe Smartphone app: Working with colleagues at CITOM, the project team designed and developed an open source Android smartphone application called TrafficProbe. This was used as the means of collecting a continuous sample of vehicle location point data for multiple vehicles moving around the road network of Cebu at any given time.  Primary target users for the app itself were taxi drivers, who would be collecting data as they drove around Cebu, but could represent any vehicle fleet (e.g. public transit, city authority vehicles, garbage collection vehicles, privately owned vehicles). The aspects of the app designed to meet their needs have been documented later in this chapter in the section relating to taxi dispatch tools.  Secondary target users, of the data the app collected and transmitted, were Cebu City Government’s CITOM team and the taxi operators. The remainder of this section focuses on how the software was designed to meet their data needs. 2.5 Aside from being useable by local taxi drivers with variable English language skills and limited knowledge of maps and map-based software tools, the TrafficProbe app also needed to send data back via HTTP to the Cebu TrafficProbe web-server in a format that could be aggregated and related to the road network of Cebu City (for CITOM). The data also needed to be relayed to the taxi operators for vehicle tracking and dispatch operations. Finally, we were conscious that the app needed to work in the challenging taxi operating environment of Cebu (heat, dust, vibration) and overcome the variability in 3G/GPRS network data signals that we observed during our early testing. 25/06/2014 4 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT 2.6 The following features were incorporated into the TrafficProbe smartphone application in order to satisfy the data collection requirements, and were modified based on field-testing and end-user feedback:  Simple configuration and set-up procedures were deployed to ensure the process of registering each device running the application onto the Cebu instance of the TrafficProbe web-server was streamlined. The taxi vehicle body number (or license plate number), and driver name(s) could be used as the main identifier for the device. Once registered, these settings were pin-locked so that drivers could not alter them, and point-people at each taxi company received training in how to re-configure the devices. The setting also included more complex options relating to the frequency of data transmission and the wireless protocol that was used to transmit data. These options were only used during testing.  Continuous background operation of the application so that it starts up and runs whenever the device it is installed onto is powered on. This approach ensured that data were continuously being collected about the location of the devices placed in the vehicles. As a result the drivers could be using other features or applications on the phone (e.g. Facebook, Twitter, YouTube) and the data about their location would continue to be transmitted.  Geo-location of the device happened every 5 seconds, so that regular, time and date- stamped updates on the location of the vehicle were collected. These geo-location positions were buffered in the memory of the smartphone device until they had been transmitted to the server. This design-feature helped to overcome areas or times of day when we experienced variable wireless data connectivity and ensured none of the data collected by the apps were lost.  Data transmission protocols were deliberately streamlined in order to function optimally on low-cost Android handsets, and when operating in variable 3G/GPRS wireless data network conditions. Specifically, this involved the use of HTTP websockets as a means of providing a single bi-directional TCP (Transmission Control Protocol) link from each mobile handset running the Cebu Traffic application to the webserver receiving and aggregating the position data in real-time. The use of websockets enabled a two-way, on-going conversation to take place between the TrafficProbe app and the server over a HTTP data connection. This was required so that the application could simultaneously:  Send data to the server – time and date-stamped latitude/longitude coordinates of vehicles and push messages (a panic button alert and dispatch messages).  Receive data from the server – relevant OpenStreetMap (OSM) tiles of Cebu City, map-tile overlay visualisations showing live traffic speed/delay conditions and push message notifications (dispatch messages and traffic incident alerts). Data packets were sent from each device installed with the TrafficProbe app every 30 seconds, with GPS location being collected every 5 seconds. 2.7 TrafficProbe web-server: The cloud-hosted Cebu City instance of the TrafficProbe web- server performed the following vital functions in order to collate, and make sense of, the 25/06/2014 5 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT data being received from all of the TrafficProbe apps installed on smartphone devices moving around Cebu City in participating taxis:  Message processing: GPS location information generated by handsets and transmitted to the web-server and stored in a message processing queue. The queue allowed for the buffering of messages to ensure consistent and reliable processing of all location messages by separating the receipt and storage of incoming messages from the processing tasks. Figure 2-2 demonstrates the density of the point data being handles by this process. Figure 2-2: Illustration showing the density of GPS location points captured from participating taxis using the TrafficProbe application in Cebu City  Inference of data into vehicle tracks and time/travel information: The inference engine component of the web-server is responsible for converting point-in-time location messages into vehicle tracks and time travel information for specific roadway segments. Each vehicle tracked by the system maintained a temporary, in-memory, record of its most recent positions. This record is managed by a series of statistical methods (particle filters) that convert these point locations into travel legs and velocities mirroring known roadway segments, which we derived from OSM data for Cebu City (see Data processing and storage of traffic speed information: The inference engine stores the estimated travel time for each road segment. These travel times can be used to calculate average traffic speed (the travel time divided by segment length) for each segment. These segment level measurements serve as the basis for all subsequent analysis and are stored on the web-server for historical analysis and comparison.  Figure 2-3, overleaf). The techniques utilised by the inference engine follow established techniques developed for real-time bus tracking applications in New York City by OpenPlans, and made available as open source code. Our team modified this code in order to account for both routine and systematic stoppages, and to ensure that manoeuvres specific to taxi operations (e.g. U-Turns) were discarded from subsequent analyses of traffic conditions in Cebu City. 25/06/2014 6 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT  Data processing and storage of traffic speed information: The inference engine stores the estimated travel time for each road segment. These travel times can be used to calculate average traffic speed (the travel time divided by segment length) for each segment. These segment level measurements serve as the basis for all subsequent analysis and are stored on the web-server for historical analysis and comparison. Figure 2-3: Visualisation showing how TrafficProbe server inference engine evaluates the path of individual vehicle movements to derive speed and journey time  Data processing and storage of journey time information: Using the road segment travel time information generated by the inference engine, the web-server was able to generate journey times for all individual network segments, which could be joined-up to create a journey time data output along a specific route. These segment journey times were also stored on the web-server for historical analysis and comparison.  Data processing and storage of journey time information: Using the road segment travel time information generated by the inference engine, the web-server was able to generate journey times for all individual network segments, which could be joined-up to create a journey time data output along a specific route. These segment journey times were also stored on the web-server for historical analysis and comparison.  Data processing and storage of general traffic congestion levels: Traffic congestion levels were estimated by comparing current velocity against historical “free-flow” velocities for each given roadway segment. The degree of deviation from historical norms served as the congestion measurement. 2.8 Traffic Alert data entry tools: The third and final component of the traffic data collection software tools was delivered in response to a need identified through discussion with CITOM’s COMMEL team. The COMMEL team is responsible for managing and deploying the traffic enforcers in Cebu City. The enforcers typically attend traffic incidents, issue fines for traffic offences, and manually direct the traffic at busy times in locations where traffic signals are not functioning. 25/06/2014 7 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT 2.9 The team’s observation that the COMMEL team were using paper log-books (Figure 2-4) to maintain records of traffic incidents reported in Cebu prompted the design of a simple map- based data entry tool that mirrored this existing workflow. The fundamental difference was that, once entered into the system, the data were stored and remained for historic analysis and comparison using the visualisation tools described in section b of this chapter. Figure 2-4: Paper log-books used by CITOM’s COMMEL team 2.10 Figure 2-5 shows that by right-clicking on a map of the city’s road network that displays in the Traffic Alert section of CITOM’s web-based application, the COMMEL radio operators can enter details of an incident or traffic event whilst simultaneously receiving a radio call. Data entry fields include:  A title for the traffic event and a drop-down menu for the type of event (Incident, major event, traffic congestion, road closed, traffic enforcer deployed, fire, traffic signal problem, road construction, or flooding).  An optional ‘Public’ checkbox accompanied by Private (CITOM) and Public (pushed to the Cebu instance of the TrafficProbe application) descriptions for the item.  An option to enter an expiry time for the item, e.g. where a major event or set of roadworks are known to be finishing at a particular time or on a specific date. 25/06/2014 8 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT Figure 2-5: Screenshot showing traffic incident data entry tools 2.11 The data-set created through the Traffic Alert component of CITOM’s web-based ‘CebuTraffic’ portal augmented that from the TrafficProbe app and provides scope for richer analysis of traffic conditions in Cebu City. How the software addresses the challenge 2.12 The key components of this specific objective were to develop a low cost and simple means of collecting traffic data. When deployed in combination, the TrafficProbe smartphone application and web-server provide a means of collecting and aggregating in real-time the movements of multiple ‘floating car’ data probes around any road network environment where wireless data networks are present. This is particularly relevant to road networks in urban environments. The Traffic Alert data entry tool provides scope for CITOM’s COMMEL team to add context to the raw traffic speed and journey time datasets, by recording other issues and incidents taking place on the city’s road network. The common time and date stamps used across both data-sets serves to ensure comparability between the different sets of information and facilitates future analyses. 2.13 At the time of preparing this final report a total of 319 Samsung smartphone handsets (a combination of Galaxy Y and Galaxy Ace devices) loaded with the application had been installed into participating taxis that operate in Cebu City and surrounding areas. A further 191 devices are due to be installed by the team at CITOM as part of their on-going support for the pilot. During the course of the demonstration period an average of 75 devices appeared on the network on any given day, and around 30 devices were typically online at any given time. As a result of this sample the project team was able to collect an average of 0.6 million data points per day from taxi vehicles moving around Cebu City’s road network, which equates to an average of 2 million roadway segments per month. These data were 25/06/2014 9 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT made available for analysis through the web-based tools described elsewhere in this chapter, and would not have collected in Cebu were it not for this platform. 2.14 Cost: The cost of collecting this dataset is low when the vast quantity of data collected is considered. If the up-front cost of software development effort required to build this platform is written off as World Bank investment, and the cost of smartphone handsets is amortised over 3 years, then the estimated cost of collecting traffic data using the TrafficProbe smartphone app and server can be placed at $20 per vehicle per month when deployed to an existing vehicle fleet of 320 vehicles. This has been broken down in Table 2-1. Table 2-1: Breakdown of costs to replicate TrafficProbe data collection tools Item Cost ($ USD) Amortised fixed cost for smartphone hardware 10,667 1 Annual smartphone data costs 38,400 2 Annual server cloud hosting costs 03 Local technical support (smartphone installation and maintenance): 12,000 4 Remote ICT support (cloud server maintenance): 05 Total annual cost 51,467 Total cost per vehicle per annum 218 Total cost per vehicle per month 18 2.15 These costs can be further reduced for city authorities if the cost of smartphone purchase and/or data plans can be shared or outsourced to the owners of vehicle fleets who also stand to benefit from the collected data. In the case of Cebu City Government, it could be possible to negotiate such a deal with local taxi companies – who have benefitted from free automatic vehicle location (AVL) and taxi dispatch services through the demonstration project. 2.16 The project team has previously undertaken high quality GPS-based manual traffic speed and journey time data collection efforts in Cebu City in order to appraise the feasibility of implementing a BRT line. These data collection efforts typically involve 2 surveyors (a driver and an enumerator) driving along a specific road corridor at different times of day in order to collect GPS data and manual timings for each road segment. The collected data are then post-processed using MS Excel spread-sheets in order to calculate average journey times along each route segment so that they can be entered into a Cube area transport model. This post-processing effort takes 1.5 days per route surveyed, and adds considerable time to the whole process. Conducting such a journey time survey typically involves consideration of multiple routes and can therefore take 4-8 weeks from commencement of data collection to completion of data processing ready for analysis. 1 Represents a sample of 320 smartphone handsets purchased at a cost of USD $100 per handset and deployed in the field for 3 years. 2 Represents a USD $10 per month data plan for 320 handsets. 3 Provided by national government for project. Otherwise, ~ USD $100 hosting cost per month. 4 Represents 2 x local support staff at a day rate of USD $20. 5 Provided by national government. Otherwise ~ 17 days of software developer time at a day rate of USD $700. 25/06/2014 10 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT 2.17 Table 2-2 compares the cost of implementing the TrafficProbe data collection platform with a single handset/into an existing fleet of 320 vehicles (as deployed in Cebu City taxis) in order to collect 1 months’ worth of data – the equivalent of 15 manual route surveys. It reveals that the cost of deploying TrafficProbe is almost 6 times cheaper than comparative manual traffic surveys using one data collection device. Indeed, setting up and running a similar TrafficProbe sample of 320 devices with a team of 8 local Full Time Equivalent support staff members (to install and maintain the devices) would still cost less than the cost of conducting 15 route surveys over 30 days. Table 2-2: Manual and TrafficProbe journey time survey costs (in USD $) Cost item Manual survey TrafficProbe TrafficProbe (all costs in USD $) (15 routes/30 days) 1 device 30 days 320 devices 30 days GPS device (amortised over 36 7 3 889 months) Data consumed 0 10 3,200 Staff time for data 10,200 1,000 4,000 collection / support Post-processing of 1,500 1,050 1,200 collected data 6 Total 11,707 2,063 9,289 2.18 The main source of these cost savings is the removal of staff time required to conduct the surveys, as well as cheaper data post-processing costs at scale for the TrafficProbe application. These cost savings increase with the scale of sample required, because they are largely fixed cloud hosting and data costs for the TrafficProbe software implementation, while they scale with sample-size in a manual data collection effort. 2.19 A further benefit of the automated data collection and post-processing achieved by deploying the TrafficProbe smartphone apps and web-server is that this approach will yield a significantly greater volume of data than manual survey methods. Deploying all 320 devices for a cost of USD $9,289 for a single month would yield 17 million data points and journey time/speed data for approximately 2 million roadway segments based on the demonstration in Cebu City. This provides scope for whole network traffic speed and journey time analysis, at a cheaper price than collecting data manually for 15 routes. Collecting and inferring this volume of data to the road network manually would be an impossible undertaking in the space of 1 month. As such, the automation of post- processing of collected traffic data that is performed by the inference engine component of the TrafficProbe web-server is a key benefit of the software platform demonstrated in Cebu City. 2.20 Simplicity: the automated nature of data collection is a significant advance of the TrafficProbe platform. All the while the system remains operational there is no need for CITOM’s transport planning team to commission new manual journey time surveys, because they have a continuously updating data-set that they can analyse at-will. As such the 3 month lag-time associated with collecting traffic data (journey time, speed and delay 6 For the manual data surveys this assumes that Philippines-based data analysis staff members are conducting post-processing at a cost of USD $100 per route (1.5 days work). 25/06/2014 11 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT data) is removed from the transport planning process. The quality of the automatically collected data is also higher than that which is manually collected, since typographical and timing errors associated with analogue methods are removed from the traffic data set. 2.21 The major challenge to the simplicity of using TrafficProbe as a data collection platform relates to the reliability of the Android platform and the fallibility of smartphone devices as data collection probes. The issues identified by the project team through the demonstration project in Cebu City included:  Background operations on the smartphone devices (at Operating System level) which create an inherently unstable platform for ‘always on’ data collection tools and constantly rob the device of 3G/GPRS bandwidth and system memory.  The need to maintain a substantial number of smartphones and occasionally re-load the application or re-boot the whole device – largely as a result of processes associated with the Android operating system/other applications. This responsibility fell to a team of staff members at CITOM and the participating taxi operators. Maintaining the smartphone devices in a connected and operational state was a daily task.  Supplying power to smartphone devices in vehicles. This proved to be a real test in the taxi operating environment of Cebu, where the heat, dust and vibration from poor road surfaces meant that a significant number of in-vehicle 12v charging connections and associated wiring looms do not function reliably. While it may be possible to hardwire the device to the vehicle accessories unit, the project team was unable to find a commercially available solution that would provide anything more reliable than the 12v socket manufactured into the taxi vehicles.  Smartphone devices can easily be removed from the vehicle or turned off. While this was necessary for driver safety and compliance (responding to drivers concerns about potentially becoming targets for violent crime), it meant the size of the effective sample of vehicles transmitting data to the server was reduced each day based on driver compliance. 2.22 These reasons explain the relatively small live (30 devices) and daily (75 devices) samples achieved through the course of this demonstration project from our floating vehicle population of 320 taxi vehicles. 2.23 Additional Advantages: A number of additional advantages are associated with the TrafficProbe data collection approach. The provision of a continuous supply of data, typically only available from UTMC systems or cell phone network data, means that proactive and strategic transport planning activities are immediately achievable. Also, the fact the data collection software is open source (see Chapter 3 for more details) means that it can be readily changed and customised in the future in order to meet other contexts. 2.24 The additional functionality provided by the TrafficAlert data entry platform is also a significant advantage, and value-add, for the software platform which emerged from the team’s efforts to address the traffic data collection objective for the project. Innovations 2.25 The following innovations were required in order to meet this program objective: 25/06/2014 12 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT  Collaboration between taxi fleet owners, drivers and city government. Ensuring that the wider software platform and analytical tools provided ‘something for everyone’ was important. The fundamental need to obtain valid traffic data for analysis by CITOM was supported by the interests of taxi operators in knowing where there vehicles are and, as a result, the project team was able to work with CITOM to develop a set of Memorandum of Understanding agreements (see Appendix A) that ensured the interests of all parties were respected. Specifically, these covered:  Ownership of smartphones and their use (CITOM)  Receipt of vehicle tracking data and dispatch operations (taxi operators)  Respect for data privacy from CITOM to ensure the data collection and visualisation tools did not become a  App power-saving features: Due to the issues experienced with variable power supply in vehicles, power saving features adopted from the from the mobile computer games industry (see http://gamedev.stackexchange.com/questions/18686/optimal-data-size- for-a-3g-client-server-game) were designed into the TrafficProbe smartphone app. Specifically these included:  Using Protocol Buffers to reduced data transmission packet size and frequency to prevent cell radio from entering full-power DCH transmit mode;  Optimising GPS data sampling and background wait state;  Reducing data transmission and power consumption by a factor of five when using Websockets (can be used when network reliability permits). Training and capacity building delivered 2.26 A substantial amount of local training and capacity building was delivered in order to ensure that CITOM’s local support team, and the staff/drivers at participating taxi operators were equipped to install and manage the TrafficProbe application onto the Samsung smartphones procured for the demonstration project. The following components of training were provided by the project team in relation to the data collection tools:  Training for CITOM staff members on how to configure and install the TrafficProbe application onto the smartphone devices from first turning on the ‘phones.  Training for CITOM staff members and point people at taxi companies on how to install and mount the smartphone devices into taxi vehicles, and how to operate the TrafficProbe application.  Group training for taxi drivers at each participating company in order to explain the purpose of the TrafficProbe application, how it worked, and what they were signing up to by agreeing to participate in the project. 25/06/2014 13 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT  Troubleshooting guides for CITOM staff members and point people at taxi companies to help resolve common issues experienced with the performance of the TrafficProbe application and Android smartphone devices.  Training for the COMMEL team in how to use the TrafficAlert data entry tools, which was led by in Cebuano members of the CITOM team with support from the project team. 2.27 Appendix B to this report contains the step-by-step smartphone configuration and in- vehicle installation guides that were produced in relation to the TrafficProbe application deployed in Cebu. 25/06/2014 14 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT b) Use collected data to more effectively plan and manage local transport systems The transport planning role and capacity in Cebu City is currently in a state of flux as a result of an organisational change process. A city ordinance upgrading CITOM into a city department was passed in June 2010, thereby creating the Cebu City Transportation Office (CCTO). Though this ordinance has been approved, the actual and full transformation of CITOM has yet to take place. In the interim, CITOM continues to function according to its original mandate – providing traffic enforcement and management within the administrative bounds of Cebu City. Responsibility for transport planning and more active transport management to improve the performance of the transport network remains primarily with the national government through the Department of Transport and Communications (DOTC) and the Department of Public Works & Highways (DPWH) for national road network development. This planning function is remote and has, historically, been exercised with the lightest of touches. The upgrading of CITOM into the CCTO therefore aims to address this long-standing issue. As such there is currently no strategic transport planning function within CITOM, which partially explains the lack of pressure for city-wide traffic data sets, with both the transport planning and traffic signals teams under-staffed. CITOM was transferred responsibility for managing the GIS layers associated with PUJ routes, railings and traffic signs assets from MICS in 2010, with one member of staff at CITOM receiving training on how to use the ArcView GIS software. This is used to display and manage GIS data, which CITOM maintains for the City Government’s Management of Information and Computer Systems (MICS) department. As a result of these issues, most of the proposed changes to the traffic system are currently focused on the downtown and Carbon areas of Cebu City, because these are where traffic congestion is most commonly an issue. The long lead-times for traffic data collection highlighted in section 2a, and lack of up-to-date sources of city-wide data, means that almost all transport planning efforts typically follow a proposal to change an aspect of highway infrastructure, rather than being undertaken pre-emptively, or as part of a strategic transport planning activities. The result is a lack of proactive and strategic transport planning in Cebu City, and instead a tendency for transport data collection efforts to be reactive to the ideas and proposals of local decision-makers. Consequently most transport planning decisions in Cebu City are politically-led, rather than driven by good data and commonly used transport planning appraisal techniques. Software tools developed and target users 2.28 Two different components of a web-based, and open-source, CITOM traffic analysis software tool were created in order to facilitate more effective planning and management of Cebu City’s transport system by the relevant team at CITOM:  Traffic Alerts – online tool for visualising Traffic Alerts input by the COMMEL team.  Journey Time Analysis – online tool for visualising journey time and speed data. 2.29 Both tools are accessed through a password-protected section of the Cebu Traffic website (www.cebutraffic.org), and consume data-feeds provided by the TrafficProbe web-server and TrafficAlert data entry tools described in section 2a. Users with an account registered 25/06/2014 15 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT on the server with ‘CITOM’ access rights can use both the Traffic Alert and Journey Time Analysis options (Figure 2-6). Figure 2-6: Access to the CITOM portal of the Cebu Traffic website 2.30 In both views a user has access to a set of map-based graphical user interfaces that enable them to customise enquiries of the underlying databases by a range of different options relevant to the data-set. The target users for these tools were staff in the CITOM transport planning and COMMEL teams, for whom the ability to use intuitive map-based (GIS-like) tools is a significant improvement on existing paper-based practices. The visualisation of data on maps both simplifies the process of understanding the information collected, and aids intuitive analyses. Specific features of each tool are discussed below. 2.31 The Traffic Alert visualisation tool: allows CITOM users to filter all/active alerts:  Active alerts (shown by default – see Figure 2-7) shows only those alerts which are currently ‘live’ based on the incident reports being logged by the COMMEL team. They are visualised as point of interest overlays on an OpenStreetMap base-map of Cebu. Users can filter currently active traffic alerts according to their type, and/or by keyword. Figure 2-7: Active traffic alerts displayed for Cebu  All alerts presents a user with a series of options that enable them to customise their search query further. As well as being able to define the type of alert to be displayed, this tool enables a user to define the date-range for which they would like to display data (see Figure 2-8). 25/06/2014 16 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT Figure 2-8: Search showing road closures recorded in Cebu City during July 2013 2.32 In both the Active and All alert views, the user has the option to download an MS Excel CSV (Comma Separated Variable) file containing all of the data points displayed on-screen for further analyses. As Figure 2-9 shows, these reports contain all of the data visualised as a result of the most recent search enquiry, or default view shown on the screen, and contain the fields: Type, Active from, Active to, User description, Public description, Latitude, and Longitude. Figure 2-9: Sample CSV report output for traffic enforcer locations in Cebu City 2.33 The Journey Time Analysis visualisation tool: allows members of the CITOM team to define routes in Cebu City on which they would like to perform journey time analysis by clicking desired ‘start’ and ‘end’ locations onto an OSM base map. In response the application does several things simultaneously:  Consults the OSM road network data (via an API - Application Programming Interface) in order to draw out the route that the user wants to check. The route drawn is based on the movement paths (e.g. no right turn / one way streets) defined in the underlying OSM database, so good OSM data in the city is critical for this to work effectively.  Looks up data from the TrafficProbe web-server (also via an API) for all of the corresponding roadway segments and extracts the relevant average speed data for defined time/date periods. 25/06/2014 17 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT Figure 2-10: Sample journey speed and time analysis of a user-defined route 2.34 The journey time analysis tool additionally provides CITOM’s transport planning team with several useful tools that enable them to customise their analyses. These include:  Comparisons between different months of the year. Monthly data comparisons are the finest grain of data-level supported by the sample of traffic data collected in Cebu City by participating taxi vehicles using the TrafficProbe application (see Chapter 4 on data validation for details).  Comparisons between different times of day – allowing users to compare travel times for traffic conditions within specific hour ranges (e.g. morning peak, inter-peak, evening- peak and overnight free-flow).  The ability to save routes so that they can be re-visited and re-analysed as required. How the software addresses the challenge 2.35 The software tools described above directly address the objective of using data collected through the course of this demonstration project in order to more effectively plan and manage transport systems in Cebu City. 2.36 Using collected data: Both the Traffic Alert and Journey Time Analysis tool draw on data recorded and collected by the tools created through this demonstration project, and described in Section 2a of this chapter:  The Traffic Alert tool was deliberately designed, and iteratively developed, so that it would be easy for the COMMEL team to digitally record information about accidents and incidents as part of their existing workflow. All of the information fields directly replicate those recorded into paper logbooks by the COMMEL team, but have the added benefit of being digitally recorded to support transport planning and management. Since these data were not being maintained in such formats previously, the scope for using them for analytical purposes was limited and not pursued due to the effort that encoding information from the COMMEL log-books would involve.  The Journey Time Analysis tool uses data collected by the TrafficProbe applications installed on Android mobile phones installed into taxi vehicles operating in Cebu City during the course of the demonstration project. The data are specifically formatted by and stored in the Traffic Probe server so that they can be used for transport planning analyses. 2.37 More effectively plan: The Traffic Alert and Journey Time analysis tools enable both time- series and geo-spatial visualisation across the range of different event types recorded by 25/06/2014 18 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT the COMMEL team, as well as the traffic speed and delay data aggregated by the TrafficProbe web-server. Table 2-2 details the scope for these analyses and shows the number of data points recorded in the Cebu City database through the data collection methods described in section 2a between January and the end of July of 2013. Table 2-3: Transport planning opportunities provided by the software tools Number of data Metric Transport planning value points (01/13 – 08/13) • Crash mapping • Road safety reporting Traffic incidents 2,542 recorded • Relation to road closures and traffic signal problems • Congestion event mapping • Relation to roadworks, traffic signal Traffic congestion problems, major events. 69 recorded events • Relation to average traffic speeds and journey times. • Non-transport related incident mapping 41 events recorded Major events, • Relation to congestion events, average 48 fires recorded fires and flooding traffic speeds and journey times 16 floods recorded • Mapping closure locations and purpose • Relation to traffic incidents, congestion Road closures 93 recorded events and average traffic speeds / journey times. • Traffic signal investment/repair planning Traffic signal • Relation to traffic enforcer locations, 33 recorded problems congestion events and average traffic speeds/journey times. • Roadwork location mapping Roadworks • Relation to congestion events and 44 recorded average traffic speeds/journey times • Analysis of enforcer locations for future resource and incident response plans. Traffic Enforcer • Relation to traffic incidents, major 13,816 recorded locations events, traffic signal problems and road closures. Average traffic • Network wide analysis at different times • 71 million location speeds of day / days of week / months of year. records • Relation to all other metrics to • 10 million road Average journey understand impacts of events and segment velocity times incidents on speeds and journey times observations 2.38 While it is very clear that the COMMEL team is most diligently recording the locations and actions of its team of traffic enforcers (an operational requirement), the transport planning value of the digital database created through the demonstration project is also evident. For example, the ability to produce simple visualisations, such as the traffic incident ‘crash map’ shown in Figure 2-11 for traffic incidents in Cebu City in July 2013, reveals concentrations of collisions at the junctions of P.Del Rosario Street and Leon Kilat and P.Del Rosario Street and Sikatuna Street/IMUS Avenue indicating potential road safety black-spots requiring further investigation. 25/06/2014 19 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT Figure 2-11: ‘Crash Map’ showing incidents at key junctions in Cebu City in 07/13 2.39 Transport planning analyses such as this were not taking place at CITOM prior to this demonstration project, because it would have required months of human effort to manually interpret and input the information contained in the COMMEL logbooks (for example into an offline GIS software package) before being able to analyse the data. A reliable cost estimate of time taken to complete such a manual data analysis task is therefore very difficult to make. 2.40 What we do know is that the cost of implementing the Traffic Alert data collection and visualisation tools in Cebu City has been relatively low. When the costs of software development are written off as World Bank investment in the platform (which can be replicated in other locations), and the cost of PC workstations and connectivity equipment required in the COMMEL radio room is amortised over 3 years, then the estimated cost of collecting and analysing traffic alert using the Traffic Alerts tool can be placed at $646 per month (as broken down in Table 2-3). The majority of this cost is for the staff time needed to analyse the collected data. 2.41 This equates to approximately 1.3 Full Time Equivalent (FTE) technical staff members working in CITOM’s transport planning team, or 1 FTE staff member and a licensed copy of ARCGIS software for desktop. Given the scale of data collected as part of the day-to-day operation of the COMMEL team, it is clear that the cost of manually collating this data for analysis, and then analysing it using offline GIS tools and/or database enquiry tools would be several orders of magnitude higher than the equivalent cost of implementing the Traffic Alert software tool. 2.42 Furthermore, these costs can be reduced if (as in the Cebu City CITOM office) an existing broadband connection is used and shared to provide the necessary connectivity. Also, when deployed alongside the TrafficProbe platform, the cloud server hosting and maintenance costs benefit from scale economies of implementation. 25/06/2014 20 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT Table 2-4: Breakdown of costs to replicate Traffic Alert data collection tools Item Cost ($ USD) Amortised fixed cost for PC workstations 333 7 Amortised fixed cost for PC connectivity equipment (router and cables) 33 8 Annual broadband connection costs 180 9 Annual server hosting and management cost 1,200 10 Local staff time for analysis of collected data 6,000 11 Total annual cost 7,747 Cost per month over 3 years 646 2.43 As a result of the implementation of the Traffic Alert and Journey Time Analysis visualisation tools, CITOM and its transport planning team now has access to the richest set of data it has ever known for in-depth transport planning analyses and strategy development. Implementing such tools prior to exploring the feasibility of major transport investments – such as new mass transit lines in cities like Cebu – also presents considerable scope for funding bodies and aid donors to more quickly and cheaply understand and appraise the potential impact and viability of such major schemes. 2.44 More effectively manage: The same combination of geospatial and time-series data visualisations also present new opportunities for CITOM to improve the way it manages Cebu City’s transport network. The following changes to existing processes were successfully adopted during the course of the demonstration project:  Digitally tracking and managing the locations and actions of traffic enforcers in Cebu City, in conjunction with the existing radio network used by the enforcers – from February 2013 onwards.  Use of the geo-spatial Traffic Alert tools to proactively plan, and manage in real-time, the road closures needed to host the annual Sinulog parades in January 2013.  Using the TrafficProbe smartphone application to track local bus services for Cebu City’s Gabii sa Kabilin (Night of Heritage) on Friday 31st May 2013. The phones were installed into buses, which were also assigned radio communicators and managed remotely via the Cebu Traffic platform (mainly used by taxi operators through this demonstration project) which CITOM’s dispatch team used to monitor each vehicle’s movements and ensure a reasonable frequency of arrivals and departures at each participating venue. Without being able to monitor the GPS locations of the buses in real-time, it would not have been possible to ensure a reliable frequency of bus services was maintained during the evening’s event. 2.45 An additional opportunity for enhanced transport network management which was discussed with the CITOM team includes publicly sharing limited details of traffic incidents, flooding and fires via the CebuTraffic website. This was happening to some extent, but there is scope for the COMMEL team to be more diligent about publicly sharing information 7 Represents 2 PCs purchased at a cost of USD $500 each and deployed for 3 years. 8 Represents USD $100 outlay on a router and cabling. 9 Represents USD $15 per month on a 1Mb/s broadband connection. 10 Represents a USD $100 hosting and server maintenance cost per month. 11 Represents 1 x local transport planning staff member at a day rate of USD $20 25/06/2014 21 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT about live incidents so that members of the public are better informed about traffic incidents and disruptions before making journeys in Cebu City. 2.46 If adopted, both of these practices offer scope to reduce traffic congestion in Cebu and reduce journey times on the city’s road network. Innovations 2.47 The following innovations have been delivered in order to meet this program objective:  Design of software tools for desk-based environments with limited data connectivity: To overcome slow broadband speeds at Cebu City Government offices, the project team sought to minimise the amount of data being requested and visualised on each view of the web-based Cebu Traffic tools by:  Minimising the number of data points and amount of information displayed on default views – custom input is required on most views to visualise significant numbers of data points.  Using very low-resolution .png image files for all icons, background imagery, map overlays, and base map tiles from OSM; to ensure that each image being displayed was no more than a few kilobytes in size.  Using default zoom levels that minimise the number of data points that need to be displayed when screens are first loaded.  Development of geo-spatial editing tools in a real-time web-based environment – These simple online tools removed the need for multiple staff members requiring training on how to use complex, dedicated GIS software tools that are typically used for the offline maintenance of geo-spatial datasets. Such tools also carry high user licence costs (ARCGIS costs around $1,500 per annum) which are unsustainable for an organisation such as Cebu City Government if multiple users are to use the software.  Collaborative editing of geo-spatial information in real-time – Following on from the point above, this includes the ability to store data alongside geo-spatial points of reference, through the Traffic Alerts tool, and for different users to collaboratively edit these data points. This would not be possible in real-time using an offline GIS software tool.  Journey Time Analysis tools based on OSM road network data – Our team’s use of the OSM API to pull-in road network segment lengths (edges), and then apply these values to calculate average journey times and speeds based on the transit times of vehicles (carrying Android handsets on which the TrafficProbe app is installed) across each road segment is highly innovative in its own right. Without this underlying OSM data-set, and the associated technology, it would not be possible for the software tools to visualise traffic speed or journey time data in real-time.  Real-time consumption of OSM map tiles – A further benefit of building the TrafficProbe and Cebu Traffic software platforms on OSM map tiles is that they also benefit from third party technical innovation. The Leaflet map-tiles provided by Mapbox (and derived from OSM) is a good example of this. Any changes made to the underlying OSM data are refreshed and updated to the maps displayed on the TrafficProbe smartphone application and Cebu Traffic website within 5 minutes. This provided a great incentive 25/06/2014 22 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT for members of the CITOM team who, following OSM map editing training, quickly realised that they had the power to correct any errors in the OSM data so that the maps appeared correctly in the TrafficProbe and Cebu Traffic software tools.  Traffic speed/journey time visualisation tools – Making a simple distinction between relative and absolute average traffic speeds and journey time visualisation required innovative geo-spatial visualisation techniques. This includes on-the-fly creation of traffic speed overlay map “tiles” and leveraging in-browser rendering of vector geospatial data formats (GeoJSON) to support dynamic visualization. Additionally the user interface for travel analysis tools utilizes a built in routing engine to automate the selection of street segments for specific origin/destination pairs. 2.48 All of these innovations were necessary in order for the web-based software developed by the project team to be both useable in the context of Cebu City Government offices, and user friendly for the various teams at CITOM. Training and capacity building delivered 2.49 The tools described in this section were designed to be simple and intuitive so that users would not need extensive training or documentation in order to use them. This proved to be the case, with iterative prompts built into the user interface serving as the main way that members of CITOM staff learned how to use the tools. 2.50 To ensure that the relevant teams at CITOM understood the tools the project team conducted interactive in-person training sessions with the key ‘point-people’ in the COMMEL Traffic enforcement team, CITOM Transport planning team and CITOM Scats team. Each one took the form of a walk-through of the relevant software tools and a follow- up discussion around the ways the local teams would use them. 25/06/2014 23 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT c) Use collected data to support dispatching services for local taxi operators The majority of taxis operating in Cebu City are owned by large operators, who lease their vehicles out to a pool of drivers that work for their firm. They operate 24/7 with vehicles out on the road, and maintenance facilities available, around the clock. A smaller number of independent taxi drivers own and drive their own vehicles. Most taxi drivers in Cebu are not salaried, but keep the remainder of the earnings left over once they have cleared their fixed daily costs. The Boundary Fees collected by operators are used to repay the capital cost of purchasing a taxi vehicle, as well as the parts and labour needed to keep the taxi fleet on the road. Higher fees are typically charged at Christmas and Sinulog, when there are greater numbers of tourists in Cebu City. Under this operating model, both the taxi driver and taxi operator have an interest in maximising revenues and minimising their costs. For the taxi drivers this means finding and transporting passengers as economically as possible, which can be challenging due to the competition for fares that exists as a result of an apparent oversupply of taxis in the City – 93% of taxi drivers interviewed in Cebu City stated that a key part of their strategy for finding fares involved avoiding traffic congestion, because it costs time, increases fuel costs and is stressful. For operators it means performing routine vehicle maintenance in a timely and efficient manner, and ensuring drivers pay their Boundary Fees. At some point during each working day a taxi driver is likely to visit their depot in order to pay their Boundary Fee (for vehicle rental, cleaning and radio hire) and re-fuel their vehicle. Drivers who rent their vehicles for 24 hours at a time usually alternate their shifts with another driver. Vehicle exchanges do not routinely take place at the taxi depot, since some drivers pick each other up and get dropped off at their homes. For taxi operators loss of/theft from vehicles is a particular issue, and the fact that drivers exchange the vehicle ‘off-premises’ can make it hard to attribute responsibility for any losses. While GPS-based vehicle tracking is seen as an ideal solution to this issue, it is considered too expensive by most taxi firms. A relatively small proportion (13%) of the taxis operating in Cebu City has radio despatch, and they belong to the largest taxi firms. Those that operate radio networks estimate around 30% of all fares come through passengers telephoning the company to request/book a taxi, with vehicles subsequently dispatched by radio. Mountain Barangay’s in Cebu City and its surrounds are the most common source of these requests. Radio dispatch networks are also used by drivers to share information about traffic conditions in the city, road accidents, fires and floods. Taxi drivers in Cebu City are regularly the targets of violent crime, primarily because they are known to carry cash. Many (18% of drivers surveyed by the project team) resort to carefully selecting which passengers they pick up, but 12% arm themselves and 10% know self-defence in the event they need to react to a threatening situation. Software tools developed and target users 2.51 Two distinct, but inter-related, software components were developed by the project team in response to this objective:  The user interface for the TrafficProbe smartphone app was designed to meet the needs of taxi drivers in Cebu City, keeping them in contact with their taxi dispatch office 25/06/2014 24 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT and showing their current location on a map of Cebu relative to traffic incidents and alerts.  The Taxi Dispatch interface within the Cebu Traffic website was developed with the specific needs of taxi operators in mind, and focused on vehicle tracking and dispatch. 2.52 As noted in section 2a, the TrafficProbe app is downloadable from the Google Play store, while the Taxi Dispatch section of the Cebu Traffic website is accessed through a password-protected section of the Cebu Traffic website (www.cebutraffic.org). The Taxi Dispatch tools consume the data-feeds (APIs) provided by the TrafficProbe web-server described in section 2a, which themselves draw on the data collected by the TrafficProbe app placed in taxi vehicles. Users working at taxi operators each have accounts registered on the server with access rights to their firms’ vehicle data (Figure 2-12). Figure 2-12: Taxi operators’ access to the dispatch portal of Cebu Traffic 2.53 Carefully defined access privileges ensure that each taxi company can only see their own vehicles’ data, whilst also ensuring that CITOM staff members only see the anonymised locations of taxi vehicles. This was essential in order to overcome data privacy concerns held by taxi operators and drivers who would not co-operate in the demonstration project if there was scope for the taxi vehicle location data to be used against them by CITOM as an enforcement tool. 2.54 TrafficProbe smartphone application: The design of the user interface for the TrafficProbe smartphone application was specifically based upon the project team’s early stakeholder engagement activities which found that:  Approximately 60% of taxi drivers speak English, while a further 30% understand English but do not speak it.  78% of drivers had a mobile phone, but few owned a smartphone.  Taxi drivers in Cebu were happy to share anonymised data about their vehicle’s location with CITOM, but needed to be incentivised in some way to keep the application running on a smartphone.  Taxi drivers seldom use maps, and noted that any live congestion maps would need to include clear street names and local landmarks for the app to be useful to them.  Taxi drivers had legitimate concerns about their personal safety, because taxis were frequently a target for violent and late-night crime. 2.55 Based on these identified needs, the following design features were built into the TrafficProbe smartphone app: 25/06/2014 25 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT  A simple Graphical User Interface (GUI): This was required primarily so that taxi drivers with variable reading and English comprehension skills could use the app. As such the default view was a map showing the user’s current location (which followed movement around the map) in relation to the street network of Cebu, with dispatch messages appearing on-screen when they were received, and clearing automatically/following a response. OSM map tiles with clear street-names were used as the basis for the map shown on the application, while simple +/- zoom buttons and re-centre options were provided to aid navigation around the city by taxi drivers (Figure 2-13). The simplicity of operation was also intentional so that drivers would not be tempted to use the device while in-motion, so as to comply with a city ordinance mandating no use of cell phones whilst driving in Cebu City. Figure 2-13: Screenshots of the TrafficProbe smartphone application  Turn traffic alerts on/off: Drivers could toggle traffic alerts (as input and made publicly available by CITOM staff members) by selecting the blue ‘point of interest’ icon in the top right hand corner of the map screen (See Figure 2-13). In doing so, all publicly available alerts about traffic congestion, incidents, major events, road closures, floods and fires are displayed on the map in the location they are placed by CITOM’s COMMEL team.  Panic button: A simple ‘!’ icon was included to form a panic button feature. The visible black and white triangle shaped ‘button’ located in the bottom right hand corner of the app display (Figure 2-13) was activated by the driver long-pushing on the icon. This action sent a push-message alert via the TrafficProbe web-server to the relevant taxi company’s dispatch view, which resulted in a distinctive icon being displayed alongside the relevant taxi vehicle (see Figure 2-14) so that the staff at the dispatch office were immediately made aware that a driver had pushed the button and was likely in trouble. The taxi company could then contact the City Police, and/or other drivers in the vicinity, and notify them of the location of the vehicle in trouble. The panic button was intended to provide a secondary form of safety device in support of an Emergency Assistance 25/06/2014 26 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT Device (EAD or ‘Blinker’ light) light which is fitted to the top of taxis in Cebu City, and activated by the driver flicking a switch in their cab. Figure 2-14: Panic Button display in the Cebu Traffic Taxi Dispatch view  The push-messaging functionality built into the Android Operating System (OS) was leveraged to enable two-way written dispatch communications between taxi drivers and their dispatch operators (See Figure 2-15). Drivers with the app installed and running on their device were able to receive and respond to messages with their dispatch team, who could use their dispatch view to prepare and send messages to drivers. Alongside this messaging functionality, the taxi operators were also able to contact the drivers on the Android devices that they received through the project via SMS and voice calling. The drivers were not able to make out-going calls or send SMS messages, and the system was intended to complement existing radio communications by allowing taxi operators to send written addresses, or directions to their drivers when dispatching them to collect passengers. Figure 2-15: Web and phone interfaces demonstrating two-way messaging functions  Continued operation if the device was removed from the dashboard mount: During briefings at each taxi compound the drivers were encouraged to hide the device out of sight (e.g. in the glovebox, or a door pocket) in the event that they felt threatened by a passenger or the area of the city they were working in. The app was designed to continue transmitting the location of each device when operating in the background, with the app launching whenever the device it was installed on was re-booted. 2.56 Taxi operator dispatch and vehicle tracking tools: These web-based tools were designed to fully integrate with the smartphone app described above in order to display the 25/06/2014 27 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT real-time locations of each operator’s taxi vehicle fleet, and provide them with a dispatch messaging function (Figure 2-15). This view also shows incoming messages received from each vehicle, and (if entered when the device is registered) can show the mobile phone number that the driver can be contacted directly upon. Figure 2-16: Taxi operator dispatch and vehicle tracking view 2.57 The taxi dispatch view provides filters which enable the taxi dispatch operators to see the locations of all their taxis (Android devices running the app), only those which are active, and those with live messages requiring review (See Figure 2-16). This view also provides taxi dispatch operators with the opportunity to toggle on/off the same set of public Traffic Alerts, as input and shared by the COMMEL team, which taxi drivers can see when using the TrafficProbe smartphone app. Figure 2-17: Filtered view showing taxis with live/unread messages 2.58 Basic taxi operator vehicle operations & maintenance tools: were included to provide additional value for taxi operators. These simple tools tracked the distance travelled in kilometres by their fleet’s vehicles on a daily, last seven day, and last 30 day basis. How the software addresses the challenge 2.59 The software tools meet the challenge of this objective by providing an integrated platform for taxi vehicle tracking, taxi dispatch via instant messaging, and the analysis of operations and maintenance data. All aspects of this platform rely totally upon full-compliance from taxi drivers of participating firms in Cebu, who needed to ensure that the smartphone device remains in their taxi and powered-up at all times. The issues created by this requirement are discussed in the evaluation section of this report (see Chapter 5). 2.60 The GPS-based vehicle tracking functionality provided by the combination of the TrafficProbe smartphone app and Cebu 25/06/2014 28 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT Traffic web-based interface, satisfied the Cebu City taxi operator’s desire to know where there vehicles are at any given time. The unique approach of using open source Android applications installed on smartphones mounted into vehicles proved to be cost-effective. When compared with average USD $27 per month per vehicle cost 12 of the Tramigo vehicle tracking solution that had previously been piloted by CTC (one of the largest taxi operators in Cebu City), the USD $20 per month cost to deploy the TrafficProbe application (as described in section 2a) is around 25% cheaper. 2.61 The taxi dispatch tools provide scope for operators not already running radio dispatch operations to add this service to their taxi fleets. At the cost of USD $20 per vehicle per month, this would be expensive relative to a one-off investment in radio equipment and on-going maintenance, but the added value of vehicle tracking and vehicle operations and maintenance data is likely to make the TrafficProbe/Cebu Traffic solution quite compelling for most taxi operators. 2.62 The operations and maintenance tools offer scope for taxi firms to adopt a more reliable, and less labour-intensive, approach to determining maintenance regimes for taxi vehicles operating in Cebu City. Provided that the smartphones running the TrafficProbe application remain turned on and in the vehicle, then a reliable record of vehicle kilometres travelled can be maintained digitally in order to inform the frequency of routine taxi maintenance items, such as oil-change and timing belt replacements. This would replace the commonly quoted 300km per day mileage ‘rule of thumb’, requiring depot supervisors and fuel cashiers to collaborate on mileage logs (based on fuel consumed), or checking daily taxi meter print-outs, as a more accurate means of calculating the approximate mileage of taxi vehicles. Analysis of the kilometres travelled data could also enable taxi operators to understand peaks and troughs in boundary fee earnings reported by their drivers. Innovations 2.63 The following innovations were delivered in the course of meeting this project objective:  The use of an Android device rather than a dedicated GPS unit for vehicle tracking. As well as reducing the overall cost of GPS Automatic Vehicle Location by around 25%, the use of an Android device proved to be a viable way of collecting vehicle location data for taxi operators. The cost could be further reduced if driver’s own devices were leveraged to deploy the TrafficProbe application, but this was not possible in Cebu because so few drivers had smartphones. While this approach is viable, it relied totally on driver compliance and willingness to participate. As observed in Chapter 5 of this report, this was undermined by two key factors: 12 Based on reported values of USD $10 per device for a SIM and data connection, and USD $500 per connected GPS tracking device (amortised to USD $167 over a three year replacement cycle). 25/06/2014 29 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT  Drivers who did not want to be located and simply turning off the smartphone handset for some/all of the day, or choosing to leave the device at home.  Faulty in-vehicle power supplies which meant some devices were not able to receive constant charge in the vehicle and ran out of power after approximately 10 hours of constant use (which quickly reduced if the drivers were accessing other data or display-hungry applications).  Panic button geo-location: This represents a significant advance over the EAD/blinker light on top of the taxi vehicles, because it enabled drivers who were in trouble to be immediately geo-located by their dispatch operators. As with the vehicle tracking tools described above, this relied upon compliance by both the driver (keeping the device on) and the dispatch operators (watching the taxi display screen).  Sharing of data with city government to assist with traffic monitoring. As noted earlier in this chapter (Section 2a) the fact that taxi operators and drivers were prepared to share the underlying vehicle tracking data to the benefit of CITOM’s traffic management efforts is itself an innovation. If Cebu City Government and participating taxi operators agreed to share the on-going running costs of the TrafficProbe and Cebu Traffic platform, then the implementation costs become cheaper for all parties. For example, were CITOM to cover half the cost of smartphone replacement and on-going data charges plus its own Traffic Alert system costs (USD $45,000 per annum in total), then the cost to taxi operators would reduce to a highly affordable USD $10 per vehicle per month. Training and capacity building delivered 2.64 The training provided for taxi operators and drivers in respect of the TrafficProbe app, and accompanying Taxi Dispatch tools on the Cebu Traffic web-application, was delivered at the same time as that described previously in section 2a of this chapter. 2.65 In addition to briefing drivers and taxi engineers about the TrafficProbe application and the process of mounting the devices into the vehicles and ensuring a reliable power source was provided, the project team provided on-site training for both CITOM’s technical delivery team and the taxi company dispatch teams at their operations compound. The intuitive nature of the dispatch and operations and maintenance software tools meant that no dedicated training materials were provided. Instead, the team provided both English and Cebuano walk-throughs of the dispatch and operations and maintenance tools and answered any questions prompted by the dispatch operators and maintenance teams who would be using the software. Much of this demonstration and training work was led by the CITOM team in order that it could be delivered in Cebuano for native language speakers. 25/06/2014 30 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT d) Establish an information platform to support public participation in transport system and network development Transport system and network development activities in Cebu have traditionally been the preserve of political decision-makers and the Government Agencies, such as CITOM, that are required to provide evidence to support or contest different proposals. Some key issues, such as the development of Flyovers on national roads, can expose differences in the strategic transport planning objectives of Cebu City Government and the Philippine Department of Transport and Communications. Public dialogue on such matters is often driven by local media coverage and campaign groups, such as the Movement for a Livable Cebu who raise awareness of such matters through high profile local campaigns and opinion piece articles in the local press. Despite a growing presence of such groups, public involvement in transport network development is generally low, with relatively limited consultation or consideration of the impact on people’s lives and livelihoods of major local transport and land-use planning initiatives. Software tools developed and target users 2.66 A public traffic visualisation was created through the course of this project and made available at www.cebutraffic.org. The tool was intended to show real-time traffic conditions on the road network in Cebu City based on the data being collected by the TrafficProbe smartphone application installed on the Android devices mounted in participating taxis. The traffic speed data aggregated and processed by the TrafficProbe web-server (as described in sections 2a and 2b) could then be visualised in order to show live average speeds on the local road network. This is effectively a visualisation of the same underlying data as that made available to the CITOM SCATS and COMMEL teams in order to assist their day-to-day management of the Cebu City highway network, and strategic transport planning by CITOM’s transport planning team. 2.67 Figure 2-18 depicts this visualisation for Cebu City based on the average traffic flows in Cebu City in April 2013. Due to the reasons discussed in greater detail in Chapter 4 (covering data validation), a real-time traffic visualisation of traffic speeds was not feasible due to the smaller than required real-time sample of TrafficProbe floating cars available at any one time. Instead of showing ‘Current Conditions’ the visualisation therefore provided users with a view of average traffic conditions at different times of day based on the latest available months’ worth of traffic data collected and aggregated by the TrafficProbe software tools. 2.68 In the final version of the demonstration software platform an alternative view – showing live traffic alerts input by the COMMEL team at CITOM – was made publicly available in order that members of the public would be able to view current incidents that might affect their journeys on the road network. 25/06/2014 31 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT Figure 2-18: Visualisation of average traffic conditions in Cebu City based on April 2013 data collected through the TrafficProbe software platform How the software addresses the challenge 2.69 While the public traffic visualisation did not provide a live-view of traffic conditions, such as those available from Google’s Traffic tool or the Waze live traffic map, it does support public participation in in transport system and network development activities. This type of data has never before been publicly available in Cebu City, and presents interested parties with an opportunity to perform the following analyses:  Review traffic speeds in different areas of the city at different times of day and week.  Appraise transport network proposals mooted by Cebu City Government and the Department of Transport and Communications.  Propose alternative solutions to the decision-makers of Cebu for strategic transport network development and management. 2.70 The traffic speed visualisations previously available on www.cebutraffic.org have already been reported in the local media, and picked up by local campaign groups – highlighting future potential for its use as an engagement tool. The Traffic Alert view that was placed live on www.cebutraffic.org at the end of the project is therefore intended to be a live public information tool that is of value to Cebu City residents and enhances their awareness of traffic conditions on the city’s road network. Innovations 2.71 Aside from the technical innovations mentioned in earlier sections of the report, the most innovative aspect of the public traffic visualisation is that the information is even being shared publicly. The public availability of the information opens the topic of transport planning and road network management up for public debate in Cebu City. Training and capacity building delivered 2.72 A short in-person briefing for Att. Raffy Yap, the Head of CITOM, on what data are being displayed publicly, so that the organisation was able to respond to media enquiries and make members of the public aware of the availability of traffic information via the Cebu Traffic website. 25/06/2014 32 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT 3 THE VALUE OF OPEN SOURCE SOFTWARE DEVELOPMENT 3.1 As a fundamental design principal this project is based on open source software leveraging open data. In practical terms this means that the project can be customized and re- deployed by anyone without need to secure licenses for either the software or data sets used by the software. Further it is a belief of those implementing the demonstration in Cebu that data created by the software should also be open, and shared publicly wherever feasible to the extent permitted by privacy concerns. 3.2 Although similar functionality is implemented by existing proprietary applications in some markets (e.g. Google Maps Traffic, Waze, Inrex), many of these platforms are completely proprietary. Although created using data from public sources (e.g. roadside detectors) or direct contribution from users (via mobile platforms), data created by these platforms are proprietary. In some cases (e.g. Google and Waze) the data is not available for license or re-use in any form, while in others it can be licensed for third-party applications. However in all cases the traffic observation data is linked to proprietary base maps. 3.3 This project was designed to overcoming data limitations inherent in existing proprietary platforms. By building an open, reusable software platform we enable communities not served by our project to replicate and adapt the implementation as desired. Similarly, by leveraging open data sources, namely our OpenStreetMap derived base map, the data collected and created through our and other implementations can be reused by anyone without the need to acquire additional licenses or meet complex terms of service requirements. GNU Library General Public License (LGPL) 3.4 By utilizing the GNU LGPL license for software created as part of this project, we ensure that the core code remains perpetually open while still allowing commercial use. LGPL requires that contributions to the core software library be released as open source code under a similar license. 3.5 Unlike the related, and more restrictive, GPL license LGPL has specific provisions for including libraries built from LGPL code in closed source projects without also requiring the closed source code be made available. This allows for the creation of commercial, closed source implementations that leverage LGPL code while ensuring that modifications to the core remain open. Ease of replication in other locations 3.6 As part of the development process for this project, all related software, code and documentation was publicly released through Github, a online repository and collaboration space for open source projects. 3.7 The project repository is located at: http://github.com/conveyal/traffic-tools. The repository contains three distinct sub-projects:  traffic-engine: the core data processing framework for converting vehicle location data into traffic velocity measurements and relating these to and underlying OSM derived base map. This is the primarily building-block for re-use in other locations. The project offers a great deal of flexibility in how data is collected and fed into the processing pipeline. Data can be transmitted in real-time or batches directly from the point of 25/06/2014 33 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT collection (i.e. a connected mobile device) or it can be uploaded from existing archival sources in CSV format. Traffic-engine then processes the data and generates a statistical summary of roadway velocity observations, relating these observations back to an underlying OpenStreetMap derived base map. The OpenStreetMap data is imported and processed by OpenTripPlanner, and existing stand-alone open source project, bundled with the traffic-engine software.  TrafficProbe: An open source android application for collecting vehicle location data in real-time. The app collects and transmits GPS data in a highly compressed binary format design to reduce power and data consumption. The software was initially developed for deployment as part of the Cebu demonstration project but can be adapted and reused in any context where real-time GPS data collection is needed.  cebu-server: An open source interface developed for the Cebu demonstration project. This includes a number of features specific to the demonstration project in addition to collecting real-time GPS sample data from TrafficProbe devices. Additional features include an interface for managing and tracking devices deployed in taxis, as well as a traffic alert tracking interface for operations staff in Cebu City. These features can be customized redeployed as desired, but are considered independent from the core traffic analysis platform. Opportunity for further customisation and enhancement of software tools 3.8 The software developed as part of this project was designed to be as modular as possible with the intention of incentivizing future development and customization required for re- implementation. 3.9 Specific opportunities for future development include:  A public-facing mobile data collection platform to enable true “crowd sourcing” of traffic information (similar to existing proprietary platforms like Waze). This mobile platform will need to address both privacy and user incentivization concerns not explored as part of the demonstration project. However it can leverage the existing client-side and service code created as part of this project.  A stand-alone traffic alerts platform. The traffic alert interfaces created as part of this project were conceived and developed based on interviews with city traffic management staff during the development of the traffic demonstration platform. These tools, while independent from the traffic data analysis and not part of the demonstration project scope, demonstrated significant value for city staff and could be implemented as a standalone platform. 25/06/2014 34 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT 4 VALIDATION OF COLLECTED DATA 4.1 A range of validation methods were employed throughout the development of the traffic speed inference software tool. These methods enabled testing and verification of results for different aspects of the overall project: data collection methods (using specialized GPS data collection hardware); inference engine (using simulation tools); real-world data (using both intra-day comparison and comparison with independently collected travel surveys). This chapter of the report documents the project team’s findings that emerged from these validation activities. Simulation 4.2 The primarily method for evaluating the performance of inference methods has been through the development of a simulation test framework. Utilizing the same underlying OpenStreetMap network graph that powers the inference software, the simulator generates random test journeys with known paths and velocities. From these test journeys simulated GPS data points are generated, introducing spatial error to reflect real-world conditions. The data points for known journeys are then fed into the inference engine and the results are compared with the original values. 4.3 For data points with a 10 second frequency, and +/- 15m spatial error, the inference engine was able to calculate journey times within +/- 5% of the average expected values. 4.4 In addition to comparing velocity estimates the simulator was also used to validate matching accuracy - detecting match errors, including over- and under-matching of GPS signal to OSM roadway segments. After the inference engine development and testing was completed, on-going challenges with segment-matching were determined to be primarily the result of incorrect or incomplete OSM data. Test data sample from the demonstration project 4.5 Early in the project, prior to the development of the mobile phone application, an effort was made to create a test data set generated from taxis journeys undertaken in Cebu. This data was collected using a small number of GPS data devices with GPRS modems temporarily installed into taxi vehicles operating in Cebu City. 4.6 Due to limitations in the GPS hardware the test data set has a significantly lower than desired temporal resolution, with data points collected every 30 seconds to 1 minute. Despite this limitation the data proved useful in validating key aspects of the data collection and inference software. 4.7 This test data shaped the development of inference methodologies by demonstrating that, even with the less capable GPS hardware, the data was of quality was sufficient to support less complex interference methods than originally planned. As a result a Kalman and particle-filter based classification system was discontinued in favour of a geometric approach, with significantly lower computational intensity. Sanity-check sample data 4.8 Once a sufficient longitudinal sample was collected using the final mobile application, an effort was made to “sanity-check” data using a variety of methods. For this stage of 25/06/2014 35 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT validation a subset of the collected data was used: 17.5 million location points, or 2 million inferred segment velocity observations, from April 2013. 4.9 The data was first evaluated for expected intra-day and intra-week trends. For intra-day velocities we expected to show a bi-modal distribution with slower travel times at both morning and afternoon peak hours. As expected we saw a pronounced morning and afternoon slowing of traffic corresponding with observed travel patterns (see Figure 4-1). Also as expected we observed the highest travel speeds between 2:00am and 5:00am, representing what we believed to be maximal free flow velocities on most road segments. Figure 4-1: Bi-modal distribution showing average journey speeds by hour and day of week (M-F, Sa-Su, and combined) 4.10 In comparing intra-week changes in velocity we saw additional expected patterns, including a less pronounced peak periods on weekends and late evening slowing on weekends, likely related to increased evening traffic volume. Comparison with travel survey data 4.11 In addition to examining expected trends we also compared data against existing travel survey data for equivalent road segments. This comparison required encoding of the journey paths from nearly 75 corridors evaluated as part of a recently conducted BRT feasibility study. These journeys provided an important framework for comparing inferred data both against known journey time surveys, as well as comparing the inferred data against itself. 4.12 Intra-dataset comparisons of Cebu Traffic data against known travel survey data provided the most significant validation of data collection and inference methods. For this evaluation we divided the day into three survey periods: morning, inter and afternoon peaks. Velocities were then compared on a per segment basis across these periods (e.g. velocity for segment X was compared between morning and mid-day travel periods). 4.13 A strong correlation between travel speeds across times of day reflects a coherent dataset, likely measuring real-world travel speeds, whereas a weak correlation may reflect increased error in the observed data and/or an underlying problem in the inference methodology. 25/06/2014 36 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT 4.14 The Cebu Traffic derived samples showed an exceptionally high correlation across all time periods (see Table 4-1 and Figure 4-2) while the same roadway segment observations from the existing travel time data sets showed questionable correlations (some with R values less than 0.5). The data quality issues present in the existing travel time data are likely the result of substantially smaller sample size, but may also reflect the difference between manually and automated data collection techniques. Table 4-1: Correlation summaries for intra-data set comparisons of inferred Cebu Traffic data and existing travel survey data Figure 4-2: Comparing within data sets, inter-peak to pm peak. Intra Cebu Traffic comparisons show a R value of 0.94, compared with existing data with 0.38 4.15 Further, we attempted to compare Cebu Traffic data against existing data sets. After removing three outlining points (the result of OSM data quality problems), despite the sample size quality challenges in the existing travel survey data, we observed correlations approaching 0.70 between data sets (see Figure 4-3). 25/06/2014 37 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT Figure 4-3: Inter-data set comparison by observation period. 4.16 This indicates that Cebu Traffic data expresses both internal coherence and a strong correlation with independently observed roadway characteristics. 4.17 It should be noted that the Cebu Traffic observations showed a substantially higher (circa. 50% higher) mean velocity than existing journey time survey data. This is reflected in the comparison in Figure 4-3. It is likely that systemic bias undermines the value of Cebu Traffic data in determining absolute roadway velocities. In our opinion this is likely attributable to different driver behaviour, with taxi drivers demonstrating significantly higher average speeds when compared with non-taxi drivers. Despite this difference we believe that Cebu Traffic-derived comparison of velocity in relative terms holds value. Findings and next steps 4.18 In combination, these validation efforts indicate that the Cebu Traffic data collection and inference methods generate robust observational data sets; perhaps surpassing the quality of data derived from traditional survey methods due at least in part to the ability to collect substantially larger sample sizes. 4.19 We believe that there is still room for improvement of the inference methods and validation. Particularly through the collection of data sets from a larger pool of drivers and vehicle fleets. By comparing taxi and non-taxi driver behaviours it is likely that we could address any systemic bias embedded in a taxi-only data set. Requirements to achieve a live traffic dataset 4.20 As part of the validation task we determined that real-time data collection is not feasible given the currently available Cebu City datasets sample size. This determination was made by reviewing average velocity observation frequencies on a per-road segment basis during the validation period (data collected in April 2013). 25/06/2014 38 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT 4.21 During the validation period we observed an average of 75 vehicles participating per day. With this sample size during the hours of 8am-8pm only 1,100 road segments saw, on average, more than one velocity observation per hour (see Figure 4-4). Figure 4-4: Map of street segments with observation rate greater than one per hour between the hours of 8am-8pm based on 75 vehicle per-day sample 4.22 We assume that a segment observation rate of at least 10/hour is required to show a live traffic view. Extrapolating from the validation sample this would necessitate at least 750 vehicles participating per day, assuming they mirror the driver behaviour of the validation sample, in order to provide a live feed only for the segments illustrated in Figure 4-4. 4.23 Based on these findings we believe that current collection methods do not support real- time observation of traffic conditions. However, by aggregating data over time or geography, even a small number of vehicles can provide meaningful aggregate views of traffic conditions for further analyses. 25/06/2014 39 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT 5 PROOF OF CONCEPT EVALUATION 5.1 This Chapter of the final report provides a detailed evaluation of the proof of concept software tools and data collection processes that were demonstrated in Cebu City through the project team’s delivery of this project. Evaluation activities 5.2 In order to evaluate the effectiveness, value and impact of the four software components which made up the demonstration project platform (TrafficProbe data collection tools, Cebu Traffic Alerts data entry and visualisation platform, Taxi Dispatch tools, and Cebu Traffic data visualisation software) the following activities were undertaken by the project team:  Before and After surveys, and Focus Group Discussions, with a sample of taxi drivers in Cebu who participated in the demonstration project. In the After survey a control group of taxi drivers that did not participate in the demonstration project were asked the same questions as a sample of drivers that were involved in order to control for societal changes (e.g. associated with broader smartphone penetration over time). All taxi drivers that participated in the Focus Group Discussions were remunerated PhP 300 for their time, in order to compensate them for lost taxi earnings during the two hours they were involved in the discussion.  Before and after interviews with all 7 participating taxi company owners and/or managerial staff in order to understand their needs (before interview) and perceptions of value/effectiveness (After interview) in respect of the Cebu Traffic Taxi Dispatch tools.  Before and after interviews with CITOM team members in different departments, and ethnographic observations of each team using the software tools designed to meet their needs. The teams covered included:  The COMMEL radio network team.  The SCATS traffic signal control team.  The CITOM transport planning and data collection team.  Attorney Rafael Yap, the Head of CITOM.  Analysis of all data collected by the project team during the course of the study.  Ethnographic observations of taxi dispatch and CITOM staff when using the software tools in order to observe the functions and tools which were/were not useful to them, and to see how the tools were used. 5.3 The project team’s thanks go to Lynn Madrona and her colleagues at the University San Jose Recolitas, who undertook all taxi driver surveys and organised interviews and Focus Group Discussions with all respondents. We are also grateful to Sheilah Gaabucayan- Napalang, (Assistant Professor from the School of Urban and Regional Planning/ 25/06/2014 40 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT Research at the University of the Philippines’ National Center for Transportation Studies - NCTS), for acting in her role as independent critical friend and leading all of the Focus Group Discussions and in-depth interviews with the software users. While Sheilah was part of the project team, and gained a sound understanding of the software tools we created, she was not directly involved in their development. Sheilah was therefore able to act impartially, and with no vested interest, when asking questions about the tools’ effectiveness and reporting her findings. Software platform implementation costs 5.4 As noted in previous chapters of this report, the software tools implemented in Cebu City through this demonstration project represent low-cost ways that city governments can collect/input traffic and road network data on a continuous basis, and in a format which is immediately available for analysis through the software tools provided. The cost of replicating the whole platform of software tools developed and deployed in Cebu City through this demonstration project has been summarised in Table 5-1. The integrated nature of the tools is a significant advantage, and one which helped to keep total implementation costs down. For instance, the public traffic visualisation tool is a corollary output of deploying the TrafficProbe data collection tools, the cost of which is incorporated within the TrafficProbe tools. Table 5-1: Whole software platform implementation costs per annum (in USD $) 13 Software component ICT hardware Data / hosting Support Staff Total TrafficProbe data 5,334 20,400 12,000 37,734 collection tools Traffic Alerts Data Entry 366 1,380 6,000 7,747 and Visualisation tools Taxi dispatch and Automatic Vehicle 5,334 20,400 12,000 37,734 Location tools Public traffic - - - - visualisation tool 14 Total cost 11,034 42,180 30,000 83,215 Traffic Probe data collection tools 5.5 TrafficProbe can be deployed in 320 vehicles in Cebu City over a 3 year smartphone handset and ICT hardware replacement cycle for a total cost of around USD $20 per vehicle per month, or USD $75,000 per annum. It is roughly six times cheaper than equivalent manual GPS journey time survey data collection techniques when deployed as a one-off traffic survey tool, with 1 month of data collection achievable for as little as USD $2,000 by placing a smartphone device into a vehicle. An equivalent manual traffic survey costs would be closer to USD $12,000 due to the human effort required to post-process the collected GPS point data. These implementation costs would reduce sharply - to USD 13 Hardware costs assume a sample of 320 smartphone handsets is deployed, and ICT infrastructure costs are amortised and shared 50:50 between the city authority and taxi operators participating in the implementation of the software platform. 14 The public traffic visualisation costs are covered by the delivery of other aspects of the software platform and cannot be disaggregated from the delivery of the other components. 25/06/2014 41 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT $64,800 per annum if the smartphone handset costs are removed, and USD $26,400 if both smartphone handset costs and data costs are stripped out – e.g. if the cost of ICT hardware and data transmission costs were off-shored from a city authority. Traffic Alerts Data Entry and Visualisation tools 5.6 The Traffic Alert data entry tools and map-based visualisation software can be deployed in Cebu City for USD $7,750 per annum, when ICT hardware costs are amortised over 3 years. These open up new forms of analysis that were not previously possible due to the paper-based methods for recording traffic incidents, collisions and other significant events that affect the city’s road network. Taxi dispatch and Automatic Vehicle Location (AVL) tools 5.7 The cost of implementing the taxi dispatch and AVL tools is deeply entwined with the cost of deploying the TrafficProbe data collection tools. As a result the cost breakdown in Table 5-1 assumes that the city authority and participating taxi operators would share ‘50:50’ the costs of implementing TrafficProbe for mutual and civic benefit. On this cost-sharing basis, taxi operators would bear USD $10 per-vehicle-per-month for every taxi in which a smartphone device running the TrafficProbe was operating. This is over 60% cheaper than locally available GPS-based vehicle tracking solutions that taxi operators in Cebu City have previously tested which offer similar functionality. What has worked? Identified benefits of implementing taxi crowd sourcing 5.8 A range of positive benefits and outcomes have been identified through our team’s evaluation of the software tools being implemented in Cebu City. 5.9 Rich and continuous data-sets to inform transport network analysis, planning and way-finding by taxi drivers:  TrafficProbe: 17 million data points and 2 million roadway segments per month were collected by the TrafficProbe application. This continuously collected dataset did not exist previously and was widely acknowledged to be a rich data source that is valuable for CITOM in its efforts to tackle traffic congestion in Cebu City. CITOM’s Transport Planning team identified the automated average speed and journey time data collection as the main benefit of these data, since they spare CITOM from needing to allocate budget (as documented in the previous cost analysis section) and staff resources for manual journey time surveys – freeing them up for more extensive analyses and other priorities.  Traffic Alerts for CITOM: The most useful component of the platform for the COMMEL team is map-based data entry in real-time and shared visualisation across multiple users, which facilitates live monitoring of incidents and activities taking place on the road network in Cebu City. As a result the COMMEL team working in the radio control room knows where the problems exist and can provide this information to local TV/Radio stations when they request traffic updates. The live monitoring and mapping of field personnel locations is also very beneficial to the COMMEL team and (as noted later in this chapter) has been the clear focus of their data entry effort through the course of the demonstration project. 25/06/2014 42 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT  Traffic Alerts for taxi drivers: Taxi drivers reported that they found icons indicating locations of traffic accidents and on-going road construction (as input by the COMMEL team) very helpful when making their way around the city, because they displayed on the smartphone app mounted on their dashboard. Figure 5-1 supports this qualitative finding, and shows that 41% of the respondents to the post-implementation survey who had used the TrafficProbe smartphone application stated that they relied on it for information about the location of congested roads in Cebu City. Although an encouraging finding, this is a substantially lower proportion of drivers than those who stated that they use radio alerts to identify congested streets (83% - 90%). Figure 5-1: Taxi driver techniques for identifying congested roads in Cebu City 100% 94% 95% 94% 93% 90% 90% 82% 83% 80% 74% Percentage of responses (%) 70% 60% 50% 45% 41% 40% 30% 20% 11% 12% 14% 10% 7% 0.5% 0.5% 0% Varies by time of Same roads always Warned by other Radio alerts Don't know / Rely on info from day / weather congested drivers Other smartphone app Before survey - Oct 2011 (509 respondents) After survey (GPS) - Jul 2013 (202 respondents) After survey (No GPS) - Jul 2013 (201 respondents) 5.10 GPS-based Automatic Vehicle Location (AVL) tools for taxi operators and drivers: Taxi operators, drivers, and (indirectly) customers all reported significant benefits of the AVL functionality of the software tools:  Operators like being able to monitor fleet location in real-time and cited taxi break- downs, emergency situations and returning lost-property to passengers as being particular examples of its value. Of the 40 drivers interviewed at the end of the demonstration project, 3 had been questioned about their locations by their taxi company – demonstrating that some degree of monitoring of the Taxi Dispatch map was happening at participating taxi companies control rooms/offices. The operators also noted that they used the vehicle tracking to observe whether drivers might be involved in illegal practices. For instance, if a driver is seen to be frequenting ‘Duljo Fatima’, a place known to be a local ‘hang-out’ for drug users, then this alerts the company owners and management staff members that the driver may need to be monitored closely. Substance abuse is a particular issue among taxi drivers in Cebu City. 25/06/2014 43 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT “There was one instance when a driver asked permission to take a passenger outside the City limits. I was able to confirm his route and approximate the kind of road he was travelling on. The latter is important for maintenance purposes” Operator, CATZ Taxi Company  All of the taxi drivers we interviewed and surveyed reported feeling safer as a result of knowing that CITOM, or their taxi dispatch office, could readily identify their location in the event of a breakdown, or that they are threatened by a passenger or snatcher. Figure 5-1 shows this was reflected in responses to the before and after surveys of taxi drivers. Although overall perceptions of safety among taxi drivers had worsened since the pre-implementation survey in October 2011 - the percentage of respondents stating they felt very safe/safe fell from 89% to between 66% and 52% - a greater proportion of the drivers who had participated in the demonstration project and received a smartphone to run the TrafficProbe app in their vehicle (66%) stated that they felt very safe/safe when driving their taxi when compared to drivers who did not participate in the demonstration project (52%). A greater proportion of the drivers who had not participating in the project (40%) also stated that they had ever had to call the police in relation to their safety while driving their taxi in Cebu City, when compared to drivers surveyed pre-implementation (31%) and those who had participated in the demonstration project (30%) – see Figure 5-3, below and overleaf. Figure 5-2: Cebu City taxi drivers’ perceptions of safety when driving their taxi 60% 50% 50% 49% 47% Percentage of responses (%) 39% 40% 36% 33% 30% 20% 16% 16% 10% 7% 3% 2% 0.5% 0% Very safe Safe Neither/nor Not very safe Not safe at all Before Survey - Oct 11 (508 responses) After Survey (GPS) - Jul 13 (215 responses) After Survey (No GPS) - Jul 13 (207 responses) 25/06/2014 44 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT Figure 5-3: Drivers that have ever had to call the police in relation to their safety while driving their taxi in Cebu City Before Survey After Survey - Participating drivers (503 responses) (203 responses) 31% 30% Yes Yes 69% No 70% No After Survey - Control group of drivers (201 responses) 40% Yes 60% No  The drivers also liked being able to show traffic incident reports to passengers in order to justify why they are taking particular routes at busy times, and felt that having a smartphone in the taxi made them appear more credible and trustworthy. “Passengers feel that we are cheating them if we choose another route. So we have to use the usual route, even when we know it will be congested.” Male taxi driver, KEN Taxi.  Both operators and drivers noted that customers had commented on the presence of a smartphone mounted on the dashboard of their taxis. Drivers reported using ancillary tools such as Google maps to plan routes to unfamiliar destinations, or to search for local landmarks and restaurants on behalf of customers. Operators noted that knowing the locations of vehicles in real-time made it easier to re-unite passengers with lost property left in the back of vehicles, which is an at-least daily occurrence for most firms. “In our experience, recovery of items left behind by the passengers is facilitated, with the Smartphones in our taxis” Manager, KEN Taxi Company 5.11 Fostering collaboration between CITOM, taxi companies and taxi drivers: All 46 of the 47 taxi operators and drivers that we interviewed who had participated in the demonstration project all expressed a willingness to share data with CITOM through this demonstration project. Only one operator was not happy with participating in the future if the TrafficProbe/Cebu Traffic platform is sustained, but the reason cited for this was not data- sharing but the concern over being responsible to CITOM for the smartphone handsets. 25/06/2014 45 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT The belief expressed by taxi operators and drivers was that they had a role to play in helping CITOM improve the traffic situation in Cebu City. 5.12 Enhancing existing radio-based taxi dispatch systems: Both taxi operators and drivers interviewed at the end of the demonstration project concluded that the combination of GPS-enabled vehicle tracking, and two-way messaging between taxi office and vehicles facilitated through the software tools, makes the system deployed in Cebu City a valuable partner for existing radio-based dispatch systems.  Operators liked the system, because the live vehicle map enabled them to first identify which taxis were closest to a passenger before contacting them by radio to direct them to a location. As well as suggesting this was an incentive for drivers to keep their devices on, charged and mounted on the dashboard; the operators liked being able to send their drivers a specific address/landmark so that they definitely knew where they were heading.  Drivers liked the system, because it meant they were not as heavily incentivised to be dishonest about their location/hire status when jobs were broadcast across the whole radio network, thereby increasing their chances of picking up fares through dispatch. The only reported drawback to the system was that the small screens on the smartphones made it hard for drivers to type a response – particularly while driving or waiting in traffic.  Despite these very positive endorsements from both drivers and taxi operators, it appears from the survey data that they are referring to the system’s potential, rather than actual usage. Figure 5-5 shows that none of the 202 drivers surveyed who participated in the TrafficProbe demonstration had received dispatch instructions via the TrafficProbe application. It also reveals how little radio dispatch itself is used in Cebu City as a method for directing drivers to passengers, and may indicate the limited need for dispatch requirements given how many taxis there are competing for business. Figure 5-4: Taxi driver strategies for finding fares in Cebu City 100% 99%99% 100% 96% 90% 90% 90% 85% 80% 80% 72% 70% Percentage of respondents 60% 50% 40% 30% 19% 20% 10% 1% 3% 0% 0% 0% 0% 0% 0% 0% Wait at taxi rank Wait near key Drive around Radio dispatch Wait at seaport, Dispatch via landmarks looking for fares airport or terminal smartphone app Before survey - Oct 2011 (509 respondents) After survey (GPS) - Jul 2013 (202 respondents) After survey (No GPS) - Jul 2013 (201 respondents) 25/06/2014 46 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT 5.13 Knowledge and capacity building: All 7 participating taxi operators cited the opportunity to experience and evaluate the benefits of using smartphones in their vehicles as their reason for participating in the demonstration project, and 6 of these indicated a desire to remain involved beyond the demonstration period. 5.14 Enhanced awareness and perceptions of traffic congestion among participating taxi drivers: Figure 5-3 shows that the perceptions of taxi drivers working in Cebu City had changed markedly since the pre-implementation surveys were conducted in October 2011. This could be explained by the different times of year that the before and after surveys were completed. Analysis of the post-implementation survey results show that slightly smaller proportions of taxi drivers who had participated in the demonstration project and used the TrafficProbe smartphone application reported being stressed by congestion, that their journeys were slowed down by congestion, and that their fuel costs were increased; when compared to non-participating taxi drivers from the control group. Figure 5-5: Taxi drivers’ pre- and post-implementation perceptions of congestion 100% 96% 93% 91% 90% 89% 85% 87% 85% 84% 83% 80% 81% 80% 75% 70% Percentage of responses (%) 60% 51% 50% 40% 30% 22% 20% 13% 10% 0% Causes stress Slows down my Increases fuel costs Prevents me from It doesn’t affect me journeys picking up more greatly passengers Before Survey - Oct 11 (509 respondents) After Survey (GPS) - Jul 13 (202 respondents) After Survey (No GPS) - Jul 13 (201 respondents) 5.15 Across all three pre- and post-implementation surveys between 93% and 95% of drivers stated that they try to avoid roads that they know to be busy or congested when in their taxi. 25/06/2014 47 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT What hasn’t worked as well? Sub-optimal outcomes of the demonstration project 5.16 A number of less positive outcomes have also been identified through our team’s evaluation of the demonstration project. 5.17 Real-time Traffic Alert data entry: For CITOM’s COMMEL team, the task of entering data into the Traffic Alerts system was seen as an additional and low-priority task, when compared to organising the Traffic Enforcer response to live issues on the traffic network. This was not aided by weak radio network signals, and interference, which can make it challenging for the COMMEL team to interpret radio messages and, in real-time, type them into the Traffic Alert tools meaningfully. This finding was reflected in the make-up of data entered by the team over the course of the demonstration period (see Figure 5-6), and the fact that a number of traffic incidents were not entered in real-time, but to inform retrospective collision analysis. Taxi drivers that participated in the demonstration project also noticed that the quality and reliability of the public TrafficAlert information displayed through seemed to be variable – with some icons remaining on-screen after incidents have cleared, and other incidents going un-noticed by COMMEL. One member of personnel has subsequently been assigned specifically to input traffic alerts in real-time, but only on weekdays (when the need is greatest). At weekends the task is shared by the two personnel who man the COMMEL control room. Figure 5-6: Breakdown of TrafficAlert data points entered by COMMEL team (Percentage of 16,702 data entries from Jan – Aug 2013) 0.2% 0.4% 0.3% 15% Traffic incidents 0.1% Traffic congestion events 0.6% 0.2% Major events 0.3% Fires Flooding Road closures Traffic signal problems Roadworks 83% Traffic Enforcer locations 5.18 Taxi industry take-up and responsibility for smartphone handsets: Of around 20 substantial taxi operations based in and around Cebu City, only 7 have thus far agreed to participate. As such, 180 smartphones were waiting to be deployed by CITOM at the time of preparing this final project report. The CITOM team responsible for local delivery of the project reported that it was increasingly hard to find taxi operators in Cebu City who are willing to accept responsibility for the smartphone devices that would be installed into their vehicles. This is also a concern for the taxi drivers at participating companies, for whom a USD $100 smartphone represents between 4 and 10 days’ income for a taxi driver in Cebu 25/06/2014 48 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT City (depending on the time of year). More than half of the 40 taxi drivers that participated in Focus Group Discussions believe that carrying a smartphone in their vehicle makes them more of target for crime. As a result, many drivers and operators have developed strategies to ensure the financial and personal risks of agreeing to participate in the initiative are mitigated. These include:  Drivers not turning on their phones to prevent theft – often under instruction from their firm’s managers or company bosses.  Turning on the smartphones, but placing them in a safe area within the taxi (such as a door pocket or the glove-box) without paying any further heed to the screen. From a data collection perspective this is fine if the phone is on-charge and can obtain GPS/data connections, but renders all on-screen dispatch and traffic alerts useless – reducing the value of the software tools. This approach is particularly adopted at night time, along with reducing screen brightness, or covering the screen with a piece of cloth  Removing the phones when they take meals and breaks. 5.19 Although the participating drivers were carefully selected by the taxi operators (for their reliability and trustworthiness), three of the seven operators reported loss of Smartphones, either because their drivers have been robbed or the driver himself stole the Smartphone. “One of my drivers sold the Smartphone issued to him to support his drug habit” Operator, RICHIELDA Taxi 5.20 Wireless 3G data collection reliability: The reliability of the 3G data network in Cebu City, which is paramount for the constant transmission of data from the Smartphones as well as the functioning of the TrafficProbe app, was a constant source of problems throughout the demonstration project. The following connectivity issues we experienced have both limited the size and quality of the traffic data sample collected (meaning that a live traffic visualisation of Cebu was not possible), and inhibited the reliability of vehicle tracking and operations and maintenance data for participating taxi operators:  Poorly provisioned smartphones meaning that all procured handsets were disconnected en-masse from the network by the local service provider on at least 5 occasions. The ensuing need to repeatedly re-start the devices and reconfigure network settings created considerable additional work for CITOM’s Cebu Traffic delivery team, who had to visit all participating taxi operator’s compounds and assist the drivers and admin teams with returning the ‘phones to a functioning state. Time spent addressing these issues meant that CITOM staff members invested at least 4-5 times the estimated 10 days allocated to supporting system testing prior to the proof of concept demonstration.  Highly variable 3G signal strength and network performance, with very frequent drop- outs and transmission failures. All drivers and operators noted that data connection was frequently cut-off, and registering devices onto the network was sometimes challenging. The project team observed a greater than 7% data transmit failure rate while running the TrafficProbe app was experienced early on in the demonstration project, which compared to less than 0.5% running the app on identical devices in the US and UK (see Figure 5-1). The project team and CITOM’s Cebu Traffic deliver team had to invest substantial time and effort (adding 5 months of troubleshooting effort to 25/06/2014 49 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT the project timeline) to work with the local service provider and CITOM to conclusively show that the source of the issue was network-related. Although network reliability improved once the local service provider had provided newer handsets with correctly provisioned baseband firmware, the transmission failure rate remained high and continues to be affected by factors such as heavy rainfall on a regular basis. Figure 5-7: Most common locations of data transmission failures experienced in Cebu City  Smartphones struggling to transition between GPRS and 3G connections remains a prevailing issue which the project team believes is a result of the combination of how the data network is being provided in Cebu City by the local service provider and the quality of Android handsets, which were deliberately procured for their cost- effectiveness (to mitigate theft and demonstrate the potential for low-cost traffic data collection). 5.21 Taxi driver compliance: As noted previously in this report, the success of the demonstration project was wholly reliant upon the compliance of participating taxi drivers, who were responsible for ensuring that the smartphone in their vehicle remained on-charge and connected to the network when they were driving around Cebu City. The following driver compliance issues were observed by the project team and all of the partners involved in the evaluation interviews and surveys:  Limited driver knowledge of smartphones: Many taxi driver’s inherent lack of familiarity of using smartphones and apps meant that whenever the data connection went down, preventing map tiles from displaying on the app, and drivers tried to ‘fix’ the phone themselves they would often alter important connectivity settings in the process. Each week 10-20 phones, on average, were being returned to CITOM for re-configuration before they could be returned to the drivers and contribute to the TrafficProbe data-set. The taxi operators were also concerned that not all drivers fully understood the 25/06/2014 50 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT functionality of the TrafficProbe app, and therefore were not extracting full value from the tools available to them. “Many of our drivers do not know how to use the GPS for navigation” Operator, RICHIELDA Taxi  Lack of comprehension of the icons used in CITOM Traffic Alerts: Not all of the drivers understood fully what each of the different icons that were displayed on the TrafficProbe application after a public alert was published by CITOM’s COMMEL team actually meant.  Over-use of data connections for other applications: A number of drivers quickly realised that the smartphone in their vehicle provided them with access to the internet, videos, games and applications. The result was that on around 20% of the available handsets all of the available data provisioned to the SIM card was quickly used up for the month, resulting in both a loss of real-time vehicle tracking to the operators and a loss of traffic data being submitted to the TrafficProbe web-server.  Full storage/low memory on the devices: A corollary of the point above was that the device storage and internal memory quickly became full of data and system resource hungry applications which prevented some of the Android smartphones from performing optimally and transmitting location data reliably. The Cebu Traffic team at CITOM had to spend considerable time and effort uninstalling apps and files from such devices in order to get them to work again.  Deliberately turning off the ‘phones: Operators also noted that drivers deliberately turning off the phones at particular times of day, or in certain locations, in order to avoid their location being tracked was an issue. Other drivers had turned the ‘phones off due to the unreliable data connection issues, and never turned them back on again. 5.22 Insufficient traffic data sample for live congestion visualisation and analysis: The combination of low levels of driver compliance and wireless data network connectivity issues (with the poor network connectivity contributing to lower driver compliance levels) resulted in a much smaller sample of vehicles being out on the street simultaneously to that which the project team had anticipated. Figure 5-8 shows that pre-implementation interviews with taxi operators suggested that we should anticipate for 20% of the fleet to be off the road each day for routine maintenance, repair or driver change-over. As such we assumed that a sample of 500 vehicles would yield a daily floating car sample of around 400 vehicles. Instead the project team and CITOM’s Cebu Traffic implementation team was able to deploy 320 smartphone devices, of which around 25% (75 vehicles) appeared on the network each day. 25/06/2014 51 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT Figure 5-8: Comparison between anticipated and achieved floating data point sample Achieved sample from 80 240 320 devices Anticipated sample 400 100 from 500 devices 0 200 400 600 Floating vehicle data points No. vehicles off-the-road each day 5.23 This may, in part, have been due to the fact that the demonstration period took place during a time when demand for taxi services in Cebu City is at its lowest compared with the period from October – February. As identified in Chapter 4 of this report (Validation of Collected Data), this combined with the lower than expected level of driver compliance and network connectivity in Cebu City means that providing a ‘live’ rolling of traffic data requires revised estimate for the number of participating taxi vehicles in Cebu City. 5.24 By extrapolating from current sample, at least 750 daily active taxis would need to be equipped with an Android smartphone in order to achieve a 15 minute windowed average only for the primarily road (see segments shown in Figure 4-4). Using current data collection methods we believe that a ‘live’ traffic dataset is only feasible for the primarily road network (see figure 4-4). Achieving a similar sample rate for secondary and tertiary roads within the city core requires as many as 2,500 active vehicles, assuming driver behaviour remained consistent with the sample dataset achieved through the demonstration project in Cebu City. 5.25 Lack of local capacity to analyse collected traffic / vehicle location / taxi operations and maintenance data: All of the respondents interviewed at CITOM (COMMEL, Transport Planning team, SCATS team) and the participating taxi operators noted that they were yet to find internal resources with the capacity to analyse and interpret the rich seam of data that was being gathered through the TrafficProbe and Traffic Alert software tools. In part this relates to the fact that the continuous data-set being provided from the tools was overwhelming in scale when compared with existing sources of traffic condition/alert data. “The information on total kilometres travelled daily can help track fuel consumption and thus can be a useful reference, although we have not used it yet” Manager, KEN Taxi 5.26 It also reflects the fact that the distribution of handsets to taxi operators only achieved a scale at which the traffic data sample became rich enough for analysis in April 2013, and was subsequently affected by network connectivity issues. At the time the post- implementation interviews were conducted, both CITOM’s COMMEL and Transport Planning teams, and the participating taxi companies were seeking resources that would enable them to scale up their analysis efforts. The Head of CITOM indicated his belief that 25/06/2014 52 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT there are several possibilities for the Cebu Traffic data to be used for the improvement of CITOM operations, including using the data and map on accidents for road safety black- spot analysis and the creation of semi-live traffic maps using the available traffic speed data being collected. He also envisaged that the final demonstration project versions of the traffic congestion map and Journey Time Analysis tools, would enable CITOM to validate the SCATS data collected from its functioning induction loop traffic counters. “We are still learning how to retrieve data from the Journey Time Analysis tool in our preferred format. More training on how to convert information on the map into a tabular format would be helpful.” Female member of CITOM’s Transport Planning team 5.27 Incompatibility of traffic data for SCATS optimisation: Currently, the collected traffic data does not directly supplement the information required by CITOM’s SCATS (area traffic signal control control) team, because the SCATS system requires data on traffic volume and TrafficProbe generates data on average traffic speed and journey time. Although these two data sets are related, CITOM’s SCATS team considers them to be separate monitoring activities. 5.28 Representativeness of absolute taxi traffic speed data: An issue observed by the project team (see Chapter 4), and highlighted by CITOM’s Transport Planning team is that the taxi crowd-sourced data displays considerably higher (~50%) average traffic speeds when compared with control data-sets provided by CITOM, and those collected by ITP on behalf of the World Bank in order to appraise the feasibility of a proposed BRT line in Cebu City. The degree of variability between these datasets alters at different times of day:  During the AM Peak (7am – 10am) and Inter-peak (10am – 4pm) periods the data collected manually in average traffic conditions (driving to keep up with the flow of traffic) provided absolute speeds that were was, on average, 37% slower than that data collected automatically from taxis using TrafficProbe.  During the PM Peak this disparity increased to show average traffic speeds as being 55% slower than taxi crowd sourced data, which is a considerable difference.  Overnight (midnight – 4am) the difference from taxi crowd-sourced data to manually collected data reduced to -9.75%. The main reason identified for this appears to be that taxis in Cebu City are prone to being driven more quickly around the city than other vehicles – particularly during peak periods. Based on our pre- and post-implementation surveys with taxi drivers, and ethnographic observation whilst in Cebu, this is most likely the result of competition for fares in the city coupled with taxi drivers’ greater knowledge (derived through daily experience) of congested areas and how to avoid them. Indeed, collecting data solely from taxis biases the sample in a way that discounts the different driving behaviours and traffic patterns of local public transit options (Jeepneys / regional buses), private motorists and freight vehicles as they move around Cebu City. 5.29 No discernible impact on taxi driver incomes: Both the in-depth interviews with taxi drivers, and the pre- and post-implementation surveys, confirmed that the participating taxi drivers in the TrafficProbe demonstration project did not report any improvement on their income as a result of having the Android device running the TrafficProbe app mounted on 25/06/2014 53 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT their vehicle’s dashboard. Figure 5-2 demonstrates both that this finding stands when the incomes of taxi drivers that did not have GPS enabled smartphones installed in their vehicles are controlled for, and the tremendous cyclical variation in taxi driver earnings – as noted earlier in this report. Average earnings in July 2013 are less than half those reported in the pre-implementation survey undertaken in October 2013 (at which point the build-up to Christmas was underway). Figure 5-9: Cebu City taxi drivers’ self-reported incomes before/after the project 100% 89% 88% 90% 80% Percentage of responses 70% 60% 50% 43% 40% 30% 30% 27% 20% 11% 12% 10% 1% 0% <1000 pesos 1000 - 2000 pesos 2001-3000 pesos >3000 pesos Before Survey - Oct 11 (505 responses) After Survey (GPS) - Jul 13 (202 responses) After Survey (No GPS) - Jul 13 (199 responses) 5.30 Low uptake and response to the panic button tool: Both taxi operators and drivers identified issues with the panic button tool and response mechanisms built into the Traffic Probe smartphone app and Taxi Dispatch and Monitoring tools:  Although taxi operators agreed that the inclusion of the panic button will help keep their drivers safe, especially at night, they also recognised it is only useful if someone monitors their locations 24/7 and they do not have staff resources to do this currently.  The taxi drivers demonstrated low awareness of the Panic Button’s existence when asked about it during Focus Group Discussions, and those who did know about it stated that they were aware that the taxi dispatch screen was not being routinely monitored by their operator or CITOM. As such they did not anticipate a response to pushing the button – some had deliberately tested it and received no offers of support or calls enquiring about their well-being.  When operating at night (when most taxi drivers are attacked or threatened in Cebu City) the taxi drivers tend to stow the device in the glove-box to avoid attracting the attention of would-be thieves or attackers. Drivers also noted that they would not use the smartphone to call for assistance (e.g. from the Police) if they were being held-up (even if they could), because it was perceived to only draw attention to the device and increase the anger of their assailant. These prudent approaches to maintaining personal safety in what can be a challenging working environment appear to undermine the well-intended value of the panic button. “At night, I remove the Smartphone from its mounting because it might tempt unsavoury passengers” Driver, JTY Taxi 25/06/2014 54 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT Key learning points to-date 5.31 A number of key findings have emerged through this evaluation of the TrafficProbe and Cebu Traffic taxi crowd sourcing demonstration projects. This final section of the chapter reflects on the most salient points reported in this chapter to pick out the highest and lowest value components of the software tools. In doing so it feeds directly into the remaining chapters, and their exploration of how the platform can best be sustained and scaled-up in Cebu City / replicated in other locations, as well as opportunities and ideas for developing the software platform for use in other locations. High value components of the demonstration project 5.32 The Traffic Alerts data entry and visualisation tools represent both the cheapest, and one of the highest impact, components of the whole software platform tested in this project:  At a low implementation cost of USD $7,750 per annum 15, the tools provided Cebu City Government with the means to digitally record all of the incidents and traffic congestion events that happen on the road network.  By complementing existing workflows used in CITOM’s COMMEL team the tools represented both a substantial productivity improvement over existing (paper-based) incident reporting methods, and also facilitate easier management of traffic enforcement resources and an improved response to incidents occurring on the city’s highway network.  The information feeds generated by this tool were highly valued by taxi drivers, who could see them via the TrafficProbe app, and are now available for download and analysis by CITOM’s transport planning team – presenting opportunities for improved network planning and management. There is considerable scope for these to be made publicly available (e.g. via a web-based visualisation) in order to maximise the value to residents in Cebu City. 5.33 The TrafficProbe smartphone application and web-server software tools have demonstrated the potential for such approaches to be successful in challenging operational environments such as Cebu City:  At a total annual cost of USD $75,000 16, these tools provide a continuous feed of traffic data that can be used for both real-time Automatic Vehicle Location, and time-series analyses of traffic speed and journey time analyses across around 2 million roadway segments each month based on the sample achieved in Cebu City. If the driver compliance and vehicle fleet operating environment issues experienced through the demonstration project in Cebu City are addressed, then there is scope for these tools to yield a richer sample of data that could also power real-time traffic data feeds. Achieving this would require a significantly larger sample of floating vehicles than was deployed in Cebu City - of the order of 750 participating vehicles connected to the server each day (See paragraph 4.20 and 5.23). 15 Assumes ICT hardware costs are amortised over a three year implementation period. 16 Assumes ICT hardware costs are amortised over a three year implementation period. 25/06/2014 55 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT  These implementation costs would reduce - to USD $64,800 per annum if the smartphone handset costs are removed, and USD $26,400 per annum if both smartphone handset costs and data costs are stripped out – e.g. if the cost of ICT hardware and data transmission costs were not a city authority’s responsibility. This could potentially be achieved through vehicle fleet operators meeting these costs, or by publicly crowd-sourcing the data collection effort (as both Google’s Traffic and Waze applications have done successfully).  Even if a city authority were to bear the TrafficProbe hardware and data costs itself, this approach is still around six times cheaper than manual survey techniques that are conventionally used to obtain traffic speed and journey time data. In its current guise, the TrafficProbe platform is most readily deployable in low numbers for purposive traffic speed and journey time data collection.  The collaboration fostered between taxi operators and drivers, and CITOM, demonstrated that both parties were prepared to work together and share data for mutual benefit. While this presents a significant opportunity for sustaining the platform in Cebu City beyond the life of the demonstration project, it is also a key requisite for future replication in other cities using taxi vehicle fleets. Lower value components of the demonstration project  The small ‘real world’ sample of floating car data points achieved through this demonstration project is due to a combination of unreliable wireless data connectivity in Cebu City and low levels of taxi driver compliance that were, at least in part, driven by concerns of taxi operators and drivers over the value of the smartphones and the extent they made taxi drivers a greater target for violent crime. While concerns over smartphones being stolen appear to have been largely unfounded (6 devices out of 320 were reported stolen during the demonstration project) the reliability of 3G data networks and driver resistance to having their location tracked are difficult issues to overcome. These are considered requisites for successful replication in other cities.  Using the city’s taxi fleet as a floating car sample resulted in a dataset that contains ~50% faster absolute average traffic speeds and journey times – variable by time of day – than those recorded by previous manual surveys that include public transit and/or attempt to circulate at the speed of general traffic flow in the city. Broadening the sample of vehicles in which the TrafficProbe app is deployed could resolve this.  The panic button tool was little-used by taxi drivers and operators during the course of the Cebu City demonstration project. Most drivers were aware that there was no formal monitoring or coordinated response, and therefore did not trust it as a mechanism.  Taxi dispatch functionality was also barely used through the course of the demonstration project, which appears mainly due to the high level of competition for taxi fares in Cebu City resulting from an over-supply of vehicles and licensed drivers. The small screens on low-cost smartphone devices deployed through the demonstration project, low literacy levels among some taxi drivers, and a city ordinance making using a ‘phone while driving illegal, also contributed to this outcome. 25/06/2014 56 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT  The availability of human resources and their capacity to analyse and use new data feeds is an issue presented by the introduction of the new sources of data provided by the TrafficProbe and Traffic Alert software tools. 25/06/2014 57 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT 6 SUSTAINING AND SCALING-UP THE SOFTWARE PLATFORM 6.1 This chapter draws on the findings from our evaluation of the TrafficProbe and Cebu Traffic software platforms in order to recommend options for sustaining and scaling up the tools in Cebu City, as well as replicating them in other cities. Sustaining the tools in Cebu City 6.2 Encouragingly; both the participating taxi operators, and their drivers, stated that they were keen to remain involved based on the value they have derived from the smartphone app and web-based tools to date. Figure 6-1 shows that 94% of participating drivers, and 93% of the non-participant control group of taxi drivers, stated they would find the system tested in Cebu City attractive or very attractive in the future. Figure 6-1: Cebu City taxi drivers’ perceptions of the TrafficProbe app’s future value 60% 53%54% 50% 47% 46% Percentage of respondents (%) 43% 40% 40% 30% 20% 10% 5% 7% 3% 3% 0% 1% 0% 0% 0.5% 0% Very attractive Attractive Neither/nor Not very Not attractive at attractive all Before Survey - Oct 11 (509 respondents) After Survey (GPS) - Jul 13 (202 respondents) After Survey (No GPS) - Jul 13 (201 respondents) 6.3 In order to successfully maintain the platform there are a number of considerations that CITOM and the participating taxi operators will need to bear in mind. These have been discussed in the remainder of this section. Software platform operating costs 6.4 The operating costs of the software platform will become a concern for CITOM and the participating taxi operators from November 2013 onwards, as the inclusive data contracts funded by the World Bank in order to support this demonstration project will end. The key dates at which significant numbers of these data plans will cease to be funded by the World Bank through this demonstration project are:  November 2013 – 30 units  March 2014 – 100 units  April 2014 – 200 units  May 2014 – 180 units 25/06/2014 58 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT 6.5 Based on the sample of 320 smartphones currently distributed and managed by CITOM and the 190 remaining devices that are ready to be deployed in Cebu City:  The total annual cost of maintaining unlimited data plans, cloud hosting and technical support for the devices will be USD $87,600, or $14 per fleet vehicle per month.  Both the taxi operators and CITOM expressed an interest in equally sharing these costs in order to sustain the platform and the data feeds it generates.  Splitting these costs equally would see each participating taxi operator contributing $7.00 per vehicle per month ($84 per annum per vehicle) to CITOM in return for a real- time automatic vehicle location system, and extended loan of the smartphone devices distributed through the project. CITOM would require a budget of USD $43,800 to cover the on-going cost of maintaining this fleet of floating vehicle data probes, and a further $7,000 to maintain the Traffic Alert data entry and visualisation tools – representing a total annual budget of $50,000. 6.6 As well as sharing the implementation costs, the taxi operators noted that they would be more willing to continue participating in the initiative if the loss of a smartphone by a participating driver could be linked to the professional driver licensing system in Cebu City – possibly the confiscation of licence until the ‘phone is replaced. Identified additional training needs 6.7 The project evaluation findings have highlighted a need for further training in several areas in order to maximise the value of the existing platform of software tools, and these are summarised in Table 6-1: Table 6-1: Training needs identified through project evaluation Target user-group Purpose Delivery by • Improve awareness and understanding of Cebu Traffic CITOM Cebu Participating taxi operators dispatch and O&M tools. Traffic delivery • Address driver compliance issues and team associated management challenges. • Improve awareness and understanding of TrafficProbe app CITOM Cebu functions. Participating taxi drivers Traffic delivery • Address driver compliance issues team (turning-off phones / not charging devices). • Improving understanding of information to include in the Traffic CITOM Cebu Alerts database. Traffic delivery COMMEL Radio operators • Agreeing data entry protocols so they team and are consistently replicated. COMMEL • Agreeing on what types of alert supervisors should be made publicly available. • Analytical training focused on using Colleagues new sources of data. from University CITOM Transport Planning • Focus on how new data can be used San Jos team to complement other sources of data Recolitas / held/collected by CITOM. UPNCTS 25/06/2014 59 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT Other resource requirements 6.8 Staff at both CITOM and the participating taxi operators identified a possible need for additional resources in order to accommodate and manage various aspects of the software platform and maximise its value in Cebu. These included:  CITOM committing additional staff resources to the COMMEL team – whose recommendation was 4 people running the radio control room during the day – to ensure that they are better able to:  Provide a 24/7 taxi driver Panic Button monitoring function using the Taxi Dispatch view that shows all taxi driver’s real-time locations, with an associated protocol for a response by Traffic Enforcers/Police Officers. Both taxi operators and drivers agreed that this would provide assurance to taxi drivers that their panic button calls were being monitored and responded to, but noted that CITOM’s view of this vehicle-specific data (e.g. not anonymised) must never be used for traffic enforcement purposes. The post-implementation survey revealed that 100% of the 202 taxi drivers who participated in the demonstration project, and 98% of the 201 that did not, indicated that a panic button which was reactively monitored and guaranteed a response from CITOM or their taxi operator would be useful.  Guarantee timely real-time entry and maintenance of the Traffic Alert view; with particular attention being paid to enhancing the quality of information entered, and maintaining publicly visible traffic alerts so that they are added to the map promptly and cleared from the map once a problem has been resolved.  Taxi companies agreeing to commit additional staff resources, and auto-parts / vehicle maintenance effort, in order to:  Monitor the dispatch view during office hours so that they are also aware of incoming driver Panic Alerts and messages.  Better maintain in-vehicle 12v DC charging ports, hard-wire a charging lead to the vehicle battery’s accessories output, and (if deemed appropriate by the operator) securely mount the devices onto the dashboard so that they cannot be forcibly removed. Scaling-up the existing software platform in Cebu City 6.9 A number of ideas and opportunities for scaling-up the existing software platform were identified through the course of post-implementation stakeholder engagement activities completed at the end of the demonstration project. These ideas assume the resources required to sustain the basic platform (as identified above) will continue to be met through some combination of CITOM and the participating taxi operators in Cebu City. Creating a public information website/smartphone app 6.10 The next challenge, according to CITOM’s Executive Director, is to find ways to make the Cebu Traffic Data valuable to the public to ensure sustainability. In a post-implementation interview he suggested that that the development of applications and websites would be a good avenue to make the data accessible to the public. Ideas for how this could be developed include: 25/06/2014 60 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT  Creating a public website visualisation that shows live incidents on the road network in Cebu City. This visualisation could be coded in such a way that it is embeddable as a widget/plug-in into other websites (e.g. local news and weather sites) as well as being a source of information in its own right. Making traffic alerts public would create healthy pressure for the COMMEL team to ensure that the information about traffic incidents they are inputting using the TrafficAlert tools, and sharing publicly, is accurate. Making the website responsive to different screen sizes (using HTML 5) would also ensure it can be viewed on a smartphone/tablet. Estimated cost to develop: USD $5,000.  Creating a public website visualisation that shows average traffic conditions. The extent to which this is useful would need to be explored, since the validation of demonstration project data showed that a significantly larger number of handsets need to be connected to the TrafficProbe platform in Cebu City to achieve an acceptable live sample of traffic conditions in the city. Based on the data collected through the demonstration period of the project, it would be possible to visualise average traffic conditions at different times of day/day of the week on a public website. This would facilitate open public debate about traffic conditions in the city, and the action that can be taken in order to address identified issues. Estimated cost to develop: USD $5,000.  Creating a public smartphone application based on the Traffic Probe app. As a minimum this application could share the visualisation of incident points in Cebu City, and show them overlaid on an OSM map of Cebu City. Estimated cost to develop: USD $5,000 per smartphone platform. A more complex version of the app, which leverages GPS functionality on smartphone devices in order to boost the sample size, could represent a future enhancement that broadens the size of the sample. Improving traffic management operations at CITOM / in Metro Cebu 6.11 Through the course of post-implementation interviews, both COMMEL and the SCATS Traffic Control teams identified opportunities for the Traffic Probe platform being deployed in Cebu City to improve the integration between these two teams and enhance the organisation’s responsiveness to identified traffic incidents. The recommendations from these teams included:  The COMMEL and Traffic Control Centre being co-located to facilitate communication and coordination of monitoring activities.  Making the new traffic control centre operational 24/7, with COMMEL and SCATS staff members sharing responsibility for fulfilling this function and updating the Traffic Alert map. 6.12 Given that these changes would require facilities changes at the existing CITOM offices on North Bacalso Avenue, they would likely need to be taken forward as part of any proposed relocation of the CITOM office in Cebu City. The costs of achieving these changes would be for CITOM to explore, but could include both staffing (extra person hours) and facilities (re-configuring office space) costs. 6.13 The project team recommends that regular meetings between the Operations Division (COMMEL, SCATS Traffic Control) and the planning teams could be beneficial as a way of requiring regular analyses and discussion of traffic speed and journey time data, and 25/06/2014 61 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT potential actions (e.g. using SCATS) to address identified issues. These meetings would ideally be held on a monthly basis – based on the level of data achieved through the demonstration project – and reflect on analyses of the last months’ worth of live traffic data. Key performance indicators, such as journey times along key arterial routes at specific times of day, could be developed as a means of quickly understanding the extent to which traffic conditions have improved/worsened from a previous period. The cost of these meetings and routine analyses would be negligible, but would involve representative staff from the COMMEL, SCATS and Transport Planning teams finding the time to meet on a regular basis. Extending Traffic Alert coverage 6.14 To be more useful to members of the public, and to help CITOM staff members understand traffic congestion events that spill into Cebu City from neighbouring cities in Metro Cebu, it may be beneficial to extend the Traffic Alert reporting to other City’s traffic management teams. For example, CITOM’s COMMEL team could act as a training partner for neighbouring city’s (e.g. Mactan/Talisay/Mandaue) traffic management teams. All of the cities would benefit from sharing information with each other, and user log-in privileges could be established to avoid any confusion over the locations of traffic enforcer staff in the event that all of the participating cities’ teams wish to use the software tools for this purpose. Estimated costs of expanding the Traffic Alerts system to neighbouring cities in Metro Cebu are:  Fixed cost of USD $5,000 to implement user log-in privileges and admin tools.  Fixed cost of USD $1,000 per control room for PCs and connectivity equipment.  Variable cost of USD $15 per month for broadband connection to each additional control room.  Cost of time charged by CITOM for training in how to use the software tools (if charged by CITOM). Extending the sample of vehicles collecting traffic data 6.15 Based on the project team’s experience of deploying mobile handsets in taxis we do not believe that significant expansion is appropriate or feasible beyond the current sample using owned- devices. Setting aside capital costs involved with mobile handset procurement, the on-site labour and expertise required to successfully deploy and maintain handsets in marginal operating conditions (e.g. in taxis and on less than favourable mobile networks) is considerable. Further, the challenge of driver compliance and participation make it unclear if there are additional, untapped opportunities to deploy devices. 6.16 With increased public adoption of Smartphone devices opportunities exist to increase passive locational/movement data without the need to buy, configure and maintain the device. The efficacy of this approach is demonstrated through a variety of crowd-sourced traffic data collection platforms, including those operated by Google, Waze, Telenav and Inrex. 6.17 During the development of this demonstration we identified a simplified approach to data collection that could be deployed on any mobile device, without significantly impacting user privacy, or battery and mobile data consumption. These methods have already proven 25/06/2014 62 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT effective as part of the Mobile Millennium project and can be easily scaled to the capacity required for a full real-time sample per requirements outlined in paragraph 4.20. The only requirement is incentivizing direct public participation (e.g. combining data collection functions in a publicly distributed app of significant popularity, such as the Manila MMDA Traffic App) or embedding data collection tools into a variety of existing commercial applications (strategy used by the Telenav platform). Guidelines for replicating in other cities 6.18 The estimated cost of replicating the whole TrafficProbe platform, and Traffic Alerts on a similar scale in a similar location is USD $83,215 per annum over a 3 year period. This assumes similar local labour costs to Cebu City, that the delivery of all high-level ICT support is remote, and that a similar number of agencies are participating in the project. 6.19 Based on our experience deploying and validating a fully-supported taxi-based data collection platform in Cebu we have developed the following recommendations for re- deployment in other locations:  Recognise the challenges inherent in procuring, distributing and managing mobile handsets. This is both costly in terms of capital and in labour. Particularly, the long-term cost of configuring, distributing and maintaining deployed handsets must be considered as part of the overall project budget. This is particularly a concern if engaging a non- technical audience like taxi drivers, as they may require a significant degree of technical support.  By taking on the procurement and distribution of devices, significant risk is also absorbed related to the reliability of underlying hardware. As demonstrated as part of this project there are significant quality problems with low-cost mobile handsets. These are challenging problems to diagnose or detect prior to deployment. And even with higher quality devices problems will still be encountered when dealing with a large number of installs.  Consider the availability of existing vehicle fleets (both public and private) as well as opportunities for engaging the public directly in data collection activities. By tapping existing infrastructure this may eliminate the need to consider hardware as a component of the project.  Consider reducing the scope of the data collection activities and extending the survey time period. By focusing on a smaller number of vehicles a sample sufficient for transport planning and evaluation can be collected over a period of time (weeks or months). Similarly, consider semi-connected data collection approaches over real-time. With a smaller sample size the real-time data becomes less relevant, allowing batch processing either at the end of the project or on a period basis. Combined, these changes significantly reduce the technical complexity while delivering a valuable data set.  To the extent that data must be collected from the public, address the privacy implication by moving aspects of the inference to the phone. This allows users to return summarized velocity data rather than positional information. This data should be stored only in aggregate forms and not tied to user identifiable logs. 25/06/2014 63 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT 6.20 Notwithstanding the points identified above, relating to the challenge of achieving a sufficiently large sample of deployed TrafficProbe handsets in order to achieve a real-time traffic dataset, we recognise that other cities may find the software platform valuable in the context of purposively collecting accurate floating vehicle data, and using the Traffic Alerts system to coordinate traffic network management/public information services. It may also appeal to taxi operators whose operations are based in more compliant environments and who wish to establish a low cost Automatic Vehicle Location platform. 6.21 In order to assist city authorities or taxi companies that might be considering replicating the TrafficProbe platform in their city, the project team has prepared a set of Implementation Guidelines (see Appendix C to this report) that define the steps associated with setting up the software tools and inter-agency collaboration needed to make it work. 6.22 The remainder of this report summarises the key lessons learned by the project team through challenges met on this project, and also sets out our ideas for future development of the TrafficProbe platform, which may be relevant to the World Bank and donor funding agencies. 25/06/2014 64 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT 7 LESSONS LEARNED FROM KEY IMPLEMENTATION CHALLENGES 7.1 This chapter of the report outlines the lessons learned by the project team through the course of overcoming key implementation challenges whilst delivering this demonstration project in Cebu City. They are likely to be valuable to other city authorities or taxi operators wishing to replicate the TrafficProbe software platform in their local area. Procurement of handsets and data-plans 7.2 One of the primary lessons learned is that not all handsets are created alike. Perhaps even more surprisingly, we learned that quality can even vary significantly within product portfolios for established handset makers. This discovery related to one of the biggest project setbacks - our initial round of mobile devices (received and deployed in Oct 2012) contained a firmware bug that caused the GSM modem to stop transmitting data after a short period of time. The bug could not be recreated when using the devices on a different mobile network. 7.3 The only way to resolve the failure was to cycle the power. After over three months of extensive investigation the failure was traced to a known flaw in the installed firmware related to deployment on the carrier's network, correctable via a manufacturer upgrade. Due the delay in tracing this problem and the labour required to install the updated firmware, a decision was made to replace the handsets with a different model. Despite successful resolution, this caused a several month project delay. 7.4 As a result we strongly encourage field testing of all mobile software on the specific device on the intended mobile network. Without testing the exact network/device/software combination there is strong chance of missing critical deployment related bugs. Software platform and firmware selection 7.5 For this project we selected Android phones for application deployment. This allowed substantial flexibility in developing and deploying test applications. However, the aforementioned challenges with device quality and capability raise questions about consistency across the Android platform. 7.6 To the extent that a future applications will be deployed on owned-devices we have decided it is worth the additional cost to use only fully unlocked devices with Google- deployed Android versions. Android modifications made by carriers/device manufacturers lead to additional operating system nuances that are not present in the Google-deployed Android OS versions, and also increase data charges due to the data traffic they generate. In-vehicle charging of smartphone handsets 7.7 Access to consistent and reliable power hook-ups proved to be the second most significant challenge in deploying devices. The project team used a USB charger mounted in the cigarette lighter power port. However, the variety of different vehicle types (and degree to which they were being properly maintained) required flexibility both in terms of cabling solutions and support from taxi owners in diagnosing and resolving vehicle wiring problems. These ranged from blown fuses to missing wiring looms. 25/06/2014 65 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT 7.8 Even once vehicle a power source was identified, challenges remained with reliability. By using a cigarette lighter charger it was easy for cables to come loose or to compete with other uses, as the driver swapped cables to power other devices. 7.9 Despite the complexity and expense, hardwired connections are critical to ensure reliable maintenance-free power. Wireless connectivity in Cebu 7.10 Device-related connectivity problems aside, the project team also encountered general system-wide and account specific connectivity issues. At several times over the course of the project we discovered network-wide loss of data attributable to problems with the cell network itself. More problematically, however, we experienced several account-related disconnections where devices were turned off due to errant billing problems or incorrect provisioning. These problems required that devices be reset multiple times; effectively taking deployed devices offline until CITOM’s local delivery team intervened. 7.11 Additionally, due to limited data plans, we encountered wide-spread account overages as drivers used phones for purposes other than intended (particularly social media applications, wireless hotspot delivery and content downloading). This resulted in disconnection of a substantial number of devices and many complaints from drivers. 7.12 After negotiation with the provider we were able to remove data caps for the devices. However, as shown in Figure 7-1, shortly after re-provisioning (on or around August 10th) we saw a significant drop in connected devices. We assume this is related to the aforementioned provisioning related disconnections. Figure 7-1: Daily handset count, showing a significant drop in mid-August following operator re-provisioning Local capacity to maintain the Cebu-Traffic server and database 7.13 Given the complexity of the software platform, local maintenance of the software platform remains a challenge. Progress was made in building a relationship with local university partners with capacity to host the deployed applications on Filipino servers. However, the reliability of these servers and the ability of staff to intervene and deploy application-related updates remains to be seen. 25/06/2014 66 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT Working with compliant partners 7.14 The success of this project hinged on the extent to which local taxi operators were prepared to both share data with the city authority, and their drivers were prepared to have their location tracked by their employers. The extent to which this actually happened - combined with other issues highlighted in this report relating to device power supply, wireless data network connectivity, and data-plan limits being reached through drivers using the ‘phones for other applications – critically limited the traffic data sample size achieved through the demonstration project. It underlines the importance to city authorities of working with compliant partners whose interests closely align with those of local transport network managers, when attempting to implement the TrafficProbe software. Viability of using TrafficProbe to collect real-time traffic data 7.15 Based on observed driving patterns within the demonstration project’s sample of deployed TrafficProbe applications mounted in taxis, the project team determined that real-time sampling of roadway conditions is not feasible (see paragraph 4.20). The increased sample size required to support real-time collection calls into question the approach of deploying owned devices. However, a small number of devices operating over an extended period of time (weeks or months) can provide meaningful and accurate observations of traffic conditions in aggregate to facilitate more detailed traffic analyses, or area-wide traffic model development. Quality of OpenStreetMap (OSM) data 7.16 As the project fundamentally depends on OSM data as an input for tracking vehicle movements, the quality of the underlying data was a concern. However, the project team discovered early in the project that existing OSM data for the region was of sufficient quality to support the TrafficProbe applications. Further, as part of the project local staff received training on OSM maintenance and editing and have subsequently made contributions to improve the quality and accuracy of base map data. 25/06/2014 67 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT 8 IDEAS FOR FUTURE PLATFORM DEVELOPMENT 8.1 This final chapter draws on the project team’s experiences of developing the TrafficProbe software platform and working with local partners to implement the demonstration project in Cebu City to set out a number of ideas for the future development of the software platform. These could be taken forward through replication projects in other locations, or through the scaling up and expansion of the demonstration platform deployed in Cebu City. Smartphone-based traffic enforcement tools 8.2 A smartphone app that enables in-street traffic enforcers to be permanently geo-located whilst at work would save control room teams – such as when managing their staff resources. Although it would be unlikely to remove the need for a radio network altogether (due to the cost of calling in place of using a free radio network channel), creating and deploying such an app would potentially:  Make it possible for traffic enforcers to place Traffic Alerts directly into the TrafficProbe database.  Reduce the effort of control room staff (such as the COMMEL team in Cebu City), and allow them to focus on coordinating CITOM’s response to incidents that occur on the local highway network.  Improve the geo-spatial accuracy of fault reports by leveraging GPS functionality on smartphones to pin-point the site of collisions, congestion, broken traffic signals and other location critical incidents. 8.3 A version of such an app could also be created to allow members of the public to report traffic incidents. These might need to be vetted by traffic enforcers/managers, but would truly crowd source the effort of reporting and communicating the location of traffic incidents. Enhanced taxi dispatch functionality 8.4 The taxi dispatch tools developed through the demonstration project are relatively basic, and could be enhanced through replication or extension of the platform. Potential enhancements could be made to both the TrafficProbe smartphone app, and the Taxi Dispatch tools, including:  Conversation messaging mode – allowing taxi operators using the web-based dispatch tools, and drivers using a smartphone app, to follow a conversation – rather than trading isolated messages.  Including a For Hire/Hired status function into the TrafficProbe app, so that this could be communicated back to a control room using the web-based dispatch tools. All drivers in Cebu City expressed a willingness to share this information and operators were also keen to see this implemented, but felt it could be manipulated by drivers. Ideally this function would therefore be linked to taxi meters if they are present in the vehicle.  Logging of jobs accepted/rejected/serviced in order to identify responsive and unresponsive drivers.  Integration of VoIP (e.g. Skype or Google Voice) calling within the app, to enable drivers and taxi operators to stay connected cheaply – potentially replacing a radio 25/06/2014 68 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT network requirement. This would require very good 3G (or ideally 4G) wireless data connectivity in order to function effectively, so may not be appropriate in every context.  Integrated routing recommendations based on local street network data in the OpenStreetMap. This would require considerable additional development to work effectively, as well as an accurate underlying OSM base map. A further extension of this concept could be to integrate of real-time traffic conditions/incident locations in order to provide scope for dynamic re-routing mid-journey. This would represent substantial additional development from the current crowd-sourcing platform, but would also likely enhance the attractiveness of the TrafficProbe app to both taxi users and members of the public using the highway network. 8.5 A requirement when developing several of these tools would be that they are deployed in a location that requires taxi dispatch services, and does not already use an alternative system (e.g. a radio dispatch network), and where there is a greater taxi booking requirement than in Cebu City. Regenerative creation of OSM data from crowd sourced traffic data 8.6 During the development of this demonstration project the project team identified an opportunity to re-purpose collected GPS location data to improve the quality of underlying OSM base-maps. Significant research has been conducted regarding generative map creation from GPS data (e.g. segment clustering, inference of directional properties, etc.) however, as yet, no attempt has been made to incorporate this functionality into OpenStreetMap. We believe this can be considered a natural extension to any project collecting large amounts of GPS data and is a feature that could be added to the TrafficProbe platform. Developing an open crowd sourcing version of TrafficProbe 8.7 As per paragraph 6.15 we believe there is significant, and as yet unexplored, opportunity to develop a fully open, crowd-sourced, traffic data collection infrastructure. The success of platforms like Waze demonstrate the efficacy of this approach, however, as yet no open source/open data equivalent has been developed. As demonstrated through this project the technical challenges are surmountable, but the primary question remains as to ‘How to incentivise public participation?’ Variable Message Sign integration 8.8 In an environment where remotely connected Variable Message Signs form part of local highway infrastructure, there would be scope to integrate message activation and editing tools into the Traffic Alerts web-application. This could enable an authority’s traffic management team the opportunity to draw on live traffic alert information, and (where a large enough sample has been achieved) live traffic speed data, to relay information to roadside Variable Message Signs via an API sent over local data networks. While there are many proprietary versions of this type of system, developing integration with the open- source TrafficProbe software platform deployed in Cebu City could enable city authorities to run their own VMS signage. 25/06/2014 69 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT Improved junction transit time data 8.9 During the development the project team recognised several opportunities to improve monitoring of queue related delay at junctions. By sub-dividing road segments to allow monitoring of transit times for only the portion of a segment approaching a junction it may, in certain situations, be possible to disaggregate junction related transit times from overall segment travel speeds. 8.10 Further research is needed to validate this approach, as is a larger observation sample. The current sample size challenges prevent accurate estimates of transit times based on a meaningful frequency of junction crossings at the scale of a single junction. 25/06/2014 70 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 1 FINAL REPORT Transport Crowd Source Information and Communications Technology (ICT) Demonstration Component 2 – Civic Engagement Platform October 2013 Produced by: Integrated Transport Planning Ltd 32a Stoney Street The Lace Market Nottingham NG1 1LL 25/06/2014 1 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT EXECUTIVE SUMMARY This document constitutes the final report of Component 2 of the Transport Crowd Source Information and Communications Technology (ICT) Demonstration project. It focused upon crowd-sourcing street infrastructure fault reports via SMS texts from residents in two pilot Barangays in Cebu City, Philippines, using replicable open source software tools and low-cost smartphones. The aim of the project was to explore the viability of using ICT (SMS texts and software) to create data feeds and analytical tools that would assist Cebu City Government and collaborating national government agencies with their day-to-day management of reported faults relating to defective streetlights and potholes. The demonstration project was co-ordinated by the World Bank using funds from AusAid and the Korea ICT4D Trust; and implemented in partnership with Cebu City Government, it’s Department of the Environment and Public Works (DEPW) and Department of Public Services (DPS), and the Philippines Government’s Department of Public Works and Highways (DPWH). A summary of key findings related to the three project deliverables is provided in the table below: Applications / Tools / Quantifiable Objective Qualitative Result Training Results Develop a proof of • FixMyBarangay Message • 150 SMS text • Reduces fault concept low-cost, Manager –receives and messages reporting time and simple, means manages SMS text received since and effort to collect street messages from local March 2013 • 1 Peso SMS cost repair and residents. • 6 fault reports is more maintenance data • FixMyBarangay web- added to the expensive than via SMS based data entry tool – FMB map by reporting in used by Brgy. teams to Barangay staff person at Brgy. input faults reported in- • No fixed Hall person or ‘phone problems • Streamlines fault • Hands-on, in-person reported via information training and mentoring the tools handling task for delivered to Cebu City • Set-up cost: Brgy. staff Government delivery team USD $10,200 and repair agencies, Brgy. • Staff time main Staff and members of the driver of costs public Use collected data • FixMyBarangay • Timeframe for • Integrated, to more effectively Maintenance Database fault report digitised means track, plan and endpoints for DEPW, DPS response of managing and deliver street and DPWH linked to FMB reduced from resolving repairs website for 2-way fault 8-12 weeks to reported faults. reports and status update 2-3 weeks. • Likely labour time • Supported local delivery • Set-up cost: savings for repair team at Cebu City USD $19,500 teams. Government with training • Implementation • Expectation for repair agency staff cost is mainly management of • Template presentations, staff time fault repair times pledge of commitment and story of a pothole reources created Establish an • FixMyBarangay publicly • Costs covered • New way to map information viewable website through FMB reported issues platform to support • Contains nstructions on data collection in Cebu City public participation how to submit fault reports tools • New opportunity 25/06/2014 i TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT Applications / Tools / Quantifiable Objective Qualitative Result Training Results and engagement in and view-only access to • Added-value for open dialogue identifying and maop showing reported component of about faults and monitoring street problems and their status FMB website repair response / repairs • Community Street resource mapping and public allocation launch events supported • Opportunities for through demonstration such dialogue yet project. to be exploited in Cebu City after demonstration project Platform implementation and maintenance costs The software tools implemented in Cebu City through this demonstration project represent low- cost ways that city governments can collect and manage street infrastructure repair data on a continuous basis, and in a digital format which is immediately available for budget/response performance analysis. The estimated cost of replicating the whole FixMyBarangay platform, and associated Maintenance Databases on a similar scale in a similar location is USD $30,000 for the first year, and USD $7,440 to maintain it each year thereafter. This assumes similar local labour costs to Cebu City, that the delivery of all high-level ICT support is remote, and that a similar number of agencies are participating in the project. Approaches to engaging a local ‘crowd’ The success or otherwise of a FixMyBarangay project implementation hinges on the extent to which a local ‘crowd’ of stakeholders is engaged by whichever local agencies are responsible for delivering the service. In this sense, the ICT platform is a means to an end, with the effort and energy of local people ensuring the software tools remain relevant and useful. The project and local delivery team experienced mixed success in respect of engaging local people in Cebu through the pre-launch, launch and post-launch stage of the project. The following key lessons emerged from our process learning at each stage of the project:  Pre-launch: Early meetings with local community leader, community engagement through participatory mapping exercises and a poster design campaign run with local youth groups were successful at generating interest and awareness in the project. Greater hands-on software/SMS fault reporting training and system testing, and a more extensive soft-launch would have been beneficial and likely reduced the need for repeated refresher training as th project progressed.  Launch: Shortlisted and winning poster designs displayed at a public launch event, the involvement of local media partners, and use of social media and local community group networks all helped to ensure that the FixMyBarangay caught the Mayor of Cebu City’s attention, and secured considerable media coverage. The lack of hands-on training and immediate follow-up training for both Barangay staff members and local residents who participated in the launch events at the two Barangay Halls was the result of insufficient time being allocated for each launch event. Not being able to do this as thoroughly as intended partly explains the relatively low uptake in the initial few months of the FixMyBarangay tool’s launch in Cebu City, and loss of momentum following the launch events. 25/06/2014 ii TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT  Post-launch: The project team’s experience emphasised the need for continual support and frequent training for local residents who might be unfamiliar with the approach to submitting fault reports by SMS text, and Council staff working with web applications to verify and map these. Fortnightly contact with community and Council leaders, targeted follow-up training to all Council participants, and follow-up surveys to understand why people are/are not using the service are likely to be necessary post-launch activities if the degree of public uptake/civic response is not as expected. Adding more issues/broadening the geographical coverage of the FixMyBarangay service could also help to encourage greater uptake and use of the system – something being considered in Cebu City at the end of this demonstration project. Sustaining and scaling up the software platform in Cebu City If Cebu City Government renews the existing service with the incumbent SMS Gateway provider, and all staffing and broadband costs continue to be borne by Cebu City Government, the participating Barangays and the repair teams at DEPW, DPWH and DPS (as they were during the demonstration project), then the total cost of maintaining all aspects of the FixMyBarangay software platform is estimated at: USD $7,440. The bulk of this cost (USD $6,000) is for technical ICT support (which was not available within Cebu City Government at the time of preparing this report), with the remainder allocated to cloud hosting and SMS gateway subscription costs. When shared between Cebu City Government’s MICS team and the three participating departments with fault repair responsibilities, the total annual cost per-agency is less than USD $2,000. Additional training needs were identified if the FixMyBarangay platform is to be sustained and maximised in Cebu City beyond the demonstration project. These centred on improving the awareness and understanding of the service among local residents in order to drive up fault reporting levels, increasing the number of people in each Barangay who can use the FixMyBarangay tools to assign incoming fault reports (both via SMS and over the ‘phone/in person) to the map, and defining and agreeing routine protocols for repair agency staff using FixMyBarangay Maintenance Databases to manage and plan street infrastructure repairs. Some additional resources will also be required to sustain the platform. Each participating Barangay will need to commit at least two members of staff beyond the Barangay Captain and Secretary so they have sufficient resources to use the FixMyBarangay tools to place reported problems (either by SMS text, in-person, over the ‘phone or received by email) onto the map of Cebu City. The Chief Engineer at each participating local and national government department will need to allocated responsibility for checking their organisation’s Maintenance Database endpoint to at least two members of staff. Finally; additional Barangay-wide advertising targeted at people with access to cell ‘phones, as well as people who are currently reporting streetlight defects and potholes by means other than through FixMyBarangay. Opportunities for scaling up the demonstration platform in Cebu City include:  Adding extra Barangays to the software platform to extend the service coverage to a greater number of Cebu City residents. Ideally a small number (e.g. 1-2) of additional Barangays would be added to the FixMyBarangay service in Cebu City at a time to avoid overwhelming fault response teams. Estimated cost to deploy is negligible based on on-going costs.  Adding new problem report issues (e.g. garbage collection) to the FixMyBarangay platform in order to improve the usefulness of the service for local people. New issues should be added one-at-a-time to allow repair agencies time to adjust, and widely communicated to residents in participating Barangays. Estimated cost to deploy is negligible based on on-going costs. 25/06/2014 iii TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT Lessons learned from key implementation challenges The lessons learned through the course of overcoming key implementation challenges whilst delivering this demonstration project in Cebu City are likely to be valuable to other city authorities or community groups wishing to replicate the FixMyBarangay software platform in their local area:  Understand local access to communication technologies. The project team conducted 500 surveys and focus groups with Cebu City residents to gain insight into local levels of mobile phone ownership and internet access, and what people use these services for. This intelligence helped the project team and local delivery partners determine that FixMyBarangay should be SMS text-based, rather than web or smartphone app-focused.  Carefully select ‘problem’ issues for fault reporting. Striking an appropriate balance between issues which matter to local people, and which can also be addressed through a local government response can be challenging. The project team found that most important street infrastructure issues for local people (illegal parking and overflowing drains) were not issues which are easy to resolve in Cebu City. Hindsight has taught the project team that garbage collection may have been a more engaging issue on which local people would participate, and is likely to be added as the next issue that the FixMyBarangay platform covers.  Adopt the most agile approach to software development as possible. Prior to implementation, a good ‘real-world’ test of local people’s preparedness to report problems via SMS text would involve a 2 week long pilot using an old mobile phone and a SIM card. This would test the extent to which people are prepared to report problems by SMS, locations from which most problems are reported and the key issues about which people report problems. We would strongly urge any city authority seeking to replicate FixMyBarangay undertakes this kind of low-cost trial before investing time and resources into implementing the software platform  Understand local cultural awareness of maps and geo-spatial information. Maps and geo- spatial means of presenting information are a potential barrier to uptake of the FixMyBarangay tool. In the Philippines it is culturally more common for people to think about places and spaces in a descriptive sense; with local landmarks, physical geography features (e.g. rivers, hills, beaches), and street-names being the most commonly-used points of reference. Requiring Barangay staff members to click on an OSM map of their local area in order to locate a reported problem was an issue in this demonstration project, since this was also the mechanism by which problems were categorised and escalated to relevant local repair teams. This requirement for geo-spatial knowledge has likely prevented some reported faults from being categorised and passed on to the relevant repair team in a timely manner.  Exercise care when choosing and implementing SMS Gateway services. The SMS Gateway represents the most significant piece of software customisation that any city authority wishing to replicate FixMyBarangay in their city would need to undertake, since it is typically most cost- effective to use a local SMS Gateway service provider so that messages can be sent and received at local rates. It is generally best to seek out a specialised local provider whose main line of business is in providing SMS Gateway services that enable the sending and receiving of SMS texts via the web, email and an API. Test the SMS Gateway service extensively prior to the launch and try to find an SMS Gateway provider that will make a single SMS short-code number available across all local network providers, since this makes it easier for local residents to remember where to send their fault reports. 25/06/2014 iv TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT  Commit local staff resources to the project, and provide extensive training and mentoring. Obtaining firm staffing commitments from Barangay Halls and the local/national Government Departments was challenging, and the pressure on staff resources at both sets of organisations continued to present difficulty beyond the launch of the project. Ensuring that participating organisations and staff who will be responsible for using the software tools to deliver an outcome (i.e. problem reports categorised, appraised and fixed) have the time available to undertake these tasks alongside their day-to-day responsibilities is very important. Securing the backing of key internal decision-makers, and incentivising individuals to routinely use the FixMyBarangay software tools is more likely to ensure that individual’s commitment to the project is allied to personal as well as civic goals.  Local technical capacity and resources to maintain a FixMyBarangay server are a requirement if you don’t have access to remote ICT support. The project team found that the process of configuring and maintaining a FixMyBarangay web-server requires levels of both technical staff resources and ICT capacity that can be challenging to deliver in locations such as the Philippines. Through the demonstration project the team was able to support local ICT staff with the task of deploying the Maintenance Databases on local servers, but not the FixMyBarangay web-application and Message Manager tool. Ideas for future platform development Through the course of developing the FixMyBarangay software tools, and supporting their implementation in Cebu City, the project team identified a number of ideas for future development. These could be taken forward through replication projects in other locations, or through the scaling up and expansion of the demonstration platform deployed in Cebu City.  Automated street light post identification - the position (lat/lon) and unique lamp post ID number for every streetlight in Cebu City could be made available so that when a user picks "Street light" from the drop-down menu of problem type, the nearest post numbers (e.g. within 25m of that point) could be offered so the user could choose one if it matches.  Smartphone app to enable mobile reporting – although overhead costs to develop and maintain smartphone apps are higher than for a responsively designed website (such as FixMyBarangay) a new open source FixMyStreet mobile application is about to be released and could be customised for use with the FixMyBarangay platform.  MMS submission of fault reports – Message Manager could be extended to connect to an MMS gateway instead of an SMS Gateway, which would enable geo-coded images to the submitted alongside fault reports.  Opening up FixMyBarangay for submission of fault reports via a web-browser – This would enable members of the public to report problems via the FixMyBarangay website as well as by SMS text message. Publicly viewable and editable updates on reported issues could also be implemented to facilitate community-led issue checking and validation.  Adding ‘private’ problem categories – This would allow for sensitive personal data (such as the home address of an individual reporting a missed garbage collection) to be transmitted to the Maintenance Database endpoint, without appearing on the FixMyBarangay website. In the context of FixMyBarangay, this could be useful if a city authority wished to encourage anonymised reporting of non-emergency illegal/criminal activity. 25/06/2014 v TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT CONTENTS Page 1 INTRODUCTION 1 Funding and implementation partners 1 Project objectives and their relevance to Cebu City 1 Structure of this report 2 2 HOW PROGRAM OBJECTIVES WERE MET 3 Develop a low-cost, and simple, way of collecting street infrastructure data 3 Use collected data to more effectively plan and manage repairs 15 Establish an information platform to support public participation in transport system and network development 23 3 THE VALUE OF OPEN-311 AND OPEN SOURCE SOFTWARE DEVELOPMENT28 Open-311 28 The GNU General Public License 29 Documentation and management of software code using Github 30 Ease of replication in other locations 30 Opportunity for further customisation and enhancement of software tools 31 4 APPROACH TO ENGAGING A LOCAL ‘CROWD’ 33 Pre-launch 33 Launch 34 Post-launch and on-going support 36 5 SUSTAINING AND SCALING-UP THE SOFTWARE PLATFORM 37 Sustaining FixMyBarangay 37 Scaling-up the tools in Cebu City 39 Guidelines for replicating in other cities 41 6 LESSONS LEARNED THROUGH CHALLENGES MET DURING THE PROJECT42 Understand local access to communication technologies 42 Carefully select ‘problem issues’ when setting up a FixMyBarangay service 42 Adopt the most agile approach to software development as possible 43 Understand local cultural awareness of maps and geo-spatial information 44 Implementation of SMS Gateway systems 45 Committing local staff resources to the project 45 Local technical capacity and resources to maintain a FixMyBarangay server 46 7 IDEAS FOR FUTURE PLATFORM DEVELOPMENT 47 25/06/2014 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT Automated street light post identification 47 Smartphone app to enable mobile reporting 47 MMS submission of issues 47 Opening up FixMyBarangay for submission of fault reports via a web-browser 47 Adding ‘private’ problem categories to FixMyBarangay 48 LIST OF TABLES Page Table 2-1: FixMyBarangay message string 5 Table 2-2: Breakdown of costs to replicate FixMyBarangay data collection tools 12 Table 2-3: Breakdown of costs to replicate Maintenance Database tools 20 Table 5-1: Breakdown of costs to maintain all FixMyBarangay 37 Table 5-2: Training needs identified for FixMyBarangay 38 Table 5-3: Tasks and responsibilities for adding new Barangays to FMB 39 Table 5-4: Tasks and responsibilities for adding new problem report issues to FMB 40 LIST OF FIGURES Follows Page Figure 2-1: FixMyBarangay system diagram 4 Figure 2-2: Message Manager running within FixMyBarangay 6 Figure 2-3: Selecting a message from Message Manager for action in FixMyBarangay 7 Figure 2-4: The ‘Users’ admin screen in the Message Manager admin tool 8 Figure 2-5: A thread of messages displayed in the FMB Message Manager view 8 Figure 2-6: Using a ‘Boiler-Plate’ reply to respond to a fault report via FMB 9 Figure 2-7: ‘Boiler-Plate’ string editing interface in the Message Manager admin tool 9 Figure 2-8: Reporting a problem from a received SMS text message 10 Figure 2-9: Non-SMS text message based fault reporting using FixMyBarangay 11 Figure 2-10: Existing MS Access database and handwritten logbook 12 Figure 2-11: FixMyBarangay training sessions in Cebu City 14 Figure 2-12: DEPW’s fault report maintenance database 16 Figure 2-13: Edit problem report view in the DEPW Maintenance Database tool 17 Figure 2-14: Viewing a problem on FixMyBarangay from within Maintenance Dbase 17 Figure 2-15: Map view of all reported faults for DPS to repair 18 25/06/2014 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT Figure 2-16: Story of a pothole in Cebu City – training materials created for MICS 22 Figure 2-17: FixMyBarangay homepage 24 Figure 2-18: All reported problems in Barangay Luz 24 Figure 2-19: Detailed public problem report displayed through FixMyBarangay 25 Figure 2-20: Community street-mapping in Cebu City 26 Figure 2-21: FixMyBarangay launch event poster competition and winner 27 APPENDICES Appendix A: FixMyBarangay Training Presentation Appendix B: FixMyBarangay Pledge of Commitment Appendix C: Street mapping in unplanned communities Appendix D: Sustainability and Scaling up Plan Appendix E: FixMyBarangay Implementation Guidelines 25/06/2014 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT 9 INTRODUCTION 9.1 This document constitutes the final report of Component 2 of the Transport Crowd Source Information and Communications Technology (ICT) Demonstration project, which focused upon crowd-sourcing street repair information from members of the public in Cebu City, Philippines, using SMS text messaging and open source software tools called FixMyBarangay. It summarises all the deliverables provided by the project team during the course of the demonstration project, and documents the challenges met, and lessons learned, through program implementation; as well as providing ‘How-To’ guidelines for other cities interested in replicating such a program. Funding and implementation partners 9.2 The demonstration project was co-ordinated by the World Bank using funds from AusAid and the Korea ICT4D Trust; and implemented in partnership with Cebu City Government, it’s Department of the Environment and Public Works (DEPW) and Department of Public Services (DPS), and the Philippines Government’s Department of Public Works and Highways (DPWH). The project’s consulting team is particularly grateful to the local delivery team at Cebu City Government’s Management for Information and Computer Services (MICS) team, with whom we worked closely to develop, implement and monitor the FixMyBarangay software tools. Project objectives and their relevance to Cebu City 9.3 The project objectives were developed by the World Bank Task Team Leader in response to identified local issues associated with the collection of street repair data and its subsequent application to effect repairs in Cebu City. Specifically, the objectives were to:  Develop a proof of concept low-cost, and simple, means to collect street repair and maintenance data via SMS.  Use collected data to more effectively track, plan and deliver street repairs.  Establish an information platform to support public participation and engagement in identifying and monitoring street repairs. 9.4 These three objectives are directly relevant to the local context in Cebu City. Although road density in the Philippines is comparable with other countries in the region, the quality of those roads is comparably very poor. To illustrate, according to the World Economic Forum (WEF) Global Competitiveness Report 2010–2011, the Philippines ranks 114th out of 139 surveyed countries in terms of road quality. As a result, transport costs and accident rates tend to be high, as well as fleet wide fuel inefficiency. 9.5 Issues such as pot holes in the highway have a strong profile in Cebu with regular news items highlighting damage to vehicles caused by maintenance issues and flooding during the wet season often exacerbated by poor highway conditions. The daily photograph ‘Siloy is watching’ in Cebu Daily News regularly highlights potholes and missing signs, ‘Motorists Corner’ on Facebook (http://www.facebook.com/#!/groups/132768933461789) is also a means by which local road condition issues are highlighted. As such there is an institutional vacuum on highway fault reporting that has, to date, been plugged by the 25/06/2014 1 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT media. This provides clear identification of a need for, and willingness to, participate in highways fault reporting in Cebu City. 9.6 A fundamental challenge is that the agencies responsible for maintaining national (DPWH) and local (DEPW) highways in Cebu City do not have good data on the locations of highway faults and road surface defects. Small teams of engineers work daily in an attempt to audit the city’s extensive road networks and prioritise repairs. Most of the information they hold is recorded in paper drawings, or disparate MS Excel files. Decisions regarding the prioritisation of repairs, and allocations of budget to enact them, are made by the relevant organisation’s Department Head. As a result there is a tendency for citizen groups, Barangay Captains and other influential people in the city to target these Department Heads when requesting street repairs. 9.7 The consequent lack of objective data for informing street repair investment decisions; combined with general distrust of local politicians and disbursement of public funding (according to the WEF Global Competitiveness indices, the Philippines ranks 135th out of 139 countries in terms of diversion of public funds, and 134th for public trust of politicians); inhibits city engineers’ ability to ensure transparent, data-driven, transport infrastructure maintenance takes place in a timely and prioritised manner. 9.8 Our overarching aim was to demonstrate proof of concept versions of basic ICT tools that harnessed SMS text-based fault reports collected in real-time from members of the public in two Cebu City Barangays (Luz and Basak San Nicolas). These Barangays were selected because they represent one small and one large Barangay in different districts (North and South) of Cebu City, and each has distinctly different street patterns. By collecting and aggregating highway-related fault reports sent by SMS text from members of the public residing in these locations, and presenting them through web-based information management tools, the project team sought to provide local highway maintenance departments with a means to more easily assess, prioritise and action street repairs. Structure of this report 9.9 The remainder of this report is structured as follows:  Chapter 2 explains how the project delivery team met each of the 3 project objectives and details the software applications, innovations, and training and capacity building delivered through the project.  Chapter 3 demonstrates why open source software and open data are so valuable to both Cebu City Government and the World Bank.  Chapter 4 summarises the approach adopted by the project team and local delivery partners to engage the local ‘crowd’ of residents in the two participating Barangays.  Chapter 5 provides commentary on how the demonstration software platform that was deployed in Cebu City could be sustained and scaled up in its current context, as well as replicated in other city contexts. A separate ‘How to’ Guide has been appended to this report to assist anyone interested in replicating the project in their local context.  Chapter 6 details the key lessons learned through this project.  Chapter 7 concludes by setting out ideas for the future development of the software platform created through this project. 25/06/2014 2 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT 10 HOW PROGRAM OBJECTIVES WERE MET 10.1 This chapter of the report examines each project objective in detail, and explains how the delivery team working on behalf of the World Bank collaborated with colleagues at Cebu City Government and the local Barangays to develop and implement the FixMyBarangay software platform. Develop a low-cost, and simple, way of collecting street infrastructure data Responsibility for collecting street infrastructure data in Cebu City is dispersed across multiple local and national Government Departments. Road surface defects are recorded by Department of Public Works and Highways (DPWH) on national (strategic) roads, and Department of the Environment and Public Highways (DEPW) on local (minor) roads. The Department of Public Services audits and repairs street light defects. The Barangay staff of Luz and Basak San Nicolas also make regular checks on local roads and street lights, and report defects to the most appropriate/responsive department. The scale of on-going street auditing effort is substantial and under-resourced. DPWH employs 2 members of permanent staff jointly responsible for checking and auditing the condition of nationally managed roads and drains in Cebu City. They are expected to audit 30km of road per day, but rarely achieve this. It involves walking along the roads with trundle wheels to measure and pin-point precise locations of road and drainage defects. DEPW conducts ad-hoc audits of all local roads (last undertaken in 2011) to record defects – this takes 3 months of continuous effort to complete. Reactive road inspections, following a reported fault, also lead to the preparation of repair reports for the Chief Engineer to review and approve for action. The use of mainly paper-based reporting and fault logging methods creates disconnected silos of information about faults requiring maintenance within each Department. Defects are recorded on a mix of hand-drawn road network schematic diagrams, in log-books, and MS Excel/Access databases. Members of the public can also report problems in a multitude of ways, and seldom report them to the correct Department. DEPW receives around 50 telephone calls per day to report faults or problems with the surfaces of roads in the city. Few people are aware whether they are reporting a fault on a city or national road - they simply want the problem to be fixed. Most problems are reported by telephone, and some callers are asked to put their complaints in writing in order that they can be dealt with effectively. Potholes and missing/broken streetlights were identified through surveys and focus groups with residents of Luz and Basak San Nicolas as the main street infrastructure defects that they notice in their local area. Although the vast majority (over 99%) of the people surveyed in both areas stated they had noticed faults in their Barangay, only around a quarter (26%) had reported them as problems that needed fixing. The majority of fault reports (88%) were made in person to the Barangay Captain – often at local residents meetings, which appears to be the current norm for notifying the relevant authorities about local problems and faults. This places considerable responsibility on the Barangay Captain and their support teams, who have to pass on the fault reports to the relevant authorities – in some cases they choose to make repairs themselves. 25/06/2014 3 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT Software tools developed and target users 10.2 Two sets of software tools were developed by the project team in order to establish a low- cost and simple means of collecting street infrastructure data through crowd-sourcing:  FixMyBarangay Message Manager – used to receive and manage SMS text messages from local residents.  FixMyBarangay Barangay web-based data entry tool – used by Barangay teams to input faults reported in-person or over the telephone. 10.3 The FixMyBarangay (www.fixmybarangay.com) system diagram shown in Figure 2-1 illustrates how these street infrastructure data collection and processing activities relate to one another, and how they combine to provide data feeds for the web-based tools that are described later in this chapter. The central component of this system, FixMyBarangay, is an implementation of mySociety’s existing FixMyStreet Open-311 software tool (currently running in the UK as www.fixmystreet.com). Figure 2-1: FixMyBarangay system diagram 25/06/2014 4 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT 10.4 The system illustrated in Figure 2-1 was based on feedback from residents of both Barangay Luz and Basak San Nicolas, which was gathered by the project team through surveys and focus groups during the project inception and delivery planning stage. The notion that people in both Barangays. In particular, Male respondents liked it because it would enable them to report problems anonymously, while female respondents liked it because it was a more efficient way of reporting problems then they currently use (reporting them in person to the Barangay Hall). Survey and focus group respondents unanimously indicated a preparedness to pay for text messages to a ‘FixMyBarangay’ number if they saw action happening as a result of their text messages. “If P1.00 can change our situation, then it’s worth it” Female participant from Barangay Basak San Nicolas 10.5 The remainder of this section describes in-turn each of the software tools developed and their target users. 10.6 FixMyBarangay Message Manager: This web-based tool was developed to provide residents of Barangay Luz and Basak San Nicolas with a means of sending SMS text messages from their mobile ‘phone to report potholes and missing street lights in their neighbourhood. Through the demonstration project, members of the public were encouraged to submit SMS text messages containing fault reports relating to potholes and defective streetlights in their local area. Messages needed to follow a particular string in order for them to be recognised by the SMS Gateway and appear in Message Manager. Table 2-1 demonstrates the format of this message string and provides examples of the types of messages that could be submitted by SMS text. Table 2-1: FixMyBarangay message string Pre-cursor Barangay location tag Information FMB Brgy short code Problem, address, details FMB LUZ Broken streetlight pole #3456 outside Julie’s bakeshop on P Cabantan St FMB BSN Pothole on Katipunan St by the basketball courts 10.7 In reality, no member of the public will be aware that Message Manager exists because it runs in the background of the FixMyBarangay website. As such, the target users for this tool are administrative members of staff working in each participating Barangay Hall. They use the Message Manager tool (via the FixMyBarangay website) to:  Check for new incoming fault report SMS text messages.  Send replies back to people who have submitted fault reports via SMS text (e.g. to clarify the location or nature of a fault report, or to confirm completion of a repair). 10.8 Message Manager is implemented in PHP using the CakePHP framework, which provides a clean admin back-end that is easy to customise, and utilises a Postgres database. It integrates with an HTTP (web-based) SMS gateway procured by the World Bank from a local telecoms provider that handles incoming and outgoing SMS problem reports, and allows Barangay admin staff to create or update existing problem reports displayed on the FixMyBarangay website. 25/06/2014 5 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT 10.9 Message Manager is a standalone software component concerned with making incoming SMS texts available to the other FixMyBarangay components responsible for the presentation of their fault report content. Other than for admin access, there's no need for a front-end for this application, because the FixMyBarangay website accesses it exclusively via an Application Programming Interface (API) which it calls regularly in order to check for newly received messages. Figure 2-2 illustrates Message Manager working within the Barangay admin staff members’ (password protected) section of the FixMyBarangay website to display ‘Problems via Text’. In this context Message Manager runs in the background to queue messages that are being received and sent from within the FixMyBarangay website. Figure 2-2: Message Manager running within FixMyBarangay 10.10 By making calls to Message Manager via the API, the FixMyBarangay software derives the status of a message held within the Message Manager database in order to indicate whether or not the message has yet been associated with a fault report. This ensures that Barangay admin staff members using the FixMyBarangay website know whether or not a message received and displayed in Message Manager has been dealt with. Figure 2-3 shows a fault report displayed in the FixMyBarangay website that has been received via Message Manager and been selected so that it can be utilised in FixMyBarangay – either to be allocated a location on the map, or replied to in order to seek further clarification. By being selected, this message becomes ‘locked’ in the Message Manager database in order to prevent another system user from being able to allocate it to a fault report. 25/06/2014 6 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT Figure 2-3: Selecting a message from Message Manager for action in FixMyBarangay 10.11 Message Manager runs over https in order to provide security for each authenticated session. This means that encryption does not need to be provided by the application itself, and improves the security of processes associated with retrieving and sending SMS text messages from the FixMyBarangay website. Authentication is by username/password which are the same as those used by Barangay admin staff members to log-in to the FixMyBarangay website. The Message Manager admin tool (accessed via: https://message-manager.fixmybarangay.com/users/login) provides the administrators of FixMyBarangay (system administrators at Cebu City Government’s MICS department) with a suite of tools that they can use to manage user accounts and configure different levels of user privilege, based on configurable parameters. Figure 2-4 shows how an administrator can create and manage individual user account privileges based on:  Whether they need admin / manager / SMS text reply / data-entry only access to the Message Manager database of stored SMS text messages.  Whether they are an API user (e.g. a programme using Message Manager) or message sources (different SMS Gateways).  The different Barangay tags that a user can access through the Message Manager API and assign to the FixMyBarangay map of fault reports – these were differentiated for Barangay admin staff in the different areas of Luz and Basak San Nicolas. Admin users were granted access to all tags and those text messages which came in with no tag assigned (e.g. had been incorrectly submitted).  Whether the user is granted permission to reply to text messages received through the SMS Gateway and Message Manager – only Barangay admin staff members and managers required this permission. 25/06/2014 7 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT Figure 2-4: The ‘Users’ admin screen in the Message Manager admin tool 10.12 Message Manager also tracks threads, allowing a series of related messages (messages and their replies, chained) to be retrieved and displayed via the FixMyBarangay website. Figure 2-5 shows an SMS thread displayed in the FixMyBarangay Message Manager view. In technical terms the API provides the following capabilities, and returns the requested data in the JSON format required by the FixMyBarangay website:  Get messages (with limit (i.e., number of messages required), offset, conditions (i.e., query interface).  Get messages by thread ID (either as a list of IDs, or as message data).  Update status of individual message.  Add/remove external data (in this case: FMS report ID(s)).  Given a FMB report ID and a message ID, return true or false depending on whether a message from this phone has already been added to the report (this is required to prevent duplicate messages being registered as separate counts see FMB below).  Session management (i.e. issuing session cookies for login, revoking them for logout). Figure 2-5: A thread of messages displayed in the FMB Message Manager view 10.13 A final aspect of functionality provided by the Message Manager is its ability to provide customisable ‘Boiler-Plate’ responses that can be selected by Barangay admin staff members through the FixMyBarangay website. These pre-defined message strings could 25/06/2014 8 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT be selected to provide a standard response to fault report messages received from members of the public (e.g. Figure 2-6), and could be customised using the Message Manager admin tools (Figure 2-7). Figure 2-6: Using a ‘Boiler-Plate’ reply to respond to a fault report via FMB Figure 2-7: ‘Boiler-Plate’ string editing interface in the Message Manager admin tool 10.14 FixMyBarangay web-based data entry tool: Complementing the Message Manager tools described above, the FixMyBarangay web-based data entry tool is an implementation of the Open-311 FixMyStreet website. It enables members of staff working in each of the Barangays to place problems reported via SMS Text, in person, or over the ‘phone onto a map of their local area. In doing so Barangay admin staff members populate the Maintenance Databases created for each of the repair agencies in Cebu City (DEPW, DPWH, DPS and each participating Barangay’s in-house repair teams). The web-based data entry tool is therefore effectively used to convert ‘raw’ fault report data (from SMS texts, written complaints, emails and in-person reports) into data which can be used by the repair agencies to define and prioritise their response to a reported fault. 10.15 Having selected a ‘problem by text’ that they wish to place on the map (Figure 2-3), a Barangay administrator would simply click on the map location wherever they wish to place it. An icon subsequently appears on the map and a series of forms appear on the left-hand side of the screen. The information from the received SMS text message pre-populates these forms and is editable by the Barangay admin staff member (Figure 2-8). 25/06/2014 9 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT Figure 2-8: Reporting a problem from a received SMS text message 10.16 As well as being able to provide details of the problem, a Barangay admin staff member can additionally:  Categorise the fault report as to whether it is a streetlight or pothole repair, and assign responsibility for fixing the problem to the relevant agency in Cebu City.  Upload a photo of the problem to be attached to the fault report.  Add further text messages to an existing report, which increments the count of messages that apply to this report, and adds each subsequent messages text as an update.  Add the contact details of either the Barangay admin staff member entering the fault, or the person reporting the fault (if they are doing so in person). 10.17 Once completed and submitted, the problem appears on the map of the Barangay, and can be viewed publicly. It also appears in the Maintenance Database of the designated repair agency. When incoming SMS text messages are allocated to a problem on the map, they are subsequently removed from the list of available messages so that they cannot be allocated again (i.e. they have been dealt with). 10.18 For problems reported in person, over the ‘phone, or by email; the Barangay admin staff members have the option to click directly onto the map from the first screen they see after logging into their Barangay’s admin page (Figure 2-9). 25/06/2014 10 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT Figure 2-9: Non-SMS text message based fault reporting using FixMyBarangay 10.19 The approach of requiring Barangay admin staff members to act as an intelligent data entry resource is necessary for the following reasons:  SMS text messages cannot be geo-coded, so this is a necessary step if problems are to be geo-coded and placed on a map.  SMS text messages cannot simply be machine-read and sorted to the appropriate Cebu City government department. As such there is a need for human intervention, and it makes most sense for this to happen at the Barangay level, since the people working at the participating Barangay Halls have the best knowledge of their local area.  It sits comfortably with existing public interaction fault reporting workflows, which rely largely on the Barangay Captain and their support staff. How the software addresses the challenge 10.20 The key components of this specific objective were to develop a low cost and simple means of collecting street infrastructure data. When deployed in combination, the SMS Gateway and Message Manager tools provide a means for real-time, crowd-sourced feed of fault reports to be created in Cebu City. The map-based FixMyBarangay tool is required in order to facilitate the human intervention needed to intelligently filter the incoming SMS- based fault reports, and ensure they are accurately mapped and appropriately assigned to relevant departmental repair teams. The fact that a digital flow of information has been created is significant, and has the potential to remove the need for paper-based logbooks and telephone calls between Barangays and departments (see Figure 2-10). 10.21 At the time of preparing this final report (August 2013), a total of 150 SMS text messages had been received through the Message Manager portal during an implementation period that commenced in March 2013, although a substantial number of these were for system testing and set-up purposes. As well as relatively low uptake in the submission of SMS text message fault reports, few fault reports (6 in total) had been added to the maps by Barangay admin staff using the FixMyBarangay. 25/06/2014 11 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT Figure 2-10: Existing MS Access database and handwritten logbook 10.22 Cost: The cost of collecting street infrastructure repair data using the crowd-sourcing method is low. For members of the public reporting a fault costs the same as a standard SMS text message, which is typically 1 Philippine Peso (a quarter of a cent in USD $ terms). For people with inclusive SMS text messaging bundles, which are common in the Philippines, the cost becomes negligible. Compared with current practices of telephoning the Barangay Hall or Government Department to report a fault, the cost of sending a 1 Peso text message is significantly lower than the 20 – 30 Peso call cost. 10.23 The cost of maintaining the FixMyBarangay software platform is also low, and would ideally be shared by Cebu City Government, participating Barangay Halls and the Government Departments responsible for enacting repairs. If the costs of developing the software tools are written off as World Bank investment, then the total cost of providing the FixMyBarangay data collection platform described in this section is USD $10,200 per annum. This has been itemised in Table 2-2, below, and would be considerably reduced to USD $3,840 per annum if staff time at each Barangay is already being allocated to passing fault reports on to other government departments, and there are already internet connected PCs at the Barangay Hall (as was the case in Luz and Basak San Nicolas in Cebu City). Table 2-2: Breakdown of costs to replicate FixMyBarangay data collection tools Item Cost (USD $) 12 months broadband at 2 x Barangay Halls 17 360 12 months SMS Gateway subscription (unlimited SMS) 18 240 12 months server cloud hosting 19 600 12 month staffing cost at Barangays 20 6,000 12 months technical support (ICT) 21 3,000 Total 22 10,200 17 Assumes USD $15 per month connection at 2 x Barangay Halls 18 Assumes USD $20 per month for unlimited SMS plan and SMS Gateway subscription 19 Assumes USD $50 per month for cloud hosting of FixMyBarangay and Message Manager software tools 20 Assumes 1 x 0.5 Full Time Equivalent staff member at each Barangay at daily rate of USD $20 21 Assumes 1 x ICT professional remotely maintaining FMB server for 0.25 days /month at USD 1,000 per day 22 Assumes that there are already PCs available at the Barangay Hall (as there were in Cebu City) 25/06/2014 12 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT 10.24 Simplicity: For Barangay residents, the time required to submit street infrastructure fault reports by SMS text is considerably lower than making a trip in person to the Barangay Hall. Although in practice, most people will only report problems they are aware of when they are visiting the Barangay Hall for another reason. 10.25 For staff members working at the Barangay Hall, having a single portal that they can use to receive fault reports, and pass them on to the relevant department is also more straightforward than having multiple methods of contact. Although not all fault reports are likely to arrive by SMS text, as observed during the demonstration period for this project, the fact that all fault reports can be entered digitally into the FixMyBarangay software tool (either just by clicking on the map, or by pulling in text messages from the Message Manager tool) makes life easier for staff working at the Barangay Hall. Simply by placing problems onto the map on the FixMyBarangay website, and assigning them appropriate repair responsibility, the problem is passed to the relevant government department’s Maintenance Database and they are alerted to the problem. 10.26 Although no formal evaluation was completed of the time spent by staff at each Barangay dealing with reported faults and passing them on to the relevant department, it is likely that the more streamlined approach facilitated by the FixMyBarangay software would result in labour time savings – freeing up Barangay staff members and volunteers to work on other projects and initiatives. Innovations 10.27 The two key innovations associated with the FixMyBarangay data collection tools were:  SMS submission of fault reports via Message Manager: This is rarely implemented as part of an Open-311 software tool, and was highly appropriate for Cebu City given the highest volume of text messages per capita is sent by people in the Philippines. The creation of the Message Manager software through this project, using open source code, means that this tool can now be readily replicated and implemented in other locations where the submission of faults by SMS may be more appropriate than using web/smartphone based approaches.  Design of software tools around existing local workflows: Considerable time was taken early in this project to understand the fault reporting workflows used in each Barangay, and the most common ways that members of the public report street infrastructure defects. As a result, the project team was able to design the FixMyBarangay interface around these processes in a bid to make them compelling to use and maximise possible time-savings for staff members at each Barangay team. Training and capacity building delivered 10.28 Hands-on, in-person training was delivered by both the project team and the local technical support team from Cebu City Government’s MICS department. Training sessions delivered, and recipients, included: 25/06/2014 13 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT  MICS – explanation of the open source code behind FixMyBarangay, and how to propose changes by making ‘pull requests’ using GitHub.  MICS – familiarisation training with FixMyBarangay and Message Manager software tools covering all points of functionality described earlier in this section, and advice on how to engage and train the Barangay Hall support staff.  Barangay Captains and Secretaries - familiarisation training with FixMyBarangay and Message Manager software tools (delivered by MICS with support from the project team).  Barangay Hall support staff – familiarisation training with FixMyBarangay and Message Manager software tools. All such training was delivered in Cebuano by the local implementation team from Cebu City Government’s MICS department.  Members of the public – instruction at public launch and through small group meetings with Sitio leaders in each Barangay on how to submit fault reports to the FixMyBarangay team via SMS text message. All of these sessions were delivered in Cebuano by the local implementation team from Cebu City Government’s MICS department. 10.29 The purpose of these sessions was to raise awareness of the FixMyBarangay platform among all of the participating stakeholders, but also to build capacity among the local delivery teams (MICS, Barangay Halls, local and national Government Departments) in order to ensure they had the necessary skills to use the software platform created by the project team. Figure 2-11: FixMyBarangay training sessions in Cebu City 25/06/2014 14 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT Use collected data to more effectively plan and manage repairs Planning and managing road and street light repairs in Cebu City is challenging because of the lack of consistent data, as well as the scarcity of materials available to make good repairs. DEPW staff members explained how, following an audit of a reported road defect, a multi-stage workflow begins (see diagram below). This typically sees information about the fault transferred from hand-written to digital databases, reviewed by the Chief Engineer for the City’s roads, assigned to and accepted by an Engineer, audited, reported upon, reviewed again by the Chief Engineer, then prioritised for repair. This workflow, below, typically takes 8-12 weeks to complete before a repair is prioritised: 1) Receipt of complaint: 2) Issue sheet created 3) Review by Chief Engineer 4) Logbook and Access Admin team receives Complaint is recorded in an DEPW’s Chief Engineer, or Asst. dbase updated road defect/drainage issue sheet and forwarded Chief Engineer reviews issue Admin staff receive updated complaint by for review to the Chief / sheet and delegates initial issue sheet, update logbook telephone/in writing Assistant Chief Engineer inspection task to an and MS Access database with appropriate colleague tasking from Chief Engineer 8) Action taken 7) City Engineer reviews 6) Audit is undertaken 5) Logbook signed by Either a repair is initiated report Assigned engineer audits the assigned Engineer based on DEPW report, DEPW’s Chief Engineer reported problem to quantify The assigned engineer signs or additional funds are reviews colleague’s report the costs associated with the handwritten logbook to sought from the Mayor’s and determines whether making a repair and prepares a acknowledge receipt of Office to fund the repair funds are available for repair written report for Chief Engr. responsibility for an issue Small repairs are typically dealt with straight away, while more expensive repairs require an application to the Mayor’s Office for funding. As well as scarce budgets (Cebu City Government provides DEPW with a total annual budget of P60 million, and about P10million of this is set aside for patching potholes each year, with a rough cost of P1,200 per square meter of asphalt required to completed pothole repairs), the variable availability of asphalt and replacement streetlight bulbs means that repairs often need to be prioritised before they can be completed. The procurement of materials needed to make highway repairs is ad-hoc, and it can take 4 months to obtain supplies. DEPW and DPWH repair teams often share cold and hot-mix asphalt when it is available in a bid to fix as many known problems as possible within a short space of time. Street repairs also require planning around the wet season, since the fierce rains traditionally experienced from June to October quickly wash away cold mix asphalt repairs. The Chief Engineers at DEPW and DPWH noted that obtaining sufficient budget to make lasting repairs to road surfaces is a challenge. Software tools developed and target users 10.30 In order to address this challenge the project team worked closely with the staff at the three Government Departments responsible for managing repairs (DEPW, DPWH and DPS – the main target users for the software tools), repair teams at the two participating Barangays (Luz and Basak San Nicolas) and the MICS local delivery team in order to create a series of FixMyBarangay Maintenance Databases. These SQL databases were designed to be accessed via a password protected log-in through a web-browser, and were standardised across all of the government departments in order to make it easy for MICS’ local delivery team to host and maintain these databases on their own server – rather than necessarily having to rely on cloud hosting. 25/06/2014 15 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT 10.31 The SQL databases for each repair team were effectively the end-points to which fault reports managed by the Barangay Hall staff members were sent. This process happened when a member of staff in the Barangay Hall used the FixMyBarangay tool to place a reported problem onto the map of their local area, and assigned responsibility to the relevant department. Once submitted, the fault was transmitted through the Open-311 server infrastructure underpinning FixMyBarangay to the relevant repair teams ‘Endpoint’ database. 10.32 Figure 2-12 illustrates the main view of the DEPW’s maintenance database. This view shows a number of items of information relating to each reported fault including:  The current status of each fault - as specified by staff at DEPW.  The date the fault was reported and the type of fault it is. In the case of DEPW all are potholes on city roads, because this is what they repair.  The FixMyBarangay ID, which links to a map view of the fault’s location (Figure 2-14)  A link to any media (e.g. a photo, or CAD plan) of the problem, a description and address of the fault. Figure 2-12: DEPW’s fault report maintenance database 10.33 Staff members at each government department’s repair team can log-in and use this interface in order to review and prioritise reported faults in the way that they currently do when updating their MS Access and Excel databases. The advantage of this approach is that each team member can see, in real-time, what their colleagues are working on; and use it to task engineers to go and make an inspection or prepare a report in the way that they currently do. 10.34 Furthermore, the administrative staff members who handle calls and in-person fault reports from members of the public/local Councillors can also add problem reports to the database using the same tool. In doing so they can augment the information that is being pushed through to them by colleagues at the Barangay Hall, and keep track of all the reported faults relevant to their organisation in a single online database. By clicking on the ‘edit problem’ button to the right-hand side of this view, staff members at DEPW are able to edit 25/06/2014 16 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT all of the fields available. Figure 2-13 shows how a team member might edit the status of a reported problem once it has been fixed by their repair team. Prioritisation, further investigation, and reporting on the materials needed to affect a repair could all be completed through this ‘edit problem’ view. Figure 2-13: Edit problem report view in the DEPW Maintenance Database tool Figure 2-14: Viewing a problem on FixMyBarangay from within Maintenance Dbase 25/06/2014 17 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT 10.35 As well as being able to view individual fault reports on a map – to help locate them for inspection or repair (Figure 2-14) – the staff at the repair team can view all of the open problems assigned to their team by clicking on the ‘“Department Name” on FixMyBarangay’ button which is displayed on the bottom left-hand side of every page in the Maintenance database. Selecting this view loads a FixMyBarangay map window such as that shown in Figure 2-15, and each individual problem can be clicked upon in order to open the individual fault report view illustrated in Figure 2-14. Figure 2-15: Map view of all reported faults for DPS to repair 10.36 Any change made by the repair teams to the ‘Status’ of faults logged in their maintenance database results in this information being returned to the FixMyBarangay database through its Open-311 server API. For example, when a fault is reported as ‘Fixed’ by the relevant repair team, the yellow flags displayed on the FixMyBarangay map view turn green and contain additional text that states ‘Problem Fixed’. The value of this is that any changes the repair teams make to the status of reported problems (e.g. scheduled for inspection) is fed back to the Barangay teams and any member of the public using the read-only version of FixMyBarangay which is described in the next section of this Chapter. 10.37 Other features of the repair team’s maintenance databases include:  An MS Excel CSV export for analysis purposes, which provides the following fields of information: report_id, status, status_notes, priority, category_id, description, agency_responsible, service_notice, token, source_client, external_id, requested_datetime, updated_datetime , expected_datetime, address, address_id, postal_code, lat, long, email, device_id, account_id, first_name, last_name , phone, media_url, engineer.  The ability to review the fault categories assigned to the repair team by Cebu City Government’s MICS (local delivery) team – which has been included to facilitate future expansion of the fault report topics either in Cebu City, or other locations. 25/06/2014 18 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT  An ‘Updates’ view, which enables the repair team to see the most recent updates to fault reports. This can be useful when checking on the progress of engineers with making repairs, or for additional information from staff at the Barangay Hall. This is also what FixMyBarangay polls to determine if the status of any reports has changed – with the changes being fed back into the FixMyBarangay website. How the software addresses the challenge 10.38 The Maintenance Databases created through the demonstration project for each of the participating repair teams in Cebu City provides them with an integrated, digitised means of managing identified street infrastructure faults and effecting repairs in a timely manner. Although no formal evaluation was completed to determine the time spent by staff at each repair team dealing with reported faults, inspecting them and determining the appropriate repair, it is likely that the more streamlined approach facilitated by the Maintenance Database software would result in labour time savings – freeing up government and Barangay staff members to fix a greater number of problems. 10.39 Identified advantages of using the Maintenance Database tools include:  Because the databases are all connected to each other, via the FixMyBarangay Open- 311 server, the effort associated with identifying faults, managing fault reports, and planning repairs is effectively shared between the departments, members of the public and staff members working at each of the two Barangay Halls. This complements existing, time-consuming proactive audit-based approaches to identifying faults, and the tools can be used to record identified problems in this way.  Having been designed around the existing fault report management and repair workflows of the various participating agencies, the Maintenance Database software tools present an opportunity for these teams to gradually migrate their existing paper- based and multi-database practices to a connected digitised system.  The cycle of time taken to identify street infrastructure faults; correctly transfer responsibility to the appropriate repair team; review, inspect and prioritise the fault for a repair; should be reduced considerably from the 8-12 weeks that it takes using existing methods to around 2-3 weeks – roughly a quarter of the time.  Repair teams have an opportunity and a communication channel with which they can manage public expectations when there are no raw materials available, or the climatic conditions are wrong, to enable repairs to be undertaken. Communicating via the FixMyBarangay website enables the Cebu City Government departments to manage expectation on a one-to-many basis, rather than current approaches which only allow for one-to-one updates via the ‘phone, email, text or in-person.  The MS Excel CSV export function provides each Departments Chief Engineer with scope to more-accurately track the number of reported street infrastructure faults and defects that are being reported and repaired over time. As such, the FixMyBarangay tools create an evidence base that can be used to more accurately determine annual budget requirements that take into account previous year’s fault reporting levels and the materials used to repair them. 25/06/2014 19 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT  That tools could potentially be used by Cebu City Government’s Mayor’s Office to provide a form of oversight that ensures budgets allocated for repairs are being spent efficiently by each Department. 10.40 If up-front software development costs are discounted as World Bank investment in the FixMyBarangay and Maintenance Database platform, then the annual cost of implementing the Maintenance Database software tools in Cebu City through this demonstration project is USD $19,500 per annum. This has been itemised in Table 2-3, below, but would be substantially reduced to USD $3,600 per annum if staff time at each government department and Barangay repair team is already being allocated to managing fault reports and planning a response, and there are already internet connected PCs at each organisation (as was the case in Cebu City). Table 2-3: Breakdown of costs to replicate Maintenance Database tools Item Cost (USD $) 12 months broadband at 5 x repair team offices 23 900 12 months server cloud hosting 24 600 12 month staffing cost to use software tools in repair team offices 25 15,000 12 months technical support (ICT) 26 3,000 Total 27 19,500 Innovations 10.41 The following innovations were delivered through the project and local delivery team’s implementation of the Database Maintenance tools:  All of the software tools were designed to work well in environments with limited data connectivity, such as Cebu City. In particular, this involved ensuring that the FixMyBarangay Open-311 server would continue to operate unaffected in the event that local endpoint databases connected to it become temporarily disconnected (e.g. due to limited internet connectivity in some government departments). The FixMyBarangay server was therefore designed to be hosted ‘in the cloud’ and therefore always accessible, so that each Maintenance Database could ‘drop in and out’ of connectivity – with all data being pushed between the two as, and when a connection was available – as required.  The use of simple databases to complement/replicate/replace existing paper-based methods of managing faults in Cebu City was an innovation specific to this deployment. It will make the process of transition from existing practices to the use of connected database as simple as possible to complete. 23 Assumes USD $15 per month connection at 5 x repair team office locations 24 Assumes USD $50 per month for cloud hosting of Maintenance Database software tools 25 Assumes 1 x 0.5 Full Time Equivalent staff member at each repair team at daily rate of USD $20 26 Assumes 1 x ICT professional remotely maintaining FMB server for 0.25 days/month at USD 1,000 per day 27 Assumes that there are already PCs available at all repair teams (as there were in Cebu City) 25/06/2014 20 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT  The two-way communication between FixMyBarangay – the tools used by Barangay staff and members of the public – and the Maintenance (endpoint) databases represents an innovative use of Open-311 Simple database architecture. This facilitates the updating of the status of fault reports in FixMyBarangay when changes are made to the endpoint databases. Training and capacity building delivered 10.42 The majority of the training and capacity building delivered to the repair teams at each of the government departments (DEPW, DPWH and DPS), and the Barangay Hall repair teams (Basak San Nicolas and Luz) was delivered in-person by Cebu City Government’s local delivery team from MICS. The reasons for adopting this approach were two-fold:  Local language speaking skills were essential in order to ensure the repair teams understood the Maintenance Database software applications, how they worked, and their role in the project.  The project team was working with MICS to build in-house skills and capacity in order to ensure they were able to support the project going forward, and handle technical questions posed by their colleagues in other Government departments. 10.43 The project team mentored the MICS team through this process, and provided a range of materials to support the process, including:  A template presentation for re-use/customisation when delivering training/familiarisation with point people at each repair team, and their Chief Engineer (See Appendix A).  A Pledge of Commitment signed by each Department Head committing staff resources and raw materials to ensure the aims of the project were met (Appendix B).  The story of a pothole ‘crib-sheet’ depicted in Figure 2-16, below. 25/06/2014 21 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT Figure 2-16: Story of a pothole in Cebu City – training materials created for MICS 25/06/2014 22 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT Establish an information platform to support public participation in transport system and network development Around 74% of Barangay Luz and Basak San Nicolas residents surveyed early in this project indicated that they observed street infrastructure problems in their local area, but did not report them. Slow response rates from the organisations responsible for fixing reported faults, and their relatively low priority alongside other local issues (crime, drugs, drainage), meant that relatively few people saw the value of reporting problems they observed. Even so, compared to other societies, this represents a relatively high level of public participation – with members of the community actively involved in reporting local problems to their Barangay captain/secretary, who in turn pass them on to a local government department or ensure the problem is fixed by staff working for the Barangay. Writing to many different organisations; including DEPW, local Councillors and the Mayor’s Office; when reporting faults is perceived to be an effective strategy for getting important problems repaired. Intervention by the mayor and councillors usually results in a swift response from staff at local Government departments and helps to ensure the commitment of discretionary funds from the Mayor’s central budget needed to fund necessary repairs. One challenge for public participation in Cebu City is therefore that it is not always well directed, or coordinated. A lack of mapping resources at the departments responsible for maintaining the city’s highway networks (MICS has central responsibility for maintaining and updating GIS maps, which happens on an ad-hoc basis) means that engineers and draughtsmen tend to use autocad software to draw road maps and record defect locations. This, and a lack of public comprehension of map-based information, makes it difficult to visualise reported/known problems on local highway networks. This, in-turn, makes it hard for members of local communities in Cebu City to see which problems have already been reported and acknowledged by the department responsible for enacting a repair. As a result, it is common for multiple departments to learn about the same problem from a variety of different sources. Software tools developed and target users 10.44 The project team’s development of the FixMyBarangay platform placed heavy emphasis on public participation throughout the demonstration project. The main software deliverable from the perspective of members of the public is the publicly accessible FixMyBarangay website (www.fixmybarangay.com). This website is open for anyone to use and provides a read-only view of all reported faults in each of the Barangays that participated in the demonstration project. Figure 2-17, overleaf, depicts the FixMyBarangay homepage, from which members of the public can:  Learn how to submit fault reports via SMS text, or in-person at their Barangay Hall.  Click on one of the participating Barangay links in order to view all of the problems in their area (see Figure 2-18, overleaf). 25/06/2014 23 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT Figure 2-17: FixMyBarangay homepage Figure 2-18: All reported problems in Barangay Luz 10.45 The public website therefore provides Barangay residents with an opportunity to see what faults have been reported in their local area, and to explore them in more detail. By clicking on one of the flags on the map in Figure 2-18, a member of the public can navigate through to more detailed, publicly available information about the nature of a reported problem and the status of its repair (see Figure 2-19). 10.46 The map view shown in Figure 2-18 can also be printed out (using standard browser tools) by the Barangay team and placed on local noticeboards in order to demonstrate the effectiveness of the local community’s fault reporting efforts. 25/06/2014 24 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT Figure 2-19: Detailed public problem report displayed through FixMyBarangay How the software addresses the challenge 10.47 The public FixMyBarangay website created through the demonstration project is a completely new way of visualising reported problems, and is significantly quicker to create maps of reported issues when compared with existing hand-drawn maps that are commonly displayed in Barangay Halls (see right). The cost of the public FixMyBarangay website is covered through the delivery of the data collection tools described earlier in this chapter and, as such, represents an added-value deliverable resulting from establishing this crowd-sourced approach to identifying street infrastructure problems in the Barangays of Cebu City. 10.48 As well as being cost-effective, the website provides members of the local community with an opportunity to visualise, on-demand, the range of issues that exist in their local area. Making this information publicly available, as it now is in Cebu City, presents an opportunity for local members of the community to participate in public debate about the prioritisation of repairs in their area. It can also help local community members to understand reasons for delays in making improvements or repairs – because the teams responsible for making these repairs can use the information embedded into the public map as a communication and expectation management tool. 25/06/2014 25 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT Innovations 10.49 The concept of mapping local problems is not particularly innovative itself, but the technique of leveraging crowd-sourced information (in this case submitted via SMS text) and then making it available for multiple purposes – including for public consumption – is innovative in the Philippines. A particular technology innovation related to the public map view is the use of live OpenStreetMap tiles. The base-map tiles used on the FixMyBarangay website are derived from the OpenStreetMap (OSM) – the open source, editable map of the world – which means that the maps are not static, and can continue to be updated by the local OSM community in response to changes in the built environment. Drawing on these map tiles is innovative in Cebu City for two reasons:  The rapidly changing urban form of Cebu is likely to continue being updated by the local OSM community, so the maps will remain constant with minimal effort from the local community.  No local government mapping resources are required – the local community owns the map and can edit it themselves. The use of OSM, and its accessible online map- editing tools such as iD, means that the maps can be maintained locally without the need for specialised and expensive GIS software packages, and limited map-editing skills. Training and capacity building delivered 10.50 The project team’s focus on public participation extended to the training and capacity building delivered through the course of the demonstration project. Activities we delivered include:  Community street-mapping using walking papers with volunteers from the local communities of Barangay Luz and Basak San Nicolas. The purpose of each half-day event was practical – we needed to map the locations of Sitio pathways into OSM in order that they could be used as a point of reference by Barangay Hall staff members when placing fault reports onto the FixMyBarangay map. Rather than just complete the exercise ourselves, we chose to involve the local community in the process – introducing them to the concept of OpenStreetMap through the use of walking papers, basic GPS devices, the Java OSM (JOSM) editing tool, and the OpenStreetMap website. Further information about the process we adopted can be found in the guide to street mapping in unplanned communities we prepared as an output (Appendix C). Figure 2-20: Community street-mapping in Cebu City 25/06/2014 26 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT  Support to MICS and Barangay staff with public launch events which included running poster design competitions in each Barangay. Local youth groups were engaged by MICS – through the Barangay Secretaries – who were challenged to design a poster to raise awareness of the FixMyBarangay tools, and the fact that problems could now be reported via text. The winning design was chosen by the Head of MICS and the head of CITOM and the posters were printed and distributed in both Basak San Nicolas and Barangay Luz (See Figure 2-21). Different coloured T-shirts bearing the FixMyBarangay logo and instructions on how to report pot holes and street lights were also printed and distributed to the Barangay staff members involved in the project, and the MICS delivery team. Figure 2-21: FixMyBarangay launch event poster competition and winner  Mainly for fun, but also to ensure the launch events attracted maximum local publicity, we filmed ‘Harlem Shake’ FixMyBarangay public launch videos in Basak San Nicolas and Barangay Luz. The purpose of the videos – both filmed in the participating Barangay Halls – was to increase local awareness of the initiative, and emphasise the high level of community engagement behind the FixMyBarangay project. 25/06/2014 27 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT 11 THE VALUE OF OPEN-311 AND OPEN SOURCE SOFTWARE DEVELOPMENT 11.1 This chapter describes the Open-311 standard in non-technical terms, and considers how the use of open source software is beneficial to projects like FixMyBarangay. It's important to note that this is explicitly different from using proprietary software: the key distinction is that modification to the software, whether it be to refine (bug fixes) or enhance (new features), can be performed by developers both inside and outside the government departments who may be using the software. Furthermore, the nature of open source development is that changes made to the code by developers unrelated to the local installation can nonetheless benefit all users of the software. Open-311 11.2 FixMyBarangay communicates with the Cebu authorities using the Open-311 standard. This has a number of benefits:  It is already an established and proven way of handling civic reports.  It is technologically simple (using simple HTTP POST or GET requests, in the same way as a web form) and basic XML (or, optionally, JSON) to pass structured data.  It prevents lock-in - systems that use custom or proprietary methods of integration are expensive to modify and can be very expensive to leave, because the integration cannot be reused.  Conversely, it encourages others to integrate - because it's an open standard, any number of different clients can use it to connect to the back end without needing any more development. About the Open-311 standard 11.3 Open-311 takes its name from the 311 (telephone) number used in the USA for reporting non-urgent faults, which are typically remedied by services provided by the local councils. Typical examples are road repairs (potholes, broken signage, or faulty traffic lights), damaged public property (vandalism or graffiti), or rubbish collection (littering or fly-tipping). 11.4 Open-311 is a collaborative model and open standard for civic issue tracking. It is facilitated by OpenPlans, a New York based non-profit dedicated to making cities work better. Open-311 was created to address the common problem of submitting problem reports to bodies such as the municipal departments that keep cities running. Many authorities are turning to online fault reporting because it is significantly cheaper than the alternative that it is replacing, namely person-to-person reporting (typically through a telephone contact centre or help line). Every time such a system is implemented, it has to overcome the problem of how the report can be consumed by the server. Open-311 attempts to resolve this by providing a simple and clear standard web interface so that such integration can be handled in the same way regardless of the underlying technology (language or platform) or manufacturer. The FixMyBarangay Open-311 Implementation 11.5 The FixMyBarangay website operates as an Open-311 client, and each departmental fault report maintenance database runs as an Open-311 server. Specifically, FixMyBarangay implements the required parts of the Open-311 specification defined as GeoReport v2. The 25/06/2014 28 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT departmental endpoints are based on the PHP implementation of an Open-311 server written by Philip Ashlock whilst working on Civic Commons. 11.6 A benefit of using Open-311 for FixMyBarangay is that the FixMyStreet platform already supports it, and it allows the Maintenance Database endpoints to be easily replaced in future with any other back-end solution that also implements it. It also means that other reporting mechanisms -- whether these be written for internal, departmental use, or are external third-party services -- can easily be added. 11.7 mySociety, which supports the Open-311 standard, presented a simple overview of how it works in the blog post entitled Open-311 explained. FixMyBarangay implements an extension of the Open-311 standard, which allows a status update (for example, a pothole marked as fixed in the departmental fault repair database) to propagate back to the FixMyBarangay website. The Open-311 Georeport v2 specification doesn't quite provide this functionality. Open-311 around the world 11.8 Adoption of Open-311 is largely driven from the server-side, because the cost benefit is most significant, and most urgent, from the point of view of the authorities that are receiving the reports. Early adopters are therefore government departments that implement their own webservices; next to follow are the third-party vendors who supply such systems to government departments. Some of the larger suppliers sometimes appear slow or outright reluctant to implement open standards, because their business model to some extent depends on lock-in or the charges that can be made for custom integration work. We do not approve of this approach, and believe that in the long term Open-311, and standards like it in other fields, will inevitably become widespread. 11.9 Open-311 is most widely adopted in the USA, partly because it was initiated there. Cities using Open-311 now include Chicago, Toronto, Bonn, and Helsinki. Although these are all places who are changing their existing infrastructure in order to benefit from Open-311 in the future, the standard is particularly well-suited for new systems (that is, places that do not yet have an established back-end infrastructure) because it prevents lock-in to a single proprietary solution. 11.10 Currently, a number of project attempt to track the spread of Open-311 around the world. One example is a world map of Open-311 instances. The Open-311 site itself monitors some of the endpoints worldwide. The GNU General Public License 11.11 The GNU General Public License (GNU GPL, or GPL) is the most widely used free software license, which guarantees end users (individuals, organizations, companies) the freedoms to use, study, share (copy), and modify the software. The GPL is a copyleft license, which means that derived works can only be distributed under the same license terms. 11.12 In effect this ensures that the effort expended in writing the software is always protected, because cumulative changes (presumably improvements) to the code remain available to all parties using it. It also encourages developers who want to adopt or customise the software for their particular, local requirements to do so. 25/06/2014 29 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT 11.13 One practical consequence of this is that it encourages developers working on installations of the FixMyStreet platform to feed their new features or improvements back into the core code. In fact, mySociety makes the FixMyStreet platform available via github (see below), which makes it easy for developers to submit such customisations or features as "pull requests". As the FixMyStreet platform is still in active development, the FixMyBarangay project has already benefitted from this practice. Documentation and management of software code using Github 11.14 The FixMyStreet platform, Mapit (the component that handles adminstrative boundaries), Message Manager, and FMS Endpoint (the Maintenance Database websites) are all managed using git, a popular distributed source code control system. The code is available on github, which makes it easy to download, inspect the source code and its detailed history, and report issues and even submit changes. 11.15 Github also facilitates documentation, so each of these projects contains technical documentation that is presented on a variety of ways. The most complete example is the FixMyStreet platform (FixMyBarangay is technically a cobranded instance of the FixMyStreet code). mySociety supports an active community of people running, installing, or coding on the FixMyStreet platform: the documentation is centred around code.fixmystreet.com – which is actually an example of github pages, presented as a website. 11.16 The Message Manager software runs with extensive help documentation available to logged-in users (this is part of the installation, and is served as web pages within it). There is also technical documentation in the repository. 11.17 Github supports "issues", which is effectively a ticketing system for reporting and monitoring bug reports, feature requests, or any other changes. mySociety's own developers use the github issues extensively. This allows anyone to monitor the progress of changes and improvements to the code. Ease of replication in other locations 11.18 The setup for FixMyBarangay is fundamentally a regular FixMyStreet installation running as a cobrand (which is configured at setup), as well as the Message Manager, which handles the SMS text messages and makes them available to the FixMyBarangay website. FixMyBarangay also uses mySociety's Mapit service, which in Cebu's case is a separate installation. 11.19 Installation documentation for all these projects is available both as part of the respective repositories and also via the FixMyStreet community. 11.20 Github makes download of the repository (that is, the entire code base and the resources such as images and some libraries) straightforward. It's possible to download the software as a .ZIP package and deploy it, although if local technical capability supports it, it's better to clone the git repository. This just means that the local installation is managed through the same git source code control as the repository on github (effectively, git does the unzipping for you), and furthermore is aware of that relationship; this makes it easy to update the local installation with the latest version of the software after it has been deployed. 25/06/2014 30 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT 11.21 FixMyStreet implementations have been deployed around the world. The document "Can we fix it" describes the issues which should be considered -- both technical and non- technical -- before embarking on such an endeavour. 11.22 The Message Manager software is comparatively easy to install, because it is a straightforward PHP (Cake) web application. Integrating it with the FixMyStreet software is documented (for example, Notes on FMS config. Finally, integration with the local SMS gateway is likely to vary from country to country, but Message Manager offers two mechanisms for this by way of examples. One is to accept POST requests from the gateway whenever a new message is received, the other is to poll the gateway asking for new messages at regular intervals (which, incidentally, is how the gateway in Cebu behaves). 11.23 Mapit is the webservice which the FixMyStreet platform uses to determine which authorities within its database are responsible for problems at a given location (that is, a point specified by latitude and longitude coordinates). This too can be easily installed (the software is available, and fully documented, at [http://global.mapit.mysociety.org](http://global.mapit.mysociety.org). In fact, if the boundary data needed for a particular installation is already available within Open Street Map, then it may be possible to use mySociety's existing Mapit installation -- that is, installation of a new Mapit installation is not always required. Opportunity for further customisation and enhancement of software tools 11.24 The FixMyStreet platform has been under active development for several years – mainly, but not only, by coders working for mySociety. FixMyBarangay is a cobrand of FixMyStreet, which means it's running the same core software as other installations, but the presentation and some behaviour is enabled (for example, the FixMyBarangay branding, and the use of Message Manager), while other behaviour is switched off (for example, FixMyBarangay currently does not allow non-staff users to submit reports online). This conditional behaviour is handled by the cobrand mechanism, and it is this which allows the software to be updated with new features without breaking existing implementations. 11.25 The software that runs the Maintenance Database websites (FMS Endpoint) already has basic customisation built-in, but can also benefit from additional features being added. As part of the FixMyBarangay project, MICS developers made a small change to the FMS Endpoint code and added it to the repository, in order to demonstrate that such customisation could be made. 11.26 FMS Endpoint is written in PHP and uses the mySQL database. This was an original requirement, because these were technologies with which the MICS development team were most familiar. The FixMyStreet platform is written mostly in Perl, and uses a PostgreSQL database. All these are free technologies - that is, there is no dependency on proprietary or paid-for license software in order to run the software comprising FixMyBarangay. 11.27 The FMS Endpoint which was provided for the departments, is a relatively basic database made accessible through a web interface. This can easily be substituted with another fault management database. Because the FixMyStreet platform operates as an Open-311 client, any Open-311 compliant back-end could be used with little or no modification to the 25/06/2014 31 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT existing FixMyStreet code. Alternatively, it is possible to add custom integration – such as proprietary enterprise software applications used by some city authorities. But in situations where such databases are not required, it's entirely feasible to run FixMyStreet with Message Manager using only email addresses as the departmental endpoints instead. This is all helpful when considering that sometimes the public-facing fault reporting website may be sending its reports to departments that already have some back-end system already in place. 11.28 The open nature of the software, and its ready availability on Github, means it's relatively easy for competent developers to add or customise any parts of the FixMyBarangay system to their own requirements. Furthermore, by feeding these changes back via pull requests, such work can (and typically does) offer benefits to everyone who is using the same core code in their local installations. 25/06/2014 32 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT 12 APPROACH TO ENGAGING A LOCAL ‘CROWD’ 12.1 In order to support Cebu City Government’s MICS team with their delivery of the launch of the FixMyBarangay software tools, and to maximise its potential outreach, the project team prepared a Crowd Engagement Strategy. This document has been included in Appendix D to this report so that it may serve as a template for any city authority wishing to replicate a FixMyBarangay initiative in their area. This Chapter briefly summarises of the key tasks undertaken in each phase of the project (pre-launch, launch, and post-launch) in order to reflect on what worked well, and what could be delivered differently if the project were being replicated elsewhere. Pre-launch 12.2 Pre-launch engagement included all of the initial meetings that the project team and MICS representatives undertook with Barangay Captains and Secretaries, surveys and focus groups with Barangay residents, informal contact with the local civil society column in the Cebu Daily Newspaper and the community-led Barangay Street Mapping activity that was delivered in conjunction with Cebu's OpenStreetMap community of contributors, Barangay Councils and volunteer groups. These pre-launch activities ramped-up as the March 2013 launch of FixMyBarangay drew closer and included the delivery of updated Barangay maps and GIS data following the OSM street-mapping parties, the delivery of hands-on training for Barangay staff and system testing activities, a competition for the design of the FixMyBarangay promo posters, a soft launch and further training for Barangay staff, DEPW, DPWH & DPS staff alongside system testing activities, meetings with Sitio leaders and Barangay volunteers to demonstrate the FixMyBarangay SMS text reporting tool and web interfaces and the final design, printing and distribution of posters to promote the launch of FixMyBarangay. What worked well? 12.3 The most successful aspects of the FixMyBarangay pre-launch strategy, which we would recommend are repeated in any location where FixMyBarangay is launched have been listed below, along with reasons why:  Early meetings with the Barangay Captain and their support staff – this was critical to securing the participation of the local communities in the demonstration project.  Community street-mapping task – this raised awareness of the project with a large number of Barangay Hall staff members and volunteers, improved their knowledge of maps and spatial information, and updated the OpenStreetMap tiles that were needed to enhance the FixMyBarangay tool’s deployment in Cebu City.  Poster competition with local youth groups – this was effective at both securing the involvement of young people in the area, and developing an eye catching 25/06/2014 33 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT poster that was displayed in the Barangay Hall and other local community areas. What could be improved upon? 12.4 If we were to repeat the process of launching an instance of FixMyBarangay in another location, we would change the way we undertook the following activities:  Hands-on training and system-testing – with hindsight the project team’s focus was probably centred too greatly on the Barangay Captain and Secretary, rather than a wider team of staff/volunteers within each of the participating Barangays. While we envisaged that the Barangay Secretaries would ultimately take responsibility for passing on their knowledge of how to use the FixMyBarangay and Message Manager software tools to their colleagues they ultimately did not have time. As a result, the local delivery team from MICS had to make several refresher training trips back to each Barangay Hall during, and following, the launch of FixMyBarangay to liaise with different individuals on a one-to-one basis.  Soft-launch – a combination of the issue highlighted above with regard to staff training not being relayed as anticipated, and delays to the software development timeline (as a result of the third-party provided HTTP SMS Gateway), meant that the soft launch only took place 6 weeks before the full public launch. As a result neither the Barangay staff members or participating repair teams at local and national Government Departments really had sufficient time to test the process of submitting, managing, and responding to identified street infrastructure problems. Were we to repeat the project we would allow more time between the soft launch and full public launch to allow for this to happen. Launch 12.5 The launch of FixMyBarangay took place in both Barangays in March 2013 and this demanded a significant amount of initial effort to promote the launch of FixMyBarangay in Basak San Nicolas and Luz, as well as publicising any early achievements (e.g. in terms of reported problems being fixed) which can be attributed to the inception of FixMyBarangay. The main tasks associated with the launch of FixMyBarangay involved: putting up posters around the Barangay and in the Barangay Halls; circulating press releases to local radio, TV and newspaper media; word of mouth and social media (Facebook and Twitter) campaigns to promote the service; further deliver of community group training on how to text problems to the FixMyBarangay team at the Barangay; the publication of monthly reports raising awareness of the number of problems reported and fixed as a result of FixMyBarangay; recognising the most prolific contributors to FixMyBarangay through small awards; and prompting people who haven’t contributed for a while/at all. 25/06/2014 34 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT What worked well? 12.6 The most successful aspects of the FixMyBarangay launch strategy, which we would recommend are repeated in any location where FixMyBarangay were:  Posters – putting the winning posters up around the Barangay raised a significant amount of interest in FixMyBarangay, with the Barangay Captain and Secretary reporting that a number of residents stopped them in the street to ask what the service was for, and how they could use it.  Media involvement – involving the city authority’s media in the launch event meant that it presented an opportunity for the Mayor and Barangay Councillors to attend the launch event and appear in print alongside the project logo. This helped to spread the initial message about FixMyBarangay widely, and ensured good coverage via local TV, radio and print news.  Initial use of social media and Sitio groups – using the Facebook pages of the Barangay Captain, Secretary and Barangay Hall page was an effective way of making ICT-savvy Barangay residents aware of FixMyBarangay. The large turnout for each Barangay’s launch events was largely secured through Facebook communication, and by word of mouth from the Sitio Leaders within each Barangay. What could be improved upon? 12.7 If we were to repeat the process of launching an instance of FixMyBarangay in another location, we would deliver the following activities differently:  Launch-day and immediate follow-up training – Time constraints on the day, and the large turnout at each of the FixMyBarangay launch events meant that it was not possible to coherently deliver the level of hands-on training that we had planned. This was a significant missed opportunity, because significant numbers of Barangay residents were present at the launch. Ideally, we would have liked to have spent more time with smaller groups of Barangay residents in each location to ensure they had fully understood the process of submitting problem reports by SMS text. We would then have liked to have followed-up in greater detail with the Barangay staff members to ensure they had fully grasped the workflow for checking incoming SMS text messages and placing them onto the FixMyBarangay map so that they are assigned to the relevant repair team. Not being able to do this as effectively as we had hoped may partly explain the relatively low uptake in the initial few months of the FixMyBarangay tool’s launch in Cebu City.  Lack of sustained effort around other post-launch activities – the timing of the FixMyBarangay launch meant that it fell just as Cebu City was approaching the hottest months of the dry season. A combination of a local election, school holiday time and 25/06/2014 35 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT staff absence in the MICS delivery team meant that immediate follow-up (monthly reports and awards) did not happen. This could have helped to incentivise a greater level of initial SMS fault reporting, which in-turn would have created healthy pressure for the Barangay staff and participating government department’s repair teams. Post-launch and on-going support 12.8 The crowd-engagement strategy in Appendix D assumed that post-launch engagement would focus on rolling-out the FixMyBarangay tools to a wider number of Barangays, and expanding the range of issues covered by the existing FixMyBarangay platform (e.g. beyond potholes and broken streetlights). Given the relatively low-level of uptake in FixMyBarangay during the first 4 full months of it being available (April – July 2013) these proposed approaches have been covered in Chapter 5 (Sustainability and Scaling up). 12.9 An alternative set of post-launch priorities and actions were agreed between the Project Team and MICS’ local delivery team at a final project meeting in June 2013, which include:  Making regular, fortnightly, texts and calls to the Barangay Secretaries to see how they are progressing with their adoption of FixMyBarangay. Suggest to the Barangay captain and secretary that they send text messages to FixMyBarangay so that their colleagues can deal with following-up the problems on their behalf.  Providing further follow-up map training to small teams in each Barangay whose responsibility it is to place reported problems onto the map of their local area. Feedback from the Barangays suggested that a cultural lack of map-based and spatial- information/awareness among these was preventing full adoption of FixMyBarangay. Key to this was also delivering training beyond the Barangay Captain and Secretary, who were both often too busy in the Barangay to use the software tools – which require them to be sat at their desks.  Undertake a follow-up survey to try and understand the reasons behind low-uptake of FixMyBarangay, and also to raise awareness again.  Place adverts for the service on the Cebu City website when it gets refreshed.  As, and when, messages begin to arrive MICS planned to contact the relevant Government Departments to see if they are aware that the software is up and running. This would involve reminding the repair teams that they have a chance to respond to reported problems.  If further training and advertising is not successful, then MICS would consider adding another issue that people could text about in order to create more demand for text messages. The simplest issue to add would be ‘Garbage Collection’ given the Department of Public Services (DPS) has been involved since the project’s inception.  Another approach would be to work with other Barangays, given that MICS has received interest from colleagues at Barangay Tisa to extend the system into their area. 12.10 These post-launch activities were being taken forward by MICS at the end of the project funding period, with remote support continuing to be provided by the project team in response to enquiries and requests for help. 25/06/2014 36 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT 13 SUSTAINING AND SCALING-UP THE SOFTWARE PLATFORM 13.1 This chapter draws upon the findings from the final project meeting with the MICS local delivery team, as well as the experiences of the project team through the demonstration project, in order to recommend options for sustaining and scaling up the FixMyBarangay tools in Cebu City and replicating them in other locations. Sustaining FixMyBarangay 13.2 In order to successfully maintain the FixMyBarangay platform there are a number of considerations that Cebu City Government’s MICS team, the participating Barangays and government department repair teams will need to bear in mind. These have been discussed in the remainder of this section. Software platform operating costs 13.3 The operating costs of the FixMyBarangay software platform will become a concern for Cebu City Government from November 2013 onwards, at which point the cost of the inclusive SMS Gateway that has so far been funded by the World Bank to support this demonstration project will no longer be supported. Based on the assumption that Cebu City Government renews the existing service with the incumbent SMS Gateway provider, and that all staffing and broadband costs continue to be borne by MICS, the participating Barangays and the repair teams at DEPW, DPWH and DPS (as they have been to date), the total cost of maintaining all aspects of the FixMyBarangay software platform is estimated at: USD $7,440. 13.4 The breakdown of these costs is provided in Table 5-1, which reveals that the majority of the cost is for remote ICT support to maintain the FixMyBarangay cloud-hosted server. Table 5-1: Breakdown of costs to maintain all FixMyBarangay Item Cost (USD $) 12 months SMS Gateway subscription (unlimited SMS) 28 240 12 months server cloud hosting 29 1,200 12 months technical support (ICT) 30 6,000 Total 31 7,440 13.5 When shared between Cebu City Government’s MICS team and the three participating departments with fault repair responsibilities, the total annual cost per-agency is less than USD $2,000. These costs could be further reduced if:  A local resource with the appropriate ICT skills is able to fulfil this role.  Cebu City Government is able to negotiate a sponsorship deal with a local telecoms provider in return for an unlimited SMS gateway service. 28 Assumes USD $20 per month for unlimited SMS plan and SMS Gateway subscription 29 Assumes USD $100 per month for cloud hosting of all FixMyBarangay and Message Manager software tools 30 Assumes 1 x ICT professional remotely maintaining FMB server for 0.25 days/month at USD 1,000 per day 31 Assumes that there are already web-connected PCs available at all repair team offices and that staffing costs are covered by existing working practices related to fault reporting (as experienced in Cebu City) 25/06/2014 37 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT Identified additional training needs 13.6 As noted in the previous chapter of this report, there is a need for further training in several areas if Cebu City Government and its partner agencies are to maximise the value of the existing platform of FixMyBarangay software tools. These are summarised in Table 5-2 and will be delivered by the MICS delivery team: Table 5-2: Training needs identified for FixMyBarangay Target user-group Purpose • Improve awareness and understanding of Members of the public living in FixMyBarangay service. participating Barangays • Increase number of fault reports submitted by SMS text from members of the public. • Increase number of people in each Barangay who are able to use the FixMyBarangay tools to assign Participating Barangay Hall incoming fault reports (both via SMS and over the staff members ‘phone/in person) to the map. • Encourage Barangay Captain and Secretary to submit fault reports via SMS text to FixMyBarangay. • Improve awareness and understanding of Repair teams with participating FixMyBarangay service. government departments and • Define and agree routine protocols for using Barangay Halls FixMyBarangay Maintenance Database tools to manage and plan street infrastructure repairs. Other resource requirements 13.7 In our final project meeting MICS’ delivery team staff members identified a need for additional resources in order to accommodate and manage various aspects of the FixMyBarangay software platform and maximise its value in Cebu City. These included:  Each participating Barangay committing at least two members of staff beyond the Barangay Captain and Secretary in order that they have sufficient resources to use the FixMyBarangay tools to place reported problems (either by SMS text, in-person, over the ‘phone or received by email) onto the map of Cebu City. These staff members will need to be adequately trained by the MICS team in order to ensure that they are capable of using the tools competently, and understand the geo-spatial nature of the mapping component of the tool.  The Chief Engineer at each participating local and national government department allocating responsibility for checking their organisation’s Maintenance Database endpoint to at least two members of staff. These individuals would ideally be required to make a brief daily check on the database in order to review any new reported problems, and flagging them for action, as well as updating the status of any existing reported problems against which repair progress is being made.  Further Barangay-wide advertising in both Luz and Basak San Nicolas. This would ideally be targeted at people with access to cell ‘phones, as well as people who are currently reporting streetlight defects and potholes by means other than through FixMyBarangay. 13.8 If this combination of funding, training, and resource requirements is met, then it should be relatively straightforward to sustain the FixMyBarangay platform in Cebu City. 25/06/2014 38 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT Scaling-up the tools in Cebu City 13.9 Provided that an unlimited inbound/outbound SMS Gateway service is secured to support FixMyBarangay beyond the timeframe of this demonstration project, then scaling this platform across additional Barangays in Cebu City, or to cover new issues is very simple, and requires a small amount of local and remote ICT support to ensure it happens. The two key means of scaling-up the existing tools are:  Adding new Barangays to the two demonstration locations.  Adding new issues about which people can report problems. Adding new Barangays to the two demonstration locations 13.10 Adding a new Barangay is a relatively simple process that will involve input from both the local MICS delivery team and remote ICT support from a software developer maintaining the FixMyBarangay cloud server (which could, over time and with further training, become MICS; but at the present time the organisation does not have the capacity or resources to maintain the server). Table 5-3 outlines the steps involved: Table 5-3: Tasks and responsibilities for adding new Barangays to FMB Task Responsibility MICS make pull request through Github and remote Adding a new hyperlink to the FixMyBarangay home-page developers accept it and and web-template so that reported problems in the newly- make the change to the added Barangay can be viewed. Cebu City software code for FixMyBarangay. Adding map-views that highlight the added Barangay MICS make changes using boundary in relation to Cebu City, for use when placing FixMyBarangay admin reported problems on the map, using Mapit to define a tools. new unique area_idResponsibility. Creation of a new Tag for incoming SMS texts received in Message Manager, so that messages from residents in a MICS delivery team newly-added Barangay are sorted and presented only to admin staff working in the relevant Barangay Hall. Creation of a new set of Message Manager user-accounts for staff at the newly-added Barangay, with appropriate MICS delivery team permissions to view messages tagged with the short code that relates to their Barangay. Reviewing and updating ‘boiler-plate’ message response MICS delivery team strings (as required). Training for participating staff at the newly-added MICS delivery team Barangay. Refresher training for staff working in each government repair team, to ensure they are aware that a new MICS delivery team Barangay is being added to the FixMyBarangay platform and they will receive new fault reports from this location. Launch the FixMyBarangay service in the newly added MICS delivery team Barangay to raise local awareness of the service. 13.11 The project team’s recommendation is that a small number (e.g. 1-2) of additional Barangays is added to the FixMyBarangay service in Cebu City at a time. This will avoid the repair agencies from becoming overwhelmed by the volume of fault reports, and ensure the scale-up process happens smoothly. Once a critical mass of Barangays has been 25/06/2014 39 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT reached (e.g. city-wide coverage) then the design of the website home-page and template may need to be revisited, since there will be up to 80 locations to choose from. This would likely involve the use of a text-searchable drop-down menu, rather than the use of hyperlink buttons. 13.12 Beyond the staff resources required by MICS to deliver training, define roles at the Barangay Hall and launch the service in each location (re-using the resources developed for the launch in Basak San Nicolas and Luz during the demonstration project), the cost of adding extra Barangays to the FixMyBarangay service is relatively trivial. As such, it is envisaged that this would be included within the cost of on-going local and remote ICT technical support. Adding new problem report issues to the two demonstration locations 13.13 Adding a new issue (e.g. Garbage collection) to those covered in the demonstration project (potholes and defective streetlights) is also a simple process that requires input from both the local MICS delivery team and remote ICT support from whichever software developer is maintaining the FixMyBarangay cloud server. Table 5-4 outlines the steps involved: Table 5-4: Tasks and responsibilities for adding new problem report issues to FMB Task Responsibility MICS add new category Adding a new report category for each issue and repair (and, possibly, the repair agency to the FixMyBarangay web-application, for use agency body if it's a new when placing reported problems on the map, and linking it department) via the with the appropriate Maintenance Database FixMyBarangay admin. Creation and hosting of a new Maintenance Database endpoint website for the repair agency (as required) – MICS delivery team which will likely involve modifying one of the existing database instances. Reviewing and updating ‘boiler-plate’ message response MICS delivery team strings (as required). Training for participating staff at the newly-added government repair team, to ensure they are fully aware of how the system works and the way they will receive and MICS delivery team respond to problem reports received from the participating Barangays. Publicise the availability of the new issue across all participating Barangays in order to raise local awareness MICS delivery team of the additional problem reporting option(s). 13.14 As above, the project team recommends that the process of adding new issues is measured (e.g. one at a time) in order to minimise the amount of time and effort that the MICS delivery team has to spend training and maintaining relationships new repair agency teams. The resources of the MICS team may need to scale-up as the number of teams being supported increases. We also recommend that issues selected are those closest to the needs and interests of local people, and are based on the knowledge of staff members at participating Barangay Hall’s in respect of the most commonly reported problems. 13.15 Beyond the staff resources required by MICS to deliver training, define roles at the repair agencies and raise awareness in each participating Barangay that there are new issues people can report faults about, the cost of adding new issues to the FixMyBarangay service 25/06/2014 40 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT is relatively trivial. As such, it is envisaged that this would be included within the cost of on- going local and remote ICT technical support. Guidelines for replicating in other cities 13.16 The estimated cost of replicating the whole FixMyBarangay platform, and associated Maintenance Databases on a similar scale in a similar location is USD $30,000 for the first year, and USD $7,440 to maintain it each year thereafter. This assumes similar local labour costs to Cebu City, that the delivery of all high-level ICT support is remote, and that a similar number of agencies are participating in the project. 13.17 In order to assist city authorities that might be considering replicating the FixMyBarangay platform in their city, the project team has prepared a set of Implementation Guidelines (see Appendix E to this report) that define the steps associated with setting up the software tools and inter-agency collaboration needed to make it work. The remainder of this report summarises the key lessons learned by the project team through challenges met on this project, and also sets out our ideas for future development of the FixMyBarangay platform, which may be relevant to the World Bank and donor funding agencies. 25/06/2014 41 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT 14 LESSONS LEARNED THROUGH CHALLENGES MET DURING THE PROJECT 14.1 This penultimate chapter of the final report identifies the key lessons learned by the project team through the course of developing and implementing the demonstration instance of the FixMyBarangay platform in Cebu City. It draws together some of the issues identified earlier in this report and expands on them in order to present valuable process-learning from which other authorities wishing to replicate the FixMyBarangay software tools and SMS-based fault reporting system in their city may learn. Understand local access to communication technologies 14.2 One of the earliest activities undertaken in the project were 500 surveys with local residents in the two participating Barangays of Luz and Basak San Nicolas, as well as separate Focus Group Discussions with male and female residents. These stakeholder engagement efforts were highly valuable and gave the project team insight into local levels of mobile phone ownership and internet access, and what people use these services for. This intelligence helped the project team and local delivery partners determine that FixMyBarangay should be SMS text-based, rather than web or smartphone app-focused. Carefully select ‘problem issues’ when setting up a FixMyBarangay service 14.3 One thing the project team was very keen to do from the outset of the project was to identify street infrastructure ‘problem categories’ that we knew could definitely be addressed through local resources. The rationale behind this approach was that members of the public would be more likely to submit problem reports using the FixMyBarangay service if they were able to see an outcome (i.e. the problem being fixed) than if their problem went onto a list of repairs that were never fixed. 14.4 Through the aforementioned surveys and focus groups, we were able to determine important issues for local people in the two participating Barangays. It quickly became apparent that the most important street infrastructure issues for local people (illegal parking and overflowing drains) were not issues which are easy to resolve in Cebu City:  CITOM, the local agency responsible for parking enforcement, prioritises its limited resources on violations on major roads through the city and would not therefore have capacity to respond to what was anticipated to be a large number of complaints from residents on comparatively minor Barangay streets.  DPWH, the national agency responsible for drainage, has a long-term programme for installing/improving drains in the city and a quick response to inadequate drainage was not feasible. 14.5 As such the project team decided to focus on potholes and defective street lights. Although these were not the most important street-infrastructure issues for local people 25/06/2014 42 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT (and considerably less important to local people than crime, drugs, rubbish collection and anti-social behaviour), they did represent the most important issues that could be addressed by the Barangays and local/national government departments’ repair teams. In order to guarantee a response to these problems the project and local delivery teams coordinated with the participating repair agencies pre-launch to ensure they retained a stockpile of asphalt and replacement streetlight bulbs that might be needed when SMS problem reports began arriving. 14.6 Given the relatively small number of SMS text messages sent to the FixMyBarangay platform, it is possible to question whether the issues selected by the project team (although repairable) were considered significant enough by residents of the two participating Barangays to warrant sending a text message. One interesting observation is that the majority of the reported problems following the launch related to broken streetlights. It is possible that this reflects local concerns about crime in the Barangays, and a perception that well-lit streets are a way of deterring unsavoury activity. 14.7 With hindsight, a better issue to have selected might have been garbage collection – since this is something that more-directly impacts on people’s lives in the Barangays and there is a mechanism, through the Department of Public Services, to address this issue. The idea of adding this issue to the FixMyBarangay platform as part of a re-launch of the service in the two participating Barangays of Luz and Basak San Nicolas was being considered by the local delivery team at MICS at the end of the demonstration project. Adopt the most agile approach to software development as possible 14.8 Picking up on the previous point, the project team would strongly advocate a more agile approach to software development than the one we used in Cebu City. With the benefit of hindsight, a good ‘real-world’ test of local people’s preparedness to report problems via SMS text would have been to run a 2 week long pilot using an old mobile phone and a SIM card. City-wide residents could have been encouraged to submit any problem they wanted to report in their local area via SMS text. People submitting a problem report would need to state clearly the location of the problem they had identified. 14.9 Keeping track of all the messages received would have usefully tested:  The extent to which people are actually prepared to send problems to their Barangay Hall by SMS text - although most people indicated a willingness to do this in surveys conducted at the beginning of the project, the 1 Peso cost per message sent may have discouraged some people.  The city subdivisions from which most of the problem reports were generated – in order to target a spatial area for piloting of FixMyBarangay.  The issues about which people submitted problems – in order to determine the topic that is most likely to yield a critical mass of identified problems that require fixing. 25/06/2014 43 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT 14.10 We would strongly urge any city authority seeking to replicate FixMyBarangay undertakes this kind of low-cost trial before investing time and resources into implementing the software platform. If at the end of this process there is demonstrated willingness to submit problem reports by SMS, a clear locational/city-wide focus, and a priority issue on which to focus, then we would advocate piloting with a single issue in a single location before looking to scale-up to the whole city. Understand local cultural awareness of maps and geo-spatial information 14.11 A finding which emerged through the course of our team’s user-focused software design effort was that maps and geo-spatial means of presenting information are a potential barrier to uptake of the FixMyBarangay tool. In the Philippines it is culturally more common for people to think about places and spaces in a descriptive sense; with local landmarks, physical geography features (e.g. rivers, hills, beaches), and street-names being the most commonly-used points of reference. 14.12 One of the challenges this presented was how to handle problem reports that were geo- spatial in nature, but received in the form of a descriptive SMS text message. After considerable deliberation, and ethnographic observation of Barangay staff members using beta versions of the software tools, the project team decided to include both maps and lists in the FixMyBarangay website view. 14.13 With hindsight, a critical decision was that which required Barangay staff members to click on an OSM map of their local area in order to locate a reported problem, since this was also the mechanism by which problems were categorised and escalated to the local/national government department’s repair teams. It is possible this requirement for geo-spatial knowledge has prevented some reported faults from being categorised and passed on to the relevant repair team in a timely manner. 14.14 Based on this experience, our recommendation to authorities looking to implement a similar system is to:  Provide pre-emptive map training and familiarisation for all prospective users of the FixMyBarangay platform – this could be delivered cheaply by local OpenStreetMap volunteers – and follow it up again as the system is being launched.  Consider working with local software developers to alter the source-code behind FixMyBarangay in order to change the way that faults are categorised and relayed to local repair teams. This would be appropriate in locations where map skills and spatial awareness are culturally unfamiliar. 25/06/2014 44 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT Implementation of SMS Gateway systems 14.15 One of the most significant software development challenges for the whole project involved installing and integrating the HTTP SMS Gateway so that the Message Manager application could make SOAP (Single Object Access Protocol) calls that fetched/pushed SMS messages from/to the SMS Gateway API. This represents the most significant piece of software customisation that any city authority wishing to replicate FixMyBarangay in their city would need to undertake, since it is typically most cost-effective to use a local SMS Gateway service provider so that messages can be sent and received at local rates. 14.16 The SMS Gateway service we used was provided as part of a larger bundle of ICT services procured for other components of this demonstration project and, as such, was not a commercially provided offer. As a result the documentation was poor and obtaining test accounts was challenging. The process of establishing how this particular SMS Gateway implementation worked and could be called upon programmatically took several weeks of effort spread over a period of 2 months during the testing phase of the project. 14.17 The main learning points we brought away from this process were to:  Procure SMS Gateway services with care. It is generally best to seek out a specialised local provider whose main line of business is in providing SMS Gateway services that enable the sending and receiving of SMS texts via the web, email and an API.  Try to find an SMS Gateway provider that will make a single SMS short-code number available across all local network providers. We were unable to do this for the demonstration project, since the SMS Gateway services was provided by one of the major telecoms companies in the Philippines. Having a single short-code number can help people to remember the number and drive up incoming fault reports.  Test the SMS Gateway service extensively prior to the launch using Message Manager, since changes the provider has made to the Gateway settings by the service provider can affect its status. Committing local staff resources to the project 14.18 The FixMyBarangay project would not have been possible without the commitment of considerable ICT and local project management resources by Cebu City Government’s MICS department. Obtaining similar staffing commitments from Barangay Halls and the local/national Government Departments was challenging, and the pressure on staff resources at both sets of organisations continued to present difficulty beyond the launch of the project. One particular issue was ensuring that staff members working at the Barangay were taking the time to evaluate incoming fault reports, and us the FixMyBarangay tools to correctly categorise them and pass them on to the relevant repair agency. Feedback received from the local delivery team at MICS is that the limited capacity of point-people at both of the Barangay Halls has been a limiting factor in early uptake in the software tools. 14.19 Key learning points for other city authorities considering setting up a FixMyBarangay platform are therefore to: 25/06/2014 45 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT  Ensure that the organisations, and point- people, who will be responsible for using the software tools to deliver an outcome (i.e. problem reports categorised, appraised and fixed) have the time available to undertake these tasks alongside their day-to-day responsibilities.  Ensure that key decision-makers at each organisation are bought-in to the FixMyBarangay software tools, and understand the benefit to the organisation of allowing their staff members’ the time and resources to implement them.  Consider incentivising key individuals to ensure that their commitment to the project is allied to personal as well as civic goals. Local technical capacity and resources to maintain a FixMyBarangay server 14.20 The final learning point that the project team identified was that the process of configuring and maintaining a FixMyBarangay web-server requires levels of both technical staff resources and ICT capacity that can be challenging to deliver in locations such as the Philippines. The following things proved to be barriers to the team at MICS setting up and hosting their own implementation of FixMyBarangay:  A modestly powerful, web-server that is reliably connected to the internet so it can host applications that are being accessed at different times of day by multiple users.  Budget resources to cover the cost of out-sourced cloud-based hosting.  ICT professionals who have the necessary core skills to set-up and maintain a Linux Debian server, and install FixMyBarangay software onto it. 14.21 In Cebu City, some of these issues are likely to be resolved by the Philippines’ iGov Hub, which is set to provide considerable government web-server hosting capacity from late 2013. 25/06/2014 46 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT 15 IDEAS FOR FUTURE PLATFORM DEVELOPMENT 15.1 This final chapter draws on the project team’s experiences of developing the FixMyBarangay software platform, and working with local partners to implement the demonstration project in Cebu City, to set out a number of ideas for the future development of the software platform. These could be taken forward through replication projects in other locations, or through the scaling up and expansion of the demonstration platform deployed in Cebu City. Automated street light post identification 15.2 DPS and MICS between them can provide streetlight data, namely the position (lat/lon) and unique lamp post ID number for every streetlight in Cebu City. This data could be made available so that when a user picks "Street light" from the drop-down menu of problem type, the nearest post numbers (e.g. within 25m of that point) could be offered so the user could choose one if it matches. The actual distance could be refined once the accuracy of the data is established. 15.3 As well as offering the choice to the user, the calculated (that is, the nearest, assuming data and map location is accurate) post number could be suggested in the report that is submitted to the Management Database endpoint. Some of this functionality (namely collecting extra data when specific problem categories are selected) is already partially supported in the FixMyBarangay code, because it's similar to the Open311 concept of metadata for specific services. Smartphone app to enable mobile reporting 15.4 The overhead cost to mobile app development is considerably greater than simply making the website responsive to mobile/tablet screen layouts (which FixMyBarangay already is). Nonetheless, a new open source FixMyStreet mobile application is, at time of preparing this report, about to be released. Customising this application by branding it for FixMyBarangay is therefore feasible. MMS submission of issues 15.5 Currently the Message Manager only anticipates SMS (text-only) messaging, but it could be extended to connect to an MMS gateway instead. Aside from the ability to receive images of reported problems (which aid repair teams when they are scoping the scale of a repair), the benefit of accepting MMS messages is that it allows the possibility of images containing ‘EXIF’ data which contains reasonably accurate geo-location data. Opening up FixMyBarangay for submission of fault reports via a web-browser 15.6 A possible way of expanding the FixMyBarangay platform is to open up the website so that anyone – not just admin users from participating Barangay Halls – can submit problem reports in their local area. Only staff at the Barangay Halls would be able to retrieve and assign problem reports submitted via SMS text (using Message Manager), but anyone could add a problem to the map and request it is repaired by the relevant government agency via the FixMyBarangay website. This is how most Open-311 websites work elsewhere in the world and would be appropriate in Cebu City as internet access increases. Depending on uptake, this approach could save Cebu City Government from bearing the cost of an SMS gateway in the long-term. 25/06/2014 47 TRANSPORT CROWD SOURCE ICT DEMONSTRATION COMPONENT 2 FINAL REPORT 15.7 Opening up problem reporting in this way increases the likelihood that identified problems get mis-reported or reported to the wrong agency, because members of the public are unaware of the correct agency to which they should direct their complaint. This can be mitigated by:  Including a clear key on the FixMyBarangay website that defines which agencies are responsible for each type of problem – providing guidance on the website for members of the public on where they should direct their problem report.  Creating tools that enable agencies to re-define the responsible agency for a mis- directed problem, which would require changes to the software code underlying FixMyBarangay and Maintenance Databases.  Automating the assignment of responsibility for problem reports based on an underlying database of geo-spatial and problem category responsibilities. FixMyStreet operates on this basis in the UK, but in Cebu City it would require the creation (and maintenance) of such a database from scratch.  The existing functionality within the FixMyStreet code-base which allows updates (and hence discussion) on the reports by members of the public (and Council staff) – as such it's not only restricted to reporting new issues, but also to community-led checking of existing ones. 15.8 Any of these solutions would require collaborative working between the MICS delivery team and the remote software developer that is responsible for maintaining the cloud- hosted FixMyBarangay server. The estimated one-off cost of opening up the FixMyBarangay website to allow open public reporting is between USD $1,000 and $6,000 depending on the approach(es) adopted. Adding ‘private’ problem categories to FixMyBarangay 15.9 The underlying FixMyStreet code-base already supports "private" problem categories, which are submitted to Maintenance Database endpoints, but are not shown on the main FixMyStreet map. This means location-based reports that are sensitive or specific and not of public interest (e.g. containing an individual’s address for a missed garbage collection) can be made privately. In the context of FixMyBarangay, this could be useful if a city authority wished to encourage anonymised reporting of non-emergency illegal/criminal activity. 25/06/2014 48