JP5675751B2 - Techniques for structuring navigation databases. - Google Patents

Description

  The present disclosure relates generally to navigation databases. In particular, this disclosure relates to techniques for structuring data in a navigation database.

  Modern navigation devices have a large amount of useful information regarding the route to be traveled, points of interest (POI) in the vicinity of the calculated route or in the vicinity of the device location, city, street or building names, traffic information, etc. Provide users with information and search options. Depending on the service that the navigation device will provide, the navigation device stores a large amount of navigation data in its database related to, for example, routing, map display, destination input, POI, and traffic information.

  When calculating a route based on user input and stored navigation data, a routing algorithm is used for route calculation and to keep the calculated route in main memory in the navigation device. It must be possible to address all possible route links in a navigation database. Therefore, an addressing scheme is required to gain access to specific navigation data from a large amount of stored navigation data. In general, the addressing scheme used is closely related to data structuring in the database.

  Modern navigation databases (e.g., navigation databases that comply with the Navigation Data Standard (NDS) storage format) use a global tiling scheme for navigation data addressing. The data structure and addressing scheme by NDS will be described in more detail with reference to FIGS.

  As illustrated in FIG. 1a, NDS provides 16 data levels for routing data (see the x-axis of FIG. 1a. The maximum data level is labeled level 0 and the lowest data level Is labeled level 15). A specific data level is assigned to routing data representing roads of a specific road function class (FC) (ie, FC1 to FC4 roads according to international classification standards for roads). In this context, NDS defines level 13 as the basic level that contains the routing data for roads FC0 to FC4. Thus, level 13 includes the entire road network, and hence the maximum road network resolution, from the main road to the local small road. As further illustrated in FIG. 1a, the road network resolution decreases continuously with decreasing level numbers. For example, data levels 10, 9, 8, and 6 are: FC0 to FC3 roads, FC0 to FC2 roads, FC0 to FC1 roads (corresponding to a road network consisting only of highways), and FC0 roads, respectively. Simply associated (see cross in FIG. 1a). Note that not all levels supported by NDS need to be available in the database for clarity. In the embodiment shown in FIG. 1a, only levels 6, 8, 9, 10, and 13 are associated with routing data.

Each NDS level has its own basic global tiling structure. A tile represents a rectangular specific region segment in a global coordinate system having a predetermined size. The tile structure for each level is derived from a global tiling scheme that is briefly discussed with reference to FIG. 2a. In the case of level 0, the ground surface covers the ground surface where one tile has a 0 ° longitude to + 180 ° line (tile 1 in FIG. 2), and one tile has a ground surface having a 0 ° longitude to −180 ° line. It is partitioned into two tiles covering (Tile 2 in FIG. 2). For subsequent level 1, each of these two tiles is divided into four tiles (shown for tile 2 only in FIG. 2). Each level 1 tile is again divided into 4 tiles with respect to level 2 (see shaded area), and so on. This hierarchical partitioning scheme continues through all levels up to the base level. More specifically, k = 0, 1, 2,. . . For level k which is 15, 2 ^{(2k + 1)} tiles are generated. Level 0 includes only two tiles to cover the entire surface, 2 ²⁷ tiles in order to structure the basal level 13 is provided, where each tile is approximately 2.5km × 2. It covers a specific area section of 5 km perpendicular.

  The NDS substructure of the NDS data level is exemplarily shown with respect to NDS level 9 of FIGS. 1b and 1c. FIG. 1 b shows four tiles 201, 203, 205, 207 covering a local specific area segment around the city “Munich” (see the oval shaded area). Further, the route links L1 to L8 represent several roads of the urban road network organized in the corresponding navigation database (the geographic region of FIG. 1c, ie the navigation database including Germany) as follows: The route links L2, L8 of tile 201 (see FIG. Lb) are stored in the tile block using the tile identifier T-ID 10111, and the route links L3, L4, and L5 are different from each other using the T-ID 10112. Stored in the tile block, the path link L1 is stored in the tile block using T-ID 10113, and the path links L6 and L7 are stored in the tile block using T-ID 10114. Note that it stores path links that span across tile boundaries in tiles with points). Similarly, basic map display data can be organized according to the underlying tile structure.

  NDS uses a global T-ID to address individual route links within a tile. The T-ID structure is used in NDS and is closely related to the encoding of the geographic coordinate system illustrated in FIGS. 2a and 2b.

Longitude coordinates and latitude coordinates (x coordinate and y coordinate) are represented by 32-bit and 31-bit integers, respectively. Thus, the NDS coordinate unit corresponds to 90/2 ³⁰ degrees of longitude and latitude (note the scaling factor of 2 ³⁰ ). The longitude and latitude integer values are further mapped to a single integer value using Morton mapping. The received Morton code represents that the received 63-bit integer forms 32-bit and 31-bit bit interleaving for longitude and latitude. On the other hand, the geographic coordinate system is partitioned into 2 ^{(2k + 1)} ) tiles for level k. The number of tiles for a given tile in level k can be inferred from the most significant 2k + 1 bits of the Morton code of coordinates present in that tile. Therefore, 2k + 1 bits are required to uniquely address a single tile in level k. As a result, at least 27 bits are required to address a level 13 tile.

  Additional addressing bits are required to further distinguish different tiles at different levels. As shown in FIG. 2b, each T-ID in the NDS consists of a level number and a tile number. For a navigation database having the levels and tile structures shown in FIGS. 1a-1c, a 32-bit ID is required to uniquely address each tile at any level. In addition, NDS suggests a 16-bit route link identifier (L-ID) to address the route link within each tile. In order to address all possible path links within each particular tile, an L-ID that consumes such memory is needed for tiles with high density path links for NDS and low density path links. (E.g., tiles covering large cities can contain multiple route links, whereas tiles covering mountains (e.g., Himalayas) or oceans). May include a small number of route links (eg, links representing ferry connections) or may be invalid). In short, to address a single route link in NDS, a 48-bit ID that consumes memory is required.

  It is an object to provide a more flexible database structure for efficiently addressing navigation data.

  According to one aspect, a method for structuring a navigation database is provided, the navigation database including route link data for at least a predetermined geographic region, the method comprising at least route link data associated with the predetermined geographic region. Organizing into one routing cluster, providing a cluster identifier to the at least one routing cluster, and storing at least one routing cluster in the navigation database along with the cluster identifier.

  A “predetermined geographic region” may correspond to any (individual) geographic region provided by a map supplier or navigation data supplier. A given geographic region may include smaller or larger regions that belong together geographically and / or politically. For example, it may mean a (federal) state, a country, a group of countries, and / or a single continent, or part thereof, such as North America, the Middle East, Southern Europe, Western Russia.

  The technique presented herein is a navigation data standard and / or map standard, or a general navigation data standard that can be claimed in the NDS context (described in the background section) or any other priority. And / or can be implemented in the context of a map standard. Thus, as NDS specific representations are used herein, it should be understood that those representations should not be construed as limited to NDS entities, but also encompass any other standard corresponding entities. Like.

  The method can further include providing at least one indicator structure for addressing at least one routing cluster in the navigation database. This at least one index structure can be provided as an index tree (optionally a B-tree, B + tree). The at least one indicator structure can include a cluster identifier. Via this at least one indicator structure, it is possible to access each routing cluster and / or route link of the database.

  A given geographic region can be further partitioned into tiles. A tile can represent a local specific area segment of a given geographic area. That is, a tile represents a local specific area segment of a predetermined size and a predetermined shape (eg, a rectangular area of 40 km × 40 km) designed to cover an entire predetermined geographical area without gaps. it can. The shape and size may depend on the tiling scheme used for segmentation. It is conceivable that a tiling scheme similar to NDS can be used.

  According to another understanding, the above NDS tiling scheme is used to segment a given geographic region (and to segment the navigation database of the navigation database associated with a given geographic region) Is possible. According to another understanding, in order to segment a given geographic region (and to segment navigation data in a navigation database associated with a given geographic region), a local tile identifier (local T-ID) ) Can be used.

  Route links associated with a given tile (and optionally other navigation data for the corresponding tile, such as basic map display data, destination input data, etc.) can be organized into at least one routing cluster. is there. That is, it is possible to provide a separate routing cluster for each tile covering a given geographic area.

  It is possible to organize at least one indicator structure associated with the routing cluster independent of the tile structure. That is, the index tree can be organized independently of the tiling structure in the database according to the routing cluster structure. The at least one indicator structure may include a cluster identifier (and optionally a path link identifier) (only) through which each cluster may be referenced. The index structure associated with the routing cluster may be independent of the possible index structure associated with the possible database tile structure.

  Thus, the index structure for addressing tiles can be independent of the index structure for addressing clusters (and route links). This can provide the database with two different addressing schemes for tile addressing and route link addressing (or other navigation data addressing).

  Any number of route links can be provided for each routing cluster. However, it is also possible to provide at least one route link for each routing cluster. A routing cluster with an invalid route link may not exist in the database. Each routing cluster can represent a database infrastructure that includes a free number of path links stored in a memory block. It is possible to organize the route links in each cluster into a data table (ie, a route link table). The data table may be a relation table. In contrast, there may be invalid tiles that do not have route links (and / or other navigation data). The size and number of tiles may depend solely on the tile link scheme applied to partition the underlying predetermined geographic area. Invalid tiles may not have a routing cluster.

  The number of path links per cluster may not exceed the (given) upper threshold. The upper threshold may take an arbitrary value. A small threshold can be used to keep the maximum possible number of path links per cluster (ie, cluster size) low.

  The number of routing clusters stored may be arbitrary. The number of clusters may depend on the amount of path link data in the database that will be organized. The number of clusters may depend on the total number or path link density for a given geographic region. Optionally, the number of clusters may be limited by an upper threshold. For tile partitioning, the number of routing clusters created per tile may depend on the path link density of the tile. That is, a tile with a large number of route links can accordingly include more routing clusters than a tile with a smaller number of route links. This allows the number of routing clusters to be individually adjusted for the number of route links in each tile.

  The number of routing clusters created can be proportional to the route link density. The generated cluster can be fully filled with path links (if the cluster size is limited by an upper threshold), and a new cluster can only be created when the generated class is fully filled. Conceivable. Alternatively, the generated cluster may simply be partially filled with route link data.

  The method includes reorganizing route link data organized into at least one routing cluster into at least one new routing cluster; and storing the at least one new routing cluster in a database; Can further be included. It is possible to further provide a cluster identifier for the new routing cluster. Reorganization of route link data can be performed during database updates. This reorganization may include organizing newly added route link data in the database during the update into a new routing cluster and / or into an existing routing cluster. This reorganizing step includes assigning an existing route link in an existing routing cluster to other existing cluster (s) or newly created cluster (s). It is also possible. At least one indicator structure can be appropriately adjusted for the new cluster configuration. Thus, this reorganization step can provide efficient path link organization in the database.

  Navigation data updates can include navigation data updates for the entire database, or navigation data updates (incremental updates) associated with one or more tiles. In the case of a “tiled database”, incremental updates can be performed based on a single tile update. In such a case, the route link data and routing cluster associated with the tile to be updated can be reorganized as described above.

  An identifier (cluster identifier) can be provided to at least one routing cluster. The identifier may be a fixed identifier. A fixed identifier may mean that the identifier remains unchanged during (incremental) database updates. It is possible to provide a new cluster identifier for the new cluster. The fixed identifier can ensure that the routing cluster and / or route link remains accessible after incremental database updates without requiring an update of the entire index structure.

  A link identifier can be provided for each route link in at least one routing cluster. The link identifier may be a variable link identifier. The link identifier may correspond to a link number indicating the order of route links in the link table. “Variable link identifier” may mean that the path link order may change with reorganization of the path links, as described above.

  The size of the route link identifier (ie, the bit size) can be determined by an upper threshold that indicates the maximum number of route links that can be organized in the cluster. The size of the route link identifier can determine the cluster size. In order to keep the route link addressing space small, the upper threshold, and thus the bit size of the route link identifier, can be kept small. In other words, the bit size of the route link identifier can take a predetermined (small) value. A low bit number path link identifier may be particularly advantageous within a "tiled database". Tile route links with only a few route links can be easily organized and addressed within one or a few addressable routing clusters, whereas many Route links can be organized and addressed simply by increasing the number of routing clusters per tile. Thus, the number of addressable routing clusters can be adjusted (dynamically) to the amount of route links (typically navigation data) that will be addressed.

  The bit size of the cluster identifier can be selected such that each generated routing cluster can be individually addressed via its assigned cluster identifier. The size of the cluster identifier can be adjusted with respect to the size of the route link identifier. If the bit size of the route link identifier is small, it is possible to increase the size of the cluster identifier (since more clusters have to be generated and addressed) and vice versa. Within an addressing scheme that provides a predetermined bit size for navigation data addressing, clusters from the difference between the predetermined bit size for navigation data addressing and the (selected) route link identifier size It is possible to obtain an identifier.

Each route link in the navigation database is accessible by addressing the corresponding cluster identifier, in which case the route link can be organized and the corresponding route link identifier. Routing clusters and / or path links within those clusters can be directly addressed by corresponding index structures. Therefore,
The routing data can be addressed independently of the fixed tile structure.

  The navigation database may further include at least one of map display data, destination input data, POI data, TMC data, and other extended navigation data. At least one of map display data, destination input data, POI data, TMC data, and other extended navigation data can be organized into a variable navigation data cluster. The extended navigation data may be, for example, orthoimage data, 3D data, audio data, full-text search data, digital terrain model data, and the like.

  Also provided is a computer program product with program code for performing the structured techniques described herein when the computer program product is executed on a computing device. For this purpose, the computer program product can be stored on a computer-readable recording medium (eg a memory card or a read-only memory).

  Also provided is a navigation database that includes at least route link data for a given geographic region, and for the given geographic region, the navigation database is a cluster for organizing route link data. It includes at least one routing cluster having an identifier.

  The navigation database may further include at least one indicator structure that includes cluster identifiers through which the at least one routing cluster and / or a routing route link within the at least one routing cluster is accessible. Is possible. The cluster identifier may be a fixed identifier that remains unchanged during (incremental) data update (s).

  The at least one routing cluster may be a flexible routing cluster that includes a variable number of route links. It is possible to organize the routing clusters within at least one routing cluster into a (relevant) route link table. It is possible to provide a route link identifier for each route link in the table. The route link identifier may correspond to a route link sequence number in the route link table. The path link order may be variable. That is, the path link order may be changed after (incremental) updates.

  The cluster size may be variable. The cluster size can be presented by the number of organized route links in the cluster. The maximum number of route links for each cluster may not exceed the upper threshold. The threshold can be selected such that path link identifiers that save corresponding memory can be used.

  It is possible to further partition the navigation database into tiles. Path links (and optionally other navigation data) associated with a single tile can be organized into clusters.

  Further provided is a navigation device that includes a navigation database according to the navigation database described above.

  Further details, advantages, and aspects of the present disclosure described herein are presented by the following drawings.

FIG. 3 schematically illustrates a navigation database structuring according to the prior art of the present invention. FIG. 3 schematically illustrates a navigation database structuring according to the prior art of the present invention. FIG. 3 schematically illustrates a navigation database structuring according to the prior art of the present invention. FIG. 3 schematically illustrates an addressing scheme according to the prior art of the present invention. FIG. 3 schematically illustrates an addressing scheme according to the prior art of the present invention. FIG. 2 schematically illustrates a navigation device according to an embodiment of the invention. FIG. 3 schematically illustrates a navigation database structuring according to an embodiment of the present invention. FIG. 3 schematically illustrates a navigation database structuring according to an embodiment of the present invention. 3 is a flow diagram of one method embodiment of the present invention. FIG. 3 schematically illustrates an addressing scheme according to an embodiment of the present invention. FIG. 3 schematically illustrates an addressing scheme according to an embodiment of the present invention.

  In the following description, for purposes of explanation and not limitation, certain details are set forth, such as particular navigation database structures and particular signaling scenarios, in order to provide a thorough understanding of the present disclosure. It will be apparent to those skilled in the art that the techniques presented herein may be implemented in other embodiments that depart from these specific details. For example, the methods, steps, and functions described herein can be easily implemented with the NDS database standard. One of ordinary skill in the art will readily recognize that the methods, steps, and functions described do not depend on the data level structure or the specific NDS tile design that depends on the level. The methods, steps, and functions described can also be applied in the context of other navigation data standards or map data standards.

  Those skilled in the art will understand that the methods, steps, and functions described herein may be performed using one or more software functions in conjunction with a programmed microprocessor or general purpose computer using individual hardware circuits. It will be further appreciated that implementation can be made using an application specific integrated circuit (ASIC), one or more digital signal processors (DSPs) and / or one or more field programmable gate arrays (FPGAs). The methods, steps, and functions disclosed herein may be implemented in a processor and in a memory coupled to the processor, the memory being discussed herein when executed by the processor. It will also be appreciated that one or more programs that control the processor to perform the steps are stored.

  The principles of certain exemplary embodiments of the present disclosure will be described in more detail with reference to FIGS.

  FIG. 3 shows an embodiment of the navigation device 10 in communication with the server 40. The navigation device 10 includes a navigation database 20 in which navigation data is structured according to the present disclosure. Database structuring and navigation data addressing are described in more detail below with reference to FIGS. The device 10 further includes a processing unit 12, a position sensor 14, an input / output (I / O) module 16, a main memory 18, and a communication module 22.

  The position sensor 14 is configured to receive position coordinates from a positioning system, such as a global positioning system (GPS), Galileo, or other system. The I / O module 16 represents the interface between the navigation device 10 on the one hand and the user on the other hand. Optical and / or acoustic means for output of calculated or retrieved navigation information (eg, light output and / or acoustic output of the calculated path) can be included. Main memory 18 is configured to buffer input data, data received on communication module 22, and / or navigation data loaded from database 20 for further processing by processing unit 12. The processing unit 12 receives data (for example, update data) received from the communication module and data to be transmitted via the communication module according to a program or (sub) routine stored in advance in the navigation device 10. (E.g., update request), configured to adjust and process data in position sensor 14, I / O module 16 and / or navigation database 20 (arrows in FIG. 3).

  The communication module 22 is configured to support wireless and / or wired communication with external devices such as the navigation server 40 and / or other navigation devices, user terminals (smartphones, PDAs, etc.). The communication module may include at least one wireless module (not shown in FIG. 3) for supporting at least one of UMTS and GPRS communications.

  Server 40 is configured to provide navigation data to the navigation device. The server includes a data repository 42, a processing unit 44, and a communication module 46.

  The database repository 42 is configured to store at least the latest version of navigation data for individual states, countries, continents, or other geographic regions. The repository can also store previous versions of navigation data. The navigation data may include at least one of routing data, map display data, destination input data, point of interest (POI) data, TMC data, and other expanded navigation data. Data can be stored in modular form. For example, at least one of routing data, destination input data, map display data, POI data, TMC data, and other extended navigation data can be stored in the form of data clusters, respectively. It is also possible that clusters can be associated with tiles to support incremental data updates in a tiled navigation database. In addition, the repository 42 may include version data that indicates navigation content versions. The navigation data may further include an indicator structure configured to access a single navigation data (ie, a route link cluster, a map display cluster, etc.).

  Server 40 can be further configured to perform navigation data structuring, as described in more detail below with respect to FIG. To this end, the server includes at least one program (stored on server memory (not shown in FIG. 3)) that controls the processing unit 44 to perform the structured steps discussed below. It is possible. The processing unit 44 can be further configured to control data traffic from the communication module 46 to the data repository 42, and vice versa. That is, the communication module can be configured to provide an update signal to the navigation device in response to the update request 30 received from the navigation device 10 via the communication module 46. In response to the update request, the processing unit 44 can provide an updated signal 32 that includes the updated navigation data, as well as the updated indicator data, structured according to the data structure of the navigation database 20. Update signal 32 may include navigation data in the form of data clusters. According to one embodiment, data clusters can be associated with individual tiles. The data signal can include a complete update of the navigation database 20 or an incremental update (ie, based on a single tile).

  With reference to FIGS. 4 to 6, the structuring and addressing of the navigation database 20 including route link data for at least a given geographic region will be described in more detail. As already outlined above, navigation data structuring may be performed by a navigation data supplier, such as server 40 of FIG. Navigation data structuring can also be performed by the navigation device 10 when the navigation device includes a corresponding pre-stored program.

  4a and 4b represent a schematic diagram of database structuring according to one embodiment of the present disclosure. For clarity, FIG. 4a represents only the route link data for the portion of the navigation database content associated with a larger predetermined area. For comparison, the same geographical area around Munich (and thus the same route link data) as in FIG. 2a is illustrated. The geographical area part is divided into tiles. In this context, it is possible to use a local tiling scheme or a global tiling scheme similar to the global tiling scheme used in NDS. However, the present disclosure does not rely on details regarding tiling of a given area represented by database content.

  Database structure and database structuring are described with reference to FIGS. 4b and 5.

  In a first step, the route link data for each tile of a given geographic region is organized into at least one routing cluster. In addition, a unique cluster identifier is provided for each routing cluster. For example, as shown in FIG. 4b, the path links L2b, L4, L3, L5, L6a of tile 203 have two independent path links with corresponding cluster identifiers (C-IDs) C-ID100 and C-ID101. Organized into clusters. It is clear that the C-ID values presented in FIG. 4b are merely exemplary values. The cluster identifier is usually given by a predetermined bit value and is discussed in more detail below. Similarly, path links L1b, L2, and L8 are organized into two independent clusters with C-IDs 102 and 103. Although not shown in FIG. 4b, route links associated with tiles 205, 207 are also organized into at least one routing cluster, respectively. As a result, the routing cluster represents the database substructure of the database 20 associated with the unique identifier. In a further step, the generated routing cluster and the corresponding provided cluster identifier are stored in the navigation database 20.

  The navigation database further includes at least one indicator structure that includes a cluster identifier. The at least one indicator structure is configured to provide (direct) access to routing clusters and / or route links of those routing clusters. For example, a B-tree can be used to refer to which leaf node a cluster and / or route link contains a routing cluster ID. The index structure can be stored separately from the routing data (and optionally from other navigation data).

  The navigation database 20 further includes basic map display data, destination input data, and POI data. In the exemplary embodiment, the basic map display data and destination input data are also organized into data clusters (for each tile). For example, tile 203 includes a map display cluster 305, a map display data, and a destination input data cluster that includes the next valid characteristic (NVC) data and designated object data, respectively. Accordingly, in FIG. 4a, as schematically illustrated by the segmented portions M1, M2, M3, M4, the routing data, the basic map display data, and the destination input data are at least separately for each tile. Organized into one data cluster.

  Of course, it is also possible to organize the route link data, destination input data, and / or basic map display data into clusters independent of the underlying tiling scheme. For example, several tile route links can be organized into a single routing cluster. In addition, POI data can be organized into POI clusters independent of the underlying tiling scheme. POI data associated with a given geographic region can be organized according to POI classes. For example, POI data indicative of restaurants can be organized into at least one POI cluster, and POI data indicative of pharmacies can be stored in at least one other POI cluster. The stored routing clusters (and other navigation data clusters) represent addressable data substructures that can be accessed directly (by the navigation application) via corresponding indicator structures.

  The underlying tile structure does not affect the navigation data addressing scheme and access. The tile structure can only be used to support incremental updates within the navigation database 20 (ie, replacement or update of a single tile-based navigation data).

  Referring to FIG. 6, the structure of the routing cluster and related addressing scheme for the route link will be discussed. In the following description, it will be assumed that the navigation database 20 has a tile structure to support incremental updates.

  FIG. 6 shows two exemplary tiles 301, 302 of the navigation database 20, as well as route links representing the road network associated with both tiles 301, 302. The route links in tile 301 are further organized into three routing clusters 61, 62, 63, which are associated with cluster identifiers (C-IDs) 110, 111, 112. Specifically, cluster 61 includes path links 1a and 1b, cluster 62 includes path links 2a and 2b, and cluster 63 includes path links 3a and 3b. In a similar manner, the cluster 64 of tiles 302 includes path links 4a-4e. Route links and / or routing clusters associated with both tiles 301, 302 are organized flexibly. While tile 302 includes only a few routing links that can be easily organized into a single routing cluster, tile 301 includes multiple routing links organized into three routing clusters. It is clear that this example is only used to explain the principle of flexible path link clustering according to the present disclosure. The number of clusters and the number of path links per cluster may vary from tile to tile and from cluster to cluster, respectively.

Organization can be performed according to a route link organization scheme. For example, route links representing roads or road parts that cross tile boundaries may be clustered into a single cluster. It may also be possible to store route links for a particular road function class in a cluster. Regardless of the organization details, a C-ID is provided for each route link cluster, and a route link identifier (L-ID) is further provided for each route link in the cluster. The L-ID may be a position number of a route link in the cluster, for example. Thus, each path link can be addressed by the C-ID of the cluster to which the path belongs and the corresponding L-ID. For example, a 24-bit C-ID can be used to address routing clusters, and an 8-bit L-ID can be used to address routing links within each cluster. Is possible. In such a case, 2 ²⁴ cluster identifier may be available a number high enough to address the cluster conceivable in the navigation database. Furthermore, it is possible to address 2 ⁸ route link within each routing cluster. In short, for route link addressing, only 24 bits + 8 bits are required instead of 48 bits as in the case of NDS using the inflexible global tiling scheme. Of course, the C-ID and / or L-ID can take other bit values depending on the amount of data in the database. However, since routing clusters are only generated for route link organization and the number of clusters scales in proportion to the cluster size (determined by the size of the provided L-ID), the number of clusters, and therefore The size of the cluster identifier can be kept small, and as a result, more efficient navigation data addressing is possible.

  FIG. 6b shows tiles 301 and 302 after an (incremental) update. As shown, new path links (1d, 5a-5c) have been added in both tiles 301,302. With a flexible clustering scheme, new roads can be organized into new clusters 65 (as shown with respect to tiles 302) or added to existing clusters (clusters 61, 63). Accordingly, the cluster 61 can be reorganized and a new L-ID can be provided to the route links 1a-1c of the cluster. Furthermore, it is possible to modify an existing routing cluster (if appropriate) by changing the road configuration. For example, during the reorganization process, cluster 62 has been deleted and existing route links 2a and 2b of cluster 62 have been added to existing clusters 61 and 63 (links 1c and 3c, respectively). Thus, for each tile, clusters are dynamically created, reorganized, and / or deleted depending on the path link density and / or path link attributes.

  The advantage of such flexible path links and cluster organization is that the number of clusters can be kept small. Therefore, the size of the cluster identifier for the inflexible addressing scheme can be made smaller. Thus, an addressing scheme is provided that uses less memory to address navigation data.

Claims (17)

A method of structuring a navigation database (20) using a computer , wherein the navigation database (20) includes route link data for at least a predetermined geographical area partitioned according to a tiling scheme , the method comprising:
Organizing route link data associated with the predetermined geographic region into at least one routing cluster;
Providing a cluster (61, 62, 63, 64) identifier to the at least one routing cluster;
Storing the at least one routing cluster (61, 62, 63, 64) in the navigation database (20) along with the cluster identifier ;
Providing at least one index structure including a cluster identifier addressing the at least one routing cluster (61, 62, 63, 64), wherein the at least one index structure associated with the routing cluster is a tiling scheme; And a method of causing a computer to perform the steps organized independently of the indicator structure associated with the tiles .   The predetermined geographic area is further partitioned into tiles (301, 302), and the organizing step for each tile is routing at least one route link data associated with the tile (301, 302). The method of claim 1, comprising organizing into clusters (61, 62, 63, 64).   The method according to claim 1, wherein at least one route link is provided for each routing cluster (61, 62, 63, 64).   The method of claim 1, wherein the number of route links organized in the at least one routing cluster (61, 62, 63, 64) does not exceed an upper threshold.   The method according to claim 1, wherein the number of routing clusters (61, 62, 63, 64) depends on the path link density. Reorganizing route link data organized into at least one routing cluster (61, 62, 63, 64) into at least one new routing cluster;
The method of claim 1, further comprising: storing the at least one new routing cluster in the database (20). The method of claim 6 , wherein a cluster identifier is provided for the at least one new routing cluster (61, 62, 63, 64). Wherein said at least one respective path link route link identifier routing cluster (61, 62, 63, 64) in is provided, the method according to any one of claims 1 to 7. Wherein the size of the route link identifier is determined by the upper threshold value that indicates the maximum number of organizing possible route links in the cluster, in combination with claim 4, method according to claim 8. The method of claim 1, wherein the navigation database further comprises at least one of map display data, destination input data, POI data, TMC (Traffic Message Channel) data, and other expanded navigation data. 11. The method of claim 10 , comprising at least one of map display data, destination input data, POI data, TMC ( Traffic Message Channel) data, and other extended navigation data, organized as a navigation data cluster. . The program which makes a computer perform the method of at least one of Claims 1-11. 12. A recording medium on which a program for causing a computer to execute the method according to claim 1 is recorded . A navigation database (20) comprising route link data relating to at least a predetermined geographical area , wherein at least one routing cluster is organized by the method according to any of claims 1 to 11. 20). The navigation database (20) according to claim 14 , wherein the at least one routing cluster (61, 62, 63, 64) is a flexible routing cluster comprising a variable number of route links. The navigation database (20) according to claim 14 , wherein the cluster identifier is a fixed identifier. A navigation device (10) comprising a navigation database (20) according to claims 14-16 .

Images