Road network data construction method, query method, system and server
By creating a composite index structure and performing road matching and merging operations, the redundancy and error problems of open street map data are solved, high-precision road network data construction is achieved, data processing efficiency and accuracy are improved, and it is suitable for intelligent transportation scenario analysis.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-27
- Publication Date
- 2026-04-07
AI Technical Summary
Existing methods for constructing road network data rely on unprocessed open street map data, resulting in inaccurate output data that cannot meet the needs of high-precision applications.
By acquiring open street map data and vehicle trajectory data, a composite index structure is created, nearest neighbor road matching and merging operations are performed, GIST and BRIN indexes are used to improve data processing efficiency, and smoothing and filtering are performed to ensure data accuracy.
The output road network data achieved an accuracy rate of over 90% in manual sampling, meeting high-precision standards, providing a reliable map semantic foundation for intelligent traffic scenario analysis, and improving data processing efficiency.
Smart Images

Figure CN121807981A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of assisted driving, in particular to a road network data construction method, a query method, a system and a server. BACKGROUND
[0002] In intelligent driving technology, vehicle trajectory data is matched with map data to obtain road network data, which can improve the value of original trajectory data. However, existing methods usually rely on original and unprocessed open street map data, which may include duplicate data, error data and the like, so that the final output road network data is extremely inaccurate and cannot meet the needs of high-precision applications. SUMMARY
[0003] To solve the above technical problems, the present application provides a road network data construction method, a query method, a system and a server.
[0004] Specifically, the present application provides a road network data construction method, comprising the following steps: obtaining a plurality of open street map data and vehicle trajectory data, and creating a composite index structure based on the open street map data; based on the composite index structure, and according to the open street map data and the vehicle trajectory data, performing nearest neighbor road matching to perform road merging operation based on the matching result; and based on the merging result, obtaining road network data and writing it into a database.
[0005] In the above technical solution, through the process of adjacent merging, the inherent redundancy and error of original OSM data are effectively solved, and the output road network data is more accurate to meet the high-precision standard and provide a highly reliable map semantic basis for downstream intelligent traffic scene analysis. The accuracy of the obtained road network data can stably reach more than 90% in manual sampling. In addition, the construction of the composite index structure can also improve the data processing efficiency.
[0006] Further, after obtaining the open street map data, the method further comprises: importing the open street map data into a database, wherein the open street map data at least includes a map ID, geometric information, an attribute set and road network data.
[0007] In the above technical solution, the open street map (OSM) data provides basic road network information, which lays a foundation for the construction of subsequent road network data.
[0008] Further, the method of creating a composite index structure based on the open street map comprises: establishing a general search tree index based on the geometric information; obtaining a data import timestamp of the open street map data imported into the database, and establishing a block range index based on the map ID and the data import timestamp.
[0009] In the above technical solution, the GIST index (general search tree index) is suitable for processing spatial data and can efficiently process queries of geometric information. In road network construction, it can quickly locate roads similar to vehicle trajectories and improve the efficiency of nearest road matching. The BRIN index (block range index) reduces the number of data blocks that need to be scanned by storing metadata information of data blocks. By using map ID and data import timestamp to establish a BRIN index, data in a specific map and time range can be quickly filtered out, further improving the efficiency of data query and processing.
[0010] Further, based on the composite index structure and according to the open street map data and the vehicle trajectory data, the nearest road matching is performed, including: dividing the vehicle trajectory data into multiple data partitions; based on the composite index structure, obtaining road network data corresponding to the data partitions from the open street map data and performing nearest road matching; when the matching is successful, based on the composite index structure, obtaining the map ID, attribute set and geometric information corresponding to the currently matched road network data from the open street map data, to associate the map ID, attribute set and geometric information with the road ID of the currently matched data partition as the matching result.
[0011] In the above technical solution, dividing the vehicle trajectory data into multiple data partitions can reduce the amount of data that needs to be processed each time, improving matching efficiency; road network data corresponding to the data partitions can be quickly obtained from the open street map data and nearest road matching can be performed.
[0012] Further, based on the matching result, a road merging operation is performed, including: based on the geometric information in the matching result, filtering out road network data with a geometric distance within a set threshold and merging; at the same time, verifying whether the attribute set of the merged road network data is consistent, if consistent, taking the currently merged road network data as the merging result; otherwise, performing smoothing processing on the road network data to obtain the smoothed road network data as the merging result.
[0013] In the above technical solution, by filtering and merging road network data with a geometric distance within a set threshold, the problem of redundancy and error in the original OSM data can be effectively solved, making the road network more concise and accurate; and when the attributes are inconsistent, smoothing processing is performed, ensuring that the merged road network data has high quality in both geometry and attributes.
[0014] Further, based on the merging result, road network data is obtained, including: filtering the merging result based on a pre-set filter rule library to obtain road network data based on the filtering result.
[0015] In the above technical solution, the preset filtering rule base can filter the merged results according to actual needs, remove road data that does not meet the requirements, and further improve the accuracy and quality of road network data.
[0016] Furthermore, after writing the road network data into the database, the method also includes: recreating the composite index structure based on the road network data.
[0017] In the above technical solution, recreating the composite index structure based on the new road network data can ensure that the database can maintain high performance in subsequent queries and analyses.
[0018] Based on the same concept, this application also provides a road network data query method, wherein a database including road network data is pre-deployed on a server, the database being constructed using the road network data construction method, and the server being configured with a single-point query interface and a batch query interface; the road network data query method includes: based on a composite index structure, calling the single-point query interface to obtain road network data corresponding to the currently queried map ID, or calling the batch query interface to obtain road network data corresponding to the currently queried list of road IDs; and displaying the road network data.
[0019] The above technical solution can provide millisecond-level standardization and data query services, enabling the processed high-quality road network data to be easily integrated into a larger data mining platform for stable and efficient use and reuse by other modules (such as scene understanding, behavior analysis, and high-precision map construction), thereby improving the technical synergy and output value of the entire platform. Furthermore, based on a composite index structure, it enables efficient spatial queries, completely changing the bottleneck mode of traditional single-point serial queries and perfectly meeting the stringent requirements of the intelligent driving field for large-scale data processing efficiency.
[0020] Based on the same concept, this application also provides a road network data query system, including: a query module, used to call a single-point query interface based on a composite index structure to obtain road network data corresponding to the currently queried map ID, or call a batch query interface to obtain road network data corresponding to the currently queried list of road IDs; and a display module, used to display the road network data.
[0021] The above technical solution provides users with an integrated solution for querying and displaying complete road network data, and provides strong support for various applications in the field of intelligent transportation.
[0022] Based on the same concept, this application also provides a server, which is equipped with a road network data query system and a database including road network data, to obtain road network data using the road network data query method.
[0023] Compared with the prior art, the advantages of this application are as follows: This application effectively solves the inherent redundancy and error problems of raw open street map data through processes such as neighbor merging, thereby making the output road network data more accurate to meet high precision standards and providing a highly reliable map semantic foundation for downstream intelligent transportation scenario analysis. Attached Figure Description
[0024] Figure 1 This is a flowchart of the road network data construction method described in this application.
[0025] Figure 2 This is a flowchart of the road network data query method described in this application.
[0026] Figure 3 This is a framework diagram of the road network data query system described in this application.
[0027] Figure 4 This is a framework diagram of the server described in this application. Detailed Implementation
[0028] The following describes in further detail a road network data construction method, query method, system, and server of this application with reference to specific embodiments and accompanying drawings.
[0029] Please see Figure 1 This application provides a method for constructing road network data, including the following steps S100-S300.
[0030] In one feasible implementation, the specific process is as follows: First, acquire the latest OSM nationwide PBF (Protocolbuffer Binary Format, a highly efficient compression format) data. Next, import this data in batches into the database, simultaneously creating a composite index structure consisting of a GIST spatial index and a BRIN temporal index. Then, start a distributed computing cluster, read the vehicle GPS trajectory data stored in HDFS or the database in RDD or DataFrame format, and utilize the parallel calls to Python's osmnx and shapely library functions on each computing node to execute a nearest neighbor road matching algorithm for each trajectory point. This associates the successfully matched road ID, attribute set, and geometric information with the map ID, and then outputs the results to intermediate storage. Subsequently, spatial functions are used to merge road segments that meet proximity conditions and have consistent attributes. Network analysis tools or custom SQL scripts are called to detect and repair topological errors (such as dangling nodes). SQL scripts or applications are written based on a rule base to perform batch consistency checks and cleaning of road attributes, removing invalid data. Finally, the clean, non-redundant, and topologically consistent road network data obtained after post-processing is written into a new table in the database. A GIST + BRIN composite index is also created for the new table to ensure high query performance.
[0031] The specific implementation methods of steps S100-S300 will be described in detail below.
[0032] Step S100: Obtain several open street map data and vehicle trajectory data, and create a composite index structure based on the open street map data.
[0033] The process includes, after obtaining the open street map data, importing the open street map data into a database, wherein the open street map includes at least map ID, geometric information, attribute set and road network data.
[0034] In some embodiments, preferably, the open-source relational database PostgreSQL is selected as the storage engine, and its core spatial extension PostGIS is loaded; wherein, PostGIS provides PostgreSQL with complete spatial data types (such as POINT, LINESTRING), spatial functions (such as distance calculation, geometric merging) and spatial index support, which is an ideal foundation for processing OSM road network data.
[0035] It should be noted that PostgreSQL / PostGIS can be replaced by other relational databases that support spatial queries (such as MySQL with Spatial Extensions) or proprietary spatial databases (such as Oracle Spatial), but PostGIS has advantages in terms of open-source ecosystem and richness of spatial functions.
[0036] Furthermore, the latest national open street map data is obtained from official channels and compressed in PBF format. The open street map data is then imported into the PostgreSQL database using a dedicated tool (such as osm2pgsql). After importation, the data is stored in a table named planet_osm_lines or similar. The table structure should include at least the following fields: osm_id (map ID, i.e., unique road identifier), way / geometry (geometric information, LineString type), tags (attribute set, JSON or HStore type), and name (road network data name).
[0037] For example, the OpenStreetMap (OSM) is a global, free, and open-source map database based on a crowdsourcing model, which contains rich road network information.
[0038] In the above technical solution, open street map data provides basic road network information, laying the foundation for the construction of subsequent road network data.
[0039] Furthermore, the creation of a composite index structure based on the open street map includes: establishing a general search tree index based on the geometric information; obtaining the data import timestamp of the open street map data imported into the database; and establishing a block range index based on the map ID and the data import timestamp.
[0040] In some embodiments, the search tree index query optimization formula is: ;in, For querying the set, For spatial data range, Representing the area function Represents the perimeter function, To adjust the parameters.
[0041] GIST index search complexity: ;in, For the branching factor of the tree, For the total amount of data, This represents the number of results to return.
[0042] Furthermore, a block range index does not record pointers to individual data entries, but rather records a range summary of data blocks. It occupies very little space and is extremely efficient for large-scale batch imports of data inserted in chronological order and queries based on time ranges, making it ideal for processing time-series data such as trajectory data. The BRIN index efficiency formula is... ;in, For the number of related data blocks, This represents the total number of data blocks. This represents the scan time.
[0043] In the above technical solutions, the GIST index (General Search Tree Index) is suitable for processing spatial data and can efficiently process geometric information queries. In road network construction, it can quickly locate roads close to vehicle trajectories, improve the efficiency of nearest neighbor road matching, and solve the performance bottleneck of a large number of random "point queries" (i.e., matching of a single trajectory point). The BRIN index (Block Range Index) reduces the number of data blocks that need to be scanned by storing metadata information of data blocks. By using map IDs and data import timestamps to build BRIN indexes, data within specific maps and time ranges can be quickly filtered out, further improving the efficiency of data query and processing. The composite index structure built by combining the two enables fast spatial matching for massive trajectory points and road network construction.
[0044] Step S200: Based on the composite index structure, and according to the open street map data and the vehicle trajectory data, perform nearest neighbor road matching, and perform road merging operation based on the matching result.
[0045] The step of performing nearest-neighbor road matching based on the composite index structure and the open street map data and the vehicle trajectory data includes: dividing the vehicle trajectory data into multiple data partitions; obtaining the road network data corresponding to the data partitions from the open street map data based on the composite index structure, and performing nearest-neighbor road matching; when a match is successful, obtaining the map ID, attribute set, and geometric information corresponding to the currently matched road network data from the open street map data based on the composite index structure, and associating the map ID, attribute set, and geometric information with the road ID of the currently matched data partition as the matching result.
[0046] In some embodiments, preferably, Apache Spark is used as the distributed computing engine. Its Resilient Distributed Dataset (RDD) architecture divides massive amounts of vehicle GPS trajectory data (i.e., the vehicle trajectory data) into multiple partitions and distributes them to multiple computing nodes in the cluster for parallel processing. The trajectory data stored in HDFS or a database is read into the Spark cluster as an RDD or DataFrame, and Spark's higher-order functions, such as mapPartitions or foreachPartition, are used to push the computation logic to the nodes where each data partition is located for parallel execution.
[0047] It should be noted that Apache Spark can be replaced by other distributed computing systems such as Flink for parallel processing, but their programming models and APIs will differ, and those skilled in the art can choose for themselves.
[0048] Specifically, for example, on each computing node, the osmnx library is called to obtain open street map data for a specified area for each vehicle trajectory data. At the same time, the nearest_points, distance and other functions of the shapely library are called to accurately calculate the spatial distance between the trajectory point and all candidate roads, find the nearest road segment, and complete the spatial matching calculation.
[0049] It should be noted that the osmnx library is a network analysis tool specifically designed for open street map data, capable of efficiently acquiring road network data from local or online sources. While osmnx and shapely can be replaced by API combinations of other open-source GIS libraries (such as GEOS and JTS), osmnx provides a higher-level encapsulation for OSM, simplifying development.
[0050] Among them, the nearest neighbor road matching is performed, and the calculation formula is as follows: ;in, For Euclidean distance The angle between directions, For weighting coefficient constraints, , trajectory points Cartesian coordinates in the plane , Road section The Cartesian coordinates of a reference point (such as the start, end, or midpoint of a road segment). trajectory points The direction vector of motion, Road section The direction vector.
[0051] Furthermore, when a match is successful, all attributes (such as highway: motorway, maxspeed: 120, lanes: 3, etc.) and their complete geometric information are extracted from the tags field of the open street map data. The map ID, attribute set, and geometric information are then associated with the road ID of the currently matched data partition and output to form a complete trajectory-road matching result.
[0052] In the above technical solution, dividing vehicle trajectory data into multiple data partitions can reduce the amount of data that needs to be processed each time and improve matching efficiency; it can quickly obtain the road network data corresponding to the data partition from open street map data and perform nearest neighbor matching.
[0053] Furthermore, the road merging operation based on the matching results includes: filtering out road network data whose geometric distance is within a set threshold based on the geometric information in the matching results and merging them; at the same time, verifying whether the attribute sets of the merged road network data are consistent. If they are consistent, the currently merged road network data is taken as the merging result; otherwise, the road network data is smoothed and the smoothed road network data is taken as the merging result.
[0054] In some embodiments, based on the rule that "geometric information is similar and attribute sets are consistent, then the same object is considered", road segments with geometric distances within a set threshold are filtered out using, for example, the PostGIS function ST_DWithin. These road segments are then collected using ST_Collect and merged using ST_LineMerge, thus completing the road merging operation. The set threshold can be adjusted and replaced by those skilled in the art according to actual data conditions and accuracy requirements.
[0055] Simultaneously, verifying the consistency of key attributes effectively eliminates data redundancy, merging duplicate road segments generated by crowdsourced editing into a single line, significantly simplifying the road network structure; the road merging decision function is... ;in, Geometric distance For attribute similarity, For topological connectivity, The i-th road segment to be merged and the j-th road segment to be merged For weighting coefficient constraints, This is a parameter for adjusting the geometric distance threshold. Road section and The value of the k-th attribute item, Road section and Geometric information, This represents the total number of categories of road segment attributes.
[0056] For different road segments belonging to the same logical road, the values of their key attributes are checked for conflicts. For example, SQL scripts are written to perform logical judgments based on a rule base. Outliers are smoothed using the mode of preceding and following road segments or interpolation, resolving attribute conflicts and missing values, and significantly improving the reliability and consistency of road semantic information. The attribute consistency index is... , For adjacent road segments, These are the weighting coefficients.
[0057] It should be noted that, based on graph theory principles, the road network is viewed as a graph structure, with road segments as edges and road intersections as nodes. The connectivity of nodes is analyzed using libraries such as pgRouting or custom SQL scripts. Dangling nodes with a connectivity of 1 represent topological errors, and these errors are automatically corrected by algorithms to ensure that the generated road network is logically connected in terms of topology, conforming to the physical connectivity of the real world.
[0058] In the above technical solution, by merging road network data whose geometric distance is within a set threshold, the redundancy and error problems existing in the original OSM data can be effectively solved, making the road network more concise and accurate; while smoothing processing when attributes are inconsistent ensures that the merged road network data has high quality in both geometry and attributes.
[0059] Step S300: Obtain road network data based on the merging results and write it into the database.
[0060] The step of obtaining road network data based on the merging result includes: filtering the merging result based on a preset filtering rule base to obtain road network data based on the filtering result.
[0061] In some embodiments, based on a preset filtering rule base, obviously invalid data is identified and removed, including cases where the road length is too short, isolated road segments, and attribute values are obviously incorrect; for example, batch cleaning is performed using SQL DELETE statements to purify the data, improve the quality and credibility of the overall dataset, and output a high-quality, non-redundant, topologically correct, and attribute-consistent road network layer.
[0062] In the above technical solution, the preset filtering rule base can filter the merged results according to actual needs, remove road data that does not meet the requirements, and further improve the accuracy and quality of road network data.
[0063] Furthermore, after writing the road network data into the database, the method also includes: recreating the composite index structure based on the road network data.
[0064] In some embodiments, the clean, non-redundant, and topologically consistent road network data obtained from post-processing is written into a new table in a database such as PostGIS, and a GIST+BRIN composite index is also created for the new table to ensure efficient query performance.
[0065] In the above technical solution, recreating the composite index structure based on the new road network data can ensure that the database can maintain high performance in subsequent queries and analyses.
[0066] In summary, the road network data construction method described in this application effectively solves the inherent redundancy and error problems of the original OSM data through processes such as proximity merging, thereby making the output road network data more accurate, meeting high-precision standards, and providing a highly reliable map semantic foundation for downstream intelligent transportation scenario analysis. Furthermore, the accuracy of the obtained road network data can consistently reach over 90% in manual sampling. In addition, constructing a composite index structure can further improve data processing efficiency.
[0067] Based on the same concept, please refer to Figure 2 This application also provides a method for querying road network data, wherein a database including road network data is pre-deployed on a server, the database being constructed using the road network data construction method, and the server being configured with a single-point query interface and a batch query interface; the road network data query method includes: based on a composite index structure, calling the single-point query interface to obtain road network data corresponding to the currently queried map ID, or calling the batch query interface to obtain road network data corresponding to the currently queried list of road IDs; and displaying the road network data.
[0068] In some embodiments, the core API logic is written using the lightweight Python Flask web framework. During service deployment, Gunicorn is used as a WSGI HTTP server to handle multiple concurrent requests, and Nginx is used as a reverse proxy and load balancer to handle static files and improve overall performance, thus building a highly available, low-latency service architecture. Internally, the API service connects to a PostgreSQL / PostGIS database via a Psycopg2 database adapter to execute efficient spatial SQL queries. By optimizing query statements and utilizing database indexes, millisecond-level query responses are achieved, with a QPS exceeding 300, providing stable and reliable data service support to downstream systems.
[0069] It should be noted that the single-point query interface receives latitude and longitude parameters and returns detailed information about the road where the point is located, while the batch query interface receives a list of trajectory points and returns matching information for each point.
[0070] In other embodiments, an interface for querying the complete attributes and geometric information of a specific road based on a map ID is also included to meet the data query needs of different scenarios.
[0071] The above technical solution can provide millisecond-level standardization and data query services, enabling the processed high-quality road network data to be easily integrated into a larger data mining platform for stable and efficient use and reuse by other modules (such as scene understanding, behavior analysis, and high-precision map construction), thereby improving the technical synergy and output value of the entire platform. Furthermore, based on a composite index structure, it enables efficient spatial queries, completely changing the bottleneck mode of traditional single-point serial queries and perfectly meeting the stringent requirements of the intelligent driving field for large-scale data processing efficiency.
[0072] Based on the same concept, please refer to Figure 3 This application also provides a road network data query system, including: a query module, used to call a single-point query interface based on a composite index structure to obtain road network data corresponding to the currently queried map ID, or call a batch query interface to obtain road network data corresponding to the currently queried road ID list; and a display module, used to display the road network data.
[0073] The above technical solution provides users with an integrated solution for querying and displaying complete road network data, and provides strong support for various applications in the field of intelligent transportation.
[0074] Based on the same concept, please refer to Figure 4 This application also provides a server, which is equipped with a road network data query system and a database including road network data, to obtain road network data using the road network data query method.
[0075] Although exemplary embodiments have been described herein with reference to the accompanying drawings, it should be understood that the above exemplary embodiments are merely illustrative and are not intended to limit the scope of this application. Various changes and modifications can be made therein by those skilled in the art without departing from the scope and spirit of this application. All such changes and modifications are intended to be included within the scope of this application as claimed in the appended claims.
[0076] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0077] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed.
[0078] The various component embodiments of this application can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some modules according to the embodiments of this application. This application can also be implemented as an apparatus program (e.g., a computer program and computer program product) for performing part or all of the methods described herein. Such an implementation of this application can be stored on a computer-readable medium, or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.
[0079] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0080] Although the description of this application has been made in conjunction with the specific embodiments described above, it will be apparent to those skilled in the art that many substitutions, modifications, and variations can be made based on the foregoing. Therefore, all such substitutions, modifications, and variations are included within the spirit and scope of the appended claims.
Claims
1. A method for constructing road network data, characterized in that, Includes the following steps: Acquire several open street map data and vehicle trajectory data, and create a composite index structure based on the open street map data; Based on the composite index structure, and according to the open street map data and the vehicle trajectory data, nearest neighbor road matching is performed to perform road merging operation based on the matching results; Additionally, road network data is obtained based on the merging results and written into the database.
2. The road network data construction method according to claim 1, characterized in that, After obtaining the open street map data, the following is also included: The open street map data is imported into the database. The open street map includes at least map ID, geometric information, attribute set, and road network data.
3. The road network data construction method according to claim 2, characterized in that, The creation of a composite index structure based on an open street map includes: A general search tree index is established based on the aforementioned geometric information; Obtain the data import timestamp of the open street map data imported into the database, and establish a block range index based on the map ID and the data import timestamp.
4. The road network data construction method according to claim 3, characterized in that, The step of performing nearest neighbor road matching based on the composite index structure and the open street map data and the vehicle trajectory data includes: The vehicle trajectory data is divided into multiple data partitions; Based on the composite index structure, the road network data corresponding to the data partition is obtained from the open street map data, and the nearest road matching is performed; When a match is successful, based on the composite index structure, the map ID, attribute set, and geometric information corresponding to the currently matched road network data are obtained from the open street map data, so as to associate the map ID, attribute set, and geometric information with the road ID of the currently matched data partition as the matching result.
5. The road network data construction method according to claim 4, characterized in that, The road merging operation based on the matching results includes: Based on the geometric information in the matching results, road network data with geometric distances within a set threshold are filtered out and merged. Simultaneously, the attribute sets of the merged road network data are checked to see if they are consistent. If they are consistent, the currently merged road network data is taken as the merging result; otherwise, the road network data is smoothed and the smoothed road network data is taken as the merging result.
6. The road network data construction method according to claim 5, characterized in that, The road network data obtained based on the merging results includes: The merged results are filtered based on a preset filtering rule base to obtain road network data.
7. The road network data construction method according to claim 6, characterized in that, After writing the road network data into the database, the process also includes: Recreate the composite index structure based on the road network data.
8. A method for querying road network data, characterized in that, A database including road network data is pre-deployed on a server, the database being constructed using the road network data construction method as described in any one of claims 1-7, and the server being configured with a single-point query interface and a batch query interface; The road network data query method includes: Based on the composite index structure, the single-point query interface is called to obtain the road network data corresponding to the currently queried map ID, or the batch query interface is called to obtain the road network data corresponding to the currently queried road ID list. In addition, the road network data is displayed.
9. A road network data query system, characterized in that, include: The query module is used to call the single-point query interface based on the composite index structure to obtain the road network data corresponding to the currently queried map ID, or to call the batch query interface to obtain the road network data corresponding to the currently queried road ID list. The display module is used to display the road network data.
10. A server, characterized in that, The server is equipped with a road network data query system and a database containing road network data, in order to obtain road network data using the road network data query method as described in claim 8.