JP6129253B2 - 経路探索加速データとともに地図データを用いるナビゲーション装置 - Google Patents

Description

本発明は、地図データを生成するコンピュータを使用した方法及び関連するシステムに関するものである。特に、地図データを生成する方法は、所定のコスト関数に従って少なくとも２つの地点間の経路計画を容易にするために使用されるが、これに限定されない。本発明の実施形態は、経路計画で使用される時に経路を生成するのにかかる時間を短縮する探索加速データを生成する。

ｈｔｔｐ：／／ｒｏｕｔｅｓ．ｔｏｍｔｏｍ．ｃｏｍ／等のワールドワイドウェブ（ＷＷＷ）でアクセス可能なウェブサイトと共に経路計画装置（衛星ナビゲーション又はポータブルナビゲーション装置（ＰＮＤ）等と呼ばれることが多い。）は既知であり、ユーザが２地点間の経路を計画することを可能にする。そのような技術は、一般に電子経路計画又は単に経路計画と呼ばれてもよい。

そのような電子経路計画のための地図データは、Ｔｅｌｅ Ａｔｌａｓ ＮＶ等の地図専門メーカから得られる。そのような経路計画は、ＰＮＤで実行される場合、一般にＧＰＳシステムからの場所データを使用する。しかし、他の応用例は、ユーザが経路計画の目的で自身の場所又は考慮される他の地点を入力することを可能にしてもよい。

そのような地図データは、線、すなわちベクトル又は道路区分（例えば、道路の始点、終点、方向であり、道路全体は、それぞれが始点／終点方向パラメータにより一意に規定される数百もの区分から構成される）として記述される複数の道路（及び他のナビゲート可能なパスを含む。地図は、そのような道路ベクトル、各ベクトルと関連付けられたデータ（制限速度、移動方向等）＋地点情報（ＰＯＩ）＋道路名＋公園の境界や川の境界等の他の地理的特徴の集合であり、それらは全てベクトルに関して規定される。全ての地図の特徴（例えば、道路ベクトル、ＰＯＩ等）は、一般にＧＰＳ座標系に対応するか又は関連する座標系で規定され、ＧＰＳシステムを介して判定される装置の位置を地図に示された関連道路に配置することを可能にし、目的地までの最適な経路の計画を可能にする。

そのような地図データは広範囲にわたる可能性がある。地図が１２０，０００，０００個以上のベクトルを有するエリアを範囲に含むことが既知であり、そのような地図データの一例はヨーロッパ及びロシアのエリアを範囲に含む地図である。従って、そのような地図データを使用して経路を計画することは、複雑であり且つ時間もかかる。また、そのような経路計画は精度と時間との間にはトレードオフの関係があることが既知である。

経路指定が行われる速度を向上する時の概念を考慮した従来技術は特許文献１を含み、これは、西ヨーロッパの幹線道路ネットワーク（約４００，０００個のベクトルを有する）等の非常に小さい地図のサイズに適したＡ＊最良優先探索戦略に対する改善点について説明している。

米国特許第６，６３６，８００号明細書

本発明の第１の態様によると、それぞれが電子地図によってカバーされるエリアにおいてナビゲート可能な経路の区分を表す複数のナビゲート可能区分を含む電子地図にわたり経路を計画する際の速度を向上するように構成された探索加速データを含む地図データを作成する方法であって、
ａ）ナビゲート可能区分のコアネットワークを形成するナビゲート可能区分を除去することにより探索加速データの作成時に考慮されるナビゲート可能区分の数を減少するステップと、
ｂ）各ナビゲート可能区分が階層の各レベルの少なくとも１つの領域に分類されるように電子地図を複数の階層領域の集合に分割するステップと、
ｃ）ナビゲート可能区分が複数の領域の少なくとも１つまでの最小コストの経路の一部であるかを判定するためにコアネットワークの少なくともいくつかのナビゲート可能区分、一般には各ナビゲート可能区分と関連付けられた時変関数を使用し且つ当該判定を探索加速データに記録するステップと、
ｄ）地図データを生成するステップと、
を備える方法が提供される。

そのような方法は、探索加速データが従来の方法より速く算出されるのを可能にするため有利であると考えられる。従って、探索加速データは、その地図データを使用する経路計画がより速く実行されるのを可能にするため有利であると考えられる。

一般に、探索加速データは複数のビットベクトルとして算出される。本発明のいくつかの実施形態は、探索加速データのビットを介して、道路区分が起点ナビゲート可能区分から行先領域までの最小コストの経路の一部であるかを算出し、示してもよい。

一般に地図データ内の各ナビゲート可能区分又はノードが時変関数と関連付けられていることは、当業者には理解されるだろう。例えば時変関数は、異なる時間間隔でのナビゲート可能区分における平均速度を含んでもよい。例えば平均速度は、５分間隔等で指定されてもよい。

コアネットワークは、探索加速データが後で回復可能なナビゲート可能区分を除去することにより生成される。そのような方法は、探索加速データが電子地図内のほぼ全てのナビゲート可能区分に対して判定されるのを可能にし、それにより地図内のいずれのナビゲート可能区分からの経路計画も加速されるため有利である。

本発明のいくつかの実施形態は、探索加速データの作成前に電子地図からナビゲート可能区分を除去するために以下の技術のうちのいずれか１つ以上を利用してもよい。
・道路プロパティに関連する所定の基準を満たすこと。
・ある所定の基準に従って十分に小さく且つ更なる所定の基準を満たすナビゲート可能区分の集合を除去することによりネットワークの残りの部分から切断されるネットワークの部分を形成するナビゲート可能区分をネットワークから除去すること。
・所定の状況においてナビゲート可能区分の間の分岐点に存在するノードを他方のノードにまとめること。
・ノードが２つ以下のナビゲート可能区分を接続させる場合にそれらノードを他方のノードにまとめること。

そのような技術は、探索加速データの生成中に考慮される必要があるナビゲート可能区分の数を減少させ、それにより探索加速データを作成する際の速度が可能性として非常に向上されるため有利であると考えられる。

更に又はあるいは、本発明の実施形態は、探索加速データが作成された後に探索加速データを圧縮する以下の技術のうちのいずれか１つ以上を利用してもよい。
・探索加速データ中のビット対の相関性を計算する。
・可逆的に符号化するビット数を減少するために探索加速データ中のほぼ相関されたビットを結合させる。
・不可逆的圧縮を実行するために探索加速データ中の相関されたビットを結合させる。
・相関性に従って結合された探索加速データ中のビットを再順序付けする。
・探索加速データをハフマン符号化する。

いくつかの実施形態において、ほぼ相関されたビットは他方とほぼ相関されたものと考えられてもよい。すなわち、圧縮される探索加速データに小さな差分が存在する。探索加速データが結合される際の探索加速データの密接度は所定の基準に従って調整可能であってもよい。従って、そのような不可逆的結合を実現する本発明の実施形態は、探索加速データを使用して経路計画を実行するのに必要な処理を増加するが、探索加速データにより占有されるメモリフットプリントを更に減少する。

探索加速データを再順序付けする実施形態は、ハフマン圧縮が探索加速データを圧縮する際の効率が向上されるため有利である。

本発明の第２の態様によると、電子地図にわたり経路が計画される際の速度を向上するように構成された探索加速データを含む地図データを作成する方法であり、電子地図によってカバーされるエリアにおけるナビゲート可能な経路の区分を表す複数のナビゲート可能区分を含む電子地図を処理するために少なくとも１つの処理装置を使用することを備える方法であって、処理装置が、
ａ．ナビゲート可能区分のコアネットワークを形成するナビゲート可能区分を除去することにより探索加速データの作成時に考慮されるナビゲート可能区分の数を減少させるためにナビゲート可能区分を処理し、
ｂ．そのナビゲート可能区分が最小コストの経路の一部であるかを示す探索加速データをコアネットワークのナビゲート可能区分の少なくとも一部に対して、一般には各ナビゲート可能区分に対して生成するようにすることを備え、
ステップａ．は、
・道路プロパティに関連した所定の基準を満たすステップと、
・ある所定の基準に従って十分に小さく且つ更なる所定の基準を満たすナビゲート可能区分の集合を除去することによりネットワークの残りの部分から切断されるネットワークの部分を形成するナビゲート可能区分をネットワークから除去するステップと、
・所定の状況においてナビゲート可能区分の間の分岐点に存在するノードを他方のノードにまとめるステップと、
・ノードが２つ以下のナビゲート可能区分を接続させる場合にそれらノードを他方のノードにまとめるステップと、
のうちいずれか１つ以上を含む方法が提供される。

本発明の第３の態様によると、電子地図にわたり経路が計画される際の速度を向上するように構成された探索加速データを含む地図データを作成する方法であり、それぞれが電子地図によってカバーされるエリアにおいてナビゲート可能な経路の区分を表し且つナビゲート可能な経路のパラメータを表す関連付けられた少なくとも１つの属性を有する複数の関連付けられたノードを有する複数のナビゲート可能区分を含む電子地図を処理するために少なくとも１つの処理装置を使用することを備える方法であって、
ａ）少なくとも１つの属性を評価するステップと、
ｂ）ナビゲート可能区分と関連付けられたノードが電子地図の領域にわたり均衡されることを保証するためにステップａ．の評価を使用して各ナビゲート可能区分を階層の各レベルの少なくとも１つの領域に分類するように、電子地図を階層領域の集合に分割するステップと、
ｃ）地図データを生成するステップと、
を備える方法が提供される。

そのような方法の１つの利点は、各領域間で分布されるナビゲート可能区分の数を均衡させることを助長でき、その結果、探索加速データの有効性を向上することを助長できることである。

ステップａ）及びｂ）は、領域にわたるノードの均衡を測定する所定の基準が満たされるまで繰り返し実行されてもよい。例えば、所定の領域に存在してもよいナビゲート可能区分の数に対する上限閾値がそのような基準であってもよい。そのような尺度は、探索加速データがより迅速に算出されることを保証するのを助長できる。領域がそこに含まれたナビゲート可能区分に関して不均衡を含む場合、探索加速データが算出される際の速度は損なわれる可能性がある。

属性は以下のうちのいずれかを含んでもよい。

・ナビゲート可能区分の種類
・ナビゲート可能区分に沿う平均速度
・ナビゲート可能区分の長さ
・他のナビゲート可能区分に対するその区分の接続性
方法は、移動時間が所定の閾値より遅い電子地図の領域を判定するように構成されてもよく、それら領域内の別個のナビゲート可能区分を電子地図の他の領域から更に分離してもよい。

方法は、島の一部であるナビゲート可能区分を電子地図の他の領域から分離するように構成されてもよく、これはナビゲート可能区分に対する属性がフェリー路線であると判定することにより実行されてもよい。そのような島までの移動が電子地図の他の領域までの移動より遅く、そのような島を含むことにより探索加速データの有効性を損ない且つ／又は探索加速データの算出を遅くする可能性あるため、そのような方法は有利である。

本発明の第４の態様によると、電子地図にわたり経路を計画する際の速度を向上するように構成された探索加速データを含む地図データを作成する方法であり、それぞれが電子地図によってカバーされるエリアにおいてナビゲート可能な経路の区分を表す複数のナビゲート可能区分を含む電子地図を処理するために少なくとも１つの処理装置を使用することを備える方法であって、
ａ）より粗なレベルのいずれか１つの領域がより精細なレベルの複数の領域を含む場合に、各ナビゲート可能区分がより粗なレベル及びより精細なレベルの各々の少なくとも１つの領域に分類されるように、地図を少なくともより粗なレベル及び近傍のより精細なレベルに属する複数の階層領域に分割するステップと、
ｂ）行先領域を含むより粗なレベルの領域に近接する領域が可視エリアに追加されるべきかを評価し且つその評価が肯定的である場合にそれらの領域を追加することにより、行先領域を含むより粗なレベルの領域を少なくとも含む可視エリアの範囲を所定の行先領域に対して判定するステップと、
ｃ）少なくともいくつかのナビゲート可能区分に対して行先領域までの少なくとも１つの最小コストの経路に関する情報を算出するステップと、
ｄ）ナビゲート可能区分の処理が行先領域からナビゲート可能区分へ戻る逆探索の実行を含み、実質的に行先領域の可視エリアのナビゲート可能区分のみを含むステップと、
ｅ）地図データを生成するステップと、
を備える方法が提供される。

そのような方法の１つの利点は、近傍のエリアの使用により、探索加速データを生成するのに使用される探索空間が制限されるため、探索加速データが作成される際の速度が向上されることである。

本発明の第５の態様によると、電子地図にわたり経路が計画される際の速度を向上するように構成された探索加速データを含む地図データを作成する方法であり、それぞれが電子地図によってカバーされるエリアにおいてナビゲート可能経路の区分を表す複数のナビゲート可能区分を含む電子地図を処理するために少なくとも１つの処理装置を使用することを備える方法であって、
ａ）より粗なレベルのいずれか１つの領域がより精細なレベルの複数の領域を含む場合に、各ナビゲート可能区分がより粗なレベル及びより精細なレベルの各々の少なくとも１つの領域に分類されるように、地図を少なくともより粗なレベル及び近傍のより精細なレベルに属する複数の階層領域に分割するステップと、
ｂ）行先領域を含むより粗なレベルの領域に近接する領域が可視エリアに追加されるべきかを評価し且つその評価が肯定的である場合にそれらの領域を追加することにより、行先領域を含むより粗なレベルの領域を少なくとも含む可視エリアの範囲を所定の行先領域に対して判定するステップと、
ｃ）少なくともいくつかのナビゲート可能区分に対して行先領域までの少なくとも１つの最小コストの経路に関する情報を算出するステップと、
ｄ）可視エリアの少なくともいくつかのナビゲート可能区分に対して、一般には各ナビゲート可能区分に対して、行先領域までの少なくとも１つの最小コストの経路に関する情報を含むように探索加速データを構成するステップと、
ｅ）地図データを生成するステップと、
を備える方法が提供される。

そのような方法の１つの利点は、探索加速データを使用する経路計画が実行される際の速度が向上されることである。探索加速データは、行先領域までの道路標識であると考えられてもよい。これにより近傍エリア内に含まれた領域までの探索加速データを含む領域の数を増加することにより、行先領域までの「道路標識」を含む領域の数が増加される。従って、探索加速データを使用する経路計画の性能が向上されるが、探索加速データを生成する時間が増加する可能性がある。

領域が行先領域を含むより粗なレベルの領域に近接するかに関する評価は、所定の基準に基づいてもよい。この所定の基準は、グラフ理論距離、地理的距離、移動時間、燃料消費及び／又はＣＯ_２排出のうちのいずれか１つ又はそれらの組み合わせであってもよい。実際には、いくつかの実施形態において、行先領域を含むより粗なレベルの領域に隣接する領域はより近接すると判定されてもよい。

可視エリアに追加された領域は、より粗なレベルの１つ以上の領域及びより粗なレベルの１つ以上の領域の一部のうちの少なくとも一方を含んでもよい。

上記方法のいずれも、最小コストの経路に加えて少なくとも１つの追加の経路を探索加速データ内に含んでもよく、追加の経路は以下のいずれか１つ以上を反映してもよい。

・所定の出発地と目的地との間の異なる時間における種々の最小コストの経路
・種々の交通状況に対する所定の出発地と目的地との間の種々の最小コストの経路
・種々のコスト関数に従う所定の出発地と目的地との間の種々の最小コストの経路
・所定の道路ネットワークのあらゆる動的変化に対する所定の出発地と目的地との間の種々の最小コストの経路
・同一のコスト関数に従う所定の出発地と目的地との間の別の経路
・互いに類似する方向の種々の目的地
従って、探索加速データは、それぞれが一般に異なる基準に対して判断される複数の「最小コスト」の経路を含んでもよい。そのような方法の１つの利点は、最小コストのデータを使用する経路計画が種々の基準に対して最適な経路を生成できることである。

本発明の第６の態様によると、
ａ）地図を階層の１つ以上のレベルの複数の階層領域に分割するステップと、
ｂ）レベル階層の順序で階層の特定のレベルに属する領域の少なくとも一部を処理し、最も精細なレベルから最も粗なレベルに向かって動作し、それら領域の少なくとも一部に対してその領域に入るナビゲート可能区分及び／又はその領域から出るナビゲート可能区分を判定するステップと、
ｃ）地図内のナビゲート可能区分の少なくとも一部を処理してそのナビゲート可能区分から行先領域までの少なくとも１つの最小コストの経路を決定するステップと、
ｄ）ナビゲート可能区分の処理が行先領域からナビゲート可能区分に戻る逆探索の実行を含むステップと、
ｅ）結果として得られた探索グラフにおいて、次に精細なレベルの少なくとも１つの領域に対して、所定の領域からの最小コストの各パスが次に精細なレベルの領域の集合の少なくとも１つの領域を通過するようにその集合を特定し、結果として相関行列を得るステップと、
ｆ）結果として得られた探索グラフにおいて、自身とは異なる領域から更なる行先領域までのいずれのパスにも含まれず且つ従って「非通過区分」と考えられるナビゲート可能区分を特定し、後続ステップにおいて考慮されるナビゲート可能区分の数を減少するために後続ステップのためにそれら非通過区分を除去するステップと、
ｇ）探索加速データの作成が前の全てのステップにおいて除去された非通過区分に探索加速データを割り当てるために相関行列を使用することを含むステップと、
ｈ）地図データを生成するステップと、
が提供される。

本発明の上記態様のうちのいずれも、少なくとも一連の位置により構成されている測位データを生成するために１つ以上のナビゲーション装置を使用してもよい。その後、方法は、測位データを処理して時間と共に変動する速度プロファイルを生成してもよく、生成された速度プロファイルは、速度プロファイルを生成する測位データが発生したナビゲート可能区分と関連付けられる。

本発明の第７の態様によると、プロセッサを使用して電子地図にわたり経路を生成するように構成されたナビゲーション装置であって、プロセッサは、
電子地図にわたり経路探索を実行し、
電子地図のナビゲート可能区分を表す探索中に処理されたノードにおけるコストの算出において、それらノードに接続されたナビゲート可能区分が最小コストの経路の一部として印をつけられるかの評価を実行し、
そのようなナビゲート可能区分が存在する場合にそれらのナビゲート可能区分のみを探索するように構成されるナビゲーション装置が提供される。

探索は、Ａ＊探索又は本明細書で説明される他のあらゆる探索方法等の木探索を含んでもよい。他の実施形態において、探索は有向非周期グラフ探索を含んでもよい。

本発明の第８の態様によると、電子地図内のナビゲート可能区分を表すグラフ木のノードで実行されるコストの算出においてＡ＊探索を実行することと、ノードに接続されたナビゲート可能区分が最小コストの経路の一部として印をつけられるかを判定するために探索加速データを評価し且つそのようなナビゲート可能区分が存在する場合にそれらのナビゲート可能区分のみを探索することを含むこととを備える電子地図にわたり経路を生成する方法が提供される。

探索加速データは、再生成され且つ電子地図と共に又は電子地図と関連付けられて格納されるのが便利である。

そのような方法は、電子地図にわたり経路が生成される際の速度を非常に向上する可能性があるため有利であると考えられる。

本発明の第９の態様によると、地図データを解析するためにプロセッサを使用して目的地までの電子地図にわたる経路を生成するように構成されたナビゲーション装置であって、プロセッサは、
・地図データに保持された情報を使用して電子地図にわたり経路探索を実行し、
・電子地図のナビゲート可能区分を表す探索中に処理されたノードにおけるコストの算出において、それらノードに接続されたナビゲート可能区分が探索加速データ内で最小コストの経路の一部として印をつけられるかの評価を実行し、
・最小コストの経路に関する更なる情報を提供する追加の探索加速データがノードから目的地までに存在するかに関する指標を前記地図データが含み、
・そのような最小コストのデータが入手可能である場合にそのような探索加速データを有するそれらのナビゲート可能区分のみを探索するように構成されるナビゲーション装置が提供される。

地図データに提供された指標がナビゲーション装置により探索される経路の数を制限する情報を提供するのを助長するため、そのような装置は有利である。

指標は、目的地の可視エリアを含んでもよく、ナビゲーション装置は、最小コストの経路に関する更なる情報が可視領域内にある場合にそれを利用するように構成されてもよい。

本発明の更なる態様によると、上記方法のいずれかを実行するように構成された演算装置が提供されてもよい。

本発明の更なる態様によると、少なくとも１つの機械に読み込まれた時に上記方法のいずれかを提供する命令を含む機械可読媒体が提供される。

本発明の更なる態様によると、命令が読み込まれる各機械に本発明の上記態様のいずれかの演算装置として機能させる命令を含む機械可読媒体が提供される。

方法が並行に実行される実施形態において、命令は複数の機械に読み込まれてもよい。

本発明の上記態様の特徴のうちの多くは、必要な変更を加えて本発明の他の態様に適用されてもよいことが当業者には理解されるだろう。

本発明の上記態様のいずれかにおいて、機械可読媒体は、フロッピーディスク、ＣＤ ＲＯＭ、ＤＶＤ ＲＯＭ／ＲＡＭ（−Ｒ／−ＲＷ及び＋Ｒ／＋ＲＷを含む）、ハードドライブ、メモリ（ＵＳＢメモリキー、ＳＤカード、Ｍｅｍｏｒｙｓｔｉｃｋ（登録商標）又はコンパクトフラッシュカード等）、テープ、他のあらゆる形態の光磁気記憶装置、送信信号（インターネットダウンロード、ＦＴＰ転送等を含む）、ワイヤ又は他のあらゆる適切な媒体のうちのいずれを含んでもよい。

本明細書で説明される方法及び／又は装置の多くは、ソフトウェア、ハードウェア又はファームウェアで実行されてもよいことが当業者には理解されるだろう。実際には、それら３つの組み合わせが少なくとも一部の概念に適切であってもよい。

本発明の上記態様のいずれかにおける地図データの生成の参照は、実際にはオプションのステップであってもよく、そのようなステップが方法に対するオプションであってもよいことは当業者には理解されるだろう。

本発明の更なる１つの態様によると、探索加速データを生成するためにナビゲート可能区分を前処理することを含む探索加速データを生成する方法が提供される。

測位データから地図データを生成する方法であり、電子地図によってカバーされるエリアのナビゲート可能経路の区分を表す複数のナビゲート可能区分を含む電子地図を処理するために少なくとも１つの処理装置を使用することを備える方法であって、
１．少なくとも一連の位置により構成されている測位データを生成するために１つ以上のナビゲーション装置を使用するステップと、
２．測位データを処理して時間と共に変動する速度プロファイルを生成することであり、生成された速度プロファイルが速度プロファイルを生成する測位データが発生したナビゲート可能区分と関連付けられるステップと、
３．ナビゲート可能区分の少なくとも一部に対して、所定の基準に対する時変関数を使用して、ナビゲート可能区分が各領域まで移動するための所定の基準に対するコストを最小限にするために経路の一部を含むかを少なくとも１つの領域、一般には各領域に対して示す探索加速データを生成するステップと、
４．地図データを生成するステップと、
を備える方法が提供される。

本発明の態様において、ノード、線又は道路に対する参照はナビゲート可能区分に対する参照として利用されてもよく、ナビゲート可能区分に対する参照はノード、線又は道路に対する参照として利用されてもよい。必要な変更を行う方法は、当業者には理解されるだろう。

図１は、ナビゲーション装置により使用可能な全地球測位システム（ＧＰＳ）の例示的な一部を示す概略図である。 図１ａは、ポータブルナビゲーション装置（ＰＮＤ）又は他のあらゆる適切なナビゲーション装置の電子構成要素を示す概略図である。 図１ｂは、ナビゲーション装置を搭載及び／又はドッキングするための構成を示す概略図である。 図１ｃは、図１ａのナビゲーション装置により採用されたアーキテクチャスタックの概略表現を示す図である。 図２は、本発明の実施形態により生成されるような地図の一例の一部を示す図である。 図３は、経路指定に使用されたノードが示される図２の地図を示す図である。 図４は、処理後の図２の地図を示す図である。 図５は、いくつかの実施形態においてノードが図３の地図に割り当てられる方法の一例を示す図である。 図６は、地図が複数のネストされた領域に区分される方法の一例を示す図である。 図６ａは、図６の区分の高度化を示す図である。 図７は、本発明の実施形態により利用されたビットベクトルの集合の一例を示す図である。 図７ａは、時間プロファイル化された情報がネットワークのダイクストラ探索中に利用される方法を示す図である。 図８は、本発明の一実施形態のファイルに対するファイル形式の一例を示す図である。 図９は、図８の領域再マッピングテーブル及び領域ＩＤリストが符号化される方法の一実施形態を示す図である。 図１０は、レベル０領域に対するファイル形式の一例を示す図である。 図１１は、レベル０以外のレベル領域に対するファイル形式の一例を示す図である。 図１２は、符号化方式内のビットの結合を例示的に示す図である。 、 図１３は、ビットを結合する効果を例示的に示す図である。 図１４は、ビットを結合する効果を例示的に更に示す図である。 図１５は、従来の経路指定技術を使用して考えられた経路を強調表示する地図を示す図である。 図１６は、本発明の実施形態により考えられた経路を強調表示する地図を示す図である。 図１７は、Ａ＊探索方法（従来技術）の一例を示す図である。 図１８は、本発明の少なくともいくつかの実施形態により使用された図１７に対する変形例を示す図である。 図１９は、方法のステップを概略的に示すフローチャートである。

以下の説明において、同一の図中符号は同様の部分を特定するために使用される。種々の実施形態の説明において、一連の１９ｘｘの図中符号を有する図１９のフローチャートを参照する。

図１は、連続した位置、速度、時間及びいくつかの例においては無数のユーザに対する方向情報を判定するために利用されてもよい衛星無線を使用したナビゲーションシステムである全地球測位システム（ＧＰＳ）を概略的に示す。以前はＮＡＶＳＴＡＲとして既知であったＧＰＳは、極めて正確な軌道で地球を周回する複数の衛星を含む。これらの正確な軌道に基づいて、ＧＰＳ衛星は自身の場所をＧＰＳデータとしていかなる数の受信ユニットにも中継できる。しかし、ＧＬＯＳＮＡＳＳ、欧州のＧａｌｉｌｅｏ測位システム、ＣＯＭＰＡＳＳ測位システム又はＩＲＮＳＳ（Ｉｎｄｉａｎ Ｒｅｇｉｏｎａｌ Ｎａｖｉｇａｔｉｏｎ Ｓａｔｅｌｌｉｔｅ Ｓｙｓｔｅｍ）等の全地球測位システムが使用可能であることが理解されるだろう。

特にＧＰＳデータを受信できる装置がＧＰＳ衛星信号に対する無線周波数の走査を開始する場合、ＧＰＳシステムは実現される。ＧＰＳ衛星から無線信号を受信すると、装置は、複数の異なる従来の方法のうちの１つを使用してその衛星の正確な場所を判定する。殆どの例において、装置は、少なくとも３つの異なる衛星信号を取得するまで信号の走査を継続する（尚、位置を判定する標準的な方法ではないが、２つの信号だけでも他の三角測量技術を使用して位置を判定できる）。幾何学的三角測量を実現すると、受信機は、３つの既知の位置を利用して、衛星に対する自身の２次元位置を判定する。これは、既知の方法で行われる。更に、第４の衛星信号を取得することにより、受信装置は、同一の幾何学計算によって既知の方法でその３次元位置を算出できる。位置及び速度データは、無数のユーザにより連続的にリアルタイムで更新可能である。

図１に示すように、ＧＰＳシステム１００は、地球１０４の周囲の軌道上にある複数の衛星１０２を含む。ＧＰＳ受信機１０６は、多くの衛星１０２からスペクトル拡散ＧＰＳ衛星データ信号１０８としてＧＰＳデータを受信する。スペクトル拡散データ信号１０８は、各衛星１０２から連続的に送信され、送信された各スペクトル拡散データ信号１０８は、データストリームの発信元である特定の衛星１０２を特定する情報を含むデータストリームを含む。一般にＧＰＳ受信機１０６は、２次元位置を算出できるように少なくとも３つの衛星１０２からスペクトル拡散データ信号１０８を必要とする。第４のスペクトル拡散データ信号を受信することにより、ＧＰＳ受信機１０６は既知の技術を使用して３次元位置を算出できる。

従って、ＧＰＳシステムにより、ＧＰＳ受信機１０６を有する装置のユーザは数メートル内で地球上の自身の位置を判定できる。この情報を使用するために、ユーザの位置を示すことを可能にする電子地図に依存することが一般的になっている。そのような地図は、ＴｅｌｅＡｔｌａｓ（ｈｔｔｐ：／／ｗｗｗ．ｔｅｌｅａｔｌａｓ．ｃｏｍ）等のプロバイダにより例示される。

そのような電子地図は、ＧＰＳシステム（又は他の手段）を使用してユーザの位置を示すことを可能にするだけでなく、ユーザが移動等（経路指定の目的）のための経路を計画することを可能にする。この経路計画を行うために、電子地図はナビゲーション装置により処理され、これは一般的な演算装置により提供されてもよい。

ナビゲーション装置の特定の例は、ポータブルナビゲーション装置（ＰＮＤ）と呼ぶ便利な衛星ナビゲーション装置（衛星ナビゲーション）を含む。しかし、本発明の教示はＰＮＤに限定されず、一般に経路計画及びナビゲーション機能性を提供するために電子地図を処理するように構成されるいかなる種類の処理装置にも例外なく適用可能である。従って、本出願において、ナビゲーション装置は、ＰＮＤ、自動車等の乗り物、例えば経路計画及びナビゲーションソフトウェアを実行するポータブルパーソナルコンピュータ（ＰＣ）、移動電話又はパーソナルデジタルアシスタント（ＰＤＡ）又はサーバであるポータブル計算リソース、あるいはネットワークを介してそのような機能性を提供する他の演算装置として実装されるか否かにかかわらず、どんな種類の経路計画及びナビゲーション装置も含むことを意図する（それらに限定されない）。

ＰＮＤの形態のそのようなナビゲーション装置の一例を図１ａに示す。尚、ナビゲーション装置２００のブロック図は、ナビゲーション装置の全ての構成要素を含んでいるわけではなく、多くの構成要素の例を示しているにすぎない。ナビゲーション装置２００は筐体（不図示）内に配置される。ナビゲーション装置２００は、例えば上述したプロセッサ２０２を含む処理回路網を含む。プロセッサ２０２は、入力装置２０４及び例えば表示画面２０６である表示装置に結合される。ここで、入力装置２０４は単数で示されるが、入力装置２０４がキーボード装置、音声入力装置、タッチパネル及び／又は情報を入力するのに利用される他のあらゆる既知の入力装置を含む任意の数の入力装置を表すことは、当業者には理解されるべきである。同様に、表示画面２０６は、例えば液晶ディスプレイ（ＬＣＤ）等のあらゆる種類の表示画面を含むことができる。

ナビゲーション装置２００において、プロセッサ２０２は、接続２１０を介して入力装置２０４に動作可能に接続されて入力装置２０４から入力情報を受信でき、各出力接続２１２を介して表示画面２０６及び出力装置２０８のうち少なくとも一方に動作可能に接続されて情報を出力する。ナビゲーション装置２００は、例えば可聴出力装置（例えば、スピーカ）である出力装置２０８を含んでもよい。出力装置２０８がナビゲーション装置２００のユーザに対して可聴情報を生成できるため、入力装置２０４は入力音声コマンドを受信するためのマイク及びソフトウェアを含むことができると同様に理解されるべきである。また、ナビゲーション装置２００は、例えばオーディオ入出力装置等のあらゆる追加の入力装置２０４及び／又はあらゆる追加の出力装置を更に含むことができる。

プロセッサ２０２は、接続２１６を介してメモリ２１４に動作可能に接続され、更に接続２２０を介して入出力（Ｉ／Ｏ）ポート２１８に対して情報を送受信するように更に構成される。Ｉ／Ｏポート２１８は、ナビゲーション装置２００の外部のＩ／Ｏ装置２２２に接続可能である。外部Ｉ／Ｏ装置２２２は、例えばイヤホン等の外部リスニングデバイスを含んでもよいがこれに限定されない。Ｉ／Ｏ装置２２２への接続は、イヤホン又はヘッドホンへの接続及び／又は例えば移動電話への接続のためのハンズフリー動作及び／又は音声起動動作を行うカーステレオユニット等の他のあらゆる外部装置への有線又は無線接続であってもよい。ここで、例えばナビゲーション装置２００とインターネット又は他のあらゆるネットワークとの間のデータ接続を確立するため、並びに／あるいは例えばインターネット又は他の何らかのネットワークを介してサーバとの接続を確立するために移動電話接続が使用される。

ナビゲーション装置２００のメモリ２１４は、不揮発性メモリ（例えば、プログラムコードを格納する）の一部及び揮発性メモリ（例えば、プログラムコードが実行された時にデータを格納する）の一部を含む。ナビゲーション装置は、接続２３０を介してプロセッサ２０２と通信するポート２２８を更に含み、取外し可能なメモリカード（一般に、カードと呼ばれる）が装置２００に追加されるのを可能にする。説明している実施形態において、ポートは、ＳＤ（セキュアデジタル）カードが追加されるのを可能にするように構成される。他の実施形態において、ポートは他の形態のメモリが接続されるのを可能にしてもよい（コンパクトフラッシュ（ＣＦ）カード、Ｍｅｍｏｒｙ Ｓｔｉｃｋ（登録商標）、ｘＤメモリカード、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）フラッシュドライブ、ＭＭＣ（マルチメディア）カード、ＳｍａｒｔＭｅｄｉａカード又はマイクロドライブ等）。

図１ａは、接続２２６を介するプロセッサ２０２とアンテナ／受信機２２４との間の動作可能接続を更に示す。ここで、アンテナ／受信機２２４は、例えばＧＰＳアンテナ／受信機であってもよいため、図１のＧＰＳ受信機１０６として機能する。図中符号２２４で指定されたアンテナ及び受信機は図示するために概略的に組み合わされるが、アンテナ及び受信機は別個に配置された構成要素であってもよく、アンテナは例えばＧＰＳパッチアンテナ又はヘリカルアンテナであってもよいことが理解されるべきである。

更に、図３のポータブル又はハンドヘルドナビゲーション装置２００は、例えば自転車、オートバイ、自動車又は船等の乗り物に既知の方法で接続又は「ドッキング」される。そのようなナビゲーション装置２００は、ポータブル又はハンドヘルドナビゲーションに使用するためにドッキングされた場所から取り外し可能である。実際には、他の実施形態において、装置２００はユーザのナビゲーションを可能にするためにハンドヘルド装置となるように構成されてもよい。

図１ｂを参照すると、ナビゲーション装置２００は、内蔵された入力及び表示装置２０６並びに図３の他の構成要素（内部ＧＰＳ受信機２２４、プロセッサ２０２、電源（不図示）、メモリシステム２１４等を含むがこれらに限定されない）を含むユニットであってもよい。

ナビゲーション装置２００は、吸着カップ２５４を使用して車両のダッシュボード／窓等に固定されてもよいアーム２５２上に位置してもよい。このアーム２５２は、ナビゲーション装置２００がドッキングされるドッキングステーションの一例である。ナビゲーション装置２００は、例えばナビゲーション装置２００をアーム２５２に嵌合接続することによりドッキングステーションのアーム２５２にドッキングされるか又は接続される。ナビゲーション装置２００は、アーム２５２を中心に回転可能であってもよい。ナビゲーション装置２００とドッキングステーションとの間の接続を解放するために、例えばナビゲーション装置２００上のボタン（不図示）が押下されてもよい。ドッキングステーションに対してナビゲーション装置２００を結合及び分離する同様に適切な他の構成は当業者には既知である。

図１ｃを参照すると、プロセッサ２０２及びメモリ２１４は協働して、ナビゲーション装置２００の機能ハードウェア構成要素２８０と装置により実行されるソフトウェアとの間のインタフェースとして機能するＢＩＯＳ（基本入出力システム）２８２をサポートする。プロセッサ２０２は、メモリ２１４からオペレーティングシステム２８４をロードし、アプリケーションソフトウェア２８６（説明された経路計画及びナビゲーション機能性の一部又は全てを実現する）が実行可能な環境を提供する。アプリケーションソフトウェア２８６は、例えば地図閲覧、経路計画、ナビゲーション機能及び関連する他のあらゆる機能であるナビゲーション装置の中核機能をサポートするグラフィカルユーザインタフェース（ＧＵＩ）を含む動作環境を提供する。この点に関して、アプリケーションソフトウェア２８６の一部はビュー生成モジュール２８８を含む。

説明している実施形態において、ナビゲーション装置のプロセッサ２０２は、アンテナ２２４により受信されたＧＰＳデータを受信し且つＧＰＳデータが受信された時のタイムスタンプと共にＧＰＳデータを時々格納してナビゲーション装置の一連の位置を構築するようにプログラムされる。そのように格納された各データレコードはＧＰＳのフィックス解と考えられてもよい。すなわち、ナビゲーション装置の場所のフィックス解であり、緯度、経度、タイムスタンプ及び精度レポートを含む。この一連の位置は測位データと考えられてもよい。

一実施形態において、データは、ほぼ周期的に、例えば５秒毎に格納される。他の周期も可能であり、データ解像度と記憶容量との間で均衡がとられることが当業者には理解されるだろう。すなわち、データの解像度がより多くのサンプルをとることにより向上されると、データを保持するのに必要なメモリはより多くなる。しかし、他の実施形態において、解像度は、ほぼ１秒毎、１０秒毎、１５秒毎、２０秒毎、３０秒毎、４５秒毎、１分毎、２．５分毎（又は実際にはそれらの周期の間のあらゆる周期）であってもよい。従って、装置のメモリ内では、複数の時点における装置２００の位置のレコードが構築される。

いくつかの実施形態において、取り込まれたデータの品質は、周期が長くなるほど低下し、劣化の程度はナビゲーション装置２００の移動していた速度に少なくとも部分的に依存するが、約１５秒の周期が適切な上限を与える可能性があることが分かるだろう。

更にプロセッサ２０２は、装置２００の位置のレコード（すなわち、ＧＰＳデータ及びタイムスタンプ）をサーバに対して時々アップロードするように構成される。ナビゲーション装置２００が自身をサーバに接続する永続的な又は少なくとも一般的に存在する通信チャネルを有するいくつかの実施形態において、データのアップロードは、２４時間に１回等の周期的に行われる。他の周期も可能であり、ほぼ１５分毎、３０分毎、１時間毎、２時間毎、５時間毎、１２時間毎、２日毎、１週間毎又はそれらの期間の間のあらゆる時間のいずれであってもよいことが当業者には理解されるだろう。実際には、そのような実施形態において、プロセッサ２０２は、ほぼリアルタイムに位置のレコードをアップロードするように構成されてもよい。しかし、これは、データが実際には送信の間に相対的に短い周期で時々送信されることを必然的に意味するため、より正確には擬似リアルタイムであると考えられる。そのような擬似リアルタイムの実施形態において、ナビゲーション装置は、メモリ２１４内及び／又はポート２２８に挿入されたカードにＧＰＳのフィックス解をバッファリングし且つ所定の数だけ格納された時にそれらを送信するように構成されてもよい。この所定の数は、２０、３６、１００、２００又はそれらの間のどのような数であってもよい。所定の数は、メモリ２１４／ポート２２８内のカードのサイズにより部分的に管理されることが当業者には理解されるだろう。

一般的に存在する通信チャネルを有さない他の実施形態において、プロセッサは、通信チャネルが作成される時にレコードをサーバにアップロードするように構成されてもよい。例えばこれは、ナビゲーション装置２００がユーザのコンピュータに接続される時であってもよい。ここでも、そのような実施形態において、ナビゲーション装置は、メモリ２１４内又はポート２２８に挿入されたカードにＧＰＳのフィックス解をバッファリングするように構成されてもよい。メモリ２１４又はポート２２８に挿入されたカードがＧＰＳのフィックス解で一杯になった場合、ナビゲーション装置は、最も古いＧＰＳのフィックス解を削除するように構成されてもよいため、先入れ先出し（ＦＩＦＯ）バッファと考えられてもよい。

説明している実施形態において、位置のレコードは、それぞれが２４時間以内のナビゲーション装置２００の動きを表す１つ以上のトレースを含む。２４時間の各期間はカレンダーの日付と一致するように構成されるが、他の実施形態においては一致する必要はない。

サーバは、装置の位置のレコードを受信し且つ処理するために大容量データ記憶装置内にそのレコードを格納するように構成される。従って、時間の経過と共に、大容量データ記憶装置はデータをアップロードした複数のナビゲーション装置２００の位置のレコードを蓄積する。一般に、サーバは複数のナビゲーション装置２００の位置を収集する。

サーバは、各装置の収集した位置から速度データを生成するように構成されてもよい。この速度データは、地図のナビゲート可能区分に沿う平均速度が計時変化する様子を示す時間で変動する速度プロファイルを含んでもよい。

図２は、説明している実施形態において、この例ではインターネットであるネットワークを介してナビゲーション装置において閲覧される電子地図の一例を示す。本明細書で説明している実施形態のいずれかにおける第１のステップは、そのような電子地図１９００の生成である。地図は、ｈｔｔｐ：／／ｒｏｕｔｅｓ．ｔｏｍｔｏｍ．ｃｏｍ／で閲覧されてもよい。

図２の電子地図が行われる経路指定の目的で使用されるために、電子地図は一般に電子地図のユーザには見えない一連のノードを有する。従って、ノード等は一般に地図データと呼ばれてもよい。しかし、理解しやすいように、ノード３００の一部が図３に示される。これらのノードは、交差点、道路の最終領域等に提供され、経路指定の目的で使用される。ユーザが自身のナビゲーション装置に２つ以上の地点間の経路を計画するように要求する場合、一般にナビゲーション装置は地図の関連するノード間の経路を計画する（ノードのグループまでの経路を計画することも可能であるが）。従って、地図データは、ナビゲーション装置のユーザにより設定された少なくとも１つの基準に従って経路を生成するために使用される。

電子地図は、道路区分の形状、建物への入り口の場所等を提供する更なるノードを更に含んでもよい。

従って、各ノード３００は、ユーザが移動してもよいそのノードから出る道路区分を少なくとも１つ、一般には複数有する。例えばノード３０２は、４つのそのような道路区分３０４ａ、３０４ｂ、３０４ｃ、３０４ｄを有する。各道路区分は、歩道、自転車道路、運河、鉄道線路又は軌道等の道路ではない経路を参照する可能性があるため、ナビゲート可能区分と考えられてもよい。しかし、便宜上、道路区分を参照する。従って、図２に示すような地図は、それぞれが地図によってカバーされるエリアのナビゲート可能な経路の一部を表す複数の道路区分をユーザに対して示す。

経路計画方法（ダイクストラ法、Ａ＊方法又はＭｏｏｒｅ／Ｐａｐｅ方法）は既知である。しかし、これらは、算出時間に関して非常に遅い。そのような経路計画の速度を向上する方法の一例は、米国特許第６，６３６，８００号公報で示され、その教示は参考として本明細書に取り入れられている。

本明細書で説明している実施形態は、前処理ステップにおいて、電子地図を処理する時に経路の生成を加速するために使用される探索加速データを含むいわゆる副ファイルを生成してもよい。この情報は、ビットベクトルと呼ばれてもよい２値データ、すなわち０及び１の列（又はその圧縮符号化）として保持されてもよい。従って、副ファイルは地図データと考えられてもよいが、電子地図（例えば、図２に示すような）が供給されてもされなくてもよい。従って、本発明のいくつかの実施形態は、副ファイルから分離可能な地図として地図データを提供してもよいが、本発明の他の実施形態は、地図及び副ファイルデータを組み合わせてもよい。

しかし、副ファイルが使用される場合、副ファイルが生成された電子地図と共に使用されるべきであることは、当業者には理解されるだろう。これが行われない場合、不正確な経路（例えば、ユーザにより設定されたコスト関数を最小限にしない経路）が取得されると考えられる。

また、本発明の種々の実施形態は、探索加速データ（本実施形態においては、一連のビットベクトルであり、便宜上、以下においてビットベクトルと呼ぶ）の生成のための種々のパラメータを指定してもよい。従って、生成された地図データを使用する次の経路計画がビットベクトルを作成するのに使用されたパラメータとは異なるパラメータを使用する場合、ビットベクトルはその経路計画に有用ではないと考えられる。

例えばいくつかの実施形態は、自動車による地図上の移動に対してビットベクトルを生成してもよい。次の経路計画が徒歩のための経路を生成するために使用される場合、自動車用のビットベクトルは有用ではないと考えられる。別の例において、いくつかの実施形態は、ユーザが高速自動車道路、有料道路等を喜んで移動すると仮定してビットベクトルを生成してもよい。次の経路計画において、ユーザが高速自動車道路、有料道路等を利用しない経路を要求する場合、ビットベクトルは有用ではないと考えられる。

本発明のいくつかの実施形態は、それぞれが所定の基準の異なる集合を有する複数のビットベクトルの集合を生成してもよい。例えば本発明の実施形態は、２つ、３つ、４つ、５つ、６つ、１０個、１５個又はそれ以上のビットベクトルの集合のいずれを生成してもよい。

従って、いくつかの実施形態において、副ファイルを生成するために、地図前処理ステップにおいてノードは複数の領域に分割されるため、あらゆる地図は既知の数の領域、例えばＮ個の領域に分割される。これについては、図５を参照して以下に更に詳細に説明する。この前処理は、経路計画方法の速度を向上するために地図と共に利用可能なデータを生成する。

再帰的であってもよい反復処理において、地図データ内のノードは階層領域の集合に分割される。図５の点線で示すような領域が作成され、各領域は複数のノードを含む。方法は、より多くの又はより少ないノード（及び従ってナビゲート可能区分）を含むようにそれらの境界を移動し、それらの境界の移動の際にノードと関連付けられた道路区分のパラメータを考慮する。方法のいくつかの実施形態は、いずれか１つの領域内に含まれるノード数に関する上限を設定することを目的とする。方法は、ナビゲート可能区分の予想された移動時間に従って領域のメンバーシップを判定してもよい。例えばナビゲート可能区分が遅い平均移動時間を有する（例えば、フェリー路線）場合、ノードは別個の領域に移動されてもよい。

一般に前処理は、地図データがウェブサイト上で使用されるか又はＰＮＤ等の装置上で使用されるかに関わらず、地図データが使用される前に実行される。従って、前処理ステップは、サーバ側処理と呼ばれることが多い。

一般的なあらゆる演算装置が前処理を実行するのに適しているが、装置の性能が高い程、前処理は迅速に実行されることが当業者には理解されるだろう。一般に、Ｘ８６アーキテクチャ演算装置が前処理に利用される。一般にそのようなＸ８６アーキテクチャ装置は、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）、ＵＮＩＸ、ＬＩＮＵＸ、ＯＳＸ（登録商標）等のオペレーティングシステム（ＯＳ）を実行する。しかし、他の実施形態はＲＩＳＣアーキテクチャ等の他の演算プラットフォームを使用してもよい。

また、他で説明するように、前処理は並列に実行されてもよいため、複数の演算装置又は少なくとも複数のプロセッサコア（仮想又は実プロセッサコアであってもよい）で実行されてもよい。

次の前処理ステップとして、領域内の各道路区分（例えば、３０４ａ〜３０４ｄ）が処理され、それが地図内の領域数（Ｎ）の各々までの最小コスト経路の一部であるかを判定し、ビットベクトルが生成される（最小コスト評価）。従って、領域内の道路区分毎のビットベクトルは、領域内のナビゲート可能区分毎のビットを含む。すなわち、ビットベクトルは、経路がビットで表された領域までの最短経路の一部を形成するかに依存して０又は１に設定されるＮ−１ビット（当該領域を除いた各領域に対して１ビット）を含む。いくつかの実施形態は、ヘッダ及び可視エリア等の更なる情報を提供するために追加のビットを追加してもよい。これらの用語については以下に説明する。これについては、図５を参照して以下に更に詳細に説明する。

この意味で最小コスト経路が複数の種々のコスト基準に対して判定されることは、当業者には理解されるだろう。例えば最小コストは、最短距離、最短移動時間、最安（環境的な影響に関して）、最小の使用燃料、最小の生成ＣＯ_２等の基準のうちいずれかに対して判断されてもよい。本実施形態において、最小コストは最短移動時間に対して判断される。

従って、大きなエリアを範囲に含む地図の場合にＮが大きい可能性が高いことは、当業者には理解されるだろう。そのため、前処理には多くの時間がかかる可能性がある。

例えばヨーロッパ及びロシアを範囲に含む地図の一例において、一般に１２０，０００，０００個の道路区分を有する５０，０００，０００個のノードが存在する。地図内に１００個の領域が存在すると仮定すると、Ｎは１００であり、ビットベクトルに属する１２０，０００，０００ｘ１００（Ｎ）ビットが存在する。すなわち、１２ｘ１０^９ビットは地図の道路区分毎に９９（すなわち、Ｎ−１）ビットを格納する必要がある。以下に説明する本発明の実施形態を使用すると、そのような地図は約５００Ｍｂの追加の記憶容量を使用してもよい。

国際公開第ＷＯ２００９／０５３４１０号は、時間の関数として地図の経路に沿う速度を与える速度プロファイルを割り当てる方法を説明する。この出願の内容は、参考として本明細書に取り入れられている。従って、経路指定の目的で、ある経路が別の領域までの最速経路の一部を構成するか否かは時間の関数として変動する。すなわち、例えばラッシュアワー等で、交通密度が増加すると経路を使用するのが望ましくなくなり、交通密度が減少すると経路を使用するのがより望ましくなる。

いくつかの実施形態は、道路区分毎に複数のビットベクトルを格納してもよい。速度が記録される際の解像度が高い程、必要とされるビットベクトル数は増加することが当業者には理解されるだろう。しかし、他の実施形態は、国際公開第ＷＯ２００９／０５３４１０号で説明するように時変関数を多く利用して最速経路の評価を行ってもよい。

電子地図にわたる経路計画の時、約１／１００秒の精度の時間粒度を使用してこれを行える必要があると考えられる。すなわち、最小コストの経路を正確に判定するために、０．０１秒の精度でノードからの出発時間を指定できる必要があると考えられる。

従って、このレベルの精度を考慮する場合、上記で考慮された地図に対して、５０，０００，０００個のノード及び１２０，０００，０００個の道路区分を有することは１２０，０００，０００^２個の可能な経路を有することが理解されるだろう。時間次元が更に考慮される場合、可能な経路の数は更に増加する。すなわち、７（すなわち、１週間の日数）ｘ２４（すなわち、１日の時間数）ｘ３６００（すなわち、１時間の秒数）ｘ１００（すなわち、１秒間の１００分のいくつか）ｘ１２０，０００，０００^２＝８７０，９１２，０００，０００，０００，０００，０００，０００（１０２１）個の可能な経路がある。現在の処理レベルで、各区分が各時間間隔で探索される単純な方法を使用すると、約２７，６１６，４３８，４００，０００，０００年かかるだろう。ヨーロッパ及びロシアの地図は年々大きくなっているため、その時間は更に増加する。

従って、前処理段階でデータを格納及び処理するために多くのデータ量が必要とされることは理解されるだろう。

本発明の実施形態は、前処理の量を非常に低減するために技術を使用する。これらの技術について次に更に詳細に説明する。本発明のいくつかの実施形態はそれら技術の全てを利用してもよいが、他の実施形態は一部のみを利用してもよい。

本発明の種々の実施形態は、以下に概略を示す特徴の種々の組み合わせを使用してもよい。従って、いくつかの実施形態は、情報量を減少するために説明される技術の全てを利用してもよい。全く逆に、他の実施形態はデータを低減するためにそれら技術のいずれも利用しなくてもよい。

本発明のいくつかの実施形態は、ステップ１９０２（すなわち、道路区分が道路プロパティの所定の基準を満たさない）として示すように、所定の基準を満たさない道路区分に対するビットベクトルを算出しない。例えば、所定の種類の交通機関で道路区分を移動できない場合、道路区分は自身に対するビットベクトルを算出しなくてもよい。

従って、交通機関のモードの基準が自動車に設定される一例において、以下の道路区分は自身に対するビットベクトルを算出しなくてもよい。

・鉄道線路
・ナビゲート可能区分に対応しない地図データに存在する区分
・間違った（不法な）方向の一方通行道路
・交通機関の形態によりナビゲート不可能な道路区分（例えば、自動車による運転性を考慮した時、歩行用ゾーン、歩道）
・非決定地点の道路区分（すなわち、道路区分から方向転換できない）。

ネットワークの縮小
１つの技術は、道路区分が最小コストの経路の一部を形成するかに関する評価に対して考慮されるネットワークのサイズを縮小することである。すなわち、ステップ１９０４で示すように、道路区分数を減少することにより算出を行うのにかかる時間が短縮される。

この技術を図示するために、図２に示すような道路ネットワークを図４に示すが、図４では最小コスト評価に有用でない道路区分が削除されている。ネットワークの縮小の目的は、最小コスト評価が行われるべき最小のサブネットワークを提供することである。従って、ナビゲート可能区分はコアネットワークを形成する除去されていることが当業者には理解されるだろう。

数学的には、残されたネットワークは、図４に示すように、図２の道路ネットワークの最大の強連結成分の無向表現の最大の２連結成分として記述される。コアネットワークは、右左折制限及びローカルアクセス等の道路交通規制に適応した双方の強い接続性（２連結性としても既知である）に対して一般的な技術を適用することにより判定される。強い接続性は、２つのノード間で双方の方向に移動が可能であること（すなわち、Ａ−＞Ｂ及びＢ−＞Ａ）を示すことが当業者には理解されるだろう。

図２及び図４の双方を参照すると、袋小路２５０、冗長ループ２５２等の行き止まりの道が削除されていることが分かる。しかし、ノード（例えば、図４の４００）は、除去された道路区分の起点に残っていることが分かる。これは以下に説明する理由による。

図２のネットワークを図４に示すネットワークに縮小する際、探索加速データが次に回復可能であるナビゲート可能区分は除去されている。すなわち、いくつかの所定の基準に従って十分に小さく且ついくつかの更なる所定の基準を満たすナビゲート可能区分の集合を除去することにより残りのネットワークから切断されてもよいネットワークの部分を形成するナビゲート可能区分は、ネットワークから除去されている。例えばノード３０２に対する探索加速データは、いずれの経路計画の性能にも殆ど影響を及ぼさずに、ナビゲート可能区分３０４ａの行き止まりの領域のノードに対して容易に使用されてもよい。

コアネットワーク（例えば、図４に示す）に縮小後、コアネットワークは、上述した領域を提供するように区分される。説明している実施形態において、ネットワークは、多方向の円弧状の区切り記号に従って区分される。そのようなネットワークにおいて、領域境界により二等分される道路区分（すなわち、円弧）が除去される場合、いずれか一方の領域に残っている道路区分は他方の領域に接続されないことが当業者には理解されるだろう。
ネットワークの区分−ステップ１９０６
しかし、区分の実行前に以下のステップが行われる。

１．島が判定され、個々に区分される。島は、フェリーリンク等の手段によりネットワーク及びリンクの他の部分から物理的に分離される傾向がある。これらは一般的な道路区分とは異なる挙動をし（すなわち、平均速度が非常に遅い等）、そのようなリンクが区分に含まれる場合、方法は実行されず、予想されてもよい。

２．ネットワークにおいて２つ以上のノードで表される交差点、ロータリー及び他の分岐点は、同一の交差点等に属するノードが異なる領域で終了しないように短縮される。

３．全てのナビゲート可能区分が同一のプロパティの集合（例えば、フェリー区分、歩行用ゾーン又はゲート制御されたコミュニティに属する区分等）を共有する単純なパス（すなわち、方向転換の可能性のない２つのノード間の接続）は、区分システムに渡されるネットワークの入力サイズを縮小するために短縮される。例えば図３を見ると、ノード３０１は、そのすぐ下のノードにまとめられてもよい。すなわち、ノードは、２つ以下のナビゲート可能区分を接続させる場合に一方のノードにまとめられる。

更なる実施形態において、ナビゲート可能区分間の複雑な分岐点は複数のノードを含んでもよい。そのような複雑な分岐点は、単一のノードにまとめられてもよい（すなわち、ナビゲート可能区分間の分岐点にあるノードは、所定の状況において一方のノードにまとめられる）。

説明している本発明の実施形態は、ｈｔｔｐ：／／ｌａｂｒｉ．ｆｒ／ｐｅｒｓｏ／ｐｅｌｅｇｒｉｎ／ｓｃｏｔｃｈで概略を示される分割統治法を採用する。そこで概略を示される方法は、地図のエリアに基づかず領域内に含まれたノード数に基づく多くの領域を含むように地図を分割する。そのように編成されるノードを有することは、同様のローカル探索の直径を有する領域を出力するのを助長するため、領域を使用する経路指定をより効率的にすることを助長できるという利点を有する。

各ノードは、領域ＩＤを含む関連付けられた特定番号を有するため、同一領域のノードは同一の領域ＩＤ番号を有する。ノードは、Ｌ個の階層レベルの領域に属する。レベル０は、慣例によって、最も粗なレベル（長い距離の経路指定に使用される）である。レベルＬ−１は最も精細なレベルである。

いずれか１つの領域内に含まれるノードの絶対数を設定するのではなく、本発明のいくつかの実施形態はノードの最大数の上限を設定し、これを下回る自由度を可能にしてもよい。例えば方法は、領域毎に最大１００個のノードを指定してもよく、その結果、一般に６０〜１００個のノードの領域毎のノードの広がりが得られる。設定されたノードの数が結果として不自然な形状の領域を与え、それら領域を使用する場合に次善の経路指定が得られるため、上限は設定された数より有利であると考えられる。

複数レベル
説明している実施形態において、複数のレベルのネストされた領域を提供するように区分が行われる。これについては、図６に例示的に示す。最も粗なレベル（０）がレベル１を提供するように細分され、レベル１が最も精細なレベルであるレベル２に細分される階層性が存在することは図６から明らかである。

各領域のノード数はレベル間で異なり、より粗なレベル（より広い地理的エリアを範囲に含む傾向がある）はより低いレベルより多くのノードを有する。従って、説明している実施形態におけるより粗なレベル（例えば、レベル０）は一般に長い範囲の経路指定の目的で使用され、より精細なレベル（例えば、レベル２）は短い範囲の経路指定に使用される。

道路区分毎のビットベクトルの一部分はレベル毎にビットを含む。ビット数は、各レベルにおける領域数である。

符号化するデータ量の概念を与えるために（一般的な一実施形態において、一般にレベル数はＬ＝３である）、以下を示す。

・一般に、グローバルレベル＝０は１００個の領域を有する
・一般に、中間レベル＝１はレベル０の領域毎に１０個の領域を有する（すなわち、１００ｘ１０）
・一般に、最も詳細なレベル＝２は、レベル１の領域毎に５つの領域を有する（すなわち、１００ｘ１０ｘ５）
階層レベルを使用することは、必要とされる処理量を可能性として非常に減少させるため有利である。説明している本実施形態において、１００ｘ１０ｘ５個の領域（すなわち、５０００個の領域）である。従って、平坦な構造において、同数の領域を有することは５０００個の領域を参照するために本明細書で概略を示された方法を必要とする。しかし、本明細書で説明される実施形態において、これは適切なレベルのノードを参照することにより減少される。

一般に、種々の因子が地図に対して分かると、レベル数及びレベル毎の領域数は変更される。例えば、地図に割り当て可能な記憶容量及び経路指定が実行されるべき速度である。前処理量が増加すると、データを保持するために地図のサイズが大きくなるが、より速い経路はその地図を使用して算出されるという調和があることが当業者には理解されるだろう。

一実施形態において、３つのレベルの領域が存在する。しかし、他の実施形態において、レベルがいくつ存在してもよい。例えば、１つ、２つ、４つ、５つ、６つ、７つ、８つ、９つ又は１０個のレベルが存在してもよい。

従って、上記例を使用して、一般に５０，０００，０００個のノード及び１２０，０００，０００個の道路区分を有するヨーロッパ及びロシアの地図において、最も単純な符号化は、各レベルの全てのノードの領域ＩＤに対する固定サイズの符号化及び各レベルの各道路区分に対する固定サイズのビットベクトルを使用する。従って、そのような基本的な符号化のサイズは以下のように容易に算出される。

・レベル０の各ノード領域ＩＤはｌｏｇ＿２（１００）ビット＝７ビットを使用する
・レベル１の各ノード領域ＩＤはｌｏｇ＿２（１０）ビット＝４ビットを使用する
・レベル２の各ノード領域ＩＤはｌｏｇ＿２（５）ビット＝３ビットを使用する
・レベル０の各ビットベクトルは１００ビット（１００個の領域−現在の領域である１つの領域）を使用する
・レベル１の各ビットベクトルは１０ビット（１０個の領域−現在の領域である１つの領域）を使用する
・レベル２の各ビットベクトルは５ビット（５個の領域−現在の領域である１つの領域）を使用する
図６は、最も粗なレベルの領域６００を示す。図中、領域６００は６つの領域１〜６を提供する。これらの領域の各々は、領域６００の粗なレベル内の破線により表されるように、更なる領域、本実施形態では９つのサブ領域に細分される。６つの粗なレベルの領域はより粗なレベルの領域と考えられてもよく、９つのサブ領域は、より粗なレベルに対する近傍領域にあるより精細なレベルの領域と考えられてもよい。説明している実施形態において、破線で提供された各領域が更に細分される更なる細分のレベルが使用され、これにより３つのレベルの区分を提供するが、これについては参照を分かりやすくするため図６には示さない（しかし、図６ａに示す）。当然、他の実施形態はより多くのレベル（例えば、４つ、５つ、６つ、７つ又はそれ以上のレベル）又はより少ないレベル（例えば、１つ又は２つのレベル）を使用してもよい。

従って、本発明の実施形態は、ステップ１９０８において、より精細なレベルの領域に対していわゆる可視エリアを導入する。ｋ領域の可視エリアは、（ｋ−１）領域の集合であり、領域はフラグセットの自身のビットで区別可能である。当然、可視エリアは所定のｋ領域が属する（ｋ−１）領域を常に含む。更に可視エリアは、近傍の（ｋ−１）領域を含んでもよい。可視エリアは、前処理中に計算され、ビットベクトルと関連付けられて格納される。ここで、ｋ領域はより精細な領域と考えられてもよく、（ｋ−１）領域はより粗な領域と考えられてもよい。

ｋ領域とそれらの（ｋ−１）レベルの可視エリアとの関係は反対側から見られる。各（ｋ−１）領域は近傍にあるｋレベルの領域から構成される限界を認識している。このように考えると、道路区分のフラグセットは地図全体にわたり固定長ではない。その代り、各１領域のビットベクトルは、特定の長さＡ＋Ｂ＋Ｃ＋Ｎｏｕｔｓｋｉｒｔｓ０＋Ｎｏｕｔｓｋｉｒｔｓ１を有する。Ａは最も粗なレベルの領域を示し、Ｂは中程度の粒度を示し、Ｃは最も精細な粒度の領域を示す（３つのレベルが存在する一実施形態において）。

次の前処理は、ビットベクトルを生成するための最短パスの算出前に可視エリアを計算する。可視エリアを見つける方法は以下のように説明される。

一番上の各レベルの各領域Ｒに対して、近傍グラフは、以下の計測値が選択された閾値を超えるまで領域隣接グラフで幅優先探索を使用してｋ領域毎に探索される。

・Ｒから現在の領域のノードまでのグラフ理論距離
・現在の領域とＲの中点との間のユークリッド距離
・本明細書の他の場所で説明される他のいずれかの距離
その後、開始領域に十分に近接する訪問先ｋ領域毎に、含んでいる（ｋ−１）領域を可視エリアに追加する。

「密接度」の関係は、地理的計測値（例えば、領域中点間の距離）及びグラフ理論距離を考慮に入れるべきである。（従って、領域は、地理的に遠いが高速接続により現在の領域とリンクされる場合に「近い」だろう。同様に、領域は、地理的に近くても領域間を移動するのが困難である場合は「遠い」と考えられるだろう。）
厳密な閾値は、前処理の増加等の上述した悪影響を最も受けやすい首都圏の平均直径のような地図固有のプロパティに依存するため実験的調整を行われてもよい。非常に長い移動時間がかかるナビゲート可能区分（フェリー又は歩行用ゾーンに属する道路区分等）は隣接グラフの横断中隠蔽される。このように、可視エリアは同一領域に属する小さな列島又は単独の島に常に制限される。

従って、幅優先探索中に訪問される領域はＲの近傍領域を構成する。近傍領域を完全に範囲に含む次に粗なレベルの領域の操作対象最小集合は、Ｒの可視エリアと呼ばれる。逆の関係は近傍と呼ばれる。領域Ｑ（レベルＬの）の近傍リストは、可視エリアにＱを有するレベルＬ＋１の全ての領域から成る。

特定の例を与えるため、図６を参照すると、可視エリアの例は以下の通りである。

各１領域とその可視エリアの境界との間の最短距離が少なくとも１であるべきであると判断した場合、いくつかの選択した１領域に対する可視エリアは以下の０領域（自身の０領域は常に存在するため省略される）から成る。

・１５：
（すなわち、自身の０レベル領域が常に存在するために省略されるため、レベル１領域ｎｏ．１５は可視エリアを示さない）
・２８：５
（すなわち、レベル１領域ｎｏ．２８の可視エリアはレベル０領域ｎｏ．５を含む）
・３７：２、５、６
（すなわち、レベル１領域ｎｏ．３７は自身の可視エリアに３つの領域、すなわちレベル０領域ｎｏ．２、５及び６を有する）。

レベル１領域のレベル０近傍領域を考慮することに加えて、レベル１近傍領域がレベル０領域毎に判定される。一例として以下を示す。

・１：２１、２４、２７、２８、４１、４２、４３、５１
（すなわち、レベル０領域ｎｏ．１に対して、レベル１領域は２１、２４、２７、４１、４２、４３、５１である）
従って、この例において、領域２８が領域２の最も左側の列にないにも関わらず一覧表示されていることが分かる。例えばこれは、領域２８が領域１への迅速なリンクを有しているために距離ではなく時間に関して考慮された時に近いからである。密接度は、環境性（最少のＣＯ_２等）等の他の計測値に対して判断されてもよい。

いくつかの実施形態は、探索加速データの算出を制約することにより探索加速データを生成するのに必要とされる前処理量を低減するために可視エリアを使用してもよい。例えば実施形態は、行先領域（例えば、図６の領域２４）から起点ナビゲート可能区分（例えば、図６の領域２７）までの逆探索を使用してもよい。この逆探索は、行先領域の可視エリアの全てのナビゲート可能区分に最短経路で到達した時に停止するように制約されてもよい。例えば領域２４の可視エリアが領域２であると仮定すると、逆探索は、領域２の全てのナビゲート可能区分に最短経路で到達すると停止する。領域２内の最短経路は、領域２４の可視エリアに含まれていない領域を通過してもよいことが当業者には理解されるだろう。例えば、領域２の２つの場所の間の最短経路は領域１を通過してもよい。

更に詳細には、これは、領域２７の起点ナビゲート可能区分と領域２４の目的地との間の最短経路に対して真であってもよい。この経路は、領域２４に対して正確な探索加速データを生成するために考慮される必要がある。上述した制約された探索は、領域１を通過する経路に対する正確な探索加速データを生成することが当業者には理解されるだろう。すなわち、領域２内で、特に領域２７において、探索加速データを使用する探索は領域２４に対する探索加速データを使用する。領域１に進むと、粗な領域２に対する探索加速を使用する。領域１が領域２４の可視エリアにないため、領域１のナビゲート可能区分は、より精細な領域２４ではなく粗な領域２に対する探索加速データを有する。

更なる実施形態又は別の実施形態は、所定のナビゲート可能区分に対して格納された探索加速データを増加するために可視エリアを更に使用してもよい。これは必要とされる前処理量を増加するが、そのような探索加速データを含む地図データを使用して経路計画が実行される際の速度を向上できる。領域５１の可視エリアが領域５及び領域４の双方を含むと仮定すると、領域５１の目的地までの加速された探索は、領域４に存在する領域５１固有の加速データを既に使用する。すなわち、領域４内の道路区分は追加の探索情報を追加され、それらが領域５１に対する更なる最小コストデータを含むことを示す。この追加の情報は関連ビットと呼ばれてもよい。これは、領域４のレベル５にのみ加速データを適用することにより領域５１に近接するより広い探索面から悪影響を受ける従来技術にとって利点であると考えられる。

近傍リストの符号化
図６ａは、図６と比較して採用されてもよいレベルの更なる詳細を示す。レベル０は、最も粗なレベルであり、レベルｋ−１と考えられてもよい。簡潔にするために、図６ａにおいて、領域１〜４のみが示される（すなわち、６０２、６０４、６０６、６０８）。ｋ−１領域の各々は、ｋレベル領域すなわちレベル１領域と呼ばれてもよい９つの領域（１〜９）に更に分割される。また、これらのレベル１領域の各々は４つのｋ＋１レベル領域（すなわち、レベル２領域）に分割される。

ビットベクトルの生成
ネットワークが領域の階層レベル（説明している実施形態においては３）に区分されると、ステップ１９１０において、それら領域の各々までの最小コストの経路を決定するために処理され、ビットベクトルは領域内の道路区分毎に作成される。従って、上述したように、いずれか１つの領域内の各道路区分は、他の各領域までの最小コストの経路の一部であるかを判定するためにコスト関数に関して解析される。ビットベクトルは、図７に示すように領域の全ての道路区分に対して生成される。図７は、理解しやすくするために簡素化されたビットベクトルを示す。

最小コストの経路は、単一の期間で判定されるのではなく、以下に説明するように複数の期間に対して算出されることが理解されるべきである。

この算出は、図４に示したネットワーク（すなわち、縮小されたネットワーク）に対して行われる。除去された図３のネットワークの部分は、起点となるノードに効果的にまとめられる。例えば図３に示した道路区分３０４ａの終端ノードは、図３のノード３０２にまとめられる。

各ビットベクトルは３列含むことが分かる。最も左側の列７００は、考慮中の道路区分の開始のノードの特定番号を含む。第２の列７０２は、考慮中の道路区分の終了のノードの特定番号を含む。第３の列７０４はその道路区分のビットベクトルを含む。従って、各道路区分は、それぞれが道路区分の端部である２つのノードにより特定されることが分かるだろう。

道路区分が最小コスト経路の一部であるかを判定するためにどのような適切な経路指定方法が使用されてもよい。特定の本実施形態において、既知のダイクストラ法がネットワーク全体を探索するために使用される。

しかし、処理時間は種々の戦略を採用することにより短縮されてもよい。上述したネットワークを縮小する技術は、処理時間も短縮することが当業者には理解されるだろう。本発明の実施形態は、以下のうちいずれか１つ以上を採用してもよい。
・領域に対応する全てのビットベクトルエントリを１度に算出する。最短のパス木は、境界上にあるナビゲート可能区分毎に逆グラフにおいて算出される。そのような方法は、各領域が並行に処理されることにより処理時間を短縮するため有利である。
・同様の最短のパス部分木の再計算を減少する。
・既に生成されたビットベクトルを再計算しない。

従って、要約すると、一実施形態はビットベクトルを生成するために以下を実行してもよい。

準備ステップ
１．当業者には理解されるように、電子地図にわたる探索は有向非周期グラフ（ＤＡＧ）により表される。このグラフ及び隣接するデータ構造（方向転換コスト及び長い範囲テーブル）が逆にされる。

２．最も精細なレベルに対する単純な道路区分は短縮される（すなわち、他で説明するように、終端ノードは一方にまとめられる）。道路区分（すなわち、パス）は、所定のレベルの同一の領域にある程度＝２の１つ以上のノードから構成される場合に単純であると言われ、ナビゲート可能区分は同一の属性を有する。例えば、「フェリーである」、「ＮｏＴｈｒｏｕｇｈである」及び「ＮｏＤｒｉｖｉｎｇである」である。

３．道路ネットワークの道路区分は、領域毎に、先端（すなわち、ｆｒｏｍ＿ｎｏｄｅ）及び／又は末端（すなわち、ｔｏ＿ｎｏｄｅ）のノードがその領域に属するかに依存して、退出道路区分、進入道路区分及び内部道路区分の３つのグループにソートされる。すなわち、先端及び末端の双方が同一の領域内にある場合、道路区分は内部道路区分と呼ばれる。先端が領域内にあるが末端が領域内にない場合、道路区分は退出道路区分と呼ばれる。末端が領域内にあるが先端が領域内にない場合、道路区分は進入道路区分と呼ばれる。

４．特別な右左折制限は、ＮｏＴｈｒｏｕｇｈ及びＮｏＤｒｉｖｉｎｇエリアを出る全ての道路区分に設けられる。

前処理ルーチンは、最も精細な区分レベル、すなわち説明している実施形態においてはレベル２から開始してボトムアップ方式で進む。領域の各レベルにおいて、以下のステップが領域Ｒ毎に繰り返される。

１．Ｒの探索エリアを判定する。最上位レベル（例えば、説明している実施形態においては領域０）においてはグラフ全体であり、より精細なレベルにおいてはＲの可視エリアにより制限された部分グラフである（上述したように）。

従って、中間レベル（すなわち、レベル１）において、以下のステップはレベル１領域が含まれるレベル０領域の可視エリアに対してのみ実行される。レベル０において、長い範囲の経路指定に対して使用されることを注意すべきであり、グラフ全体の道路区分が考慮される。

可視エリアの進入道路区分、すなわちエリア外のノードからエリア内に至る道路区分を収集する。その後、境界付近の道路区分、すなわち進入道路区分に続く道路区分を収集する。先端（Ｌ１）＝末端（Ｌ２）でありＬ１からＬ２への方向転換が禁止されていない場合、道路区分Ｌ２はＬ１に続くと言われる（且つＬ１はＬ２に先行する）。複雑な交差点は、境界付近の道路区分を見つける目的で単一のノードに短縮される。フェリー路線及び「ＮｏＤｒｉｖｉｎｇ」属性を有する道路区分は境界付近の道路区分と考えられない。

このように進入道路区分を収集することにより、後述する探索ステップで必要とされる処理量を可能性として非常に減少できる。探索ステップは、進入経路を含む所定の領域までの経路を考慮するためにグラフの探索を減少できる。

２．Ｒの退出道路区分毎に、ルート道路区分及び探索ステップ数を見つける。退出道路区分がＲ内にある先行道路区分の少なくとも１つの唯一の後続道路区分である場合、この退出道路区分は唯一のルート道路区分であり、単一の探索ステップが実行される。あるいは、退出道路区分が双方向である場合（すなわち、双方向に運転可能である場合）、道路区分自体及びその反対の（進入）道路区分は単一の探索ステップのルート道路区分として利用される。あるいは、退出道路区分が一方向である場合、先行する各内部道路区分（及び存在する場合はその反対の道路区分）は別個の探索ステップのルート道路区分として利用される。最後に、退出道路区分の種類に関係なく、退出道路区分を通る交通範囲パス毎に、範囲の開始道路区分（Ｒ内にある場合）は別個の探索ステップのルート道路区分として利用される。

より精細なレベル（すなわち、レベル０以外の全てのレベル）において、退出フェリー路線は特別に処理される。上述したように、フェリー路線は、領域の近傍領域を判定する時に無視される。フェリー路線の先端領域がＲの可視エリアに属さない場合、フェリー路線が唯一のルート道路区分であり且つ探索エリアが先端領域自体に制限された状態で単一の探索ステップが実行される。

３．スケジュールされた探索ステップを実行する（以下に説明する）。

４．探索エリア内の道路区分からルート道路区分までの最短パスを辿る。最上位（すなわち、レベル０）以外の全てのレベルにおいて、辿ることを開始する道路区分の順序は結果に影響を及ぼす。ＲがレベルＬ領域（Ｌ＞０）であるとすると、レベル（Ｌ−１）領域の退出道路区分は最初に処理され、その後、レベルＬの残りの退出道路区分等、最も精細なレベルに向かって処理される。すなわち、最も精細なレベルに関して内部にあり（且つまだ除去されていない）道路区分が最後に処理される。先に辿った時に既に訪れた道路区分に遭遇した場合、２度目にそのパスに従う必要はない。辿っている間、適切な目標ビットベクトルが訪れた道路区分毎に設定される。最上位レベル（すなわち、レベル０）以外の全てのレベルにおいて、以下の追加の動作が行われる。

パスがあるレベルＬ領域の境界を初めて横切った後、その境界線及びルート道路区分までの途中にある全ての更なる道路区分は通過線フラグにより印がつけられる。

最短パスがＵターンをするノードは、Ｕターンフラグで印がつけられる。

最後に、最も精細なレベル以外の全てのレベルにおいて、相関行列エントリが満たされる。

そのレベルの全ての領域が処理された後、グラフは次のレベルに対して簡素化される。最初に、通過線として印をつけられなかった全ての道路区分が除去される。その後、増加する新しい単純なパスは短縮される。Ｕターンノードとして印をつけられたノードは保存される。

最後に、ビットベクトルは、相関行列に従って、このレベルを処理する前に除去された道路区分に伝播される。

相関行列
本発明のいくつかの実施形態は、道路区分上にビットベクトルを設定するのに必要な目標領域の間の関係を格納する相関行列を使用する。最も精細なレベル以外の各レベルＬにおいて、新しい相関行列が作成され且つ使用される。レベルＬにおいて、行列の行は、レベル（Ｌ＋１）領域により指標をつけられ、列はレベルＬ領域により指標をつけられ、各行列エントリは０個以上のレベル（Ｌ＋１）領域の集合である。より低いレベルにおいて、殆どの行列エントリが空の集合と等しい。すなわち、行列は疎である。

相関行列の目的は、早い段階で削除された道路区分にビットベクトルを設定することを助長することである。これらの道路区分は、レベルＬの探索ステップの結果として得られた有向非周期グラフに含まれないが、削除されなかった場合は含まれる。より詳細には、相関行列は、あるレベル＞Ｌの算出中に削除されたＳの探索エリアの道路区分のあるレベルＬ領域Ｓ（Ｌは最も精細なレベルではない）にビットベクトルを設定するために使用される。Ｓの探索エリアに含まれたレベル（Ｌ＋１）領域Ｒの場合、行列成分Ｍ［Ｒ，Ｓ］は、ＳからＲまでの全ての最短パス（逆グラフにおける）が１つの領域を通過するように、最終的にＲの可視エリアの境界にあるレベル（Ｌ＋１）領域の集合となる。

行列が作成される場合、全てのエントリは空の集合に初期化される。その後、全てのレベルＬ領域Ｓに対して、以下の２つの動作が行われる。

１．行列の構築：Ｓのルート道路区分ｌ及び結果として得られる有向非周期グラフＤを使用する各探索ステップに対して、Ｓの探索エリアに含まれた各レベル（Ｌ＋１）領域Ｒに対して、並びにＲの各進入道路区分ｌ’に対して、行列成分Ｍ［Ｒ，Ｓ］が以下のように更新される。

Ｒの探索領域をＡで示す（レベルＬ＋１に対して早い段階で算出されたように）。ｌ’からｌまでのＤにおけるパスを辿り、Ａを出たかを検査する。すなわち、Ｔが依然としてＡに含まれるがＴ’は含まれない状態で、このパス上の道路区分がレベル（Ｌ＋１）領域Ｔからレベル（Ｌ＋１）領域Ｔ’まで通っている場合、Ｔは集合Ｍ［Ｒ，Ｓ］に追加され、次のｌ’が処理される。

２．行列を読み出す：レベルＬ算出が開始する前に削除されたＳの探索エリアの各道路区分に対して、Ｒを道路区分が終了する（ここでも、逆グラフに対して）レベル（Ｌ＋１）領域とする。ここで、その線上の領域Ｓに対するビットベクトルのビットは領域Ｔのビットベクトルの論理和に設定される。尚、ＴはＭ［Ｒ，Ｓ］の全ての要素に及ぶ。

尚、Ｔ毎のビットベクトルのビットは、ある有向非周期グラフから直接又はより低いあるレベルにおいて相関行列を含む同様の手順で、より早いレベルで設定される。

探索
探索ステップは、所定の道路区分（対）を根とする最短パスの有向非周期グラフを構築することから成る。これは、最短パス（すなわち、最小コスト）の計算に対して既知のダイクストラ法の一変形例を使用することにより達成される。従来、「最短」という用語が選択される。実際には、最小にされる目的関数が、例えば移動時間又は推定された燃料消費又は他で説明される他の因子のいずれかとして自由に選択される。

一実施形態は、移動時間、パスの長さ、並びに望ましくない方向転換及び操作を抑制する他のペナルティ条件の加重和を使用する。

以下の変形が従来の（ダイクストラ）方法に行われる。

１．道路区分グラフに対して動作する。すなわち、訪れた項目、緩和された項目等がノードではなく道路区分である。これは、方法が右左折制限及び／又は交通範囲を考慮することを可能にするのに有用である。

２．ラベルの目的関数は、ルート道路区分における到着タイムスロットの固定の集合に対する対（移動時間、コスト）のベクトルである。タイムスロットは、全ての関連交通モードが範囲に含まれるように（自由流れ、平日の朝のラッシュアワー、夕方のラッシュアワー等）選択される。これについては、複数の期間におけるコスト関数の評価に関する説明において以下に更に詳述する。

３．２つ以上のラベルが所定の道路区分に対して格納される。２つのラベルにおける保留中（未完了）の交通範囲の集合が等しくない場合、ラベル自体は独立していると言われ、後続する道路区分にわたり伝播し続ける。あるいは、種々の到着タイムスロットに対するコスト関数値の間の関係は交互にならない。すなわち、一方のラベルが他方のラベルより良いのは明確であり、悪い方のラベルは廃棄される。そうでなければ、新しいラベルがタイムスロット毎の良い方の値をマージすることにより作成され、これは元のラベルの代わりに伝播される。先行するマージされたラベルの集合は、先行する元のラベルの集合の結合である。

４．特別なＵターンラベルは、双方向の各道路区分において作成される。それらラベルは、双方向の実際の（逆にされていない）経路を開始する可能性を符号化する。Ｕターンラベルは伝播されず、通常のラベルとマージされなくてもよい。しかし、それらラベルは、ビットベクトルが設定される時に追跡段階に影響を及ぼす。すなわち、開始ラベルが同一道路区分上のＵターンラベルより悪くない場合のみ、最短パスはフラグを立てられる。

５．探索エリアが領域の集合に制限されるより精細なレベルにおいて、上記で規定したような境界付近の道路区分は永続的に監視される。全ての境界付近道路区分に探索面が到達するとすぐに、監視コームはタイムスロット毎の最大（＝最悪）のコスト関数値から構築される。その後、コスト関数値が少なくとも１つのタイムスロットにおいて現在の監視コームを下回る場合にのみ、探索エリア外の道路区分のラベルはヒープを出た時に伝播される。探索エリアがいくつかの島に及ぶ場合、別個の監視コームが島毎に維持される。

時変関数
本発明のいくつかの実施形態は、単一の時間ではなく複数の期間においてネットワークにわたる最小コストの経路を示すビットベクトルを算出してもよい。道路ネットワークにわたる最小コストの経路は、交通密度の影響等により計時変化する可能性があることが当業者には理解されるだろう。従って、あらゆる１つのノードに対して、それぞれが異なる時間に対するものである２つ以上の最小コストパスが存在してもよい。本実施形態において、ビットベクトルは、最小コストパスが適用可能である場合に対して時間参照により符号化されない。ビットベクトルは、最小コストパスの一部であるとして又は一部でないとしてナビゲート可能区分を特定するために単純に設定される。従って、最小コストデータを使用して経路指定する場合、経路指定アルゴリズムはノードからの可能な全ての最小コストパスを考慮する必要がある。この処理については、図７ａを使用して次に簡単に説明する。

ネットワークの一般的なダイクストラ探索において、ネットワークが探索されると、方法はネットワークのその地点に到達するために現在までに発生した合計コスト＋まだ発生していない予想されるコストを使用する。

従って、いくつかの実施形態は、各ノードにおいてコスト評価を行うために別個の値とは対照的に関数を利用する。図７ａにおいて、探索されているグラフ７５１の各ノード（例えば、７５０）はコスト関数と関連付けられ、これは、探索されているパラメータ（例えば、時間又は消費燃料等）が計時変化する様子を特定する。ノード７５０は、起点ノードとして考えられてもよい。いくつかの実施形態において、起点ノードは起点ナビゲート可能区分と同義語であってもよい。

コスト関数は、ノードとは対照的に道路区分と関連付けられてもよい。

方法は費やしたコストを処理し、新しい関数を生成するために現在までに蓄積したコストを有する現在のノードにおいて関数を合計することにより推定されたコストを加算する。図７ａの７５２で示した例は、探索方法によりノード７５０で生成されたコスト関数を示し、移動時間（ｙ軸）が出発時間（ｘ軸）に伴って変化する様子を示す。朝及び夕方のラッシュアワーのために移動時間がポイント７５４及び７５６において増加していることが分かる。

特定の一実施形態において、コスト関数（例えば、道路区分の平均速度）は５分間隔で格納される。すなわち、これは５分間に変化し続ける関数ではなく量子化関数である。

道路区分に対するビットベクトルは、その道路区分がどの期間においても最小コスト経路の一部である場合に設定される。

完全なネットワークへのコアデータの投影
区分方法により考慮される必要があるノード及び道路区分の数を減少するために地図に含まれたネットワークを縮小する方法について上述した。しかし、経路指定方法が削除された道路区分及びノードに対する経路を依然として生成できるようにするためには、縮小ステップで削除されたノードも更に考慮されるべきである。

従って、削除されたノード及び道路区分は、それらがコアネットワークにおいて接続されるノードと同一の領域に割り当てられる。

圧縮
上述したように、生成されたビットベクトルはサイズが大きいため、情報を圧縮するのが望ましい。本発明の実施形態は、これを種々の方法で実行してもよい。しかし、一実施形態は、ビットベクトルを圧縮、結合及び／又は相関し、その後ビットベクトルのハフマン符号化を行う種々の技術を利用する。

いくつかの実施形態は、ビットベクトルの不均一な分布があることを保証しようとしてもよい。これは、そのような分布がない場合よりハフマン符号化が効率的であることを保証するのを助長できるからである。

例えばビットベクトルが以下のように分布される場合、
００００．．．．（時間の４９％）
１１１１．．．．（時間の４９％）
？？？？．．．．（時間の２％）
以下のようなより不均一な分布を有するようにハフマン符号化前のビットベクトルを操作するのが望ましい。

００００．．．．（時間の７９％）
１１１１．．．．（時間の１９％）
？？？？．．．．（時間の２％）。

生成されたビットベクトルの縮小
生成される必要があるビットベクトルの量を減少するために、本発明の実施形態は、以下の戦略のうちいずれか１つ以上を使用してもよい。

・領域ＩＤは、全てのノードに対して使用されるわけではなく、ナビゲート可能ノードに対してのみ生成される（例えば、鉄道線路に対応するノードは無視される）。

・ビットベクトルは、全ての道路区分に対して必要とされるわけではなく、決定ノードの周囲の決定道路区分に対して使用されてもよい。決定ノード＆決定道路区分は道路区分データを見ることにより判定される（本明細書で説明されるように）。

・可能なビットベクトルが多く存在するが、その一部はその他のビットベクトルよりはるかに頻繁に発生するため、特定の符号化は最も頻度の高いビットベクトル（例えば、０００．．．０００及び１１１．．．１１１）に対して使用される。

・多くの場合、０００．．．０００でも１１１．．．１１１でもないビットベクトルは、それらの殆どのビットが１に設定されているか又は０に設定されている。従って、部分ブロックのハフマン符号は、それらを非常に効率的に符号化すべきである。

・ビットベクトルは、多くの場合に互いに近接するノードにおいて同一であるため、デルタ符号化がそれらを効率的に符号化できる。

・種々の領域は、ソース領域毎に行先領域ＩＤを再順序付けすることにより、より類似するビットベクトルパターンを有するようにされてもよい（概念は本明細書において説明する）。

・ノードの道路区分の周囲の全てのビットベクトルは、常に１１１．．．１１１を与えるべきである。これはビットベクトルを更に効率的に符号化するために適切に使用される。

これらのうちの一部について、以下に更に詳細に説明する。

尚、この時点では、本明細書で説明される技術の目的はビットベクトルのサイズを縮小することである。しかし、経路指定の目的で地図データを使用する装置によりデータへのランダムアクセスが必要とされる。しかし、一般に、データの効率的な符号化にはデータへのランダムアクセスを防止する可変サイズが必要とされる。

従って、本発明の実施形態は、データが指標をつけられる一連のページとして符号化され且つそれらのページ内で可変符号化を利用するというトレードオフの関係を使用してもよい。そのような実施形態において、ランダムアクセスは各ページに対して達成可能である（指標をつけることにより）。ページがアクセスされると、実施形態はページ全体を復号化してもよい。これにより、効率と地図のサイズとの間にはトレードオフの関係が提供される。ページ毎のノード数を増加すると地図のサイズは減少するが、データアクセスは遅くなる。本発明の特定の一実施形態は、ページ毎に１６個のノードを使用する。いずれか１つのノードは、そのノードを出る異なる数の道路区分を有してもよいことが理解されるだろう。従って、同数のノードが存在してもよいが、ページ毎の道路区分の量は可変であってもよい。更に、各ページに格納されたビットベクトルの各々に対して異なる圧縮が適切に行われてもよい。

そのような構造により、図８に示す地図形式が得られる。ここで、数字「ｎ」は、ヘッダ内に格納され、その地図に対して性能を最適化するために種々の地図に対して変更されてもよい。

「ｎ」を調整することは、地図データを復号化する時のアクセス速度と地図のサイズにはトレードオフの関係がある。

・大きな値のｎは多くのノードをグループ化する。これは、地図の圧縮には適切であるが、データへのランダムアクセスの速度には不適切である。

・小さな値のｎは殆どのノードをグループ化しない。これは、データのランダムアクセスの速度には適切であるが、地図の圧縮には不適切である。

・「ｎ」は例えば４に設定されてもよい。すなわち、１６個の出発ノード（出発ノードは道路区分の開始点あり、すなわち図７の列７００である）から成るページであるが、各出発ノードはいくつかの到着道路区分を有する。平均で３つの到着道路区分を有すると仮定すると、各ページが〜４８個の道路区分を格納することを意味する。

この形式において、符号化される領域のレベルに依存してデータに対する異なる形式が存在する。図９は、レベル０（すなわち、最も粗な領域）に対する形式の一例を示し、図９は、領域の他のレベルに対する形式の一例を示す。

ビットベクトル及び関連情報はデータ構造に格納され、その形式を図８に示す。図８は、ヘッダ８００、後述するハフマン符号化で使用されるハフマン木８０２、各階層における領域数８０４（レベル毎の領域数が一定の場合は空）、近傍領域８０６（近傍領域がない場合は空）、領域ＩＤ再マッピングテーブル８０８、ビットベクトルページ指標（２ｎ個のノード）８１０、並びに領域ＩＤ及びビットベクトル８１２を含む。ビットベクトルを保持するデータ構造は、単一のファイル内に保持されてもよく、あるいは複数のファイル内に保持されてもよい。

いくつかの実施形態において、地図ヘッダ８００は、以下を示す更なる情報を含むように構成される。

・レベルの最大数
・最短近傍リストの長さ
・最長近傍リストの長さ
・全ての近傍リストを含むセクションのバイトオフセット。

情報を保持する各ファイルは、近傍リストを符号化するためにセクションを有してもよい。全てのリストのサイズがまず符号化される。リストの各長さは、最短リストの長さに対して、ＢｉｔｓＲｅｑｕｉｒｅｄ（ｌｏｎｇｅｓｔＬｉｓｔＬｅｎｇｔｈ−ｓｈｏｒｔｅｓｔＬｉｓｔＬｅｎｇｔｈ）により判定された固定のビット数に符号化される。尚、全てのリストが同一の長さを有する場合、長さを符号化するのにビットは必要ない。

その後、全てのリストの内容に従う。各リストは、近傍領域ＩＤのいくつかのタプル、すなわちレベル０ではいくつかの対、レベル２では３つの要素のいくつかのタプルから成る。

尚、出発領域タプル（ＡＳＣＩＩファイルの「：」の前の部分）は符号化されない。これらは、リストが全ての領域に対して昇順に格納されるため黙示的である。例えば地図が１００ｘ１０ｘ５（レベル０の１００個の領域、レベル１の１０個の領域、レベル２の５つの領域）を有する３つのレベルを有する場合、以下の通りである。

・レベル０において、リストは出発領域１、２、３、．．．１００（この順序で１００個のリスト）に対して格納される。これらリスト各々は対を含む。

・レベル１において、リストは出発領域１．１、１．２、１．３、．．．１．１０、２．１、２．２、．．．２．１０、３．１、．．．１００．９、１００．１０（この順序で１０００個のリスト）に対して格納される。これらのリストの各々は、３つの要素のタプルを含む。

・レベル２において、これは最後のレベルであり近傍領域が存在しないため、何も格納されない。

タプルの各成分はｎビットとして格納される。レベル毎のビット数は、対応するレベルの領域数から判定される。従って、リストにランダムにアクセスできる。３つのレベルの１００ｘ１０ｘ５の場合、タプルａ．ｂ．ｃを符号化するには、ａに対しては７ビット（レベル０の領域が１００個存在するため）、ｂに対しては４ビット（レベル１の領域が１０個存在するため）及びｃに対しては３ビット（レベル２の領域が５つ存在するため）を使用する。

例：１００ｘ１０ｘ５個の領域、すなわち粗レベル０の１００個の領域、中間レベル１の１０個の領域及び詳細レベル２の５つの領域の区分を仮定する。

レベル０のファイルにおいて、近傍リストを含むセクションは以下を含む。

・レベル０の１００個の領域に対するリストの長さを示す１００個の番号。ビット数は、ＢｉｔｓＲｅｑｕｉｒｅｄ（ｌｏｎｇｅｓｔＬｉｓｔＬｅｎｇｔｈ−ｓｈｏｒｔｅｓｔＬｉｓｔＬｅｎｇｔｈ）から算出される。各番号は、そのレベルの最短リストに相対的である（最短リストはヘッダに格納される）。

・その後、１００個のリスト（１００対）の内容に従う。各対の第１の要素は７ビット（レベル０の領域が１００個存在するため）に符号化され、各対の第２の要素は４ビット（レベル１の領域が１０個存在するため）に符号化される。

レベル１のファイルにおいて、近傍リストを含むセクションは以下を含む。

・・レベル１の１０００個の領域に対するリストの長さを示す１００＊１０＝１０００個の数字。

・・１０００個のリスト（１０００個の３つの要素のタプル）の内容に従う。各タプルの第１の要素は７ビット（レベル０の領域が１００個存在するため）に符号化され、各タプルの第２の要素は４ビット（各レベル０領域においてレベル１の領域が１０個存在するため）に符号化され、各タプルの第３の要素は３ビット（各レベル１領域においてレベル２の領域が５つ存在するため）に符号化される。

レベル２のファイルにおいて、これは最後のレベルであるため、何も格納する必要がない。

ヘッダ８００
一般に、本発明の実施形態で使用されるヘッダは小さく、従ってそのサイズを縮小するためにサイズを最適化する必要はない。一般に、全てが便宜上位置合わせされたバイト又は単語である。

・（４バイト）符号化バージョン（地図形式が変更される度に増加する）
・（４バイト）地図フラグ（機能をＯＮ又はＯＦＦする。最初は０であるが、オプションの機能を追加する必要がある場合に後で使用される）
・（４バイト）地図中のノードの合計数
・（４バイト）地図中の道路区分の合計数
・（４バイト）ハフマン木セクションのバイトオフセット
・（４バイト）領域ブロブセクションのバイトオフセット
・（４バイト）領域ページ情報セクションのバイトオフセット
・（４バイト）ビットベクトルページ情報セクションのバイトオフセット
・（４バイト）可変サイズレコードセクションのバイトオフセット
・（４バイト）ビットベクトルページの最大ビット数（起動時にビットストリーム復号器に対して悪い例を事前に割り当てるために経路計画方法により使用される）
・（４バイト）平均ビットベクトルページサイズのビット数（ビットベクトルページ位置を補間するために使用される）
・（４バイト）最小ビットベクトルページデルタ（全てのデルタを＞＝０にするために使用され、ビットサインを格納することを回避する）
・（２バイト）ビットベクトル履歴の最大サイズ（起動時に履歴バッファを事前に割り当てるために経路計画方法により使用される）
・（２バイト）ページ毎の道路区分の最大数（現在使用されていない）
・（１バイト）このファイルのアポロレベル
・（１バイト）ビットベクトル毎のビット
・（１バイト）ビットベクトルページデルタ毎のビット（ビットベクトルページの固定サイズレコードのフィールド）
・（１バイト）ブロブ指標毎のビット（領域ページ情報の固定サイズレコードのフィールド）
・（１バイト）領域数毎のビット（領域ページ情報の固定サイズレコードのフィールド）
・（１バイト）非自明なビットベクトルブロック毎のビット
・（１バイト）領域ノードページサイズのｌｏｇ＿２（）
・（１バイト）ビットベクトルページサイズのｌｏｇ＿２（）
・（１バイト）ローカル領域ＩＤを符号化するためのハフマン木の数
・（１バイト）ビットベクトル履歴符号を符号化するためのハフマン木の数。

ハフマン木８０２
・各ノードの周囲の道路区分数を符号化するためのハフマン木。小さく、１０個ほどの符号がレベル０のファイルにのみ存在する）
・非自明なビットベクトルのブロックを格納するためのハフマン木。最大のハフマン木であり、大きい程、圧縮に適切であるが、経路計画方法で必要とされるメモリは多くなる（経路計画方法でのメモリの使用量と地図圧縮との間のトレードオフの関係）。

・履歴サイズが０である場合のビットベクトルデルタ符号のハフマン木。小さく、符号を３つだけ含む。

・履歴サイズが１である場合のビットベクトルデルタ符号のハフマン木。小さく、符号を４つだけ含む。

・履歴サイズが＞＝ｎである場合のビットベクトルデルタ符号のハフマン木。小さい（ヘッダに格納されたハフマン木の数）。

・領域ページに３つの領域が存在する場合の領域ＩＤに対するハフマン木。小さく、符号を３つだけ含む。

・領域ページに４つの領域が存在する場合の領域ＩＤに対するハフマン木。小さく、符号を４つだけ含む。

・領域ページに＞＝ｎ個の領域が存在する場合の領域ＩＤ対するハフマン木。小さい（ヘッダに格納されたハフマン木の数）。

領域再マップテーブル８０４及び領域ＩＤリスト８０６
図８のファイル形式の他の部分より小さいが、領域ＩＤ８０６は、図１１に例示するように圧縮されてもよい。ここで、使用されるデータ量を減少するために、地理的相関が使用されてもよい。

各領域ページは、その領域ページの別個の領域のリストを格納する。このリストは、殆どの場合に小さいと予想される（実際には、多くのページは少なくともレベル０の領域を１つだけ含む可能性が高い）。領域のリストは可変サイズを有する。ページ内のデータは、ランダムにアクセス可能であるべきであり（すなわち、ランダムアクセス）、固定テーブルサイズはこれを可能にするために使用される。

別個の領域の各リストは、各領域のノードの頻度により順序付けされる。リストの第１の要素は、ページ中の最大数のノードを含む領域に対応し、リストの再度の要素は、ページ中の最小数のノードを含む領域である。

領域ページの各ノードにおいて、ローカル領域ＩＤ（ページにローカルな）を使用してその領域ＩＤを符号化できる。このローカルＩＤは、ページ中の領域の指標である（これは小さい整数であり、０は領域ページの最も一般的な領域に対応するため、多くの場合は０である）。

ノードの領域ＩＤは以下のように格納される。

・領域ＩＤ’を含む領域配列はページ中の領域の可能な重複リストを全て格納する。領域のリストは、その配列において連続した領域ＩＤである。リストは、重複してもよい（重複する）。配列は各リストの開始及び終了を格納しない（これは、領域ページ情報テーブルにより行われる）。

・領域ページ情報テーブルは固定サイズレコードテーブルであり（従って、ランダムにアクセス可能である）、各レコードはリストの開始の配列における指標＋リスト中の項目数を含む。

・各ノードはローカルノードＩＤ（そのページにローカルな）を含む。

これらの概念の各々については、以下に更に規定する。

領域配列
領域配列は、ページの全ての可能な領域リストを符号化する。領域ＩＤのリストが重複してもよい領域ＩＤの単純な配列である。そのサイズは、リストが重複するため小さい。領域配列については、領域ページ情報の節で更に説明される。

領域ページ情報
領域ページテーブルの領域ＩＤのリストを指定するには、領域ページ情報テーブルの固定サイズレコードの２つのフィールドを使用する。

・領域数（このページの領域数であり、小さいと予想される）
・領域リストの配列へのオフセット（ここで領域のリストが開始する）
一実施形態において、これについては図９で説明する通りである。

オフセットフィールドは領域配列を示す。領域ＩＤ毎に１バイトの固定サイズレコードで十分である。例えば、各レベルには２５６個未満の領域が常に存在すると仮定する。これは妥当な仮定である（しかし、レベル毎に最大２５６個の領域というのは制限しすぎであると考えられる場合、８ビットより大きくすることは容易に可能である）。領域ページテーブルレコードの領域数は、指定されたオフセットで配列にあると考えられる領域数を示す。

いくつかの領域が同一リストを有する場合、それらは同一の場所を示せる。これは、多くのページが同一リストを共有するか又は同一リストの部分を共有することが予想できるためコンパクトであるべきである。

これについては、図９を参照して更に詳細に説明する。図９は、２＾ｎｒ個のノード（例えば、５１２個のノードをグループ化するためにｎｒ＝９）のページを有する一実施形態を示す。

尚、いくつかのページが配列において同一の場所又は重複する場所（図中、領域ブロブとラベル付された）を示せるため、領域ＩＤの配列９００は非常にコンパクトである。実際には、各ページがより少ない領域と重複し、組み合わせの可能性が低減されるため、ページ数を増加することにより配列のサイズは増加されない。従って、この配列は、生成された地図データがロードされる装置において多くの地図空間も多くのメモリも必要とせずに多くのページを作成することを可能にすべきである。

方法の目的は、領域ＩＤのリストを含む配列９００を可能な限り小さく維持することである。方法の目的は、領域ＩＤの同一のリストを配列において可能な限り多く再利用することである。方法は、リストの最後の２つの要素がハフマン符号のサイズに影響を及ぼさないためそれらの要素を自由に再順序付けできる。

例えばリストが２つの領域１０及び３４を含む場合、２つのノードが存在する全ての例においてハフマン木が１ビットのみを使用するため、これはリスト１０、３４又は３４、１０を格納すること（頻度に関係なく）と同等である。換言すると、頻度により再順序付けすることは、最後の２つの領域に対して緩和される。同様に、第１の符号１０（頻度が最も高い）のみが１ビットを使用し、他の符号４０及び３４の双方が２ビットを使用する（順序に関係なく）ため、３つの要素１０、３４、４０のリストは１０、４０、３４として格納されてもよい。

図９を参照すると、配列９００が２つの値、すなわち長さ及び領域データの開始からのオフセットを格納することが分かる。第１の行（３：０）を考慮すると、これはファイルの開始から０だけオフセットして３つのデータを参照する（すなわち、１０、３４、４０）。更なる例を考慮すると、配列エントリ（１：２）は、ファイルの開始から２だけオフセットした単一の領域（すなわち、長さ１）を参照する（すなわち、領域４０）。

別の実施形態において、領域ページ情報は、以下の方法に従って符号化される。

このセクションは、各領域のサブ領域数を符号化する。サブ領域の数はレベル毎に可変であってもよい。しかし、サブ領域数がレベル毎に一定であることが多い。サブ領域数は、ｌｏｇ＿２（ｍａｘ＿ｎｕｍｂｅｒ＿ｏｆ＿ｒｅｇｉｏｎｓ−ｍｉｎ＿ｎｕｍｂｅｒ＿ｏｆ＿ｒｅｇｉｏｎ）ビットを使用して、各レベルの最小領域数に対して相対的に符号化される。従って、領域数が一定である場合、領域数を符号化するために０ビットが使用され、このセクションは空である。最小領域数及び最大領域数は、副ファイルのヘッダに格納される。
近傍領域セクションの符号化（近傍領域についは、図６及び図６ａに関連して説明する）
このセクションは、所定のレベルＬの領域階層毎に、より詳細なレベルＬ＋１の近傍領域のリストを符号化する。例えば、レベルＬ＝１の領域３．９は、レベルＬ＝２において近傍領域のリスト、３．５．４、３．６．３、３．６．４、４．７．１、４．７．３を有してもよい。他で説明するように、近傍領域のリストは、各副ファイルを生成するのに使用される前処理の速度を向上するために使用されてもよい。

このセクションは２つのサブセクションに分割される。

・全ての近傍リスト（所定のレベルにある領域と同数）の長さを符号化するサブセクション。長さは、最短リストに対して相対的に符号化され、ビット数はｌｏｇ＿２（ｌｅｎｇｔｈ＿ｌｏｎｇｅｓｔ＿ｌｉｓｔ−ｌｅｎｇｔｈ＿ｓｈｏｒｔｅｓｔ＿ｌｉｓｔ）で計算される。全てのリストが同一の長さを有する場合、長さを符号化するのに０ビットが使用される（従って、セクションは空である）。

・全ての近傍リスト（所定のレベルにある領域と同数）を符号化するサブセクション。

領域ＩＤ再マッピングテーブルの符号化
このセクションは、レベル０の副ファイルでのみ符号化される。これは、レベル０の各領域のビットを再順序付けし且つ結合するのに使用される２次元テーブルを符号化する（ビットベクトルを効率的に符号化するために、結合及びビット再順序付けについて本文献において以下に更に説明する）。ビットベクトルのビットの再順序付け及び結合は、ビットベクトルのハフマン符号化を最適化するために行われる。このテーブルは、以下が分かっている場合に復号化するビットベクトルにおけるビット位置を見つけるために経路計画方法により使用される。

・現在のノードの出発領域ＩＤ
・元の到着ビット指標（すなわち、ビットベクトルのビットを分離した後のビット指標）
２次元テーブルの２つの指標は以下の通りである。

・出発領域ＩＤ
・行先ビット指標（目的地の領域）
このセクションは２つのサブセクションから成る。

・レベル０の領域毎に結合ビット数を符号化するセクション。各数を符号化するために使用されるビット数は、ｌｏｇ＿２（ｍａｘ＿ｎｕｍｂｅｒ＿ｏｆ＿ｃｏａｌｅｓｃｅｄ＿ｂｉｔｓ）である。

・ビット再マッピングテーブルを符号化するセクション。経路指定する場合、行先ビットは変化しないが（経路指定の間、目的地は同一のままである）、出発領域ＩＤは行先ビットの行により格納された行列を変更する（経路指定中に探索されるノードに依存して）。各行において、ビット再順序付け番号は、出発領域毎に格納される。一般に、経路計画方法は、経路指定中、所定の経路指定目的地に対応するメモリの１行のみをロードする。経路計画方法は、２次元行列全体をメモリに格納する必要はない。経路計画方法は、その行にランダムにアクセスできる。各再マッピングエントリを符号化するのに使用されるビット数は、ｌｏｇ＿２（最大結合ビット数）で計算される。

図１０は、レベル０領域（図６を参照）に対する図８に示したファイルのビットベクトルセクション８１２を展開する。各ページが道路区分数、領域ＩＤ及びビットベクトルを含むことが分かる。

図１１は、レベル０以外のレベルに対する図８に示したファイルのビットベクトルセクション８１２を展開する。他の領域に対して、ビットベクトルのみが格納され、レベル０に対して格納される道路区分数又は領域ＩＤは格納されない。

これは、より精細なレベルにおいて、各ノードがレベル０の副ファイルに格納された全てのレベルに対する領域番号を有するためである。そのように格納する理由は、副ファイルを使用するいずれかの経路計画の間にアクセスされる必要のあるファイル数を減少するためである。

ビットベクトル８１０、８１２の符号化
テーブル８１０は固定サイズレコードを含む。出発ノードＩＤは２ｎのページにグループ化される。

ビットベクトルが同一の近傍領域のいくつかの道路区分に対して同様のパターンを有すると予想されるため、複数の連続したノードのページにデータをグループ化するのが便利である。ページを使用することにより、いくつかの道路区分をデルタに符号化でき、適切な圧縮を達成できる。同様に、ページにおいてデルタにノードの領域ＩＤを符号化できる。一方、これは、１つの道路区分のデータにアクセスすることがいくつかの道路区分のデータをアンパックすることを必要とすること（直接ランダムアクセスではない）を意味する。１つの道路区分又はノードのデータにアクセスするのにいくつかのノード又は道路区分をアンパックする必要があることは、以下の理由により受け入れ可能であると考えられる。

・データは、１つの道路区分にアクセスする時に読み出された追加のデータが無用でないことが多いためキャッシュされる。この追加のデータはすぐ後で有用となるだろう（これは、ディスクキャッシングの先読みパラメータに類似する）。

・ビットベクトルを使用する経路指定は、ダイクストラＡ＊経路指定と比較した時に拡張探索のサイズをある桁だけ減少する。ページ毎にデータをグループ化することにより、地図の小さな部分が依然として復号化される必要がある（実際のパスに沿うページ）。

・領域ＩＤ＆ビットベクトルのデルタ圧縮のために符号化データサイズが非常に縮小される。

・上述したようにデータが副ファイルに格納されるため、ページは指標付けのサイズを縮小する。

テーブル８１０内の各レコードは、「デルタ」フィールドを含み、これは、各ページの可変サイズの開始位置（補間位置に対するデルタ）を見つけるために使用される。デルタ毎のビット数はヘッダに格納される。

領域ＩＤ及びビットベクトル８１２にアクセスするために、復号器は線形補間を行うことにより開始ページの推定されたオフセットを計算してもよい。

ｉｎｔｅｒｐｏｌａｔｅｄ＿ｏｆｆｓｅｔ ＝ ｆｒｏｍ＿ｎｏｄｅ＿ｉｄ ＊ ａｖｇ＿ｐａｇｅ＿ｓｉｚｅ
式中、ａｖｇ＿ｐａｇｅ＿ｓｉｚｅはヘッダに格納された平均ページサイズのビット数である（精度を向上するために可能性として固定点における）。データのオフセットは、以下のように計算される。

オフセット ＝ ｉｎｔｅｒｐｏｌａｔｅｄ＿ｏｆｆｓｅｔ ＋ ｍｉｎ＿ｄｅｌｔａ ＋ デルタ
式中、ｍｉｎ＿ｄｅｌｔａは全てのページ（ヘッダに格納された）に対する全てのデルタフィールドの最小値であり、デルタは、ページに格納された符号なしフィールドである。ｍｉｎ＿ｄｅｌｔａ値は、全てのデルタフィールドが正の値であること（格納するビット符号はない）を保証する。

可変サイズレコードは、上述したビットベクトルページ情報の「デルタ」フィールドを介してアクセスされる。

各レコードは、２^ｎ個のノードのデータ（全てのレベルにおける出発ノードの領域ＩＤ及びそれらの連結道路区分のビットベクトル）を含む。従って、同一の指標付け方式が全てのレベルに対して使用される。

可変サイズレコードは以下を格納する。

・ページ符号−そのページ内のノードが同一領域の一部であるか否かを示すページ全体に対する符号。

・ビットベクトルページの各ノードの周囲の道路区分数（全てのレベルに対して同一であるため、レベル０でのみ格納される）。

・ページの出発ノードの領域ＩＤ。レベル毎に１つのＩＤがある（レベル０でファイルに格納された全てのレベルに対する情報）。

・レベルｉのみのページのノードの周囲（＞２個の連結道路区分を有するノードの周囲のみ）の道路区分のビットベクトル。これはデータの最大の部分である。

・各ノードの周囲の道路区分数の符号化。

ビットベクトルページの２^ｎ個のノードの各々に対して、ハフマン符号はノードの周囲の道路区分数を符号化する。この情報は、全てのレベルに固有のものではなく、レベル０のファイル（ａｐ＿０＿＊．ｄａｔ）にのみ格納される。

ノードの周囲の道路区分数を認識することは、ビットベクトルを復号化するのに使用される（図１０の１０００を参照）。この情報は、他のファイルに既に存在する情報と冗長するが、他の場所にある情報をルックアップする必要なくページ中のビットベクトルを復号化するのを容易に且つ迅速にする。これにより、サイズの小さな増加が性能を向上する。

可変サイズレコードの領域ＩＤの符号化
ノードの領域ＩＤ１００２は、各ノードの周囲の道路区分数１０００の符号化の直後に可変サイズレコードに符号化される。前処理において生成されたビットベクトルを使用して経路指定を行うために、一般に所定のノードに対する全てのレベルの領域ＩＤ１００２にアクセスする必要があり、全てのレベルの領域ＩＤは、レベル毎に異なるファイルに分割されるのではなく互いに近接して同一ファイルに格納される。

３つのアポロレベルを有する２ｎ（例えば、ｎ＝４）個のノードのビットベクトルページは以下のようにノードＩＤを格納する。

ノード＃０：ｌｏｃａｌ＿ｒｅｇｉｏｎ＿ｉｄ＿ｌｅｖｅｌ＿０ ｌｏｃａｌ＿ｒｅｇｉｏｎ＿ｉｄ＿ｌｅｖｅｌ＿１ ｌｏｃａｌ＿ｒｅｇｉｏｎ＿ｉｄ＿ｌｅｖｅｌ＿２
ノード＃１：ｌｏｃａｌ＿ｒｅｇｉｏｎ＿ｉｄ＿ｌｅｖｅｌ＿０ ｌｏｃａｌ＿ｒｅｇｉｏｎ＿ｉｄ＿ｌｅｖｅｌ＿１ ｌｏｃａｌ＿ｒｅｇｉｏｎ＿ｉｄ＿ｌｅｖｅｌ＿２
ノード＃２：ｌｏｃａｌ＿ｒｅｇｉｏｎ＿ｉｄ＿ｌｅｖｅｌ＿０ ｌｏｃａｌ＿ｒｅｇｉｏｎ＿ｉｄ＿ｌｅｖｅｌ＿１ ｌｏｃａｌ＿ｒｅｇｉｏｎ＿ｉｄ＿ｌｅｖｅｌ＿２
．．．
ノード＃１５：ｌｏｃａｌ＿ｒｅｇｉｏｎ＿ｉｄ＿ｌｅｖｅｌ＿０ ｌｏｃａｌ＿ｒｅｇｉｏｎ＿ｉｄ＿ｌｅｖｅｌ＿１ ｌｏｃａｌ＿ｒｅｇｉｏｎ＿ｉｄ＿ｌｅｖｅｌ＿２
更に、以下の通りである。

・１つ又は２つの連結道路区分を有するノードの周囲で符号化されるものはない（すなわち、連結道路区分数として０を格納するノードに対して）。

・ページ符号のビットが所定のレベルで設定される場合、全てのノードはそのレベルの同一領域ＩＤにあり、そのレベルの領域ＩＤは１度だけ符号化される（＞＝３個の連結道路区分を有する第１のノードに対して）。領域ＩＤを符号化するビット数はｌｏｇ＿２（ｒｅｇｉｏｎＣｏｕｎｔ−１）である。

・領域ＩＤが符号化されるページの第１のノード以外は、各領域ＩＤを符号化する前にビットが符号化される。このビットは、領域ＩＤが同一レベルの先に符号化されたノードＩＤと同一であるかを示す。このビットが設定される場合、そのレベルの先に符号化されたものと同一であるため、領域ＩＤを符号化する必要はない。このビットが０である場合、ｌｏｇ＿２（ｒｅｇｉｏｎＣｏｕｎｔ−１）ビットで領域ＩＤを符号化する。多くの連続したノードが同一の領域にあるため、領域ＩＤを符号化するのに１ビットだけ必要とすることが多い。

以下の理由のために、ローカル領域指標のハフマン符号化は効率的である。

・領域は各領域ページにおける頻度によりソートされる（従って、ローカル指標０はローカル指標１、．．．より頻度が高い）。

・ページの領域数毎に別個の専用のハフマン木が存在する（３つの領域がページにある場合に１つのハフマン、４つの領域がページにある場合に１つのハフマン木等）。ハフマン木は小さいため、メモリを多く使用せずにいくつか格納できる。

・少なくともレベル０において、３つ以上の領域を有することは極めて珍しい（しかし、他のレベルでは珍しくない）。

可変サイズレコードのビットベクトルの符号化
各可変サイズレコードは、ページのノードの周囲の全ての道路区分に対するビットベクトルを含む。ビットベクトルは、３つ以上の連結された線（道路区分）を有するノードの周囲でのみ符号化される。１つ又は２つの連結道路区分を有するノードの場合、経路指定方法は、それらのノードにビットベクトル値１１１．．．１１１を黙示的に与えられる。

到着ノードは符号化されない。

図７を参照すると、道路区分は、それぞれが道路区分の端部にある２つのノードにより指定されてもよい。従って、方向が考慮される場合、方向の開始にあるノードはｆｒｏｍ＿ｎｏｄｅと呼ばれてもよく、方向の終了にあるノードはｔｏ＿ｎｏｄｅと呼ばれてもよい。

ビットベクトルに関する種々のプロパティは、効率的にするために符号化内で使用される。

・ビットベクトルの多くは０００．．．０００又は１１１．．．１１１である。

・ビットベクトルの他の値（すなわち、０００．．．０００でも１１１．．．１１１でもない）に対しては、繰り返しになる可能性が高く、同一の値が繰り返される可能性が高い。

ビットベクトルは、第１のハフマン符号及びオプションの更なるハフマン符号として符号化される。第１のハフマン符号は、ビットベクトルが以下のいずれであるかを示す。

・自明なビットベクトル０００．．．０００に対する符号０
・自明なビットベクトル１１１．．．１１１に対する符号１
・符号２、すなわちページでまだ遭遇していない非自明なビットベクトルを示す符号。この場合のみ、新たに遭遇したビットベクトルを符号化するために他のハフマン符号が後続する。

・ビットベクトルが現在のページの先に遭遇したビットベクトルと同一である場合（自明なビットベクトル０００．．．０００及び１１１．．．１１１は無視する）、＞＝２の符号。この符号化は、ページの先に遭遇した符号の履歴を使用する。符号は、実際には先に遭遇した全ての符号の履歴中の指標を与える。

このハフマン符号以外は、履歴中で見つけられなかった非自明なビットベクトルの場合（符号＝２）にのみ、更なる情報が符号化される必要がある。この場合、ハフマン符号＝＝２の直後に以下が符号化される。

・否定ビット
・Ｎビットのブロックによりｎ個の領域に対するビットベクトルを符号化するためのいくつかのハフマン符号（Ｎ及びｎは地図ヘッダで与えられる）。例えば、１００個の領域（９９ビットのビットベクトル）を１１ビットのブロックを使用して符号化することは、９個のハフマン符号（９ｘ１１＝９９）を符号化することを必要とする。

殆どのビットベクトルは殆どが０又は殆どが１のベクトルを含むため、否定ビットは、ビットベクトルが否定されて格納されるか否かを示す。これにより、殆どが０のベクトルを多く含むハフマン木への符号の格納を可能にする（これにより、ブロックのハフマン符号化を向上する）。ブロックのサイズが領域数より小さい場合にのみ否定ビットは存在し、これは、実際にはレベル０において当てはまるが、レベル１又は２において、ビットベクトル全体は１つのブロックにのみ符号化されるため否定ビットは必要ない。

１００個の領域が存在する場合、すなわちＮ＝１００（従って、９９ビットのビットベクトル）の場合、第１のブロックは行先領域１〜１１に対するビットを符号化し、第２のブロックは領域１２〜２２を符号化する。第１のブロックにおいて、ＬＳＢ（０ｘ１）は行先領域１に対応し、次のビット（０ｘ２）は領域２に対応し、次のビット（０ｘ４）は領域３に対応する。

履歴を使用するビットベクトルの場合、履歴配列の深さはページ中の先に遭遇した別個のビットベクトルの数である（自明なビットベクトル０００．．．０００及び１１１．．．１１１を考慮に入れない）。異なるハフマン木は、履歴ベクトルが０個の要素、１つの要素、２つの要素、３つの要素等を含むかに関わらず使用される。全てのハフマン木が小さいために大きな記憶容量が必要とされないため、ハフマン木を増加することは受け入れられる。

・履歴が０個の要素を有する場合、ハフマン木は３つの符号、すなわち０００．．．０００に対する０、１１１．．．１１１に対する１、新しいビットベクトルに対する２を有する。

・履歴が１つの要素を有する場合、ハフマン木は４つの符号、すなわち０００．．．０００に対する０、１１１．．．１１１に対する１、新しいビットベクトルに対する２、履歴の要素＃０と同一のベクトルに対する３を有する。

・履歴が２つの要素を有する場合、ハフマン木は５つの符号、すなわち０００．．．０００に対する０、１１１．．．１１１に対する１、新しいビットベクトルに対する２、履歴の要素＃０と同一のベクトルに対する３、履歴の要素＃１と同一のベクトルに対する４を有する。

・その他。

ビットベクトルページのサイズが小さい（例えば、２ｎ個の出発ノード）と予想されると、ハフマン木の数も小さいと予想される。

しかし、ハフマン木のサイズを最大値に制限できる。例えば履歴がＨ個より多くの要素を含む場合は必ず、単一のハフマン木が使用される（値Ｈは地図ヘッダに格納される）。

この符号化は、各ページ中の別個のビットベクトル＋いくつかの符号のみを符号化する。

経路指定の目的でビットベクトル（ページ中の復号化するより多くのビットベクトル）を使用するために、符号化は、復号化を遅くする代わりに大きな指標のページに対してサイズに関してより効率的である。

統計
ベネルクスを２５４個の領域（１つのレベル）に符号化する場合のファイル形式に対する詳細な統計を示す。以下の入力パラメータを使用した。

ビットベクトルブロック毎のビット数：１１
ビットベクトルページ毎のノード数：２＾４＝１６
領域ページ毎のノード数：２＾９＝５１２
統計は、地図のサイズに関して地図形式の概念を与え且つ実データに関する地図形式の記述を示すために提供される。
−−−グローバル統計カウンタ：
ノード数．．．．．．．．．．．．．．．．．．．．．．．１５９８６３２
線の数．．．．．．．．．．．．．．．．．．．．．．．． １５９８６３２（１００．０００％）
１つの線を有するノードの周囲の線をスキップする．．． ２２０１８０（ １３．７７３％）
２つの線を有するノードの周囲の線をスキップする．．． ７２７１３８（ ４５．４８５％）
−−−レベル＝［０］の統計：
地図カウンタ．．．．．．．．．．．．．．．．．．．．．．８７４３７７３６（１００．０００％）
符号化された自明なａｒｐフラグ０００．．．０００．．． １３１０９１４（ ３１．６５１％）
符号化された自明なａｒｐフラグ１１１．．．１１１．．． ９１３３４８（ ２２．０５２％）
履歴中の符号化されたａｒｐフラグ．．．．．．．．．．． ３６２４３２（ ８．７５１％）
履歴中にない符号化されたａｒｐフラグ．．．．．．．．． ６０７７１７（ １４．６７３％）
否定ブロック．．．．．．．．．．．．．．．．．．．． ２３５１７１（ ５．６７８％）
地図のサイズ（ビット）．．．．．．．．．．．．．．．．．８７４３７７３６（１００．０００％）
グローバルヘッダ．．．．．．．．．．．．．．．．．．． ４９６（ ０．００１％）
ハフマン木．．．．．．．．．．．．．．．．．．．．．． ２８８０８（ ０．０３３％）
領域ブロブ．．．．．．．．．．．．．．．．．．．．．． ５２６６４（ ０．０６０％）
領域ページ情報．．．．．．．．．．．．．．．．．．．． ５６２１６（ ０．０６４％）
ａｒｐフラグページ情報．．．．．．．．．．．．．．．． ２４９７８８０（ ２．８５７％）
可変サイズレコード．．．．．．．．．．．．．．．．．．８４８０１６７２（ ９６．９８５％）
ノードの周囲の線の数．．．．．．．．．．．．．．．． ２８４７８４４（ ３．２５７％）
ノード領域ＩＤ．．．．．．．．．．．．．．．．．．． ２１１２４５１（ ２．４１６％）
ａｒｐフラグ．．．．．．．．．．．．．．．．．．．．７９８４１３７０（ ９１．３１２％）
自明な符号０００．．．０００．．．．．．．．．．． １６８９３２２（ １．９３２％）
自明な符号１１１．．．１１１．．．．．．．．．．． １８２６６９６（ ２．０８９％）
履歴中で見つけられた符号．．．．．．．．．．．．． １６６８０５３（ １．９０８％）
履歴中で見つけられない．．．．．．．．．．．．．．７４６５７２９９（ ８５．３８３％）
履歴中で見つけられない符号．．．．．．．．．．． １４６３１８３（ １．６７３％）
否定ビット．．．．．．．．．．．．．．．．．．． ６０７７１７（ ０．６９５％）
ブロック．．．．．．．．．．．．．．．．．．．．７２５８６３９９（ ８３．０１５％）
全てのサイズはビット単位である。地図の合計サイズは、８７，４３７，７３６ビット（１０，９２９，７１７バイト）である。

インデントは階層を反映している。可変サイズレコード情報は、圧倒的に大きい情報（地図のサイズの９６．９７５％）である。可変サイズレコードにおいて、サブ項目（インデントされた）はより詳細を与える。ビットベクトルは、可変サイズレコードに格納する圧倒的に大きな情報（９１．３１２％）である。ビットベクトルにおいて、履歴においてまだ遭遇していない非自明なビットベクトルを格納することは地図の最大部分を構成する（８３．０１５％）。

ハフマン木に関する統計
このセクションは、ベネルクスを２５５個の領域に符号化する（すなわち、上記で示した地図データに対して）場合のハフマン木に対する統計を与える。

各ノードの周囲の道路区分数のハフマン木
−−−［ハフマン木：Ｎｒ本の線］−−−
ビット： １ 値： ３ 符号 ０
ビット： ２ 値： ２ 符号 １０
ビット： ３ 値： １ 符号 １１０
ビット： ４ 値： ４ 符号 １１１０
ビット： ５ 値： ５ 符号 １１１１０
ビット： ６ 値： ６ 符号 １１１１１０
ビット： ７ 値： ７ 符号 １１１１１１０
ビット： ７ 値： ８ 符号 １１１１１１１
殆どのノードは３つの連結道路区分を有するが、ハフマン木の第２及び第３の位置において、２つ又は１つの連結道路区分を有するノード（決定ノードではない）を見つける。

非自明なビットベクトルブロックのハフマン木
自明なビットベクトルのブロックを格納することが圧倒的に大きな地図のサイズを占める（ベネルクスの２５５個の領域の例において８３．０１５％）ため、これは最大のハフマン木である。

−−−［ハフマン木：ＮｏｎＴｒｉｖｉａｌＡｒｐＦｌａｇＢｌｏｃｋ］−−−
ビット： １ 値： ０ 符号 ０
ビット： ６ 値： １ 符号 １０００００
ビット： ６ 値： ２ 符号 １００００１
ビット： ６ 値： ４ 符号 １０００１０
ビット： ６ 値： ８ 符号 １０００１１
ビット： ６ 値： １６ 符号 １００１００
ビット： ６ 値： ３２ 符号 １００１０１
ビット： ６ 値： ６４ 符号 １００１１０
ビット： ６ 値： ５１２ 符号 １００１１１
ビット： ６ 値：１０２４ 符号 １０１０００
ビット： ７ 値： １２８ 符号 １０１００１０
ビット： ７ 値： ２５６ 符号 １０１００１１
ビット： ７ 値： ３８４ 符号 １０１０１００
ビット： ８ 値： ５ 符号 １０１０１０１０
．．．大きすぎるため中略．．．
ビット： ２４ 値：１５３４ 符号 １１１１１１１１１１１１１１１１１１１１１０１１
ビット： ２４ 値：１７１７ 符号 １１１１１１１１１１１１１１１１１１１１１１００
ビット： ２４ 値：１７４１ 符号 １１１１１１１１１１１１１１１１１１１１１１０１
ビット： ２４ 値：１８３０ 符号 １１１１１１１１１１１１１１１１１１１１１１１０
ビット： ２４ 値：１９７３ 符号 １１１１１１１１１１１１１１１１１１１１１１１１
全て０から成るブロックを格納することは、頻度が最も高いパターンであり、上記ハフマン木に従って１ビットのみに符号化される（これは、自明なビットベクトル０００．．．０００がブロックにより符号化されないが、ブロックの５０％以上が値０を符号化することを意味する）。これは、殆どの非自明なビットベクトルが以下のいずれかを含むためである。

・殆どが０（及びいくつかの１）
・殆どが１（及びいくつかの０）
符号化方式は、殆どが１であるビットベクトルに否定演算（〜）をし、最終的にビットベクトルのブロックを符号化することは、主に、０００．．．０００を含むブロックを１ビットにのみ符号化する。次に頻度の高いブロックは、１ビットのみが設定されるブロックである（１、２、４、８、１６、３２、６４．．．）。これらのブロックは同程度の頻度を有するため、同一（又はほぼ同一）のビット数を有する。

ローカル領域ＩＤのハフマン木
領域のリストが頻度により各ページに格納されるため、ローカル領域ＩＤ０を格納することは他の場所の領域ＩＤより少ないビット数（実際には１ビットのみ）を利用する。種々のハフマン木は、３つの領域、４つの領域、５つの領域等を含むページに対応する。

−−−［ハフマン木：Ｒｅｇｉｏｎｓ＿０］−−−
ビット： １ 値： ０ 符号 ０
ビット： ２ 値： １ 符号 １０
ビット： ２ 値： ２ 符号 １１
−−−［ハフマン木：Ｒｅｇｉｏｎｓ＿１］−−−
ビット： １ 値： ０ 符号 ０
ビット： ２ 値： １ 符号 １０
ビット： ３ 値： ２ 符号 １１０
ビット： ３ 値： ３ 符号 １１１
−−−［ハフマン木：Ｒｅｇｉｏｎｓ＿２］−−−
ビット： １ 値： ０ 符号 ０
ビット： ２ 値： １ 符号 １０
ビット： ３ 値： ２ 符号 １１０
ビット： ４ 値： ３ 符号 １１１０
ビット： ４ 値： ４ 符号 １１１１
−−−［ハフマン木：Ｒｅｇｉｏｎｓ＿３］−−−
ビット： １ 値： ０ 符号 ０
ビット： ２ 値： １ 符号 １０
ビット： ３ 値： ２ 符号 １１０
ビット： ４ 値： ３ 符号 １１１０
ビット： ５ 値： ４ 符号 １１１１０
ビット： ５ 値： ５ 符号 １１１１１
．．．以下略．．．。

ビットベクトル履歴符号のハフマン木
符号０（自明なビットベクトル０００．．．０００を意味する）は、頻度が最も高い（且つ殆どの場合、１ビットにのみ符号化される）。符号１（自明なビットベクトル１１１．．．１１１は、次に頻度が高い（且つ１ビットにのみ符号化される）。次に頻度が高い符号（２）は、ブロックにより符号化された非自明なビットベクトルに対するものである。他のコード（＞２）は履歴中に見つけられるビットベクトルに対するものである。

−−−［ハフマン木：ＡｒｐＦｌａｇ＿０］−−−
ビット： １ 値： ０ 符号 ０
ビット： ２ 値： １ 符号 １０
ビット： ２ 値： ２ 符号 １１
−−−［ハフマン木：ＡｒｐＦｌａｇ＿１］−−−
ビット： １ 値： ０ 符号 ０
ビット： ２ 値： １ 符号 １０
ビット： ３ 値： ２ 符号 １１０
ビット： ３ 値： ３ 符号 １１１
−−−［ハフマン木：ＡｒｐＦｌａｇ＿２］−−−
ビット： １ 値： ０ 符号 ０
ビット： ２ 値： １ 符号 １０
ビット： ３ 値： ２ 符号 １１０
ビット： ４ 値： ３ 符号 １１１０
ビット： ４ 値： ４ 符号 １１１１
−−−［ハフマン木：ＡｒｐＦｌａｇ＿３］−−−
ビット： １ 値： ０ 符号 ０
ビット： ２ 値： １ 符号 １０
ビット： ３ 値： ２ 符号 １１０
ビット： ４ 値： ３ 符号 １１１０
ビット： ５ 値： ４ 符号 １１１１０
ビット： ５ 値： ５ 符号 １１１１１
−−−［ハフマン木：ＡｒｐＦｌａｇ＿４］−−−
ビット： １ 値： ０ 符号 ０
ビット： ２ 値： １ 符号 １０
ビット： ３ 値： ２ 符号 １１０
ビット： ４ 値： ３ 符号 １１１０
ビット： ５ 値： ４ 符号 １１１１０
ビット： ６ 値： ５ 符号 １１１１１０
ビット： ６ 値： ６ 符号 １１１１１１
−−−［ハフマン木：ＡｒｐＦｌａｇ＿５］−−−
ビット： ２ 値： ０ 符号 ０
ビット： ２ 値： １ 符号 ０１
ビット： ２ 値： ２ 符号 １０
ビット： ４ 値： ３ 符号 １１００
ビット： ４ 値： ４ 符号 １１０１
ビット： ４ 値： ５ 符号 １１１０
ビット： ５ 値： ６ 符号 １１１１０
ビット： ５ 値： ７ 符号 １１１１１
．．．以下略．．．。

地図のサイズに対する入力パラメータの影響
図８に示したファイル形式を制御し且つ地図のサイズに影響を及ぼす入力パラメータが多く存在する。パラメータを微調整することは、パラメータに依存する伸張の速度又はメモリ使用量と地図のサイズとの間のトレードオフの関係となる。

本発明の実施形態は、以下の入力パラメータを使用してもよい。

・領域ページサイズ
・ビットベクトルページサイズ
・ビットベクトルブロックサイズ
・ビットベクトルハフマンコーデック数
・領域ハフマンコーデック数。

ビットベクトルブロックサイズの影響
値 地図のサイズ（ビット）
４ ３５５４８１９２
５ ３３６４８７９２
６ ３２２９０３４４
７ ３０８５３６１６
８ ３１１０３２００
９ ３０４３６６９６（デフォルト）
１０ ３００５１７９２
１１ ２９２６６７８４
１２ ２８９３４６９６。

ビットベクトルに対するハフマンブロックサイズを増加することにより、地図圧縮は向上される。ブロックサイズが大きい程、圧縮はより適切になる。しかし、ブロックサイズを増加することは、２＾ｎ個の値のより大きなハフマン木を格納するのにより大きなメモリが必要となる。上記テーブルはこのことを示す。

ソース領域毎に領域ＩＤを再マッピングするために最適化を導入する場合、このパラメータの影響はより大きくなると予想される。この最適化の結果、大きいビットベクトルブロックサイズを使用する場合に地図のサイズが非常に減少されるのが望ましい。

ビットベクトルページサイズの影響
値 地図のサイズ（ビット）
２＾１ ５５５６３９４４
２＾２ ４２５０２９３６
２＾３ ３４８９８８４０
２＾４ ３０４３６６９６（デフォルト）
２＾５ ２７３８９９５２
２＾６ ２５１６５０３２
２＾７ ２３６３５９３６
ページサイズを増加することは、地図をより適切に圧縮するのを助長する。しかし、ランダムな道路区分のビットベクトルにアクセスするにはページ中の全ての道路区分を復号化する必要があるため、大きなページは経路指定方法によりデータをファイル形式に伸張することを遅くする。上記テーブルはこのことを示す。

ビットベクトルハフマンコーデック数の影響
値 地図のサイズ（ビット）
１ ３０８６６９２０
２ ３０７４８０２４
３ ３０６３４１６８
５ ３０５０４５０４
７ ３０４６７９４４
９ ３０４３６６９６（デフォルト）
１１ ３０４２３６８８
ビットベクトルハフマンコーデックの数を増加することは、圧縮を僅かに向上させるのを助長し、これを上記テーブルに示す。ハフマン木はいずれの場合も小さいため、値を増加することに対する欠点はほぼない。９個（デフォルト値）を上回ってハフマン木を増加しても大きな改善は得られない。このパラメータを増加することは、ビットベクトルページが大きいほど効果的である可能性がある。

ビットベクトルのビットの結合＆再順序付け
ビットベクトルはパターンを有する。これらのパターンはソース領域（すなわち、ビットベクトルが格納されるノードの領域）毎に大きく異なる。Ｎビットのビットベクトルを格納するためのビット数は、ソース領域毎に小さな変換テーブルを格納することにより減少される。これらのテーブルは、この節で更に説明される２つの関数を実行する。

・ビットの結合
・ビットの再順序付け
概念は、以下のように直感的に理解される。スペインの場合、スウェーデン（行先領域スウェーデンに対してビット＝１）に通じている道路区分は、ノルウェー（すなわち、目的地ノルウェーに対するビットも１）に通じている可能性が高いことは明らかである。別の道路区分がスウェーデン（ビット＝０）に通じていない場合、その道路区分は殆どの場合においてノルウェーにも通じていない。従って、スペインの場合、行先領域スウェーデン及びノルウェーに対するビットベクトルのビットの値はほぼ常に等しい。実際には、ビットの値は多くの行先領域に対して常に厳密に等しい。どのビットがどのビットに相関しているかは、出発領域に大きく依存する。

例えばフィンランドの場合、行先領域ノルウェー及びスウェーデンに対するビットは殆ど相関しない。一方、フィンランドにおいて、行先領域スペイン及びポルトガルに対するビットは１００％（又は少なくともほぼ１００％）相関する可能性が高い。

ビットの結合は、いくつかのビットが常に等しい（完全に相関される）というプロパティを利用する。これらのビットは単一ビットに結合される。ビットを結合することにより、各領域で符号化するビット数が減少される。

ビットの再順序付けは、ビットベクトルのハフマン符号化を最適化するように（且つ／又はハフマン木のサイズを縮小するように）ビットをシャッフルするために、いくつかのビットが十分適切に相関される（しかし、１００％相関されるわけではない）というプロパティを利用する。

ビットを結合し且つ再順序付けするためのテーブルを計算する前に、全ての出発領域の全てのビット対の相関が算出される。別個の対の数は以下の通りである。

Ｃ（Ｎ， ２） ＝ Ｎ！／（２！ ＊ （Ｎ − ２）！） ＝ Ｎ ＊ （Ｎ − １）／２
式中、Ｎは領域数である。この数は、領域数が多い場合に大きくなる。全てのビット相関を計算することは、図８に示したファイル形式を生成する方法の最も遅い部分である。方法の複雑さはｎ＊Ｎ＊Ｎであり、ｎはビットベクトル数であり、Ｎは領域数である。各領域のビット対（すなわち、ビットベクトルの個別の列の対）毎に３次元テーブルを計算する。

ｂｉｔＣｏｒｒｅｌａｔｉｏｎ［ｆｒｏｍＲｅｇｉｏｎＩｄ］［ｂｉｔＩ］［ｂｉｔＪ］
テーブルの各エントリは、以下をカウントする４つのフィールドから成る構造を含む。

・ｆｒｏｍＲｅｇｉｏｎＩｄの全てのビットベクトルにおけるｂｉｔＩ＝０及びｂｉｔＪ＝０の回数
・ｆｒｏｍＲｅｇｉｏｎＩｄの全てのビットベクトルにおけるｂｉｔＩ＝０及びｂｉｔＪ＝１の回数
・ｆｒｏｍＲｅｇｉｏｎＩｄの全てのビットベクトルにおけるｂｉｔＩ＝１及びｂｉｔＪ＝０の回数
・ｆｒｏｍＲｅｇｉｏｎＩｄの全てのビットベクトルにおけるｂｉｔＩ＝１及びｂｉｔＪ＝１の回数
計算するためのプロセッサの時間に関して高価である（且つ従って遅い）が、出発領域毎にビット相関を計算することは他の出発領域から完全に独立しているため、この処理は容易に並列化できる。

本発明の実施形態は、マルチスレッディングを使用して、ＳＭＰ（対称型マルチプロセッシング）マシンを効率的に使用するための全てのビットの相関の計算を加速する。１つのシステムにおいて、３００個の領域を含むベネルクスのビット相関を計算する１ＣＰＵのマシンは約８分かかる。しかし、並行処理が適切に釣り合い、スレッドを可能にし且つビット相関を計算する４つのＣＰＵを使用する場合は２分（１／４の時間）かかる。

ビットの結合
いくつかのビットが完全に相関される場合（すなわち、常に全て０又は全て１）、どの情報も損失することなくそれらのビットを１ビットのみに結合できる。所定の領域において「グループ」として完全に相関されるビットの集合を参照すると、所定の領域のビットベクトルはいくつかのグループから成る。Ｎビットのビットベクトルがｎ個のグループから成る場合、Ｎビットのビットベクトルを符号化することはｎビット＋各領域において等しいビットを示す小さなテーブルを使用する。

そのようなビットの結合は、結果として得られるファイルのサイズが可逆的に縮小されるという利点を有する。領域数が増加すると、より多くのビットが結合される可能性があるため、領域数の増加に伴いこの利点も大きくなる可能性が高い。従って、地図のサイズは領域数に伴いほぼ線形的に増加する。

一実施形態において、以下のデータが得られた。
最小グループ数 平均グループ数 最大グループ数
２５５個の領域のベネルクス １２ ８４ １５２
３００個の領域のベネルクス １３ ９０．０１７ １６３
従って、２５５個の領域を有するベネルクスの例において、１２個のグループのみを有する少なくとも１つの領域が存在する（すなわち、ハフマン符号化の前であっても（及びハフマン符号化の後であっても）２５５ビットのビットベクトル（すなわち、ビットベクトルが領域数と同一の長さである）を符号化するのに１２ビットだけ必要とされる）。

平均して、領域は２５５個の領域のベネルクスに対して８４ビット必要とする。この例において、ハフマン符号化の前、最悪な領域でも１５２ビット（１５２個のグループ）を必要とする。

別の例として、符号化データから得られるような以下の１８個のグループを有する上記２５５個の領域のベネルクスにおいてｒｅｇｉｏｎＩｄ＝３を利用する。
ｒｅｇｉｏｎＩｄ＝［３］は［１８］個のグループを有する。

各行は１つのグループ（ｒｅｇｉｏｎＩｄ＝３に対する１８個のグループ）を表す。小括弧内の数字は、各グループで結合されたビット指標である。＃の後の数字は各グループのビット数である。

この例において、１つのグループは非常に大きく、１４１個もの領域を含む。これは異例ではない。一般に、地図の境界上の領域は、地図の中央の領域より多くのビットを結合する。

この例において、ビット数は平均で〜３（〜＝２５５／８４）に減少されている。当然、これは、符号化する残りのビットが元のビットより高いエントロピーを有する（従って、ハフマンブロックにより符号化するのはより困難である）ため、地図のサイズが１／３に縮小されることを意味しない。しかし、ビットの結合により、地図のサイズは可能性として非常に縮小される可能性がある。

各領域のビットを結合させる場合、各領域のビットベクトルは、図１２に示すように結果として異なるビット数を有する（しかし、所定の出発領域のビットベクトルに対しては同一のビット数を有する）。陰影は、各ビットベクトルの出発領域ＩＤを示す。ｙ軸は区分の順序を表す。例えば、最上部のブロックは１０４３本の線を表してもよく、次のブロックは５０７本の線を表してもよい。

テーブルｂｉｔＣｏｒｒｅｌａｔｉｏｎが計算されると、完全に相関したビットのグループを特定することは非常に容易で且つ迅速である。０１又は１０パターンが見つからない全てのビット対は完全に相関され、１ビットに結合される。

ビットの結合の更なる一例を与えるために、以下のテーブルは、それぞれが１５ビットから成る６つのビットベクトルの一例を与える。これらは結合されていない。

これらの１５ビットのビットベクトルは、４つのグループ、すなわちハフマン符号化の前のビットベクトル毎に４ビットに結合される。

テーブルの右側部分の見出しは、テーブルの左側部分の４ビットの結合ベクトルのビットを示す。明示するために、４ビットの結合ベクトルの第１のビットは、左側部分の第１列、第３列及び第９列を表す。従って、左側部分（すなわち、１５ビットの元のベクトル）の第１のビット、第３のビット及び第９のビットが上記例において常に同一であるため、それらのビットは上記テーブルの右側部分の第１列により表されてもよい。

従って、要約すると、左側と右側との間の索引のテーブルは以下の通りである。
元のビット 結合されたビット
０ ０
１ １
２ １
３ ０
４ ０
５ ３
６ ２
７ １
８ ２
９ ２
１０ ３
１１ ０
１２ ３
１３ １
１４ １
ビットを効果的に結合することは、近傍の行先領域及び図１３に示すように出発領域から同一角度の扇形内にある行先領域をグループ化することである。

図１３の陰影は、結合される領域のグループを示す。２つの図面（すなわち、図１３ａ及び図１３ｂ）は、２つの異なる出発領域の観点から結合された同一領域を示す。結合される領域は、図示するように出発ノードの領域ＩＤに依存する。図中、８つの領域が４つのグループに結合される。ビットの結合は、これらの図の出発領域Ａ又は出発領域Ｂの観点から異なる。尚、垂直の縞模様の領域（１３００）は、出発領域Ａから見た場合に同一方向のあるため結合される。

これは、図１４において更に例示される。図１４は、ビットの結合が各出発領域の観点から近傍の行先領域及び＋／−の同一角度の扇形内にある行先領域をグループ化することを示す。

ビットを結合した後、ビットベクトルに対して符号化するビット数は領域毎に異なる。例えば２５５個の領域のベネルクスの場合、領域毎のビットベクトルのビット数は以下の通りである。
出発領域 −＞ 結合されたビット
１ −＞ ５７
２ −＞ ９３
３ −＞ １８
４ −＞ １２
５ −＞ ６３
６ −＞ ７５
．．．中略．．．
２５１ −＞ ２１
２５２ −＞ ４６
２５３ −＞ １１７
２５４ −＞ ８０
方法は正確である（ヒューリスティックではない）。従って、理想的なビットのグループ数が分かる。

いくつかの実施形態において、ビットの結合は可逆的に実現される。すなわち、領域は常に同一ビットを有する場合に結合される。しかし、他の実施形態において、これは不可逆にするように、すなわち元のデータの完全な回復が不可能であるように拡張されてもよい。そのような不可逆の実施形態は閾値（すなわち、密接度の尺度）を導入してもよい。すなわち、ビット対がＸ倍未満だけ異なる場合、一部のビットベクトルの１つ以上の０を１で置換することによりビットベクトルを結合できる場合にビットを結合できる。従って、いくつかの実施形態において、そのような結合はほぼ相関されるビットに対して行われる。

そのような不可逆結合の一例は、００００００１１００を００００００１１１０と結合することである。そのような方法の利点は、データの圧縮がより適切であることであるが、欠点は、道路区分が最速経路の一部であることを追加の１が示すため、更なる道路区分がビットベクトルを使用して経路指定方法により評価されることである。

可逆的結合の場合、閾値は０である。閾値を増加することにより更なる領域を結合することが可能になるが、いくつかのビット１をビットベクトルに導入する。しかし、閾値が小さく維持される場合、閾値は、経路指定がデータ形式を使用して実行される際の速度にほぼ何も影響を及ぼさない。例えば２ビットが１ビットのベクトル以外の数千個のビットベクトルにおいてほぼ常に同一である場合、これは、より多くのビットを結合することを可能にするために異なるものであるこの一意のビットベクトルを変更するために受け入れ可能であってもよい。閾値が大きい程、より高い地図圧縮を期待できる。

ビットの再順序付け
いくつかの実施形態において、上述したようにビットが結合されると、ビットは再順序付けされてもよい。ビットの再順序付けは、符号化するビット数（ハフマン符号化前の）を減少しないが、ハフマン符号化をより効率的にすることを助長し、従って地図のサイズを縮小する。ビットの再順序付けは、ビットベクトルハフマン符号における別個の符号の数を減少することを更に助長し、従ってハフマン木に要求されるメモリを減少する。

ビットの結合とは異なり、ビットの再順序付けはヒューリスティック法であるため、適切な再順序付けを見つけるが、最善の再順序付けを見つけない可能性がある。

ビットベクトルはブロックにより符号化される。ブロックサイズは、カスタマイズ可能であり、地図ヘッダ８００に格納される。以下の説明において、一例として、ブロックサイズは１１ビットに設定される。ビットベクトルのビット数は１１で割り切れない可能性があるため、最後のブロックは１１ビットより小さい可能性がある。最後のブロックは、１１ビットの完全なブロックに対するハフマン木とは異なるハフマン木を使用する。各ビットベクトルを符号化することにより、以下を符号化する。

・１１ビットのブロック（この例において）に対するハフマン符号を使用するいくつかの完全なブロック
・１１ビット未満が残っている時に別のハウマン符号を使用する最後の１つのブロック
以下の図は、２つの領域（結合後、異なるビット数を有する）のビットベクトルを有するブロックによりハフマン符号化するビットを示す。

領域毎にハフマン木を有することはメモリに関して高価すぎる可能性がある。従って、いくつかの実施形態において、同一のハフマン木が全ての領域に対して共有される。相関したビットが各領域において異なるため、各領域のビットを再順序付けでき、その結果、相関したビットは全ての領域の同一位置に体系的に置かれる。従って、全ての領域にわたりハフマン木を共有することは更に効率的になる。

領域毎にビットを再順序付けするテーブルは地図データに格納される。尚、ビットを結合するための別個のテーブル及びビットを再順序付けするための別個のテーブルを符号化する必要はなく、その代わりに双方の変換（結合＋再順序付け）の合成である１つのテーブルのみを符号化できる。

完全なブロックのビットを再順序付けする方法は以下のように進む。領域毎に、最も相関したビット対を見つける。完全に相関したビットが既に結合されているため、残りのビットで完全に相関されたものは存在しない。しかし、いくつかのビット対は他のビット対より相関される。最も相関したビット対（ａ，ｂ）は第１の完全なブロックのビット＃０及び＃１に再マッピングされる。

最も相関したビット対をグループ化した結果、完全なブロックのハフマン木はより少ない別個の符号（データを格納するのにより少ないメモリを使用するという利点を有する）を有し、統計はより偏る（これにより、ハフマン符号化がより効率的になる）。ランダムなビットシーケンスを含むのではなく、例えば最初の２ビットは殆どの場合が００又は１１を含み、１０又は０１を含むものはほぼない（他のビットについても同一である）。ビットを再順序付けせずに、最初の２ビットは全ての種類のパターン００、０１、１０、１１を含む。

最初の２ビットを再マッピングした後、方法は、次に最も相関したビット対（ｃ，ｄ）を見つけ、それらを再マッピングして第２のブロックの最初の２ビットに格納する。

方法は、次に最も相関したビット対（ｅ，ｆ）を見つけ、それらを再マッピングして第３のブロックの最初の２ビットに格納する。

最後の完全なブロックに到達すると、方法は最初の完全なブロックに戻り、次に最も相関したビット対（ｇ，ｈ）を再マッピングする。いくつかの対が同一の相関性を有する場合、タイブレーカは、同一ブロックの前の対と最も相関した対（すなわち、（ａ，ｂ）と最も相関した対）を選択する。

アルゴリズム方法は、完全なブロック中の全てのビット対が再マッピングされるまで上記のように進む。

この例において、ブロックサイズが奇数のビット数（１１ビット）を有するため、再マッピングされていないビットが完全な各ブロックに依然として存在する。方法は、「ｚ」と最も相関したビットを見つけ、それを第１のブロックに格納する。その後、Ｂと最も相関したビットを見つけ、それを第２のブロックに格納する。全ての完全なブロックが再マッピングされるまでこのような処理を行う。

この時点で、全てのビットが完全なブロックに再マッピングされる。方法は、最後のブロックのビットを再マッピングし、完全なブロックに対して行ったように最も相関したビット対をグループ化しようとする。最後のブロックのビットを再順序付けすることは、地図のサイズを縮小することを助長できるが、以下の２つの理由により完全なブロックのビットの再順序付けほどは助長しない。

・完全なブロックの方が重要である。この例において、各符号は、完全なブロックに対して３つのハフマン符号を使用するが、一方、最後のブロックに対しては１つのハフマン符号しか使用しないため、完全なブロックが最後の不完全なブロックより全体の地図のサイズに寄与していることは普通であり、完全なブロックのハフマン符号化を最適化することがより有用である。

・最も相関したビットを全て既に選択してそれらを完全なブロックに再マッピングしたため、最後のブロックにおける再マッピングする残りのビットの相関性はより低い。従って、最後のブロックのビットのエントロピーは、完全なブロックのビットのエントロピーより高い。換言すると、最後のブロックのハフマン符号化は、完全なブロックのハフマン符号化ほど効率的ではない。

尚、全ての領域の全ての完全なブロックに対して、同一のハフマン木が使用される。上記例におけるビットベクトルを符号化することにより、同一のハフマン符号を使用して全ての完全なブロックを符号化し、最終的に異なるハフマンコーデックにより最後のブロックを符号化する。

方法が各ブロックの最初のビットを再マッピングする（第２のブロックに進む前に第１のブロックの全てのビットを再マッピングするのではなく）理由は、上記図面を見ることにより明らかである。同一のコーデックが全ての完全なブロックに使用されるため、全てのブロックに対する全ての符号を可能な限り同一にすることが望ましい。第１のブロックの全てのビット、次に第２のブロックの全てのビット（等）を再マッピングする場合、各ブロックは非常に異なるパターンを有する。すなわち、第１のブロックは最も相関したビットを有し、第２のブロックはより相関性の低いビットを有し、第３のブロックは更に相関性の低いビットを有する。完全なブロックの各列に対していくつかのハフマンコーデックを作成できるが、これはメモリに関して高価すぎると考えられる。ここまで概略を示した方法は、適切に動作する一方で、全ての完全なブロックに対して同一のハフマンコーデックを共有する。

可能な他の最適化
この節では、データを更に圧縮するために更なる実施形態において使用されてもよい最適化について説明する。

ページのページ
ページ情報は、各ビットベクトルページの開始オフセットを見つけるために使用されるデルタフィールドを格納する。デルタフィールドは、オフセットの線形補間を使用して格納される。しかし、小さなノードＩＤ（レベル０、高速自動車道路）の周囲のビットベクトルがより大きいノードＩＤ（レベル５、行先道路）の周囲のビットベクトルより多くのビットを必要とするため、オフセットはそれ程線形ではない。図１５のグラフは、３００個の領域を含むベネルクスの地図に対するデルタフィールドを示す。

補間が実際のオフセットを正確に予測しないため、ビットベクトルページ情報の符号化は要望される程の利点を有さない。補間を向上することにより、ビットベクトルページ情報テーブルの符号化を向上し、より効率的にすることができる。

本発明のいくつかの実施形態は、１つのレベルではなく２つのレベルを有するビットベクトルページ（及び可能性として領域ページ）を使用してもよい。データをグループ化する２^ｎ個のノードのページ（これらをサブページと呼ぶ）は、２^Ｎ個のサブページのページにグループ化される。

従って、線形補間パラメータは、グローバルではなくページ毎に格納される（ヘッダに）。例えば指標レベル２は、サブページの最初の方で２^４＝１６個のノードをグループ化してもよく、指標１はページ中のそれらのサブページの２^１０＝１０２３個のノードをグループ化してもよい。線形補間は、全体のノード数（ヨーロッパ及びロシアの地図の５０，０００，０００個のノード）に対してではなく、１０２４＊１６＝１６Ｋ個のノードに対して行われるため、可変サイズオフセットの線形補間ははるかに正確になり、指標２のデルタフィールドはより小さくなる。

ページが大きい（メモリに適合するのに十分に小さい）場合、追加の指標１のサイズは小さい。装置のメモリ内に適合可能であることは、データを使用する経路指定を遅くしないため有利である。平均ページサイズをヘッダに格納するのではなく、平均ページサイズは指標１のテーブルの全てのエントリに対して格納される。

ビットベクトルページのインタリーブ
上述したように、ビットベクトルが重要な道路（多くの非自明なフラグ）及びあまり重要でない道路（多くの自明なフラグ）に対して異なるため、ページオフセットに対する補間は正確でない。補間をより線形にする１つの単純な方法は、種々のネットワークレベルのページをインタリーブすることであり、これは本発明の実施形態において使用されてもよい。

上記実施形態において説明したファイルは以下のページを格納する。
＃０
＃１
＃２
＃３
＃４
・・・
＃ｎ−３
＃ｎ−２
＃ｎ−１
より効率的である可能性のある他の実施形態において、以下のようにインタリーブして格納できる。
＃０
＃ｎ−１
＃１
＃ｎ−２
＃２
＃ｎ−３
＃３
＃ｎ−４
・・・
ページ＃ｘにアクセスする（例えば、経路計画アプリケーションにより）ために、ページはページ＃ｘ’をロードすることによりアクセスされる。

・ｘ’ ＝ ２ ＊ ｘ （ｘが偶数の場合）
・ｘ’ ＝ ２ ＊ （ｘ − （ｎ − １）） （ｘが奇数の場合）
このような一実施形態は、ページ毎に数ビットずつ指標付けのサイズを縮小するため有利である。しかし、データは、キャッシュするためにより不適切にグループ化される可能性があるため、データアクセスを遅くする可能性がある（ファイルシステムキャッシュにおいてヒット数が少なくなる）。

全てのノードに対する領域ＩＤの非格納
領域ＩＤは、末端のノード及び２つの連結道路区分を有するノードに対して格納される必要はない。これらのノードは経路指定に対して無視される。これらのノードのうちの１つに行くことは、近傍の決定ノードに行くことに変換される。

ページレベル及び／又はノードレベルにおける追加の情報の格納
地図データを見ると、自明なビットベクトル０００．．．０００又は１１１．．．１１１のみを含むビットベクトルページが多く存在する。いくつかの実施形態は、ページに印をつけるためにそれらページ毎に１ビットを格納してもよく、そのビットベクトルが０００．．．０００であるか又は１１１．．．１１１であるかを示すためにビットベクトル毎に単一ビットのみ必要とするため、ビットベクトルをそれらのページに格納することはより効率的になる。これは、自明なビットベクトルのみを含むページのサイズを縮小するだけでなく、非自明なビットベクトルを有するページに対してビットベクトル符号のハフマン木をより適切に最適化する（これらの符号の頻度のパーセント値が非常に増加するため、非自明なベクトルを示すためのビット数は減少される）。より精細なネットワークレベル（例えば、レベル３）において、殆どのページは自明なビットベクトルのみを含むため、約半分のページにおいてページ毎に１つのビットベクトルのみが存在する可能性がある。

決定ノードのビットベクトルのみの格納
上述したように、いくつかの実施形態は、１つ又は２つの連結道路区分を有するノードに対するビットベクトルを格納しなくてもよい。しかし、他の実施形態は、より積極的であってもよく、決定ノードの周囲のビットベクトルのみを格納する概念を一般化してもよい。

決定ノード及び決定道路区分の概念は、地図データの符号化に関して利点を有するため導入される。すなわち、次に説明するように、ビットベクトルは非決定道路区分に対して符号化される必要はない。

・決定ノードは、ノードを出る（Ｕターンをせずに）複数の選択肢があるように経路指定するための進入道路区分が存在するノードである。

・非決定ノードは、決定ノードでないノードである。従って、経路指定の出発地に関係なく、ノードを出る出口が常に１つのみ存在する。

・決定道路区分は、決定ノードを出るのに合法な道路区分である。

・非決定道路区分は、決定道路区分でない道路区分である。

全ての決定道路区分は、決定ノードの周囲にある。しかし、決定ノードの周囲にある全ての道路区分が決定道路区分ではない。非決定ノードの周囲にある全ての道路区分は非決定道路区分である。

ビットベクトルは、決定道路区分に対してのみ符号化される。データを使用する経路決定技術が道路区分に既に存在する情報から判定できるため、ビットベクトルは、非決定道路区分に対して黙示的である（０００．．．０００又は１１１．．．１１１）。

ノードが決定ノードであるかを判定する方法は？緩和できる基準は以下の通りである。
ｉｓＤｅｃｉｓｉｏｎＮｏｄｅ＝（ｌｉｎｅＣｏｕｎｔ＞＝３）＆＆（ｌｉｎｅＧｏｉｎｇＯｕｔＣｏｕｎｔ＞＝２）
式中、ｌｉｎｅＣｏｕｎｔは、経路指定不可能な線の種類（鉄道、基準線）を無視し、双方向に閉じた線を無視し、且つ通り抜け禁止道路（住宅エリア）を無視するノードに連結された線の合計である。ｌｉｎｅＧｏｉｎｇＯｕｔＣｏｕｎｔは、ノードを出るために利用するのに合法であるノードに連結された線の数である。

ノードを出るためにある道路区分を利用するのが合法か否かは、以下の道路区分属性に依存する。

・道路区分の種類（鉄道＆基準線は常に違法である）
・道路の順方向／逆方向の流れ（道路区分フラグに格納される）
・道路区分フラグの通り抜け禁止属性（通り抜け禁止道路区分はいずれのビットベクトルも有さない）
いくつかの実施形態において、非決定道路区分を無視することは、約４０％の道路区分を廃棄できる。このパーセント値は、地図に関係なく非常に安定していることが分かっている。自明なビットベクトルを主に除去するため、ビットベクトルの４０％の符号化を回避することは利点であるが、節約される地図のサイズは４０％未満である。

３つ未満の連結道路区分を有するノード（ダミーノード）の周囲のビットベクトルを除去することにより、非自明なビットベクトルが除去されるため、このカテゴリの非決定道路区分に対する地図のサイズの節約は非決定道路区分に対する節約より大きい。一方、フィルタリングは、復号器（地図を使用する経路指定方法等）が道路区分の種類及び線の道路区分フラグを復号化し且つ黙示的であるビットベクトルを計算するためにそれらに論理を適用することを必要とする。これは、処理を遅くする可能性がある。

理論上、実施形態は、退出道路区分が合法であるかを決定するために操作（すなわち、右左折制限）に着目するが、そのような技術は複雑さを増す。操作を無視することは、実施形態が厳密に必要な数より多くのビットベクトルを符号化してもよいが方法の単純化が達成されることを意味する。

非決定ノードの例
ａ−−＜−＞−−ｂ−−＜−＞−−ｃ
この例において、（ｂ）は双方向にナビゲート可能である２つの道路区分に連結される。＜＝２個の連結道路区分が存在するため、（ｂ）は決定ノードではない。

従って、ノード（ｂ）を出る双方の道路区分のビットベクトルは符号化されない。復号器は、それらを１１１．．．１１１に黙示的に設定できる。
ａ−−＞−−ｂ−−＜−＞−−ｃ
｜
＾
｜
ｄ
この例における矢印＞は、フローの合法な方向を示す。出口が１つのみ存在するため、（ｂ）は決定ブロックではない。従って、（ｂ）の周囲のいずれの道路区分もビットベクトルを必要としない。

ノード（ｂ）を出る道路区分（ｂ）−＞（ｃ）に対するビットベクトルは符号化されず、黙示的に１１１．．．１１１となる。（ｂ）を出る違法な道路区分に対するビットベクトルも符号化されず、黙示的に０００．．．０００となる。

決定ノードの例
ａ−−＜−＞−−ｂ−−＜−＞−−ｃ
｜
＾
｜
ｄ
（ｂ）は、（ｄ）から来る場合に選択肢があるため決定ノードである。すなわち、経路指定は（ａ）又は（ｃ）に向かって継続可能である。

尚、この例において、（ａ）から来る場合、選択肢はない。すなわち、経路指定は（ｃ）に向かってのみ継続可能である。しかし、ノード（ｂ）は、（ｄ）から来る場合に少なくとも選択肢があるため依然として決定ノードである。従って、ビットベクトルは、ノード（ｂ）の周囲の２つの決定道路区分に対して格納されるべきである。

道路区分（ｂ）−＞（ａ）及び道路区分（ｂ）−＞（ａ）が決定道路区分であるため、ビットベクトルはこれらの道路区分に対して格納される。

交通の逆方向／順方向の流れによると道路区分（ｂ）−＞（ｄ）を利用するのは違法であるため、ビットベクトルはこの道路区分に対して格納されない。これは、黙示的に０００．．．０００である。

ビットベクトルの論理和
ノードが３つの連結道路区分を有し、最初の２つの復号化道路区分が以下のビットベクトルを有すると仮定する。

００００００００００００００００００００
００００００００００００００００００００
第３のビットベクトルは、以下の通りであるため符号化される必要はない。

１１１１１１１１１１１１１１１１１１１１
これは、ノードａの周囲の道路区分のビットベクトルがこの順序で現れる場合にのみ動作可能である。すなわち、全てのビットベクトルが０００．．．０００であり、最後のビットベクトルが１１１．．．１１１である。実際には、これはより精細なレベル（例えば、レベル３）のネットワーク（殆どの道路区分が存在する）において非常に頻繁に現れると考えられる。

最初の２つのビットベクトルは以下の通りとする。

０００００００００００００００００１１０
００００００００００００００００００１０
第３のビットベクトルは、未知であり且つ何らかの方法で符号化される必要がある２ビット以外の全てのビットを１に設定できる。

１１１１１１１１１１１１１１１１１？？１
上記例において、殆どのビットが既知であるため、ビットベクトル全体を符号化するより効率的に２つの未知のビットを符号化するためにこの情報を使用できるべきである。従って、この例において、２ビットを符号化すればよい。

このプロパティを使用する可能な高速復号化方式は、道路区分の全ての先のビットベクトルの論理和をとることにより現在のノードの道路区分の全ての復号化ビットベクトルのビットマスクを計算することである。上記と同一の例を使用して、ノードが３つの連結道路区分を有する場合及び先の２つの道路区分が以下のビットベクトルを有する場合、
０００００００００００００００００１１０
００００００００００００００００００１０
ＯＲビットマスクは以下の通りである。

０００００００００００００００００１１０
ノードの周囲の符号化する第３の最後のビットベクトルを以下の通りとする。

１１１１１１１１１１１１１１１１１００１
極めて稀な１１１１１１１１１１１１１１１１１００１のハフマン符号を符号化する代わりに、符号器は、以下の場合に他のあらゆる符号（ｏｔｈｅｒＣｏｄｅ）を自由に符号化できる。

ｖａｌｕｅ＿ｔｏ＿ｅｎｃｏｄｅ ＝ 〜ｂｉｔＭａｓｋ ｜ ｏｔｈｅｒＣｏｄｅ
この例において、ｏｔｈｅｒＣｏｄｅ＝０００００００００００００＊０００００００は、以下が成り立つために適格である。

ｖａｌｕｅ＿ｔｏ＿ｅｎｃｏｄｅ ＝ １１１１１１１１１１１１１１１１１００１ ＝ 〜０００００００００００００＊００００１１０ ｜ ０００００００００００００＊０００００００
００００００００００００００００００００の頻度がより高いため、００００００００００００００００００００を符号化することは、１１１１１１１１１１１１１１１１１００１を符号化するより非常に効率的である。復号化は、ビットベクトルを復号化する時は常にビットマスク（又は動作）を計算し且つ最後に復号化されたビットベクトルにビットマスクを適用すればよいため、復号化は速い。

実際のビットベクトル＝ビットマスク＆復号化ビットベクトル
＝〜０００００００００００００００００１１０ ＆ ００００００００００００００００００００
＝１１１１１１１１１１１１１１１１１００１
この最適化は、ノードの周囲の道路区分が最後の領域において殆どが１であるビットベクトルの道路区分を有するように格納される場合に適切に動作する。しかし、これは困難である。

・ノードの周囲の道路区分の格納は、ビットベクトルの計算前に行われる（再符号化するためにビットベクトル情報を帰納的に使用しない限り）。

・道路区分は道路名で既にソートされている。道路名が特定される場合、ノードの周囲の道路区分をソートできる。

ネットワークレベルの使用
領域のレベルに加えて、地図データ内の道路区分は道路区分レベルに従って分類される。出発ノードの周囲において道路区分ネットワークレベルとビットベクトルとの間には強い相関性がある。すなわち、一般に別の領域までの経路指定は、高速自動車道路等の高いレベルの道路区分ネットワークを利用するのを好む。最も重要な道路区分ネットワークレベルは、高速自動車道路レベルである可能性が高く、これはレベル１であってもよい。

以下の例は、異なるネットワークレベルにおける道路区分との交差点を示す。

４
｜
｜
１＝＝＝＝＝＝＝２＝＝＝＝＝＝＝３
線（２）−＞（１）は、ネットワーク４（重要）にある。
線（２）−＞（３）はネットワーク５（あまり重要でない）にある。
線（２）−＞（３）はネットワーク５（あまり重要でない）にある。

ビットパターンは以下のようになる可能性が高い。
２ １ ？？？？？？？？？？？？
２ ３ ？？？？？？？？？？？？
３ ４ ００００００００００００。

非重要道路区分ネットワークレベルのノードに対するビットベクトルの非格納
経路指定は、目的地又は出発地に近接する場所以外ではネットワークレベル５等の非重要道路区分ネットワークレベルをほぼ通過しない。従って、レベル５のビットベクトルを格納しないことが可能であり、従ってレベル５の道路区分数が多くても経路指定への影響は最小である。殆どの場合の経路指定は、いくつかの更なる重要な道路区分ネットワークレベルに迅速に到着するため、経路の開始又は終了において最も重要でないネットワークレベルの道路区分を殆ど探索しない。これらのノードに関する探索加速データは、最も重要でないネットワークレベルに戻るナビゲート区分をスキップし且つより重要なネットワークレベルに通じるか又は入るナビゲート区分を使用するようにルータにほぼ常に伝える。目的地が依然として遠い場合に最も重要なネットワークレベルが使用されるため、このことは、そのネットワークレベルにおいて当てはまる。

最も重要でない道路区分（例えば、レベル５）におけるビットベクトルをドロップすることに加えて、そのネットワークにおいて領域ＩＤを符号化しないことも可能である。

ビットベクトルのいくつかの０の１への変換
これは、不可逆圧縮方式である。

ビットベクトルが１つの０だけ（又は可能性として小さい閾値未満）を含む場合、以下の結果（すなわち、その道路区分を最速経路の一部になるように設定する）が得られる場合はそれを１に変換できてもよい。

・自明なビットベクトル１１１．．．１１１（自明なビットベクトルは非自明なビットベクトルよりコンパクトに符号化されるため）
・現在のビットベクトルページの履歴で既に見つけられたビットベクトル（より効率的に符号化されるため）
ビットベクトルにおいて０を１に変換することは経路指定結果に影響を及ぼさず、経路指定がより多くの道路区分を考慮するようにすることにより遅くなるだけである（最速経路の一部になるように設定されるため）。しかし、特に経路指定の速度に関して性能への悪影響が小さく、地図の節約が大きい場合、本発明のいくつかの実施形態はこの方法を採用してもよい。

経路指定
図１５は、従来のＡ＊探索方法により探索された複数の道路区分と共に開始ノード１６０２及び行先ノード１６０４を有し且つあるエリアを範囲に含む地図１６００を示す。選択された経路を点線１６０６で示す。

図１６は、図１５の地図と同一エリアを範囲に含み且つ同一の開始ノード１６０２及び行先ノード１６０４を示す地図１６５０を示す。図１６は、図１５の経路を生成するために使用したのと同一の道路ネットワーク及び基準（例えば、双方とも自動車で移動され、最小にするコスト関数として速度を使用することを要求する）を利用した本発明の一実施形態を使用して探索された道路を強調表示する。方法により選択された経路は、点線１６０６で示され、その線は図１５で算出されたものと同一である。従って、本発明の実施形態により算出された経路は、いわゆる数学的に正確であり、最小になるように選択された所定のコストモデルに関して最善／最適な経路を見つける。従って、本発明の実施形態により探索された道路区分は、従来技術と比較して非常に少ないことが明らかである。本発明の実施形態の方法は、従来のＡ＊方法より高速であり、一般にははるかに高速である。

尚、経路１６０６が目的地１６０４に近づくと開始時と比較してより多くの経路が探索される。すなわち、経路１６０６が地点１６５２を越えて進む場合、最小コスト経路以外に道路が探索される。この１つの説明としては、方法が地点１６５２においてレベル０領域からレベル１領域に切り替わったからである。目的地１６０４付近で更なる道路区分が探索されることが更に分かるだろう。ここでも、これは、経路計画方法がこの付近でレベル１からレベル２に切り替わったことを指摘することにより説明できる。

従って、長い範囲での経路指定の場合、一般に最速経路は１つのみ存在する。しかし、方法がより精細なレベルに切り替わると（例えば、レベル０から１に）、「最小コスト」として印がつけられ且つ従って探索される必要がある経路が２つ以上存在してもよい。

地図データが作成され、ビットベクトルが算出及び格納されると、２つの地点間の経路を算出するのに使用される。

図１７は、ネットワークが経路計画アプリケーションにより探索される従来のＡ＊方法を示す。ここで、ノードにおいて更に探索する道路区分に関する決定が行われる。これを達成するために、次のノードまで移動するためのコストは、次のノードから目的地まで移動するための推定されたコストに追加される。所定のノードからの最小コストを有するパスは、更に探索される。方法が進み且つ各繰り返しにおいて最小コストが考慮されるため、方法はそれまでに発生したコストの合計を保持する。

例えば、ノードＢから開始すると、双方のノードＣ及びＤは開始ノードであるＢから２コスト単位だけ離れていることが分かる。しかし、ノードＤからノードＦに到達するための推定コストは３単位であり、ノードＣからノードＦに到達するための推定コストは５単位である。従って、Ａ＊方法は、次のノードまでのコスト＋目的地までの推定コストがノードＤまでの道路区分に対してより少ないため（すなわち、ＢＣ＝２＋５＝７であるが、ＢＤ＝２＋３＝５である）、ノードＣへの経路よりノードＤへの経路を好んで探索する。

経路計画が本発明の実施形態のビットベクトルを使用して実行されることを考慮すると、道路区分毎のビット（すなわち、図７の列７０４）は、行先領域までの最小コスト経路の一部となる候補である道路区分を特定する。従って、図１７に関連して説明したＡ＊方法は修正され、図１８に示した方法が得られる。

一般に経路計画は、図１８に関連して説明するようなビットベクトルを使用して実行される。しかし、本発明のいくつかの実施形態は、種々の状況下において経路計画がＡ＊（又は他の従来の方法）にフォールバックすることを可能にしてもよい。種々の実施形態は、以下のうちのいずれかを利用してもよい。すなわち、ビットベクトル情報が失われていること（これにより、ビットベクトルがない場合でもシステムは機能できる）、コスト関数が使用されること、ビットベクトルが算出されたコスト関数以外の経路指定（一般に最速経路であるが必ずしも最速経路である必要はない）、ユーザがビットベクトルを事前計算するのに使用された基準と異なる基準を指定すること（例えば、ユーザは高速自動車道路を回避したい）、乗り物の種類がビットベクトルの事前計算に使用されたものと異なる（例えば、ユーザは自動車ではなく徒歩である）こと、及び経路が閾値の長さを下回ること（例えば、経路の開始点及び終了点が同一領域内にある）である。

図１７と比較して、２つの追加の数字１８００、１８０１を図１８に示す。更に領域は、図１８において破線１８０２及び１８０４により示される。「１」１８００は、道路区分ＢＤがノードＢから目的地ノードが位置する領域までの１つの低コスト経路の一部であることを示す（他で説明するように、更に他の低コスト経路が存在してもよい）。「０」１８０１は、道路区分ＢＣがノードＢから目的地ノードが位置する領域までのいずれの低コスト経路の一部でないことを示す。

従って、ノードＡから開始すると、本発明の実施形態は、上記で概略を示したＡ＊を使用してＡからノードを探索する。しかし、ノードＢに到達すると、道路区分ＢＤのみが最小コスト経路の一部である可能性があることの明示的な表記があるため、探索を更に使用する必要はない。従って、Ａ＊方法が使用され、最小コスト経路を見つけると、次にビットベクトル内の関連ビットを見ることにより最小コスト経路を選択する。

しかし、種々の最小コストパスが異なる時間において一対の領域の間に存在する場合、最小コストデータは、その対の領域間で２つ以上の最小コストパスを特定してもよい。従って、例えば道路区分ＢＤ及びＢＣに対する数字１８００及び１８０１が、各道路区分が特定の時間において最小コストパスの一部であることを示す値「１」を有する場合、開始ノードと目的地ノードとの間（起点と目的地との間）の経路指定は、２つ以上の最小コストパスを見つけてもよく、競合する最小コストパス間で判定する必要がある。本実施形態において、ビットベクトルは、各道路区分が最小コストパスの一部である時間を特定しない。そのため、経路指定アルゴリズムは、パスの区分を移動する時間に基づいて双方の可能な最小コストパスに対してコスト解析を実行する。この時間は、起点／開始ノードからの出発時間から判定されてもよい。

図１０ａに示すように、区分中の推定移動速度がどのように計時変化するかの速度プロファイルは各区分と関連付けられる。これらの速度プロファイルから、関連する時間における推定速度が判定され、これは、その時間にその道路区分を移動するためのコストを判定するために使用される。各最小コストパスの道路区分を移動するためのコストを合計することにより、各最小コストパスに対するコストが判定される。ナビゲーション装置は、その時間に対する最小コストを有する最小コストパスを経路に選択してもよい。

ここまで説明した経路指定を実行するために、ビットベクトル情報は、復号化処理を使用して図８〜図１０に関連して説明した符号化副ファイルから取得される。

上述した前処理の出力は以下を含む。

・殆どのノードに対する階層領域の割り当て
・これらのノードにおける退出道路区分に対するビットベクトルの割り当て
地図のロード
一貫性検査
地図データがロードされる場合、副ファイルの集合は地図ディレクトリに存在すべきであり、存在しない場合、復号器は経路探索が探索加速データなしで実行されるように探索加速データを非アクティブにする。データ完全性を保証するのを助長するいくつかの検査がある。これを一覧表示する。

副ファイルは命名規則に従う。

レベルの数は副ファイルの数により与えられるが、各副ファイルのヘッダにも格納され、副ファイルの数に等しい。

各副ファイルは、副ファイル名で指定されたレベルと同一の各レベルの領域数を格納する。更に副ファイルは、全ての副ファイルに対して同一であるべき以下の情報を格納する。

・副ファイルのバージョン
・「ビットベクトルページ」（以下に説明する）毎のノード数
各副ファイルには、以下を特定するチェックサムが存在する。

・全体の特定の副ファイル集合
・全体の地図
これらは、所定の電子地図に対して関連付けられた副ファイルに対して正確であるべきである。上記検査のいずれかが失敗した場合、探索加速データプロパティはこの地図に対してアクティブにされない。

メモリにロードされるデータ構造
復号器は、外部メモリの実現例の副ファイルを読み出す。これは、ビットベクトル副ファイルのコンテンツがメモリに完全にロードされず、必要に応じてのみ読み出されることを意味する。しかし、ある一般的なデータは最初にメモリにロードされ、地図がロードされる限りそこに保持される。

ヘッダ情報
各副ファイルは、図８〜図１０に関連して上述したデータを含むヘッダセクションで開始する。この情報は、副ファイル毎にメモリに格納される。

ハフマン木の定義
副ファイルは、いくつかのハフマン木の定義を含む。ハフマン木の各定義は、特定のハフマン符号化の完全な記述を与え、副ファイルビットストリームの一部を元のデータに復号化するために（すなわち、副ファイルのビットシーケンスを数字又は他のある特定の値に復号化するために）後で使用される。以下のハフマン木の定義は、各副ファイルから読み出され且つメモリに保持される。

・各ノードにおいて道路区分数を復号化するためのハフマン木。（符号化された道路区分数は、基礎となる地図の道路区分数より少ない。尚、復号器は基礎となる地図とは無関係である。すなわち、地図を読み出す必要はない。）このハフマン木は、レベル０の副ファイルにのみ格納される。

・ページ符号を復号化するためのハフマン木（以下に説明する）。

・ビットベクトルブロックを復号化するためのいくつかのハフマン木。木の定義数は、副ファイルヘッダに格納されるような正規のビットベクトルのブロックの長さにより与えられる。これはブロックの長さ−１に等しい。（道路区分に対するビットベクトルのビット列全体はブロックに分割される。ビットベクトルのビット列の長さが正規のブロックの長さの倍数でない場合、最終的なブロックはより短い。２〜正規のブロックの長さまでのブロックの長さ毎に１つのハフマン木が存在する。長さ１のブロックの場合、これは単に１ビットであり、直接格納されるため、ハフマン木は使用されない。）
・ビットベクトルに対して復号化方法を選択するためのいくつかのハフマン木。これらの木の数はヘッダで指定される。その使用については以下に説明する。

近傍リスト
最も精細なレベル以外の各レベルにおいて、副ファイルは近傍リストを符号化する。レベルｋにおける領域の近傍リストは、レベルｋ領域の近傍領域と呼ばれる０個以上のレベル（ｋ＋１）領域のリストである。レベルｋの副ファイルの近傍リストセクションは以下の２つの部分を有する。

・第１の部分は、各レベルｋサブ領域に対する近傍領域の数を含む。例えば（ｋ＝１）、グローバルレベル０において４０００個の領域があり、各グローバル領域が１０個のレベル１領域に細分される場合、レベル１の副ファイルは４０００＊１０個のレベル１サブ領域を含む。これらの各々に対して、個別の近傍リスト（レベル２領域から成る）の長さが与えられる。

・第２の部分は、長さが第１の部分から既知である実際の近傍リストを含む。各近傍リストはレベル（ｋ＋１）サブ領域のリストである。

従って、近傍リストは、所定の行先領域に対して、その行先領域の可視エリアにある領域を指定する。地図データを使用するナビゲーション装置に対して可視エリアの範囲を特定する指標が提供される。探索加速データを使用する経路計画は、探索されるナビゲート可能区分を制約するのに使用可能な行先領域が更なる探索加速データを利用できるかを特定でき、それにより経路計画の速度を向上する。

領域再マッピングテーブル
副ファイルは、例えば結合及び再順序付け等により圧縮形式でビットベクトルを格納する。レベルｋの副ファイルは、ブロックにより符号化されたビットベクトルを伸張するのに使用される領域再マッピングテーブルを有する。これは以下の２つの部分から成る。

・第１の部分は、レベルｋサブ領域により指標をつけられる配列である。レベルｋのサブ領域毎に、圧縮ビットベクトルの長さを含む。これは、ビットベクトルがブロックにより符号化される各サブ領域におけるノードの退出道路区分にとって有意義である。

・第２の部分は、（１）非圧縮ビットベクトルのビット位置及び（２）レベルｋサブ領域により指標をつけられた２次元配列である。配列のエントリは、ブロックにより読み出された非圧縮ビット列の所定のビット位置に対する圧縮ビットベクトルのビット位置を指定する。

尚、第１の部分のみがメモリに保持される。第２の部分は、大きいため、復号化中に要望に応じてのみ使用される。現時点で、領域再マッピングテーブルはグローバルレベルの副ファイル（ｋ＝０）にのみ格納される。

経路クエリの開始
復号器は、出発位置から行先ノードの集合までの経路探索を加速するために使用される。（目的地が２つ以上のノードから成る一例は、全体の道路の広がりが目的地として使用される場合である。）行先ノードは１つ以上の目標領域の集合を規定する。

尚、目標領域は領域ＩＤのシーケンスであり、各領域ＩＤは各区分レベルに対するものであり、レベル０から開始する。新しい探索の各々の開始時、目標領域の集合は、先の目標領域集合をクリアし且つ新しい行先ノードを復号器に渡すことにより構築される。復号器は、重複のない目標領域のリストを判定する。所定のノードの領域を見つける機構は探索と同一であり、詳細については以下を参照。

経路探索中のノードの走査
残りの説明は、目標領域の集合が設定されたと仮定する。復号器の特徴は、道路ネットワークのノードＩＤを仮定すると、このノードを出る道路区分にわたり指標をつけられるビット配列（このノードに対するビットベクトル及び所定の目標領域）を返す関数である。ノード及びあるノードにおける道路区分の順序付けは、地図により規定される。ビット値が０である場合は必ず、これは対応する道路区分が探索中に無視されることを意味する。（通常、これにより探索空間は大きく減少され、従って探索の実行時間が短縮される。）
少数のノードの場合、領域情報もビットベクトルデータも副ファイルに格納されない。これらのノードに対して、復号器は全てのビットが１であるビット列を返す。（これにより、経路探索がこのノードにおける道路区分をスキップすることを防止する。）復号器は、これが所定のノードに当てはまるかを示すブールクエリ関数を有する。更に所定のノードが先に固定された目標領域の１つに配置されるかを示すブールクエリ関数が存在する。目標領域のノードに対して復号器により返されたビットベクトルは、ここでも全てのビットが１であるビット列である。これらのブールクエリ関数は経路探索における最適化のために使用される。

副ファイル形式に従って、所定のノードに対するビットベクトルデータはいくつかのステップで復号化される。各副ファイルにおいて、領域及びビットベクトル情報は、いわゆるページに編成される。ページ毎のノード数は２の既定の累乗（例えば、１６）であり、副ファイル集合の副ファイル毎に同一である。これは、所定のノードＩＤに対してビットベクトルページのページ指標が単純なビットシフトにより計算されることを意味する。ノードの情報は、ノードＩＤで連続して格納される。

所定のノードに対するページオフセットの検索
ページ毎の平均バイト数は、副ファイル毎に副ファイルのヘッダに格納される。これは、ページ指標を平均サイズと乗算することによりページのバイトオフセットを近似するために使用される。修正項は、ページ指標により指標をつけられたテーブルに格納される。このテーブルは、副ファイルの別個のセクションに格納される。ページがクエリされると、修正項は、テーブルでルックアップされ且つ近似ページオフセットに加算され、それにより副ファイルにおけるページの位置が与えられる。

ページの復号化
キャッシュ
ページが初めてクエリされる場合、ページのノードに対するビットベクトル列は復号化され（固定の目標領域集合に関して）且つキャッシュされる。次に同一ページのノードに対してデータがクエリされると、キャッシュされたデータはいずれの副ファイルにもアクセスせずに使用される。復号化されたビットベクトルのビット列の特別なマーカビットは、ノードが非情報ノードであるかを記憶するために使用される。

ページ符号
いわゆるページ符号ビットは、ページの全てのノードが同一の領域ＩＤを有するかをページ毎に指定する。ページ符号はレベル毎に１ビットを含むが、全てのビットは、レベル０の副ファイルのページ開始時にのみ共通のハフマンシンボルとして格納される。

退出道路区分数の復号化
上述したように、各ページは固定のノード数に対する情報を含む。このノード数は、各副ファイルのヘッダに格納される。ページの開始時（又はレベル０の場合はページ符号の後）、ページはページの各ノードに対する退出道路区分数を一覧表示する。退出道路区分数が０である場合は常に、これは対応するノードに対して情報が全く格納されていないことを意味する。ページが復号化される間、数字は一次配列に格納される。
領域の復号化
道路区分数セクションの後、領域セクションが続く。ノードの領域は、レベル毎に１つである領域ＩＤのシーケンスにより与えられる。特定のレベルの領域ＩＤは、対応する副ファイルに格納される。復号器は、ページの全てのノードに対して全てのレベルの領域を読み出す。ノードに対して情報が格納されていない場合（すなわち、ノードの道路区分数が０である場合）、領域情報は空のままである。復号器は、０より大きい道路区分数を有する第１のノードに対する領域ＩＤシーケンスを読み出す。全ての領域ＩＤが所定のレベルで同一であるとそのレベルのページ符号が指定する場合、そのレベルにおいて、同一の領域ＩＤが全てのノードに対して設定される。指定しない場合、対応するレベルの領域ＩＤが正の道路区分数の全てのノードに対して読み出される。この処理の終了時、復号器はページの全てのノードに対する完全な領域ＩＤシーケンスでテーブルを埋めている（いくつかのシーケンスは空であってもよい）。

ビットベクトルの復号化
関連するビット位置の集合の検索
所定のノード及び目標領域に対して、特定のレベルの特定のビットは、そのノードを出る道路区分に対するビットベクトルのビットの値を判定する。２つ以上の目標領域がある場合、結果として得られるビットの論理和がとられる。ノード毎に、復号器は関連するビット位置の集合を計算する。関連するビット位置の集合は、そのノードの退出道路区分毎に同一である。これは、ノードの領域及び目標領域の集合にのみ依存する。目標領域が１つだけ存在する場合、１つのレベルにおいて関連するビット位置は１つだけ存在する。換言すると、他のレベルで格納された情報は、このノードに関しては無視される。２つ以上の目標領域がある場合、関連するビット位置の一部は一致するため、最大で存在する目標領域と同数の関連するビット位置が常に存在する。以下において、復号器が１つの目標領域に対する関連するビット位置を判定する方法について説明する。２つ以上の目標領域がある場合、関連するビット位置は、同様に見つけられ、１つの集合に組み合わされる。

近傍領域が規定されない場合、各レベルの目標領域毎にビットベクトルのビットが１つ存在する（退出道路区分毎に）。（簡潔にするために、ノード自体の領域ＩＤに対してビットが格納されないということを無視する。）関連するビットは第１のレベルにあり、ノードの領域ＩＤが目標領域の領域ＩＤと異なるレベル０からカウントアップする。例えばグローバルレベルのノードの領域ＩＤがグローバルの目標領域ＩＤと等しいが、２つの領域ＩＤがレベル１で異なる場合、関連するビット位置はレベル１にあり、目標領域ＩＤと等しい。これは、そのレベルの非圧縮ビットベクトル列のビット位置である。この列は、可能な目標領域ＩＤ毎に１ビットを含む。領域再マッピングテーブルは、この位置を実際にはそのレベルで符号化される圧縮ビットベクトル列の位置に変換するために使用される。

近傍領域が規定される（すなわち、可視エリア内の領域）場合、関連するビットは、目標領域がノードの領域の近傍にある「最も精細な」レベルで判定される。４つのレベルを一例として利用して、目標領域ＩＤシーケンスを（ａ，ｂ，ｃ，ｄ）とし、ノードの領域ＩＤシーケンスを（ｅ，ｆ，ｇ，ｈ）とする。近傍リストセクションで規定されるように（ａ，ｂ，ｃ，ｄ）が（ｅ，ｆ，ｇ）の近傍にあり、（ａ，ｂ）が（ｅ）の近傍にある場合、関連するビットは（ａ，ｂ，ｃ，ｄ）により判定され且つレベル２で配置され、接頭辞（ｅ，ｆ，ｇ）のレベルは近傍にあるものとして（ａ，ｂ，ｃ，ｄ）を含む。より詳細には、関連するビット位置はレベル２の副ファイルにおける領域（ｅ，ｆ，ｇ）の近傍の（ａ，ｂ，ｃ，ｄ）の指標である。前の段落で説明したように、領域ＩＤ ｈに対する正規のビットはこの場合は関連がない。ここでも、この関連するビット位置は、非圧縮ビットベクトル列に対するものである。復号器は、領域再マッピングテーブルを使用して、それをレベル２の圧縮ビット列のビット位置に変換する。近傍リストに関するより多くの情報は、文献「Ｐｒｏｐｏｓａｌ ｆｏｒ ｅｎｈａｎｃｅｄ ｍｕｌｔｉ−ｌｅｖｅｌ ｇｒａｐｈ ｐａｒｔｉｔｉｏｎｉｎｇ」に含まれる。

ビットベクトルのビットの復号化
固定の目標領域の集合を仮定すると、ページの各ノードのビットベクトルは退出道路区分毎に１ビットから成る。ノードの道路区分数が０である場合（すなわち、ノードが非情報ノードである場合）、各ビットは、そのノードに対して更に復号化を行わずに１に設定される。ノードが目標領域の１つに配置される場合、ここでもビットベクトルは全て１である。この場合、符号化データは、後続するノードに対するデータを復号化するためにスキップされる必要がある。

現在のノードに対するビットベクトルが単純に全て１でない場合、上述したように、復号器は関連するビット位置の集合を判定する。各ビット位置は、特定のレベルに対するものである。すなわち、ビットは特定の副ファイルに配置される。各レベルにおいて、副ファイルは完全な圧縮ビット列を含むが、復号器は関連するビット位置においてのみビットを抽出する必要がある。復号化中、実際に必要な情報が後続する時のみ、未使用の情報は読み出される（スキップされる）。そうでない場合、ビットストリームの未使用部分は全く読み出されない。

関連するビット位置の集合は、レベルに従ってグループ化される。圧縮ビット列を復号化し且つ関連する位置でビットを読み出すためにそれを伸張する代わりに、関連する位置は圧縮ビット列の位置に変換される。あるレベルにおいて関連するビットが存在する場合、最初に、先行ノードに対するデータが適宜スキップされる（復号器は、それがどの程度遠くから来たものかを各レベルの副ファイルに記憶する）。所定の副ファイルにおいて当該ノードに対するセクションに到達すると、ビットベクトルは線毎に復号化される。退出道路区分毎に１ビットが格納される。これは、全ての関連するビット位置に対する復号化ビットの論理和演算の結果である。現在のノードの特定の道路区分に対する情報は、復号化方法を指定するハフマンシンボルから開始する。これは以下の値のうちの１つを有する。

・このレベルにおける道路区分に対する全てのビットベクトルのビットが０であることを指定するシンボル（このレベルにおける全ての近傍ビットを含む）。この道路区分に対して、これ以上ビットが復号化される必要はない。

・このレベルにおける道路区分に対する全てのビットベクトルのビットが１であることを指定するシンボル（このレベルにおける全ての近傍ビットを含む）。この道路区分に対して、これ以上ビットが復号化される必要はない。

・ビットベクトルのビット列がブロックにより明示的に与えられることを指定するシンボル。ブロックによる圧縮ビットベクトルのビット列の復号化については以下に説明する。道路区分に対するビットベクトルのビットは、ページ全体の符号化中に構築される「履歴トラック」に入れられる。

・履歴トラックへの指標を指定するシンボル。所定の指標において、履歴トラックは道路区分に対する所望のビットベクトルのビット値を含む。

履歴トラックの現在のサイズに依存して、復号化方法セレクタのための異なるハフマン木が使用される。ハフマン木の数を指定する限界値が副ファイルのヘッダにある。履歴トラックのサイズがこの値を越える場合、最後のハフマン木が再利用される。

ビットベクトル列が明示的に符号化されるべきであることを方法セレクタシンボルが指定する場合、復号器は圧縮ビットベクトルのビット列をブロック毎に読み出す。これは、このレベルにおける関連するビット位置（圧縮ビットベクトル列に対する）のビット値を収集する。ビットの値の論理和がとられる。論理和の中間結果が１になるとすぐに、この道路区分に対する全ての更なるブロックの残りのビットがスキップされる。各ブロックを復号化するために使用されるハフマン木はブロック中のビット数に依存する。副ファイルヘッダで指定されるように、正規のブロックの長さに対して１つのハフマン木が存在する。道路区分に対する最後のブロックはより短くてもよい。そのサイズに依存して、復号化のために適切なハフマン木が使用される。長さ１のブロックは１ビットであり、ハフマン復号化を使用せずに直接読み出される。

ブロック数が少なくとも２である場合、ビットベクトルから生成されたビットストリームはブロックに対するハフマンシンボルの前に追加のビットを含む。その値は、復号化列全体が実際の値のビット毎の否定となると理解されるかを指定する。（この否定の目的はより適切なハフマン圧縮である。）
探索方法に関する注釈
従来のダイクストラ及びＡ＊探索方法は探索木を生成し且つ従って木探索の例と呼ばれてもよいが、所定のナビゲート可能区分を根とする一般的な経路探索は探索が実行されるネットワークのサブネットワークを構成する有向非周期グラフを一般に生成してもよいこと、並びにその有向非周期グラフに含まれたいずれの所定のナビゲート可能区分に対してもその区分と探索の根との間に１つ以上の最小コスト経路が存在することが当業者には理解されるだろう。従って、探索木又は木探索に関して説明する場合、この概念は探索の結果として得られる有向非周期グラフに一般化される。

例えば、地図中のナビゲート可能区分に対して速度値を提供する時変関数を使用すると、所定のナビゲート可能区分と探索の根との間に２つ以上の最小コスト経路が存在するため、そのような探索は木探索ではなく有向非周期グラフを使用する。

Claims (15)

1. それぞれが電子地図によってカバーされるエリアにおいてナビゲート可能な経路の区分を表す複数のナビゲート可能区分を含む前記電子地図を処理するために、少なくとも１つの処理装置を用いて、前記電子地図にわたって経路を計画する際の速度を向上するように構成された探索加速データを含む地図データを作成する方法であって、
   前記処理装置が、
   前記電子地図を複数の領域に分割する工程と、
   前記電子地図の領域内で前記複数のナビゲート可能区分の少なくともいくつかに対してビットベクトルを生成するために前記複数のナビゲート可能区分を処理する工程であって、前記ビットベクトルは複数のビットを含み、それぞれのビットが前記ナビゲート可能区分が他の前記領域の１つへの最小コストの経路の一部であるかどうかを示す工程と、
   前記探索加速データを圧縮するために前記領域に対する生成された複数の前記ビットベクトルを処理する工程であって、当該圧縮は複数の前記ビットベクトルの複数の前記ビットの相関性を計算し、前記計算した相関性に従って前記複数のビットを結合する工程と
   を実行することを特徴とする方法。
2. 前記圧縮は、さらに、前記計算した相関性に従って複数の前記ビットベクトルの複数のビットを再順序付けすることを含むことを特徴とする請求項１に記載の方法。
3. 前記圧縮は、さらに、複数の前記ビットベクトルをハフマン符号化することを含むことを特徴とする請求項１又は２に記載の方法。
4. 各ナビゲート可能区分がそれぞれの階層レベルの少なくとも１つの領域に分類されるように、前記電子地図が複数の階層化領域へ分割されることを特徴とする請求項１乃至３の何れか１項に記載の方法。
5. 時変関数が少なくともいくつかのナビゲート可能区分、一般的には各ナビゲート可能区分に関連付けられ、
   前記時変関数は、前記ナビゲート可能区分が複数の異なる時刻での他の複数の前記領域の１つへの最小コストの経路の一部であるかどうかを決定するために使用されることを特徴とする請求項１乃至４の何れか１項に記載の方法。
6. 前記生成されたビットベクトルの前記複数のビットのそれぞれは、前記ナビゲート可能区分が前記複数の異なる時刻での他の複数の前記領域の１つへの最小コストの経路の一部であるかどうかを示すことを特徴とする請求項５に記載の方法。
7. ナビゲート可能区分に関連付けられる前記時変関数は複数の時間間隔での前記ナビゲート可能区分の平均速度を表すことを特徴とする請求項５又は６に記載の方法。
8. 複数のナビゲート可能区分のコアネットワークを形成するために、複数の区分を除去することによって、前記探索加速データの作成時に考慮される前記複数のナビゲート可能区分の数を減少させる工程をさらに含むことを特徴とする請求項１乃至７の何れか１項に記載の方法。
9. 前記探索加速データの作成前に、少なくとも１つの以下の工程に従って、前記電子地図からナビゲート可能区分を除去し、
   前記以下の工程は、
   （ｉ）道路プロパティに関連する所定の基準を満たすナビゲート可能区分を除去する工程と、
   （ｉｉ）所定の状況においてナビゲート可能区分の間の分岐点に存在するノードを他方のノードにまとめる工程と、
   （ｉｉｉ）ノードが２つ以下のナビゲート可能区分を接続させる場合に当該ノードを他方のノードにまとめる工程と
   を含むことを特徴とする請求項８に記載の方法。
10. 前記電子地図の前記複数のナビゲート可能区分のそれぞれが、それぞれに関連する複数のノードを有し、前記ナビゲート可能な経路のパラメータを表す少なくとも１つの関連する属性を有し、
    ナビゲート可能区分に関連付けられる少なくとも１つの前記属性は、
    （ｉ）前記ナビゲート可能区分の種類と、
    （ｉｉ）前記ナビゲート可能区分に沿った平均速度と、
    （ｉｉｉ）前記ナビゲート可能区分の長さと、
    （ｉｖ）他のナビゲート可能区分に対する前記ナビゲート可能区分の接続性と
    の何れかを含み、
    前記ナビゲート可能区分のそれぞれの分類が、前記ナビゲート可能区分に関連付けられる前記複数のノードが前記電子地図の前記複数の領域にわたって均衡されることを保証すべく、少なくとも１つの前記属性の評価を使用することを特徴とする請求項１乃至９の何れか１項に記載の方法。
11. 前記最小コストの経路は、最短距離、最短移動時間、最小の環境への影響、最小の使用燃料、及び最小の生成ＣＯ_２のコスト基準の１つに従って決定されることを特徴とする請求項１乃至１０の何れか１項に記載の方法。
12. 前記生成されたビットベクトルの第１の複数のビットのそれぞれが、前記ナビゲート可能区分が第１のコスト基準に従って他の複数の前記領域の１つへの最小コストの経路の一部であるかどうかを示し、
    前記生成されたビットベクトルの第２の複数のビットのそれぞれが、前記ナビゲート可能区分が第２のコスト基準に従って他の複数の前記領域の１つへの最小コストの経路の一部であるかどうかを示すことを特徴とする請求項１乃至１１の何れか１項に記載の方法。
13. それぞれが電子地図によってカバーされるエリアにおいてナビゲート可能な経路の区分を表す複数のナビゲート可能区分を含む前記電子地図を処理するために、少なくとも１つの処理装置を用いて、前記電子地図にわたって経路を計画する際の速度を向上するように構成された探索加速データを含む地図データを作成するコンピュータデバイスであって、
    前記少なくとも１つの処理装置は、
    前記電子地図を複数の領域に分割し、
    前記電子地図の領域内で前記複数のナビゲート可能区分の少なくともいくつかに対してビットベクトルを生成するために前記複数のナビゲート可能区分を処理し、前記ビットベクトルは複数のビットを含み、それぞれのビットが前記ナビゲート可能区分が他の前記領域の１つへの最小コストの経路の一部であるかどうかを示し、
    前記探索加速データを圧縮するために前記領域に対する生成された複数の前記ビットベクトルを処理し、当該圧縮は複数の前記ビットベクトルの複数のビットの相関性を計算し、前記計算した相関性に従って前記複数のビットを結合する
    ように構成されることを特徴とするコンピュータデバイス。
14. コンピュータデバイスで読み取られると、請求項１乃至１２の何れか１つに記載の方法をコンピュータデバイスに実行させる命令を含むコンピュータプログラム。
15. 請求項１４に記載のコンピュータプログラムを記憶したコンピュータで読取可能な記憶媒体。

Images