Path planning method, electronic device, computer storage medium and program product

Abstract

Embodiments of the present application provide a path planning method, an electronic device, a computer storage medium and a program product, wherein the path planning method comprises: obtaining real-time ticket checking rates and real-time passenger flow data corresponding to a plurality of entrance channels of a target venue respectively; fusing the real-time ticket checking rates and the real-time passenger flow data to generate dynamic congestion indexes corresponding to the entrance channels; based on the dynamic congestion indexes, performing path planning for a user to be entered into the target venue to obtain at least one candidate entrance channel, and recommending the candidate entrance channel to the user. Through the embodiments of the present application, the guiding efficiency and user experience when the user enters the target venue are improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a path planning method, electronic device, computer storage medium, and program product. Background Technology

[0002] In traditional performance venues such as theaters, concert halls, and stadiums, static signage such as signs, maps, and banners, along with manual guidance, are often used to guide audiences into the venue. However, the process of audience entry is often complex and unpredictable, especially during the ticket verification stage before the performance begins, when a surge in crowds frequently occurs, causing congestion.

[0003] To address this, one related technology uses historical data to predict incoming pedestrian flow, combined with manual guidance. However, this method lacks dynamic sensing capabilities, which may still lead to users concentrating at a few entrances, causing congestion and affecting entry efficiency and experience. Summary of the Invention

[0004] In view of this, embodiments of this application provide a path planning scheme to at least partially solve the above-mentioned problems.

[0005] According to a first aspect of the embodiments of this application, a path planning method is provided, comprising: acquiring real-time ticket checking rate and real-time passenger flow data corresponding to multiple entrance channels of a target venue; fusing the real-time ticket checking rate and real-time passenger flow data to generate a dynamic congestion index corresponding to each entrance channel; and, based on the dynamic congestion index, performing path planning for users waiting to enter the target venue to obtain at least one candidate entrance channel, and recommending the candidate entrance channel to the user.

[0006] According to a second aspect of the embodiments of this application, an electronic device is provided, including: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; the memory is used to store at least one executable instruction, which causes the processor to perform an operation corresponding to the method of the first aspect.

[0007] According to a third aspect of the embodiments of this application, a computer storage medium is provided that stores a computer program thereon, which, when executed by a processor, implements the method of the first aspect.

[0008] According to a fourth aspect of the embodiments of this application, a computer program product is provided, including computer instructions that instruct a computing device to perform an operation corresponding to any method of the first aspect.

[0009] According to the path planning scheme provided in this application embodiment, when guiding entry to a target venue, real-time ticket verification rate and real-time passenger flow data corresponding to multiple entrance channels of the target venue are obtained, and the real-time ticket verification rate and real-time passenger flow data are fused to generate a dynamic congestion index corresponding to each entrance channel. Because both real-time ticket verification rate and real-time passenger flow data are considered simultaneously, the real-time congestion situation at entry can be dynamically perceived, making the generated dynamic congestion index more accurate and better reflecting the congestion level of the entrance channels. Then, based on the dynamic congestion index, path planning can be performed for users waiting to enter the target venue, obtaining at least one candidate entrance channel, and recommending the candidate entrance channel to the user. This allows for the development of dynamic, personalized guidance strategies based on the dynamic congestion index, improving user guidance efficiency and user experience. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0011] Figure 1 A schematic diagram of an exemplary system to which the embodiments of this application are applicable; Figure 2 This is a flowchart of a path planning method according to an embodiment of this application; Figure 3 This is a flowchart of another path planning method according to an embodiment of this application; Figure 4 for Figure 3 A schematic diagram illustrating a scenario example of the embodiment shown; Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0012] To enable those skilled in the art to better understand the technical solutions in the embodiments of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art should fall within the protection scope of the embodiments of this application.

[0013] The specific implementation of the embodiments of this application will be further described below with reference to the accompanying drawings.

[0014] Figure 1An exemplary system applicable to embodiments of this application is shown. For example... Figure 1 As shown, the system 100 may include a server 102, a ticket verification terminal 104, and a ticket purchasing device 106.

[0015] Server 102 can be any suitable device for storing information, data, programs, and / or any other suitable type of content, including but not limited to distributed storage system devices, server clusters, computing cloud server clusters, etc. In some alternative embodiments, server 102 can perform any suitable function. In some alternative embodiments, server 102 can perform path planning to more efficiently guide users into the target venue and avoid congestion. For example, server 102 can obtain real-time ticket checking rates and real-time passenger flow data corresponding to multiple entrance channels of the target venue; fuse the real-time ticket checking rates and real-time passenger flow data to generate a dynamic congestion index corresponding to each entrance channel; based on the dynamic congestion index, perform path planning for users waiting to enter the target venue, obtain at least one candidate entrance channel, and recommend the candidate entrance channel to the user.

[0016] The ticket verification terminal 104 can interact with the server 102 and the ticket purchasing device 106 to perform electronic ticket verification operations. Based on this verification operation, the real-time ticket verification rate can be obtained. Optionally, the ticket verification terminal 104 can also be equipped with real-time people flow collection devices such as cameras or infrared sensors to obtain real-time people flow data. However, it is not limited to this; the real-time people flow collection device can also be set up independently of the ticket verification terminal 104.

[0017] The ticketing device 106 may include any device suitable for displaying information and interacting with users (e.g., ticket purchasers, users of electronic tickets, etc.). Optionally, the ticketing device 106 may receive a user's ticket purchase operation to realize the purchase of electronic tickets. Furthermore, when entry into the venue is required, the ticketing device 106 may display the electronic ticket to the ticket verification terminal, or input the electronic ticket to the ticket verification terminal via a communication link to realize the ticket verification operation. For example, in some embodiments, the ticketing device 106 may include mobile devices (such as mobile phones), tablet computers, laptop computers, and / or any other suitable type of user equipment.

[0018] The ticketing device 106 can be connected to the communication network 1082 via one or more communication links, and the communication network 1082 can be linked to the server 102 via one or more communication links. The ticket verification terminal 104 can be connected to the communication network 1084 via one or more communication links, and the communication network 1084 can be linked to the server 102 via one or more communication links. The communication links can be any communication link suitable for transmitting data, such as network links, dial-up links, wireless links, hardwired links, any other suitable communication links, or any suitable combination of such links. In some embodiments, the communication networks 1082 and 1084 can be any suitable combination of one or more wired and / or wireless networks. For example, the communication network can include any one or more of the following: the Internet, intranet, wide area network (WAN), local area network (LAN), wireless network, digital subscriber line (DSL) network, frame relay network, asynchronous transfer mode (ATM) network, virtual private network (VPN), and / or any other suitable communication network. Optionally, communication networks 1082 and 1084 can be different communication networks, or they can be the same communication network.

[0019] Based on the above system, this application provides a path planning method, which will be described below through several embodiments.

[0020] Reference Figure 2 A flowchart of a path planning method according to an embodiment of this application is shown, such as... Figure 2 As shown, the method includes the following steps: Step S101: Obtain the real-time ticket verification rate and real-time passenger flow data corresponding to the multiple entrance channels of the target venue. In this embodiment, the target venue can be a performance venue, such as a theater, concert hall, or stadium. This venue has multiple entrance channels, which serve as the core passageways for users (audience members) entering the performance venue (e.g., theater, concert hall, stadium) from the outside. These channels are primarily used for entry guidance, security checks, and ticket verification. Each entrance channel is equipped with a ticket verification terminal to verify tickets when users enter the venue. Furthermore, multiple sensors are installed in the target venue to collect venue data, including pedestrian flow, and for security inspections. Regarding the pedestrian flow collection function, this embodiment also refers to these sensors as pedestrian flow collection devices, including but not limited to cameras and infrared sensors.

[0021] When obtaining the real-time ticket verification rate for each entrance channel, considering that each entrance channel includes a ticket verification terminal for ticket confirmation, ticket verification data can be obtained in real time based on this terminal. This data can include the number of people who have successfully passed through the gate set by the terminal, as counted by the terminal. The real-time ticket verification rate, such as the number of people passing through each gate per minute, can be calculated based on this data. Additionally, when obtaining real-time pedestrian flow data for each entrance channel, the real-time pedestrian flow can be directly or indirectly calculated. Real-time pedestrian flow indicates the number of people entering the target venue through the entrance channel per unit of time. For example, human identification can be performed using data collected by cameras or infrared sensors, and then the number of people passing through each entrance channel per unit of time can be counted to obtain real-time pedestrian flow data.

[0022] Step S103: The real-time ticket verification rate and real-time passenger flow data are fused to generate a dynamic congestion index corresponding to each entrance channel. In this embodiment, the dynamic congestion index is used to indicate the dynamic throughput efficiency and congestion level of the corresponding entrance channel. By comprehensively considering real-time ticket checking rate and real-time passenger flow data, the dynamic congestion index can be determined more accurately and objectively. The fusion of real-time ticket checking rate and real-time passenger flow data can be implemented by those skilled in the art using appropriate methods. In one optional approach, congestion weights can be determined separately based on the impact of real-time ticket checking rate and real-time passenger flow data on channel congestion, and then the real-time ticket checking rate and real-time passenger flow data can be fused according to the congestion weights, such as through weighted summation, to obtain the dynamic congestion index. However, this is not limited to this; other methods such as time series fusion and streaming computing fusion are also applicable to the scheme of this embodiment. It should be understood that the larger the value of the dynamic congestion index, the higher the degree of congestion at the entrance channel.

[0023] Step S105: Based on the dynamic congestion index, perform route planning for users waiting to enter the target venue, obtain at least one candidate entrance channel, and recommend the candidate entrance channel to the user. In this embodiment, path planning is used to select at least one path with lower congestion from multiple paths, i.e., at least one candidate entrance channel, to reduce the time spent by users entering the target venue. Based on the dynamic congestion index of each entrance channel, path rules can be easily applied to the current user. For example, path rules can be applied to the current user based on their location and distance from each candidate entrance channel, recommending less congested candidate entrance channels to the current user. Furthermore, after determining the candidate entrance channel for the current user, a corresponding path can be generated to guide the user to the candidate entrance channel for ticket verification and entry.

[0024] As described above, when guiding visitors to a target venue, real-time ticket verification rates and visitor flow data for multiple entrance channels are acquired and integrated to generate a dynamic congestion index for each entrance channel. Because both real-time ticket verification rates and visitor flow data are considered simultaneously, the real-time congestion situation at the entrance can be dynamically perceived, making the generated dynamic congestion index more accurate and better reflecting the congestion level of the entrance channels. Then, based on the dynamic congestion index, path planning can be performed for users waiting to enter the target venue, resulting in at least one candidate entrance channel, which is then recommended to the user. This allows for the development of dynamic, personalized guidance strategies based on the dynamic congestion index, improving user guidance efficiency and user experience.

[0025] In some optional implementations, step S101 above, obtaining real-time pedestrian flow data corresponding to multiple entrance channels of the target venue, may include: Step S1011: Identify the waiting user queues at each entrance channel in real time, and count the queue length and movement speed of the waiting user queues.

[0026] In this embodiment of the application, based on the aforementioned traffic flow collection devices such as cameras or infrared sensors, waiting queues formed by users who have not yet entered the venue at each entrance channel can be identified and counted. These waiting queues can be used to indicate queues formed by users who have arrived at the target venue but have not yet passed through the entrance channel (such as at the ticket verification terminal) due to factors such as ticket verification.

[0027] For example, human body recognition can be performed on images captured in real time by a camera to obtain the queue of waiting users. Alternatively, changes in human body thermal radiation can be detected by an infrared sensor to perform human thermal imaging and obtain the queue of waiting users. After identifying the user queue, the number of people in the queue can be counted to obtain the queue length, such as 50 people. The time taken for each user to pass through the entrance channel can be detected in real time to obtain the movement rate of the queue, such as 2 seconds / person.

[0028] Step S1012: Determine real-time pedestrian flow data based on queue length and movement speed.

[0029] In this embodiment of the application, real-time pedestrian flow data is used to indicate the number of people entering the target venue through the entrance channel per unit time. The system can perform pedestrian flow statistics once every preset time interval (such as every minute) to obtain real-time pedestrian flow data, such as 30 people / minute.

[0030] To determine real-time pedestrian flow data, the number of people passing through the entrance channel per unit time can be calculated based on the movement rate. For example, if the movement rate is 2 people per second and the unit time is one minute, then the number of people passing through per unit time is 30. This number can then be verified using queue length (e.g., whether the number exceeds the queue length) to obtain the real-time pedestrian flow data.

[0031] For example, if the queue length is 20 people and the detected user queue movement rate is 6 seconds per person, then the number of people passing through per unit time calculated based on the average movement speed is 10 people, which is less than the queue length of the waiting user queue. Therefore, the real-time pedestrian flow data can be 10 people per minute. Alternatively, if the average movement rate is 2 seconds per person, the number of people passing through per unit time (1 minute) determined based on the average movement speed is 30 people, which exceeds the queue length of the waiting user queue. In this case, the real-time pedestrian flow data can be the queue length, i.e., 20 people per minute.

[0032] As can be seen, after obtaining the waiting user queue length and movement speed corresponding to each entrance channel, this application can obtain the real-time pedestrian flow data corresponding to each entrance channel, thereby realizing effective real-time monitoring of pedestrian flow at the entrance channels.

[0033] In some optional implementations, step S103 above, which fuses real-time ticket verification rate and real-time passenger flow data to generate a dynamic congestion index corresponding to each entrance channel, may include: Step S1031: Determine the first congestion weight corresponding to the real-time ticket verification rate and the second congestion weight corresponding to the real-time passenger flow data.

[0034] In this embodiment, the congestion weight is used to assess the impact of corresponding factors on the overall congestion status of the entrance channel. In one optional embodiment, the sum of the weights of the first congestion weight and the second congestion weight is 1. Considering the impact of real-time ticket checking rate and real-time passenger flow data on congestion in practical applications, the first congestion weight can be set to 0.7, and the second congestion weight can be set to 0.3, for example. However, this is not a limitation; the sum of the weights of the first and second congestion weights may not be 1, and can be any value that implements the scheme of this embodiment.

[0035] Step S1032: Based on the first congestion weight and the second congestion weight, the real-time ticket checking rate and real-time passenger flow data are fused to obtain the dynamic congestion index corresponding to each entrance channel.

[0036] As mentioned earlier, methods such as weighted summation, time series fusion, and streaming computing fusion can be used to fuse real-time ticket verification rate and real-time passenger flow data.

[0037] To improve fusion efficiency, in one alternative approach, considering the different dimensions of real-time ticket checking rate and real-time passenger flow data, the real-time ticket checking rate and real-time passenger flow data can first be standardized to obtain standard values ​​with unified or dimensionless dimensions, and then the fusion processing of real-time ticket checking rate and real-time passenger flow data can be performed based on the first congestion weight and the second congestion weight.

[0038] For example, the standardized value of the ticket checking rate corresponding to the real-time ticket checking rate can be expressed as: (real-time ticket checking rate - historical minimum rate) / (historical maximum rate - historical minimum rate), and the standardized value of the passenger flow corresponding to the real-time passenger flow data can be expressed as: (real-time passenger flow data - minimum observation value) / (maximum observation value - minimum observation value). For example, if the historical maximum rate of a certain entrance channel is 100 people / minute, the historical minimum rate is 40 people / minute, and the real-time ticket checking rate is 40 people / minute, then the standardized value of the ticket checking rate = (40-20) / (100-20) = 0.25.

[0039] After determining the standardized values ​​for ticket checking rate and passenger flow, the two can be weighted and merged based on the first congestion weight w1 and the second congestion weight w2. For example, the dynamic congestion index = (standardized ticket checking rate × w1) + (standardized passenger flow × w2). For instance, if the standardized ticket checking rate for entrance channel A is 0.25 and the standardized passenger flow is 0.6, then the dynamic congestion index = (0.25 × 0.7) + (0.6 × 0.3) = 0.175 + 0.18 = 0.355.

[0040] It is evident that by integrating real-time ticket checking rate and real-time passenger flow data based on the first and second congestion weights, the dynamic congestion index can better reflect the congestion situation at the entrance channels.

[0041] In some optional implementations, step S103 above further includes: Step S11: Collect ticket verification status data for multiple entrance channels.

[0042] In this embodiment, each entrance channel is equipped with a corresponding ticket verification terminal. In one optional approach, the operating status of the ticket verification terminal can also be collected to obtain the ticket verification status of the entrance channel. This ticket verification status can be used to detect whether any abnormalities have occurred during ticket verification, or whether any abnormal ticket verification events have taken place. For example, whether the ticket verification rate has changed abruptly, such as a sharp drop or increase in the real-time ticket verification rate.

[0043] Step S12: If it is determined from the collection results that there are abnormal ticket verification events in multiple entrance channels, then adjust the first congestion weight and / or the second congestion weight according to the type of abnormal ticket verification event.

[0044] For example, if the ticket verification status of a certain entrance channel indicates a sharp drop in the real-time ticket verification rate, or if the real-time ticket verification rate of the current entrance channel spikes due to the temporary closure of an adjacent entrance channel, then an abnormal ticket verification event can be identified. In this case, the type of abnormal ticket verification event can be determined first, and then the corresponding weights can be adjusted based on the determined type.

[0045] Among them, the types of abnormal ticket verification events can include the first type of event that causes a sharp drop in the real-time ticket verification rate and the second type of event that causes a sharp increase in the real-time ticket verification rate.

[0046] For example, when a Type I event occurs, a second congestion weight corresponding to real-time passenger flow data can be increased to reduce the impact of the real-time ticket checking rate indicator on the dynamic congestion index. Similarly, when a Type II event occurs, a first congestion weight corresponding to the real-time ticket checking rate indicator can be increased, thereby increasing the influence of the real-time ticket checking rate indicator on determining the dynamic congestion index. Thus, by adjusting the first and / or second congestion weights, the importance ratio of the influencing factors corresponding to the dynamic congestion index can be adjusted in real time, improving adaptability to unforeseen circumstances.

[0047] In some optional implementations, step S103 above further includes: updating the dynamic congestion index based on a preset update interval, and mapping the dynamic congestion index to the corresponding congestion interval to obtain the congestion level of the corresponding entrance channel.

[0048] In this embodiment, at least one update interval for the dynamic congestion index can be preset, and the dynamic congestion index can be updated after the update interval is reached. For example, the update interval can be set to 30 seconds, so that the dynamic congestion index is updated every 30 seconds.

[0049] After updating the dynamic congestion index, it can be mapped to the corresponding congestion intervals. Multiple congestion index ranges can be pre-defined, and a corresponding congestion level can be set for each range to map the dynamic congestion index to the corresponding congestion interval. For example, it can be divided into smooth flow intervals, lightly congested intervals, and severely congested intervals. However, it is not limited to this; in practical applications, those skilled in the art can flexibly set the required congestion intervals according to actual needs. Furthermore, both the congestion index range and the congestion level can be set according to actual needs, and this application embodiment does not impose any limitations on this.

[0050] For example, if the dynamic congestion index ranges from [0, 1], the congestion level corresponding to the range [0, 0.3) is smooth traffic, the congestion level corresponding to the range [0.3, 0.6) is light congestion, and the congestion level corresponding to the range [0.7, 1.0] is severe congestion, then a dynamic congestion index of 0.5 can be considered as light congestion.

[0051] In this embodiment, the dynamic congestion index can be updated based on a preset update interval, thereby ensuring the real-time nature of the dynamic congestion index. The updated dynamic congestion index is mapped to the corresponding congestion interval to obtain the congestion level of the corresponding entrance channel, such as smooth, light congestion, heavy congestion, etc., thereby quantifying the congestion situation at the entrance of the channel. This provides a technical basis for the system to perform route planning for users based on the congestion level, thereby improving the rationality of the route planning results.

[0052] In some alternative implementations, step S105 above, which involves route planning for users waiting to enter the target venue based on a dynamic congestion index to obtain at least one candidate entrance channel, may include: Step S1051: Based on the user's real-time location, determine the distance data between the user and each entrance channel.

[0053] To better guide users and prevent them from discovering congestion on the way or upon arriving at the venue, thus leaving no time to change routes or entrance channels, this embodiment first obtains the user's real-time location and then determines the distance data between the user and each entrance channel based on the user's real-time location, so as to provide a basis for subsequent path rules.

[0054] For example, when a location request initiated by a ticketing device is detected, the device can be instructed to detect its real-time location using GPS and send this location to the server. Then, based on this real-time location and the locations of preset points at each entrance channel, such as the ticket verification terminal, the distance data between the user and each entrance channel can be calculated.

[0055] Step S1052: Based on the distance intervals corresponding to the distance data, determine the distance weights that match each entrance channel; and determine the dynamic congestion index and the third congestion weight corresponding to each entrance channel.

[0056] For users, when they are still some distance from the target venue, the impact of the current congestion situation at each entrance can be assessed using distance weights and a third congestion weight. Specifically, when determining distance weights, a distance interval matching the user's distance data can be identified, and based on a pre-built mapping relationship between distance intervals and distance weights, a distance weight matching that distance interval can be determined.

[0057] Considering that the greater the distance between the user and the entrance passage, the longer the time it takes for the user to reach the entrance passage, and that congestion scores for entrance passages often have a certain time sensitivity, the greater the likelihood that the congestion score for a more distant entrance passage will become invalid when the user arrives. It should be understood that an invalid congestion score indicates that the congestion situation of the entrance passage has changed when the user arrives; that is, the entrance passage may have become more congested than it is currently. Furthermore, considering that users in actual navigation scenarios often prefer shorter routes, greater distance weight can be assigned to entrance passages with larger distance ranges. This would allow entrance passages farther from the user to obtain higher congestion scores, thereby reducing the likelihood of planning more distant entrance passages as candidate entrance passages.

[0058] For example, for entrance channels 1 and 2 with the same dynamic congestion index, if the distance d1 between entrance channel 1 and the user is greater than the distance d2 between entrance channel 2 and the user, then the distance weight corresponding to entrance channel 1 can be greater, so that entrance channel 1 will eventually obtain a higher congestion score, thereby reducing the probability that entrance channel 1 will be planned as a candidate entrance channel.

[0059] Similarly, the third congestion weight corresponding to the dynamic congestion index can also be determined in a similar way. That is, based on the pre-built mapping relationship between the dynamic congestion index and the third congestion weight, the third congestion weight that matches the current dynamic congestion weight is determined. Likewise, considering that the larger the dynamic congestion index, the more severe the congestion at the entrance, and the greater the influence of the dynamic congestion index in calculating the congestion score, the higher the dynamic congestion index, the higher the corresponding third congestion weight.

[0060] It should be understood that the method for determining the distance weight and the third congestion weight is not limited to the above embodiments. In another optional method, to simplify the calculation, the sum of the distance weight and the third congestion weight can be made 1. Then, after determining one of the distance weight or the third congestion weight, the other can be determined. However, those skilled in the art should understand that other methods of setting the weight to be greater than 1 are also applicable to the schemes of the embodiments of this application.

[0061] Step S1053: Based on distance weight and third congestion weight, the distance data and dynamic congestion index are fused to obtain a congestion score.

[0062] After determining the distance weight and the third congestion weight, the distance data and the dynamic congestion index can be fused based on these weights. This fusion can also employ methods such as weighted summation, time-series fusion, and streaming computation fusion, as described above, to obtain a congestion score for each entrance channel at the user's current location. For example, congestion score = distance weight × distance data + congestion weight × dynamic congestion index.

[0063] Step S1054: Perform path planning based on congestion score to obtain at least one candidate entrance channel.

[0064] After obtaining the congestion score, the entrance channels can be filtered based on the congestion score to obtain at least one candidate entrance channel for the user's current location.

[0065] In one example, at least one candidate entrance to the target venue can be obtained through the following process: (1) Sort multiple entrance channels based on congestion scores.

[0066] (2) Based on the ranking results, determine a preset number of low-congestion paths corresponding to low congestion scores in multiple entry channels.

[0067] (3) Based on the real-time location, determine at least one candidate entry channel in the low-congestion path whose distance from the real-time location meets the push conditions.

[0068] The preset number can be flexibly set by those skilled in the art according to actual needs. For example, a preset number of entry channels selected by sorting congestion scores from low to high can be used as the aforementioned low-congestion paths, or entry channels with congestion scores less than a set threshold can be used as the aforementioned low-congestion paths, etc. The preset number can be flexibly set by those skilled in the art as needed.

[0069] After identifying low-congestion routes, the system can collect data on whether the user's real-time location is within the push notification range. For example, it can collect the distance between the user and the entrance or ticket verification terminal of each low-congestion route in real time, and identify low-congestion routes that are within the push notification range as candidate entrance channels that meet the push notification criteria.

[0070] For example, if the push range is 1km, and the low-congestion paths include low-congestion path 1 corresponding to entrance channel 1, low-congestion path 2 corresponding to entrance channel 2, and low-congestion path 3 corresponding to entrance channel 3, then the distances between the user and the ticket verification terminals of low-congestion paths 1, 2, and 3 can be calculated based on the user's real-time location, resulting in distances 1, 2, and 3. If distances 1 and 2 are detected to be less than 1km, then paths 1 and 2 can be identified as candidate entrance channels within the push range, and the path planning process based on congestion scores ends. Then, the identified paths 1 and 2 can be recommended to the user for selection, and the candidate entrance channel selected by the user can be rendered in the virtual map data, thereby instructing the user to travel along that candidate entrance channel.

[0071] In this embodiment, considering that the user is in a mobile state, the distance weight and the third congestion weight can be adjusted in real time based on the distance range of the user's real-time location. This allows for flexible adjustment of the weighting ratio when determining the congestion score, taking into account both the objective limitations of physical distance and the dynamic changes in real-time congestion. Furthermore, by determining a low-congestion path that meets the push conditions, such as push distance, information push can be triggered only when the user is close to the target venue, avoiding information delays.

[0072] In some optional implementations, step S105 above further includes: Step S21: After determining that the user has reached the corresponding candidate entrance channel based on the user's real-time location, obtain the user's travel time.

[0073] In this embodiment, the user's real-time location can be compared with the coordinates of the entrance to the candidate entrance channel (such as the coordinates of the ticket verification terminal). If the coordinates are within a small range (e.g., within 1 meter), it can be determined that the user has reached the entrance of the corresponding candidate entrance channel. Then, the user's travel time can be determined based on the time difference between the start time of the user triggering the "Start Navigation" flag and the user's arrival time at the entrance channel.

[0074] Step S22: If the deviation between the travel time and the predicted travel time exceeds the deviation threshold, the recommendation priority corresponding to the candidate entry channel is adjusted.

[0075] Predicted latency refers to the time it takes for a user to reach the entrance channel (such as a ticket verification terminal), based on the real-time ticket verification rate. To determine predicted latency, the user's queuing time can be predicted based on the real-time ticket verification rate, and the predicted latency can be determined based on the queuing time.

[0076] For example, the user arrival rate λ corresponding to the entrance channel can be obtained. This user arrival rate λ indicates the number of users arriving at the entrance channel per unit time, and the real-time ticket verification rate v indicates the number of users completing ticket verification per unit time. Then, the user's queuing time w can be expressed as w = λ / v(v-λ). For example, if λ = 3 people / minute and v = 5 people / minute, then w = 3 / 5 × (5-3) = 0.3 minutes, which is approximately 18 seconds.

[0077] When the deviation between the travel time and the predicted travel time exceeds a deviation threshold, it indicates that the actual congestion at the candidate entry point is worse than predicted. Therefore, the recommendation priority of the candidate entry point can be reduced, thereby decreasing the recommendation of that candidate entry point path when planning routes for subsequent users. Here, the deviation threshold can be appropriately set by those skilled in the art based on the actual situation, such as 5 minutes.

[0078] In another optional embodiment, after determining that a user has reached the entrance of a candidate entrance channel recommended by the system, when deciding whether to adjust the recommendation priority of the candidate entrance channel, the real-time ticket verification rate of the candidate entrance channel at that time can be obtained. Based on the deviation between the real-time ticket verification rate and the predicted ticket verification rate of the system when recommending the candidate entrance channel to the user, it is determined whether to adjust the recommendation priority of the entrance channel. For example, if the system predicts a ticket verification rate of 40 people / minute when recommending a candidate entrance channel to the user, but the real-time ticket verification rate of the candidate entrance channel is 20 people / minute after the user reaches the entrance, then the deviation between the predicted ticket verification rate and the real-time ticket verification rate is 50%. If the rate threshold is 20%, then it is determined that the deviation exceeds the rate threshold, which also indicates that the actual congestion at the entrance of the candidate entrance channel is worse than the predicted situation, and the step of reducing the recommendation priority of the candidate entrance channel described above is executed.

[0079] When the deviation between a user's actual travel time and the predicted travel time exceeds a deviation threshold, the recommendation priority of the candidate entry channel can be automatically reduced. This reduces the recommendation of that candidate entry path when planning routes for subsequent users, thus improving the rationality of route planning.

[0080] In some alternative implementations, the above Figure 2 The implementation methods corresponding to the described path planning method also include: Step S31: Determine the real-time distance between the user and the target venue based on the user's real-time location.

[0081] Step S32: If the real-time distance is lower than the preset push distance, mark the candidate entry channel in the client's virtual map data.

[0082] In this embodiment of the application, considering that if the candidate entrance channel is pushed when the user is far away from the target venue, the data may become outdated and invalid due to the premature push of the candidate entrance channel, the push distance can be set in advance to ensure the timeliness of the pushed candidate entrance channel.

[0083] For example, the real-time distance between the user and the target venue can be determined based on the location coordinates of the target venue and the user's real-time location coordinates. When this real-time distance is lower than a preset push distance, a path display request is sent to the user, and virtual map data is invoked when the user responds to the request. For instance, if the preset push distance is 1km, a path display request is sent when the user reaches within 1km. It should be understood that anti-jitter measures can be set to avoid frequently triggering push requests, such as repeated pushes when the user walks around the venue within a 1km radius.

[0084] Once candidate entry points are identified, users can be instructed to access and display virtual map data through their terminal devices (which could be ticketing devices or other devices such as mobile devices). Pre-installed operation logic can be pre-programmed on the device to invoke an installed navigation application for candidate entry point labeling.

[0085] In addition, a corresponding labeling strategy can be adopted based on the congestion level of the candidate entrance channels. For example, when the congestion level is "unimpeded," the labeling strategy can be to use green; when the congestion level is "lightly congested," the labeling strategy can be to use yellow; and when the congestion level is "severely congested," the labeling strategy can be to use red.

[0086] In this embodiment of the application, when the real-time distance between the user and the target venue is lower than the preset push distance, the candidate entrance channel can be marked in the virtual map data of the client, thereby ensuring the timeliness of the push data and preventing the candidate entrance channel from being pushed too early and causing the data to become outdated and invalid.

[0087] The following, combined with Figure 3 and Figure 4 The path planning method of this application embodiment will be described by way of example. The path rule method includes: Step S201: Based on the ticket verification terminal data generated by the ticket verification terminal operation, calculate the ticket verification rate to obtain the real-time ticket verification rate corresponding to the multiple entrance channels of the target venue.

[0088] For example, the server can obtain the successful ticket verification records of each entrance channel in real time through the ticketing system interface to which the ticket verification terminal belongs, calculate the number of people passing through per minute, and thus obtain the real-time ticket verification rate of each entrance channel.

[0089] Step S202: Based on the channel sensor data collected by the channel sensor, perform pedestrian flow statistics to obtain real-time pedestrian flow data corresponding to multiple entrance channels of the target venue.

[0090] For example, the channel sensor can be implemented as a camera or an infrared sensor. By using the data collected by the camera or infrared sensor to identify and count users, real-time pedestrian flow data for each entrance channel can be obtained. Further optionally, the waiting queue length and movement speed of each entrance channel can be further differentiated.

[0091] It should be noted that steps S201 and S202 can be executed in any order or in parallel.

[0092] Step S203: By using a congestion index model, the real-time ticket checking rate and real-time passenger flow data are fused to generate a dynamic congestion index corresponding to each entrance channel.

[0093] For example, the real-time ticket checking rate and real-time passenger flow data of each entrance channel can be combined into a congestion index according to their corresponding weights, such as the real-time ticket checking rate accounting for 70% and the real-time passenger flow data accounting for 30%.

[0094] Step S204: Generate a dynamic congestion index table.

[0095] For example, a dynamic congestion index table can be generated based on the correspondence between each entrance channel and its corresponding dynamic congestion index. Optionally, this index table can also be sorted from low to high according to the dynamic congestion index.

[0096] In addition, the dynamic congestion index for each entrance channel can be updated every 30 seconds to ensure the timely updating of the dynamic congestion index table. Optionally, levels can be categorized by thresholds, such as smooth flow, light congestion, and severe congestion, and these levels can also be stored in the dynamic congestion index table for a more intuitive and rapid understanding of the congestion situation at each entrance channel. In certain situations, such as when a ticket verification terminal at an entrance channel malfunctions, the ticket verification rate may drop sharply. In such cases, the weight of the real-time passenger flow data can be automatically increased and an alarm can be triggered for timely handling, while maintaining the relative accuracy of the dynamic congestion index.

[0097] Step S205: Determine the user's real-time location and, based on the user's real-time location, perform distance calculations to determine the distance data between the user and each entrance channel.

[0098] Step S206: Based on the distance data obtained from distance calculation and the dynamic congestion index table, perform route planning for the user and generate a route recommendation list.

[0099] For example, a congestion score can be obtained by combining distance data with the dynamic congestion index of each entrance channel in the dynamic congestion index table.

[0100] For example, the congestion score = distance weight × distance data + congestion weight × dynamic congestion index. The congestion weight in this formula is the aforementioned third congestion weight.

[0101] Then, a route recommendation list (including at least one candidate entrance channel) is generated in ascending order of congestion score, prioritizing entrance channels that are "shorter in distance and have a lower congestion index".

[0102] Step S207: Perform path push trigger judgment.

[0103] Step S208: Determine whether the user is within the preset push distance (1km). If yes, proceed to step S209; otherwise, proceed to step S212.

[0104] Push notifications are triggered when the user is less than 1km away from the target venue to avoid premature recommendations that could lead to outdated information.

[0105] Step S209: Push a list of recommended routes to the user.

[0106] Step S210: Perform click detection on the user.

[0107] Detect whether the user has clicked on the entry channel corresponding to a certain path in the path recommendation list.

[0108] Step S211: After detecting that the user has clicked on the entrance channel, instruct the map to mark the path corresponding to the entrance channel. End the process.

[0109] For example, when a user clicks on a recommended entry point, the user's device, such as a mobile phone, can invoke the phone's local map application to display the path from the user's current location to the recommended entry point. Figure 4 The diagram shows different lines.

[0110] Alternatively, if the actual ticket checking rate deviates from the predicted rate by more than 20% after a user arrives at the entrance channel, the subsequent recommendation weights for that entrance channel will be automatically adjusted.

[0111] Step S212: In response to the user's location update, perform the above step S208.

[0112] In this embodiment, the method for marking candidate entry channels in the client's virtual map data when the user's real-time distance is lower than the preset push distance, i.e., when the user is within the preset push distance, is as described above. Figure 2 The corresponding implementation methods are described herein and will not be repeated here.

[0113] This embodiment collects real-time ticket checking rates and passenger flow data at each entrance channel, generating real-time ticket checking rate and passenger flow data. These two sets of data are then fused to dynamically calculate and obtain the dynamic congestion index for each entrance channel, reflecting the real-time congestion situation at each entrance channel. Furthermore, combined with the user's real-time location, a personalized entrance channel recommendation list is generated, and preferred entrance channels and routes can be pushed to avoid congestion and improve entry efficiency. The system does not rely on AR or Bluetooth beacons; standard map services are sufficient for route marking, reducing deployment costs.

[0114] Reference Figure 5 This diagram illustrates the structure of an electronic device according to an embodiment of this application. The specific embodiments of this application do not limit the specific implementation of the electronic device. For example, the electronic device may be a server-side device.

[0115] like Figure 5 As shown, the electronic device may include: a processor 502, a communications interface 504, a memory 506, and a communications bus 508.

[0116] in: The processor 502, communication interface 504, and memory 506 communicate with each other via communication bus 508.

[0117] Communication interface 504 is used to communicate with other electronic devices or servers.

[0118] The processor 502 is used to execute program 510, specifically to perform the relevant steps in the above-described path planning method embodiment.

[0119] Specifically, program 510 may include program code that includes computer operation instructions.

[0120] The processor 502 may be a CPU, a GPU (Graphics Processing Unit), an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. The electronic device includes one or more processors, which may be processors of the same type, such as one or more CPUs; or they may be processors of different types, such as one or more CPUs and one or more ASICs.

[0121] Memory 506 is used to store program 510. Memory 506 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0122] Program 510 may include multiple computer instructions. Specifically, program 510 may use multiple computer instructions to cause processor 502 to perform the operation corresponding to the path planning method described in any of the aforementioned multiple method embodiments.

[0123] The specific implementation of each step in program 510 can be found in the corresponding steps and units described in the above method embodiments, and has corresponding beneficial effects, which will not be repeated here. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the devices and modules described above can be referred to the corresponding process descriptions in the foregoing method embodiments, and will not be repeated here.

[0124] This application also provides a computer storage medium storing a computer program thereon, which, when executed by a processor, implements the method described in any of the foregoing method embodiments. The computer storage medium includes, but is not limited to, compact disc read-only memory (CD-ROM), random access memory (RAM), floppy disk, hard disk, or magneto-optical disk.

[0125] This application also provides a computer program product, including computer instructions that instruct a computing device to perform an operation corresponding to any of the path planning methods in the above-described multiple method embodiments.

[0126] Furthermore, it should be noted that the user-related information (including but not limited to client information, user personal information, etc.) and data (including but not limited to sample data used for training the model, data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this application are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0127] It should be noted that, depending on the implementation needs, the various components / steps described in the embodiments of this application can be broken down into more components / steps, or two or more components / steps or parts of the operation of components / steps can be combined into new components / steps to achieve the purpose of the embodiments of this application.

[0128] The methods described in the embodiments of this application can be implemented in hardware, firmware, or as software or computer code that can be stored in a recording medium (such as a CD-ROM, RAM, floppy disk, hard disk, or magneto-optical disk), or as computer code downloaded over a network that is originally stored in a remote recording medium or a non-transitory machine-readable medium and will be stored in a local recording medium. Thus, the methods described herein can be stored on a recording medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware (such as an Application Specific Integrated Circuit (ASIC) or a Field Programmable Gate Array (FPGA)). It is understood that the computer, processor, microprocessor controller, or programmable hardware includes storage components (e.g., Random Access Memory (RAM), Read-Only Memory (ROM), Flash Memory, etc.) capable of storing or receiving software or computer code, implementing the methods described herein when the software or computer code is accessed and executed by the computer, processor, or hardware. Furthermore, when a general-purpose computer accesses code used to implement the methods shown herein, the execution of the code transforms the general-purpose computer into a dedicated computer for executing the methods shown herein.

[0129] Those skilled in the art will recognize that the units and method steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this application.

[0130] The above embodiments are only used to illustrate the embodiments of this application, and are not intended to limit the embodiments of this application. Those skilled in the art can make various changes and modifications without departing from the spirit and scope of the embodiments of this application. Therefore, all equivalent technical solutions also fall within the scope of the embodiments of this application, and the patent protection scope of the embodiments of this application should be defined by the claims.

Claims

1. A path planning method, comprising: Obtain real-time ticket verification rate and real-time passenger flow data for multiple entrance channels of the target venue; The real-time ticket verification rate and the real-time passenger flow data are fused to generate a dynamic congestion index corresponding to each entrance channel; Based on the dynamic congestion index, a path is planned for users waiting to enter the target venue, resulting in at least one candidate entrance channel, and the candidate entrance channel is recommended to the user.

2. The method according to claim 1, wherein, The process of fusing the real-time ticket verification rate and the real-time passenger flow data to generate a dynamic congestion index corresponding to each entrance channel includes: Determine the first congestion weight corresponding to the real-time ticket verification rate and the second congestion weight corresponding to the real-time passenger flow data respectively; Based on the first congestion weight and the second congestion weight, the real-time ticket checking rate and real-time passenger flow data are fused to obtain the dynamic congestion index corresponding to each entrance channel.

3. The method according to claim 2, wherein, The method further includes: The ticket verification status of the multiple entrance channels is collected; If, based on the data collection results, it is determined that there are abnormal ticket verification events in the multiple entrance channels, then the first congestion weight and / or the second congestion weight are adjusted according to the type of the abnormal ticket verification event.

4. The method according to claim 2 or 3, wherein, The method further includes: Based on a preset update interval, the dynamic congestion index is updated, and the dynamic congestion index is mapped to the corresponding congestion interval to obtain the congestion level of the corresponding entrance channel.

5. The method according to any one of claims 1-3, wherein, Based on the dynamic congestion index, path planning is performed for users waiting to enter the target venue to obtain at least one candidate entrance channel, including: Based on the user's real-time location, the distance data between the user and each of the entrance channels is determined; Based on the distance intervals corresponding to the distance data, a distance weight matching each of the entrance channels is determined; and a dynamic congestion index corresponding to each of the entrance channels and a third congestion weight corresponding to the dynamic congestion index are determined. Based on the distance weight and the third congestion weight, the distance data and the dynamic congestion index are fused to obtain a congestion score; Based on the congestion score, path planning is performed to obtain at least one candidate entry channel.

6. The method according to claim 5, wherein, The process of route planning based on the congestion score to obtain at least one candidate entry route includes: The multiple entrance channels are sorted based on the congestion score; Based on the ranking results, a preset number of low-congestion paths corresponding to low congestion scores are determined among the multiple entry channels; Based on the real-time location, at least one candidate entry channel is determined in the low-congestion path whose distance from the real-time location meets the push conditions.

7. The method according to any one of claims 5 or 6, wherein, The method further includes: After determining that the user has reached the corresponding candidate entrance channel based on the user's real-time location, the travel time of the user is obtained; If the deviation between the travel time and the predicted travel time exceeds the deviation threshold, the recommendation priority corresponding to the candidate entry channel will be adjusted.

8. The method according to claim 1, wherein, Obtain real-time pedestrian flow data for multiple entrances to the target venue, including: Real-time identification of the waiting user queues corresponding to each of the aforementioned entrance channels, and statistics on the queue length and movement speed of the waiting user queues; The real-time pedestrian flow data is determined based on the queue length and movement speed.

9. The method according to claim 1, wherein, The method further includes: Based on the user's real-time location, determine the real-time distance between the user and the target venue; If the real-time distance is lower than the preset push distance, the candidate entry channel will be marked in the virtual map data of the user device.

10. An electronic device, comprising: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the operation corresponding to the method as described in any one of claims 1-9.

11. A computer storage medium having a computer program stored thereon, which, when executed by a processor, implements the method as described in any one of claims 1-9.

12. A computer program product comprising computer instructions that instruct a computing device to perform an operation corresponding to any one of the methods described in claims 1-9.

Images