Academia.eduAcademia.edu

Figure 8 – uploaded by Pedro Wences Olguin

See full PDFdownloadDownload figure
The performance of the algorithm to predict the arrival times was measured by using the Root Mean Square Error (RMSE), Mean Absolute Error (MAE), Mean Absolute Percentage Error (MAPE), and Precision. Table 9 shows the results of the eight trips analyzed in the experimentation.

Table 9 The performance of the algorithm to predict the arrival times was measured by using the Root Mean Square Error (RMSE), Mean Absolute Error (MAE), Mean Absolute Percentage Error (MAPE), and Precision. Table 9 shows the results of the eight trips analyzed in the experimentation.

Related Figures (27)

Figure 1. Overview of the proposed solution. The approach uses the resources of the bus drivers’ smartphones to collect context nformation about public transport. This information is used by the algorithms to determine he arrival time to the next bus stop. In addition, a small electronic device was developed o record the users getting on/off of the bus. The users of public transport can use the web pplication developed in this project to receive the information about the arrival time of he next bus coming to the bus stop where the user is located and also to know the number of available seats on the coming bus. Figure 1 shows the conceptual architecture of the sroposed system that predicts the arrival times of buses and also determines the available eats on that bus.
Figure 1. Overview of the proposed solution. The approach uses the resources of the bus drivers’ smartphones to collect context nformation about public transport. This information is used by the algorithms to determine he arrival time to the next bus stop. In addition, a small electronic device was developed o record the users getting on/off of the bus. The users of public transport can use the web pplication developed in this project to receive the information about the arrival time of he next bus coming to the bus stop where the user is located and also to know the number of available seats on the coming bus. Figure 1 shows the conceptual architecture of the sroposed system that predicts the arrival times of buses and also determines the available eats on that bus.
Figure 2. An example of an asymmetrical bus route. One of the aspects taken into account to design the route is that only in a few cases is an urban passenger transport route symmetrical, leaving from point A to point B and returning, following the same streets in the city but in the opposite direction. This is the reason why, in this work, a route is considered to be composed of two journeys: one journey starting from bus stop A to bus stop B and another journey starting from bus stop B to return to the original bus stop A (Figure 2).
Figure 2. An example of an asymmetrical bus route. One of the aspects taken into account to design the route is that only in a few cases is an urban passenger transport route symmetrical, leaving from point A to point B and returning, following the same streets in the city but in the opposite direction. This is the reason why, in this work, a route is considered to be composed of two journeys: one journey starting from bus stop A to bus stop B and another journey starting from bus stop B to return to the original bus stop A (Figure 2).
The accuracy of the solution depends on the design of a well-defined route. In most cases, a route in the city is not completely straight and it is likely to have several curves. Therefore, care needs to be taken to define the straight and curved sections of the route. To do this, when designing the route, additional GPS points need to be assigned on the route in order to make a better match between the graphical route designed in the software app and the real bus route in the city. Figure 3 shows an example of a well-designed route and an example of a poorly-designed route. Figure 3. Example of a well-designed route and a poorly designed route.
The accuracy of the solution depends on the design of a well-defined route. In most cases, a route in the city is not completely straight and it is likely to have several curves. Therefore, care needs to be taken to define the straight and curved sections of the route. To do this, when designing the route, additional GPS points need to be assigned on the route in order to make a better match between the graphical route designed in the software app and the real bus route in the city. Figure 3 shows an example of a well-designed route and an example of a poorly-designed route. Figure 3. Example of a well-designed route and a poorly designed route.
Figure 4. Example of variability of GPS.
Figure 4. Example of variability of GPS.
Figure 5. Circuit diagram of the ultrasonic counter device. The USoniCont device follows the following process detailed to register when a perso! boards a bus (Figure 6): if a passenger walks near Sensor 1, a waiting circle is created wher a counter is waiting for that user to walk near Sensor 2.
Figure 5. Circuit diagram of the ultrasonic counter device. The USoniCont device follows the following process detailed to register when a perso! boards a bus (Figure 6): if a passenger walks near Sensor 1, a waiting circle is created wher a counter is waiting for that user to walk near Sensor 2.
Figure 6. (a) The ultrasonic device detecting a “getting on” event; (b) the ultrasonic device detecting a “getting off” event. When a passenger crosses near Sensor 2 before a previously defined time, the counter will record that action as a “getting on” event. If Sensor 2 does not detect the passenger, then the counter will keep the same value. Figure 6a shows the “getting on” event of a passenger.
Figure 6. (a) The ultrasonic device detecting a “getting on” event; (b) the ultrasonic device detecting a “getting off” event. When a passenger crosses near Sensor 2 before a previously defined time, the counter will record that action as a “getting on” event. If Sensor 2 does not detect the passenger, then the counter will keep the same value. Figure 6a shows the “getting on” event of a passenger.
Figure 7. Context data produced by a bus on the route.
Figure 7. Context data produced by a bus on the route.
Figure 8. Time to travel an edge. Figure 8 shows the situation when a bus finishes traversing Edge E3 using the time tE3. At the instant in which the bus crosses Node 4 (N4), the context-sensitive service calculates the time spent by the bus in traversing Edge E3.
Figure 8. Time to travel an edge. Figure 8 shows the situation when a bus finishes traversing Edge E3 using the time tE3. At the instant in which the bus crosses Node 4 (N4), the context-sensitive service calculates the time spent by the bus in traversing Edge E3.
Figure 9. (a) Time of the bus to travel an edge; (b) time at which the bus passed the start node and the end node; (c) search for the closest bus.
Figure 9. (a) Time of the bus to travel an edge; (b) time at which the bus passed the start node and the end node; (c) search for the closest bus.
Figure 10. The calculation of the arrival time.
Figure 10. The calculation of the arrival time.
Figure 11. Architecture of the smart information system.
Figure 11. Architecture of the smart information system.
Figure 12. Interface for the creation of a new route.
Figure 12. Interface for the creation of a new route.
Figure 14. Interface to define the location of a bus stop. Figure 13. Graphical interface for maps.
Figure 14. Interface to define the location of a bus stop. Figure 13. Graphical interface for maps.
This software application has been developed to monitor, collect, and send the context information of each bus that circulates on the route to the Web Server and to store this information in a database. To do this, the bus driver needs to be logged into the app. This module periodically communicates the following data to the Web Server: the GPS position of the bus, the seat availability, the bus unit number and the route on which the bus is circulating. Figure 15 shows the login interface for the bus driver, the interface for bus location data, and the information of the passenger counter. Figure 15. The login Interface for the bus driver and the interface for bus location and passengers.
This software application has been developed to monitor, collect, and send the context information of each bus that circulates on the route to the Web Server and to store this information in a database. To do this, the bus driver needs to be logged into the app. This module periodically communicates the following data to the Web Server: the GPS position of the bus, the seat availability, the bus unit number and the route on which the bus is circulating. Figure 15 shows the login interface for the bus driver, the interface for bus location data, and the information of the passenger counter. Figure 15. The login Interface for the bus driver and the interface for bus location and passengers.
Figure 16. Interface for the bus driver. Once the bus driver is logged into the system, the application enables the bus drive to know the distance between the next bus and previous bus on the route. Figure 16 show: the interface, indicating the distance (in time) to the next bus.
Figure 16. Interface for the bus driver. Once the bus driver is logged into the system, the application enables the bus drive to know the distance between the next bus and previous bus on the route. Figure 16 show: the interface, indicating the distance (in time) to the next bus.
Figure 18. Design of the route used for experimentation. The first phase for the experimentation was the design of the route (which is called Route 1) with 66 bus stops: 28 bus stops on the Guacamayas-University journey and 38 bus stops in the opposite direction (University-Guacamayas journey). Figure 18 shows both directions of Route 1. The two directions of the route are not symmetrical because some of the streets on the route are one-way streets. It is important to point out that the route needs to be designed with a software application because there are no GTFS specifications for most small Mexican cities. The GTFS specification is only available for big cities, such as Mexico City or Guadalajara.
Figure 18. Design of the route used for experimentation. The first phase for the experimentation was the design of the route (which is called Route 1) with 66 bus stops: 28 bus stops on the Guacamayas-University journey and 38 bus stops in the opposite direction (University-Guacamayas journey). Figure 18 shows both directions of Route 1. The two directions of the route are not symmetrical because some of the streets on the route are one-way streets. It is important to point out that the route needs to be designed with a software application because there are no GTFS specifications for most small Mexican cities. The GTFS specification is only available for big cities, such as Mexico City or Guadalajara.
Figure 17. Some views of the interface of the Passenger Transport App.
Figure 17. Some views of the interface of the Passenger Transport App.
Table 1. Results obtained for Trip 1 (Guacamayas—University Journey) MAE = +34 s, MAPE = 12.8% Precision = 87.2%. Table 2. Results obtained for Trip 2, Journey: University-Guacamayas. MAE = +95.3 s MAPE = 21.6% Precision = 78.4%.
Table 1. Results obtained for Trip 1 (Guacamayas—University Journey) MAE = +34 s, MAPE = 12.8% Precision = 87.2%. Table 2. Results obtained for Trip 2, Journey: University-Guacamayas. MAE = +95.3 s MAPE = 21.6% Precision = 78.4%.
Table 3. Results obtained for Trip 2, Journey: Guacamayas—University. MAE = +34 s, MAPE = 15.7% Precision = 84.3%.
Table 3. Results obtained for Trip 2, Journey: Guacamayas—University. MAE = +34 s, MAPE = 15.7% Precision = 84.3%.
Table 4. Results obtained for Trip 4, Journey: University-Guacamayas. MAE = +28.7 s, MAPE = 18.8% Precision = 81.2%. Table 5. Results obtained for Trip 5, Journey: Guacamayas—University. MAE = +42 s, MAPE = 20.5% Precision = 79.5%.
Table 4. Results obtained for Trip 4, Journey: University-Guacamayas. MAE = +28.7 s, MAPE = 18.8% Precision = 81.2%. Table 5. Results obtained for Trip 5, Journey: Guacamayas—University. MAE = +42 s, MAPE = 20.5% Precision = 79.5%.
Table 6. Results obtained for Trip 6, Journey: University-Guacamayas. MAE = +59.4 s, MAPE = 28.9% Precision = 71.1%.
Table 6. Results obtained for Trip 6, Journey: University-Guacamayas. MAE = +59.4 s, MAPE = 28.9% Precision = 71.1%.
Table 7. Results obtained for Trip 7, Journey: Guacamayas—University. MAE = +£57.7 s, MAPE = 27% Precision = 73%. Table 8. Results obtained for Trip 8, Journey: University-Guacamayas. MAE = +68.8 MAPE = 33.8% Precision = 66.2%.
Table 7. Results obtained for Trip 7, Journey: Guacamayas—University. MAE = +£57.7 s, MAPE = 27% Precision = 73%. Table 8. Results obtained for Trip 8, Journey: University-Guacamayas. MAE = +68.8 MAPE = 33.8% Precision = 66.2%.
Table 9. Results obtained for Journeys: University-Guacamayas, Guacamayas—University
Table 9. Results obtained for Journeys: University-Guacamayas, Guacamayas—University
Table 10. The results obtained of the passenger counting.
Table 10. The results obtained of the passenger counting.
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved