Systems, methods, computer program products, and computer readable media for sharing and receiving map matching results

Abstract

The invention relates to a system for sharing map matching results, which comprises a map matching module (30), the invention relates to a map matching system (10) comprising:-a map matching module (30) adapted to-receive digital map data (28, 28 ') from a map provider (24),-receive location information,-perform map matching on the received location information using the digital map data (28, 28'), and-generate map-matched location information, and-a map matching result sharing module (34) connected to the map matching module (30), the map matching result sharing module (34) is adapted to-receive map matching location information from the map matching module (30) and-aggregate messages (36, 36 ') comprising the map matching location information as map matching results to be shared. The invention also provides a method of receiving shared map matching location information by a receiving entity (44) and matching the shared map matching location information to a local map. 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 system for sharing map matching results and a method for receiving shared map matching results. 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 can immediately improve 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 (e.g. 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. Background Art

[0006] There are several solutions to solve the map matching problem. Based on the applied map matching algorithm and the digital map, the results of map matching may be different, which may cause compatibility issues when sharing the results of map matching with other entities, such as other vehicles or roadside units (RSUs).

[0007] US2006 / 0224301 discloses a vehicle-to-vehicle communication system that transmits notifications about moving bodies (such as pedestrians or other vehicles) to other drivers who are unable to detect the moving bodies themselves. The vehicles can communicate with each other directly or via vehicle control devices. The system includes a device for detecting the position of the moving body and a device for transmitting the position to other vehicles. The system also has a map matching unit for matching vehicle data with map data stored in a storage unit. Data received from other vehicles can be matched with a local map.

[0008] US2022 / 0084399 A1 discloses a method, system, module and software for intelligent management of multi-way parking intersections. The purpose of the method is to control traffic flow near the intersection. According to the present application, a consensus method is used, which may be based on information such as lane-level position sharing of nearby vehicles. The shared information is then processed in a distributed manner or on a central entity, and the solution is then broadcast to the various participants in the traffic ecosystem, for example, other vehicles. When the method according to the present application is executed in a distributed manner, map matching is performed on all entities arriving at the same intersection, and if a remote entity shares its map matching results, it is only used for cross-checking at the receiving entity. Therefore, the computing power required for each entity is not reduced at all. In addition, the present application focuses on how to reach a consensus on the movement order of entities at the same intersection, and map matching is only an optional additional source of information that can improve the quality of decision-making.

[0009] US2021 / 0039675 A1 discloses a path providing device and a path providing method thereof. In addition, the present application discloses a scheme that can be used for path planning. The present application describes several sub-modules and their interconnections and interactions. According to the present application, traffic participants perform map matching individually and can share the resulting information with each other via V2X messages. In addition, the present application proposes a scheme for managing and processing digital map information provided simultaneously by different map providers, and how to use these maps to describe sub-portions of the proposed path. The results of map matching are shared only between modules within the on-board system, and therefore, such information is neither intended to allow the remote vehicle to better understand the status of a specific vehicle in its surroundings nor to reduce the amount of computation required for it.

[0010] In view of known approaches, there exists a need for a system and method that allows location information to be shared among participants (entities) of a transportation ecosystem in an efficient manner while reducing the computational requirements of the participants. Summary of the invention

[0011] The main object of the present invention is to provide a system for sharing map matching results 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 method for receiving a shared map matching result.

[0013] It is also an object of the present invention to provide a system and method by which map matching results calculated by entities of a transportation ecosystem can be effectively shared and used by different entities.

[0014] 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 method steps on one or more computers.

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

[0016] As is known, map matching is a computationally expensive problem, but it can greatly improve the accuracy of self-localization, as well as the accuracy of locating other entities of the traffic ecosystem. The advantage of performing map matching is that traffic participants are more aware of their surroundings due to better localization, and can thus avoid accidents more effectively.

[0017] It has been recognized that if participants in the transportation ecosystem share their map-matched positioning information instead of their raw positioning data, the overall computational requirements can be greatly reduced compared to a scenario where each participant performs map matching on each received raw position information. The overall gain in terms of computational cost will be proportional to the number of entities that share their map-matched positions within the receiving entity's reception range.

[0018] It is also recognized that due to the existence of different map providers, map matching results of different entities need to be coordinated / merged. A major advantage of the system and method according to the invention is that map matching results calculated based on map data provided by different map providers can also be effectively used. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0020] Figure 1 is a block diagram illustrating a process of sharing a map matching result of an ego vehicle,

[0021] Figure 2is a block diagram illustrating another process of sharing the map matching results of an ego vehicle,

[0022] Figure 3 is a block diagram illustrating a process by which infrastructure elements share map matching results, and

[0023] Figure 4 is a block diagram illustrating a process of receiving map matching information from other entities. DETAILED DESCRIPTION

[0024] The present invention relates to a system that enables traffic participants to share map matching results with other traffic participants, including but not limited to vehicles, vulnerable road users (VRUs) such as cyclists, pedestrians and any part of the traffic infrastructure.

[0025] Figures 1 to 4 A block diagram illustrating an example of a system according to the present invention is shown.

[0026] The system according to the present invention may include the following components or functional blocks.

[0027] Map Provider 24: An entity adapted to provide digital geographic services to its clients. The map provider 24 is preferably accessible via a data communication channel 26, 26', which is a wired or wireless connection, such as a wired or wireless Internet connection. The map provider 24 may be hosted in the cloud or on one or more traditional servers by Multi-Access Edge Computing (MEC). The map provider 24 preferably provides maps to clients once, or the maps may be updated periodically or on demand via the data communication channel 26, 26'.

[0028] Self-positioning subsystem 20: A functional module adapted to calculate the geographic location of the host vehicle (i.e., ego vehicle 10). The self-positioning subsystem 20 combines inputs from various low-level location services, such as GNSS 12 (Global Navigation Satellite System), RTKS 14 (Real-Time Kinematic System), and DR (Dead Reckoning) algorithms 16 to calculate a high-precision position of the ego vehicle 10.

[0029] Map matching module 30: a functional module of the system for performing map matching according to the present invention. Map matching can be performed using any map matching algorithm known in the art.

[0030] Map matching result sharing module 34: a functional module that obtains map matching results and aggregates messages 36, 36' (e.g., map matching result sharing messages). The map matching result sharing messages may include one or more of the following data:

[0031] - an identifier that matches an object, e.g., a station ID for a vehicle,

[0032] - the identifier of the matching map object, e.g. a road segment,

[0033] - the corrected positions of the map-matched traffic participant entities, e.g. the positions of vehicles projected onto the matched road segment, and

[0034] - An identifier of the map provider 24 .

[0035] Preferably, the map matching result sharing message includes all the above data. In some preferred embodiments, the map matching result sharing message may include other data.

[0036] Network stack 38 : a functional module adapted to communicate on one or more network protocols. The network stack 38 preferably provides network services for the map matching result sharing module 34 .

[0037] Receiving entity 44: An entity adapted to receive a map matching result sharing message. As an example, the receiving entity 44 may be the ego vehicle 10, a remote vehicle 46, an infrastructure element 62 (such as an RSU (roadside unit), an MEC server, a cloud server, a traffic control / management center), etc.

[0038] Remote Entity: An entity of the transportation ecosystem that can share its location with other entities of the same ecosystem. A remote entity can be another vehicle, such as a remote vehicle 46 or an RSU, etc.

[0039] Map matching result sharing entity 60: An entity of the traffic ecosystem that shares its map matching algorithm results with other entities of the same ecosystem. The map matching result sharing entity 60 may be a remote entity, such as a remote vehicle 46. The map matching result sharing entity 60 may also be the ego vehicle 10.

[0040] Map matching result verification module 52: a functional module of the receiving entity 44. The map matching result verification module 52 is adapted to process the received map matching result sharing message.

[0041] Map matching object database 18 , 18 ′: a data storage module that can be used by the receiving entity 44 (or ego vehicle 10 ) to store information extracted from the map matching result sharing messages.

[0042] Map merging API 58: A network communication interface and corresponding protocol implementation that can be used by a receiving entity 44 to merge received map matching results (e.g., map matching result sharing messages) that are generated based on data from another map provider other than the receiving entity 44 (e.g., a second map provider 56).

[0043] Figure 1An exemplary system that can be used to share map matching results of an ego vehicle 10 is shown. Figure 1 , the ego vehicle 10 shares its own map matching information with other traffic participants. The advantage of this is that other traffic participants do not have to perform map matching with the ego vehicle 10, but only need to receive and process the shared results, so other traffic participants can reduce their computing requirements.

[0044] The ego vehicle 10 preferably receives digital map data 28 or a digital map data set from a map provider 24. Preferably, there is a data communication channel 26 between the map provider 24 and the ego vehicle 10, wherein the data communication channel 26 has a wired or wireless connection, for example a wired or wireless Internet connection.

[0045] The ego vehicle 10 preferably uses GNSS 12 (Global Navigation Satellite System), RTKS 14 (Real Time Kinematic System), DR (Dead Reckoning) algorithm 16, more preferably an onboard DR algorithm, or any other method or combination of these algorithms to calculate the geographic location of the ego vehicle 10 (ego vehicle location 22). The ego vehicle location 22 and digital map data 28 are provided to a map matching module 30. Preferably, the map matching module 30 receives actual and historical data of the ego vehicle location 22. The map matching module 30 finds the best matching map object (e.g., road segment) and calculates the corrected position of the ego vehicle 10. The corrected position of the ego vehicle 10 is the ego vehicle map matching result 32 sent from the map matching module 30 to the map matching result sharing module 34. The map matching result sharing module 34 preferably collects more additional information and aggregates a message 36, preferably a map matching result sharing message, which may include one or more of the following data:

[0046] - an identifier that matches an object, e.g., a station ID for a vehicle,

[0047] - the identifier of the matching map object, e.g. a road segment,

[0048] - the corrected position of the map-matched traffic participant entity, e.g. the position of the remote vehicle 46 projected onto the matched road segment, and

[0049] - An identifier of the map provider 24 .

[0050] Preferably, the message 36 contains all the above data. In some preferred embodiments, the message 36 may contain other data.

[0051] In accordance with Figure 1In the case of, the identifier of the matching object is the identifier of the ego vehicle 10, for example, the C-ITS station ID. The map matching result sharing module 34 is adapted to request the network stack 38 to send the aggregated message 40. Preferably, the aggregated message 40 can be shared simultaneously on multiple communication channels.

[0052] The map matching results are preferably stored in the map matching object database 18. Preferably, once the map matching module 30 calculates the ego vehicle map matching results 32, the ego vehicle map matching results 32 are communicated to the map matching object database 18.

[0053] The map matching result sharing message can be implemented as an extension of an existing standardized V2X message, such as a cooperative awareness message (CAM) or a basic safety message (BSM), a collective awareness message (CPM), or as a new standard message type or a proprietary message. The ego vehicle 10 can preferably send the map matching result sharing message in multiple message formats at the same time, for example, via multiple communication channels.

[0054] according to Figure 1 The process is preferably repeated. For example, each time the ego vehicle position 22 is updated, or the digital map data 28 changes, the process according to Figure 1 process and compute new map matching metadata and share a new message including the new map matching information.

[0055] Alternatively, according to Figure 1 The repetition of the process may be determined, for example, based on the speed of the ego vehicle 10. At lower speeds, a lower messaging frequency may be used to share the messages 40, and at higher speeds or at high acceleration / deceleration of the ego vehicle 10, a higher messaging frequency may be used. This allows for more frequent updates when the position of the ego vehicle 10 may change more quickly, or when dangerous situations are anticipated (i.e., when there is heavy braking or high deceleration).

[0056] Figure 2 A system is shown where a remote vehicle 46 shares its map matching results with the ego vehicle 10 .

[0057] Combined with Figure 1 Similar to the process described, any traffic participant can perform map matching on other traffic participants instead of on their own position. This enables map matching for remote vehicles 46 that do not perform ego vehicle map matching and therefore cannot share such information about themselves.

[0058] according to Figure 2, the ego vehicle 10 preferably receives a remote vehicle position 50 from a remote vehicle 46. The remote vehicle 46 is preferably connected to the ego vehicle 10 via a data communication channel 48, more preferably via a wireless data communication channel, to communicate information about the remote vehicle 46 to the ego vehicle 10.

[0059] The remote vehicle position 50 is preferably fed into the map matching module 30 of the ego vehicle 10 together with the digital map data 28 received from the map provider 24. The map matching module 30 may preferably consult the map matching object database 18 of the ego vehicle 10 via a bidirectional connection between the map matching module 20 and the map matching object database 18 to check if there is a map matching context already available for the remote vehicle 46.

[0060] If map matching data corresponding to the remote vehicle 46 is already contained in the map matching object database 18 , the map matching data corresponding to the remote vehicle 46 may use that stored data.

[0061] If map matching has not been previously performed on the remote vehicle 46, or the previous map matching information about the remote vehicle 46 is outdated, the map matching module 30 performs map matching of the remote vehicle 46, and the results of the map matching are preferably stored in the map matching object database 18, or the corresponding data may be updated with the newly performed map matching.

[0062] and Figure 1 Similarly, the output of the map matching module 30, i.e., the map matching result 32, can be stored in the map matching object database 18 or forwarded to the map matching result sharing module 34. The map matching result sharing module 34 creates a message 36 or an aggregated message that is forwarded to the network stack 38. The network stack 38 transmits the message 40 containing the map matching information about the remote vehicle 46 and / or the ego vehicle 10 to the receiving entity 44, wherein the receiving entity 44 can be the remote vehicle 46, other vehicles, RSUs, or any other participants of the transportation ecosystem. The network stack 38 preferably communicates the message 40 via a data communication channel 42', wherein the data communication channel 42' is preferably a wireless communication channel. The network stack 38 is preferably adapted to communicate via different predetermined data communication channels 42' simultaneously.

[0063] Figure 3 An embodiment of the system according to the invention is shown, wherein the computing entity is an infrastructure element 62, such as an RSU or a map matching service running on a MEC (Mobile Edge Computing) or a cloud server.

[0064] The infrastructure element 62 is preferably a static entity that does not move; therefore, it is not necessary to perform map matching on itself, but the infrastructure element 62 can perform map matching on the remote vehicle 46, similar to Figure 2 Example shown.

[0065] according to Figure 3 , the infrastructure element 62 is preferably adapted to receive the remote vehicle position 50 from the remote vehicle 46. The remote vehicle 46 preferably transmits the remote vehicle position 50 to the infrastructure element 62 via the data communication channel 48, preferably a wireless communication channel.

[0066] and Figure 2 Similarly, the infrastructure element 62 has a map matching module 30 that receives the remote vehicle position 50 from the remote vehicle 46. The map matching module 30 of the infrastructure element 62 also preferably receives digital map data 28 from the map provider 24 via the data communication channel 26', which is preferably a wireless communication channel.

[0067] The infrastructure element 62 preferably also includes a map matching object database 18, which is preferably similar to Figure 2 The map matching object database 18 and the map matching module 30 are preferably in a bidirectional connection, which allows the map matching module 30 to use data from the map matching object database 18, and the map matching data (e.g., map matching results 32') from the map matching module 30 can be stored in the map matching object database 18.

[0068] In addition to storing the map matching results 32 in the map matching object database 18, the map matching results may also be forwarded to a map matching results sharing module 34. The map matching results sharing module 34 creates a message 36 or an aggregated message that is forwarded to a network stack 38. The network stack 38 transmits a message 40 containing map matching information about a remote vehicle 46 and / or the ego vehicle 10 to a receiving entity 44, wherein the receiving entity 44 may be a remote vehicle 46, another vehicle, an RSU, or any other participant of the traffic ecosystem. The network stack 38 preferably communicates the message 40 via a data communication channel 42', wherein the data communication channel 42' is preferably a wireless communication channel.

[0069] The network stack 38 is preferably adapted to communicate simultaneously via different predetermined data communication channels 42'.

[0070] When the receiving entity 44 receives the map matching information from the map matching result sharing entity 60, preferably in the form of a message 40', it needs to process the received information. Figure 4A preferred arrangement is shown for validating and merging map matching results received from a map matching results sharing entity 60. The map matching results sharing entity 60 is preferably a remote vehicle 46.

[0071] The receiving entity 44 preferably first checks whether the map provider 24 of the map matching result sharing entity 60 is the same as its own map provider 24. The receiving entity 44 preferably has a map matching result verification module 52 to compare the map provider 24 of the receiving entity 44 with the map provider 24 of the map matching result sharing entity 60. Figure 4 In the illustrated example, the map provider 24 of the receiving entity 44 is a first map provider 54 , and the map provider 24 of the map matching result sharing entity is a second map provider 56 .

[0072] In case the first map provider 54 and the second map provider 56 are the same, the receiving entity 44 may directly use the received map matching result, for example, the received map matching result may be saved and stored in the map matching object database 18' for further use. The map matching object database 18' preferably checks whether there is an existing entry for the map matching result sharing entity 60 and / or the map matching object about which the map matching result sharing entity 60 is sending information. In case of an existing entry, the data related to the existing entity is updated, otherwise a new entry is created in the map matching object database 18' for the map matching result sharing entity 60 and / or the map matching object.

[0073] In case the first map provider 54 and the second map provider 56 are not the same, the receiving entity 44 needs to merge the received information, i.e. the received information provided in the context of the second map provider 56 is to be interpreted in the context of the first map provider 54. The merging is preferably performed by a map merging API 58. The merging process will be described later.

[0074] Merging means converting the received map object identifier into a digital map representation of the map provider 24 used by the receiving entity 44. The map matching result validation module 52 consults its map provider 24 (first map provider 54) through the map merging API 58 and requests the conversion of the received remote map data source identifier. Alternatively, the receiving entity 44 can perform the merging using its own resources with the help of auxiliary information shared by the map matching result sharing entity 60.

[0075] Map matching result reception may be managed by a classification and prioritization module (not shown) that indicates which objects must be map matched on the vehicle and from which objects to accept map matching results.

[0076] Typically, different map providers 24 provide different digital maps to their users, which can make it difficult to evaluate location data generated or map-matched using different digital maps. The most common differences between two digital maps may be any of the following:

[0077] - Differences in the level of detail. For example, standard definition (SD) maps typically contain only vague information about lanes within a road, or no information about lanes at all, while high definition (HD) maps typically include information about the exact boundaries of each lane.

[0078] - Topological differences. For example:

[0079] - In some cases, some (usually lower-level) roads were completely missing from one map, while another, more detailed map included them.

[0080] - There are no universal rules for how to divide roads into shorter sections (also known as links).

[0081] A road may be divided on one map based on speed limit changes or properties around specific traffic signs, while another map may have a maximum number of intermediate points between two endpoints, etc.

[0082] - In some locations on digital maps, roads may or may not be updated in a timely manner.

[0083] -Some maps may filter out certain roads that are deemed irrelevant to the user.

[0084] - Differences in road geometry. For example, different map providers 24 often use different techniques to collect data about road geometry, which results in differences in the actual geometry of the roads.

[0085] There are technical solutions that can forward the current position and direction of a vehicle (or, in general, an entity) (i.e., the direction in which the vehicle is heading). This information, i.e., the current position and direction, is usually forwarded as part of a CAM or BSM message. However, the information initially included in these messages is not sufficient to identify the road or road segment on which the entity is traveling, and the probability is high. Therefore, it is still necessary to perform map matching on the receiving entity 44 to locate the shared entity (e.g., remote vehicle 46 or remote entity) on its own map. It should be noted that if the sharing entity and the receiving entity do not use the same or compatible maps, then even if the shared entities share map matching position information, it needs to be map matched with the map of the receiving entity 44, which increases the computing requirements of the receiving entity 44.

[0086] The method according to the invention provides a solution for merging maps used by different entities of the traffic ecosystem, thereby reducing the computational burden of the receiving entity 44. The method according to the invention allows identifying the road on which the remote vehicle 46 is travelling.

[0087] The digital maps provided by any map provider 24 typically include nodes and links between nodes. The nodes of the digital map can be intersections, such as junctions, that is, vertices with at least three connecting edges in the road topology map (e.g., T or Y junctions, intersections, roundabouts, etc.). These nodes can be referred to as junction nodes. If a road or road section is missing on the map, the corresponding junction node may also be missing.

[0088] Other nodes may also be defined between the junction nodes, for example, at predetermined intervals between them, or at predefined traffic signs, or where a new lane begins or where a lane ends, etc.

[0089] A link is preferably an edge of a graphical representation of a road structure arranged between nodes. For example, a link may be a road segment between two nodes.

[0090] In connection with the present invention, the "straight line extension" of a link is defined by the following. First, an initial link is selected. A link always has two end nodes that separate the link. Starting from one end node of the initial link, a connecting segment is searched, i.e., a link (connecting link) that has a common end node with the initial link and also points in the same direction as the initial link. The same direction means that the direction difference between the initial link and the connecting link is within a threshold angle (e.g., 20 degrees). When a connecting link is found, other connecting nodes are searched starting from its end node (i.e., the common end node) until no connecting link that meets the connecting link criteria is found, or until a predetermined number of connecting links is reached. Starting from the other end node of the initial link, the process of searching for connecting links is repeated in the opposite direction. Finally, this process produces a set of ordered connecting links.

[0091] The method according to the invention can be applied to any participant involved in traffic or transport (vehicle, bicycle or motorcycle, pedestrian, etc.). Therefore, in this specification, these are referred to as entities.

[0092] Furthermore, in the context of map matching, the terms "ahead" and "behind" are defined as follows. The terms "ahead" and "behind" should be interpreted relative to the movement of the map matching entity. In a digital map, the geometry of a link is described by a series of points between a start node and an end node. However, an entity may move in two (opposite) directions, so the node that the map matching entity is approaching is the "ahead" node, and the other node of the link is the "behind" node.

[0093] Note that an entity may start its journey somewhere between the two end nodes of a link (e.g. because it stopped there for a while, or entered the link (road) from outside the road structure described in the map, e.g. from a road that does not exist in the map). Also, when creating line extensions, the result may contain links that the map-matching entity did not even drive.

[0094] An example of a method according to the invention is described below. A variable of an enumeration type is defined, which collects all known map providers 24 and all their known services; an identifier is defined for each map provider 24 and each of its services, wherein the identifier is preferably a map data source identifier. The map data source identifier can be used as a guide for the receiving entity 44 to determine whether the map of the remote entity is compatible with its own map. Once the map data source identifier of the remote entity (the remote map data source identifier) ​​is received, it is compared with the map data source identifier of the receiving entity 44 (the local map data source identifier). If the remote map data source identifier is compatible with the local map data source identifier, that is, there is a match between the remote map corresponding to the remote map data source identifier and the local map corresponding to the local map data source identifier, the map data or map matching data of the remote entity can be converted to a local map, that is, the map matching result of the remote entity can be directly applied without the receiving entity 44 performing any further steps. In addition to the map data source identifier, the message shared by the remote entity can also include the map matching result of the remote entity (e.g., a link identifier and optionally a lane identifier of the lane in which the remote entity is currently located). If the results are shared in a separate message that already contains the remote entity's location (e.g., in the form of a BSM / CAM), the message may also include the remote entity's current location to allow the receiving entity 44 to use it for lane-level positioning.

[0095] In a preferred embodiment, in addition to the remote map data source identifier, the optional link identifier and the lane identifier, information about the straight extension of the map matching link can also be shared by the remote entity, preferably via a message. The preferred method for extracting the straight extension of the initial map matching link has been described above. Preferably, the position of the front node and the rear node can also be shared via a message. The position data of the front node and the rear node are preferably stored in a local digital map in a customized container, which contains two lists, i.e., a list for the front node position and a second list for the rear node position. The number of nodes in the two lists is preferably limited to a predefined maximum number N and M, respectively, and even more preferably, each list is sorted based on the distance along the road to the map matching entity (e.g., the remote entity). Each list preferably contains nodes in ascending order based on the distance to the map matching entity on the road. Therefore, preferably, the first node in the front node list is the closest node (e.g., the junction node) in the direction of the remote entity, and the first node in the rear node list is the closest node in the opposite direction (e.g., the junction node). According to the remote map, if a minimum number of front nodes and / or rear nodes can be found, the remote entity (i.e., the entity sharing its map matching results) may not be able to fill both lists. Preferably, the remote vehicle 46 stores two lists of front nodes and rear nodes in its memory, especially when both lists are fully filled.

[0096] As an illustrative example, a set of changes that can be applied to the current European (ETSI EN 302637-2 V1.4.1) and American (SAE J2735-2007) standard message containers for map matching results sharing are shown in Listings 1 to 3. The following pseudo-code is intended to introduce a possible way to integrate map matching results into already existing message types. Data elements are grouped into various containers that build standard messages. Additional elements compared to the standard message are marked in italics. The message structure is shown up to the level where the map matching result container is added to the already existing container of the standard message.

[0097] The data type of a field is often a design parameter, and is usually chosen to be the smallest size that can accommodate the extreme values ​​of a given field, in order to strike a balance between performance and message size. Sometimes fields are dynamically resized based on the current contents. Therefore, the following list only contains rough / generic type names that are intended to reflect the underlying type of the corresponding field.

[0098] According to the example shown below (Listing 1-3), the MapMatchingResult container has a field that identifies the map data source (mapDataSourceId) used by the remote entity for map matching. The results of the map matching, preferably including the matching link (identifier of the matching link), are also included in the MapMatchingResult container. The matching link is preferably interpreted together with the mapDataSourceId.

[0099] In addition, the front node and the back node can be stored in the fields nodesAhead and nodesBehind, respectively, preferably in a class array container (or in a list), wherein the size of the class array container can vary and / or the class array container has a maximum capacity. The elements stored in the class array container are preferably used to store the positions corresponding to the front node and the back node. These fields can be implemented by any other known solution in the art, for example, by a data list.

[0100] It is worth noting that the Collaborative Awareness Message (CAM) (commonly used in the EU) and the Basic Safety Message (BSM) (commonly used in the United States and China) already contain absolute positions (the locations of shared entities). Therefore, it is best to store the map-matched location data in different data fields, for example, as offset values. This also helps to make the messages (CAM and / or BSM) as concise as possible. In a preferred embodiment, each element of the node list can be interpreted relative to a reference position value (i.e., the absolute position contained in the corresponding message). The reference position can also be used as a reference for the position information of the front node and the rear node. The position information of consecutive elements of the list of front nodes and rear nodes can also be interpreted relative to the previous position in the corresponding list. As an example, the field MapNodeDeltaPosition MapNodeDeltaPositionList follows this convention.

[0101] Listing 2 and Listing 3 show which container a map matching result may fit into in an implementation. For CAM messages, the MapMatchingResultContainer may be arranged into a CamParameters container, as shown in Listing 2. For BSM messages, fields with similar types may be placed in the SupplementalVehicleExtensions that are part of the BSM message (see Listing 2). For compatibility reasons, it is best to place the last field specified by the standard and a custom element that can host any custom content not constrained by the standard (e.g., a custom element represented by a " <customfields>" indicates that the new element and the new container are placed between them. Listing 1. Example of the structure of the map matching result container.

[0102]

[0103] Listing 2. Example of entering map match data fields into a CAM message.

[0104]

[0105] Listing 3. Example of entering map match data fields into a BSM message.

[0106]

[0107]

[0108] The preferred embodiments of the method according to the present invention are described in detail below. Figure 4 As shown, receiving entity 44 receives a message containing information about the location of a remote entity. Preferably, at receiving entity 44, the algorithm applied to map-match the shared container contents is less expensive than performing map-matching on either remote entity 46 or receiving entity 44.

[0109] The message received by the receiving entity 44 is preferably a CAM or BSM message. The message preferably contains a remote map data source identifier and a link identifier corresponding to a remote digital map used by the remote entity. The message is received by the receiving entity 44, which preferably has a local map data source identifier corresponding to a local digital map used by the receiving entity 44.

[0110] After receiving the message, the receiving entity 44 compares the remote map data source identifier with the local map data source identifier. If the remote map data source identifier is compatible with the local map data source identifier, a link identifier corresponding to the map matching result shared by the remote entity is returned. The compatibility between the remote map data source identifier and the local map data source identifier means that the receiving entity 44 can directly interpret and use the received location data. In this case, further method steps can be skipped.

[0111] If the remote map data source identifier is incompatible with the local map data source identifier, the receiving entity 44 defines a node distance threshold. If the distance between a node in the remote digital map and a node in the local map is less than the node distance threshold, the node in the remote digital map and the node in the local map are preferably considered to be equivalent. In addition, a link distance threshold is defined. If a point is below the link distance threshold from a dotted line defined by consecutively connected links, the point is considered to be located on a link in the local digital map.

[0112] In a further step, a set of candidate links is compiled by selecting links near the remote entity's location using the location information in the received message. If bounding boxes around the links are stored in a local digital map, using the bounding boxes can speed up the compilation of the set of candidate links.

[0113] In a further step, the distance between the remote entity and the set of candidate links is calculated, and preferably, the set of candidate links is arranged in ascending order. Preferably, links whose distance to the remote vehicle is greater than or equal to a link distance threshold are eliminated from the set of candidate links, and only links whose remote entity is closer than the link distance threshold are retained in the set of candidate links.

[0114] In a further step, an iteration is performed through the set of candidate links and it is checked whether the two endpoints of the current candidate link have equivalents in the lists of preceding nodes and succeeding nodes in the map matching container of the received message. If a matching link is found, the subsequent steps are skipped and the current link is returned as a matching result.

[0115] In a further step, an iteration is performed through the set of candidate links and the following sub-steps are performed:

[0116] Based on the direction of motion of the remote vehicle 46, the endpoints of the current candidate link are classified as either a front local node or a rear local node.

[0117] - Generate a straight-line extension of the current candidate link according to the directionality defined in the previous sub-step.

[0118] - Iterate through the nodes of the linear expansion set and check whether any of the preceding local nodes and any of the following local nodes have an equivalent in the list of preceding nodes and following nodes in the map matching container of the received message, respectively. If a matching link is found, the following steps are skipped and the current candidate link is returned as the matching result.

[0119] - (Optional) Run an iteration through the nodes in the map matching container of the received message and check if any element in the list of preceding nodes and following nodes is within a link distance threshold of a link in a straight line extension of the current candidate link. If a match is found, return the current candidate link as the matching result. This optional sub-step is preferably performed only if the default map matching algorithm used in the general case requires much more effort than performing this sub-step.

[0120] If none of the previous steps returns a matching result, it means that no correspondence is found between the local digital map and the remote map matching result. Therefore, the remote entity needs to perform map matching with the local digital map through any map matching algorithm available at the receiving entity 44.

[0121] A second exemplary embodiment of the method according to the present invention is described below. The following method has a higher success rate in matching received position information within a local digital map.

[0122] Furthermore, the main difference between the two is that the second exemplary embodiment does not return the first matching candidate link as a result, but selects the candidate link that is "most similar" to the shared data. Similarity is measured by a cost function; the implementation of the cost function may be application specific.

[0123] According to this example, a receiving entity 44 receives a message containing information about the location of a remote entity. The message received by the receiving entity 44 is preferably a CAM or BSM message. The message preferably contains a remote map data source identifier and a link identifier corresponding to a remote digital map used by the remote entity. The message is received by the receiving entity 44, which preferably has a local map data source identifier corresponding to a local digital map used by the receiving entity 44.

[0124] The method comprises the following steps.

[0125] 1. Compare the map data source identifier with the local map data source identifier. If the remote map data source identifier is compatible with the local map data source identifier, return a link identifier corresponding to the map matching result shared by the remote entity. The compatibility between the remote map data source identifier and the local map data source identifier means that the receiving entity 44 can directly interpret and use the received location data. In this case, further method steps can be skipped.

[0126] 2. If the remote map data source identifier is incompatible with the local map data source identifier, a node distance threshold is defined. If the distance between a node in the remote digital map and a node in the local map is less than the threshold, the two are considered equivalent. In addition, a link distance threshold is defined.

[0127] A point is considered to be located on a link in the local digital map if the distance from the imaginary line defined by the consecutively connected links is below a link distance threshold.

[0128] 3. Compile a set of candidate links by selecting links near the remote entity's location using the location information in the message. If bounding boxes around the links are stored in a local digital map, using bounding boxes can speed up the compilation of the set of candidate links.

[0129] 4. Calculate the distance between the remote entity and each element in the set of candidate links. Preferably, links whose distance to the remote vehicle 46 is greater than or equal to the link distance threshold are eliminated from the set of candidate links, and only links whose remote entity is closer than the link distance threshold are retained in the set of candidate links.

[0130] 5. Create an initially empty list to contain the subset of candidate links, where the list will be populated based on the order according to the cost function defined in step 6.2.

[0131] 6. Iterate through the set of candidate links and perform the following substeps in each iteration.

[0132] 6.1 Check whether the endpoints of the current candidate link have equivalents in the lists of preceding and succeeding nodes in the map matching container of the received message.

[0133] 6.2 If at least one equivalent node is found (there may be several equivalent nodes in the local digital map), a cost value is calculated, where the cost value is a function of the distance of the nearest equivalent node of the first node behind and the distance of the nearest equivalent node of the first node in front, and the distance between the remote entity and the candidate link. (As an example, the cost function can be the sum of the three distances.)

[0134] 6.3 If no equivalent node is found for either the first node behind or the first node ahead in step 6.2, the iteration continues with the next candidate link. Otherwise, the current candidate link and its corresponding cost value are added to a list sorted by cost value.

[0135] 7. If the list defined in step 5 is not empty, return the candidate link with the lowest cost as the matching result and skip further steps.

[0136] Alternatively, steps 5 to 7 may be implemented as follows:

[0137] 5'. Create an initially empty list to contain the subset of candidate links, where the list will be populated based on the order according to the cost function defined in step 6.2.

[0138] 6'. Iterate through the set of candidate links again and perform the following sub-steps.

[0139] 6'.1 Based on the direction of movement of the remote vehicle 46, the endpoints of the current candidate link are classified as the front local node and / or the rear local node.

[0140] 6'.2 Generate a straight line extension of the current candidate link according to the directionality defined in the previous step.

[0141] 6'.3 Extract nodes that extend across the straight line obtained in the previous substep and keep only nodes that have more than two connecting links or exactly one connecting link. The first condition describes nodes where roads join (joint nodes), while the second condition corresponds to nodes that have no more road connections (in the map segment currently stored in the memory).

[0142] 6'.4 In the ordered list of nodes obtained in the previous substep, find the nearest equivalent node in the rear node and the front node, and use the distance between the nearest equivalent node in the rear node pair and the nearest equivalent node in the front node pair and the distance between the remote entity and the current candidate link to evaluate the same cost function as in step 6.2. (It should be noted that the number of node pairs to be checked in this step is greater than the number in step 5.)

[0143] 6'.5 (Optional) Iterate through the nodes within the map match container of the received message and check if any element in the list of preceding nodes and following nodes is within the link distance threshold of a link in the straight extension of the current candidate link. If a match is found, evaluate the same cost function as in step 6.2, but use the lowest distance between the preceding node, following node, and link in the straight extension instead of the equivalent node distance.

[0144] 6'.6 If no equivalent node is found in either the back node or the front node in step 6'.4, or no close link to the link is found in step 6'.5 (optional), the iteration continues with the next candidate link. Otherwise, the current candidate link and its corresponding cost value are added to the list sorted by cost value.

[0145] 7'. If the list defined in step 5' is not empty, return the candidate link with the lowest cost as the matching result and skip further steps.

[0146] 8'. If this step is reached, it means that no correspondence is found between the local digital map and the map matching result of the remote entity. The remote entity is map matched with the local digital map by any map matching algorithm available at the receiving entity 44.

[0147] 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.

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

[0149] 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.

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

[0151] 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.

[0152] Reference designator list

[0153] 10 Ego Vehicle

[0154] 12 GNSS

[0155] 14 RTKS

[0156] 16 DR algorithm

[0157] 18.18' Map Matching Object Database

[0158] 20 Self-positioning subsystem

[0159] 22 Ego vehicle position

[0160] 24 Map Providers

[0161] 26. 26' Data communication channel

[0162] 28. 28' Digital map data

[0163] 30 map matching module

[0164] 32, 32' map matching results

[0165] 34 Map matching result sharing module

[0166] 36, 36' News

[0167] 38 Network Stack

[0168] 40, 40' message

[0169] 42, 42'Data communication channel

[0170] 44 Receiving Entity

[0171] 46 Remote Vehicles

[0172] 48 data communication channels

[0173] 50 Remote Vehicle Position

[0174] 52 Map matching result verification module

[0175] 54 No.1 map provider

[0176] 56 Secondary map provider

[0177] 58 Map Merge API

[0178] 60 Map matching result shared entity

[0179] 62 Infrastructure Elements< / customfields>

Claims

1. A system for sharing map matching results, comprising: - A map matching module (30) adapted to - receiving digital map data (28, 28') from a map provider (24), - receive location information, - performing map matching on the received position information using said digital map data (28, 28'), and - Generate map matching location information, and - a map matching result sharing module (34), which is connected to the map matching module (30), wherein: The map matching result sharing module (34) is suitable for - receiving the map matching position information from the map matching module (30), and - Aggregating messages (36, 36') including said map-matched position information as map-matched results to be shared.

2. The system according to claim 1 further comprises a self-positioning subsystem (20) connected to the map matching module (30) for providing the position information of the self-vehicle (10) to the map matching module (30).

3. The system according to claim 2, wherein: The self-positioning subsystem (20) is connected to the GNSS (12) and / or the RTKS (14).

4. A system according to claim 2 or claim 3, wherein: The self-localization subsystem (20) is adapted to receive input from a DR algorithm (16).

5. A system according to any one of the preceding claims, wherein: The map matching module (30) is adapted to receive the position information from a remote vehicle (46).

6. The system according to any of the preceding claims, further comprising a map matching object database (18, 18') adapted to store map matching position information, wherein The map matching object database (18, 18') is connected to the map matching module (30).

7. The system according to claim 6, wherein: The map matching object database (18, 18') is bidirectionally connected to the map matching module (30).

8. The system according to claim 6 or claim 7 further comprises a map matching verification module (52) adapted to receive map matching position information from a remote vehicle (46) and verify the compatibility of the received map matching position information, and the map matching verification module (52) is connected to the map matching object database (18, 18').

9. The system according to any one of the preceding claims, further comprising a network stack (38) connected to the map matching result sharing module (34) for receiving a message (36, 36') comprising the map matching position information, wherein: The network stack (38) is adapted to share messages (40, 40') with one or more receiving entities (44), wherein the messages (40, 40') are aggregated by the network stack (38) based on messages (36, 36') including the map-matched location information.

10. The system according to claim 9, wherein: The network stack (38) is adapted to communicate over one or more network protocols.

11. A system according to claim 9 or claim 10, wherein: The network stack (38) is adapted to communicate with a plurality of receiving entities (44) simultaneously.

12. A system according to any one of the preceding claims, wherein: The messages (36, 36') aggregated by the map matching result sharing module (34) are CAM messages or BSM messages.

13. A method for receiving shared map matching location information by a receiving entity (44) and matching the shared map matching location information with a local map having a local map data source identifier, wherein: The local map includes links and nodes, wherein the map matching position information is received in the form of a message (40, 40'), the message including - the map data source identifier, and - a link identifier corresponding to the map-matched location information, The method comprises the following steps: - comparing the map data source identifier with the local map data source identifier by a map matching result verification module (52), - if the map data source identifier and the local map data source identifier are compatible, returning the link identifier as a match to the received map matching location information, and - if the map data source identifier and the local map data source identifier are incompatible, - defining the link distance threshold in the definition step, - compiling a set of candidate links by selecting links within said link distance threshold from locations corresponding to said map-matched location information, and - in an iterative step, iterating through each element of the set of candidate links to find a candidate link as a match for the received map-matching position information.

14. The method according to claim 13, characterized in that The comparison of the map data source identifier with the local map data source identifier is performed based on a predetermined compatibility table.

15. The method according to claim 13 or claim 14, characterized in that If no match is found for the received map matching location information, map matching is performed on a local map of the received map matching location information.

16. The method according to any one of claims 13 to 15, characterized in that If the message (40, 40') comprises one or more containers containing a preceding node list and / or a following node list, the following steps are performed in the iterative step: - classifying an endpoint of a current candidate link as a front local node and / or a rear local node, wherein the current candidate link is an element of the set of candidate links, - generating a straight-line extension of the current candidate link, - Iterate through each node of the straight line extension and check whether any of the front local nodes and any of the rear local nodes have an equivalent in the front node list and the rear node list, and if an equivalent is found, return the current candidate link as a match to the received map matching position information.

17. The method according to claim 16, characterized in that - defining a node distance threshold in said defining step, and - In said iterative steps, - calculating the distance between the front local node and the element of the front node list and the distance between the rear local node and the element of the rear node list, and -If the distance between the front local node and the element of the front node list and / or the distance between the rear local node and the element of the rear node list is within the node distance threshold, then any one of the front local nodes and any one of the rear local nodes is considered to be equivalent to the elements of the front node list and / or the rear node list.

18. The method according to claim 17, characterized in that If an equivalent of a node is found, - define the cost function, and - calculating a cost value, wherein the cost value is a function of the distance of the nearest equivalent node of the first node behind and the distance of the nearest equivalent node of the first node in front and the distance between the remote entity and the current candidate link.

19. The method according to claim 18, characterized in that The cost function is the sum of the distance of the nearest equivalent node of the rear first node, the distance of the nearest equivalent node of the front first node, and the distance between the remote entity and the current candidate link.

20. 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 13 to 19.

21. 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 13-19.

Images