Data processing method, storage medium, and electronic device

Abstract

This application provides a data processing method, storage medium, and electronic device, including: obtaining a first major version number corresponding to an original mapping engine and a second major version number corresponding to a target mapping engine, wherein the original mapping engine is the mapping engine corresponding to an initial mapping data file, the target mapping engine is the mapping engine to be used, and the initial mapping data file is a data file to be read; in response to the inconsistency between the first major version number and the second major version number, performing format conversion on the initial mapping data file to obtain the target mapping data file, wherein the file format of the target mapping data file is a format that the target mapping engine can parse; verifying the target mapping data file to obtain a verification result; and in response to the verification result being successful, using the target mapping engine to read the target mapping data file, thus solving the technical problem in related technologies where mapping data and mapping engines cannot be read normally due to version incompatibility.

Description

Technical Field

[0001] This application relates to the field of intelligent driving technology, and more specifically, to a data processing method, a storage medium, and an electronic device. Background Technology

[0002] With the rapid development of intelligent driving technology, high-precision maps serve as the core input for perception and decision-making, and the generation of local mapping data heavily relies on various mapping engines. However, due to continuous iterations and upgrades of mapping engines, significant differences exist between different versions, causing mapping data generated by older engines to be unable to be correctly parsed by newer engines. Consequently, in offline testing and simulation scenarios, a large amount of historical mapping data cannot be reused due to version incompatibility, resulting in wasted acquisition costs.

[0003] There is currently no good solution to the above problems. Summary of the Invention

[0004] This application provides a data processing method, storage medium, and electronic device to at least solve the technical problem in the related art where mapping data and mapping engines cannot be read normally due to version incompatibility.

[0005] According to one aspect of the embodiments of this application, a data processing method is provided, comprising: obtaining a first major version number corresponding to an original mapping engine and a second major version number corresponding to a target mapping engine, wherein the original mapping engine is the mapping engine corresponding to an initial mapping data file, the target mapping engine is the mapping engine to be used, and the initial mapping data file is a data file to be read; in response to the inconsistency between the first major version number and the second major version number, performing a format conversion on the initial mapping data file to obtain a target mapping data file, wherein the file format of the target mapping data file is a format that the target mapping engine can parse; verifying the target mapping data file to obtain a verification result; and in response to the verification result being successful, reading the target mapping data file using the target mapping engine.

[0006] Furthermore, the initial mapping data file is format-converted to obtain the target mapping data file, including: converting the initial mapping data file into an intermediate model data file according to the first major version number; and mapping the file format of the intermediate model data file to the target mapping data file with the same second major version number through the first rule base, wherein the first rule base is used to map the intermediate model data file into a file that can be parsed by the target mapping engine.

[0007] Furthermore, the initial mapping data file is converted into an intermediate model data file according to the first major version number, including: determining the data loading interface adapted to the first major version number by calling the data loading library corresponding to the first major version number; and converting the initial mapping data file into an intermediate model data file according to the data loading interface and the second rule library, wherein the second rule library is used to record the conversion rules between the initial mapping data file and the intermediate model data file.

[0008] Furthermore, the target mapping data file is validated to obtain validation results, including: verifying the target mapping data file based on data integrity rules and data correctness rules; determining the validation result as passed if the target mapping data file is not missing or corrupted and conforms to the parsing specifications of the target mapping engine; and determining the validation result as failed if the target mapping data file is missing or corrupted, or does not conform to the parsing specifications of the target mapping engine.

[0009] Furthermore, the data processing method also includes: in response to the verification result being verified as passed and the target mapping data file being opened normally by the target mapping engine, determining that the target mapping data file has been successfully converted.

[0010] Furthermore, the data processing method also includes: in response to the verification result being a verification failure, or the target mapping data file not being opened normally by the target mapping engine, determining that the target mapping data file conversion has failed.

[0011] Furthermore, the data processing method also includes: in response to the failure of the conversion of the target mapping data file, performing a format conversion on the initial mapping data file based on the prompt information, wherein the prompt information is used to indicate the reason for the failure of the conversion from the initial mapping data file to the target mapping data file.

[0012] According to another aspect of the embodiments of this application, a data processing apparatus is also provided, comprising: an acquisition module, configured to acquire a first major version number corresponding to an original mapping engine and a second major version number corresponding to a target mapping engine, wherein the original mapping engine is the mapping engine corresponding to an initial mapping data file, the target mapping engine is the mapping engine to be used, and the initial mapping data file is a data file to be read; a conversion module, configured to convert the format of the initial mapping data file to obtain a target mapping data file in response to a discrepancy between the first major version number and the second major version number, wherein the file format of the target mapping data file is a format that the target mapping engine can parse; a verification module, configured to verify the target mapping data file and obtain a verification result; and a reading module, configured to read the target mapping data file using the target mapping engine in response to a verification result indicating that the verification is successful.

[0013] Furthermore, the conversion module is also used to convert the initial mapping data file into an intermediate model data file according to the first major version number; and to map the file format of the intermediate model data file to the target mapping data file that is consistent with the second major version number through the first rule base, wherein the first rule base is used to map the intermediate model data file to a file that the target mapping engine can parse.

[0014] Furthermore, the conversion module is also used to determine the data loading interface that is compatible with the first major version number by calling the data loading library corresponding to the first major version number; and to convert the initial mapping data file into an intermediate model data file according to the data loading interface and the second rule library, wherein the second rule library is used to record the conversion rules between the initial mapping data file and the intermediate model data file.

[0015] Furthermore, the verification module is also used to verify the target mapping data file based on data integrity rules and data correctness rules; in response to the fact that the target mapping data file is not missing or damaged, and the target mapping data file conforms to the parsing specifications of the target mapping engine, the verification result is determined to be verification passed; in response to the fact that the target mapping data file is missing or damaged, or the target mapping data file does not conform to the parsing specifications of the target mapping engine, the verification result is determined to be verification failed.

[0016] Furthermore, the verification module is also used to confirm that the target mapping data file has been successfully converted if the verification result is successful and the target mapping data file can be opened normally by the target mapping engine.

[0017] Furthermore, the verification module is also used to determine that the target mapping data file conversion failed in response to a verification result of verification failure or the target mapping data file not being opened normally by the target mapping engine.

[0018] Furthermore, the conversion module is also used to perform format conversion on the initial mapping data file based on the prompt information in response to the failure of the conversion of the target mapping data file. The prompt information is used to indicate the reason for the failure of the conversion from the initial mapping data file to the target mapping data file.

[0019] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer-readable storage medium, and the computer program is configured to perform the data processing method described in any of the above when it is run on a computer or processor.

[0020] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the data processing method described in any of the preceding claims.

[0021] According to another aspect of the embodiments of this application, a vehicle is also provided, including: a memory storing an executable program; and a processor for running the executable program, wherein the executable program performs the data processing method described in any of the above embodiments when running on the processor.

[0022] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the data processing methods of various embodiments of this application.

[0023] According to another aspect of the embodiments of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the data processing methods of various embodiments of this application.

[0024] According to another aspect of the embodiments of this application, a computer program is also provided, which, when executed by a processor, implements the data processing methods of the various embodiments of this application.

[0025] In this embodiment, the first major version number corresponding to the original mapping engine and the second major version number corresponding to the target mapping engine are first obtained. The original mapping engine is the mapping engine corresponding to the initial mapping data file, the target mapping engine is the mapping engine to be used, and the initial mapping data file is the data file to be read. When the first major version number and the second major version number are inconsistent, the initial mapping data file is format-converted to obtain the target mapping data file. The target mapping data file is in a format that the target mapping engine can parse. Next, the target mapping data file is verified to obtain a verification result. When the verification result is successful, the target mapping data file is read using the target mapping engine. This is achieved by using the original mapping data file based on a unified... The system performs lossless format conversion between different models and triggers the conversion process only based on the major version number difference, avoiding redundant processing of minor version changes and significantly improving conversion efficiency and stability. Furthermore, a dual verification mechanism of integrity and semantic consistency ensures that the converted data fully conforms to the parsing specifications of the target mapping engine, effectively preventing parsing crashes or data misreading caused by format mismatches. When the verification result is successful, the target mapping engine reads the target mapping data file, achieving automated reuse of cross-version mapping data. This realizes cross-version compatibility and normal reading of the target mapping engine and historical mapping data, thus solving the technical problem in related technologies where mapping data and mapping engines cannot be read normally due to version incompatibility. Attached Figure Description

[0026] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0027] Figure 1 This is a flowchart of a data processing method according to an embodiment of this application;

[0028] Figure 2 This is a schematic diagram of an optional conversion rule according to an embodiment of this application;

[0029] Figure 3 This is a flowchart illustrating an optional conversion method according to an embodiment of this application;

[0030] Figure 4 This is a schematic diagram of an optional conversion system according to an embodiment of this application;

[0031] Figure 5 This is a schematic diagram of a data processing apparatus according to an embodiment of this application. Detailed Implementation

[0032] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0033] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0034] According to an embodiment of this application, an embodiment of a data processing method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0035] This embodiment provides a data processing method. Figure 1 This is a flowchart of a data processing method according to an embodiment of this application, such as... Figure 1 As shown, the process includes the following steps:

[0036] Step S10: Obtain the first major version number corresponding to the original mapping engine and the second major version number corresponding to the target mapping engine. The original mapping engine is the mapping engine corresponding to the initial mapping data file, the target mapping engine is the mapping engine to be used, and the initial mapping data file is the data file to be read.

[0037] In this embodiment, the original mapping engine refers to the mapping engine used when generating the initial mapping data file. The original mapping engine is the software system relied upon when actually collecting or generating map data offline; it is typically embedded in the intelligent driving development or testing platform and is responsible for constructing structured map files from sensor data. The version of the original mapping engine determines the file's internal data structure, field definitions, and encoding rules.

[0038] The first major version number is the major version portion of the original mapping engine's version number. It identifies version nodes where significant changes have occurred in the map data format, such as the addition or deletion of fields, adjustments to word length, or reconstruction of core feature structures. The first major version number is related to the data storage format and is a key criterion for determining whether the data is compatible with the target mapping engine.

[0039] The target mapping engine refers to a specific version of the mapping engine that is scheduled to load the initial mapping data file. It is responsible for parsing map data in the intelligent driving system and providing it to the perception, positioning, or planning modules.

[0040] The second major version number is the major version portion of the target mapping engine's version number, reflecting the map data format specifications supported by the target mapping engine. The second major version number strictly corresponds to the target mapping engine's parsing logic and is used to compare with the first major version number to determine whether data format conversion is necessary.

[0041] Obtaining the first major version number of the original mapping engine and the second major version number of the target mapping engine can be understood as obtaining the first major version number of the original mapping engine corresponding to the initial mapping data file and the second major version number of the mapping engine to be used, thus providing a basis for determining whether data format conversion is needed in the future.

[0042] For example, firstly, the first major version number is extracted from the metadata of the initial mapping data file. This first major version number is automatically written by the original mapping engine during data generation, typically located in the file header or a dedicated configuration section. It records the complete engine version in a standardized format (e.g., "V1.2.3"), and the major version number is its first digit (e.g., "1"), representing the core data structure specifications upon which the data depends. The original mapping engine is the software system that generates the initial mapping data file. The first major version number indicates the storage logic, field order, and encoding method of map features. The second major version number is obtained in two ways: one is automatic identification, which reads the version information from the executable file or configuration file of the target mapping engine in the current operating environment; the other is manual specification, which involves selecting the target version from a list of preset engine versions in the tool interface. This is suitable for scenarios where the target mapping engine is not running or the environment is limited. The target mapping engine is the engine instance currently running or about to load map data in the current intelligent driving system. The second major version number of the target mapping engine determines the boundaries of the map structure that the target mapping engine can parse. By comparing the first and second major version numbers, it is possible to clearly determine whether the current data matches the parsing capabilities of the target mapping engine, thereby deciding whether to initiate the data format conversion process. This lightweight decision-making based solely on the version number ensures efficiency and avoids misjudgments.

[0043] As can be seen, by accurately extracting the first major version number of the original mapping engine and the second major version number of the target mapping engine, version compatibility judgment is pre-emptively and automatically determined, avoiding the risk of system crashes caused by blind loading and parsing. This step does not require reading the underlying data content, relying only on the version identifier in the metadata, significantly improving judgment efficiency and reducing computational overhead. Simultaneously, the major version number focuses on core structural changes, accurately distinguishing between scenarios requiring and not requiring conversion, effectively suppressing redundant processing, improving system stability, and providing a reliable basis for subsequent differentiated conversion strategies. This fundamentally improves the availability and processing reliability of mapping data in cross-version environments.

[0044] Step S12: In response to the inconsistency between the first major version number and the second major version number, the initial mapping data file is converted to a new format to obtain the target mapping data file. The target mapping data file is in a format that the target mapping engine can parse.

[0045] In this embodiment, the target mapping data file refers to a new type of map data file that has undergone format conversion to adapt to the parsing specifications of the target mapping engine. The structure, field definitions, data encoding, and feature organization of the target mapping data file are all consistent with the expected input format of the target mapping engine. The target mapping data file is not a simple copy of the original data, but is reconstructed and generated by performing semantic mapping, field rearrangement, word length adjustment, or redundant field completion on the original data through an intermediate model and according to the output rule base. This ensures that all map features (such as road topology, lane lines, signs, etc.) conform to the parsing protocol of the target mapping engine in both semantics and physical storage. The target mapping data file retains all the semantic information of the original data, only completing compatibility adaptation in terms of expression form. It has the same geographic accuracy and content integrity as the original file and can be directly loaded, parsed, and used by the target mapping engine for positioning, perception, or path planning tasks.

[0046] In response to the inconsistency between the first and second major version numbers, the initial mapping data file is converted to obtain the target mapping data file. This can be understood as follows: when the first and second major version numbers are inconsistent, the initial mapping data file is converted to obtain the target mapping data file that can be parsed by the target mapping engine.

[0047] For example, when the structure of the initial mapping data file does not match the parsing capabilities of the target mapping engine, a data format conversion process will be automatically triggered. First, based on the first major version number, the corresponding data loading module is called to fully parse all map features (such as lane lines, road boundaries, traffic signs, etc.) and their field storage structures in the original file. Then, this original data is mapped to a predefined intermediate model, which covers all fields and data types supported by all historical major versions, ensuring no information loss. Next, based on the second major version number, the data format that the target mapping engine can parse is matched from the export rule base, and operations such as field rearrangement, word length alignment, redundant field filling, or obsolete field removal are performed. Finally, a target mapping data file whose structure fully conforms to the parsing protocol of the target mapping engine is generated. This process does not change the map semantics or geographic accuracy; it only performs compatibility recoding of the data representation, ensuring that the converted file can be read, loaded, and used by the target mapping engine without errors, thereby reducing the cost of discarding historical data.

[0048] As can be seen, by responding to format conversions triggered by inconsistencies in the main version number, automated adaptation of mapping data across different engine versions is achieved, significantly improving system compatibility and data reuse efficiency. This format conversion process utilizes an intermediate model to achieve lossless semantic transfer, ensuring that the geometric accuracy and semantic integrity of map features remain unaffected. Once the target mapping data file is generated, it can be loaded by the target mapping engine, avoiding parsing failures, system crashes, or data loss due to version incompatibility. This ensures the continuity of intelligent driving testing and operation, thereby achieving the technical effects of saving data acquisition costs and improving development efficiency.

[0049] Step S14: Verify the target mapping data file and obtain the verification result;

[0050] In this embodiment, the verification result refers to a comprehensive judgment on whether the target mapping data file after format conversion meets the parsing specifications of the target mapping engine. Specifically, it includes assessments of both data integrity and semantic correctness. Integrity verification checks indicators such as the total number of map features, the existence of key fields, whether data block lengths match, and the distribution of null or outlier values ​​to confirm that the file has not suffered data loss, truncation, or structural damage during the conversion process. Correctness verification, based on the target mapping engine's protocol document, performs item-by-item parsing tests on field encoding methods, coordinate system units, feature type identifiers, and topological connectivity to ensure that it conforms to the engine's expected semantic structure. The verification module simulates the engine loading process using a built-in validator. If the target mapping data file can be completely parsed without any errors, it outputs "Verification Passed"; if there are missing fields, type mismatches, or parsing anomalies, it outputs "Verification Failed" along with specific error location information. This verification mechanism effectively prevents the target mapping data file from having superficial compatibility but actual unusability, providing high-quality data input for subsequent intelligent driving algorithm training and functional verification.

[0051] The verification of the target mapping data file can be understood as the automated verification module performing multi-dimensional and automated detection on the structural integrity, semantic accuracy, and engine compatibility of the converted target mapping data file, and outputting a clear judgment conclusion.

[0052] For example, firstly, a structural integrity check is performed: verifying underlying structural elements such as file header information, number of data blocks, field offsets, and index table consistency to ensure no data loss, misalignment, or formatting errors. Secondly, semantic correctness verification is performed: comparing the encoding specifications, coordinate precision, and attribute value ranges of map feature types (such as lane lines, traffic signs, and curbs) to ensure they meet the requirements of the target mapping engine protocol, and verifying whether topological relationships (such as road connectivity and lane adjacency) are preserved. Finally, a lightweight simulation loading test is conducted, calling the target mapping engine's parsing interface to attempt to read the file, observing for any errors, crashes, or data anomalies. If verification fails, the erroneous fields and causes are precisely located, significantly reducing the risk of "pseudo-compatibility" and ensuring that the converted data can be effectively read, providing a reliable data foundation for subsequent simulation, testing, and functional verification.

[0053] As can be seen, systematic verification of the target mapping data file effectively ensures the reliability and usability of the format conversion results. This verification process automatically identifies potential defects such as missing data, field mismatches, and encoding anomalies based on structural integrity, semantic consistency, and engine compatibility. This fundamentally prevents the risk of intelligent driving system crashes or misjudgments caused by data anomalies, further significantly reducing the cost of manual review and improving testing efficiency. Furthermore, the verification results can provide precise error location, accelerating problem repair.

[0054] Step S16: In response to the verification result being successful, the target mapping data file is read using the target mapping engine.

[0055] In this embodiment of the application, responding to the verification result being verified as passed, using the target mapping engine to read the target mapping data file can be understood as follows: when the verification result is verified as passed, it indicates that the entire compatibility conversion process has been successfully closed, and the system has entered a stable state that can be directly applied. At this time, the target mapping engine can be used to read the target mapping data file.

[0056] For example, when the verification result is successful, it indicates that the target mapping data file has met the input requirements of the target mapping engine in terms of structural integrity, semantic accuracy, field encoding standards, and engine protocol compatibility. Therefore, the target mapping engine can directly load and parse all map features (such as lane lines, traffic signs, elevation grids, semantic labels, etc.), achieving millisecond-level response and error-free operation. This process eliminates problems such as parsing anomalies, memory overflows, or functional module crashes caused by version incompatibility. At the same time, this step allows the new version of the engine to access historical data without needing to be compatible with the old format, relying only on a unified format conversion process, significantly reducing development and maintenance complexity.

[0057] As can be seen, when the verification result is successful, the target mapping engine is directly called to load the target mapping data file. This eliminates the redundant steps of "manual verification and adaptation after conversion" in traditional solutions, ensuring that rigorously verified data can be directly parsed by the target mapping engine without modifying the engine code or adding a compatibility layer, greatly improving system deployment efficiency. Furthermore, this step enables "zero-cost reuse" of historical mapping data in the new engine environment, significantly reducing data re-acquisition costs, accelerating algorithm iteration and simulation verification cycles, and providing stable, consistent, and traceable data input for the intelligent driving system.

[0058] Through the above steps, firstly, the first major version number corresponding to the original mapping engine and the second major version number corresponding to the target mapping engine are obtained. The original mapping engine is the mapping engine corresponding to the initial mapping data file, and the target mapping engine is the mapping engine to be used. The initial mapping data file is the data file to be read. When the first and second major version numbers are inconsistent, the format of the initial mapping data file is converted to obtain the target mapping data file. The file format of the target mapping data file is a format that the target mapping engine can parse. Next, the target mapping data file is verified, and the verification result is obtained. When the verification result is successful, the target mapping data file is read using the target mapping engine. This is achieved by using the original mapping data file as a unified intermediate... The model undergoes lossless format conversion, triggering the conversion process solely based on major version number differences. This avoids redundant processing of minor version changes, significantly improving conversion efficiency and stability. Furthermore, a dual verification mechanism of integrity and semantic consistency ensures that the converted data fully conforms to the parsing specifications of the target mapping engine, effectively preventing parsing crashes or data misreading due to format mismatches. When the verification result is successful, the target mapping engine reads the target mapping data file, achieving automated reuse of cross-version mapping data. This realizes cross-version compatibility and normal reading of the target mapping engine and historical mapping data, thus solving the technical problem in related technologies where mapping data and mapping engines cannot be read normally due to version incompatibility.

[0059] Figure 2 This is a schematic diagram of an optional conversion rule according to an embodiment of this application, such as... Figure 2As shown, the initial mapping data files have varying field structures due to engine iterations. These are mapped to a standardized intermediate model through import rules. This model encompasses all field definitions for all map features, achieving semantic unification of heterogeneous data. Subsequently, based on the target mapping engine version, compatible field subsets are extracted using export rules, and then re-encoded, field-split, or filled with default values ​​to generate data files conforming to the target mapping engine's parsing specifications. The conversion rules use field semantics, not names, for matching, supporting field expansion, missing data compensation, and redundancy filtering. Arrows indicate the bidirectional mapping path, with rule numbers attached, and dashed boxes indicate default value filling and redundancy removal stages. This application obtains the target mapping data file through an intermediate model, improving version compatibility, scalability, and maintainability.

[0060] Further, the initial mapping data file is converted to obtain the target mapping data file, including the following steps:

[0061] Convert the initial mapping data file into an intermediate model data file based on the first major version number;

[0062] The first rule base maps the intermediate model data file to the target mapping data file with the same second major version number. The first rule base is used to map the intermediate model data file to a file that the target mapping engine can parse.

[0063] In this embodiment, the intermediate model data file is a standardized intermediate representation format used to uniformly store all mapping data structures. Essentially, the intermediate model data file is a semantically complete general map data model independent of specific engine versions. This intermediate model covers all possible map elements in intelligent driving mapping (such as lane lines, traffic signs, curbs, traffic lights, high-precision positioning points, etc.) and their complete attribute fields (location coordinates, semantic labels, topological relationships, confidence levels, timestamps, etc.). It adopts a structured and scalable data organization method to ensure that no semantic information of the original data is lost. The intermediate model is not bound to the storage format or field naming rules of any specific engine, but rather acts as a bridge connecting different versions of source data and the target mapping engine, achieving data normalization processing.

[0064] The first rule base is a set of rules used to implement bidirectional mapping from intermediate model data files to target mapping data files. This rule base is stored in a structured configuration file (such as YAML / JSON) and includes data type conversion logic, default value strategies for missing fields, and rules for discarding redundant fields. For example, when the "lane width" field in the source version is an integer (unit: meters), while the intermediate model requires a floating-point number, the rule base defines a conversion function; when the target mapping engine adds a "dynamic obstacle semantics" field and the source data has no corresponding value, the rule base specifies that it should be filled with "0" by default. The first rule base ensures that heterogeneous data is accurately normalized, and its modular design supports dynamic loading by version. This allows for updating only the rules when a new engine version is added, without refactoring the code, greatly improving the system's flexibility and sustainable evolution capabilities.

[0065] Converting the initial mapping data file to an intermediate model data file based on the first major version number can be understood as follows: Based on the first major version number recorded in the initial mapping data file, a data loading interface matching the first major version number is called, and the original mapping data is structurally mapped into a unified, version-independent intermediate model data file. The intermediate model uses standardized field definitions, covering all possible map features (such as lanes, curbs, traffic signs, elevation points, etc.) and their complete attributes (coordinates, semantics, topology, confidence level, timestamps, etc.), ensuring the semantic integrity of the original data. This process does not depend on the target mapping engine, focusing only on the structural features of the source version, achieving accurate normalization of heterogeneous data. Through these steps, the initial mapping data file is transformed into a universal intermediate format that can be reused by any subsequent target mapping engine, providing a consistent input foundation for subsequent conversions and significantly improving the scalability and maintenance efficiency of compatibility processing.

[0066] For example, during a system upgrade, the Intelligent Driving Center received a batch of offline map data (.map_v21) generated using the V2.1 main version mapping engine. In this version, the lane line field is "lane_width_i32" (32-bit integer), and "lane_type" is an enumeration value (1-5), without including the "dynamic semantics" field. After the system starts the conversion process, the version reading module identifies the main version number as 2.1, and then loads the corresponding mapping rules for v2.1 → intermediate model from the preset rule library: dividing "lane_width_i32" by 1000 to convert it to the floating-point type "lane_width_m", mapping "lane_type" to the standard enumeration "LANE_TYPE_CENTERLINE", etc., and injecting the default value "NONE" into the missing "dynamic_semantic" field. The preset rule library also defines that the coordinate system is uniformly converted from "local coordinates" to "WGS84+UTM" benchmark. Ultimately, all data is integrated into an intermediate model data file (.midmap) conforming to the Protobuf definition, containing a complete set of fields, such as "lane_width_m: 3.5, lane_type: LANE_TYPE_CENTERLINE, dynamic_semantic: NONE". This intermediate model data file can be reused by any subsequent target version (such as V3.0, V4.0) without parsing the original .v21 format, achieving the technical effect of "one-time conversion, universal for multiple versions".

[0067] Mapping the intermediate model data file's file format to the target mapping data file, which is consistent with the second major version number, using the first rule base can be understood as loading the corresponding "export rule subset" from the first rule base based on the second major version number of the target mapping engine. This reconstructs the standardized intermediate model data file into an output file that conforms to the target mapping engine's expected format. This process does not modify the intermediate model itself; instead, it dynamically specifies strategies such as field pruning, renaming, type conversion, and redundancy padding through the first rule base to achieve data format conversion. This avoids loading failures caused by missing fields or format inconsistencies, simplifying data migration costs during engine upgrades.

[0068] For example, when adapting the intermediate model file (.midmap) to the target mapping engine V3.0, the system reads its major version number as 3.0 and then loads the export rule subset for "intermediate model → V3.0" from the first rule base. V3.0 adds the fields "lane_curvature" and "road_marking_strength", and requires the "lane_width" field to be in float32 format and named "lane_width_f32". The rule base defines: multiply "lane_width_m" in the intermediate model by 1000 and assign it to "lane_width_f32" (unit from meters to millimeters), and dynamically calculate the "lane_curvature" value based on the curvature algorithm (three-point fitting) of the lane point sequence in the intermediate model, filling it with a floating-point value in the range of 0.001 to 0.05; for old data that did not have the "road_marking_strength" field, fill it with the default value of 0.8. At the same time, the rule base automatically removes the "lane_color_flag" field, which existed in V2.1 but is deprecated in V3.0. The final output is a standard V3.0 format .map_v30 file, whose structure fully conforms to the target mapping engine's .proto definition. It can be directly loaded, rendered, and used for path planning by the new system without any compatibility layer.

[0069] As can be seen from the above steps, the heterogeneous initial data is uniformly transformed into semantically complete and structurally standardized intermediate model data files based on the first major version number, eliminating the problem of source data format fragmentation. The intermediate model data files are dynamically mapped to the format required by the target mapping engine according to the first rule base, so that a single intermediate model data file can be adapted to any number of subsequent engine versions, avoiding the need to develop parsing logic separately for each version, thereby reducing maintenance complexity and improving system flexibility and iteration efficiency.

[0070] Furthermore, the initial mapping data file is converted into an intermediate model data file based on the first major version number, including the following steps:

[0071] By calling the data loading library corresponding to the first major version number, the data loading interface adapted to the first major version number is determined;

[0072] The initial mapping data file is converted into an intermediate model data file based on the data loading interface and the second rule base. The second rule base is used to record the conversion rules between the initial mapping data file and the intermediate model data file.

[0073] In this embodiment of the application, the data loading library is a set of dynamically loadable plug-in modules pre-built for different mapping engine versions. Each sub-library corresponds to a specific initial mapping data major version number (such as v2.1, v3.0, etc.) and contains a data parser, file header parser, field mapper and binary / structured format decoding logic specific to that version.

[0074] The data loading interface defines a unified input and output specification (e.g., input: original file path; output: structured intermediate object), shielding the differences in underlying file formats. Regardless of whether the source file is binary, JSON, protobuf, or a custom format, the interface returns a unified intermediate data structure containing all map features and their attributes.

[0075] The second rule base is a collection of rules used to implement a two-way mapping from the initial mapping data file to the intermediate model data file. It is stored in a structured format (such as YAML / JSON) and includes logic for field name mapping, data type conversion, unit conversion, default value filling, and missing field compensation. For example, the "lane_width_i32" field in v2.1 is divided by 1000 and assigned to the "lane_width_m" field in the intermediate model, and "sign_type_enum" is mapped to the standardized "TRAFFIC_SIGN_STOP", etc. The rule base also supports conditional expressions (such as "if road_type=HIGHWAY, then assign lane_count=4") to achieve intelligent conversion.

[0076] By calling the data loading library corresponding to the first major version number, determining the data loading interface adapted to the first major version number can be understood as automatically retrieving a pre-set set of versioned data loading libraries by identifying the major version number embedded in the initial mapping data file (such as v2.1), and dynamically loading the plugin module (such as DataLoader_v2.1.dll) that matches the major version number (such as v2.1). This module encapsulates the underlying parsing logic for the file structure specific to this version (such as field offsets, byte alignment, encoding methods, and compression algorithms) and provides a standard interface. By calling this unified interface, structured and parsable raw data objects can be obtained.

[0077] For example, an offline test data file is in .map_v2.1 format and uses a custom binary structure. The lane line field uses a 32-bit signed integer to represent the width (unit: mm), and the coordinates use a local Cartesian coordinate system. There is no timestamp field. After system startup, the version number "2.1" in the file header is read, and then the module DataLoader_v2.1.so is loaded from the loading library directory. This module contains a byte stream parser for .map_v2.1, which can correctly parse the lane width field with an offset of 0x100, identify the coordinate system reference as "Carla-Local," and automatically fill in missing timestamps as 0. The exported unified interface returns a MapDataObject containing the fields lane_width_mm: 3500, coordinates: [[x1, y1], [x2, y2]...], and timestamp: 0. The upper-layer conversion module can obtain this object simply by loader.load("file.map_v2.1") without needing to know its binary layout. When a new version 2.5 is added later, only DataLoader_v2.5.so needs to be added; the core system does not need to be modified at all.

[0078] Converting the initial mapping data file into an intermediate model data file using the data loading interface and the second rule base can be understood as follows: After obtaining a standardized initial mapping data file from the data loading interface, the initial mapping data file is mapped item by item to a unified intermediate model data structure based on the second rule base, resulting in the intermediate model data file. This process does not depend on the source format, but only on the rule definition, ensuring that different versions of the original data, after being processed by unified rules, output completely consistent intermediate model data files. This lays a semantically consistent and structurally clear foundation for subsequent output conversion for the target mapping engine.

[0079] For example, the initial mapping data file is obtained through the data loading interface: lane_width_mm: 3500, lane_type: 2, road_type: "HIGHWAY". The second rule base defines: lane_width_mm, lane_width_m = lane_width_mm / 1000.0, lane_type: 2, lane_type = LANE_TYPE_CENTERLINE, road_type: "HIGHWAY" → lane_count = 4, and sets the default value "NONE" for the missing dynamic_semantic field. The system executes the rules item by item: dividing 3500 by 1000 to get 3.5, and assigning it to the lane_width_m of the intermediate model; mapping the integer 2 to the enumeration LANE_TYPE_CENTERLINE; automatically inferring and adding lane_count: 4 based on the road type; and replacing dynamic_semantic with "NONE". The final output intermediate model data file is: {lane_width_m: 3.5, lane_type: LANE_TYPE_CENTERLINE, lane_count: 4, dynamic_semantic: NONE, coordinates: [...]}.

[0080] As can be seen, the system automatically matches a dedicated loading library based on the major version number, eliminating hard-coded parsing logic and improving scalability and stability. Subsequently, based on a configurable second rule base, heterogeneous raw data is standardized into a unified intermediate model, resolving the format fragmentation problem. These steps support rapid adaptation to new and old versions, significantly reducing maintenance costs while ensuring data semantic consistency. This lays a solid foundation for the output of the subsequent target mapping engine, improves the reusability of historical data, and enhances the efficient cross-version compatibility of mapping data.

[0081] Furthermore, the target mapping data file is validated to obtain the validation results, including the following steps:

[0082] The target mapping data file is verified based on data integrity rules and data correctness rules;

[0083] If the target mapping data file is not missing or corrupted, and the target mapping data file conforms to the parsing specifications of the target mapping engine, the verification result is determined to be successful.

[0084] If the target mapping data file is missing or corrupted, or if the target mapping data file does not conform to the parsing specifications of the target mapping engine, the verification result is determined to be verification failure.

[0085] In this embodiment, data integrity rules refer to the criteria used to verify whether the target mapping data file has a complete structure and necessary elements. These include, but are not limited to: the number of fields in all map elements (such as lane lines, traffic signs, road boundaries, and semantic labels) is consistent with expectations; the coordinate point sequence of each element is not empty and is continuous; key metadata (such as version number, timestamp, coordinate system, and data scale statistics) exists and is valid; and there are no byte-level holes, file truncation, or serialization anomalies. Data integrity rules ensure that the data has readable physical and logical integrity.

[0086] Data correctness rules refer to the criteria used to verify whether the target mapping data conforms to the semantic specifications and parsing contract required by the target mapping engine. These include: field data types (such as floating-point, enumeration, array) are consistent with the engine's expectations; numerical ranges are compliant (e.g., lane width is within 0.1~5.0 meters); coordinate systems match the reference frame (e.g., WGS84 or local coordinate system); relationships are correct (e.g., the topological connection between lanes and intersections is valid); and field naming is completely consistent with the protocol definition. Data correctness rules ensure that the data can be correctly parsed and semantically correct, guaranteeing the normal functioning of the engine after loading.

[0087] Verifying the target mapping data file based on data integrity and data correctness rules can be understood as automatically verifying the converted data file from two dimensions: "structural integrity" and "semantic compliance," through a pre-defined dual verification mechanism. Integrity rules check whether the data is complete, whether fields exist, whether coordinates are continuous, and whether metadata is complete. Correctness rules verify whether the data format, type, range, coordinate system, and topological relationships strictly conform to the parsing protocol and semantic specifications of the target mapping engine; no restrictions are imposed here.

[0088] If the target mapping data file is found to be free of missing or corrupted data and conforms to the parsing specifications of the target mapping engine, the verification result is deemed successful. This means that if the target mapping data file is free of missing or corrupted data and conforms to the parsing specifications of the target mapping engine, it is determined that the target mapping data file has been successfully adapted to the target mapping engine and can be safely used in subsequent intelligent driving perception, positioning, or planning modules without human intervention.

[0089] In response to the situation where the target mapping data file is missing or corrupted, or the target mapping data file does not conform to the parsing specifications of the target mapping engine, the verification result is determined to be verification failure. This can be understood as the target mapping data file failing verification when it is identified that the target mapping data file is missing or corrupted, or the target mapping engine cannot parse the target mapping data file normally.

[0090] It can be seen that the dual-dimensional closed-loop verification of "integrity + correctness" significantly improves the reliability and security of mapping data conversion. Data integrity rules ensure that the target file has no structural gaps, missing fields, or corrupted bytes, while data correctness rules verify semantic compliance, ensuring that field types, units, coordinate systems, and topological relationships fully match the parsing contract of the target mapping engine, avoiding runtime crashes or misjudgments caused by format discrepancies. Through these steps, the on-site failure rate due to compatibility issues is reduced, and data acquisition costs are lowered.

[0091] Furthermore, the data processing method also includes the following steps:

[0092] If the verification result is successful and the target mapping data file can be opened normally by the target mapping engine, the target mapping data file conversion is confirmed to be successful.

[0093] In this embodiment, a successful conversion of the target mapping data file can be understood as the converted file not only meeting data integrity rules at the structural level (e.g., complete fields, no missing or damaged fields) but also strictly conforming to the target mapping engine's protocol specifications at the semantic level (e.g., consistent coordinate system, matching feature types, correct topological relationships), and passing the end-to-end verification of the engine's underlying parsing module. The target mapping engine's successful opening of the target mapping data file indicates that the data can be accurately mapped to the memory structure, and map features can be normally invoked by the perception, positioning, or planning modules without abnormal interruptions, data out-of-bounds errors, or format parsing errors. This step ensures the engineering effectiveness of the conversion algorithm in a real-world operating environment, eliminates potential dynamic compatibility defects that might be missed by relying solely on static verification, and achieves a complete closed loop from format conversion to functional usability.

[0094] As can be seen, the above steps realize the final verification closed loop from format validation to system empirical verification, effectively avoiding semantic deviations or runtime compatibility risks that may exist by relying solely on rule matching, improving the reliability of data reuse and system stability, and reducing debugging costs and functional failure risks caused by version incompatibility.

[0095] Furthermore, the data processing method also includes the following steps:

[0096] If the verification result is "verification failed" or the target mapping data file cannot be opened normally by the target mapping engine, it is determined that the target mapping data file conversion failed.

[0097] In this embodiment of the application, the determination that the conversion of the target mapping data file has failed can be understood as follows: when the verification result is that the verification has failed, or the target mapping engine cannot load and parse the target mapping data file normally, it can be determined that the conversion process has failed to achieve the expected function, and the conversion has been confirmed to have failed.

[0098] For example, the above steps indicate that the data still has defects in terms of structural integrity or semantic compliance, or that although the target mapping data file passes static verification, it exposes deep-seated problems of incompatibility with the target mapping engine protocol during dynamic loading, such as incorrect field mapping, misaligned coordinate systems, and mismatched topology. By promptly identifying and marking transformation failures, it is possible to effectively prevent erroneous data from flowing into the production environment, prevent the spread of systemic risks, and provide clear feedback signals for debugging, identifying specific deviations in the transformation rule base or data loading module. This supports closed-loop optimization and precise repair of version iterations, ensuring data security and reliability during system evolution.

[0099] As can be seen, through the above steps, when verification fails or the target mapping engine cannot load the data normally, the conversion is determined to have failed. This effectively prevents incompatible data from entering the downstream system, thus preventing operational risks such as engine crashes, abnormal positioning, or perception failures caused by format errors. This step provides reliable quality feedback for the conversion process, accurately locates the source of the problem, assists in quickly fixing rule defects, improves debugging efficiency, and enhances system stability and the reliability of data reconstruction.

[0100] Furthermore, the data processing method also includes the following steps:

[0101] In response to the failure of converting the target mapping data file, the initial mapping data file is converted to a new format based on the prompt message. The prompt message indicates the reason for the failure to convert the initial mapping data file to the target mapping data file.

[0102] In this embodiment, the prompt information refers to a structured diagnostic report automatically generated and output by the verification module after determining that the conversion of the target mapping data file has failed. This report records the root cause of the data format conversion failure, including but not limited to: data integrity anomalies: such as missing key map features (e.g., empty or abnormally long fields such as road topology, lane lines, and signs), corrupted data frames, truncated byte streams, or checksum mismatches; data correctness violations: such as mismatched field types (e.g., coordinates mistakenly converted from float to int), conflicting unit systems (e.g., mixing meters and centimeters), misaligned coordinate systems (wrong conversion between WGS84 and the local coordinate system), semantic violations of features (e.g., a no-turn sign is incorrectly mapped to a variable lane); missing version mappings: such as fields in the source version that are obsolete or undefined by the target mapping engine, and no corresponding compatible mapping in the conversion rule base; engine protocol incompatibility: such as the metadata header format, version identifier, or extended attributes required by the target mapping engine not being correctly filled.

[0103] Responding to a target mapping data file conversion failure, the initial mapping data file undergoes a format conversion based on the prompt message. This can be understood as re-converting the initial mapping data file based on the prompt message when the target mapping data file conversion fails. The prompt message can identify the root cause of the conversion failure, including but not limited to: missing key map feature fields, data type or character length mismatch, incorrect coordinate system conversion parameters, incompatible metadata header format, or semantic incompatibility issues such as source version-specific attributes not having corresponding definitions in the target mapping engine. Based on the prompt message, the system can dynamically call the adaptation rule module to correct the source data mapping path or supplement missing fields, and then re-trigger the data format conversion process to ensure that the repaired data conforms to the parsing specifications of the target mapping engine. This reduces manual troubleshooting costs and improves the automation level and robustness of data compatibility processing.

[0104] As can be seen, by following the above steps, in response to conversion failure, the initial mapping data file is corrected based on the prompt information and the data format conversion is retried. This can locate and repair key issues such as missing fields, type mismatch, or protocol violations, avoid blind retries, significantly improve repair efficiency and success rate, thereby reducing the cost of manual intervention and ensuring that historical data remains available in engine iterations.

[0105] Figure 3 This is a flowchart illustrating an optional conversion method according to an embodiment of this application, such as... Figure 3As shown, the intelligent driving mapping data and mapping engine compatibility conversion tool is launched. This tool reads the mapping engine version information from the intelligent driving mapping data file in the specified path. Simultaneously, it obtains the version information of the mapping engine software in the specified path or the version information of the target mapping engine from the selected mapping engine version information list. First, the major version number is extracted from the mapping data engine version information using the compatibility conversion tool. Then, the major version number of the mapping engine in the mapping data file is compared with the major version number of the target mapping engine. If they match, the mapping file is used directly.

[0106] When the major version number of the mapping engine in the mapping file is inconsistent with the major version number of the target mapping engine, a data conversion operation is required. At this time, the compatibility conversion tool, based on the mapping engine version information recorded in the mapping data file, calls the data loading interface adapted to that version number from the data loading library to efficiently load the data file into memory. After loading, the compatibility conversion tool performs the conversion work according to the rules set in the conversion rule library, mapping the same fields of the same map features one-to-one. Since the intermediate data model covers all field information of each map feature in all mapping data, and the full field information of each map feature is a subset of the intermediate model, the intelligent driving mapping data converts the mapping data file into a unified intermediate model data file according to the conversion rule library. Finally, based on the target mapping engine version information, the compatibility conversion tool, according to the rules in the export rule library that also map the same fields of the same map features one-to-one, further converts the intermediate model data into a data file completely consistent with the target mapping engine version, thus completing the entire data format conversion process.

[0107] After conversion, the verification module verifies the integrity and correctness of the converted data files. Data integrity verification checks for missing or corrupted data, and confirms the completeness of all data element types and their statistical information. Data correctness verification focuses on ensuring the data conforms to the parsing specifications of the current mapping data engine. After verification, the conversion result is determined by whether software using the map data can successfully load and utilize the new map data. If the software can successfully load and utilize the new data, the data conversion is successful, and the entire process is complete. If the software cannot load or utilize the new data, the conversion is considered a failure, and the system will promptly provide a clear prompt to determine the reason for the failure.

[0108] Figure 4 This is a schematic diagram of an optional conversion system according to an embodiment of this application, such as... Figure 4As shown, the system includes: a version information reading module, a version comparison module, an intermediate model conversion module, a target data engine conversion module, and a data verification module. The version information reading module reads the mapping engine version information from the intelligent driving mapping data file and can also obtain the current mapping engine version information; it also supports manually selecting the target mapping engine version information. The version comparison module compares the mapping engine version information in the mapping data file with the target mapping engine version information and outputs corresponding judgment signals based on the comparison results. When the judgment signal output by the version comparison module indicates a version inconsistency, the intermediate model conversion module calls the data loading module to convert the intelligent driving mapping data into unified intermediate model data according to the input rule base. Then, the target data engine conversion module calls the data export module to convert the intermediate model data according to the target mapping engine version information and the output rule base, ultimately generating a data file consistent with the target mapping engine version information. The data verification module performs a comprehensive verification of the converted data file and outputs the verification results. Specifically, the verification module performs operations such as format checks and attribute parsing on data feature types, statistical information of each feature, and each field of the data, based on the data format requirements of the target mapping engine, thereby ensuring the correctness and integrity of the data.

[0109] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0110] According to an embodiment of this application, an embodiment of a data processing apparatus is provided. It should be noted that the apparatus can be used to execute the above-described data processing method.

[0111] Figure 5 This is a schematic diagram of a data processing apparatus according to an embodiment of this application, such as... Figure 5As shown, the data processing device 500 includes: an acquisition module 501, used to acquire a first major version number corresponding to the original mapping engine and a second major version number corresponding to the target mapping engine, wherein the original mapping engine is the mapping engine corresponding to the initial mapping data file, the target mapping engine is the mapping engine to be used, and the initial mapping data file is the data file to be read; a conversion module 502, used to convert the format of the initial mapping data file to obtain the target mapping data file in response to the inconsistency between the first major version number and the second major version number, wherein the file format of the target mapping data file is a format that the target mapping engine can parse; a verification module 503, used to verify the target mapping data file and obtain a verification result; and a reading module 504, used to read the target mapping data file using the target mapping engine in response to the verification result being successful.

[0112] Furthermore, the conversion module 502 is also used to convert the initial mapping data file into an intermediate model data file according to the first major version number; and to map the file format of the intermediate model data file to the target mapping data file that is consistent with the second major version number through the first rule base, wherein the first rule base is used to map the intermediate model data file to a file that the target mapping engine can parse.

[0113] Furthermore, the conversion module 502 is also used to determine the data loading interface adapted to the first major version number by calling the data loading library corresponding to the first major version number; and to convert the initial mapping data file into an intermediate model data file according to the data loading interface and the second rule library, wherein the second rule library is used to record the conversion rules between the initial mapping data file and the intermediate model data file.

[0114] Furthermore, the verification module 503 is also used to verify the target mapping data file based on data integrity rules and data correctness rules; in response to the fact that the target mapping data file is not missing or damaged, and the target mapping data file conforms to the parsing specifications of the target mapping engine, the verification result is determined to be verification passed; in response to the fact that the target mapping data file is missing or damaged, or the target mapping data file does not conform to the parsing specifications of the target mapping engine, the verification result is determined to be verification failed.

[0115] Furthermore, the verification module 503 is also used to determine that the target mapping data file has been successfully converted if the verification result is successful and the target mapping data file is opened normally by the target mapping engine.

[0116] Furthermore, the verification module 503 is also used to determine that the target mapping data file conversion failed in response to a verification result of verification failure or the target mapping data file not being opened normally by the target mapping engine.

[0117] Furthermore, the conversion module 502 is also used to perform format conversion on the initial mapping data file based on the prompt information in response to the failure of the conversion of the target mapping data file. The prompt information is used to indicate the reason for the failure of the conversion from the initial mapping data file to the target mapping data file.

[0118] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer-readable storage medium, and the computer program is configured to perform the data processing method described in any of the above when it is run on a computer or processor.

[0119] Optionally, in this embodiment, the storage medium may be configured to store a computer program for performing the following steps:

[0120] Step S10: Obtain the first major version number corresponding to the original mapping engine and the second major version number corresponding to the target mapping engine. The original mapping engine is the mapping engine corresponding to the initial mapping data file, the target mapping engine is the mapping engine to be used, and the initial mapping data file is the data file to be read.

[0121] Step S12: In response to the inconsistency between the first major version number and the second major version number, the initial mapping data file is converted to a new format to obtain the target mapping data file. The target mapping data file is in a format that the target mapping engine can parse.

[0122] Step S14: Verify the target mapping data file and obtain the verification result;

[0123] Step S16: In response to the verification result being successful, the target mapping data file is read using the target mapping engine.

[0124] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the data processing method described in any of the preceding claims.

[0125] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0126] Step S10: Obtain the first major version number corresponding to the original mapping engine and the second major version number corresponding to the target mapping engine. The original mapping engine is the mapping engine corresponding to the initial mapping data file, the target mapping engine is the mapping engine to be used, and the initial mapping data file is the data file to be read.

[0127] Step S12: In response to the inconsistency between the first major version number and the second major version number, the initial mapping data file is converted to a new format to obtain the target mapping data file. The target mapping data file is in a format that the target mapping engine can parse.

[0128] Step S14: Verify the target mapping data file and obtain the verification result;

[0129] Step S16: In response to the verification result being successful, the target mapping data file is read using the target mapping engine.

[0130] According to another aspect of the embodiments of this application, a vehicle is also provided, including: a memory storing an executable program; and a processor for running the executable program, wherein the executable program performs the data processing method described in any of the above embodiments when running on the processor.

[0131] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0132] Step S10: Obtain the first major version number corresponding to the original mapping engine and the second major version number corresponding to the target mapping engine. The original mapping engine is the mapping engine corresponding to the initial mapping data file, the target mapping engine is the mapping engine to be used, and the initial mapping data file is the data file to be read.

[0133] Step S12: In response to the inconsistency between the first major version number and the second major version number, the initial mapping data file is converted to a new format to obtain the target mapping data file. The target mapping data file is in a format that the target mapping engine can parse.

[0134] Step S14: Verify the target mapping data file and obtain the verification result;

[0135] Step S16: In response to the verification result being successful, the target mapping data file is read using the target mapping engine.

[0136] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the data processing methods of various embodiments of this application, including:

[0137] Step S10: Obtain the first major version number corresponding to the original mapping engine and the second major version number corresponding to the target mapping engine. The original mapping engine is the mapping engine corresponding to the initial mapping data file, the target mapping engine is the mapping engine to be used, and the initial mapping data file is the data file to be read.

[0138] Step S12: In response to the inconsistency between the first major version number and the second major version number, the initial mapping data file is converted to a new format to obtain the target mapping data file. The target mapping data file is in a format that the target mapping engine can parse.

[0139] Step S14: Verify the target mapping data file and obtain the verification result;

[0140] Step S16: In response to the verification result being successful, the target mapping data file is read using the target mapping engine.

[0141] According to another aspect of the embodiments of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the data processing methods of various embodiments of this application, including:

[0142] Step S10: Obtain the first major version number corresponding to the original mapping engine and the second major version number corresponding to the target mapping engine. The original mapping engine is the mapping engine corresponding to the initial mapping data file, the target mapping engine is the mapping engine to be used, and the initial mapping data file is the data file to be read.

[0143] Step S12: In response to the inconsistency between the first major version number and the second major version number, the initial mapping data file is converted to a new format to obtain the target mapping data file. The target mapping data file is in a format that the target mapping engine can parse.

[0144] Step S14: Verify the target mapping data file and obtain the verification result;

[0145] Step S16: In response to the verification result being successful, the target mapping data file is read using the target mapping engine.

[0146] According to another aspect of the embodiments of this application, a computer program is also provided. When executed by a processor, the computer program implements the data processing methods of various embodiments of this application, including:

[0147] Step S10: Obtain the first major version number corresponding to the original mapping engine and the second major version number corresponding to the target mapping engine. The original mapping engine is the mapping engine corresponding to the initial mapping data file, the target mapping engine is the mapping engine to be used, and the initial mapping data file is the data file to be read.

[0148] Step S12: In response to the inconsistency between the first major version number and the second major version number, the initial mapping data file is converted to a new format to obtain the target mapping data file. The target mapping data file is in a format that the target mapping engine can parse.

[0149] Step S14: Verify the target mapping data file and obtain the verification result;

[0150] Step S16: In response to the verification result being successful, the target mapping data file is read using the target mapping engine.

[0151] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0152] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0153] 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 units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0154] Furthermore, the functional units in the various embodiments of this application 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0155] If the integrated unit 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 application, in essence, or the part that contributes to the prior art, or all or 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 described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0156] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A data processing method, characterized in that, include: Obtain the first major version number corresponding to the original mapping engine and the second major version number corresponding to the target mapping engine, wherein the original mapping engine is the mapping engine corresponding to the initial mapping data file, the target mapping engine is the mapping engine to be used, and the initial mapping data file is the data file to be read; In response to the inconsistency between the first major version number and the second major version number, the initial mapping data file is format-converted to obtain a target mapping data file, wherein the file format of the target mapping data file is a format that the target mapping engine can parse; The target mapping data file was verified, and the verification results were obtained. In response to the verification result being successful, the target mapping engine is used to read the target mapping data file.

2. The method according to claim 1, characterized in that, The step of converting the format of the initial mapping data file to obtain the target mapping data file includes: The initial mapping data file is converted into an intermediate model data file according to the first major version number; The intermediate model data file is mapped to the target mapping data file with the same major version number by a first rule base, wherein the first rule base is used to map the intermediate model data file to a file that the target mapping engine can parse.

3. The method according to claim 2, characterized in that, The step of converting the initial mapping data file into an intermediate model data file according to the first major version number includes: By calling the data loading library corresponding to the first major version number, the data loading interface adapted to the first major version number is determined; The initial mapping data file is converted into the intermediate model data file according to the data loading interface and the second rule base, wherein the second rule base is used to record the conversion rules between the initial mapping data file and the intermediate model data file.

4. The method according to claim 1, characterized in that, The verification of the target mapping data file, to obtain the verification result, includes: The target mapping data file is verified based on data integrity rules and data correctness rules; In response to the fact that the target mapping data file is not missing or corrupted, and that the target mapping data file conforms to the parsing specifications of the target mapping engine, the verification result is determined to be successful. In response to the absence or corruption of the target mapping data file, or the fact that the target mapping data file does not conform to the parsing specifications of the target mapping engine, the verification result is determined to be a verification failure.

5. The method according to claim 4, characterized in that, The method further includes: If the verification result is successful and the target mapping data file can be opened normally by the target mapping engine, it is determined that the target mapping data file has been successfully converted.

6. The method according to claim 5, characterized in that, The method further includes: If the verification result is that the verification failed, or if the target mapping data file cannot be opened normally by the target mapping engine, it is determined that the conversion of the target mapping data file has failed.

7. The method according to claim 6, characterized in that, The method further includes: In response to the failure of the conversion of the target mapping data file, the format of the initial mapping data file is converted based on the prompt information, wherein the prompt information is used to indicate the reason for the failure of the conversion of the initial mapping data file to the target mapping data file.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program is configured to perform the data processing method described in any one of claims 1 to 7 when executed on a computer or processor.

9. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the data processing method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the data processing method as described in any one of claims 1 to 7.

Images