CN117980695A

CN117980695A - Processing digital map data

Info

Publication number: CN117980695A
Application number: CN202380013712.4A
Authority: CN
Inventors: M·J·范许尔斯特; 孙蕊; S·萨勒; K·范博塞尔; N·热贝尔
Original assignee: TomTom Traffic BV
Current assignee: TomTom Navigation BV
Priority date: 2022-02-18
Filing date: 2023-02-07
Publication date: 2024-05-03
Also published as: WO2023156258A1; GB202202231D0

Abstract

A method for generating a subset of an electronic map describing a network of roads in an area is described. The generation process reduces the number of road segments and the number of attributes associated with those road segments. The map data subset generation enables bandwidth and request rate to be optimized to provide relevant information to a client application (102) that processes the map data subset.

Description

Processing digital map data

Background

The present invention relates to a method, apparatus and software for processing digital map data.

It is known to generate, maintain and distribute digital map information for use in navigation systems, advanced driving applications and autopilot applications. For road vehicles, digital map data may describe a network of roads in an area (e.g., country) that is represented as a plot that includes arcs (i.e., edges) representing road segments and vertices (i.e., nodes) representing connections, such as intersections, exits, and endpoints. Each arc and node in the map may be associated with one or more attributes that describe characteristics of a road segment or connection point. The characteristics may be abstract or physical, such as average travel speed, legal speed limits, travel direction, length of road segments, average turn time of intersections, shape of road segments, or number of lanes. These attributes may be used by various applications operating based on map data.

One exemplary system that may utilize digital map data is Intelligent Speed Assistance (ISA) in a motor vehicle. The european union safety regulations 2019/2144 in clause 6 specify that ISA must be contained in motor vehicles (cars, motorcycles, trucks) since 2022. The regulations state that ISA systems in vehicles may operate on speed limit information that they obtain by observing road signs and signals, or from road infrastructure signals or from electronic map data. In addition, the regulations state that ISA systems should avoid or minimize error rates under real-time driving conditions.

The process of obtaining legal speed attributes from digital map data is implemented in existing navigation systems, such as in-vehicle satellite navigation devices and smart phone applications, for map-matched locations of vehicles, i.e., locations expressed in terms of digital map elements. However, transmitting this quorum attribute data to the client device is typically data intensive.

Thus, it is desirable to have the transmission of digital map data (e.g., speed limitation information) efficiently utilize communication resources, especially when such communication resources are provided via a communication network in a mobile telecommunication infrastructure or an inter-vehicle communication infrastructure or an automobile where bandwidth may be limited and/or costly.

WO 2014/068094 A1 by general international limited (TomTom International b.v.) discloses the use of the current location of a vehicle and digital map data to determine a "horizon" containing a set of road segments corresponding to paths within a predetermined distance or radius in front of the vehicle that the vehicle may traverse in the near future. For paths contained in the horizon, attribute data (e.g., speed limits associated with road segments) may be transmitted to advanced driver assistance systems via an internal vehicle bus.

Using this horizon may reduce the amount of digital map data to be transmitted. However, embodiments of the present invention aim to provide further efficiency.

Disclosure of Invention

A method for sending map-related data to a client device, wherein the map-related data is extracted from digital map data representing a network of navigable path segments within a geographic area, the method comprising:

receiving probability data for a subject vehicle at a location, wherein, for each of a plurality of the path segments of the digital map data, the probability data represents a respective probability that the subject vehicle traversed the respective path segment;

determining a set of one or more paths, each path comprising one or more of the plurality of path segments and having a respective determined extension, wherein the determined extension of at least one of the paths depends at least in part on the received probability data;

Extracting data associated with the determined set of one or more paths from the digital map data according to the respective determined one or more path extensions; and

The extracted data is sent to the client device.

From a second aspect, the present invention provides a computer processing system for sending map-related data to a client device, wherein the map-related data is extracted from digital map data representing a network of navigable path segments within a geographic area, and wherein the computer processing system is configured to:

The extracted data is sent to the client device.

From a third aspect, the present invention provides computer software comprising instructions that when executed on a computer processing system cause the computer processing system to send map-related data to a client device, wherein the map-related data is extracted from digital map data representing a network of navigable path segments within a geographic area by:

The extracted data is sent to the client device.

Thus, it will be seen that the extent (i.e., length) of at least one of the paths in the set whose data is extracted (which may define a virtual "horizon" for the vehicle) varies depending on the likelihood that the vehicle traverses various path segments, according to embodiments of the invention. Thus, the size of the extracted data may vary in response to the relative likelihood that each path is traversed. This approach may increase the expected time that the vehicle will remain within the defined horizon without increasing the amount of map data to be transmitted, stored, and/or processed. This may allow the embodiments to utilize communication bandwidth particularly efficiently when sending the extracted data (e.g., when transmitting the extracted data from a remote server to a client device carried by or as part of a subject vehicle via a telecommunications network).

In contrast to the horizon defined as having a fixed distance or radius in WO 2014/068094 A1, the extension (i.e. distance) of at least one path in the embodiments disclosed herein may vary depending not only on the layout of the map but also on the probability of the vehicle traversing the path segments constituting the path or paths.

Any or all of the receiving, determining, extracting, and sending steps may be performed by a server that may be remote from the client apparatus and/or the subject vehicle.

Each path may include a continuous sequence of path segments. Each path segment may be a straight line or a multi-segment line. Some or all of the paths may partially overlap, i.e., one or more common path segments may be shared. The probabilities of path segments that lead away from a common node (e.g., from an intersection) may add up to 1, although this is not necessarily the case for all nodes, for example, because some path segments may not be selected to be included in the set of paths.

In some embodiments or in some cases, the system may determine the extent of only a single path depending on the probability data, and may extract map-related data from the extent of such a single path. However, in other embodiments and other cases, the set of paths may include multiple paths, and the extracted data may be determined based on an extension of the multiple paths.

The method may include determining which paths are to be included in the set of paths. This may be determined at least in part on the received probability data. Which may be determined at least in part depending on the location of the vehicle. The set of paths may be generated constructively (e.g., by gradually adding path paths to the set), or they may be determined by screening a larger set of possible paths. Sometimes, a path may be determined to have a null (e.g., zero) extension; this may be equivalent to the path being excluded from the set of one or more paths. The extracted data may contain only digital map data associated with a path of the set of one or more paths.

The location of the vehicle is preferably located in a geographic area covered by digital map data. The position of the vehicle may be determined from probe data (e.g., GNSS data) generated by, for example, a position sensing system in or of the subject vehicle. The geographic location of the subject vehicle may be matched to the location of the vehicle in the network of navigable path segments, for example, using probe data including one or more GNSS locations and/or heading. This map matching may be done by a client device on the vehicle, but is preferably done by a server.

In some embodiments, the received probability data may directly represent the path segment probabilities (e.g., as encoded values). However, in other embodiments, the received probability data indirectly represents the path segment probabilities, such as by including data upon which the probabilities may be calculated. For example, in some embodiments, the probability data may include turn probabilities at the junctions between the path segments. These turn probabilities may optionally be target vehicle specific. Some embodiments include processing the received probability data to calculate a respective probability (i.e., likelihood) for the subject vehicle to traverse each of the path segments of the paths in the set of one or more paths. This process may take into account how the subject vehicle arrives at the location. In some embodiments, the determined probability of a subject vehicle traversing a particular path segment may depend on the sequence of path segments traversed by the subject vehicle to reach the path segment (i.e., to reach a connection at the start of the path segment). This sequence may be at least partially hypothetical (e.g., related to future travel of the subject vehicle). The turn probability may be associated with a road feature such as a circular intersection, an intersection, or a junction. Which may be received as part of the received probability data.

Some embodiments include processing the received probability data to calculate respective probabilities that a subject vehicle traversed a path of the set of one or more paths (i.e., up to a determined extension of the path).

The set of paths may include a Most Probable Path (MPP), which is the path of each possible path subject to one or more constraints (e.g., subject to a maximum extension) whose road segments have the highest cumulative probability. The set of paths may include a primary path and zero, one, or more alternative paths. Each alternative path may branch from the primary path at the current vehicle location or at a connection point further along the primary path.

In some embodiments, the extension of at least one path (e.g., the most probable path in the set of paths) and optionally all paths in the set of paths may be determined based at least in part on a minimum path probability threshold. The minimum path probability threshold may be predetermined, e.g., fixed. The same threshold may be used to determine the extent of each of the set of paths. The extension may be determined such that a probability of a vehicle traversing a path (i.e., remaining on the path) within the determined extension is close to the minimum path probability threshold. When adding or removing one path segment will cause the probability of the generated path to cross the threshold, the probability may be considered to be close to the threshold. The extension of the path may be determined by: the path segments are iteratively added to the path until the path probability crosses below the minimum path probability threshold, and then adding any other path segments to the path is stopped.

In some embodiments, the extension of the set of paths may be determined based at least in part on a minimum horizon probability threshold. The minimum horizon probability threshold may be predetermined, e.g., fixed. The extension may be determined such that a probability of a vehicle traversing any path of the set within the respective extension of the path is close to the minimum horizon probability threshold. When adding or removing a path segment relative to the set of paths would cause the cumulative probability of the set of paths to cross a threshold, the probability may be close to the threshold.

In some embodiments, the extension of at least one path (e.g., the most likely path in the set of paths) and optionally all paths in the set of paths may be determined based at least in part on a maximum path distance threshold. The maximum path distance threshold may be predetermined, e.g., fixed, or it may be dynamically calculated, e.g., based on the speed of the vehicle. The same threshold may be used to determine the extent of each of the set of paths. The extension may be determined such that it is close to the maximum path distance threshold. When adding or removing one path segment will cause the extension of the generated path to cross the threshold, the path extension may be considered to be close to the threshold. The extension of the path may be iteratively determined by: the path segments are added to the path until the extension of the path crosses above the maximum path distance threshold, and then the addition of any other path segments to the path is stopped.

Some embodiments may determine members of the set of paths (i.e., which paths are included) and extension using both a maximum path distance threshold for each path and a minimum horizon probability threshold for the set of paths. Each path in the set may be extended using an iterative extension process until the path has a distance close to a maximum path distance threshold, and the number of paths in the set of paths may be determined using a minimum horizon probability threshold. Paths may be added to the set of paths until the probability of a vehicle traversing the path within a respective extension of any path in the set is close to the minimum horizon probability threshold. When adding or removing a path relative to the set of paths would cause the cumulative probability of the set of paths to cross a threshold, the probability may be close to the threshold.

In some embodiments, the extension range of each of the set of paths may be determined based at least in part on a maximum data amount threshold. The maximum data amount threshold may be predetermined, e.g., fixed. The extension range may be determined such that the extracted data is below the maximum data amount threshold.

In some embodiments, the extension of each of the set of paths may be determined based at least in part on a target request rate. The target request rate may be predetermined, e.g., fixed. The target request rate may be used to determine the maximum path distance threshold described above. The maximum path distance threshold may be determined based at least in part on a speed of the vehicle.

More generally, the extent of at least one path of the set of paths may be determined at least in part depending on the speed of the vehicle (e.g., its current speed).

The extracted data may be transmitted to the subject vehicle via a data network. Which may be transmitted at least partially wirelessly (e.g., by radio). Which may be sent via a cellular telecommunications network.

The server and client devices may be provided by a common apparatus or device (e.g., where the sending occurs via an internal interface). However, in other embodiments, the data may be extracted by a server (e.g., a static server) that is remote from the vehicle. The data may be received by a client device in the vehicle, which may be built into the vehicle or otherwise located within the vehicle (e.g., a smart phone including the driver). The client device may be or include a target vehicle, or a processing system of a target vehicle.

In some embodiments, a server remote from the vehicle may send the extracted data to an intermediate device (e.g., a smart phone in the vehicle), which may then further transmit some or all of the data to a processing system of the subject vehicle (e.g., via bluetooth).

In some embodiments, the determining the set of one or more paths and/or the extracting the data and/or the sending the extracted data may be performed by a stand-alone processing device (e.g., a smart phone or a self-contained satellite navigation unit).

In some embodiments, the determining the set of one or more paths and/or the extracting the data and/or the sending the extracted data may be performed by a digital map processing system of a subject vehicle (i.e., integrated within the vehicle). The client device may be another processing system or navigation system in or of the same subject vehicle. The data may be sent via an electrical, optical, or wireless connection within the vehicle.

Extracting map data from respective path extents may include extracting data associated with some or all of the path segments up to respective determined extents of each path

The extracted data may include attribute data associated with one or more path segments of one or more paths, preferably related to the intended use of the extracted data. Which may include speed limit data. Which may include all of the determined extension attribute data for each path.

The probability data may be generated using a machine learning model trained on historical trip data.

The extracted data may represent a portion of a network of navigable path segments (e.g., path segment identifiers or geographic data) and attribute data for a determined set of one or more paths.

A valid distance or time may be determined for the extracted data within which an attribute (e.g., a speed limit) of the map data is constant. The effective distance may be used to simplify extracted data in which the attribute is unchanged along one or more consecutive path segments. These successive path segments may be combined into a single element in the extracted data for transmission to the client device.

When the vehicle has reached the end of the path covered by the extracted data or is within a predetermined distance thereof (i.e., such that further travel will result in the position of the vehicle being outside of the virtual horizon), an updated data set may be extracted (e.g., a new virtual horizon may be generated). The processing system on the server may generate a new set of one or more paths (i.e., a new virtual horizon) in response to determining that the location of the vehicle is outside of the (current) set of one or more paths. Alternatively, when the client device determines this, the client device may request a new extracted data set from the server.

The path segment may be a road segment. The vehicle may be a road vehicle, such as an automobile or truck.

Receiving data (e.g., probability data) may include retrieving data from a memory (e.g., a memory of a processing system) or receiving data via a network connection.

An apparatus in a vehicle (e.g., an in-built processing system, or a portable device such as a smart phone) may communicate probe data (e.g., GNSS location data) to a server via a network (e.g., a radio network). Which may receive the extracted data from the server. It may receive a series of extracted data sets in response to a respective series of requests, each of which may include respective probe data.

In some embodiments, the extracted data may be used to determine information for output to a driver of the vehicle (e.g., visually and/or audibly) and/or to determine control data for controlling movement of the vehicle (e.g., reducing the speed of the vehicle). The information may be auxiliary information. Which may include speed limit information. The extracted data may be processed at least in part in the vehicle (e.g., in a computer system built into the car or in a smart phone or satellite navigation device).

The methods disclosed herein may be at least partially computer-implemented. The computer software disclosed herein may be located on a transitory or non-transitory computer readable medium. The model may be implemented on a single processing device (e.g., server) or may be implemented across multiple processing devices that may be located in different geographic locations. The model may be implemented for use on a different computer processing system than the computer processing system used to train the model in an inference mode.

The model may include any number of other convolution layers, dense blocks, and other processing layers in addition to those described above. The model may include software instructions for one or more processors, or may include dedicated hardware logic, or may be implemented using a combination of software and dedicated hardware. The software may include instructions stored in a memory of a computer processing system. The computer processing system may include one or more of the following: CPU, DSP, GPU, FPGA, ASIC, volatile memory, non-volatile memory, inputs, outputs, displays, network connections, power supplies, radios, clocks, and any other suitable components. Which may include one or more servers or computers. Which may include a microcontroller or a system-on-a-chip (e.g., when implementing a trained model for reasoning operations). Which may be configured to store or display or output probability data.

Features of any aspect or embodiment described herein may be applied to any other aspect or embodiment described herein, where appropriate. Where reference is made to different embodiments or to different sets of embodiments, it should be understood that the embodiments are not necessarily different but may overlap.

Drawings

Certain preferred embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

FIG. 1 is a digital map of a portion of a road network;

FIG. 2 is a schematic diagram of a first map processing system embodying the present invention;

FIG. 3 is the digital map of FIG. 1 highlighted to show a first virtual horizon;

FIG. 4 is the digital map of FIG. 1 highlighted to show a second virtual horizon;

FIG. 5 is the digital map of FIG. 1 highlighted to show a virtual horizon including a primary path and an alternate path determined using probability thresholds;

FIG. 6 is the digital map of FIG. 1 highlighted to show a virtual horizon including a primary path and an alternate path determined using probability thresholds and distance thresholds;

FIG. 7 is a schematic diagram of a second map processing system embodying the present invention;

FIG. 8 is a schematic diagram of a machine learning system for generating probabilities for use with some embodiments of the invention; and

Fig. 9 is a schematic diagram of a third map processing system embodying the present invention.

Detailed Description

Fig. 1 shows a part of a digital map of a road network covering a map area 1, wherein the map is represented as a plot. The map data of the map area 1 includes sides representing road segments 2 and sides connecting nodes representing links 3. For example, road segment 2a links connections 3a and 3b. The connection 3 may represent a road intersection, exit, end point or location of a change in road properties (e.g. a change in speed limit). The road segment 2 may be associated with attributes describing information such as average travel speed, legal speed limit, travel direction, length of the road segment, average turn time of the intersection, shape of the road segment (e.g., including a multi-segment line along a geographic coordinate sequence of the road segment), or number of lanes. To provide Intelligent Speed Assist (ISA) functionality, each road segment 2 (and optionally connection 3) may include a speed limit attribute that describes a legal speed limit for that road segment or connection.

Road segment 2 may be a directed segment identified by a unique path segment identifier. The unique road segment identifier may be formed using geographic coordinates of a pair of links located at both ends of the road segment in the order of travel. For example, one direction of traffic flow for a road segment 2a may be represented by a start connection 3a and an end connection 3b, while traffic flow in the opposite direction of the same road segment 2a may be represented by ordered pair connections 3b and 3 a.

Fig. 1 shows positions 4, 6 and a direction of travel 5, which are examples of probe data obtained from sensors on a vehicle, such as GNSS sensors. The probe data may encode the current position 4 and the current direction 5. Alternatively, the probe data may encode the current position 4 and the previous position 6, with the current direction of travel 5 inferred from positions 4 and 6. This provides a more general direction of travel in relation to the probe data.

The location information of the probe data is obtained from a location (e.g., GPS) sensor having a detection error margin that causes the location information to be inconsistent with the road segments shown in fig. 1. In the presence of a position sensing error, it is known to use a map matching process to determine map matched positions 7. This map matching process obtains a sequence of measured locations 4, 6 and determines a current map-matched location 7 in the road network represented by a digital map, which may be expressed as a distance traveled along a road segment. Examples of map matching processes that may be used are described in WO 2018/019984A1 and WO 2018/019989 A1, both from the TONGCHANDing navigation Co., ltd (TomTom Navigation B.V).

This map-matched location data may be updated at intervals (i.e., in real-time) as the vehicle travels. Which is given as an input to the service in order to retrieve map data about the path to be entered.

Fig. 2 shows a map processing system 100 embodying the present invention. Including a server 101 and a client apparatus 102 arranged to communicate with each other. The communication may include one or more wired or wireless links, such as a radio link (e.g., provided by a cellular network). Which may occur over one or more private and/or public networks. The server 101 may be static, e.g., hosted in a server farm located at a fixed location, and the client device 102 may be mobile, e.g., implemented on a smart phone, or a standalone navigation device, or built into a vehicle such as an automobile or truck. However, in other embodiments, the server 101 may also be located on the vehicle, for example, with all of its components provided by a single smart phone executable program, or built into the vehicle.

The server 101 executes software on one or more processors to provide a "virtual horizon" service 8. This service 8 retrieves, selects, and provides relevant map information in response to location-based probe data received from a "virtual horizon" client 9 executing on one or more processors of the client apparatus 102.

The term "virtual horizon" is used herein merely as a convenient label to express the concept of a limit (e.g., a boundary on a digital map) beyond which a device may have less information than the device has for a location within the limit.

The virtual horizon service 8 accesses a database 10 that stores digital map data, which may be similar to the data whose excerpts are shown in fig. 1. The probe data is associated with a vehicle traveling within a road network represented by a digital map database. The virtual horizon client 9 includes a probe data module 11 that obtains location data (e.g., latitude and longitude) from a location sensor 12, such as a Global Navigation Satellite System (GNSS) sensor, that is attached to or located within the vehicle. The probe data module 11 may combine the position data with other data, such as time, direction, speed or previously generated probe data.

The probe data is sent by the client device 102 to the server 101. The map matcher module 13 of the virtual horizon service 8 receives the probe data and determines a current map-matched position 7 that best matches the received probe data for the current position 4 of the vehicle. The probe data may include additional information that helps map matcher module 13 determine the current map-matched location 7. The probe data with two GNSS positions (longitude, latitude) and two directions of progress may be sufficient for the map matcher module 13 to determine which road matches. Using a longer travel history comprising more than two locations may not necessarily provide a reasonable improvement to the overall accuracy of map-matched locations. Because a longer travel history requires an increased amount of probe data, at least some embodiments of the map matcher module 13 process a maximum of two locations from the probe data to determine a map-matched location 7.

The virtual horizon service 8 has a front path extension module 14 that receives the current map-matched location 7 and optionally probe data. The forward path expansion module 14 uses the map data to determine path data representing one or more paths forward of the current map-matched location 7. The path data may sometimes represent a single, non-branching path through the plot, while it may sometimes represent multiple paths, including a main path and one or more alternative paths branching from the main path. The path may branch at the current vehicle location (e.g., where the vehicle is at an intersection), or at a point further along the primary path (e.g., where the vehicle is not currently at an intersection). The alternate path may provide map information related to an alternate future location of the vehicle in the road network that is not on the primary path. Each path may be a continuous sequence of one or more path segments. Each path has a respective total distance (i.e., extension) equal to the sum of the lengths of all path segments in the path. These ranges of extension may be determined explicitly (e.g., as total distance values calculated by expansion module 14) or may be determined implicitly only. The set of path extensions defines the extension of the virtual horizon. The virtual horizon can be said to have a total distance equal to the minimum total distance of any of the paths in the virtual horizon. Alternatively, it can be said that the virtual horizon has a total distance equal to the average of the total distances of all paths in the virtual horizon. The total distance may be used as a way to estimate how frequently a client associated with a subject vehicle requests a new path dataset. Doing this using the minimum total distance gives a conservative estimate.

The expansion module 14 generates a path or paths of the virtual horizon based on probabilities associated with road segments that are about to exit at the connection locations. This may be done in a variety of ways, some of which are described in more detail below.

These probabilities may be assigned to each connection location statically, e.g., determined analytically based on rules related to intersection angle and road category, or empirically from historical trip data. Probabilities may be included within map data, and expansion module 14 may receive corresponding probability data from map database 10.

However, in other embodiments, expansion module 14 may calculate the probabilities in real-time. Some such arrangements are explained in more detail below with reference to fig. 7-9. It may do this based on the general direction of travel or other information in the probe data. Which may depend at least in part on determining a probability for a particular vehicle to traverse for a sequence of road segments to arrive at a connection. The probability may be equal for each user (i.e., all vehicles and/or drivers), or the probability may be specifically determined for a particular vehicle and/or driver. The expansion module 14 may adjust the generic probability data (e.g., received from the map database 10 or another source) applicable to the user population by applying one or more contextual factors, such as time and/or identity of the driver or vehicle.

The road segment identifiers included in the path data may include geographic coordinates of the end point of each road segment such that the client device 102 may process the geographic coordinates without having to access the map data. The forward path extension module 14 obtains a set of map data attributes (e.g., speed limit attributes, or shape attributes) associated with the path data and combines the path data with the set of attributes to form a data set referred to herein as a "virtual horizon".

The optional virtual horizon reducer module 15 of the virtual horizon service 8 receives the virtual horizon from the front path expanding module 14 and merges road segments whose set of attributes have the same value. The distance of these road segments having the same value may be referred to as "effective distance". For example, when the set of attributes is speed attributes, the virtual horizon simplifying module 15 merges subsequent road segments that have speed attributes with the same speed value. The merging step replaces the road shape attribute (e.g., a multi-segment line) of the subsequent road segment with a single road shape attribute having a length equal to the effective distance. The merged road segment is associated with a merged road shape attribute and a common speed attribute. This method of merging road segments may be applied to any attribute suitable for the application. Road segments along paths in the virtual horizon may be merged if subsequent road segments have the same data value for a given attribute. Thus, using the virtual horizon reducer module 15 reduces the amount of data in the virtual horizon and makes it easier to process information contained in the virtual horizon client 9.

The virtual horizon providing module 16 of the virtual horizon service 8 receives the (optionally simplified) virtual horizon and transmits the virtual horizon to the virtual horizon retrieving module 17 of the virtual horizon client 9. The virtual horizon retrieving module 17 obtains the virtual horizon as a response to the probe data transmitted by the probe data module 11.

The virtual horizon processing module 18 executing on the client device 102 obtains the virtual horizon received from the virtual horizon retrieval module 17. As the vehicle travels along the path, the virtual horizon processing module 18 processes the virtual horizon and matches the GNSS input from the position sensor 12 with road shape attributes of the path or paths associated with the virtual horizon. It also uses the position data from the position sensor 12 to generate output data from a set of attributes associated with the current path and/or alternative path of the virtual horizon (e.g., representing a current speed limit), which may be displayed on a display unit to a driver of the vehicle and/or sent to a control system of the vehicle (e.g., to an automatic speed limiter system).

The virtual horizon processing module 18 receives and monitors GNSS sensor data to determine that a vehicle associated with a virtual horizon client remains in the path of the virtual horizon. It may use a trigger mechanism to determine the path that the client has deviated from the virtual horizon. Examples of such triggers may include the client being a threshold distance from a path in the virtual horizon, or the detected heading of the client differing from the heading encoded in the path of the virtual horizon by more than a threshold. When a deviation is considered to have occurred, the virtual horizon client 9 requests a new virtual horizon from the service 8 by sending updated probe data to the virtual horizon service 8.

Instead of sending a fixed radius of map data for the map area around the current location 4, the system uses the current map-matched location 7 to determine a virtual horizon from the map data in the area around the current map-matched location 7.

Fig. 3 shows an exemplary virtual horizon 19 overlaid on the map extract of fig. 1. The virtual horizon 19 here comprises a part of the road segment 2a where the current map-matched position 7 is located, which extends from the current map-matched position 7 to the next connection 3b. The associated total distance of the virtual horizon 19 is the distance travelled along the road segment from the current map-matched position 7 to the connecting node 3b. In this example, the connecting node 3b marks a change in an attribute (e.g., a speed limit) instead of a decision point (e.g., an intersection). A set of one or more attributes, which in some instances are attributes related to providing intelligent speed assistance functionality on the vehicle, is selected from map data corresponding to the virtual horizon. For example, virtual horizon retrieval module 17 may select a speed attribute from map data. In addition to the selected attributes, the virtual horizon retrieval module 17 also determines the effective distance that the attributes are effective (i.e., remain unchanged). The respective effective distance may be determined for each path of the virtual horizon 19. For the example shown in fig. 3, the selected attribute is valid from the current map-matched location 7 to the end point connection 3b of the current road segment 2 a. This distance may be the actual travel distance along the road network, or a straight line (i.e., line of sight) distance.

Fig. 4 shows the map area 1 of fig. 1 with the same road network and probe data, but where the front path expansion module 14 has generated a different virtual horizon 19 extending beyond the next connection 3b from the current map-matched position 7 of the vehicle. This virtual horizon 19 comprises a part of the current road segment 2a and a part of the next road segment 2b up to the destination connection 3c. Since there is no intersection on this part of the road network, the vehicle must traverse the entire path of the virtual horizon 19 created. The path of the virtual horizon 19 in fig. 4 has a longer associated total distance than the total distance of the path in fig. 3.

In some cases, road segments that make up a path may have the same attribute (e.g., speed limit) value. The virtual horizon simplifying module 15 may merge such road segments into a single road segment having merged road shape attributes that describe the combined road shape of the merged road segment. The travel distance of the merged road segment is then the effective distance that the set of attributes (e.g., speed limit attributes) remains unchanged. The merging of road shape attributes may reduce the amount of information in the merged road shape, for example, using the Ramer-Douglas-Peucker algorithm. This may allow the merged road shape, initially represented by many (e.g., one hundred) points, to be reduced to a merged road shape having fewer (e.g., fifty) points, depending on the curve and straightness of the road segments to be merged.

In some variant embodiments, the effective distance may be represented by an effective time. It should be appreciated that the effective time may be used instead of the effective distance, e.g., based on an assumed average speed of the vehicle. When the effective time is reached, the vehicle is expected to have traversed an effective distance. Thus, once the validity time has elapsed, new information may need to be displayed, or a new virtual horizon may need to be retrieved.

The front path extension module 14 may use different algorithms and/or factors to determine the extension of the virtual horizon. Some embodiments may support multiple algorithms, for example, provided as user-selectable alternatives. However, in all cases, the virtual horizon generated by the forward path extension module 14 has a dynamically changeable total distance that may depend on factors such as road topology, road network usage patterns, or current traffic speed data. This may be beneficial to enable efficient communication between the server 101 and the client device 102, e.g., reducing the amount of transmitted data that is never needed by the vehicle, as the data relates to road segments that the vehicle will not traverse.

The client 102 requests updated virtual horizon from the server 101 at regular or irregular intervals. The average request rate for the updated virtual horizon may be affected by various factors including vehicle speed. It may also be affected by the total distance of the paths contained in the virtual horizon, as well as by the probability of traversing the paths contained in the virtual horizon. This can be seen in the following formula indicating a potential relationship between parameters and factors that may contribute to the process of generating and providing a virtual horizon to the virtual horizon client 9.

The request rate may be defined by:

Where R is the request rate of a single vehicle (e.g., ISA client), D is the total distance (e.g., the average distance or minimum path distance of the path in the virtual horizon), and v is the travel speed of the vehicle along the path.

The estimated probability P _T of traversing the path contained in the virtual horizon (i.e., not deviating from the virtual horizon) may be given by:

Where P ₀ is the average probability of the vehicle traversing any one of the individual turns contained in the virtual horizon at the intersection, D is the average total path distance, c is the average distance between two nodes in the local map region (i.e., a measure of node density in the map region), and k is the number of intersections where all possible paths that may be traversed next are contained in the virtual horizon, i.e., the probability of deviating from the path contained in the virtual horizon is 0 at the intersection.

The average amount of data S in the information exchange transmitting the virtual horizon can be calculated as:

/>

Where s _n is the amount of map data per node (attribute data per road segment), s _R is a fixed amount of data per request (probe data plus some overhead), and k, D, and c are as defined above.

The amount of data S in the information exchange covers the situation in which the vehicle follows any path within the virtual horizon. If the vehicle deviates from the provided path, the client on the vehicle triggers a new information exchange. These additional exchanges increase the overall data volume.

The total amount of information in the exchange, S _T, including retransmissions due to deviations from the intended path may be written as:

The request rate R may also require a correction factor calculated from the traversal probability to obtain the total request rate R _T. This correction can be applied in the same way as for the total amount of information S _T.

The estimated probability P _T of traversing only the path contained in the virtual horizon affects the request rate R in the same way as the amount of information S is affected.

With an estimated probability P _T of 80%, the estimated data rate increase would be 104%.

When the estimated probability drops to 30%, the total requested rate doubles. If a 10% rate increase is considered acceptable, then the estimated probability needs to be around 70%.

The total probability of traversing may be changed by providing an alternative path (a higher k value would increase P _T for the same total distance D) or by decreasing the total distance.

The variation of parameters k and D also affects the average amount of data per request and the request rate.

Thus, the total distance (i.e., average path extension) and the number of paths included may be altered in order to achieve a target request rate and/or a target amount of data per request.

The above shows extending the total distance D versus the traversal timeA virtual horizon that is relatively short and has a relatively high estimated probability P _T is most beneficial. Thus, efficient communication performance may be provided by using embodiments of the present invention that provide a virtual horizon with a dynamically changeable total distance that depends on factors such as road topology, road network usage patterns, or current traffic speed data (i.e., total distance D may be different from one request to the next). Varying the number of alternate paths k included in the virtual horizon data is another related variable that may be controlled to optimize data exchanges.

There are various ways in which different embodiments may be used to vary the virtual horizon in response to one or more criteria. In each case, the extent of each of the paths that the vehicle will traverse the virtual horizon is determined at least in part on the respective probabilities of that path.

Criteria used by the forward path extension module 14 may include one or more of the following:

probability threshold (totalized for a single path or across multiple paths);

-a path extension (i.e. distance) threshold;

-a data amount threshold; and/or

-A target request rate.

Examples of these different methods are summarized below. Embodiments may use only one of these methods or may combine two or more to determine the virtual horizon. The threshold may be a soft threshold rather than a hard limit, as the algorithm may allow the threshold to be crossed, but use crossing of the threshold to trigger an action that determines the extension of the path, such as stopping the path from further extending. Thus, a threshold value may be used as a target. The threshold may be predetermined, e.g., hard coded or user configurable. It may remain constant across multiple horizon requests.

Minimum path probability threshold

In some approaches, the forward path extension module 14 repeatedly extends a single Most Probable Path (MPP) until the addition of a road segment results in the combined probability of the vehicle traversing the path falling below a threshold. This final road segment may or may not be included in the virtual horizon depending on the implementation) it extends the path by iteratively selecting, at each successive node along the path, from all road segments leading away from that node, the additional road segment having the highest probability of being traversed by the vehicle. The virtual horizon output by the front path expansion module 14 contains this single path and its associated attribute data (e.g., speed limit attributes).

The probability may be determined in advance or dynamically and may be based on one or more factors, such as road geometry, historical trip data, current time, etc. If a path has a probability P _P and the probability of traversing an additional road segment has a probability P _s, then the combined probability of the path and the road segment is equal to P _P times P _s.

Fig. 5 shows the map area 1 and probe data of fig. 1, wherein a first possible outgoing path section 2c and a second possible outgoing path section 2d from the connection point 3c are considered to be included in a virtual horizon. These path segments immediately follow the path of segment 2b, which includes segment 2a starting from the current position 7 up to a part of the connection point 3b and between the connection points 3b and 3 c. Starting from the connection point 3c, the probability that the vehicle takes the first road segment 2c is 0.7 (70%) and the probability that the second road segment 2d is 0.3 (30%). Thus, the probability of traversing the path from the current position 7 to the connection point 3d is 0.7, and the probability of traversing the path from the current position 7 to the connection node 3e is 0.3. (the path between the current position 7 and the connection point 3c has 100% probability of crossing.)

When applying the MPP method, the forward path extension module 14 will select the first road segment 2c to be included in the virtual horizon as a more likely segment. If the forward path extension module 14 determines that the respective product of 0.7 and the probability assigned to each of the three possible road segments leading from the next connection 3d along this road segment 2c is below a predetermined threshold, it may stop and output a virtual horizon having three path segments 2a (the portion of segment 2a forward from the current position 7), 2b, and 2 c.

In this way, the path probability, as well as the threshold value of the road segment probability itself, affects the extension of the path contained in the virtual horizon, with a lower minimum threshold value increasing the average amount of data to be returned for each request.

Minimum horizon probability threshold

In a variant approach, instead of considering only a single most likely path, the front path extension module 14 may include zero, one, or more alternative paths in the virtual horizon (depending on the intersection layout). The virtual horizon may be extended by extending one or more paths by adding road segments to the paths until the probability that the vehicle takes any path within the virtual horizon (i.e., does not turn onto a path that is not included in the horizon until reaching the extension of the horizon) falls below a minimum horizon probability threshold.

In the example shown in fig. 5, the combined probability of the primary path 21 including the first road segment 2c continuing from the second intersection 3c and the alternate path 22 including the second road segment 2d continuing from the second intersection 3c is 1 (i.e., 100%). However, if adding another road segment to the end of the primary path 21 or to the end of the alternate path 22 would cause the combined probability of the virtual horizon to be below the minimum horizon probability threshold level, the path expansion process may stop expanding the virtual horizon (with or without the final road segment being included, depending on the implementation).

Paths may be extended with breadth-first methods that add more paths close to map-matched locations, or depth-first methods that give priority to grow the main path may be used. The minimum horizon probability threshold for the virtual horizon may cause more alternative paths to be included, and different heuristics may be used to limit the introduction of new alternative paths. This may be done by using a distance threshold as explained below, or in any other suitable way. The cost function may be used to determine how the paths should be selected depending on the map topology and the probability of traversing each path. For example, where the probability of traversing all paths along the origin is low, it may be beneficial to use a shorter distance threshold and include a greater number of paths in the virtual horizon.

The minimum threshold of the combined probabilities of the virtual horizon may affect the total distance associated with the virtual horizon. On highways with few exits, the total distance may be on the order of a few kilometers. In urban environments with a large number of closely spaced intersections, the total distance may be about 100 meters.

Maximum path distance threshold and minimum horizon probability threshold

Some methods of determining the extension of the virtual horizon use a maximum path distance threshold.

This is explained with reference to the example of fig. 6 based on the map extract of fig. 1. The virtual horizon service 8 generates a virtual horizon by: the most likely path is extended until a road segment is included that extends the path beyond a predetermined threshold distance value. This distance threshold is represented by line 23, which spans the road segment 2e with the highest probability that is drawn from the connection 3d in the example of fig. 6. It should be noted, however, that in practice the exact geographical location of the threshold value does not necessarily need to be determined) depends on the intersection (connection) density and traffic pattern of the road network, the combined probability of the main paths determined in this way may be below the minimum horizon probability threshold of the virtual horizon. If so, the front path extension module 14 may generate and extend the first alternative path 22 until its extension also just exceeds the same threshold distance value represented by the second line 23b in FIG. 6. If the combined virtual horizon probability for both paths is still below the minimum horizon probability threshold, then additional alternative paths may be iteratively added until the combined probability crosses above the minimum horizon probability threshold, at which point expansion may cease.

In the example of fig. 6, the probability of traversing the primary path 21 is 0.56 (56%) according to the combined probabilities of road segments 2b (1.0), 2c (0.7), and 2e (0.8), while the alternate path 22 has a combined probability of 0.24 (24%) according to road segments 2b (1.0), 2d (0.3), and 2f (0.8). The combined total probability of crossing the virtual horizon consisting of the two paths 21, 22 is then 0.8 (80%). If the minimum threshold probability of the virtual horizon is set to, for example, 0.7 (70%), then the extracted map data in the virtual horizon shown in fig. 6 would meet this requirement.

For a given virtual horizon request, the front path expansion module 14 continues to generate alternative paths until the combined probabilities of the primary and alternative paths exceed a minimum horizon probability threshold. This approach produces a virtual horizon that has a greater total distance for a particular map area while ensuring that a minimum total distance is contained in the virtual horizon in a relatively dense portion of the road network, such as in a city area. This may reduce the risk of the vehicle turning onto a road where the vehicle-based client 102 does not have any attribute information, but may come at the cost of an increased amount of data per request.

Maximum data amount threshold

The extension of the virtual horizon may be determined at least in part by one or more communication system parameters.

In some embodiments, the virtual horizon service 8 generates a virtual horizon in which the total amount of data sent in response to a request is below a maximum threshold data value. This can help reduce costs imposed by the telecommunications provider in order to deliver responses to client requests and/or make such costs more predictable. The threshold may be used only as an additional limit to the selection of path segments to be included in the horizon, or it may be used as a target, e.g., adding path segments until the selected map data is close to the maximum data amount threshold.

This approach may be advantageously used even in embodiments where the virtual horizon always consists of only a single path (i.e. the most likely path) but where the amount of data varies depending on the number of curves (points) in the road shape (multi-segment lines) and/or depending on the set of attributes of the road segments. In such cases, the simplistic fixed distance limitation may result in an unpredictable amount of data, potentially resulting in unpredictable costs from the telecommunications provider.

Request rate targeting

The extension of the virtual horizon may be determined at least in part by the target request rate, i.e., the frequency at which the client 9 sends requests for new virtual horizons to the server 8 (e.g., how many requests per minute or hour). The actual request rate may depend on various factors, but the expected request rate may be determined based on the extension of the virtual horizon and the expected traverse speed of the vehicle through the virtual horizon. Assuming a constant average path distance within the virtual horizon, the faster the vehicle travels through the road network, the higher the request rate will be.

The predetermined target request rate may be used to limit the request rate from being too high and/or too low. Thus, it may be a bi-directional source rather than a uni-directional threshold.

The virtual horizon service 8 may determine an expected speed from the received probe data and determine a target distance for the virtual horizon response. Which uses the target distance to generate a virtual horizon for the received probe data. The expected traverse speed may be a current travel speed, an average travel speed, a current average travel speed, a historical travel speed, which may be obtained from map data.

This target distance may be used as a maximum path distance threshold in the algorithms disclosed above, or in any other suitable manner.

Any or all of these methods may be combined in some embodiments in order to enhance the selection of a subset of map data to be included in the virtual horizon. The virtual horizon service 8 may determine a virtual horizon in which a compromise between the combined probability of crossing and the amount of data is stalled. For example, an optimal virtual horizon may be determined based on a weighted sum of the combined probability and data amount for each of a number of candidate virtual horizons.

In all of the above methods, the primary path in the virtual horizon and any alternate paths are generated based on probabilities associated with road segments that are about to exit at the connection location. These "turn probabilities" may be statically assigned to each connection location, or they may be adjusted, for example, based on general direction of travel or other information (e.g., what path the vehicle takes to reach the connection).

Fig. 7 shows a map processing system 100 'that is similar to the system 100 of fig. 2, except that the front path expansion module 14' contains a probability estimator 20. The probability estimator 20 enables the forward path extension module 14' to dynamically determine path segment probabilities, e.g., taking into account contextual factors such as the identity of the vehicle.

In some embodiments, the forward path extension module 14' uses a probability estimator that includes a model trained using machine learning. FIG. 8 shows a high-level schematic diagram of an exemplary machine learning system for probability generation that may be used to train a model. The historical trip data 24 and map data 26 are input to a machine learning process 25 that trains a model (e.g., a neural network) to generate probabilities of possible paths. The model or data derived from the model is provided to (e.g., implemented within) a probability estimator 20. The probability estimator 20 may then use this to determine path probabilities in response to client requests.

Using machine learning may make it possible to determine the probability of a sequence of connected road segments taken, rather than simply selecting the most likely option at each turn, which may provide a substantial increase in the accuracy of the path prediction and thus a decrease in the likelihood of the vehicle turning on a road that is not included in the latest virtual horizon response sent to the client 102.

Fig. 9 shows a variant map processing system 100 "that is similar to the system 100' of fig. 7, except here the front path expansion module 14" contains a contextualized probability estimator 20 "that can generate contextualized probabilities of road segments at the junction, taking into account the identity of the vehicle or driver and optionally other factors (e.g., time of day). Contextualized probability estimator 20″ may obtain trip data from local trip data storage 27 that includes individual, parallelized data based on trips taken by a particular user or vehicle. The general population-wide data may provide good predictions of paths that may typically be traversed, but these predictions may be further improved using the parallelization data if personalized data is available for local travel, if previously traveled routes have associated preference information for each user. Predicting based on the iterative behavior enables the forward path extension module 14 "to better determine the forward path that should be included in the virtual horizon.

The probability of generating from the local trip data 27 may be a deterministic process or may be based on machine learning. The forward path extension module 14 "may operate the model to adjust probabilities determined from the population-wide predictions for contextual factors.

It will be appreciated by those skilled in the art that the present invention has been illustrated by description of one or more specific embodiments thereof, but is not limited to such embodiments; many variations and modifications are possible within the scope of the appended claims.

Claims

1. A method for sending map-related data to a client device, wherein the map-related data is extracted from digital map data representing a network of navigable path segments within a geographic area, the method comprising:

Determining a set of one or more paths, each path comprising one or more of the plurality of path segments and having a respective determined extension, wherein the determined extension of at least one of the paths in the set depends at least in part on the received probability data;

The extracted data is sent to the client device.

2. The method of claim 1, wherein the set of one or more paths comprises a plurality of paths, and wherein the method comprises extracting data associated with each of the plurality of paths from the digital map data according to the respective determined path extension ranges.

3. The method of claim 2, wherein the extracted data contains only digital map data associated with the path of the set of one or more paths.

4. The method of any of the preceding claims, comprising determining the extension of at least one path of the set of paths based at least in part on a minimum path probability threshold.

5. The method of claim 4, comprising iteratively adding path segments to a path until the probability that the vehicle crosses the path crosses below the minimum path probability threshold, and then ceasing to add any other path segments to the path.

6. The method of any of the preceding claims, comprising determining the extension of each of the set of paths based at least in part on a minimum horizon probability threshold.

7. The method of claim 6, comprising determining the extension such that the probability that the vehicle traverses any path of the set within the respective extension of the path will be such that adding or removing one path segment relative to the set of paths will cause the probability to cross the minimum horizon probability threshold.

8. The method of any of the preceding claims, comprising determining the extension of at least one path of the set of paths based at least in part on a maximum path distance threshold.

9. The method of claim 8, comprising iteratively adding path segments to a path until the extension of the path crosses above the maximum path distance threshold, and then ceasing to add any other path segments to the path.

10. The method of claim 8 or 9, comprising determining the maximum path distance threshold based at least in part on a current speed of the vehicle.

11. The method according to any one of the preceding claims, comprising determining members and extension of the set of paths by applying a maximum path distance threshold for each path and a minimum horizon probability threshold for the set of paths.

12. The method of claim 11, comprising extending each path of the set of paths using an iterative extension process until the path has an extension such that adding or removing one path segment will cause the extension of a generated path to cross the maximum path distance threshold, and adding a path to the set of paths until the probability that the vehicle traverses any path of the set within the respective determined extension such that adding or removing one path segment relative to the set of paths will cause the probability to cross the minimum horizon probability threshold.

13. The method of any one of the preceding claims, wherein the extension of each of the set of paths is determined based at least in part on a maximum data amount threshold.

14. The method of any of the preceding claims, wherein the extension of each of the set of paths is determined based at least in part on a target request rate.

15. The method of any one of the preceding claims, wherein the subject vehicle carries or comprises the client device, and wherein sending the extracted data to the client device comprises transmitting the extracted data from a remote server to the subject vehicle via a data network.

16. The method of any one of the preceding claims, wherein the extracted data comprises attribute data of one or more road segments of the set of one or more paths.

17. The method of any of the preceding claims, wherein the extracted data comprises speed limit data over the determined extension of each path of the set of one or more paths.

18. The method of any one of the preceding claims, comprising receiving probe data from the subject vehicle via a network, determining the set of paths based at least in part on the received probe data, and transmitting the extracted data to the vehicle.

19. A computer processing system for processing digital map data, wherein the computer processing system is configured to perform the method of any of claims 1-18.

20. Computer software comprising instructions which, when executed on a computer processing system, cause the computer processing system to perform the method of any of claims 1 to 18.