Road element conversion method, system, medium, device and terminal

Abstract

The present invention belongs to the field of high-precision map technology and discloses a road element conversion method, system, medium, device, and terminal. The method constructs UML diagrams of road elements for OpenDRIVE and GDF, respectively; establishes a mapping model based on the types of roads and road-related elements common to OpenDRIVE and GDF; establishes conversion rules for element instances between the two standards based on the semantic mapping of concepts and attributes between OpenDRIVE and GDF elements; and implements conversion of OpenDRIVE element instances to GDF elements based on the mapping rules. Based on the differences in semantic descriptions and data structures of roads and related elements between OpenDRIVE and GDF, the present invention establishes a semantic mapping relationship between roads and related elements in the two standards, designs conversion rules between data structures, and fully leverages the advantages of each high-precision map standard to achieve effective conversion and fusion of high-precision map data.

Description

Technical Field

[0001] The present invention belongs to the field of high-precision map technology, and in particular relates to a road element conversion method, system, medium, equipment and terminal. Background Art

[0002] With the development of autonomous driving, map users are gradually shifting from humans to vehicles, and the demand for road data accuracy is becoming increasingly higher. High-precision maps, as an essential carrier and decision-making platform for autonomous driving, provide rich and detailed road information, playing a vital role in autonomous driving's perception, decision-making, planning, and control. Compared to traditional electronic navigation maps, high-precision maps place greater emphasis on the accuracy of the roads depicted and their practicality for autonomous driving.

[0003] Currently, mainstream international HD map standards include NDS (Navigation Data Standard) and OpenDRIVE. As a navigation data standard, NDS primarily constructs the HD map data model based on the lane group model, expressing non-road features by linking them to road entities. This ensures a high degree of coupling between features and road entities, resulting in high data efficiency. However, this also makes conversion to other formats more difficult. OpenDRIVE is an open file standard that focuses on describing the logical structure of road networks. It provides an exchange format for HD map static road networks. Published by VIRES Simulation since 2006, it is now widely used in autonomous driving simulation.

[0004] The Geographical Data File (GDF), a traditional navigation electronic map data standard, also added content for autonomous driving in GDF 5.1, released in 2020. Targeting intelligent transportation system applications and services, GDF details geographic database concepts, logical data models, and physical encoding formats. It provides a comprehensive and systematic description of geographic elements, encompassing not only roads and road-related information but also a wide range of other geographic elements.

[0005] From this we can see that GDF and OpenDRIVE are both standards related to road representation, and there are certain differences in their historical and technical backgrounds, as well as their applicable scopes and fields.

[0006] As a standard specification for high-precision maps, OpenDRIVE focuses on defining the construction of static road networks, making it highly targeted and applicable to autonomous driving. However, this focus also brings certain limitations. OpenDRIVE ignores the representation of other geographical features on the road, such as administrative divisions, gas stations, service areas, and residential areas, which can affect autonomous driving. For example, in autonomous driving, it can find nearby gas stations based on the driving route.

[0007] As an extension of traditional electronic navigation maps, GDF inherits the universal model of geographic elements for describing roads, providing a comprehensive and systematic description of traffic geographic elements. However, the GDF universal model was originally designed for map navigation rather than autonomous driving, and therefore lacks specificity in the application of high-precision maps for autonomous driving.

[0008] The OpenDRIVE and GDF data standards each have their own strengths, and their integration can fully leverage these advantages. For example, OpenDRIVE constructs a road network structure suitable for autonomous driving, while GDF's rich geographic features provide the contextual information necessary for autonomous driving. To leverage these complementary advantages, a high-precision map conversion method that integrates the OpenDRIVE and GDF formats is urgently needed.

[0009] Through the above analysis, the problems and defects of the existing technology are as follows:

[0010] (1) As a standard specification for static road networks, the OpenDRIVE standard ignores the expression of background information other than roads and road-related elements, including administrative divisions, gas stations, service areas, residential areas, etc., which affects the global planning, navigation and other functions of autonomous driving.

[0011] (2) The latest GDF standard adds high-precision map content to the classic GDF navigation standard. Therefore, although GDF has detailed expressions of roads, road-related information, and background information, it takes into account both standard navigation and high-precision maps, resulting in a complex data structure and redundant definitions (multiple definitions of the same element).

[0012] (3) High-precision map data collected with a single standard is difficult to share and disseminate across data platforms with different standards, resulting in low map utilization efficiency and, to a certain extent, limiting the use of high-precision maps in the field of autonomous driving.

[0013] (4) In summary, OpenDRIVE and GDF each have their own advantages and disadvantages. It is difficult for one format to replace the other. The situation where the two formats coexist in the same application still exists. Therefore, the need for mutual conversion between the two formats has been raised. Summary of the Invention

[0014] In response to the problems existing in the prior art, the present invention provides a road feature conversion method, system, medium, device and terminal, and in particular relates to a road feature conversion method, system, medium, device and terminal based on the OpenDRIVE and GDF standards. The high-precision maps defined by OpenDRIVE and GDF are converted through feature mapping, rule construction and other methods to achieve multi-source data fusion and cross-standard sharing of high-precision map data.

[0015] The present invention is implemented as follows: a road element conversion method, the road element conversion method comprising: constructing UML (Unified Modeling Language) diagrams of road elements in OpenDRIVE and GDF respectively; establishing a mapping pattern based on the types of roads and road-related elements common to OpenDRIVE and GDF; establishing conversion rules for element instances between the two standards based on the mapping of concepts and attributes between OpenDRIVE and GDF elements in semantic definitions; and achieving conversion of element instances in OpenDRIVE to GDF elements based on the mapping rules.

[0016] Furthermore, the road element conversion method includes the following steps:

[0017] Step 1: Build the UML diagram of OpenDRIVE road elements;

[0018] Step 2: Construct the UML diagram of the GDF road elements;

[0019] Step 3: Establish a mapping between OpenDRIVE and GDF road features;

[0020] Step 4: Establish a conversion rule for feature instances between the two standards; based on the established mapping rule, convert the feature instance of one standard into the feature instance of another standard.

[0021] Furthermore, the construction of the OpenDRIVE road element UML diagram in step 1 includes:

[0022] Based on ASAM OpenDRIVE version 1.7.0, a UML diagram of roads and road-related element types was developed to express the logical structure between element types. The OpenDRIVE compilation includes:

[0023] (1) Based on the description of roads and related elements in OpenDRIVE, the definitions of road elements and road-related elements in OpenDRIVE are extracted;

[0024] (2) Establish semantic relationships between element types, including hierarchical relationships, to form UML diagrams that represent hierarchical classification between elements;

[0025] (3) Extract the relevant attributes, expressions and data types contained in each element.

[0026] Furthermore, the construction of the GDF road element UML diagram in step 2 includes:

[0027] Establish a subset of GDF 5.1 road and road-related feature types, including:

[0028] (1) Extract road elements and road-related elements from GDF and form subsets, forming two parts of GDF: road and related element subsets and others;

[0029] (2) Establish a UML model for the elements mapped by OpenDRIVE in GDF.

[0030] Furthermore, the mapping between OpenDRIVE and GDF road features in step 3 is established as follows:

[0031] A mapping model between GDF 5.1 and OpenDRIVE is established for roads and related elements that are common to both standards. The conceptual model for building the mapping includes:

[0032] According to the subset of roads and related features mapped to OpenDRIVE in GDF, the correspondence between each feature and OpenDRIVE is established, including one-to-one correspondence, many-to-one correspondence and one-to-many correspondence.

[0033] One-to-one correspondence includes Junction-IntersectionBelt and Road Marking-Road Marking. Among them, the Junction element in OpenDRIVE represents an intersection on the road, and the IntersectionBelt element in GDF also represents an intersection on the road. The two express the same thing and have a one-to-one correspondence.

[0034] Many-to-one correspondence includes Road-RoadBelt. For Road, OpenDRIVE stipulates that the Road element represents a section of road. Between two intersections, if the road attributes remain unchanged, one Road is used to represent it; if the road attributes change, two or more Roads are used to represent it. GDF stipulates that the RoadBelt element represents the road between two intersections, and the same RoadBelt corresponds to one to multiple Roads.

[0035] One-to-many correspondences include Lane-{LaneBeltElement, Road Furniture Feature}, LaneSection-LaneSection, and Objects-{Road Furniture Feature, Structure}. The Objects feature type in OpenDRIVE covers the feature types of GDF, including obstacles and pillars in the Road Furniture Feature feature class and bridges and tunnels in the Structure feature class.

[0036] Furthermore, the construction of the conversion rules in step 4 includes:

[0037] Within the conceptual model framework, for any corresponding relationship, a semantic mapping of concepts and attributes is established between the corresponding elements based on the definitions of relevant elements in GDF 5.1 and OpenDRIVE, and conversion rules are established; among them, the conversion rules include the conversion between data structure and semantics.

[0038] (1) For any corresponding relationship, determine the definitions of the mutually mapped elements in the standard, including the element concepts and attribute semantics;

[0039] (2) Establishing semantic relationships between mutually mapped elements, including conceptual semantic relationships and spatial semantic relationships;

[0040] (3) Define the conversion rules between mutually mapped elements.

[0041] Another object of the present invention is to provide a road element conversion system applying the road element conversion method, the road element conversion system comprising:

[0042] UML diagram construction module, used to construct UML diagrams of road elements for OpenDRIVE and GDF respectively;

[0043] Feature mapping module, used to establish the mapping between OpenDRIVE and GDF road features;

[0044] A conversion rule establishment module is used to establish conversion rules between element instances of two standards;

[0045] The feature instance conversion module is used to convert a standard feature instance into another standard feature instance according to the established mapping rules.

[0046] Another object of the present invention is to provide a computer device, which includes a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the road element conversion method.

[0047] Another object of the present invention is to provide a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to execute the steps of the road element conversion method.

[0048] Another object of the present invention is to provide an information data processing terminal, which is used to implement the road element conversion system.

[0049] In combination with the above technical solutions and the technical problems solved, the advantages and positive effects of the technical solutions to be protected by the present invention are as follows:

[0050] First, in view of the technical problems existing in the above-mentioned prior art and the difficulty of solving these problems, we closely combine the technical solutions to be protected by the present invention and the results and data during the research and development process, and conduct a detailed and in-depth analysis of how the technical solutions of the present invention solve the technical problems and some creative technical effects brought about by solving the problems. The specific description is as follows:

[0051] The OpenDRIVE and GDF data standards each have their own advantages, and their integration can fully leverage these strengths. For example, OpenDRIVE constructs a road network structure suitable for autonomous driving, while GDF's rich geographic elements provide the background information required for autonomous driving. By leveraging these complementary advantages, this paper constructs a high-precision map framework that integrates the OpenDRIVE and GDF formats, establishes a mapping model for the two standards in road descriptions, and proposes a corresponding format conversion method.

[0052] During the autonomous driving process, not only detailed and rich lane information is needed for local planning and decision-making, but also off-lane information such as administrative areas and points of interest is needed for global planning. As two different map standards, GDF and OpenDRIVE differ in the expression and construction of autonomous driving maps. GDF covers lane information and off-lane information, while OpenDRIVE focuses on lane information. Although GDF has a description of lane information, it is not as popular as OpenDRIVE. Therefore, in order to achieve the integration and complementary advantages of the two standards, it is necessary to construct conversion rules between them regarding roads and related elements. Based on the existing GDF and OpenDRIVE standards, the present invention analyzes and compares their descriptions of road-related elements, and constructs mapping and conversion rules between corresponding elements. That is, the present invention performs semantic mapping and structural conversion of road elements on OpenDRIVE and GDF 5.1, and realizes multi-source data fusion and cross-standard sharing of high-precision maps.

[0053] This invention relates to methods for converting between different standards for high-precision autonomous driving maps, particularly between two internationally recognized standards. Given that road-related elements are common to both OpenDRIVE and GDF, this invention establishes and analyzes mapping patterns and conversion rules for road-related elements between GDF and OpenDRIVE from a spatial and semantic perspective. This provides technical support for the reuse and sharing of autonomous driving map data, as well as the construction of an integrated data framework for global and local planning in autonomous driving.

[0054] Second, considering the technical solution as a whole or from the perspective of the product, the technical effects and advantages of the technical solution to be protected by the present invention are described in detail as follows:

[0055] The road feature conversion system based on OpenDRIVE and GDF standards provided by the present invention establishes a semantic mapping relationship between roads and related features in the two standards, and designs conversion rules between data structures. While giving full play to the advantages of each high-precision map standard, it realizes the effective conversion and fusion of high-precision map stock data, and provides technical support for the fusion, reuse and conversion of multi-source heterogeneous data of high-precision maps.

[0056] The high-precision map data conversion system provided by this invention can support distributed data storage, exchange, sharing, fusion, and integration applications between central cloud, edge cloud, and autonomous vehicle systems. Because autonomous vehicles use different standard formats, different data standards must be processed between vehicles, between vehicles and edge clouds, between vehicles and central clouds, and between edge clouds and central clouds. For example, data sharing, fusion, and integration require the construction of a mutual conversion system for different data standards.

[0057] This invention constructs a conversion system between two international standards in the field of high-precision maps, providing a technical framework and system process for data conversion between other international standards, between domestic standards, and between international and domestic standards in the field of high-precision maps.

[0058] Third, as auxiliary evidence for the inventiveness of the claims of the present invention, it is also reflected in the following important aspects:

[0059] (1) The expected benefits and commercial value of the technical solution of the present invention after transformation are:

[0060] This invention constructs mapping rules for autonomous driving map standards, which can realize the reuse, sharing, fusion and integration of multi-source heterogeneous data between different vehicles, between vehicles and the cloud, and between vehicles and road tests through the conversion between different high-precision map data, and give full play to the maximum value of multi-source data: by improving data utilization and increasing data value, it can enhance the effectiveness and safety of autonomous driving, improve road use efficiency, reduce vehicle energy consumption, and save transportation costs and personal time costs.

[0061] By converting commercial GDF data into open-source OpenDRIVE data, high-precision map data can be made open and open-source, thereby maximizing the dissemination, sharing, and value-added of data.

[0062] (2) The technical solution of the present invention fills the technical gap in the industry at home and abroad:

[0063] Currently, the only domestic patent that covers the rules for converting OpenDRIVE data to Apollo data is the patent "A Method for Converting Map Formats Based on Different Protocols." A method for converting OpenDRIVE to GDF data has not yet been discovered. Internationally, research on the conversion of high-precision map formats such as OpenStreetMap, Lanelet / Lanelet2, and OpenDRIVE has not yet been conducted, but conversion between OpenDRIVE and GDF data formats has not been discovered. This invention fills the gap in OpenDRIVE to GDF data conversion.

[0064] (3) The technical solution of the present invention solves the technical problems that people have been eager to solve but have never been able to solve successfully:

[0065] OpenDRIVE and GDF have different definitions of the same HD map elements in terms of naming, semantics, geometry, etc., that is, HD map data differs at the schema level, which hinders the direct reuse and format conversion of HD map data from one standard to another. This means that data conversion between standards requires not only the conversion of naming rules and geometric paradigms, but also the conversion of data schemas between standards. The present invention establishes mapping rules between standards, realizes semantic mapping between data schemas, solves the problem of conversion and sharing of autonomous driving map data between the two standards of OpenDRIVE and GDF, and provides a technical foundation for cross-standard and cross-platform sharing, integration, and services of HD map data in the vehicle-road-side-cloud framework.

[0066] GDF, which includes HD maps, is a relatively recent development. Since its introduction in March 2020, little research has been conducted on the mapping and format conversion between HD maps and other standards. This paper establishes a connection between GDF and OpenDRIVE, providing examples for data conversion and integration between the two, and a technical framework for mapping and format conversion between different HD map standards. BRIEF DESCRIPTION OF THE DRAWINGS

[0067] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments of the present invention. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0068] Figure 1 This is a flow chart of a road element conversion method provided by an embodiment of the present invention;

[0069] Figure 2 is a UML diagram of the OpenDRIVE elements provided by an embodiment of the present invention;

[0070] Figure 3 It is a UML diagram of a GDF mappable element provided by an embodiment of the present invention;

[0071] Figure 4 This is a corresponding diagram of OpenDRIVE and GDF elements provided by an embodiment of the present invention;

[0072] Figure 5A is an original road example map provided by an embodiment of the present invention;

[0073] Figure 5B A road instance diagram constructed in the OpenDRIVE format provided by an embodiment of the present invention;

[0074] Figure 5C A road instance diagram constructed in the GDF format provided by an embodiment of the present invention;

[0075] Figure 6A This is a UML diagram of a road feature class of OpenDRIVE provided by an embodiment of the present invention;

[0076] Figure 6B is a diagram showing the relationship between the OpenDRIVE mode and instance data provided by an embodiment of the present invention;

[0077] Figure 7A This is a UML diagram of a road element of the GDF provided by an embodiment of the present invention;

[0078] Figure 7BIt is a correspondence diagram between the GDF pattern and instance data provided by an embodiment of the present invention;

[0079] Figure 8 It is a schematic diagram of two standard mappings provided by an embodiment of the present invention;

[0080] Figure 9 This is an OpenDRIVE lane element ID conversion diagram provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0081] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0082] In response to the problems existing in the prior art, the present invention provides a road element conversion method, system, medium, device and terminal. The present invention is described in detail below with reference to the accompanying drawings.

[0083] In order to enable those skilled in the art to fully understand how to implement the present invention, this section provides an explanatory embodiment that expands on the technical solutions of the claims.

[0084] As a preferred embodiment, Figure 1 As shown, the road feature conversion method based on the OpenDRIVE and GDF standards provided by an embodiment of the present invention is to establish a mapping between the types of roads and road-related features in OpenDRIVE and GDF, and to realize the conversion of feature instances between the two standards. Specifically, it includes the following steps:

[0085] S101: Construct the UML diagram of road elements of OpenDRIVE.

[0086] Based on ASAM OpenDRIVE version 1.7.0, a UML diagram of roads and road-related element types is formed to express the logical structure between element types.

[0087] S102: Constructing a UML diagram of the GDF road elements.

[0088] Establish a subset of GDF 5.1 road and road-related feature types.

[0089] S103: Establish a mapping between OpenDRIVE and GDF road features.

[0090] For roads and related elements that are common to GDF 5.1 and OpenDRIVE, a mapping model between the two standards is established.

[0091] S104: Establishing conversion rules for feature instances between two standards.

[0092] S105: According to the established mapping rule, a standard feature instance is converted into another standard feature instance.

[0093] The arrangement of OpenDRIVE in step S101 provided in the embodiment of the present invention includes:

[0094] (1) Based on the description of roads and related elements in OpenDRIVE, the definitions of road elements and road-related elements in OpenDRIVE are extracted.

[0095] (2) Establish semantic relationships between element types, including hierarchical relationships, to form a UML diagram that represents hierarchical classification between elements, such as Figure 2 shown.

[0096] (3) Extract the relevant attributes contained in each element, its expression method and data type.

[0097] The establishment of a subset of road and road-related element types in GDF 5.1 in step S102 provided in the embodiment of the present invention includes:

[0098] (1) Extract road elements and road-related elements from GDF and form subsets, forming two parts of GDF: road and related element subsets and others (see Table 1).

[0099] Table 1 GDF element classification table

[0100]

[0101] (2) Create a UML model for the elements in GDF that can be mapped by OpenDRIVE (see Figure 3 ).

[0102] The conceptual model of the mapping constructed in step S103 provided by the embodiment of the present invention includes:

[0103] like Figure 4 As shown in FIG, based on the subset of roads and related elements in GDF that can be mapped to OpenDRIVE, a correspondence between each element and OpenDRIVE is established, including one-to-one correspondence, many-to-one correspondence, and one-to-many correspondence.

[0104] One-to-one correspondence includes Junction-IntersectionBelt and Road Marking-RoadMarking. A Junction element in OpenDRIVE represents a road intersection, and an IntersectionBelt element in GDF also represents a road intersection. Both elements represent the same thing and can be mapped one-to-one.

[0105] A many-to-one mapping is like a Road-RoadBelt. For Road, OpenDRIVE specifies that the Road element represents a section of road. Thus, if the road attributes (such as the number of lanes) remain unchanged between two intersections, a single Road is used to represent it. However, if the road attributes change, two or more Roads are required. GDF specifies that the RoadBelt element represents the road between two intersections. This means that the same RoadBelt can correspond to one or more Roads.

[0106] One-to-many relationships include Lane-{LaneBeltElement, Road Furniture Feature}, LaneSection-LaneSection, and Objects-{Road Furniture Feature, Structure}. The Objects feature type in OpenDRIVE encompasses all GDF feature types, including obstacles and pillars in the Road Furniture Feature class and bridges and tunnels in the Structure class.

[0107] The construction of the conversion rule in step S104 provided in the embodiment of the present invention includes:

[0108] Within the conceptual model framework, for any corresponding relationship, a semantic mapping of concepts and attributes is established between the corresponding elements based on the definitions of the relevant elements in GDF 5.1 and OpenDRIVE, and conversion rules are established based on this. This conversion involves not only data structures but also conversion between semantics.

[0109] (1) For any corresponding relationship, determine the definitions of the mutually mapped elements in the standard, including the element concepts and attribute semantics.

[0110] (2) Establish semantic relationships between mutually mapped elements, including conceptual semantic relationships, spatial semantic relationships, etc.

[0111] (3) Define the conversion rules between mutually mapped elements.

[0112] The element conversion in step S105 provided by the embodiment of the present invention includes: converting element examples in OpenDRIVE into GDF elements according to mapping rules.

[0113] The road element conversion system provided by the embodiment of the present invention includes:

[0114] UML diagram construction module, used to construct UML diagrams of road elements for OpenDRIVE and GDF respectively;

[0115] Feature mapping module, used to establish the mapping between OpenDRIVE and GDF road features;

[0116] A conversion rule establishment module is used to establish conversion rules between element instances of two standards;

[0117] The feature instance conversion module is used to convert a standard feature instance into another standard feature instance according to the established mapping rules.

[0118] like Figure 2 As shown in the following figure, the UML diagram of OpenDRIVE extracts road elements from OpenDRIVE and divides them into five parts: Road, Signal, Junction, Objects, and Rail Road. Among them, Road is composed of Lane Section, and Lane Section includes Lane and Road Marking. Objects can be mainly divided into Object, Tunnel, and Bridge.

[0119] like Figure 3 As shown in the GDF UML diagram, GDF5.1 has 17 feature classes. Here, we only organize the OpenDRIVE-related elements: Abstract Belt Feature, Road Furniture Feature, Road Furniture, and Structure. The Abstract Belt Feature includes Intersection, LaneBeltJoint, LaneBelt, LaneSection, RoadBeltElement, and RoadBelt. Here, RoadBelt, RoadBeltElement, LaneSection, and LaneBelt represent the road structure, which gradually refines the road belt from a complete road belt to a lane belt.

[0120] like Figure 6B As shown, the specific content is based on Figure 6A Built for templates.

[0121] like Figure 7B As shown, the specific content is based on Figure 7A Built for templates.

[0122] like Figure 8 As shown, the correspondence between GDF (left) and OpenDRIVE (right) elements

[0123] Among them, RoadBelt and Road have a one-to-one or one-to-many relationship.

[0124] The relationship between GDF's Lane Section and OpenDRIVE's Lane Section is one-to-one or one-to-two. If the OpenDRIVE Lane Section consists of lanes for a single driving direction, the corresponding relationship between GDF and OpenDRIVE's Lane Section is one-to-one. If the OpenDRIVE Lane Section does not distinguish between driving directions, the corresponding relationship between GDF and OpenDRIVE's Lane Section is one-to-one.

[0125] LaneBeltElement and Lane have a one-to-one relationship.

[0126] In order to prove the creativity and technical value of the technical solution of the present invention, this section provides application examples of the claimed technical solution on specific products or related technologies.

[0127] The data mode mapping between the two standards is the theoretical basis for data format conversion. Based on the definitions of OpenDRIVE and GDF on high-precision maps, this paper divides data mode mapping into three categories:

[0128] (1) The same geographic feature in the two standards has the same semantic ontology, but the naming rules are different. In this case, the conversion only requires converting the naming of one standard to the naming of the other standard. These elements include road and lane segment elements. For example, the road and lane segment elements in the OpenDRIVE standard are converted to the road and road segment elements in the GDF standard; the intersection elements in the OpenDRIVE standard are converted to the intersection strip elements in the GDF standard.

[0129] (2) The same geographic features in the two standards have the same semantic ontology and naming rules, but differ only in the ID rules and spatial topological relationships. Conversion in this case requires converting the ID rules and topological relationships of one standard to the ID rules and topological relationships of the other standard. These features include lane features. For example, converting lane features in the OpenDRIVE standard to lane features in GDF involves converting the feature representation and topological relationships.

[0130] (3) The same geographic feature is defined in one standard but not in the other. In this case, the conversion either adds a new definition or ignores it. This includes road junctions. For example, road junctions are added to the converted GDF data based on the positional relationship between lanes in the OpenDRIVE standard.

[0131] The embodiments of the present invention have achieved some positive results during the development or use process, and indeed have great advantages over the existing technology. The following content describes them in conjunction with data, charts, etc. from the experimental process.

[0132] Figures 5A to 5C They are respectively the original road of the present invention, the road constructed in OpenDRIVE format, and the example road graph constructed in GDF format. This section of road is expressed by OpenDRIVE and GDF respectively.

[0133] As a preferred embodiment, the road element conversion method provided by the embodiment of the present invention includes the following steps:

[0134] Step 1: Build the OpenDRIVE road element UML diagram.

[0135] In OpenDRIVE, roads are represented by Road, which is composed of Lane Sections. Lanes are used to represent lanes, which constitute Lane Sections. OpenDRIVE defines the composition of example roads as follows: Figures 6A and 6B Here, Figure 6A UML diagram representing a feature class, from Figure 2 part; Figure 6B Represents the relationship between objects or instances, following Figure 6A The schema of the class represented.

[0136] Step 2: Construct the GDF road element UML diagram.

[0137] In GDF, RoadBelt represents a road. RoadBelt is composed of RoadBeltElements that are composed of lanes in the same driving direction. RoadBeltElement is composed of Lane Sections, i.e. Lane Section A, Lane Section B, and Lane Section C in the figure. Lane Section is composed of lanes, such as Lane Section A includes two lanes, LEB101 and LEB102. Here, Figure 7A UML diagram representing a feature class, from Figure 3 part; Figure 7B Represents the relationship between objects or instances, following Figure 7A The schema of the class represented.

[0138] Step 3: Establish a mapping between OpenDRIVE and GDF road features.

[0139] In this example, lane features in two standards are mapped and converted. Figure 8 From Figure 4 part of.

[0140] Step 4: Establish conversion rules between feature instances of two standards.

[0141] The two standards define a lane element as a segment of lanes whose attributes remain unchanged. On the same road, adding or removing lanes within a segment generates a new lane segment element. Based on this, rules for mapping and converting lanes between the two standards are established, primarily encompassing lane element content, lane element representation, and lane element association.

[0142] (1) Lane element content

[0143] In this example, the lane types are ordinary lanes in GDF and driving lanes in OpenDRIVE.

[0144] (2) Lane element expression

[0145] In OpenDRIVE, lane features are contained in lane segments and are named using relative IDs. A center lane is defined in the road. This lane is numbered lane 0 and has no width. It is only used as a marking reference. In the same lane segment, the lane IDs decrease from left to right according to the lane arrangement position, such as Figure 5B Lanes 0, -1, and -2 of Lane Section A.

[0146] Although lane features use local IDs, road features use global IDs, such as Road01 and Road02. Within the same road, lane segment features are coded based on the distance between the start of the lane segment and the start of the road on which they are located. For example, Lane Section B starts at the beginning of Road 02, so Lane Section B is coded as 0; and Lane Section C starts 20 meters away from the start of Road 02, so Lane Section C is coded as 20.

[0147] In GDF, lane elements do not have local numbers defined, but are marked with a unified global ID, such as LBE101. Therefore, during the conversion process, the lane ID in OpenDRIVE needs to be converted into the global ID of GDF. The present invention combines the road element ID (such as Road01), lane section code (such as Lane Section A is coded as 0) and lane ID (such as -1) in OpenDRIVE, and converts them into a global ID. Among them, since the type of GDF lane ID is a positive integer, the lane ID of OpenDRIVE (including negative and positive numbers) needs to be converted into a positive integer. Arrange the lane ID values ​​of OpenDRIVE from small to large, and record them in order as consecutive positive integers starting from 1. Figure 9 Indicates that Figure 5B Schematic diagram of converting OpenDRIVE lane ID to positive integer.

[0148] (3) Lane element association

[0149] In OpenDRIVE, lanes are connected using two elements: prodecessor and successor. The direction of the lanes is the same as that of the road reference line. The prodecessor represents the previous lane, and the successor represents the next lane. In contrast, lane elements in GDF are connected using lane connection points, which do not distinguish between lanes in the order of precedence. Therefore, when converting OpenDRIVE data to GDF data, corresponding lane connection points should be added to the lanes. Here, the two lane IDs associated with the connection point are used: the GDF lane ID corresponding to the prodecessor and the GDF lane ID corresponding to the successor.

[0150] Step 5: According to the established mapping rules, the OpenDRIVE feature instance is converted into the GDF feature instance.

[0151] The conversion from OpenDRIVE to GDF involves lane mapping and the addition of connection points (see Table 2).

[0152] Table 2 GDF and OpenDRIVE feature mapping and conversion

[0153]

[0154] (1) Lane feature ID conversion

[0155] The lane ID conversion results are shown in Table 2. For example, the lane Road 01_Lane Section A_-1 in OpenDRIVE can be converted to the lane element LBE102 in GDF. Here, 1 is the ID of the lane Road in OpenDRIVE, 0 is the code of Lane Section A in OpenDRIVE, and 3 is the positive integer after the lane element in OpenDRIVE is converted.

[0156] (2) Lane element relationship conversion

[0157] In OpenDRIVE data, lane connections are expressed using the predecessor and successor tag elements. Taking lane-1 in Lane Section B as an example, the following code shows how the preceding and succeeding lanes of this lane element are represented in OpenDRIVE:

[0158] <opendrive>

[0159] …

[0160] <lane id="-1"type="driving"level="false">

[0161] <link>

[0162] <predecessor id="-1" / >

[0163] <successor id="-1" / >

[0164]

[0165] …

[0166] < / opendrive>

[0167] In GDF, lane features are connected using lane connection points. For example, LBE102 is connected to LBE203 and LBE2203 via lane connection points LBJ102203 and LBJ2032203, respectively. Furthermore, GDF does not have road reference lines to indicate road direction. Therefore, when converting from OpenDRIVE to GDF, lane connection points must be added at the GDF lane junctions. For example, lane -1 in Lane Section A and lane -1 in Lane Section B in OpenDRIVE require lane connection points 102203 after conversion to LBE102 and LBE203 in GDF.

[0168] It should be noted that the embodiments of the present invention can be implemented by hardware, software, or a combination of software and hardware. The hardware portion can be implemented using dedicated logic; the software portion can be stored in a memory and executed by an appropriate instruction execution system, such as a microprocessor or dedicated design hardware. Those skilled in the art will appreciate that the above-mentioned devices and methods can be implemented using computer-executable instructions and / or contained in processor control code, for example, such as a carrier medium such as a disk, CD or DVD-ROM, a programmable memory such as a read-only memory (firmware), or a data carrier such as an optical or electronic signal carrier. The devices and modules of the present invention can be implemented by hardware circuits such as very large-scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, or programmable hardware devices such as field programmable gate arrays, programmable logic devices, etc., can also be implemented by software executed by various types of processors, or can be implemented by a combination of the above-mentioned hardware circuits and software, such as firmware.

[0169] The above description is only a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any modifications, equivalent substitutions and improvements made by any technician familiar with this technical field within the technical scope disclosed by the present invention and within the spirit and principles of the present invention should be covered by the scope of protection of the present invention.

Claims

1. A road element conversion method, characterized in that: The road feature conversion method includes: constructing UML diagrams of road features for OpenDRIVE and GDF respectively; establishing a mapping model based on the types of roads and road-related features common to OpenDRIVE and GDF; establishing conversion rules for feature instances between OpenDRIVE and GDF based on the semantic mapping of concepts and attributes between the two standards; and converting feature instances in OpenDRIVE to GDF features based on the mapping rules. The mapping between OpenDRIVE and GDF road features is established as: A mapping model between GDF 5.1 and OpenDRIVE is established for roads and related elements that are common to both standards. The conceptual model for building the mapping includes: Based on the subset of roads and related features mapped to OpenDRIVE in GDF, establish the corresponding relationship between each feature and OpenDRIVE, including one-to-one correspondence, many-to-one correspondence, and one-to-many correspondence; One-to-one correspondence includes Junction-IntersectionBelt and Road Marking-Road Marking. The Junction element in OpenDRIVE represents a road intersection, and the IntersectionBelt element in GDF also represents a road intersection. The two elements represent the same thing and are in one-to-one correspondence. Many-to-one correspondence includes Road-RoadBelt. For Road, OpenDRIVE stipulates that the Road element represents a section of road. Between two intersections, if the road attributes remain unchanged, one Road is used to represent it; if the road attributes change, two or more Roads are used to represent it. GDF stipulates that the RoadBelt element represents the road between two intersections, and the same RoadBelt corresponds to one to multiple Roads. One-to-many correspondences include Lane-{LaneBeltElement, Road Furniture Feature}, LaneSection-LaneSection, and Objects-{Road Furniture Feature, Structure}. The Objects feature type in OpenDRIVE covers the feature types of GDF, including obstacles and pillars in the Road Furniture Feature feature class and bridges and tunnels in the Structure feature class.

2. The road element conversion method according to claim 1, wherein: The road feature conversion method includes the following steps: Step 1: Build the UML diagram of OpenDRIVE road elements; Step 2: Construct the UML diagram of the GDF road elements; Step 3: Establish a mapping between OpenDRIVE and GDF road features; Step 4: Establish a conversion rule for feature instances between the two standards; based on the established mapping rule, convert the feature instance of one standard into the feature instance of another standard.

3. The road element conversion method according to claim 2, wherein: The construction of the OpenDRIVE road element UML diagram in step 1 includes: Based on ASAM OpenDRIVE version 1.7.0, a UML diagram of roads and road-related element types was developed to express the logical structure between element types. The OpenDRIVE compilation includes: (1) Based on the description of roads and related elements in OpenDRIVE, the definitions of road elements and road-related elements in OpenDRIVE are extracted; (2) Establish semantic relationships between element types, including hierarchical relationships, to form UML diagrams that represent hierarchical classification between elements; (3) Extract the relevant attributes, expressions and data types contained in each element.

4. The road element conversion method according to claim 2, wherein: The construction of the GDF road element UML diagram in step 2 includes: Establish a subset of GDF 5.1 road and road-related feature types, including: (1) Extract road elements and road-related elements from the GDF and form subsets, forming two parts of the GDF: road and related element subsets and others; (2) Establish a UML model for the elements mapped by OpenDRIVE in GDF.

5. The road element conversion method according to claim 2, wherein: The construction of the conversion rules in step 4 includes: In the conceptual model framework, for any corresponding relationship, a semantic mapping of concepts and attributes is established between the corresponding elements based on the definitions of relevant elements in GDF 5.1 and OpenDRIVE, and conversion rules are established. The conversion rules include the conversion between data structure and semantics. (1) For any corresponding relationship, determine the definition of the mutually mapped elements in the standard, including the element concept and attribute semantics; (2) Establishing semantic relationships between mutually mapped elements, including conceptual semantic relationships and spatial semantic relationships; (3) Define the conversion rules between mutually mapped elements.

6. A road element conversion system using the road element conversion method according to any one of claims 1 to 5, characterized in that: The road element conversion system includes: UML diagram construction module, used to construct UML diagrams of road elements for OpenDRIVE and GDF respectively; Feature mapping module, used to establish the mapping between OpenDRIVE and GDF road features; A conversion rule establishment module is used to establish conversion rules between element instances of two standards; The feature instance conversion module is used to convert a standard feature instance into another standard feature instance according to the established mapping rules.

7. A computer device, characterized in that: The computer device includes a memory and a processor. The memory stores a computer program. When the computer program is executed by the processor, the processor executes the steps of the road element conversion method according to any one of claims 1 to 5.

8. A computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, the processor executes the steps of the road element conversion method according to any one of claims 1 to 5.

9. An information data processing terminal, characterized in that: The information data processing terminal is used to implement the road element conversion system as described in claim 6.

Images