Design, Validation, and Comparative Analysis of a Private Bus Location Tracking Information System

,


Introduction
Some universities in Jordan provide a bus transportation service to students and employees.Hence, that necessitates having a computerized system to manage features such as user accounts (e.g., passenger, driver, and administrator), user subscriptions, fee payments, bus setup (e.g., model, license plate, and capacity), driver assignment to buses, bus stops, bus routes, bus schedules, and bus trips.Moreover, the system should help passengers track any ongoing trips to check the possibility of catching a bus or finding out how far is the bus from a certain bus stop.Furthermore, it must allow university management to generate related reports (e.g., late trips report, punctual trips report, and unpaid fees report) and solicit user feedback (e.g., regarding the drivers' behavior and buses' comfortability) to evaluate service quality and passenger satisfaction.Accordingly, management can take proper actions (e.g., renew a bus and reduce fees) to improve the offered services as necessary.
In this context, the main aim of this paper is to tackle the challenges pertaining to the design and development of webbased bus management and tracking system that fulfills the needs of the German Jordanian University (GJU) (or any other institution with similar demands).Note that the system has been developed in-house to keep customizing it to meet continual university requirements such as the following: (i) Track and record all bus trips in an efficient and accurate manner using a free open-source API.(ii) Provide all basic system setup functionality such as managing drivers, buses, stops, routes, schedule, and trips.(iii) Assign drivers to buses and assign buses to schedules without any conflicts (i.e., assigning two drivers to the same bus or assigning a bus to two overlapping schedules).(iv) Integrate the system with the Student Information System (SIS) [1,2], Human Resources (HR), and Accounting Information System (AIS) [3,4] to gain direct access to passenger (i.e., students or employees) profiles and financial data needed to retrieve the user account information (e.g., name, national number, and gender) and to check the payment of bus transportation fees (e.g., for login authorization purposes).(v) Support single-sign-on-(SSO-) based authentication to allow users to log in to the system using the same credentials (i.e., a single username and password) that they use to log in to other university portals.(vi) Allow passengers to evaluate the provided services (e.g., bus quality and driver behavior).(vii) Offer reporting capabilities with flexible filtering criteria to enable management to assess the service quality and user satisfaction and then take suitable actions accordingly.
e rest of the paper is organized as follows.In Section 2, the literature review and main contributions of this work are presented.In Section 3, project management and software development processes as well as system design issues (e.g., UI, database, and architecture design) are addressed.In Section 4, the development details for the record trip, replay trip, detect schedules conflict, and authenticate user features are explained.
e validation methods and comparative analysis results for the bus management system are illustrated in Section 5. Finally, the summary and limitations of this work as well as the planned future work are explored in Section 6.

Literature Review
e study in [5] proposed an ad hoc bus propagation model, taking into account bus overtaking and distributed passenger boarding behavior, to reduce bus bunching using holding control strategies for schedule and headway.Accordingly, bus bunching happens when two or more buses along the same route arrive at a designated stop simultaneously, and it is mainly related to the high uncertainty of bus systems running times, bus capacity, driving maneuvers (e.g., bus overtaking), and passenger boarding behavior.Holding control works by delaying buses at stops to regularize bus headway and reduce the overall passenger waiting time, possibly at the expense of extending on-board waiting time and total riding time.In the study in [6], a multiagent deep reinforcement learning framework to develop dynamic and flexible holding control strategies for a bus route is introduced to efficiently incorporate global coordination and long-term operation in bus holding.e work in [7] also investigated the effect of bus driver behavior on bus holding control strategies and more specifically their effort in catching up with a schedule in case of delay (i.e., schedule recovery).e research in [8] suggested a first schedulefollowing model where buses try to adhere to their schedule in a typical schedule-based public transport system.e model considers schedule following, bus bunching, and leapfrogging and uses observed automatic bus location and smart card data.
A flexible bus route optimization model for efficient public transportation systems based on multitarget stations was proposed in [9].
e model considers passenger demands, vehicle capacities, and transportation network and aims to find the optimal route while minimizing the vehicles' travel time.
e optimization problem is solved using a heuristic algorithm based on a gravity model.e study in [10] introduced a dynamic bus scheduling model to find an optimal schedule that can adapt to the variations in passenger demands and traffic conditions and hence increase financial benefit and social satisfaction.e model aims to minimize passenger waiting time and maximize bus capacity utilization while taking into account the constraints due to bus capacity and the number of available buses, as well as ensuring that the service does not exceed the maximum anticipated headway.e study in [11] introduced a robust optimization model for limited-stop bus service with vehicle overtaking and demand dynamics, with an objective to minimize user cost and operation cost.A simulation-based optimization framework integrating the response surface methodology, which only needs to fit an initial input-output dataset before solving to optimality, is used to solve the stopskipping optimization problem.e work in [12] discussed a heuristic framework to solve the bus routing and scheduling problem with transfer.
e framework deals with the transportation of students from home to their school assuming that students may change buses on their way.e results show that allowing transfers reduces total operating costs significantly with user ride times comparable to solutions without transfers.
e study in [13] investigated a statistical method for correcting the systematic errors that occur in the estimation of bus arrival times.e errors are related to the cycle time to record each bus location and arrival information, as well as the information processing time.e method was verified by applying it to the bus information system of a city in Korea.
e work in [14] resulted in a technique to predict bus arrival times based on the collected data from buses and the analysis of road conditions.e prediction is achieved using two algorithms that take advantage of historical data with current data.In the work in [15], a hybrid approach for predicting bus trajectories by integrating multiple predictors is proposed.e method minimizes the prediction error using a linear regression heuristic, and it was applied to five bus routes in different cities.In the study in [16], a methodology to predict bus arrival time using several artificial neural network models was developed.e models were built based on real-world automatic passenger counter data such as bus travel time and bus passenger load.e predicted arrival times were compared to the actual arrival times to evaluate the models' accuracy.A WiFi-sensing-based real-time bus tracking and arrival time prediction approach was discussed in [17].e work in [18] suggested a system that utilizes the bus passengers' surrounding environmental context to estimate the bus traveling routes and predict bus arrival time at various bus stops.e study in [19] provided a two-step trip purpose labeling process for alighting station estimation 2 Journal of Advanced Transportation based on transit smart card data.e process considers the station category, trip time, trip sequence, and alighting station frequency during five weekdays.e work in [20] utilized massive historical coach trajectory data to extract coach operation information such as station location, station name, coach schedule, and driving route.Such data is important as it facilitates the realization of intelligent traffic information services.e main goal of the work in [21] is to test point data visualization possibilities of selected Java-Script Mapping Libraries to measure their performance and ability to cope with a big amount of data.Five libraries for marker clustering and two libraries for heat map visualization were analyzed.Loading time and the ability to visualize large datasets were compared for each dataset and each library.e study in [22] focused on the design of a bus ticketing system.
e studies in [23,24] discussed the design of RFID hardware systems to monitor buses.e aforementioned literature review showed that the main challenges in this field are related to finding methods to collect accurate bus propagation and passenger demands information and then to use such data in the development of intelligent bus management applications that aim to increase bus capacity utilization, reduce bus operation cost, and improve passenger satisfaction.Specifically, the studies in [5][6][7][8][9][10][11][12][13][14][15][16][17][18][19][20][21][22][23][24] addressed particular issues related to bus management applications (e.g., reducing bus bunching, finding optimal schedules, predicting bus arrival time, collecting coach operation information, and designing bus tracking hardware) but did not discuss design aspects pertaining to the software development of bus management information systems as a whole.On the other hand, the software engineering aspects to develop bus management information systems that focus on bus trip tracking were introduced in [25][26][27][28][29][30][31][32][33][34][35][36][37], but only the systems in [25][26][27] discussed driver, bus, and route setup steps besides trip tracking.
Correspondingly, this work has three main contributions.First, it proposes design and development methods to realize all the needed features (e.g., account management, bus setup, route schedules, driver assignment, and trip monitoring) in a bus location tracking information system.Second, the proposed system utilizes the free open-source Leaflet library API [38] to present interactive maps, whereas the majority of the related systems used the no longer free (i.e., proprietary) Google Maps API [39,40] for that purpose.In that regard, a comparative analysis is also conducted to evaluate the aforementioned APIs and illustrate that the open-source API is accurate, efficient, and responsive like its counterpart, in addition to being more adaptable due to its open-source nature.ird, unlike most similar work, this system records the trip information and solicits the passenger feedback to allow reviewing and analyzing that data to enhance the provided services and hence reduce operation cost as well as improving passenger satisfaction.

Project Management and Software
Design Methods e adopted research methodology steps are summarized in Figure 1. e project management and development processes, as well as the software analysis and design methods to realize the bus location tracking system, are described in this section, whereas some of the technology development techniques and system validation measures are discussed in Sections 4 and 5, respectively.Specifically, this section covers four main topics.First, suitable project management and software development processes to deliver this project are selected.Second, the users of the system are identified and the services offered to them are specified.ird, the database tables and data structures needed to implement the various features are proposed.Finally, the software modules needed in the adopted three-tier web-based system architecture are discussed.

Project Management and Software Development
Processes.
e project management process in the systems engineering basic profile [41] was adopted to manage this project.is process is applicable in this context as it addresses important project management aspects like project planning, progress, review, versioning, and risks, whereas the iterative and incremental software development process is suitable to develop the various system modules.Based on that, several repeated waterfall cycles (i.e., iterations) have been used to implement the bus management modules (i.e., increments).

User Role Identification and System View Specification.
e system needs to support three user roles: admin, driver, and passenger.Accordingly, it must offer three views to provide related services to each user role.e main features in the admin view are summarized in the use case diagram in Figure 2, whereas the services offered to the driver and passenger roles are shown in the use case diagram in Fig- ure 3. e services offered to each of the three user roles are discussed next.

Admin View.
e admin view supports management features such as system setup (e.g., buses, drivers, stops, routes, and schedules), trips monitoring (i.e., tracking and replay), and feedback evaluation (i.e., user trip reviews).e offered services in the admin view are as follows: (1) Manage Drivers. is feature allows managing (i.e., adding, editing, deleting, and viewing): driver information (e.g., name, national number, address, and phone number) in the system.Such data can be used for management and reporting purposes.For example, knowing the address of a driver helps the admin in assigning the driver to a bus route that is closer to his/her place of residence.(2) Manage Buses. is capability is needed to set up the buses' information (e.g., manufacturer, model, license plate, chassis number, and capacity) in the system.(3) Assign Drivers to Buses.
e system supports assigning one driver per bus.Hence, to assign a new driver to a bus, the original driver has to be unassigned first.
Journal of Advanced Transportation (4) Manage Stops. is service is used to define the bus stops that can be used to specify the different bus routes.Each bus stop is identified by the name of the place where the buses stop to let passengers get on and off.(5) Manage Routes.e admin view permits managing bus routes using the screen shown in Figure 4.A bus route consists of two (i.e., the source and destination) or more bus stops (see Figure 5) and has a unique code.e bus route can be associated with several schedules.e route schedule specifies the expected arrival time of the bus to each stop along the route as shown in Figure 5.Each route schedule has a unique identifier.Also, a bus must be assigned to each schedule.Further, a route can be associated with several identical schedules as long as they are assigned different buses.Accordingly, the assigned buses take trips on a daily basis on the designated schedule times.Based on the example in Figure 5, Bus 1, Bus 2, and Bus 3 take the trips with Id 1 and Id 2, the trip with Id 3, and the trip with Id 4, respectively, on a daily basis as shown in Figure 6.
Note that the bus trips will continue daily as long as their route schedules remain active.( 6) Manage Route Stops.e system allows managing the bus stops for each route.Each stop has a different order than its counterparts to enable the system to display the stops based on their defined order.( 7) Manage Route Schedules.e system allows managing the bus route schedules via the screen shown in Figure 7.Note that it checks whether the arrival time to a certain bus stop is greater than or equal to the arrival time to the previous bus stop in a given bus route schedule.( 8) Assign Buses to Route Schedules.A specific bus should be assigned to each bus route schedule via the screen shown in Figure 7. e same bus may be assigned to multiple bus route schedules as long as there are no time overlaps between those schedules.When a bus is being assigned to a schedule, the system automatically checks whether or not that bus is assigned to an overlapping schedule to avoid conflicts or proceed with the operation (see subsection 4.3).( 9) Monitor Trips.e admin can also track an ongoing bus trip or replay a past bus trip, if needed.For that purpose, the system displays the selected trip map and keeps updating the marker position to point at the current or recorded bus position (i.e., longitude and latitude values) at a given time (see Figure 8).(10) Generate Reports.e admin may generate reports with flexible filtering criteria (see Figure 9) to display trip details such as driver name, bus information, departure time, arrival time, route stops, trip status, and trip reviews.Accordingly, the admin can evaluate the bus punctuality and the passenger satisfaction.en, the evaluation reports can be shared with university management for needed action (e.g., keep the bus transportation company, replace a bus, or reward a driver).

Driver View.
e driver view offers the following features: (1) View Profile.A driver can view his/her information (e.g., picture, name, national number, and phone number).(2) View Schedules.is feature displays the bus route schedules that are assigned to a driver as shown in Figure 10.A driver can start an on-time trip (i.e., highlighted in green) or a late trip (i.e., highlighted in    (4) View Reports.
is feature allows displaying the details (e.g., bus information, departure time, arrival time, route stops, and trip status) of the trips that were initiated by the driver.

Passenger View.
e passenger view supports the following three services: (1) View Profile.A passenger can view his/her profile.In case the passenger is a student, the profile would contain information retrieved from the SIS database such as name, student ID, degree, and major.On the other hand, when the passenger is an employee, the profile would contain data obtained from the HR database such as name, employee ID, job title, and department.(2) Track Trips.A passenger may track any ongoing trip to check the possibility of catching a bus or finding out how far is the bus from a bus stop.e system displays the selected trip map and keeps updating the marker position to point at the bus position at the current time (see Figure 8).Noting that this page (and the other pages in the passenger view) is designed to be responsive such that it is navigable and viewable in screens with different sizes.
(3) Review Trips.A passenger can provide feedback regarding any trip using the trip review form shown in Figure 12. e feedback is related to issues such as driver's behavior, driver's driving, bus quality (e.g., comfortability and cleanliness), trip punctuality, and general comments.e system admin can evaluate the user feedback to make sure passengers are satisfied with the provided bus transportation service.Journal of Advanced Transportation 3.3.Database Design.For example, the ER diagram for the major tables that are utilized by the bus management system is shown in Figure 13.Accordingly, the drivers, buses, and stops information are stored in the DRIVERS, BUSES, and STOPS tables, respectively.e DRIVER_ID and BUS_ID are saved in the BUSES_DRIVERS table when a driver is assigned to a bus.e bus routes information (e.g., code, source, and destination) are saved in the ROUTES e trip summary is saved in the TRIPS table.e latitude and longitude values of each recorded position in a bus trip are stored in the TRIPS_COORDINATES table (also see Figure 11).

System Architecture.
e bus management system is a web-based Java EE application that is separated into client, web, and data tiers as shown in Figure 14.In the client tier, users (i.e., clients) would access the system via web browsers running on computers or phones.In the web tier, the system modules are deployed and executed in a web container that resides within the Java EE server (running on a remote host in a data center).In the data tier, the buses, SIS, HR, and AIS databases are managed by the Relational Database Management System (RDBMS).A software module (e.g., manage buses, manage routes, and manage stops) consists of Java-Server Faces (JSF) [42] pages, managed beans, and Data Access Objects (DAOs).A JSF file includes HTML and JSF elements to represent the UI components (e.g., tables, text fields, checkboxes, and menus) in the related module.A managed bean is a Java object that is automatically managed (i.e., instantiated, executed, updated, and destroyed) by the web container.It saves the state of the corresponding JSF page and implements the business logic of the page.e JSF framework offers more services to support data validation and conversion, event handling, page templates, and language translation.It also allows the use of custom UI component libraries like PrimeFaces [43] within the JSF pages.A DAO is used by a bean to manage the application information in the data tier.For that purpose, it utilizes the Java Database Connectivity (JDBC) API to interact with the RDBMS to retrieve data from, or store data in, the desired database tables.

Development Methods
e development details for some of the main features within the bus management system are discussed next.

Trip Tracking and Recording.
e sequence diagram in Figure 15 illustrates the developed methods to display and record a bus trip map.In that regard, when a driver starts a trip, the trip map page will be rendered every 15 seconds until the trip is ended.Given that the latitude and longitude values of the bus location are collected via JavaScript functions in the client tier, therefore the inputHidden elements have been used in the map's JSF page to allow storing these values in a managed bean named mapBean whenever the page is requested by the browser.e JSF framework invokes the setLat and setLng methods on the mapBean object to store the received latitude and longitude values, respectively.It also records the captured coordinates in the database by first invoking the saveLatLng method on the mapBean object.In turn, the mapBean object invokes the insertLatLng method on the related DAO, which then uses the Java JDBC API to communicate with the RDBMS to insert the coordinates of the current bus location in the TRIPS_COORDINATES table.Consequently, the JSF framework generates the HTML tags and JavaScript code for the elements in the map page and then sends the page within an HTTP response message to the browser.e Leaflet library API [38] is utilized by the JavaScript code that is executed by the browser to initialize and display the interactive map.Next, the Geolocation API is used by the Leaflet locate function to capture the coordinates of the current bus location.en, a marker for the current bus coordinates is added and displayed on the map.Finally, the latitude and longitude values of the current bus location are saved in the values of the inputHidden elements for processing upon submitting the form data of the map page to the web application server.

Trip Replay.
e sequence diagram in Figure 16 illustrates the developed methods to replay a saved bus trip.When the trip page is requested by the browser, the JSF framework invokes the getTripCoords method on the mapBean object to retrieve the markers information of the desired trip for replay.In turn, the mapBean object invokes the buildTripCoords method on the related DAO, which then uses the Java JDBC API to communicate with the RDBMS to retrieve the coordinates' rows of the desired trip from the TRIPS_COORDINATES table.Consequently, the JSF framework generates JavaScript code to display the trip's recorded markers on the map.Next, it generates HTML tags and JavaScript code for the rest of the elements on the page.Finally, it encapsulates the generated page within an HTTP response message that is sent to the browser.e Leaflet library API is utilized by the JavaScript code that is executed by the browser to initialize and display the interactive map.Next, all the markers for the replayed trip are added and displayed on the map.

Schedule Conflict Detection.
e system automatically detects schedule conflict when attempting to assign a bus to an overlapping schedule as shown in Figure 17. e pseudocode for the schedule conflict detection algorithm is shown in Figure 18. e algorithm is based on the assumption that each driver is assigned to only one bus as stated at line 1. e departure time and arrival time of the route schedule (i.e., selSched) to which the bus is being assigned are computed at line 2 and line 3, respectively.e schedules to which the selected bus is already assigned are retrieved from the BUSES_SCHEDULES table and then saved in the busSche-dulesArray object at line 4 and line 5, respectively.e foreach block that starts at line 6 and ends at line 21 checks each bus schedule (i.e., busSched) in the busSchedulesArray object for conflicts.e stop schedules for the current busSched are retrieved from the ROUTES_STOPS_SCHEDULES table and then saved in the busStopSchedulesArray object at line 7 and respectively.e arrival and departure times of the current busSched are compared to their counterparts of the selSched to check for any schedule conflict within the conditional if statement block that starts at line 12 and ends at line 20.In case a schedule conflict is detected, an informative error message (see Figure 17) is constructed at line 18 for display, and a break statement is issued at line 19 to exit the foreach block.

User Authentication and Authorization.
GJU users (e.g., students and employees) log in to all university portals using SSO credentials (i.e., with a single username and password) that are managed and saved in the Microsoft Active Directory (AD) [44].Accordingly, the bus management system uses the Java Naming and Directory Interface (JNDI) as well as the Lightweight Directory Access Protocol (LDAP) to communicate with, and authenticate users in, the AD.Once a passenger is authenticated, the system also verifies whether that user had subscribed to the bus transportation service and paid the required fees (based on the related data in the buses, SIS, HR, and AIS databases shown in Figure 14).Consequently, a passenger is denied access to the system in case authentication or authorization fails.

Application Security and Data
Protection. e following security measures are implemented to protect the application and database servers from any unauthorized access: the  security-centric Linux operating system (OS) is utilized to run all servers; a strong password policy is in place to access the required servers and applications by authorized users only; the OS and all used software are regularly updated to close any vulnerabilities; antivirus tools are deployed to protect all servers from malware; the network security access list is defined to block any access to the admin view and database from outside the GJU intranet; besides, the HTTPS protocol is enabled in the application server for user authentication, data confidentiality, and data integrity purposes.

Validation and Results
e system testing results, user survey outcomes, and the feature comparison to related work are presented in this section.

Trip Tracking Accuracy and Speed.
ree samples from the many trips that were tracked during the system testing phase are shown in Figures 19-21.
e majority of the recorded bus locations during those trips were very accurate as illustrated in the three figures.In Figure 19, all the recorded points were accurate and none of them deviated from the taken path.On the other hand, only one point in Figure 20 was outside the taken path (i.e., an outlier point), and hence, it has a negligible effect on the path tracking accuracy.In Figure 21, a short gap (due to a possibly missing marker on that part of the path) was noticed on the tracked path, and that can be related to an encountered delay in the Geolocation API while attempting to locate the bus location.In some cases, the existence of some short gaps in the path is not an issue as they can be attributed to a faster movement of the bus in between the poll operations.As far as the value of the poll interval, it was found that using a value of about 10 seconds is suitable to efficiently record and accurately reproduce the taken trip paths.Noting that the longest traveled distance in the shown figures was about 5 kilometers during the trip shown in Figure 19.
Another experiment was conducted to compare the speed of the Leaflet API with that of its Google Maps counterpart.e results of this investigation are illustrated in Figure 22 in which the measured elapsed times to locate and display 70 markers using both packages are shown.Based on that, both APIs are fast and responsive, with 1. -Given that a driver is assigned to only one bus 2. -selSchedDepartureTime ← the time of the selSched stop with the lowest order 3. -selSchedArrivalTime ← the time of the selSched stop with the highest order 4. -Retrieve the schedules for the bus to be assigned to the selSched from the BUSES_SCHEDULES table 5. -Save the retrieved schedules in the busSchedulesArray 6. foreach busSched in busSchedulesArraydo 7.
-Retrieve the busSched stop schedules from the ROUTES_STOPS_SCHEDULEStable 8.
-Save the retrieved stop schedules in the busStopSchedulesArray 9.
-busSchedDepartureTime ← the time of the bus stop schedule with the lowest order 10.
-busSchedArrivalTime ← the time of the bus stop schedule with the highest order 11.12.
-Flag the schedule conflict 18.
-Construct an informative error message for display 19.
end // if statement 21.end // foreach loop Figure 18: e pseudocode for the schedule conflict detection algorithm.12 Journal of Advanced Transportation negligible speed differences.Specifically, the minimum, average, and maximum measured times using Leaflet were equal to 21 ms, 52.64 ms, and 152 ms, respectively, whereas the minimum, average, and maximum recorded times using Google Maps were equal to 16 ms, 57.05 ms, and 192 ms, respectively.erefore, this experiment asserts that using the Leaflet API to develop interactive maps in this system is advantageous because it is free and adaptable, with almost no speed differences relative to the no longer free Google Maps API.
e average time to add the markers on a map for a recorded trip was also evaluated as shown in Figure 23.Given that the travel time for most trips to/from GJU spans from 30 minutes to 90 minutes, hence the needed number of points to record a trip in the database ranges from 180 points to 540 points based on a 10-second poll interval.erefore, measuring the average time to display the markers for trips with a number of points ranging from 100 points to 600 points is sufficient to evaluate the speed of the trip replay feature.Accordingly, the measured average time values were  reasonably fast as the maximum value did not exceed 125 ms for a trip comprised of 600 markers.

Application Assessment and Trip Satisfaction Surveys.
e employees and students (i.e., about 58 users) traveling in three buses were asked to try the application and then complete a system assessment survey and a trip satisfaction review.A total of 45 participants completed the aforementioned surveys as shown in Tables 1 and 2, respectively.e answers to each question in the surveys were based on a five-point Likert scale.Hence, each question had five answers as follows: strongly agree (5 points), agree (4 points), not sure (3 points), disagree (2 points), and strongly disagree (1 point).
Based on Table 1, 93% of the participants strongly agreed or agreed that they have an acceptable Internet service.Also, 98%, 87%, 80%, 87%, and 91% of the users strongly agreed or agreed that the system is easy to use (i.e., question 2), accurate (i.e., question 3), fast (i.e., question 4), responsive (i.e., question 5), and helpful (i.e., question 6), respectively.e travelers used the trip review form shown in Figure 12 to provide their feedback regarding the trip.Accordingly, 96% and 100% of the participants strongly agreed or agreed that the drivers were friendly (i.e., question 1) and drove safely (i.e., question 2), respectively, as shown in Table 2. Also, 93% of them would recommend the drivers to others (i.e., question 3).On the other hand, 87% and 89% of the users strongly agreed or agreed that the bus was comfortable (i.e., question 4) and arrived on time (i.e., question 5), respectively.

Feature Comparison to Related Work.
A feature comparison to the related systems discussed in [25][26][27][28][29][30][31][32][33][34][35][36][37] is shown in Table 3.In that regard, this work is centered on designing a complete bus management portal, and its novelty can be summarized as follows: (i) e free open-source Leaflet library has been used to develop interactive maps in this system, while the majority of the other systems relied on the no longer free Google Maps API for that purpose.Not to mention, Leaflet is similarly fast and responsive,   aspects related to the management of buses, drivers, stops, routes, schedules, and trips.(iii) Unlike the rest of the systems, this system implements an algorithm to detect bus schedule conflict that is needed to prevent the assignment of two drivers to the same bus or the assignment of a bus to overlapping schedules.(iv) None of the other systems developed a trip replay feature as in this work despite the importance of that to review and archive previous trips.(v) Unlike all related work, this system uses SSO for user authentication due to its importance in preventing users from memorizing several passwords and relieving administrators from assigning credentials to every new user.(vi) Unlike all other systems, the bus management system is integrated with the SIS, HR, and AIS databases.Accordingly, the system setup is easier as the administrator does not have to manage students, employees, fees, or payments as all that data are directly accessible from the aforementioned databases for authorization or display purposes.(vii) Only this system gave the passengers the chance to evaluate the offered services (e.g., bus quality and driver behavior).(viii) is system is the only one that supports reporting capabilities with flexible filtering criteria as needed Journal of Advanced Transportation to enable management to assess the service quality and user satisfaction for further improvements.

Summary and Future Work
A flexible, easy to use, fast, accurate, and helpful web-based bus management and tracking system that is designed and developed in-house and supports the following user roles has been introduced in this paper: (i) Admin user role is responsible for tasks such as system setup, trip scheduling, report generation, and service evaluation.(ii) Driver user role takes care of starting, monitoring, canceling, and stopping the assigned trips.(iii) Passenger user role monitors any ongoing trip to check the possibility of catching a bus or finding out how far is the bus from a bus stop.In addition, this user can provide feedback regarding the offered services for improvement purposes.
Unlike many existing systems, this system incorporates all the user interfaces and data structures needed to manage buses, drivers, stops, routes, schedules, and trips.Also, it utilizes an algorithm to detect bus schedule conflict to prevent assigning several drivers to the same bus or assigning a bus to overlapping schedules.Moreover, it supports SSO user authentication and it is integrated with other systems (e.g., SIS, AIS, and HR) to directly access data related to students, employees, fees, and payments without the need for extra setup steps.In addition, it provides reporting capabilities with flexible filtering criteria to allow management to evaluate the service quality and user satisfaction for further action.
e sequence diagram for the code methods (in the system's client, web, and data tiers) used to display and record a bus trip has been discussed.Moreover, the sequence diagram that represents the code interactions to replay a previous bus trip has been explained.
One of the advantages of this system is that it uses the free open-source Leaflet package to develop interactive maps and track the bus trips.e comparative analysis between the open-source API and the proprietary Google API when tracking several bus trips illustrated that the benefits of using the Leaflet API are justified as they come without any effects on accuracy, performance, or responsiveness when compared to the no longer free Google Maps API.Further, the Leaflet API is more adaptable than its counterpart due to its open-source nature.
One of the limitations of this work is that it does not predict the bus arrival time to enhance customer satisfaction, but it only displays and records the actual locations of a traveling bus during a specific trip.Note that the saved historical trip data can be used to predict bus arrival times when needed.Also, this work does not attempt to avoid bus bunching and it does not regulate bus headway; however, such issues are not much of a concern in the case of the private GJU bus transportation system.Moreover, as of now, the introduced system does not collect the bus capacity during a trip for the possible use of such data in the development of scheduling algorithms to reduce, for example, bus operation cost.
As far as future work, the current plan is to enhance the system to support features such as bus seat reservation, bus capacity collection, and bus pass scanning (e.g., via a QR code reader).Such data can be utilized, for example, to reduce bus operation cost.Furthermore, the possibility to integrate accurate methods to predict bus arrival time to improve passenger satisfaction is under consideration.

Stop 4 :Figure 5 : 3 Figure 6 :
Figure 5: An example showing a bus route with its stops and schedules.

Figure 4 :
Figure 4: e manage routes screen in the admin view.

Figure 8 :
Figure 8: e manage trip screen in the driver view.

Figure 7 :
Figure 7: e manage route schedule screen in the admin view.

Figure 10 :
Figure 10: e schedule screen in the driver view.

Figure 11 :
Figure 11: e trip coordinates database table.

Figure 9 :
Figure 9: e trips report in the admin view.

Figure 12 :Figure 14 :
Figure 12: e review trip form in the passenger view.

Figure 15 :
Figure 15: e sequence diagram for the bus trip tracking and recording code interactions.

Figure 16 :
Figure 16: e sequence diagram for the replay bus trip code interactions.

Figure 17 :
Figure 17: e conflict detection message when attempting to assign a bus to an overlapping schedule.

Figure 19 :
Figure 19: A very accurate trip path.

Figure 20 :
Figure 20: A trip path in which there is one outlier marker.

Figure 21 :
Figure 21: A trip path in which there is a short gap.

Figure 22 :
Figure 22: e elapsed times to locate and display 70 markers using Leaflet and Google Maps.

Figure 23 :
Figure 23: e average times to display the markers on a map for different recorded trips.
table.A bus route is associated with several bus stops in the ROUTES_STOPS table.e bus routes' schedules are stored in the ROUTES_SCHEDULES table.e time a bus arrives at a bus schedule stop is saved in the ROUTES_-STOPS_SCHEDULES table.A bus is assigned to a schedule in the BUSES_SCHEDULES table.

Table 1 :
e system assessment survey results.

Table 3 :
A feature comparison to related work.