Map data processing method and device, equipment, storage medium and program product

Abstract

The invention provides a map data processing method and device, equipment, a storage medium and a program product, and particularly relates to the technical field of map processing. The method comprises the steps of dividing map data after operation according to map element types, a preset updating period and an equal-interval grid size to obtain a plurality of mapsheet data; a multi-dimensional label is distributed to each piece of mapsheet data, the multi-dimensional label at least comprises a version label, a data precision label and a service attribute label, the version label is used for identifying the version time of the mapsheet data, the data precision label is used for identifying the data precision grade of the mapsheet data, and the service attribute label is used for identifying the service application scene of the mapsheet data; and writing the mapsheet data and the multi-dimensional label into the corresponding distributable file to form a mapsheet finished product file which can be requested by the user. The method is used for achieving the effects of improving the updating efficiency and freshness of the electronic map data and meeting the requirement of a high-real-time scene.

Description

Technical Field

[0001] This application relates to the field of map processing technology, and in particular to a map data processing method, apparatus, device, storage medium, and program product. Background Technology

[0002] With the rapid development of smart cities, autonomous driving, and location services, the real-time performance, accuracy, and dynamic updating capabilities of electronic map data have become critical requirements. However, traditional electronic map update processes typically rely on full data replacement or periodic batch updates, which are insufficient to meet the dynamic changes required for large-scale geographic areas (such as city-level or regional-level). For example, in scenarios such as urban road construction, traffic control, and disaster emergency response, geographic information elements (such as road closures, speed limit changes, and new traffic lights) often require update responses at the minute or even second level. Furthermore, high-precision maps (such as autonomous driving maps) have extremely high requirements for element freshness with centimeter-level accuracy, while traditional methods often face numerous problems such as low data fusion efficiency, chaotic version management, and update delays when processing multi-source heterogeneous data (such as crowdsourced data, remote sensing data, and sensor data). Summary of the Invention

[0003] This application provides a map data processing method, apparatus, device, storage medium, and program product to improve the update efficiency and freshness of electronic map data and meet the needs of high real-time scenarios.

[0004] In a first aspect, embodiments of this application provide a map data processing method, including:

[0005] Based on the map feature type, preset update cycle, and equal-spacing grid size, the completed map data is divided into several map sheets.

[0006] Assign multi-dimensional labels to each map sheet data. The multi-dimensional labels include at least version labels, data precision labels, and business attribute labels. The version labels are used to identify the version time of the map sheet data, the data precision labels are used to identify the data precision level of the map sheet data, and the business attribute labels are used to identify the business application scenario of the map sheet data.

[0007] The map data and its multi-dimensional labels are written together into a corresponding distributable file to form a finished map file that users can request.

[0008] Secondly, embodiments of this application provide a map data processing apparatus, comprising:

[0009] The spatial division module is used to divide the completed map data according to the map feature type, preset update cycle and equal-spacing grid size to obtain several map sheet data.

[0010] The allocation module is used to assign multi-dimensional labels to each map sheet data. The multi-dimensional labels include at least a version label, a data precision label, and a business attribute label. The version label is used to identify the version time of the map sheet data, the data precision label is used to identify the data precision level of the map sheet data, and the business attribute label is used to identify the business application scenario of the map sheet data.

[0011] The writing module is used to write the map sheet data and its multi-dimensional labels together into a corresponding distributable file, forming a finished map sheet file that users can request to obtain.

[0012] Thirdly, embodiments of this application provide a map data processing device, including: a memory and a processor;

[0013] The memory stores computer-executed instructions;

[0014] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0016] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0017] The map data processing method, apparatus, device, storage medium, and program product provided in this application adopt a three-dimensional joint partitioning of "map feature type + preset update cycle + equidistant grid," transforming the traditional one-time refresh of the entire map sheet into a local regeneration of only the map sheets containing specified feature types that meet the cycle strategy, significantly saving computing and storage resources. Version tags directly record the creation timestamp of the map sheet data and are written to a distributable file along with the map sheet data. When changes occur on-site, the system only needs to regenerate the small number of map sheets affected by the changes and immediately release the latest version tag, without waiting for large-scale overall verification. This compresses the period for providing new data to the public from "daily" to "hourly" or even "minutely," significantly enhancing data freshness. Data accuracy tags and business attribute tags are built into the same distributable file. Users can retrieve the required accuracy level and application scenario set of map sheets at once during the request phase by using tag conditions, meeting the rigid demand for "on-demand, by accuracy, and by scenario" rapid acquisition of map data in high-frequency, high-real-time scenarios such as autonomous driving and intelligent transportation. The technical solution proposed in this application achieves the technical effects of narrowing the update scope, improving data freshness, and accelerating user acquisition, directly meeting the needs of high real-time business for "fast, accurate, and on-demand" delivery of electronic map data. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] Figure 1 Flowchart of the map data processing method provided in this application Figure 1 ;

[0020] Figure 2 Flowchart of the map data processing method provided in this application Figure 2 ;

[0021] Figure 3 A schematic diagram illustrating the map sheet data division and version management provided for this application;

[0022] Figure 4 A schematic diagram illustrating the process from task creation to final monthly database generation provided for this application;

[0023] Figure 5 A schematic diagram illustrating the process of assigning multi-dimensional labels to map sheet data provided in this application;

[0024] Figure 6 A schematic diagram of the map data processing device provided in this application;

[0025] Figure 7 A schematic diagram of the structure of the map data processing device provided in this application.

[0026] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0027] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0028] The accelerated pace of urbanization and the surge in demand for geographic information have driven the real-time requirements of electronic maps to the "hourly to minute-level" level. Traditional full-volume, periodic update models, due to their long links and extensive manual intervention, generally suffer from drawbacks such as long update cycles, low efficiency, high costs, and poor real-time performance. They can no longer provide real-time, dynamic geographic information services over large or even complex geographical areas, becoming a core technological bottleneck restricting the high-quality development of the industry.

[0029] Addressing the four major pain points of electronic maps—large data scale, second-level timeliness requirements, difficulty in multi-source heterogeneous fusion, and wasted computing power—this application proposes a fully integrated end-to-end solution encompassing "range segmentation, attribute segmentation, incremental updates, version control, data submission, and dynamic resource scheduling."

[0030] At the data segmentation layer, a 3D tiling strategy of "equidistant grid + feature type + update cycle" is adopted to segment petabyte-level data. Figure 1 The full calculation is transformed into a local calculation at the MB level map sheet.

[0031] At the storage layer, tagged files are used as the smallest unit, and traditional library-level locks are abandoned to achieve a "write-to-publish" underlying file mode.

[0032] At the computational layer, based on a dual-granularity task queue of map sheet and feature, combined with real-time prediction of node load, multi-threaded concurrent updates are dynamically scheduled.

[0033] At the version level, differential packages are generated in seconds using multi-dimensional tags such as "timestamp + precision level + business scenario".

[0034] The technical solution proposed in this application provides an engineering solution for the rapid, accurate, and low-cost updating of ultra-large-scale electronic maps.

[0035] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0036] Figure 1 Flowchart of the map data processing method provided in this application Figure 1 ,like Figure 1 As shown, the method includes:

[0037] S101. Based on the map feature type, preset update cycle, and equidistant grid size, divide the completed map data to obtain several map sheet data.

[0038] In this step, map data is divided into multiple independent map sheets based on three conditions: feature type, update cycle, and grid size, thereby enabling differentiated update management.

[0039] Different elements in a map (such as roads, rivers, buildings, and vegetation) have different attributes and update requirements. For example, roads may be updated frequently due to construction, while topography changes more slowly. Dividing map sheets by element type allows for the development of independent update strategies for different elements.

[0040] The update interval (e.g., daily, weekly, monthly, or on-demand) is set based on the frequency of change of the features. For example, traffic conditions need to be updated in real time, while administrative divisions may remain unchanged for many years. By dividing map sheets according to the update cycle, high-frequency changing features can be prioritized, avoiding waste of resources.

[0041] The map area is divided into fixed-size grids (e.g., 2km×2km, 10km×10km), with each grid serving as an independent map sheet. Grid size needs to balance update efficiency and data accuracy: grids that are too large will result in excessively large amounts of data per update, while grids that are too small will increase management costs.

[0042] Based on the above three conditions, the map data is divided into multiple independent map sheets. For example:

[0043] Feature type A (e.g., road) + update cycle 1 (weekly) + grid size X → generate several road thematic map sheets;

[0044] Feature type B (e.g., building) + update cycle 2 (monthly) + grid size Y → Generate thematic map sheet for building.

[0045] Each map sheet contains data for a specific feature within a specific grid range and indicates its update cycle.

[0046] In this way, map data can be maintained efficiently and accurately.

[0047] S102. Assign multi-dimensional labels to each map sheet data. The multi-dimensional labels shall include at least a version label, a data precision label, and a business attribute label. The version label is used to identify the version time of the map sheet data, the data precision label is used to identify the data precision level of the map sheet data, and the business attribute label is used to identify the business application scenario of the map sheet data.

[0048] Assign multi-dimensional labels to each map sheet data. The multi-dimensional labels should include at least the following:

[0049] Version tags are used to record the version time of map sheet data, supporting version iteration tracking.

[0050] Data precision labels are used to indicate the data precision level of map sheet data.

[0051] Business attribute tags are used to indicate the business application scenarios of map sheet data and support scenario-based data retrieval.

[0052] S103. Write the map sheet data and its multi-dimensional labels together into the corresponding distributable file to form a finished map sheet file that users can request to obtain.

[0053] Map sheet data and its multi-dimensional labels are synchronously written to the corresponding distributable file, so that the distributable file contains version, accuracy and business attribute information, forming a finished map sheet file that users can directly request and obtain.

[0054] The map data processing method provided in this application adopts a three-dimensional joint partitioning of "map feature type + preset update cycle + equidistant grid", transforming the traditional one-time refresh of the entire map sheet into a local regeneration of only the map sheets containing specified feature types that meet the cycle strategy, significantly saving computing and storage resources. Version tags directly record the creation timestamp of the map sheet data and are written to the distributable file along with the map sheet data. When changes occur on-site, the system only needs to regenerate the small number of map sheets affected by the changes and immediately release the latest version tag, without waiting for large-scale overall verification. This compresses the period for providing new data to the public from "daily" to "hourly" or even "minutely", significantly enhancing data freshness. Data accuracy tags and business attribute tags are built into the same distributable file. Users can retrieve the required accuracy level and application scenario set of map sheets at once during the request phase by using tag conditions, meeting the rigid demand of high-frequency, high-real-time scenarios such as autonomous driving and intelligent transportation for "on-demand, by accuracy, and by scenario" rapid acquisition of map data. The technical solution proposed in this application achieves the technical effects of narrowing the update scope, improving data freshness, and accelerating user acquisition, directly meeting the needs of high real-time business for "fast, accurate, and on-demand" delivery of electronic map data.

[0055] Figure 2 Flowchart of the map data processing method provided in this application Figure 2 ,like Figure 2 As shown, in this embodiment... Figure 1 Based on the embodiments, the map data processing method is described in detail, which includes:

[0056] S201. Parse the feature type identifier carried by the dynamically updated data, and extract the corresponding incremental feature data according to the feature type granularity.

[0057] In this step, the received dynamically updated data is first parsed. As a dataset containing rich geographic information changes, the dynamically updated data explicitly carries feature type identifiers. These feature type identifiers play a crucial role in accurately distinguishing different categories of geographic features, specifically covering various types such as road features, signage features, and road surface features.

[0058] By employing pre-defined parsing algorithms and rules, the identifiers of these feature types are accurately located and extracted from dynamically updated data. After successfully parsing the identifiers, incremental feature data in the dynamically updated data is extracted in a targeted manner according to the granularity defined by different feature types. Through this step, the dynamically updated data is systematically classified and organized according to different feature types.

[0059] S202. Create an incremental update task that matches any feature type.

[0060] Based on the incremental feature data of various feature types extracted in step S201, incremental update tasks are created for each feature type. The correspondence between tasks and feature types is not a simple one-to-one pattern. That is, not every feature type corresponds to an independent incremental update task. In reality, there may be multiple feature types belonging to the same incremental update task.

[0061] In one possible implementation, the map data processing method provided in this application may further include the following steps:

[0062] For each incremental update task, determine the task processing priority;

[0063] Based on task processing priority and combined with real-time node load, each incremental update task is scheduled to be executed on its matching target computing node.

[0064] In this implementation, each created incremental update task is comprehensively evaluated and analyzed to determine its corresponding task processing priority.

[0065] After prioritizing each incremental update task, the task scheduling phase begins. The core objective of this phase is to precisely allocate each incremental update task to the most suitable target compute node for execution, based on task processing priorities and the real-time load of each compute node. As the specific hardware or virtual resource unit executing incremental update tasks, the load of a compute node dynamically changes as the task executes. Real-time node load reflects the current working status of the compute node.

[0066] This intelligent task scheduling strategy enables efficient use of computing resources, avoiding situations where some nodes are overloaded while others are idle, thereby improving the overall efficiency and stability of the map data processing system.

[0067] In one possible implementation, a preset attribute weight table records each feature type and its corresponding default priority coefficient. For each incremental update task, the task processing priority is determined, which may specifically include the following steps:

[0068] When a business requirement event is detected, adjust the priority coefficient of the element type associated with the business requirement event;

[0069] Based on the updated priority coefficients, the priority scores of each incremental update task are recalculated, and the task processing priority is determined according to the priority scores.

[0070] In this implementation, a key mechanism is introduced: a pre-set attribute weight table. This table pre-records various geographic feature types and their corresponding default priority coefficients, providing a basis for the initial setting of task priorities.

[0071] In this step, once a specific business requirement event is detected, the priority adjustment mechanism is activated. Business requirement events cover a variety of situations that may affect the importance and urgency of geographic element updates. For example, during urban planning adjustments, if a large-scale construction area is added, the update needs of geographic elements such as roads and buildings related to that construction area will become extremely urgent; or in a traffic management optimization project, if the focus is on improving several congested road sections, then the geographic element update tasks related to these road sections need to be prioritized.

[0072] Once such business need events are identified, the types of geographic features associated with those events can be located. For example, if the business need event is the expansion of a commercial area, the associated feature types might include commercial buildings, surrounding roads, and parking lots. Subsequently, the default priority coefficients of these associated feature types are adjusted based on the specific urgency and importance of the business need. The adjustment can be done by increasing or decreasing the coefficient values; if the business need is extremely urgent and important, the priority coefficient of the corresponding feature type is increased; conversely, if the business need is relatively less important, the coefficient value is appropriately decreased.

[0073] After adjusting the priority coefficients of the feature types associated with the business needs events, the task priority score calculation phase begins. Each incremental update task is associated with a specific geographic feature type. Based on the updated priority coefficients and the pre-defined priority calculation rules, the priority score of each incremental update task is recalculated.

[0074] Finally, based on the calculated priority scores, each incremental update task is sorted to determine its processing priority. Tasks with higher scores have higher processing priority and will be allocated computing resources for execution first; tasks with lower scores are processed sequentially.

[0075] S203. Based on the incremental feature data in the incremental update task, perform incremental updates on the topological and semantic relationships of the corresponding features, and detect and handle the resulting feature conflicts.

[0076] After creating the incremental update task, based on the incremental feature data contained in each task, incremental update operations are performed on the topological and semantic relationships of the corresponding features. Topological relationships describe the spatial connections, adjacencies, and inclusion relationships between geographic features, such as the intersection relationship between roads, the adjacency relationship between sign features and surrounding roads or buildings, and the inclusion relationship between road surface features and the affected road areas.

[0077] In the incremental update process, incremental feature data involves adding, modifying, or deleting existing geometric or geographic features within a geographic area. This alters the original topological and semantic relationships, leading to feature conflicts. Feature conflicts manifest as inconsistencies or contradictions between different features in terms of spatial location, attribute information, etc.

[0078] To ensure data accuracy and consistency, this step employs advanced algorithms and rules to comprehensively examine the updated topology and semantic relationships, promptly identifying any potential element conflicts. Once a conflict is detected, it will be handled according to a pre-defined conflict resolution strategy.

[0079] S204. Write the conflict-resolved feature data into the results library as the completed map data for subsequent spatial subdivision.

[0080] After resolving feature conflicts, the rigorously processed feature data, ensuring it meets quality standards, is written into a pre-defined results repository. This repository serves as a dedicated database for storing the final updated geographic data.

[0081] S205. Based on the map feature type, preset update cycle, and equal-spacing grid size, divide the completed map data to obtain several map sheet data.

[0082] The primary purpose of data segmentation is to accurately extract specific portions of data from the overall map data based on the update cycle, map feature type, and pre-planned map sheet grid. This segmented data is mainly intended for downstream production processes, aiming to achieve rapid and efficient map sheet assembly. Specifically, downstream processes expect to process and apply map data in units of approximately 2 kilometers on each side.

[0083] By dividing map data into smaller map sheets, downstream processes can update and replace data for specific areas more flexibly and promptly without having to process the entire large-scale map data. This ensures that the map information obtained by users is always highly consistent with reality, providing users with more accurate and reliable navigation and geographic information services.

[0084] In one possible implementation, the completed map data is divided into several map sheets, which may specifically include the following steps:

[0085] For geometric features in map data, if they intersect with any map sheet boundary, the intersecting part is extracted, and the geometric feature is split into at least two sub-geometric features along the intersecting part, with each sub-geometric feature assigned to the corresponding map sheet.

[0086] Based on the split geometric features, retrieve and extract the relational features that have topological or semantic dependencies with them, and assign the relational features to the corresponding map sheets to ensure that the association between geometric features and relational features in each map sheet is complete and consistent.

[0087] The segmentation process primarily employs geometric feature segmentation. Geometric features are the fundamental elements constituting a map, including the shape and location information of roads, buildings, water bodies, etc. First, based on an equally spaced grid size, the overall map data is spatially divided into multiple regular grid regions. Then, the geometric features are segmented according to these grid boundaries. After completing the geometric feature segmentation, it is necessary to further extract relational features related to these geometric features. These relational features are crucial for the map's integrity and usability.

[0088] Specifically, taking a road that runs through multiple map sheets as an example, when the road intersects with the map sheet boundary, the portion where the road intersects with the map sheet boundary is captured. Subsequently, the original road geometry is split into at least two sub-geometric elements along this intersection.

[0089] After the splitting is complete, these sub-geometric elements will be assigned to their respective map sheets based on their spatial location. The purpose of this is to ensure that the geometric elements contained within each map sheet are complete and independent, and to avoid problems of incomplete or duplicated information due to cross-map sheets.

[0090] After decomposing and assigning the geometric elements, the next crucial step is to handle the relational elements associated with these geometric elements. Relational elements are those elements that have a close dependency on the geometric elements in terms of topological structure or semantic meaning, such as traffic lights and intersection signs related to roads.

[0091] Based on the segmented geometric features, a comprehensive search is conducted in the map data to extract associated relational features. Once extracted, these relational features are accurately assigned to their respective map sheets according to their map sheet affiliation. This process ensures that the relationships between geometric features and their associated relational features are complete and consistent within each map sheet. For example, within a map sheet, road sub-geometric features can be accurately matched with their corresponding traffic lights, intersection signs, and other relational features, without any missing or incorrectly associated relational features.

[0092] The processed map data can be compressed. The compression process uses a specific encoding algorithm to encode the data, thereby reducing the storage space it occupies.

[0093] Reference Figure 3 The image shown is a schematic diagram illustrating the map sheet data division and version management provided in this application. The upper half of the image displays three adjacent map sheets, identified as 585678, 585679, and 585680, each representing a 2km x 2km area. Each map sheet contains different map elements, as detailed below:

[0094] Map 585678: Includes sign (1), pole (1), curb (3);

[0095] Map 585679: Includes signs (2), poles (3), and curbs (1);

[0096] Map 585680: Includes sign (1), pole (1), and curb (2).

[0097] The lower half of the image shows the changes in the number of signs and curbs in different versions (v1 and v2) across various map frames:

[0098] Card elements

[0099] Version 1: The quantity is 1 in map sheets 585678, 585679, and 585680.

[0100] v2 version: The number of map sheets 585678 remains 1, the number of map sheets 585679 becomes 2, and the number of map sheets 585680 is 1.

[0101] Curb elements

[0102] v1 version: The number of curbs in each map sheet is not explicitly given in the map for version v1.

[0103] v2 version: Map sheet 585678 has 3 pieces, map sheet 585679 has 1 piece, and map sheet 585680 has 2 pieces.

[0104] S206. Assign multi-dimensional labels to each map sheet data. The multi-dimensional labels shall include at least a version label, a data precision label, and a business attribute label. The version label is used to identify the version time of the map sheet data, the data precision label is used to identify the data precision level of the map sheet data, and the business attribute label is used to identify the business application scenario of the map sheet data.

[0105] In this step, multi-dimensional labels are assigned to each map sheet. These multi-dimensional labels include version labels, data accuracy labels, and business attribute labels, each with a specific function.

[0106] S207. Write the map sheet data and its multi-dimensional labels together into the corresponding distributable file to form a finished map sheet file that users can request to obtain.

[0107] The map sheet data and its corresponding multi-dimensional labels are written together into a suitable distributable file. Through this operation, the originally separate map sheet data and the label information describing its characteristics are integrated together, ultimately forming a finished map sheet file that users can request.

[0108] According to the rules, the map data obtained by dividing the map data into 2 km x 2 km squares is presented in PBF file format. PBF format has advantages such as high storage efficiency and fast parsing speed, making it suitable for storing and transmitting map data.

[0109] In the actual map data update process, the data will change constantly, and multiple versions may be generated every day. For example, for file A, the version generated on January 1, 2025 can be identified as "file A + 20250101 + high precision identifier", where "20250101" clearly indicates the time of this version, and "high precision identifier" indicates that the data precision level of this version is high precision; the version generated on January 2, 2025 is identified as "file A + 20250102 + high precision identifier".

[0110] In one possible implementation, the map sheet data and its multi-dimensional labels are written together into a corresponding distributable file to form a finished map sheet file that users can request. This may specifically include the following steps:

[0111] The map sheet data is written to the corresponding distributable file, and its version tag and data accuracy identifier are written to the file name of the distributable file to form a finished map sheet file with version tags.

[0112] In this embodiment, the map sheet data obtained through the preceding processing steps is written to the corresponding distributable file. After writing the map sheet data, the version tag and data precision identifier corresponding to the map sheet data are written to the filename of the distributable file. The version tag is used to identify the version time of the map sheet data, recording the specific time point when the data was generated or updated. The data precision identifier clarifies the data precision level of the map sheet data, such as "high precision" or "low precision," and is used to distinguish data at different precision levels. Through the above two steps, a final map sheet file with version tags is formed.

[0113] Reference Figure 4 The diagram illustrates the process from task creation to final monthly database generation provided in this application. The task database stores raw map data from various sources. This raw map data needs to be processed, and corresponding processing tasks are created. Each main task can contain multiple subtasks, as shown in the diagram, with subtasks 1-1, 2-1, 3-1, and 4-1 listed sequentially under each main task. After each subtask is completed, its processing result (i.e., the completed map data) is submitted to the results database. The results database compiles the result files corresponding to each subtask, namely result file 1-1, result file 2-1, result file 3-1, and result file 4-1. These result files are the products of each subtask's processing and are stored in the results database awaiting further processing. Next, a final version marking operation is performed. This step aims to mark the result files that meet the requirements for subsequent assembly into a formal version. Finally, the final version files marked with the final version mark are stored in the monthly version database.

[0114] It should be noted that during data processing, when multiple different modification tasks for the same area are submitted simultaneously, this conflict event will be explicitly recorded. The conflict record includes relevant information about the conflict, such as the area identifier involved, the source of the conflicting tasks (i.e., the tasks of personnel A and B), the modifications made by each person (A changed to 'a', B changed to 'b'), and the submission time. This method provides a clear understanding of the specific circumstances of the conflict, offering detailed information for subsequent conflict resolution.

[0115] When resolving such conflicts, the "A first, B later" submission pattern rule is followed. "A first, B later" means determining the final retained changes based on the order in which tasks were submitted or a preset priority order (in this scenario, based on person A's operation first, then person B's). Even though person A made the changes first, according to the established rules, person B's changes (changing the data to 'b') will ultimately be submitted to the results repository.

[0116] Reference Figure 5 The diagram shown illustrates the process of assigning multi-dimensional labels to map sheet data as provided in this application. The diagram presents three parallel sections: each section has a version-related information text box at the top and a corresponding multi-row, multi-column grid (representing a map sheet) at the bottom, forming a schematic framework for label assignment to map sheet data under different versions. Each grid represents a map sheet. These map sheets are the basic units of map data, obtained by cutting them according to certain rules (such as geographical region division).

[0117] Different labels are marked in the grid. For example, in the map sheet grid corresponding to version 20250716, there are labels such as "Label 1", "Label 2", and "Label 1, 2". This indicates that different map sheets are assigned different labels, which are classification identifiers of map sheet data from specific dimensions (such as business attributes, data accuracy, etc.). In this way, massive amounts of map sheet data can be classified and managed.

[0118] In one possible implementation, the map data processing method provided in this application may further include the following steps:

[0119] When a user's map data retrieval request is received, the version label of the map sheet data currently used by the user and the target version label of the request are determined.

[0120] Based on the current version tag and the target version tag, the corresponding map sheet finished files are compared to generate incremental map sheet data;

[0121] Incremental map sheet data will be distributed to users so that they can complete the version differential update.

[0122] In this implementation, when a user initiates a map data retrieval request, two key version tags need to be determined:

[0123] The version label of the map data currently being used by the user: This represents the version information of the map data already stored on the user's device. By identifying the data version currently being used by the user, it is possible to understand the status of the user's existing map data.

[0124] The target version tag in the request refers to the version of map data the user expects to obtain. Users may request a specific version of map data for various reasons, such as needing more accurate map information or obtaining the latest road changes.

[0125] After determining the current version label and the target version label, the corresponding finished map sheet files are compared based on these two labels. This comparison generates incremental map sheet data. The incremental map sheet data only includes the parts that have changed from the current version to the target version, not the complete map data. The generated incremental map sheet data is then sent to the user device. Upon receiving the incremental map sheet data, the user device performs a version differential update based on this data. In other words, the user device only needs to integrate the incremental map sheet data with the existing map data to update the map data to the target version.

[0126] The map data processing method provided in this application adopts a three-dimensional joint partitioning of "map feature type + preset update cycle + equidistant grid", transforming the traditional one-time refresh of the entire map sheet into a local regeneration of only the map sheets containing specified feature types that meet the cycle strategy, significantly saving computing and storage resources. Version tags directly record the creation timestamp of the map sheet data and are written to the distributable file along with the map sheet data. When changes occur on-site, the system only needs to regenerate the small number of map sheets affected by the changes and immediately release the latest version tag, without waiting for large-scale overall verification. This compresses the period for providing new data to the public from "daily" to "hourly" or even "minutely", significantly enhancing data freshness. Data accuracy tags and business attribute tags are built into the same distributable file. Users can retrieve the required accuracy level and application scenario set of map sheets at once during the request phase by using tag conditions, meeting the rigid demand of high-frequency, high-real-time scenarios such as autonomous driving and intelligent transportation for "on-demand, by accuracy, and by scenario" rapid acquisition of map data. The technical solution proposed in this application achieves the technical effects of narrowing the update scope, improving data freshness, and accelerating user acquisition, directly meeting the needs of high real-time business for "fast, accurate, and on-demand" delivery of electronic map data.

[0127] Figure 6 A schematic diagram of the structure of the map data processing device provided in this application is shown below. Figure 6 As shown, the map data processing device 60 provided in this embodiment includes:

[0128] The spatial division module 601 is used to divide the completed map data according to the map feature type, preset update cycle and equal-spacing grid size to obtain several map sheet data.

[0129] The allocation module 602 is used to allocate multi-dimensional labels to each map sheet data. The multi-dimensional labels include at least a version label, a data precision label, and a business attribute label. The version label is used to identify the version time of the map sheet data, the data precision label is used to identify the data precision level of the map sheet data, and the business attribute label is used to identify the business application scenario of the map sheet data.

[0130] The writing module 603 is used to write the map sheet data and its multi-dimensional labels together into the corresponding distributable file, forming a finished map sheet file that users can request to obtain.

[0131] In one possible implementation, the space partitioning module is specifically used for:

[0132] For geometric features in map data, if they intersect with any map sheet boundary, the intersecting part is extracted, and the geometric feature is split into at least two sub-geometric features along the intersecting part, with each sub-geometric feature assigned to the corresponding map sheet.

[0133] Based on the split geometric features, retrieve and extract the relational features that have topological or semantic dependencies with them, and assign the relational features to the corresponding map sheets to ensure that the association between geometric features and relational features in each map sheet is complete and consistent.

[0134] In one possible implementation, the write module is specifically used for:

[0135] The map sheet data is written to the corresponding distributable file, and its version tag and data accuracy identifier are written to the file name of the distributable file to form a finished map sheet file with version tags.

[0136] In one possible implementation, the map data processing apparatus of this application is further used for:

[0137] Parse the feature type identifiers carried by the dynamically updated data, and extract the corresponding incremental feature data according to the feature type granularity;

[0138] Create an incremental update task that matches any feature type;

[0139] Based on the incremental feature data in the incremental update task, the topological and semantic relationships of the corresponding features are updated incrementally, and feature conflicts arising therefrom are detected and handled.

[0140] The conflict-resolved feature data is written into the results library and used as the completed map data for subsequent spatial subdivision.

[0141] In one possible implementation, the map data processing apparatus of this application is further used for:

[0142] For each incremental update task, determine the task processing priority;

[0143] Based on task processing priority and combined with real-time node load, each incremental update task is scheduled to be executed on its matching target computing node.

[0144] In one possible implementation, a preset attribute weight table records each feature type and its corresponding default priority coefficient. The map data processing device of this application is further used for:

[0145] When a business requirement event is detected, adjust the priority coefficient of the element type associated with the business requirement event;

[0146] Based on the updated priority coefficients, the priority scores of each incremental update task are recalculated, and the task processing priority is determined according to the priority scores.

[0147] In one possible implementation, the map data processing apparatus of this application is further used for:

[0148] When a user's map data retrieval request is received, the version label of the map sheet data currently used by the user and the target version label of the request are determined.

[0149] Based on the current version tag and the target version tag, the corresponding map sheet finished files are compared to generate incremental map sheet data;

[0150] Incremental map sheet data will be distributed to users so that they can complete the version differential update.

[0151] The map data processing device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0152] Figure 7 A schematic diagram of the map data processing device provided in this application. Figure 7 As shown, the map data processing device 70 provided in this embodiment includes at least one processor 701 and a memory 702. Optionally, the device 70 further includes a communication component 703. The processor 701, memory 702, and communication component 703 are connected via a bus.

[0153] In a specific implementation, at least one processor 701 executes computer execution instructions stored in memory 702, causing at least one processor 701 to perform the above-described method.

[0154] The specific implementation process of processor 701 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0155] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0156] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0157] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0158] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0159] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0160] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0161] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0162] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0163] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0164] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0165] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0166] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0167] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A map data processing method, characterized in that, include: Based on the map feature type, preset update cycle, and equal-spacing grid size, the completed map data is divided into several map sheets. Assign multi-dimensional labels to each map sheet data. The multi-dimensional labels include at least version labels, data precision labels, and business attribute labels. The version labels are used to identify the version time of the map sheet data, the data precision labels are used to identify the data precision level of the map sheet data, and the business attribute labels are used to identify the business application scenario of the map sheet data. The map data and its multi-dimensional labels are written together into a corresponding distributable file to form a finished map file that users can request.

2. The method according to claim 1, characterized in that, The completed map data is divided into several map sheets, including: For a geometric feature in the map data, if it intersects with any map sheet boundary, the intersecting part is extracted, and the geometric feature is split into at least two sub-geometric features along the intersecting part, with each sub-geometric feature assigned to the corresponding map sheet. Based on the split geometric features, retrieve and extract relational features that have topological or semantic dependencies with them, and assign the relational features to the corresponding map sheets so that the association between geometric features and relational features in each map sheet data is complete and consistent.

3. The method according to claim 1 or 2, characterized in that, The step of writing the map sheet data and its multi-dimensional labels together into a corresponding distributable file to form a finished map sheet file that users can request includes: The map sheet data is written to the corresponding distributable file, and its version tag and data precision identifier are written to the file name of the distributable file to form a finished map sheet file with version tags.

4. The method according to claim 1 or 2, characterized in that, Before dividing the completed map data into several map sheets based on map feature type, preset update cycle, and equal-spacing grid size, the method further includes: Parse the feature type identifiers carried by the dynamically updated data, and extract the corresponding incremental feature data according to the feature type granularity; Create an incremental update task that matches any feature type; Based on the incremental feature data in the incremental update task, the topological and semantic relationships of the corresponding features are incrementally updated, and the resulting feature conflicts are detected and processed. The conflict-resolved feature data is written into the results library and used as the completed map data for subsequent spatial subdivision.

5. The method according to claim 4, characterized in that, The method further includes: For each incremental update task, determine the task processing priority; Based on the task processing priority and in combination with the real-time node load, each incremental update task is scheduled to be executed on the target computing node that matches it.

6. The method according to claim 5, characterized in that, The preset attribute weight table records each feature type and its corresponding default priority coefficient. The process of determining the task processing priority for each incremental update task includes: When a business requirement event is detected, the priority coefficient of the element type associated with the business requirement event is adjusted; Based on the updated priority coefficients, the priority scores of each incremental update task are recalculated, and the task processing priority is determined according to the priority scores.

7. The method according to claim 1 or 2, characterized in that, The method further includes: When a user's map data retrieval request is received, the version label of the map sheet data currently used by the user and the target version label of the request are determined. Based on the current version tag and the target version tag, the corresponding map sheet finished file is compared to generate incremental map sheet data; The incremental map data is sent to the user so that the user can complete the version differential update.

8. A map data processing device, characterized in that, include: The spatial division module is used to divide the completed map data according to the map feature type, preset update cycle and equal-spacing grid size to obtain several map sheet data. The allocation module is used to assign multi-dimensional labels to each map sheet data. The multi-dimensional labels include at least a version label, a data precision label, and a business attribute label. The version label is used to identify the version time of the map sheet data, the data precision label is used to identify the data precision level of the map sheet data, and the business attribute label is used to identify the business application scenario of the map sheet data. The writing module is used to write the map sheet data and its multi-dimensional labels together into a corresponding distributable file, forming a finished map sheet file that users can request to obtain.

9. A map data processing device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium or computer program product, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7; And / or, The computer program product includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

Images