A fast matching method for road networks based on location big data

Abstract

The present invention discloses a fast matching method for a road network oriented to location big data, and belongs to the technical field of traffic big data information analysis. The present invention first divides the road network data into a number of grid blocks, and performs geographic hash coding on the obtained grid blocks; then collects the position of the GNSS point corresponding to the floating mobile vehicle in the area within a historical moment, determines which grid block it is in by the latitude and longitude coordinates of the point, takes the grid block as the center block, and obtains its 8 neighborhood grid block files; then uses the location big data matching algorithm to calculate the matching degree of the floating mobile vehicle in the area within the historical moment collected and the road sections in the center block and 8 neighborhood grid blocks where it is located, and finds the road section ID value with the highest matching degree value as the final matching road section segID; finally calculates the point closest to the GNSS point to the final matching road section segID as the matching point position coordinates. The present invention can improve the matching efficiency of location big data compared with conventional matching methods.

Description

Technical Field

[0001] The present invention belongs to the technical field of traffic big data information analysis, and in particular relates to a fast matching method for road networks oriented to location big data. Background Art

[0002] Location big data refers to various positioning data obtained in real time from various location sources (such as GNSS, mobile devices, floating vehicles, etc.). The road network matching technology of location data is one of the key technologies in many fields such as traffic data analysis, vehicle navigation, intelligent transportation system (ITS), urban planning, logistics scheduling, etc. Due to various location errors between location big data and road networks, location big data and road networks cannot be matched one by one. Existing location data matching technologies include: geometric methods, topological methods, probabilistic methods, and artificial intelligence methods. These matching technologies focus on the matching algorithm itself and ignore the data organization and spatial index of the road network. They use the full road network traversal mode in the search of candidate road sections, which is inefficient and cannot meet the real-time location matching needs in the context of big data today. For example, the patent application with publication number CN114461942A and invention name "Floating vehicle trajectory data map matching method and system" calculates alternative points, performs topological processing on the local road network, calculates the shortest path distance, and searches for matching points near the shortest path distance. This method needs to search the adjacency matrix of the entire road network for the shortest path calculation, and has a large overhead in path calculation; the patent application with publication number CN112033418A and invention name "An offline map matching method" discusses how GPS points search for the driving path with the smallest total matching difference with mobile trajectory data in the global road network. Although it is not necessary to set multiple candidate matching positions for each GPS positioning point in this process, it is necessary to traverse the adjacency matrix of the entire road network when calculating the shortest path, and the amount of calculation in solving the shortest path is still large.

[0003] In recent years, with the explosive growth of location data and the rapid expansion of urban road network data, the matching efficiency of existing road network matching methods for location big data is difficult to meet the actual needs of large data volumes. Existing methods have improved in matching accuracy, but are still limited in matching efficiency by the amount of location data. Summary of the invention

[0004] The present invention proposes a fast matching method for a road network of location big data, aiming to solve the problems of retrieval and calculation efficiency in real-time matching of a road network of location big data.

[0005] The above purpose is achieved through the following technical solutions:

[0006] A fast matching method for a road network based on location big data, the method comprising the following steps:

[0007] S1. Segment the road network data. Input the road network layer and perform 2*2 equal-area grid segmentation on the road data in the area. Each road network data block is a grid block, also called Mesh. The data of each grid block is saved as a serialized file. Set the division level deg as the quadtree segmentation depth.

[0008] S2. GeoHash encoding: Perform geohash encoding on the grid blocks obtained in step S1, which is called GeoHash encoding;

[0009] S3. Collect the position of the GNSS point corresponding to the floating mobile vehicle in the area within a historical time period, determine the grid block in which the point is located by the latitude and longitude coordinates of the point, take the grid block as the center block, and obtain its 8-neighborhood grid block file;

[0010] S4. Using the location big data matching algorithm, calculate the matching degree between the floating mobile vehicle in the area and the road sections in the center block and 8 neighboring grid blocks in the historical moment collected in step S3, traverse the center block and 8 neighboring grid blocks where the GNSS point is located, and find the road section ID value with the highest matching value as the final matching road section segID;

[0011] S5. Calculate the point closest to the final matching road segment segID obtained in step S4 from the GNSS point as the matching point position coordinates.

[0012] Furthermore, the gridding segmentation of the road data in the area described in step S1 adopts a 2*2 equal area segmentation method, specifically, the longitude and latitude coordinates (L, B) of the center point of the binary block are found in the area, where L represents longitude and B represents latitude. Starting from level 0, the first level L is obtained according to the latitude range of the binary grid block in [Bmin, Bmax] and the longitude range in [Lmin, Lmax]. The latitude interval [Bmin, Bmax] is divided into two parts: [Bmin, 0] and [0, Bmax]. Obviously, the latitude B is in [0, Bmax] to obtain the result of the first binary division. Similarly, the binary division [0, Bmax] is continued: [0, Bmax / 2] and [Bmax / 2, Bmax]. B is in [0,Bmax / 2] to obtain the result of the second binary division. The binary division is continued until the current segmentation level reaches the quadtree segmentation depth deg described in step S1.

[0013] Furthermore, the quadtree partition depth deg is 6.

[0014] Furthermore, the GeoHash encoding in step S2 is encoded in the direction of the four Mesh sub-blocks after 2*2 equal area division, namely, the lower left lb, the upper left lt, the upper right rt, and the lower right rb. The two-dimensional grid is converted into an 8-neighborhood run sequence position code through a one-dimensional run coding; in this way, the latitude is divided into 2*2 to obtain a string of 0-1 codes, and the code generated by the latitude is 1011100011, and the longitude is also grouped in this way, and the code generated by the longitude is 11010 01011; then the even digits are placed in the longitude, and the odd digits are placed in the latitude, and the two strings of codes are combined to generate a new binary string: 11100 11101 00100 01111, where the even digits start from 0; and the generated new binary string is then base32 encoded in hexadecimal.

[0015] Furthermore, the location big data matching algorithm described in step S4 is specifically described as follows:

[0016] make represents the vehicle point on the electronic map obtained after coordinate conversion of a floating mobile vehicle at a certain time, then The matching degree with road R The calculation is as follows:

[0017] ,

[0018] in, The vehicle point and roads The distance between The normalized value of is calculated by the following formula:

[0019] ,

[0020] is the average error of GNSS;

[0021] is the angle between the vehicle point's driving direction and the road direction The normalized value of is calculated by the following formula:

[0022] ,

[0023] and They are and The weight value in the matching calculation satisfies .

[0024] Furthermore, if the current vehicle point is near a road intersection, the weights in the matching calculation are , Otherwise, the weights are , .

[0025] Furthermore, the step S5 calculates the point closest to the GNSS point to the final matching road segment segID obtained in step S4, specifically by:

[0026] Get the coordinate string of the geometric data of the final matching road segment segID , process each segment in the multi-segment segment one by one The starting vertex The coordinates of ,as well as The coordinates of , the floating car position coordinates are , calculate the following vector and vector :

[0027] ,

[0028] Calculate the discriminant parameter t:

[0029] ,

[0030] Determine whether the t value satisfies , if satisfied, then calculate the floating car position point The matching position coordinates on this road segment ( , )for:

[0031] ,

[0032] If not satisfied, calculate and judge the t value of the next section.

[0033] Compared with the prior art, the present invention has the following beneficial effects:

[0034] The present invention first divides the initial road network into multi-level quadtree meshes, and performs binary serialization and persistent storage on the road network mesh data. In the road network matching calculation, only the mesh sub-block and its neighborhood block data need to be searched, which reduces the search range of the road network data and improves the road network matching efficiency. Since the mesh sub-block file name is named with the GeoHash of the mesh data block, there is no need to traverse the file system when matching the location data with the mesh data block, saving the cost of searching the file. Compared with the existing matching technology, the present invention combines the spatial data organization and matching algorithm of the road network data, and optimizes the road network matching method of the location big data from the two aspects of efficiency and accuracy. Related experiments show that the present invention is tested on the road network in the main urban area of ​​Nanjing in an ordinary PC operating environment: the time for establishing a 6-level quadtree index is about 1 minute, and the fastest matching time for a single GNSS point after being segmented by a three-level quadtree is about 3 milliseconds. In a single CPU environment, it can meet the quasi-real-time matching of more than 3,000 mobile vehicles. During the implementation of the algorithm, CPU / GPU parallelization can be performed as required, and the computing efficiency can be upgraded to 10,000-level and 100,000-level position data units. The matching speed of the present invention is independent of the distribution range of the road network. Although the present invention experiment selects the GNSS position of a floating vehicle as the research object, the application prospects of the present invention include but are not limited to (GNSS, mobile devices, floating vehicles, etc.) and other fields. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 A flowchart of a method for fast matching of a road network for location big data according to the present invention;

[0036] Figure 2 It is a flowchart of quadtree partitioning and Geohash encoding;

[0037] Figure 3 It is a schematic diagram of road network data segmentation of the present invention;

[0038] Figure 4 All the location data before matching a certain test section period of the present invention;

[0039] Figure 5 yes Figure 4 The local view before the road network and location big data matching;

[0040] Figure 6 For Figure 5 The shown road segment is a local distribution map of the location big data after matching using the method of the present invention. DETAILED DESCRIPTION

[0041] The present invention will be further explained below in conjunction with the accompanying drawings and specific embodiments. It should be understood that the following specific embodiments are only used to illustrate the present invention and are not used to limit the scope of the present invention.

[0042] A fast matching method for a road network based on location big data in this embodiment includes the following steps:

[0043] S1. Segment the road network data, input the road network layer, and grid the road data in the area. Each road network data block is a grid block, and the data of each grid block is saved as a serialized file; the 2X segmentation method is used, specifically, the longitude and latitude coordinates (L, B) of the center point of the binary block are found in the area, where L represents longitude and B represents latitude. The encoding depth of the quadtree is determined according to the accuracy of the position data coordinates (L, B). Starting from level 0, the latitude range of the binary grid block is [B min , B max ], the longitude range is [L min , L max ] to obtain the first level L, for the latitude interval [B min , B max ]Two points: [B min ,0]、[0, B max ], it is clear that latitude B is between [0, B max ] Get the result of the first binary division, and continue the binary division [0, B max ]:[0,B max / 2] and [B max / 2, B max ], B is in [0, B max / 2], and get the second binary result. With continuous binary division, B always belongs to a certain interval [a,b]. With each iteration, the interval [a,b] is always shrinking and getting closer and closer to B. The number of binary divisions represents the depth of the quadtree, deg, which is 4 by default.

[0044] S2. GeoHash encoding: The mesh blocks obtained in step S1 are encoded in the one-dimensional direction of lower left lb, upper left lt, upper right rt, and lower right rb. The corresponding mesh blocks are Mesh0, Mesh1, Mesh2, and Mesh3 ( Figure 2 As shown in the figure, the grid blocks are saved in sequence as corresponding serialized files GeoHash file 0, GeoHash file 1, GeoHash file 2, and GeoHash file 3. The serialized file names are encoded using geographic hash coding, called GeoHash coding, and are encoded according to the following rules based on the segmentation depth:

[0045] Take the segmentation depth deg=2 as an example: the two-dimensional grid blocks are divided into the lower left (00), upper left (01), upper right (10), and lower right (11) directions according to their positions before segmentation. Figure 3As shown, Mesh0, Mesh1, Mesh2, Mesh3 represent grid blocks, R1, R2, R3 represent sections of different levels) are encoded; in this way, the latitude is divided into two parts, and a string of 0-1 codes can be obtained. The code generated by the latitude of the center point of the grid is 10111 00011, and the code generated by the longitude of the center point of the grid is 1101001011. Through the cross-joining of odd and even numbers, that is, the longitude is placed in the even position and the latitude is placed in the odd position, the two strings of codes are combined to generate a new string: 11100 11101 00100 01111, where the even number starts from 0. Base32 encoding of hexadecimal encoding of binary strings: In this embodiment, 32 letters 0-9, bz (remove a, i, l, o) are used for encoding. First, the 0-1 binary code string is converted into a hexadecimal code string.

[0046] S3. Collect the position of the GNSS point corresponding to the floating mobile vehicle in the area within a historical moment, determine the grid block it is in based on the latitude and longitude coordinates of the point, take the grid block as the center block C0, obtain its 8 neighboring grid block file names N1, N2, N3, N4, N5, N6, N7, N8 and load 9 road network files from the road network folder.

[0047] S4. Using the location big data matching algorithm, calculate the matching degree between the floating mobile vehicle in the area and the road sections in the central block and the 8 neighboring grid blocks in the historical moments collected in step S3, let represents the vehicle point on the electronic map obtained after coordinate conversion of a floating mobile vehicle at a certain time, then The matching degree with road R The calculation is as follows:

[0048] ,

[0049] in, The vehicle point and roads The distance between The normalized value of is calculated by the following formula:

[0050] ,

[0051] is the average error of GNSS (usually 10-15 meters);

[0052] is the angle between the vehicle point's driving direction and the road direction The normalized value of is calculated by the following formula:

[0053] ,

[0054] and They are and The weight value in the matching calculation satisfies If the current vehicle point is near a road intersection, the weights in the matching calculation are , Otherwise, the weights are , .

[0055] S5. Calculate the point closest to the GNSS point to the final matching road segment segID obtained in step S4 as the matching point position coordinates. The specific method is:

[0056] Get the coordinate string of the geometric data of the final matching road segment segID , process each segment in the multi-segment segment one by one The starting vertex The coordinates of ,as well as The coordinates of , the floating car position coordinates are , calculate the following vector and vector :

[0057] ,

[0058] Calculate the discriminant parameter t:

[0059] ,

[0060] Determine whether the t value satisfies , if satisfied, then calculate the floating car position point The matching position coordinates on this road segment ( , )for:

[0061] ,

[0062] If not satisfied, calculate and judge the t value of the next section.

[0063] The above calculation process is transformed into a CPU parallel calculation mode as follows:

[0064] 1.1.1. Created 9 tasks: taskC0, taskN1, taskN2, taskN3, taskN4, taskN5, taskN6, taskN7, and taskN8.

[0065] 1.1.2. Use Task Parallel Library (TPL) to call the 9 tasks of 1.1.1 respectively, calculate the matching degree and matching point of the 9 tasks, compare the matching degree of the 9 results, and obtain the best matching degree segID and matching point position.

[0066] 1.1.3. Output the results, update the matching data layer, and release resources.

[0067] The above calculation process is transformed into GPU parallel computing mode as follows:

[0068] 2.1.1. Create 9 vectors hostC0, hostN1, hostN2, hostN3, hostN4, hostN5, hostN6, hostN7, and hostN8.

[0069] 2.1.2. Use Managed CUDA to copy the 9 vectors from 3.2.1.1 to GPU memory.

[0070] 2.1.3. Use the Axpy function of the Cuda Blas library to perform vector matching and matching point calculations, and copy the results from the GPU back to the host's memory.

[0071] 2.1.4. Compare the matching degrees of the 9 results and obtain the best matching degree segID and matching point position.

[0072] 2.1.5. Output the results, update the matching data layer, and release resources.

[0073] In this embodiment, in the Microsoft Visual Studio 2017 environment, based on the GIS development component ArcEngine10.1, the location big data of taxis in Nanjing in a certain year is tested and analyzed, and a road network spatial database based on GeoHash is established to verify the effectiveness of the results of the present invention.

[0074] In terms of coordinate system, since most of the location big data uses the WGS-84 coordinate system, and the current domestic basic road network basically uses the CGC2000 coordinate system. In order to accurately match the location point data on the road network, the location data must be transformed. The steps of coordinate system conversion are as follows:

[0075] ⑴ Use ArcToolbox to import location big data, set WGS-84 coordinate system parameters, and parse geocentric rectangular coordinates ;

[0076] ⑵ The geocentric rectangular coordinates of the location big data Convert to CGC2000 rectangular coordinates ;

[0077] ⑶ Using CGC2000 rectangular coordinates Calculate the CGC2000 geodetic coordinates;

[0078] ⑷ Convert the CGC geodetic coordinates into the Gauss-Krüger projection so that it matches the coordinate system of the geographic data.

[0079] In terms of data management, in order to better store road network data, an ESRI GDB database is established, and the data table is designed as follows:

[0080] The road network Mesh sub-block information table includes the Mesh rectangle position, Mesh level depth, and GeoHash code, as shown in Table 1:

[0081] Table 1 Road network Mesh sub-block information table

[0082] Fields type length unit illustrate oID Long 4 Keywords shape Polygon Mesh vertices make up the face deg Short 2 Tiers geoHash String 255 Geohash encoding area Double 8(Precision) 2(Scale) <![CDATA[m 2 > Mesh Area

[0083] The location data table is location big data, which is input data and includes location coordinates, timestamp, instantaneous motion direction and other information, as shown in Table 2:

[0084] Table 2 Position data table

[0085] Fields type length unit illustrate oID Long 4 Keywords shape Point Location data points segID Long 4 Section number curTime Date Second Current timestamp avgSpeed Float 20 km / h Movement Speed direction String 60 Direction of movement

[0086] When designing the database table, the present invention also stores the adjacency topology of the road network as common attribute information in the attribute table, as shown in Table 3:

[0087] Table 3 Road section table

[0088] Fields type length illustrate oID Long 4 Keywords shape Line segID Long 4 Section number segName String 30 road name fromNodeID Short 4 Starting node number toNodeID Short 4 End node number preSegID Short 4 Previous section number nextSegID Short 4 The next section number

[0089] When querying a path, the adjacency topology information can be directly read from the attribute table, which speeds up the program's operation. In order to meet the needs of storing the location data processing results, the present invention designs a matching table for storing the location data network matching results (matching point coordinates, matching road sections, and road network sub-blocks), as shown in Table 4:

[0090] Table 4 Matching table

[0091] Fields type length unit illustrate oID Long 4 Keywords ptID Long 4 Position data number segID Long 4 Location data matches the road segment number meshID Long 4 Road network sub-block number mScore Double 8(Precision) 2(Scale) Match shape Point Location data matching points

[0092] Test data: All location data of Nanjing taxis during a certain period of time ( Figure 3 ), Figure 4 yes Figure 3 A partial enlarged view of Figure 5The distribution diagram of vehicle points after map matching is shown in Figure 1. They are all screenshots of partial data. Before map matching, the vehicle points deviated from the road section they traveled due to various errors. After matching using the method proposed by the present invention, the vehicle points were matched to the road section they traveled.

[0093] Matching speed test: Therefore, the algorithm's computational efficiency is an important indicator for evaluating the algorithm's performance. The experiment shows that under the existing common PC computer conditions: CPU Intel Core i7-980X\GPU Nvidia GeoForce 4060Ti hardware platform, the single point time period location big data matching takes 3 milliseconds.

Claims

1. A fast matching method for road networks based on location big data, characterized in that: The method comprises the following steps: S1. Segment the road network data, input the road network layer, and perform 2*2 equal-area grid segmentation on the road data in the area. Each road network data block is a grid block, also called Mesh. The data of each grid block is saved as a serialized file, and the division level deg is set as the quadtree segmentation depth; S2. GeoHash encoding: Perform geohash encoding on the grid blocks obtained in step S1, which is called GeoHash encoding; S3. Collect the position of the GNSS point corresponding to the floating mobile vehicle in the area within a historical time period, determine the grid block in which the point is located by the latitude and longitude coordinates of the point, take the grid block as the center block, and obtain its 8-neighborhood grid block file; S4. Using the location big data matching algorithm, calculate the matching degree between the floating mobile vehicle in the area and the road sections in the center block and 8 neighboring grid blocks in the historical moment collected in step S3, traverse the center block and 8 neighboring grid blocks where the GNSS point is located, and find the road section ID value with the highest matching value as the final matching road section segID; S5. Calculate the point closest to the final matching segment segID obtained from the GNSS point in step S4 as the position coordinates of the matching point; The location big data matching algorithm described in step S4 is specifically as follows: Let P(t) represent the vehicle point on the electronic map obtained after coordinate conversion of a floating mobile vehicle at a certain time, then the matching degree δ(P(t), R) between P(t) and road R is calculated as follows: in, It refers to the normalized value of the distance d between the vehicle point P(t) and the road R, which is calculated by the following formula: Δ GNSS is the average error of GNSS; It is the normalized value of the angle θ between the vehicle point's driving direction and the road direction, and is calculated using the following formula: ω d and ω θ They are and The weight value in the matching calculation satisfies ω d +ω θ =1.

2. The method for fast matching of road networks for location big data according to claim 1, characterized in that: The gridding segmentation of the road data in the area described in step S1 adopts a 2*2 equal area segmentation method, specifically, the longitude and latitude coordinates (L, B) of the center point of the binary block are found in the area, where L represents longitude and B represents latitude. Starting from level 0, the first level L is obtained according to the latitude range of the binary grid block in [Bmin, Bmax] and the longitude range in [Lmin, Lmax]. The latitude interval [Bmin, Bmax] is divided into two parts: [Bmin, 0] and [0, Bmax]. Obviously, the latitude B is in [0, Bmax] to obtain the result of the first binary division. Similarly, the binary division [0, Bmax] is continued: [0, Bmax / 2] and [Bmax / 2, Bmax]. B is in [0, Bmax / 2] to obtain the result of the second binary division. The binary division is continued until the current segmentation level reaches the quadtree segmentation depth deg described in step S1.

3. A fast matching method for road networks based on location big data according to claim 1 or 2, characterized in that: The quadtree partition depth deg is 6.

4. A fast matching method for road networks based on location big data according to claim 1 or 2, characterized in that: The GeoHash encoding described in step S2 is encoded in the direction of the four Mesh sub-blocks after 2*2 equal area division, namely, the lower left lb, the upper left lt, the upper right rt, and the lower right rb. The two-dimensional grid is converted into an 8-neighborhood run sequence position code through a one-dimensional run coding; in this way, the latitude is divided into 2*2 to obtain a string of 0-1 codes, and the code generated by the latitude is 10111 00011, and the longitude is also grouped in this way, and the code generated by the longitude is 11010 01011; then the even digits are placed in the longitude, and the odd digits are placed in the latitude, and the two strings of codes are combined to generate a new binary string: 11100 11101 00100 01111, where the even digits start from 0; and the generated new binary string is then base32 encoded in hexadecimal.

5. The method for fast matching of road networks for location big data according to claim 1, characterized in that: If the current vehicle point is near a road intersection, the weights in the matching calculation are ω d =0.4,ω θ =0.6; otherwise, the weights are taken as ω d =0.6,ω θ =0.

4.

6. The method for fast matching of road networks for location big data according to claim 1, characterized in that: The specific method of calculating the closest point of the GNSS point to the final matching road segment segID obtained in step S4 is: Get the coordinate string V1(x1,y1),V2(x2,y2),…,V of the geometric data of the final matching road segment segID n (x n ,y n ), process each segment L in the multi-segment segment by segment i The starting vertex V i The coordinates (x i ,y i ), and V i+1 The coordinates (x i+1 ,y i+1 ), the floating car position is F(x F ,y F ), calculate the following vector A and vector B: Calculate the discriminant parameter t: Determine whether the t value satisfies 0≤t≤1. If so, calculate the floating car position F(x F ,y F ) on the road segment’s matching position coordinates (x m ,y m )for: If not satisfied, calculate and judge the t value of the next section.

Images