Transport capacity management method and device and computer equipment

Abstract

The invention relates to the technical field of online car hailing, and discloses a transport capacity management method and device and computer equipment, and the method comprises the steps: a server side receives an original position point reported by a user side in a preset range, updates the original transport capacity distribution information of a geographic grid corresponding to the preset range in a server map according to the original position point, and stores the original transport capacity distribution information; generating a corresponding transport capacity scheduling strategy; and the user side sends an original position point of the user side to the server side, receives a push data packet returned by the server side based on the original position point, analyzes the scheduling suggestion information and the transport capacity feedback information in the push data packet, executes an updating operation of a user side map according to the transport capacity feedback information, and executes a reminding operation of the scheduling suggestion information at the same time. Through interactive cooperation of the server side and the user side, dynamic updating and accurate scheduling of transport capacity distribution are realized, and the utilization efficiency of transport capacity resources is effectively improved. According to the invention, the problem of unbalanced supply and demand of transport capacity caused by asymmetry of driver and passenger information in the prior art is solved.

Description

Technical Field

[0001] This invention relates to the field of ride-hailing technology, specifically to a capacity management method, device, and computer equipment. Background Technology

[0002] With the rapid development of ride-hailing services, driver capacity has increased significantly. However, demand for rides is unevenly distributed in time and space, with concentrated demand during peak hours, holidays, and in areas such as scenic spots and office buildings. This unevenness and uncertainty in demand makes capacity management difficult, requiring a technical solution that can manage capacity by area, monitor capacity hotspots in real time, and combine this with travel demand hotspots to effectively guide driver capacity to demand hotspots and solve the problem of passengers having difficulty hailing a ride.

[0003] In existing technologies, due to information asymmetry between drivers and passengers, passengers cannot obtain real-time information on surrounding transportation capacity, and drivers cannot accurately perceive areas of high demand, leading to an imbalance between supply and demand. During peak hours or in areas with concentrated demand, insufficient capacity causes passengers to wait longer; during off-peak hours or in less busy areas, excess capacity leads to resource waste. Furthermore, the lack of a mechanism for dynamically adjusting capacity makes it impossible to achieve a balanced distribution of transportation capacity. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a capacity management method, apparatus and computer equipment to solve the problem of capacity supply and demand imbalance caused by information asymmetry between drivers and passengers in the prior art.

[0005] In a first aspect, embodiments of the present invention provide a capacity management method, applied on a server side, the method comprising:

[0006] Receive raw location points reported by user terminals within a preset range; The original capacity distribution information of the geographic grid within the preset range in the server map is updated based on the original location point to obtain the updated server map; Based on the updated server map, a corresponding capacity scheduling strategy is generated.

[0007] Furthermore, the step of updating the capacity distribution information of the geographic grid within the preset range in the server map based on the original location point to obtain the target capacity distribution information includes: The original location points are filtered to obtain valid location points; Extract the latitude and longitude information contained in the effective location point, and determine at least one target geographic grid that the effective location point hits in the update server map based on the latitude and longitude information; The capacity distribution information of the target geographic grid in the server map is updated to obtain the updated server map.

[0008] Furthermore, the filtering process for the original location points to obtain valid location points includes: Obtain the timestamp and functional status associated with the original location point; Verify whether the timestamp and functional status corresponding to the original location point meet the preset filtering conditions, and obtain the verification result; The original location points whose verification results do not meet the preset filtering conditions are taken as invalid location points, and the invalid location points are removed from the original location points to obtain at least one valid location point.

[0009] Furthermore, updating the capacity distribution information of the target geographic grid in the server map to obtain the updated server map includes: Obtain the number of hits for the valid location points in the target geographic grid; The density information of the target geographic grid is calculated based on the number of hits, wherein the density information is used to characterize the degree of capacity concentration of the target geographic grid; The capacity distribution information of the target geographic grid in the server map is updated based on the density information to obtain the updated server map.

[0010] Furthermore, the generation of the capacity scheduling strategy based on the updated server map includes: The updated server map identifies imbalanced geographic grids with abnormal capacity distribution. Obtain information on the difference in capacity distribution between the unbalanced geographic grid and its adjacent geographic grids; Based on the capacity distribution difference information, determine the capacity scheduling relationship between the unbalanced geographical grid and the adjacent geographical grid; Based on the capacity scheduling relationship, a capacity scheduling strategy is generated for the unbalanced geographical grid.

[0011] Furthermore, the method also includes: Based on the updated server map, corresponding scheduling suggestion information and capacity feedback information are generated for each user terminal. The scheduling suggestion information and capacity feedback information of each user terminal are encapsulated into a corresponding push data packet, and the push data packet is sent to the user terminal.

[0012] Secondly, embodiments of the present invention provide a capacity management device applied to a server, the device comprising: The receiving module is used to receive raw location points reported by user terminals within a preset range; The processing module is used to update the original capacity distribution information of the geographic grid within the preset range in the server map according to the original location point, so as to obtain the updated server map; The generation module is used to generate a corresponding capacity scheduling strategy based on the updated server map.

[0013] Thirdly, embodiments of the present invention provide a capacity management method applied to a user terminal, the method comprising: Send the user's own original location point to the server; Receive the push data packet returned by the server based on the original location point, and parse the scheduling suggestion information and capacity feedback information in the push data packet; Based on the capacity feedback information, the user-side map is updated, and the scheduling suggestion information is reminded.

[0014] Fourthly, embodiments of the present invention provide a capacity management device applied at the user end, the device comprising: The sending module is used to send the user's own original location point to the server. The parsing module is used to receive the push data packet returned by the server based on the original location point, and parse the scheduling suggestion information and capacity feedback information in the push data packet; The execution module is used to perform the update operation of the user-end map based on the capacity feedback information, and to perform the reminder operation of the scheduling suggestion information.

[0015] Fifthly, embodiments of the present invention provide a computer device, including: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the method described in the first aspect or any corresponding embodiment thereof.

[0016] In a sixth aspect, embodiments of the present invention provide a computer-readable storage medium storing computer instructions for causing a computer to perform the method described in the first aspect or any corresponding embodiment thereof.

[0017] The method provided in this application has the following beneficial effects: The method provided in this application embodiment achieves accurate and low-latency collection of real-time location information of drivers and passengers by receiving raw location points reported by user terminals within a preset range on the server side, laying the data foundation for the entire real-time response. Based on the raw location points, the method updates the raw capacity distribution information of the geographic grid within the preset range on the server map, obtaining an updated server map. This transforms discrete location point data into a structured, grid-based capacity heatmap, enabling the server to visualize the capacity density and distribution in different areas, achieving real-time perception and quantitative analysis of the overall capacity situation. Based on the updated server map, a capacity scheduling strategy is generated, allowing the server to intelligently identify areas of supply-demand imbalance based on the latest capacity distribution data and automatically generate strategies such as guiding drivers to move to demand hotspots or implementing dynamic pricing. This proactively and efficiently adjusts capacity supply, solving the core problem of uneven spatial and temporal distribution of capacity and achieving optimized allocation of capacity resources and dynamic supply-demand balance.

[0018] The method provided in this application actively participates in the information sharing process by sending its own original location to the server, providing necessary data input for the server to perform global capacity calculation and scheduling, thus forming the starting point of the closed-loop system. Next, it receives push data packets returned by the server based on the original location and parses the scheduling suggestions and capacity feedback information in the push data packets. This allows the user to obtain high-value information after intelligent processing from the server, enabling drivers to receive clear business guidance and both drivers and passengers to obtain feedback information such as the surrounding capacity situation, alleviating the problem of information asymmetry. Based on the capacity feedback information, it performs map updates on the user's end and executes reminders for scheduling suggestions, transforming abstract capacity data into an intuitive visual display on the map. This helps users quickly understand the surrounding environment, and proactive reminders ensure that key scheduling suggestions are received in a timely manner, directly guiding drivers' decisions and movements, improving user participation, experience, and overall scheduling efficiency. Attached Figure Description

[0019] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating a capacity management method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating another capacity management method according to an embodiment of the present invention; Figure 3 This is a flowchart illustrating another capacity management method according to an embodiment of the present invention; Figure 4 This is a schematic diagram of a geographic grid display of a capacity heatmap according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the interaction process of the capacity management method according to an embodiment of the present invention; Figure 6 This is a structural block diagram of a capacity management device according to an embodiment of the present invention; Figure 7 This is a structural block diagram of another capacity management device according to an embodiment of the present invention; Figure 8 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0022] According to embodiments of the present invention, a capacity management method, apparatus, and computer device are provided. It should be noted that the steps shown in the flowcharts in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0023] This embodiment provides a capacity management method applied to the server side. Figure 1 This is a flowchart of a capacity management method according to an embodiment of the present invention, such as... Figure 1 As shown, the process includes the following steps: Step S101: Receive the original location points reported by user terminals within a preset range.

[0024] In this embodiment, the server receives raw location points actively reported by all user terminals (including driver and passenger applications) within a preset range (e.g., a specific city, operating area, or designated geofence) in real time via a network interface (such as the accept module). The raw location points include at least latitude and longitude coordinates, a timestamp, user identifiers (such as driver ID or passenger ID), and device status metadata. To achieve efficient reception and initial processing, an asynchronous message processing mechanism is adopted: when a user terminal initiates a location reporting request via API, the accept module first calls the patrol network service to perform initial filtering based on the user identifier and functional status (such as the driver's "out" or "out" status), processing only user locations in a valid service state (e.g., the driver has "out") to exclude data interference from inactive devices. Next, the module verifies the location point's administrative code (adcode); if missing, it calls the asset module to complete it, ensuring the location data has complete regional attributes. Subsequently, the accept module encapsulates the original location data, along with complete metadata, into a message and pushes it to a message queue (MQ) for buffering and decoupling. Downstream consumer services then perform persistent storage (e.g., in Redis or Elasticsearch) and deep processing. This step, through a modular receiving chain and asynchronous message queue, ensures high-concurrency, low-latency access to massive amounts of location data, providing a real-time and reliable data foundation for the entire capacity management system.

[0025] Step S102: Update the original capacity distribution information of the geographic grid within the preset range in the server map according to the original location points to obtain the updated server map.

[0026] In this embodiment, a data cleaning process is first performed on the original location points, including at least filtering out invalid drifting points by verifying timestamps, functional status, and latitude and longitude ranges to obtain valid location points. Next, the latitude and longitude coordinates of each valid location point are extracted and converted to a specific resolution level using the H3 grid system's API to determine the target geographic grid to which each point is located. Then, the number of valid location points hitting each target geographic grid is counted, and density information representing the degree of capacity concentration is calculated based on this. Finally, this new density information is used to overwrite or update the original capacity distribution information field of the corresponding target geographic grid stored in the database. Once all relevant grid data within a preset range has been updated, a globally synchronized updated server map is generated, reflecting the latest spatial distribution of capacity based on the cellular grid at the current moment.

[0027] As an example, raw location points were received from hundreds of drivers in District T of City J. After filtering, 5 outdated locations due to clock errors, 3 drivers in the "retired" state, and 1 location with significantly abnormal latitude and longitude were excluded. The remaining valid location points were converted to the H3 L8 grid. Calculations showed that the number of hits within grid abc123 increased from 15 to 22. Based on this, their density information was calculated (e.g., the normalized value was updated from 60 to 88), and the capacity distribution information of that grid in the database was updated with this new value. Once all grids in the area have completed this update, an updated server map is generated that clearly shows where drivers are concentrated and sparse in Chaoyang District.

[0028] Step S103: Generate the corresponding capacity scheduling strategy based on the updated server map.

[0029] In this embodiment, the capacity distribution information and supply and demand data of each geographic grid stored in the updated server map are first read. By comparing with a preset supply and demand balance threshold, imbalanced geographic grids (including areas with excess capacity and areas with shortage capacity) that are significantly mismatched with passenger demand are identified. Next, the capacity distribution difference information between each imbalanced geographic grid and all its neighboring geographic grids is obtained, including key indicators such as capacity density difference and supply-demand ratio. Based on this difference information, the capacity scheduling relationship is determined, and the direction (e.g., from high-density grids to low-density grids) and priority of capacity scheduling are clarified. Finally, an operable capacity scheduling strategy is generated. This strategy includes specific scheduling suggestions, recommended routes, and possible incentive measures, providing a direct basis for subsequently pushing scheduling instructions to drivers.

[0030] As an example, in the updated server map, grid H3 abc123 (corresponding to a business district) was identified as an unbalanced geographical grid with a capacity density of 15, while the real-time demand intensity was as high as 85, indicating a supply-demand gap far exceeding the threshold. By obtaining information on the differences in capacity distribution between it and its neighboring grids, it was found that the capacity density of the adjacent grid abc124 to the east was 60, indicating a relatively balanced supply and demand. Based on this, the capacity scheduling relationship of "scheduling capacity from grid abc123 to grid abc124" was determined, and a specific capacity scheduling strategy was ultimately generated: "It is recommended that empty drivers in grid abc123 head west to the business district, increasing their order acceptance probability by 50% and earning a 5 yuan scheduling reward."

[0031] In this embodiment of the application, the target transportation capacity distribution information is obtained by updating the capacity distribution information of the geographic grid within a preset range in the server map based on the original location point, including: Step A1: Filter the original location points to obtain valid location points.

[0032] In this embodiment of the application, filtering the original location points to obtain valid location points includes: Step A101: Obtain the timestamp and functional status associated with the original location point.

[0033] Specifically, two key filtering attributes are extracted from the received raw location metadata: timestamp and functional status. The timestamp (usually in UTC format) is the precise time record when the location was collected or sent by the user's device. It is obtained directly by parsing specific fields in the location data packet and is used to subsequently determine the data's freshness and timeliness. The functional status is a marker representing the current operational activity of the user's device (specifically the driver's device). It is obtained by querying or associating the user identifier (such as driver ID) carried in the raw location with the driver's operational status at that specific time. This process can be accomplished by calling an internal status management service such as XunGai.com, which can return the driver's current status as "outgoing" (having clicked the outgoing button and preparing to accept orders), "retired" (having clicked the retired button and paused accepting orders), or "not outgoing device" (the app process is running but the driver is not outgoing). These two attributes—timestamp and functional status—form the core criteria for subsequent validity verification, eliminating invalid, drifting data and ensuring the accuracy of capacity statistics.

[0034] Step A102: Verify whether the timestamp and functional status corresponding to the original location point meet the preset filtering conditions, and obtain the verification result.

[0035] Specifically, the timestamp and functional status are logically compared with predefined filtering conditions, and the verification result is output (usually a Boolean value "compliant / True" or "incompatible / False"). The verification process is parallel and independent: for the timestamp, it is compared with the server's current time. Predefined filtering conditions include, but are not limited to, "the timestamp must not be earlier than the current time," to filter out outdated timestamps caused by device clock anomalies, network latency, or data retransmission. Simultaneously, for the location coordinates themselves, it is verified whether their latitude and longitude fall within a preset valid geographical range (e.g., 16-54 degrees North latitude, 70-140 degrees East longitude); those outside this range are also deemed invalid. For the functional status, the preset filtering conditions are directly related to business logic, with the core condition being "the driver must be in a driving state." Status information obtained by querying the patrol network service is used; if the status is "retired" or "not in a driving state," it is deemed incompatible. Finally, combining the verification results from both aspects, a unified verification result is generated: the verification result is compliant only when both the timestamp and functional status meet all preset filtering conditions; otherwise, it is incompatible.

[0036] Step A103: The original location points whose verification results do not meet the preset screening conditions are taken as invalid location points, and the invalid location points are removed from the original location points to obtain at least one valid location point.

[0037] Specifically, all original location points are traversed, and the verification result corresponding to each location point is checked. Any original location point whose verification result is marked as "does not meet the preset filtering conditions" is classified as an invalid location point. Invalid location points typically include expired points (timestamps exceeding 5 minutes) caused by network latency or device clock errors, points reported by drivers in non-operational states such as when they are at rest or not on duty, points with significantly abnormal latitude and longitude coordinates (such as single displacement exceeding 5 kilometers or coordinates outside the geographical range of China), and other invalid data identified through services such as the patrol and modification network. Invalid location points are physically removed from the current batch of data or logically marked as discarded, and are not included in subsequent capacity calculation processes. After filtering, all remaining original location points with valid verification results are retained and collectively referred to as valid location points. Valid location points will serve as the sole location data source for subsequent calculations of the H3 grid and capacity distribution, fundamentally ensuring the accuracy and business relevance of the capacity distribution information perceived by the system.

[0038] Step A2: Extract the latitude and longitude information contained in the valid location points, and determine at least one target geographic grid that the valid location points hit in the updated server map based on the latitude and longitude information.

[0039] Specifically, the core latitude and longitude information (i.e., the numerical pairs of latitude and longitude) is first extracted from the data structure of each valid location point. Then, a pre-integrated H3 grid system (specifically using Uber's open-source H3 API) is invoked, taking each set of latitude and longitude coordinates as input parameters. The core function, geoToH3, performs spatial calculations at a specific resolution used by the updated server map (e.g., L8 level, where the side length of a hexagonal grid is approximately 460 meters). The calculation process determines which specific hexagonal geographic grid the latitude and longitude coordinate point falls within and returns a unique H3 address (i.e., grid ID) corresponding to that grid as output. The geographic grid represented by the calculated H3 address (or those grids, which may involve multiple grids if the location point is on the boundary, but usually belong to one under the H3 standard) is marked as the target geographic grid to which the valid location point is located. Ultimately, all valid location points were successfully mapped to their corresponding target geographic grid sets, thus organizing discrete point-like location data into spatial structure data based on regular cellular grids, laying a solid foundation for grid-based capacity density statistics and visualization rendering.

[0040] Step A3: Update the capacity distribution information of the target geographic grid in the server map to obtain the updated server map.

[0041] In this embodiment of the application, the capacity distribution information of the target geographic grid in the server map is updated to obtain an updated server map, including: Step A301: Obtain the number of hits for valid location points in the target geographic grid.

[0042] Specifically, the process first iterates through all mapping relationships, that is, the correspondence between each valid location point and its corresponding target geographic grid (identified by its unique H3 address). Then, using the H3 address of each target geographic grid as a key index, a count operation is performed on all valid location points falling within that grid. This count result is the hit count for that grid. During the counting process, real-time aggregation calculations can be used; for example, updating the counter corresponding to each H3 address in real time as data flows in; alternatively, batch queries and count aggregation operations can be performed based on location point data stored in Elasticsearch or Redis. Finally, a non-negative integer hit count value is output for each target geographic grid. This value represents the absolute number of active drivers within that grid unit, providing the core raw data input for the next step of transforming the abstract spatial distribution into measurable density information.

[0043] Step A302: Calculate the density information of the target geographic grid based on the number of hits, whereby the density information is used to characterize the degree of capacity concentration of the target geographic grid.

[0044] Specifically, a direct mapping method is used for calculation: Since the actual physical area of ​​each target geographic grid in the H3 grid system is basically equal (approximately 0.21 square kilometers) at the same resolution (e.g., L8 level), the capacity density per unit area of ​​each grid is highly positively correlated with the number of hits. The number of hits itself, or the value obtained after normalizing it to a preset numerical range (e.g., 0-100), is defined as the density information of that grid. The density information value quantitatively characterizes the degree of concentration of capacity within the target geographic grid; the higher the value, the more active the number of drivers in the grid area, and the more abundant the capacity supply. It is the direct data source corresponding to the "darker color" in the subsequent generated heat map, providing a core quantitative basis for the system to perceive the "hot zones" and "cold zones" of capacity distribution.

[0045] Step A303: Update the capacity distribution information of the target geographic grid in the server map according to the density information to obtain the updated server map.

[0046] Specifically, the process iterates through all target geographic grids containing the new calculation results, using their unique H3 address as the primary key, and locates the corresponding record in the database storing the server map data structure (such as Elasticsearch). Then, the new density information value directly overwrites the original fields in that record that characterize capacity distribution information (e.g., a numeric field named `driver_density`). This update operation not only changes the numerical values ​​of the data but also updates attributes related to map rendering (e.g., mapping density values ​​to specific color values ​​according to preset color mapping rules, such as higher density resulting in darker colors). Once the capacity distribution information for all target geographic grids has been refreshed, the server map data version maintained in memory and persistently stored is marked as the updated server map. The latest version of the map reflects the current spatial distribution of capacity based on the cellular grid, providing an immediate and reliable spatial situational basis for subsequent capacity scheduling strategies.

[0047] In this embodiment of the application, a capacity scheduling strategy is generated based on the updated server map, including: Step B1: Identify imbalanced geographic grids with abnormal capacity distribution based on the updated server map.

[0048] Specifically, the system iterates through all geographic grids on the map, comparing their density information (representing supply) with travel demand hotspot information (representing demand) obtained from other data channels (such as order systems) for each grid in real time. It calculates the supply-demand gap for each grid (i.e., the difference between capacity density and demand intensity) and compares this difference with a preset reasonable threshold range. When the supply-demand gap of a geographic grid consistently and significantly exceeds the threshold range (e.g., capacity density is far lower than demand intensity, representing a capacity vacuum; or capacity density is far higher than demand intensity, representing a capacity congestion area), it is identified as having abnormal capacity distribution and marked as an unbalanced geographic grid. Finally, a list of identified unbalanced geographic grids is output. These grids are the key target areas requiring capacity intervention, providing a clear processing target for analyzing their differences from surrounding areas.

[0049] Step B2: Obtain information on the difference in capacity distribution between the unbalanced geographic grid and its adjacent geographic grids.

[0050] Specifically, firstly, based on the spatial topology of the H3 grid system, all neighboring geographic grids (i.e., all hexagonal grids directly connected to the current grid at the same resolution level) are identified for each unbalanced geographic grid. Then, capacity distribution information for the unbalanced geographic grid and each of its neighboring geographic grids, along with supply and demand data obtained from Elasticsearch queries, are extracted from the updated server map. Based on this data, the differences between the unbalanced geographic grid and each of its neighboring geographic grids in key indicators are calculated, thus forming capacity distribution difference information. This information includes, but is not limited to: capacity density difference (i.e., the difference in the number of drivers per unit area), used to identify the gradient of capacity resources; and supply-demand ratio (i.e., the difference between the current capacity and the estimated demand within the grid), used to determine scheduling potential and urgency. Finally, capacity distribution difference information is generated for each unbalanced geographic grid, clearly depicting the relative position and degree of difference of the unbalanced grid in its surrounding local environment, providing data support for determining specific capacity scheduling directions and traffic volumes.

[0051] Step B3: Determine the capacity scheduling relationship between the unbalanced geographic grid and its adjacent geographic grids based on the capacity distribution difference information.

[0052] Specifically, the capacity distribution differences (including capacity density differences and supply-demand ratios) between the imbalanced geographic grid and each of its neighboring geographic grids are analyzed one by one. For imbalanced geographic grids identified as having capacity vacuums, neighboring geographic grids with significantly higher capacity density and more relaxed supply-demand conditions are selected from their capacity distribution difference information and identified as potential sources of capacity transfer. This establishes a capacity scheduling relationship for supplementing capacity from a neighboring grid to the imbalanced grid, and a preliminary estimate of the recommended scheduling capacity based on the difference value is made. Conversely, for imbalanced geographic grids with capacity accumulation, the opposite scheduling relationship is established. Finally, a structured set of capacity scheduling relationships is generated for each imbalanced geographic grid. This set indicates the scheduling flow (from which grid to which grid) and the relative urgency and potential of the scheduling, providing a direct logical basis for generating executable scheduling strategies in the next step.

[0053] Step B4: Generate a capacity scheduling strategy for the unbalanced geographical grid based on the capacity scheduling relationship.

[0054] Specifically, for each established capacity scheduling relationship (e.g., "replenishing capacity from grid A to the unbalanced grid B"), one or more structured capacity scheduling strategies are generated. These strategies are executable instructions directly addressed to drivers, and their content mainly includes: explicit scheduling suggestions, such as informing drivers in grid A via text message that "go to grid B, 1 km to the west, where demand is high"; specific navigation guidance, providing the optimal route from the driver's current location to the target grid; and potential incentives, such as automatically calculated and added dynamic pricing information like "additional subsidies for traveling to this area." All this information is encapsulated into strategy instructions, awaiting subsequent steps to be packaged into push data packets and sent to the relevant user terminals. This directly transforms the conclusions of spatial analysis (scheduling relationships) into business instructions driving capacity flow, completing a closed loop from situational awareness to intelligent scheduling.

[0055] In the embodiments of this application, such as Figure 2 As shown, the method also includes: Step S201: Based on the updated server map, generate corresponding scheduling suggestion information and capacity feedback information for each user terminal.

[0056] In this embodiment, the specific geographic grid (H3 address) where the user is currently located is first obtained based on the user's identifier. For the driver, the generated capacity scheduling strategy is queried. If the grid where the driver is located or a neighboring grid is identified as an unbalanced geographic grid, specific scheduling suggestion information is extracted and generated, such as "It is recommended that you drive west to the XX business district, where demand is currently high." At the same time, capacity feedback information is generated by integrating the density information of the surrounding grids to generate capacity heatmap data for rendering on the app map, as well as text information such as "the number of empty vehicles of a specified vehicle type" obtained by calling the leopard-location service. For the passenger, scheduling suggestions are usually not generated. Their capacity feedback information mainly includes text prompts about the number of empty vehicles in the vicinity and a visual overview of capacity distribution generated for them. Finally, a data object containing personalized scheduling suggestion information and capacity feedback information is generated for each user, waiting to be packaged and pushed.

[0057] Step S202: Encapsulate the scheduling suggestion information and capacity feedback information of each user terminal into a corresponding push data packet, and send the push data packet to the user terminal.

[0058] In this embodiment, the two types of information (typically structured data objects in JSON or Protocol Buffers format) are first serialized and encapsulated together with metadata such as the target user's device identifier (e.g., Client ID), message type, and timestamp, forming a push data packet with a specific communication protocol format. Subsequently, based on the device identifier, this push data packet is asynchronously and in real-time sent to the designated user terminal via a persistent connection (e.g., a WebSocket long connection) or using a high-performance push service (e.g., based on Leopard-PushService). This process ensures that drivers receive guidance instructions immediately, and both drivers and passengers can simultaneously see the latest capacity distribution, thus achieving symmetry of driver and passenger information and dynamic guidance of capacity at the technical level.

[0059] This embodiment provides a capacity management method applied to the user end. Figure 3 This is a flowchart of another capacity management method according to an embodiment of the present invention, such as... Figure 3 As shown, the process includes the following steps: Step S301: Send the user's own original location point to the server.

[0060] In this embodiment, the user terminal collects raw location data, including latitude and longitude coordinates, high-precision timestamps, device identifiers, and business status (such as the driver's "departure / return" status), according to a preset fixed time frequency (e.g., every 5 seconds during the driver's performance) or based on rules of significant location changes. Subsequently, the application sends this raw location data packet to the server by calling a pre-packaged network service interface (e.g., an HTTP / HTTPS API request initiated to the accept module). In weak network environments, the user terminal can also employ a local caching and retransmission mechanism: if transmission fails, the location point is temporarily stored locally and automatically retransmitted after network recovery. The reporting process is executed within the protocol framework of user-authorized location information collection, thus providing the server with a continuous, real-time, and legitimate stream of individual location data, forming the basis for global capacity perception and scheduling.

[0061] Step S302: Receive the push data packet returned by the server based on the original location point, and parse the scheduling suggestion information and capacity feedback information in the push data packet.

[0062] In this embodiment, the network monitoring module on the user end (such as the component in the SDK responsible for handling server pushes) receives push data packets delivered via long-connection channels (such as WebSocket) or push services. The data packets are server-side encapsulated data streams in binary or JSON format containing personalized content. Subsequently, the user end calls a built-in deserialization program (Parser) to decode the received data packets, parsing out the structured core content: dispatch suggestion information (e.g., text instructions for drivers, such as "suggest going to business district Y," with structured fields such as navigation path and incentive amount) and capacity feedback information (typically including a density data set based on H3 grids for rendering heatmaps, as well as text or numerical information such as the number of available vehicles in the surrounding area and supply and demand status). The parsing process ensures that the abstract business instructions and situational data encapsulated in the data packets are accurately transformed into internal objects that the user end application logic can understand and process, preparing data for visualization rendering on the map and prompting dispatch suggestions.

[0063] Step S303: Based on the capacity feedback information, perform the update operation of the user-end map and perform the reminder operation of the scheduling suggestion information.

[0064] In this embodiment, the user terminal first calls its map rendering engine (such as the integrated map SDK) to update the user terminal map based on the capacity feedback information (i.e., the parsed density data set based on H3 grids and information such as the number of empty vehicles in the surrounding area). The geographical grid display in the capacity heatmap is as follows: Figure 4 As shown, based on the density value of each geographic grid (H3 grid), a capacity heatmap within a preset range is redrawn according to a preset color gradient rule (e.g., the higher the density, the darker the color). Simultaneously, for the parsed dispatch suggestion information (such as text instructions and incentive information), the user terminal will execute a reminder operation: proactively pushing the suggestion to users (especially drivers) through non-modal methods such as notification channels or in-app pop-ups, ensuring that key dispatch instructions can be perceived promptly and clearly. These two operations work together to ultimately transform the abstract data issued by the server into intuitive map visualizations and clear action guidelines, completing a full closed loop from data reception and parsing to final user interaction, directly improving the user's contextual awareness and the system's dispatch efficiency.

[0065] As an example, Figure 5 A schematic diagram of the interaction flow of the capacity management method provided in the embodiments of this application is shown below. Figure 5As shown, the user sends its original location to the receiving module; the receiving module transmits this original location to the server, where the server verifies the associated information (such as timestamps, functional status, etc.) of the original location. If the verification is successful, the location is determined to be a valid location. Based on the server map and the updated capacity distribution information of the valid location, the server generates a capacity scheduling strategy (scheduling strategy generation logic); subsequently, the server generates push data containing scheduling suggestions and capacity feedback and transmits it to the push channel; finally, the push channel returns the push data packet to the receiving module, which then forwards it to the user, completing the capacity management interaction process.

[0066] This embodiment also provides a capacity management device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0067] This embodiment provides a capacity management device applied to the server side, such as... Figure 6 As shown, it includes: The receiving module 61 is used to receive raw location points reported by user terminals within a preset range; Processing module 62 is used to update the original capacity distribution information of the geographic grid within a preset range in the server map based on the original location points, so as to obtain the updated server map; The generation module 63 is used to generate the corresponding capacity scheduling strategy based on the updated server map.

[0068] In this embodiment of the application, the processing module 62 includes: The filtering submodule is used to filter the original location points to obtain valid location points; The extraction submodule is used to extract the latitude and longitude information contained in the valid location points, and to determine at least one target geographic grid that the valid location points hit in the updated server map based on the latitude and longitude information. The update submodule is used to update the capacity distribution information of the target geographic grid in the server map, and obtain the updated server map.

[0069] In this embodiment of the application, the filtering submodule is specifically used to obtain the timestamp and functional status associated with the original location point; verify whether the timestamp and functional status corresponding to the original location point meet the preset filtering conditions, and obtain the verification result; take the original location point whose verification result does not meet the preset filtering conditions as an invalid location point, and remove the invalid location point from the original location point to obtain at least one valid location point.

[0070] In this embodiment of the application, the update submodule is specifically used to obtain the number of hits of valid location points in the target geographic grid; calculate the density information of the target geographic grid based on the number of hits, wherein the density information is used to characterize the degree of capacity concentration of the target geographic grid; update the capacity distribution information of the target geographic grid in the server map according to the density information to obtain the updated server map.

[0071] In this embodiment of the application, the generation module 63 is specifically used to identify unbalanced geographical grids with abnormal capacity distribution based on the updated server map; obtain capacity distribution difference information between the unbalanced geographical grid and adjacent geographical grids; determine the capacity scheduling relationship between the unbalanced geographical grid and adjacent geographical grids based on the capacity distribution difference information; and generate a capacity scheduling strategy for the unbalanced geographical grid based on the capacity scheduling relationship.

[0072] In this embodiment of the application, the device further includes: a push module, used to generate corresponding scheduling suggestion information and capacity feedback information for each user terminal based on the updated server map; encapsulate the scheduling suggestion information and capacity feedback information of each user terminal into a corresponding push data packet, and send the push data packet to the user terminal.

[0073] This embodiment provides a capacity management device applied to the user end, such as... Figure 7 As shown, it includes: Sending module 71 is used to send the user's own original location point to the server. The parsing module 72 is used to receive the push data packet returned by the server based on the original location point, and parse the scheduling suggestion information and capacity feedback information in the push data packet; The execution module 73 is used to update the user-side map based on the capacity feedback information and to send reminders for scheduling suggestions.

[0074] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 8As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system).

[0075] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GPA), or any combination thereof.

[0076] The memory 20 stores instructions executable by at least one processor 10 to cause at least one processor 10 to perform the method shown in the above embodiments.

[0077] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device as shown by a landing page for an app. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, which can be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0078] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0079] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0080] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0081] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A capacity management method, applied to a server, characterized in that, The method includes: Receive raw location points reported by user terminals within a preset range; The original capacity distribution information of the geographic grid within the preset range in the server map is updated based on the original location point to obtain the updated server map; Based on the updated server map, a corresponding capacity scheduling strategy is generated.

2. The method according to claim 1, characterized in that, The step of updating the capacity distribution information of the geographic grid within the preset range in the server map based on the original location point to obtain the target capacity distribution information includes: The original location points are filtered to obtain valid location points; Extract the latitude and longitude information contained in the effective location point, and determine at least one target geographic grid that the effective location point hits in the update server map based on the latitude and longitude information; The capacity distribution information of the target geographic grid in the server map is updated to obtain the updated server map.

3. The method according to claim 2, characterized in that, The filtering process for the original location points to obtain valid location points includes: Obtain the timestamp and functional status associated with the original location point; Verify whether the timestamp and functional status corresponding to the original location point meet the preset filtering conditions, and obtain the verification result; The original location points whose verification results do not meet the preset filtering conditions are taken as invalid location points, and the invalid location points are removed from the original location points to obtain at least one valid location point.

4. The method according to claim 2, characterized in that, The step of updating the capacity distribution information of the target geographic grid in the server map to obtain the updated server map includes: Obtain the number of hits for the valid location points in the target geographic grid; The density information of the target geographic grid is calculated based on the number of hits, wherein the density information is used to characterize the degree of capacity concentration of the target geographic grid; The capacity distribution information of the target geographic grid in the server map is updated based on the density information to obtain the updated server map.

5. The method according to claim 1, characterized in that, The generation of the capacity scheduling strategy based on the updated server map includes: The updated server map identifies imbalanced geographic grids with abnormal capacity distribution. Obtain information on the difference in capacity distribution between the unbalanced geographic grid and its adjacent geographic grids; Based on the capacity distribution difference information, determine the capacity scheduling relationship between the unbalanced geographical grid and the adjacent geographical grid; Based on the capacity scheduling relationship, a capacity scheduling strategy is generated for the unbalanced geographical grid.

6. The method according to claim 1, characterized in that, The method further includes: Based on the updated server map, corresponding scheduling suggestion information and capacity feedback information are generated for each user terminal. The scheduling suggestion information and capacity feedback information of each user terminal are encapsulated into a corresponding push data packet, and the push data packet is sent to the user terminal.

7. A capacity management method, applied to the user end, characterized in that, The method includes: Send the user's own original location point to the server; Receive the push data packet returned by the server based on the original location point, and parse the scheduling suggestion information and capacity feedback information in the push data packet; Based on the capacity feedback information, the user-side map is updated, and the scheduling suggestion information is reminded.

8. A capacity management device, characterized in that, The device, applied to the server side, includes: The receiving module is used to receive raw location points reported by user terminals within a preset range; The processing module is used to update the original capacity distribution information of the geographic grid within the preset range in the server map according to the original location point, so as to obtain the updated server map; The generation module is used to generate a corresponding capacity scheduling strategy based on the updated server map.

9. A capacity management device, characterized in that, The device, applied to a user terminal, includes: The sending module is used to send the user's own original location point to the server. The parsing module is used to receive the push data packet returned by the server based on the original location point, and parse the scheduling suggestion information and capacity feedback information in the push data packet; The execution module is used to perform the update operation of the user-end map based on the capacity feedback information, and to perform the reminder operation of the scheduling suggestion information.

10. A computer device, characterized in that, include: A memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, the processor executing the computer instructions to perform the method of any one of claims 1 to 7.

Images