A trajectory compression storage method for a two-wheeled vehicle and related products

Abstract

This application discloses a method for compressing and storing the trajectory of a two-wheeled vehicle and related products. First, it continuously receives segmented riding messages periodically reported by the target two-wheeled vehicle and performs protocol parsing to obtain structured segmented riding data. After a riding end event or a timeout event is triggered, the trajectory points from all segmented riding data are integrated and sorted by collection time to obtain the original trajectory sequence. Trajectory filtering is then performed using mileage constraints, vector angle constraints, and start / end point retention constraints to generate a compressed trajectory point sequence. Then, the start and end times of the trip are extracted from the compressed trajectory point sequence. Finally, the compressed trajectory point sequence, vehicle identifier, riding trip identifier, and start and end times are associated and stored to obtain archived trip trajectory data, which is then synchronously stored on both TiDB and OSS storage media. This application can achieve efficient trajectory compression while balancing data compression rate and trajectory reconstruction accuracy.

Description

Technical Field

[0001] This application relates to the fields of intelligent transportation and vehicle networking technology, specifically to a method for compressing and storing the trajectory of a two-wheeled vehicle and related products. Background Technology

[0002] With the iterative popularization of IoT technology, intelligent two-wheeled electric vehicles, electric bicycles, shared electric bicycles and other intelligent travel devices have been connected to the vehicle network system on a large scale, and rely on the cloud platform to realize intelligent business functions such as vehicle status monitoring, user riding behavior analysis, and trajectory playback display.

[0003] Currently, most mainstream smart electric vehicles are equipped with a high-precision Global Positioning System (GPS) positioning module and a wireless communication module, which can collect core operating data such as vehicle latitude and longitude location information, riding speed, battery level, cumulative riding mileage, and collection timestamp in real time. Among them, latitude and longitude data can be used to calculate the driving point vector, providing data support for trajectory morphology analysis.

[0004] To ensure the continuity and accuracy of cycling routes, devices generally employ a high-frequency data collection and periodic reporting mechanism. This involves sampling route points in short cycles and periodically uploading multiple sets of sampled data to the IoT platform via wireless communication networks. For long-distance cycling scenarios, the high-frequency sampling and periodic reporting mode continuously generates massive amounts of raw route data, significantly increasing the pressure on cloud data storage, transmission, and processing.

[0005] Current trajectory compression processing methods mainly fall into four categories: geometric simplification, fixed-frequency sampling, distance threshold filtering, and velocity threshold filtering. However, these methods generally struggle to simultaneously achieve both high data compression rates and accurate trajectory reconstruction.

[0006] Therefore, how to achieve both data compression rate and trajectory restoration accuracy while performing trajectory compression processing is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0007] To address the aforementioned issues, this application provides a method for compressing and storing the trajectory of a two-wheeled vehicle, as well as related products, which can balance the trajectory data compression rate and trajectory restoration accuracy, thereby meeting the processing needs of massive amounts of cycling trajectory data.

[0008] The embodiments of this application disclose the following technical solutions: A method for compressed storage of the trajectory of a two-wheeled vehicle, the method comprising: The system periodically receives binary segmented riding messages reported by the target two-wheeled vehicle's terminal and performs protocol parsing on these messages to obtain structured segmented riding data. Each segmented riding message includes a protocol header and a message body. The message body stores vehicle identifiers, riding distance identifiers, satellite positioning sampling data, and real-time vehicle operating parameters. The segmented riding data is bound to the corresponding vehicle identifier and riding distance identifier. The segmented riding data includes multiple trajectory points within a single reporting cycle, with each trajectory point labeled with the collection time, cumulative mileage, and latitude and longitude. In response to the end of riding event or timeout failure to update event of the target two-wheeled vehicle, the trajectory points in all segmented riding data of the target two-wheeled vehicle in a single riding session are sorted and spliced ​​together according to the collection time to obtain the original trajectory sequence; Based on mileage constraints, vector angle constraints, and first and last point retention constraints, and combined with the cumulative mileage and latitude and longitude of each trajectory point in the original trajectory sequence, trajectory filtering is performed on the trajectory points in the original trajectory sequence to obtain a compressed trajectory point sequence. The acquisition time corresponding to the first trajectory point in the compressed trajectory point sequence is taken as the start time of the journey, and the acquisition time corresponding to the last trajectory point in the compressed trajectory point sequence is taken as the end time of the journey. The compressed trajectory point sequence, along with the corresponding vehicle identifier, cycling trip identifier, trip start time, and trip end time, are associated and stored to obtain archived trip trajectory data. The archived trip trajectory data is then stored in the TiDB distributed database and OSS.

[0009] In one possible implementation, the mileage constraint is as follows: if the cumulative mileage difference between the current trajectory point and the previous retained trajectory point is less than the mileage change threshold, then the current trajectory point is determined to be a redundant point and filtered, and when mileage filtering is triggered multiple times consecutively, one trajectory point in multiple filtering cycles is forcibly retained. The vector angle constraint is as follows: take three consecutive trajectory points in sequence, calculate the driving vectors of the two segments of the trajectory based on the latitude and longitude of each point, and if the angle between the two segments of the vectors is less than the angle deviation threshold, then the middle trajectory point is determined as a straight redundant point and filtered. The constraint for retaining the first and last points is: retain the starting and ending trajectory points in the compressed trajectory point sequence.

[0010] In one possible implementation, the track points are also labeled with riding speed and battery level; The method further includes: In response to a riding record retrieval request from a client of an electric two-wheeled vehicle, the query start time, query end time, and riding trip identifier are extracted from the riding record retrieval request. Based on the query start time and the query end time, the storage duration of the cycling record to be retrieved corresponding to the cycling record retrieval request is identified; Based on the query start time, query end time, riding trip identifier, and vehicle identifier of the electric two-wheeled vehicle, and in conjunction with the storage duration, the archived trip trajectory data corresponding to the riding record retrieval request is obtained from the corresponding storage medium, and the archived trip trajectory data is used as the target trajectory data. The target trajectory data is assembled and parsed to obtain cycling trip summary information; the cycling trip summary information includes the trip start address, trip end address, total trip distance, total trip time, average cycling speed and trip power consumption. The summarized cycling trip information is then pushed to the client for display.

[0011] In one possible implementation, the method further includes: In response to the client of the electric two-wheeled vehicle's request to replay the riding trajectory based on the summary riding trip information, the target trajectory data is sent to the client so that the client can use a smooth interpolation algorithm to perform interpolation and point filling operations on the target trajectory data in combination with the average riding speed to obtain the restored trajectory animation, and then display the restored trajectory animation.

[0012] In one possible implementation, the storage medium includes the OSS and the TiDB distributed database; The process involves retrieving archived journey trajectory data corresponding to the riding record retrieval request from the corresponding storage medium based on the query start time, query end time, riding trip identifier, and the vehicle identifier of the electric two-wheeled vehicle, combined with the storage duration, and using this archived journey trajectory data as the target trajectory data. If the storage duration is greater than or equal to the storage time threshold, then based on the query start time, query end time, riding trip identifier, and vehicle identifier of the electric two-wheeled vehicle, the archived trip trajectory data corresponding to the riding record acquisition request is obtained from the OSS; If the storage duration is less than the storage time threshold, then based on the query start time, query end time, riding trip identifier, and the vehicle identifier of the electric two-wheeled vehicle, the archived trip trajectory data corresponding to the riding record retrieval request is obtained from the TiDB distributed database.

[0013] In one possible implementation, the method further includes: Obtain the road conditions and vehicle type of the target two-wheeled vehicle; The mileage change threshold and the angle deviation threshold are adjusted based on the driving conditions and the vehicle model.

[0014] In one possible implementation, the method further includes: If the duration of the same riding session corresponding to the target two-wheeled vehicle exceeds the preset maximum riding time limit and no riding end event is received, it is determined that the target two-wheeled vehicle has a timeout failure event.

[0015] A trajectory compression and storage system for two-wheeled vehicles, the system comprising an Internet of Things (IoT) platform, a Vehicle Service Platform (TSP) platform, a TiDB distributed database, and an OSS system. The IoT platform is used to periodically receive binary segmented riding messages reported by the target two-wheeled vehicle, and to perform protocol parsing on the segmented riding messages to obtain structured segmented riding data. The segmented riding message includes a message protocol header and a message body. The message body stores the vehicle identifier, riding trip identifier, satellite positioning sampling data, and real-time vehicle operating parameters. The segmented riding data is bound to the corresponding vehicle identifier and riding trip identifier. The segmented riding data includes multiple trajectory points within a single reporting cycle, and each trajectory point is marked with the collection time, cumulative mileage, and latitude and longitude. The TSP platform, in response to the end of riding event or timeout failure to update event of the target two-wheeled vehicle, sorts and splices the trajectory points in all segmented riding data of the target two-wheeled vehicle in a single riding session according to the collection time to obtain the original trajectory sequence. The TSP platform is also used to perform trajectory filtering on the trajectory points in the original trajectory sequence based on mileage constraints, vector angle constraints, and first and last point retention constraints, combined with the cumulative driving mileage and latitude and longitude of each trajectory point in the original trajectory sequence, to obtain a compressed trajectory point sequence. The TSP platform is also used to take the acquisition time corresponding to the first trajectory point in the compressed trajectory point sequence as the start time of the journey and the acquisition time corresponding to the last trajectory point in the compressed trajectory point sequence as the end time of the journey. The TSP platform is also used to associate and store the compressed trajectory point sequence with the vehicle identifier, cycling trip identifier, trip start time and trip end time corresponding to the compressed trajectory point sequence to obtain archived trip trajectory data, and store the archived trip trajectory data in the TiDB distributed database and the OSS.

[0016] A trajectory compression and storage device for a two-wheeled vehicle includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the trajectory compression and storage method for a two-wheeled vehicle as described above.

[0017] A computer-readable storage medium storing instructions that, when executed on a terminal device, cause the terminal device to perform the two-wheeled vehicle trajectory compression storage method as described above.

[0018] Compared with the prior art, this application has the following advantages: This application provides a method for compressing and storing the trajectory of a two-wheeled vehicle and related products. Specifically, when executing the method for compressing and storing the trajectory of a two-wheeled vehicle provided in this application, the system first continuously receives binary segmented riding messages periodically uploaded by the two-wheeled vehicle. After protocol parsing, segmented riding data bound to the vehicle identifier and riding trip identifier are obtained. After detecting a riding end event or a session timeout without update event, all trajectory points of a single riding session are aggregated and sequentially spliced ​​according to the collection time to form an original trajectory sequence. Then, combining mileage constraints, vector angle constraints, and start and end point retention constraints, trajectory filtering is completed based on the cumulative mileage and latitude and longitude information of the trajectory points. Redundant trajectory points in the original trajectory sequence are jointly selected to generate a compressed trajectory point sequence, and the timestamps of the start and end points are extracted as the trip start and end times. Finally, the compressed trajectory point sequence is associated with the corresponding vehicle identifier, riding trip identifier, and trip start and end times and stored to form archived trip trajectory data, which is synchronously saved to a distributed hybrid transactional analytical database (Titanium Database, TiDB) and an object storage service (OSS). This application employs a triple constraint mechanism of mileage, vector angle, and retention of start and end points to achieve trajectory redundancy filtering. It precisely eliminates dense points where the vehicle is stationary at low speed and redundant points where it is traveling straight without steering, while strictly retaining key points at the start and end of the journey. Through this multi-dimensional and refined screening mechanism, a balance can be achieved between trajectory compression rate and trajectory restoration accuracy. Attached Figure Description

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

[0020] Figure 1 A schematic diagram illustrating an exemplary application scenario provided in this application embodiment; Figure 2 A flowchart illustrating a method for compressing and storing the trajectory of a two-wheeled vehicle, as provided in this application embodiment; Figure 3 A flowchart illustrating a method for acquiring cycling records provided in this application embodiment; Figure 4 This is a schematic diagram of the structure of a trajectory compression and storage system for a two-wheeled vehicle provided in an embodiment of this application. Detailed Implementation

[0021] To facilitate understanding of the technical solutions provided in the embodiments of this application, the background technology involved in the embodiments of this application will be described below.

[0022] With the rapid development of IoT technology, smart mobility devices (such as smart two-wheeled electric vehicles, electric bicycles, and shared electric bicycles) have been widely connected to Telematics Service Provider (TSP) platforms to achieve functions such as vehicle status monitoring, user behavior analysis, and riding trajectory playback. Smart electric vehicle brands, such as Yadea, generally deploy high-precision GPS modules and communication modules on their vehicles, enabling them to collect and upload key operational data in real time, including vehicle location information (latitude and longitude, used to calculate two-point vectors), speed, battery level, riding mileage, and collection timestamps.

[0023] In practical applications, to ensure trajectory continuity and positioning accuracy, vehicles typically sample data every 5 seconds and upload the data to the Internet of Things (IoT) platform every 15 seconds via wireless communication methods such as NB-IoT and 4G / 5G. For a long-distance ride lasting several hours, the amount of raw trajectory data generated is extremely large.

[0024] Trajectory simplification and compression processing methods mainly include four categories: geometric simplification, fixed-frequency sampling, distance threshold filtering, and velocity threshold filtering. Each of these methods has limitations and cannot simultaneously improve data compression rates while maintaining trajectory reconstruction accuracy.

[0025] To address this issue, this application provides a method and related products for compressing and storing the trajectory of two-wheeled vehicles. First, binary segmented riding messages uploaded by the target two-wheeled vehicle are continuously and periodically received. Through protocol parsing, segmented riding data bound to vehicle and riding trip identifiers are obtained. Each segmented riding data contains multiple sets of trajectory points with collection time, cumulative mileage, and latitude / longitude information for a single reporting cycle. When a riding end event or a timeout event is detected, all trajectory points from the same riding session are aggregated and sorted according to collection time to form an original trajectory sequence. Then, combining mileage constraints, vector angle constraints, and start / end point retention constraints, redundant points are filtered based on the cumulative mileage and latitude / longitude information of the trajectory points to generate a compressed trajectory point sequence. The collection time corresponding to the first and last points of the sequence is extracted as the start and end times of the trip. Subsequently, the compressed trajectory point sequence, vehicle identifier, riding trip identifier, and trip start / end times are associated and integrated into archived trip trajectory data, which is stored in parallel to the TiDB distributed database and OSS object storage service. This application can achieve efficient trajectory compression in scenarios involving massive amounts of riding trajectory data processing, while simultaneously considering data compression rate and trajectory restoration accuracy.

[0026] To facilitate understanding of the trajectory compression and storage method for two-wheeled vehicles provided in the embodiments of this application, the following is combined with... Figure 1 The example scenario is shown below. See also... Figure 1 This figure is a schematic diagram of an exemplary application scenario provided in the embodiments of this application.

[0027] This embodiment uses the application of this method to cloud data receiving and processing platforms including IoT platforms, TSP platforms, TiDB distributed databases, and OSS to fully illustrate the process of trajectory compression and storage for two-wheeled vehicles: First, the target two-wheeled vehicle periodically reports binary segmented riding messages to the IoT platform via the Message Queuing Telemetry Transport (MQTT) protocol. The IoT platform continuously receives these periodically pushed binary segmented riding messages from the target two-wheeled vehicle. After receiving the segmented riding messages, the IoT platform performs message protocol parsing and conversion to obtain structured segmented riding data, and then forwards the structured segmented riding data to the TSP platform via a Kafka message queue.

[0028] After receiving structured segmented riding data, the TSP platform uses `ride_id` as the unique identifier for each riding session. It continuously caches all segmented riding data within the same session in a RedisList structure, setting a maximum cache expiration time of 48 hours. It continuously collects the trajectory points reported in batches during the riding process. The TSP platform continuously monitors event signals. When it detects that the target two-wheeled vehicle reports a riding end event, or when the riding session duration exceeds 48 hours and no riding end event is received (i.e., a timeout event is confirmed), the TSP platform reads all trajectory points cached for this riding session from Redis. It then sorts and concatenates the trajectory points from all segmented riding data within the target two-wheeled vehicle's single riding session according to the collection time, generating a time-sequential original trajectory sequence.

[0029] Subsequently, the TSP platform performs trajectory simplification calculations. Based on mileage constraints, vector angle constraints, and first and last point retention constraints, and combined with the cumulative mileage and latitude / longitude information corresponding to each trajectory point in the original trajectory sequence, it performs redundant trajectory point filtering on the original trajectory sequence, resulting in a compressed trajectory point sequence with a reduced number of discrete points. During the trajectory filtering process, the platform can dynamically adjust the mileage change threshold and angle deviation threshold based on the vehicle's road conditions and vehicle type. Road conditions are categorized as urban and rural roads and mountain roads, and vehicle types include lightweight electric two-wheelers and high-powered electric two-wheeled motorcycles. For example, when the road conditions are mountain roads and the vehicle type is a high-powered electric two-wheeler, the thresholds for both types are appropriately increased to avoid the incorrect removal of valid points on curves. When the road conditions are urban and rural roads and the vehicle type is a lightweight electric two-wheeler, a smaller threshold is used to further improve compression efficiency.

[0030] After completing trajectory filtering, the TSP platform determines the acquisition time corresponding to the first trajectory point in the compressed trajectory point sequence as the trip start time and the acquisition time corresponding to the last trajectory point in the compressed trajectory point sequence as the trip end time. The TSP platform then associates and encapsulates the compressed trajectory point sequence with the corresponding vehicle identifier, riding trip identifier, trip start time, and trip end time to generate standardized archived trip trajectory data.

[0031] Finally, the TSP platform adopts a hot and cold tiered persistence scheme, which synchronously forwards archived ride trajectory data to the TiDB distributed database and OSS object storage service machine for storage. Recent hot riding trajectories rely on TiDB to achieve high-concurrency and fast query, while long-term historical riding trajectories rely on OSS to achieve low-cost, large-capacity, long-term archiving.

[0032] This fully demonstrates the entire operational logic of this application, including vehicle-side message reporting, cloud session caching, event-driven trajectory aggregation, multi-constraint adaptive trajectory compression, and cold / hot layered hybrid storage. It can solve the pain points of large data storage volume and high transmission bandwidth consumption caused by the continuous reporting of massive positioning trajectories of two-wheeled vehicles. While retaining the key features of the riding path, it reduces the number of trajectory points. At the same time, it relies on the TiDB and OSS hybrid storage architecture to balance query response speed and cloud storage cost, supporting various upper-layer business needs such as client riding record query and trajectory playback.

[0033] Those skilled in the art will understand that Figure 1 The schematic diagram shown is merely one example in which embodiments of this application can be implemented. The scope of application of the embodiments of this application is not limited by any aspect of this framework.

[0034] 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 this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0035] See Figure 2 This figure is a flowchart illustrating a method for compressing and storing the trajectory of a two-wheeled vehicle according to an embodiment of this application. This method is applied to a cloud-based data receiving and processing platform. The overall system architecture of the cloud-based data receiving and processing platform includes an IoT platform, a TSP platform, a TiDB distributed database, and OSS. The cloud-based data receiving and processing platform is built on a microservice architecture based on Java 21, Spring Boot, Kafka, TiDB, and Redis. It consumes vehicle-reported data through the kafka-clients component, uses jackson-databind for JSON parsing, employs the tidb-jdbc component for database connections, provides vector computation capabilities through commons-math3, and can optionally be configured with jts-core for geospatial calculations.

[0036] like Figure 2 As shown, the trajectory compression and storage method for this two-wheeled vehicle may include steps S201-S205: S201: The IoT platform periodically receives binary segmented riding messages reported by the target two-wheeled vehicle and performs protocol parsing on the segmented riding messages to obtain structured segmented riding data.

[0037] To reliably receive the continuous riding sampling data uploaded by the two-wheeled vehicle, the target two-wheeled vehicle uses the MQTT protocol to report binary segmented riding messages to the IoT platform. The IoT platform continuously receives the original data packets reported by the target two-wheeled vehicle from its own device. Based on this, the IoT platform performs standardized protocol parsing on the received binary segmented riding messages, converting the unstructured binary messages into recognizable and computable structured segmented riding data.

[0038] The segmented cycling message consists of a protocol header and a message body. The message body encapsulates core information such as vehicle identifier, cycling trip identifier, satellite positioning sampling data, and real-time vehicle operating parameters. The parsed segmented cycling data is uniquely bound to the vehicle identifier and cycling trip identifier, ensuring that individual cycling session data are isolated from each other and do not interfere with each other. Each segmented cycling data corresponds to multiple sets of trajectory points generated in a single reporting cycle of the vehicle. Each trajectory point is fully labeled with key information such as collection time, cumulative mileage, and latitude and longitude, providing a complete and standardized raw data foundation for subsequent trajectory sequence integration, redundant point filtering, and accurate trajectory compression.

[0039] S202: In response to the end of riding event or timeout failure to update event of the target two-wheeled vehicle, the TSP platform sorts and splices the trajectory points in all segmented riding data of the target two-wheeled vehicle in a single riding session according to the collection time to obtain the original trajectory sequence.

[0040] To integrate fragmented cycling locations in a timely manner and construct a complete and continuous cycling trajectory for subsequent compression calculations, the TSP platform continuously relies on Kafka consumers to listen to the `vehicle_telemetry` topic, receiving segmented cycling data uploaded by the target two-wheeled vehicles in real time and generating it through message parsing. The TSP platform creates a cycling record upon recognizing the start of a ride, using `ride_id` as the distinguishing identifier. Segmented cycling data generated within the same cycling session is continuously cached in a RedisList structure, with an expiration time set equal to the maximum cycling duration (e.g., 48 hours) for the cached data to prevent invalid session data from occupying cache resources for extended periods. When the platform detects that the target two-wheeled vehicle has triggered a ride end event or a timeout failure to update event, it will terminate the continuous data collection process for that ride session. Then, it will read the complete ride trajectory point sequence cached in this ride session from Redis, extract all trajectory points contained in all segmented ride data saved in the current single ride session of the target two-wheeled vehicle, sort and stitch them together in ascending order according to the collection time carried by each trajectory point, and generate a complete and continuous original trajectory sequence after time alignment. In this way, the fragmented point data reported intermittently by the vehicle in batches will be reorganized into a coherent travel trajectory, providing a complete time-series data source for trajectory filtering processing under multiple constraints.

[0041] S203: The TSP platform, based on mileage constraints, vector angle constraints, and first and last point retention constraints, combined with the cumulative mileage and latitude and longitude of each trajectory point in the original trajectory sequence, performs trajectory filtering on the trajectory points in the original trajectory sequence to obtain a compressed trajectory point sequence.

[0042] In order to significantly reduce the number of trajectory points while preserving the true cycling path shape and driving characteristics to the greatest extent, and to avoid the problems of one-sided compression and precision imbalance caused by traditional single filtering methods, the TSP platform of this application integrates mileage constraints, vector angle constraints and first and last point retention constraints to form a multi-dimensional joint filtering mechanism for the complete original trajectory sequence after splicing. It relies on the cumulative mileage and latitude and longitude coordinate information of each trajectory point to carry out refined redundancy screening.

[0043] Specifically, the platform compares the mileage difference between adjacent trajectory points using mileage constraints to filter out dense, redundant points with minimal mileage changes and no driving significance during low-speed coasting, stationary waiting, or other conditions. Simultaneously, it introduces vector angle constraints to construct driving vectors for three consecutive trajectory points and calculate the angle between them, identifying and removing duplicate sampling points with no directional deviation and completely identical path shapes in straight sections. Furthermore, it enforces the retention of the first and last trajectory points of a single ride through start-end point retention constraints, preventing the loss of crucial information at the travel boundaries. Through this triple-constraint collaborative filtering, effective feature points and redundant sampling points can be accurately distinguished from each other across three dimensions: driving displacement, path direction, and travel boundaries. This enables intelligent simplification of the original trajectory sequence, ultimately resulting in a compressed trajectory point sequence with both high compression ratio and high fidelity.

[0044] S204: The TSP platform uses the acquisition time corresponding to the first trajectory point in the compressed trajectory point sequence as the start time of the journey, and uses the acquisition time corresponding to the last trajectory point in the compressed trajectory point sequence as the end time of the journey.

[0045] To accurately define the time boundaries of a single ride and support subsequent ride duration statistics, trip retrieval, and trajectory playback, after filtering the original trajectory sequence through multiple constraints to obtain a time-ordered compressed trajectory point sequence, the TSP platform, relying on the inherent temporal order of the compressed trajectory point sequence, selects the collection time corresponding to the first trajectory point in the sequence as the start time of the ride and the collection time corresponding to the last trajectory point as the end time. Since the compression process already ensures that the start and end points of the ride are not mistakenly removed through the first and last point retention constraint, the start and end times extracted from the first and last points of the compressed trajectory sequence can fully reflect the actual time range of the ride. This eliminates the need for additional retrieval of massive amounts of original trajectory data for secondary comparison, reducing data query and computation overhead while ensuring the accuracy and effectiveness of the ride time information. It also facilitates the subsequent unified packaging and archiving of start and end times, trajectory points, vehicle identification, and other information.

[0046] S205: The TSP platform associates and stores the compressed trajectory point sequence with the vehicle identifier, cycling trip identifier, trip start time and trip end time corresponding to the compressed trajectory point sequence to obtain archived trip trajectory data, and stores the archived trip trajectory data in the TiDB distributed database and OSS.

[0047] To unify the management of complete single-ride trip information and support diverse business calls such as subsequent ride queries, route playback, and riding behavior statistics, the TSP platform, after determining the compressed trajectory point sequence, trip start time, and trip end time, integrates the compressed trajectory point sequence with the corresponding vehicle identifier, ride trip identifier, trip start time, and trip end time to generate standardized archived ride trajectory data. The platform employs a layered hybrid storage scheme to persistently store the archived ride trajectory data. On one hand, the data is stored in the TiDB distributed hybrid transactional analytical database, which combines transaction processing and real-time analysis capabilities. Leveraging its distributed scalability, it ensures low-latency, high-concurrency queries for recently popular riding routes.

[0048] On the other hand, the archived ride trajectory data is simultaneously stored in OSS object storage service. Relying on the advantages of object storage in terms of large capacity and low cost, massive historical riding trajectories are preserved for a long time. This takes into account both the performance of online business access and the long-term archiving needs of massive time-series trajectories, forming a data persistence solution that balances performance and storage cost, and completing the full lifecycle storage processing of a single riding trajectory.

[0049] Based on the content of S201-S205, the system first periodically receives binary segmented riding messages uploaded by the target two-wheeled vehicle. After protocol parsing, segmented riding data is obtained, and data association is completed based on vehicle identifiers and riding trip identifiers. When a riding end event or a timeout failure to update event is detected, all trajectory points within a single riding session are integrated and sorted according to the collection time to construct an original trajectory sequence. Then, combining the cumulative mileage and latitude / longitude information of the trajectory points, the original trajectory sequence is collaboratively filtered using mileage constraints, vector angle constraints, and start / end point retention constraints to obtain a compressed trajectory point sequence. The start and end collection times of the trajectory sequence are then extracted as the trip start and end times. Finally, the compressed trajectory point sequence, along with the corresponding vehicle identifier, riding trip identifier, trip start time, and trip end time, are associated and stored to obtain archived trip trajectory data, which is then synchronously and persistently stored in the TiDB distributed database and OSS. This application can achieve efficient trajectory compression in scenarios involving massive amounts of riding trajectory data processing, while simultaneously balancing data compression rate and trajectory reconstruction accuracy.

[0050] In one possible implementation, the mileage constraint is as follows: if the cumulative mileage difference between the current trajectory point and the previous retained trajectory point is less than the mileage change threshold (e.g., 10m), then the current trajectory point is determined to be a redundant point and filtered, and when mileage filtering is triggered multiple times (e.g., 10 times), one trajectory point in multiple filtering cycles is forcibly retained. The vector angle constraint is as follows: take three consecutive trajectory points in sequence, calculate the driving vectors of the two segments of the trajectory based on the latitude and longitude of each point, and if the angle between the two segments of the vectors is less than the angle deviation threshold (e.g., 15°), then the middle trajectory point is determined to be a straight redundant point and filtered out. The constraint for retaining the first and last points is: retain the starting and ending trajectory points in the compressed trajectory point sequence.

[0051] Specifically, to achieve refined identification of redundant points and to balance compression effects in both low-speed stationary scenarios and long-distance straight-line scenarios, the platform is configured with three types of constraints to collaboratively complete trajectory point selection: Mileage constraints are used to handle densely sampled points generated when the vehicle is stationary or moving at low speeds: the cumulative mileage of the current trajectory point is compared with that of the previous retained trajectory point. When the difference in mileage is less than a preset mileage change threshold (e.g., 10m), the current trajectory point is determined to be a redundant point and is filtered out. A continuous filtering protection mechanism is also added. If the mileage filtering condition is met multiple times (e.g., 10 times), one of the trajectory points is forcibly retained to prevent the loss of travel feature information due to the complete deletion of trajectory points during long periods of inactivity.

[0052] Vector angle constraints are used to identify invalid sampling points in straight road segments. The program extracts three consecutive trajectory points from the original trajectory sequence in sequence, and constructs two adjacent driving vectors by combining the latitude and longitude information of each point. The angle between the vectors is calculated. If the angle is less than the preset angle deviation threshold, it means that the vehicle is in a straight state. The middle trajectory point is determined to be a redundant straight point and is removed.

[0053] The first and last point retention constraint is used as a fallback rule. Regardless of the results of other constraint judgments, the first starting point and the last point of the entire trajectory sequence are forcibly retained to ensure that the boundary information of the cycling journey is not lost due to compression and to ensure that the start and end intervals of the final trajectory are accurate and complete.

[0054] In one possible implementation, the track points are also labeled with riding speed and battery level.

[0055] See Figure 3 , Figure 3 A flowchart of a cycling record acquisition method provided in this application embodiment can be implemented through steps S301-S305: S301: The TSP platform responds to the riding record retrieval request from the client of the electric two-wheeled vehicle by extracting the query start time, query end time, and riding trip identifier from the riding record retrieval request.

[0056] To accurately identify client query requests and achieve precise retrieval of subsequent trajectory data, when the TSP platform receives a request from an electric two-wheeled vehicle client to retrieve riding records, it first parses and processes the request message, extracting core query parameters such as the query start time, query end time, and riding trip identifier. The query start time and query end time define the time range of the user's desired trip, used to determine the storage medium of the target trajectory data; the unique riding trip identifier accurately locates the archived trip trajectory data corresponding to a single riding session, serving as the core index for data retrieval.

[0057] The TSP platform extracts the above key conditions to standardize and decompose query requirements, providing a reliable retrieval basis for subsequent identification of storage duration based on time span and targeted reading of corresponding archived trajectory data. This avoids large-scale full scanning of storage resources, effectively reduces database query overhead, and improves the efficiency of cycling record retrieval.

[0058] S302: The TSP platform identifies the storage duration of the cycling record to be retrieved corresponding to the cycling record retrieval request based on the query start time and the query end time.

[0059] To differentiate between hotspot trajectory data and historical archived trajectory data, and to dynamically distribute query requests to different storage media, the TSP platform combines the parsed query start and end times to calculate the time interval corresponding to the queried cycling trip, and uses this to identify the storage duration of the cycling record to be retrieved for the request. This storage duration represents the time span from the generation of the archived trip trajectory data to the current query time.

[0060] By pre-identifying the storage duration to determine whether data is hot or cold, it is possible to avoid all query requests accessing the same type of storage resource. This ensures the response speed for recent cycling record queries while fully leveraging the advantages of low cost and large capacity of object storage, thus balancing platform query performance with overall storage overhead.

[0061] S303: Based on the query start time, query end time, riding trip identifier, and vehicle identifier of the electric two-wheeled vehicle, the TSP platform retrieves the archived trip trajectory data corresponding to the riding record retrieval request from the corresponding storage medium in conjunction with the storage duration, and uses the archived trip trajectory data as the target trajectory data.

[0062] To achieve targeted retrieval of trajectory data based on a hierarchical storage architecture, balancing query response speed and storage resource costs, the TSP platform combines extracted query start time, query end time, riding trip identifier, and electric two-wheeler vehicle identifier to form multi-dimensional search conditions. It then uses the storage duration identified in the previous step to determine the storage medium of the target data. If the data is determined to be recent hot data, it accesses the TiDB distributed hybrid transactional analytical database for retrieval; if it is determined to be long-term historical cold data, it switches to OSS object storage service for reading.

[0063] The platform uses multi-condition joint indexes to accurately match the corresponding archived trip trajectory data, avoiding the query delay caused by large-scale full scans. After successfully reading the complete archived information of the target trip, the archived trip trajectory data is defined as the target trajectory data, providing the original data foundation for subsequent trip information parsing, statistical assembly, and completing the core query step of directionally pulling cycling trajectory data from the storage medium.

[0064] In one possible implementation, the storage medium includes the OSS and the TiDB distributed database.

[0065] In one possible implementation, the step of retrieving archived trip trajectory data corresponding to the riding record retrieval request from the corresponding storage medium based on the query start time, query end time, riding trip identifier, and vehicle identifier of the electric two-wheeled vehicle, combined with the storage duration, and using this archived trip trajectory data as the target trajectory data includes: If the storage duration is greater than or equal to the storage time threshold (e.g., 3 months), then based on the query start time, query end time, riding trip identifier, and the vehicle identifier of the electric two-wheeled vehicle, the archived trip trajectory data corresponding to the riding record acquisition request is obtained from the OSS. If the storage duration is less than the storage time threshold, then based on the query start time, query end time, riding trip identifier, and the vehicle identifier of the electric two-wheeled vehicle, the archived trip trajectory data corresponding to the riding record retrieval request is obtained from the TiDB distributed database.

[0066] Specifically, when the storage time of any archived trip trajectory data in the TiDB distributed database is greater than or equal to the storage time threshold, the TiDB distributed database deletes the archived trip trajectory data.

[0067] S304: The TSP platform assembles and parses the travel information of the target trajectory data to obtain summary information of the cycling trip.

[0068] To avoid directly transmitting massive amounts of raw track points to clients, reduce interface bandwidth pressure, and provide users with intuitive and easy-to-understand cycling statistics, the TSP platform retrieves the target track data and performs trip information assembly and parsing. The TSP platform performs reverse geocoding based on the latitude and longitude of the track's start and end points to obtain the trip's start and end addresses. It then calculates the total distance traveled based on the cumulative mileage carried by the track points, calculates the total trip time based on the track's start and end collection times, and calculates the average cycling speed based on the total mileage and time. Simultaneously, it combines vehicle operating parameters to calculate the corresponding power consumption for this ride. The platform integrates and encapsulates all the above information to generate standardized cycling trip summary information.

[0069] The cycling trip summary information includes the trip start address, trip end address, total trip distance, total trip time, average cycling speed, and trip power consumption.

[0070] S305: The TSP platform will push the summarized cycling trip information to the client for display.

[0071] To complete the closed-loop process of cycling query services and deliver lightweight, easy-to-render cycling result data to the requesting client, the TSP platform, after parsing the target trajectory data and generating cycling trip summary information, encapsulates the cycling trip summary information, including start and end addresses, mileage, duration, average speed, and power consumption, into a standard response message and pushes it to the client corresponding to the electric two-wheeled vehicle.

[0072] Compared to directly sending the complete sequence of trajectory points, transmitting only the summarized statistical information can significantly reduce the amount of data transmitted through the interface, reducing network transmission time and the pressure on the client's local rendering. Furthermore, after receiving the summarized information, the client can directly render and display various cycling metrics without performing complex data calculations and parsing operations locally. This optimizes the loading experience for users querying cycling records, ultimately realizing a complete business chain from user-initiated query requests, backend retrieval of trajectory data, calculation of statistical information, to frontend visualization.

[0073] Steps S301-S305 enable a standardized processing flow for client-side cycling record query requests. The TSP platform first extracts key query conditions such as time intervals and trip identifiers from the query request sent from the front end. Based on the start and end times of the query, it identifies the storage duration corresponding to the cycling record to be queried, and adaptively selects either the TiDB distributed database or OSS object storage as the target reading medium. Combining vehicle identifiers and cycling trip identifiers, it accurately retrieves the corresponding archived trip trajectory data. The platform does not need to directly transmit complete original trajectory points to the client. Instead, it performs secondary parsing and information assembly on the target trajectory data, calculating and generating summary cycling trip information including start and end addresses, total mileage, cycling duration, average speed, and trip power consumption. Finally, the structured summary data is pushed to the client for display. The entire query process is adapted to the application's cold and hot tiered hybrid storage architecture, which can intelligently select the storage medium to read data based on the query time span, reducing bandwidth consumption caused by the transmission of massive trajectory points. At the same time, it outputs intuitive and readable trip statistics information to users, balancing query response efficiency and front-end display experience, forming a complete business closed loop of trajectory storage, query parsing, and front-end display.

[0074] In one possible implementation, to balance the data transmission efficiency for daily itinerary queries with the smoothness requirements of trajectory playback scenarios, this application adds an additional trajectory playback processing flow: In response to a request from the client of the electric two-wheeled vehicle to replay the riding trajectory based on the summary riding information, the TSP platform sends the target trajectory data to the client. The client then uses a smooth interpolation algorithm (e.g., linear interpolation or Bézier curve) to perform interpolation and point filling operations on the target trajectory data based on the average riding speed to obtain a restored trajectory animation, which is then displayed.

[0075] Specifically, when the TSP platform receives a request from an electric two-wheeled vehicle client to replay its riding trajectory based on a summary of riding trip information, the TSP platform no longer simply pushes lightweight statistical data, but instead sends the complete target trajectory data to the client. Because the number of target trajectory points is reduced after filtering by multiple constraints, direct rendering can easily result in abrupt trajectory lines and choppy, disjointed animations. After obtaining the target trajectory data, the client, combined with the average riding speed corresponding to the trip, uses linear interpolation or smooth interpolation algorithms such as Bézier curves to perform interpolation point supplementation calculations. This adds transition coordinate points between discrete compressed trajectory points, generating a more continuous restored trajectory animation, which is ultimately displayed on the client's page.

[0076] This approach enables differentiated data distribution for different business scenarios. For ordinary queries, only summary information is pushed to save bandwidth. In trajectory playback scenarios, the original trajectory points are sent, and the client-side interpolation algorithm compensates for the missing points caused by trajectory compression. This ensures a smooth and natural visual effect for trajectory playback without significantly increasing the platform's storage and transmission pressure.

[0077] In one possible implementation, to enable trajectory filtering rules to adapt to different driving scenarios, improve the rationality of trajectory compression under different working conditions, and avoid the loss of critical path information caused by fixed thresholds in complex road conditions, the method further includes: The TSP platform acquires the road conditions and vehicle type of the target two-wheeled vehicle. Then, based on the road conditions and vehicle type, it adjusts the mileage change threshold and the angle deviation threshold.

[0078] Specifically, the TSP platform first obtains the road conditions and vehicle type corresponding to the target two-wheeled vehicle. The road conditions are divided into types such as urban and rural roads and mountain roads, and the vehicle types include lightweight electric two-wheeled vehicles and high-powered electric two-wheeled motorcycles. Then, the TSP platform matches the corresponding parameter strategy according to the combination of road conditions and vehicle type. For example, if the road condition is a mountain road and the vehicle type is a high-powered electric two-wheeled motorcycle, the mileage change threshold and angle deviation threshold are appropriately increased to adapt to the driving characteristics of frequent turns and large speed fluctuations on mountain roads, and to reduce the false filtering of effective turning points. If the road condition is an urban and rural road and the vehicle type is a lightweight electric two-wheeled vehicle, a smaller mileage change threshold and angle deviation threshold are selected to improve the simplification of points while ensuring the integrity of the riding trajectory outline.

[0079] The TSP platform dynamically adjusts the mileage change threshold corresponding to the mileage constraint and the angle deviation threshold corresponding to the vector angle constraint based on the matching results. This enables the trajectory compression strategy to adapt to various travel scenarios, allowing the compressed trajectory to effectively reduce the number of points while accurately preserving the key steering and shifting features during different road conditions and vehicle types, thus balancing compression efficiency and trajectory restoration accuracy.

[0080] In one possible implementation, to properly handle scenarios such as vehicle offline disconnection and abnormal client disconnection, avoid long-term Redis cache dwell of cycling sessions consuming system resources, and ensure that fragmented trajectory data can be properly aggregated and archived, the method further includes: When the TSP platform detects that the duration of the same riding session corresponding to the target two-wheeled vehicle exceeds the preset maximum riding time limit (e.g., 48 hours) and no riding end event is received, it determines that the target two-wheeled vehicle has a timeout failure event.

[0081] Specifically, the TSP platform continuously monitors the duration of a single riding session of the target two-wheeled vehicle. If the duration of the same riding session exceeds the preset maximum riding time limit (e.g., 48 hours) and no riding end event is reported by the vehicle throughout the session, it is determined that the vehicle has experienced an abnormal situation such as loss of connection or signal interruption, and the target two-wheeled vehicle is automatically identified as having triggered a timeout failure to update event. After this event is triggered, the platform can stop receiving the location data corresponding to the ride_id and actively read all the trajectory points of this ride cached in Redis to perform the splicing, trajectory compression, and archiving storage process. This prevents the riding trajectory data from remaining in the cache for a long time without generating a formal archive record due to the vehicle's inability to report the end command normally. While taking into account the normal riding process, it realizes a fallback closed-loop processing for abnormal riding sessions, ensuring that the trajectory data is completely stored.

[0082] See Figure 4 , Figure 4 This is a schematic diagram of the structure of a trajectory compression and storage system for a two-wheeled vehicle provided in an embodiment of this application. Figure 4 As shown, the trajectory compression and storage system for this two-wheeled vehicle includes: an IoT platform, a TSP platform, a TiDB distributed database, and OSS. The IoT platform is used to periodically receive binary segmented riding messages reported by the target two-wheeled vehicle, and to perform protocol parsing on the segmented riding messages to obtain structured segmented riding data. The segmented riding message includes a message protocol header and a message body. The message body stores the vehicle identifier, riding trip identifier, satellite positioning sampling data, and real-time vehicle operating parameters. The segmented riding data is bound to the corresponding vehicle identifier and riding trip identifier. The segmented riding data includes multiple trajectory points within a single reporting cycle, and each trajectory point is marked with the collection time, cumulative mileage, and latitude and longitude. The TSP platform, in response to the end of riding event or timeout failure to update event of the target two-wheeled vehicle, sorts and splices the trajectory points in all segmented riding data of the target two-wheeled vehicle in a single riding session according to the collection time to obtain the original trajectory sequence. The TSP platform is also used to perform trajectory filtering on the trajectory points in the original trajectory sequence based on mileage constraints, vector angle constraints, and first and last point retention constraints, combined with the cumulative driving mileage and latitude and longitude of each trajectory point in the original trajectory sequence, to obtain a compressed trajectory point sequence. The TSP platform is also used to take the acquisition time corresponding to the first trajectory point in the compressed trajectory point sequence as the start time of the journey and the acquisition time corresponding to the last trajectory point in the compressed trajectory point sequence as the end time of the journey. The TSP platform is also used to associate and store the compressed trajectory point sequence with the vehicle identifier, cycling trip identifier, trip start time and trip end time corresponding to the compressed trajectory point sequence to obtain archived trip trajectory data, and store the archived trip trajectory data in the TiDB distributed database and the OSS.

[0083] In one possible implementation, the mileage constraint is as follows: if the cumulative mileage difference between the current trajectory point and the previous retained trajectory point is less than the mileage change threshold, then the current trajectory point is determined to be a redundant point and filtered, and when mileage filtering is triggered multiple times consecutively, one trajectory point in multiple filtering cycles is forcibly retained. The vector angle constraint is as follows: take three consecutive trajectory points in sequence, calculate the driving vectors of the two segments of the trajectory based on the latitude and longitude of each point, and if the angle between the two segments of the vectors is less than the angle deviation threshold, then the middle trajectory point is determined as a straight redundant point and filtered. The constraint for retaining the first and last points is: retain the starting and ending trajectory points in the compressed trajectory point sequence.

[0084] In one possible implementation, the track points are also labeled with riding speed and battery level.

[0085] In one possible implementation, the TSP platform is also used for: In response to a riding record retrieval request from a client of an electric two-wheeled vehicle, the query start time, query end time, and riding trip identifier are extracted from the riding record retrieval request. Based on the query start time and the query end time, the storage duration of the cycling record to be retrieved corresponding to the cycling record retrieval request is identified; Based on the query start time, query end time, riding trip identifier, and vehicle identifier of the electric two-wheeled vehicle, and in conjunction with the storage duration, the archived trip trajectory data corresponding to the riding record retrieval request is obtained from the corresponding storage medium, and the archived trip trajectory data is used as the target trajectory data. The target trajectory data is assembled and parsed to obtain cycling trip summary information; the cycling trip summary information includes the trip start address, trip end address, total trip distance, total trip time, average cycling speed and trip power consumption. The summarized cycling trip information is then pushed to the client for display.

[0086] In one possible implementation, the TSP platform is also used for: In response to the client of the electric two-wheeled vehicle's request to replay the riding trajectory based on the summary riding trip information, the target trajectory data is sent to the client so that the client can use a smooth interpolation algorithm to perform interpolation and point filling operations on the target trajectory data in combination with the average riding speed to obtain the restored trajectory animation, and then display the restored trajectory animation.

[0087] In one possible implementation, the storage medium includes the OSS and the TiDB distributed database.

[0088] In one possible implementation, the step of retrieving archived trip trajectory data corresponding to the riding record retrieval request from the corresponding storage medium based on the query start time, query end time, riding trip identifier, and vehicle identifier of the electric two-wheeled vehicle, combined with the storage duration, and using this archived trip trajectory data as the target trajectory data includes: If the storage duration is greater than or equal to the storage time threshold, then based on the query start time, query end time, riding trip identifier, and vehicle identifier of the electric two-wheeled vehicle, the archived trip trajectory data corresponding to the riding record acquisition request is obtained from the OSS; If the storage duration is less than the storage time threshold, then based on the query start time, query end time, riding trip identifier, and the vehicle identifier of the electric two-wheeled vehicle, the archived trip trajectory data corresponding to the riding record retrieval request is obtained from the TiDB distributed database.

[0089] Obtain the road conditions and vehicle type of the target two-wheeled vehicle; The mileage change threshold and the angle deviation threshold are adjusted based on the driving conditions and the vehicle model.

[0090] In one possible implementation, the TSP platform is also used for: If the duration of the same riding session corresponding to the target two-wheeled vehicle exceeds the preset maximum riding time limit and no riding end event is received, it is determined that the target two-wheeled vehicle has a timeout failure event.

[0091] In addition, this application embodiment also provides a trajectory compression storage device for a two-wheeled vehicle, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the trajectory compression storage method for a two-wheeled vehicle as described above.

[0092] In addition, this application embodiment also provides a computer-readable storage medium storing instructions that, when executed on a terminal device, cause the terminal device to perform the two-wheeled vehicle trajectory compression storage method as described above.

[0093] This application employs a joint screening mechanism combining mileage constraints, vector angle constraints, and start / end point retention constraints to filter redundant points in the original trajectory sequence. Mileage constraints filter out densely packed sampling points with small displacement fluctuations under low-speed, stationary conditions based on the mileage change characteristics of trajectory points. Vector angle constraints identify redundant points within straight sections without route turns using the travel vectors formed by continuous points. Start / end point retention constraints ensure that the start and end points of a single ride are not mistakenly deleted. By collaboratively determining redundant points based on multi-dimensional conditions, refined sampling point reduction can be achieved, avoiding the selection bias caused by a single discrimination rule. This improves the trajectory data compression effect while preserving key morphological information of the riding path, achieving an effective balance between trajectory compression rate and trajectory reconstruction accuracy. Meanwhile, this application receives segmented riding messages periodically reported by the vehicle and parses and caches them in real time. After the riding end event or the timeout failure to update event is triggered, the trajectory splicing and compression processing is completed in a unified manner, and the generated archived trip trajectory data is synchronously stored in the TiDB distributed database and OSS object storage. On the basis of realizing lightweight storage of massive riding trajectories, it also takes into account the needs of fast query of hot data and low-cost archiving and storage of historical cold data, and is suitable for vehicle networking business scenarios with high frequency of reporting and large data volume of two-wheeled vehicles.

[0094] The foregoing has provided a detailed description of a two-wheeled vehicle trajectory compression and storage method and related products provided in this application. The various embodiments in the specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

[0095] It should be understood that, in this application, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A method for compressing and storing the trajectory of a two-wheeled vehicle, characterized in that, The method includes: The system periodically receives binary segmented riding messages reported by the target two-wheeled vehicle's terminal and performs protocol parsing on these messages to obtain structured segmented riding data. Each segmented riding message includes a protocol header and a message body. The message body stores vehicle identifier, riding distance identifier, satellite positioning sampling data, and real-time vehicle operating parameters. The segmented riding data is bound to the corresponding vehicle identifier and riding distance identifier. The segmented riding data includes multiple trajectory points within a single reporting cycle, with each trajectory point labeled with the collection time, cumulative mileage, and latitude and longitude. In response to the end of riding event or timeout failure to update event of the target two-wheeled vehicle, the trajectory points in all segmented riding data of the target two-wheeled vehicle in a single riding session are sorted and spliced ​​together according to the collection time to obtain the original trajectory sequence; Based on mileage constraints, vector angle constraints, and first and last point retention constraints, and combined with the cumulative mileage and latitude and longitude of each trajectory point in the original trajectory sequence, trajectory filtering is performed on the trajectory points in the original trajectory sequence to obtain a compressed trajectory point sequence. The acquisition time corresponding to the first trajectory point in the compressed trajectory point sequence is taken as the start time of the journey, and the acquisition time corresponding to the last trajectory point in the compressed trajectory point sequence is taken as the end time of the journey. The compressed trajectory point sequence, along with the corresponding vehicle identifier, cycling trip identifier, trip start time, and trip end time, are associated and stored to obtain archived trip trajectory data. The archived trip trajectory data is then stored in the distributed hybrid transactional analytical database TiDB and the object storage service OSS.

2. The method according to claim 1, characterized in that, The mileage constraint is as follows: if the cumulative mileage difference between the current trajectory point and the previous retained trajectory point is less than the mileage change threshold, then the current trajectory point is determined to be a redundant point and filtered, and when mileage filtering is triggered multiple times in a row, one trajectory point in multiple filtering cycles is forcibly retained. The vector angle constraint is as follows: take three consecutive trajectory points in sequence, calculate the driving vectors of the two segments of the trajectory based on the latitude and longitude of each point, and if the angle between the two segments of the vectors is less than the angle deviation threshold, then the middle trajectory point is determined as a straight redundant point and filtered. The constraint for retaining the first and last points is: retain the starting and ending trajectory points in the compressed trajectory point sequence.

3. The method according to claim 1, characterized in that, The track points are also marked with riding speed and battery level; The method further includes: In response to a riding record retrieval request from a client of an electric two-wheeled vehicle, the query start time, query end time, and riding trip identifier are extracted from the riding record retrieval request. Based on the query start time and the query end time, the storage duration of the cycling record to be retrieved corresponding to the cycling record retrieval request is identified; Based on the query start time, query end time, riding trip identifier, and vehicle identifier of the electric two-wheeled vehicle, and in conjunction with the storage duration, the archived trip trajectory data corresponding to the riding record retrieval request is obtained from the corresponding storage medium, and the archived trip trajectory data is used as the target trajectory data. The target trajectory data is assembled and parsed to obtain cycling trip summary information; the cycling trip summary information includes the trip start address, trip end address, total trip distance, total trip time, average cycling speed and trip power consumption. The summarized cycling trip information is then pushed to the client for display.

4. The method according to claim 3, characterized in that, The method further includes: In response to the client of the electric two-wheeled vehicle's request to replay the riding trajectory based on the summary riding trip information, the target trajectory data is sent to the client so that the client can use a smooth interpolation algorithm to perform interpolation and point filling operations on the target trajectory data in combination with the average riding speed to obtain the restored trajectory animation, and then display the restored trajectory animation.

5. The method according to claim 3, characterized in that, The storage medium includes the OSS and the TiDB distributed database; The process involves retrieving archived journey trajectory data corresponding to the riding record retrieval request from the corresponding storage medium based on the query start time, query end time, riding trip identifier, and the vehicle identifier of the electric two-wheeled vehicle, combined with the storage duration, and using this archived journey trajectory data as the target trajectory data. If the storage duration is greater than or equal to the storage time threshold, then based on the query start time, query end time, riding trip identifier, and vehicle identifier of the electric two-wheeled vehicle, the archived trip trajectory data corresponding to the riding record acquisition request is obtained from the OSS; If the storage duration is less than the storage time threshold, then based on the query start time, query end time, riding trip identifier, and the vehicle identifier of the electric two-wheeled vehicle, the archived trip trajectory data corresponding to the riding record retrieval request is obtained from the TiDB distributed database.

6. The method according to claim 2, characterized in that, The method further includes: Obtain the road conditions and vehicle type of the target two-wheeled vehicle; The mileage change threshold and the angle deviation threshold are adjusted based on the driving conditions and the vehicle model.

7. The method according to claim 1, characterized in that, The method further includes: If the duration of the same riding session corresponding to the target two-wheeled vehicle exceeds the preset maximum riding time limit and no riding end event is received, it is determined that the target two-wheeled vehicle has a timeout failure event.

8. A trajectory compression and storage system for a two-wheeled vehicle, characterized in that, The system includes an Internet of Things (IoT) platform, a Vehicle Service Platform (TSP) platform, a TiDB distributed database, and an OSS system. The IoT platform is used to periodically receive binary segmented riding messages reported by the target two-wheeled vehicle, and to perform protocol parsing on the segmented riding messages to obtain structured segmented riding data. The segmented riding message includes a message protocol header and a message body. The message body stores the vehicle identifier, riding trip identifier, satellite positioning sampling data, and real-time vehicle operating parameters. The segmented riding data is bound to the corresponding vehicle identifier and riding trip identifier. The segmented riding data includes multiple trajectory points within a single reporting cycle, and each trajectory point is marked with the collection time, cumulative mileage, and latitude and longitude. The TSP platform, in response to the end of riding event or timeout failure to update event of the target two-wheeled vehicle, sorts and splices the trajectory points in all segmented riding data of the target two-wheeled vehicle in a single riding session according to the collection time to obtain the original trajectory sequence. The TSP platform is also used to perform trajectory filtering on the trajectory points in the original trajectory sequence based on mileage constraints, vector angle constraints, and first and last point retention constraints, combined with the cumulative driving mileage and latitude and longitude of each trajectory point in the original trajectory sequence, to obtain a compressed trajectory point sequence. The TSP platform is also used to take the acquisition time corresponding to the first trajectory point in the compressed trajectory point sequence as the start time of the journey and the acquisition time corresponding to the last trajectory point in the compressed trajectory point sequence as the end time of the journey. The TSP platform is also used to associate and store the compressed trajectory point sequence with the vehicle identifier, cycling trip identifier, trip start time and trip end time corresponding to the compressed trajectory point sequence to obtain archived trip trajectory data, and store the archived trip trajectory data in the TiDB distributed database and the OSS.

9. A trajectory compression and storage device for a two-wheeled vehicle, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the trajectory compression storage method for a two-wheeled vehicle as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed on a terminal device, cause the terminal device to perform the trajectory compression storage method for a two-wheeled vehicle as described in any one of claims 1-7.

Images