A bus trajectory offset storage and query method based on distributed memory index

Abstract

The present invention relates to a bus track offset storage and query method based on distributed memory index, which belongs to the field of track semantic storage and track search technology. First, the city line information and bus GPS track data are obtained, and the grid sequences corresponding to the bus scheduled route and the bus actual GPS track are calculated respectively. The similarity between the actual GPS track of each bus and the scheduled route is further calculated to obtain the route offset information of each bus. All offset information is repartitioned in a time-grid manner using Spark's RDD elastic distributed dataset to form a global index. Within each partition, multi-level division is performed according to attributes such as date, route and license plate number, and auxiliary filter vectors are established at each level to form a local index. Finally, a spatiotemporal query interface is defined to support query based on multiple query condition combinations. The present invention realizes the rapid and efficient retrieval of route deviations with semantic information in ultra-large-scale GPS datasets.

Description

Technical Field

[0001] The present invention relates to a bus track offset storage and query method based on distributed memory index, belonging to the technical field of track storage and track search. Background Art

[0002] With the accelerated pace of urbanization and continued population growth, public transportation systems are facing increasing operational pressure. As a core component of urban public transportation networks, the operational efficiency and service quality of buses not only directly impact citizens' travel experience but also the overall operational effectiveness of the urban transportation system. However, in complex urban road networks and dynamic traffic conditions, buses can deviate from their scheduled routes due to factors such as road congestion, construction detours, and driver errors. These abnormal route deviations can result in a poor passenger experience, travel delays, reduced operational efficiency, and even serious safety hazards. For example, Shenzhen's public transportation system has over 1,000 bus routes, tens of thousands of buses operating daily, and serving millions of urban residents. Monitoring and managing bus route deviations over large temporal and spatial scales is fundamental to the safe operation of the public transportation system.

[0003] Solutions for GPS trajectory management and querying are becoming increasingly mature, but there's still a significant gap in managing abnormal trajectories with semantic information. Specifically, GPS trajectory data alone cannot determine whether a vehicle is following its intended route or has deviated. Existing solutions are mostly focused on GPS trajectory storage and querying, and cannot address the querying of abnormal trajectories with semantic information or route deviations.

[0004] Technologies for storing and indexing GPS trajectories include GeoMesa, GeoSpark, and TrajMesa. They efficiently process large-scale spatiotemporal data, particularly GPS trajectory data. To optimize data query efficiency, these technologies often combine multiple spatiotemporal indexing methods, such as GeoHash, which encodes two-dimensional spatial coordinates as strings to enable fast proximity queries; R-Tree, a tree-based index structure for multidimensional data, commonly used for spatial range queries; and H3, a hexagonal grid indexing system developed by Uber that efficiently supports spatial queries and aggregation operations. The combination of these indexing technologies makes the storage and querying of GPS trajectory data more efficient and flexible in large-scale scenarios.

[0005] However, in the case of route deviation data, it is necessary to consider both spatiotemporal and semantic information of the trajectory, such as the route number, license plate number, time, and spatial range of the vehicle that experienced the route deviation. Therefore, traditional spatiotemporal indexing methods cannot directly support trajectory queries with semantic information, requiring customized index design.

[0006] Building a bus route offset storage and query solution for large temporal and spatial scales faces the following challenges:

[0007] (1) Data management at large temporal and spatial scales. In a scenario with 1,000 bus routes, 10,000 buses travel an average of 16 hours per day, 180 kilometers per day, and generate an average of 1.8 million kilometers of GPS data per day, or 54 million kilometers per month. Meeting the storage requirements of this large-scale data scenario is the first challenge.

[0008] (2) Multi-dimensional index design. Route deviation data involves multiple factors such as time dimension (year, month, day), spatial dimension (longitude, latitude), route, and vehicle. How to design an efficient index is the second challenge faced in building a solution.

[0009] (3) Efficient query methods. In scenarios with massive data, distributed environments, and multi-dimensional spatiotemporal data, the third challenge is to design optimization measures such as query algorithms and filtering algorithms to accelerate the query process.

[0010] Chinese patent "CN113051359A" describes a large-scale trajectory data similarity query method based on a multi-level index structure. This method constructs a spatial grid index through data preprocessing and extracts trajectory start and end points and feature points to form a three-level index structure of "grid-start-end-feature point." This implements multi-level spatial correlation mapping of trajectory data. By filtering from coarse-grained to fine-grained data, it reduces computational effort and improves efficiency, achieving excellent query performance. However, this method primarily relies on an indexing mechanism based on spatial and geometric features, which cannot meet the technical requirements of the present invention: supporting spatiotemporal queries on GPS trajectories with semantic information. Summary of the Invention

[0011] The problem to be solved by the present invention is to provide a bus trajectory offset storage and query method based on distributed memory index, which is used to solve the problem of detecting route deviation in ultra-large-scale GPS data sets and further improve the operation quality of buses.

[0012] The technical solution of the present invention is to propose a method for storing and querying bus trajectory deviations based on a distributed memory index based on the above analysis. This method provides a method for rapidly calculating bus route deviation information, enabling the rapid generation of a bus deviation information set. Compared with common similarity calculation methods, this method uses a coarse-grained grid sequence instead of a dense GPS point sequence for trajectory similarity calculation, significantly reducing the complexity of trajectory similarity calculation. Furthermore, the algorithm is parallelized in a distributed environment, enabling rapid calculation of trajectory deviations for very large GPS datasets. Furthermore, a distributed global three-dimensional cube index is constructed, and the deviation GPS dataset is repartitioned based on the global index, mapping the deviation information to different nodes in the distributed environment according to cube number, thereby improving the performance of data parallel query. Furthermore, within each node, a multi-level data partition is established based on attributes such as date, route, and license plate number. An auxiliary filtering index is designed at each level. The multi-level data partition and the auxiliary filtering index constitute a local index. Finally, based on the global and local indexes, a spatiotemporal query method for route deviation GPS trajectories is implemented. Distributed secondary indexes improve search parallelism. Local indexes and auxiliary vectors avoid brute force searches during the query process and improve query efficiency in case of line deviation.

[0013] Specifically, the process is as follows:

[0014] First, obtain city route information and bus GPS trajectory data, calculate the grid sequence corresponding to the scheduled bus route, and calculate the grid sequence corresponding to the actual GPS trajectory of the bus. Further calculate the similarity between the actual GPS trajectory of each bus and the scheduled route, and obtain the route offset information of each bus. Use Spark's RDD elastic distributed dataset to repartition all offset information in a cube (time-grid) manner to form a global index. Within each partition, multi-level division is performed according to information attributes such as date, route and license plate number, and auxiliary filter vectors are established at each level. The multi-level division and auxiliary vectors form a local index. Finally, a spatiotemporal query interface is defined to support querying with multiple query condition combinations. The present invention realizes the rapid and efficient execution of route deviation retrieval with semantic information in ultra-large-scale GPS datasets.

[0015] A bus trajectory offset storage and query method based on distributed memory indexing, the specific steps are as follows:

[0016] Step 1: Obtain all bus GPS trajectories in a certain city within a certain period of time, perform data preprocessing, perform GPS trajectory map matching, and divide bus itineraries;

[0017] Step 2: Calculate the similarity between the actual GPS trajectory of each bus and the planned route, obtain the route deviation information of each bus, and form a bus route deviation information set;

[0018] Step 3: Use longitude and latitude to divide the urban area into equal grids, calculate the grid number corresponding to each offset information, map the offset information to the grid number and time slice index, and form a global index;

[0019] Step 4: Repartition and redirect the offset information, mapping the offset information to different nodes in the cluster according to the grid number;

[0020] Step 5: Within each partition, the offset information is divided into multiple levels by date, route, and license plate number to form a tree structure. An auxiliary filtering vector is constructed within each level. The multi-level tree structure and the auxiliary vectors form a local index structure.

[0021] Step 6: Submit the query information, which is any combination of date, license plate number, route number, longitude and latitude;

[0022] Step 7: Calculate the intersection of the query information and the global index, determine the partitions involved in the query, and multicast the query conditions to the corresponding partitions;

[0023] Step 8: After receiving the query conditions, each partition traverses the local index, uses auxiliary vectors to accelerate the query process, and saves the intermediate results involved in the query;

[0024] Step 9: Aggregate the intermediate results involved in each partition to form the final query result, and return the final query result.

[0025] Specifically, the relevant definitions of the present invention are as follows:

[0026] In an urban public transportation system, multiple bus routes are operated simultaneously. The definition of a bus route set is:

[0027] (1)

[0028] In formula (1), bus routes, ;

[0029] A bus route consists of multiple buses. The set of buses belonging to the same route is defined as:

[0030] (2)

[0031] In formula (2), For bus route signs, For buses, ;

[0032] The bus is equipped with a GPS positioning device, which generates GPS records regularly. The GPS records contain three fields: timestamp, longitude, and latitude. These three fields constitute a time-space point, which is defined as:

[0033] (3)

[0034] In formula (3), Represents the GPS timestamp, represents the longitude of a point in spacetime, represents the latitude of a point in space and time;

[0035] After map matching and trip segmentation, the complete GPS record of a single bus is defined as:

[0036] (4)

[0037] In formula (4), linenumber represents the bus line number, idx represents the license plate number of a specific bus, opath represents the road section number after the latitude and longitude are matched with the map, journey represents the specific itinerary of a bus on a certain day in the bus GPS data, and direction represents the up and down directions of the bus, 1 represents up and 2 represents down.

[0038] There are bus stops along the bus routes. Different bus routes have different bus stop sequences. The bus stop set is defined as:

[0039] (5)

[0040] In formula (5), For bus stops on the bus route, , a set of bus stops are arranged in an orderly manner along a predetermined route;

[0041] There are bus stops along the bus route, and the data structure of a single stop is defined as:

[0042] (6)

[0043] In formula (6), station represents the name of the current bus station, stLon represents the longitude of the current station, stLat represents the latitude of the current station, and position represents the station position in the bus scheduled route corresponding to the longitude and latitude in the bus station data;

[0044] The bus GPS trajectory describes a series of time-ordered GPS records generated by a bus as it travels along a predetermined route. The vehicle trajectory is defined as:

[0045] (7)

[0046] In formula (7), Represents a series of space-time points generated by the bus in chronological order, ;

[0047] The route trajectory set contains the trajectory set generated by all buses on a specific route, recording the specific location information of each bus. It is defined as follows:

[0048] (8)

[0049] In formula (8), For the line trajectory, ;

[0050] After map matching of each bus's GPS track, each GPS point is associated with a road section number. The GPS track fragment after map matching is as follows:

[0051] (9)

[0052] In formula (9), For the GPS point of the bus, , Number the road sections of the map road network;

[0053] Use longitude and latitude to divide the urban area into equal grids and define a grid calculation function. This function divides the bus GPS data into different grids according to the geographic location and the specified calculation accuracy. The grid calculation function is as follows:

[0054] (10)

[0055] In formula (10), gdf is the bus GPS data with longitude and latitude information, accuracy is the specified grid size for calculating the bus GPS data. The present invention uses a square grid, and gridMath() is a custom function that takes gdf and accuracy as input and outputs the gridded GPS data gpsGrid.

[0056] The calculation interface of the grid number is implemented as follows:

[0057] Based on the given research scope and grid size, calculate the longitude ∆lon and latitude ∆lat corresponding to the length and width of the grid, give the longitude and longitude (x, y) of any point within the research scope, and calculate the distance between x and y and the lower left corner. and The specific grid number is obtained by the number of longitude ∆lon and latitude ∆lat. The formula is as follows:

[0058] (11)

[0059] (12)

[0060] (13)

[0061] (14)

[0062] In formulas (11) to (14), ⌊⌋ indicates rounding down, loncol and latcol indicate grid numbers, the study range is (minx, miny, maxx, maxy), the radius of the earth is R, and the circumference of the meridian is , corresponding to 360° of longitude, the circumference of the latitude is , corresponding to 360° of latitude, the grid side length is a;

[0063] The grid number corresponding to the latitude and longitude (lon, lat) of a specific GPS point is defined as follows:

[0064] (15)

[0065] In formula (15), Represents the grid number corresponding to the longitude of the GPS point, Represents the grid number corresponding to the latitude of the GPS point;

[0066] By calling formula (10), the grid number corresponding to a complete GPS record is calculated and defined as follows:

[0067] (16)

[0068] By calling formula (10), the data grid number corresponding to a certain site is calculated and defined as follows:

[0069] (17)

[0070] There are bus stops along the bus routes. A complete bus route consists of multiple fixed grids. The grids are arranged in order according to the bus operation sequence. The corresponding grid number is calculated by calling formula (10) according to the longitude and latitude of the bus stop. The bus stop grid sequence is defined as follows:

[0071] (18)

[0072] In formula (18), is the corresponding grid, ;

[0073] A complete bus GPS track is composed of multiple grids. The grids are arranged in order according to the bus running time. The corresponding grid number is calculated by calling formula (8) according to the longitude and latitude of the GPS track point. The GPS track grid sequence is defined as follows:

[0074] (19)

[0075] In formula (19), busid is the bus license plate number;

[0076] The similarity is reflected by calculating the length of the longest common subsequence LCS between two sequences. Given two sequences 𝑋={𝑥1,𝑥2,…,𝑥 𝑚} and 𝑌={𝑦1,𝑦2,…,𝑦 𝑛}, the length of LCS 𝐿(𝑋,𝑌) is defined as the length of the longest common subsequence between the two sequences, and the calculation formula is as follows:

[0077] (20)

[0078] In formula (20), represents the LCS length of the first 𝑖 elements of sequence 𝑋 and the first 𝑗 elements of sequence 𝑌;

[0079] When m=0 or n=0, it means that at least one sequence is empty, and the length of the longest common subsequence is 0;

[0080] when When the length of the common subsequence increases by 1, the current problem is transformed into calculating the prefix subsequence and LCS length;

[0081] when When , the solution of the current subproblem is to remove or remove The maximum value of the solutions to the last two subproblems;

[0082] The trajectory similarity measurement function is used to calculate the longest common subsequence between two different trajectories by calling formula (20), which is defined as follows:

[0083] LCSLength = L (StationGridSeq, GPSGridSeq)(21)

[0084] In formula (21), 𝑆𝑡𝑎𝑡𝑖𝑜𝑛𝐺𝑟𝑖d𝑆𝑒𝑞 is the grid sequence of bus stops, and GPS𝐺𝑟𝑖d𝑆𝑒𝑞 is the grid sequence of GPS tracks of a bus corresponding to a specific bus route;

[0085] Define the trajectory similarity calculation function to detect bus trajectory deviation:

[0086] (twenty two)

[0087] In formula (22), LCSlength is the length of the longest common subsequence LCS, LCSsimilarity represents the similarity ratio between the two sequences, and its value is between 0 and 1, where 1 indicates a perfect match and 0 indicates no common subsequence, |GPSLength| is the length of the GPS track grid sequence after deduplication, and |StationLength| is the length of the station grid sequence.

[0088] Specifically, the Step 2 is as follows:

[0089] The route deviation refers to the situation where the bus does not travel according to the scheduled route. According to formula (22), the route deviation is defined as when the calculation result of the longest common subsequence similarity LCSsimilarity is less than the preset threshold, the route is judged to have deviated;

[0090] The line offset calculation process is as follows:

[0091] Step 2.1: Get all the data of bus stations (stationRecording) and GPS track data of all buses (GPSRecording);

[0092] Step 2.2: Apply formula (10) to each row of the bus station data and GPS trajectory data to calculate the grid number stationGrid corresponding to the station data and the grid number GPSGrid corresponding to the GPS trajectory data;

[0093] Step 2.3: Persist the gridded bus stop data into memory;

[0094] Step 2.4: Convert the bus stop grid data into key-value pairs, specifically:

[0095] ;

[0096] Step 2.5: Group by linenumber and direction key values, combining bus lines and stops with the same up and down directions;

[0097] Step 2.6: Sort each group of station data according to the station position of the bus scheduled route;

[0098] Step 2.7: Remove the position field from the key-value pairs processed in Step 2.6, leaving only the {(linenumber, direction), (loncol, latcol)} combination;

[0099] Step 2.8: Keep the grid order after step 2.6 unchanged and remove duplicate values ​​(loncol, latcol) in the key-value pairs;

[0100] Step 2.9: Define stationDict to receive the station grid sequence obtained by the above processing, specifically ;

[0101] Step 2.10: Broadcast the stationdict obtained from the above process to all nodes in the cluster;

[0102] Step 2.11: Process the gridded GPS track data GPSGrid in Step 2.2;

[0103] Step 2.12: Convert GPS data into key-value pairs, specifically:

[0104] ;

[0105] Step 2.13: Group by key value (linenumber, idx, direction, journey), combining GPS data with the same bus line, bus license plate, up and down directions, and the same journey;

[0106] Step 2.14: Sort each group of GPS data according to the specific time of each trip;

[0107] Step 2.15: Convert the time to date format YYYY-MM-DD;

[0108] Step 2.16: Remove the time field, keep the grid order unchanged, and deduplicate the value (loncol, latcol) in the key-value pair.

[0109] Step 2.17: Define GPSDict to receive the GPS grid sequence obtained from Step 2.11-Step 2.16. Specifically, GPSDict = {( linenumber, idx, direction, journey, date), (GPSGridSeq)};

[0110] Step 2.18: Calculate the longest common subsequence and similarity between the GPS track grid sequence and the site grid sequence in each partition by calling formula (21) and formula (22); the specific implementation is as follows:

[0111] Step 2.18.1: Initialize a similarities dictionary to store similarity results;

[0112] Step 2.18.2: Extract the station data dictionary stationDict;

[0113] Step 2.18.3: Initialize the variable i = 1 to traverse all GPS track data in GPSDict;

[0114] Step 2.18.4: Determine the relationship between i and the length of the dictionary (GPSDict.len). If i <= GPSDict.len, retrieve the current track data (key, GPSGridSeq) for processing; otherwise, go to Step 2.18.12.

[0115] Step 2.18.5: Initialize a tuple tuple = (key, GPSGridSeq), key = tuple[0], get the key value of the tuple, value = tuple[1], get the GPS track grid sequence GPSGridSeq of the tuple;

[0116] Step 2.18.6: Extract the following information from the key variable: linenumber, idx, direction. Do not process the remaining irrelevant fields.

[0117] Step 2.18.7: Check if (linenumber, direction) exists in stationDict. If so, get the station grid sequence stationGridSeq for the line and perform similarity calculation. Otherwise, go to Step 2.18.11 to traverse the next trajectory data.

[0118] Step 2.18.8: Calculate the longest common subsequence length LCSLength between the corresponding GPSGridSeq and stationGridSeq according to formula (21);

[0119] Step 2.18.9: Calculate the similarity ratio LCSsimilarity between GPSGridSeq and stationGridSeq according to formula (22);

[0120] Step 2.18.10: Store the calculated results of the current trajectory data into similarities;

[0121] Step 2.18.11: Variable i is incremented by 1, i=i+1, pointing to the next GPS track data in GPSDict;

[0122] Step 2.18.12: Return similarities.items(), which contains the longest common subsequence length LCSength, the station grid sequence length stationLength, the GPS track grid sequence length gpsLength, and the similarity ratio LCSsimilarity between the GPS track grid sequence and the station grid sequence;

[0123] Step 2.19: Collect all the calculation results in Step 2.18 and return them in the form of a dictionary, specifically {(linenumber, idx, direction, journey, date), (LCSsimilarity, lcsLength, stationLength, gpsLength)};

[0124] Step 2.20: Filter the data with similarity results less than the preset threshold in the obtained similarity results to obtain all the route numbers, bus license plates, up and down directions, travel itineraries, and corresponding travel dates that deviate from the track.

[0125] Specifically, the Step 3 is as follows:

[0126] Step 3.1: Based on the longitude and latitude boundaries (lat_min, lat_max, lon_min, lon_max) and grid size of the given study area, the urban area is divided into equal grids using longitude and latitude;

[0127] Step 3.2: Calculate the grid number corresponding to each offset information according to formula (10);

[0128] Step 3.3: Based on the time span of the study, set the time slice ∆t to 7 days as the time dimension of the global index;

[0129] Step 3.4: For any given time t, calculate the time slice index to which it belongs. The formula is as follows:

[0130] (twenty three)

[0131] In formula (23), is the starting time of the study time range;

[0132] Step 3.5: Generate a 3D cube global index based on the mapping of offset information to grid numbers and time, specifically:

[0133] Combine the spatial index (loncol, latcol) and the time index timeIndex to build a three-dimensional index (loncol, latcol, timeIndex), so that the data forms a three-dimensional cube structure based on the longitude, latitude, and time slice indexes;

[0134] Three-dimensional index structure: X-axis grid number loncol, Y-axis grid number latcol, Z-axis time index timeIndex, divided by time slice ∆t.

[0135] Specifically, the Step 4 is as follows:

[0136] Step 4.1: Repartition the offset data based on the global index, specifically Step 4.2 to Step 4.4;

[0137] Step 4.2: Set the total number of grids × the number of time slices = the number of partitions. If the city area is divided into M grids, and the time span timeTotal can be divided into K time slices by ∆t, then the number of partitions = M × K.

[0138] Step 4.3: Each (loncol, latcol, timeIndex) uniquely corresponds to a partition number, so that data is stored according to spatial location + time slice; the partition number is calculated as follows:

[0139] (twenty four)

[0140] in, is the partition number;

[0141] Step 4.4: Map data to corresponding partitions based on the global index;

[0142] Step 4.5: For a single GPS track point (t, lon, lat), calculate the spatial index and time index to determine the partition where the data is located;

[0143] Step 4.6: Calculate the grid number (loncol, latcol) according to formula (10) to determine its spatial location;

[0144] Step 4.7: Calculate the time index timeIndex according to formula (23) and determine its time slice index;

[0145] Step 4.8: Calculate the partition number by calling formula (24) based on the 3D cube index (loncol, latcol, timeIndex) to obtain the corresponding partition mapped to the point.

[0146] Specifically, the Step 5 is as follows:

[0147] The specific construction of the partitioned local multi-level index tree structure function is as follows:

[0148] gpsPartitionIndex = buildTree(partitionNmber,iterator)(25)

[0149] In formula (25), partitionNmber represents the partition number where the data is located, iterator represents an iterator used to obtain all data rows in the partition, buildTree() is a custom function that takes partitionNmber and iterator as input and outputs gpsPartitionIndex, where gpsPartitionIndex represents a local multi-level index tree;

[0150] The specific function implementation interface is as follows:

[0151] Step 5.1: Use defaultdict to initialize a multi-layer nested index tree structure gpsPartitionIndex;

[0152] Step 5.2: The multi-layer nested index tree structure in Step 5.1 is as follows:

[0153] The first-level node date corresponds to the date in the GPS trajectory data;

[0154] The second-level node linenumber corresponds to the bus line number on a specific date;

[0155] The third-level node idx corresponds to the license plate number of each vehicle on the bus route;

[0156] The fourth layer nodes are specific points, which store the GPS data point latitude and longitude (lon, lat), up and down direction, and journey information;

[0157] Step 5.3: Construct the auxiliary vector has_data inside each level of the index tree;

[0158] Step 5.4: Set the initial value of the auxiliary vector to 0. The value of the auxiliary vector is 0 or 1, where 0 represents no data and 1 represents data.

[0159] Step 5.5: Use the iterator to get each row of data in the partition;

[0160] Step 5.6: Initialize the variable i to 1 to traverse all data rows in the iterator;

[0161] Step 5.7: Determine the relationship between i and the number of data rows, iterator.len; if i <= iterator.len, go to Step 5.8; otherwise, go to Step 5.12;

[0162] Step 5.8: Extract and process the fields in the iterator. The specific fields are:

[0163] ;

[0164] Step 5.9: Insert the date, line number, idx, GPS point (lon, lat), direction, and journey in each row of data into the corresponding position according to the tree structure;

[0165] Step 5.10: The specific data insertion is:

[0166] Insert the data into the first-level node of the tree according to date, insert the data into the second-level node according to linenumber, and insert the data into the third-level node according to linenumber according to idx. Under the node corresponding to idx, append all the GPS points (lon, lat) of the vehicle and their up and down directions and travel information to the points list. After each successful insertion, set the value of the auxiliary vector has_data to 1, indicating that the node and its parent node contain data.

[0167] Step 5.11: Variable i is incremented by 1, i=i+1, pointing to the next row of data in the iterator;

[0168] Step 5.12: Return a multi-level index tree structure containing the partition number and the construction (partitionNmber, tree), where tree is a tree structure;

[0169] Step 5.13: Build a partitioned local multi-level index tree in each partition according to the buildTree() function;

[0170] Step 5.14: Cache the local multi-level index tree in each partition into memory;

[0171] Step 5.15: Return the local multi-level index tree gpsPartitionIndex.

[0172] Specifically, the Step 7 is as follows:

[0173] Step 7.1: Initialize an empty set partitionsQuery to store the partition numbers that meet the query conditions;

[0174] Step 7.2: Define query conditions queryConditions = (date, linenumber, idx, lon, lat), where date, linenumber, idx, lon, and lat can be set arbitrarily according to actual needs;

[0175] Step 7.3: Based on the given date, calculate the time slice timeIndex to which the date belongs according to formula (23);

[0176] Step 7.4: Based on the longitude and latitude (lon, lat), calculate the corresponding grid number (loncol, latcol) according to formula (10);

[0177] Step 7.5: Based on Step 7.3 and Step 7.4, calculate the specific partition number partitionIndex according to formula (24);

[0178] Step 7.6: Store partitionIndex into partitionsQuery;

[0179] Step 7.7: Return the set of all partition numbers that meet the query conditions partitionsQuery;

[0180] Step 7.8: Multicast the query conditions to the corresponding partitions.

[0181] Specifically, the Step 8 is as follows:

[0182] Construct a local index search function. This function is used to query the corresponding trajectory based on any combination of the specified date, route number, and bus ID in the created distributed multi-level tree index structure. During the search process of each level of the tree, the auxiliary vector value is judged to be 0 or 1 to accelerate the search process. The specific construction is as follows:

[0183] queryGpsResult = queryGpsData(tree, date=None, linenumber=None, idx=None)(26)

[0184] In formula (26), tree is the constructed local multi-level index tree structure of GPS data, queryGpsData() is a custom function that takes tree, date, linenumber and idx as input and outputs the query result queryGpsResult;

[0185] The default values ​​of the date, linenumber, and idx parameters in the function are set to None. When performing a query, the bus track that matches the specified conditions is searched for according to any combination of the specified date, line number, and bus ID.

[0186] The specific function implementation interface is as follows:

[0187] Step 8.1: Define the queryGpsData() interface of the search function;

[0188] Step 8.2: Initialize an empty list results to store query results;

[0189] Step 8.3: Determine whether the date parameter is provided;

[0190] Step 8.3.1: If the date parameter is not provided, initialize the variable i to 1 to traverse all dates in the index tree;

[0191] Step 8.3.2: If i <= len(tree), then for each date, check the corresponding linenumber and idx and go to Step 8.4; otherwise, go to Step 8.3.4:

[0192] Step 8.3.3: Variable i is incremented by 1, i=i+1, pointing to the next date;

[0193] Step 8.3.4: If a date parameter is provided, first determine the value of the auxiliary vector has_data corresponding to the date parameter. If the value is 0, it indicates that there is no data for that date, and an empty result is directly returned. If the value is 1, go to Step 8.4;

[0194] Step 8.4: Determine whether linenumber is specified;

[0195] Step 8.5: If linenumber is specified;

[0196] Step 8.5.1: Enter the judgment branch corresponding to linenumber and quickly determine whether the node corresponding to linenumber has data based on the value of the auxiliary vector;

[0197] Step 8.5.2: If the value of the auxiliary vector corresponding to linenumber is 0, it means there is no data under this linenumber, and a null value is returned directly;

[0198] Step 8.5.3: If the value of the auxiliary vector corresponding to linenumber is 1 and idx is specified, determine the value of the auxiliary vector corresponding to idx;

[0199] Step 8.5.4: If the auxiliary vector value corresponding to idx is 0, it indicates that there is no data, skip the current idx, and return a null value; if the auxiliary vector value corresponding to idx is 1, it indicates that there is data, and the corresponding GPS point information is stored in the results list to form the corresponding trajectory;

[0200] Step 8.5.5: If the value of the auxiliary vector corresponding to linenumber is 1 and idx is not specified, then search for all idx under the linenumber and determine the value of the auxiliary vector corresponding to each idx, performing the same operation as Step 8.5.4;

[0201] Step8.6: If linenumber is not specified;

[0202] Step 8.6.1: Enter the judgment branch corresponding to idx;

[0203] Step 8.6.2: Determine whether idx is specified;

[0204] Step 8.6.3: If idx is specified, initialize the variable j to 1 to traverse all linenumbers under the current date;

[0205] Step 8.6.4: If j <= len(tree[date]), check whether each linenumber contains the specified idx and go to Step 8.5.2; otherwise, go to Step 8.7.

[0206] Step 8.6.5: Variable j is incremented by 1, j = j + 1, pointing to the next line number;

[0207] Step 8.6.6: If idx is not specified, initialize the variable k to 1 to traverse all linenumbers under the current date;

[0208] Step 8.6.7: If k <= len(tree[date]), go to Step 8.5.2; otherwise, go to Step 8.7.

[0209] Step 8.6.8: Variable k is incremented by 1, k=k+1, pointing to the next line number;

[0210] Step 8.7: Return the results list, which contains all the data results queryGpsResult that meet the query conditions.

[0211] Specifically, the Step 9 is as follows:

[0212] Step 9.1: Initialize an empty list allResults to store the query results of each partition;

[0213] Step 9.2: Determine whether the query condition provides the date and longitude and latitude;

[0214] Step 9.3: If the date and longitude and latitude are given, determine the partitions involved in the query condition according to Step 7;

[0215] Step 9.4: Execute the local index search function queryGpsData in formula (26) in the partition involved;

[0216] Step 9.5: If no date or longitude and latitude are given, the local index search function queryGpsData in formula (26) is directly executed in all partitions;

[0217] Step 9.6: Collect the query results allResults of all partitions into the driver program;

[0218] Step 9.7: Determine whether there is data in the collected allResults. If there is no data, directly return "There is no data for this query";

[0219] Step 9.8: If there is data, initialize an empty list combinedResults to merge the query results of different partitions to obtain a specific trajectory;

[0220] Step 9.9: Initial variable i is used to iterate over all the results allResults collected in Step 9.5. The data structure is ({(date, linenumber, idx): ((lng, lat), (direction, journey))});

[0221] Step 9.10: If i <= len(allResults), go to Step 9.11; otherwise, go to Step 9.14;

[0222] Step 9.11: If allResults contains a triple of date, linenumber, and idx, extract all points and merge the result lists in each partition into a total list. Generate a trajectory based on the total list, format the result into a string, and append it to combinedResults.

[0223] Step 9.12: If allResults does not contain idx and only contains date and linenumber, merge all idx lists to get the traces of all idx, format the result into a string and append it to combinedResults;

[0224] Step 9.13: Variable i is incremented by 1, i=i+1, pointing to the next partition query result allResults;

[0225] Step 9.14: Return the final query result list combinedResults.

[0226] The beneficial effects of the present invention are:

[0227] (1) This paper proposes a method for efficiently calculating bus route deviation information, which can quickly form a bus deviation information set. Compared with common similarity calculation methods, this method can achieve efficient calculation on ultra-large-scale GPS data sets, can quickly locate and extract trajectory deviation information, and provide strong support for monitoring and intelligent traffic management;

[0228] (2) This paper proposes a distributed global three-dimensional cube index and repartitions the data based on the index, so that the offset information is distributed to different nodes in the cluster according to the grid number and time slice index, thereby improving the flexibility of data management and computing efficiency;

[0229] (3) The present invention proposes a distributed local multi-level index and its query method. Auxiliary vectors are designed in the local index. The auxiliary vectors can be used to accelerate data filtering when querying offset information, avoid brute force search, and improve retrieval efficiency.

[0230] (4) The present invention is implemented in parallel based on the big data computing engine Spark. Compared with existing methods, it has stronger data processing capabilities and can quickly and efficiently perform the retrieval of route deviation information with semantic information in ultra-large-scale GPS data sets. BRIEF DESCRIPTION OF THE DRAWINGS

[0231] Figure 1 This is the technical roadmap of the present invention;

[0232] Figure 2 This is a schematic diagram of the global index of a three-dimensional cube;

[0233] Figure 3 This is a schematic diagram of a partitioned local multi-level index;

[0234] Figure 4 It is a schematic diagram of partitioned local multi-level index parameters;

[0235] Figure 5 Schematic diagram of a query using a global-local index. DETAILED DESCRIPTION

[0236] The present invention will be further described below in conjunction with the accompanying drawings and specific embodiments based on the description.

[0237] The bus GPS trajectory data used in this paper comes from Shenzhen's bus operation data from January 2019. The dataset contains 3,658 bus routes, 16,800 vehicles, 3.222 billion GPS records, and a total data volume of 394.50GB. After map matching and trip segmentation, each GPS record contains the following fields: route number, bus ID, segment number, timestamp, longitude, latitude, trip distance, and up / down direction.

[0238] This paper was implemented in a six-node Spark cluster consisting of one client node, one master node, and four worker nodes. Each node was configured with an 8-core CPU, 16GB of memory, and a 500GB hard drive. The relevant software versions were as follows: CentOS operating system 7.9; Hadoop 3.3.4; Spark 3.3.3; pySpark 3.3.3; and Python 3.10.0.

[0239] Figure 1 The technical route of the present invention is described. The GPS data preprocessing part in the figure corresponds to step Step 1, which is used to provide the required data format for subsequent route deviation information calculation, space-time cube division, and the construction of global index and local index. Figure 1 The index construction part corresponds to Step 2 to Step 5, which is used to calculate the deviation information of the actual GPS trajectory of each bus, divide the urban area into spatiotemporal cubes, and build a three-dimensional cube global index and multi-level local index. Figure 1 The spatiotemporal query part corresponds to Step 6 to Step 9. Its function is to quickly locate the partition involved in the relevant query based on the global index, multicast the query conditions, traverse the local index of the partition, and use the auxiliary vector to accelerate the query process and finally obtain the query result.

[0240] Example 1: Figure 1 The bus trajectory offset storage and query method shown in the figure based on distributed memory index includes the following steps:

[0241] Step 1: Obtain GPS trajectory data for 16,800 buses on 3,658 routes in Shenzhen in January 2019. Perform data cleaning and preprocessing, perform GPS trajectory map matching, align the raw GPS data with the map road network, and divide the bus trips.

[0242] Step 2: Calculate the similarity between the actual GPS trajectory of each bus and the planned route, obtain the route deviation information of each bus, and generate a bus deviation information set.

[0243] The specific implementation process is as follows:

[0244] Use pySpark program to obtain bus stop data and bus GPS trajectory data from HDFS;

[0245] Apply formula (8) to each row of GPS trajectory data and bus stop data to calculate the grid number of the corresponding data;

[0246] Use the cache() method in pyspark to persist the gridded bus stop data into memory;

[0247] Use the map() method in pyspark to convert the site data into key-value pairs:

[0248]

[0249] Use the operator groupByKey() to group by linenumber and direction key values;

[0250] Use the mapValues() operator to sort each group of station data according to the station position of the bus scheduled route;

[0251] Use the mapValues() operator to remove the position field from the processed key-value pairs, leaving only the {(linenumber, direction), (loncol, latcol)} combination;

[0252] Use the OrderedDict() method to remove duplicates from the value (loncol, latcol) in the key-value pair while maintaining the order of the sorted grid.

[0253] Use the collectAsMap() operator to convert the RDD obtained from the above processing into key-value pairs;

[0254] Use the broadcast() method to broadcast the site key-value pairs obtained from the above processing to all nodes in the cluster, so that when performing similarity calculations, each node can access the site information without the need to repeatedly transmit data, thereby reducing the data transmission overhead of site data between nodes;

[0255] Use the conversion operator map() method to convert GPS data into key-value pairs:

[0256]

[0257] Use the groupByKey() operator to group by key value (linenumber, idx, direction, journey) to combine GPS data with the same bus line, bus license plate, up and down directions, and the same journey;

[0258] Use the mapValues() operator to sort each group of GPS data according to the specific time of each trip;

[0259] Use the collectAsMap() operator to convert the above processing results into key-value pairs;

[0260] Use partitionBy() to call a custom partitioning method to repartition the GPS data so that the amount of data in each partition is more uniform and the computing task load is more balanced.

[0261] Use the operator mapPartitions() to call the specific trajectory similarity calculation function and execute it in parallel in each partition;

[0262] Use collectAsMap() to collect the similarity calculation results into the driver program and return them.

[0263] Specifically, taking Shenzhen on January 4, 2019 as an example, there were 28,721,375 GPS data items. After trajectory offset calculation, 5,778 trajectory data items with a similarity less than the preset threshold of 0.90 were screened out, taking an average of 61.8 seconds.

[0264] Step 3: Use longitude and latitude to divide the entire Shenzhen area into equal grids with a grid size of 3500m*3500m. The entire Shenzhen area is divided into 204 grids. The grid number corresponding to each offset information is calculated according to formula (10), and the time slice index corresponding to each offset information is calculated according to formula (23). Then, based on the mapping of offset information to grid number and time slice index, a three-dimensional cube global index is constructed. The index structure is: X-axis grid number (loncol), Y-axis grid number (latcol), Z-axis time slice index (timeIndex).

[0265] Step 4: Calculate the partition number of the offset information based on the three-dimensional cube global index (loncol, latcol, timeIndex) according to formula (24), and use the partitionBy() method to distribute the offset information to different nodes in the cluster according to the custom partitioning method.

[0266] Step 5: Within each partition, the offset information is divided into multiple levels by date, route, and license plate number to form a tree structure; an auxiliary vector is constructed within each level, and the multi-level tree structure and the auxiliary vector form a local index structure.

[0267] The specific construction details are as follows:

[0268] Insert data into the first-level tree node based on date, insert data into the second-level node based on line number, and insert data into the third-level node based on line number based on idx. Under the node corresponding to idx, all GPS points (lon, lat) for the vehicle, along with their uplink and downlink directions and travel information, are appended to the points list. After each successful insertion, the auxiliary vector has_data is set to 1, indicating that data exists at that node and its parent node. Specifically, using the January 2019 offset data for Shenzhen as an example, the mapPartitionsWithIndex() method was used to call the buildTree() function in each partition to construct a partitioned local multi-level index tree, which took a total of 16.28 seconds.

[0269] Step 6: Submit the query information. The query information can be any combination of date, license plate number, route number, and latitude and longitude. Specifically, query condition 1: queryConditions1 = ('2019-01-04', '00276', 'BS0010X'), query condition 2: queryConditions2 = ('2019-01-04', ' M5323', '113.94029185', '22.5491592202'), query condition 3: queryConditions3 = ('2019-01-04', ' M5063','113.940523711', '22.5449062151').

[0270] Step 7: Calculate the intersection of the query information and the global index, determine the partitions involved in the query, and use the broadcast() method to multicast the query conditions to the corresponding partitions. Specifically, for query condition 2: queryConditions2 = ('2019-01-04', ' M5323', '113.94029185', '22.5491592202'), based on the longitude and latitude, use formula (10) to calculate the corresponding grid number (6, 2). Based on the date, use formula (23) to calculate the time slice to which the date belongs, which is 1. Then, use formula (24) to calculate the partition number 212. Query condition 2 can be multicast to the corresponding partition 212.

[0271] Step 8: After receiving the query conditions, each partition uses the mapPartitions() method to execute the partition search function formula (26) in each relevant partition to traverse the local index, use auxiliary vectors to accelerate the query process, and save the intermediate results involved in the query. Take query condition 1: queryConditions1 = ('2019-01-04', '00276', 'BS0010X') as an example. This query condition provides the date, line number, and bus ID. First, the auxiliary vector has_data corresponding to the date parameter is judged to be 1, indicating that data exists under this date; then, the judgment branch corresponding to linenumber is entered, and the auxiliary vector corresponding to linenumber is judged to be 1, indicating that data exists under this line number; finally, the auxiliary vector corresponding to the corresponding bus ID is judged to be 1, indicating that data exists under this bus ID, and the corresponding GPS point information is stored in the result list to form the corresponding trajectory.

[0272] Step 9: Use the collect() method to collect the intermediate results involved in each partition to form the final query result, and return the final query result.

[0273] Figure 2 This is a diagram of the global index of a three-dimensional cube. The index structure is: X-axis grid number (loncol), Y-axis grid number (latcol), Z-axis time slice index (timeIndex). Each spatiotemporal grid (loncol, latcol, timeIndex) corresponds to a partition. A local multi-level index tree is constructed within the partition to store and query specific offset information.

[0274] like Figure 2 As shown in Figure 2, the specific construction process of the 3D cube global index is as follows: First, the Shenzhen area is divided into equal grids using longitude and latitude based on the longitude and latitude boundaries (lat_min, lat_max, lon_min, lon_max) and grid size of the given study area. Then, the grid number corresponding to each offset information is calculated according to formula (10), and the time slice index corresponding to each offset information is calculated according to formula (23). Then, based on the mapping from offset information to grid number and time slice index, the 3D cube global index is constructed. Then, the partition number is calculated according to formula (24) to obtain the partition corresponding to each spatiotemporal grid.

[0275] Figure 3 This is a schematic diagram of a partitioned local multi-level index tree. The structure of the multi-level index tree is as follows:

[0276] The first-level node, date, corresponds to the date in the GPS trajectory data and is used to divide the data by date to implement data organization in the time dimension;

[0277] The second-level node linenumber corresponds to the bus route number on a specific date and is used to further divide the data by route number and refine it to the specific route;

[0278] The third-level node idx corresponds to the license plate number of each vehicle on the bus route and is used to further refine the data by license plate number and locate the specific vehicle;

[0279] The fourth layer of nodes are specific points, which store detailed information of GPS data points, including longitude and latitude (lon, lat), up and down direction, and journey information, forming specific offset trajectory information.

[0280] To optimize query efficiency, an auxiliary vector, has_data, is constructed within each layer of the index tree. Its value is either 0 or 1, which is used to quickly determine whether data exists at that layer's nodes. This mechanism effectively avoids brute-force searches and significantly improves query performance.

[0281] Figure 4 This is a local index parameter diagram, which is used to explain the parameters of each node layer in a partitioned local multi-level index tree. This diagram clearly marks the key parameters of each node layer, providing an intuitive reference for understanding and using the multi-level index tree.

[0282] Figure 5 The following is a query diagram for a global-local index, which describes the query execution process in detail:

[0283] Step 1: Based on the query conditions, call formula (10), formula (23) and formula (24) to calculate the partitions involved in the query conditions and quickly locate them in the global index;

[0284] Step 2: Directly broadcast the query conditions to the specific partitions involved;

[0285] Step 3: Within the partition, call formula (26) to perform the specific search process on the local multi-level index tree;

[0286] Step 4: Transmit local query results of multiple partitions;

[0287] Step 5: Merge the query results of different partitions to obtain the specific trajectory.

[0288] In order to verify the efficiency of building a local multi-level index tree, the present invention measured the time required for its construction through multiple experiments. The specific experimental results are shown in Table 1:

[0289] Table 1 Performance analysis of local multi-level index tree construction

[0290]

[0291] Table 1 shows the performance test results of building a local multi-level index tree based on the Shenzhen GPS trajectory offset dataset from January 2019. Through repeated experiments, the average construction time was 16.53 seconds, and the single construction time remained stable between 16.28 seconds and 16.72 seconds.

[0292] To systematically verify the acceleration effect of local multi-level indexes and auxiliary vectors in trajectory offset queries, we designed a set of comparative experiments based on different query conditions. By comparing the performance differences between hit queries, queries within the spatiotemporal range, and queries outside the spatiotemporal range, we evaluated the optimization effects of local multi-level index trees and auxiliary vectors on data filtering and query efficiency. The specific experimental results are shown in Table 2 below:

[0293] Table 2 Comparison of response time of local multi-level index tree under different query conditions

[0294]

[0295] Table 2 shows the response time comparison of the local multi-level index tree under different query conditions. Among them, a hit query refers to the existence of an offset track that meets the query conditions in the multi-level index tree; a query within the time and space range refers to the time or space in the query condition being within the time and space range covered by the current index, but there is no offset track that meets the license plate number or route number in the multi-level index; a query outside the time and space range refers to the time or space of the query condition not belonging to the time and space range covered by the current index. These three different queries are widely representative and can fully verify the experimental effect of the present invention. The experimental results show that: when the hit query is executed multiple times, the average response time of each query is stable between 0.22 seconds and 0.28 seconds; when the query within the time and space range is executed multiple times, the average response time of each query is stable between 0.24 seconds and 0.27 seconds; when the query outside the time and space range is executed multiple times, the average response time of each query is stable between 0.041 milliseconds and 0.052 milliseconds.

[0296] The above experimental results show that the index structure proposed by the present invention has a high construction efficiency, and the construction time is stable at the second level. It also performs well in terms of query performance: for hit queries and queries within the time and space range, the system can achieve sub-second responses, and for queries outside the time and space range, the system can even achieve micromillisecond responses. The overall performance is far superior to existing methods. In particular, by comparing the response time under different query conditions, it can be seen that the auxiliary vector acceleration mechanism designed by the present invention significantly improves the query filtering efficiency and can achieve fast and efficient trajectory offset information retrieval. In addition, under query loads of different intensities, the system shows stable performance, which can meet the needs of fast and accurate retrieval of trajectory offset information in actual application scenarios.

[0297] The above describes the specific embodiments of the present invention in detail with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments. Various changes can be made within the knowledge of ordinary technicians in this field without departing from the scope of the present invention.

Claims

1. A bus trajectory offset storage and query method based on distributed memory index, characterized by: Step 1: Obtain all bus GPS trajectories in a certain city within a certain period of time, perform data preprocessing, perform GPS trajectory map matching, and divide bus itineraries; Step 2: Calculate the similarity between the actual GPS trajectory of each bus and the planned route, obtain the route deviation information of each bus, and form a bus route deviation information set; Step 3: Use longitude and latitude to divide the urban area into equal grids, calculate the grid number corresponding to each offset information, and form a global index by mapping the offset information to the grid number and time slice index; Step 4: Repartition and redirect the offset information, mapping the offset information to different nodes in the cluster according to the grid number; Step 5: Within each partition, the offset information is divided into multiple levels by date, route, and license plate number to form a tree structure. An auxiliary filtering vector is constructed within each level. The multi-level tree structure and the auxiliary vectors form a local index structure. Step 6: Submit the query information, which is any combination of date, license plate number, route number, longitude and latitude; Step 7: Calculate the intersection of the query information and the global index, determine the partitions involved in the query, and multicast the query conditions to the corresponding partitions; Step 8: After receiving the query conditions, each partition traverses the local index, uses auxiliary vectors to accelerate the query process, and saves the intermediate results involved in the query; Step 9: Aggregate the intermediate results involved in each partition to form the final query result, and return the final query result.

2. A bus trajectory offset storage and query method based on distributed memory index according to claim 1, characterized in that: The route deviation information refers to the situation where the bus does not follow the scheduled route. The longest common subsequence similarity is used to determine whether the bus has deviated from the route. The expression is: ； Where LCSlength is the length of the longest common subsequence LCS, LCSsimilarity is the similarity ratio between the two sequences, and the value is between 0 and 1, with a value of 1 indicating a perfect match and a value of 0 indicating no common subsequence, |GPSLength| is the length of the GPS track grid sequence after deduplication, and |StationLength| is the length of the station grid sequence. When it is less than the preset threshold, it is determined that the line is offset.

3. The bus track offset storage and query method based on distributed memory index according to claim 1 is characterized in that: The expression for calculating the grid number corresponding to each offset information is: ； Where gdf is the bus GPS data with longitude and latitude information, accuracy is the specified grid size for calculating the bus GPS data, and gridMath() is a custom function that takes gdf and accuracy as input and outputs the gridded GPS data gpsGrid.

4. The bus track offset storage and query method based on distributed memory index according to claim 1 is characterized in that: The Step 4 is specifically as follows: Step 4.1: Set the total number of grids × the number of time slices = the number of partitions. If the city area is divided into M grids, and the time span timeTotal can be divided into K time slices by ∆t, then the number of partitions = M × K. Step 4.2: Each global index (loncol, latcol, timeIndex) uniquely corresponds to a partition number, so that data is stored according to spatial location + time slice; Step 4.3: Map data to corresponding partitions based on the global index; Step 4.4: For a single GPS track point (t, lon, lat), calculate the spatial index and time index to determine the partition where the data is located, where t is an arbitrary time. represents the longitude of the trajectory point, Represents the latitude of the trajectory point; Step 4.5: Calculate the grid number and determine its spatial location; Step 4.6: Calculate the time index timeIndex and determine its time slice index. The expression is: ； Where, is the starting time of the study time range, ∆t represents the time slice; Step 4.7: Calculate the partition number and get the corresponding partition mapped to the point. The expression is: ； in, is the partition number, Represents the grid number corresponding to the longitude of the GPS point, Represents the grid number corresponding to the latitude of the GPS point.

5. The bus track offset storage and query method based on distributed memory index according to claim 1 is characterized in that: The expression of the local index structure is: gpsPartitionIndex = buildTree(partitionNmber,iterator); In the formula, partitionNmber represents the partition number where the data is located, iterator represents an iterator used to obtain all data rows in the partition, and buildTree() is a custom function that takes partitionNmber and iterator as input and outputs gpsPartitionIndex, where gpsPartitionIndex represents a local multi-level index tree.

6. The bus track offset storage and query method based on distributed memory index according to claim 1 is characterized in that: The Step 7 is specifically as follows: Step 7.1: Initialize an empty set partitionsQuery to store the partition numbers that meet the query conditions; Step 7.2: Define query conditions queryConditions = (date, linenumber, idx, lon, lat), where the date in the GPS trajectory data, the bus line number linenumber, and the license plate number idx, lon, and lat of each vehicle on the corresponding bus line can be arbitrarily given according to actual needs; Step 7.3: Based on the given date, calculate the time slice timeIndex to which the date belongs; Step 7.4: Based on the longitude and latitude (lon, lat), calculate the corresponding grid number (loncol, latcol); Step 7.5: Calculate the specific partition number partitionIndex based on the time slice timeIndex and the grid number (loncol, latcol); Step 7.6: Store partitionIndex into partitionsQuery; Step 7.7: Return the set of all partition numbers that meet the query conditions partitionsQuery; Step 7.8: Multicast the query conditions to the corresponding partitions.

7. The bus track offset storage and query method based on distributed memory index according to claim 1 is characterized in that: The Step 8 is specifically as follows: Construct a local index search function to query the trajectory of the corresponding conditions according to any combination of the specified date, route number, and license plate number. In the search process of each layer of the tree, the auxiliary vector value is judged to be 0 or 1 to accelerate the search process. The expression is: queryGpsResult = queryGpsData(tree, date=None, linenumber=None, idx=None) Where tree is the constructed local multi-level index tree structure of GPS data, queryGpsData() is a custom function that takes tree, date, linenumber, and idx as input and outputs the query result queryGpsResult; The default values ​​of the date, linenumber, and idx parameters are set to None. When performing a query, bus tracks that meet the corresponding conditions are searched based on any combination of the specified date, line number, and license plate number.

8. The bus track offset storage and query method based on distributed memory index according to claim 1 is characterized in that: The Step 9 is specifically as follows: Step 9.1: Initialize an empty list allResults to store the query results of each partition; Step 9.2: Determine whether the query condition provides the date and longitude and latitude; Step 9.3: If the date and longitude and latitude are given, directly determine the partitions involved in the query condition; Step 9.4: Execute the local index search function queryGpsData in the partitions involved; Step 9.5: If no date or longitude and latitude are given, execute the local index search function queryGpsData in all partitions; Step 9.6: Collect the query results allResults of all partitions into the driver program; Step 9.7: Determine whether there is data in the collected allResults. If there is no data, directly return "There is no data for this query"; Step 9.8: If there is data, initialize an empty list combinedResults to merge the query results of different partitions to obtain a specific trajectory; Step 9.9: Initialize the variable i, which is used to iterate over all the results allResults collected in Step 9.

5. The data structure is ({(date, linenumber, idx): ((lon, lat), (direction, journey))}), where direction represents the up and down directions of the bus, journey represents the specific itinerary of a bus on a certain day in the bus GPS data, date represents the date in the trajectory data, linenumber represents the bus line number, idx represents the license plate number of each vehicle on the corresponding bus line, and lon and la represent the latitude and longitude of the GPS data point. Step 9.10: If i <= len(allResults), go to Step 9.11; otherwise, go to Step 9.14; Step 9.11: If allResults contains a triple of date, linenumber, and idx, extract all points and merge the result lists in each partition into a total list. Generate a trajectory based on the total list, format the result into a string, and append it to combinedResults. Step 9.12: If allResults does not contain idx and only contains date and linenumber, merge all idx lists to get the traces of all idx, format the result into a string and append it to combinedResults; Step 9.13: Variable i is incremented by 1, i=i+1, pointing to the next partition query result allResults; Step 9.14: Return the final query result list combinedResults.

Images