Visualization Tool to Analyze Data-Driven Bus Lane Allocation Guidelines

Ben-Gurion University of the Negev

Faculty of Engineering Science

Department of Industrial Engineering and Management

Bussleneck – Visualization Tool to Analyze Data-Driven Bus Lane Allocation Guidelines

Thesis Submitted in Partial Fulfillment of the Requirements for M.Sc. Degree

Submitted By: Shaked Kaufman-Ofek

Supervisors:

Prof. Noam Tractinsky, Department of Software and Information Systems Engineering

Dr. Eran Ben-Elia, Department of Geography and Environmental Development

E-mail: [email protected]

15 December 2020

Ben-Gurion University of the Negev

Faculty of Engineering Science

Department of Industrial Engineering and Management

Bussleneck – Visualization Tool to Analyze Data-Driven Bus Lane Allocation Guidelines

Thesis Submitted in Partial Fulfillment of the Requirements for M.Sc. Degree

Submitted By: Shaked Kaufman-Ofek

Supervisors:

Prof. Noam Tractinsky, Department of Software and Information Systems Engineering

Dr. Eran Ben-Elia, Department of Geography and Environmental Development

Author: ……………………………….……… Date: …………15/12/2020………………

Supervisor: …………………………………… Date: …………15/12/2020………………

Chairman of Graduate Studies Committee: …………………_ Date: …15/12/2020……

15 December 2020

Abstract

Public Transit (PT) plays a vital part in a sustainable mobility network. In addition to walking, cycling and micro-mobility, PT provides relatively cheap and highly efficient way to move masses of people within the city and between cities. In dense areas, heavy and light trains provide the backbone of the PT system to move masses of people, while buses provide greater coverage and more flexibility in both planning and operation. However, in some places, buses are the backbone of the system. In Israel, for example, buses deliver 85% of PT trips and the rest is delivered by other means (ISC 2019).

In order to provide a reliable service, causes of delays should be removed. Buses can be delayed due to traffic, congestion, late departure, inadequate driving style, cash payments and more. To increase ridership and improve the travel experience, these should be mitigated. One of the major reasons for delays is congestion and general traffic that cause buses to travel at low speeds. Different means exist to mitigate this issue: bus lanes, bus preemption in traffic-lights, bus islands and more.

The publication of guidelines for planning and operating public transportation bus services in Israel (Ashak and Shliselberg 2016) was a milestone in PT service planning and operation in the country. For the first time, an official government-issued document addressed data-driven bus lane allocation. The guidelines consider bus volumes, passenger volumes and bus speeds to justify bus priority.

One may produce static maps or lists that describe where bus lanes should be allocated, but we aimed to offer a fundamental application that allows analyzing the underlying metrics and overviewing analysis outcomes in a comprehensive manner. Our work suggests Bussleneck, a data visualization application that implements those guidelines on two real-world use cases of the cities of Be’er Sheva and Tel Aviv–Yafo in Israel. We address data sources collection (bus schedules, aggregated real-time data records and on-board passenger counts), data processing into relevant metrics and different aspects of data visualization design.

The application was evaluated by a group of experts who represents the intended audience of PT planners and PT related data analysts. The application will be available for public use, including source code and processed metrics. The application displays metrics based on data records collected during March 2019. We intend to do our best efforts to publish the application using up-to-date data sources.

In this work we also developed a methodology to build a network of PT segments (road segments that carry PT vehicles [buses] delimited by either a bus stop or an intersection) from GTFS and OSM data. We also systematically surveyed different papers that utilize data visualization tools to analyze similar data sources. Finally, we provide recommendations to authorities regarding the use of OSM and suggest improvements to data sources that can contribute to higher precision of the analysis process.

• A paper titled ‘Visualization Tool to Analyze Data-Driven Bus Lane Allocation Guidelines’ was presented at the Transit Data 2020 symposium. • The code for processing the data can be accessed on this GitHub repository, and the code for the application can be found on this repository. Bussleneck application itself can be accessed and used by the public.

keywords: PT, Public Transit, Public Transportation, bus lane, SIRI, AVL, GTFS, APC, Data Visualization, Buses, Data-driven Planning

iii

Acknowledgments

I would like to express my gratitude to my academic advisors, Prof. Noam Tractinsky and Dr. Eran Ben-Elia for their helpful advice and guidance, financial support, in-depth proofing and continuous guidance throughout the research.

Though not an official academic advisor, I wish to thank Dr. Peter Bak for being my mentor and consultant for academic, technical and practical aspects of designing and developing data visualization tools.

My research would have been more cumbersome without the help of Dror Bogin, whose research work and coding are the basis for my data processing methodologies. Similar gratitude goes to the authors and publishers of Open Street Map, QGIS software suite, React JS and D3 JS code packages and the following Python packages: Pandas, GeoPandas, GTFS Kit, SciPy and Shapely who made it possible to develop this application in timely manner.

Incorporating passenger counts data records would not be possible without the help of The Ministry of Transport and Road Safety and the National Public Transport Authority personnel. I thank them for the cooperation and willingness to support my research by providing data records from different periods and high volumes to support this research.

Special thank you goes to the Facebook ‘Transit Data Israel – API, R&D and data analysis’ group members, and especially Netta Beninson and Dan Bareket who provided endless consultation and suggestion on PT data processing in the Israeli context.

Over three years of research, I worked with groups of B.Sc. students from the Department of Software and Information Systems Engineering. Though not included in this final work, their project works were an inspiration and a basis for the final products of this research. I wish to thank them for taking part in my wild ideas and high demands.

More than everyone, my deepest gratitude goes to my partner Yoni who stood by me, endorsed me and encouraged me to pursue my research goals and make this work available for the public, and not just stay in the academic realm.

Finally, this research was sponsored by the following scholarships which I personally thank:

• The Ben Gurion University’s Vice Rector grant program for inter-disciplinary Masters studies • BGU Interdisciplinary Research with Faculty of Humanities and Soc. Sciences grant program • The Israeli Smart Transportation Research Center for funding the costs of attending and presenting at the Transit Data 2020 symposium.

Table of Contents

Abstract ...... iii

Acknowledgments ...... iv

List of Tables ...... viii

List of Figures ...... ix

List of Equations ...... xi

1. Introduction ...... 2

2. Background ...... 3

2.3.1. Bus Service Profiles ...... 5

2.4.1. Guidelines for Planning and Operating Public Transit Bus Services ...... 6 2.4.2. Bus Lane Allocation Guidelines ...... 7

2.5.1. GTFS – General Transit Feed Specification ...... 9 2.5.2. AVL – Automatic Vehicle Location ...... 10 2.5.3. APC – Automatic Passenger Counter ...... 10

2.6.1. The “WhatWhyHow” Model ...... 12

3. Related Work ...... 15

3.1.1. Publications Addressing Relevant Metrics ...... 15 3.1.2. Publications Discussing GTFS, AVL & APC Analysis Indepth ...... 19

4. Context ...... 29

4.3.1. Open Street Map Data...... 34 4.3.2. GTFS ...... 34 4.3.3. SIRI ...... 35 4.3.4. APC ...... 36

5. Development Methodology ...... 38

5.1.1. Public Transit Segment Network ...... 38 5.1.2. Bus Lane Allocation Metrics Definition ...... 41 5.1.3. Data Processing ...... 45

5.2.1. Specifying User Tasks ...... 49

5.3.1. Visualization Mapping (Building Blocks) ...... 51 5.3.2. Controllers and Filtering options ...... 52 5.3.3. General interaction techniques: ...... 52

6. Bussleneck – Comprehensive Analysis Application of Israeli MoT Bus Lane Allocation Guidelines ...... 53

6.1.1. View 1: Analyze Metric Distribution ...... 53 6.1.2. View 2: Analyze Metric Interaction ...... 56 6.1.3. View 3: Overview Qualification for Bus Lane Allocation ...... 58

6.3.1. Be’er Sheva ...... 61 6.3.2. Tel Aviv ...... 64

7. Evaluation ...... 67

7.2.1. Sample ...... 68 7.2.2. The Interview ...... 69 7.2.3. Results ...... 70

8. Discussion ...... 71

9. Limitations and Future Work ...... 73

9.2.1. Suggested Improvements for Bussleneck ...... 74 9.2.2. Suggested Further Work...... 75

10. Conclusion ...... 77

References ...... 78

11. Appendices ...... 83

vii

List of Tables Table 1 List of abbreviations ...... 1 Table 2 Twelve types of bus lane allocation qualification functions (BV – bus volumes; BS – bus speeds; PV – passenger volumes) ...... 8 Table 3 Bus lane allocation guidelines related metrics and their data sources ...... 9 Table 4 Mapping works related to data sources analysis and metric products ...... 18 Table 5 Classification of publications to different categories as part of user task analysis...... 24 Table 6 Bus route counts in Be’er Sehva, by PTO ...... 30 Table 7 Bus route counts in Tel Aviv, by PTO ...... 33 Table 8 GTFS feed properties for Be’er Sheva and Tel Aviv bus services on Sunday (working day in Israel) March the 3rd 2019 ...... 35 Table 9 SIRI protocol response fields ...... 35 Table 10 Comparison between SIRI records collected for Be’er Sheva and Tel Aviv on March 3rd 2019 ...... 36 Table 11 APC fields ...... 37 Table 12 Comparison between APC records collected for Be’er Sheva and Tel Aviv on March 3rd 2019 ...... 37 Table 13 Mapping PT services time-of-day periods to hour spans ...... 41 Table 14 Example data for calculating BV metric. Blank cells represent trips outside of the time scope ...... 42 Table 15 Example data for calculating BS metric. Blank cells represent trips outside of the time scope ...... 43 Table 16 Example data for calculating BD metric. Blank cells represent trips outside of the time scope ...... 44 Table 17 Example data for calculating PV metric. Blank cells represent trips outside of the time scope ...... 44 Table 18 Detailed description of metrics and their visual mapping ...... 52

viii

List of Figures Figure 1 The Rav-Kav card – National smartcard for PT services access and payment ...... 5 Figure 2 Qualification for adding a new bus lane on urban roads (Ashak and Shliselberg 2016)...... 8 Figure 3 A 19th century map depicting clusters of Cholera disease cases near a water pump in Broad Road, London (1854) from (Tufte 2001) ...... 11 Figure 4 Iterative “What-Why-How” model where the designer should validate his work in each phase (Munzner 2015) ...... 12 Figure 5 Data, data sets and attributes (Munzner 2015)...... 13 Figure 6 Visualization idioms: encode, manipulate, facet and reduce (Munzner 2015) ...... 14 Figure 7 a section of the PT-related visualization user tasks depicting a connection between‘'frequnecy’' and ‘'passenger load’'- 2 targets that appear together in many publications ...... 25 Figure 8 Types of actions users can perform as part of visualization user tasks ...... 25 Figure 9 Targets of actions when analyzing PT related data sources ...... 26 Figure 10 Different patterns of PT related data ...... 27 Figure 11 Different aspects of PT related data sources analysis ...... 28 Figure 12 Be’er Sheva heavy rail train stations (blue train icons) with the Israeli railway marked in dashed black-white color (from MoT GIS system https://geo.mot.gov.il/) ...... 30 Figure 13 Map of the PT service in Be’er Sheva. Bus stops are marked by round blue bus icons. Service frequency is represented by the width of the red lines (from MoT GIS system https://geo.mot.gov.il/) ...... 31 Figure 14 Tel Aviv heavy rail train stations (blue icons) with the Israeli railway marked in gray color lines. City municipal borders are marked in red dashed line (from Tel Aviv GIS system https://gisn.Tel Aviv.gov.il/iview2js4) ...... 32 Figure 15 Map of the PT service in Tel Aviv. Service frequency is represented by the width of the red lines (from MoT GIS system https://geo.mot.gov.il/) ...... 33 Figure 16 PT segment network of Be’er Sheva - The lines represent the road segments that carry any PT service delivered by buses...... 34 Figure 17 Illustration of PT segments delimited by either a junction, traffic lights or a bus stop ...... 38 Figure 18 Yeffet street in Tel Aviv, illustrated on OSM. Though the highlighted road link carries two-way traffic, the OSM linestring displays one-way traffic only. It was split it into two lines to support two-way traffic ...... 39 Figure 19 Salame street in Tel Aviv. On the left-hand side a set of 3 red points representing traffic lights and a green point representing a junction – these were merged. On the right-hand side, a green point represents a junction. The point was buffered so it would ‘touch’ all intersecting lines...... 40 Figure 20 Illustration of the PT segment network building process ...... 40 Figure 21 Patterns of daily boarding in Israel showing that there are 3 general patterns: weekdays (Sun-Thu), Friday and Saturday (Benenson, Marinov, and Ben-Elia 2019) ...... 47 Figure 22 Bussleneck view layout ...... 53 ix

Figure 23 Distribution of PT segments that carry buses running in average speed of 0-10 kph on Sundays during early ...... 54 Figure 24 Distribution of PT segments around Rager Blvd. (Be’er Sheva) as a function of PV on Sundays during early morning peak ...... 54 Figure 25 Color palettes for the sequential metrics: BV, BS and PV ...... 55 Figure 26 Diverging color palette for BD metric ...... 55 Figure 27 Distribution of PT segments in Be’er Sheva as a function of BD on Sundays during early morning peak ...... 55 Figure 28 Bussleneck in light mode as presented during the expert review...... 56 Figure 29 Interaction between PT segments metrics: BV & BS on Be’er Sheva on Sundays during early morning peak. A bi-variate color scheme is used to represent the interaction between the metrics per each PT segment (point in the scatter plot) .. 56 Figure 30 Creation of bi-var color schemes for Bus Volumes and Bus Speeds ...... 57 Figure 31 Zoom-in on Rager Blvd. in the 2nd view (Analyze metric interaction) ...... 57 Figure 32 Overview qualification for bus lane allocation by the combination of BV & BS on Sundays during early morning peak ...... 58 Figure 33 User filters the BV histogram to focus on the busiest PT segments ...... 59 Figure 34 Scatter plot data points that carry most buses are highlighted (filtered-in) ...... 59 Figure 35 Scatter plot data points that carry most buses are highlighted (filtered-in) and indicated to qualify for bus lane allocation ...... 60 Figure 36 Distribution of PT segments as function of BV during early morning peak (06:00- 08:30 AM) Sun-Thu during March 2019 ...... 61 Figure 37 Distribution of PT segments as function of BV during late morning peak (08:30- 11:00 AM) Sun-Thu during March 2019 ...... 61 Figure 38 Busiest PT segments (more than 50 buses on average per hour) during Sun-Thu eraly morning peak ...... 62 Figure 39 The busiest PT segments average speeds vary greatly, bus mostly found at 15-30 kph ...... 62 Figure 40 Filtered segments are qualified for bus lane allocation ...... 62 Figure 41 During early morning peak, no PT segment carries more than 500 passengers on average ...... 63 Figure 42 Distribution of PT segments in Tel Aviv as function of BV during early morning peak (07:00-08:30 AM) Sun-Thu during March 2019 ...... 64 Figure 43 Qualification of PT segments qualified for bus lane allocation plotted over existing bus lanes ...... 64 Figure 44 Comparison between the qualification of PT segments on Shaul Hamelech Blvd. for bus lane allocation at early morning peak (left) and after-noon peak (right) .... 65 Figure 45 Distribution of PT segments as a function of qualification for bus lane allocation in the south-east part of Tel Aviv...... 65 Figure 46 Distribution of PT segments as a function of qualification for bus lane allocation in the north-east part of Tel Aviv...... 66 Figure 47 Distribution of the scores for the quantitative questions presented to the experts following the review. Each color represents a score on the 7-point Likert scale. The average score is displayed on the right-hand side. Designed using DataWrapper ... 70

List of Equations Equation 1 Average value of on-board passengers for I parts of road segment l ...... 7 Equation 2 Average value of bus volumes for i parts of road segment l ...... 8 Equation 3 Bus Volumes on a given PT segment ...... 42 Equation 4 Bus Speeds on a given PT segment ...... 43 Equation 5 Bus Delays on a given PT segment ...... 43 Equation 6 Passenger Volumes on a given PT segment ...... 44

Abbreviation Full Form

AFC Automatic Fare Collection

APC Automatic Passenger Counter

AVL Automatic Vehicle Location

BD Bus Delays

BS (Commercial) Bus Speeds

BV Bus Volumes

DoA Day of Analysis

GTFS General Transit Feed Specification

HOV High Occupancy Vehicles

Kph Kilometers per hour

LoS Level-of-service

MoT Ministry of Transportation

NPTA National Public Transport Authority

PT Public Transit / Public Transportation

PTA Public Transit Agency

PTO Public Transit Operator

PV Passenger Volumes

SIRI Standard Interface for Real-time Information

Table 1 List of abbreviations

1 1. Introduction

Public Transit (PT, see Table 1) plays a vital part in a sustainable mobility network. In addition to walking, cycling and micro-mobility, PT provides relatively cheap and highly efficient way to move masses of people within the city and between cities. In dense areas, heavy and light trains are considered the backbone of the PT system to move masses of people, while buses provide greater coverage and more flexibility in planning and operation. However, in some places, buses are the backbone of the system. In Israel, for example, buses deliver 85% of PT trips and the rest delivered by other means (ISC 2019).

In order to provide a reliable service, causes of delays should be removed. Buses can be delayed due to traffic, congestion, late departure, inadequate driving, cash payments and more. If we are to increase ridership and improve the travel experience, these should be mitigated. One of the major reasons for delay is congestion and general traffic that cause buses to travel at low speeds. Different means exist to mitigate this issue: bus lanes, bus preemption in traffic-lights, bus islands and more.

In some cities and places, bus lanes prevail, so buses have relatively high commercial speeds and travel time reliability is maintained. In other places, like Israel, the PT infrastructure remained for many years under-funded in favor of road infrastructure investments. However, in recent years, the approach has changed in the Israeli Ministry of Transportation (MoT) and more PT services are developed and pushed forward.

One of the milestones in this approach was the publication of (Ashak and Shliselberg 2016) that addressed the planning and operation of PT services by buses. For the first time, an official government-issued document addressed data-driven bus lane allocation. These guidelines consider bus volumes, passenger volumes and bus speeds as criteria for bus priority. Our work focuses on bus lanes as priority means to address many of the problems of bus delays.

This study has two major contributions. First, we developed a data visualization application that implements the bus lane allocation guidelines using two real-world use cases of the cities of Be’er Sheva and Tel Aviv–Yafo in Israel where we only address urban roads. One may produce static maps or lists that describe where bus lanes should be allocated, but we aimed to offer a fundamental application that allows analyzing the underlying metrics and overviewing final analysis outcomes in a comprehensive manner. We address data sources collection (bus schedules, aggregated real-time data records and on-board passenger counts), data processing into relevant metrics and different aspects of data visualization design.

Second, we developed a specification of the generation of a city’s network of PT segments. As described later on, we aim to have a very high resolution of data analysis. Therefore, a prime objective was to be able to attach each data point to the correct spatial element. Instead of looking at road links between junctions, we observe PT segments which are road segments delimited by either bus stops or junctions. This high resolution of spatial data processing suggests a more refined and true representation of real-world data with less assumptions.

The rest of this work is structured as follows: The following section provides background on the two fields of public transportation and visualization; Section 3 presents related work and Section 4 discusses the context of this project. Section 5 describes the study’s development methodology and goals, and Section 6 describes the novel visualization proposed in this study. Section 7 deals with the experts’ reviews and their results, while Section 8 offers discussion. Section 10 presents the conclusion and future work. Appendix A includes the full interview held with ten experts for evaluating the visualization.

2. Background Public Transit

Public Transportation or Public Transit (PT) has a significant weight in a sustainable transportation system (Mamun and Lownes 2011). Mobility that relies mostly on private cars or a malfunctioning PT system is doomed to be incapable of handling peak demand which is a vital solution for the mobility needs of the masses. This is a complex system that is based on physical elements of stops, vehicles, routes and other temporal and spatial aspects (Ceder 2016). Apart from establishing the needed infrastructure and PT components, one must verify that the system connects areas of different uses (residential, commercial, employments. mixed-use) and be accessible to different populations accounting for different characteristics and needs (Mamun and Lownes 2011).

(Walker 2012) defines Public Transit as consisting of “regularly scheduled vehicle trips, open to all paying passengers with the capacity to carry multiple passengers whose trips may have different origins, destinations and purposes”. The author further details 7 passenger demands of a successful PT system:

1. It takes me where I want to go. 2. It takes me when I want to go. 3. It is a good use of my time. 4. It is a good use of my money. 5. It respects me in the level of safety, comfort, and amenity it provides. 6. I can trust it. 7. It gives me freedom to change my plans.

A trust-worthy PT system, as described in demand #6, is a system that supports almost all the other demands. In order for a passenger to be able to use a PT system when and where she desires, without waiting for too long and with a sense of respect for her time and comfort, the system must be trustworthy.

A trustworthy PT system is not necessarily one where buses drive the fastest, as we usually perceive mobility based on private vehicles. While in an interurban bus trip context, a bus spends most of its time on driving along highways/regional roads, the case of an urban bus service very different. Passengers expect the buses to arrive in a timely fashion, according to published timetables or headways and without being delayed in general traffic.

There exist two types of bus delays: routine and exceptional. The latter refers to unexpected delays like emergency events of sorts. Routine delays are general congestion, signal delays and passenger- stop delays. These types of delays should be addressed systematically in order to improve the reliability of urban bus services. Causes of delays and the means to deal with them including bus priority means, are discussed in the next section.

3 Bus Priority Means

The following section provides details for causes of delays for PT services and means to mitigate them.

Causes for Delays

(Walker 2012) provides details about different delays that bus services encounter on a regular basis:

• Traffic delays: o congestion – caused by mass volumes of vehicles sharing the road with PT vehicles o friction – caused by single vehicles blocking the bus from merging in the traffic or moving smoothly on its route. • Signal delays – buses and other PT modes (trams or light rail) may be delayed by traffic lights that do not grant them a priority. • Passenger-stopping delays – constitute passenger alighting/boarding times, dwell time to collect fares, merging in/out traffic and stop acceleration/deceleration.

(Ashak and Shliselberg 2016) further elaborate on 5 metrics to measure delay aspects of a given route (threshold limit values in brackets):

1. Commercial speed on a specific road segment or along the entire route (lower than 16 kph) 2. Dwell time at stop – from door opening until door closing (higher than 30 seconds) 3. Merging back to traffic – from door closing until full merge into traffic (higher than 15 seconds) 4. Delay due to traffic signal – number of signal cycles until the bus passes the junction (higher than 1 cycle) 5. Miscellaneous metrics that measure the service reliability

Priority Means

The authors of both publications suggest various means to address each type of delay:

• Bus and High Occupancy Vehicles (HOV) Lanes can help buses to avoid traffic congestion and friction. They also may eliminate most of the time required to merge in/out of traffic. The lanes can be part of the general road but restricted to buses only at all or different times. Alternately, they can be physically separated by a barrier that does not allow general vehicles to bypass signage. The most extreme example of a separated bus lane is a lane that uses a different physical infrastructure, usually grade-separated road. The latter is more popular with high speed light rail systems. • Traffic lights preemption – smart traffic lights can be configured to detect an approaching bus and extend the green light or change the signal phase in order to allow it to pass more quickly. • Spacing out stops – decreasing the number of stops requires less acceleration / deceleration phases (but increases walking times to access stops) • All-door access & AFC – off-board or on-board automatic fare collection combined with all-door access allows speedy boarding/alighting.

• Various infrastructure changes – means such as bus-level bus stops and bus islands (anti- bus bays) where the bus stop extends to the middle of the lane allowing the bus to dwell less as passengers can easily alight and board and merge easily in traffic. Public Transit in Israel In Israel, PT mainly relies on bus and train (heavy/light) services. In 2017, there were more than 900,000 service trips in Israel, where approximately 85% of them are bus services (Banitta and Spector Ben Ari 2019). In 2019, more than 2 million passengers were served daily by 17 bus operators using 9,700 buses. With a population of just over 9.2 million (Israel Population Report 2020), only 20% of the population states that they used PT for commuting in 2016.

The Ministry of Transportation (MoT) solely regulates the PT service in Israel. Routes, departure times and geographical and temporal service spans are dictated by the ministry, through internal departments and the new National Public Transport Authority (NPTA). After years of service operated by the Duopoly of two cooperatives (Dan and Egged), a reform initiated in 2000 divided Israel into 34 different PT districts where each area is out for tender every 5-10 years.

Apart from regulation and service planning, MoT and the local authorities are responsible for the transportation and PT infrastructure projects throughout the country. These projects include bus stops, central bus stations, railways and rail stations, bus lanes, and bus terminals. In recent years, as more technology was introduced into the industry, the MoT also started regulating and maintaining technological infrastructure. The “Rav-Kav” (illustrated in Figure 1) is a centralized smart card system that allows paying to any operator via automatic fare collection (AFC) means.

Figure 1 The Rav-Kav card – National smartcard for PT services access and payment A real-time data center also reports on all bus and trains current locations from their GPS transponders (Automatic Vehicle Location – AVL) for the objectives of trip planning applications and researches, and operators are now obligated to mount automatic passenger counters (APC) for demand and loading analysis as part of new PT tenders.

2.3.1. Bus Service Profiles

Israeli bus services’ main operation starts at 5:30 and ends around midnight (Ashak and Shliselberg 2016) on weekdays (Sunday-Thursday in Israel). Sunday and Thursday usually have more services provided to accommodate larger amounts of students and soldiers going back and forth to their military bases / universities and home. Though different operation profiles exist for urban, regional and rural areas, all settlements receive a certain amount of daily bus service. The denser an area is, more service is planned and operated in that area.

Apart from the weekdays regular service, there are several more service profiles:

• Friday service – operating from 5:30 through 17:00 and loosely based on the weekdays schedule and span with required changes.

5 • Saturday night service – operating from 18:00 (or later) through midnight with a schedule which is usually a subset of the weekdays schedule. • Night service – operating on Thursdays and Saturdays, and during all weekdays throughout Summer, this service is intended for night goers and youth. • Other operation profiles – there are also considerations for pupil bus routes and in some cases 7-day operation in certain cities. Bus Lane Allocation Guidelines by Israeli MoT / NPTA

Our work focuses on bus lanes as a priority means to address many of the causes for bus delays. (ISC 2019) explains that the average commercial speed of PT buses in Israel is around 16 kph, compared to an average of 25 kph in various cities in developed countries around the world. The sharp rise in congestion and decrease in bus speeds in recent years has long last received MoT attention. Numerous projects to allocate bus lanes were announced and implemented since 2016, most of them in the dense metropolitan Tel Aviv area where 40% of the population resides and 50% of jobs are located. For the first time, a massive array of projects that coordinate 17 different local authorities aimed to allocate dozens of kilometers of well-connected bus lanes throughout the metropolitan region was launched. This project, like other projects in other parts of the country, encountered many delays and various issues in planning and implementation. Nonetheless, one of the major achievements with regard to this kind of projects is the true understanding of national and local authorities about the dire need for upgrades and priority means to the PT system.

2.4.1. Guidelines for Planning and Operating Public Transit Bus Services

One milestone in this process was a publication by NPTA in 2016 under the title “Guidelines for Planning and Operating Public Transit Bus Services”, (Ashak and Shliselberg 2016). This publication is a first of its kind in Israeli PT history. For the first time, formal guidelines for planning and operating PT bus routes are published, taking into account all aspects of PT services:

• Planning PT networks with geographical aspects and demographics taken into account (statutory demands) • Types of PT service that are proper for each region and sub-region • Full technical procedures for planning • Infrastructure and Transportation: o PT oriented street and urban space design o Bus stops o Central bus stations and transfer hubs o Operational terminals o Pedestrian accessibility • Bus priority means: o Measurable objectives of bus service o Various physical and technological means o Bus priority metrics for justification • Implementing and operating the service: o Guidelines for implementing changes in current bus services

o Evaluating Level of Service o Public inquiries and passenger demands o Bus operation management

Though most of the guidelines are not compulsory, they are used in many PT-related projects, among them the aforementioned mega bus lane project in the Tel Aviv metropolitan.

2.4.2. Bus Lane Allocation Guidelines

(Ashak and Shliselberg 2016) present guidelines and formulas for instructing planners how to decide whether a certain road link is entitled to have a preferred infrastructure for PT in the form of a single bus lane. The formulas are based on the following factors:

• Low bus commercial speed (km per hour) • High bus volumes (vehicles per hour) • High passenger volumes (passengers per hour)

It is also noted that on top of the formula calculations, while planning a bus lane, the continuity of bus lanes must be taken into account to create an effective and seamless bus lane network.

The authors differentiate between two types of bus lane allocation: adding a new lane or adapting an existing lane out of 2 or 3 general traffic lanes. Each type of allocation is justified for urban and regional roads while taking into account commercial bus speeds (BS) in conjunction with bus volumes (BV) or commercial bus speed and Passenger Volumes (PV).

As a pro-PT policy, and regardless of the measured bus speeds in some road segments, urban road lanes will be qualified for bus lane allocation if they carry more than 40 buses or 2,000 on-board passengers per hour during peak times.

In case of BS, BV or PV metrics change along the road segment (this will be specifically addressed in this work in 5.1.1), the following formulas are used to calculate the average value for a road link. Equation 1 breaks down the calculation of passenger volumes for each link, while Equation 2 breaks down the calculation of bus volumes for each link.

푙푖∙푝푖 푃= ∑푙 where 푖=1 퐿

Equation 1 Average value of on-board passengers for I parts of road segment l

P = Average on-board passengers on segment 푙 during peak hours

푙푖 = Length of segment i in kilometers

푝푖 = on-board passengers on segment 푙푖 during peak hours

L = Total length of the road segment, sum of all 푙푖 in kilometers.

7 푙푖∙푣푖 푉= ∑푙 where 푖=1 퐿

Equation 2 Average value of bus volumes for i parts of road segment l

V = Average bus volumes on segment 푙 during peak hours

푙푖 = Length of segment i in kilometers

푣푖 = buses traveling on segment 푙푖 during peak hours

L = Total length of the road segment, sum of all 푙푖 in kilometers.

In total, there are 12 types of allocation qualification functions, that take into consideration allocation type, urban/regional road type and metrics combinations (passenger volumes & bus speeds or bus volumes & bus speeds), as detailed in Table 2.

Bus lane Road type Urban road Regional road allocation type Metrics used BV & BS PV & BS BV & BS PV & BS

Adding new lane

Preempting out of 2 existing lanes

Preempting out of 3 existing lanes

Table 2 Twelve types of bus lane allocation qualification functions (BV – bus volumes; BS – bus speeds; PV – passenger volumes)

For example, Figure 2 shows a chart from (Ashak and Shliselberg 2016) that illustrates the qualification for adding a new bus lane on an urban road considering PV and BS.

Figure 2 Qualification for adding a new bus lane on urban roads (Ashak and Shliselberg 2016).

The horizontal axis denotes the bus commercial speed in kph, and the vertical axis denotes the volume of onboard passengers during peak hours. The qualified allocation is illustrated by the color red (above the function line) and the unqualified one by the color green. For example, if a road link carries more than 1,070 passengers and measures an average speed lower than 14 kph during peak hours, it’s qualified. As mentioned previously, any segment carrying more than 2,000 passengers during peak hours is qualified for bus lane allocation regardless of the commercial bus speed.

This work will focus solely on bus lane allocation for urban roads. Public Transit Data Sources

As mentioned above, in order to justify bus lane allocation, the following metrics are required for calculating the qualification of each road segment:

• Bus Volumes (BV) • Bus Speeds (BS) • Passenger Volumes (PV)

Each metric can be derived and calculated using open data sources that can be collected and processed automatically. Table 3 provides details about the data sources for each metric, and the next section will provide general details on each source.

Metric Data sources used for calculation

Bus Volumes Bus schedules (GTFS

Bus Speeds Bus historical location data (AVL) Bus schedules (GTFS)

Passenger Volumes Automatic passenger counters (APC) Bus historical location data (AVL) Bus schedules (GTFS)

Table 3 Bus lane allocation guidelines related metrics and their data sources

2.5.1. GTFS – General Transit Feed Specification

In 2006 Google published GTFS as Google Transit Feed Specification, which was later changed to General Transit Feed Specification (Hadas 2013). The specification, available online at (Google 2019), defines accurately required and optional information that operators (PTO) or agencies (PTA) should provide in order to publish their schedules on Google Maps or Google Transit services. A GTFS feed can represent a schedule for a single PTO/PTA or many.

In practice, GTFS is one of the most popular standards for publishing PT transit schedules for buses and trains, among other protocols such as Trans Exchange. According to (TransitFeeds 2020), there are more than 750 GTFS feeds available online as of July 2020. The single GTFS feed published by Israeli MoT since 2012 consolidates schedules for 36 bus and rail operators as of July 2020. It provides schedules for about 7,800 route-direction-pattern alternatives serving 28,000 bus and rail stops across the country.

GTFS requires supplying data about bus schedules and timetables, bus stops and routes. The specifications are used also outside of the Google framework and many applications and websites use GTFS feeds as inputs. The following files are commonly included in published feeds (some are required by the specification): 9 • Agency – data about the PT operator (name, code, website, etc.) • Routes – PT route numbers, codes, origin, destination and alternatives • Trips – instances of routes departing at specific times in the day • Calendar – service date range and day-in-week operations • Stop times – full details of each bus (or train) stopping event time at each route stop • Stops – Name, code and geographic coordinates for each bus stop • Shapes – Full geographical coordinates for the route shape of each trip

2.5.2. AVL – Automatic Vehicle Location

Modern bus fleets are equipped with GPS devices that report the vehicle location at all times. This data can be used for fleet management or real-time prediction for bus arrival times. The latter offers a better experience for passengers to plan their actions and expect delays if occur.

There are different standards for publishing real-time data for trip planning applications and analysts. One of them is an extension of GTFS called GTFS Realtime (GTFS-RT). However, we will focus on the protocol used in Israel and many European cities, SIRI– Standard Interface for Real-time Information. SIRI is a CEN technical standard managed by (Transmodel 2015) and provides protocols for both static and real-time PT data.

In Israel, SIRI is used to publish the real-time locations of buses and predictions for their arrival at bus stops along the route. There are two ways to publish data using SIRI protocol: VM (vehicle monitoring) and SM (station monitoring). While VM allows querying for specific vehicles, SM requires querying for data per bus stop. This method might be a good choice for bus stop real-time signage but requires more complex algorithms for extracting specific bus trip records for statistical analysis.

2.5.3. APC – Automatic Passenger Counter

An APC system counts the number of boarding and alighting passengers, usually by infrared sensors mounted on each of the bus doors. The data records produced by this system usually include door open/close times and number of alighting and boarding passenger in each stop of the trip.

It is important to mention AFC, automatic fare collection, in this context. Different operators and agencies implement a smart card system that allows passengers to pay for the bus trip in various ways without having the bus operator handles the transaction. This frees the operator to concentrate on driving. These smartcards are part of an AFC system that produces data records that can also be used for analysis of the type discussed in this work. However, due to legal limitations on data privacy and scope of the work, this data is not included here, and the APC data records are used to address the passenger volumes metric.

Data Visualization

Data Visualization is the use of computer-supported, interactive, visual representations of data to amplify cognition (Card, Mackinlay, and Shneiderman 1999). As the objective of a mathematical computation is to gain insight and not just numbers, the objective of a visualization is to gain insight as well, not just pictures (Hamming 1975). That is, the objective is to amplify exploration, decision making and provide explanations.

As opposed to scientific visualization that focuses on the physical elements of the object, many data structures do not have physical attributes. Therefore, a central challenge is how to map abstract data structures to effective visual means.

Let us focus on the meaning of cognition amplification. Focusing on the process of knowledge extraction to produce insights about data related to some task requires finding a visual representation that encodes the data points or maps them to visual structures. Data visualization can assist and promote the process of knowledge extraction, which requires data, user task and representation. If the data is incomplete or not fully available, visualization can assist with completion. If the representation is missing, the visualization can be a means to complete it. We may conclude that data visualization can assist with cognition amplification by:

• adding processing and memory resources to the users. • reducing the search time for information using visual representation to amplify pattern detection. For example, marking cholera death cases over a 19th century map (Figure 3) allowed showing a distinct pattern of death toll near water pumps, which were later discovered as sources of contamination (Tufte 2001). • enabling the performance of deduction activities using the human perception. • using perception mechanism to monitor a given live display. • encoding data using computational means that allow interaction and exploration from different dimensions by user will.

Figure 3 A 19th century map depicting clusters of Cholera disease cases near a water pump in Broad Road, London (1854) from (Tufte 2001)

As mentioned above, in order to extract knowledge, we require data, user tasks and visual representation. The following section will overview in detail a popular model used to design data visualization applications that address these three components.

11 2.6.1. The “What-Why-How” Model

Munzner suggests a model for designing data visualization tools and systems (Munzner 2015). As noted above, the model addresses the components of data visualization design:

What: Data

Why: User Tasks

How: Visual representation

The model is to be used for design and evaluation, in an iterative manner. It guides the visualization designer in understanding the data sources and needed transformations, phrasing the user tasks and selecting proper visual idioms to represent the data. Each step of the model is followed by an evaluation step to make sure all challenges are addressed properly. The outcome of this process is a data visualization design that can be coded and used by intended audience. The ‘What’ level is to be validated by domain problem characterization and data abstraction, ‘Why’ by encoding technique and interaction idiom design and the ‘How’ level by algorithm design. Following each validation phase, the designer can go back to improve the output of the previous level and so forth.

Figure 4 Iterative “What-Why-How” model where the designer should validate his work in each phase (Munzner 2015)

What – Data

Once data sources are obtained and the data is collected, the first thing is to understand its characteristics. Abstract data attributes can be classified under several categories, all detailed by Munzner in Figure 5.

Figure 5 Data, data sets and attributes (Munzner 2015)

The data collection should be observed for its type, data set type (table? network? geometry?) and especially for its attributes: are we looking at ordinal, nominal (categorical) or quantitative data?

• Categorical data – order has no meaning, so it can’t be assigned numerical order with a sense. Religion can be a good example: Muslim, Jewish, Christian, Hindi, etc. • O rdinal data – the order of the data has relative meaning within the data set: high, medium, level. • Q uantitative data – Numeric data, that can be further divided to: o Ratio data – Data centered around a zero value that carries a significance, like temperature o Interval data – Data with arbitrary zero that has no meaning, like SATs grading scale

Before moving forward, it is best to explore the data from different aspects and avoid using collected or given data as-is (this can of course be done using visualization!): what is the distribution? What are the data properties? Is the data incomplete? Subsequently, the data can be transformed, e.g. aggregated in different ways, in order to have a better form for the desired user tasks and objective.

Why – User Tasks

In this stage, the designer’s objective is to define what are the tasks the intended user is to conduct while working with the data. Munzner suggests looking at actions and targets. Actions are what the user is supposed to do with the intended application: analyze the data, search within it or query it. These actions are further sub-divided into sub-action, e.g. search can refer to lookup, browse, locate or explore. Targets are the objective of these actions within the data – is the user exploring the entire data set? Analyzing distribution, extremes or correlation within it? Two cases of targets that are worth indicating in our context are spatial data analysis and network paths and topology.

13 How – Visual Represnetaiton & Idioms

The final phase includes the ways in which the designer can encode the data in order to deliver the message in a clear and efficient method. The data should be encoded by using visual properties that can be manipulated or filtered to highlight the most important parts.

Visual properties can be position, length, shape, angle, curvature and color (the combination of hue, saturation and luminance). Different properties have different levels of effectiveness when it comes to human perception. The best visual mapping is considered to be position (Mackinlay 1986), then length, angle and slope, area, volume, color and density. It’s best to use the most accurate properties first and move along the accuracy scale when adding more visual dimensions.

The possible idioms for encoding, manipulating, faceting or reducing the data points are detailed in Figure 6.

Figure 6 Visualization idioms: encode, manipulate, facet and reduce (Munzner 2015)

Applying the What-Why-How Model

Section5 describes how we implemented the What-Why-How model in our work. We first identified and analyzed the data sources at hand. We then processed and transformed them according to the user needs and tasks. Finally, we selected the proper visual mapping, in our opinion and based on existing literature to display the data in a useful and meaningful way.

3. Related Work

This section provides an overview of related work in four fields that, put together, comprise the basis for the data analysis and development of our data visualization application:

• PT data analysis • PT related data visualization • Existing alternative designs • Data visualization evaluation methods for expert systems

Public Transit Data Analysis

First, we survey publications that address metrics related to bus lane allocation guidelines analysis in general. In the second sub-section we review specific data sources.

3.1.1. Publications Addressing Relevant Metrics

Section 2.3 described the different data sources relevant to bus lane allocation guidelines: PT schedules such as GTFS, PT AVL such as SIRI and APC (or AFC). These data sources can provide data sets to be processed and transformed to the needed metrics of bus volumes (BV), passenger volumes (PV) and bus speeds (BS).

This section will explore previous works where the aforementioned data sources were used to produce the metrics. We will also address the metric of bus delays (BD). Though the bus delays metric is not directly related to bus lane allocation qualification, it has a significant role in providing a complete picture for the analyst or planner intended to use the tool. We will elaborate on this in section 5.1.3.

All four metrics play part in PT related data sources analysis in the existing literature. We will survey works addressing single, several or all metrics combined. AVL data can also be collected from other types of vehicles, e.g. taxis or private cars. Therefore, it was also worth to survey papers that collected AVL from those sources that analyzed them in order to produce metrics such as vehicle volumes and vehicle speeds. The survey of related work is summarized in Table 4, which maps these publications to their study of different data sources and produced metrics.

(Sandim et al. 2016) systematically survey metrics and methods to analyze AVL data. GPS data was used to analyze general and taxi traffic volume (BV). Bus arrival time (BD) and average speed (BS) over a certain road link were observed in several papers.

(Moreira-Matias et al. 2015) survey works that focused on evaluating PT schedule plan reliability using AVL data and automatic control strategies to mitigate delays and bus bunching. Different metrics are surveyed, among them are bus on-time performance (BD) and speed metrics (BS).

(Lock and Erhardt 2015) and (Erhardt et al. 2014) perform a thorough process of preprocessing and analyzing AVL-APC data in order to develop an advanced analysis tool to evaluate PT service from different aspects, including BV, PV, BS and BD.

(Cortés et al. 2011) conduct an analysis of bus commercial speed (BS), by calculating the mean speed of vehicles that run on a given road link within a certain period of time.

15 (Kong et al. 2013) suggest two methods to estimate the status of traffic congestion by utilizing AVL data from taxies, where the status included vehicle speed (BS) and volume analysis (BS).

(Yoon, Noble, and Liu 2007) propose a framework to analyze traffic states using different metrics, amongst them mean speed, i.e. average speed on a specific road link (BS).

(Furth et al. 2006) suggest different uses for AVL and APC archived data. Among the suggested metrics are BS, BD and PV that assist in analyzing and improving PT management and performance. The following papers were among others that produce BD and BS:

• (Tilocca et al. 2017), the authors calculate service punctuality and regularity (BD). • (Oskarbski et al. 2015) estimate the average speed of PT vehicles based on traffic control system data. • (Watanabe et al. 2018) attempt to adjust bus timetables considering observed delays (BD) and passenger counts (PV).

PV and BV are also important metrics in the existing literature as they have multiple uses of ridership analysis, passenger crowding, Origin-Destination (O-D) analysis, network design, what-if scenarios and more. (Berkow et al. 2009) present visualization and analysis tools for common metrics in the PT service analysis realm, including BS and PV.

(Myrvoll et al. 2018) suggest a novel method to count passengers using mobile device’' WiFi signatures. Some works, such as (Gong et al. 2012), employ technics to extract insights about passengers, such as PV and O-D data, from AFC records.

Finally, some works are extensive projects that aim to analyze PT services from different aspects as in (Lock and Erhardt 2015). Another is (Peris et al. 2019), where PV is calculated together with passenger flows in order to unravel the underlying urban form based on observed activity patterns considering physical context and topology. In another work, (Bogin, Levy, and Ben-Elia 2018) analyze and visualize BS, BD and BV metrics for an entire urban network of PT service using AVL and open source tools, while most of the existing literature focuses on a subset of the routes in a certain location.

To conclude this survey, the mentioned metrics are an essential part of the suggested formulas by (Ashak and Shliselberg 2016) and highly needed in order to provide a full picture for the end-user or analyst. Nonetheless, their abundant appearances and frequent referral in the existing literature (in one form or another) are strong evidence for the need for dedicated analysis tools that support mass data sets that also provide accountability and transparency for tracing back data processing and outcome generation.

Metrics observed in papers Data # Paper Bus / Passenger Bus / Bus Delays sources # Vehicle Volumes Vehicle Volumes Speeds (Sandim et al. 2016) 1 (Moreira-Matias et al. 2015) 2 X X (Erhardt et al. 2014) / 3 X X X (Lock and Erhardt 2015) (Cortés et al. 2011) 4 (Kong et al. 2013) 5 (Yoon, Noble, and Liu 6 2007) Bus (Furth et al. 2006) 7 X X Schedule Data (Tilocca et al. 2017) 8 X X (Oskarbski et al. 2015) 9 (Watanabe et al. 2018) 10 X X X (Berkow et al. 2009) 11 X X (Myrvoll et al. 2018) 12 (Gong et al. 2012) 13 (Peris et al. 2019) 14 (Bogin et al. 2018) 15 X X X (Sandim et al. 2016) 1 X (Moreira-Matias et al. 2015) 2 X X (Erhardt et al. 2014) / 3 X X X (Lock and Erhardt 2015) (Cortés et al. 2011) 4 (Kong et al. 2013) 5 X (Yoon, Noble, and Liu 6 2007) (Furth et al. 2006) 7 X X AVL (Tilocca et al. 2017) 8 X X (Oskarbski et al. 2015) 9 (Watanabe et al. 2018) 10 X X X (Berkow et al. 2009) 11 X X (Myrvoll et al. 2018) 12 (Gong et al. 2012) 13 (Peris et al. 2019) 14 (Bogin et al. 2018) 15 X X X (Sandim et al. 2016) 1 (Moreira-Matias et al. 2015) 2 APC/ (Erhardt et al. 2014) / 3 X AFC (Lock and Erhardt 2015) (Cortés et al. 2011) 4 (Kong et al. 2013) 5

17 Metrics observed in papers Data # Paper Bus / Passenger Bus / Bus Delays sources # Vehicle Volumes Vehicle Volumes Speeds (Yoon, Noble, and Liu 6 2007) (Furth et al. 2006) 7 X (Tilocca et al. 2017) 8 (Oskarbski et al. 2015) 9 (Watanabe et al. 2018) 10 X (Berkow et al. 2009) 11 X (Myrvoll et al. 2018) 12 X (Gong et al. 2012) 13 X (Peris et al. 2019) 14 X (Bogin et al. 2018) 15 Table 4 Mapping works related to data sources analysis and metric products

3.1.2. Publications Discussing GTFS, AVL & APC Analysis In- depth

Processing these data sets into metrics requires addressing different challenges of missing data points, incorrect records, cleansing and cross-referencing. Most surveyed publications, mentioned in the previous and following sections, do not go into details about the data processing of the collected data sets of bus schedules, AVL or APC.

In a perfect world, every event of a scheduled bus stopping event (a bus stopping at a stop at a certain scheduled time) would have corresponding records for real-time arrival and departure from the stop and the number of boarding/alighting passengers. This, however, is not the case. Some scheduled bus trips don’t take place due to various reasons such as technical issues, missing staff and other factors. AVL and APC sensors might be misconfigured or broken so data is not transmitted or transmitted incorrectly. All these factors should be taken into account in the algorithms that process data sets into metrics. This section surveys several papers and publications that provide details about their data process methodologies and algorithms.

(Bogin and Ben-Elia 2018) describe a method to handle AVL data in SIRI protocol to estimate bus arrival time accuracy on temporal and spatial aspects for whole cities using R code . The SIRI data is cleansed and matched with GTFS to show the early or late arrivals of trips at bus stops. Following is a general overview of the data processing to match scheduled data records and historical real-time data records:

1. GTFS dataset is transformed to a full timetable format that specifies a record for each scheduled bus stopping event (e.g. bus that operates route 7 at 08:00 on July 9th should stop at Columbus bus stop at 09:15). 2. SIRI records are validated to be in the same date range of the scheduled data as expected. 3. If all SIRI records of a single trip are 75 meters from each other, the entire trip data is discarded (the vehicle never left the terminal, or some other malfunction took place). This is done using a convex hull. 4. SIRI records represent a bus location somewhere along its trip, so for each record the nearest stop is detected, and the distance is measured. This is because in Israel SIRI-SM is used, as opposed to SIRI-VM (see section 2.5.2) 5. GTFS timetable and SIRI data sets are merged, such that each schedule record has a corresponding SIRI record that had the minimal distance and proper collection time. 6. Further outlier detection and cleansing steps are performed.

(Luo et al. 2018) combine APC and AVL data to analyze load profiles on buses during March 2015 in the Hauge (22 million records for AVL). The authors describe different issues they encountered in the GTFS, AVL and APC records and how they addressed these issues. Data records of GTFS and AVL were matched by estimating the scheduled time of an AVL record by using the actual arrival time and the delay reported by the AVL system

The authors of (Barabino et al. 2017) and (Barabino, Di Francesco, and Mozzoni 2013) describe various steps to address different issues with the data arriving from AVL, such as bus overtaking, technical failure (of the GPS transmitter for example), and interruption of Service.

19 (Erhardt et al. 2014) and (Lock and Erhardt 2015) propose a set of processing methodologies to handle AVL and APC data. In their case, the data mainly sampled on 25% of the bus population. Therefore, they also employ a method developed to expand the data to be representative of the transit system as a whole. Their data processing is described in high-level:

1. Removing duplicate or invalid records 2. Derived fields are added: alighting/boarding passenger loads, schedule deviations, flagging on-time arrival, etc. 3. GTFS is pre-processed to have a timetable style with a record for each scheduled bus stopping. 4. GTFS and AVL/APC data are matched, and the existing 25% AVL/APC records are completed using values from similar days: a. Left-side join is used to match all scheduled records with real-data records. b. For all weekdays of a certain month, create a mean of real values for each route- direction-trip-stop combination (5 records usually) c. Complete missing values using aggregated values from 2 months before and 2 months after. This brings to 93-98% of observed or imputed trips. d. A weighting factor is used to compensate and scale up missing data records for bus ridership.

The survey presented us with different methodologies to incorporate GTFS, AVL and APC data sources into valuable metrics. The main benefit of this survey was the discovery of works that specifically discuss the process and challenges of analyzing these data sources and processing them into different metrics.

Many other publications handle AVL and APC data processing for decision making purposes or further analysis, but do not go into detail about their data processing methodology. Therefore, the list of these publications is attached in Appendix B – List of reviewed papers

Public Transit Related Data Visualization

As the main objective of this work is to develop a data visualization application, it is important to survey existing literature for visualization of data that originates in AVL, APC or sources and works that visualize bus lanes related data sets.

The purpose of this survey was to develop a mind map of possible user tasks for papers related to GTFS, AVL and APC sources together with bus lanes visualizations. A mind map is a diagram for representing tasks, words, concepts, or items linked to and arranged around a central concept or subject using a non-linear graphical layout that allows the user to build an intuitive framework around a central concept. In her What-Why-How model, (Munzner 2015) provides a comprehensive description of possible user tasks. These tasks were used to classify the works and assist other researchers and analysts in exploring possible user tasks to be used when visualizing PT related data sources.

Eighty-eight papers were reviewed and classified into different categories as detailed in Table 5. About half of the corpus–- 46 publications–- were reviewed in-depth in order to extract possible user tasks and connect them to possible data sources. These works were selected as they are most relevant to the data sources mentioned above with proper and detailed visualization used in them.

The publications were classified by the following categories:

1. Data sources: AFC/smart card, APC, AVL, SIRI, GTFS, mobile phone data, real-time passenger information 2. Methods of analysis: GIS, metrics, machine learning, matching algorithms, network analysis, ontology, (non-linear) regression models, simulations, what-ifs scenarios 3. Types of visualization: complex visualizations aided in analysis, explanatory visualization, simple visualizations aided in Analysis 4. PT domain related topics: bus bunching, congestion, current network state analysis, bus lanes, dwell time, equity/accessibility, failure detection, network connectivity, regularity, ridership, scheduling, service improvement, service monitoring, speed analysis, topology, trains, transfers

Table 5 details the number of papers (88 in total) classified into each category (88 in total). Each publication can be classified into more than one category, so the total counts do not sum up to 88.

Data sources

AFC / 24 APC 10 AVL 8 GTFS 4 Smart

Mobile 1 Real-time 3 SIRI 3 data passenger informati on

Methods of analysis

GIS 3 Metrics 19 Machine 19 Matching 1 learning algorithms

Network 7 Ontology 1 (non- 3 Simulation 6 analysis linear) regression models

What-if 1 scenarios

Types of visualization

Complex 45 Explanatory 10 Simple 56 Visualizations visualization visualizations aided aided in analysis in Analysis

Public transit domain topics

Bus 5 Congestion 4 Current 17 Bus lanes 4 bunching network state analysis

Dwell 3 Equity/ 2 Failure 7 Network 2 time Accessibility connectivity Detection

Regularity 15 Ridership 2 Scheduling 12 Service 9 improvements

Service 2 Speed 1 Topology 3 Trains 1 monitoring analysis

Transfers 1 Table 5 Classification of publications to different categories as part of user task analysis

Forty-six papers were analyzed in-depth in order to identify and extract possible user tasks for analyzing PT related metrics using data visualization tools. The full review of each and every paper can be found online, here (https://www.researchgate.net/publication/343862774_Exploration_of_user_task_landscape_for_DBL _related_data).

How the mind map was used

According to (Munzner 2015), each visualization user task can be composed of an action and a target. To that, we add patterns and aspects to create a comprehensive user task. So, a user task is composed of:

action + target(s) + pattern(s) + aspect(s)

For example, overview the distribution of bus lanes in the city center.

Many combinations of the task parts exist in the reviewed papers, and in theory. However, one should use her logic when combining parts to generate a user task. For example, there is no sense in a user task such as “Detect outliers in temporal/spatial distribution of bus dwell time and passenger trip needs”.

Dashed orange arrows (----) indicate tuples of patterns or aspects mentioned in many papers together. For example, one or more papers examined the connection between ‘frequency’ and ‘passenger loads’:

Figure 7 a section of the PT-related visualization user tasks depicting a connection between‘'frequnecy’' and ‘'passenger load’'- 2 targets that appear together in many publications

The following figures display the four components of a visualization user tasks in the context of PT data analysis as reflected in the papers mentioned above. Figure 8 displays the different actions that were suggested for end users to perform when analyzing PT related data sources using visualization tools.

Figure 8 Types of actions users can perform as part of visualization user tasks

Figure 9 displays the different targets surveyed in the papers. The spectrum is very wide and covers specific results, distributions, progress, outcomes and more.

Figure 9 Targets of actions when analyzing PT related data sources

The patterns displayed in Figure 10 were divided into vehicle patterns, passenger patterns and others. Vehicle patterns relate more to the supply side of PT where analysts and researchers evaluate the operational or planning aspects of the PT service. Passenger patterns aim to give more weight to the passenger experience of the service (demand)

Figure 10 Different patterns of PT related data

However, several sets of metrics tend to appear together in surveyed works, providing a more comprehensive view of the service performance and measures. For example, papers that deal with passenger loads, also deal with headway metrics. Passenger waiting times are always analyzed with bus arrival times.

The last component of aspects provides the different factors of patterns, and as seen in Figure 11, are grouped by time, passenger, space, vehicle and data aspects.

Figure 11 Different aspects of PT related data sources analysis

Space and time are important and very broad aspects of PT service as both have a great impact on service, how well it operates and whether it meets the passenger needs.

Taken together, the mind map and the paper overview indicate that repeatedly and across all aspects of PT-related data analysis, visualization tools are used to simplify the analyst’s or researcher’s work, amplify it by making sense of big data sources and helping to communicate important conclusions.

Existing Alternative Design

As far as our literature review and our research efforts, there are currently no existing interactive visualization systems that support the analysis of bus lane allocation guidelines.

4. Context

To show the generalizability of our data visualization solution, we demonstrate how our application can work with data from two major cities in Israel: Tel Aviv and Be’er Sheva.

Tel Aviv–Yafo is the 2nd largest city in Israel with a population of 462,000 (Israeli CBS 2019) persons. It is the center of the Tel Aviv metropolitan area, where around 3.6 million (40% of the country’s population) resides. The city is a major business and tourism center that attracts hundreds of thousands of people on a daily basis. It is ranked 21 out of 200 in the Israeli built density score ranking with a density of 11,031 people per square kilometer (MIU 2019).

Tel Aviv cannot be separated from its neighboring cities when it comes to mobility, PT service and other aspects. Many of the bus routes that serve Tel Aviv start or end outside of the city municipal limits. However, due to time constraints in this work the use case focuses only on the city of Tel Aviv per its municipal borders.

Be’er Sheva, which serves as the major city of the Negev area, is the 8th largest city in Israel with a population of 210,000 people. However, it is considered to be one of the most important cities in Israel as it the biggest city in southern Israel and serves as a leading business and education center of the area. It is ranked as the 55th city in the Israeli built density score with a density of 6,870 people per square kilometer. Compared to Tel Aviv, Be’er Sheva is more sprawled, with a dense city center, but sparse surrounding neighborhoods. The difference in the cities’ topology and density, both spatially and demographically, allow testing our application in two very different scenarios.

The following sections provide details about the PT service in both cities as of March 2019. This month was selected for collecting the data used in the analysis as it was considered a “regular” month where there are no holidays, schools are in session and there are no special major events that affect the PT service as a whole.

29 Public Transit in Be’er Sheva

As of March 2019, the city of Be’er Sheva is served by seven PTOs running different bus services (Israeli MoT 2019). There are two train stations in Be’er Sheva which are part of the Israeli train network operated by Israel Railways. The train stations are used almost strictly for outside commuting and inter-urban trips to other cities in the south or other metropolitan areas.

Figure 12 Be’er Sheva heavy rail train stations (blue train icons) with the Israeli railway marked in dashed black-white color (from MoT GIS system https://geo.mot.gov.il/)

The main PTO is Dan Be’er Sheva which is responsible for most of the urban bus services in the city. Other PTOs, mainly Metropolin, run inter-urban services coming and going to nearby cities or towns but also to major cities and locations all around the country. There are 151 bus routes (431 route-direction-pattern alternatives) serving the city. Table 6 shows the breakdown by operator:

PTO Number of Routes

Metropolin 61

Dan Be’er Sheva 33

Dan Badarom 22

Egged 22

Galim 6

Egged Taavura 6

Kavim 1

Table 6 Bus route counts in Be’er Sehva, by PTO

Most of the service frequency is dedicated for the main streets and points of interest (POIs) of the city: central bus station, the government complex, the Ben Gurion University, Soroka Hospital, Rager Blvd., Ben-Gurion Blvd. and Hevron Avenue. Figure 13 displays the spatial distribution of bus stops in the city and the service frequency levels where PT operates.

Figure 13 Map of the PT service in Be’er Sheva. Bus stops are marked by round blue bus icons. Service frequency is represented by the width of the red lines (from MoT GIS system https://geo.mot.gov.il/)

The temporal span of service is similar to Israel’s general span where the urban service runs from Sunday to Thursday between 5AM-1AM, 5AM-4PM on Fridays and 6PM-1AM on Saturdays. The exception is inter-urban bus services that sometimes start before 6PM on Saturdays.

31 Public Transit in Tel Aviv

As of March 2019, the city of Tel Aviv is served by nine PTOs running different bus services (Israeli MoT 2019). There are four train stations in Tel Aviv which are part of the Israeli train network operated by Israel Railways. The train stations are used mainly for commuting out and into the city. All train stations are located on Ayalon highways. Some business districts and residential areas are a walking distance from the stations, but most of the population would need to ride the bus, a car or bicycle to get to them in a reasonable time. Two more stations are located in between Tel Aviv and Holon (The two train stations at the bottom of Figure 14), but they mostly serve Holon.

Figure 14 Tel Aviv heavy rail train stations (blue icons) with the Israeli railway marked in gray color lines. City municipal borders are marked in red dashed line (from Tel Aviv GIS system https://gisn.Tel Aviv.gov.il/iview2js4)

The main PTO is Dan which is responsible for most of the urban bus services in the city. Other PTOs, mainly Egged, run urban and inter-urban services coming and going to nearby cities or towns but also to major cities and locations all around the country. There are 335 bus routes (916 route-direction-pattern alternatives) serving the city. Table 7 shows the breakdown by agency:

PTO Number of Routes

Egged 105

Dan 88

Kavim 51

Metropolin 46

Afikim 37

Superbus 4

Dan badarom 2

Nesiot Vetayarut 1

Galim 1

Table 7 Bus route counts in Tel Aviv, by PTO

Bus service frequency in Tel Aviv is considered very high throughout the city as it forms the major city of the metropolitan area and business capital of the country. Figure 15 displays the spatial distribution of the service frequency levels where PT operates.

Figure 15 Map of the PT service in Tel Aviv. Service frequency is represented by the width of the red lines (from MoT GIS system https://geo.mot.gov.il/)

33 Data Sources

The temporal context of this work relates to March 2019. When analyzing PT or mobility- related data sources, it is important to be aware of calendar effects. March 2019 was a month without any major holidays during which PT services are stopped or narrowed down and schools were in session as usual. Therefore, it is a representative period for analysis.

This section overviews the properties of each data source used in this work.

4.3.1. Open Street Map Data

The road network used for this work is taken from Open Street Map (OSM) Data, as collected from (Geofabrik 2019) on March 2019. As this work discusses bus lanes, it was important to extract and identify correctly road segments used by PT services. Section 5.1.15.1.1 discusses the definition of PT segments and the data processing required for identifying them.

The OSM data for Be’er Sheva and Tel Aviv is, unfortunately, inaccurate. The road layer shows a single geometric line for roads that have 2 directions (either one-way separated lanes or two-way). This required manual editing of the layer in order to make sure that each road has lines that truthfully represent the traffic directions using Google Maps satellite and Google Street View. Accurate road network is crucial for matching correct bus route shapes and later on data counts to the correct road segment. Using additional data sources, such as junction and traffic lights layers and GTFS route shape data, PT segments were identified and extracted for further analysis.

Figure 16 PT segment network of Be’er Sheva - The lines represent the road segments that carry any PT service delivered by buses

4.3.2. GTFS

In Israel, a single GTFS feed consolidates the schedules of all PT services in the country for 60 days from the day after its publication. The feed is updated every day around 10PM on ftp://gtfs.mot.gov.il by Israeli MoT.

For this work, we collected 31 GTFS feeds that can be used to get the most accurate schedules for each day of the month. The GTFS files were collected between Feb 28th and March 30th.

Section 5.1 discusses the data processing, but it can be stated here that each GTFS file was sliced by each city municipal borders for faster and more accurate processing. Table 8 provides a comparison between different properties of each of the cities’’ relevant slice of GTFS feed for bus services, for the feed collected on March 1st for Sunday (first day of the week in Israel) March the 3rd. The feeds can vary on a daily basis but the numbers in general are the same.

Property Be’er Sheva Tel Aviv

Number of PTOs 7 9

Number of routes 368 916

Number of trips 13,566 19,957

Number of bus stops 2,8321 7,721

Number of scheduled bus 416,322 2,803,917 stopping events

Table 8 GTFS feed properties for Be’er Sheva and Tel Aviv bus services on Sunday (working day in Israel) March the 3rd 2019 4.3.3. SIRI

Real-time data location of buses (and trains) is published in Israel using the SIRI format. As of March 2019, SIRI 2.7 is used (Israeli MoT 2020). The protocol allows querying any bus stop, using an ID used in the GTFS. The response includes records for the next bus trips that are scheduled or actually going to arrive at the stop. Table 9 provides details about each record fields:

Field Meaning

Time of recording Time stamp of the response

Monitoring Stop Code The code of the queried stop (different from ID)

Route ID Route ID to be matched to GTFS

Dated Vehicle Journey Ref A Ref number that can be used to match the specific trip to the GTFS using a dedicated matching file

Destination Stop Code The code of the destination stop (should match to GTFS)

Original aimed time The scheduled time of arrival to this stop (should at least match GTFS of the day before)

Longitude & Latitude GPS coordinates of the vehicle current location

Expected Arrival time The expected arrival time of the bus to the queried stop by the MoT forecast

Table 9 SIRI protocol response fields

35 As our objective is to analyze historical data rather than to provide passengers with bus arrival estimations, the expected arrival time field was ignored. This field is calculated by MoT using a forecasting model in order to provide passengers with an estimation of the bus arrival to the stop. Apart from being highly inaccurate, our focus was to understand when the bus actually arrived at the stop, or near it and not when it is estimated to arrive. This will be elaborated in section 5.1.3, but the general idea is using SIRI records where the buses were closest (up to 200 meters in extreme cases) to the intended stop and utilizing the record timestamp as arrival time.

All the stops in each city were queried every 30 seconds and most relevant records were used for analysis (see section 5.1.3). This methodology of querying in 30-sec interval produces dozens and hundreds of distinct records per bus trip (records are for bus position at and in between stops).

Table 10 compares the SIRI records data counts for Sunday March the 3rd between the 2 cities.

Property Be’er Sheva Tel Aviv

Number of collected bus location records (duplicates removed)1 2,352,001 9,001,049

% of schedule bus stopping events covered by a corresponding SIRI 81% 79% record

Table 10 Comparison between SIRI records collected for Be’er Sheva and Tel Aviv on March 3rd 2019 4.3.4. APC

Automatic passenger counters on PT vehicles are a new technology in Israel and the data collection and use are still considered experimental by the Ministry of Transportation. As of March 2019, Dan Be’er Sheva (Be’er Sheva principal urban PTO) has all of its vehicles mounted with APCs. Other PTOs throughout the country have some APCs and the coverage is far from complete for different reasons.

The data sets of APCs were received from MoT after internal data cleansing with records collected from different PTOs and filtered for bus stopping events in each city. Table 11 provides details about each record fields:

Field Meaning

Office line ID A line code to be used to match the specific route to the GTFS the route description field in GTFS

Date and time Date and time of the record

Planned mission time The schedule time of departure of this trip from the terminal

Station ID Code of the bus stop

Station order per schedule The ordinal number of the stop on the route

Trip ID A trip ID that can be matched to GTFS using a dedicated matching file

1 It is possible that different queries retrieve the same record (e.g. bus stays in one place for more than.1 minute). Counts in this table only take into account such duplication removal, not further data processing. 36

Field Meaning

Door open and close time Recorded times of opening and closing the bus doors

Passenger alighting and boarding counts Count of alighting and boarding passenger according to the counter

On-board passenger counts Calculated number of on-board passenger counts (after an internal process to fix technical issues with collection)

Table 11 APC fields

As mentioned, the APC coverage is very low, so time-series analysis and SIRI records were used to impute missing counts. This process is described in section 5.1.3.4,

Table 12 compares the APC records data counts for Sunday March the 3rd between the 2 cities.

Property Be’er Sheva Tel Aviv

Number of collected APC records 45,580 13,627

% of schedule bus stopping events covered by a corresponding 42% 3% APC record after imputation

Table 12 Comparison between APC records collected for Be’er Sheva and Tel Aviv on March 3rd 2019

It is clear that the current passenger counts cannot be used for analyzing bus lane allocation qualification in Tel Aviv. As mentioned before, the passenger counts data sets are yet sparse and should be improved in future iterations once more data becomes available. Be’er Sheva records are being used for demonstration in the tool.

37 5. Development Methodology “What” – Data

In this section, we define terms and metrics relevant for the bus lane allocation guidelines. For each metric and term, we provide an overview of the data processing that converts the data source records (OSM, GTFS, SIRI & APC) to those final metrics before visualization mapping.

5.1.1. Public Transit Segment Network

Bus lanes should only be allocated on roads that carry PT buses. When PT, transportation or urban planners address PT in their works, it is custom to snap bus stops to the nearest junction and work from there. We, however, feel that this methodology might skew the results of the data analysis or create too many anomalies due to the geometric changes.

Bus volumes can change only at junctions (or terminals). That is, if a bus turns at a junction it cannot be counted as riding the next segment of the road it was already on. Passenger volumes can, however, change on both bus stops and junctions. A passenger on-board a turning bus is not be counted on the next onward road segment, as much as a passenger that alights at a bus stop is not counted on the next road segment the bus runs on.

We therefore use a notion of a Public Transit Segment. A PT segment is a road link that carries PT buses and delimited by either a junction or a bus stop. There are four types of PT segments:

1. Junction - Junction 2. Junction - Bus Stop 3. Bus Stop - Junction 4. Bus Stop - Bus Stop

Junction / traffic lights Bus stops Road links that carry buses

Figure 17 Illustration of PT segments delimited by either a junction, traffic lights or a bus stop

Building the City PT Segment Network

We present the steps we used to build a city’s PT segment network, using Open Street Map (OSM) for road geo-data, GTFS for route geo-data and junction/traffic light data provided by Israeli CBS. The GIS analysis was done using the open-source platform for GIS processing QGIS 3.6.2 and a single step using ArcMap.

1. The following layers were loaded/converted to ITM projection (ESPG 2039): a. OSM road network (multi linestring layer) b. GTFS bus route shapes (multi linestring layer)

c. Junctions (point layer) d. Traffic lights (point layer) 2. O SM road layer was filtered to include only road of the following types: • motorway • primary • residential • secondary • tertiary • service • trunk 3. O SM road, bus stop, junction and traffic light layers were limited to the city’s borders only (manually or by intersecting with a dedicated layer) 4. PT roads layer for the city was created: a. A buffer of 20 meters was added to the GTFS route shapes layer. b. The road layer was intersected with the buffered GTFS route layer which outputs the PT roads layer containing only roads that carry PT bus services. c. Any needed manual fixes were performed (missing direction, redundant elements such as roundabouts). For example, the highlighted street in Figure 18 carries two- way traffic, including buses. It is required to split the line string to into two-line strings that represent both traffic directions. d. The layer was dissolved into one multi-linestring and later split by junctions / traffic lights / stops.

Figure 18 Yeffet street in Tel Aviv, illustrated on OSM. Though the highlighted road link carries two-way traffic, the OSM linestring displays one-way traffic only. It was split it into two lines to support two-way traffic

5. Create a bus-stop-junction-traffic-light layer: a. Redundant junction points were removed by buffering the traffic lights points and deleting any intersecting points. Figure 19 shows on the left-hand side a set of 3 red points representing lights and a green point representing a junction.

39 b. The stops, traffic lights and remaining junctions were merged to create the joint layer.

Figure 19 Salame street in Tel Aviv. On the left-hand side a set of 3 red points representing traffic lights and a green point representing a junction – these were merged. On the right-hand side, a green point represents a junction. The point was buffered so it would ‘touch’ all intersecting lines.

6. The bus-stop-junction-traffic-light layer was snapped to the PT road layer using 30-meter tolerance. Any duplicate points were removed and the points were buffered to touch all directions (see an example in Figure 19). 7. The city PT segments layer was created by splitting the PT road layer using the bus-stop- junction-traffic-light layer (in ArcMap as QGIS performance was poor with irrelevant output)

Figure 20 illustrates the general process of combining GTFS route data, OSM road network, traffic lights, junctions and bus stops layers into a PT segment network.

Figure 20 Illustration of the PT segment network building process

The PT segment layer can now be used for further data processing. Each of our metrics (BS, BS, BD & PV) will be calculated per each PT segment in the city during various time scopes.

5.1.2. Bus Lane Allocation Metrics Definition

As described in section 2.4.2, the MoT bus lane allocation guidelines take into account three metrics:

1. Bus Volumes (BV) 2. Bus Speeds (BS) 3. Passenger Volumes (PV)

Our visualization application will also display Bus Delays (BD) data in order to provide a complete picture for the analyst or PT planner using the system.

Each metric is calculated over a certain period of time for each and every PT segment. Our system temporal scope based on one month of data - for March 2019. That means that the data used for processing and visualization was collected for the entire month.

The analysis of PT-related data should be done according to the temporal scope and operational patterns of PT services. Per section 2.3, we processed the data using the following day-of-week periods:

• Sunday • Thursday • Friday • Saturday • Monday-Wednesday • Sunday-Thursday • Friday-Saturday

Additionally, we break down the temporal scope into time-of-day periods. Table 13 details time-of- day periods used in this work according to commute patterns in Israel and aspiring from other PT data analysis systems (Ayalon Highways 2020):

Time-of-day period Hour span

Morning early peak 6AM-8:30AM

Morning late peak 8:30AM-11AM

Noon off-peak 11AM-3PM

Afternoon peak 3PM-7PM

Evening 7PM-11PM

Table 13 Mapping PT services time-of-day periods to hour spans

These periods are the end result of the system design and following a revision based on the expert review process described in section 7.

Following are the formal definition for each metric.

Bus Volumes

Bus volumes on PT segment, denoted as 퐵푉푝푡푠, is the average bus trip count during a period of the day. The bus volumes are based on scheduled service data (GTFS) in order to reflect the intended

41 use of a certain PT segment, as opposed to actual use that may be lacking due to technical issues, shortage of drivers and more.

∑퐻 푡푟 ∑퐷 ℎ=1 푑ℎ 퐵푉 = 푑=1 퐻 where 푝푡푠 퐷

푡푟푑ℎ – Total count of bus trips travelling on PT segment 푝푡푠 during day 푑 hour ℎ

퐻–- number of hours during the observed time span

D – number of days during the observed time span

Equation 3 Bus Volumes on a given PT segment

Example:

Let us assume that the observed dates and times are 3 specific calendar days, Mon-Wed, during morning early peak at 06:00-08:30AM. On Public Transit segment #105, at 06:00-8:30AM, 3 routes are running with a different number of trips per route on Monday, Tuesday and Wednesday:

• R1 has 1 trip departing at every hour h, at h:00 • R2 has 3 trips departing at every hour h, at h:00, h:15, h:30 • R3 has 2 trip departing at every hour h, at h:20 and h:45

PT segment #105 starts at a junction and ends on a bus stop that serves all three routes.

Table 14 displays the count of buses for each route-trip at 06:00-08:30AM.

Day Monday Tuesday Wednesday

Route R1 R2 R2 R2 R3 R3 R1 R2 R2 R2 R3 R3 R1 R2 R2 R2 R3 R3 -trips :00 :00 :15 :30 :20 :45 :00 :00 :15 :30 :20 :45 :00 :00 :15 :30 :20 :45

6AM- 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 7AM

7AM- 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 8AM

8AM- 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 8:30AM

Table 14 Example data for calculating BV metric. Blank cells represent trips outside of the time scope

6+6+5 6+6+5 6+6+5 + + The 퐵푉 at 06:00AM-08:30AM on Mon-Wed is 2.5 2.5 2.5 =6.8 buses 105 3

Bus Speeds

Bus Speeds on PT segment, denoted as 퐵푆푝푡푠, is the average speed of all bus trips during a certain time span of hours H in kph:

∑퐻 푎푣푔푆푝푑 ∑퐷 ℎ=1 퐵푆 = 푑=1 퐻 where 푝푡푠 퐷

푎푣푔푆푝푑 – Average speeds of all bus trips travelling on PT segment 푝푡푠 during day 푑 hour ℎ

퐻–- number of hours during the time span

D – number of days during the observed time span

Equation 4 Bus Speeds on a given PT segment

Example:

To continue the previous example, Table 15 displays sampled bus speeds for each route-trip at 06:00AM-08:30AM in kph:

Day Monday Tuesday Wednesday

Route R1 R2 R2 R2 R3 R3 R1 R2 R2 R2 R3 R3 R1 R2 R2 R2 R3 R3 -trips :00 :00 :15 :30 :20 :45 :00 :00 :15 :30 :20 :45 :00 :00 :15 :30 :20 :45

6AM- 50 40 45 30 40 23 30 50 40 45 30 40 23 30 50 40 45 30 7AM

7AM- 20 10 12 14 19 20 45 20 10 12 14 19 20 45 20 10 12 14 8AM

8AM- 12 7 8 14 20 12 12 7 8 14 12 12 12 7 8 8:30AM

Table 15 Example data for calculating BS metric. Blank cells represent trips outside of the time scope

38+15.8+12.2 39.1+20+10.6 36.3+201.1+10.2 + + The 퐵푆 at 06:00AM-08:30AM on Mon-Wed is 2.5 2.5 2.5 = 27 kph 푝푡푠 3

Bus Delays

The BD metric measures deviations from schedule. Some buses arrive to late at stops compared to the schedule, but some arrive too early. This is not a major operational problem for the PTO, but more of a problem of service reliability for passengers (Walker 2012).

Bus Delays on PT segment, denoted as 퐵퐷푝푡푠, is the average deviation of the actual bus stopping event times from schedule times at stops of 푝푡푠 during a certain time span of hours 퐻 in minutes:

∑퐻 푎푣푔퐷푒푙 ∑퐷 ℎ=1 푑ℎ 퐵퐷 = 푑=1 퐻 where 푝푡푠 퐷

푎푣푔퐷푒푙푑ℎ – Average delay of all bus trips travelling on PT segment 푝푡푠 during day 푑 hour ℎ

퐻–- number of hours during the time span

D – number of days during the observed time span

Equation 5 Bus Delays on a given PT segment

43 Example:

To continue the previous example, Table 16 displays sampled bus delays for each route-trip at 06:00AM-08:30AM in minutes:

Day Monday Tuesday Wednesday

Route R1 R2 R2 R2 R3 R3 R1 R2 R2 R2 R3 R3 R1 R2 R2 R2 R3 R3 -trips :00 :00 :15 :30 :20 :45 :00 :00 :15 :30 :20 :45 :00 :00 :15 :30 :20 :45

6AM- 0 1 -2 0 1 -2 1 0 1 20 10 1 -3 -5 2 0 0 0 7AM

7AM- 4 5 12 2 1 4 2 4 5 0 7 8 1 7 15 10 -1 -7 8AM

8AM- 1 -4 20 10 8 7 1 -4 0 4 10 2 -9 10 -8 8:30AM

Table 16 Example data for calculating BD metric. Blank cells represent trips outside of the time scope

−0.3+4.67+7 5.5+4.3+1.6 −1+4.2+1 + + The 퐵퐷 at 06:00AM-08:30AM on Mon-Wed is 2.5 2.5 2.5 = 3.6 minutes of delay 푝푡푠 3

Passenger Volumes

Passenger volumes on PT segment, denoted as 푃푉푡푝푠, is the average on-board passenger count during a certain time span of hours:

∑퐻 푡푟푝 ∑퐷 ℎ=1 ℎ푑 푃푉 = 푑=1 퐻 where 푝푡푠 퐷

푡푟푝푑ℎ – Total count of on-board passengers travelling on PT segment 푝푡푠 during day 푑 hour ℎ

퐻–- number of hours during the time span

D – number of days during the observed time span

Equation 6 Passenger Volumes on a given PT segment

Example:

To continue the previous example, Table 17 displays sampled on-board passenger counts for each route-trip at 06:00AM-08:30AM:

Day Monday Tuesday Wednesday

Route R1 R2 R2 R2 R3 R3 R1 R2 R2 R2 R3 R3 R1 R2 R2 R2 R3 R3 -trips :00 :00 :15 :30 :20 :45 :00 :00 :15 :30 :20 :45 :00 :00 :15 :30 :20 :45

6AM- 5 30 50 11 12 5 30 40 7 20 10 1 3 20 60 60 60 20 7AM

7AM- 20 60 60 60 19 20 60 30 0 0 7 8 1 7 20 10 1 7 8AM

8AM- 20 80 40 23 45 80 12 10 0 4 10 2 9 10 0 8:30AM

Table 17 Example data for calculating PV metric. Blank cells represent trips outside of the time scope

113+239+208 108+105+106 223+46+31 + + The 푃푉 at 06:00AM-08:30AM on Mon-Wed is 2.5 2.5 2.5 = 157.2 passengers 105 3

5.1.3. Data Processing

The following section provides high-level overview of the data processing algorithm for each and every metric. Some of the steps are mutual for several metrics, so in order to avoid repetition, we will direct the reader to the relevant steps in previous metric data processing description. The description below applies to processing the data for one day each time using the following sources:

• OSM and PT network data collected at the beginning of the month • GTFS published the day before the day of analysis (DoA) • SIRI records collected during DoA • APC records collected during DoA

Once the metrics are output for each day of the month, they are aggregated over the span of the whole month to produce a metric for each segment for all combinations of day-of-week and time-of- week details in section 5.1.2, e.g. BV on PT segment #105 during the early morning peak hours (6AM-8:30AM) Sunday through Thursday for March 2019.

Bus Volumes

Producing BV data for a single day of analysis DoA:

1. Load following sources: a. GTFS published the day before DoA, denoted GTFS b. SIRI records collected during DoA, denoted SIRI c. PC records collected during DoA, denoted PC d. PT network segments, denoted PTNS e. OSM/GIS data of the city in question, denoted CITYGIS 2. Pre-process sources: a. Filter PTNS to exclude segments that are lower than 10 meter in length b. Limit data sources to city limits and DoA services: i. Filter GTFS to city borders per CITYGIS and DoA. ii. Filter SIRI records to city borders per CITYGIS and DoA using GPS coordinates. iii. Filter PC records to city borders per city GTFS stop codes and DoA. c. Perform geographic projection to ESPG 2039 (ITM) for any GIS-related data (GPS coordinates cannot be used for distance calculations; metric system is needed) 3. For each GTFS_route generate a gtfs_route_timetable that has a record for each bus stopping event for that day (route id, trip id, scheduled arrival time to the bus stop). 4. For each gtfs_route_timetable: a. Get route_shapes – GPS coordinates (projected) path of each route (only within city limits) b. Get route_shape_points_to_PTNS – a match between each point on the route shape to the closest PT segment c. Get stop_to_PTNS – a match between each bus stop of the route to the closest segment d. Using route_shape_points_to_PTNS, count the number of bus trips at each segment throughout the day. 45 5. Remove extreme data points using 3 standard deviations threshold. 6. Aggregate the results by the needed time-of-day periods for that day. 7. Remove extreme aggregated data points using 3 standard deviations threshold.

Bus Speeds

1. Perform steps 1 to 4c of calculating Bus Volumes 2. For each gtfs_route_timetable: a. Remove SIRI records that are outliers: i. If a trip has less than 10 records, remove all records ii. If all the trip records are less than 75 meters away from each other, remove them. This indicates of a technical failure or a bus that has never left the terminal (using convex hull). b. Generate route_siri from SIRI 2 c. Get siri_points_to_PTNS – a match between each route_siri point to the closest PT segment (remove any records that is more than 200 away from a segment) d. Get siri_points_to_stops – a match between each route_siri point to the closest bus stop of the route. e. For each trip in gtfs_route_timetable: i. Calculate the speed between each 2 consecutive records of trip in route_siri and attach it to siri_points_to_PTNS 3. Remove extreme data points using 3 standard deviations threshold. 4. Aggregate the results by the needed time-of-day periods for that day. 5. Remove extreme aggregated data points using 3 standard deviations threshold.

Bus Delays

1. Perform steps 1 to 2d of calculating Bus Speeds 2. For each trip in gtfs_route_timetable: a. Calculate the delta between scheduled arrival time and scheduled arrival using siri_points_to_stops and gtfs_route_timetable b. Attach each record in trip with the corresponding time_delta record using siri_points_to_stops 3. Remove extreme data points using 3 standard deviations threshold. 4. Aggregate the results by the needed time-of-day periods for that day. 5. Remove extreme aggregated data points using 3 standard deviations threshold.

2 It should be stated that matching SIRI and APC data records with GTFS in the Israeli context is not done directly using a trip_id or route_id field due to combability issues. An intermediate file called TripIdToDate is published along GTFS every day in order to allow the matching. 46

Passenger Volumes

Perform steps 1 to 4c of calculating Bus Volumes 1. Match PC with GTFS records so each PC record has a correct route_id and planned_departure_time from the terminal. 2. For each gtfs_route_timetable: a. Generate route_pc from PC b. Impute missing time stamp of pc records using a match with route_siri c. Get pc_points_to_PTNS – a match between each route_pc point to the closest PT segment. d. For each trip in gtfs_route_timetable: i. Attach each record in trip with the corresponding route_pc record ii. Attach records to pc_points_to_PTNS 3. Remove extreme data points using 3 standard deviations threshold. 4. Aggregate the results by the needed time-of-day periods for that day. 5. Remove extreme aggregated data points using 3 standard deviations threshold. 6. For missing values, attempt to impute records using route trip data from the same time-of- day in other days of the month. Corresponding records, with same time-of-day and weekdays/weekend day type, are aggregated using average and imputed accordingly. If a trip is missing PV, we impute it by looking at the hourly average of trips from the same route-direction on other days of the month, according to the day characteristic. Per (Benenson, Marinov, and Ben-Elia 2019), Sunday-Thursday (weekdays in Israel) are very similar, then Friday has its own patterns, and the same goes for Saturday – see Figure 21.

Figure 21 Patterns of daily boarding in Israel showing that there are 3 general patterns: weekdays (Sun- Thu), Friday and Saturday (Benenson, Marinov, and Ben-Elia 2019)

47 The full code and Readme files for processing the data can be found at the GitHub repository (Ofek 2020).

A major part of the data processing was dedicated to data cleansing and data source matching. If one is to perform an accurate analysis, these actions must be accomplished but they are time consuming, both for generating the code and executing it. Preferably, PTOs and PTAs that author the data sources will provide them in a more concise, connected and cleansed manner.

This way, researches and analysts would be able to focus on analysis, metric calculation and producing tools or insights for others to exploit.

“Why” – User Tasks

The next step of the data visualization design process is to translate user needs to user tasks. The user tasks guide the visualization designer in abstracting and transforming the data, visual mapping and idiom selection.

We discussed and interviewed five public transit planners and public transit data analysts regarding their needs and requirements from a visualization application for bus lane related data analysis. Their needs were translated into user tasks as described below, following several iterations of discussions and as also derived from the datasets at hand and objectives of the analysis.

The end objective of this work is to support analysts and planners in identifying the network-level needs of bus lanes based on the formulas and guidelines published in (Ashak and Shliselberg 2016). One can provide the end user with a list or static map of PT segments that are qualified for bus lane allocation. However, allowing the user to explore the PT segment related data within different time and space scopes offers better accountability and user confidence in the system output. Extending this manner of conduct, we wish to provide the user with the means to analyze the related datasets at several levels. This will allow the user to build confidence with the system calculations and understand different aspects of the data.

Therefore, the user tasks are split into three levels:

1. Analyze metric distribution 2. Analyze metric interaction 3. Overview qualification for bus lane allocation

The idea is that the user can analyze datasets independently of each other, and as she moves up the scale, the analysis becomes more complex including different combinations of the datasets. All tasks are derived from the datasets at hand and the purpose of analyzing bus lane related metrics.

5.2.1. Specifying User Tasks

According to the What-Why-How model described in (Munzner 2015), it is important to describe user tasks in a domain-independent terms as much as possible, that is general task abstraction. The reason is that the use of domain-specific terms for user task abstraction makes it hard to compare different visualization tools aimed at different data domains. We will describe user tasks in both domain-specific terms and general terminology as much as possible.

Level 1–- Analyze Metric Distribution

Domain-independent description

Explore the distribution in patterns of countable data considering temporal and spatial distributions / network layouts.

Sub tasks:

1. Overview dataset distribution patterns as function of time and space. 2. Detect extremes in patterns of countable data as function of time and space

Bussleneck user task description

Explore the distribution and extremes of BV, BS, BD and PV considering temporal and spatial distributions.

49 Level 2 – Anlayze Metric Interaction

Domain-independent description

Detect correlations between different datasets as a function of spatial data points (network links) and time periods.

Bussleneck user task description

Detect correlations between BV & BS or PV & BS as a function of PT segments considering temporal and spatial scopes.

Level 3 – Overview Qualification for Bus Lane Allocation

Domain-independent description

Detect links in a networks and data points with certain properties, considering temporal and spatial distributions.

Bussleneck user task description

Detect PT segments that are (not) qualified to different types of bus lane allocation, considering temporal and spatial distributions.

“How” – Bussleneck

In this work, we have decided to focus on demonstrating the capabilities of data visualization in supporting decision making through charts and maps. The 3 levels of analysis are meant to introduce better user confidence with the processed data and provide a solid basis for the bus lane allocation qualification assigned to each PT segment.

Visual mapping (or encoding) is the process where data metrics are mapped to visual marks and channels, as described in section 2.6.1.3.

Extensive research has been conducted in the fields of spatiotemporal data visualization and specifically visualization of PT-related data as described in section 3.2. In this work we therefore combine existing building blocks to create a multi-level analysis tool with high accountability and confidence in the data analysis process.

5.3.1. Visualization Mapping (Building Blocks)

Table 18 describes the suggested visual mapping, based on previous research and state-of-the-art works. These were implemented in the application.

Metric Name Units Visual Mapping Interaction

Level 1 Tasks

Bus Volumes Mean bus counts • Histogram showing the Selection of one/ per segment within distribution of the metric multi segments in time period over PT segments each chart • Plotting lines over a highlights the Passenger Volumes Mean passenger geographic map segments on the counts per segment map while within time period • Sequential color scheme to indicate change in filtering out other Bus Speeds Mean bus speed value levels components in (kph) per segment • For BD, diverging color the chart within time period scheme to account for Bus Delays Mean bus delay positive/negative values (minutes) per segment within time period

Level 2 Tasks

Correlation between Same units as • Scatter plot showing the Selection of one/ BV & BS described above, per interaction between multi segments in each metric metrics per PT segment. each chart Correlation between • Each axis represents a highlights the PV & BS different metric segments on the • Plotting lines over a map while geographic map filtering out other • Both chart and map components in elements are colored the chart using a bi-variate color

51 scheme that represents

the mutual behavior of both selected metrics (Brewer 2002)

Level 3 Tasks • Scatter plot • Selection of Bus lane allocation Boolean – qualified superimposed with one/ multi qualification by type or not dotted line graph guiding segments in to the cut points of each chart allocation qualification highlights the • Plotting lines over a segments on geographic map the map while filtering out • Both chart and map other elements are colored components in using a 2-color palette to the chart visualize qualification for bus lane allocation • Selecting different types of allocation

Table 18 Detailed description of metrics and their visual mapping 5.3.2. Controllers and Filtering options

The mind map in section 3.2 showed us how essential it is to consider the spatial and temporal aspects of PT services. We used the following controllers and filters to allow the user to view different aspects of the data, while striving to minimize the need remember previous selection or analysis outcomes: • Metric selection per view – selection is kept across views unless the user changes it. • Filter by day-of-week - selection is kept across views. • Filter by time-of-day - selection is kept across views. • Filter by PT segments data points or by metric values - selection is kept across views. 5.3.3. General interaction techniques:

We previously mentioned our wish to provide the user with an application that is based on charts and maps. To amplify user abilities when using the application, we wish to ease on the user’s cognition by showing her more data, selecting different slices of data points, and most importantly by connecting quantitative and spatial aspects by implementing the following techniques: • Hover for details of data point • Multiselect of several data points • Brushing between map and charts

6. Bussleneck – Comprehensive Analysis Application of Israeli MoT Bus Lane Allocation Guidelines

Our application, Bussleneck, is comprised of 3 views that allow comprehensive analysis of bus lane allocation guidelines:

1. Analyze metric distribution 2. Analyze metric interaction 3. Overview qualification for bus lane allocation Bussleneck Views

This section describes the application’s views, components and controllers. The second and third sub-sections integrate and demonstrate how all these elements work together using case studies for Be’er Sheva and Tel Aviv All views share the same structure as can be seen in Figure 22:

1. View navigator 2. Chart and map title providing details on selected metrics and day-of-week/time-of-day filters 3. Controllers and filters – selection of metrics, day-of-week, time-of-day and allocation type (latter in 3rd view only) 4. Chart area – histogram or scatter plot 5. Map area with plotted color-coded PT segments

1 2 5 3 4

Figure 22 Bussleneck view layout 6.1.1. View 1: Analyze Metric Distribution

In the first view, the user can analyze the quantitative and spatial distribution of PT segments as a function of every metric: BV, BS, BD and PV. Figure 22 displays a screenshot of the first view. As one can see, on the right-hand side a histogram displays the distribution of PT segments count as function of BV (the selected metric in component #3). For example, there are 427 PT segments in Be’er Sheva that carry, in average, 5-10 PT buses per hour during the selected day-of-week and time-of-day. The data is displayed for Sunday(s) during early morning peak as seen in component #3.

53 On the left hand-side, a map displays the PT segments spatial distribution where each segment is color-coded using the same color palette and scale used for the histogram.

The map and the chart are linked, so the user can filter either one of them to focus on specific data points. For example, in Figure 23, the user filtered-in all the segments that carry buses running in an average speed of 0-10 kph on Sundays during the early morning peak. The filtering feature is available across all views.

Figure 23 Distribution of PT segments that carry buses running in average speed of 0-10 kph on Sundays during early

In Figure 24, the user filtered PT segments around Rager Boulevard on the map. It seems that during the early morning peak on Sundays, those PT segments carry passenger counts from all over the distribution.

Figure 24 Distribution of PT segments around Rager Blvd. (Be’er Sheva) as a function of PV on Sundays during early morning peak

Color palette selection

Three out of the four metrics are encoded by sequential scale going from 0 to some maximal value (Mittelstädt et al. 2015) and (Bostock 2019). For these metrics (BV, BS and PV), a sequential color scheme was selected raging from white (#FFFFFF) to a fully saturated color of different hue – see Figure 25 for details.

BV color palette ranges from #FFFFF to #401010

BS color palette ranges from #FFFFF to #104010

PV color palette ranges from #FFFFF to #0E1140

Figure 25 Color palettes for the sequential metrics: BV, BS and PV

BD, however, has a diverging scale as it can represent both bus delays (+), on-time arrival (0) or bus ahead of schedule (-). The diverging color palette in Figure 26 was selected for this metric. Figure 27 displays a user selection to view the distribution of PT segments as a function of BD.

Figure 26 Diverging color palette for BD metric

Figure 27 Distribution of PT segments in Be’er Sheva as a function of BD on Sundays during early morning peak

A note about the dark background. During the expert review (see section 7.2), a white background was used to visualize the data with different color palettes more appropriate for this shade of color as seen in Figure 28. Following experts’ comments and internal discussion, it was decided that sequential color schemes raging from white to some fully saturated hue would be more effective. This is the reason the background was changed to be dark, and the end result appears above. We do consider the option to allow users to switch between light and dark modes, to grant users more discretion over the visualization.

Figure 28 Bussleneck in light mode as presented during the expert review

6.1.2. View 2: Analyze Metric Interaction

In the 2nd view, ‘Analyze Metric Interaction’, users can analyze the interaction between 2 sets of metrics:

• BV & BS • PV & BS

These metric combinations are used in the bus lane allocation guidelines.

Figure 29 displays a screenshot of the 2nd view. On the left-hand side, a map shows the geographical distribution of PT segments, as before. On the right-hand side, a scatter plot shows the interaction between the metrics selected. In this case, the x-axis accounts for BS and y-axis to BV. Each point in the scatter plot represents a PT segment.

Figure 29 Interaction between PT segments metrics: BV & BS on Be’er Sheva on Sundays during early morning peak. A bi-variate color scheme is used to represent the interaction between the metrics per each PT segment (point in the scatter plot)

In order to account for the user task of analyzing the interaction, we have decided to use a bi- variate color scheme (Brewer 2002). A bi-variate color scheme includes 2 hues, each corresponds to one of the variables. Each of the variable values is classified to 3-level classes. The low-end class is mapped to very bright color, e.g. white, and the high-end to a fully saturated hue.

Figure 30 shows 2 gradual color schemes combined into a bi-var color scheme for 2 metrics.

Figure 30 Creation of bi-var color schemes for Bus Volumes and Bus Speeds

The single metric color schemes have a single hue that moves from low saturation to high saturation. Both schemes are super-imposed and thus a 3x3 color palette is generated. This blend of colors shows how the two metrics behave in different scenarios. For example, a data point that has low values for both metrics, will be of very light in color, the light pink at the bottom-left corner. A data point that holds high values for both metrics, will be deep blue using this color scheme.

The great strength of using this kind of mapping, though might take a moment or two to grasp, is the corresponding colors on the map.

In Figure 31, the user zooms in on Rager Blvd. in Be’er Sheva. We can see many segments in highly saturated or even dark pink. This indicates that many buses are using the PT segments on Rager.

Figure 31 Zoom-in on Rager Blvd. in the 2nd view (Analyze metric interaction)

Moreover, these are segments that have low or medium speed (see the upper-left corner of the scatter plot in Figure 29) and therefore are natural candidates for bus priority means. It should be noted that in this view there is no reference to bus lane allocation. This view shows the interaction between relevant metrics with no indication of qualification.

57 6.1.3. View 3: Overview Qualification for Bus Lane Allocation

The 3rd and last view is dedicated to analyzing the bus lane allocation guidelines.

The user can choose between different types of allocation:

• Adding a new lane • Convert a lane out of two existing ones • Convert a lane out of three existing ones

Figure 32 Overview qualification for bus lane allocation by the combination of BV & BS on Sundays during early morning peak

In Figure 32, the user can check if each and every PT segment (points in the scatter plot) is qualified to bus lane allocation of “add new lane” type. Green points are qualified, while orange segments are not. To indicate a clear distinction and reference the MoT charts (see Figure 2), a purple line is added to the scatter plot dividing between the qualified and unqualified segments.

As before, the same color palette is used to encode the PT segments on the map, and it is visible that many PT segments on Rager Blvd. and the old city of Be’er Sheva are qualified for bus lane allocation.

Bringing It All Together

In this section, we will provide an end-to-end use-case that describes how the different views are connected. As mentioned earlier, we wish to provide the user confidence with the data and accountability of the end results. We will see how metric, day-in-week, time-of-day, and data points filtering is aligned across the different views.

The following series of screenshots describes journey of a user where the user wishes to explore if the busiest segments on Sunday early morning peaks are qualified for bus lane allocation and what is the speed metrics for these segments.

In Figure 33, the user analyzes the BV metric distribution in Be’er Sheva. She filtered the PT segments carrying most buses at the selected times. Looking at the map, it is clear that most of these segments are at Rager and Ben-Gurion boulevards. These segments are located near major POIs in the city: Soroka hospital, Ben Gurion University, the city theatre and town hall.

Figure 33 User filters the BV histogram to focus on the busiest PT segments

The user then moves to the 2nd view, where the filtering is kept. The data points that represent PT segments that carry most buses are filtered-in and highlighted, while other data points are semi- transparent.

Figure 34 Scatter plot data points that carry most buses are highlighted (filtered-in)

Figure 34 also shows that the average speed on most of these segments is 15-27 kph. Each segment can be reviewed separately to try and understand if action is required to improve the speed on this busy section.

59 Moving to the last view, it is apparent that all these segments are qualified for bus lane allocation. Figure 35 does show that as the filtering of data points from the 1st view is maintained.

Figure 35 Scatter plot data points that carry most buses are highlighted (filtered-in) and indicated to qualify for bus lane allocation

Case Studies

As mentioned before, we were interested in implementing the application for two real-world case studies: Be’er Sheva and Tel Aviv. The following sections describe different outcomes provided by the application for data collected during March 2019.

6.3.1. Be’er Sheva

First, we look at the busiest segments in the city in terms of bus volumes. We can see in Figure 36 and Figure 37 that during the early morning peak on Sun-Thu (weekdays in Israel), some of the routes in the city do not operate yet, but only in the late morning peak period (some examples are highlighted).

Figure 36 Distribution of PT segments as function of BV during early morning peak (06:00-08:30 AM) Sun-Thu during March 2019

Figure 37 Distribution of PT segments as function of BV during late morning peak (08:30-11:00 AM) Sun- Thu during March 2019

61 We then filter the view in order to see the busiest segments, carrying more than 50 buses during the early morning peak, as seen in Figure 38.

Figure 38 Busiest PT segments (more than 50 buses on average per hour) during Sun-Thu eraly morning peak

Taking it to the next level, we see that those filtered-in segments, have varying average speeds, but mostly around 15-30 kph, as seen in Figure 39.

Figure 39 The busiest PT segments average speeds vary greatly, bus mostly found at 15-30 kph

Finally, all these segments are of course qualified for bus lane allocation, because as we have mentioned before, any PT segment that carries more than 40 buses per hour on average, is qualified for bus lane allocation. See Figure 40:

Figure 40 Filtered segments are qualified for bus lane allocation

We observe several interesting findings from Figure 40:

1. The boulevard that runs northbound is almost completely qualified for bus lane allocation. This is Rager Blvd., the city’s main street and road. In the time of collecting the data, a bus lane project was on its way. 2. Just perpendicular to Rager Blvd. is Ben Gurion Blvd. that runs east bound and is the gateway to the university and hospital. Though it is a major PT segment, it does not have a current plan for bus lane allocation. 3. The southbound counterpart of Rager Blvd. shows missing data in consistent way throughout different time periods (The figure above shows only one segment with no data due to the filtering).

Qualification for bus lane allocation based on passenger volumes seems to be lacking in data quality. For example, in Figure 41 we can observe that no PT segment carries more than 500 people on average during the early morning peak. For other periods, the same situation occurs.

Figure 41 During early morning peak, no PT segment carries more than 500 passengers on average

As more than 50% of PT segments carry at least 15 buses per hour on average, this necessitates to review the methodology of collecting and processing passenger count data.

63 6.3.2. Tel Aviv

Tel Aviv is very different from Be’er Sheva, in terms of area, population size and service frequency. Figure 42 shows us that the hourly average number of buses a PT segment carries can be as high as 220 vehicles per hour during early morning peak, whereas in Be’er Sheva the highest count was 80 buses per hour.

Figure 42 Distribution of PT segments in Tel Aviv as function of BV during early morning peak (07:00- 08:30 AM) Sun-Thu during March 2019

Figure 43 shows existing bus lanes in Tel Aviv as of March 2019 and the qualification of other PT segments for bus lane allocation during Sun-Thu at the early morning peak. The figure shows us that many segments are good candidates for bus lane allocation.

Figure 43 Qualification of PT segments qualified for bus lane allocation plotted over existing bus lanes

The bus lane allocation guidelines by (Ashak and Shliselberg 2016) dictate bus lane allocation by looking at peak times only. However, in practice many bus lanes in Tel Aviv are time-dependent and operate only at certain periods of the day. Our approach allows observing the qualification at different times. For example, Figure 44 shows us that during the early morning peak, Shaul Hamelech Blvd. is qualified for bus lane allocation, but during the after-noon peak some of the segments do not.

Figure 44 Comparison between the qualification of PT segments on Shaul Hamelech Blvd. for bus lane allocation at early morning peak (left) and after-noon peak (right)

This high level of resolution allows planning flexible bus lanes, if the authorities are interested in that.

Let us focus on the south-east side of the city, which as seen in Figure 45 has almost no bus lanes as of March 2019. It is obvious that almost all major roads in this area are qualified for bus lane allocation.

Figure 45 Distribution of PT segments as a function of qualification for bus lane allocation in the south- east part of Tel Aviv.

Observing the relation between bus volumes and bus speeds for these segments, we can see that some segments are qualified as they carry more than 40 buses per hour. Others are qualified because they carry some buses, but with low average speeds.

The north-east part of the city tells a different story. Figure 46 (eastern of Ayalon highway which is marked by two long black lines) shows us that only one bus lane exists already in this area. However, this area has more sprawled with a higher percentage of private housing and cul-de-sac inclined urban planning. The current bus service frequency in this area does not justify extensive bus lane allocation. A grid would have been a better option as a street network for better PT service.

Figure 46 Distribution of PT segments as a function of qualification for bus lane allocation in the north- east part of Tel Aviv.

7. Evaluation Data Visualization Evaluation Methods for Expert Systems

As mentioned before, an integral part of developing a data visualization application is evaluating it. Different types of tools require different types of validation. This section overviews different works discussing the evaluation of systems such as our tool which is firstly intended for domain experts such as analysts or PT/transpiration planners.

(Lam et al. 2014) explains that it is possible to conduct a case study with domain experts to evaluate a visualization tool used for visual data analysis and reasoning (VDAR).

(Elmqvist and Soo Yi 2015) goes into detail about different patterns of visualization evaluation. For expert review, they suggest providing the users with the tool with open-ended questions to promote deep insight. Expert review shortcoming is mainly not being able to conclude meaningful statistical inference.

(Carpendale 2008) and (Elmqvist and Soo Yi 2015) indicate that expert review can be conducted using a small group of users. The interview should focus on open-ended questions, but not leading ones. It is recommended to take notes while observing the user conducts the tasks to have a complete picture of the evaluation.

(Tory and Moller 2005) discusses heuristic evaluation, where experts evaluate a tool with respect to predefined heuristics and propose various recommendations:

• Preparing the interview: o Develop descriptions of a few typical users and tasks to be specific and descriptive as possible o Determine objectives and select a set of heuristics o Select experts that will be able to communicate well and who might have experience with visualization tools • Conducting the interview: o Have experts be independent and express their thoughts and intentions aloud o Focus on qualitative issues and not the heuristics o Remain neutral and do not defend the tool o Take many notes • Analyzing the results: o Analyze results as soon as possible o Try and find common themes between respondents

Expert Review

In expert reviews, experts are provided with a comprehensive description of the application’s objectives and the application itself. The experts are performing different tasks guided by the application developer and then perform tasks on their own. Lastly, the experts provide quantitative and qualitative feedback.

67 7.2.1. Sample

We recruited PT domain experts with various backgrounds. Their characteristics are described below.

Expert 1 (Male, 47) – A public transit planner with a PhD in civil engineering.

Expert 2 (Male, 38) – A public transit planner in the Tel Aviv municipality. Has relevant experience as a planner, parking and transportation model designer and public transit planning advisor.

Expert 3 (Male, 36) – Holds a PhD in Geography and has experience in building PT and transportation models and improving PT data collection.

Expert 4 (Male, 33) – Holds a M.Sc. in Urban Planning and gained experience as a public transit planner and as a data analyst.

Expert 5 (Female, 40) – Holds a M.Sc. in Urban Planning and gained vast experience as GIS developer, PT model builder and PT data analyst.

Expert 6 (Male, 40) – Works in a planning division of a public transit planning company. Has vast experience in PT planning and authors a celebrated online PT blog.

Expert 7 (Male, 32) – Transportation engineer with experience in transportation and PT planning.

Expert 8 (Male, 31) – Senior solutions engineer and a Transportation Engineer who worked as a transportation and PT planning advisor, mainly around transportation master plans.

Expert 9 (Male 31) – Senior solutions engineer. Holds a M.Sc. in Transportation Engineering. Previously worked as a PT planner and built demand models / PT simulations with emphasis on PT policies.

Expert 10 (Female, 30) – Works for the Be’er Sheva municipality. Responsible for planning bus stop locations and working with MoT on PT route planning and changes.

7.2.2. The Interview

Based on guidelines and recommendations from papers mentioned in 7.1, the interview consisted of the following steps:

1. Personal & general introduction – personal introduction of both parties, description of the research motivation and learning about the expert’s background and relevant experience. 2. Introduction of Bussleneck: • Explaining the application’s main objectives • Explaining about the concept of PT segments • Introducing the MoT bus lane allocation guidelines • Introducing the temporal and spatial use cases of the review: March 2019 PT data for the city of Be’er Sheva, Israel. • Describing data sources and the application’s views with the different visualizations being used. 3. Using Bussleneck: • Four pilot tasks – the experts followed several tasks with verbal guidance that demonstrate possible use cases of each view and one task that incorporates a cross- system analysis. • Free time with the application – the experts received free time (5-7 minutes) to explore the application’s different views. Seven optional tasks were introduced to the experts so they can follow additional suggested use cases. 4. Conclusion: • Final survey – experts were asked to answer a questionnaire to evaluate the application’s usability, ease-of-use, missing/redundant features, and more.

The interviews lasted 35-45 minutes with each respondent. A full transcript of the interview can be found in Appendix A – Full Expert Review Interview

69 7.2.3. Results

Per the quantitative results of the expert review, Bussleneck achieves its goal to provide a comprehensive analysis application of the MoT bus lane allocation guidelines. Nine out of ten experts agreed that the application achieves this goal. Figure 47 displays the scores for the quantitative on a 7 point Likert scale:

Q1 - Application’s usability score on a scale of 1 (not usable at all) and 7 (very usable)

Q2 - Application’s ease-of-use score on a scale of 1 (very hard/complicated to use) to 7 (easy and clear for use)

Q3 - Application’s intuitiveness score on a scale of 1 (very complicated and unclear to use) to 7 (very intuitive)

Q4 - Bi-variate color scheme (on the 2nd view) ease-of-use score reaging from level 1 (not clear at all) to 7 (very clear and easy to use)

Figure 47 Distribution of the scores for the quantitative questions presented to the experts following the review. Each color represents a score on the 7-point Likert scale. The average score is displayed on the right-hand side. Designed using Data Wrapper App

The verbal and written qualitative responses from the experts suggest that along with some required improvements, the application can be useful for various use cases and objectives.

It can assist in improving bus lane planning and PT planning in general (“This is a very powerful tool. It can help not only in bus lane justifications…”, Expert 3 / “decision support system”, Expert 1) and also with raising the public awareness to needed bus lanes allocation (“This tool can assist with improving public opinion towards needed bus lane on the expense of parking and general-use lanes”, Expert 4).

The combined use of the map and chart supports easy analysis and investigation (“All the data in a one-stop-shop.”, Expert 6, “Presentation on both chart and map allows better understanding of the data.” Expert 3 and “proper use of visualization, multi-dimensional presentation”, Expert 5)

The application deems to be useful and not very complicated to use (“Well done. Beautiful and good system on the usability aspect and public aspect which is absolutley shouldn’t be taken for granted”, Expert 6).

Requests and suggestions for improvements will be discussed in section 9.2.1.

8. Discussion Contribution

Bussleneck’s end objective was “to support analysts and planners in identifying the network-level needs of bus lanes based on the formulas and guidelines published by MoT”. Following the expert’s review of the end result we do believe this objective was achieved. The application provides a comprehensive approach to analyze the spatial, temporal and quantitative distribution of related metrics, the interaction between metrics and the allocation guidelines/formulas themselves.

Bussleneck is a first of its kind interactive visualization tool, which holds great potential for improving transportation planners’ work. Specifically, it provides considerable advantages over the MoT book-provided guidelines:

1. Real-world use cases To the best of our knowledge and literature review, Bussleneck is the first data visualization / GIS tool to implement any formal allocation guidelines in a real-world use case. The application uses the relevant data sources (GTFS, SIRI & APC) for a span of one month and provides interactive means for a comprehensive analysis. Looking at Be’er Sheva, taking into account bus volumes and speeds, it is obvious that a bus lane should be allocated on Rager Blvd., as actually planned in the time appropriate for the data collection. Moreover, we saw that other roads, which are not currently planned for bus lane allocation, should be considered for bus lane allocation according to the guidelines for improving the reliability of the PT service in the city.

Tel Aviv is very different from Be’er Sheva, with a more frequent and abundant PT service. The tool easily showed us that the entire south-east area of the city has insufficient number of bus lanes compared to the provided service. The north-east part does not have many bus lanes either, but also does not qualify due to its current limited service patterns. Differently from the formal bus lane allocation guidelines, our application shows where in Tel Aviv time dependent bus lanes could be allocated. This may help the municipality to communicate bus lane allocation more easily to opposing crowds as well as push the MOT to increase investments.

2. Full-day span analysis (Ashak and Shliselberg 2016) instruct to use metrics addressing PT services during peak hours. That is, bus lane allocation is a Yes/No question for a bus lane that is allocated for PT buses during all day. In reality, there are different types of bus lanes in Israel, differentiating by time spans or vehicle allowed. Time spans for example: o All day o 5AM-10PM o 8AM-10AM & 2PM-7PM o specific days o etc. Allowed vehicle types: o PT buses only o Any bus 71 o PT buses & two-wheeled motor vehicles o PT buses & taxies All these types are in addition to new high-occupancy vehicle (HOV) lanes allocated in several highways. Bussleneck provides high level of day-of-week and time-of-day granularity. It allows planners to allocate bus lanes flexibly while better balancing the different needs of the public.

3. Primarily Automated Tool Bussleneck can automatically process any GTFS, SIRI and APC data sets collected in Israel over a span of a day, week, month or more. This means that the application can be used for different locations, either single cities or full metropolitan areas. The only required manual work is for the GIS related data, the road network. It seems OSM data is not specific enough in some cases, so manual edits are required. However, given that a high- quality network data is provided (e.g. Here, Google or Apple maps data), the required manual adjustments should be minimal.

4. Additional applications not related to bus lane allocation The metrics processed and presented by Bussleneck can be used for control and real-time analysis applications: o Detecting problems with service operations in terms of bus speeds in certain segments or links o Detecting consistent gaps between scheduled arrival times and actual arrival times, which can be a departure point for more thorough analysis of different causes for delays. This can also be useful for suggesting corrections to the scheduled running times. o Identifying passenger ridership patterns in transit corridors or areas to be looked at for further analysis. o Providing a preliminary analysis application to look into level-of-service (LoS) indicators and metrics, such as spatial and temporal coverage by PT services.

9. Limitations and Future Work Limitations

The current version of our application (used in the expert review and throughout this dissertation) has one major limitation. Adding new data into the system is a semi-automated process. While a month’s worth of GTFS, SIRI and APC data sources could be easily fed and processed by the system, the GIS data is trickier. Since we used OSM data, many manual corrections were required in addition to the GIS processing that produces PT segments. The majority of the GIS processing can be automated, but the road network to be used must be accurate, with geographic properties for each and every direction of travel, as in reality.

73 Future Work

The application is intended to be deployed for public use with use cases of Tel Aviv and Be’er Sheva loaded with data sources collected during March 2019. We intend to do our best efforts to use updated data sources collected during December 2019 or January 2020. The biggest advantage to using up-to-date data is that per MoT data department, the quality and amount of APC data is much higher. Both prospect months considered to be regular – no special holidays and schools are in session. Moreover, around February 2020 the COVID-19 pandemic broke out and caused major changes in the PT services in Israel.

9.2.1. Suggested Improvements for Bussleneck

Following the expert review, different improvements were suggested by both the authors and the experts in order to provide a better user experience to end users. The improvements were divided into categories by their level of importance:

1. Major Features a. User guidance - the application was described by some experts as not intuitive at points, so a comprehensive tutorial and visual ques (tooltips, overlays, etc.) should be added during the work for the user convenience b. Filtering – the use of shift + mouse click for filtering is counter-intuitive c. Navigation – the different views should be designed as tabs to indicate that they relate to each other and some of the filtering and selections are kept across all views. d. Passenger volumes - the time-series data analysis performed to impute missing records was too specific. Each scheduled bus stopping event record that has no corresponding APC record, can be completed using data points from the same route trips taking place on similar days (weekdays/weekends) and time-of-day. There is no need to adhere to the same day-of-week specifically. e. Add a GIS layer detailing current bus lanes for planners to both see whether bus lanes respect the guidelines and analyze data in the context of the bus lane network.

2. N ice-to-have and Minor Features a. Filtering - users should be able to add data points to the currently filtered points, either on the map or the chart. b. Time-in-day periods – the morning peak time should be split into more granular periods – early morning peak and late morning peak. c. Qualified PT segments filtering - a dedicated button should filter qualified and unqualified PT segments on the bus lane allocation guidelines screen (instead of using the filter where each dot should be marked). d. Add a count of total PT segments in the observed network and the number of filtered-in segments when a filter is active. e. Add color indication in the legend for segments that are gray, i.e. have no data.

9.2.2. Suggested Further Work

Different directions and ideas for further work came up during expert review and this research.

What-if scenarios

One of the options we considered at earlier stages is what-if analysis. One of the experts also addressed this issue. Currently, the application provides insights only about the existing state. However, planners should always look into the future when planning long-term infrastructure. There are different models that predict population growth or increase/decrease in PT services according to new urban planning. These models can be integrated into Bussleneck in different manner.

One possible, and the simplest approach would be to allow users to inflate current volumes / deflate speeds by a constant percentage. This allows an easy method to predict where bus lanes might be needed in the future. More complex approaches are possible with integrating sophisticated predication models for traffic counts, population growth, etc.

Integration with AFC data sources

As the adoption of APCs on buses is very slow, a possible work around is to extract the data from AFC sources. As of July 2020, all the bus drivers in Israel do not accept cash and smart cards must be used to pay for bus trips. Smart payment using mobile apps is expected to be added to the services soon. Tap-out doesn’t exist in the Israeli bus system as of today, therefore the alighting passenger counters would have to be estimated using acceptable algorithms (Morency, Trepanier, and Bruno 2007). When payment apps would be added into the mix, passengers would be required to state their alighting stop. In any case, the AFC can be used as part of the APC missing data records imputation process. In this context, we can also add that it would be interesting to analyze the interaction between bus volumes and passenger volumes as it provides insights on mobility and supply-demand patterns.

Integration with other modes of transportation

Passengers never use PT services from door-to-door. All PT trips start/end in walking to a destination and/or from origin locations. Moreover, PT bus trips can be combined with cycling, light rail/metro, train, scooter and more. Adding GIS, passenger volume and headways data of other means of transportation can assist planners in having a comprehensive understanding of the multimodal mobility or mobility-as-a-service needs. There are different types of bus lanes and HOV lanes in Israel. Integrating additional data sources can provide comprehensive tools to better plan and allocate time-flexible and vehicle-flexible lanes of such.

Challenge the MoT bus lane allocation guidelines

The current guidelines (Ashak and Shliselberg 2016) are based on academic research and an economic analysis. Using our application, it is possible to review the guidelines in a more critical way. Are the guidelines too permissive? Are they too strict? Could additional metrics, data sources or aspects be taken into account?

Joint Planning of PT services and infrastructure

This work takes current PT routes and services as a given truth. Based on this assumption, we calculate different metrics and present outcomes of bus lane allocation guideline analysis. However, this might lead to a non-optimal result. In some cases, moving bus route paths while considering

75 bus lane allocation might offer better PT services that utilize the infrastructure in a favorable matter. This can be part of a network redesign or planning of interlining routes.

Planning infrastructure and service changes together can lead to better results, while reducing redundant service. This can also help avoiding cases where service quotas are not fit to the physical capacity of the road (i.e. too many uncoordinated buses on the same street).

10. Conclusion

In this work we developed a data visualization application to analyze data-driven bus lane allocation guidelines and demonstrated its viability and usefulness. The application’s analytical tools are based on guidelines that were published by the MoT (Ashak and Shliselberg 2016) and it relies on data that were gathered from multiple, open sources.

Our data visualization tool examined those guidelines using data from two real-world use cases of the cities of Be’er Sheva and Tel Aviv-Yafo. We addressed data sources (bus schedules, aggregated real-time data records and on-board passenger counts) collection, processing into relevant metrics and different aspects of data visualization design.

The application was evaluated by a group of experts who represent the application’s target user population of PT planners and PT related data analysts. The experts rated the application highly in terms of usability and functionality and also provided insightful suggestions for adding features and functionality in future versions of the application.

The real-world use cases show that planned bus lanes are needed and supported by the guidelines according to real data. They also suggest other potential bus lanes that can improve the PT service greatly.

We saw how the implementation of different time-of-day periods in the application can assist in planning time dependent bus lanes and which areas in the city require bus lane allocation the most.

The application will be available for public use, including source code and processed metrics. The application displays metrics for data collected during March 2019. However, the tool can be updated using up-to-date data sources by the eventual users.

77 References

Ampountolas, Konstantinos and Malcolm Kring. 2015. “Mitigating Bunching with Bus-Following Models and Bus-to-Bus Cooperation.” IEEE Conference on Intelligent Transportation Systems, Proceedings, ITSC 2015-Octob:60–65.

Anon. n.d. Israel Population Report 2020.

Ashak, Robert and Rebecca Shliselberg. 2016. Guidelines for Planning and Operating Public Transportation Bus Services. National Public Transportation Authority.

Ayalon Highways. 2020. “Ayalon Highways GIS System.”

Bak, P., H. J. Ship, A. Yaeli, Y. Nardi, E. Packer, G. Saadoun, J. Bnayahu, and L. Peterfreund. 2015. “Visual Analytics for Movement Behavior in Traffic and Transportation.” IBM Journal of Research and Development 59(2/3):10:1-10:12.

Bak, Peter, Eli Packer, Harold J. Ship, and Dolev Dotan. 2012. “Algorithmic and Visual Analysis of Spatiotemporal Stops in Movement Data.” Proceedings of the 20th International Conference on Advances in Geographic Information Systems - SIGSPATIAL ’12 (November 2012):462.

Banitta, Rinat and Spector Ben Ari, S. 2019. Public Transporation in Israel and Road Congestion. Working paper of the Knesset research unit.

Barabino, Benedetto, Massimo Di, Francesco Roberto Murru, and Roberto Murru. 2016. “An Offline Framework for Reliability Diagnosis by Automatic Vehicle Location Data.” 18(3):1–25.

Barabino, Benedetto, Massimo Di Francesco, and Sara Mozzoni. 2013. “Regularity Diagnosis by Automatic Vehicle Location Raw Data.” Public Transport 4(3):187–208.

Barabino, Benedetto, Cristian Lai, Carlino Casari, Roberto Demontis, and Sara Mozzoni. 2017. “Rethinking Transit Time Reliability by Integrating Automated Vehicle Location Data, Passenger Patterns, and Web Tools.” IEEE Transactions on Intelligent Transportation Systems 18(4):756–66.

Barabino, Benedetto, Cristian Lai, Roberto Demontis, Sara Mozzoni, Casari Carlino, Pintus Antonio, and Tilocca Proto. 2014. “Web Architecture of a Web Portal for Reliability Diagnosis of Bus Regularity.”

Benenson, Itzhak, Maria Marinov, and Eran Ben-Elia. 2019. “Unexpected Flexibility of Public Transit Usage Revealed from Mining Israel’s Smartcard Data.” in Transit Data 2019.

Berkow, Mathew, Ahmed M. El-Geneidy, Robert L. Bertini, and David Crout. 2009. “Beyond Generating Transit Performance Measures : Visualizations and Statistical Analysis Using Historical Data.” Transportation Research Record: Journal of the Transportation Research Board 2111(January 2019):158–68.

Bogin, Dror and Eran Ben-Elia. 2018. “Estimation of Public Transportation Service Reliability Gaps : Spatiotemporal Querying of Israeli Automatic Vehicle Location ( AVL ) and GTFS Data.”

Bogin, Dror, Nadav Levy, and Eran Ben-Elia. 2018. “Spatial and Temporal Estimation of the

Service Reliability of Public Transportation Using Big Data and Open Source Tools.”

Bostock, Mike. 2019. “D3 JS Sacle Chromatic Color Code Library.” GitHub.

Brewer, Cindy. 2002. “Color Use Guidelines for Mapping and Visualization.”

Brosi, Patrick. 2014. “Real-Time Movement Visualziation of Public Transit Data.” Mycotoxin Research 6(March):100.

Card, Stuart K., Jock D. Mackinlay, and Ben Shneiderman. 1999. Readings in Information Visualization: Using Vision To Think.

Carpendale, Sheelagh. 2008. “Evaluating Information Visualizations.” in Information Visualization.

Cats, Oded. 2014. “Real-Time Predictions for Light Rail Train Systems.” 2014 17th IEEE International Conference on Intelligent Transportation Systems, ITSC 2014 1535–40.

Cats, Oded and Gerasimos Loutos. 2016a. “Evaluating the Added-Value of Online Bus Arrival Prediction Schemes.” Transportation Research Part A: Policy and Practice 86(February 2018):35–55.

Cats, Oded and Gerasimos Loutos. 2016b. “Real-Time Bus Arrival Information System: An Empirical Evaluation.” Journal of Intelligent Transportation Systems: Technology, Planning, and Operations 20(2):138–51.

Ceder, Avishai. 2016. Public Transit Planning and Operation. {CRC} Press.

Chen, Wei, Fangzhou Guo, and Fei-yue Wang. 2015. “A Survey of Traffic Data Visualization.” 16(6):2970–84.

Comi, Antonio, Agostino Nuzzolo, Stefano Brinchi, and Renata Verghini. 2017. “Bus Dispatching Irregularity and Travel Time Dispersion.” 5th IEEE International Conference on Models and Technologies for Intelligent Transportation Systems, MT-ITS 2017 - Proceedings 856–60.

Cortés, Cristian E., Jaime Gibson, Antonio Gschwender, Marcela Munizaga, and Mauricio Zúñiga. 2011. “Commercial Bus Speed Diagnosis Based on GPS-Monitored Data.” 19:695–707.

Elmqvist, Niklas and Ji Soo Yi. 2015. “Patterns for Visualization Evaluation.”

Erhardt, Gregory D., Oliver Lock, Elsa Arcaute, and Michael Batty. 2014. “A Big Data Mashing Tool for Measuring Transit System Performance.” Springer Geography 257–78.

Feng, Wei and Miguel A. Figliozzi. 2015. “Empirical Analysis of Bus Bunching Characteristics Based on Bus AVL / APC Data.” 94th Annual Meeting of Transportation Research Board.

Feng, Wei, Miguel Figliozzi, and Kristina Hostetler. 2011. “Techniques to Visualize and Monitor Transit Fleet Operations Performance in Urban Areas.” Trb (February):1–16.

Furth, Peter;, Brendon; Hemily, Theo; Muller, and James; Strathman. 2006. Using Archived AVL- APC Data to Improve Transit Performance and Management.

Geofabrik. 2019. “OpenStreetMap Downloads Server.” Retrieved (https://www.geofabrik.de/geofabrik/).

79 Gokasar, Ilgin and Yigit Cetinel. 2017. “Evaluation of Bus Dwelling Patterns Using Bus GPS Data.” 5th IEEE International Conference on Models and Technologies for Intelligent Transportation Systems, MT-ITS 2017 - Proceedings 867–71.

Gong, Yongxi, Yu Liu, Yaoyu Lin, Jian Yang, Zhongyuan Duan, and Guicai Li. 2012. “Exploring Spatiotemporal Characteristics of Intra-Urban Trips Using Metro Smartcard Records.” Proceedings - 2012 20th International Conference on Geoinformatics, Geoinformatics 2012.

Google. 2019. “GTFS Static Overview.” Retrieved (https://developers.google.com/transit/gtfs).

Grace, Fattouche. 2007. “Improving High-Frequency Bus Service Reliability through Better Scheduling.” MIT.

Guido, Giuseppe, Daniele Rogano, Alessandro Vitale, Vittorio Astarita, and Demetrio Festa. 2017. “Big Data for Public Transportation: A DSS Framework.” 2017 5th IEEE International Conference on Models and Technologies for Intelligent Transportation Systems (MT-ITS) 872–77.

Hadas, Yuval. 2013. “Assessing Public Transport Systems Connectivity Based on Google Transit Data.” Journal of Transport Geography 33:105–16.

Hamming, R. W. 1975. “Numerical Methods for Scientists and Engineers.” Mathematics of Computation 29(130):648.

ISC. 2019. The Crisis in Israel Public Transporation Report.

Israeli CBS. 2019. “Israel Population 2019 by Local Authoritieis.” Retrieved July 1, 2020 .(xlsx. 2019קובץ_ישובים_/https://www.cbs.gov.il/he/publications/LochutTlushim/2019)

Israeli MoT. 2019. “Israel GTFS (March 31 2019).” Retrieved (ftp://gtfs.mot.gov.il/).

Israeli MoT. 2020. “Israel MoT SIRI Guide.”

Kong, Qing Jie, Qiankun Zhao, Chao Wei, and Yuncai Liu. 2013. “Efficient Traffic State Estimation for Large-Scale Urban Road Networks.” IEEE Transactions on Intelligent Transportation Systems 14(1):398–407.

Koutsopoulos, H. N., P. Noursalehi, Y. Zhu, and N. H. M. Wilson. 2017. “Automated Data in Transit: Recent Developments and Applications.” 5th IEEE International Conference on Models and Technologies for Intelligent Transportation Systems, MT-ITS 2017 - Proceedings 604–9.

Kurkcu, Abdullah, Fabio Miranda, Kaan Ozbay, and Claudio T. Silva. 2017. “Data Visualization Tool for Monitoring Transit Operation and Performance.” 2017 5th IEEE International Conference on Models and Technologies for Intelligent Transportation Systems (MT-ITS) 598–603.

Lam, Heidi, Enrico Bertini, Petra Isenberg, Catherine Plaisant, and Sheelagh Carpendale. 2014. “Empirical Studies in Information Visualization: Seven Scenarios.”

Lock, Oliver and Gregory D. Erhardt. 2015. “Keeping Track—The Fusion of Large, Automatically Collected Transport Data in Capturing Long-Term System Change.” in Australian Institute of

Traffic Planning and Management (AITPM) National Conference, 2015, Brisbane, Queensland, Australia.

Luo, Ding, Loïc Bonnetain, Oded Cats, and Hans van Lint. 2018. “Constructing Spatiotemporal Load Profiles of Transit Vehicles with Multiple Data Sources.” Transportation Research Record: Journal of the Transportation Research Board In press(January). 2672(8), pp. 175– 186.

Ma, Xiaolei and Yinhai Wang. 2015. “Development of A Data-Driven Platform for Transit Performance Measures Using Smart Card and GPS Data.” (July 2014).

Mackinlay, Jack. 1986. “Automating the Design of Graphical Presentations of Relational Information.” ACM Transactions on Fraphics BD. 5 17.

Mamun, Md Al and Nicholas Lownes. 2011. “A Composite Index of Public Transit Accessibility.” Journal of Public Transportation 14(2):69–87.

Mittelstädt, Sebastian, Dominik Jäckle, Florian Stoffel, and Daniel A. Keim. 2015. “ColorCAT: Guided Design of Colormaps for Combined Analysis Tasks.” in Eurographics Conference on Visualization (EuroVis).

MIU. 2019. “Trasnit Analyst Israel.” Retrieved July 1, 2020 (https://s3.eu-central- 1.amazonaws.com/transitanalystisrael-current/indexe.html).

Moreira-Matias, Luis, Joao Mendes-Moreira, Jorge Freire De Sousa, and Joao Gama. 2015. “Improving Mass Transit Operations by Using AVL-Based Systems: A Survey.” IEEE Transactions on Intelligent Transportation Systems 16(4):1636–53.

Morency, Catherine, Martin Trepanier, and Agard Bruno. 2007. “Measuring Transit Use Variability with Smart-Card Data.” Transport Policy 14(3):193–203.

Mozzoni, Sara, Roberto Murru, and Benedetto Barabino. 2017. “Identifying Irregularity Sources by Automated Location Vehicle Data.” Transportation Research Procedia 27:1179–86.

Munzner, Tamara. 2015. Visualization Analysis & Design.

Myrvoll, Tor A., Jan E. Håkegård, Tomoko Matsui, and François Septier. 2018. “Counting Public Transport Passenger Using WiFi Signatures of Mobile Devices.” IEEE Conference on Intelligent Transportation Systems, Proceedings, ITSC 2018-March:1–6.

Ofek, Shaked Kaufman. 2020. “GTFS-SIRI-PC Matching GitHub Reportsitory.” Retrieved (https://github.com/shakedk/GTFStoSiri).

Oort, Niels Van and Oded Cats. 2015. “Improving Public Transport Decision Making, Planning and Operations by Using Big Data: Cases from Sweden and the Netherlands.” IEEE Conference on Intelligent Transportation Systems, Proceedings, ITSC 2015-Octob:19–24.

Oskarbski, Jacek, Krystian Birr, Michal Miszewski, and Karol Zarski. 2015. “Estimating the Average Speed of Public Transport Vehicles Based on Traffic Control System Data.” 2015 International Conference on Models and Technologies for Intelligent Transportation Systems

81 (MT-ITS) (June):287–93.

Peris, Rafael, Santiago Martínez, Alejandro Ruiz, Patricia Bellver, Manuel Serrano, and Yuki Oyama. 2019. Transform Graphical Analysis Interface of Travel Demand.

Sandim, Miguel, Rosaldo J. F. Rossetti, Daniel C. Moura, Zafeiris Kokkinogenis, and Thiago R. P. M. Ŕubio. 2016. “Using GPS-Based AVL Data to Calculate and Predict Traffic Network Performance Metrics: A Systematic Review.” IEEE Conference on Intelligent Transportation Systems, Proceedings, ITSC 1692–99.

Tilocca, Proto, Simona Farris, Silvano Angius, Roberto Argiolas, Andrea Obino, Salvatore Secchi, Sara Mozzoni, and Benedetto Barabino. 2017. “Managing Data and Rethinking Applications in an Innovative Mid-Sized Bus Fleet.” Transportation Research Procedia 25(December):1904–24.

Tory, M. and T. Moller. 2005. “Evaluating Visualizations: Do Expert Reviews Work?” IEEE Computer Graphics and Applications.

TransitFeeds. 2020. “TransitFeeds.” Retrieved (https://transitfeeds.com/feeds).

Transmodel. 2015. “SIRI.”

Treethidtaphat, Wichai, Wasan Pattara-atikom, and Sippakorn Khaimook. 2017. “Bus Arrival Time Prediction at Any Distance of Bus Route Using Deep Neural Network Model.” 484–88.

Tufte, E. 2001. The Visual Display of Quantitative Information. Warwickshire: Graphics Press.

Walker, Jarrett. 2012. Human Transit. Island Press/Center for Resource Economics.

Watanabe, Yusuke, Toshiyuki Nakamura, Jan Dirk Schmocker, Nobuhiro Uno, and Takenori Iwamoto. 2018. “Adjusting Bus Timetables Considering Observed Delays and Passenger Numbers.” IEEE Conference on Intelligent Transportation Systems, Proceedings, ITSC 2018- March:585–90.

Yang, Xiaoguang and Linan Zhang. 2014. “A Dynamic Method to Monitor Public Transport Based on Smart Card and GPS Data.” 17th International Conference on Intelligent Transportation Systems (ITSC) 924–29.

Yoon, Jungkeun, Brian Noble, and Mingyan Liu. 2007. “Surface Street Traffic Estimation.” MobiSys’07: Proceedings of the 5th International Conference on Mobile Systems, Applications and Services (June 2007):220–32.

11. Appendices Appendix A – Full Expert Review Interview Structure

The interview was conducted in Hebrew but was translated to English for the dissertation reader.

For explanatory purposes screenshots were used at first during the interview, and for pilot tasks and following tasks the users used the actual application.

Bussleneck – Expert Review

The results of the expert review will be stored anonymously, without identifying information. The interview might be recorded to allow an after-math analysis of user actions. The recording will be used for the evaluation only and will be deleted after the analysis is complete.

Demographics

Please state your age, gender, and past or current experience with PT planning or related data analysis.

Presenting the application

Application Objective

Providing PT planner and data analysts to overview MoT bus lane qualification guidelines in real use cases using commercial bus speeds, bus volumes and on-board passenger volumes

Geographic Context

The application was developed for Be’er Sheva and Tel Aviv use cases, but the expert review will be conducted on Be’er Sheva only. The application observes urban roads and bus lanes only.

Temporal Scope

The data collected covers PT services throughout the day for every day during March 2019.

MoT Bus Lane Allocation Guidelines

The guidelines address bus lane allocation by looking at 2 sets of metrics:

1. Bus Speeds & Bus Volumes 2. Bus Speeds & Passenger Volumes

There are different types of bus lane allocation: adding a new lane, using existing out of 2 or 3 lanes and taking urban/regional road type into account.

For example, the following chart provides details about qualification of a road link (red – qualified, green – unqualified) based on bus speeds and on-board passenger volumes. The allocation here refers to allocating a bus lane out of 2 existing urban lanes. For example, links that have an average speed of up to 12 kph during peak hour and at least 1,000 onboard passengers are qualified for allocation.

Public Transit Segments

MoT bus lane allocation guidelines refer to road links in general (a road stretch between 2 junctions). However, the data processing in our application is references to Public Transit Segments. a PT segment is a link that can start and end either bus stop or a junction. When one counts buses or passengers and measure speeds, she aggregates the data for a given link. The count of on-board passengers can change in either bus stop or a junction. Bus metrics (counts and speeds) can only change in junctions. Following are several examples of PT segments:

PT Segments: 1 (junction – junction), 2 (bus stop – junction), 3 (junction – junction)

PT Segments: 4 (junction – bus stop), 5 (bus stop – bus stop), 6 (bus stop – junction)

Data Processing

The application utilizes the following metrics:

• Bus volumes per the schedules published by MoT • Bus speeds based on aggregated records of real-time data for each bus stopping event • Passenger volumes collected by MoT APC systems (time-series imputation was performed to deal with missing values) The data was aggregated using an average function for each PT segment over different day-of- week time-of-day periods. Though MoT focuses on peak hours in its guidelines, we’ve decided that is best to provide comprehensive picture and to allow planning of time-flexible bus lanes.

Presenting the Application’s Views

The objective of the application is to allow a comprehensive analysis of MoT guidelines for bus lane allocation. This is not a application that is meant to produce a final product such as a poster showing the network of recommended bus lanes. Instead, it aims to provide means to analyze the data points and calculations used by MoT guidelines.

So, the application is comprised of 3 analysis views where each one of them is the basis for the next step.

First View – Analyze Metric Distribution (quantitative, spatial and temporal distribution of each metric)

The first view allows users to analyze the quantitative, spatial and temporal distribution of each and every metric separately for all PT segments:

• Bus volumes in counts • Bus speeds in kph • Bus delays or arrivals ahead of schedule in minutes (not directly used by MoT guidelines, but provides a better understanding of the state of PT) • Bus volumes in counts

Second View – Analyze Metric Interaction

The second view allows users to analyze the interaction between taking into account spatial and temporal aspects:

• Bus speeds & bus volumes • Bus speeds & passenger volumes

Third View – Overview Bus Lane Allocation Qualification

The third view displays the bus lane allocation guidelines for each PT segments according to thresholds published by MoT:

85 • Adding a new lane (either by measuring BV & BS or PV & BS) • Using a lane out of 2 existing general lanes (either by measuring BV & BS or PV & BS) • Using a lane out of 3 existing general lanes (either by measuring BV & BS or PV & BS)

Pilot tasks for the 1st view (Analyze Metric Distribution)

We will conduct several pilot tasks together in order to learn about the best use of the application. Click on Analyze Metric Distribution

What do we see here?

On the right-hand side a histogram displays the distribution of PT segment counts per the bus volumes each segment carries on Sundays during morning peak hour (6-11AM). The map shows the PT segments locations using the same color coding to support learn about the spatial distribution of bus volumes.

Time to play!

Q: Look at the histogram. How many PT segments carry the most abundant average amount of bus volumes? Use the mouse cursor to hover the longest bar and write down the answer. A: 443 segments

Click Bus Speeds then Go

Using the mouse cursor and while pressing the Shift button, filter the 3 top-most bars – these are the bars that represent PT segments with highest average speed.

Q: Are these segments can be found mainly in city center or outskirts?

A: Outskirts.

Clear the filtering by clicking Clear Filter

Pilot tasks for the 2nd view (Analyze Metric Interaction)

Click on Analyze Metric Interaction

What do we see here?

Currently we see tools to analyze the interaction between bus volumes and bus speeds metrics.

On the right-hand side a scatter plot displays the interaction between bus speeds (x axis) and bus volumes (y volumes).

Each data point in the scatter plot represents a PT segment and the color encodes the level of each metric. For example, the more turquoise a data point color is, more buses travel on this segment, but in high speed. The pinker a data point color is, more buses travel on this segment, but in low speed. Dark blue segments would carry many buses in high speed (none are visible).

The same color scheme is used to paint the PT segments on the map.

Time to play!

Q: Using the map, indicate the names of the road that have a high count of PT segments that carry many buses in low speed (use the zoom buttons instead of scrolling)

A: Rager Blvd and the old city area

Pilot tasks for the 2nd view (Analyze Metric Interaction)

Click on Overview Qualification fur Bus Lane Allocation

What do we see here?

We currently see tools to analyze bus lane allocation guidelines by BV & BS. On the right-hand side a scatter plot shows which PT segments are qualified. As before, each data point represents a PT segments that is color-coded by qualification (green – qualified, blue – unqualified). The brown line is used a separator to make the distinction clearer3. The same color scheme is used to encode qualification over the map.

Time to play!

Q: Rager Blvd. is currently planned to have bus lanes (project already under way). Per the displayed metrics and filters, do Rager qualified for bus lane allocation?

A: Qualified for part of its segments on both directions.

Click Passenger Volumes / Bus Speeds then Go.

Q: And now, is Rager Blvd. qualified?

A: No. (note: not enough data).

Pilot tasks – Putting it all together

While still in the 3rd view, change the allocation type to Using existing out of 3 then click Go.

Go to the 1st view by clicking Analyze Metric Distribution.

Display data for Bus Delays by clicking the dedicated button.

Select the 2 bars that represent the most severe delays. Please keep in mind that actually we’re not looking at bus delay, but deviations from schedule in general. Use shift + mouse cursor to select the 2 top-most bars.

Go to the 3rd view by clicking Overview Qualification for Bus Lane Allocations

3 As mentioned before, the light background and other color palettes of the tool were later switched to provide a better user experience. The colors and screenshots seen here in the interview are as they were at the time of conducting the interview itself. 87 It is apparent that all PT segments with severe delays are filtered in. Their data points are highlighted by a thin black stroke.

Q: Do all filtered in segments are qualified for bus lane allocation?

A: No

Time to go wild!

During the next 5 minutes, please use the application as best to your imagination. Go from one view to another and try some filtering. If you wish, a set of questions is provided to steer you toward possible use cases of the application.

Q: Where in the city buses are delays at most on Sunday-Thursday mornings?

A: City outskirts and the bypass road

Q: Where in the city buses are mostly ahead of schedule on Sunday-Thursday afternoons?

A: Southern part of the city.

Q: During Sunday morning peak, on which direction of Ben Gurion Blvd. buses travel slower?

A: Westbound

Q: During Sunday-Thursday mornings, is there a substantial difference between the spatial distribution of PT segments with many buses with high speed and PT segments with many buses with low speed?

A: Yes

Q: During Sunday-Thursday mornings, for which allocation types is the Rager PT segment between Wingate & Shazar next to Soroka hospital is qualified?

A: All 3 types

Q: During Sunday-Thursday mornings, are PT segments that carry highest bus volumes are also qualified for bus lane allocation?

A: Yes

Q: Do any segments qualify for bus lane by looking at Saturday night data for bus volumes?

A: Yes, 10 PT segments are qualified

The last part of the interview as getting feedback by the usability questionnaire. Both questions and answers can be found in the next section.

Appendix B – List of reviewed papers

1. (Watanabe et al. 2018) 2. (Mozzoni, Murru, and Barabino 2017) 3. (Koutsopoulos et al. 2017) 4. (Comi et al. 2017) 5. (Treethidtaphat, Pattara-atikom, and Khaimook 2017) 6. (Tilocca et al. 2017) 7. (Kurkcu et al. 2017) 8. (Guido et al. 2017) 9. (Gokasar and Cetinel 2017) 10. (Cats and Loutos 2016a, 2016b) 11. (Cats 2014) 12. (Oort and Cats 2015) 13. (Sandim et al. 2016) 14. (Barabino et al. 2016) 15. (Barabino et al. 2014) 16. (Barabino et al. 2013) 17. (Moreira-Matias et al. 2015) 18. (Chen, Guo, and Wang 2015) 19. (Yang and Zhang 2014) 20. (Brosi 2014) 21. (Feng, Figliozzi, and Hostetler 2011) 22. (Feng and Figliozzi 2015) 23. (Bak et al. 2015) 24. (Bak et al. 2012) 25. (Oskarbski et al. 2015) 26. (Ma and Wang 2015) 27. (Grace 2007) 28. (Ampountolas and Kring 2015)

89 תקציר ה תחבורהל ציבורית )תח"צ( תפקיד חיוני במערכת תחבורה מקיימת. בנוסף להליכה, רכיבה על אופניים ואמצעי דוניידות - גלגליים זעירים, תח"צ מספקת פתרון זול ויחסית יעילרבבות להנעת בני אדם בתווך העירוני ומחוצה לו. באזורים צפופים, רכבות קלות וכבדות מהוות את עמוד הש דרה של מערכת התחבורה הציבורית, בעוד אוטובוסים מספקים כיסוי גדול יותר וגמישות רבה יותר בתכנון ותפעול שירותי תח"צ. עם זאת, במקומות מסוימים אוטובוסים מהווים את השדרה של המערכת. בישראל, למשל, נסיעות באוטובוס מהוות 85% מנסיעות 85% ( .התח "צ ISC 2019והשאר) באמצעים אחרים קעל מנת לספ שירות תח"צ אמין באוטובוסים, דרוש להסיר חסמים ועיכובים מהדרך. אוטובוסים מתעכבים, בין השאר, בגלל תנועת רכבים אחרים, עומסי תנועה, יציאה מאוחרת מהמסוף, סגנון נהיגה לא אחיד, תשלום במזומן ועוד. אם ברצוננו להעלות את מספר הנוסעים בתח"צ ולשפר את חווית הנסיעה מדלת לדלת, יש לטפל בכל אחת מהבעיות המוזכרות. אחד מגורמי העיכוב המשמעותיים הוא הגודש ותנועת כלי הרכב הכללית לנוע במהירות לאוטובוסים המפריעה סבירה. ישנן דרכים שונות לטפל בבעיה זו: נתיבי תחבורה ציבורית )נת"צים(, קדימות יםרזמבצמתים מרו םלאוטובוסי , אנטיתחנות - מפרץ ועוד . - הנחיות התכנון של משרד התחבורה שחוברו על ידי (Shliselberg 2016 בתכנוןand דרך אבן Ashak) היוו מבוססי םצי "נת והקצאת לתכנון התייחס רשמי ממשלתי מסמך, הראשונה בפעם. בישראל צ "תח ותפעול אוטובוסיםהנסיעה של .ה ומהירות נוסעים ספירות, אוטובוסים ספירות בחשבון לוקחות ההנחיות. נתונים תל בעיר אמיתיים בוחן וזכרותמה בשנימקרי ההנחיות את מממשה נתונים הדמייתל כלי מציעים אנו זו בעבודה , אוטובוס קווי של מתוכננים זמנים לוחות)נתונים מקורותלאיסוף מתייחסים אנו. שבע באר ובעיר יפו-אביב נתונים עיבוד(, על האוטובוסים ממשיכים נוסעים וספירות, אוטובוסיםה של מיקומי אמת מןבז רשומות . נתונים להדמיית כלי עיצוב של היבטים ושלל מתאימים למדדים . צ"תח נתוני מנתחי וכן צ"תח מתכנני: המשתמשים קהל את המייצגים מומחים קבוצת ידי על הערכה עבר הכלי נתונים על מתבסס הכלי. המעובדים ישחופוהמדדים , הקוד מערכיכוללבאופן הכללי לציבור נגיש יהיה הכלי אך ניתן לעדכן מרץ 2019או, בחודש שנאספו תו לנתונים מעודכנים יותר במקרה הצורך.

מאמר בכותרת ’Visualization Tool to Analyze Data-Driven Bus Lane Allocation Guidelines‘ התקבל לסימפוזיון Transit Data 2020 . .

הקוד לעיבוד הנתונים זמין במאגר גיטהאב הבא. הקוד של האפליקציה עצמה נמצא במאגר זה. בסבוסהכלי, ", צוואר Bussleneck באנגלית, זמין לציבור הרחב לשימוש חופשי בקישור הבא . .

: מילות מפתח תח"צ, תחבורה ציבורית, נתיב APC,תחבורה GTFS,ציבורית , נת"AVLצ, SIRI , ספירות נוסעים, נתוני זמן אמת, הדמיית נתונים, ויזואליזציה, אוטובוסים, תכנון מונחה נתונים

בנגבאוניברסיטת בן גוריון נדסההפקולטה למדעי הה

המחלקה להנדסת תעשיה וניהול

– צוואר בסבוס כלי הדמיית נתונים לניתוח הנחיות משרד התחבורה להקצאת נתיבי תחבורה ציבורית

חיבור זה מהווה חלק מהדרישות לקבלת תואר מגיסטר בהנדסה

: שקד קאופמן אופקמאת

מנחים : פרופסור נעם טרקטינסקי, המחלקה להנדסת תוכנה ומער כות מידע בןד"ר ערן- אליא, המחלקה לגאוגרפיה ופיתוח סביבתי

מחבר: ……….……………………………… תאריך: ……………15.12.2020…………………

מנחה: ……….……………………………… תאריך: ……………15.12.2020…………………

יו"ר וועדת הוראה תאריך: מחלקתית ……….………: .. _ ……………15.12.2020…………………

בכסכ "ט אתשלו פ" 15.12.2020 15.12.2020

אוניברסיטת בן גוריון בנגב הפקולטה למדעי ההנדסה

המחלקה להנדסת תעשיה וניהול

– צוואר בסבוס כלי הדמיית נתונים לניתוח הנחיות משרד התחבורה להקצאת נתיבי תחבורה ציבורית

חיבור זה מהווה חלק מ הדרישות לקבלת תואר מ גיסטר בהנדסה

: שקד קאופמן אופקמאת

מנחים : פרופסור נעם טרקטינסקי, המחלקה להנדסת תוכנה ומערכות מידע בןד"ר ערן- אליא, המחלקה לגאוגרפיה ופיתוח סביבתי

כתובת דוא"ל: [email protected] [email protected]

בכסכ "ט אתשלו פ" 15.12.2020 15.12.2020