Passenger analysis system and passenger analysis method
The passenger analysis system addresses the challenge of determining train type preferences by comparing entry and exit time-based travel route searches, offering detailed passenger preference estimates for operational planning.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- HITACHI LTD
- Filing Date
- 2022-11-25
- Publication Date
- 2026-05-15
AI Technical Summary
Existing technologies struggle to accurately determine passengers' preferences for train types on lines with multiple train operations, as current methods like surveys are costly and insufficient, and existing data analysis techniques fail to provide detailed insights into train type choices.
A passenger analysis system that compares travel route searches based on entry and exit times using ticket gate passage data and train timetable data to estimate preferences for train types, visualizing results in graph form by station, time of day, and train schedule.
Provides railway operators with detailed estimates of passengers' travel route preferences, particularly for train types, supporting operational planning and service improvements.
Smart Images

Figure 0007859958000001 
Figure 0007859958000002 
Figure 0007859958000003
Abstract
Description
Technical Field
[0001] The present invention relates to a passenger analysis method and a passenger analysis system. In particular, it relates to a technology for analyzing the travel routes of passengers using ticket gate passing data at stations and train timetable data.
Background Art
[0002] Influenced by the spread of infectious diseases, the trend of promoting remote work, and in anticipation of the era of future population decline, railway operators have started measures such as reducing the number of train operations to cut operating costs. However, if the reduction in the number of train operations causes the transport service level to decline too much, users may start using transportation means other than railways, etc., and there is a possibility of falling into a negative spiral. In order to avoid such a vicious cycle, railway operators need to consider the travel needs of passengers as much as possible and proceed with cost reduction measures while maintaining convenience.
[0003] Here, the travel needs of passengers are, for example, the actual situation and preferences of how passengers move from the departure station to the arrival station and whether they choose a train with some will during the movement. For railway operators, knowing whether passengers prefer trains that can arrive early or choose trains from a perspective different from speed is useful for considering improvement measures for transport services that lead to an increase in passengers.
[0004] Typical examples of measures taken by railway operators to improve transport services while considering the needs of passengers are train types such as limited express, express, and all-stops. Currently, many railway companies are providing transport services considering train types, but there is a problem that it is difficult to grasp the actual situation of which train types passengers prefer and whether they really meet the needs of passengers.
[0005] Traditionally, analyzing passenger travel behavior has mainly relied on surveys and other methods, which are costly and often fail to yield sufficient data. However, in recent years, the utilization of data collected and stored within railway operations has been expanding, and efforts to analyze passenger travel behavior using this data are accelerating.
[0006] As prior art in this field, Patent Document 1 discloses a technique for estimating multiple candidate travel routes from a departure station to an arrival station by estimating train operation records using passenger movement data such as actual station entry and exit data. Furthermore, Patent Document 2 discloses a technique for estimating the feasibility of passengers' travel routes by using actual station entry and exit data to determine the distribution of travel times between entry and exit stations. [Prior art documents] [Patent Documents]
[0007] [Patent Document 1] Japanese Patent Publication No. 2016-030473 [Patent Document 2] Japanese Patent Publication No. 2022-052076 [Overview of the project] [Problems that the invention aims to solve]
[0008] Using the technology described in Patent Document 1, it is possible to estimate the travel routes and trains that passengers would have actually used, based on certain criteria, using train operation records estimated from passenger travel data. However, this technology does not provide detailed estimation of which trains passengers intentionally choose on lines where multiple types of trains operate.
[0009] Furthermore, while the technology described in Patent Document 2 can be used to estimate the travel route a passenger likely took by comparing the theoretical travel time distribution with the actual travel time of passengers, it is difficult to determine which route was chosen if there is no clear difference in the theoretical travel time for each route.
[0010] This invention has been made in view of the above points, and aims to provide railway operators with the results of estimations regarding passengers' travel route preferences, particularly their preferences for train types, by utilizing ticket gate passage data and timetable data collected and stored by each railway operator. [Means for solving the problem]
[0011] To solve the aforementioned problems, the passenger analysis system for a route where multiple train types operate from a departure station to an arrival station according to the present invention compares the results of a travel route search based on the entry time at the departure station with the results of a travel route search based on the exit time at the arrival station, and if the comparison of the travel route search results is different, Assuming that passengers used a travel route based on their departure time from the aforementioned arrival station, passenger travel route preferences for the analyzed lines are compiled in graph form by station, time of day, and train schedule, and visualized according to the display conditions. I made it so. [Effects of the Invention]
[0012] According to the present invention, it is possible to provide railway operators with estimated results regarding passengers' travel route preferences, particularly their preferences for train types, using ticket gate passage history and train operation history. [Brief explanation of the drawing]
[0013] [Figure 1] This diagram illustrates the relationship between the travel route and the type of train in this embodiment. [Figure 2] This diagram shows the configuration of the travel route preference estimation system (passenger analysis system) of this embodiment. [Figure 3A] This diagram shows the structure of station information within station and route information. [Figure 3B] This diagram shows the structure of route information within station and route information. [Figure 3C] This diagram shows the structure of station and route-related information within station and route information. [Figure 4] This diagram explains the relationship between stations, lines, and train types. [Figure 5] This diagram shows the data structure of the transfer route master on the data server. [Figure 6] It is a diagram showing the data structure of the time expression information of the data server. [Figure 7] It is a diagram showing the data structure of the arrival / departure data of the data server. [Figure 8] It is a diagram showing the data structure of the moving route search result of the data server. [Figure 9] It is a diagram showing the data structure of the preference estimation result of the moving route of the data server. [Figure 10] It is a flowchart explaining the generation procedure of the transfer route master of the transfer route master generation program. [Figure 11] It is a flowchart showing the processing procedure for searching the moving route of the moving route search program. [Figure 12] It is a flowchart showing the processing procedure of the train estimation program. [Figure 13] It is a flowchart showing the processing procedure of the moving route preference estimation program for estimating the preference of the moving route. [Figure 14] It is a diagram showing an example of an execution process management screen for a user of a system for estimating the preference of a moving route to input analysis conditions. [Figure 15] It is a flowchart of a management screen program for managing the execution process of a moving route preference estimation system. [Figure 16] It is a diagram showing an example of a display screen of the moving route preference estimation result. [Figure 17] It is a diagram showing another example of the display screen of the moving route preference estimation result. [Figure 18] It is a flowchart of a display screen creation program of an information distribution server. [Figure 19] It is a diagram showing an example of a transfer guidance screen distributed to passengers.
Mode for Carrying Out the Invention
[0014] Hereinafter, embodiments of the present invention will be described with reference to FIGS. 1 to 19. Figure 1 illustrates the relationship between travel routes and train types in this embodiment. In this embodiment, the travel route preferences of passengers are estimated by comparing the results of route searches using two criteria, based on the passengers' arrival and departure times, from departure station 1 to arrival station 2.
[0015] Travel Route 1 in Figure 1 is an example of the results of searching the train operation history to find the train that can arrive closest to passenger A's departure time. Travel Route 2 is an example of the results of searching the train operation history to find the train that can reach destination station 2 as quickly as possible, starting from passenger A's arrival time.
[0016] Let's assume that we obtain the results of using local trains as travel route 1 and the results of using express trains as travel route 2. Unless there are special circumstances such as the arrival station having extensive facilities, it is generally unlikely that passengers would linger in the station premises for a long time after disembarking from the train at the arrival station, so it is more natural to consider the route used by passenger A as travel route 1.
[0017] As shown in Figure 1, if we take the position that travel route 1 and travel route 2 yield different results, and that travel route 1 is more reasonable, then it is highly likely that passenger A chose travel route 1, even if it meant letting the train that would get them to their destination station the fastest (travel route 2) pass by. Therefore, we can determine that the route used by passenger A is travel route 1. Furthermore, there are several possible reasons why passenger A chose travel route 1, such as "because I could get a seat" or "because it wasn't crowded." While this is purely speculative, it can be inferred that some preference of passenger A played a role when presented with multiple options.
[0018] This invention compares the results of travel route searches based on entry time and travel route searches based on exit time, estimates which route (train type) is preferred by passengers on lines where multiple train types operate from departure station to arrival station, and provides railway operators with aggregated results by station and time of day, thereby supporting decisions in operational planning operations such as timetable revisions.
[0019] In this specification, passenger preferences refer to factors such as priority for seating, speed, number of transfers, and whether or not there are premium fares for express trains, which are criteria for passengers to choose their route (type of train). However, preferences may also include things like passenger habits and quirks.
[0020] Figure 2 shows the configuration of the travel route preference estimation system (passenger analysis system) of this embodiment. In recent years, automatic ticket gates 101 have been installed at many railway stations. These automatic ticket gates 101 can detect passengers entering or leaving a station by reading contactless IC cards (or mobile devices with equivalent functionality) or magnetic tickets.
[0021] The information read by the automatic ticket gate 101 is transmitted via the network 106 to a group of data management servers managed by the railway operator and stored as ticket gate passage data. The ticket gate passage data includes information such as the station and time at which each passenger entered to use the train, and the station and time at which they exited after alighting from the train.
[0022] In addition to compiling the pass-through logs from automatic ticket gate 101, other methods that utilize data equivalent to ticket gate pass-through data include public Wi-Fi usage logs, information on detected Bluetooth devices, and QR code usage history.
[0023] More specifically, in recent years, with the spread of public Wi-Fi available at stations and on trains, access points have been installed in various locations. It should be noted that public Wi-Fi may be provided by operators other than railway companies. Public Wi-Fi is a service that provides internet access via wireless LAN, allowing passengers to connect to the internet via access points using mobile devices such as laptops, tablet PCs, and smartphones.
[0024] In public Wi-Fi networks, the range of a single access point is generally only a few tens of meters, so multiple access points are installed in large spaces such as train stations. To prevent interference when a mobile device can communicate with multiple access points, communication is performed using an SSID (Service Number) to identify the network.
[0025] Access points can obtain the connection start and end times for each mobile device. Generally, multiple access points are installed in train stations near ticket gates and on platforms, so the location of a mobile device can be roughly estimated from the signal strength between each access point and the passenger's mobile device. Alternatively, by tracking the access points to which each mobile device is connected over time, the entry and exit times within the station can be roughly estimated.
[0026] Train 102 is operated using the railway management system owned by the railway operator. The railway management system has subsystems such as a timetable planning system, an operation management system, and a train information management system.
[0027] The train operation management system monitors whether train 102 is operating according to the timetable created by the timetable planning system. The train information management system is a system that acquires and collects various information from train 102 in operation and transmits that information to the crew and the operations management center.
[0028] This train information management system allows train locations, train numbers, and malfunction information to be transmitted from each train and aggregated at the operations management center. However, due to accidents, bad weather, and other factors, trains do not always operate according to the planned timetable created by the timetable planning system.
[0029] In that case, there will be a discrepancy between the actual operation history recorded in the operation management system and the planned timetable. In such cases, using the actual operation history for analysis will yield more accurate results. If the train operation status can be considered to be in line with the planned timetable, the planned timetable can be used as is.
[0030] In this embodiment, the preferences of passengers' travel routes are estimated based on information from the automatic ticket gate 101 and the train 102. Of course, such estimations are not limited to those using these devices. The travel route preference estimation system 105 may be owned by a railway operator as part of its operational system, or it may be owned by a service provider different from the railway operator and provided with the analysis results to the railway operator.
[0031] The travel route preference estimation system 105 comprises a data server 120, a computing server 130, and an information distribution server 140. Each server is connected via a network 112 to a terminal 111 used by the system administrator (or the railway operator if the system is owned by the railway operator). The travel route preference estimation system 105 can also communicate via the network 115 to computer terminals used by the railway operator 113 and to external systems 114 such as the transportation planning system used when formulating timetable revision proposals.
[0032] The servers constituting the travel path preference estimation system 105 are described below. In this embodiment, they are described as a group of three servers, but they can be configured as a single physical computer, or as a computer system consisting of multiple logically or physically configured computers. They may operate in separate threads on the same computer, or they may operate on virtual computers built on multiple physical computing resources.
[0033] Each server has the same basic configuration and is a computer having network interfaces (I / F) 131, 141, processors (CPU) 132, CPU 142, memory 133, 143, and storage units 134, 144. Network interfaces 131 and 141 are interfaces for connecting to networks 106, 112, and 115. CPUs 132 and 142 execute programs stored in memory 133 and 143.
[0034] Memory 133 and 143 include a non-volatile memory element called ROM (Read Only Memory) and a volatile memory element called RAM (Random Access Memory). ROM stores immutable programs, such as the BIOS (Basic Input Output System). RAM, on the other hand, is a high-speed, volatile memory element like DRAM (Dynamic Random Access Memory), and temporarily stores programs executed by CPU 132 and CPU 142, as well as data used during program execution.
[0035] The memory units 134 and 144 are composed of large-capacity, non-volatile storage devices such as magnetic storage devices (HDD (Hard Disk Drive)), flash memory (SSD (Solid State Drive)), and optical drives, and store the CPU 132, the programs executed by the CPU 142, and the data used when the programs are executed. Alternatively, multiple recording devices may be provided as memory units, and programs and data may be divided and recorded on multiple recording devices.
[0036] Furthermore, each server may have an input interface to which a keyboard, mouse, etc., is connected and to which input from the operator is received, and an output interface to which a display device, printer, etc., is connected and to which the program execution results are output in a format that can be viewed by the operator. Furthermore, the programs executed by each server are provided to each server via a network or removable media (optical disc, flash memory, etc.). Therefore, each server should have an interface for reading data from the removable media.
[0037] The following describes the startup process for each server in detail. First, let's explain the data server 120. Departure and arrival data 126 generated from ticket gate passage logs, and timetable information 125 generated based on information from the operation management system that manages train 102, are transmitted to the data server 120 via the network 106 when new data is acquired, or at predetermined time intervals (every few minutes, every few hours, etc.). The data server 120 records the received data in the data storage unit (DB) 121.
[0038] The data storage unit 121 stores station and route information 123, transfer route master 124, timetable information 125, departure and arrival data 126, travel route search results 127, and travel route preference estimation results 128. Details of this data will be described later.
[0039] Next, the computing server 130 uses the data stored in the data server 120 to perform a preference estimation process for travel routes. The storage unit 134 stores the transfer route master generation program 135, the travel route search program 136, the travel route preference estimation program 137, and intermediate data generated during the calculation process. The programs are read from the storage unit 134, loaded into memory 133, and executed by the CPU 132.
[0040] The data to be analyzed is obtained from intermediate data stored in the data server 120 or the storage unit 134, temporarily stored in memory 133, and the CPU 132 reads and executes a program from the storage unit 134. These programs may be executed automatically according to predetermined time intervals, such as daily, or at times requested by the system administrator. Details of these programs will be described later.
[0041] Next, the information distribution server 140 stores programs such as the management screen program 145 and the display screen creation program 146, as well as intermediate data generated during the calculation process, in its storage unit 144. The information distribution server 140 is accessed via networks 112, 115, and 116 from terminals 111 used by system administrators, terminals used by railway operators 113, and mobile information terminals 118 used by passengers 117, and provides information.
[0042] The system administrator of the travel route preference estimation system 105 can check the configuration and status of data stored in the travel route preference estimation system 105, the processing execution status and calculation results of the computing server 130, and the usage status of users, etc., from a terminal via the network 112.
[0043] Figures 3A, 3B, and 3C illustrate the data structure of station / route information 123 stored in the data server 120. The station / route information 123 consists of station information 310 in Figure 3A, route information 320 in Figure 3B, and station / route relationship information 330 in Figure 3C.
[0044] The station information 310 in Figure 3A includes information such as station ID 311, station name 312, owning company 313, location 314, and latitude and longitude information 315, and is data that shows the geographical location information of the station. The route information 320 in Figure 3B includes items such as route ID 321, route name 322, direction 323, and type 324, and represents data that expresses the common name of the route. The station / route-related information 330 in Figure 3C includes information such as route, line ID 331, station ID 332, and travel order 333, and represents the order in which stations are arranged on each route.
[0045] Station and route information 123 is updated and recorded by the railway operator or system operator from outside the system when changes occur. Furthermore, if, for example, the operating pattern differs depending on the day of the week, multiple tables may be maintained and switched depending on the day of the week for which data processing is being performed.
[0046] Figure 4 illustrates the relationship between stations, lines, and train types. While the common names and definitions of train types vary among railway operators, here we will use express trains and local trains as examples. Generally, local trains stop at every station on a given line, while express trains often have a mix of stops and through stations. Figure 4 shows the relationship between each train type and its stops, and can be generated from station / line information 123. In this case, the line ID and the order of stations must be defined for each train type.
[0047] Figure 5 shows the data structure of the transfer route master 124 stored in the data server 120. The transfer route master 124 includes information such as departure station ID 301, arrival station ID 302, first boarding route ID 303, first boarding station ID 304, first alighting station ID 305, second boarding route ID 306, second boarding station ID 307, and second alighting station ID 308, and shows information about the routes and boarding / alighting stations used to reach the arrival station from the departure station.
[0048] When using a single line from the departure station to the arrival station, the information can be represented by just three pieces of information: the first boarding line ID, the first boarding station ID, and the first alighting station ID. However, when traveling using multiple lines, three pieces of information, such as the second boarding line ID, the second boarding station ID, and the second alighting station ID, form a set, and the above information is stored for all lines used.
[0049] On a line where multiple train types operate, and where the boarding and alighting stations allow boarding and alighting using multiple train types, the boarding route ID will contain multiple candidates. For example, as shown in the second record in Figure 5, if the departure station ID is 1001 and the arrival station ID is 1013, and boarding and alighting are possible using either a local or express train, then the first boarding route ID field will store two route IDs: one for the local train and one for the express train.
[0050] If the type of train service or the interval between trains changes significantly depending on the day of the week or time of day, a transfer route master may be maintained separately for weekdays, holidays, and time of day. To create the transfer route master 124, the search results of a general transfer information service may be used, or the transfer route master generation program described in Figure 10 may be used.
[0051] Figure 6 shows the data structure of the timetable information 125 stored in the data server 120. The timetable information 125 includes information such as train ID 341, route ID 342, type 343, station ID 344, running sequence 345, stop classification 346, arrival time 347, departure time 348, and passenger capacity information 349, and represents the train operation plan information.
[0052] The stop classification 346 stores a value indicating whether the train passes through or stops. If the stop classification is "pass through," it is not necessary to store arrival or departure times. Timetable information 125 is updated by receiving data from the railway management system's timetable planning system, operation management system, and train information management system as needed.
[0053] Figure 7 shows the data structure of arrival and departure data 126 stored in the data server 120. The departure / arrival data 126 includes information such as trip ID 351, departure station ID 352, arrival station ID 353, entry time 354, exit time 355, number of people 356, and route 357, showing spatiotemporal information of the passenger's travel behavior, such as which station they departed from and at what time, and which station they arrived at and at what time, as well as the number of people. Here, the trip ID is a unique value.
[0054] The arrival and departure data 126 can be generated by using the ticket gate passage data to aggregate the number of passengers who entered a station within a specified time period and then disembarked at that station. The granularity of the entry time (354) and exit time (355) should preferably be fine, such as in seconds, but it can also be stored in any unit, such as 1 to 3 minutes. However, the granularity of the time must be finer than the train operating interval of the route being analyzed.
[0055] Route 357 is a list of route ID, boarding station ID, and alighting station ID information for each combination of departure station ID 352 and arrival station ID 353, and is stored by referencing the information in the transfer route master 124. The information for departure station ID 352, arrival station ID 353, entry time 354, exit time 355, and number of people 356 is generated by collecting and aggregating the information read by the automatic ticket gate 101 in the data server.
[0056] In this embodiment, route 357 is described as data uniquely assigned to a combination of departure station ID 352 and arrival station ID 353, but it is also possible to have multiple routes. In that case, it is preferable to store information on multiple routes and route selection probabilities for a combination of departure station ID 301 and arrival station ID 302 in advance in the transfer route master 124.
[0057] For example, as shown in the first record in Figure 7, suppose there were 6 passengers, each with departure station ID 352 as 1001, arrival station ID 353 as 1004, entry time 354 as 2020 / 3 / 21 12:00, and exit time 355 as 2020 / 3 / 21 12:15. In this case, the combination of departure station ID 352 and arrival station ID 353 (1001 and 1004) is used as the key to refer to the transfer route master 124, and records corresponding to this combination are extracted. The total number of people, 6, is allocated using the route information (first boarding route ID 303 and later) and route selection probability information from the transfer route master 124, and stored together with the information for each route.
[0058] For listing multiple routes and setting route selection rates, possible methods include using search results from typical transit guidance apps or estimating them using mobile phone location data. The departure and arrival data 126 may also include passenger profile information such as gender, age, and whether or not they hold a commuter pass, and it is possible to use this information to vary the route selection rate for each profile.
[0059] The arrival and departure data 126 may be received in real time each time a passenger passes through any ticket gate, aggregated and stored, or the received data may be processed in batches according to a certain update timing, and the data server 120 should perform the storage process in accordance with the transmission timing.
[0060] Furthermore, the data source for the number of people passing through the ticket gates (356) in the arrival / departure data (126) is not limited to ticket gate passage history; it may also be aggregated using IC card history. Additionally, at stations without automatic ticket gates or where IC cards cannot be used, surveillance cameras or motion sensors may be installed near the ticket gates, and the number of people entering and exiting the gates may be obtained using video analysis and signal analysis technologies. The aggregation of the number of people passing through the gates and the usage history of IC cards, as well as the calculation of the number of people entering and exiting the gates using video analysis and signal analysis, may be performed on the data server (120) or outside the system.
[0061] Figure 8 shows the data structure of the travel path search results 127 stored in the data server 120. The travel route search result 127 includes information such as trip ID 371, search criteria 372, departure station ID 373, arrival station ID 374, number of people 375, boarding time 376, alighting time 377, first route ID 378 (route ID[1]), first train ID 379 (train ID[1]), and combination of first boarding station ID and first alighting station ID 380 (boarding station ID - alighting station ID[1]), and stores the results of searching for the train that was boarded for each record of the departure and arrival data 126.
[0062] The values from each record of the departure and arrival data 126 are stored as is in Trip ID 371, Departure Station ID 373, Arrival Station ID 374, First Route ID 378, and the combination 380 of the First Boarding Station ID and First Alighting Station ID.
[0063] The item in Search Criteria 372 stores the criteria information used when searching for the train you boarded. For example, if you search for the train that can reach the arrival station earliest, using the entry time 354 of each record in the departure / arrival data 126 as the starting point, the string "Entry Time" will be stored. Similarly, if you search for the train that can arrive at the time closest to the departure time, using the departure time 355 as the starting point, the string "Departure Time" will be stored.
[0064] Figure 9 shows the data structure of the travel route preference estimation result 128 stored in the data server 120. The travel route preference estimation result 128 includes information such as the trip ID 391, the combination of departure and arrival stations 392 (departure station - arrival station), the train number used 393, the type of train used 394, the type of train not used 395, the train type selection station 396, the travel route preference 397, and the number of people 398. It stores the results of estimating the travel route preference using the search results stored in the travel route search result 127.
[0065] The values from each of the 126 records in the Trip ID (391), the combination of departure and arrival stations (392), and the number of people (398) are stored directly.
[0066] The train number 393 and train type 394 will store the result information of the train search based on the entry time 354 and the train search based on the exit time 355, whichever result is considered to be the one actually used by the passenger. For train type 395, which was not used, the information for the result that was deemed not used by the passenger will be stored.
[0067] The train type selection station 396 stores information about stations where two options exist (stations where a train was selected) by comparing the results of searching for trains based on the entry and exit times. The 397 items of travel route preference store the results of estimating passenger preferences based on difference information (comparison information of train search results).
[0068] Next, Figure 10 illustrates the procedure for generating the transfer route master 124 (Figure 5) stored in the data server 120, which is generated by the transfer route master generation program 135 (Figure 2) of the computing server 130.
[0069] The transfer route master generation program 135 uses the departure and arrival data 126, station and route information 123, and timetable information 125 stored in the data server 120 to obtain route information for each trip and registers it in the transfer route master 124.
[0070] First, in step S501, the transfer route master generation program 135 reads the departure and arrival data 126.
[0071] Next, in step S502, the transfer route master generation program 135 reads the station and route information 123.
[0072] In step S503, the transfer route master generation program 135 repeats the processing from steps S504 to S511 for each record of the departure and arrival data read in step S501.
[0073] In step S504, the shortest route is determined using the combination of departure station ID 352 and arrival station ID 353 included in the departure / arrival data 126, the entry time 354, and the transfer route master 124. As a result, the route ID that allows the fastest arrival at departure station ID 352 and arrival station ID 353 is determined.
[0074] In this case, on routes where multiple train types are in operation, the route ID that generally corresponds to the fastest train, such as an express train, is likely to be output as the result. However, the transfer route master generation program 135 outputs not only the route ID with the shortest travel time, but also candidate route IDs for different train types if they can be used.
[0075] In step S505, the following processing is performed on the route ID of the route used, which was obtained in step S504. Note that the following explanation describes an example where one route ID was obtained in step S504, but if route IDs for multiple routes are obtained, that is, if a transfer to another route is required along the way, the following processing is repeated for each route used.
[0076] First, based on the departure station ID 352 included in the arrival / departure data, the system references the route information 320 and station / route relationship information 330 to extract all route IDs that have the same route name 322 as the route used in step S504 and that stop at the departure station. The extracted list of route IDs is stored as the variable L_dep.
[0077] In step S506, similarly, based on the arrival station ID 353 included in the departure and arrival data, the route information 320 and station / route relationship information 330 are referenced to extract all route IDs that have the same route name 322 as the route used in step S504 and that stop at the arrival station. The list of extracted route IDs is stored as the variable L_arr.
[0078] In step S507, the contents stored in the variables L_dep and L_arr are compared to determine whether they are identical. In other words, step S507 compares the results of the travel route search based on the departure time at the departure station with the results of the travel route search based on the departure time at the arrival station.
[0079] If the two lists are identical (Yes in S507), then it can be assumed that the available routes from the departure station to the arrival station match the contents stored in the variable L_dep, as it is possible to get off at the arrival station regardless of which route stops at the departure station. Therefore, the process proceeds to step S511, and the contents of the variable L_dep are registered in the transfer route master.
[0080] In step S507, if the contents stored in the variables L_dep and L_arr are different (No. in S507), then for some routes that stop at the departure station, it may not be possible to alight at the arrival station. Alternatively, there may be route IDs that do not stop at the departure station but do stop at the arrival station.
[0081] Specifically, this applies to cases where the departure station is only served by local trains, and the arrival station is served by both local and express trains. In such cases, it is necessary to divide the route from the departure station to the arrival station into several parts and list the possible routes, which are processed as follows.
[0082] In step S508, the system searches for a station closest to the departure station in the travel sequence from the departure station to the arrival station where all train types stop (a station where it is possible to transfer to a different type of train).
[0083] Similarly, in step S509, the system searches for a station closest to the arrival station in the travel sequence from the arrival station to the departure station where all train types stop (a station where passengers can transfer to a different type of train).
[0084] In step S510, the route from the departure station to the arrival station is divided into three parts: the first ride from the departure station to the transfer station determined in step S508, the second ride from the transfer station determined in step S508 to the transfer station determined in step S509, and the third ride from the transfer station determined in step S509 to the arrival station. The candidate route IDs for each part are then extracted. The candidate route for the first ride corresponds to the variable L_dep. The candidate route for the second ride includes all train types. The candidate route for the third ride corresponds to the variable L_arr. If the transfer station determined in step S509 and the transfer station determined in step S510 are the same station, the second ride can be omitted. In other words, if the comparison of the results of the travel route search is different (if step S507 is No), steps S508 to S510 determine the route used by the passenger and estimate the passenger's preferences from the route (train type).
[0085] Then, in S511, the divided route IDs and transfer stations are registered in the transfer route master.
[0086] In S512, if the processing of steps S504 to S511 for the arrival and departure data has been repeated, the process is terminated.
[0087] Figure 11 is a flowchart showing the processing procedure for searching for a travel path in the travel path search program 136.
[0088] The travel route search program 136 reads the arrival and departure data 126 stored in the data server 120, and for each of the two search criteria, "arrival time" and "departure time," it calls a train estimation program that searches for the train number used, and outputs the travel route.
[0089] First, in step S601, the travel route search program 136 reads the departure and arrival data 126.
[0090] Next, in step S602, the travel route search program 136 repeats the processing from step S603 to step S605 for each record of the departure and arrival data read in step S601.
[0091] In step S603, the travel route search program 136 searches for a travel route by executing the process in step S604 twice for each departure and arrival data. One search is based on the "entry time" (entry time-based), and the other search is based on the "exit time" (exit time-based).
[0092] In step 604, the travel route search program 136 calls the train estimation program to search for the travel route for each search criterion, i.e., the train number used. At that time, the program passes the value of the search criterion and the record information of the departure and arrival data to the train estimation program as program arguments.
[0093] In step S605, once the travel route search program 136 has completed the search based on entry time and exit time, it proceeds to step S606. In step S606, once the travel route search program 136 has finished repeating for the departure and arrival data, it proceeds to step S607.
[0094] In step S607, the travel path search program 136 stores the travel path search result returned from the train estimation program in step S604 in the travel path search result 127.
[0095] Figure 12 is a flowchart showing the processing procedure of the train estimation program called from the travel path search program 136 described in Figure 11. The train estimation program should be executed on the calculation server 130 (Figure 2).
[0096] The train estimation program reads the arrival and departure data 126 stored in the data server 120, refers to the route information of each data, associates it with available trains, obtains the train number used, and outputs the travel route. The train estimation program is called from within the travel route search program 136 when the travel route search program 136 is executed.
[0097] First, in step S701, the train estimation program obtains the travel route search criteria passed from the travel route search program 136. The travel route search criteria are one of two types: "entry time" and "exit time".
[0098] Next, the train estimation program retrieves the departure and arrival data records passed from the travel route search program 136 in step S702, and if the search criterion is "departure time", it performs data conversion processing.
[0099] When the search criterion for the train estimation program is "arrival time," it uses the departure and arrival data records directly to find the shortest route that will get you to the arrival station as quickly as possible, based on the departure station and arrival time.
[0100] When the search criterion for the train estimation program is "departure time," it searches for the shortest route starting from the departure time, as it seeks the travel route closest to the departure time at the arrival station.
[0101] For more details, if the search criterion is "departure time," you need to swap the departure station and arrival station values in the departure / arrival data with the entry time and departure time values when performing a route search. In other words, if the search criterion is "departure time," the arrival station 353 in the departure / arrival data is treated as the calculated departure station, and the departure time 355 is treated as the calculated departure time.
[0102] In step S703, the train estimation program reads the timetable information 125. At this time, the timetable information 125 is also converted if the search criterion is "departure time," similar to step S702. Specifically, the order of stations 344 is reversed in the timetable information 125. Also, the arrival time 347 and departure time 348 for each station are swapped.
[0103] In step S704, the train estimation program refers to the route 357 included in the departure / arrival data 126 record and repeats the process from step S705 to step 708 for the number of routes used.
[0104] In step S705, the train estimation program obtains the route ID to be used from route 357 and searches for the train that runs on that route and arrives at the boarding station earliest after the entry time 354.
[0105] In step S706, it is determined whether or not it is possible to board the train that was searched for. Specifically, the number of passengers on the searched train is referenced, and if the number of passengers (336) included in the currently processed departure and arrival data record does not exceed the capacity indicated in the capacity information (349), it is determined that boarding is possible. If it exceeds the capacity, boarding is not possible. If it is determined that boarding is not possible (NO in S706), the process returns to step S705, and the next train arriving at the station is used as a candidate for the same determination process.
[0106] In this case, the capacity may be the same as the capacity information 349 included in the timetable information 125, or a margin may be set, such as allowing up to the value of capacity information 349 + 100 people, or allowing up to a multiplier of the value of capacity information 349. The degree of the margin may also be adjusted for each route or time slot.
[0107] If a train with available passengers can be found in step S706 (YES in S706), proceed to step S707, where the boarding section (all stations between the boarding station and the alighting station) of the currently processed departure / arrival data record is referenced, added to the passenger information for the relevant train, and stored. The information of the found train ID is retained (step S707).
[0108] Furthermore, in step S707, the waiting time for the train is calculated and stored from the difference between the entry time 354 of the currently processed arrival / departure data record and the departure time 348 of the corresponding train ID. In reality, the time required for walking from the ticket gate at the departure station to the platform where the train for the first line to be used will arrive is also necessary, so this walking time may be taken into consideration and a certain amount of time may be deducted.
[0109] In step S708, the train estimation program, as part of the disembarkation process, refers to the arrival time 347 when the current train ID arrives at the disembarkation station, and searches for trains available for boarding on the next route to be used, with arrival times 347 or later. Here, the time from the departure time of the relevant train ID from the boarding station to the arrival time at the disembarkation station is stored as the boarding time.
[0110] In step S709, the train estimation program repeats the process from steps S705 to 708 for the number of routes used, and then proceeds to step S710.
[0111] In step S710, if the train estimation program successfully searches for available trains for all routes used and confirms that it will arrive at arrival station 353 included in the departure / arrival data record, it adds the stored train ID, train boarding / alighting times, and other information to the departure / arrival data record and returns it to the travel route search program 136 that called the train estimation program.
[0112] Figure 13 is a flowchart showing the processing procedure of the travel route preference estimation program 137, which estimates the preference for travel routes. The travel route preference estimation program 137 reads the travel route search results 127 stored in the data server 120, compares the results of searching for travel routes using two search criteria for each trip, estimates the passenger's travel preference from the difference, and outputs the result. This travel route preference estimation program 137 may be executed automatically when the travel route search program 136 is executed and processing is completed, or it may be executed at any time the system user chooses.
[0113] In step S801, the travel route preference estimation program 137 reads the travel route search results 127.
[0114] Next, in step S802, the travel route preference estimation program 137 refers to the trip IDs 391 included in the travel route search results 127 and creates a list of unique trip IDs.
[0115] In step S803, the travel route preference estimation program 137 repeats the processes from steps S804 to S807 for each trip ID, based on the list of trip IDs created in step S802.
[0116] In step S804, the travel route preference estimation program 137 obtains the results of a route search from the travel route search results 127 for records with the trip ID to be processed, using two search criteria: "entry time" and "exit time".
[0117] In step S805, the travel route preference estimation program 137 determines whether there is a difference in the route ID 378 and train ID 379 items included in the two obtained results. For trips that do not include transfers, it is sufficient to compare the route ID and train ID only for the first ride, but for trips that include transfers, the same comparison is performed for the second and subsequent rides as well.
[0118] If the search result matches in step S805 (NO in S805), proceed to step S808 and process the next trip.
[0119] In step S805, if there is a difference in route ID 378 or train ID 379 between the two search results (YES in S805), in step S806, the travel route preference estimation program 137 refers to the boarding station and alighting station combination 380, obtains the boarding station information for the part where the difference appears, and obtains the train type 343 by referring to the timetable information 125 from train ID 379.
[0120] In step S807, the travel route preference estimation program 137 stores the travel route preference estimation result 128. Specifically, the trip ID 391, the combination of entry and exit stations 392 (departure station - arrival station), and the number of people 398 in the travel route preference estimation result 128 are stored as they are, based on the values included in the departure and arrival data, while the items from the train number 393 onwards are stored based on information extracted from the travel route search result 127.
[0121] For example, if the results of a search based on "departure time" are treated as the passenger's actual selection, the train number 393 and the type of train used 394 will store information obtained from the search based on "departure time," while the type of train not used 395 will store information obtained from the search based on "arrival time." The train type selection station 396 stores the value of the boarding station where the difference occurred, as determined in step S806. The travel route preference 397 stores preference pattern information based on predetermined label information, using the type of train used 394 and the type of train not used 395. The setting of label information is explained in Figure 14.
[0122] In step S808, the travel route preference estimation program 137 terminates its operation after repeating the processes from steps S804 to S807 for the number of trips required.
[0123] Next, Figure 14 illustrates an example of an execution process management screen where a user of a system for estimating travel route preferences inputs analysis conditions. The execution process management screen 1001 (hereinafter referred to as screen 1001) contains boxes for selecting options and text input fields, allowing users to choose conditions from a set of options or input individual conditions according to their specific analysis needs.
[0124] The screen 1001 in Figure 14 displays a field 1002 for selecting the main search criteria from the top, a field 1003 for setting labels related to the preference of travel routes, and a field 1004 for selecting the analysis process. In addition, there may be fields for specifying the analysis period, such as year, month, and day, weekdays / holidays, and the routes to be analyzed in detail.
[0125] In section 1002, where the primary search criteria are selected, a pull-down menu is used to specify whether to base the search on "entry time" or "exit time" to represent the actual travel time of the passenger. Since the appropriateness of each search criterion may vary depending on factors such as the station's structure and the availability of commercial facilities, the primary search criteria may be selectable for each line, station, day of the week, or time of day. If there are many possible combinations of selections, an interface may be provided to upload a list or similar document in text file format.
[0126] The field 1003 for setting labels related to travel route preferences includes a table listing patterns of train types and transfer status for both used and unused routes, as well as an interface for inputting travel route preference label information.
[0127] Based on information about the routes used and not used, users can input intuitively understandable labels such as "prioritize speed" or "prioritize seating" as text input. In addition to text input, there may also be an interface that allows users to select from pre-defined options. The label information set here is referenced within the travel route preference estimation program 137 and used in the travel route preference 397 item of the travel route preference estimation result 128.
[0128] The section 1004 for selecting the analysis process is equipped with three buttons: a "Start" button 1006, a "Cancel" button 1007, and a "Show Results" button 1008.
[0129] After selecting the main search criteria in section 1002 and setting labels in section 1003 for setting labels related to the preference of the travel route, pressing the "Start" button 1006 will execute the process of estimating the preference of the travel route using the travel route preference estimation program 137, as explained in Figure 13.
[0130] Pressing the "Cancel" button 1007 will interrupt the process of estimating the preference for the travel route. Pressing the "Show Results" button 1008 will bring up a screen that displays the results of the calculation obtained from the process of estimating the preference of travel routes, along with the results in a graph. If the primary search criterion is not selected, or if a preference label has not been set, all buttons in the section 1004 for selecting the analysis process may be disabled (cannot be pressed).
[0131] Alternatively, the progress of the transfer route master generation program 135 (Figure 10), the travel route search program 136 (Figure 11), the train estimation program (Figure 12), and the travel route preference estimation program 137 (Figure 13) may be monitored, and the enable / disable status of the "Cancel" button 1007 may be controlled.
[0132] The travel route preference estimation system 105 may manage the execution of multiple analysis processes simultaneously, in which case it is desirable that the user be able to check all currently running processes on the screen. In addition, the progress of the transfer route master generation program 135 (Figure 10), travel route search program 136 (Figure 11), train estimation program (Figure 12), and travel route preference estimation program 137 (Figure 13) may be displayed on the management screen or in a separate pop-up screen.
[0133] This allows users to understand how long the process is likely to take, enabling them to temporarily suspend the process if it seems to be taking longer than expected, narrow down the stations to be analyzed, and then restart the process.
[0134] Furthermore, the "Show Results" button 1008 becomes active when the processing of the travel route preference estimation program 137 (Figure 13) is completely finished. An example of the screen obtained by pressing the "Show Results" button 1008 is shown in Figures 16 and 17.
[0135] Figure 15 is a flowchart of the management screen program 145 (Figure 2) that manages the execution process of the travel path preference estimation system 105. The management screen program 145 is executed, for example, on the execution processing management screen 1001 (Figure 14) of the travel route preference estimation system, when the user sets conditions and presses the "Start" button 1006.
[0136] In step S1101, the analysis conditions, such as the main search criteria and preference labels, specified on the execution process management screen 1001 of the movement path preference estimation system are first read.
[0137] In step S1102, the content of the analysis process specified on the execution process management screen 1001 of the movement path preference estimation system is then read.
[0138] In step S1103, if the content of the analysis process obtained in step S1102 is "start", the process of the movement path preference estimation program 137, as explained in Figure 13, is executed with the analysis conditions as arguments. In this case, the execution timing may be immediate, or a job may be registered so that the process starts at a specified time.
[0139] Figure 16 shows an example of a display screen for the travel route preference estimation results 128. Screen 1101 aggregates passenger travel route preferences for the analyzed routes in graph form, broken down by station, time of day, and train schedule, and visualizes them according to the display conditions.
[0140] By specifying the display conditions for each graph, it is possible to analyze in detail the types of trains that passengers prefer to use, broken down by station and time of day. This is expected to be useful for railway operators in making decisions regarding transportation planning, such as confirming the effectiveness of current transportation plans and identifying areas for improvement in future transportation plans.
[0141] There are various ways to present the data in graphs. For example, in addition to actual numerical values, methods such as showing the percentage composition based on the number of entries per station or per time period are possible. In the example in Figure 16, the aggregated results by station and time period are shown in a bar graph, but this is not the only way to display the data. It can also be displayed in the form of a table, pie chart, or radar chart.
[0142] Furthermore, the system may have a function that allows users to compare time-based graphs for multiple stations side-by-side, or a function that allows users to compare results for specific stations or time periods with different analysis periods.
[0143] The same applies to train schedules; there could be a function to display and compare train schedules for multiple routes, or a function to display and compare results for different analysis periods for specific routes or time slots. For example, it could be used to analyze changes in passenger travel route preferences by displaying analysis results based on the current transportation plan alongside analysis results based on the previous transportation plan.
[0144] If the arrival and departure data 126 includes attribute information such as passenger gender and age, the system may have a function to filter the display conditions based on this attribute information. This would allow for a detailed analysis, for example, of which travel routes are preferred by age.
[0145] Furthermore, the system may include a function that allows users to view detailed information about specific stations, time slots, or trains in a pop-up window by clicking on the train schedule or station / time-specific graphs with the mouse. Figure 16 shows an example of a pop-up window that appears when clicking on the line around "Station 1002" for train number 381 on the train schedule. In the pop-up window, for example, users can check the number of passengers who are intentionally waiting for this train number 381 at "Station 1002".
[0146] Figure 17 shows another example of a display screen for estimating travel route preferences. Figure 17 is a screen for getting an overview of passenger travel route preferences for trains and stations throughout the entire area under analysis, with a map screen 1111 placed within screen 1101.
[0147] On the map screen 1111, trains running on each line are displayed as icons color-coded according to values such as the number of passengers. Similarly, stations are displayed as icons of varying sizes and colors, adjusted based on values such as the number of people waiting for a particular train. For trains, information such as train delays may also be displayed. Train delay information can be obtained from the difference between the planned timetable and the actual running time.
[0148] The map screen 1111 features a time slider, allowing users to track the movement of trains throughout the day, as well as changes in train passenger numbers and the number of people waiting for specific trains at stations. The intention behind the display of the screen in Figure 17 is to provide a screen that displays the number of people waiting for specific trains at stations, train passenger numbers (i.e., congestion rates), and average train delay information for the area being analyzed, all on a single screen, allowing users to simultaneously view the relationships between these factors.
[0149] The map screen 1111 can be operated using input interfaces such as a mouse and keyboard. For example, users can zoom in / out on the map screen using the scroll wheel buttons, or change the map's display position by dragging with the mouse. The layout of the route map and stations may be determined considering actual spatial location information, or they may be arranged in a way that fits on a single screen.
[0150] Furthermore, in large metropolitan areas, the number of routes is large, and it is anticipated that it will be difficult to list all routes due to screen space limitations. Therefore, it would be a good idea to allow users to select which routes to display. Here, the color and size of the train icons running on the map should be changed based on the average or maximum number of passengers, delay time, etc. For example, different colors could be defined for several stages of passenger occupancy, such as 0% to less than 50%, 50% to less than 100%, 100% to less than 150%, and 150% or more.
[0151] It is desirable that the display format of these train icons and the content of the station occupancy display be customizable by the user. The selection of display content can be done through an interface that allows the user to select a single option or an interface that allows the user to select multiple indicators simultaneously. It would also be desirable to have a function that allows users to click on the train icon or station icon with a mouse to calculate the number of passengers waiting for that train and view it in a pop-up window. The number of passengers waiting for a specific train can be calculated by aggregating the travel route preference estimation results 128.
[0152] Figure 17 shows an example where clicking on train number 101 displays a pop-up screen 1112. It also shows an example where clicking on station 1005 displays a pop-up screen 1113.
[0153] When the information distribution server 140 receives conditions entered by a user via the on-screen condition setting function, or operations performed via the mouse or keyboard input interface, it recreates the display screen according to those conditions and distributes it to the device that sent the request.
[0154] These processes are performed by the display screen creation program 146. On the pop-up screen, for example, information such as the train type for train number 101, the number of passengers intentionally waiting for this train, and the ratio of passengers to the number of crew members can be viewed. Additionally, at station 1005, information regarding the travel route preferences of passengers about to board the train can be viewed.
[0155] By presenting system operators and railway companies with a screen that allows them to view passenger travel route preferences linked to train operation status, it becomes possible to analyze whether current transportation services align with passenger preferences and utilize this information in future transportation planning. Furthermore, it can be used for passenger information at stations and on trains.
[0156] Figure 18 is a flowchart of the processing of the display screen creation program 146 (Figure 2) of the information distribution server 140. The display screen creation program 146 is executed when the user presses the "Display Results" button 1008 on the execution process management screen 1001 of the travel route preference estimation system.
[0157] First, in step S1201, the display screen creation program 146 acquires the display conditions. The display conditions are the selection of the main search criteria and the preference label setting information, as shown in the execution process management screen 1001 of the movement path preference estimation system in Figure 14.
[0158] The execution process management screen 1001 of the travel route preference estimation system is shown in the diagram, but only the "Display Results" button 1008 is displayed. However, pressing this "Display Results" button 1008 may bring up a detailed screen regarding display conditions, allowing the user to specify the conditions. In that case, it would be good to be able to select the type of results display screen, specify the stations to be displayed, and specify the unit of data aggregation as display condition settings.
[0159] In step S1202, the display screen creation program 146 refers to the travel path preference estimation result 128 based on the display conditions and extracts the relevant data. Then, it aggregates the extracted data according to the display conditions (step S1203) and plots it in the specified graph format (step S1204).
[0160] The information distribution server 140 may combine multiple display screen creation programs 146 to create the screen to be distributed, according to the characteristics of the receiving device and the content of the information to be distributed. For example, web server technology can be used to distribute the screen, and the distributed information can be viewed by a web browser running on the receiving device. Alternatively, a dedicated application running on the receiving device may create the screen to be displayed using data sent from the information distribution server 140.
[0161] Figure 19 shows an example of a transfer guidance screen delivered to passengers. Using the travel route preference estimation results 128, it is possible to calculate the popularity of each train based on the number of passengers who have chosen and used a particular train. This allows for applications such as displaying search results on the transfer guidance search results screen 1201 in order of popularity (in order of the number of passengers who have chosen and used that train), providing this information as a reference for passengers when choosing a train.
[0162] In addition to sorting by popularity, other methods such as displaying the average number of people using each train or showing the percentage of passengers that make up the train's capacity could also be used. This would allow passengers to predict which trains are likely to have seats available and which are likely to be crowded, enabling them to decide which train is best suited to their individual circumstances and needs.
[0163] As described above, embodiments of the present invention can be used to estimate the number of people occupying a station by utilizing vehicle load data, which is easily available in real time, and supplementing it with data on passengers entering and exiting through ticket gates, etc.
[0164] The present invention is not limited to the embodiments described above, and various modifications are possible. The embodiments described above can be combined as appropriate. For example, it is possible to replace a part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. Furthermore, it is possible to add, delete, or replace parts of the configuration of one embodiment with the configuration of another embodiment. [Explanation of Symbols]
[0165] 1 Departure station, 2 Arrival station, 101 Automatic ticket gate, 102 Train, 105 Travel route preference estimation system (passenger analysis system), 106 Network, 111 Terminal, 112, 115, 116 Network, 113 Railway operator, 114 External system, 117 Passenger, 118 Mobile information terminal, 120 Data server, 121 Data storage unit, 123 Station / route information, 124 Transfer route master, 125 Timetable information, 126 Departure / arrival data, 127 Travel route search results, 128 Travel route preference estimation results, 130 Computing server, 131 Network interface, 132 CPU, 133 Memory, 134 Storage unit, 135 Transfer route master generation program, 136 Travel route search program, 137 Travel route preference estimation program, 140 Information distribution server, 141 Network interface, 142 CPU, 143 Memory, 144 Storage unit, 145 Management screen program, 146 Display screen creation program
Claims
1. In a passenger analysis system for lines where multiple train types operate from the departure station to the arrival station, The results of the route search based on the entry time at the departure station are compared with the results of the route search based on the exit time at the arrival station. If the comparison of the results of the aforementioned travel route search is different, it is assumed that the passenger used a travel route based on the departure time from the arrival station. For the analyzed routes, passenger travel route preferences will be compiled in graph form by station, time of day, and train schedule, and visualized according to the display conditions. A passenger analysis system characterized by the following features.
2. In the passenger analysis system described in claim 1, If the arrival time at the destination station on the travel route starting from the departure time at the aforementioned departure station is earlier than the arrival time at the aforementioned destination station on the travel route starting from the departure time at the aforementioned arrival station, it is assumed that the passenger used the travel route starting from the departure time at the aforementioned arrival station, and the customer's preference is presumed to be a seated preference. A passenger analysis system characterized by the following features.
3. In a passenger analysis system for lines where multiple train types operate from the departure station to the arrival station, A transfer route master generation unit generates a transfer route master from station and route information, timetable information, departure station ID, arrival station ID, and departure / arrival data including the entry time at the automatic ticket gate of the departure station and the exit time at the arrival station. A travel route search unit searches for routes based on entry time and routes based on exit time, using departure and arrival data including the ID of the departure station, the ID of the arrival station, the entry time of the automatic ticket gate at the departure station, and the exit time at the arrival station, the transfer route master, and timetable information. When the explored entry-based route differs from the exit-based route, the travel route preference estimation unit estimates the passenger's preferences based on the types of trains used and not used, for example, the route using the exit-based route and the route not using the entry-based route. Equipped with, The unit for estimating the preference of the aforementioned movement path is: For the analyzed routes, passenger travel route preferences will be compiled in graph form by station, time of day, and train schedule, and visualized according to the display conditions. A passenger analysis system characterized by the following features.
4. In the passenger analysis system described in claim 3, For each pair of entry and exit times in the arrival and departure data, the preference for travel routes is estimated. The data corresponding to the preference labels set as display conditions will be aggregated. A passenger analysis system characterized by the following features.
5. A method for analyzing passenger traffic on a route where multiple train types operate from the departure station to the arrival station, A step of generating a transfer route master from station and route information, timetable information, departure and arrival data including the ID of the departure station, the ID of the arrival station, the entry time of the automatic ticket gate at the departure station, and the exit time at the arrival station, A step of searching for routes based on entry time and routes based on exit time, using departure and arrival data including the ID of the departure station, the ID of the arrival station, the entry time of the automatic ticket gate at the departure station, and the exit time at the arrival station, the transfer route master, and timetable information. If the explored entry-based route differs from the exit-based route, the process involves estimating the passenger's preferences based on the types of trains used and not used for the route that utilized the exit-based route and the route that did not utilize the entry-based route. The analysis involves aggregating passenger travel route preferences for the target routes in graph form by station, time of day, and train schedule, and visualizing them according to the display conditions. The process involves estimating the preference for travel routes for each pair of entry and exit times in the arrival and departure data, and aggregating data that corresponds to the preference labels set as display conditions. A passenger analysis method characterized by including the following.