Road data processing method, device, equipment and product

Abstract

The invention provides a road data processing method, device, equipment and product, and the method comprises the steps: obtaining to-be-processed road data which comprises road elements and lane vector data; identifying semantic features of the road elements; based on the semantic features of the first road element associated with the lane vector data, determining candidate lane vectors belonging to a target lane type in the lane vector data; and determining target lane data in the candidate lane vector based on a second road element associated with the candidate lane vector, the road element including the first road element and the second road element. According to the method, the target lane is accurately identified from the road data, more reliable data support is provided for a lane-level navigation system, and the safety of the navigation process is improved.

Description

Technical Field

[0001] The present application relates to the field of information processing technology, and in particular to a road data processing method, device, equipment and product. Background Art

[0002] Lane-level navigation is an advanced map-based navigation technology designed to provide drivers with more detailed road information and navigation guidance. Unlike traditional road-based navigation systems, lane-level navigation can identify and display specific lane information, helping drivers make more informed driving decisions in complex traffic environments.

[0003] Dedicated lanes are lanes designated on roads for use only by specific types of vehicles. These lanes are typically established to improve traffic efficiency, safety, or meet certain policy requirements. Examples include bus lanes, high-occupancy vehicle lanes, and taxi lanes. For example, bus lanes are typically reserved specifically for buses, ensuring that public transportation can maintain high speeds and punctuality during peak hours and other busy traffic periods. With the acceleration of urbanization and the increase in urban population, traffic congestion is becoming increasingly serious. Therefore, in lane-level navigation, clarifying the distribution of dedicated lanes such as bus lanes has become a pressing technical issue that needs to be addressed. Summary of the Invention

[0004] The main purpose of the embodiments of the present application is to provide a road data processing method, device, equipment and product, which can accurately identify target lane data from road data, provide more reliable data support for lane-level navigation systems, and help improve the safety of the navigation process.

[0005] In a first aspect, an embodiment of the present application provides a road data processing method, comprising: obtaining road data to be processed, the road data to be processed including road elements and lane vector data; identifying semantic features of the road elements; determining, based on the semantic features of a first road element associated with the lane vector data, a candidate lane vector belonging to a target lane type in the lane vector data; and determining target lane data in the candidate lane vector based on a second road element associated with the candidate lane vector, wherein the road elements include the first road element and the second road element.

[0006] In a second aspect, an embodiment of the present application provides a road data processing device, comprising:

[0007] An acquisition module, configured to acquire road data to be processed, wherein the road data to be processed includes road elements and lane vector data;

[0008] A recognition module, configured to recognize semantic features of the road elements;

[0009] a first determining module, configured to determine, based on the semantic feature of the first road element associated with the lane vector data, a candidate lane vector belonging to a target lane type in the lane vector data;

[0010] The second determining module is configured to determine target lane data in the candidate lane vector based on a second road element associated with the candidate lane vector, wherein the road element includes the first road element and the second road element.

[0011] In a third aspect, an embodiment of the present application provides an electronic device, including:

[0012] at least one processor; and

[0013] a memory communicatively coupled to the at least one processor;

[0014] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the electronic device to execute the method described in any one of the above aspects.

[0015] In a fourth aspect, an embodiment of the present application provides a cloud device, including:

[0016] at least one processor; and

[0017] a memory communicatively coupled to the at least one processor;

[0018] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the cloud device to execute the method described in any one of the above aspects.

[0019] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the method described in any one of the above aspects is implemented.

[0020] In a sixth aspect, an embodiment of the present application provides a computer program product, including a computer program, which implements the method described in any of the above aspects when executed by a processor.

[0021] The road data processing methods, devices, equipment, and products provided in the embodiments of the present application, by identifying the semantic features of road elements in the road data to be processed, enable the system to intelligently classify and understand different types of road elements. Based on the semantic features of the first road element associated with the lane vector data, the system can accurately filter out candidate lane vectors belonging to the target lane type from the lane vector data. Then, by analyzing the second road element associated with the candidate lane vector, the system can further determine the target lane data actually present in the candidate lane vector. In this way, by integrating the semantic features of road elements and the association between lane vector data and road elements, a two-level screening mechanism is adopted, gradually narrowing the data processing scope through semantic constraints, and intelligently identifying lane vector types based on semantic context, achieving accurate identification of target lane data from road data, providing more reliable data support for lane-level navigation systems, and helping to improve the safety of the navigation process. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The accompanying drawings are incorporated into and constitute a part of the specification, illustrate embodiments consistent with the present application, and together with the specification, are used to explain the principles of the present application. Obviously, the drawings described below are some embodiments of the present invention, and it is clear that those skilled in the art can derive other drawings based on these drawings without inventive effort.

[0023] Figure 1 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application;

[0024] Figure 2 A schematic diagram of an application scenario of a road data processing system provided in an embodiment of the present application;

[0025] Figure 3 A schematic flow chart of a road data processing method provided in an embodiment of the present application;

[0026] Figure 4A A schematic diagram of semantic group division provided in an embodiment of the present application;

[0027] Figure 4B A schematic diagram of a scenario for determining path information provided in an embodiment of the present application;

[0028] Figure 5 A schematic diagram of the architecture of a prediction model provided in an embodiment of the present application;

[0029] Figure 6 A schematic flow chart of a road data processing method provided in an embodiment of the present application;

[0030] Figure 7A schematic structural diagram of a road data processing device provided in an embodiment of the present application;

[0031] Figure 8 A schematic diagram of the structure of a cloud device provided in an embodiment of the present application.

[0032] The above drawings illustrate specific embodiments of the present application, which will be described in more detail below. These drawings and the textual description are not intended to limit the scope of the present application in any way, but rather to illustrate the concepts of the present application to those skilled in the art by reference to specific embodiments. DETAILED DESCRIPTION

[0033] Exemplary embodiments are described in detail herein, with examples illustrated in the accompanying drawings. When the following description refers to the drawings, identical numerals in different drawings represent identical or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with this application.

[0034] The term "and / or" in this article is used to describe the association relationship of associated objects, specifically indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone.

[0035] 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, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0036] In order to clearly describe the technical solutions of the embodiments of the present application, the following definitions are given first:

[0037] Road elements: refers to various facilities and elements on the road, including but not limited to traffic signs, road markings, ground markings, etc.

[0038] Lane-level map data: an abstraction of lanes and road elements in a road scene, and map data stored in vector form.

[0039] Map vector: An abstract representation of ground lane lines, ground markings, etc. on a map, generally in the form of lines, boxes, etc.

[0040] Scope: scope.

[0041] Bus lane scope: The lane-level start and end range dedicated to bus travel in the road scene.

[0042] OBJ: Object, in the embodiment of this application, refers to the vector data of discrete, independent road elements on the road, including but not limited to poles, signs, arrows, guide strips, stop lines, zebra crossings and other ground signs.

[0043] Semantic OBJ: A linear geometry on the ground with a set of semantic expressions, including associated ground text and logos, and attribute information such as type, effect time, and date.

[0044] Topo: Topological relationships are mainly used to describe the relationship between spatial objects. Topological relationships focus on the relative position and connectivity between spatial objects. This relationship has a wide range of applications in map data processing, network analysis, navigation systems, and database management.

[0045] Laneset: A vector representation of lane segments in a map. For example, a complete lane can be divided into lane segments of approximately 5 meters. A lane network can be generated through the topological relationship of laneset.

[0046] NLP: Natural Language Processing.

[0047] Transformer: A deep learning model for natural language processing (NLP) and other sequence-to-sequence tasks.

[0048] Token: In natural language processing, tokens are the basic units of text, usually words or subwords.

[0049] Position embedding: The main purpose of position embedding is to provide the model with the position information of each word in the sequence, so that the model can use the order of words to understand the context. For example, position embedding is added to the input word embedding for use in the Transformer's self-attention mechanism. This allows the model to take the order of words into account when processing the input sequence.

[0050] The road data processing method of the embodiment of the present application can be applied to any application field that requires determining dedicated lanes.

[0051] Lane-Level Navigation (LNL) is an advanced map-based navigation technology designed to provide drivers with more precise road information and navigation guidance. Unlike traditional road-based navigation systems, LNL identifies and displays specific lane information, helping drivers make more informed driving decisions in complex traffic environments.

[0052] Dedicated lanes are lanes designated on roads for use only by specific types of vehicles. These lanes are typically established to improve traffic efficiency, safety, or meet certain policy requirements. Examples include bus lanes, high-occupancy vehicle lanes, and taxi lanes. Taking bus lanes as an example, these are typically lanes reserved specifically for buses, ensuring that public transportation can maintain high speeds and punctuality during peak hours and other busy traffic periods. With the acceleration of urbanization and the increase in urban population, traffic congestion is becoming increasingly serious. Therefore, to address urban traffic congestion, lane-level navigation requires clarifying the starting and ending points of bus lanes to facilitate driving guidance within motor vehicle lanes other than bus lanes and other dedicated lanes. Clarifying the distribution of dedicated lanes such as bus lanes has become a technical issue that needs to be addressed urgently.

[0053] To address at least one of the aforementioned issues, an embodiment of the present application provides a road data processing solution. By identifying the semantic features of road elements in the road data to be processed, the system is able to intelligently classify and understand different types of road elements. Based on the semantic features of the first road element associated with the lane vector data, the system is able to accurately filter out candidate lane vectors belonging to the target lane type from the lane vector data. Then, by analyzing the second road element associated with the candidate lane vector, the system is able to further determine the target lane data actually present in the candidate lane vector. In this way, by integrating the semantic features of road elements and the association between lane vector data and road elements, a two-level screening mechanism is adopted, gradually narrowing the data processing scope through semantic constraints. Lane vector types can be intelligently identified based on semantic context, achieving accurate identification of target lane data from road data. This provides more reliable data support for lane-level navigation systems and helps improve the safety of the navigation process.

[0054] The following detailed description of some embodiments of the present application is provided in conjunction with the accompanying drawings. The following embodiments and features thereof may be combined with one another unless they conflict with each other. Furthermore, the sequence of steps in the following method embodiments is provided for illustrative purposes only and is not intended to be a strict limitation.

[0055] like Figure 1 As shown, this embodiment provides an electronic device 1, including: at least one processor 11 and a memory 12, Figure 1 A processor is used as an example. Processor 11 and memory 12 are connected via bus 10. Memory 12 stores instructions executable by processor 11. The instructions are executed by processor 11 so that electronic device 1 can execute all or part of the process of the method in the following embodiment to accurately identify target lane data from road data, provide more reliable data support for the lane-level navigation system, and help improve the safety of the navigation process.

[0056] In one embodiment, the electronic device 1 may be a mobile phone, a tablet computer, a laptop computer, a desktop computer, or a large computing system composed of multiple computers.

[0057] Figure 2 Schematic diagram of a road data processing system application scenario 200 provided in an embodiment of the present application. Figure 2 As shown, the system includes: a server 210 and a terminal 220, wherein:

[0058] The server 210 may be a data platform that provides road data processing services, such as a map data production platform. In actual scenarios, a map data production platform may have multiple servers 210. Figure 2 Here, one server 210 is taken as an example.

[0059] The terminal 220 may be a mobile device used to log in to the map data production platform, such as a computer, mobile phone, tablet computer, etc. used for map data production. There may also be multiple terminals 220. Figure 2 Two terminals 220 are used as an example for illustration.

[0060] The terminal 220 and the server 210 can transmit information via the Internet, so that the terminal 220 can access the data on the server 210. The terminal 220 and / or the server 210 can be implemented by the electronic device 1.

[0061] The road data processing solution of the embodiment of the present application can be deployed on the server 210, can also be deployed on the terminal 220, or can be deployed partially on the server 210 and partially on the terminal 220. In actual scenarios, the choice can be based on actual needs, and this embodiment does not limit it.

[0062] When the road data processing solution is fully or partially deployed on the server 210 , a calling interface may be opened to the terminal 220 to provide algorithm support to the terminal 220 .

[0063] The method provided in the embodiments of the present application can be implemented by executing corresponding software code on electronic device 1 and by interacting with a server. The electronic device 1 can be a local terminal device. When the method is run on a server, the method can be implemented and executed based on a cloud interaction system, which includes a server and a client device.

[0064] In a possible implementation, the method provided in the embodiment of the present application provides a graphical user interface through a terminal device, wherein the terminal device can be the local terminal device mentioned above, or it can be a client device in the cloud interaction system mentioned above.

[0065] Please see Figure 3 , which is a road data processing method according to an embodiment of the present application, the method can be Figure 1 The electronic device 1 shown is used to perform and can be applied to Figure 2 In the road data processing application scenario shown in , the target lane data can be accurately identified from the road data, providing more reliable data support for the lane-level navigation system, which helps to improve the safety of the navigation process. In this embodiment, the terminal 220 is used as the execution end as an example. The method includes the following steps:

[0066] Step 301: Obtain road data to be processed, where the road data to be processed includes road elements and lane vector data.

[0067] In this step, the road data to be processed can be road data within a specified area, such as a city or administrative district. The road data to be processed can be obtained from map data for the specified area. In practical scenarios, map data can be generated using a device-cloud approach. The device perceives map elements within the specified area through images and performs appropriate abstraction processing. The cloud aggregates these abstracted map elements from multiple passes to address the issue of imperfect single-pass perception, thereby constructing a complete map of the specified area. The vector map elements abstracted by the cloud can be used as the road data to be processed. This includes, but is not limited to, road elements and lane vector data within the specified area. Road elements refer to various road sign information, including, but not limited to, ground signs and text. Ground signs include, for example, left-turn arrows, right-turn arrows, and straight-ahead markings. Ground text includes, for example, "Bus Lane" or "7-9 o'clock." Lane vector data refers to the vector distribution data of lanes, which can be used to represent their length, width, shape, and direction. In real-world scenarios, lanes can be pre-defined using lane markings. For example, the range between two lane markings can define a lane. Lane vectors are then represented using virtual arrow lines located within the lane. For example, a virtual arrow line located in the middle of the lane can be used to represent the lane vector. The direction of the arrow indicates the lane's direction, and the length of the arrow line represents the lane's length. The lane's width and shape are used as attribute information for the arrow line vector, forming lane vector data and storing it in the map data. Lane vector data can include the complete vector path of a lane. In this case, the lane vector can be represented using a virtual arrow line encompassing the complete lane path. Lane vector data can also include vectors of multiple interrupted lane segments, as well as the topological relationships between different lane segment vectors. Here, a lane segment refers to the multiple subdivisions of a lane. Each lane segment is numbered sequentially according to the actual location sequence. In this case, the lane vector can be represented using multiple virtual arrow lines connected end to end. Each virtual arrow line represents the length and direction of the corresponding lane segment. Each virtual arrow line can also be associated with attribute information such as the width and shape of the corresponding lane segment. For example, a lane with a total length of 1 km can be divided into lane segments every 5 meters, for a total of 200 lane segments. Each lane segment is numbered in order according to the direction of the actual scene, and the topological relationship is retained.

[0068] Step 302: Identify semantic features of road elements.

[0069] In this step, the semantic features of road elements refer to the feature descriptions that understand and classify the properties and functions of road elements. These features help the system or algorithm identify and distinguish different types of road elements, allowing for more accurate data processing and analysis.

[0070] In one embodiment, the road data to be processed also includes lane lines of each lane; identifying semantic features of road elements includes: determining road elements belonging to the same lane based on the lane lines; and separately identifying semantic features of road elements belonging to the same lane.

[0071] In this embodiment, the road data to be processed may also include lane lines for each lane. Lane lines can be used to first filter road elements belonging to the same lane from the road data to be processed, and then the semantic features of the road elements can be identified by lane. By introducing lane lines as the physical basis for lane division, a lane attribution judgment mechanism based on geometric topological relationships is constructed. The continuity characteristics of lane lines (such as linear curvature and extension direction) are used to establish a lane container model. Road elements such as ground signs and ground text are grouped into corresponding lanes according to spatial distribution relationships, so that the semantic features of elements in the same lane have spatial consistency. The use of a separate lane processing mechanism ensures data isolation between lanes while dynamically adapting to the differentiated semantic rules of different lanes (such as special sign recognition rules for bus lanes) to avoid misjudgments caused by cross-lane feature interference.

[0072] In one embodiment, the identification of semantic features of road elements belonging to the same lane in step 302 may specifically include: aggregating road elements belonging to the same lane according to distance to generate multiple candidate element sets; and identifying the semantic content and location information of each road element in the candidate element set, where the semantic features include the semantic content and location information.

[0073] In this embodiment, for each lane, road elements belonging to that lane are first clustered by distance to generate multiple candidate element sets, ensuring the effective organization and management of geographically proximate elements. By clustering candidate element sets by distance, a data clustering model based on geographic proximity is constructed within the lane spatial domain, effectively overcoming the problem of feature correlation failure caused by spatial discreteness of elements. Specifically, an adaptive distance threshold (e.g., dynamically adjusting the aggregation radius based on lane curvature) is used to group and cluster elements such as ground signs and ground text within the same lane, ensuring spatial correlation within each candidate element set. Then, the semantic content and precise location information of road elements are simultaneously analyzed at the candidate element set level. Based on this, a three-dimensional semantic feature vector (semantic type + absolute position + relative orientation) of the road element can be constructed as required. Subsequent processing enables verification of semantic consistency based on spatial logical relationships. For example, this can assist in intelligently identifying special scenarios (e.g., temporary signs covering existing road markings in a construction area), providing the autonomous driving system with high-precision road recognition data with spatial interpretability.

[0074] Semantic features include, but are not limited to, the semantic content and location information of road elements. By identifying the semantic features of road elements, a deep understanding and intelligent processing of road data is achieved. Identifying semantic content enables the system to accurately classify and understand the types and functions of road elements. For example, it can distinguish between different lanes, identify left-turn ground signs, identify right-turn ground signs, and identify their specific uses, such as regular lanes or dedicated lanes. Location information indicates the position of a road element within the road network, such as its lateral offset from the lane edge, the direction of the intersection, and the side of the road. Identifying location information ensures precise positioning of the road element's spatial location within the entire traffic network, facilitating route planning. Combined with semantic content and location information, these semantic features provide the system with a comprehensive perspective, enabling more effective data analysis and decision support, thereby providing an accurate data foundation for identifying the target lane.

[0075] Optionally, the semantic features of road elements may also include geometric features, dynamic features, and usage rule features. Geometric features may include geometric attributes such as the shape, length, width, and curvature of road elements. Dynamic features involve the dynamic properties of road elements, such as the periodic changes in traffic lights and the status of variable lanes. Usage rule features are used to describe the usage rules or restrictions of road elements, such as the speed limit of speed limit signs and the usage hours and conditions of dedicated lanes. By identifying and understanding these semantic features, traffic management systems or navigation systems can more effectively analyze road data and make decisions for route planning, traffic monitoring, and management.

[0076] In one embodiment, the method may further include: for each candidate element set, dividing the road elements in the candidate element set whose semantic similarity is greater than a preset threshold into the same semantic group based on semantic features to generate multiple semantic groups.

[0077] In this embodiment, road elements in each candidate element set are semantically grouped. Road elements within the candidate element set with semantic similarity greater than a preset threshold are assigned to the same semantic group, generating multiple semantic groups. This establishes multi-dimensional feature matching relationships within the candidate element set (including semantic type, functional attributes, and spatial relevance). This not only provides a functional understanding of road elements but also integrates their spatial location to form complete and accurate semantic features. This effectively addresses the semantic conflict issues that arise in traditional methods due to the dense spatial distribution of elements in complex intersection scenarios. For example, arrow markings and ground text on the same guide lane are automatically grouped into the same semantic group, resulting in more accurate recognition results for complex semantics. Furthermore, dynamically controlling the grouping granularity using a preset threshold prevents feature confusion caused by over-aggregation (e.g., incorrectly merging bus lane signs with regular lane markings) and decision fragmentation caused by overly detailed grouping. This reduces cascading misjudgments caused by single-element parsing errors and improves overall semantic consistency in complex scenarios. This provides lane-level navigation with contextually relevant structured road recognition data, effectively supporting the reliable implementation of lane-level trajectory planning.

[0078] Taking the production scenario of bus lane scope in a road scenario as an example, its purpose is to accurately produce the start and end ranges and effective dates and times of bus lanes in the map. To achieve the above purpose, the semantic OBJ production method of this embodiment is first adopted. The process is as follows: (1.1) First, based on the lane lines, the road elements belonging to the same lane are determined; for each lane road element, based on the position neighbor search, the road elements (such as road surface text, graphics, etc.) are associated by distance to form a candidate element set. Specifically, let the full set be N, randomly select element a from the road elements of the road data to be processed and add it to the empty set M, and remove element a from the full set N. The distance between each element in the full set N and the elements in the set M is calculated. Elements with distances less than the preset distance d are removed from N and added to M to form a candidate element set corresponding to element a. The above steps are repeated until the elements in N are empty or the distances between elements in N and elements in M ​​are all greater than d, forming multiple candidate element sets aggregated by distance.

[0079] (1.2) Extract the road elements from the candidate element set generated in (1.1) and obtain their location coordinates, type (the type of the road element can be, for example, an arrow, text, or icon), and semantic content (for example, if the road element type is an arrow, the semantic content can be whether the arrow turns left or right; if the road element type is text, the semantic content of the road element can be the specific content of the text). Then, a language model can be used as the basic model to pre-build a similarity comparison model. The semantic content of the road element is used as the basic token, supplemented by road element type encoding and geometric coordinate information encoding tokens. The similarity comparison model fully integrates and understands the semantic content, type, and location coordinates to generate the final semantic features of each road element. Finally, the similarity of the semantic features of each road element is calculated, and road elements with similarity above a certain threshold are grouped into a semantic group.

[0080] like Figure 4A As shown, it is a semantic group division diagram provided by an embodiment of the present application. It is assumed that the content of the road elements included in a certain candidate element set is "bus lane, multi-member lane", "7-10, 16-19", "merge to the right", "road", "car", "turn", and "right". The contents of the above road elements are respectively used as Y-axis labels and X-axis labels, and by matching single words in pairs, it can be obtained that "bus lane, multi-member lane" and "7-10, 16-19" are divided into the same semantic group, and "merge to the right", "road", "car", "turn", and "right" are divided into the same semantic group. Among them, "7-10, 16-19" means that the effective time is "7:00-10:00" and "16:00-19:00" every day.

[0081] (1.3) The semantic content of the road elements within the same semantic group generated in (1.2) is input into a pre-set semantic understanding model. The semantic understanding model can include a discriminative model and a generative model. The discriminative model is used to generate the semantic group's lane type, while the generative model is used to generate the semantic group's content with a reading order and semantic content such as the effective time and date. Ultimately, the location information and semantic content of each road element in the semantic group form a semantic object (OBJ). For example, if a semantic group includes the geometric coordinates and textual content of the road element "7-9, use special transportation." The textual content of the road element in the semantic object (OBJ) will be translated into the readable "Public bus only, 7-9," and the corresponding semantic content will be "Restricted vehicle type to buses, effective from 7:00 to 9:00."

[0082] In this way, a set of semantic OBJ candidate elements is determined through nearest neighbor search. Then, through semantic matching, road elements with the same set of semantics are grouped together. Semantic understanding is then used to determine the semantic information expressed by this group of road elements (such as lane type, effective time, date, etc.) to form a semantic OBJ.

[0083] Step 303: Determine a candidate lane vector belonging to the target lane type in the lane vector data based on the semantic feature of the first road element associated with the lane vector data.

[0084] In this step, the road elements include a first road element, which refers to a road element associated with the lane vector data, such as a road element whose spatial position is within the lane vector range defined by the lane vector data. The semantic features of the first road element can be used to characterize the lane type, function, and other characteristics of the lane vector in which it is located. Therefore, based on the semantic features of the first road element, candidate lane vectors belonging to the target lane type can be screened out from the lane vector data. Here, the target lane type can be a dedicated lane type, such as a bus-only lane. The target lane type can also be a custom lane type. Semantic constraints can be used to gradually narrow the data processing scope and reduce computational complexity.

[0085] In one embodiment, the lane vector data includes vector data of multiple lane segments and topological relationships between the multiple lane segments. Step 303 may specifically include: determining at least one path information formed by the multiple lane segments based on the topological relationships and the vector data of the multiple lane segments; determining a first road element associated with each lane segment position in the path information based on the position information of the road elements; and screening, from the path information, candidate lane paths whose semantic type is the target lane type based on the semantic content of the first road element, wherein the candidate lane vectors include the lane segment vectors forming the candidate lane path.

[0086] In this embodiment, a lane segment refers to a lane divided into multiple small segments of a preset length. A lane segment can be a vector. For example, a lane segment vector in map element data can divide a lane into approximately 5-meter segments. A topological relationship refers to the connection between different lane segments in the actual scene. A lane network can be generated using the topo relationship of the lane set. In actual applications, if the lanes in the input map element data are represented by multiple small vector segments, a complete real-world path generally does not exist. During the selection of candidate lane vectors, the vector data of the multiple lane segments in the lane vector data and the topological relationships between the lane segments are first utilized to accurately construct at least one path formed by the multiple lane segments. This path information not only includes the geometric shape of the lanes but also reflects the topological structure between the lanes. Then, combined with the location information in the semantic features of the road elements, a first road element associated with each lane segment is determined for each path. Here, a location association may mean that the first road element is within the location range of the lane segment, representing the spatial relationship between the first road element and the associated lane segment. Based on the semantic content of primary road elements, candidate lane paths belonging to the target lane type can be effectively screened from this path information. This method achieves a collaborative analysis based on topological relationships and lane segment vector data, establishing a three-dimensional spatial association model of the road network. Using a spatial position association mapping mechanism, primary road elements such as ground signs and text are precisely anchored to corresponding lane segments, forming a path feature description system with both semantic and spatial constraints, reducing invalid data matching calculations. Finally, through the semantic screening mechanism for the target lane type, candidate lane paths are ensured to meet not only geometric connectivity but also semantic compliance, providing a data foundation for the navigation system that balances spatial accuracy and logical rationality.

[0087] Taking the bus lane scope creation scenario described above as an example, the lane segments in the lane vector data are traversed using a depth-first traversal to generate a complete set of paths. These paths are then associated with semantic OBJs to select candidate lane paths associated with bus lanes. By combining the semantic features of road elements with the paths formed by lane segments, the accuracy and efficiency of target lane recognition are improved.

[0088] Optionally, if the input data contains a complete lane path, there is no need to construct the path. Instead, for each lane path, the first road element associated with the lane path position can be determined based on the position information of the road element. Based on the semantic content of the first road element, candidate lane paths with a semantic type of the target lane type can be screened out from the lane path.

[0089] In one embodiment, determining at least one path information formed by the multiple lane segments based on the topological relationship and the vector data of the multiple lane segments in step 303 includes: removing the multidirectional topological relationship from the topological relationship based on the topological relationship and the vector data of the multiple lane segments, and splicing the multiple lane segments based on the removed topological relationship to form a first path, where the first path is a single-line path; and splicing two adjacent first paths whose direction angle is less than a preset angle based on the topological relationship to generate a second path, where the path information includes the second path and the unspliced ​​first path.

[0090] In this embodiment, the path information formed by lane segments can be simplified, streamlining the calculation process. A multi-directional topological relationship refers to a lane segment connecting multiple lane segments in different directions. For example, one end of lane segment A is connected to both lane segments B and lane segment C, but lane segments B and C are in different directions. This creates a bifurcation when forming the path, complicating data calculation. To simplify the data calculation process, the topological relationship and vector data between lane segments are firstly utilized to eliminate multi-directional topological relationships, thereby simplifying the path complexity and ensuring that the generated first path is a single-line path. Single-line paths do not bifurcate, effectively reducing redundancy and uncertainty in path calculation. Then, based on the topological relationship, two adjacent first paths with a direction angle less than a preset angle are rejoined to generate a more comprehensive second path. The direction angle here refers to the angle between the vector directions of two adjacent first paths at the connection point. The preset angle can be set according to actual needs, for example, 10 degrees. This ensures that two first paths with a direction angle less than the preset angle belong to the same lane. This ensures that the joined second paths are in the same lane, improving the accuracy of path joining. The resulting path information includes these optimized second paths and the first path that was not included in the secondary splicing. This method not only improves the accuracy and reliability of path information, but also provides more precise basic data support for traffic management systems and navigation applications, thereby improving the efficiency and safety of vehicle navigation and path planning.

[0091] like Figure 4BThe figure shows a schematic diagram of a scenario for determining path information provided by an embodiment of the present application. In the primary path, one end of lane segment A has a topological relationship with both lane segment B and lane segment C, but lane segment B and lane segment C have different directions. The connection relationship between lane segment A and lane segment B is eliminated, and the connection relationship between lane segment A and lane segment C is eliminated. The lane segments between P0 and P1 are then spliced ​​together to form the first path P0P1. Similarly, the first paths P1P2 and P1P3 are spliced ​​together. In the secondary path, the angle between the directions of the first paths P0P1 and P1P2 at the connection point P1 is less than a preset angle of 10 degrees, and they are actually on the same line. Therefore, a secondary splicing is performed to form the second path P0P2. The angle between the directions of the first path P1P3 and the first path P0P1 at the connection point P1 is greater than a preset angle of 10 degrees, so secondary path splicing is not required. The resulting path information includes the first path P1P3 and the second path P0P2.

[0092] Step 304: Determine target lane data in the candidate lane vector based on the second road element associated with the candidate lane vector.

[0093] In this step, the road element also includes a second road element, which is a road element that is positionally associated with the candidate lane vector. After screening in step 303, the target lane is found in the candidate lane vector. To further accurately determine the target lane data, the candidate lane vector can be further verified using the second road element to further confirm and extract the target lane data that actually exists in the candidate lane vector. This allows for accurate identification of the target lane from the road data, while gradually narrowing the data processing scope based on semantic constraints. This further verification using the second road element provides more reliable data support for the lane-level navigation system, helping to improve navigation safety.

[0094] In one embodiment, step 304 may specifically include: determining, based on the lane line, a second road element belonging to the same lane as the candidate lane vector and a target lane line belonging to the candidate lane vector; and determining target lane data in the candidate lane vector based on the second road element and the target lane line.

[0095] In this embodiment, the road data to be processed also includes lane lines for each lane. The spatial position of the lane can be determined based on the lane lines. Then, based on the spatial position of the candidate lane vector and the spatial position of the road element, the ground signs and ground text located in the same lane as the candidate lane vector can be determined. These ground signs and ground text are the second road element. The target lane lines refer to the lane lines located on both sides of the candidate lane vector. For example, if the candidate lane vector is a path formed by multiple candidate lane segments, the target lane lines refer to the lane lines located on the left and right sides of each candidate lane segment. The target lane lines are associated with the corresponding candidate lane segments. Then, based on the second road element and the target lane lines, the target lane data in the candidate lane vector can be accurately determined. The final target lane data combines the dual verification results of physical boundaries and semantic associations, improving the accuracy of the target road data.

[0096] In one embodiment, a candidate lane vector includes multiple candidate lane segment vectors and a topological relationship between the multiple candidate lane segment vectors; determining target lane data in the candidate lane vector based on a second road element and a target lane line includes: generating an embedding vector for the candidate lane vector based on the topological relationship between the second road element, the target lane line, and the multiple candidate lane segment vectors; generating a lane type for each candidate lane segment in the candidate lane vector using a preset prediction model based on the embedding vector; screening a target lane segment belonging to the target lane type from the multiple candidate lane segments based on the lane type; determining an effective time of the target lane segment based on semantic features of the road element of the target lane segment; the target lane data includes a location range of the target lane segment and an effective time of the target lane segment.

[0097] In this embodiment, a candidate lane vector may include multiple candidate lane segment vectors and the topological relationships between the multiple candidate lane segment vectors. First, the topological relationships between the candidate lane segment vectors and the different candidate lane segment vectors are used to determine the embedding vector corresponding to each candidate lane segment vector. Here, the embedding vector includes the position embedding information of the candidate lane segment vector. The position embedding information reflects the spatial position and relationship characteristics of the candidate lane segment vector in the overall road network. Then, based on the embedding vector, a preset prediction model is used to automatically generate the lane type to which each candidate lane segment in the candidate lane vector belongs. The main purpose of position embedding is to provide the prediction model with the position information of each word in the input sequence so that the prediction model can use the order of words to understand the context. Therefore, guided by the position embedding information, the prediction model can accurately generate the lane type to which the candidate lane segment belongs. This method can quickly filter out target lane segments belonging to the target lane type from the candidate lane segments. Then, based on the semantic features of the road elements associated with the target lane segment, the effective time of the target lane segment can be further determined; ultimately, the target lane data not only includes the location range and effective time of the target lane segment, but also covers the detailed lane segment data associated with it. This method significantly improves the accuracy and efficiency of target lane identification, providing more reliable and detailed data support for traffic management and intelligent navigation.

[0098] Taking the production scenario of the bus lane scope in the aforementioned road scenario as an example, after the semantic OBJ production is completed in (1.3), the bus lane scope production process can also be included, and the lane segments in the candidate lane path are associated with their left and right lane lines, ground signs, ground text, etc. to produce lane segment laneset attribute data. The bus lane data is determined based on the laneset attribute data and the topological relationship between different lanesets. Specifically, a vectorized prediction model input embedding vector can be constructed based on the multiple candidate lane segment vectors and their attribute data in the candidate lane path, and the lane type corresponding to each candidate lane segment laneset is predicted by the prediction model. Then, the candidate lane segment lanesets in the candidate lane path are grouped according to the same lane type, and the geometric coordinates of the candidate lane segment lanesets of the bus lane type in the same group are taken to form the final bus lane scope, and the effective date and time of the corresponding bus lane scope are determined according to the associated bus lane semantic OBJ. Optionally, after the semantic OBJ production is completed in (1.3), the bus lane scope production process can be as follows:

[0099] (2.1) Lane segments can be constructed based on topo relationships, eliminating topo relationships with multiple connections, and generating a primary path (i.e., the first path) through a depth-first traversal method. After generating the primary path, two adjacent primary paths with a direction angle less than a preset angle are spliced ​​together based on the topological relationships between different lane segments to generate a secondary path (i.e., the second path).

[0100] (2.2) The secondary path generated by (2.1) is matched and associated with the semantic OBJ generated by (1.3) through geometric coordinates, and the secondary path associated with the bus lane type semantic OBJ is selected as the candidate lane path. The starting and ending ranges (Scope) of the bus lane are within the candidate lane path.

[0101] (2.3) For the candidate lane path generated in (2.2), associate the candidate lane segment with its adjacent lane line vectors and ground object vectors. Determine the attributes of the adjacent lane lines, road boundary attributes, and the attributes and content of ground signs that intersect the candidate lane segment. Tokens are constructed based on this data and the normalized geometric coordinates of the candidate lane segment.

[0102] (2.4) The candidate lane segment lane set tokens corresponding to the candidate lane path generated in (2.3) and the position embedding vector constructed based on the topo topological relationship between the candidate lane segments in the candidate lane path are used as the input data of the prediction model.

[0103] like Figure 5 The figure shows a schematic diagram of the architecture of a prediction model provided by an embodiment of the present application. The input sequence is first converted into a fixed-dimensional vector representation through an embedding layer. The positional encoding of the input sequence is added to the embedding vector based on the position embedding information through position embedding to retain the position information of the words in the input sequence. The input data is then lane encoded (lane encoder) and information exchange is completed through the transformer method. Finally, the prediction model classifies each token based on the corresponding prompt word, predicts the lane type corresponding to each token (i.e., lane segment lane set), and outputs the prediction result (predict).

[0104] (2.5) The lane type prediction results for each candidate lane segment within the candidate lane path predicted by the model in (2.4) are processed for consistency based on line type and other factors. The predicted lane type for each candidate lane segment is compared with the lane type in the actual scenario to ensure that there are continuous bus lane types within the candidate lane path. Finally, the geometric coordinates of the continuous lane segments corresponding to the bus lane are extracted to generate the final bus lane scope. In actual scenarios, a candidate lane path may contain multiple bus lane scopes.

[0105] The above road data processing method provides a target lane scope creation solution. This method implements a multimodal matching solution based on map vector elements, combined with geometric coordinates and content. This solution, combined with lane attribute understanding, constructs a semantic object (OBJ) to express traffic rules and restrictions. Furthermore, based on semantic object and path construction, a vector-centric target lane scope creation solution is proposed, providing more reliable data support for lane-level navigation systems and helping to improve navigation safety.

[0106] like Figure 6 The figure shows a flow chart of a road data processing method provided by this application. Taking the bus lane scope production scenario in a road scene as an example, it mainly includes two parts: semantic OBJ production and bus lane scope production. Specifically, it can include the following steps:

[0107] Step 601: Obtain map element vectors after abstraction of road data, including but not limited to lane lines, ground signs, text, etc., and determine a set of semantic OBJ candidate elements through nearest neighbor search.

[0108] Step 602: Divide road elements with the same set of semantics into a semantic group through semantic matching.

[0109] Step 603: Determine the semantic information (such as lane type, effective time, date, etc.) expressed by the group of road elements through semantic understanding to generate a semantic OBJ.

[0110] Step 604: Path generation: for each semantic group, generate a complete set of paths by performing a depth-first traversal on the lane segments laneset.

[0111] Step 605: Match and associate the paths in the path set with the semantic OBJ, and select candidate lane paths whose lane types are related to bus lanes.

[0112] Step 606: Associate the lane segments in the candidate lane path with their left and right lane lines, lane width, ground markings and other information to generate attribute data of the lane segment laneset.

[0113] Step 607: Construct a vectorized model input embedding based on the candidate lane paths and attribute data, and predict the lane type corresponding to each lane segment laneset through the prediction model.

[0114] Step 608: Post-processing smoothes the lane types within the candidate lane path to improve lane generation accuracy. Lane segments within the candidate lane path can be grouped by type. For bus lane-type lane segments within the same type group, their geometric coordinates are used to form the final bus lane scope. The bus lane semantic object associated with the lane segment determines the effective date and time for the corresponding bus lane scope.

[0115] For details of each step of the above method, please refer to the relevant description of the above embodiment, which will not be repeated here.

[0116] Please see Figure 7 , which is a road data processing device 700 of an embodiment of the present application, the device can be applied to the electronic device 1, and can be applied to Figure 2 In the road data processing application scenario shown in , the target lane is accurately identified from the road data, providing more reliable data support for the lane-level navigation system and helping to improve the safety of the navigation process. The device includes: an acquisition module 701, an identification module 702, a first determination module 703, and a second determination module 704. The functional principles of each module are as follows:

[0117] An acquisition module 701 is used to acquire road data to be processed, where the road data to be processed includes road elements and lane vector data;

[0118] Recognition module 702, for recognizing semantic features of road elements;

[0119] A first determining module 703 is configured to determine a candidate lane vector belonging to a target lane type in the lane vector data based on a semantic feature of a first road element associated with the lane vector data;

[0120] The second determining module 704 is configured to determine target lane data in the candidate lane vector based on a second road element associated with the candidate lane vector, wherein the road element includes a first road element and a second road element.

[0121] In one embodiment, the road data to be processed also includes lane lines of each lane; the identification module 702 is used to determine road elements belonging to the same lane based on the lane lines; and respectively identify semantic features of the road elements belonging to the same lane.

[0122] In one embodiment, the recognition module 702 is specifically configured to group road elements belonging to the same lane according to distance to generate a plurality of candidate element sets; and to identify the semantic content and location information of each road element in the candidate element set, wherein the semantic features include the semantic content and location information.

[0123] In one embodiment, the device further includes: a grouping module for grouping, for each candidate element set, road elements in the candidate element set whose semantic similarity is greater than a preset threshold into the same semantic group based on semantic features to generate multiple semantic groups.

[0124] In one embodiment, the lane vector data includes vector data of multiple lane segments and a topological relationship between the multiple lane segments. A first determination module 703 is configured to determine at least one path information formed by the multiple lane segments based on the topological relationship and the vector data of the multiple lane segments; determine a first road element associated with the position of each lane segment in the path information based on the position information of the road elements; and screen, from the path information, a candidate lane path having a semantic type of the target lane type based on the semantic content of the first road element, wherein the candidate lane vector includes the lane segment vectors forming the candidate lane path.

[0125] In one embodiment, the first determination module 703 is configured to remove multidirectional topological relationships from the topological relationships based on the topological relationships and vector data of the multiple lane segments, and to splice the multiple lane segments based on the removed topological relationships to form a first path, where the first path is a single-line path. Furthermore, based on the topological relationships, two adjacent first paths whose direction angle is less than a preset angle are spliced ​​together to generate a second path, where the path information includes the second path and the unspliced ​​first path.

[0126] In one embodiment, the second determination module 704 is configured to determine, based on the lane line, a second road element belonging to the same lane as the candidate lane vector and a target lane line belonging to the candidate lane vector; and determine target lane data in the candidate lane vector based on the second road element and the target lane line.

[0127] In one embodiment, the candidate lane vector includes multiple candidate lane segment vectors and the topological relationship between the multiple candidate lane segment vectors; the first determination module 703 is used to generate an embedding vector of the candidate lane vector based on the topological relationship between the second road element, the target lane line, and the multiple candidate lane segment vectors; based on the embedding vector, generate the lane type to which each candidate lane segment in the candidate lane vector belongs using a preset prediction model; based on the lane type, filter out a target lane segment belonging to the target lane type from the multiple candidate lane segments; determine the effective time of the target lane segment based on the semantic features of the road element of the target lane segment; the target lane data includes the location range of the target lane segment and the effective time of the target lane segment.

[0128] For a detailed description of the road data processing device 700 , please refer to the description of the relevant method steps in the above embodiment. The implementation principle and technical effects are similar and will not be repeated here in this embodiment.

[0129] Figure 8 This is a schematic diagram of the structure of a cloud device 80 provided by an exemplary embodiment of the present application. The cloud device 80 can be used to run the method provided by any of the above embodiments. Figure 8 As shown, the cloud device 80 may include: a memory 804 and at least one processor 805, Figure 8 A processor is used as an example.

[0130] The memory 804 is used to store computer programs and can be configured to store various other data to support operations on the cloud device 80. The memory 804 can be an object storage service (OSS).

[0131] The memory 804 may be implemented by any type of volatile or non-volatile memory device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk.

[0132] The processor 805 is coupled to the memory 804 and is used to execute the computer program in the memory 804 to implement the solution provided by any of the above method embodiments. The specific functions and technical effects that can be achieved are not described in detail here.

[0133] Furthermore, if Figure 8 The cloud device also includes: a firewall 801, a load balancer 802, a communication component 806, a power supply component 803 and other components. Figure 8 Only some components are shown schematically, which does not mean that the cloud device only includes Figure 8 Components shown.

[0134] In one embodiment, the above Figure 8The communication component 806 is configured to facilitate wired or wireless communication between the device where the communication component 806 is located and other devices. The device where the communication component 806 is located can access a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G, LTE (Long Term Evolution, Long Term Evolution, referred to as LTE), 5G and other mobile communication networks, or a combination thereof. In an exemplary embodiment, the communication component 806 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 806 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra wide band (UWB) technology, Bluetooth (BT) technology and other technologies.

[0135] In one embodiment, the above Figure 8 The power supply component 803 provides power to various components of the device where the power supply component 803 is located. The power supply component 803 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device where the power supply component is located.

[0136] An embodiment of the present application further provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the method of any of the aforementioned embodiments is implemented.

[0137] An embodiment of the present application also provides a computer program product, including a computer program, which implements the method of any of the aforementioned embodiments when executed by a processor.

[0138] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the module division is only a logical function division. In actual implementation, other division methods may be used. For example, multiple modules can be combined or integrated into another system, or some features can be ignored or not implemented.

[0139] The above-mentioned integrated module implemented in the form of a software functional module can be stored in a computer-readable storage medium. The above-mentioned software functional module is stored in a storage medium and includes a number of instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) or a processor to perform some steps of the methods of various embodiments of the present application.

[0140] It should be understood that the above-mentioned processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. The general-purpose processor can be a microprocessor or the processor can be any conventional processor, etc. The steps of the method disclosed in the application can be directly embodied as being executed by a hardware processor, or can be executed by a combination of hardware and software modules in the processor. The memory may include high-speed RAM (Random Access Memory) memory, and may also include non-volatile storage NVM (Nonvolatile memory, NVM for short), such as at least one disk memory, and can also be a USB flash drive, a mobile hard disk, a read-only memory, a disk or an optical disk, etc.

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

[0142] An exemplary storage medium is coupled to a processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be an integral part of the processor. The processor and the storage medium can be located in an application specific integrated circuit (ASIC). Of course, the processor and the storage medium can also exist as discrete components in an electronic device or a main control device.

[0143] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, apparel, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, apparel, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, apparel, or apparatus comprising the element.

[0144] The serial numbers of the above embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0145] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods of each embodiment of the present application.

[0146] In the technical solution of this application, the collection, storage, use, processing, transmission, provision and disclosure of user data and other information involved comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0147] The above are only preferred embodiments of the present application and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A road data processing method, characterized in that: include: Acquiring road data to be processed, wherein the road data to be processed includes road elements and lane vector data; identifying semantic features of the road elements; determining, based on the semantic feature of the first road element associated with the lane vector data, a candidate lane vector belonging to a target lane type in the lane vector data; The target lane data in the candidate lane vector is determined based on a second road element associated with the candidate lane vector, wherein the road element includes the first road element and the second road element.

2. The method according to claim 1, characterized in that The road data to be processed also includes lane lines of each lane; and the identifying semantic features of the road elements includes: Based on the lane lines, determining road elements belonging to the same lane; Semantic features of road elements belonging to the same lane are identified separately.

3. The method according to claim 2, characterized in that The semantic features of the road elements belonging to the same lane are respectively identified, including: Aggregating the road elements belonging to the same lane according to distance to generate multiple candidate element sets; Respectively identifying the semantic content and location information of each road element in the candidate element set, the semantic features including the semantic content and the location information; and / or The method further comprises: For each candidate element set, the road elements in the candidate element set whose semantic similarity is greater than a preset threshold are divided into the same semantic group based on the semantic features to generate multiple semantic groups.

4. The method according to claim 3, characterized in that The lane vector data includes vector data of a plurality of lane segments and a topological relationship between the plurality of lane segments; and determining, based on the semantic feature of the first road element associated with the lane vector data, a candidate lane vector belonging to a target lane type in the lane vector data, includes: determining at least one path information formed by the plurality of lane segments based on the topological relationship and the vector data of the plurality of lane segments; determining, based on the position information of the road element, the first road element associated with each lane segment position in the path information; Based on the semantic content of the first road element, a candidate lane path having a semantic type of a target lane type is screened from the path information, the candidate lane vector including lane segment vectors forming the candidate lane path.

5. The method according to claim 4, characterized in that The determining, based on the topological relationship and the vector data of the plurality of lane segments, at least one path information formed by the plurality of lane segments includes: Based on the topological relationship and the vector data of the plurality of lane segments, removing the multidirectional topological relationship from the topological relationship, and splicing the plurality of lane segments based on the removed topological relationship to form a first path, where the first path is a single-line path; According to the topological relationship, two adjacent first paths whose direction angle is smaller than a preset angle are spliced ​​to generate a second path, and the path information includes the second path and the unspliced ​​first path.

6. The method according to claim 2, characterized in that The determining the target lane data in the candidate lane vector based on the second road element associated with the candidate lane vector includes: Based on the lane line, determining the second road element that belongs to the same lane as the candidate lane vector and a target lane line that belongs to the candidate lane vector; Target lane data in the candidate lane vector is determined based on the second road element and the target lane line.

7. The method according to claim 6, characterized in that The candidate lane vector includes a plurality of candidate lane segment vectors and a topological relationship between the plurality of candidate lane segment vectors; and determining target lane data in the candidate lane vector based on the second road element and the target lane line includes: generating an embedding vector of the candidate lane vector based on a topological relationship among the second road element, the target lane line, and the plurality of candidate lane segment vectors; Based on the embedded vector, generating a lane type to which each candidate lane segment in the candidate lane vector belongs by using a preset prediction model; Filtering a target lane segment belonging to a target lane type from the plurality of candidate lane segments based on the lane type; Based on the semantic features of the road elements of the target lane segment, the effective time of the target lane segment is determined; the target lane data includes the position range of the target lane segment and the effective time of the target lane segment.

8. A road data processing device, characterized in that: include: An acquisition module, configured to acquire road data to be processed, wherein the road data to be processed includes road elements and lane vector data; A recognition module, configured to recognize semantic features of the road elements; a first determining module, configured to determine, based on the semantic feature of the first road element associated with the lane vector data, a candidate lane vector belonging to a target lane type in the lane vector data; The second determining module is configured to determine target lane data in the candidate lane vector based on a second road element associated with the candidate lane vector, wherein the road element includes the first road element and the second road element.

9. An electronic device, characterized in that: include: at least one processor; as well as a memory communicatively coupled to the at least one processor; The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the electronic device to perform the method according to any one of claims 1 to 7.

10. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 7 when being executed by a processor.

Images