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

Abstract

(57)【要約】 【課題】 地理データベースを使用するナビゲーション
システムが、交通放送システムによって放送される交通
メッセージ内のデータをも使用できるようにするシステ
ム及び方法を提供する。 【解決手段】 一面では、位置参照データレコードを形
成し、ナビゲーションシステムが使用する地理データベ
ース内に格納し、使用する。これらの位置参照レコード
は、道路のセグメントを表すデータレコードのような物
理的な地理特色を表す他の種類のデータレコードを、位
置参照番号に関連付けて識別する。別の面では、交通放
送システムが使用する位置参照番号をナビゲーションシ
ステムが使用する地理データベース内の位置参照レコー
ドに関係付ける１つ以上の索引を形成し、格納し、使用
する。別の面では、各位置参照番号毎に、直前、直後の
位置参照番号を識別するデータベースを形成し、格納
し、使用する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ナビゲーションシ
ステムにおいて、交通及び道路状態の実時間放送を使用
するシステム及び方法に関し、詳しく述べれば、本発明
は、地理データベースを使用するナビゲーションシステ
ムにおいて、交通情報放送データの使用及び協調を容易
にし、実施するシステム及び方法に関する。

【０００２】

【従来の技術】若干の地方及び大都市圏、及び国におい
ては、交通及び道路状態情報の極く最新の報告を放送す
るシステムが実現されている。これらのシステムは、交
通及び道路状態情報を連続的に、定期的に、または頻繁
に放送する。これらの放送は、その地方を走行している
ビークルに搭載された受信機によって受信することがで
きる。搭載受信機は放送をデコードし、報告内の情報を
ビークルの運転手が利用できるようにする。

【０００３】これらの交通報告放送システムは、ラジオ
局を通して簡単な交通情報を放送するよりも幾つかの利
点を有している。例えば、これらの交通放送システムに
よって運転手は情報をより迅速に入手することができ
る。運転手は、ラジオ局が交通情報を放送するまで待つ
必要はない。これらの交通放送システムの別の利点は、
運転手は彼／彼女が居る位置から離れた領域の交通状態
の情報を聞く必要がないことである。交通放送システム
の別の利点は、より詳細な、そして多分より最新の情報
を入手できることである。

【０００４】これらの型のシステムでは、放送される交
通情報は、１つまたはそれ以上の予め確立された仕様ま
たはフォーマットに準拠している。これらの仕様または
フォーマットは、その領域内を走行しているビークルに
搭載された受信機によって使用され、交通報告メッセー
ジがデコードされる。

【０００５】実時間交通及び道路状態を放送する１つの
システムは、無線データシステム・交通メッセージチャ
ンネル（ Radio Data System - Traffic Message Chann
el :“ＲＤＳ−ＴＭＣ”）である。ＲＤＳ−ＴＭＣシス
テムは、若干の欧州諸国で使用されている。ＲＤＳ−Ｔ
ＭＣシステムに関しては、“ Radio Data System, CENE
LEC END50067:1996, Specification of the Radio Data
System."を含むいろいろな刊行物に記載されている。
ＲＤＳ−ＴＭＣシステムは、ＦＭ局データチャンネルを
使用して交通メッセージをビークルに放送する。ＲＤＳ
−ＴＭＣメッセージは、イベントの優先順位に依存して
定期的に、または変化する間隔で放送される。他の諸国
及び領域においても同じような、または同一のシステム
が使用されているか、または計画されている。

【０００６】交通渋滞の位置を識別するために、現在使
用されている、並びに近い将来のために計画中の交通及
び道路状態放送システムは、カバーしている領域内の位
置にコードを割当てる。例えば、ＲＤＳ−ＴＭＣシステ
ムでは、カバーしている地理領域内の道路に沿う特定位
置に、位置参照コードを割当てる。これらの位置は、交
差点、インターチェンジ、または道路の一部分であるこ
とができる。次いで、これらの位置に関係する交通状態
を識別するデータメッセージが放送される。一般的に言
えば、これらの位置は、高速道路及び主要道路のような
交通量の多い道路に関係付けられる。

【０００７】運転手を援助するために開発された別の分
離した技術は、ビークルナビゲーションシステムであ
る。ビークルナビゲーションシステムは、ビークルの運
転手、その他にいろいろなナビゲーティング特色を提供
する。ビークルナビゲーションシステムによって提供さ
れる特色は、交通放送システムによって提供される特色
とは異なっている。例えば、ナビゲーションシステム
は、運転手のために特定のルートを計算することができ
る。運転手のために計算されたルートは、カバーしてい
る地理領域のどの街位置から開始することもでき、カバ
ーしている地理領域内の他のどの街位置に位置する目的
地をも有することができる。ビークルナビゲーションシ
ステムは、運転手にルート案内をも提供することができ
る。ルート案内機能は、運転手のためのルート計算に特
定であることもできる。ルート案内機能は、そのルート
を辿って走行している運転手に対して可聴的に、または
視覚的に運転操作（以下、単に運転という）命令を供給
することができる。ナビゲーションシステムは、ビーク
ルの現在位置から２マイル以内の全てのイタリアンレス
トランのような、所与の探索領域内の特定の型の１つま
たはそれ以上の目的地を見出すような他の特色を提供す
ることもできる。これらの種類の機能を提供するため
に、ナビゲーションシステムは、ビークル内に位置して
いるか、または無線通信リンクを通してアクセス可能な
詳細な地理データベースを使用する。

【０００８】交通放送システムも、ナビゲーションシス
テムも、運転手に対して貴重な特色を提供することがで
きる。しかしながら、もし交通放送報告内のデータをナ
ビゲーションシステム特色と共に使用すれば、さらなる
有用な特色を提供することができる。例えば、もしナビ
ゲーションシステム内のルート計算機能を使用してルー
トを計算する時に、交通メッセージ内のデータが使用で
きれば有利である。不幸にも、ＲＤＳ−ＴＭＣシステム
のような交通放送システムによって放送される報告内の
データは、ナビゲーションシステムによって使用される
データに関係付けられていない。例えば、交通放送シス
テムのオーソリティによって割当てられた位置番号は、
ナビゲーションシステムによって使用される地理データ
ベース内のデータレコードによって表される何等かの物
理的特色に直接関係付けられてはいない。

【０００９】従って、放送される交通情報を、地理デー
タベースを使用するビークルナビゲーションシステムと
共に使用する要望が存在している。

【００１０】

【発明の要旨】上述した諸問題に対処するために、地理
データベースを使用するナビゲーションシステムが、交
通放送システムによって放送される交通メッセージ内の
データをも使用できるようにしたシステム及び方法が提
供される。本実施例の一つの面は、ナビゲーションシス
テムによって使用される地理データベース内の位置参照
データレコードの形成、格納、及び使用を含む。これら
の位置参照データレコードは、道路のセグメントを表す
データレコードのような物理的地理特色を表す若干の他
の種類のデータレコードを、若干の位置参照番号に関連
付けることによって識別する。これらの位置参照データ
レコードは、ビークル内に設置された地理データベース
内に含ませることも、または無線通信リンクを通してビ
ークルに供給することもできる。

【００１１】本実施例の別の面は、交通放送システムに
よって使用される位置参照番号を、ナビゲーションシス
テムによって使用される地理データベース内の位置参照
データレコードに関連付ける１つまたはそれ以上の索引
の形成、格納、及び使用を含む。

【００１２】本実施例の別の面は、位置参照データレコ
ードを、パーセルで形成、格納、及び使用することであ
る。

【００１３】本実施例の更に別の面は、各位置参照番号
毎に、直前及び直後の位置参照番号を識別するデータを
形成、格納、及び使用することである。

【００１４】本実施例の更に別の面は、地理データベー
スを照会し、若干の識別された位置参照番号に関連する
データエンティティを戻すプログラミング、及びその使
用方法を含む。

【００１５】本実施例の別の面は、地理データベースを
使用する多くの異なる型の交通メッセージシステムを支
援する能力である。

【００１６】本実施例の別の面は、地理データベースを
使用するナビゲーション応用へ送信される実時間交通デ
ータの使用を支援する地理データベースを含む。実時間
交通データを送信する手段は、放送及び直接伝送のよう
な無線伝送の形状、並びに、電話及びデータ回線のよう
な非無線伝送の形状である。

【００１７】

【実施例】Ｉ．交通放送システム − 概要 図１は、ある地域１０を示す図である。地域１０は、ニ
ューヨーク大都市圏、ロスアンジェルス大都市圏、また
は他の何れかの大都市圏のような大都市圏であることが
できる。代替として、地域１０は、カリフォルニア、イ
リノイ、フランス、イングランド、またはドイツのよう
な州（ステート）、プロビンス、または国であることも
できる。代替として、地理領域１０は、１つまたはそれ
以上の大都市圏、州、国、等々であることができる。地
域１０内には、道路網１２が位置している。

【００１８】交通放送システム２０は地域１０内に位置
している。交通放送システム２０は地域１０内の交通及
び道路状態に関するデータ５０を放送する。交通放送シ
ステム２０は、政府機構によって動作させることも、ま
たは私企業が動作させることもできる。一実施例では、
交通放送システム２０はＲＤＳ（ラジオデータシステ
ム）標準に準拠しているが、代替システムを使用するこ
とができる。

【００１９】ビークル１１（Ａ）、１１（Ｂ）、１１
（Ｃ）、・・・、１１（ｎ）は、地域１０内の道路網１
２上を走行している。ビークル１１は、乗用車またはト
ラックを含むことができる。若干の、または全てのビー
クル１１は、交通放送システム２０によって放送される
交通及び道路状態を受信可能な適当な機器を含む。

【００２０】交通放送システム２０から放送されるデー
タ５０は、ビークル内に設置されていないシステム（例
えば、「非ビークル８０」）においても受信され、使用
される。これらの非ビークル８０は、ワークステーショ
ン、パーソナルコンピュータ、パーソナルディジタル支
援、ネットワーク、ページャ、テレビジョン、ラジオ受
信機、電話機、等々を含むことができる。データ５０を
受信する非ビークル８０はビークルと同じようにして、
即ち放送によってデータを入手することができる。代替
として、非ビークル８０は、電話回線を通して、インタ
ーネットを通して、ケーブルを介して、等々のような他
の手段によってデータ５０を受信することができる。交
通データ５０を受信するビークル１１内の、または非ビ
ークル８０内のシステムは、いろいろな異なるプラット
フォームを含むことができる。

【００２１】図２は、図１の交通情報放送システム２０
の成分、及びビークル１１の１つを示している。交通情
報放送システム２０は、交通及び道路状態に関するデー
タを集め、これらの集めたデータを解析して編成し、解
析したデータを交通メッセージにフォーマットして地域
１０内のビークル１１にこれらの交通メッセージを定期
的に及び連続して送信するようになっている。

【００２２】交通放送システム２０は、いろいろなセン
サ２２から地域１０内の交通及び道路状態に関するデー
タを集めるための機器及びプログラミング２０（１）を
含んでいる。この機器及びプログラミング２０（１）
は、例えば、いろいろな通信リンク（無線リンクを含
む）、受信機、データ記憶デバイス、集めたデータを保
管するプログラミング、データを集めた時刻及び位置を
ログするプログラミング、等々を含む。交通放送システ
ム２０は、集めた交通及び道路状態データをアセンブル
し、編成し、解析し、そしてフォーマットするための機
器及びプログラミング２０（２）を含んでいる。このプ
ログラミング及び機器２０（２）は、記憶デバイス、集
めたデバイスを潜在的なエラーについて統計的に解析す
るプログラミング、集めたデータを編成するプログラミ
ング、データを使用して１つまたはそれ以上の適切な所
定のフォーマットでメッセージを準備するプログラミン
グを含む。交通放送システム２０は、データを放送する
ための適当な機器及びプログラミング２０（３）をも含
んでいる。機器及びプログラミング２０（３）は、送信
機へのインタフェース、フォーマットされたメッセージ
を定期的な間隔で送信機へ通信するプログラミング、等
々を含む。交通放送システム２０は、送信機器２０
（４）をも含んでいる。この機器２０（４）は、アンテ
ナを含む１つまたはそれ以上のＦＭ送信機、または他の
無線送信機からなることができる。この機器２０（４）
は、フォーマットされたメッセージを、その地域１０全
体の交通及び道路状態データ５０として放送するように
なっている。放送機器２０（４）は、交通放送システム
２０の一部であることも、または代替として、放送シス
テム２０はセルラまたはページングシステム、ＦＭラジ
オ局、等々のような他の型のシステムからの放送機器を
使用して、地域内のビークル１１へ交通メッセージを放
送することもできる。（本明細書の目的及び特許請求の
範囲から、交通メッセージの放送は、直接無線伝送を含
むどのような伝送の形状をも含むものとする。）図３
は、交通メッセージ５０の１つのデータ成分を示してい
る。交通メッセージ５０は、いろいろな種類の情報を含
むことができる。交通メッセージ５０が含むことができ
る情報の１つの有用な種類は、交通渋滞に関するもので
ある。交通渋滞に関する情報を提供するために使用する
場合、交通メッセージ５０は、渋滞している道路に沿う
１つまたはそれ以上の位置、渋滞がどれ程酷い状態にあ
るのか、及びその渋滞がどれ程遠くまで伸びているかを
識別するデータを含む。

【００２３】図３に示す実施例においては、交通メッセ
ージ５０は、以下のデータ成分を含む。即ち、イベント
記述５０（１）、位置５０（２）、方向５０（３）、範
囲５０（４）、持続時間５０（５）、及び助言５０
（６）である。代替実施例では、交通メッセージ５０
は、他の情報５０（ｎ）を提供する成分を含むこともで
きる。

【００２４】イベント記述成分５０（１）は、交通問題
５０（１）（１）を、この交通問題５０（１）（１）の
酷さのレベルを記述するデータと共に記述するデータを
含んでいる。

【００２５】位置成分５０（２）は、交通問題５０
（１）（１）の位置を識別する参照番号を含んでいる。

【００２６】方向成分５０（３）は、影響されている交
通の方向を指示するデータを含んでいる。

【００２７】範囲成分５０（４）は、位置５０（２）に
対する交通渋滞の列の長さを識別するデータを含んでい
る。範囲成分５０（４）は、交通状態の別の（例えば、
二次位置）範囲を、その間の位置参照の数の表現で暗示
的に定義する。

【００２８】助言成分５０（６）は、迂回ルートの推奨
を提供する。

【００２９】一実施例によれば、交通メッセージ５０
は、ＲＤＳ−ＴＭＣシステムに確立されているＡＬＥＲ
Ｔ−Ｃメッセージのための標準フォーマットに準拠して
いる。例えば、ＲＤＳ−ＴＭＣシステムにおいては、メ
ッセージ５０の位置５０（２）部分はＲＤＳ−ＴＭＣコ
ード５１内に含まれる。ＲＤＳ−ＴＭＣコード５１は、
位置番号５１（１）、位置テーブル番号５１（２）、国
別コード５１（３）、及び方向５１（４）を含んでい
る。位置番号５１（１）は、１つの位置テーブル（即
ち、番号のデータベース）が対応しているある地域に独
特の番号である。位置テーブル番号５１（２）は、分離
した各位置テーブルに割当てられた独特の番号である。
国別コード５１（３）は、位置番号５１（１）によって
参照される位置が位置している国を識別する番号であ
る。方向５１（４）は、双方向性、及びセグメントがそ
の合流点の外部にあるか否かのようなファクタを斟酌す
る。ＲＤＳ−ＴＭＣコード５１は、ある列内のメッセー
ジ５０内で以下のように発表されている。

【００３０】ＡＢＣＣＤＥＥＥＥＥ ここに、 Ａ：道路セグメントの方向（＝方向５１（４））、 Ｂ：国別コード（＝国別コード５１（３））、 ＣＣ：位置データベース番号（＝位置テーブル番号５１
（２））、 Ｄ：ＲＤＳ方向（＋、−、Ｐ、Ｎ）（＝方向５１
（４））、 ＥＥＥＥＥ：位置コード（＝位置番号５１（１））。

【００３１】地域１０内の、適切な機器を搭載している
ビークル１１は、これらの交通メッセージ５０を受信す
ることができる。これらのメッセージ５０は、これらの
ビークル内の運転手または乗客に提供することができ
る。

【００３２】II. ビークル搭載ナビゲーションシステム
− 概要 再び図２に戻って、図２は図１のビークル１１の１つの
成分を示している。前述したように、ビークル１１は乗
用車またはトラックであることができる。ビークル１１
に搭載されているのは、ナビゲーションシステム１１０
である。ナビゲーションシステム１１０は、ハードウェ
ア及びソフトウェア成分の組合せである。一実施例で
は、ナビゲーションシステム１１０は、プロセッサ１１
２、プロセッサ１１２に接続されているドライブ１１
４、及びナビゲーション応用ソフトウェアプログラム１
１８及び多分他の情報を格納する不揮発性メモリ記憶デ
バイス１１６を含んでいる。プロセッサ１１２は、日立
ＳＨ 1、インテル 80386、インテル 960、モトローラ 6
8020のような、フラットアドレス空間を使用する 32 ビ
ットプロセッサ（または類似の、またはより大きいアド
レス空間を有する他のプロセッサ）のような、ナビゲー
ションシステムに使用されるどのような型であることも
できる。これら以外の型、及び近い将来開発されるかも
知れないプロセッサも適している。

【００３３】ナビゲーションシステム１１０は、測位シ
ステム１２４を含むこともできる。測位システム１２４
は、ＧＰＳ型技術、推測型システム、またはこれらの組
合せ、または他のシステム（これらは全て当分野におい
ては公知である）を使用することができる。測位システ
ム１２４は、ビークルの走行距離、速度、方向、等々を
測定する適当な感知デバイス１２３を含むことができ
る。測位システム１２４は、当分野において公知の手法
でＧＰＳ信号を入手する適切な技術を含むこともでき
る。測位システム１２４は、信号をプロセッサ１１２へ
出力する。測位システム１２４からの信号は、プロセッ
サ１１２上で走るナビゲーション応用ソフトウェア１１
８によって使用され、ビークル１１の位置、方向、速
度、等を決定することができる。

【００３４】ビークル１１は、交通メッセージ受信機１
２５を含んでいる。受信機１２５は、交通放送システム
２０が交通メッセージ５０を放送するのに使用している
適切な周波数に同調させたＦＭ受信機であることができ
る。受信機１２５は、交通放送システム２０から交通メ
ッセージ５０を受信する。（セルラ無線伝送を介しての
ような直接無線伝送によって交通メッセージが送られる
代替実施例では、ビークル１１内の受信機１２５は、セ
ルラ電話機に類似、または同一であることができる。）
以下に詳細に説明するように、受信機１２５は、ナビゲ
ーションシステム１１０内の適切なプログラミングがナ
ビゲーション機能を遂行する時に、交通放送システム２
０によって放送されたデータを利用することができるよ
うに、出力をプログラミング１１２へ供給する。

【００３５】ナビゲーションシステム１１０は、ユーザ
インタフェース１３１をも含む。ユーザインタフェース
１３１は、エンドユーザ（例えば、運転手または乗客）
がナビゲーションシステム内へ情報を入力できるように
する適切な機器を含む。この入力情報は、ナビゲーショ
ンシステムのナビゲーション特色の使用の要求を含んで
いる。例えば、入力情報は、所望の目的地までのルート
に関する要求を含むことができる。入力情報は、他の種
類の情報に対する要求を含むこともできる。ナビゲーシ
ョンシステム１１０内へ情報を入力するために使用され
るユーザインタフェース機器は、キーパッド、キーボー
ド、マイクロホン、等々、並びに音声認識プログラムの
ような適切なソフトウェアを含むことができる。ユーザ
インタフェース１３１は、エンドユーザへ情報を戻す適
当な機器も含む。この機器は、ディスプレイ１２７、ス
ピーカ１２９、または他の手段を含むことができる。

【００３６】ナビゲーションシステム１１０は、記憶媒
体１３２上に格納されている地図データベース１４０を
使用する。記憶媒体１３２は、地理領域のための適切な
地図データベースを有する記憶媒体を、走行中のビーク
ルが使用できるように取り外し可能であり、置換可能で
ある。更に記憶媒体１３２は置換可能であるので、その
上の地図データベース１４０を容易に更新することがで
きる。一実施例では、地理データ１４０はカリフォルニ
ア州サニービルの Navigation Technologiesから出版さ
れている地理データベースであることができる。

【００３７】一実施例においては、記憶媒体１３２はＣ
Ｄ−ＲＯＭディスクである。代替実施例においては、記
憶媒体１３２はＰＣＭＣＩＡカードであることができ、
この場合ドライブ１１４はＰＣＭＣＩＡスロットに置換
される。固定またはハードディスク、ＤＶＤ、または現
在市販されている他の記憶媒体、並びに近い将来開発さ
れるかも知れない記憶媒体を含む他のさまざまな記憶媒
体を使用することができる。記憶媒体１３２及び地理デ
ータベース１４０は、物理的にナビゲーションシステム
の位置に設ける必要はない。代替実施例においては、地
理データ１４０の若干、または全てを格納している記憶
媒体１３２をナビゲーションシステムの残余から離して
配置し、地理データの一部を必要に応じて通信リンクを
介して供給することができる。

【００３８】ナビゲーションシステムを動作させるため
にナビゲーション応用ソフトウェアプログラム１１８
は、不揮発性メモリ１１６からプロセッサ１１２に組合
されているＲＡＭ２０内へロードされる。プロセッサ１
１２は、ユーザインタフェース１３１からの入力も受信
する。入力は、ナビゲーション情報に対する要求を含む
ことができる。ナビゲーションシステム１１０は、記憶
媒体１３２に格納されている地図データベース１４０
を、多分測位システム１２４及び受信機１３２からの出
力と共に使用して、さまざまなナビゲーション特色及び
機能を提供する。ナビゲーション応用ソフトウェアプロ
グラム１１８は、これらのさまざまなナビゲーション特
色及び機能を提供する分離した応用（または、サブプロ
グラム）を含むことができる。これらの機能及び特色
は、ルート計算１４１（エンドユーザによって識別され
た目的地までのルートを決定する）、ルート案内１４２
（所望の目的地へ到達するために詳細な指示を供給す
る）、地図表示１４３、ビークル位置決め１４４（例え
ば、マップマッチング）を含むことができる。ナビゲー
ションシステム上のプログラミング１１８には、後述す
る位置参照プログラミング１４５も含まれている。これ
らに加えて、他の機能及びプログラミング１４６もナビ
ゲーションシステム１１０に含ませることができる。ナ
ビゲーション応用プログラミング１１８は、Ｃのような
適当なコンピュータプログラミング言語で書くことがで
きるが、Ｃ＋＋、または Java のような他のプログラミ
ング言語も適当である。

【００３９】上述した全ての成分は普通のもの（また
は、普通ではないもの）であり、これらの成分の製造及
び使用は当分野においては公知である。

【００４０】III. 地理データベース Ａ．概要 一実施例では、ナビゲーションシステムの速度及び／ま
たは機能は、データを使用するシステム内のナビゲーシ
ョン応用プログラム内の若干の機能によるデータの使用
を容易にするために、システムが使用する地理データの
格納、配列、及び／または構成の改良を含む組合せによ
って強化することができる。地理データを格納、配列、
及び／または構成する手法に基づいて、データにアクセ
スしてそれを使用するナビゲーション応用プログラム内
の機能は、地理データ内に組み込まれた改良を活用する
ルーチンを実現することができる。この組合せによっ
て、ナビゲーションシステムの性能が総合的に改善され
る。

【００４１】地図データベース１４０は、地理領域内の
道路網に関する情報を含む。一実施例では、地図データ
ベース１４０は、ノードデータ及びセグメントデータを
含む。これらのデータは物理的な道路網の成分を表して
いる。ノードデータは地理領域内の物理的位置（例え
ば、道路の交差点、及び他の位置）を表し、セグメント
データはノードによって表される物理的位置の間の道路
の部分を表す。地理領域内の各道路セグメントは、地図
データベース１４０内の道路セグメントデータエンティ
ティ（即ち、レコード）によって表される。地図データ
ベース内の各道路セグメントデータレコードは、道路セ
グメントデータレコードによって表される道路セグメン
トの各端における座標位置を表す２つのノードを有して
いる。ノード及びセグメントデータエンティティ内に含
まれる情報を、図４及び５に関連して以下に説明する。
（用語「ノード」及び「セグメント」は、これらの物理
的な地理特色を記述する唯一の用語であり、これらの特
色を記述する他の用語もこれらの概念の範囲内に含まれ
ることを意図している。） 図４は、地理領域２１２を示す地図２１０である。図４
の地理領域２１２は図１及び２の地理領域１０に対応さ
せることも、または地理領域２１２は異なる境界を有す
ることもできる。本実施例では、交通放送システム２０
が交通状態サービスを提供している地域１０（図１）
は、地理データベース１４０によって表される地域２１
２（図４）内に包含されている。

【００４２】図４には、複数の位置２１４が、地理領域
２１２内に位置しているように示されている。各位置２
１４は、地理データベース内に情報が含まれていること
が望まれる特色が位置する地理領域２１２内の場所、ま
たは点を表している。これらの各位置２１４は個々の物
理的位置（緯度、経度、及びオプションとして絶対また
は相対高度）を有し、各位置２１４はその二次元（また
は、三次元）地理座標（即ち、緯度、経度、及びオプシ
ョンとして高度）によって個々に識別することができ
る。位置２１４は、２つまたはそれ以上の道路が出会う
交差点、道路の方向が変化する道路セグメントに沿う
点、速度制限が変化する道路セグメントに沿う点、道路
が行き止まりになる点、等々に対応させることができ
る。位置２１４は、ホテルまたは市民センターのような
関心点の位置に対応させることも、湖のような自然特色
の境界、または鉄道軌道またはフェリーに沿う位置に対
応させることもできる。各位置２１４は、地理領域２１
２内に物理的に位置する何かに対応させることができ
る。

【００４３】図５は、地図２１０の部分２１６の拡大図
である。図５の部分２１６は、地理領域２１２内の道路
網２２０の一部を示している。道路網２２０は、図１及
び２の道路網１２に対応させることも、または代替とし
て、道路網２２０と１２とは異なることもできる。本実
施例では、交通放送システム２０が交通状態データを提
供する道路網１２は、地理データベース１４０によって
表される道路網２２０内に包含されている。道路網２２
０は、特に、地理領域２１１２内に位置する道路及び交
差点を含んでいる。図５に地図２１０の部分２１６とし
て示すように、地理領域２１２内の各道路は１つまたは
それ以上のセグメント２２２（１）、２２２（２）・・
・２２２（ｎ）からなる。一実施例では、道路セグメン
トは、道路の一部分を表す。図５では、各道路セグメン
ト２２２は、それに２つのノード２２３が関連付けられ
ている。即ち、１つのノードが道路セグメントの一方の
端における点を表し、他方のノードがその道路セグメン
トの他方の端における点を表している。道路セグメント
の何れかの端のノードは、例えば交差点のようにその道
路が別の道路と出会う位置、または道路の行き止まりの
位置に対応させることができる。

【００４４】１つの型の地理データベースでは、ある地
理領域内に表されている各道路セグメント毎に、少なく
とも１つのデータベースエントリ（「エンティティ」と
も「レコード」とも呼ぶ）が存在する。この道路セグメ
ントデータレコードは、道路セグメントに関連するノー
ド、及び／または２つのノードの地理的位置（例えば、
緯度及び経度座標）を識別可能にする情報（「属性」、
「フィールド」等のような）を、それに関連付けること
ができる。更に、道路セグメントレコードは、道路セグ
メントレコードによって表される道路の部分の走行速
度、道路セグメントレコードによって表される道路部分
上で許される走行方向、道路セグメントレコードによっ
て表される道路部分の両端における交差点に対応する各
ノードにどの（もしあれば）転回禁止が存在するのか、
道路セグメントレコードによって表される道路部分の街
路番地範囲、道路名、等々を指定する情報（例えば、よ
り多くの「属性」、「フィールド」等）をそれに関連付
けることもできる。直線以外の道路セグメントを表す各
セグメントデータエンティティは、その道路セグメント
の直線以外の形状を定義する１つまたはそれ以上の形状
点データ属性を含むことができる。道路セグメントに関
連するいろいろな属性は、単一の道路セグメントレコー
ド内に含ませることができ、または好ましくは、互いに
相互参照し合う１つの型より多い道路セグメントレコー
ド内に含ませる。

【００４５】地理領域２１２を表す地理データベースに
おいては、地理領域内の各ノード毎にデータベースエン
トリ（エンティティまたはレコード）も存在することが
できる。ノードデータレコードは、それに接続されてい
る１つ以上の道路セグメント及び／またはその地理的位
置（例えば、その緯度及び経度座標）を識別可能にする
情報（「属性」、「フィールド」等のような）を、それ
に関連付けることができる。

【００４６】Ｂ．地理データの分離したサブセット 図６は、データ型によって地理データベース１４０の編
成を示す図である。いろいろなナビゲーション機能を遂
行するために地理データのアクセスを強化することを可
能にする１つの方法は、ナビゲーション応用プログラム
１１８内の各分離した機能（例えば、１４１−１４６）
によって使用される地理データ１４０の分離した集ま
り、即ちサブセットを設けることである。

【００４７】これらの分離した各サブセットは、特定の
１つの機能によって使用されるように合わされている。
例えば、ルート計算機能１４１（図２）は、通常は、あ
る道路のあるセグメントに関連する地理データベース内
の全ての情報の一部分しか必要としない。ルート計算機
能１４１が走っている場合には、道路セグメントに沿う
速度、１つの道路セグメントから別の道路セグメントへ
の転回禁止、等々のような情報を要求するかも知れな
い。しかしながら、ルート計算機能１４１は、ルートを
計算するためには必ずしも道路名は必要としない。同様
に、地図表示機能１４３が使用されている場合、速度制
限または転回禁止のような道路セグメントに関連する情
報の若干は必要ない。代わりに、地図表示機能１４３が
走っている時には、道路の形状及び位置、及び多分道路
名のような道路セグメントに関連する情報の一部分だけ
を使用する。また更に、ルート案内機能１４２が走って
いる場合には、速度及び転回禁止のような道路のセグメ
ントに関連する若干の情報は不要である。代わりに、ル
ート案内機能１４２が走っていいる時には、この機能
は、道路セグメントによって表される道路名、その道路
セグメントに沿う番地範囲、その道路セグメントに沿う
交通標識、等を含む情報を使用する。さまざまなナビゲ
ーション機能が使用する情報の型に関しては若干の重な
りが存在し得るが、これらのナビゲーション機能の何れ
か１つが使用するデータの若干は、別の機能は使用しな
い。もし各道路セグメントに関する全ての情報が単一の
データベース内の単一のデータエントリに関連付けられ
ていれば、各データエンティティは比較的大きくなる。
従って、ナビゲーション機能の何れか１つがエンティテ
ィレコードにアクセスすると、その機能は、殆どはその
ナビゲーション機能が必要としないかなりな量の情報
を、メモリ内に読み込まなければならない。更に、ディ
スクからデータエンティティを読み込む場合、各データ
エンティティが比較的大きいことから、一時に比較的僅
かなデータエンティティしか読み込むことができない。

【００４８】各ナビゲーション機能が使用するのにより
効率的なフォーマットで地理データベース内の情報を提
供するために、ナビゲーション応用プログラム１１８内
に供給される異なる型の各ナビゲーション機能毎に、所
与の地理領域の地理データベース全体の分離したサブセ
ットが設けられる。

【００４９】図６に、分離したルーティングデータ２３
６、地図作成データ２３７（地図表示用）、運転データ
２３８（ルート案内用）、及び関心点データ２３９（ホ
テル、レストラン、博物館、スタジアム、空港、等のよ
うな特定関心点識別用）、及び合流点データ２４０（名
前のある交差点の識別用）からなる地理データベース１
４０を示す。これらの型のデータの他に、地理データベ
ース１４０はナビゲーション特色データ２４１を含むこ
とができる。このデータのサブセットは、郵便番号２４
３及び場所２４４（例えば、市、州、及び国）のための
データサブセットを含むこともできる。一実施例では、
地理データベース１４０は、後述する位置参照のための
データ２４５の分離したサブセットを含む。地理データ
ベースは、これらより少ない、またはより多くのサブセ
ットを定義することができ、また他の型のデータ２４６
を定義し、含むことができる。

【００５０】データの各サブセットは、特定のナビゲー
ション機能が使用するために必要なデータだけを含んで
いる。これらの各サブセットの間には若干の重なりが存
在しており、その結果、情報の若干の部分が１つより多
くのサブセット内に含まれることがあり得る。例えば、
ルーティングデータサブセット２３６内の道路セグメン
トデータエンティティ、並びに地図作成データサブセッ
ト２３７内の道路セグメントデータエンティティが共
に、セグメントの両端に位置するノードを識別する属性
を含むことがあり得る。この重複によりデータ記憶要求
は大きくなり得るが、より少量のデータを処理するとい
う結果的な効率によって各ナビゲーション機能に利益が
もたらされる。

【００５１】各ナビゲーション機能毎に地理データの分
離したサブセットを設ける場合、これらの各ナビゲーテ
ィング機能の使用が他のナビゲーション機能に予測でき
るように関係することをも考えておく。例えば、エンド
ユーザは、先ず現在の位置を見たいと思い、次に目的地
を入力し、次に目的地に向かってどのように出発するか
の命令を受け、次にルートの始めの部分を示す地図を見
て、さらなる命令を受け、ルートの次の部分を示す地図
を表示させたい思う、等々であろう。使用がこのように
予測されるので、データをサブセットに分割すると、分
離された各機能を使用する場合にデータの使用が効率的
になる。

【００５２】地理データをサブセットに分割すると、異
なる各ナビゲーション機能によるデータの使用は効率的
になるが、データベースのこれらの異なるサブセットを
使用する異なるナビゲーティング機能を一緒に動作させ
ることが必要になる。例えば上述した例では、計算され
たルートをエンドユーザが入手した後に、計算されたル
ートをハイライトさせた地図をコンピュータディスプレ
イ上に表示させることが望ましいであろう。これを達成
するために、先ず地理データのルーティングサブセット
２３６にアクセスして最適ルートのためのルーティング
道路セグメントデータエンティティを入手し、次に地理
データベースの地図作成サブセット２３７にアクセスし
てそのルーティングデータエンティティに対応する地図
作成道路セグメントデータエンティティを入手する。こ
れらのデータサブセットを一緒に動作させることができ
るように、相互参照、探索木、または他のデータ探索技
術を提供する索引を含ませることができる。これらの索
引は、何れかのデータの中に、または何れかのサブセッ
トの外部に配置することができる。図６には、外部索引
２４７が示されている。索引を、索引されるデータの外
部に格納すると、いろいろなデータのサブセットの中の
どのデータを次にロードするのかを決定するために索引
をロードし、使用することができる。

【００５３】Ｃ．地理データの層化 地理データを編成してそれらの使用を強化することがで
きる別の方策は、データを層で供給することである。若
干のナビゲーション機能（図２の地図表示機能１４３及
びルート計算機能１４１のような）は、詳細さのレベル
が異なるデータを使用することができる。例えば、地図
表示機能１４３を使用する場合、パンニングまたはズー
ミングを行うことが望ましい場合がある。ズーミング
は、もしデータが層に編成され、低い層がより詳細に、
高い層はそれ程詳細ではないようになっていれば、より
効率的に行うことができる。ルート計算機能１４１を使
用する場合、詳細さのレベルが異なるデータを使用する
ことも有利である。例えば、２つの位置間のルートを計
算する時に、そのルートに沿う各交差点から分れる補助
街路及び小道を含む全ての可能性のある道路セグメント
を調べることは非効率的である。その代わりとして、あ
るルートが主要道路または高速道路「上」に決定された
場合には、一般に、目的地が近づいて補助道路へ出る必
要を生ずるまでは主要道路または高速道路上に留まるこ
とが好ましい。もしルーティングデータが層にされてい
れば、可能ならば、ルートを計算する時に補助道路が省
かれている高い層を使用し、検査すべき可能性のある道
路セグメントを最小にすることができる。従って、若干
のデータ型のサブセット内では、地理データは分離した
層に対応する分離した集まり、またはグループで設けら
れる。

【００５４】層化を実現するために、地図データベース
１４０内の各道路セグメントデータレコードは、それが
表している道路の対応する部分のランクをも識別する。
道路セグメントのランクは、その機能クラスに対応させ
ることができる。ランク「４」の道路セグメントは、高
速道路及びフリーウェイのような高ボリュームの、アク
セスが制御されている道路を含むことができる。ランク
「３」の道路セグメントは、少しの速度変化はあるが、
必ずしもアクセスが制御されていない高ボリュームの道
路であることができる。低くランク付けされた道路は対
応する低ボリュームを取扱い、一般的には、より多くの
速度変化、またはより遅い速度を有している。ランク
「０」の道路は、最低のボリュームを取り扱うことがで
きる。例えば、これらは、横路、小道、等を含むことが
できる。

【００５５】道路セグメントデータエンティティのラン
クは、道路セグメントエンティティが含まれている最高
データ層をも指定する。例えば、図７に示すように、ル
ーティング型データ２３６は５つの分離したデータの層
Ｒ０、Ｒ１、Ｒ２、Ｒ３、及びＲ４を含むことができ
る。各層は、ルート計算機能が使用できる詳細さのレベ
ルが異なるルーティングデータの分離した集まりからな
る。地理データベースのルーティングデータ型では、層
０（“Ｒ０”）は「０」またはそれより高いランクを有
する道路セグメントデータエンティティ（及びそれらの
対応するルーティングデータ属性の若干、または全て）
を含む。従って、層０は、地理領域内の全ての道路の全
ての部分に対応する道路セグメントデータエンティティ
を含んでいる。ルーティングデータ２３６の層１は、ル
ーティングデータの分離したサブセット（即ち、集ま
り）からなり、「１」またはそれより高いランクを有す
るルーティングセグメントデータエンティティ（及びそ
れらの対応するルーティングデータ属性の若干、または
全て）だけを含んでいる。ルーティングデータの層２
は、ルーティングデータの分離したサブセットからな
り、レベル「２」またはそれより高いランクを有するル
ーティングセグメントデータエンティティ（及びそれら
の対応するナビゲーションデータ属性の若干、または全
て）だけを含んでいる、等々である。最高層（層ｎ）
は、ｎのランクを有するレコードだけを含む。この実施
例ではｎは４に等しく、他の実施例ではｎは０より大き
いどのような数であることもできる。層が高い程含まれ
るレコードは少なくなるが、これらのレコードは一般的
に高速で走行する道路を表している。

【００５６】同様に、地図作成サブセット型２３７のよ
うな他の型のデータは、分離したデータの層を含むこと
ができる。各層は、地図表示機能が使用できる異なるレ
ベルの詳細さを含んでいる。これらの異なる層の地図作
成データを使用すると、地図表示機能は迅速なパンニン
グ及びズーミングを提供することができる。

【００５７】若干のデータを層に編成するとデータに若
干の重複をもたらすことになるが、層化によって得られ
る効率の増加が、一般的に何等かの欠点を相殺する。上
述した分離した型のデータを使用する場合のように、こ
れらの層を一緒に動作可能にする要望が生まれる。この
目的のために、索引２４９を設けることができる。図７
には、内部索引が示されている。内部索引２４９は、い
ろいろな型のデータの中に含まれている。

【００５８】Ｄ．地理データベースのパーセル化 図８は、データ記憶媒体１３２上に実現された地理デー
タベース１４０の編成を示す図である。媒体１３２上の
地理データベース１４０は、ヘッダー及びグローバルデ
ータ３２１、及び地理データ３１０を含む。ヘッダー及
びグローバルデータ３２１は、データベースによって表
される地域（例えば、図４の２１２）、データベースの
データの解放、どの種類のデータ圧縮（もしされていれ
ば）が使用されているか、等々の識別のような地理デー
タベース１４０全体に関する情報を含んでいる。地理デ
ータ３１０は、地理特色に関するデータを含む。即ち、
地理データ３１０は、ルーティングデータ２３６、地図
作成データ２３７、運転データ２３８、等々のような図
６に表されている異なる型の地理データに対応する全て
のデータを含んでいる。地理データ３１０は、図６に示
した索引２４７、及び図７に示した索引２４９のような
索引をも含んでいる。

【００５９】地図データベース１４０内においては、地
理データ３１０は型によって（図６に示すように）、及
び層を有するこれらの型のための層によって（図７に示
すように）編成されている。各型及び層内においては、
データ３１０は複数のデータエンティティまたはレコー
ドからなる。各型及び層内においては、これらのデータ
エンティティは複数のパーセル３２０にグループ化され
ている。各パーセルは、地理データ３１０の各型または
層を構成している複数のデータエンティティの一部を含
む。一実施例では、各パーセルのサイズは正規データサ
イズ、例えば 16 キロバイト、８キロバイト、等に準拠
している。データレコードのパーセルへのこの編成によ
り、地理データの格納及び検索が容易になる。一実施例
では、図６に表されている、ルーティングデータ２３
６、地図作成データ２３７、運転データ２３８、等々の
ような異なる型の地理データに対応する全てのデータ
が、パーセルに編成される。

【００６０】データをパーセル化する方法が、同時出願
された一連番号 08/740,295 及び 08/924,328 （ 1997
年９月５日付、代理人ドケット No. 7117-61）に開示さ
れており、本明細書にはその開示を参照として採り入れ
ている。

【００６１】IV. 地理的な地図データベースを用いる交
通メッセージの協調 Ａ．概要 一実施例において、交通放送システムによって放送され
る交通メッセージを、これも地理データベースを使用す
るナビゲーションシステムと共に使用することを容易に
する手段が提供される。例えば、図１及び２に示す交通
メッセージシステム２０を参照する。この実施例は、放
送システム２０によって放送される交通メッセージ５０
を、図１、２及び６−８に示す地理データベース１３２
を使用するナビゲーションシステム１１０と共に使用す
るのを容易にする手段を提供する。放送交通メッセージ
を地理データベースと共に使用することによって、ナビ
ゲーションシステムは改善されたナビゲーティング特色
を運転手に提供することができる。更に、放送交通メッ
セージを地理データベースと共に使用することにより、
従来は使用することができなかったナビゲーション特色
をも提供できるようになる。交通放送メッセージを地理
データベースと共に使用することの１つの重要な利点
は、ナビゲーションシステム内のルート計算機能が所望
の目的地位置までのルートを計算する時に、最新の交通
状態を斟酌できることである。

【００６２】交通放送システムによって割当てられた位
置参照コードをナビゲーションシステムが容易に使用す
ることができない１つの理由は、これらのコードが必ず
しも何れかの既知の物理的特色に対応していないことで
ある。例えば、関心ハイウェイに沿う位置のための位置
参照コードは、任意のｎビット（例えば、20ビット）の
番号であることができる。これらの番号は、それら自体
は必ずしもナビゲーションシステムのエンドユーザ（例
えば、マイカーの運転手）にとって何等かの意味を有す
るものではない。マイカーの運転手が、特定のハイウェ
イインターチェンジのためのｎビット位置参照コード番
号を知っている筈はない。同様に、ｎビット位置参照番
号を参照することによって交通渋滞の位置が識別された
交通メッセージは、必ずしもエンドユーザ運転手にとっ
て有意味の重要性を有してはいない。

【００６３】前述したように、交通放送システムの１つ
の例はＲＤＳ／ＴＭＣシステムである。ＲＤＳ−ＴＭＣ
メッセージは、ＡＬＥＲＴ−Ｃプロトコルに準拠してい
る。ＲＤＳ／ＴＭＣシステムでは、多くの主要な道路イ
ンターチェンジ、及び若干の二次的な道路インターチェ
ンジは予め定義された位置番号を有している。これらの
位置番号は、放送される交通メッセージの一部である。
これらの位置番号は、ＲＤＳ／ＴＭＣシステムの開発及
び保守を担当する道路オーソリティまたは他のパーティ
によって割当てられる。これらの位置番号は、全てのユ
ーザに対して標準化されている。即ち、交通放送システ
ムからのメッセージを使用するどの受信機も、ＲＤＳ−
ＴＭＣメッセージ内の位置参照番号を、それらの番号が
割当てられている既知の位置に関係付けることができる
ようになっている必要がある。

【００６４】これらの型の位置番号が割当てられている
場所では、位置参照番号は、特定の交通放送システムの
地域データベース内で独特であり得る。このような地域
データベースは「位置テーブル」として知られている。
異なる各地域毎に分離した位置テーブルが定義されてい
る。この位置テーブル地域は、図１の地域１０には対応
しているが、必ずしも図４の地理領域２１２に対応し
（即ち、正確に一致する境界を有し）てはいない。

【００６５】図９は、位置参照番号がどのように割当て
られるのかを示す一例である。図９の例は、ＲＤＳ／Ｔ
ＭＣシステムに類似している。図９は、道路５００の一
部を示している。この道路５００は、交通放送システム
２０が交通渋滞を監視し、また交通放送システム２０が
交通メッセージ５０によって交通渋滞を報告する道路網
１２（図１）内の道路の１つである。

【００６６】道路５００に沿う交通渋滞が発生する位置
を識別するために、位置参照番号（例えば、ＬＲ１２０
０５、ＬＲ１２００６、及びＬＲ１３２９７）が、道路
５００に沿う位置に予め割当てられている。これらの位
置参照番号は、交通放送システム２０を管理している道
路オーソリティその他によって割当てられる。交通放送
システム２０によって放送されるメッセージ５０（図１
−３）は、交通渋滞の位置を識別する時にこれらの位置
参照番号を含む。

【００６７】ＲＤＳ−ＴＭＣシステムのような交通放送
システムでは、監視され、それに関する交通メッセージ
が放送される道路５００は、通常は、高速道路または主
要幹線道路である。重要ではない、即ちマイナーな道路
に沿う交通状態は、これらの種類の交通放送システムに
よって監視されていない。従って、ＲＤＳ−ＴＭＣシス
テムのような交通放送システムでは、高速道路及び主要
幹線道路に沿う位置には位置参照番号が割当てられてい
るが、重要ではない道路に沿う位置には割当てられてい
ない。

【００６８】図９には、３つの位置番号、即ちＬＲ１２
００５、ＬＲ１２００６、及びＬＲ１３２９７だけが示
されている。典型的な交通放送システムでは、位置テー
ブルによって表される各地域内の道路に沿う位置に割当
てられた数百、数千、またはそれ以上の位置参照番号が
存在し得ることを理解されたい。図９に示すように、位
置参照番号は、道路５００に沿うインターチェンジに対
応している。しかしながら、位置参照番号は、インター
チェンジの間を含む道路５００上のどのような位置にも
割当てることができる。

【００６９】ＲＤＳ−ＴＭＣシステムのような交通放送
システムでは、方向は正及び負として定義することがで
きる。例えば、ＲＤＳ−ＴＭＣシステムでは、西から東
へ、及び南から北への走行方向が正の方向である。位置
参照番号は、必ずしもそのようにしなくともよいが、道
路に沿って連続する順番に割当てることができる。

【００７０】ＲＤＳ−ＴＭＣシステムのような交通放送
システムでは、各道路自体にも位置参照番号が割当てら
れている。１つの道路の位置参照番号が、他の道路と共
用されることはない。従って、２つの道路の間のインタ
ーチェンジにおいては、各道路に位置参照番号が割当て
られている。即ち、１つの位置参照番号が第１の道路の
ためのインターチェンジに割当てられ、第２の位置参照
番号が第２の道路のための同一インターチェンジに割当
てられている。従って、１つのインターチェンジは、そ
れに割当てられた２つまたはそれ以上（そのインターチ
ェンジにおいて出会う各道路毎に１つ）の位置参照番号
を有することができる。

【００７１】前述したように、地理データベースを使用
するナビゲーションシステムに位置参照番号を使用する
場合の１つの問題は、位置参照番号が必ずしも何等かの
物理的な道路特色に関係付けられていないことである。
図９に示す道路５００は、個々の道路セグメント、Ｓ１
０１、Ｓ１０２、・・・、Ｓ１３２からなっている。こ
れらの道路セグメントＳ１０１、Ｓ１０２、・・・、Ｓ
１３２は、道路５００の個々の部分（即ち、セグメン
ト）に対応している。例えば、道路５００のこれらの各
個々のセグメントは、道路５００と他の道路（入口ラン
プ及び出口ランプを含む）との交差点の間の道路５００
の一部からなることができる。地理データベース１４０
（図２）では、これらの分離した各道路セグメントＳ１
０１、Ｓ１０２、・・・、Ｓ１３２は、少なくとも１つ
の分離したデータレコードによって表される。

【００７２】図９に示す道路５００では、道路５００の
レーンについて各方向毎に別々の道路セグメントが存在
している。これは、１つの方向へ向かうレーンが、他の
方向へ向かうレーンとは物理的に分離されているよう
な、典型的な高速道路構成を表している。図９の道路５
００の部分におけるように、レーンが実際に互いに物理
的に分離されている場合には、地理データベース１４０
内には、１つの方向のレーン及び他の方向のレーンのた
めに別々のセグメントデータレコードが存在し得る。道
路のレーンが互いに物理的に分離されていない場合であ
ってさえも、地理データベースでは分離したデータレコ
ードによって表すことができる。代替として、単一のセ
グメントデータレコードを、道路の両方向の全てのレー
ンを表すデータベース内に含ませることができる。デー
タベースレコードは、それらが両方向のレーンを表して
いるのか、または単一方向のレーンだけを表しているの
かを指示する属性を含んでいる。

【００７３】図９に示すように、位置参照番号（例え
ば、ＬＲ１２００５、ＬＲ１２００６・・・）が割当て
られている道路５００に沿う各位置に関連して道路５０
０の多重セグメントＳ１０１、Ｓ１０２、・・・、Ｓ１
３２が存在し得る。上述したように、道路５００のこれ
らの各多重セグメントは、地理データベース１４０内の
少なくとも１つのレコードによって表すことができる。
更に、図９に示すように、位置参照番号が割当てられて
いる道路５００に沿うインターチェンジの間に位置する
道路５００の幾つかのセグメントも存在し得る。インタ
ーチェンジの間の道路５００のこれらの各セグメント
は、地理データベース内の少なくとも１つのレコードに
よって表すことができる。しかしながら、これらの個々
の道路セグメントＳ１０１、Ｓ１０２、・・・、Ｓ１３
２は何れも、交通放送システムによって放送されるメッ
セージ内の位置参照番号に関係付けて別々に識別されな
い。

【００７４】前述したように、もしナビゲーションシス
テム１１０内のルート計算機能１４１（図２）を使用し
てルートを計算する時に、交通メッセージ５０内のデー
タを使用することができれば有利である。もし交通メッ
セージ内のデータをナビゲーションシステムによって使
用することができれば、ルート計算機能は、位置参照番
号が割当てられている交通渋滞位置に関連するセグメン
トを避けることができる。不幸にも、図９によって例示
したように、交通放送システムオーソリティによって割
当てられた位置番号は、地理データベース１４０内のデ
ータレコードによって表されるどの物理的特色にも直接
的に関係がない。更に交通放送システム２０によって放
送される交通メッセージは、必ずしも地理データベース
内のデータレコードによって表される実際の道路セグメ
ントの何れかに関係するとは限らない。

【００７５】交通放送システムによって放送される交通
メッセージを、ナビゲーションシステム内のルート計算
機能に使用するのを複雑にしている更に別のファクタ
は、図３に関して説明したように、ＲＤＳ−ＴＭＣのよ
うなシステムにおいては、交通渋滞の発生によって影響
を受ける道路の長さが、放送交通メッセージ内に含まれ
る「範囲」データ５０（４）の表現で報告されることで
ある。「範囲」データは、交通メッセージ内の位置参照
番号によって識別された道路に沿う位置に対する交通渋
滞状態によって影響される位置番号によって表される隣
接位置の番号の表現で定義される。従って、「範囲」デ
ータ５０（４）も、地理データベース内のデータレコー
ドによって表される物理的特色に何等の直接的な関係を
有するものではない。交通メッセージ内の「範囲」デー
タを使用すると、ナビゲーションシステム１１０のルー
ト計算機能１４１内に交通放送メッセージ情報を組み入
れる困難さが倍加する。

【００７６】ルート計算機能を支援するために交通メッ
セージを使用するためには、交通メッセージからの位置
参照データを、ルート計算機能によって使用される地理
データベース内の地理データ（セグメントデータレコー
ドのような）に関係付ける方法が必要である。図２に示
す機能１４１のようなルート計算機能では、ルート計算
は、出発点から目的地位置までの潜在的な幾つかの解ル
ートを探索することによって遂行することができる。ル
ート計算機能１４１は、潜在的な解ルートの部分に沿う
交差点からの幾つかの可能な経路を比較し、ある費用割
当て基準に基づいて最良の総合費用を有する経路を選択
することによって、このプロセスを遂行することができ
る。これらの解ルート、またはそれらの部分を比較する
ために、これらの潜在的な解ルート内の各道路セグメン
トを表すデータレコードが調べられる。これらのデータ
レコードは、潜在的な解ルートの比較を行うことができ
る情報を含む。例えば、道路セグメントを表すデータレ
コードは、表された道路セグメントに沿う速度制限、そ
の道路セグメントの終わりに停止標識が存在するか否
か、等々を指示する属性を含むことができる。これらの
データを使用すると、潜在的な解ルートを互いに比較す
ることができるので、最良解ルート（例えば、最高速総
合走行時間、または最短総合距離を有するルート）を選
択することができる。

【００７７】交通渋滞の領域を識別するデータのよう
な、交通放送システムによって放送される交通メッセー
ジ５０内のデータを、最良総合ルートの計算に直接関係
付けることができることは理解できよう。交通データメ
ッセージ内の情報を、ルート計算機能に組み入れるため
には、インターチェンジに関連する道路セグメント（交
通放送システム２０によって位置参照番号が割当て済み
のインターチェンジへ導入する道路セグメントを含む）
を表すデータレコードを識別する必要がある。

【００７８】この機能を提供するために、これらの実施
例は、ナビゲーションシステム１１０内のナビゲーショ
ン応用プログラム１１８が交通メッセージ５０内のデー
タを使用できるようにする特色及び／または成分の組合
せを含んでいる。この実施例の一つの面によれば、地理
データベース内の若干のセグメントデータレコードを若
干の位置参照番号に関連するものとして識別するため
に、位置参照データレコードが形成され、格納され、そ
して使用される。これらの位置参照レコードは、地理デ
ータベース１４１内に含ませることも、または無線通信
リンクを介してビークルに供給することもできる。１つ
の位置参照レコードの成分を図１１に示す。この実施例
の別の面によれば、位置参照番号を、位置参照レコード
に関係付けるために１つまたはそれ以上の索引が形成さ
れ、格納され、そして使用される。これらの索引を図１
３に示す。この実施例の別の面によれば、位置参照デー
タレコードのパーセルが形成され、格納され、そして使
用される。位置参照データを含むパーセルを図１２に示
す。この実施例の別の面によれば、各位置参照番号毎
に、直前の位置参照番号及び直後の位置参照番号を識別
するためのデータが形成され、格納され、そして使用さ
れる。これにより、放送メッセージ内の「範囲」データ
を解釈し、地理データベース内のレコードに関係付ける
ことが可能になる。この実施例の更に別の面によれば、
ナビゲーションシステム内には、地理データベースに照
会して若干の識別された位置参照番号に関連するデータ
エンティティを戻すプログラミングが含まれている。こ
の実施例のこの面を図１４−１６に示してある。

【００７９】これらの各面を以下に説明する。

【００８０】Ｂ．位置キー この実施例の一部として、ナビゲーションシステムによ
って使用される地理データベース内の若干のデータエン
ティティを、交通放送システムによって使用される位置
参照コードに対応付けるようにするデータレコードが形
成される。この実施例では、この一部として「位置キ
ー」が形成される。位置キーは、位置参照コードに関係
付けるデータ成分の集合体である。各位置キーは、地理
データベース内のその位置コードのための独特な識別子
を形成する。この特色の故に、位置キーは地理データベ
ース内のこれらのレコードのためのエンティティＩＤと
して使用することができる。

【００８１】位置キー５０５の成分を図１０に示す。位
置キー５０５は、国別コード、位置テーブル番号、及び
位置番号の組合せで形成される。この組合せが一緒にな
って独特な 32 ビットの番号を形成する。位置番号は 1
6 ビットであり、位置テーブル番号は６ビットであり、
そして国別コードは４ビットである。この独特な番号
は、後述するように数値分類キーとして使用される。

【００８２】Ｃ．位置レコードのデータ成分 地理データベースによって表される地域内の各位置（１
つまたはそれ以上の交通放送システムによって位置参照
番号を割当て済み）毎に独特な識別子を与えるために位
置キーが形成された後に、各位置キーと対応付けるべき
地理データベース内のデータエンティティを識別する。
本実施例では、位置キーによって表されるインターチェ
ンジ内に含まれる、またはそれに導入する道路セグメン
トを表すデータエンティティが識別される。例えば、図
９において、位置参照番号ＬＲ１２００６が関連してい
るインターチェンジは、内部セグメント及び外部セグメ
ントの両方を含んでいる。位置参照番号ＬＲ１２００６
によって表されるインターチェンジの内部セグメント
は、Ｓ１１３及びＳ１１４を含む。位置参照番号ＬＲ１
２００６によって表されるインターチェンジの外部セグ
メントは、正方向にインターチェンジに導入する２つの
セグメントＳ１１０及びＳ１１２、及び負方向にインタ
ーチェンジに導入する２つのセグメントＳ１２２及びＳ
１２３を含む。これらの６つのセグメント（Ｓ１１３、
Ｓ１１４、Ｓ１１０、Ｓ１１２、Ｓ１２２、及びＳ１２
３）に関連するセグメントデータエンティティが、この
インターチェンジＬＲ１２００６のための位置キーに関
連するものとして識別される。

【００８３】インターチェンジＬＲ１２００６から導出
するＳ１２１及びＳ１１１のようなセグメントは、この
インターチェンジのための位置キーに関連付けされてい
ない。代わりにこれらのセグメントは、それらが導入す
るインターチェンジの位置参照番号に関連付けられる。
図９の例では、Ｓ１２１によって識別されるセグメント
は、位置参照番号ＬＲ１３２９７によって表されるイン
ターチェンジに導入し、Ｓ１１１によって識別されるセ
グメントは、位置参照番号ＬＲ１２００５によって表さ
れるインターチェンジに導入する。従って、これらは、
これらのインターチェンジのための位置キーを用いて地
理データベース内に関連付けられる。

【００８４】図１１に、位置参照データレコード２６０
を示す。このレコードのためのエンティティＩＤは、上
述したようにして形成された位置キーである。位置参照
レコード２６０は、セグメントＩＤ（例えば、セグメン
トＩＤ（ｘ）、セグメントＩＤ（ｗ）、セグメントＩＤ
（ｐ）、・・・、セグメントＩＤ（ｊ））のリスト２６
０（１）を含む。これらのセグメントＩＤは、位置参照
キーによって識別されたインターチェンジに関連する道
路セグメントを表すセグメントデータレコードを識別す
る。図９のインターチェンジＬＲ１２００６を表す位置
参照レコードの場合には、エンティティＩＤのリスト２
６０（１）内には６つのセグメントＩＤ、即ちＳ１１
３、Ｓ１１４、Ｓ１１０、Ｓ１１２、Ｓ１２２、及びＳ
１２３が存在する。

【００８５】リスト２６０（１）内のセグメントＩＤは
順序付けられている。いろいろな順序付け方法を使用す
ることができる。一実施例では、セグメントＩＤは、有
効ナビゲート可能経路が得られるように順序付けされて
いる。例えば、Ｓ１２３、Ｓ１２２、Ｓ１１３が負
（“Ｎ”）方向の有効経路を形成し、Ｓ１１０、Ｓ１１
２、Ｓ１１４が正（“Ｐ”）方向の有効経路を形成す
る。

【００８６】図７に関連して説明したように、地理デー
タベース１４０は、ルーティングデータベース２３６の
ような若干の型のデータベースの１つより多くの層を含
むことができる。これらの各層は、異なるセグメントＩ
Ｄを同一の道路セグメントに割当てることができる。こ
の結果、同一セグメントを、地理データベース内の１つ
より多くのセグメントＩＤによって表すことができる。
位置参照データレコード２６０内のセグメントエンティ
ティＩＤのリスト２６０（１）は、最低層（即ち、層Ｒ
０）のための、または何れかの他の層（例えば、層Ｒ１
−Ｒ４）のためのセグメントレコードＩＤを含むことが
できる。代替として、リスト２６０（１）は、１つより
多くの層のための、または全ての層のためのセグメント
エンティティＩＤを含むことができる。もしセグメント
エンティティＩＤのリスト２６０（１）が最低層だけの
ためのセグメントレコードＩＤを含んでいれば、他の層
内の道路セグメントの対応セグメントＩＤを入手するた
めの手段を設けることができる。例えば、層０内のセグ
メントデータレコードは、同一道路セグメントを表す他
の層内の対応セグメントデータレコードへの参照を含む
ことができる。

【００８７】交通放送システムによって位置参照番号が
割当てられている道路は、一般的には高ボリュームであ
り、アクセスが制限されている道路である傾向があるか
ら、道路は最高ランク（例えば、ランク「４」）だけの
セグメントからなる傾向がある。

【００８８】地理データベース１４０が複数の層を含ん
でいる場合には、より高い層は個々の道路セグメントの
集約を表すデータレコードを含むことができる。より低
くランク付けされた道路が含まれていないより高い層に
おいては、より高くランク付けされた道路セグメントと
より低くランク付けされた道路セグメントとの交差点は
抑圧乃至は排除されているので、より高い層内の道路セ
グメントの集約は、分離したデータレコードによって表
すことができる。集約されたセグメントデータレコード
を使用することにより、若干のナビゲーション機能の性
能を強化することができる。これらの集約されたセグメ
ントデータレコードが位置参照番号に関連する道路の部
分を表し、位置参照レコード２６０内のセグメントＩＤ
のリスト２６０（１）が層０セグメントＩＤだけを含む
場合には、集約されたセグメントデータレコードによっ
てより高い層内に表されている道路セグメントの集約内
に含まれる道路セグメントを表す層０セグメントデータ
レコードは、その関連する集約されたセグメントデータ
レコードを識別する参照を含むことができる。代替とし
て、集約さたセグメントデータレコードのセグメントＩ
Ｄは、位置参照レコードのリスト２６０（１）内に含ま
せることができる。

【００８９】各位置参照番号に関連するセグメントＩＤ
のリストに加えて、位置参照レコード２６０は、位置参
照番号によって表される位置に関連している他のデータ
エンティティ２６０（２）を識別することができる。例
えば、位置参照レコード２６０は、位置参照番号に関連
するノードを表すノードＩＤのリストを含むことができ
る。

【００９０】位置参照番号データレコード２６０は、他
のデータ成分を含むこともできる。例えば、位置参照番
号２６０は、方向属性２６０（３）を含む。位置参照番
号２６０は、オプションで、交差点属性２６０（４）も
含むことができる。方向属性２６０（３）は、位置参照
番号の方向を指示する。交差点属性２６０（４）（も
し、設けられていれば）は、位置参照レコードによって
表される位置の型を指示するデータを含む。例えば、交
差点属性２６０（４）は、その位置参照番号によって識
別される位置がランプ付きのインターチェンジである、
終点である、またはその交差点が停止標識を含む、等々
であることを指示するデータを含むことができる。位置
参照番号データレコード２６０は、他のデータ２６０
（５）も含むことができる。

【００９１】Ｄ．データベース内の位置参照レコード編
成 図１１に示す道路のような全ての位置レコードのデータ
成分は、位置参照番号及び範囲が与えられた時に、全て
の関連セグメントレコードの迅速な識別及び検索が容易
であるように編成され、配列され、そしてナビゲーショ
ンシステムによって使用される地理データベース１４０
内に格納されている。位置参照データベースの編成、配
列、及び格納を、図１２及び１３を参照して説明する。

【００９２】地理データベース内の位置参照番号に関連
するセグメントレコードを探知する予備ステップとし
て、位置参照番号に関連する位置キー５０５が使用され
る。前述したように、位置キーは、位置参照番号を含む
交通メッセージの成分からなっている。従って、各位置
参照キーに関連するデータレコードを見出すために位置
キー索引２４７（ＬＲ）が使用される。位置キー索引２
４７（ＬＲ）は、地理データベース１４０内に、または
地理データベース１４０を用いて形成され、格納され
る。この位置キー索引２４７（ＬＲ）は、地理データ１
４０の位置参照レコードデータ２４５から分離した一部
内に位置させることができる。図１３を参照する。一実
施例では、位置キー索引２４７（ＬＲ）は、索引ファイ
ル２４７（図６にも示されている）の間に含まれてい
る。位置キー索引２４７（ＬＲ）を位置参照レコードデ
ータ２４５から分離して格納することによって、全位置
キー索引２４７（ＬＲ）をナビゲーションシステムのメ
モリ内に読み込んで、所望の位置参照レコードの位置を
識別するために使用することができる。位置キー索引２
４７（ＬＲ）を位置参照レコードデータから分離して格
納すると、ナビゲーションシステムのメモリ内に不要の
データをロードする必要が避けられ、それによって性能
が強化される。ナビゲーションシステムのメモリ資源に
依存して、位置キー索引２４７（ＬＲ）は、索引ファイ
ル２４７の中に含まれている他の索引と共にメモリ内に
維持することができる。代替として、位置キー索引２４
７（ＬＲ）は必要な場合にだけメモリ内にロードし、使
用することができる。（もし位置キー索引２４７（Ｌ
Ｒ）のサイズが比較的大きければ、それを１つより多く
のパーセル内に格納する必要があろう。） 図１３に示す実施例では、位置キー索引２４７（ＬＲ）
は特定の各位置参照レコードの位置を識別はせず、その
代わりに、位置キー索引２４７（ＬＲ）は所望の位置参
照レコードを含む位置参照データ２４５のパーセル３２
０（ＬＲ）を識別する。図１３に示すように、位置キー
参照索引２４７（ＬＲ）はエントリのリスト５１０を含
んでいる。このリスト５１０内のエントリは、位置参照
データ２４５を含む複数の各パーセル３２０（ＬＲ）内
の最初の位置参照レコードに対応する位置参照キー５０
５だけを含んでいる。リスト５１０内の各エントリは、
そのエントリ内の位置キーに対応する位置参照レコード
を含むデータのパーセルの識別をも含んでいる。この識
別はポインタまたは他の参照であることも、または代替
として、この識別はデータベース内の、及び／または媒
体上のパーセルの位置を決定することができるパーセル
ＩＤであることもできる。

【００９３】位置キー索引２４７（ＬＲ）内のリスト５
１０内の位置参照キー５０は順番に（例えば、数値的に
最小から最大へ、またはその逆に）格納及び／または配
列されている。従って、リスト５１０内のエントリは、
何れかの位置キーに関連する位置参照レコードが位置し
ているパーセルを識別するために使用することができ
る。位置キーが与えられると、与えられた位置キーより
大きいエントリに出会うまで、リスト５１０をトラバー
スすることができる。与えられた位置キーに関連する位
置参照レコードを含むパーセルが、そのリスト内の先行
エントリによって参照されたパーセルである。代替とし
て、所望の位置参照番号を含むパーセルを見出すため
に、他の探知技術（例えば、バイナリ探索）を使用する
ことができる。即ち、このリスト５１０は、位置参照レ
コードを含むパーセルを迅速に見出すことができる探索
技術に順応する。

【００９４】もし位置キー索引２４７内のエントリのリ
スト５１０が１つより多くのパーセルからなっていれ
ば、このリスト上に探索木を構成し、キーによる位置キ
ーパーセルの探索を容易にすることができる。従って、
位置キー索引は、多層探索木からなることができる。各
層は、次に低い層における位置木パーセルのための、ま
たは（最低層位置索引パーセルから）位置参照レコード
パーセルのためのキーによってバイナリ探索することが
できる。

【００９５】位置参照データ２４５を含む各パーセル３
２０（ＬＲ）は、類似の編成を有している。位置参照デ
ータ２４５の代表的なパーセル３２０（ＬＲ）（ｎ）の
編成を、図１２に示す。位置参照データの各パーセル３
２０（ＬＲ）（ｎ）は、そのパーセル内に最小位置参照
キーを有する位置参照レコードを識別する（例えば、位
置キーによって）データ成分５２１を含む。このレコー
ドは、位置キー索引２４７（ＬＲ）内のエントリによっ
て指し示されるレコードに対応する。位置参照データ２
４５のパーセルは、オフセットテーブル５４５及び位置
参照レコード５５０をも含んでいる。

【００９６】オフセットテーブル５４５は、パーセル内
に含まれている各位置参照レコード５５０（１）、５５
０（２）、・・・、５５０（ｎ）に対応するエントリ５
４６（１）、５４６（２）、５４６（３）・・・のリス
トを含んでいる。リスト５４５内のエントリ５４６は、
一実施例では数値的に順序付けられている位置参照レコ
ードの順序付けを反映している。各エントリ５４６は、
パーセル内のその対応する位置参照レコードの長さ５４
７を識別する。オフセットテーブル５４５は、各エント
リ毎に、次の位置キー５４９を識別するデータをも含
む。次の位置キー５４９内のデータは、エントリ５４６
に対する道路に沿う直後の位置参照番号の位置キー５０
５を識別する。同様に、各エントリ５４６は、先行位置
キー５５１を識別するデータを含む。先行位置キー５５
１内のデータは、そのエントリ５４６の位置キーに対応
する位置に対する道路に沿う直前位置参照番号の位置キ
ーを識別する。例えば、図９において、“ＬＲ１２００
６”に関連するインターチェンジのための位置キーのた
めのオフセットテーブル内のエントリ５４６は、その先
行位置キー５５１としてＬＲ１２００５のための位置キ
ーを、またその次の位置キー５４９としてＬＲ１３２２
９７のための位置キーを識別する。前述したように、位
置参照番号は必ずしも道路に沿って連続的に割当てられ
てはいない。従って、各位置参照番号毎の次の及び先行
位置キーは、オフセットテーブル５４５において識別さ
れる。

【００９７】パーセル内のオフセットテーブル５４５に
後続しているのは、位置参照パーセル３２０（ＬＲ）の
位置参照レコード部分５５０である。位置参照レコード
部分５５０は、位置レコード５５０を含んでいる。位置
参照パーセル３２０（ＬＲ）内の各位置参照レコード５
５０は、図１１に識別されている成分を含んでいる。即
ち、各位置参照レコード５５０は、方向属性（図１１の
方向データ２６０（２）に対応する）、及びセグメント
ＩＤのリスト（図１１のリスト３６０（１）に対応す
る）を含む。オプションとして、位置参照レコード５５
０は、交差点属性（図１１の交差点データ２６０（３）
に対応する）をも含むことができる。

【００９８】Ｅ．位置参照データを使用するためのプロ
グラミング この実施例の別の面によれば、交通メッセージ５０内の
データ、及び地理データベース１４０内の位置参照デー
タ２４５の両方を使用するプログラミングを含む。（こ
のプログラミングを、以下に「位置参照プログラミン
グ」、または「位置参照ルーチン」１４５という。）位
置参照プログラミング１４５は、ナビゲーションシステ
ム１１０内に設置され、及び／またはナビゲーションシ
ステム１１０によって実行されるナビゲーション応用プ
ログラミング１１８（図２）の一部として含むことがで
きる。代替として、位置参照プログラミング１４５は、
ナビゲーション応用機能（ルーティング機能１４１、地
図表示機能１４３、等）と地理データベース１４０との
間に存在するソフトウェアインタフェース層の一部とし
て含むことができる。ソフトウェアインタフェース層
も、ナビゲーションシステム１１０内に設け、及び／ま
たはナビゲーションシステム１１０が実行することがで
きる。もし位置参照プログラミングがビークル内のナビ
ゲーションシステム１１０内に設けられていれば、ナビ
ゲーションシステムの一部である不揮発性コンピュータ
可読媒体内に格納することができる。

【００９９】図１４は、位置参照プログラミング１４５
の主要ステップを記述する流れ図を示している。図１４
に示されている実施例では、ナビゲーション応用プログ
ラム１１８の一部であることができる受信機ルーチン応
用７０７は、若干の初期ステップを遂行し、次いで出力
を位置参照プログラミング１４５に供給する。代替実施
例では、受信機ルーチン応用７０７によって遂行される
ステップは、位置参照プログラミング１４５によって遂
行させることができる。

【０１００】初期ステップ（ステップ７１０）におい
て、単一の交通メッセージ５０を受信する。交通メッセ
ージ５０は、図３に示すものと類似のフォーマットを有
することができる。次のステップ（ステップ７１４）で
は、位置参照番号５１（１）、範囲５０（４）、等々を
含むメッセージ５０の成分を入手するために、交通メッ
セージ５０がパーズされる。これらのデータは、受信機
ルーチン応用７０７から位置参照プログラミング１４５
へ供給される。

【０１０１】メッセージからの位置参照番号５１
（１）、国別コード５１（３）、及び位置テーブル番号
５１（２）を使用して、位置キー５０５が形成される
（ステップ７１８）。位置キー５０５は、交通メッセー
ジから抽出されたこれらの成分を連結することによって
形成することができる。先行ステップにおいて形成され
た位置キー５０５を使用して、位置キーに関連する位置
参照レコードを含む位置参照データレコードのパーセル
３２０（ＬＲ）を見出すために、地理データベース１４
０内の位置キー索引２４７（ＬＲ）が使用される（ステ
ップ７２２）。次に、位置キー索引２４７（ＬＲ）を使
用して、位置キーに関連するレコードを含む位置参照レ
コードのパーセルが識別されると、そのパーセルにアク
セスし、読み出す（ステップ７２６）。

【０１０２】パーセル３２０（ＬＲ）を読み出す際に、
オフセットテーブル５４５を含むパーセルヘッダーが先
ず読み出される（ステップ７３０）。オフセットテーブ
ル５４５（位置キーが数値的に順序付けられている）を
使用して、所望の位置キーに対応するエントリが形成さ
れる（ステップ７３４）。オフセットテーブル５４５内
のエントリから、次の位置キー５４８、または先行位置
キー５５１の何れかを読み出す。これらのキーのどちら
（即ち、次、または先行）を読み出すのかは、位置参照
番号の位置からの交通渋滞の方向を定義する交通メッセ
ージ５０内の方向データ５０（３）に依存する。交通メ
ッセージ５０からの方向データ５０（３）及び範囲デー
タ５０（４）を、オフセットテーブルからの次の、また
は先行の何れかの位置キーと共に使用して、交通メッセ
ージを適用する他の各位置キーを決定することができる
（ステップ７３８）。ある範囲内に包含される全ての位
置キーを識別するために、オフセットテーブルを数回使
用しなければならないかも知れない。例えば、もし範囲
データ５０（４）が“４”であれば、オフセットテーブ
ル５４５は先ず、メッセージ５０内に識別されている位
置参照番号５１（２）のための位置キーに対する次の
（または、方向に依存して、先行の）位置キーを識別す
るために使用される。次いで、その次の（または、先
行）位置参照キーを識別するために、オフセットテーブ
ル内の次のキー（または、先行キー）が探知される。こ
のプロセスは、４つの（範囲データフィールド５０
（４）内に識別されている“４”に対応）位置キーが全
て識別されるまで続行される。もし範囲データフィール
ド５０（３）が１つより多くのパーセル内の位置参照レ
コードによって表されている位置参照位置の列を識別し
ていれば、１つまたはそれ以上の付加的な位置参照デー
タレコードのパーセルにアクセスする必要があるかも知
れない。しかしながら、多くの場合、読み出す必要があ
るパーセルの数を最小に維持するように、キーが繰り返
される。

【０１０３】範囲に対応する全ての位置キーが識別され
た後に、オフセットテーブル５４５を使用してパーセル
内の所望の位置参照データレコードが探知される（ステ
ップ７４２）。オフセットテーブル内の各位置キーエン
トリ毎に、パーセル内へのオフセットはその位置キーエ
ントリに関連するデータが見出されるパーセル内の位置
を識別する。各位置キーエントリ毎に、位置参照データ
レコード５５０が読み出される（ステップ７４６）。詳
しく述べれば、識別された各位置キーに関連する全ての
セグメントＩＤが識別される。範囲データ５０（４）は
交通渋滞によって影響をうけている１つより多くの位置
参照番号を識別することができるので、これらのセグメ
ントＩＤは１つより多くの位置参照番号に関連付けるこ
とができる。セグメントＩＤのこのリスト７５２は、そ
れを呼出したプログラムへ戻される（ステップ７５
０）。この位置参照プログラミングルーチン１４５を、
ナビゲーションシステムに関連してどのように使用でき
るかの例を以下に説明する。

【０１０４】位置参照プログラミング１４５は、１つの
層（例えばルーティング層０）のための、または代替と
して１つより多くの層のための、セグメントＩＤのリス
トを戻すことができる。位置参照レコード２６０が、ル
ーティング層０のような１つの層に関連するセグメント
ＩＤだけを含んでいるような実施例では、これらの層０
セグメントデータレコード内に含まれる、他のより高い
層内のデータレコードへの参照を入手するために、先ず
これらのルーティング層０データレコードにアクセス
し、読み出すことができる。次いで、これらの付加的な
セグメントＩＤ７５９も、呼出した応用へ戻すことがで
きる。もしより高い層が、集約されたセグメントデータ
レコードを含んでいれば、これらのレコードへの参照を
も戻すことができる。このオプショナルな代替に含まれ
るステップ（７５６及び７５８）を図１４に破線で示し
てある。

【０１０５】位置参照プログラミング１４５は、どのよ
うな適当なプログラミング言語で書くこともできる。一
実施例では、位置参照プログラミング１４５は、地理デ
ータベースにアクセスし、使用する他の機能と同一のプ
ログラミング言語で書かれている。この実施例では、位
置参照プログラミング１４５はＣで書かれているが、代
替実施例では、位置参照プログラミング１４５はＣ＋
＋、Javaのようなどのような適当なプログラミング言語
で書くことも、または近い将来開発されるかも知れない
プログラミング言語で書くこともできる。

【０１０６】Ｆ．動作の方法 この実施例によれば、所与の型の位置参照（ＲＤＳ−Ｔ
ＭＣシステムにおけるＡＬＥＲＴ−Ｃプロトコルのよう
な）、及びその型の１つまたはそれ以上の位置参照のた
めに、これらの参照に対応するエンティティを戻す手段
が設けられている。ＲＤＳ−ＴＭＳ位置参照型の場合、
位置参照は、上述したような位置属性の集合的なエンコ
ーディングであるＲＤＳ−ＴＭＳコードを表す。地理デ
ータベース１４１から戻されたエンティティ、またはレ
コードは、セグメントデータレコードである。

【０１０７】これらの実施例を使用する方法を、以下の
例で説明する。

【０１０８】例 １ この例は、図１５を参照して説明する。図１５の例で
は、交通データベースはナビゲーションシステムの初期
化時に入手され、次いでナビゲーションシステムの使用
中に絶えず、または定期的な間隔で更新される。図１５
では、ナビゲーションシステムが始動した時、または初
期化された時（ステップ８０７）に、交通データ収集プ
ログラム８１０が実行される。この交通データ収集プロ
グラム８１０は、ナビゲーション応用プログラミング１
１８、インタフェース層プログラミング（前述）、また
はナビゲーションシステムの何れかの他の部分の一部で
あることができる。交通データ収集プログラム８１０
は、エンドユーザがナビゲーションシステムに要求して
遂行させることができる他のタスクを妨害しないように
バックグラウンドで動作することができる。

【０１０９】交通データ収集プログラム８１０は、交通
メッセージ放送５０を受信し始める。これらは、図２の
受信機１２５から受信することができる。受信した各交
通メッセージ５０毎に、交通データ収集プログラム８１
０は位置参照ルーチン１４５（図１４に示す）を呼出す
（ステップ８２５）。交通データ収集プログラム８１０
は、位置参照ルーチン１４５がメッセージを捕捉できる
まで、交通放送システム２０から受信した交通メッセー
ジ５０をバッファしなければならないかも知れない。ナ
ビゲーションシステムのメモリの一部分を、この目的の
ために準備することができる。

【０１１０】各交通メッセージ５０毎に、位置参照ルー
チン１４５は交通メッセージで報告された渋滞によって
影響を受けているセグメントＩＤのリストを戻す。交通
メッセージからの渋滞の酷さがセグメントに関連付けら
れ、臨時データベース８１８内に格納される（ステップ
８２７及び８２９）。データ収集プログラム８１０は全
ての交通メッセージを入手してしまうまで、酷さをセグ
メントデータベースレコードに関連付けるデータを格納
し続ける（ステップ８３０）。この点において、データ
収集プログラムは交通メッセージを集め続け、セグメン
トに関連する酷さが変化するにつれて、必要に応じて臨
時データベースを更新する。

【０１１１】全ての交通メッセージを入手した後の任意
の時点に、臨時データベース８１８はナビゲーション応
用によって使用される。例えば、解ルート８３３を決定
するためにルート計算機能１４１が実行される時に、臨
時データベース８１８を地理データベース１４０と共に
使用することができる。ルート計算機能は、潜在的解ル
ートを決定する目的で地理データベース１４０からのセ
グメントを調べ、何れかのセグメントが臨時データベー
ス８１８内のセグメントに関連する酷さの格付けを有し
ているか否かを決定する。もしある潜在的解ルート内の
セグメントが臨時データベース８１８内にそれに関連す
る酷さ重みを有していれば、潜在的解ルートと他の潜在
的ルートとを比較する時に、この重みを考慮に入れる。
もし潜在的解ルートのセグメント上の交通が酷く渋滞し
ていれば、別の潜在的解を選択することができる。

【０１１２】この例では、ルート計算の前に交通データ
収集プロセスがセグメントエンティティのリストを累積
するのを回避するので、臨時データベース８１８内に交
通メッセージに関連するセグメントを入手するアクセス
性能は臨界的ではない。

【０１１３】例 ２ この例は、図１６を参照して説明する。図１６では、ル
ーティング計算プログラム１４１が走るまでは、交通デ
ータ５０は入手されない。図１６では、ルーティング計
算プログラム１４１は、所望の目的地及び起点を含む入
力を受信する（ステップ９０１）。交通データ収集プロ
グラム９０３が呼出される。この交通データ収集プログ
ラム９０３は、交通放送システム２０によって放送され
る交通メッセージ５０を入手する（ステップ９０５）。
これらの各交通メッセージは、ナビゲーションシステム
１１０のメモリ内に臨時に格納することができる。潜在
的解ルーティングから比較的離れた位置に関するメッセ
ージが処理されないように、交通メッセージ５０を濾過
することができる。次いで、交通データ収集プログラム
９０３は各関係交通メッセージ毎にルーチン９０７を実
行する。

【０１１４】各交通メッセージ５０毎に、交通メッセー
ジ内の１つまたは複数の位置参照番号（交通メッセージ
内に明示的に指定されている位置参照番号、並びに交通
メッセージ内に含まれている範囲データによって暗示的
に指定されている位置参照番号を含む）に関連する全て
のセグメントデータエンティティ（または、全てのセグ
メントデータエンティティのための少なくともＩＤ）を
入手するために、ルーチン９０７は位置参照ルーチン１
４５（図１４）を呼出す。セグメントデータエンティテ
ィ（またはそれらのＩＤ）のリスティング７５２を使用
して、交通メッセージと共に含まれている交通渋滞の酷
さが、これらの各セグメントデータエンティティ（また
は、ＩＤ）に関連付けられる（ステップ９１３）。酷さ
とセグメントＩＤとのこの結合は、臨時データベース９
１６内に格納される（ステップ９１５）。

【０１１５】全ての関係交通メッセージを入手すると、
ルート計算機能１４１は解ルート９２１を決定し始める
（ステップ９１７）。解ルートを決定するプロセスにお
いては、重み付けされたセグメントの臨時データベース
９１６が地理データベース１４０と共に使用される。ル
ート計算機能１４１によって計算中の潜在的解ルートの
一部分が、臨時データベース９１６内の酷さの重みに関
連するセグメントの１つを含んでいる場合には、その潜
在的解ルートと他の潜在的解ルートとを比較する時にそ
の重みが斟酌される。酷さの重みは、交通渋滞がかなり
酷く、そのセグメントは完全に避けるべきであることを
指示することができる。代替として、交通渋滞を含むセ
グメントを潜在的解ルートとして使用できるように、酷
さに比較的軽く重み付けすることができる。

【０１１６】Ｇ．代替実施例 代替実施例では、ナビゲーションシステムによって遂行
されるナビゲーション応用プログラミング、または機能
の若干または全ては、遠隔的に遂行させることができ
る。例えば、ナビゲーション応用プログラミング機能の
若干または全ては、ビークルが無線通信リンクを有して
いるサービスプロバイダによって遂行させることができ
る。（サービスプロバイダは、必ずしも交通放送システ
ムに関連している必要はない。）この代替では、ナビゲ
ーション機能が遂行される遠隔サービスプロバイダへユ
ーザの入力を送信し、結果をビークルへ戻して送信する
ことができる。位置参照プログラミング及び／またはデ
ータ収集プログラミングは、ビークル内に配置すること
も、または遠隔的にアクセスすることもできる。

【０１１７】別の代替では、地理データベース１４０の
若干または全ては、例えばサービスプロバイダを用いて
遠隔配置し、無線通信リンクを介してビークル内のナビ
ゲーションシステムによってアクセスすることができ
る。位置参照レコードは、ビークル内のコンピュータ可
読媒体上に配置することも、または遠隔配置して通信リ
ンクを介してアクセスすることもできる。

【０１１８】別の代替では、位置参照データベースの若
干または全ては、必要に応じて無線通信リンクを介して
ダウンロードし、ビークル内に配置された分離した書き
込み可能な媒体上に格納することも、または代替とし
て、位置参照データはビークル内のメモリ（例えば、Ｒ
ＡＭ）内のテーブル内に格納することもできる。この実
施例では、位置参照データを使用するビークル内のナビ
ゲーションプログラミングは、分離した媒体からのデー
タにアクセスする。この実施例の利点は、位置参照デー
タを、必要に応じて更新できることである。別の利点
は、新しい交通メモリシステムを容易に受入れることが
できることである。格納を最小に留めるために、制限さ
れた地理カバレッジエリアのためだけのデータを読み出
すことができる。

【０１１９】さらなる代替では、分離した媒体上に位置
参照データをダウンロードし、格納するために、位置参
照データの一次源を地理データベースと共に格納し、更
新することができる。この実施例では、位置参照データ
を使用するプログラミングは、一次参照データ及び更新
されたデータの両方を使用する。

【０１２０】別の代替実施例では、交通メッセージを受
信し、交通メッセージをパーズするプログラミングへそ
れを供給する受信機は、ナビゲーションシステム１１０
の一部であることも（図２の１２５のように）、または
代替として、受信機はスタンドアロンユニット、または
別の種類の機器に関連するユニットであることもでき
る。この代替実施例を図１７の１１２５に示す。もし図
１７の１１２５に示すように、受信機がナビゲーション
システム１１０の一部でなければ、交通メッセージのよ
うなデータを受信機１１２５からナビゲーションシステ
ム１１０へ転送できるようにするために、受信機１１２
５はナビゲーションシステム１１０の入力ポート１１２
９に結合することができる出力ポート１１２７を有して
いる。受信機上のポート１１２７及びナビゲーションシ
ステム上のポート１１２９は、直接接続することも、ま
たは代替として、ケーブリング１１３１によって接続す
ることもできる。ナビゲーションシステム及び地理デー
タベースの他の面は、先に説明した実施例に類似、また
は同一である。

【０１２１】代替実施例では、地理データベース１４１
は、ＲＤＳ−ＴＭＣシステム以外のシステムからの交通
放送メッセージを支援する位置参照データベースを含む
ことができる。これらの他のシステムの例は、ＧＡＴ
Ｓ、ＶＩＣＳ、及びＩＴＳ Ｄａｔｕｍ、並びに所有権
を主張できる（プロプラエタリ）システム、及び近い将
来開発されるかも知れないシステムを含む。これらの他
のシステムは、ＲＤＳ−ＴＭＣシステムにおけるメッセ
ージと類似したメッセージを含むことも、または異なる
種類のメッセージを含むこともできる。これらの異なる
種類のメッセージは、ＲＤＳ−ＴＭＣシステムのような
位置参照システムを含むことも、または他の種類の位置
参照を含むこともできる。これらの異なる種類のシステ
ムは、他の位置を暗示的に識別する範囲データを含むこ
とも、または代替として、全ての位置を明示的に識別す
ることもできる。

【０１２２】別の実施例では、地理データベースは、１
つより多くの種類の交通放送メッセージフォーマットを
支援する位置参照データベースを含むことができる。例
えばＲＤＳ−ＴＭＣシステム、並びにある他のシステム
を支援することができる。若干の地域では、各々がそれ
自体の種類のメッセージフォーマット及び位置参照番
号、等を有している１つより多くの交通放送システムが
存在し得る。これらの環境の下では、地理データベース
は、各々が分離した位置キーで形成されている分離した
セットの位置参照データレコードを含むことができる。
これらの分離したセットは、地理データベース１４１内
に格納することができる。

【０１２３】１つより多くの種類の交通放送メッセージ
ングフォーマットを支援するナビゲーションシステム、
またはＲＤＳ−ＴＭＣシステム追加される交通放送シス
テムにおいては、地理データベースは、支援している種
類の実時間交通放送システムを識別するために、ナビゲ
ーション応用プログラムからの照会を支援することがで
きる。この照会は、位置参照データを地理データベース
内に含むか、または地理データベースによって支援され
ている交通放送システムの識別を戻す。多重交通メッセ
ージングフォーマットを支援するこれらの種類のシステ
ムでは、交通メッセージフォーマットを選択することが
できるように、プログラミングをナビゲーションシステ
ム内に設けることもできる。選択プロセスは自動とする
ことも、または代替として、選択プロセスはエンドユー
ザによって行うこともできる。多重交通放送フォーマッ
トを支援するようにしておくと、異なる交通放送システ
ムフォーマットを有する異なる市を走行するビークルに
とって有用であり得る。

【０１２４】別の代替によれば、その放送交通メッセー
ジ以外のシステムからのナンバリング参照を利用するた
めに、位置参照データエンティティを地理データ内で使
用することができる。例えば、若干の型またはクラスの
関心点に関するサービスを提供する団体、またはエンテ
ィティが存在する。これらの団体の例は、大都市圏内の
種々のイベント（例えば、演劇、スポーツ、音楽、映
画、コメディ、等々）のチケットを販売するチケット販
売業者を含む。チケット販売業者は、チケットが使用さ
れる各開催地を参照番号によって識別することができ
る。この代替実施例によれば地理データベースは、チケ
ット販売業者によって使用される参照番号を、地理デー
タベース内に含まれるデータに関係付ける位置参照デー
タエンティティを含む。この実施例では、地理データベ
ース内の各位置参照データエンティティは、開催地を識
別するためにチケット販売業者によって使用される参照
番号の１つに対応する。各位置参照データエンティティ
は、開催地の位置に対応する地理データベース内の対応
する関心点データエンティティレコードを識別する。ナ
ビゲーション応用は、それが交通メッセージ情報を使用
するのと同じようにして、これらの種類の位置参照デー
タエンティティを使用することができる。ナビゲーショ
ン応用は、チケット販売業者から直接的に、または間接
的にデータを受信する。データは、無線または非無線通
信手段によって受信することができる。チケット販売業
者からのデータは、チケット販売業者によって割当てら
れた識別番号によって開催地を識別する。データは、上
演時間、チケットの使用可能性、チケットの値段、プロ
グラム、等々を含むこともできる。ナビゲーション応用
は、位置参照データエンティティを使用して、チケット
販売業者から受信した情報を、地理データベース内の関
心点データエンティティに関係付ける。ユーザは地理デ
ータベース内の関心点の使用と共に、チケット販売業者
から受信した情報にアクセスすることができる。ユーザ
は、地理データベースを探索する時に、さらなる基準と
してチケット販売業者からのデータを使用することがで
きる。例えば、ユーザは 25 マイル以内の、そして２時
間以内に開演される演劇の上演を探索することができ
る。位置参照番号を使用できる他の種類のシステムは、
ホテルチェーン、レストラン団体、不動産ブローカーの
オフィス、等々を含む。

【０１２５】以上の詳細な説明は、単なる例示であって
本発明を制限する意図はなく、本発明は特許請求の範囲
によってのみ限定されるものであることを理解された
い。

【図面の簡単な説明】

【図１】地理領域内の交通放送システムの成分を示す図
である。

【図２】交通放送システムの成分、及び図１に示すナビ
ゲーションシステムを搭載したビークルの１つを示すブ
ロック図である。

【図３】図２の交通メッセージの１つの中に含まれるデ
ータ成分を示す図である。

【図４】図１の領域に対応させることができる地理領域
を示す地図である。

【図５】図４の地図の一部を拡大した図である。

【図６】図２の地理データベースの型による編成を示す
ブロック図である。

【図７】図６の地理データベースのルーティング型の層
による編成を示すブロック図である。

【図８】図２の地理データベースの編成を示すブロック
図である。

【図９】図１の交通放送システムによって使用される位
置参照番号が割当てられている交差点を有する道路の一
部を示す図である。

【図１０】図９に示す位置参照番号を、図２及び８に示
す地理データベース内に含まれるデータに関係付けるた
めに形成された位置参照キーの成分の図である。

【図１１】位置参照レコードを形成している成分を示す
ブロック図である。

【図１２】図８に示す位置参照データレコードを含むパ
ーセルの１つ内のデータの編成を示すブロック図であ
る。

【図１３】位置参照レコードのための索引の編成を示す
ブロック図である。

【図１４】交通放送メッセージデータを地理データと共
に使用する図２のナビゲーションシステムのプログラミ
ングによって遂行されるステップを示す流れ図である。

【図１５】図１４に示すプログラミングステップを使用
する第１の例が遂行するステップを示す流れ図である。

【図１６】図１４に示すプログラミングステップを使用
する第２の例が遂行するステップを示す流れ図である。

【図１７】交通メッセージデータをナビゲーションシス
テムと共に使用する代替実施例を示すブロック図であ
る。

【符号の説明】

１０ 地域 １２ 道路網 ２０ 交通放送システム ２２ センサ ５０ データ ５１ ＲＤＳ−ＴＭＣコード ８０ 非ビークル １１０ ナビゲーションシステム １１２ プロセッサ １１４ ドライブ １１６ 不揮発性メモリ記憶デバイス １１８ ナビゲーション応用ソフトウェアプログラム １２３ 感知デバイス １２４ 測位システム １２５ 交通メモリ受信機 １２７ ディスプレイ １２９ スピーカ １３１ ユーザインタフェース １３２ 記憶媒体 １４０ 地図データベース １４１ ルート計算機能 １４２ ルート案内機能 １４３ 地図表示機能 １４４ ビークル位置決め機能 １４５ 位置参照プログラミング １４６ 他の機能及びプログラミング ２１０ 地図 ２１２ 地理領域 ２１４ 位置 ２１６ 地図の一部分 ２２０ 道路網 ２２２ 道路セグメント ２３６ ルーティングデータ ２３７ 地図作成データ ２３８ 運転データ ２３９ 関心点データ ２４０ 合流点データ ２４１ ナビゲーション特色データ ２４３ 郵便番号データ ２４４ 場所データ ２４５ 位置参照データ ２４６ その他のデータ ２４７ 外部索引 ２４９ 内部索引 ２６０ 位置参照データレコード ３１０ パーセル ３２１ ヘッダー及びグローバルデータ ５００ 道路 ５０５ 位置キー ５１０ エントリのリスト ５２１ パーセル内の最小参照エンティティＩＤ ５４５ オフセットテーブル ５４８ 次の位置キー ５５０ 位置参照レコード ５５１ 先行位置キー ７０７ 受信機ルーチン応用 ８１０ 交通データ収集プログラム ９０３ 交通データ収集プログラム １１２５ 交通メッセージ受信機

─────────────────────────────────────────────────────

【手続補正書】

【提出日】平成１１年２月１６日（１９９９．２．１
６）

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】発明の名称

【補正方法】変更

【補正内容】

【発明の名称】 ナビゲーションシステムと共に実時間
交通情報放送を使用する方法及びシステム

フロントページの続き (72)発明者 ロバート ピー ファーネクス アメリカ合衆国 イリノイ州 60013 パ ーマ ドライヴ 959 (72)発明者 リチャード エイ アッシュビー アメリカ合衆国 ウィスコンシン州 53518 ブルー リヴァー ワイルド ロ ーズ ドライヴ 27993 (72)発明者 ディヴィッド ランパート アメリカ合衆国 イリノイ州 60035 ハ イランド パーク ブラックストーン プ レイス 650 (72)発明者 ジョン エム ジャウジラス アメリカ合衆国 イリノイ州 60148 ロ ンバード ノース メイン ストリート 135 Ｆターム(参考） 2C032 HB23 HC05 HD16 HD23 2F029 AA02 AA07 AB01 AB07 AB09 AC02 AC03 AC04 AC13 AC14 AC18 5H180 AA01 AA21 AA30 BB04 BB05 BB12 BB13 EE18 FF04 FF05 FF12 FF13 FF22 FF25 FF27 FF32 9A001 BB03 BB06 CC05 DD13 FF03 HH17 HH18 HH28 JJ11 JJ72 JJ77 KK56 KK62

Claims (34)

【特許請求の範囲】
1. 【請求項１】 ナビゲーション応用プログラムを動作さ
   せる方法であって、 地理領域内の道路上の複数の位置における交通状態を指
   示するデータを含む放送交通メッセージを受信するステ
   ップと、 上記交通メッセージから、上記メッセージが関係してい
   る上記道路上の位置を識別するデータを含むデータ成分
   を抽出するステップと、 上記地理データベース内の上記位置に対応する地理特色
   を表すデータエンティティを見出すために、上記抽出さ
   れたデータ成分を使用して地理データベースを探索する
   ステップと、を備えていることを特徴とする方法。
2. 【請求項２】 上記複数の位置における交通状態を指示
   する上記交通メッセージ内のデータを、上記探索ステッ
   プにおいて上記位置に対応するとして識別された上記地
   理データベース内のデータエンティティに関連付けるス
   テップ、を更に備えている請求項１の方法。
3. 【請求項３】 上記交通メッセージ内のデータを、上記
   地理データベース内のデータエンティティに関連付ける
   ステップは、ルート計算機能を遂行する前に遂行される
   請求項２に記載の方法。
4. 【請求項４】 上記抽出、探索、及び関連付けステップ
   は、全ての関連交通メッセージが処理されてしまうまで
   遂行される請求項２に記載の方法。
5. 【請求項５】 上記交通メッセージ内のデータを、上記
   地理データベース内のデータエンティティに関連付ける
   ステップは、上記ナビゲーション応用プログラムのルー
   ト計算機能の一部として遂行される請求項２に記載の方
   法。
6. 【請求項６】 上記抽出、探索、及び関連付けステップ
   は、交通状態の変化を指示する新しい交通メッセージが
   受信されると更新される請求項２に記載の方法。
7. 【請求項７】 上記位置に対応する地理特色を表す上記
   地理データベース内のデータエンティティを見出した後
   に、交通状態を指示するデータに従って上記データエン
   ティティに重み付けするステップ、を更に備えている請
   求項１に記載の方法。
8. 【請求項８】 上記地理データベースは、オンボードナ
   ビゲーションシステム内に配置されている請求項１に記
   載の方法。
9. 【請求項９】 上記ナビゲーション応用プログラムは、
   ビークルに搭載されたナビゲーションシステム内に設置
   されている請求項１に記載の方法。
10. 【請求項１０】 上記交通メッセージは、ラジオデータ
    システム・交通メッセージチャンネル上で放送される請
    求項１に記載の方法。
11. 【請求項１１】 上記交通メッセージは、上記ＲＤＳ−
    ＴＭＣ内に確立されているＡＬＥＲＴ−Ｃのための標準
    フォーマットに準拠している請求項１に記載の方法。
12. 【請求項１２】 上記ナビゲーション応用プログラム
    は、非ビークル内に設置されている請求項１に記載の方
    法。
13. 【請求項１３】 上記受信ステップは受信機において遂
    行され、上記地理データベース探索ステップは上記受信
    機から分離されているナビゲーションシステムにおいて
    遂行される請求項１に記載の方法。
14. 【請求項１４】 ナビゲーションシステムを動作させる
    方法であって、 ビークル搭載のナビゲーションシステムにおいて、複数
    の放送交通メッセージを放送する交通放送システムから
    上記交通メッセージを受信するステップを備え、 上記各交通メッセージは、上記交通メッセージが関係し
    ている位置を識別する第１のデータ成分と、上記位置に
    おける交通渋滞の酷さのレベルを指示する第２のデータ
    成分とを含んでおり、 上記ビークル搭載のナビゲーションシステムにおいて、
    上記第１のデータ成分によって識別された位置に関連す
    るデータエンティティを、上記ビークル搭載のナビゲー
    ションシステムによって使用される地理データベース内
    で探知するために上記地理データベースを探索するステ
    ップと、 上記探知されたデータエンティティを、上記第２のデー
    タ成分の酷さのレベルに関連付けるステップと、を更に
    備えていることを特徴とする方法。
15. 【請求項１５】 上記第１のデータ成分は、上記位置を
    識別する位置参照番号からなる請求項１４に記載の方
    法。
16. 【請求項１６】 上記複数の放送交通メッセージを受信
    した後に、上記交通メッセージから上記第１のデータ成
    分及び上記第２のデータ成分を抽出するステップ、を更
    に備えている請求項１４に記載の方法。
17. 【請求項１７】 上記データ成分は、上記参照番号が割
    当てられている連続する隣接位置を指示するデータを含
    んでいる請求項１４に記載の方法。
18. 【請求項１８】 交通状態放送システムによって放送さ
    れる交通メッセージと共に使用されるナビゲーションシ
    ステムと共に使用される地理データベースであって、 地理領域内の道路網の部分を含む地理特色を表す第１の
    型のデータエンティティと、 上記交通メッセージ内に含まれる位置参照を、上記第１
    の型の複数のデータエンティティに関連付ける第２の型
    のデータエンティティと、を備え、 上記地理データベースを、上記交通状態放送システムに
    よって放送される交通メッセージと共に使用する上記ナ
    ビゲーションシステムは、上記地理データベースを使用
    する時に上記交通メッセージからの情報を組み入れるこ
    とができることを特徴とする地理データベース。
19. 【請求項１９】 上記第１の型のデータエンティティ及
    び上記第２の型のデータエンティティは複数のパーセル
    に編成され、上記各パーセルは上記それぞれの型の複数
    のデータエンティティを含んでいる請求項１８に記載の
    発明。
20. 【請求項２０】 上記地理データベースは、複数のデー
    タエンティティを各々が含んでいるパーセルに分離され
    ている請求項１８に記載の発明。
21. 【請求項２１】 上記地理データベースは、分離した型
    の地理データからなっている請求項１８に記載の発明。
22. 【請求項２２】 上記分離した型の地理データは、ルー
    ティング及び地図作成を含んでいる請求項２１に記載の
    発明。
23. 【請求項２３】 上記地理データベースは、コンピュー
    タ可読媒体上に格納されている請求項１８に記載の発
    明。
24. 【請求項２４】 上記地理データベースは、ＣＤ−ＲＯ
    Ｍディスク、ＤＶＤディスク、及びハードディスクの１
    つに格納されている請求項１８に記載の発明。
25. 【請求項２５】 上記第１の型のデータエンティティ
    は、道路のセグメントを表している請求項１８に記載の
    発明。
26. 【請求項２６】 上記第１の型のデータエンティティ
    は、上記交通メッセージ内の上記位置参照によって表さ
    れている上記道路網に沿う位置に導入する道路のセグメ
    ントを含む道路のセグメントを表している請求項１８に
    記載の発明。
27. 【請求項２７】 上記第２の型のデータエンティティへ
    の位置参照に関係付けられている索引を更に備えている
    請求項１８に記載の発明。
28. 【請求項２８】 上記第２の型のデータエンティティは
    複数のパーセル内に数値的に配列されており、上記地理
    データベースは更に、 上記複数の各パーセル内の上記第２の型の第１のデータ
    エンティティに関して、上記第２の型の第１のデータエ
    ンティティが位置している上記複数のパーセルの１つを
    識別する索引を更に備えている請求項１８に記載の発
    明。
29. 【請求項２９】 上記位置参照は、道路に沿うインター
    チェンジを表す上記交通メッセージ内に含まれている請
    求項１８に記載の発明。
30. 【請求項３０】 上記地理データベースの少なくとも一
    部は、遠隔配置されている請求項１８に記載の発明。
31. 【請求項３１】 上記第２の型のデータベースエンティ
    ティは、遠隔配置されている請求項１８に記載の発明。
32. 【請求項３２】 上記第２の型のデータベースエンティ
    ティは、遠隔位置から上記ナビゲーションシステムへダ
    ウンロードされる請求項１８に記載の発明。
33. 【請求項３３】 ナビゲーションシステムにおいて使用
    可能であり、また位置参照番号を用いて道路に沿う位置
    を識別する交通放送システムによって放送される交通メ
    ッセージをも使用する地理データベースを形成する方法
    であって、 上記各位置参照番号毎に、上記位置参照番号によって識
    別される位置に対応する道路の部分を表す上記地理デー
    タベース内のデータエンティティの第１のグループを識
    別するステップと、 上記位置参照番号によって識別される位置へ導入する道
    路の部分を表す上記地理データ内のデータエンティティ
    の第２のグループを識別するステップと、 上記各位置参照番号毎に、上記データエンティティの第
    １のグループ及び第２のグループを識別する複数の位置
    参照データエンティティを形成するステップと、を備え
    ていることを特徴とする方法。
34. 【請求項３４】 地理領域内の地理特色を表すデータエ
    ンティティを含み、交通メッセージ放送システムの関連
    する第１の型の交通メッセージと共に使用することがで
    きる第１の型の交通メッセージ位置参照データ、及び上
    記交通メッセージ放送システムの関連する第２の型の交
    通メッセージと共に使用することができる第２の型の交
    通メッセージ位置参照データを更に含む地理データベー
    スを使用するナビゲーション応用プログラムを動作させ
    る方法であって、 上記交通放送システムの上記第１の型及び上記交通放送
    システムの上記第２の型の一方を選択するステップと、 上記交通メッセージ放送システムによって放送される交
    通メッセージの上記選択された型を受信するステップ
    と、 上記選択された型に対応する上記地理データベース内の
    上記位置参照データベースを使用して、上記交通メッセ
    ージ放送システムから受信された上記交通メッセージ内
    のデータを、上記地理データベース内の地理領域内の地
    理特色を表す上記データエンティティに関連付けるステ
    ップと、を備えていることを特徴とする方法。