JP4148580B2 - ナビゲーションシステムと共に実時間交通情報放送を使用する方法及びシステム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、ナビゲーションシステムにおいて、交通及び道路状態の実時間放送を使用するシステム及び方法に関し、詳しく述べれば、本発明は、地理データベースを使用するナビゲーションシステムにおいて、交通情報放送データの使用及び協調を容易にし、実施するシステム及び方法に関する。
【０００２】
【従来の技術】
若干の地方及び大都市圏、及び国においては、交通及び道路状態情報の極く最新の報告を放送するシステムが実現されている。これらのシステムは、交通及び道路状態情報を連続的に、定期的に、または頻繁に放送する。これらの放送は、その地方を走行しているビークルに搭載された受信機によって受信することができる。搭載受信機は放送をデコードし、報告内の情報をビークルの運転手が利用できるようにする。
【０００３】
これらの交通報告放送システムは、ラジオ局を通して簡単な交通情報を放送するよりも幾つかの利点を有している。例えば、これらの交通放送システムによって運転手は情報をより迅速に入手することができる。運転手は、ラジオ局が交通情報を放送するまで待つ必要はない。これらの交通放送システムの別の利点は、運転手は彼／彼女が居る位置から離れた領域の交通状態の情報を聞く必要がないことである。交通放送システムの別の利点は、より詳細な、そして多分より最新の情報を入手できることである。
【０００４】
これらの型のシステムでは、放送される交通情報は、１つまたはそれ以上の予め確立された仕様またはフォーマットに準拠している。これらの仕様またはフォーマットは、その領域内を走行しているビークルに搭載された受信機によって使用され、交通報告メッセージがデコードされる。
【０００５】
実時間交通及び道路状態を放送する１つのシステムは、無線データシステム・交通メッセージチャンネル（ Radio Data System - Traffic Message Channel :“ＲＤＳ−ＴＭＣ”）である。ＲＤＳ−ＴＭＣシステムは、若干の欧州諸国で使用されている。ＲＤＳ−ＴＭＣシステムに関しては、“ Radio Data System, CENELEC END50067:1996, Specification of the Radio Data System."を含むいろいろな刊行物に記載されている。ＲＤＳ−ＴＭＣシステムは、ＦＭ局データチャンネルを使用して交通メッセージをビークルに放送する。ＲＤＳ−ＴＭＣメッセージは、イベントの優先順位に依存して定期的に、または変化する間隔で放送される。他の諸国及び領域においても同じような、または同一のシステムが使用されているか、または計画されている。
【０００６】
交通渋滞の位置を識別するために、現在使用されている、並びに近い将来のために計画中の交通及び道路状態放送システムは、カバーしている領域内の位置にコードを割当てる。例えば、ＲＤＳ−ＴＭＣシステムでは、カバーしている地理領域内の道路に沿う特定位置に、位置参照コードを割当てる。これらの位置は、交差点、インターチェンジ、または道路の一部分であることができる。次いで、これらの位置に関係する交通状態を識別するデータメッセージが放送される。一般的に言えば、これらの位置は、高速道路及び主要道路のような交通量の多い道路に関係付けられる。
【０００７】
運転手を援助するために開発された別の分離した技術は、ビークルナビゲーションシステムである。ビークルナビゲーションシステムは、ビークルの運転手、その他にいろいろなナビゲーティング特色を提供する。ビークルナビゲーションシステムによって提供される特色は、交通放送システムによって提供される特色とは異なっている。例えば、ナビゲーションシステムは、運転手のために特定のルートを計算することができる。運転手のために計算されたルートは、カバーしている地理領域のどの街位置から開始することもでき、カバーしている地理領域内の他のどの街位置に位置する目的地をも有することができる。ビークルナビゲーションシステムは、運転手にルート案内をも提供することができる。ルート案内機能は、運転手のためのルート計算に特定であることもできる。ルート案内機能は、そのルートを辿って走行している運転手に対して可聴的に、または視覚的に運転操作（以下、単に運転という）命令を供給することができる。ナビゲーションシステムは、ビークルの現在位置から２マイル以内の全てのイタリアンレストランのような、所与の探索領域内の特定の型の１つまたはそれ以上の目的地を見出すような他の特色を提供することもできる。これらの種類の機能を提供するために、ナビゲーションシステムは、ビークル内に位置しているか、または無線通信リンクを通してアクセス可能な詳細な地理データベースを使用する。
【０００８】
交通放送システムも、ナビゲーションシステムも、運転手に対して貴重な特色を提供することができる。しかしながら、もし交通放送報告内のデータをナビゲーションシステム特色と共に使用すれば、さらなる有用な特色を提供することができる。例えば、もしナビゲーションシステム内のルート計算機能を使用してルートを計算する時に、交通メッセージ内のデータが使用できれば有利である。不幸にも、ＲＤＳ−ＴＭＣシステムのような交通放送システムによって放送される報告内のデータは、ナビゲーションシステムによって使用されるデータに関係付けられていない。例えば、交通放送システムのオーソリティによって割当てられた位置番号は、ナビゲーションシステムによって使用される地理データベース内のデータレコードによって表される何等かの物理的特色に直接関係付けられてはいない。
【０００９】
従って、放送される交通情報を、地理データベースを使用するビークルナビゲーションシステムと共に使用する要望が存在している。
【００１０】
【発明の要旨】
上述した諸問題に対処するために、地理データベースを使用するナビゲーションシステムが、交通放送システムによって放送される交通メッセージ内のデータをも使用できるようにしたシステム及び方法が提供される。本実施例の一つの面は、ナビゲーションシステムによって使用される地理データベース内の位置参照データレコードの形成、格納、及び使用を含む。これらの位置参照データレコードは、道路のセグメントを表すデータレコードのような物理的地理特色を表す若干の他の種類のデータレコードを、若干の位置参照番号に関連付けることによって識別する。これらの位置参照データレコードは、ビークル内に設置された地理データベース内に含ませることも、または無線通信リンクを通してビークルに供給することもできる。
【００１１】
本実施例の別の面は、交通放送システムによって使用される位置参照番号を、ナビゲーションシステムによって使用される地理データベース内の位置参照データレコードに関連付ける１つまたはそれ以上の索引の形成、格納、及び使用を含む。
【００１２】
本実施例の別の面は、位置参照データレコードを、パーセルで形成、格納、及び使用することである。
【００１３】
本実施例の更に別の面は、各位置参照番号毎に、直前及び直後の位置参照番号を識別するデータを形成、格納、及び使用することである。
【００１４】
本実施例の更に別の面は、地理データベースを照会し、若干の識別された位置参照番号に関連するデータエンティティを戻すプログラミング、及びその使用方法を含む。
【００１５】
本実施例の別の面は、地理データベースを使用する多くの異なる型の交通メッセージシステムを支援する能力である。
【００１６】
本実施例の別の面は、地理データベースを使用するナビゲーション応用へ送信される実時間交通データの使用を支援する地理データベースを含む。実時間交通データを送信する手段は、放送及び直接伝送のような無線伝送の形状、並びに、電話及びデータ回線のような非無線伝送の形状である。
【００１７】
【実施例】
Ｉ．交通放送システム − 概要
図１は、ある地域１０を示す図である。地域１０は、ニューヨーク大都市圏、ロスアンジェルス大都市圏、または他の何れかの大都市圏のような大都市圏であることができる。代替として、地域１０は、カリフォルニア、イリノイ、フランス、イングランド、またはドイツのような州（ステート）、プロビンス、または国であることもできる。代替として、地理領域１０は、１つまたはそれ以上の大都市圏、州、国、等々であることができる。地域１０内には、道路網１２が位置している。
【００１８】
交通放送システム２０は地域１０内に位置している。交通放送システム２０は地域１０内の交通及び道路状態に関するデータ５０を放送する。交通放送システム２０は、政府機構によって動作させることも、または私企業が動作させることもできる。一実施例では、交通放送システム２０はＲＤＳ（ラジオデータシステム）標準に準拠しているが、代替システムを使用することができる。
【００１９】
ビークル１１（Ａ）、１１（Ｂ）、１１（Ｃ）、・・・、１１（ｎ）は、地域１０内の道路網１２上を走行している。ビークル１１は、乗用車またはトラックを含むことができる。若干の、または全てのビークル１１は、交通放送システム２０によって放送される交通及び道路状態を受信可能な適当な機器を含む。
【００２０】
交通放送システム２０から放送されるデータ５０は、ビークル内に設置されていないシステム（例えば、「非ビークル８０」）においても受信され、使用される。これらの非ビークル８０は、ワークステーション、パーソナルコンピュータ、パーソナルディジタル支援、ネットワーク、ページャ、テレビジョン、ラジオ受信機、電話機、等々を含むことができる。データ５０を受信する非ビークル８０はビークルと同じようにして、即ち放送によってデータを入手することができる。代替として、非ビークル８０は、電話回線を通して、インターネットを通して、ケーブルを介して、等々のような他の手段によってデータ５０を受信することができる。交通データ５０を受信するビークル１１内の、または非ビークル８０内のシステムは、いろいろな異なるプラットフォームを含むことができる。
【００２１】
図２は、図１の交通情報放送システム２０の成分、及びビークル１１の１つを示している。交通情報放送システム２０は、交通及び道路状態に関するデータを集め、これらの集めたデータを解析して編成し、解析したデータを交通メッセージにフォーマットして地域１０内のビークル１１にこれらの交通メッセージを定期的に及び連続して送信するようになっている。
【００２２】
交通放送システム２０は、いろいろなセンサ２２から地域１０内の交通及び道路状態に関するデータを集めるための機器及びプログラミング２０（１）を含んでいる。この機器及びプログラミング２０（１）は、例えば、いろいろな通信リンク（無線リンクを含む）、受信機、データ記憶デバイス、集めたデータを保管するプログラミング、データを集めた時刻及び位置をログするプログラミング、等々を含む。交通放送システム２０は、集めた交通及び道路状態データをアセンブルし、編成し、解析し、そしてフォーマットするための機器及びプログラミング２０（２）を含んでいる。このプログラミング及び機器２０（２）は、記憶デバイス、集めたデバイスを潜在的なエラーについて統計的に解析するプログラミング、集めたデータを編成するプログラミング、データを使用して１つまたはそれ以上の適切な所定のフォーマットでメッセージを準備するプログラミングを含む。交通放送システム２０は、データを放送するための適当な機器及びプログラミング２０（３）をも含んでいる。機器及びプログラミング２０（３）は、送信機へのインタフェース、フォーマットされたメッセージを定期的な間隔で送信機へ通信するプログラミング、等々を含む。交通放送システム２０は、送信機器２０（４）をも含んでいる。この機器２０（４）は、アンテナを含む１つまたはそれ以上のＦＭ送信機、または他の無線送信機からなることができる。この機器２０（４）は、フォーマットされたメッセージを、その地域１０全体の交通及び道路状態データ５０として放送するようになっている。放送機器２０（４）は、交通放送システム２０の一部であることも、または代替として、放送システム２０はセルラまたはページングシステム、ＦＭラジオ局、等々のような他の型のシステムからの放送機器を使用して、地域内のビークル１１へ交通メッセージを放送することもできる。（本明細書の目的及び特許請求の範囲から、交通メッセージの放送は、直接無線伝送を含むどのような伝送の形状をも含むものとする。）
図３は、交通メッセージ５０の１つのデータ成分を示している。交通メッセージ５０は、いろいろな種類の情報を含むことができる。交通メッセージ５０が含むことができる情報の１つの有用な種類は、交通渋滞に関するものである。交通渋滞に関する情報を提供するために使用する場合、交通メッセージ５０は、渋滞している道路に沿う１つまたはそれ以上の位置、渋滞がどれ程酷い状態にあるのか、及びその渋滞がどれ程遠くまで伸びているかを識別するデータを含む。
【００２３】
図３に示す実施例においては、交通メッセージ５０は、以下のデータ成分を含む。即ち、イベント記述５０（１）、位置５０（２）、方向５０（３）、範囲５０（４）、持続時間５０（５）、及び助言５０（６）である。代替実施例では、交通メッセージ５０は、他の情報５０（ｎ）を提供する成分を含むこともできる。
【００２４】
イベント記述成分５０（１）は、交通問題５０（１）（１）を、この交通問題５０（１）（１）の酷さのレベルを記述するデータと共に記述するデータを含んでいる。
【００２５】
位置成分５０（２）は、交通問題５０（１）（１）の位置を識別する参照番号を含んでいる。
【００２６】
方向成分５０（３）は、影響されている交通の方向を指示するデータを含んでいる。
【００２７】
範囲成分５０（４）は、位置５０（２）に対する交通渋滞の列の長さを識別するデータを含んでいる。範囲成分５０（４）は、交通状態の別の（例えば、二次位置）範囲を、その間の位置参照の数の表現で暗示的に定義する。
【００２８】
助言成分５０（６）は、迂回ルートの推奨を提供する。
【００２９】
一実施例によれば、交通メッセージ５０は、ＲＤＳ−ＴＭＣシステムに確立されているＡＬＥＲＴ−Ｃメッセージのための標準フォーマットに準拠している。例えば、ＲＤＳ−ＴＭＣシステムにおいては、メッセージ５０の位置５０（２）部分はＲＤＳ−ＴＭＣコード５１内に含まれる。ＲＤＳ−ＴＭＣコード５１は、位置番号５１（１）、位置テーブル番号５１（２）、国別コード５１（３）、及び方向５１（４）を含んでいる。位置番号５１（１）は、１つの位置テーブル（即ち、番号のデータベース）が対応しているある地域に独特の番号である。位置テーブル番号５１（２）は、分離した各位置テーブルに割当てられた独特の番号である。国別コード５１（３）は、位置番号５１（１）によって参照される位置が位置している国を識別する番号である。方向５１（４）は、双方向性、及びセグメントがその合流点の外部にあるか否かのようなファクタを斟酌する。ＲＤＳ−ＴＭＣコード５１は、ある列内のメッセージ５０内で以下のように発表されている。
【００３０】
ＡＢＣＣＤＥＥＥＥＥ
ここに、
Ａ：道路セグメントの方向（＝方向５１（４））、
Ｂ：国別コード（＝国別コード５１（３））、
ＣＣ：位置データベース番号（＝位置テーブル番号５１（２））、
Ｄ：ＲＤＳ方向（＋、−、Ｐ、Ｎ）（＝方向５１（４））、
ＥＥＥＥＥ：位置コード（＝位置番号５１（１））。
【００３１】
地域１０内の、適切な機器を搭載しているビークル１１は、これらの交通メッセージ５０を受信することができる。これらのメッセージ５０は、これらのビークル内の運転手または乗客に提供することができる。
【００３２】
II. ビークル搭載ナビゲーションシステム − 概要
再び図２に戻って、図２は図１のビークル１１の１つの成分を示している。前述したように、ビークル１１は乗用車またはトラックであることができる。ビークル１１に搭載されているのは、ナビゲーションシステム１１０である。ナビゲーションシステム１１０は、ハードウェア及びソフトウェア成分の組合せである。一実施例では、ナビゲーションシステム１１０は、プロセッサ１１２、プロセッサ１１２に接続されているドライブ１１４、及びナビゲーション応用ソフトウェアプログラム１１８及び多分他の情報を格納する不揮発性メモリ記憶デバイス１１６を含んでいる。プロセッサ１１２は、日立ＳＨ 1、インテル 80386、インテル 960、モトローラ 68020のような、フラットアドレス空間を使用する 32 ビットプロセッサ（または類似の、またはより大きいアドレス空間を有する他のプロセッサ）のような、ナビゲーションシステムに使用されるどのような型であることもできる。これら以外の型、及び近い将来開発されるかも知れないプロセッサも適している。
【００３３】
ナビゲーションシステム１１０は、測位システム１２４を含むこともできる。測位システム１２４は、ＧＰＳ型技術、推測型システム、またはこれらの組合せ、または他のシステム（これらは全て当分野においては公知である）を使用することができる。測位システム１２４は、ビークルの走行距離、速度、方向、等々を測定する適当な感知デバイス１２３を含むことができる。測位システム１２４は、当分野において公知の手法でＧＰＳ信号を入手する適切な技術を含むこともできる。測位システム１２４は、信号をプロセッサ１１２へ出力する。測位システム１２４からの信号は、プロセッサ１１２上で走るナビゲーション応用ソフトウェア１１８によって使用され、ビークル１１の位置、方向、速度、等を決定することができる。
【００３４】
ビークル１１は、交通メッセージ受信機１２５を含んでいる。受信機１２５は、交通放送システム２０が交通メッセージ５０を放送するのに使用している適切な周波数に同調させたＦＭ受信機であることができる。受信機１２５は、交通放送システム２０から交通メッセージ５０を受信する。（セルラ無線伝送を介してのような直接無線伝送によって交通メッセージが送られる代替実施例では、ビークル１１内の受信機１２５は、セルラ電話機に類似、または同一であることができる。）以下に詳細に説明するように、受信機１２５は、ナビゲーションシステム１１０内の適切なプログラミングがナビゲーション機能を遂行する時に、交通放送システム２０によって放送されたデータを利用することができるように、出力をプログラミング１１２へ供給する。
【００３５】
ナビゲーションシステム１１０は、ユーザインタフェース１３１をも含む。ユーザインタフェース１３１は、エンドユーザ（例えば、運転手または乗客）がナビゲーションシステム内へ情報を入力できるようにする適切な機器を含む。この入力情報は、ナビゲーションシステムのナビゲーション特色の使用の要求を含んでいる。例えば、入力情報は、所望の目的地までのルートに関する要求を含むことができる。入力情報は、他の種類の情報に対する要求を含むこともできる。ナビゲーションシステム１１０内へ情報を入力するために使用されるユーザインタフェース機器は、キーパッド、キーボード、マイクロホン、等々、並びに音声認識プログラムのような適切なソフトウェアを含むことができる。ユーザインタフェース１３１は、エンドユーザへ情報を戻す適当な機器も含む。この機器は、ディスプレイ１２７、スピーカ１２９、または他の手段を含むことができる。
【００３６】
ナビゲーションシステム１１０は、記憶媒体１３２上に格納されている地図データベース１４０を使用する。記憶媒体１３２は、地理領域のための適切な地図データベースを有する記憶媒体を、走行中のビークルが使用できるように取り外し可能であり、置換可能である。更に記憶媒体１３２は置換可能であるので、その上の地図データベース１４０を容易に更新することができる。一実施例では、地理データ１４０はカリフォルニア州サニービルの Navigation Technologiesから出版されている地理データベースであることができる。
【００３７】
一実施例においては、記憶媒体１３２はＣＤ−ＲＯＭディスクである。代替実施例においては、記憶媒体１３２はＰＣＭＣＩＡカードであることができ、この場合ドライブ１１４はＰＣＭＣＩＡスロットに置換される。固定またはハードディスク、ＤＶＤ、または現在市販されている他の記憶媒体、並びに近い将来開発されるかも知れない記憶媒体を含む他のさまざまな記憶媒体を使用することができる。記憶媒体１３２及び地理データベース１４０は、物理的にナビゲーションシステムの位置に設ける必要はない。代替実施例においては、地理データ１４０の若干、または全てを格納している記憶媒体１３２をナビゲーションシステムの残余から離して配置し、地理データの一部を必要に応じて通信リンクを介して供給することができる。
【００３８】
ナビゲーションシステムを動作させるためにナビゲーション応用ソフトウェアプログラム１１８は、不揮発性メモリ１１６からプロセッサ１１２に組合されているＲＡＭ２０内へロードされる。プロセッサ１１２は、ユーザインタフェース１３１からの入力も受信する。入力は、ナビゲーション情報に対する要求を含むことができる。ナビゲーションシステム１１０は、記憶媒体１３２に格納されている地図データベース１４０を、多分測位システム１２４及び受信機１３２からの出力と共に使用して、さまざまなナビゲーション特色及び機能を提供する。ナビゲーション応用ソフトウェアプログラム１１８は、これらのさまざまなナビゲーション特色及び機能を提供する分離した応用（または、サブプログラム）を含むことができる。これらの機能及び特色は、ルート計算１４１（エンドユーザによって識別された目的地までのルートを決定する）、ルート案内１４２（所望の目的地へ到達するために詳細な指示を供給する）、地図表示１４３、ビークル位置決め１４４（例えば、マップマッチング）を含むことができる。ナビゲーションシステム上のプログラミング１１８には、後述する位置参照プログラミング１４５も含まれている。これらに加えて、他の機能及びプログラミング１４６もナビゲーションシステム１１０に含ませることができる。ナビゲーション応用プログラミング１１８は、Ｃのような適当なコンピュータプログラミング言語で書くことができるが、Ｃ＋＋、または Java のような他のプログラミング言語も適当である。
【００３９】
上述した全ての成分は普通のもの（または、普通ではないもの）であり、これらの成分の製造及び使用は当分野においては公知である。
【００４０】
III. 地理データベース
Ａ．概要
一実施例では、ナビゲーションシステムの速度及び／または機能は、データを使用するシステム内のナビゲーション応用プログラム内の若干の機能によるデータの使用を容易にするために、システムが使用する地理データの格納、配列、及び／または構成の改良を含む組合せによって強化することができる。地理データを格納、配列、及び／または構成する手法に基づいて、データにアクセスしてそれを使用するナビゲーション応用プログラム内の機能は、地理データ内に組み込まれた改良を活用するルーチンを実現することができる。この組合せによって、ナビゲーションシステムの性能が総合的に改善される。
【００４１】
地図データベース１４０は、地理領域内の道路網に関する情報を含む。一実施例では、地図データベース１４０は、ノードデータ及びセグメントデータを含む。これらのデータは物理的な道路網の成分を表している。ノードデータは地理領域内の物理的位置（例えば、道路の交差点、及び他の位置）を表し、セグメントデータはノードによって表される物理的位置の間の道路の部分を表す。地理領域内の各道路セグメントは、地図データベース１４０内の道路セグメントデータエンティティ（即ち、レコード）によって表される。地図データベース内の各道路セグメントデータレコードは、道路セグメントデータレコードによって表される道路セグメントの各端における座標位置を表す２つのノードを有している。ノード及びセグメントデータエンティティ内に含まれる情報を、図４及び５に関連して以下に説明する。（用語「ノード」及び「セグメント」は、これらの物理的な地理特色を記述する唯一の用語であり、これらの特色を記述する他の用語もこれらの概念の範囲内に含まれることを意図している。）
図４は、地理領域２１２を示す地図２１０である。図４の地理領域２１２は図１及び２の地理領域１０に対応させることも、または地理領域２１２は異なる境界を有することもできる。本実施例では、交通放送システム２０が交通状態サービスを提供している地域１０（図１）は、地理データベース１４０によって表される地域２１２（図４）内に包含されている。
【００４２】
図４には、複数の位置２１４が、地理領域２１２内に位置しているように示されている。各位置２１４は、地理データベース内に情報が含まれていることが望まれる特色が位置する地理領域２１２内の場所、または点を表している。これらの各位置２１４は個々の物理的位置（緯度、経度、及びオプションとして絶対または相対高度）を有し、各位置２１４はその二次元（または、三次元）地理座標（即ち、緯度、経度、及びオプションとして高度）によって個々に識別することができる。位置２１４は、２つまたはそれ以上の道路が出会う交差点、道路の方向が変化する道路セグメントに沿う点、速度制限が変化する道路セグメントに沿う点、道路が行き止まりになる点、等々に対応させることができる。位置２１４は、ホテルまたは市民センターのような関心点の位置に対応させることも、湖のような自然特色の境界、または鉄道軌道またはフェリーに沿う位置に対応させることもできる。各位置２１４は、地理領域２１２内に物理的に位置する何かに対応させることができる。
【００４３】
図５は、地図２１０の部分２１６の拡大図である。図５の部分２１６は、地理領域２１２内の道路網２２０の一部を示している。道路網２２０は、図１及び２の道路網１２に対応させることも、または代替として、道路網２２０と１２とは異なることもできる。本実施例では、交通放送システム２０が交通状態データを提供する道路網１２は、地理データベース１４０によって表される道路網２２０内に包含されている。道路網２２０は、特に、地理領域２１１２内に位置する道路及び交差点を含んでいる。図５に地図２１０の部分２１６として示すように、地理領域２１２内の各道路は１つまたはそれ以上のセグメント２２２（１）、２２２（２）・・・２２２（ｎ）からなる。一実施例では、道路セグメントは、道路の一部分を表す。図５では、各道路セグメント２２２は、それに２つのノード２２３が関連付けられている。即ち、１つのノードが道路セグメントの一方の端における点を表し、他方のノードがその道路セグメントの他方の端における点を表している。道路セグメントの何れかの端のノードは、例えば交差点のようにその道路が別の道路と出会う位置、または道路の行き止まりの位置に対応させることができる。
【００４４】
１つの型の地理データベースでは、ある地理領域内に表されている各道路セグメント毎に、少なくとも１つのデータベースエントリ（「エンティティ」とも「レコード」とも呼ぶ）が存在する。この道路セグメントデータレコードは、道路セグメントに関連するノード、及び／または２つのノードの地理的位置（例えば、緯度及び経度座標）を識別可能にする情報（「属性」、「フィールド」等のような）を、それに関連付けることができる。更に、道路セグメントレコードは、道路セグメントレコードによって表される道路の部分の走行速度、道路セグメントレコードによって表される道路部分上で許される走行方向、道路セグメントレコードによって表される道路部分の両端における交差点に対応する各ノードにどの（もしあれば）転回禁止が存在するのか、道路セグメントレコードによって表される道路部分の街路番地範囲、道路名、等々を指定する情報（例えば、より多くの「属性」、「フィールド」等）をそれに関連付けることもできる。直線以外の道路セグメントを表す各セグメントデータエンティティは、その道路セグメントの直線以外の形状を定義する１つまたはそれ以上の形状点データ属性を含むことができる。道路セグメントに関連するいろいろな属性は、単一の道路セグメントレコード内に含ませることができ、または好ましくは、互いに相互参照し合う１つの型より多い道路セグメントレコード内に含ませる。
【００４５】
地理領域２１２を表す地理データベースにおいては、地理領域内の各ノード毎にデータベースエントリ（エンティティまたはレコード）も存在することができる。ノードデータレコードは、それに接続されている１つ以上の道路セグメント及び／またはその地理的位置（例えば、その緯度及び経度座標）を識別可能にする情報（「属性」、「フィールド」等のような）を、それに関連付けることができる。
【００４６】
Ｂ．地理データの分離したサブセット
図６は、データ型によって地理データベース１４０の編成を示す図である。いろいろなナビゲーション機能を遂行するために地理データのアクセスを強化することを可能にする１つの方法は、ナビゲーション応用プログラム１１８内の各分離した機能（例えば、１４１−１４６）によって使用される地理データ１４０の分離した集まり、即ちサブセットを設けることである。
【００４７】
これらの分離した各サブセットは、特定の１つの機能によって使用されるように合わされている。例えば、ルート計算機能１４１（図２）は、通常は、ある道路のあるセグメントに関連する地理データベース内の全ての情報の一部分しか必要としない。ルート計算機能１４１が走っている場合には、道路セグメントに沿う速度、１つの道路セグメントから別の道路セグメントへの転回禁止、等々のような情報を要求するかも知れない。しかしながら、ルート計算機能１４１は、ルートを計算するためには必ずしも道路名は必要としない。同様に、地図表示機能１４３が使用されている場合、速度制限または転回禁止のような道路セグメントに関連する情報の若干は必要ない。代わりに、地図表示機能１４３が走っている時には、道路の形状及び位置、及び多分道路名のような道路セグメントに関連する情報の一部分だけを使用する。また更に、ルート案内機能１４２が走っている場合には、速度及び転回禁止のような道路のセグメントに関連する若干の情報は不要である。代わりに、ルート案内機能１４２が走っていいる時には、この機能は、道路セグメントによって表される道路名、その道路セグメントに沿う番地範囲、その道路セグメントに沿う交通標識、等を含む情報を使用する。さまざまなナビゲーション機能が使用する情報の型に関しては若干の重なりが存在し得るが、これらのナビゲーション機能の何れか１つが使用するデータの若干は、別の機能は使用しない。もし各道路セグメントに関する全ての情報が単一のデータベース内の単一のデータエントリに関連付けられていれば、各データエンティティは比較的大きくなる。従って、ナビゲーション機能の何れか１つがエンティティレコードにアクセスすると、その機能は、殆どはそのナビゲーション機能が必要としないかなりな量の情報を、メモリ内に読み込まなければならない。更に、ディスクからデータエンティティを読み込む場合、各データエンティティが比較的大きいことから、一時に比較的僅かなデータエンティティしか読み込むことができない。
【００４８】
各ナビゲーション機能が使用するのにより効率的なフォーマットで地理データベース内の情報を提供するために、ナビゲーション応用プログラム１１８内に供給される異なる型の各ナビゲーション機能毎に、所与の地理領域の地理データベース全体の分離したサブセットが設けられる。
【００４９】
図６に、分離したルーティングデータ２３６、地図作成データ２３７（地図表示用）、運転データ２３８（ルート案内用）、及び関心点データ２３９（ホテル、レストラン、博物館、スタジアム、空港、等のような特定関心点識別用）、及び合流点データ２４０（名前のある交差点の識別用）からなる地理データベース１４０を示す。これらの型のデータの他に、地理データベース１４０はナビゲーション特色データ２４１を含むことができる。このデータのサブセットは、郵便番号２４３及び場所２４４（例えば、市、州、及び国）のためのデータサブセットを含むこともできる。一実施例では、地理データベース１４０は、後述する位置参照のためのデータ２４５の分離したサブセットを含む。地理データベースは、これらより少ない、またはより多くのサブセットを定義することができ、また他の型のデータ２４６を定義し、含むことができる。
【００５０】
データの各サブセットは、特定のナビゲーション機能が使用するために必要なデータだけを含んでいる。これらの各サブセットの間には若干の重なりが存在しており、その結果、情報の若干の部分が１つより多くのサブセット内に含まれることがあり得る。例えば、ルーティングデータサブセット２３６内の道路セグメントデータエンティティ、並びに地図作成データサブセット２３７内の道路セグメントデータエンティティが共に、セグメントの両端に位置するノードを識別する属性を含むことがあり得る。この重複によりデータ記憶要求は大きくなり得るが、より少量のデータを処理するという結果的な効率によって各ナビゲーション機能に利益がもたらされる。
【００５１】
各ナビゲーション機能毎に地理データの分離したサブセットを設ける場合、これらの各ナビゲーティング機能の使用が他のナビゲーション機能に予測できるように関係することをも考えておく。例えば、エンドユーザは、先ず現在の位置を見たいと思い、次に目的地を入力し、次に目的地に向かってどのように出発するかの命令を受け、次にルートの始めの部分を示す地図を見て、さらなる命令を受け、ルートの次の部分を示す地図を表示させたい思う、等々であろう。使用がこのように予測されるので、データをサブセットに分割すると、分離された各機能を使用する場合にデータの使用が効率的になる。
【００５２】
地理データをサブセットに分割すると、異なる各ナビゲーション機能によるデータの使用は効率的になるが、データベースのこれらの異なるサブセットを使用する異なるナビゲーティング機能を一緒に動作させることが必要になる。例えば上述した例では、計算されたルートをエンドユーザが入手した後に、計算されたルートをハイライトさせた地図をコンピュータディスプレイ上に表示させることが望ましいであろう。これを達成するために、先ず地理データのルーティングサブセット２３６にアクセスして最適ルートのためのルーティング道路セグメントデータエンティティを入手し、次に地理データベースの地図作成サブセット２３７にアクセスしてそのルーティングデータエンティティに対応する地図作成道路セグメントデータエンティティを入手する。これらのデータサブセットを一緒に動作させることができるように、相互参照、探索木、または他のデータ探索技術を提供する索引を含ませることができる。これらの索引は、何れかのデータの中に、または何れかのサブセットの外部に配置することができる。図６には、外部索引２４７が示されている。索引を、索引されるデータの外部に格納すると、いろいろなデータのサブセットの中のどのデータを次にロードするのかを決定するために索引をロードし、使用することができる。
【００５３】
Ｃ．地理データの層化
地理データを編成してそれらの使用を強化することができる別の方策は、データを層で供給することである。若干のナビゲーション機能（図２の地図表示機能１４３及びルート計算機能１４１のような）は、詳細さのレベルが異なるデータを使用することができる。例えば、地図表示機能１４３を使用する場合、パンニングまたはズーミングを行うことが望ましい場合がある。ズーミングは、もしデータが層に編成され、低い層がより詳細に、高い層はそれ程詳細ではないようになっていれば、より効率的に行うことができる。ルート計算機能１４１を使用する場合、詳細さのレベルが異なるデータを使用することも有利である。例えば、２つの位置間のルートを計算する時に、そのルートに沿う各交差点から分れる補助街路及び小道を含む全ての可能性のある道路セグメントを調べることは非効率的である。その代わりとして、あるルートが主要道路または高速道路「上」に決定された場合には、一般に、目的地が近づいて補助道路へ出る必要を生ずるまでは主要道路または高速道路上に留まることが好ましい。もしルーティングデータが層にされていれば、可能ならば、ルートを計算する時に補助道路が省かれている高い層を使用し、検査すべき可能性のある道路セグメントを最小にすることができる。従って、若干のデータ型のサブセット内では、地理データは分離した層に対応する分離した集まり、またはグループで設けられる。
【００５４】
層化を実現するために、地図データベース１４０内の各道路セグメントデータレコードは、それが表している道路の対応する部分のランクをも識別する。道路セグメントのランクは、その機能クラスに対応させることができる。ランク「４」の道路セグメントは、高速道路及びフリーウェイのような高ボリュームの、アクセスが制御されている道路を含むことができる。ランク「３」の道路セグメントは、少しの速度変化はあるが、必ずしもアクセスが制御されていない高ボリュームの道路であることができる。低くランク付けされた道路は対応する低ボリュームを取扱い、一般的には、より多くの速度変化、またはより遅い速度を有している。ランク「０」の道路は、最低のボリュームを取り扱うことができる。例えば、これらは、横路、小道、等を含むことができる。
【００５５】
道路セグメントデータエンティティのランクは、道路セグメントエンティティが含まれている最高データ層をも指定する。例えば、図７に示すように、ルーティング型データ２３６は５つの分離したデータの層Ｒ０、Ｒ１、Ｒ２、Ｒ３、及びＲ４を含むことができる。各層は、ルート計算機能が使用できる詳細さのレベルが異なるルーティングデータの分離した集まりからなる。地理データベースのルーティングデータ型では、層０（“Ｒ０”）は「０」またはそれより高いランクを有する道路セグメントデータエンティティ（及びそれらの対応するルーティングデータ属性の若干、または全て）を含む。従って、層０は、地理領域内の全ての道路の全ての部分に対応する道路セグメントデータエンティティを含んでいる。ルーティングデータ２３６の層１は、ルーティングデータの分離したサブセット（即ち、集まり）からなり、「１」またはそれより高いランクを有するルーティングセグメントデータエンティティ（及びそれらの対応するルーティングデータ属性の若干、または全て）だけを含んでいる。ルーティングデータの層２は、ルーティングデータの分離したサブセットからなり、レベル「２」またはそれより高いランクを有するルーティングセグメントデータエンティティ（及びそれらの対応するナビゲーションデータ属性の若干、または全て）だけを含んでいる、等々である。最高層（層ｎ）は、ｎのランクを有するレコードだけを含む。この実施例ではｎは４に等しく、他の実施例ではｎは０より大きいどのような数であることもできる。層が高い程含まれるレコードは少なくなるが、これらのレコードは一般的に高速で走行する道路を表している。
【００５６】
同様に、地図作成サブセット型２３７のような他の型のデータは、分離したデータの層を含むことができる。各層は、地図表示機能が使用できる異なるレベルの詳細さを含んでいる。これらの異なる層の地図作成データを使用すると、地図表示機能は迅速なパンニング及びズーミングを提供することができる。
【００５７】
若干のデータを層に編成するとデータに若干の重複をもたらすことになるが、層化によって得られる効率の増加が、一般的に何等かの欠点を相殺する。上述した分離した型のデータを使用する場合のように、これらの層を一緒に動作可能にする要望が生まれる。この目的のために、索引２４９を設けることができる。図７には、内部索引が示されている。内部索引２４９は、いろいろな型のデータの中に含まれている。
【００５８】
Ｄ．地理データベースのパーセル化
図８は、データ記憶媒体１３２上に実現された地理データベース１４０の編成を示す図である。媒体１３２上の地理データベース１４０は、ヘッダー及びグローバルデータ３２１、及び地理データ３１０を含む。ヘッダー及びグローバルデータ３２１は、データベースによって表される地域（例えば、図４の２１２）、データベースのデータの解放、どの種類のデータ圧縮（もしされていれば）が使用されているか、等々の識別のような地理データベース１４０全体に関する情報を含んでいる。地理データ３１０は、地理特色に関するデータを含む。即ち、地理データ３１０は、ルーティングデータ２３６、地図作成データ２３７、運転データ２３８、等々のような図６に表されている異なる型の地理データに対応する全てのデータを含んでいる。地理データ３１０は、図６に示した索引２４７、及び図７に示した索引２４９のような索引をも含んでいる。
【００５９】
地図データベース１４０内においては、地理データ３１０は型によって（図６に示すように）、及び層を有するこれらの型のための層によって（図７に示すように）編成されている。各型及び層内においては、データ３１０は複数のデータエンティティまたはレコードからなる。各型及び層内においては、これらのデータエンティティは複数のパーセル３２０にグループ化されている。各パーセルは、地理データ３１０の各型または層を構成している複数のデータエンティティの一部を含む。一実施例では、各パーセルのサイズは正規データサイズ、例えば 16 キロバイト、８キロバイト、等に準拠している。データレコードのパーセルへのこの編成により、地理データの格納及び検索が容易になる。一実施例では、図６に表されている、ルーティングデータ２３６、地図作成データ２３７、運転データ２３８、等々のような異なる型の地理データに対応する全てのデータが、パーセルに編成される。
【００６０】
データをパーセル化する方法が、同時出願された一連番号 08/740,295 及び 08/924,328 （ 1997 年９月５日付、代理人ドケット No. 7117-61）に開示されており、本明細書にはその開示を参照として採り入れている。
【００６１】
IV. 地理的な地図データベースを用いる交通メッセージの協調
Ａ．概要
一実施例において、交通放送システムによって放送される交通メッセージを、これも地理データベースを使用するナビゲーションシステムと共に使用することを容易にする手段が提供される。例えば、図１及び２に示す交通メッセージシステム２０を参照する。この実施例は、放送システム２０によって放送される交通メッセージ５０を、図１、２及び６−８に示す地理データベース１３２を使用するナビゲーションシステム１１０と共に使用するのを容易にする手段を提供する。放送交通メッセージを地理データベースと共に使用することによって、ナビゲーションシステムは改善されたナビゲーティング特色を運転手に提供することができる。更に、放送交通メッセージを地理データベースと共に使用することにより、従来は使用することができなかったナビゲーション特色をも提供できるようになる。交通放送メッセージを地理データベースと共に使用することの１つの重要な利点は、ナビゲーションシステム内のルート計算機能が所望の目的地位置までのルートを計算する時に、最新の交通状態を斟酌できることである。
【００６２】
交通放送システムによって割当てられた位置参照コードをナビゲーションシステムが容易に使用することができない１つの理由は、これらのコードが必ずしも何れかの既知の物理的特色に対応していないことである。例えば、関心ハイウェイに沿う位置のための位置参照コードは、任意のｎビット（例えば、20ビット）の番号であることができる。これらの番号は、それら自体は必ずしもナビゲーションシステムのエンドユーザ（例えば、マイカーの運転手）にとって何等かの意味を有するものではない。マイカーの運転手が、特定のハイウェイインターチェンジのためのｎビット位置参照コード番号を知っている筈はない。同様に、ｎビット位置参照番号を参照することによって交通渋滞の位置が識別された交通メッセージは、必ずしもエンドユーザ運転手にとって有意味の重要性を有してはいない。
【００６３】
前述したように、交通放送システムの１つの例はＲＤＳ／ＴＭＣシステムである。ＲＤＳ−ＴＭＣメッセージは、ＡＬＥＲＴ−Ｃプロトコルに準拠している。ＲＤＳ／ＴＭＣシステムでは、多くの主要な道路インターチェンジ、及び若干の二次的な道路インターチェンジは予め定義された位置番号を有している。これらの位置番号は、放送される交通メッセージの一部である。これらの位置番号は、ＲＤＳ／ＴＭＣシステムの開発及び保守を担当する道路オーソリティまたは他のパーティによって割当てられる。これらの位置番号は、全てのユーザに対して標準化されている。即ち、交通放送システムからのメッセージを使用するどの受信機も、ＲＤＳ−ＴＭＣメッセージ内の位置参照番号を、それらの番号が割当てられている既知の位置に関係付けることができるようになっている必要がある。
【００６４】
これらの型の位置番号が割当てられている場所では、位置参照番号は、特定の交通放送システムの地域データベース内で独特であり得る。このような地域データベースは「位置テーブル」として知られている。異なる各地域毎に分離した位置テーブルが定義されている。この位置テーブル地域は、図１の地域１０には対応しているが、必ずしも図４の地理領域２１２に対応し（即ち、正確に一致する境界を有し）てはいない。
【００６５】
図９は、位置参照番号がどのように割当てられるのかを示す一例である。図９の例は、ＲＤＳ／ＴＭＣシステムに類似している。図９は、道路５００の一部を示している。この道路５００は、交通放送システム２０が交通渋滞を監視し、また交通放送システム２０が交通メッセージ５０によって交通渋滞を報告する道路網１２（図１）内の道路の１つである。
【００６６】
道路５００に沿う交通渋滞が発生する位置を識別するために、位置参照番号（例えば、ＬＲ１２００５、ＬＲ１２００６、及びＬＲ１３２９７）が、道路５００に沿う位置に予め割当てられている。これらの位置参照番号は、交通放送システム２０を管理している道路オーソリティその他によって割当てられる。交通放送システム２０によって放送されるメッセージ５０（図１−３）は、交通渋滞の位置を識別する時にこれらの位置参照番号を含む。
【００６７】
ＲＤＳ−ＴＭＣシステムのような交通放送システムでは、監視され、それに関する交通メッセージが放送される道路５００は、通常は、高速道路または主要幹線道路である。重要ではない、即ちマイナーな道路に沿う交通状態は、これらの種類の交通放送システムによって監視されていない。従って、ＲＤＳ−ＴＭＣシステムのような交通放送システムでは、高速道路及び主要幹線道路に沿う位置には位置参照番号が割当てられているが、重要ではない道路に沿う位置には割当てられていない。
【００６８】
図９には、３つの位置番号、即ちＬＲ１２００５、ＬＲ１２００６、及びＬＲ１３２９７だけが示されている。典型的な交通放送システムでは、位置テーブルによって表される各地域内の道路に沿う位置に割当てられた数百、数千、またはそれ以上の位置参照番号が存在し得ることを理解されたい。図９に示すように、位置参照番号は、道路５００に沿うインターチェンジに対応している。しかしながら、位置参照番号は、インターチェンジの間を含む道路５００上のどのような位置にも割当てることができる。
【００６９】
ＲＤＳ−ＴＭＣシステムのような交通放送システムでは、方向は正及び負として定義することができる。例えば、ＲＤＳ−ＴＭＣシステムでは、西から東へ、及び南から北への走行方向が正の方向である。位置参照番号は、必ずしもそのようにしなくともよいが、道路に沿って連続する順番に割当てることができる。
【００７０】
ＲＤＳ−ＴＭＣシステムのような交通放送システムでは、各道路自体にも位置参照番号が割当てられている。１つの道路の位置参照番号が、他の道路と共用されることはない。従って、２つの道路の間のインターチェンジにおいては、各道路に位置参照番号が割当てられている。即ち、１つの位置参照番号が第１の道路のためのインターチェンジに割当てられ、第２の位置参照番号が第２の道路のための同一インターチェンジに割当てられている。従って、１つのインターチェンジは、それに割当てられた２つまたはそれ以上（そのインターチェンジにおいて出会う各道路毎に１つ）の位置参照番号を有することができる。
【００７１】
前述したように、地理データベースを使用するナビゲーションシステムに位置参照番号を使用する場合の１つの問題は、位置参照番号が必ずしも何等かの物理的な道路特色に関係付けられていないことである。図９に示す道路５００は、個々の道路セグメント、Ｓ１０１、Ｓ１０２、・・・、Ｓ１３２からなっている。これらの道路セグメントＳ１０１、Ｓ１０２、・・・、Ｓ１３２は、道路５００の個々の部分（即ち、セグメント）に対応している。例えば、道路５００のこれらの各個々のセグメントは、道路５００と他の道路（入口ランプ及び出口ランプを含む）との交差点の間の道路５００の一部からなることができる。地理データベース１４０（図２）では、これらの分離した各道路セグメントＳ１０１、Ｓ１０２、・・・、Ｓ１３２は、少なくとも１つの分離したデータレコードによって表される。
【００７２】
図９に示す道路５００では、道路５００のレーンについて各方向毎に別々の道路セグメントが存在している。これは、１つの方向へ向かうレーンが、他の方向へ向かうレーンとは物理的に分離されているような、典型的な高速道路構成を表している。図９の道路５００の部分におけるように、レーンが実際に互いに物理的に分離されている場合には、地理データベース１４０内には、１つの方向のレーン及び他の方向のレーンのために別々のセグメントデータレコードが存在し得る。道路のレーンが互いに物理的に分離されていない場合であってさえも、地理データベースでは分離したデータレコードによって表すことができる。代替として、単一のセグメントデータレコードを、道路の両方向の全てのレーンを表すデータベース内に含ませることができる。データベースレコードは、それらが両方向のレーンを表しているのか、または単一方向のレーンだけを表しているのかを指示する属性を含んでいる。
【００７３】
図９に示すように、位置参照番号（例えば、ＬＲ１２００５、ＬＲ１２００６・・・）が割当てられている道路５００に沿う各位置に関連して道路５００の多重セグメントＳ１０１、Ｓ１０２、・・・、Ｓ１３２が存在し得る。上述したように、道路５００のこれらの各多重セグメントは、地理データベース１４０内の少なくとも１つのレコードによって表すことができる。更に、図９に示すように、位置参照番号が割当てられている道路５００に沿うインターチェンジの間に位置する道路５００の幾つかのセグメントも存在し得る。インターチェンジの間の道路５００のこれらの各セグメントは、地理データベース内の少なくとも１つのレコードによって表すことができる。しかしながら、これらの個々の道路セグメントＳ１０１、Ｓ１０２、・・・、Ｓ１３２は何れも、交通放送システムによって放送されるメッセージ内の位置参照番号に関係付けて別々に識別されない。
【００７４】
前述したように、もしナビゲーションシステム１１０内のルート計算機能１４１（図２）を使用してルートを計算する時に、交通メッセージ５０内のデータを使用することができれば有利である。もし交通メッセージ内のデータをナビゲーションシステムによって使用することができれば、ルート計算機能は、位置参照番号が割当てられている交通渋滞位置に関連するセグメントを避けることができる。不幸にも、図９によって例示したように、交通放送システムオーソリティによって割当てられた位置番号は、地理データベース１４０内のデータレコードによって表されるどの物理的特色にも直接的に関係がない。更に交通放送システム２０によって放送される交通メッセージは、必ずしも地理データベース内のデータレコードによって表される実際の道路セグメントの何れかに関係するとは限らない。
【００７５】
交通放送システムによって放送される交通メッセージを、ナビゲーションシステム内のルート計算機能に使用するのを複雑にしている更に別のファクタは、図３に関して説明したように、ＲＤＳ−ＴＭＣのようなシステムにおいては、交通渋滞の発生によって影響を受ける道路の長さが、放送交通メッセージ内に含まれる「範囲」データ５０（４）の表現で報告されることである。「範囲」データは、交通メッセージ内の位置参照番号によって識別された道路に沿う位置に対する交通渋滞状態によって影響される位置番号によって表される隣接位置の番号の表現で定義される。従って、「範囲」データ５０（４）も、地理データベース内のデータレコードによって表される物理的特色に何等の直接的な関係を有するものではない。交通メッセージ内の「範囲」データを使用すると、ナビゲーションシステム１１０のルート計算機能１４１内に交通放送メッセージ情報を組み入れる困難さが倍加する。
【００７６】
ルート計算機能を支援するために交通メッセージを使用するためには、交通メッセージからの位置参照データを、ルート計算機能によって使用される地理データベース内の地理データ（セグメントデータレコードのような）に関係付ける方法が必要である。図２に示す機能１４１のようなルート計算機能では、ルート計算は、出発点から目的地位置までの潜在的な幾つかの解ルートを探索することによって遂行することができる。ルート計算機能１４１は、潜在的な解ルートの部分に沿う交差点からの幾つかの可能な経路を比較し、ある費用割当て基準に基づいて最良の総合費用を有する経路を選択することによって、このプロセスを遂行することができる。これらの解ルート、またはそれらの部分を比較するために、これらの潜在的な解ルート内の各道路セグメントを表すデータレコードが調べられる。これらのデータレコードは、潜在的な解ルートの比較を行うことができる情報を含む。例えば、道路セグメントを表すデータレコードは、表された道路セグメントに沿う速度制限、その道路セグメントの終わりに停止標識が存在するか否か、等々を指示する属性を含むことができる。これらのデータを使用すると、潜在的な解ルートを互いに比較することができるので、最良解ルート（例えば、最高速総合走行時間、または最短総合距離を有するルート）を選択することができる。
【００７７】
交通渋滞の領域を識別するデータのような、交通放送システムによって放送される交通メッセージ５０内のデータを、最良総合ルートの計算に直接関係付けることができることは理解できよう。交通データメッセージ内の情報を、ルート計算機能に組み入れるためには、インターチェンジに関連する道路セグメント（交通放送システム２０によって位置参照番号が割当て済みのインターチェンジへ導入する道路セグメントを含む）を表すデータレコードを識別する必要がある。
【００７８】
この機能を提供するために、これらの実施例は、ナビゲーションシステム１１０内のナビゲーション応用プログラム１１８が交通メッセージ５０内のデータを使用できるようにする特色及び／または成分の組合せを含んでいる。この実施例の一つの面によれば、地理データベース内の若干のセグメントデータレコードを若干の位置参照番号に関連するものとして識別するために、位置参照データレコードが形成され、格納され、そして使用される。これらの位置参照レコードは、地理データベース１４１内に含ませることも、または無線通信リンクを介してビークルに供給することもできる。１つの位置参照レコードの成分を図１１に示す。この実施例の別の面によれば、位置参照番号を、位置参照レコードに関係付けるために１つまたはそれ以上の索引が形成され、格納され、そして使用される。これらの索引を図１３に示す。この実施例の別の面によれば、位置参照データレコードのパーセルが形成され、格納され、そして使用される。位置参照データを含むパーセルを図１２に示す。この実施例の別の面によれば、各位置参照番号毎に、直前の位置参照番号及び直後の位置参照番号を識別するためのデータが形成され、格納され、そして使用される。これにより、放送メッセージ内の「範囲」データを解釈し、地理データベース内のレコードに関係付けることが可能になる。この実施例の更に別の面によれば、ナビゲーションシステム内には、地理データベースに照会して若干の識別された位置参照番号に関連するデータエンティティを戻すプログラミングが含まれている。この実施例のこの面を図１４−１６に示してある。
【００７９】
これらの各面を以下に説明する。
【００８０】
Ｂ．位置キー
この実施例の一部として、ナビゲーションシステムによって使用される地理データベース内の若干のデータエンティティを、交通放送システムによって使用される位置参照コードに対応付けるようにするデータレコードが形成される。この実施例では、この一部として「位置キー」が形成される。位置キーは、位置参照コードに関係付けるデータ成分の集合体である。各位置キーは、地理データベース内のその位置コードのための独特な識別子を形成する。この特色の故に、位置キーは地理データベース内のこれらのレコードのためのエンティティＩＤとして使用することができる。
【００８１】
位置キー５０５の成分を図１０に示す。位置キー５０５は、国別コード、位置テーブル番号、及び位置番号の組合せで形成される。この組合せが一緒になって独特な 32 ビットの番号を形成する。位置番号は 16 ビットであり、位置テーブル番号は６ビットであり、そして国別コードは４ビットである。この独特な番号は、後述するように数値分類キーとして使用される。
【００８２】
Ｃ．位置レコードのデータ成分
地理データベースによって表される地域内の各位置（１つまたはそれ以上の交通放送システムによって位置参照番号を割当て済み）毎に独特な識別子を与えるために位置キーが形成された後に、各位置キーと対応付けるべき地理データベース内のデータエンティティを識別する。本実施例では、位置キーによって表されるインターチェンジ内に含まれる、またはそれに導入する道路セグメントを表すデータエンティティが識別される。例えば、図９において、位置参照番号ＬＲ１２００６が関連しているインターチェンジは、内部セグメント及び外部セグメントの両方を含んでいる。位置参照番号ＬＲ１２００６によって表されるインターチェンジの内部セグメントは、Ｓ１１３及びＳ１１４を含む。位置参照番号ＬＲ１２００６によって表されるインターチェンジの外部セグメントは、正方向にインターチェンジに導入する２つのセグメントＳ１１０及びＳ１１２、及び負方向にインターチェンジに導入する２つのセグメントＳ１２２及びＳ１２３を含む。これらの６つのセグメント（Ｓ１１３、Ｓ１１４、Ｓ１１０、Ｓ１１２、Ｓ１２２、及びＳ１２３）に関連するセグメントデータエンティティが、このインターチェンジＬＲ１２００６のための位置キーに関連するものとして識別される。
【００８３】
インターチェンジＬＲ１２００６から導出するＳ１２１及びＳ１１１のようなセグメントは、このインターチェンジのための位置キーに関連付けされていない。代わりにこれらのセグメントは、それらが導入するインターチェンジの位置参照番号に関連付けられる。図９の例では、Ｓ１２１によって識別されるセグメントは、位置参照番号ＬＲ１３２９７によって表されるインターチェンジに導入し、Ｓ１１１によって識別されるセグメントは、位置参照番号ＬＲ１２００５によって表されるインターチェンジに導入する。従って、これらは、これらのインターチェンジのための位置キーを用いて地理データベース内に関連付けられる。
【００８４】
図１１に、位置参照データレコード２６０を示す。このレコードのためのエンティティＩＤは、上述したようにして形成された位置キーである。位置参照レコード２６０は、セグメントＩＤ（例えば、セグメントＩＤ（ｘ）、セグメントＩＤ（ｗ）、セグメントＩＤ（ｐ）、・・・、セグメントＩＤ（ｊ））のリスト２６０（１）を含む。これらのセグメントＩＤは、位置参照キーによって識別されたインターチェンジに関連する道路セグメントを表すセグメントデータレコードを識別する。図９のインターチェンジＬＲ１２００６を表す位置参照レコードの場合には、エンティティＩＤのリスト２６０（１）内には６つのセグメントＩＤ、即ちＳ１１３、Ｓ１１４、Ｓ１１０、Ｓ１１２、Ｓ１２２、及びＳ１２３が存在する。
【００８５】
リスト２６０（１）内のセグメントＩＤは順序付けられている。いろいろな順序付け方法を使用することができる。一実施例では、セグメントＩＤは、有効ナビゲート可能経路が得られるように順序付けされている。例えば、Ｓ１２３、Ｓ１２２、Ｓ１１３が負（“Ｎ”）方向の有効経路を形成し、Ｓ１１０、Ｓ１１２、Ｓ１１４が正（“Ｐ”）方向の有効経路を形成する。
【００８６】
図７に関連して説明したように、地理データベース１４０は、ルーティングデータベース２３６のような若干の型のデータベースの１つより多くの層を含むことができる。これらの各層は、異なるセグメントＩＤを同一の道路セグメントに割当てることができる。この結果、同一セグメントを、地理データベース内の１つより多くのセグメントＩＤによって表すことができる。位置参照データレコード２６０内のセグメントエンティティＩＤのリスト２６０（１）は、最低層（即ち、層Ｒ０）のための、または何れかの他の層（例えば、層Ｒ１−Ｒ４）のためのセグメントレコードＩＤを含むことができる。代替として、リスト２６０（１）は、１つより多くの層のための、または全ての層のためのセグメントエンティティＩＤを含むことができる。もしセグメントエンティティＩＤのリスト２６０（１）が最低層だけのためのセグメントレコードＩＤを含んでいれば、他の層内の道路セグメントの対応セグメントＩＤを入手するための手段を設けることができる。例えば、層０内のセグメントデータレコードは、同一道路セグメントを表す他の層内の対応セグメントデータレコードへの参照を含むことができる。
【００８７】
交通放送システムによって位置参照番号が割当てられている道路は、一般的には高ボリュームであり、アクセスが制限されている道路である傾向があるから、道路は最高ランク（例えば、ランク「４」）だけのセグメントからなる傾向がある。
【００８８】
地理データベース１４０が複数の層を含んでいる場合には、より高い層は個々の道路セグメントの集約を表すデータレコードを含むことができる。より低くランク付けされた道路が含まれていないより高い層においては、より高くランク付けされた道路セグメントとより低くランク付けされた道路セグメントとの交差点は抑圧乃至は排除されているので、より高い層内の道路セグメントの集約は、分離したデータレコードによって表すことができる。集約されたセグメントデータレコードを使用することにより、若干のナビゲーション機能の性能を強化することができる。これらの集約されたセグメントデータレコードが位置参照番号に関連する道路の部分を表し、位置参照レコード２６０内のセグメントＩＤのリスト２６０（１）が層０セグメントＩＤだけを含む場合には、集約されたセグメントデータレコードによってより高い層内に表されている道路セグメントの集約内に含まれる道路セグメントを表す層０セグメントデータレコードは、その関連する集約されたセグメントデータレコードを識別する参照を含むことができる。代替として、集約さたセグメントデータレコードのセグメントＩＤは、位置参照レコードのリスト２６０（１）内に含ませることができる。
【００８９】
各位置参照番号に関連するセグメントＩＤのリストに加えて、位置参照レコード２６０は、位置参照番号によって表される位置に関連している他のデータエンティティ２６０（２）を識別することができる。例えば、位置参照レコード２６０は、位置参照番号に関連するノードを表すノードＩＤのリストを含むことができる。
【００９０】
位置参照番号データレコード２６０は、他のデータ成分を含むこともできる。例えば、位置参照番号２６０は、方向属性２６０（３）を含む。位置参照番号２６０は、オプションで、交差点属性２６０（４）も含むことができる。方向属性２６０（３）は、位置参照番号の方向を指示する。交差点属性２６０（４）（もし、設けられていれば）は、位置参照レコードによって表される位置の型を指示するデータを含む。例えば、交差点属性２６０（４）は、その位置参照番号によって識別される位置がランプ付きのインターチェンジである、終点である、またはその交差点が停止標識を含む、等々であることを指示するデータを含むことができる。位置参照番号データレコード２６０は、他のデータ２６０（５）も含むことができる。
【００９１】
Ｄ．データベース内の位置参照レコード編成
図１１に示す道路のような全ての位置レコードのデータ成分は、位置参照番号及び範囲が与えられた時に、全ての関連セグメントレコードの迅速な識別及び検索が容易であるように編成され、配列され、そしてナビゲーションシステムによって使用される地理データベース１４０内に格納されている。位置参照データベースの編成、配列、及び格納を、図１２及び１３を参照して説明する。
【００９２】
地理データベース内の位置参照番号に関連するセグメントレコードを探知する予備ステップとして、位置参照番号に関連する位置キー５０５が使用される。前述したように、位置キーは、位置参照番号を含む交通メッセージの成分からなっている。従って、各位置参照キーに関連するデータレコードを見出すために位置キー索引２４７（ＬＲ）が使用される。位置キー索引２４７（ＬＲ）は、地理データベース１４０内に、または地理データベース１４０を用いて形成され、格納される。この位置キー索引２４７（ＬＲ）は、地理データ１４０の位置参照レコードデータ２４５から分離した一部内に位置させることができる。図１３を参照する。一実施例では、位置キー索引２４７（ＬＲ）は、索引ファイル２４７（図６にも示されている）の間に含まれている。位置キー索引２４７（ＬＲ）を位置参照レコードデータ２４５から分離して格納することによって、全位置キー索引２４７（ＬＲ）をナビゲーションシステムのメモリ内に読み込んで、所望の位置参照レコードの位置を識別するために使用することができる。位置キー索引２４７（ＬＲ）を位置参照レコードデータから分離して格納すると、ナビゲーションシステムのメモリ内に不要のデータをロードする必要が避けられ、それによって性能が強化される。ナビゲーションシステムのメモリ資源に依存して、位置キー索引２４７（ＬＲ）は、索引ファイル２４７の中に含まれている他の索引と共にメモリ内に維持することができる。代替として、位置キー索引２４７（ＬＲ）は必要な場合にだけメモリ内にロードし、使用することができる。（もし位置キー索引２４７（ＬＲ）のサイズが比較的大きければ、それを１つより多くのパーセル内に格納する必要があろう。）
図１３に示す実施例では、位置キー索引２４７（ＬＲ）は特定の各位置参照レコードの位置を識別はせず、その代わりに、位置キー索引２４７（ＬＲ）は所望の位置参照レコードを含む位置参照データ２４５のパーセル３２０（ＬＲ）を識別する。図１３に示すように、位置キー参照索引２４７（ＬＲ）はエントリのリスト５１０を含んでいる。このリスト５１０内のエントリは、位置参照データ２４５を含む複数の各パーセル３２０（ＬＲ）内の最初の位置参照レコードに対応する位置参照キー５０５だけを含んでいる。リスト５１０内の各エントリは、そのエントリ内の位置キーに対応する位置参照レコードを含むデータのパーセルの識別をも含んでいる。この識別はポインタまたは他の参照であることも、または代替として、この識別はデータベース内の、及び／または媒体上のパーセルの位置を決定することができるパーセルＩＤであることもできる。
【００９３】
位置キー索引２４７（ＬＲ）内のリスト５１０内の位置参照キー５０は順番に（例えば、数値的に最小から最大へ、またはその逆に）格納及び／または配列されている。従って、リスト５１０内のエントリは、何れかの位置キーに関連する位置参照レコードが位置しているパーセルを識別するために使用することができる。位置キーが与えられると、与えられた位置キーより大きいエントリに出会うまで、リスト５１０をトラバースすることができる。与えられた位置キーに関連する位置参照レコードを含むパーセルが、そのリスト内の先行エントリによって参照されたパーセルである。代替として、所望の位置参照番号を含むパーセルを見出すために、他の探知技術（例えば、バイナリ探索）を使用することができる。即ち、このリスト５１０は、位置参照レコードを含むパーセルを迅速に見出すことができる探索技術に順応する。
【００９４】
もし位置キー索引２４７内のエントリのリスト５１０が１つより多くのパーセルからなっていれば、このリスト上に探索木を構成し、キーによる位置キーパーセルの探索を容易にすることができる。従って、位置キー索引は、多層探索木からなることができる。各層は、次に低い層における位置木パーセルのための、または（最低層位置索引パーセルから）位置参照レコードパーセルのためのキーによってバイナリ探索することができる。
【００９５】
位置参照データ２４５を含む各パーセル３２０（ＬＲ）は、類似の編成を有している。位置参照データ２４５の代表的なパーセル３２０（ＬＲ）（ｎ）の編成を、図１２に示す。位置参照データの各パーセル３２０（ＬＲ）（ｎ）は、そのパーセル内に最小位置参照キーを有する位置参照レコードを識別する（例えば、位置キーによって）データ成分５２１を含む。このレコードは、位置キー索引２４７（ＬＲ）内のエントリによって指し示されるレコードに対応する。位置参照データ２４５のパーセルは、オフセットテーブル５４５及び位置参照レコード５５０をも含んでいる。
【００９６】
オフセットテーブル５４５は、パーセル内に含まれている各位置参照レコード５５０（１）、５５０（２）、・・・、５５０（ｎ）に対応するエントリ５４６（１）、５４６（２）、５４６（３）・・・のリストを含んでいる。リスト５４５内のエントリ５４６は、一実施例では数値的に順序付けられている位置参照レコードの順序付けを反映している。各エントリ５４６は、パーセル内のその対応する位置参照レコードの長さ５４７を識別する。オフセットテーブル５４５は、各エントリ毎に、次の位置キー５４９を識別するデータをも含む。次の位置キー５４９内のデータは、エントリ５４６に対する道路に沿う直後の位置参照番号の位置キー５０５を識別する。同様に、各エントリ５４６は、先行位置キー５５１を識別するデータを含む。先行位置キー５５１内のデータは、そのエントリ５４６の位置キーに対応する位置に対する道路に沿う直前位置参照番号の位置キーを識別する。例えば、図９において、“ＬＲ１２００６”に関連するインターチェンジのための位置キーのためのオフセットテーブル内のエントリ５４６は、その先行位置キー５５１としてＬＲ１２００５のための位置キーを、またその次の位置キー５４９としてＬＲ１３２２９７のための位置キーを識別する。前述したように、位置参照番号は必ずしも道路に沿って連続的に割当てられてはいない。従って、各位置参照番号毎の次の及び先行位置キーは、オフセットテーブル５４５において識別される。
【００９７】
パーセル内のオフセットテーブル５４５に後続しているのは、位置参照パーセル３２０（ＬＲ）の位置参照レコード部分５５０である。位置参照レコード部分５５０は、位置レコード５５０を含んでいる。位置参照パーセル３２０（ＬＲ）内の各位置参照レコード５５０は、図１１に識別されている成分を含んでいる。即ち、各位置参照レコード５５０は、方向属性（図１１の方向データ２６０（２）に対応する）、及びセグメントＩＤのリスト（図１１のリスト３６０（１）に対応する）を含む。オプションとして、位置参照レコード５５０は、交差点属性（図１１の交差点データ２６０（３）に対応する）をも含むことができる。
【００９８】
Ｅ．位置参照データを使用するためのプログラミング
この実施例の別の面によれば、交通メッセージ５０内のデータ、及び地理データベース１４０内の位置参照データ２４５の両方を使用するプログラミングを含む。（このプログラミングを、以下に「位置参照プログラミング」、または「位置参照ルーチン」１４５という。）位置参照プログラミング１４５は、ナビゲーションシステム１１０内に設置され、及び／またはナビゲーションシステム１１０によって実行されるナビゲーション応用プログラミング１１８（図２）の一部として含むことができる。代替として、位置参照プログラミング１４５は、ナビゲーション応用機能（ルーティング機能１４１、地図表示機能１４３、等）と地理データベース１４０との間に存在するソフトウェアインタフェース層の一部として含むことができる。ソフトウェアインタフェース層も、ナビゲーションシステム１１０内に設け、及び／またはナビゲーションシステム１１０が実行することができる。もし位置参照プログラミングがビークル内のナビゲーションシステム１１０内に設けられていれば、ナビゲーションシステムの一部である不揮発性コンピュータ可読媒体内に格納することができる。
【００９９】
図１４は、位置参照プログラミング１４５の主要ステップを記述する流れ図を示している。図１４に示されている実施例では、ナビゲーション応用プログラム１１８の一部であることができる受信機ルーチン応用７０７は、若干の初期ステップを遂行し、次いで出力を位置参照プログラミング１４５に供給する。代替実施例では、受信機ルーチン応用７０７によって遂行されるステップは、位置参照プログラミング１４５によって遂行させることができる。
【０１００】
初期ステップ（ステップ７１０）において、単一の交通メッセージ５０を受信する。交通メッセージ５０は、図３に示すものと類似のフォーマットを有することができる。次のステップ（ステップ７１４）では、位置参照番号５１（１）、範囲５０（４）、等々を含むメッセージ５０の成分を入手するために、交通メッセージ５０がパーズされる。これらのデータは、受信機ルーチン応用７０７から位置参照プログラミング１４５へ供給される。
【０１０１】
メッセージからの位置参照番号５１（１）、国別コード５１（３）、及び位置テーブル番号５１（２）を使用して、位置キー５０５が形成される（ステップ７１８）。位置キー５０５は、交通メッセージから抽出されたこれらの成分を連結することによって形成することができる。先行ステップにおいて形成された位置キー５０５を使用して、位置キーに関連する位置参照レコードを含む位置参照データレコードのパーセル３２０（ＬＲ）を見出すために、地理データベース１４０内の位置キー索引２４７（ＬＲ）が使用される（ステップ７２２）。次に、位置キー索引２４７（ＬＲ）を使用して、位置キーに関連するレコードを含む位置参照レコードのパーセルが識別されると、そのパーセルにアクセスし、読み出す（ステップ７２６）。
【０１０２】
パーセル３２０（ＬＲ）を読み出す際に、オフセットテーブル５４５を含むパーセルヘッダーが先ず読み出される（ステップ７３０）。オフセットテーブル５４５（位置キーが数値的に順序付けられている）を使用して、所望の位置キーに対応するエントリが形成される（ステップ７３４）。オフセットテーブル５４５内のエントリから、次の位置キー５４８、または先行位置キー５５１の何れかを読み出す。これらのキーのどちら（即ち、次、または先行）を読み出すのかは、位置参照番号の位置からの交通渋滞の方向を定義する交通メッセージ５０内の方向データ５０（３）に依存する。交通メッセージ５０からの方向データ５０（３）及び範囲データ５０（４）を、オフセットテーブルからの次の、または先行の何れかの位置キーと共に使用して、交通メッセージを適用する他の各位置キーを決定することができる（ステップ７３８）。ある範囲内に包含される全ての位置キーを識別するために、オフセットテーブルを数回使用しなければならないかも知れない。例えば、もし範囲データ５０（４）が“４”であれば、オフセットテーブル５４５は先ず、メッセージ５０内に識別されている位置参照番号５１（２）のための位置キーに対する次の（または、方向に依存して、先行の）位置キーを識別するために使用される。次いで、その次の（または、先行）位置参照キーを識別するために、オフセットテーブル内の次のキー（または、先行キー）が探知される。このプロセスは、４つの（範囲データフィールド５０（４）内に識別されている“４”に対応）位置キーが全て識別されるまで続行される。もし範囲データフィールド５０（３）が１つより多くのパーセル内の位置参照レコードによって表されている位置参照位置の列を識別していれば、１つまたはそれ以上の付加的な位置参照データレコードのパーセルにアクセスする必要があるかも知れない。しかしながら、多くの場合、読み出す必要があるパーセルの数を最小に維持するように、キーが繰り返される。
【０１０３】
範囲に対応する全ての位置キーが識別された後に、オフセットテーブル５４５を使用してパーセル内の所望の位置参照データレコードが探知される（ステップ７４２）。オフセットテーブル内の各位置キーエントリ毎に、パーセル内へのオフセットはその位置キーエントリに関連するデータが見出されるパーセル内の位置を識別する。各位置キーエントリ毎に、位置参照データレコード５５０が読み出される（ステップ７４６）。詳しく述べれば、識別された各位置キーに関連する全てのセグメントＩＤが識別される。範囲データ５０（４）は交通渋滞によって影響をうけている１つより多くの位置参照番号を識別することができるので、これらのセグメントＩＤは１つより多くの位置参照番号に関連付けることができる。セグメントＩＤのこのリスト７５２は、それを呼出したプログラムへ戻される（ステップ７５０）。この位置参照プログラミングルーチン１４５を、ナビゲーションシステムに関連してどのように使用できるかの例を以下に説明する。
【０１０４】
位置参照プログラミング１４５は、１つの層（例えばルーティング層０）のための、または代替として１つより多くの層のための、セグメントＩＤのリストを戻すことができる。位置参照レコード２６０が、ルーティング層０のような１つの層に関連するセグメントＩＤだけを含んでいるような実施例では、これらの層０セグメントデータレコード内に含まれる、他のより高い層内のデータレコードへの参照を入手するために、先ずこれらのルーティング層０データレコードにアクセスし、読み出すことができる。次いで、これらの付加的なセグメントＩＤ７５９も、呼出した応用へ戻すことができる。もしより高い層が、集約されたセグメントデータレコードを含んでいれば、これらのレコードへの参照をも戻すことができる。このオプショナルな代替に含まれるステップ（７５６及び７５８）を図１４に破線で示してある。
【０１０５】
位置参照プログラミング１４５は、どのような適当なプログラミング言語で書くこともできる。一実施例では、位置参照プログラミング１４５は、地理データベースにアクセスし、使用する他の機能と同一のプログラミング言語で書かれている。この実施例では、位置参照プログラミング１４５はＣで書かれているが、代替実施例では、位置参照プログラミング１４５はＣ＋＋、Javaのようなどのような適当なプログラミング言語で書くことも、または近い将来開発されるかも知れないプログラミング言語で書くこともできる。
【０１０６】
Ｆ．動作の方法
この実施例によれば、所与の型の位置参照（ＲＤＳ−ＴＭＣシステムにおけるＡＬＥＲＴ−Ｃプロトコルのような）、及びその型の１つまたはそれ以上の位置参照のために、これらの参照に対応するエンティティを戻す手段が設けられている。ＲＤＳ−ＴＭＳ位置参照型の場合、位置参照は、上述したような位置属性の集合的なエンコーディングであるＲＤＳ−ＴＭＳコードを表す。地理データベース１４１から戻されたエンティティ、またはレコードは、セグメントデータレコードである。
【０１０７】
これらの実施例を使用する方法を、以下の例で説明する。
【０１０８】
例 １
この例は、図１５を参照して説明する。図１５の例では、交通データベースはナビゲーションシステムの初期化時に入手され、次いでナビゲーションシステムの使用中に絶えず、または定期的な間隔で更新される。図１５では、ナビゲーションシステムが始動した時、または初期化された時（ステップ８０７）に、交通データ収集プログラム８１０が実行される。この交通データ収集プログラム８１０は、ナビゲーション応用プログラミング１１８、インタフェース層プログラミング（前述）、またはナビゲーションシステムの何れかの他の部分の一部であることができる。交通データ収集プログラム８１０は、エンドユーザがナビゲーションシステムに要求して遂行させることができる他のタスクを妨害しないようにバックグラウンドで動作することができる。
【０１０９】
交通データ収集プログラム８１０は、交通メッセージ放送５０を受信し始める。これらは、図２の受信機１２５から受信することができる。受信した各交通メッセージ５０毎に、交通データ収集プログラム８１０は位置参照ルーチン１４５（図１４に示す）を呼出す（ステップ８２５）。交通データ収集プログラム８１０は、位置参照ルーチン１４５がメッセージを捕捉できるまで、交通放送システム２０から受信した交通メッセージ５０をバッファしなければならないかも知れない。ナビゲーションシステムのメモリの一部分を、この目的のために準備することができる。
【０１１０】
各交通メッセージ５０毎に、位置参照ルーチン１４５は交通メッセージで報告された渋滞によって影響を受けているセグメントＩＤのリストを戻す。交通メッセージからの渋滞の酷さがセグメントに関連付けられ、臨時データベース８１８内に格納される（ステップ８２７及び８２９）。データ収集プログラム８１０は全ての交通メッセージを入手してしまうまで、酷さをセグメントデータベースレコードに関連付けるデータを格納し続ける（ステップ８３０）。この点において、データ収集プログラムは交通メッセージを集め続け、セグメントに関連する酷さが変化するにつれて、必要に応じて臨時データベースを更新する。
【０１１１】
全ての交通メッセージを入手した後の任意の時点に、臨時データベース８１８はナビゲーション応用によって使用される。例えば、解ルート８３３を決定するためにルート計算機能１４１が実行される時に、臨時データベース８１８を地理データベース１４０と共に使用することができる。ルート計算機能は、潜在的解ルートを決定する目的で地理データベース１４０からのセグメントを調べ、何れかのセグメントが臨時データベース８１８内のセグメントに関連する酷さの格付けを有しているか否かを決定する。もしある潜在的解ルート内のセグメントが臨時データベース８１８内にそれに関連する酷さ重みを有していれば、潜在的解ルートと他の潜在的ルートとを比較する時に、この重みを考慮に入れる。もし潜在的解ルートのセグメント上の交通が酷く渋滞していれば、別の潜在的解を選択することができる。
【０１１２】
この例では、ルート計算の前に交通データ収集プロセスがセグメントエンティティのリストを累積するのを回避するので、臨時データベース８１８内に交通メッセージに関連するセグメントを入手するアクセス性能は臨界的ではない。
【０１１３】
例 ２
この例は、図１６を参照して説明する。図１６では、ルーティング計算プログラム１４１が走るまでは、交通データ５０は入手されない。図１６では、ルーティング計算プログラム１４１は、所望の目的地及び起点を含む入力を受信する（ステップ９０１）。交通データ収集プログラム９０３が呼出される。この交通データ収集プログラム９０３は、交通放送システム２０によって放送される交通メッセージ５０を入手する（ステップ９０５）。これらの各交通メッセージは、ナビゲーションシステム１１０のメモリ内に臨時に格納することができる。潜在的解ルーティングから比較的離れた位置に関するメッセージが処理されないように、交通メッセージ５０を濾過することができる。次いで、交通データ収集プログラム９０３は各関係交通メッセージ毎にルーチン９０７を実行する。
【０１１４】
各交通メッセージ５０毎に、交通メッセージ内の１つまたは複数の位置参照番号（交通メッセージ内に明示的に指定されている位置参照番号、並びに交通メッセージ内に含まれている範囲データによって暗示的に指定されている位置参照番号を含む）に関連する全てのセグメントデータエンティティ（または、全てのセグメントデータエンティティのための少なくともＩＤ）を入手するために、ルーチン９０７は位置参照ルーチン１４５（図１４）を呼出す。セグメントデータエンティティ（またはそれらのＩＤ）のリスティング７５２を使用して、交通メッセージと共に含まれている交通渋滞の酷さが、これらの各セグメントデータエンティティ（または、ＩＤ）に関連付けられる（ステップ９１３）。酷さとセグメントＩＤとのこの結合は、臨時データベース９１６内に格納される（ステップ９１５）。
【０１１５】
全ての関係交通メッセージを入手すると、ルート計算機能１４１は解ルート９２１を決定し始める（ステップ９１７）。解ルートを決定するプロセスにおいては、重み付けされたセグメントの臨時データベース９１６が地理データベース１４０と共に使用される。ルート計算機能１４１によって計算中の潜在的解ルートの一部分が、臨時データベース９１６内の酷さの重みに関連するセグメントの１つを含んでいる場合には、その潜在的解ルートと他の潜在的解ルートとを比較する時にその重みが斟酌される。酷さの重みは、交通渋滞がかなり酷く、そのセグメントは完全に避けるべきであることを指示することができる。代替として、交通渋滞を含むセグメントを潜在的解ルートとして使用できるように、酷さに比較的軽く重み付けすることができる。
【０１１６】
Ｇ．代替実施例
代替実施例では、ナビゲーションシステムによって遂行されるナビゲーション応用プログラミング、または機能の若干または全ては、遠隔的に遂行させることができる。例えば、ナビゲーション応用プログラミング機能の若干または全ては、ビークルが無線通信リンクを有しているサービスプロバイダによって遂行させることができる。（サービスプロバイダは、必ずしも交通放送システムに関連している必要はない。）この代替では、ナビゲーション機能が遂行される遠隔サービスプロバイダへユーザの入力を送信し、結果をビークルへ戻して送信することができる。位置参照プログラミング及び／またはデータ収集プログラミングは、ビークル内に配置することも、または遠隔的にアクセスすることもできる。
【０１１７】
別の代替では、地理データベース１４０の若干または全ては、例えばサービスプロバイダを用いて遠隔配置し、無線通信リンクを介してビークル内のナビゲーションシステムによってアクセスすることができる。位置参照レコードは、ビークル内のコンピュータ可読媒体上に配置することも、または遠隔配置して通信リンクを介してアクセスすることもできる。
【０１１８】
別の代替では、位置参照データベースの若干または全ては、必要に応じて無線通信リンクを介してダウンロードし、ビークル内に配置された分離した書き込み可能な媒体上に格納することも、または代替として、位置参照データはビークル内のメモリ（例えば、ＲＡＭ）内のテーブル内に格納することもできる。この実施例では、位置参照データを使用するビークル内のナビゲーションプログラミングは、分離した媒体からのデータにアクセスする。この実施例の利点は、位置参照データを、必要に応じて更新できることである。別の利点は、新しい交通メモリシステムを容易に受入れることができることである。格納を最小に留めるために、制限された地理カバレッジエリアのためだけのデータを読み出すことができる。
【０１１９】
さらなる代替では、分離した媒体上に位置参照データをダウンロードし、格納するために、位置参照データの一次源を地理データベースと共に格納し、更新することができる。この実施例では、位置参照データを使用するプログラミングは、一次参照データ及び更新されたデータの両方を使用する。
【０１２０】
別の代替実施例では、交通メッセージを受信し、交通メッセージをパーズするプログラミングへそれを供給する受信機は、ナビゲーションシステム１１０の一部であることも（図２の１２５のように）、または代替として、受信機はスタンドアロンユニット、または別の種類の機器に関連するユニットであることもできる。この代替実施例を図１７の１１２５に示す。もし図１７の１１２５に示すように、受信機がナビゲーションシステム１１０の一部でなければ、交通メッセージのようなデータを受信機１１２５からナビゲーションシステム１１０へ転送できるようにするために、受信機１１２５はナビゲーションシステム１１０の入力ポート１１２９に結合することができる出力ポート１１２７を有している。受信機上のポート１１２７及びナビゲーションシステム上のポート１１２９は、直接接続することも、または代替として、ケーブリング１１３１によって接続することもできる。ナビゲーションシステム及び地理データベースの他の面は、先に説明した実施例に類似、または同一である。
【０１２１】
代替実施例では、地理データベース１４１は、ＲＤＳ−ＴＭＣシステム以外のシステムからの交通放送メッセージを支援する位置参照データベースを含むことができる。これらの他のシステムの例は、ＧＡＴＳ、ＶＩＣＳ、及びＩＴＳ Ｄａｔｕｍ、並びに所有権を主張できる（プロプラエタリ）システム、及び近い将来開発されるかも知れないシステムを含む。これらの他のシステムは、ＲＤＳ−ＴＭＣシステムにおけるメッセージと類似したメッセージを含むことも、または異なる種類のメッセージを含むこともできる。これらの異なる種類のメッセージは、ＲＤＳ−ＴＭＣシステムのような位置参照システムを含むことも、または他の種類の位置参照を含むこともできる。これらの異なる種類のシステムは、他の位置を暗示的に識別する範囲データを含むことも、または代替として、全ての位置を明示的に識別することもできる。
【０１２２】
別の実施例では、地理データベースは、１つより多くの種類の交通放送メッセージフォーマットを支援する位置参照データベースを含むことができる。例えばＲＤＳ−ＴＭＣシステム、並びにある他のシステムを支援することができる。若干の地域では、各々がそれ自体の種類のメッセージフォーマット及び位置参照番号、等を有している１つより多くの交通放送システムが存在し得る。これらの環境の下では、地理データベースは、各々が分離した位置キーで形成されている分離したセットの位置参照データレコードを含むことができる。これらの分離したセットは、地理データベース１４１内に格納することができる。
【０１２３】
１つより多くの種類の交通放送メッセージングフォーマットを支援するナビゲーションシステム、またはＲＤＳ−ＴＭＣシステム追加される交通放送システムにおいては、地理データベースは、支援している種類の実時間交通放送システムを識別するために、ナビゲーション応用プログラムからの照会を支援することができる。この照会は、位置参照データを地理データベース内に含むか、または地理データベースによって支援されている交通放送システムの識別を戻す。多重交通メッセージングフォーマットを支援するこれらの種類のシステムでは、交通メッセージフォーマットを選択することができるように、プログラミングをナビゲーションシステム内に設けることもできる。選択プロセスは自動とすることも、または代替として、選択プロセスはエンドユーザによって行うこともできる。多重交通放送フォーマットを支援するようにしておくと、異なる交通放送システムフォーマットを有する異なる市を走行するビークルにとって有用であり得る。
【０１２４】
別の代替によれば、その放送交通メッセージ以外のシステムからのナンバリング参照を利用するために、位置参照データエンティティを地理データ内で使用することができる。例えば、若干の型またはクラスの関心点に関するサービスを提供する団体、またはエンティティが存在する。これらの団体の例は、大都市圏内の種々のイベント（例えば、演劇、スポーツ、音楽、映画、コメディ、等々）のチケットを販売するチケット販売業者を含む。チケット販売業者は、チケットが使用される各開催地を参照番号によって識別することができる。この代替実施例によれば地理データベースは、チケット販売業者によって使用される参照番号を、地理データベース内に含まれるデータに関係付ける位置参照データエンティティを含む。この実施例では、地理データベース内の各位置参照データエンティティは、開催地を識別するためにチケット販売業者によって使用される参照番号の１つに対応する。各位置参照データエンティティは、開催地の位置に対応する地理データベース内の対応する関心点データエンティティレコードを識別する。ナビゲーション応用は、それが交通メッセージ情報を使用するのと同じようにして、これらの種類の位置参照データエンティティを使用することができる。ナビゲーション応用は、チケット販売業者から直接的に、または間接的にデータを受信する。データは、無線または非無線通信手段によって受信することができる。チケット販売業者からのデータは、チケット販売業者によって割当てられた識別番号によって開催地を識別する。データは、上演時間、チケットの使用可能性、チケットの値段、プログラム、等々を含むこともできる。ナビゲーション応用は、位置参照データエンティティを使用して、チケット販売業者から受信した情報を、地理データベース内の関心点データエンティティに関係付ける。ユーザは地理データベース内の関心点の使用と共に、チケット販売業者から受信した情報にアクセスすることができる。ユーザは、地理データベースを探索する時に、さらなる基準としてチケット販売業者からのデータを使用することができる。例えば、ユーザは 25 マイル以内の、そして２時間以内に開演される演劇の上演を探索することができる。位置参照番号を使用できる他の種類のシステムは、ホテルチェーン、レストラン団体、不動産ブローカーのオフィス、等々を含む。
【０１２５】
以上の詳細な説明は、単なる例示であって本発明を制限する意図はなく、本発明は特許請求の範囲によってのみ限定されるものであることを理解されたい。
【図面の簡単な説明】
【図１】地理領域内の交通放送システムの成分を示す図である。
【図２】交通放送システムの成分、及び図１に示すナビゲーションシステムを搭載したビークルの１つを示すブロック図である。
【図３】図２の交通メッセージの１つの中に含まれるデータ成分を示す図である。
【図４】図１の領域に対応させることができる地理領域を示す地図である。
【図５】図４の地図の一部を拡大した図である。
【図６】図２の地理データベースの型による編成を示すブロック図である。
【図７】図６の地理データベースのルーティング型の層による編成を示すブロック図である。
【図８】図２の地理データベースの編成を示すブロック図である。
【図９】図１の交通放送システムによって使用される位置参照番号が割当てられている交差点を有する道路の一部を示す図である。
【図１０】図９に示す位置参照番号を、図２及び８に示す地理データベース内に含まれるデータに関係付けるために形成された位置参照キーの成分の図である。
【図１１】位置参照レコードを形成している成分を示すブロック図である。
【図１２】図８に示す位置参照データレコードを含むパーセルの１つ内のデータの編成を示すブロック図である。
【図１３】位置参照レコードのための索引の編成を示すブロック図である。
【図１４】交通放送メッセージデータを地理データと共に使用する図２のナビゲーションシステムのプログラミングによって遂行されるステップを示す流れ図である。
【図１５】図１４に示すプログラミングステップを使用する第１の例が遂行するステップを示す流れ図である。
【図１６】図１４に示すプログラミングステップを使用する第２の例が遂行するステップを示す流れ図である。
【図１７】交通メッセージデータをナビゲーションシステムと共に使用する代替実施例を示すブロック図である。
【符号の説明】
１０ 地域
１２ 道路網
２０ 交通放送システム
２２ センサ
５０ データ
５１ ＲＤＳ−ＴＭＣコード
８０ 非ビークル
１１０ ナビゲーションシステム
１１２ プロセッサ
１１４ ドライブ
１１６ 不揮発性メモリ記憶デバイス
１１８ ナビゲーション応用ソフトウェアプログラム
１２３ 感知デバイス
１２４ 測位システム
１２５ 交通メモリ受信機
１２７ ディスプレイ
１２９ スピーカ
１３１ ユーザインタフェース
１３２ 記憶媒体
１４０ 地図データベース
１４１ ルート計算機能
１４２ ルート案内機能
１４３ 地図表示機能
１４４ ビークル位置決め機能
１４５ 位置参照プログラミング
１４６ 他の機能及びプログラミング
２１０ 地図
２１２ 地理領域
２１４ 位置
２１６ 地図の一部分
２２０ 道路網
２２２ 道路セグメント
２３６ ルーティングデータ
２３７ 地図作成データ
２３８ 運転データ
２３９ 関心点データ
２４０ 合流点データ
２４１ ナビゲーション特色データ
２４３ 郵便番号データ
２４４ 場所データ
２４５ 位置参照データ
２４６ その他のデータ
２４７ 外部索引
２４９ 内部索引
２６０ 位置参照データレコード
３１０ パーセル
３２１ ヘッダー及びグローバルデータ
５００ 道路
５０５ 位置キー
５１０ エントリのリスト
５２１ パーセル内の最小参照エンティティＩＤ
５４５ オフセットテーブル
５４８ 次の位置キー
５５０ 位置参照レコード
５５１ 先行位置キー
７０７ 受信機ルーチン応用
８１０ 交通データ収集プログラム
９０３ 交通データ収集プログラム
１１２５ 交通メッセージ受信機

Claims (30)

1. ナビゲーションシステムにおいて、ナビゲーションソフトウェアプログラムを動作させる方法であって、上記ナビゲーションシステムが、
   a)地理領域内の道路位置での交通状態を示すデータを含む放送交通メッセージを受信し、上記交通メッセージのそれぞれが、
   道路沿いに連続した順番で並ぶ位置参照番号を割当てた複数の指定位置の中から選択される位置であって、上記受信した放送交通メッセージ内で報告された交通状態の開始地点となる上記位置をあらわすデータと、
   前記開始位置から連続した順番で並ぶ上記指定位置を用いて、隣接する複数の上記指定位置で交通状態の範囲を表わすとしたときの上記報告された交通状態の範囲に対応するデータと、
   を含み、
   b)上記交通メッセージのそれぞれから、上記開始位置を示す上記データと上記範囲を示す上記データとを抽出し、
   c)上記開始位置、及び上記範囲が示す上記複数の隣接位置のそれぞれから連なる道路セグメントのうち、交通状態の影響を受けた道路セグメントを特定するために、地理データベースを使用し、
   d)上記交通メッセージに含まれている交通状態を、上記影響を受けた道路セグメントに関連付け、
   e)上記影響を受けた道路セグメントに関連付けられた交通状態を考慮に入れながら、選択された目的地への道路に沿ったルートを計算するために上記地理データベースを使用する、ことを行うための方法。
2. 上記ルート計算を実行する前に、上記交通メッセージに含まれている上記交通状態を、上記交通状態の影響を受けた道路セグメントに関連付ける請求項１に記載の方法。
3. 上記抽出、使用、及び関連付けは、全ての関連交通メッセージが処理されてしまうまで実行される請求項１に記載の方法。
4. 上記交通メッセージに含まれている上記交通状態を上記交通状態の影響を受けた道路セグメントに関連付けは、上記ナビゲーション用ソフトウェアプログラムのルート計算機能の一部として実行される請求項１に記載の方法。
5. 交通状態の変化を示す新しい交通メッセージが受信されるとルートを再計算することを更に含む請求項１に記載の方法。
6. 影響を受けた道路セグメントを上記地理データベース内で特定した後、交通状態を示す上記データに従って上記影響を受けた道路セグメントに重み付けすることを更に備えている請求項１に記載の方法。
7. 上記地理データベースは、オンボードナビゲーションシステム内に配置されている請求項１に記載の方法。
8. 上記ナビゲーション用ソフトウェアプログラムは、ビークルに搭載されたナビゲーションシステム内にインストールされている請求項１に記載の方法。
9. 上記交通メッセージは、ラジオデータシステム・交通メッセージチャンネル（ＲＤＳ−ＴＭＣ）上で放送される請求項１に記載の方法。
10. 上記交通メッセージは、上記ＲＤＳ−ＴＭＣ内に確立されているＡＬＥＲＴ−Ｃのための標準フォーマットに準拠している請求項１に記載の方法。
11. 上記ナビゲーション用ソフトウェアプログラムは、非ビークルシステム内にインストールされている請求項１に記載の方法。
12. 上記受信の処理は受信機において実行され、上記地理データベース使用の処理は上記受信機から分離されているナビゲーションシステムにおいて実行される請求項１に記載の方法。
13. ナビゲーションシステムを動作させる方法であって、
    ビークル搭載のナビゲーションシステムにおいて、複数の放送交通メッセージを放送する交通放送システムから上記放送交通メッセージを受信するステップであって、
    上記各放送交通メッセージは、道路に沿って連続した順番で並ぶ位置参照番号を割当てた指定位置の中から選択した位置を交通渋滞の開始位置として特定する第１のデータ成分と、上記開始位置から連なる交通渋滞のひどさのレベルを指示する第２のデータ成分と、前記開始位置から連続した順番で並ぶ上記指定位置において、隣接する複数の指定位置で上記交通状態の範囲を表わすとき、上記交通渋滞の範囲に関する第３のデータ成分とを含んでいる当該ステップと、
    上記ビークル搭載のナビゲーションシステムにおいて、上記開始位置、及び上記範囲が示す上記複数の隣接位置のそれぞれから連なる道路セグメントのうち、交通状態の影響を受けた道路セグメントを特定するために、地理データベースを使用するステップと、
    上記第２のデータ成分のひどさのレベルを、上記交通状態の影響を受けた道路セグメントに関連付けるステップと、
    上記影響を受けた道路セグメントに関連付けられた交通状態を考慮に入れながら、選択された目的地へのルートを計算するために上記地理データベースを使用するステップと、
    を更に備えていることを特徴とする方法。
14. 上記第１のデータ成分は、上記位置を特定する位置参照番号を含む請求項１３に記載の方法。
15. 上記複数の放送交通メッセージを受信した後に、上記放送交通メッセージから上記第１、第２、及び第３のデータ成分を抽出することを更に備えている請求項１３に記載の方法。
16. 交通状態放送システムによって放送される交通メッセージと共に使用されるナビゲーションシステムで使用される地理データベースであって、
    a)上記交通メッセージのそれぞれが、
    道路に沿って連続した順番で並ぶ位置参照番号を割当てた複数の指定位置の中から選択した位置を前記位置参照番号で特定するとき、上記放送された交通メッセージ内で報告された交通状態の開始位置をあらわす前記位置参照番号と、
    前記開始位置から連続した順番で並ぶ上記指定位置を用いて、隣接する複数の上記指定位置で交通状態の範囲を表わすとしたときの上記報告された交通状態の範囲に対応するデータと、
    を含み、
    b)上記地理データベースが、
    地理領域内の道路網の部分を含む地理的特徴を表す第１の型のデータと、
    連なる道路セグメントを表す第１の型のデータに対して、ある位置参照番号を関連付ける第２の型のデータと、
    を含み、
    これにより、上記交通状態放送システムによって放送される交通メッセージと共に上記地理データベースを使用する上記ナビゲーションシステムは、ルート計算のために上記地理データベースを使用する時に上記交通メッセージからの情報を組み入れることができる、ことを特徴とする地理データベース。
17. 上記第１の型のデータ及び上記第２の型のデータは複数の組(parcel)に編成され、上記各組は上記それぞれの型の複数のデータを含んでいる請求項１６に記載の地理データベース。
18. 上記地理データベースは、複数のデータを各々が含んでいる組に分離されている請求項１６に記載の地理データベース。
19. 上記地理データベースは、分離した型の地理データを含む請求項１６に記載の地理データベース。
20. 上記分離した型の地理データは、ルートデータ及び地図作成データを含んでいる請求項１９に記載の地理データベース。
21. 上記地理データベースは、コンピュータ読み出し可能な記録媒体に格納される請求項１６に記載の地理データベース。
22. 上記地理データベースは、ＣＤ−ＲＯＭディスク、ＤＶＤディスク、及びハードディスクの１つに格納されている請求項１６に記載の地理データベース。
23. 上記第１の型のデータは、道路のセグメントを表している請求項１６に記載の地理データベース。
24. 上記第１の型のデータは道路セグメントを表し、当該道路セグメントは上記交通メッセージ内の上記位置参照番号によって表される上記道路網に沿って存在する道路位置(location)の識別のために用いられる請求項１６に記載の地理データベース。
25. 上記第２の型のデータに対する位置参照番号に関係するインデックスを更に備えている請求項１６に記載の地理データベース。
26. 上記第２の型のデータは複数の組の内に数値的に配列されており、
    上記地理データベースは更に、上記第２の型のデータのために、上記第２の型のデータが配置されている上記複数の各組の１つを特定するインデックスを更に備えている請求項１６に記載の地理データベース。
27. 交通メッセージ内に含まれている上記位置参照番号は、道路インターチェンジを表す請求項１６に記載の地理データベース。
28. 上記地理データベースの少なくとも一部は、遠隔配置されている請求項１６に記載の地理データベース。
29. 上記第２の型のデータは、遠隔配置されている請求項１６に記載の地理データベース。
30. 上記第２の型のデータは、遠隔位置から上記ナビゲーションシステムへダウンロードされる請求項１６に記載の地理データベース。

Images