DE102004014050A1 - Digital map management method, especially for motor vehicle use, in which maps are managed as a collection of partial regions or tiles and have associated integral data, e.g. relating to low tunnels or speed limits - Google Patents

Abstract

Method for generating, storing and using digital street maps with integral data relating to local event points (tunnels, speed limits) for triggering or controlling journey relevant information and assistance functions. The road network is stored in the vehicle memory, divided into partial regions, or tiles, as an index structure and indexed partial region coordinates, i.e. longitude and latitude, allocated to the event points.

Description

The The invention relates to methods of managing digital cards. specially The invention relates to the management of digital street maps for control or triggering of auxiliary functions, such as those used in modern vehicles reach.

Become in the future digital road maps not just the basis for the navigation, but also for Additional functions (curve warning, 'tunnel functions') and a variety of other tasks be used in the vehicle.

today digital road maps However, they are strongly geared for use in navigation devices. This applies to both Data content, data acquisition, as well as data storage. Such road map forms a closed network over the largest possible area. The data are so filed that routing algorithms in terms of their time requirements optimally supported become. Further information, as needed for new applications, e.g. Curve warning and 'tunnel functions' (automatic closing of the Sunroof, light on, automatic switching on circulating air, etc.), are not - or only with a bad quality - included.

The The invention is based on the illustrated prior art. you the task is based on a method of managing a new digital map structure for To develop vehicles as a basis, in particular for novel map-based information and assistance functions.

These The object is achieved by the method having the features of the claim 1 solved. Further details, advantageous embodiments and developments the method according to the invention are the subject of the dependent claims.

The Considered invention the fact that the cost of a navigation system including the required digital road map for additional functions are not negligible. Does not value the navigation itself priority is given to new card-based information and assistance systems, the question arises whether a card needed for this purpose necessarily on a usual Navigation card must 'touch'. It lends itself on, especially for such novel applications have a correspondingly optimized digital road map to develop completely different from a navigation map can. For the navigation is such a map may not be usable, however, their advantage is that less memory is needed and for Users therefore incurred significantly lower royalties.

card-based Additional functions, such as curve warning and 'tunnel functions', only need information which for the Vehicle are currently relevant, i. while driving must always only to be accessed on the map detail, the closer environment represents the vehicle. That's why other data structures and corresponding access mechanisms used than for navigation systems that calculate the route quick access to larger mesh sections need.

For quick access to the map data of the vehicle environment, the entire network is divided into small subareas (also referred to as 'tiles') and stored an index structure for these subareas in the vehicle memory. The subareas may also overlap, as in the patent US 6,470,287 described.

Within of a subdomain, further redundant index structures will not needed. As during a Ride only a few subareas are needed at a time, can the data contained therein are searched linearly or dynamically an index structure for the currently relevant subareas are generated. This allows the needed Memory requirements in the vehicle can be significantly reduced.

The inventive method is hereinafter referred to by way of various embodiments with reference closer to the drawings explained. It shows

1 Description of an event point through assigned parameters

2 Representation of the event "End of a ramp" with an access point

3 Event "End of a ramp" with a 2-point chain

4 Excerpt from the graph-theoretic representation of the traffic network: edge with end point in the corner of a "tile" and possible successor edges

5 End point of an edge on the edge of a tile and corresponding trailing edges

6 Digital representation of a sequence of trailing edges and the associated "tiles" in memory

Embodiment 1

at this variant map contents are punctually and each with a greatly reduced geometry, compared to today's navigation maps, be filed. Which special map contents are taken into account may vary depending on the use of the card.

in principle can such a new map from a classic digital road map to be generated. This is so far 'thin' that they only from a variety consists of so-called event points. Need map content that in today's street maps not yet recorded the corresponding event points are obtained from other sources or be re-recorded.

Example: The attribute 'tunnel' will be in the new one Map shown with the help of the points 'Tunnel entrance' and 'Tunnel exit' and specifically for the above-mentioned 'Tunnel functions' needed. A speed limit is saved as' Speed Limit point 'and forms the basis for 'Speed Limiter' applications. tunnel and speed limit are two possible ones Map content. They represent diverse events.

Everyone Event point has a minimal set of parameters that it uses clearly describes. additional All deliver parameters for an application requires information (e.g., length of a Tunnels, maximum curvature a curve).

As in 1 , the position values of an event point (Longitude _EP , Latitude _EP ) are used to describe the center point of a circle of radius T _Radius-EP . This event point is relevant for a vehicle if it is within this circle and the vehicle direction coincides with the direction associated with the event point (heading) within a certain tolerance (± T _{direction EP} ).

• A) Im einfachsten Fall wird die Geometrie durch den Ereignispunkt selbst, d.h. seine Position (Longitude_EP, Latitude_EP) und Durchfahrtsrichtung (Heading), ausreichend beschrieben (Tabelle 1): Tabelle 1
  
• B) Ein Ereignis kann für das Fahrzeug nur dann relevant werden, wenn ein zugehöriger Zugangspunkt passiert wurde, d.h.: wurde ein Zugangspunkt überfahren, der mit einem bestimmten Ereignis korreliert ist, dann ist das Ereignis für das Fahrzeug mit Sicherheit zu erwarten. Ein Zugangspunkt ZP wird genau dann überfahren, wenn sich das Fahrzeug innerhalb eines zugeordneten Kreises (Mittelpunkt: Longitude_ZP, Latitude_ZP, Radius: T_Radius-ZP) befindet und die Fahrzeugrichtung mit der dem Zugangspunkt zugeordneten Richtung (Heading_ZP) innerhalb einer gewissen Toleranz (± T_Richtung-ZP) übereinstimmt (analog zur Darstellung in 1). Die entsprechenden Geometrieparameter für den Zugangspunkt werden daher in die Repräsentationstabelle mit übernommen (Tabelle 2). Hat ein Ereignis mehrere korrelierte Zugangspunkte, dann werden sie beispielsweise nach aufsteigender Breite (Süd-Nord) bzw. aufsteigender Länge (West-Ost) sortiert in der Ereignispunkttabelle gespeichert. Tabelle 2
  
  2 zeigt einem Zugangspunkt 'Ende einer Rampe', der mit einem nachfolgenden Ereignispunkt korreliert ist. Das durch den Ereignispunkt repräsentierte Ereignis (z.B. 'Geschwindigkeitsbeschränkung') soll nur gelten, wenn sich das Fahrzeug auf der Abfahrtsrampe von der Autobahn befindet, nicht hinge gen bei einer Fahrt auf der am Ende der Rampe parallel verlaufenden Bundesstraße. Wird der Zugangspunkt passiert, ist sichergestellt, dass die Rampe befahren wurde, denn der dortige Durchfahrtswinkel ist um ca. 90 Grad zur Fahrtrichtung auf der Bundesstraße verschieden.
• C) Es kann vorkommen, dass ein Ereignis für das Fahrzeug nur dann relevant werden kann, wenn eine Reihe von Zugangspunkten passiert wurde. Um dies eindeutig beschreiben zu können, wird mit dem Ereignispunkt eine zugehörige Kette mit einer prinzipiell beliebigen Anzahl von Zugangspunkten gespeichert (Tabelle 3). Tabelle 3
  

In order to keep the memory requirement as small as possible in this embodiment, only the absolutely necessary geometry information can be stored per event point. For the generation of an event point map, different geometry representation forms can be used:

• A) In the simplest case, the geometry is adequately described by the event point itself, ie its position (Longitude _EP , Latitude _EP ) and heading direction (Table 1): Table 1
  
• B) An event may only become relevant to the vehicle if an associated access point has been passed, ie: if an access point has been crossed over that is correlated with a certain event, then the event for the vehicle is to be expected with certainty. An access point ZP is run over exactly when the vehicle is within an assigned Circle (center: Longitude _ZP , Latitude _ZP , radius: T _{radius ZP} ) is located and the vehicle direction with the access point associated direction (Heading _ZP ) within a certain tolerance (± T _{direction ZP} ) matches (analogous to the representation in 1 ). The corresponding geometry parameters for the access point are therefore included in the representation table (Table 2). For example, if an event has multiple correlated access points, they are sorted by ascending latitude (south-north) or ascending (west-east) in the event point table. Table 2
  
  2 shows an access point 'end of a ramp', which is correlated with a subsequent event point. The event represented by the event point (eg 'speed limit') should only apply if the vehicle is on the departure ramp from the motorway, but not on a journey on the main road parallel to the end of the ramp. If the access point is passed, it is ensured that the ramp has been used, because the passage there is different by about 90 degrees to the direction of travel on the main road.
• C) It may happen that an event for the vehicle can only become relevant if a number of access points have been passed. In order to be able to describe this clearly, the event point is used to store an associated chain with an arbitrary number of access points (Table 3). Table 3
  

Becomes go through the sequence of access points, then that's the event for the Vehicle to be expected with safety. Alternatively, a comparison the match between the position chain traveled by the vehicle and the different ones Point chains of the card take place. The points chains to the individual event points can For this purpose, for example, be generated with known 'trace point' algorithms. Belong to one Event multiple points chains, then they are for example after ascending latitude (south-north) or ascending length (West-East) of the first chain point sorted in the event point table saved.

As in 3 Using the example of a motorway junction, by using a chain of points, it is possible to prevent an event 'end of a ramp' from being detected when driving on the highway beside the ramp.

For each Event point is to examine if the minimum geometry is by variant A) is sufficient. Only if this is not the case is Procedure B), C) or to use a mixed form.

Embodiment 2:

at this embodiment becomes a complete part-route network with all for needed the assistance functions Attributes stored in the vehicle memory.

The traffic network can be mathematically modeled as a graph. A graph consists of nodes and edges, with edges representing a logical connection between every two nodes. A single edge represents a stretch of road between two nodes on which no turn is made to another road can not be inflected from another street. Preferably, a so-called directed graph is used, ie, each edge has a unique direction from a source node to a destination node (but this direction has nothing to do with the allowed direction of travel).

To each edge are considered information about the course of the route at least the coordinates (latitude / longitude) of the start and end points. In it implicitly too already information about hubs If the beginning or end point of an edge is the exact has the same coordinates as the beginning or end point of another Edge, so the edges are over a node connected to each other. Successive edges of a previous edge have to Therefore, it can not be named explicitly, but can be searched for by a search Edges (within the relevant 'tile') are found whose initial or Endpoint the exact same coordinates as the previous edge Has.

The Identification of the edges is preferably done only over the Coordinates of the respective start and end point. The edges become So no identification number (edge ID) assigned as it e.g. in the Geographical Data Format (GDF) is common. This will be in considerable amount of storage space saved up. In addition, would the reduction to identification numbers when calculating a fastest route lead to unacceptably high computation times.

In the case of turn restrictions, there is the problem that the successor edges must be named, which may not be bent from a predecessor edge. Without the existence of edge IDs, this is not easily possible. However, to solve this problem, turn restrictions can be stored as follows:
For the affected predecessor edge, the associated direction of travel is specified, which describes whether the turn is prohibited when driving in the edge direction, ie at the end point of the edge, or when driving against the edge direction, ie at the starting point of the edge. The beginning or end point of the preceding edge lying in the direction of travel is called the turn-off point. To indicate which of the edges adjacent to the turn-off point, to which by the way the predecessor edge itself counts (turning maneuver), a turn is prohibited, all adjacent edges are sorted, eg according to latitude and longitude of the start or end of the turn not coinciding with the turn-off point. endpoint. This results in a unique sort order of the adjacent edges, and it can be named by specifying the position in this order, a subsequent edge.

• 1. Bit: Fahrtrichtung "0" = Anfangspunkt → Endpunkt, "1" = Gegenrichtung
• 2. Bit: ist die Nachfolgekante physikalisch mit der Vorgängerkante verbunden? "0" = nein, z.B. wenn bei einer Brücke die "Nachfolgekante" mit gleicher Koordinate in einer anderen Ebene verläuft, "1" = ja, Verbindung besteht)
• 3. Bit: werden weitere Nachfolgekanten im Abbiegeverbot angegeben? "0" = nein, "1" = ja; es kann z.B. verboten sein, von Kante A über Kante B nach Kante C abzubiegen, während es erlaubt ist, von Kante D über Kante B nach Kante C zu fahren)
• 4. Bit: ist das Abbiegeverbot auf bestimmte Fahrzeug-Klassen beschränkt "0" = nein, "1" = ja; wenn ja, folgt ein Byte mit der Be schreibung der Fahrzeuge, für die das Verbot gilt (diese Angabe kommt ggf. noch vor weiteren Folgekanten des Abbiegeverbots)
• Bit 4-8: Nr. der Nachfolge-Kante in der oben genannten Sortier-Reihenfolge (die erste Kante hat die Nr. 1, eine 0 in diesem Feld bedeutet, dass kein weiteres Abbiege-Verbot besteht).

Turn-off prohibitions can, for example, be stored in information blocks of one byte via the following bit assignments (the order is of course arbitrary, depending on the convention):

• 1st bit: direction of travel "0" = starting point → end point, "1" = opposite direction
• 2nd bit: is the trailing edge physically connected to the predecessor edge? "0" = no, eg if with a bridge the "successor edge" with the same coordinate runs in another plane, "1" = yes, connection exists)
• 3rd bit: are further successor edges specified in the turn ban? "0" = no, "1" = yes; it may be forbidden, for example, to turn from edge A to edge B to edge C while allowing from edge D to edge B to edge C)
• 4th bit: is the turnabout restricted to certain vehicle classes "0" = no, "1" = yes; if so, a byte follows with the description of the vehicles for which the ban applies (this indication may even come before further follow-on edges of the turn-off ban)
• Bit 4-8: Number of the successor edge in the above sort order (the first edge has the number 1, a 0 in this field means that there is no further turn prohibition).

By the restriction 4 bits to specify the trailing edge can be nodes with a maximum of 15 adjacent edges are described. That should be more than enough be. According to NavTech's Digitizing Policy, you may use e.g. only a maximum of 7 edges adjacent to one node.

The data format described so far is designed to minimize the memory requirement, but requires a higher computational effort in the vehicle. The main problem is locating successors of a particular edge. This operation must be performed very often to calculate the electronic horizon and requires searching all edges in a subarea (ie "tile"). To access this To accelerate, pointers to the trailing edges (so-called "pointers", ie the memory addresses of the trailing edges) can be stored for each edge. The generation of these pointers can be performed dynamically in the vehicle for the tiles in the vehicle environment. This means that all edges of a tile only have to be searched once again (namely when the pointers are generated), then trailing edges can be accessed directly during the course of the journey.

Yet Access is faster if these pointers are directly in the Card will be saved. If the memory address relative to the initial memory address the tile considered can be given the memory address be encoded with fewer bits, wherein the number selected bits also have a maximum size of the memory block for one Tile is specified. If for a tile has more data than in such a memory block fit, the tile must be further divided into smaller tiles. The following examples use the relative memory address 15 bits coded. This allows a maximum tile size of 32 Kbyte.

• • aktuelle Kachel
• • horizontaler Nachbar
• • vertikaler Nachbar
• • schräger Nachbar

If the start or end node of a predecessor edge is located at the edge of a tile (this can be recognized by the coordinates of the node), then each child edge can either be in the same tile or in an adjacent tile. In that case, in addition to the relative address of the adjacent edges, it must be specified in which tile the respective successor edge is located. For rectangular tile boundaries, the following values can be used for specifying the tile address of the successor edges ( 4 and 5 ):

• • current tile
• • horizontal neighbor
• • vertical neighbor
• • oblique neighbor

The current tile is the tile on which the predecessor edge itself is located. The horizontal neighbor is the next tile in the horizontal direction, which adjoins the considered end node of the predecessor edge. Is the end node on the right edge of the tile (s. 4 ), the horizontal neighbor is the tile to the right, whereas the end node is the left margin ( 5 ), this is the left adjoining tile. If the end node is neither left nor right, there is no horizontal neighbor.

Similarly, the vertical neighbor is defined. If the end node is at the top or bottom of the tile, this is the top or bottom tile. If the end node is neither at the upper nor at the lower limit, there is no vertical neighbor ( 5 ). The slanted neighbor only exists if the end node is exactly in one corner of the tile ( 4 ). The direction in which this neighbor is located is given by adding the direction vectors of the horizontal and vertical neighbors.

The four possible values for specifying the neighboring tile can be coded with 2 bits. In order to simplify the data processing, the neighboring roofs of the successor edges can be stored in groups of four successor edges ( 6 ).

The Tiles of the successor edges are only needed if the respective Endpoint of a previous edge located exactly on the edge of a tile. This condition can be based on the coordinates of this endpoint. Only if the condition Fulfills is, the neighboring roofs are considered. At endpoints within the tile, no additional data is needed. There only a small fraction of the edges have an endpoint at a tile boundary has, falls the additional one Memory requirement for storing the tiles of the successor edges hardly significant.

Claims (15)

Method for generating, storing and using digital road maps with integrated data on local event points (tunnels, speed limits, etc.) for triggering or controlling driving conditions (position, direction, speed, etc.) Information and assistance functions in vehicles, characterized in that the road network in the vehicle memory divided into subdomains (tiles) is stored as an index structure and the indexed subareas coordinates (Longitude _EP , Latitude _EP ) are assigned by event points. A method according to claim 1, characterized in that for each event point parameters for Cha Characterization of the event (eg length of a tunnel, maximum curvature of a curve) or triggering of the corresponding information / assistance function are stored. A method according to claim 2, characterized in that the parameters stored for event points also include heading values (heading _EP ) and distance values (T _{radius EP} ). A method according to claim 1, 2 or 3, characterized in that subareas coordinates (Longitude _ZP , Latitude _ZP ) are assigned by access points. Method according to claim 4, characterized in that that access points are correlated with event points. A method according to claim 4 or 5, characterized in that for access points direction (heading _ZP ) and / or distance parameters (T _{radius EP} ) are stored. Method according to claim 5 or 6, characterized that multiple access points to a point of event as a logical chain be assigned. Method according to claim 7, characterized in that that multiple access points of a logical chain to geographic Sequence (e.g., north-south, East-West). Method according to one of claims 1 to 8, characterized that the road network as a graph (nodes, edges) is stored. Method according to claim 9, characterized in that that the road network formed as a directed graph (edges with predetermined direction) is. Method according to claim 9 or 10, characterized that for each edge stores the coordinates of its start and end points and used to identify the edge. Method according to claim 9, 10 or 11, characterized that directional parameters are stored for each edge. Method according to one of claims 9 to 12, characterized for each edge for characterizing turn restrictions, information about edges adjacent subareas ("successor edges") are stored. Method according to claim 13, characterized in that that edges of adjacent sub-areas by geographical order (e.g., north-south, East-West). Method according to claim 14, characterized in that that data for characterizing turn restrictions in information blocks of stored in a byte, with one bit the direction of a Edge (e.g., "0" if from the starting point to the end point of the edge, "1" for opposite direction); One bit determines if the edge is physically aligned with another edge is connected (e.g., "0" if one) Bridge edges with the same coordinate in different levels, "1" if connected); another bit determines whether for Trailing edges are constraint restrictions (e.g., "0" = no, "1" = Yes); One bit determines whether a turn restriction applies to certain vehicle classes limited is (e.g., "0" = no, "1" = yes); as well as the remaining four Bit the position of the trailing edge in geographic order represents.