WO2007082782A2

WO2007082782A2 - Updating method for navigation databases

Info

Publication number: WO2007082782A2
Application number: PCT/EP2007/050008
Authority: WO
Inventors: Reinhard Meschenmoser; Dirk Luedtke
Original assignee: Robert Bosch Gmbh; Denso Corporation
Priority date: 2006-01-11
Filing date: 2007-01-02
Publication date: 2007-07-26
Also published as: WO2007082782A3; DE102006001372A1

Abstract

The invention relates to a method for updating a distributed database of a navigation system, which is subdivided into a plurality of segments, by transmitting an updated segment from a central database which is subdivided into corresponding segments and storing the corresponding segment in the distributed database. In order to maintain consistency of the database, during the update of a segment, dependencies of other segments are allocated to every segment and these dependencies are stored so that when the segment in the distributed database is updated those segments, too, are updated on which the updated segment is dependent.

Description

description

title

Update procedure for navigation databases

The present invention relates to a method for updating a decentralized

Database of a navigation system, which is divided into several segments, by transmitting an updated segment from a centralized data base divided into corresponding segments and storing the corresponding segment in the decentralized database.

Today's navigation systems have an extensive data base in which, for example, data for entering the destination, the route search and display and the route guidance are stored by displaying the current position of a vehicle. Furthermore, the database may contain additional data for driver assistance systems. The database usually has static data, d. H. the content of the database remains unchanged. An update is usually done by completely updating the entire database based on newer versions of the raw data for the digitized map data.

In part, dynamic data shares can be used as temporary information

Traffic disruptions are integrated by radio-based information systems such as TMC and / or VICS in the navigation system. TMC and / or VICS, however, are unable to update all aspects of the database. An update of the complete database is associated with a considerable amount of time due to the large amount of data. Also, the real road network underlying the digitized map changes only in individual subsections, so that a complete update of the entire database often does not justify the effort. Therefore, to reduce the amount of data required for an update step, the entire database can not be updated in a single step, but is only partially updated. For this purpose, the content of the database is divided into individual segments, for example geographic, political and / or thematic aspects or a combination thereof.

Furthermore, a subdivision may take place in that certain segments have so-called routing data, while other segments contain background data. These may, for example, include the curve between intersections or points of interest, etc.

However, the incremental update can cause problems because the database may lose consistency. That updating a subarea enables potential relationships with other segments, such as road links, and cross-connections to other segments to be resolved. These

Relationships between the various segments are referred to below as dependencies and may be of a varied nature.

An example of such a dependency is the course of a road through two segments formed geographically, so that the road is thus represented in both segments. If, due to a structural measure, a change in the course of the road takes place only in an area which lies completely in one of these two segments and is spaced from the edge of the segment, the updating of this segment with respect to the converted road has no effect on the other segment. There is no new dependency on this update.

But if the road is changed at the boundary of the two segments, these two segments can not be updated independently. In particular, an update of the road network causes problems, since the dependencies are particularly pronounced and many roads of the road network are often represented in several segments.

Against this background, the object of the present invention is to enable a consistent updating of any segments of a navigation database. This object is achieved by a method having the features of claim 1. In a method of the type described above, the invention provides that each segment dependencies of other segments of the database assigned and the dependencies are stored, so that when updating the segment in the decentralized database and the segments are updated, of which the updated segment depends is.

Updating a segment does not cause a database inconsistency because it also updates the corresponding segments associated with the updated segment. The dependencies can point in one direction or be bidirectional.

To distinguish the versions of a particular segment, each segment is assigned a version identifier that is stored in the database. From the version identifiers, for example, a consecutive numbering, the time sequence can also emerge to be able to determine the most recent version.

So updating a segment does not turn into an avalanche

Updated many segments, it is envisaged that the subdivision of the database into the individual segments is done so that there are few dependencies of a segment of other segments.

Likewise preferred in a method according to the invention is the updating of a segment in the central database in such a way that there are few dependencies of the segment on other segments.

Since a segment on which a segment to be updated is dependent may itself have its own dependencies, it is advantageously provided that in the case of

Update a segment of the decentralized database with multi-level dependencies on other segments to successively update the segments that have a multi-level dependency. - A -

In order to avoid a temporary inconsistent database during an update, the original segment is preferably continued to be used after an updated segment has been stored in the decentralized database until all segments have been updated of which the dependency of the updated segment exists. Only when the transmission of all the segments to be updated is completed, the respective updated segments are used.

In order to enable a high mobility for the navigation system with the decentralized database, the transmission of the updated segments is preferably carried out wirelessly. This can be done for example by means of a radio or radio transmission or via a mobile telecommunications connection. Alternatively, a data transfer via exchangeable storage media is also conceivable.

The invention will be explained in more detail by way of example with reference to an exemplary embodiment with reference to the attached figures, in which:

Figure 1 - shows schematically a database of a navigation system;

Figure 2 - schematically shows the database of Figure 1, taking into account different versions.

1 shows a database 1, for example a decentralized database of a navigation system, which is subdivided into a plurality of segments 2, 3, 5 and 7. Each of the segments 2, 3, 5 and 7 is represented by a square in the figure. Dependencies between individual segments 2 and 3 are indicated by arrows 4. The direction of the arrow reflects the direction of dependency. In the illustration of Figure 1 shows the arrowhead of the arrow 4 to the segment 3, of which the segment 2 is dependent. A dependency can be unidirectional or bidirectional. For the sake of clarity, all segments and all dependency arrows have been omitted.

If now a particular segment is updated, for example the segment 5, which is colored dark in the representation of FIG. 1, all segments of the navigation database must be identified by tracking the dependencies, of which the segment 5 to be updated depends directly and / or indirectly. The totality of all these segments is enclosed in the figure by a stronger boundary line 6. These wrapped segments will now also be updated.

An update of the segment 5 thus causes an update of a total of 22

Segments, so that the consistency of database 1 is maintained, taking dependencies into account. This creates the possibility of keeping the decentralized database 1 in a respectively more up-to-date state without a complete redesign of the database 1 being necessary.

Each segment, for example segment 7, whose newer version does not depend on any other segment or version, can be updated immediately. The update resolves any dependencies that exist on the new version. Segments that still have dependencies can already be loaded into the navigation system or into the decentralized database 1. However, they are not activated until all dependencies have been resolved, i. if a consistent state of database 1 has been restored. Furthermore, there is the possibility that already loaded and non-activated segments are used by an application without requiring a complete consistency of the database 1.

FIG. 2 shows in a three-dimensional representation a database 10 whose segments 11, 12, 13 and 14 are represented by cubes. In this representation, again, for reasons of clarity, the designation of all segments is dispensed with. The number of stacked cubes for a given segment reflects the number of versions. So is the segment 11 of this

Presentation is still present in its initial version, whereas the segment 12 is present in a fourth, modified version.

In this example, the segment 13 is for an update. Because of the dependencies of the segment 13 on other segments (not labeled in FIG. 2), it may be necessary for multiple versions of another segment, such as segment 14, to be updated so that the database 10 again translates into a consistent state becomes. Consecutive dependencies can cause problems because updating only a single segment can trigger an avalanche of updates to other segments. Such avalanche-like updates of a plurality of segments should be avoided as far as possible, since the time-consuming due to the large, to be transmitted Datenmangen from

User perspective are not desired. To avoid such avalanches, for example, it can already be considered when creating the database that unnecessary dependencies and redundancies are avoided as far as possible. Likewise, the division of the database into segments is preferably such that as few dependencies as possible exist between the individual segments.

In addition, care can be taken in the central database to ensure that large avalanches or dependency chains are detected and divided in good time. It is particularly useful to preserve the backward compatibility of the different versions of the individual segments.

Finally, in order to avoid a large avalanche in the decentralized database of the navigation system, a regular update of obsolete segments can be carried out as a preventative measure.

The update is made by transmitting the modified data in a suitable format. This format preferably contains only the differences between the older and the newer version of the changed segment. A transfer of the full data of the newer version is also possible. Significant here is the co-transfer of the dependencies of the newer version of the segment. The

The navigation system can use the version level of the individual segments of its database to determine whether the dependencies have already been resolved.

If the described steps are correctly applied, it is ensured that the decentralized database of the navigation system returns to a consistent state with each update. The amount of data is minimized by updating only those parts that are necessary for a consistent database.

Claims

claims

A method for updating a decentralized database of a navigation system, which is divided into several segments, by transmitting an updated segment from a segmented into a corresponding segments, central database and storing the segment in the decentralized database, characterized in that each segment dependencies on others Segments are assigned to the database and the dependencies are stored, so that when the segment is updated in the decentralized database, the segments on which the updated segment depends are also updated.

2. The method according to claim 1, characterized in that each segment is assigned a version identifier, which is stored in the database.

3. The method of claim 1 or 2, characterized in that the subdivision of the databases into segments is such that there are few dependencies of a segment of other segments.

4. The method according to any one of the preceding claims, characterized in that the updating of a segment in the central database is such that there are few dependencies of the segment of other segments.

5. The method according to any one of the preceding claims, characterized in that when updating a segment of the decentralized database with multi-level dependencies on other segments, the segments are updated successively, of which there is a multi-level dependence.

6. The method according to any one of the preceding claims, characterized in that after storing an updated segment in the decentralized database on the original segment is used until all segments have been updated that have a dependency of the updated segment.

7. The method according to any one of the preceding claims, characterized in that the transmission of the updated segment is performed wirelessly.

8. The method according to any one of claims 1 to 6, characterized in that the transfer of the updated segment is carried out via an exchangeable storage medium.