Method for assembling local high definition map, system for using map data, computer program product and computer readable medium for implementing method

Abstract

The invention is a method for assembling a local high definition map, the method comprising the steps of:-receiving a plurality of path histories, where each path history comprises a set of location points successively traversed by an entity,-building an initial undirected graph comprising location nodes, cross nodes and edges based on the plurality of path histories, wherein-each location node corresponds to one location point,-each crossing node corresponds to a crossing point of two path histories, and-an edge is defined between location nodes corresponding to adjacent location points of one of the path histories, and, in the case of a crossing node, the edge is defined between location nodes corresponding to adjacent location points of one of the path histories. An edge is defined between the intersection node and the location node corresponding to the location point of each of the two respective path histories, the respective intersection point being located between the location points, and-in a reduction step, a reduction graph is generated by removing redundancy of the received path histories. The invention is also a system for providing map-related information for traffic safety applications. The invention also relates to a computer program product and a computer readable medium for performing the method.

Description

Technical Field

[0001] The present invention relates to a method for assembling a local high-definition map and a system for using map data. The present invention also relates to a computer program product and a computer-readable medium for implementing the method.

[0002] The present invention relates to cooperative intelligent transportation systems (C-ITS) that allow communication between vehicles, infrastructure and other roadside units. This type of communication is also known as V2X (Vehicle to Everything). The radio and protocol implementation is not critical to a V2X system, so a V2X system can be implemented or integrated into any current or future system.

[0003] Through V2X communication, vehicles and other traffic participants can share information about the surrounding road topology and geometry, which fundamentally improves their position and situation awareness. In addition, this shared information immediately improves the quality of decision-making and filtering efficiency, that is, selecting relevant situations to be processed, such as potentially dangerous situations.

[0004] Map matching is a process of assigning objects - for example, vehicles or other traffic participants - to locations on a digital map. The data obtained from the positioning system naturally has uncertainties, so matching the positions of objects within the digital map leads to more accurate positioning and contributes to better situational awareness. This more accurate position information of objects with any geographical relevance can support the prediction of the movement of vehicles or any traffic participants, thus contributing to more sophisticated decision-making.

[0005] Map matching algorithms typically use inputs generated from positioning technologies such as global navigation satellite systems (GNSS), e.g., Global Positioning System (GPS), GNSS integrated with dead reckoning (DR) or real-time kinematics (RTKS), and supplement these inputs with data from accurate road network maps to find the object's travel route. The general purpose of a map matching algorithm is to identify the correct map object (e.g., road segment) on which a vehicle or any other entity with geographical relevance is traveling (or standing), preferably based on past position data, and to determine the corrected or matched position of the vehicle or other entity on that road segment. Map matching is therefore a prerequisite for various location-based applications such as navigation or vehicle tracking.

[0006] The accuracy of map matching depends largely on the quality of the map used for map matching. The more details the map contains, the more accurate the map matching results will be. Map data (usually in the form of digital map data) is usually provided by map providers (e.g., Google Maps, HERE, etc.), but can come from any source (e.g., files of any format uploaded to a processing entity). In order to reduce the computing power and memory size required to store maps, many map providers provide their maps in standard definition map (SD map) format. However, certain V2X applications can benefit more from high-definition (HD) maps, which preferably contain lane-level information. For technical and financial reasons, it is quite difficult to provide HD maps in most parts of the world, even in highly developed regions such as Europe or North America. For example, mapping an entire region (usually an entire city or country) is a tedious and expensive process, so HD maps are much more expensive than SD maps. Background Art

[0007] Map matching and V2X applications are well known in the industry. For an overview of commonly used map matching methods, see Chao P. et al.: "A Survey on Map-Matching Algorithms", in: Borovica-Gajic, R., Qi, J., Wang, W. (eds) Database Theory and Applications, ADC 2020, Lecture Notes in Computer Science, Volume 12008, Springer, Cham (2020) and Mohammed A. Quddus et al.: "Current map-matching algorithms for transport applications: State-of-the-art and future research directions", in: Transportation Research Part C: Emerging Technologies, Volume 15, Issue 5, 2007, Pages 312-328 (2007).

[0008] In addition, US 11127292 B2 discloses a method and apparatus for determining lane-level static and dynamic information. The application determines lane-level data based on a latitude and longitude trajectory cloud of a vehicle.

[0009] US 2015 / 0025789 A1 discloses a technique for lane assignment in a vehicle, wherein lane assignment is performed based on past trajectories. The technique disclosed in this application only determines a relative lane assignment compared to a vehicle (ego vehicle).

[0010] In view of the known methods, there is a need for a method that allows assembly of a local HD map, which preferably can be used for map matching or other applications that benefit from detailed, high-precision map knowledge, especially when no other HD maps are available. Summary of the invention

[0011] The main object of the invention is to provide a method for assembling a local high-definition map which is free of the disadvantages of the prior art methods to the greatest extent possible.

[0012] Another object of the present invention is to provide a system for improving the accuracy of locating other entities in a traffic ecosystem and thereby supporting decision making.

[0013] Furthermore, the object of the present invention is to provide a non-transitory computer program product for implementing the steps of the method according to the present invention on one or more computers, and a non-transitory computer-readable medium comprising instructions for executing the steps of the method on one or more computers.

[0014] The objects of the invention are achieved by a method according to claim 1. The objects of the invention are also achieved by a system according to claim 8, a non-transitory computer program product according to claim 15 and a non-transitory computer readable medium according to claim 16. Preferred embodiments of the invention are defined in the dependent claims.

[0015] As mentioned above, in many parts of the world, no HD maps are available, however, having HD maps can greatly improve map matching accuracy and thus support decision making. The lack of HD maps is a major obstacle in developed countries to create applications that require HD maps, such as applications that evaluate traffic data at the lane level, for example, applications also mentioned in this specification. Although the industry is already open to advanced driver assistance systems that consider lane-level information when making traffic safety decisions, it will still take many years to map HD road networks using traditional map generation techniques.

[0016] Another advantage of the present invention is that when HD maps are available, their accuracy can be checked and the present invention can also help track changes to HD maps. The present invention also provides a solution for situations where the HD map service is unavailable for some reason, such as in the event of a failure or coverage problem in the telecommunications network (e.g., 5G) that transmits it.

[0017] A very important advantage of the method according to the invention is that it enables the generation of local high-definition maps, ie maps which may contain lane-level information for a geographical area.

[0018] Another advantage of the method according to the invention is that it can use real-time or up-to-date traffic data, so that the generated local high-precision map can contain information about any recent changes to the map, i.e., lanes that suddenly become unavailable due to an accident, ongoing road works or recently completed road works, thereby allowing more lanes or roads to be connected to the geographical area in question.

[0019] It is recognized that creating your own local high-precision maps can contribute to better situational awareness, better decision-making, and increased availability when no HD maps are available. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Preferred embodiments of the present invention are described below by way of example with reference to the accompanying drawings, in which

[0021] Figure 1A-Figure 1C An exemplary embodiment of the method for assembling a local high-definition map according to the present invention is shown.

[0022] Figure 2A and Figure 2B is an exemplary use case scenario according to the method of the present invention,

[0023] Figure 3 is a block diagram of a preferred embodiment of a system according to the present invention,

[0024] Figure 4 is a graph showing an exemplary angle difference shaping function, and

[0025] Figure 5 is a graph illustrating an exemplary distance difference shaping function. DETAILED DESCRIPTION

[0026] The present invention relates to a method for assembling a local High Definition (HD) map, which method can preferably be used in any application that requires or benefits from using a local HD map.

[0027] The method according to the invention comprises the step of receiving a plurality of path histories, wherein each path history comprises a set of position points traversed successively by an entity. The path histories are preferably received via V2X messages, even more preferably from nearby entities capable of sharing their position information. Preferably, the path histories are received for a predetermined geographical area around the current position of the ego vehicle, and / or for a period of time (e.g. 30 minutes, 1 hour, 2 hours) before the ego vehicle arrives at said geographical area.

[0028] In a preferred embodiment of the method according to the present invention, the path history of nearby entities is collected by a processing unit of a receiving entity, wherein the receiving entity can be, for example, the ego vehicle, or a roadside unit that transmits the collected path history to other entities that need the path history.

[0029] The method according to the present invention also includes the step of constructing an initial undirected graph including position nodes, intersection nodes and edges based on a plurality of path histories. In the initial undirected graph, each position node corresponds to a position point (i.e., a position point of any received path history), each intersection node corresponds to an intersection point of two path histories, and edges are defined between position nodes corresponding to adjacent position points of one of the path histories, and for an intersection node, edges are defined between two position nodes in each of the two corresponding path histories where the intersection node and the intersection point are located.

[0030] Preferably, the path history is received as an ordered set (or matrix) of locations, e.g., path history location points P i,j Represents the jth position point of the i-th path history. In the initial undirected graph, it is the path history point P i,j Each of the defines a location node.

[0031] If two path histories have an intersection X k , then the intersection point X k Define an intersection node. The intersection point can be defined as follows: If the path generated based on the first path history intersects with the path generated based on the second path history, the point where the two paths intersect each other is the intersection point X. k . It can be done by connecting the adjacent position points P of a given path history i,j and P i,j+ Or by the adjacent position point P i,j and P i,j+1 Interpolate between to generate the path.

[0032] According to the method of the present invention, between adjacent position points of the path history, that is, between the path history position points P i,j and P i,j+1 In addition, edges are defined between intersection nodes and position nodes corresponding to position points of each of the corresponding two path histories between the position points where the corresponding intersection points are located.

[0033] For example, when the intersection X k is the position point P m,q and P m,q+1 and P n,r and P n,r+1 When the intersection of the mth and nth path histories is reached, then at the intersection point X kThe corresponding intersection nodes and are respectively related to the position point P m,q , P m,q+1 , P n,r and P n,r+1 One edge is defined between each of the corresponding position nodes, that is, a total of four edges will be connected to the intersection point X k The corresponding intersection node and position point P m,q , P m,q+1 , P n,r and P n,r+1 The corresponding position nodes are connected.

[0034] The method according to the present invention further comprises the step of generating a reduced graph by removing redundancy of the path histories in the reduction step. Redundancy of the path histories means that different entities are or have traveled on the same road segment (same lane), so their respective path histories (or parts of their path histories) are identical or very similar to each other. It is preferable to remove these path histories because they do not add any additional information to the local HD map and are therefore filtered out.

[0035] Preferably, the reducing step comprises a merging step to merge redundant path histories, wherein two or more path histories are redundant if they correspond to the same road link, eg the same section (preferably the same lane) of a road link.

[0036] The merging step preferably includes

[0037] - provide predefined similarity thresholds,

[0038] - define the similarity value of two parts of the path history, and

[0039] - if the similarity values ​​of the location nodes of the two path histories are within a predefined similarity threshold,

[0040] Then merge them.

[0041] Preferably, the similarity value is determined based on the lateral distance between the position points of the two corresponding path histories. If two or more path histories or parts of path histories can be marked as mergeable, they can be merged into one path by eliminating the nodes and edges of the redundant parts and defining the nodes and edges of the merged part, see e.g. Figure 1B .

[0042] Preferably, the reduction step comprises an edge removal step to remove pseudo edges, wherein pseudo edges correspond to arbitrary lane changes, for example lane changes performed due to overtaking maneuvers. These lane changes usually appear at random locations, so there may be no other path history including such lane changes. In a preferred embodiment of the method according to the invention, edges are removed if they are only connected to the merged part of the reduced graph. This approach ensures that road segments traveled by only a single entity are not discarded, but included in the local HD map.

[0043] Preferably, the reduction step is performed in an iterative manner, i.e. the merging step and / or the edge removal step are performed in an iterative manner until all redundancies of the path history and all pseudo edges are removed. The resulting reduced map can be used as a local HD map. An advantage of the method according to the invention is that the resulting local HD map will also reflect temporary interruptions, such as lane unavailability due to accidents or road works etc. Therefore, the resulting local HD map is beneficial for V2V (vehicle to vehicle) collision detection scenarios.

[0044] Figures 1A to 1C An exemplary embodiment of the method according to the invention is shown in steps. Figure 1A A received path history 10 for a given road segment with a merged lane is shown. Each path history 10 includes a set of location points 12, and for easier viewing, the same symbol represents location points 12 belonging to the same path history 10. By connecting the location points 12 belonging to the same path history 10, the path traveled by the entity can be better visualized.

[0045] Figure 1B The diagram shows a location node 20 corresponding to the location point 12 and an intersection node 22 corresponding to the intersection of the two path histories 10. The location node 20 and the intersection node 22 are nodes of the initial undirected graph. An edge 24 is defined between adjacent location nodes 20, i.e., Figure 1A The location nodes 20 corresponding to the location points 12 denoted by the same symbol in FIG. 1 and FIG. 2 are also shown. In addition, an edge 24 is defined between the intersection node 22 and the nearest location node 20 corresponding to the intersection path history 10 .

[0046] also, Figure 1B An example of a reduced graph 30 is shown in which location nodes and edges of redundant path histories are merged. The reduced graph 30 contains merged location nodes 25, merged intersection nodes 26 and merged edges 28.

[0047] Figure 1C An example of a reduced graph 30' is shown, which can be used as a local high-definition map, wherein the reduced graph 30' has merged location nodes 25', merged intersection nodes 26' and merged edges 28'. Figure 1CIt can be seen that in the case of merging lanes, the method according to the present invention does not trim the connecting road segment, but eliminates any lane changes between the other two lanes in the process.

[0048] It is important to note that the more path histories 10 available at a certain geographic location, the higher the accuracy of the assembled local HD map. Therefore, it is advantageous if a sufficient number of V2X entities are available at that geographic location. The content of V2X messages in all major regions of the world may contain information about the past / recent movements of the entities (also known as path histories), which can serve as a basis for assembling a local HD map.

[0049] The method according to the present invention helps several V2X-based applications that require lane-level map matching to avoid erroneous situation assessments. As an example, a forward collision warning (FCW) application is typically designed to check the motion of the ego vehicle 50 relative to another object 52 ahead, i.e., traveling in the same lane as the ego vehicle 50. This scenario is Figure 2B As shown. If the area 54 in front of the ego vehicle 50 is not defined according to actual driving and road conditions, for example, if the ego vehicle 50 is predicted to travel along the area 54 with different curvatures, false positives or negatives may occur. Therefore, it is important to define the area 54 in front of the ego vehicle 50 according to the actual geometry of the road to be traveled, so that the efficiency of the forward collision warning can be significantly improved.

[0050] Another example is when the driver of the ego vehicle 50 intends to perform a lane change, and the application is designed to check whether another object 52 is dangerously close in the target adjacent lane. In this case, it is crucial to accurately determine the relative lane positions of the two objects.

[0051] Knowledge of the local high-precision map also benefits other collision detection methods and applications. Knowing which locations are reachable from a certain starting point can help with potential hazards in false detection situations, where the local road map does not allow for physical transformation from one location to another. Figure 2A If no map information is available in the scene, the ego vehicle 50 may receive a collision warning, but in reality, a collision is unlikely to occur if the roads used by the ego vehicle 50 and the other object 52 do not intersect each other.

[0052] Unlike current solutions, which are mainly based on radar and can only detect and signal collision danger in a straight line and at a certain distance, the solution we describe is able to provide highly accurate collision danger signals (forward collision warning) based on the position and motion information of each vehicle, while being able to suppress false signals by observing that vehicles are unlikely to interact given their position, trajectory and road topology. However, this is only possible on HD maps that include lane data.

[0053] The invention also relates to a system for providing map-related information for traffic safety applications. The system according to the invention is preferably implemented on a processing entity, or it can be distributed on multiple processing entities. The processing entity can be a vehicle, a part of a vehicle or a part of an infrastructure.

[0054] The system according to the invention is adapted to receive digital map data 79 and the position of an object. Preferably, the system can also be adapted to receive motion dynamics data of an object. An object can be a vehicle or other traffic participant, such as a cyclist, a pedestrian or a motorcycle. In general, an object can be any physical or virtual entity that can be associated with a geographical location. An object can be stationary or it can be mobile. An object can be equal to the processing entity itself, i.e., a processing entity on a vehicle. In this case, we refer to the object as an ego object or an ego vehicle. In any other case, we refer to the object as a remote object or a remote vehicle.

[0055] Preferably, the digital map data 79 received by the system may be provided by the method according to the invention or by a map provider 78. The system may preferably obtain the digital map data generally from any wired or wireless Internet access, but may generally be obtained from any other source and means.

[0056] In a V2X / C-ITS system, entities can communicate with each other via dedicated wireless communication channels (e.g., DSRC, C-V2X PC5). By receiving data on these channels, position information 71 and / or motion dynamics data of remote objects (such as remote vehicles 72) can be obtained, but more generally, the data can be obtained from any other source. The data of remote objects is usually first processed by a dedicated protocol stack and then stored in an object database 70.

[0057] The ego object may typically obtain its own ego position data 73 (geolocation), for example, via a ego positioning subsystem 74 using well-known global positioning systems (GNSS 75 , RTKS 76 ) and / or using a dead reckoning (DR) algorithm 77 , but in general this information may come from any source.

[0058] The system according to the invention further comprises a map matching module 80 adapted to calculate map matching position information based on the position of the object and the digital map data. The map matching module 80 preferably uses any known map matching method or algorithm known in the art.

[0059] The system according to the invention further comprises an object database 70 connected to the map matching module 80 , wherein the object database 70 is adapted to store positions of objects and map matching information of the objects calculated by the map matching module 80 .

[0060] Preferably, the location of the object is provided by the remote vehicle 72 and / or by a self-localization subsystem 74 connected to the object database 70 and / or to a map matching module 80 .

[0061] The system according to the present invention preferably further comprises an object priority module 82 adapted to determine objects to be map matched by the map matching module 80, wherein the object priority module 82 is connected to the map matching module 80. Details of the object priority module 82 will be discussed later.

[0062] The system according to the invention preferably further comprises one or more map-aware filters 88 adapted to classify objects stored in the object database 70 based on their relevance to entities of the hosting system. Preferably, the classification of objects is performed by the map-aware filters 88 based on the distance between the location of the object and the location of the entity of the hosting system.

[0063] The object database 70 is preferably in communication with a map-aware application 90 , wherein the map-aware application 90 is a forward collision warning module, a cross motion assist module, and / or a context-based priority module.

[0064] Figure 3 A preferred exemplary embodiment of the system according to the invention is shown in FIG.

[0065] exist Figure 3 In the embodiment, the system is implemented on an ego vehicle 50, which is capable of receiving position information 71 and / or motion dynamics data of a remote vehicle 72. The ego vehicle preferably also has a self-positioning subsystem 74, which is connected to a positioning system such as GNSS 75 and RTKS 76, and it is also capable of determining self-positioning data 73 using a dead reckoning (DR) algorithm 77. According to this specific example, the position information 71 of the remote vehicle 72 and the self-positioning data 73 determined by the self-positioning subsystem 74 are fed to the object database 70.

[0066] according to Figure 3The system also has a map matching module 80, which is connected to the object database 70 to store map-matched object data 86 calculated by the map matching module 80. The map matching module 80 preferably uses digital map data 79 received from a map provider 78, or a local HD map received from the map provider 78 or an entity that calculates it based on recent local path history (e.g., by using the method according to the present invention). The ego vehicle 50 can also be the entity that calculates the local HD map. In any case, the local HD map is preferably calculated in real time.

[0067] To reduce the computations performed by the map matching module 80, the system includes an object priority module 82. Whenever new information about an object is received, the object database 70 consults the object priority module 82 (e.g., by sending the object location 81 to the object priority module 82) whether new map matching metadata needs to be computed based on the new information. The object priority module 82 preferably returns a set of filtered objects 85 for which new map matching information needs to be computed. Based on the set of filtered objects, the object database 70 preferably requests the map matching module 80 to compute new map matching information. The map matching module 80 preferably uses the current and past geographic locations of the objects and digital map data 79 (preferably provided by the map provider 78) to compute the map matching information for the set of filtered objects. In the process, the map matching module 80 matches each object in the set of filtered objects to the most appropriate map object and preferably provides at least the following information:

[0068] • The road or link (map entity) where the object (eg, vehicle) is located.

[0069] • The object's position on a matching map entity (eg, on a road).

[0070] - The direction of movement of the object along a matching map entity (eg, along a road).

[0071] The map matching module 80 preferably passes the newly calculated map matching information (map matched object data 86) back to the object database 70 where it is stored. Preferably, the map matching information is provided to the map aware application 90 using a map aware filter 88. The map aware filter 88 may use some auxiliary values ​​87 which are common to most map aware filters 88 and are updated each time new map matching information is available. The map aware filter preferably transmits the filtered object data 89 to the map aware application 90. An example of how the map aware application 90 uses this information is described later.

[0072] In parallel with the above process, the object priority module 82 preferably sends a set of object MAC addresses 83 to the context-based priority module 84 (operating in the MAC layer), which are not relevant information sources and should be filtered at a lower layer. The details of the map matching driver and context-based priority (CBP) will be given later.

[0073] First, a preferred embodiment of the object priority module 82 is described in more detail.

[0074] Since matching vehicles or other entities to the digital map data 79 is an expensive task, it is advantageous to include in the system a component whose task is to determine which vehicles or entities are "worthy" of matching in a particular processing cycle. The main idea behind this is that the system selects a few vehicles or entities to be map matched, while applying a much less computationally expensive algorithm to all other entities, e.g. entities that are less relevant from the perspective of the ego vehicle 50. Furthermore, the priority rules are preferably selected so as to maintain safety, i.e., to analyze potentially dangerous situations using the most up-to-date information.

[0075] To accommodate object priorities, the map matching module can be redesigned to use the post-trigger functionality of the entity subscription interface of the object database 70. This allows the system to collect all updates within a process cycle, assign them a priority value, and determine how each object should be processed afterwards.

[0076] Preferably, a priority list based on various rules is established in the object priority module 82. A group of vehicles is considered to have high priority per se, and their priorities are preferably arranged in descending order as follows:

[0077] • The ego vehicle 50 needs to perform map matching every time it is updated.

[0078] ● New objects to obtain information about their position and motion relative to the ego vehicle.

[0079] In addition to the above objects, objects are also classified according to their position on the road network relative to the ego vehicle 50. Those objects traveling on the same road as the ego vehicle 50 or on a road connected to the road of the ego vehicle 50 are assigned a higher priority than other objects. This classification is supported by filters that will be introduced later.

[0080] Preferably, higher priority objects are further categorized based on their distance on the road relative to the ego vehicle 50. Those objects that travel closer preferably have higher priority values, and within this category, there is a different set of objects that relate to those objects that are expected to interact with the ego vehicle 50 in the near future.

[0081] To summarize, it is best to define the following priority groups, ordered from highest priority onwards, where the priority value of each object is shown in parentheses:

[0082] ●Ego vehicle(0)

[0083] ●Recent Objects (1)

[0084] ● New / never-matched objects in the map (2)

[0085] ●High priority objects (last matching timestamp)

[0086] ●Medium priority objects (last match timestamp + medium priority match interval)

[0087] ●Low priority vehicle (last match timestamp + low priority match interval)

[0088] The object priority module 82 preferably selects the first N objects in the above list for map matching by the map matching module 80. For those objects that are not matched during the processing cycle, prediction is applied, which has negligible cost compared to map matching. If an object may have passed the intersection according to the prediction, it will be assigned a high priority because such an object may suddenly change its priority category.

[0089] The object priority module 82 may consider the following information:

[0090] Input

[0091] oObject data

[0092] ■Single motion parameter (position, direction, speed)

[0093] ■Object density (number of objects in the coverage area)

[0094] oDigital map data 79 (optional)

[0095] ■Road topology and geometry

[0096] ■ The position of the ego vehicle 50 and the remote object

[0097] ●Filter concepts (the following filter concepts can be combined to build custom complex rule sets, without requiring completeness)

[0098] o Filtering based on geometric distance

[0099] ■ Static size or adaptive size (e.g. based on ego velocity or object density)

[0100] ■ Areas of various shapes can be defined around the ego vehicle 50

[0101] ●Circular area

[0102] ● Rectangular area, possibly offset relative to the ego vehicle 50

[0103] oDistance-based filtering aided by road topology

[0104] ■The distance between objects is based on road distance (distance along the road)

[0105] ■Otherwise, similar to its geometric counterpart

[0106] oRoad relative filtering

[0107] ■Objects on the same road as the ego vehicle 50

[0108] ■ Objects located on a road connected to the road on which the ego vehicle 50 is traveling

[0109] ■ Direction filtering (remote objects are traveling in the same or opposite direction relative to the ego vehicle 50)

[0110] oFiltering based on object characteristics

[0111] ■Objects traveling at particularly high speeds

[0112] ■Sudden braking target

[0113] ■Special vehicles

[0114] ● Minimum interval between accepted incoming messages (per source)

[0115] oCan be selected as a fixed constant value within a specific range

[0116] o Can be set as a function of parameters (e.g., geometric / road-based distance to the ego vehicle 50)

[0117] ●Filter rule set example (values ​​do not necessarily match the target PPS value)

[0118] o No digital map data 79

[0119] ■Highest priority object (no filtering)

[0120] ●Meet all of the following criteria:

[0121] o In a rectangular area of ​​10 meters by 200 meters, centered on the ego vehicle 50 and pointing in the direction of movement of the ego vehicle 50

[0122] o Traveling in the same (geometric) direction as the ego vehicle

[0123] ■Medium priority object (receives a message every 1 second)

[0124] ● The distance to the ego vehicle 50 is less than 300 meters, and it does not belong to the previous group

[0125] ■Low priority object (receives a message every 2 seconds)

[0126] ●All other objects

[0127] o If digital map data 79 is available

[0128] ■Highest priority object (no filtering)

[0129] ● On the same road as the ego vehicle 50, within a distance of less than 100 meters, traveling in the same direction on the road

[0130] ● Additional criteria for remote objects (if any of the following items match):

[0131] o Relative to the front / rear self-vehicle 50 closest

[0132] o Speed ​​difference is at least 30 km / h (positive or negative)

[0133] oAcceleration is less than -5m / s^2

[0134] ■High priority object (receives a message every 500 milliseconds)

[0135] ● Objects on the same road as the ego vehicle 50, within a 100-meter radius, and traveling in the same direction as the ego vehicle 50, do not belong to the previous group

[0136] ■Medium priority object (receives a message every 1 second)

[0137] ● Objects on the same road as the ego vehicle 50, within a range of 100 to 300 meters, and traveling in the same direction as the ego vehicle 50

[0138] ■Low priority object (receives a message every 2 seconds)

[0139] ●All other objects

[0140] As described above, the map-aware filter 88 may use additional data, such as auxiliary values ​​87, to support filtering and map-aware applications 90. It has been recognized that filtering and map-aware applications 90 may be more efficient if certain variables are already calculated at a lower level to avoid calculating them multiple times when examining various vehicle / object pairs. Therefore, in addition to determining the ID of the current link (i.e., portion of a road), i.e., the current link ID of the current link along which the vehicle is traveling, other information is immediately calculated and collected.

[0141] Preferably, the basic values ​​may include the position projected onto the centerline of the current link, the ID of the node the vehicle is heading toward along the link, the ID of the last node the vehicle has passed, the remaining distance to the next node, and the length of the current link.

[0142] However, as often seen in connectivity graphs, roads tend to be split into multiple links, even between road junctions, for a variety of possible reasons. When examining remote vehicles traveling on a particular road, these links should be collected and processed as a whole. This will improve the filtering process and thus improve application performance. As an illustrative example, when examining forward collision risk, vehicles traveling on the same road in front of the ego vehicle 50 need to be selected first. If the search is limited to the links on which the ego vehicle 50 travels, there will be a considerable number of overlooked but relevant vehicles (objects) traveling on another connected link. This approach can be improved by considering connected links, supplemented with other information, such as road grade, driver intentions (such as turn signals, speed, and speed changes).

[0143] Preferably, to expand the relevant area for a particular vehicle and to make the search more powerful, a search may be performed in the connectivity graph and the current link may be extended in both directions to find the segment between two junctions and the longest continuous "straight" segment.

[0144] As in the case of the current link, the same information can be collected for these extended road segments. In addition, the direction of the last segment in each direction can be stored for the extended link, which is useful when the angle of the connecting road needs to be calculated.

[0145] As described above, the map-aware filter 88 preferably performs classification and filtering.

[0146] In general, and especially when real-time information sharing between V2X and transport participants will be widespread, local environment models are expected to include a large number of non-stationary entities in the vicinity of an entity. Most of these entities usually have a small or negligible effect on the motion of the host entity, since they are unlikely to interact within a reasonable timeframe. Therefore, for computational performance reasons, a critical step in the situation analysis is to efficiently select those entities that are likely to be relevant from the perspective of the host entity. The process of determining the relevance of remote entities involves several factors and cannot be reduced to, for example, selecting the nearest entity on the same road. Therefore, a set of tools suitable for selecting relevant remote entities for further analysis is described.

[0147] Classification plays an important role in the framework of the object database 70. A set of binary decision variables are preferably calculated for the remote entity, which indicates a simplified relationship between the remote entity and the ego vehicle 50. When digital map data 79 is available, a subset of these variables can be calculated based on the results of map matching, which is expected to lead to more accurate decisions.

[0148] The set of binary decision variables may indicate whether the remote vehicle 72 is in front of / behind the ego vehicle 50, whether the vehicles are traveling in the same direction or in opposite directions, and whether they are approaching each other from the left or the right. Furthermore, if lane-level information is available, one may even determine whether the two vehicles (i.e., the remote vehicle 72 and the ego vehicle) are traveling in the same lane, or how many lanes separate the remote vehicle 72 to the left or right relative to the ego vehicle 50.

[0149] Therefore, the concept of improving the classification is that when the map matching results are available and sufficiently updated for both the ego vehicle 50 and the remote vehicle 72, the appropriate relationship can be determined using this information. Otherwise, the original classification is always available as a fallback option.

[0150] In addition to computing basic relationship information between pairs of vehicles, remote vehicles 72 can also be filtered based on geometric properties. Filters in the object database 70 typically include classification and geometric requirements. The latter part can be used to limit the selection of vehicles of interest to those located in a specific area, which can be described by their absolute position or relative to a reference vehicle.

[0151] In some cases, vehicles within a certain distance are considered relevant, while in other cases it is vehicles travelling in front of or behind the reference vehicle. In addition to this, the object database 70 provides filters for selecting vehicles located within a polygon or circle relative to the ego vehicle 50, these filters are intended to filter out vehicles travelling on the same or connected roads. Map information can also be used to enhance these filters. Obviously, the filters described above can work well on straight roads, especially in urban environments where vehicles travel at low speeds. However, this approach will generally fail on roads or road connections where these assumptions do not hold (although the polygon can be enhanced during curves, once the vehicle enters the curve, the accuracy will be very poor if map matching is not performed). Furthermore, relying on GNSS 75 altitude measurements (if altitude is available) may also lead to erroneous results due to poor accuracy.

[0152] Using map matching, a different approach can be introduced. Checking for vehicles traveling on the same road or connecting roads is reduced to comparing the identifier of the current road (link) they are traveling on or comparing the identifier of the upcoming road connection (node). The approach of checking the upcoming node ID can be further extended to check up to a certain depth combined with the link length (in practice, 2).

[0153] Filters that meet the needs of FCW and IMA applications can be added to the object database 70. Preferably, two filters are introduced, namely "Same Road Filter" and "Connecting Road Filter". As their names suggest, they are intended to provide a method for selecting vehicles that travel along the same road segment or connected road segments with a reference vehicle. The "Same Road Filter" preferably operates on the extended straight road information calculated in the map matching results, while the "Connecting Road Filter" preferably checks the junction to junction road segments. In addition to the common set of classification flags mentioned above, both filters can have a length attribute, which can be configured as static or adaptive (depending on the speed of the reference vehicle) and can be used to filter remote vehicles within a certain distance.

[0154] The "Connecting Roads Filter" can contain two additional methods to allow the user to filter remote vehicles according to their needs. The filtering can be restricted in a topological way by restricting the checking only in the three cardinal directions, i.e., checking connecting roads from the left / right / front with respect to the road the reference vehicle is travelling on. Furthermore, a combination of left and right can be added as an option, which is convenient in cases where a specific side is not relevant, as is the case in IMA applications. Some filtering features may overlap with classification features. The filter's interface provides a larger configuration space and may be more convenient to use.

[0155] Furthermore, the movement of each vehicle can be specified as approaching or moving away from the intersection. This feature comes in handy in various situations. When one vehicle needs to move towards the intersection and the other needs to move away from the intersection, this can be considered as extending the road, which is crucial in FCW situations. Another common use case might be that only vehicles that are heading towards the same intersection as the reference vehicle are of interest. An example of this use case is an IMA application where a remote vehicle approaching from either side can be dangerous. Another use case might be a vehicle that is driving in the wrong direction in front of the reference vehicle.

[0156] The map-aware application 90 is preferably a V2X application which can greatly benefit from using a local HD map assembled by the method according to the invention.

[0157] As examples, two applications were chosen to compare cases where the presence of map matching is not only a decisive factor at a conceptual level, but also allows for more sophisticated decisions. The differences can be quantified in terms of false positive and negative cases in cases where the algorithm itself cannot properly evaluate without local road topology information.

[0158] Selected applications are Forward Collision Warning (FCW) and Cross Traffic Assist (IMA), see also Figure 2A and Figure 2B . Both applications first select long-range potentially dangerous vehicles by applying classification and filtering. This step is computationally cheap, especially when multiple applications rely on the same filter. The situation of each candidate vehicle is then preferably evaluated and a notification is sent if the situation is marked as dangerous. In the case of FCW, time to collision (TTC) is a decision parameter, while IMA preferably checks the closest expected distance between the two participating vehicles within a predefined time frame.

[0159] In the absence of map information, one can see that the selection of potentially dangerous vehicles and the situation assessment are performed purely based on Newtonian principles, i.e., without any environmental constraints. This approach obviously fails to take into account road curvature (at least until the curvature is detected by the vehicle sensors, and even at this point the road geometry cannot be correctly extracted) or elevation (GNSS 75 signals are generally of poor quality in terms of elevation information) or non-connected roads, leading to erroneous assessments manifested as false negatives and positives. Therefore, these applications need to be enhanced while maintaining the original principles.

[0160] Map-Aware Forward Collision Warning (MA-FCW):

[0161] In the case of FCW, a map-matching-assisted road / lane filtering may first be applied. This may select a remote vehicle 72 traveling in front of the ego vehicle 50. Since the position of the vehicle on the final link is available in the map-matching results, the distance between the two vehicles may also be calculated more accurately. The principles of the original (non-map-matching) FCW algorithm may then be applied, which (depending on the method applied) may result in a more accurate and reliable TTC value.

[0162] The map matching based FCW can have the "same road filter" already discussed before, which checks for vehicles on the same road segment ahead of the ego vehicle 50 in the same direction. In this way, it can be ensured that the ego vehicle 50 does not lose track of potentially dangerous vehicles in areas where the road intersections are close to each other. The filter can be configured to select vehicles traveling in the same direction ahead of the ego vehicle 50 in a static or dynamic range. Once the filter is triggered to be applied, the same analysis as the original FCW algorithm can be performed on the vehicle pairs. However, in this case, the distance along the road is considered instead of the distance on the sphere. In addition to the enable flag, the two applications can share the same configuration options. For more details on the configuration, please refer to the documentation of the original FCW application.

[0163] The app can analyze remote vehicles if the following requirements are met:

[0164] ●It is traveling along the same road as the ego vehicle 50.

[0165] • It is located in front of the ego vehicle 50 on the road.

[0166] • The ego vehicle 50 and the remote vehicle 72 are traveling in the same direction.

[0167] • The distance between the remote vehicle 72 and the ego vehicle 50 on the road is below a threshold (which may be configured as a static value or a speed-dependent dynamic value).

[0168] Below a configurable threshold speed value, the app can be disabled.

[0169] When the app is enabled, it shall calculate the Time To Collision (TTC) between two vehicles, assuming the following:

[0170] There are no other vehicles between the ego vehicle 50 and the remote vehicle 72 .

[0171] The calculation may or may not take into account the acceleration of both vehicles.

[0172] If acceleration is considered, it is assumed to be constant during the inspection time.

[0173] ●The length of the vehicle should be taken into account throughout the calculation process.

[0174] When the calculated TTC value is less than a threshold (which can be configured as a static value or a speed-dependent dynamic value), the application should trigger a warning.

[0175] Map-Aware Intersection Motion Assist (MA-IMA):

[0176] The IMA application can be enhanced in the above-described manner. The candidate dangerous remote vehicle 72 is traveling on a road that is connected to the ego vehicle 50 within a certain distance. This criterion can be translated into map matching terms, that is, there is a common upcoming node within a relatively close distance to this specific node on the current link. This can be achieved by a "connecting road filter" that is configured to trigger the application when the remote vehicle is traveling on a road with a connection angle of about 90 degrees on either side relative to the road on which the ego vehicle 50 is traveling. In addition, according to the convention in the object database 70, the vehicles should be traveling in opposite directions and the remote vehicle 72 should be in front of the ego vehicle 50. Once such vehicles are found, it can be checked whether there is a risk of collision, that is, they arrive at the connecting node at about the same time, or more precisely, whether they will arrive within a threshold distance on the way. More precisely, assuming that each vehicle continues to drive when checking, it is checked how far the other vehicle is expected to travel when reaching the junction. Preferably, the length of each vehicle is taken into account. If any of the calculated distances is lower than the threshold distance set in the application configuration, a warning is triggered (the estimated TTC value is the average of the two time values ​​at which the vehicle is expected to arrive at the intersection).

[0177] As in the case of the FCW application, both IMA variants share a common configuration space. However, as shown in the above description, the current version of the map matching variant does not take into account the acceleration of the vehicle, so the corresponding configuration parameters have no effect. The remaining configuration parameters can be found in detail in the original IMA documentation.

[0178] The IMA application preferably analyzes the remote vehicle 72 if it meets the following requirements:

[0179] • It is heading towards the same intersection as the ego vehicle 50.

[0180] ●It is approaching the junction / intersection from the left or right (vehicles approaching the intersection from the opposite direction should be ignored as in this case it is assumed that the vehicle is not on the collision path).

[0181] • It is within a threshold distance from a road intersection (which can be configured as a static value or a speed-dependent dynamic value).

[0182] Below a configurable threshold speed value the application should be disabled.

[0183] When the app is enabled, it should calculate the TTC between two vehicles, assuming the following:

[0184] The calculation may or may not take into account the acceleration of both vehicles.

[0185] If acceleration is considered, it is assumed to be constant over the period of time examined.

[0186] ●The length of the vehicle should be taken into account throughout the calculation process.

[0187] When the calculated TTC value is less than a threshold (which can be configured as a static value or a speed-dependent dynamic value), the application should trigger a warning.

[0188] Map-matching driven context-based prioritization (CBP):

[0189] In addition to security applications, insights based on map matching can also be used to create filtering rules for context-based prioritization. CBP is a method of filtering out irrelevant messages at a low level in the network stack, typically in the media access control (MAC) sublayer of the data link layer. MAC sublayer filtering requires a set of MAC addresses to filter. This set of MAC addresses is provided by the upper layer and is continuously updated. The upper layer can create filters to obtain this set of MAC addresses that are irrelevant to them and provide this set to the CBP function in the MAC sublayer. In the simplest implementation, the MAC sublayer does not forward messages with MAC addresses found in the set. This offloads the entire computational entity because only relevant messages reach the upper layer. Traditional methods use filters based on the physical distance of the objects sending and receiving the message. In most cases, this leads to poor results because distance-based methods cannot filter out transmitting stations that are near the receiver (receiving object or entity) but are still in irrelevant locations (e.g., reverse traffic on a highway). On the one hand, in other cases, traditional methods will filter out transmitting stations that are not near the receiver but are still in relevant locations (e.g., curved roads).

[0190] With the help of the present invention, map matching insights can be used to create more accurate filters for CBP.From this perspective, the MAC sublayer CBP function is just a special type of V2X application.

[0191] The map matching module 80 of the system according to the present invention preferably uses an improved map matching algorithm as described below.

[0192] Most known map matching algorithms and research focus on the problem of matching routes to sparsely sampled trajectories. The sampling range is usually between a few seconds and a few minutes. The reason for this is that most algorithms are applied to traffic monitoring, fleet management or surveillance systems involving many vehicles that need to be tracked online or the collected measurements need to be post-processed for various further use cases. Both involve processing large amounts of data, which is computationally demanding.

[0193] Various approaches may lead to similar performance. One paper—Luo An et al.: “Enhanced Map-Matching Algorithm with a HiddenMarkov Model for Mobile Phone Positioning” ISPRS International Journal of Geographic Information 6, No. 11: 327 (2017)—introduces an approach based on a state transition model. The state transition model can construct a weighted topological graph that contains all possible routes that a vehicle may travel. In this weighted topological graph, vertices represent the states that a vehicle may be in at a specific moment, while edges represent transitions between states at different timestamps. Unlike a road network, the weights of graph elements represent the likelihood of a state or transition, and the best matching result comes from the global optimal path in the graph. There are three main approaches to constructing the graph and solving the optimal path problem. Namely, hidden Markov models (HMMs), conditional random fields (CRFs), and weighted graph techniques (WGTs).

[0194] There is a considerable literature on HMM methods, which can achieve very good results. However, in the case of V2X, only online variants should be considered. These methods usually utilize future path prediction to address the need for future data, thus eliminating or reducing the latency that is naturally present in this approach.

[0195] The idea behind constructing the state transition matrix is ​​simple. The weight of each transition depends only on the topological distance between the links. The transition probability decreases as the topological distance increases. The authors of the paper suggest considering neighbors of depth 2 with weights of 0.6, 0.4, and 0.2 (0.6 corresponds to transitioning to the same link). The reason is apparently that it is increasingly unlikely that a vehicle will travel to another link between consecutive measurements.

[0196] Again, the choice of transmit probability is simple. The weight is inversely proportional to the distance between the link and the measurement location.

[0197] Surprisingly, even these rules (not even considering the distance between the end of the link and the possible matching location corresponding to the measurement) can produce decent performance. However, in areas with more complex road networks, slight modifications can be made to improve the accuracy of the algorithm. These are described in detail below:

[0198] We have discovered two major weaknesses in the original algorithm, which have been shown to result in poor performance in areas where the road topology is much more complex than elsewhere. The original algorithm does not take into account directional information in any sense. Another weakness of the original method is that it tends to match the same road segment within a certain distance even if the vehicle has passed the end point. This is partly due to favoring identical links via higher weight values, and due to the definition of distance between points and line segments. The methods used by the map matching module 80 of the system according to the present invention are preferably intended to attenuate the unintended effects of these phenomena.

[0199] A similar approach is used in both cases. A combined "distance" is calculated that combines the geometric distance and the angular difference between the road segment and the direction of vehicle motion in multiplicative form. This combined distance is penalized when the angular difference is large (i.e., above a threshold), and has little effect when the angular difference is below the threshold. Similarly, the geometric distance between a segment and a point is penalized (i.e., a larger distance is attributed to it) if the closest point to the segment is one of the segment's endpoints.

[0200] Sigmoid functions are suitable for this purpose. Sigmoid functions are monotonic functions with inflection points, and they map real numbers into a finite range. Error function, logistic function, and tanh function are some of the commonly used sigmoid functions.

[0201] In the case of angular difference, a weighting function is designed that barely distorts the distance metric when the angular difference is low, but increases it by a considerable amount when the angular difference exceeds a threshold (e.g., 30 degrees). The angular difference weight value may be selected between 1.0 and a predefined maximum value, e.g., 5.0, or alternatively, the angular difference weight value may be selected between 0.2 and a predefined maximum value of 1.0, e.g., Figure 4 As shown, the figure depicts an exemplary weighting function (angle difference shaping) with an inflection point at 30 degrees.

[0202] A similar approach can be used for geometric distances. Figure 5 , which shows an exemplary distance shaping function for a road segment of length 10m, with the main difference being that the weighting function is two-sided, in that the same weighting needs to be applied at both ends of the road segment. This function has a shaping effect because the weight is then multiplied by the distance between the given point and the road segment. The reason this method is slightly different from the one applied to angle differences is that it prefers to use closer links rather than finding a farther link with a better directional match.

[0203] Therefore, the emission probability matrix elements can be calculated as the inverse of the following expression:

[0204] d = f shaping,dist (x proj,l segment )×d p,segment ×f weighting,angle (φ veh ,φ segment )

[0205] in

[0206] x proj and l segment are the coordinates of the projection point on the road section and the length of the road section,

[0207] d p,segment is the distance between the point and the segment,

[0208] Φ veh and Φ segment They are the direction of vehicle movement and the direction of the road section respectively.

[0209] For numerical reasons, an offset is added to d when computing the emission probability matrix elements p,segment , to avoid division by zero.

[0210] A V2X specific improvement to the map matching process may be the selection of coordinates for map matching. Both the ego vehicle 50 and the remote vehicle 72 send coordinates at a relatively high rate, and map matching only needs to select a few coordinates based on the needs of the algorithm, but this still leaves some flexibility in selecting the location update. An improvement is to implement a confidence-aware selection that takes into account the location confidence of the coordinates and selects the location (data point) with the lowest confidence (highest accuracy). The confidence may vary depending on the coverage of the GNSS 75, the number of synchronous satellites, the dynamic movement of the vehicle, and some other aspects, but they all affect the final confidence value added to the location update data structure, so the highest quality point should be selected. Among the selected points, weighting can also be applied based on the confidence of each final selected location point, so a more precise location point selected for map matching can have a higher weight than a less precise coordinate (coordinate with a higher confidence ellipse) that is also selected for a given round of map matching.

[0211] In summary, when making decisions, driver assistance systems rely primarily on the distance to each vehicle. In many cases, this leads to a large number of inaccuracies, since no consideration is given to whether each vehicle can interact with each other. These errors are due on the one hand to the fact that driver assistance systems may present certain situations as much more dangerous than they actually are, and on the other hand to the fact that there are more and more vehicles on the road equipped with increasingly complex driver assistance systems, and therefore more intensive communication, so it can be expected that important information may be lost in the noise of information.

[0212] Solutions to these challenges can be provided by map matching solutions, which can help identify other vehicles in relation to the ego vehicle 50 in the application area. Of course, a prerequisite for this is the availability of high-resolution and reliable maps with sufficient detail for map matching, in particular node matching. An important part of the present invention is that if such a map is not yet available for a given area, it can be generated in real time under the right conditions, paving the way for more advanced and safer driver assistance systems with map matching solutions.

[0213] Furthermore, the invention relates to a computer program product comprising instructions which, when the program is executed by a computer, cause the computer to perform an embodiment of the method according to the invention.

[0214] The computer program product may be executed by one or more computers.

[0215] The invention also relates to a computer-readable medium comprising instructions which, when executed by a computer, cause the computer to perform an embodiment of the method according to the invention.

[0216] The computer readable medium may be single or comprise multiple separate components.

[0217] Of course, the present invention is not limited to the preferred embodiments described in detail above, but other variations, modifications and developments may be performed within the scope of protection determined by the claims. In addition, all embodiments defined by any arbitrary combination of dependent claims belong to the present invention.

[0218] Reference Symbols List

[0219] 10 Path History

[0220] 12 Location Points

[0221] 20 Location Nodes

[0222] 22 Cross Node

[0223] 24 Edge

[0224] 25, 25' Merge position node

[0225] 26, 26' Merge cross nodes

[0226] 28, 28' Merge Edge

[0227] 30, 30' reduction diagram

[0228] 50 Ego Vehicle

[0229] 52 Another object

[0230] 54 Area

[0231] 70 Object Database

[0232] 71 Location Information

[0233] 72 Remote Vehicles

[0234] 73 Self-location data

[0235] 74 Self-positioning subsystem

[0236] 75 GNSS

[0237] 76 RTKS

[0238] 77 DR algorithm

[0239] 78 map providers

[0240] 79 Digital map data

[0241] 80 Map Matching Module

[0242] 81 Object Position

[0243] 82 Object Priority Module

[0244] 83 A group of MAC addresses

[0245] 84 Context-Based Prioritization Module

[0246] 85 A filtered set of objects

[0247] 86 Map matching object data

[0248] 87 auxiliary value

[0249] 88 Map-aware filters

[0250] 89 Filtered object data

[0251] 90 Map-aware applications

Claims

1. A method for assembling a local high-definition map, the method comprising the following steps: - receiving a plurality of path histories (10), wherein each path history (10) comprises a set of location points (12) successively traversed by the entity, - constructing an initial undirected graph including position nodes (20), intersection nodes (22) and edges (24) based on the plurality of path histories (10), wherein - each location node (20) corresponds to one of said location points (12), - each intersection node (22) corresponds to the intersection of two of said path histories (10), and - defining an edge (24) between position nodes (20) corresponding to adjacent position points (12) of one of the path histories (10), and, in the case of an intersection node (22), defining an edge (24) between the intersection node (22) and a position node (20) corresponding to a position point (12) of each of the two path histories (10), The corresponding intersection point is located between said position points (12), and - In the reduction step, a reduced graph (30, 30') is generated by removing redundancy of the received path history (10).

2. The method according to claim 1, wherein: The reducing step comprises a merging step for merging a portion of the redundant path history (10).

3. The method according to claim 2, wherein: The merging step comprises: - provide predefined similarity thresholds, - defining a similarity value of two parts of said path histories (10), and - if the similarity values ​​of the two path histories (10) are within the predefined similarity threshold, Then merge its position node (20).

4. The method according to claim 3, wherein: The similarity value is determined based on the lateral distance between the position points (12) of the two corresponding path histories (10).

5. A method according to any one of the preceding claims, wherein: The reduction step includes an edge removal step for removing false edges corresponding to any lane changes.

6. A method according to any one of the preceding claims, wherein: The reduction step is performed in an iterative manner.

7. A method according to any one of the preceding claims, wherein: The path history (10) is received via a V2X message.

8. A system for providing map-related information for traffic safety applications, the system being adapted to receive - digital map data (79), and - the location of the object, The system comprises: - a map matching module (80) adapted to calculate map matching position information based on the position of said object and said digital map data (79), and - an object database (70) connected to the map matching module (80), wherein the object database (70) is adapted to store the positions of the objects and the map matching information of the objects calculated by the map matching module (80).

9. The system according to claim 8, characterized in that The digital map data (79) are provided by a method according to any one of claims 1 to 7 or by a map provider (78).

10. The system according to claim 8 or 9, characterized in that The location of the object is provided by a remote vehicle (72) and / or by a self-localization subsystem (74) connected to the object database (70) and / or to the map matching module (80).

11. The system according to any one of claims 8 to 10, characterized in that Also included is an object priority module (82) adapted to determine objects for which the map matching module (80) is to perform map matching, wherein the object priority module (82) is connected to the map matching module (80).

12. The system according to any one of claims 8 to 11, characterized in that Also included is a map-aware filter (88) adapted to classify data stored in the object database (70) based on its relevance to an entity hosting the system.

13. The system according to claim 12, characterized in that Classification of objects is performed by a map-aware filter (88) based on the distance of the location of the object from the location of the entity hosting the system.

14. The system according to any one of claims 8 to 13, characterized in that The object database (70) is in communication with a map-aware application (90), wherein the map-aware application (90) is a forward collision warning module, a cross motion assistance module, and / or a context-based priority module.

15. A non-transitory computer program product comprising instructions which, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 7.

16. A non-transitory computer-readable medium comprising instructions which, when executed by a computer, cause the computer to perform the method of any one of claims 1-7.

Images