JP2001331493A - 地図データ用演繹データベース・アーキテクチャ - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】 ナビゲーション・システムで用いる地図デー
タベースを更新すること及び地図データベースに含まれ
る地図データとは異なるタイプのデータを統合する方法
及び総合することができるように構成されたデータベー
ス・アーキテクチャを提供する。 【解決手段】 データ・アクセス・レイヤーは、地図的
参照データに対するナビゲーション・プログラム・アプ
リケーションからのリクエストを受け入れ、地図データ
ベースをアクセスしリクエストに対する応答を供給す
る。ロジック・ルールは、地図データベースに関連付け
られる。データ・アクセス・レイヤーは、媒体からのデ
ータをアクセスするためにインデックスを用いてかつそ
れらが媒体に記憶されるフォーマットからナビゲーショ
ン・プログラム・アプリケーションが用いることができ
るフォーマットにデータを変換する方法を決定するため
にロジック・ルールをアクセスしかつ組合せる演繹デー
タベース・エンジンを含む。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、地図データ用デー
タベース・アーキテクチャに関し、特に本発明は、ナビ
ゲーション・システムにおいて又はナビゲーション・ア
プリケーションによって用いる地図データ用演繹データ
ベース・アーキテクチャに関する。

【０００２】

【従来の技術】ナビゲーション・システムは、種々のコ
ンピュータ・プラットフォームに供給される。あるナビ
ゲーション・システムにおいて、ナビゲーション・アプ
リケーション及びハードウェアは、シングル・ユニット
に組合させる。そのようなシングル・ユニット・システ
ムは、車両に取付けられうるか又は人間によって運ばれ
うる。また、ナビゲーション・アプリケーションは、パ
ーソナル・コンピュータ、パーソナル・ディジタル・ア
シスタント、パームパイロット(PalmPilot)型デバイ
ス、等のような、汎用コンピュータ・プラットフォーム
に対して利用可能である。

【０００３】ナビゲーション・システム及びナビゲーシ
ョン・アプリケーションは、様々な有用なナビゲーショ
ン関連機能（機構・特徴）及びサービスを供給する。例
えば、車両に取付けられたナビゲーション・システム
は、所望の目的地までの運転に対する詳細な命令を供給
することができそれにより走行時間及び費用を低減す
る。また、ナビゲーション・システム及びナビゲーショ
ン・アプリケーションは、所望の形式のビジネスを検索
することができかつそのようなビジネスの場所へのルー
ティング・ガイダンスを供給する。また、ナビゲーショ
ン・システム及びナビゲーション・アプリケーション
は、トラック運送会社、宅配便サービス、等のような車
両部隊(vehicle fleets)のオペレータによって用いられ
うる。

【０００４】種々の有用な機能を供給するために、ナビ
ゲーション・システム及びナビゲーション・アプリケー
ションは、地図データを用いる。ナビゲーション・シス
テム及びナビゲーション・アプリケーションに対して地
図データを供給することに関連付けられた一つの考慮
は、地図データが時代遅れに（古く）なるということで
ある。例えば、新しい道路が造られ、ビジネスが場所を
変え、道路建設が道路を閉鎖し、迂回路が設定され、博
物館（美術館）及びレストランの時間が変わる、等。車
両にナビゲーション・システムを有する車両の所有者の
ような、エンド・ユーザは、逐次更新されたナビゲーシ
ョン・システムの地図データを持つことを欲するという
ことが期待される。

【０００５】

【発明が解決しようとする課題】ナビゲーション・シス
テムに対する最新データを供給することに関する考慮
は、異なる、非互換性のナビゲーション・システム・プ
ラットフォームの急増である。ナビゲーション・システ
ムの寿命の間にエンド・ユーザのナビゲーション・シス
テムに対して最新地図データを供給するために、地図デ
ータのプロバイダは、最新地図データを有するだけでな
く、エンド・ユーザの特定のナビゲーション・システム
・プラットフォームと互換性があるプロダクトを供給こ
とが必要である。１０年以上でありうる、ナビゲーショ
ン・システムの期待される寿命の間に、これは、増大す
る数の古い、非互換性のナビゲーション・システム及び
プラットフォームをサポートすることを必要とする。最
新地図データ・プロダクトの特別バージョンが各別々
の、異なるタイプ又はバージョンのナビゲーション・プ
ラットフォームに対して製造されなければならないなら
ば、異なるプロダクトの数は、長い年月の間、増大し続
けてエンド・ユーザに対する最新地図データ・プロダク
トの供給を困難かつ高価なものにする。

【０００６】ナビゲーション・システム又はナビゲーシ
ョン・アプリケーションにナビゲーション関連サービス
を供給することに関連付けられた別の問題は、地図デー
タと異なるタイプのデータを統合することである。例え
ば、ある人は、ディナーの予約をしかつ映画を見ること
を欲しうる。ナビゲーション・システムは、所望のタイ
プのレストランにおける予約の可能性、種々の映画館に
おける映画のショー・タイム（上映時間）、及びその人
の場所と、所望のタイプのレストランの場所及び種々の
映画館の場所との間の走行時間を考慮して、自動的に所
望のタイプのレストランに予約をし、映画のチケットを
取得し、かつレストランまで、そして映画館まで、それ
から家に戻るまでの走行のためのドライビング・インス
トラクション（命令）を供給する機能（特徴）を含みう
るということが想像される。このような種類の機能（特
徴）を供給するために、手段は、レストラン及び映画館
の場所に関する地図データ、道路網での走行時間に関す
るデータ、レストラン予約に関するデータ、及び映画の
上映時間及び予約に関するデータを組合せることを必要
とする。

【０００７】従って、ナビゲーション・システムで用い
る地図データベースを更新することを供給する方法の必
要性が存在する。

【０００８】また、地図データベースに含まれる地図デ
ータと異なるタイプのデータを統合する方法の必要性が
存在する。

【０００９】

【課題を解決するための手段】これら及び他の目的に取
り組むために、本発明は、ナビゲーション関連機能(nav
itation-related functions)を供給するために地図デー
タを用いるデータベース・アーキテクチャを備えてい
る。ナビゲーション関連機能は、ナビゲーション・プロ
グラム・アプリケーションによって供給される。地図デ
ータベースは、媒体に記憶されかつ地理的特徴(geograp
hic features)を表すデータを含みかつデータへの複数
のインデックスを有する。データ・アクセス・レイヤー
は、地理的参照データ(geographically-referenced dat
a)に対してナビゲーション・プログラム・アプリケーシ
ョンからのリクエストを受け入れ、地図データベースを
アクセスしかつストリート・ネーム（通り名）、シティ
ー・ネーム（都市名）、等のような地理的参照データ及
び非空間的参照データを含むデータに対するナビゲーシ
ョン・プログラム・アプリケーションからのリクエスト
に対する応答を供給する。論理規則（ロジック・ルー
ル）は、地図データベースに関連付けられる。データ・
アクセス・レイヤーは、媒体からデータをアクセスしか
つそれらが媒体に記憶されるフォーマットからナビゲー
ション・プログラム・アプリケーションが使用できるフ
ォーマットにデータを変換するためのインデックスの使
用方法を決定するために論理規則をアクセスしかつ組合
せる演繹データベース・エンジンを含む。データベース
・アーキテクチャは、オフ・ボード・データ・サプライ
ヤ(off-board data suppliers)から無線通信リンクを介
して取得したデータを用いるナビゲーション・システム
を含む車両ナビゲーション・システムで用いることがで
きる。

【００１０】

【発明の実施の形態】本発明のデータベース・アーキテ
クチャは、ナビゲーション・システム用データベース・
アーキテクチャであって、地図データ及び該地データへ
の複数のインデックスを含む地図データベースと；地図
的参照データに対するリクエストを受け入れ、前記地図
データが記憶される媒体から該地図データをアクセスし
かつ該地図的参照データに対する該リクエストに応答を
供給するデータ・アクセス・プログラミングと；前記地
図データベースに関連付けられたロジック・ルールと；
及び前記データ・アクセス・プログラミングに関連付け
られた演繹データベース・エンジンとを備え、前記演繹
データベース・エンジンは、前記媒体からどの前記地図
データをアクセスするかを決定するためにどの前記イン
デックスを用いるかを決定すべく前記ロジック・ルール
をアクセスしかつ組合せることを特徴とする。

【００１１】本発明のデータベース・アーキテクチャ
は、ナビゲーション・システム用データベース・アーキ
テクチャであって、第１のフォーマットで媒体に記憶さ
れる地図データを含む地図データベースと；第２のフォ
ーマットで供給されるべき地図的参照データに対するリ
クエストを受け入れ、前記媒体から前記地図データをア
クセス、該地図データを前記第１のフォーマットから前
記第２のフォーマットに変換し、かつ該地図的参照デー
タに対する該リクエストに応答を供給するデータ・アク
セス・プログラミングと；前記地図データベースに関連
付けられたロジック・ルールと；及び前記データ・アク
セス・プログラミングに関連付けられた演繹データベー
ス・エンジンとを備え、前記演繹データベース・エンジ
ンは、前記地図データを前記第１のフォーマットから前
記第２のフォーマットに変換する方法を決定すべく前記
ロジック・ルールをアクセスしかつ組合せることを特徴
とする。

【００１２】本発明のデータベース・アーキテクチャで
は、前記ロジック・ルールのそれぞれは、条件を特定す
る第１の部分とアクションを特定する第２の部分とを備
えてもよい。

【００１３】本発明のデータベース・アーキテクチャで
は、前記演繹データベース・エンジンは、どの前記ロジ
ック・ルールが満たされた第１の部分を有するかを決定
し、満たされた前記第１の部分を有する前記ロジック・
ルールのどの一つを最初に実行すべきかを決定し、かつ
最初に実行すべく決定された前記ロジック・ルールの前
記第２の部分で特定された前記アクションを実行するよ
うに構成してもよい。

【００１４】本発明のデータベース・アーキテクチャで
は、前記第２の部分は、プログラミング・ルーチン及び
状態の変化の一つを示すようにしてもよい。

【００１５】本発明のデータベース・アーキテクチャで
は、前記条件は、前記地図データに関する本質的条件及
び前記演繹データベース・エンジンによって先に決定さ
れた状態に関する付帯的条件の一つを備えてもよい。

【００１６】本発明のデータベース・アーキテクチャで
は、前記地図データは、第１のフォーマットで前記媒体
に記憶されかつ前記地図的参照データに対するリクエス
トへの前記応答は、第２のフォーマットで供給され、か
つ前記演繹データベース・エンジンは、前記地図データ
を前記第１のフィーマットから前記第２のフォーマット
に変換する方法を決定するために前記ロジック・ルール
をアクセスしかつ組合せるようにしてもよい。

【００１７】本発明のデータベース・アーキテクチャで
は、遠隔的に配置されたデータを更に備え、かつ前記ロ
ジック・ルールは、利用可能な場合に前記遠隔的に配置
されたデータへのアクセスを供給するロジック・ルール
を含んでもよい。

【００１８】本発明のデータベース・アーキテクチャで
は、前記地図データベースは、更新されたデータを備
え、かつ前記ロジック・ルールは、前記更新されたデー
タへのアクセスを供給するロジック・ルールを含んでも
よい。

【００１９】本発明のデータベース・アーキテクチャで
は、前記データ・アクセス・プログラミングは、前記ロ
ジック・ルールによって呼び出されるデータ検索ルーチ
ンを含むインデックス・アクセス・システムを更に備
え、前記データ検索ルーチンは、前記インデックスをア
クセスするようにしてもよい。

【００２０】本発明のデータベース・アーキテクチャで
は、前記データ・アクセス・プログラミングは、地図デ
ータを前記第１のフォーマットから前記第２のフォーマ
ットに変換するためにロジック・ルールによって呼び出
されるデータ検索ルーチンを含む物理的から論理的への
変換システムを更に備えてもよい。

【００２１】本発明の方法は、地図データベースをアク
セスするためのオペレーションの方法であって、ナビゲ
ーション関連データに対するリスエストを受け入れる段
階と；媒体に記憶された地図データベースをアクセスす
る段階と；前記地図データベースからデータを取得する
段階と；前記リクエストに対して応答を供給するために
前記地図データベースから取得した前記データを用いる
段階とを具備し、前記アクセスする段階、前記取得する
段階及び前記用いる段階は、前記応答を供給するために
必要な全てのデータが前記地図データベースから取得さ
れかつ応答が前記リクエストに供給されるまで、以下の
段階を繰り返し実行することを含む：前記地図データベ
ースに関連付けられたロジック・ルールをアクセスする
段階；どの前記ロジック・ルールが満たされるかを決定
する段階；満たされた前記ロジック・ルールのどれが最
も高い優先度を有するかを結締する段階；及び前記最も
高い優先度を有することが決定された前記ロジック・ル
ールによって特定されたアクションを実行する段階を具
備する。ことを特徴とする方法。

【００２２】本発明のデータベース・アーキテクチャ
は、ナビゲーション・システム用の改良されたデータベ
ース・アーキテクチャであって、前記データベース・ア
ーキテクチャは、地図データ及び該地図データへの複数
のインデックスを含む地図データベースを備え、更に前
記データベース・アーキテクチャは、地図的参照データ
に対するリクエストを受け入れ、該地図データが記憶さ
れる媒体から該地図データをアクセスしかつ前記地図的
参照データに対するリクエストに対して応答を供給する
データ・アクセス・プログラミングを含み、前記改良
は、前記地図データベースに関連付けられたロジック・
ルール；及び前記データ・アクセス・プログラミングに
含まれる演繹データベース・エンジンを備え、前記演繹
データベース・エンジンは、どの前記地図データを前記
媒体からアクセスするかを決定するために用いる前記イ
ンデックスのどれかを決定するために前記ロジック・ル
ールをアクセスしかつ組合せる。

【００２３】本発明のデータベース・アーキテクチャで
は、前記ロジック・ルールのそれぞれは、条件を特性す
る第１の部分とアクションを特定する第２の部分とを備
えもよい。

【００２４】本発明のデータベース・アーキテクチャで
は、前記演繹データベース・エンジンは、どの前記ロジ
ック・ルールが満たされた第１の部分を有するかを決定
し、満たされた前記第１の部分を有する前記ロジック・
ルールのどの一つを最初に実行すべきかを決定し、かつ
最初に実行すべく決定された前記ロジック・ルールの前
記第２の部分で特定された前記アクションを実行するよ
うに構成してもよい。

【００２５】本発明のデータベース・アーキテクチャで
は、前記第２の部分は、プログラミング・ルーチン及び
状態の変化の一つを示すように構成してもよい。

【００２６】本発明のデータベース・アーキテクチャで
は、前記条件は、前記地図データに関する本質的条件及
び前記演繹データベース・エンジンによって先に決定さ
れた状態に関する付帯的条件の一つを備えてもよい。

【００２７】本発明のデータベース・アーキテクチャ
は、ナビゲーション・システム用の改良されたデータベ
ース・アーキテクチャであって、前記データベース・ア
ーキテクチャは、第１のフォーマットで媒体に記憶され
る地図データを含む地図データベースを備え、更に、第
２のフォーマットで供給されるべき地図的参照データに
対するリクエストを受け入れ、前記媒体から前記地図デ
ータをアクセス、該地図データを前記第１のフォーマッ
トから前記第２のフォーマットに変換し、かつ該地図的
参照データに対する該リクエストに応答を供給するデー
タ・アクセス・プログラミングと；前記地図データベー
スに関連付けられたロジック・ルールと；及び前記デー
タ・アクセス・プログラミングに含まれた演繹データベ
ース・エンジンとを備え、前記演繹データベース・エン
ジンは、前記地図データを前記第１のフォーマットから
前記第２のフォーマットに変換する方法を決定すべく前
記ロジック・ルールをアクセスしかつ組合せる。

【００２８】

【実施例】I. ナビゲーション・システム − 概要 この開示の目的に対して、“ナビゲーション・システ
ム”は、車両に取付けられたシステムを含むことが理解
されている（即ち、車両搭載ナビゲーション・システ
ム）。また、“ナビゲーション・システム”は、パーソ
ナル・コンピュータ、ネットワーク、パーソナル・ディ
ジタル・アシスタンス、携帯電子機器、等に取付けられ
たアプリケーションを含む、ナビゲーション関連機能
（特徴）を供給しかつ地図データを用いるコンピュータ
・プラットフォームに取付けられたソフトウェア・アプ
リケーションを含む。

【００２９】本発明の実施例は、空間データベースのフ
ィールドに意味データベース解析及び論理質問エンジン
設計(logical query engine design)の原理を適用す
る。意味データベース（“演繹データベース”とも称す
る）は、ネットワーク構造において結びつくデータ及び
ロジック・ステートメント（論理文）のセットを規定す
る。質問を充たすために、演繹データベース・エンジン
は、質問を充たすデータ要素を見付けるためにロジック
・コネクション（論理結合）を介してネットワークを検
索する。（データの）実際の読み出しは、真(true)また
は偽(false)のいずれかに対して評価する簡単な規則で
ある低レベル述語(low level predicates)によって制御
される。これらの低レベル述語は、次いでＣ機能(C fun
ctions)を呼び出す。偽に対して評価する述語は、デー
タを戻さない（リターンしない）か又は不適用である。
真に対して評価する述語は、一つの値又は行全体を戻す
（リターンする）ことができる。

【００３０】図１を参照すると、ナビゲーション・シス
テム１０のブロック図が示されている。ナビゲーション
・システムは、ハードウェア及びソフトウェア・コンポ
ーネントを備えている。ハードウェア及びソフトウェア
・コンポーネントは、ナビゲーション関連機能をエンド
・ユーザ（例えば、ドライバ及び／又はパッセンジャ）
に供給するために一緒に動作する。代替実施例におい
て、以下に説明するように、ナビゲーション・システム
１０は、車両の外部に設置されうるか又は種々の他のプ
ラットフォーム又は環境で実施されうるけれども、図１
において、ナビゲーション・システム１０は、自動車又
はトラックのような、車両１１に取付けられる。ここの
開示する実施例は、車両搭載システムに限定されない。

【００３１】図１に示した実施例を参照すると、ナビゲ
ーション・システム１０は、プロセッサ１２、プロセッ
サ１２に接続されたドライバ１４、メモリ２０及びナビ
ゲーション・システムを動作するためのナビゲーション
・システム・プログラミング（ソフトウェア、ファーム
ウェア、データ、等）１８、並びに構成パラメータ１９
のような、データを記憶するための不揮発性メモリ記憶
装置１６を含む。また、ナビゲーション・システム１０
は、測位システム・コンポーネント２４を含みうる。測
位システム・コンポーネント２４は、その全てがこの分
野において知られている、ＧＰＳ型技術、推測航法型シ
ステム、またはこれらの組合せ、或いは他のシステムを
用いうる。測位システム・コンポーネント２４は、車両
のスピード（速度）、方向、角加速度、等を測定する適
当な感知（検知）装置２５を含みうる。また、測位シス
テム・コンポーネント２４は、既知の方法で、ＧＰＳ信
号を取得するための適当な技術を含みうる。測位システ
ム・コンポーネント２４は、プロセッサ１２に信号２６
を出力する。信号２６は、ナビゲーション・システム１
０の場所（位置）、方向、走行距離、スピード、等を決
定するためにプロセッサ１２上で実行されるプログラミ
ング１８によって用いられる。

【００３２】また、ナビゲーション・システム１０は、
ユーザ・インタフェース３１を含む。ユーザ・インタフ
ェース３１は、エンド・ユーザに情報をナビゲーション
・システム１０に入力させる適当な装置を含む。この入
力情報は、ナビゲーション・システムのナビゲーション
機能を使用するためのリクエストを含みうる。例えば、
入力情報は、所望の目的地へのルートに対するリクエス
トを含みうる。また、入力情報は、構成情報のような、
他の種類の情報を含みうる。ナビゲーション・システム
へ情報を入力するために用いられる装置は、キーパッ
ド、キーボード、マイクロフォン、等、並びに、音声認
識プログラムのような、適当なソフトウェアを含みう
る。また、ユーザ・インタフェース３１は、エンド・ユ
ーザに情報を戻して供給する適切な装置を含む。この装
置は、ディスプレイ、スピーカ、又は他の手段を含みう
る。

【００３３】プロセッサ、ドライブ、メモリ、測位シス
テム・コンポーネント、ユーザ・インタフェース、等を
含む、これまで述べたナビゲーション・システムのコン
ポーネントは、ナビゲーション・システムにおいて用い
られるあらゆるタイプのものでありうる。

【００３４】ナビゲーション・システム１０は、地図デ
ータ４０を用いる。地図データ４０は、記憶媒体３２に
記憶される。記憶媒体３２は、ナビゲーション・システ
ムによって地図データベース４０を読み出しかつ用いる
ことができるようにドライブ１４に取付けられる。記憶
媒体３２は、車両が走行している地理領域に対する適当
な地図データを有する記憶媒体を用いることができるよ
うに取付け自在かつ取替え自在でありうる。更に、記憶
媒体３２は、その地図データ４０を容易に更新できるよ
うに取替え自在である。一実施例において、地図データ
４０は、米国イリノイ州、ローズモント(Rosemont)のナ
ビゲーション・テクノロジー・コーポレーション(Navig
ation Technologies Corporation)によって供給され
る。

【００３５】一実施例において、記憶媒体３２は、ＣＤ
−ＲＯＭディスクである。代替実施例において、記憶媒
体３２は、ドライブ１４がＰＣＭＣＩＡスロットで置き
換えられるような場合にはＰＣＭＣＩＡカードでありう
る。固定又はハードディスク、ＤＶＤディスク又は他の
現在利用可能な記憶媒体、並びに将来開発されるであろ
う記憶媒体を含む、種々の他の記憶媒体が用いられう
る。記憶媒体３２及び地図データ４０は、代替実施例に
関して以下により詳細に説明するように、ナビゲーショ
ン・システムの場所で物理的に供給されなくてもよい。
代替実施例において、地図データ４０のあるもの又は全
てがそれに記憶される、記憶媒体３２は、必要に応じ
て、通信リンクを介して供給される地図データの部分及
びナビゲーション・システムの残りの部分から遠隔的に
設置されうる。

【００３６】図２を参照すると、ナビゲーション・シス
テム１０のナビゲーション・システム・プログラミング
１８に含まれるものは、ナビゲーション関連アプリケー
ション２８である。これらのナビゲーション関連アプリ
ケーション２８は、種々のナビゲーション関連特徴（フ
ューチャ）及び機能（ファンクション）を供給するため
に地図データ４０及び測位システム・コンポーネント２
４からの出力（もし利用可能ならば）を用いる。これら
のナビゲーション関連アプリケーション２８は、ルート
計算アプリケーション３３、地図ディスプレイ・アプリ
ケーション３４、ルート・ガイダンス・アプリケーショ
ン３５（詳細な方向が所望の目的地に到達するために供
給される）、及び地理コーディング(geo-coding)（目的
地の選択に用いられる）を含む。ナビゲーション・アプ
リケーション２８は、これらに追加して又は代替的に他
の機能（ファンクション）又はサブプログラム３６を含
みうる。例えば、ナビゲーション・アプリケーション２
８は、地図マッチング機能（ファンクション）を供給す
る車両測位アプリケーションを含みうる。これらのナビ
ゲーション関連アプリケーション２８は、個別のプログ
ラムとして表されるけれども、それらは一つのアプリケ
ーションに一緒に組合せられうる。

【００３７】また、ナビゲーション・システム・プログ
ラミング１８は、ユーザ・インタフェース・プログラミ
ング３７を含む。ユーザ・インタフェース・プログラミ
ング３７は、（図１の）ユーザ・インタフェース装置３
１をサポートする。例えば、このユーザ・インタフェー
ス・プログラミング３７は、ユーザ・インタフェース３
１、メニューのディスプレイ、プロンプト、等を介して
エンド・ユーザに情報のグラフィック・ディスプレイを
供給する。また、ユーザ・インタフェース・プログラミ
ングは、音声認識及び／又は記録音声セグメント又は音
声合成を供給しうる。

【００３８】また、ナビゲーション・システム・プログ
ラミング１８は、オペレーティングシステム・プログラ
ム３８を含みうる。オペレーティングシステム・プログ
ラム３８は、ナビゲーション・システム１０のハードウ
ェア・プラットフォームに適する。

【００３９】また、ナビゲーション・システム・プログ
ラミング１８は、データ・アクセス・レイヤー３９を含
む。データ・アクセス・レイヤー３９は、媒体３２の地
図データ４０をアクセスするためのプログラミングを含
む。好ましい実施例において、データ・アクセス・レイ
ヤー３９は、ナビゲーション・アプリケーション２８と
地図データ４０との間、特にナビゲーション機能（ファ
ンクション）２８とオペレーティングシステム３８との
間に設置される。データ・アクセス・レイヤー３９は、
以下に詳述する。 ＩＩ． 地図データベース Ａ． 概要 図２を参照すると、地図データ４０は、一つ以上のコン
ピュータ読み取り可能データ・ファイル又はデータベー
ス４２の形式で媒体３２に記憶される。地図データ４０
は、特定の地図領域における又はそれに関する道路及び
交差点の場所に関する情報を含みうるし、かつ、また、
一方通行路及び方向転換制限、ストリート・アドレス、
代替ルートに関するのような、道路及び交差点の属性に
関する情報、並びにホテル、レストラン、博物館（美術
館）、スタジアム、オフィス、自動車販売店、自動車修
理工場、等に関する情報を含みうる。地図データベース
４２の網羅領域(coverage region)は、シカゴ及びその
郊外、ニューヨーク及びその郊外、ロサンジェルス及び
その郊外のような、メトロポリタン・エリアを含みうる
か、又は代替的に、領域エリアは、カリフォルニアのよ
うな、州全体、アメリカ合衆国のような、国全体、又は
ドイツ、フランス、及びイタリアのような一つよりも多
くの国、又はこれらの組合せを含みうる。一つの領域よ
りも多くの領域に関するデータが記憶媒体３２に記憶さ
れうる。

【００４０】網羅領域に対する適当な（相応な）レベル
の機能性を供給するために、比較的大きなデータベース
が供給される。ＣＤ−ＲＯＭディスク、ＤＶＤディス
ク、ハードディスク、又はＰＣＭＣＩＡカードのよう
な、記憶媒体は、適当な機能性を供給するのに十分な大
きさ及び複雑さのデータベースを取り扱うことが可能で
ある。ナビゲーション・システムが既知の機能を実行す
るためにある一定の既知のかつ予想される方法で地図デ
ータを用いるので、地図データは、ナビゲーション・シ
ステムによってこれらの既知の方法でそれらの使用を容
易にするような方法で編成し、構成し、及び／又は配置
することができる。地図データベースにおいて地図デー
タ４０を編成し、構成し、又は配置することができる方
法のあるものは、その全体の開示がここで参考として採
り入れられる米国特許第５，９６８，１０９号、第５，
９７４，４１９号、及び第５，９５３，７２２号に記述
される。

【００４１】図３は、地図データベース４２の編成を示
す。図３に示す編成は、データベースにおいて地図デー
タ４０を編成することができる一つの方法を示す。種々
の他の構成が可能でありかつそれらを用いることができ
る。図３において、地図データベース４２は、データの
個別のサブセット４４を備えて示される。これらのサブ
セット４４は、ルーティング・データ５６、地図製作
（カートグラフィック）・データ５７（地図ディスプレ
イ用）、操縦データ５８（ルート・ガイダンス用）、興
味のある地点のデータ５９（ホテル、レストラン、博物
館（美術館）、スタジアム、空港、等のような、特定の
興味の地点を識別するため）、ネーム・データ６０（道
路、場所及び他の特徴のネームを識別する）、場所６１
（例えば、シティー（市）、ステート（州）、カウンテ
ィ（群））、郵便番号６２及び他の種類のデータ６３を
含む。地図データベース４２は、異なるデータ・タイプ
で又はより少ない又はより多くのデータ・タイプで規定
されうる。

【００４２】地図データ４０の各サブセット４４は、特
定のナビゲーション機能を実行するために必要なデータ
及び関連属性を含むが機能を実行するために不要なデー
タ及び属性を排除する。ある情報が一つよりも多くのサ
ブセットに含まれうるという結果を伴う、これらのサブ
セットのそれぞれの間でデータのオーバーラップが存在
する。例えば、ルーティング・データ５６の道路区間を
表しているデータ・エンティティ及び同じ地図製作デー
タ５７の道路区間を表しているデータ・エンティティ
は、道路区間の終端に設置されたノード（節）を識別す
る属性を含みうる。この複製は、より大きな総合的デー
タ記憶要求を結果としてもたらしうるけれども、ナビゲ
ーション機能（即ち、図２のアプリケーション２８）の
それぞれは、より小さな量のデータを取り扱うことの合
成効率によって利益を得る。

【００４３】異なるタイプへの地図データ４０の編成
は、異なるナビゲーション機能によってデータの効率的
使用を供給するけれども、これらの異なるタイプを用い
る異なる機能が一緒に動作することを供給する必要があ
る。これらのデータのタイプ４４を一緒の動作させるた
めに、インデックス６６が地図データベース４２の一部
として含まれる。インデックス６６は、相互参照、検索
ツリー、及び／又は他のデータ見出し技術を供給する。
インデックス６６は、データ・タイプ４４のいずれかの
外部に設置することができるか又はインデックス６６
は、データのタイプ４４のいずれかの内に設置されう
る。地図データベース４４のこの実施例において、内部
及び外部インデックスの両方を用いる。

【００４４】Ｂ． 地図データのレイヤーリング（段彩
式表現法） それらの使用を向上させるために地図データ４０を編成
することができる別の方法は、レイヤーのデータを供給
することである。地図ディスプレイ・アプリケーション
及びルート計算アプリケーションのような、ナビゲーシ
ョン・アプリケーションのあるものは、異なるディテー
ル（詳細・細部）のレベルのデータを用いうる。従っ
て、データ・タイプのサブセットのあるものの内で、地
図データ４０は、個別のレイヤーに供給される。

【００４５】レイヤーリングを実施（実現）するための
一つの方法は、各道路をランクに関連付けることであ
る。道路のランクは、その機能クラス(functional clas
s)に対応しうる。“４”のランクを有している道路は、
高速道路及びフリーウェイのような、高いボリューム(h
igh volume)の、制御アクセス道路(controlled accessr
oads)を含みうる。“３”のランクを有している道路
は、ほとんどスピード変化がない高いボリュームの道路
でありうるが、制御アクセス道路である必要はない。よ
り低くランク付けされた道路は、対応するより低いボリ
ュームを扱い（処理し）かつ一般により多くのスピード
変化又はより遅いスピードを有する。“０”のランクを
有している道路は、最も低いボリュームを扱う（処理す
る）ことができる。例えば、これらの最も低くランク付
けされた道路は、サイド・ストリート（脇道・横通
り）、アリーウェイ（裏通り・路地）、等を含みうる。
地図データベース４２では、道路の各部分は、個別の道
路区間データ・エンティティによって表される。道路区
間データ・エンティティは、のそれが表す道路区間のラ
ンクを識別する。

【００４６】地図データベースにおいて、レイヤーは、
物理的に又は論理的に実施（実現）されうる。物理的レ
イヤー（物理層）を供給するために、一つ以上のレイヤ
ーに対応する個別のデータの集合又はグループが供給さ
れる。道路区間データ・エンティティのランクは、道路
区間エンティティが含まれる最も高いデータ・レイヤー
を決定するために用いられる。例えば、図４を参照する
と、ルーティング・タイプ・データ５６は、データの５
つの個別のレイヤー、Ｒ０，Ｒ１，Ｒ２，Ｒ３、及びＲ
４を含みうる。これらのレイヤーのそれぞれは、ルート
計算アプリケーション３３によって用いることができ
る、異なるディテールを有するルーティング・データの
個別の集合を備えている。地図データベースのルーティ
ング・データ５６において、レイヤー０（“Ｒ０”）
は、“０”以上のランクを有している道路区間データ・
エンティティ（及びそれらの対応ルーティング・データ
属性のあるもの又は全て）を含む。そこで、レイヤー０
は、地図領域における全ての道路の全ての部分に対応し
ている道路区間データ・エンティティを含む。ルーティ
ング・データ５６のレイヤー１は、ルーティング・デー
タの個別のサブセット（又は集合）を備えかつ“１”以
上のランクを有しているルーティング区間データ・エン
ティティ（及びそれらの対応ルーティング・データ属性
のあるもの又は全て）だけを含む。ルーティング・デー
タ５６のレイヤー２は、ルーティング・データの個別の
サブセット（又は集合）を備えかつレベル“２”以上の
ランクを有しているルーティング区間データ・エンティ
ティ（及びそれらの対応ナビゲーション・データ属性の
あるもの又は全て）だけを含む、等。最も高いレイヤー
（レイヤーｎ）は、ｎのランクを有している道路を表す
記録だけを含む。他の実施例において、ｎは０よりも大
きいあらゆる数でありうるけれども、本実施例におい
て、ｎは４に等しい。各より高いレイヤーは、より少な
い記録を含むが、これらの記録は、走行が一般により速
い道路を表す。

【００４７】データの他のタイプは、それぞれが異なる
ディテールのレベルを有する、データの個別の集合を含
みうる。例えば、地図製作（カートグラフィック）・デ
ータ５７は、ルーティング・データ５６と同様なレイヤ
ーを含む。地図製作データ５７の異なるレイヤーは、迅
速なパニング及びズーミングを供給するために地図ディ
スプレイ・アプリケーション３４によって用いることが
できる。

【００４８】レイヤーへのデータのあるももの編成は、
データのある複製を結果としてもたらすけれども、レイ
ヤーリングによって供給される増大した効率は、あらゆ
る欠点を一般にオフセットする。上記した個別のタイプ
のデータの使用によるように、これらのレイヤーを一緒
の動作させることの必要性が生じる。インデックス６６
は、この目的のために供給されうる。

【００４９】上記したように、また、レイヤーリング
は、論理的に実施することができる。レイヤーリングが
論理的に実施される場合には、全てのランクのデータ・
エンティティを含む（タイプの）データの一つの集合が
供給される。しかしながら、（データ・アクセス・レイ
ヤー３９における）フィルタリング・ルーティンは、よ
り高いランクの道路だけが望ましい場合にはより低いラ
ンクの道路を表しているデータ・エンティティを抑制す
る。

【００５０】Ｃ． 地図データのパーセライゼーション ナビゲーション・システムによる地図データ４０の使用
を容易にするために用いることができる別の方法は、デ
ータをパーセライズ(parcelize)することである。所与
の地図領域全体に対するデータ記録の全てが同時にナビ
ゲーション・システムのメモリにロードされないと想定
すると、所望の機能を実行するために必要なそれらのデ
ータだけをメモリにロードすることが望ましい。これを
達成するために、地図データ４０は、ナビゲーション機
能を実行するために媒体からデータをアクセスしかつ読
み出すために必要な時間の量を最小化するように編成さ
れる。これを供給するために、データ４０は、パーセル
に編成される。データがパーセライズされる場合には、
地図データベース４２を一緒に構成する複数のデータ記
録は、個別のグルーピング又はパーセルに一緒にグルー
プにされる。図６は、パーセル９０に編成された地図デ
ータ４０を示す。データのパーセル９０は、パーセルの
全てのデータが媒体３２から同時に一緒にアクセスされ
るように設定される。それが他の要因（ファクタ）に関
連しうるけれども、これは、一つのディスク・アクセス
でアクセスすることができるデータの量に関係しうる。
ＣＤ−ＲＯＭディスクのようなあるタイプの媒体に対し
て、パーセルは、データの１６キロバイト量であるべく
設定されうる。図６に示すように、地図データ４０及び
地図データ４０に対するインデックス６６は、個別のパ
ーセル９０に形成されうる。インデックス６６のパーセ
ルは、グローバル部分９１のような、データベース４２
の個別の部分に設置されうる。また、インデックスは、
データ・タイプ４４のそれぞれの内に含まれうる。例え
ば、地図データ４０の各パーセル９０内に一つ以上のイ
ンデックスが存在しうる。

【００５１】パーセライゼーションに関連して、それら
の使用を容易にするために地図データのあるものを編成
することができる別の方法は、データを空間的に編成す
ることである。地図データが空間的に編成される場合に
は、地図領域において物理的に隣接する特徴は、データ
ベースにおいて物理的（又は論理的）に隣接するデータ
記録によって表される。地図データは、これらの技術の
両方の利点を取るためにパーゼライズしかつ空間的に編
成することの両方ができる。

【００５２】パーセルにデータを形成する目的に対し
て、上述したように、データは、異なるタイプ４４にま
ず個別に編成されうる。これらのタイプのデータのある
ものは、ナビゲーション・アプリケーション２８による
データの使用を容易にするために空間的にパーセライズ
されうる。空間的にパーセライズされたデータは、地図
的に近似な特徴を表すデータが データベース４２及
び／又は媒体３２で論理的及び／又は物理的に近似に設
置されるように配置される。ナビゲーション・アプリケ
ーションｐのあるものに対して、データの空間パーセラ
ゼーションは、媒体からより迅速に必要な地図データを
読み出しこと及びそれらを用いることができるメモリに
関連データをロードすることを供給する。この種の編成
は、記憶媒体３２でシークすること(seeking)を最小に
しかつこれらのナビゲーション機能のオペレーション
（動作・操作）をスピードアップしうる。ルーティン
グ、カートグラフィック、及び興味がある地点のデータ
は、空間的に編成されうるデータの種類の中に含まれ
る。

【００５３】空間的に編成された地図データをパーセラ
イズするために用いることができる多数の異なる手順が
存在する。例えば、簡単なパーセライゼーション方法
は、各パーセルのデータが矩形、地図データに関する矩
形グリッドを一緒に形成する複数のレギュラー・サイズ
の矩形の個別の一つの内に包含された特徴を表すよう
に、地図データを複数のパーセル又はグルーピングに分
けることを供給しうる。パーセライゼーションの別の方
法は、最大スレショルド以下のパーセル・サイズが得ら
れるまで、データを矩形のそれぞれが領域の部分を包含
している矩形の二分によって形成される矩形地域内に包
含されたパーセルに分けることである。更に、パーセラ
イゼーション手順は、全体の開示がここに参考として採
り入れられる１９９６年１０月２５日に出願した同時係
属中の米国特許出願第０８／７４０，２９５号に開示さ
れ、そしてまたパーセライゼーション手順は、全体の開
示がここに参考として採り入れられる米国特許第５，９
５３，７２２号公報に開示されいる。開示されている対
象を適用することができるパーセライゼーションの更に
別の方法は、米国特許４，８８８，６９８号公報に開示
されている。

【００５４】図５及び６を参照して、空間的に編成され
たデータのパーセライゼーションを説明する。図５は、
地図領域１１２の地図１１１を示す。（ドットまたは点
で表される）複数のポジション１１６が地図１１１に設
置（配置）されるべく示されている。ポジション１１６
のそれぞれは、図６の地図データベース４２に含まれる
情報に関する特徴が設置（配置）される地図領域１１２
の場所又は点を表す。例えば、ポジション１１４は、地
図データベース４２におけるデータによって表される、
道路区間の端点の物理的位置（ロケーション）、道路区
間に沿った点、（ホテル、シビック・センター等のよう
な）興味がある地点に対応しうる。これらのロケーショ
ン１１６のそれぞれは、固有の物理的ロケーション（緯
度、経度、及びオプショナルな絶対的又は相対的標高）
を有しかつロケーション１１６のそれぞれは、その二次
元（又は三次元）地図座標（即ち、緯度、経度、及びオ
プショナルな標高）によって独自に識別されうる。

【００５５】図５において、グリッド１１７は、地図１
１１によって表される地図領域１１２の上に横たわる。
グリッド１１７は、地図領域１１２を複数の矩形地域
（エリア）１１９に分割する。これらの矩形地域１１９
は、全て同じ大きさでありうるか又はパーセライゼーシ
ョンに用いられる手順により異なる大きさを有しうる。
グリッド１１７のグリッド線は、矩形地域１１９の境界
を表す。境界のロケーション(位置)は、用いられるパー
セライゼーション手順に依存しうる。一般に、空間パー
セライゼーションに対する手順のいずれかを用いる場合
には、各矩形地域１１９内に包含される特徴を表す特定
のタイプのデータのデータ記録は、データの個別のパー
セルに一緒にグループにされる。従って、（図６の）空
間的に編成されたデータの各パーセル９０は、（図５に
示すように）複数の矩形１１９の個別の一つの内に包含
された地図特徴を表す一つ以上のデータ記録を含む。

【００５６】図６に示すように、次いでパーセル９０
は、各パーセル９０のデータが論理的及び／又は物理的
に一緒にグループにされるようにデータベース４２を形
成するために記憶される。パーセルは、ナビゲーション
・システムによって媒体から同時にアクセスされるデー
タの量を表すので、データのパーセルがアクセスされる
場合には、そのデータ記録の全てが同時にナビゲーショ
ン・システムのメモリに読み込まれる。図５の地図１１
１を参照すると、これは、各矩形１１９内に包含された
空間的に編成されたデータのタイプの全てのデータ記録
がグループとして一緒にアクセスされるということを意
味する。ある一定の種類のナビゲーション機能に対し
て、地図領域において物理的に隣接する特徴を表す全て
のデータ記録を同時にメモリに有することが望ましいと
いうことを理解することができるであろう。

【００５７】これらのタイプのデータに対してパーセル
９０が形成されると、パーセルがオーダされる。種々の
タイプのオーダリング(ordering)が用いられうる。一般
に、データに対する検索を最小にするようにパーセルが
オーダされることが好ましい。空間的に編成されたパー
セルをオーダする一つの方法は、各データのタイプ内の
ｋＤ−ツリー・インデックスからの深さ優先オーダリン
グを用いることである。これは、ペアノ−キー(Peano-k
ey)・オーダリングと同様なオーダリングを供給する。
パーセルは、この近似ペアノ・キー・オーダにおいてデ
ィスク（即ち、図１及び２の媒体３２）に記憶されう
る。空間的にパーセルをアクセスするためにｋＤ−ツリ
ーのような、一つ以上のインデックスを用いることがで
きる。このインデックスは、ナビゲーション・システム
のプログラムが現在の車両のポジションに対応している
データに最初設置される場合のような、任意のポジショ
ンの初期ロケーションに対して有用である。パーセルが
オーダされると、それぞれは、また、固有のパーセル識
別子（例えば、“パーセルＩＤ”が割り当てられる。パ
ーセルＩＤは、パーセル及び／又は媒体上のパーセルの
ロケーションを識別するために用いられうる。

【００５８】上記したように、ある種のデータは、空間
的に編成されない（即ち、非空間的に編成されたデータ
の各パーセルは、図５の矩形地域１１９のいずれかに対
応する必要はない）。例えば、ストリートのネーム（即
ち、図３のネーム・データ６０）を表すデータは、空間
的の代わりにアルファベット順に編成されうる。国、
州、市、等のような行政的または政治的エンティティを
表すデータは、空間的に編成されない他の種類のデータ
である。例えば、行政的または政治的エンティティを表
すデータは、行政的権力層(administrative hierarchy)
によって編成されうる。本実施例において、これらの非
空間的に編成されるデータのタイプは、同様にパーセラ
イズされる。

【００５９】ＩＩＩ． データ・アクセス・レイヤー Ａ．概要 図２に関して上記したように、ナビゲーション・システ
ム・プログラミング１８は、ナビゲーション・アプリケ
ーション２８に対して地図データ４０をアクセスするこ
とを供給するデータ・アクセス・レイヤー３９を含む。
上述したように、地図データベース４２のデータ４０
は、種々のナビゲーション・アプリケーション２８によ
るそれらの使用を容易にするために媒体３２上で圧縮さ
れ、配列（アレンジメント）され、編成され、パーセラ
イズされ、かつインデックスされうる。データ・アクセ
ス・レイヤー３９は、ナビゲーション・アプリケーショ
ン２８による使用のためのデータを戻すために記憶媒体
３２の地図データベース４２の編成及び配列を取り扱
う。

【００６０】データ・アクセス・レイヤー３９は、ナビ
ゲーション・アプリケーション２８と地図データベース
４２との間に論理的に設置（位置決め）される。一実施
例において、データ・アクセス・レイヤー３９及びナビ
ゲーション・アプリケーション・プログラム２８は、他
のタイプのコンパイレーション及び／又は配列を用いう
るけれども、一つの実行可能なモジュールを形成するた
めに一緒にコンパイルされる。

【００６１】図７を参照すると、データ・アクセス・レ
イヤー３９は、幾つかのサブシステム・コンポーネント
で構成されている。図７において、データ・アクセス・
レイヤー３９は、演繹データベース・エンジン２００、
アプリケーション・インタフェース２２０、問合せ検証
(query validation)システム２４０、インデックス・ア
クセス・システム２６０、物理的から論理的への変換(p
hysical-to-logical conversion)システム２８０、及び
カーソル管理システム２９０を含む。これらのサブシス
テム・コンポーネントのそれぞれは、ある一定の機能を
実施するプログラミングで構成されている。これらのサ
ブシステム・コンポーネント間に内部インタフェースが
存在する。これらのコンポーネントのそれぞれを以下に
詳述する。

【００６２】（本実施例のデータ・アクセス・レイヤー
３９は、全体の開示がここに採り入れられる１８８６
（１９８６）年１０月２５日に出願された米国特許出願
第０８／７４０、２９８号に開示されたデータ・アクセ
ス・レイヤーと同様である。本実施例のデータ・アクセ
ス・レイヤー３９が米国特許出願第０８／７４０、２９
８号に開示されたデータ・アクセス・レイヤーとは異な
る方法がここに開示されている。これらの相違を除き、
本実施例のデータ・アクセス・レイヤー３９は、米国特
許出願第０８／７４０、２９８号に開示されたデータ・
アクセス・レイヤーと同様でありうる。） Ｂ．データベースに記憶されるロジック・ルール（論理
規則） 図７は、ロジック・ルール（論理規則）３００を示す。
ロジック・ルール３００は、地図データベース４２に関
連付けられる。ロジック・ルール３００は、データ・ア
クセス・レイヤー３９に一部ではない。図７に示すよう
に、ロジック・ルール３００は、媒体３２の地図データ
ベース４２に記憶される。代替実施例では、ロジック・
ルール３００は、以下に説明するように、それ以外に記
憶されうる。

【００６３】図８は、幾つかのロジック・ルール３００
のコンポーネントを示す。各ロジック・ルール３００
は、ヘッド３０６及びボディー３０８により構成されて
いる。ロジック・ルール３００のヘッド３０６は、一つ
以上のステートメント（文）を含む。各ステートメント
は、一つ以上の変数を含みうる。定数は、変数に対して
置換えることができる。変数は、あらゆる値を取ること
ができるということを意味する“自由変数”でありう
る。

【００６４】各ステートメントは、真であるか又は真で
ないかのいずれかを評価することができる。ルールのヘ
ッド３０６内のステートメントは、論理関係オペレーシ
ョン（例えば、“アンド(and)”、“オア(or)”、“ノ
ット(not)”、等）と組合される。

【００６５】各ステートメントは、地図データベースの
データ又はナビゲーション・システムの状態のいずれか
に関する。データベース４２からのデータ４０に関する
ステートメントは本質的(intrinsic)であり、かつナビ
ゲーション・システムに関するステートメントは付帯的
(extrinsic)である。ナビゲーション・システムの“状
態”は、他のロジック・ルールの先に実行及びデータベ
ースのデータによって決定されるようなナビゲーション
・システムの現在のしかし変更可能な状態を表す。

【００６６】各ロジック・ルール３００のボディー３０
８は、取るべき一つ以上のアクション（動作）を特定す
る。アクションは、（物理的から論理的へのシステム２
８０、インデックス・アクセス・システム２６０、又は
検証システム２４０における機能のような）機能への呼
出し（コール）でありうる。また、ロジック・ルールの
ボディーにおいて特定されたアクションは、ナビゲーシ
ョン・システムの状態を設定または変更することができ
る。

【００６７】ロジック・ルール３００は、媒体３２で圧
縮されうる。ロジック・ルール３００は、演繹データベ
ース・エンジン２００によるルールの使用及びアクセス
を容易にするように編成されうる。

【００６８】Ｃ． 演繹データベース・エンジン 再び図７を参照すると、演繹データベース・エンジン２
００は、地図データベース４２に含まれるデータ４０を
アクセスし及び／又は用いる方法を決定するために地図
データベース４２に関連付けられたロジック・ルール３
００を用いる。

【００６９】図９は、演繹データベース・エンジン２０
０の実行サイクル４００で実行される段階を示す。演繹
データベース・エンジン２００の実行サイクル４００
は、ナビゲーション・システムのオペレーションの間
中、連続的にループする。

【００７０】演繹データベース・エンジン２００内で
は、処理４０２は、ルール・ベース４０６を形成（及び
更新）する。システムの動作（挙動）を支配している全
てのルールは、ナビゲーション・システムのある状態に
適するルールを迅速に見付けるためにメカニズムと一緒
にグループにされ、ルールのグループは、“ルール・ベ
ース”と呼ばれる。ルール・ベースは、動的一時構造で
ある。ルール・ベース４０６を形成することにおいて、
処理４０２は、必要な程度まで、媒体３２からロジック
・ルール３００を読み出し、地図データベース４２から
データ４０を取得し、かつナビゲーション・システムの
状態に関する他のデータ４０３を取得する段階を含む。
これらのルール及びデータを用いて、処理４０３は、ル
ール・ベース４０６を構成するルールを形成する。媒体
３２に記憶される全てのロジック・ルールは、演繹デー
タベース・エンジン２００に対して利用可能である。し
かしながら、処理４０２は、媒体３２からのロジック・
ルール３００のどれをルール・ベース４０６に含むべき
かを決定する。媒体３２からのロジック・ルール３００
の全てをルール・ベース４０６に含むことを必要としな
い。

【００７１】ルール・ベース４０６に含まれるルールの
あるものは、個別のロジック・ルールからのステートメ
ントを組合せることによって形成されうる。ステートメ
ントを組合せる処理は、全ての述語がデータベースのエ
レメント（構成要素）を参照するまでルールのステート
メントをより簡単なステートメントで置き換える。ステ
ートメント組合せ処理は、ルール・ベース形成処理の内
部部分（例えば、図９の４０２において示すような）に
よって実行されうる。代替的に、ステートメント組合せ
処理は、演繹データベース・エンジン実行サイクルによ
って実行されうる（例えば、ステップ４０２−４２
０）。

【００７２】演繹データベース・エンジンの実行サイク
ル中に新しいルールをルール・ベースに追加することが
できる。また、演繹データベース・エンジンの実行サイ
クル中にルール・ベースからルールを削除することがで
きる。

【００７３】一度ルール・ベース４０６を形成する全て
のルールが決定されたならば、演繹データベース・エン
ジン３００の処理４０８は、ルール・ベース４０６から
のどのルールが満たされているか、即ち、ロジック・ル
ールのヘッド３０６において特定された事前条件（プレ
コンディション）が“真”であるかを決定する。一つの
サイクルにおいて実行が可能な幾らかのルールが存在し
うる。（ルール・ベース４０６からの）ルールのヘッド
が論理的に真なステートメントである場合には、そのル
ールが実行されうるルールのリストに追加される。満た
された（ルール・ベース４−６からの）このルールのセ
ットは、候補リスト４１２を形成する。（候補リストの
このルールのセットは、演繹データベース・エンジンの
各実行サイクルに対して形成（又は更新）される。） 候補リスト４１２のロジック・ルールで、演繹データベ
ース・エンジン３００の別の処理４１４は、候補リスト
４１２からどの一つのロジック・ルールを実行すべきか
を決定する。どのルールを“ファイヤー”（即ち、実
行）すべきかの選択は、どのように特定的にルールが現
在の状態に適用されるか、どのくらいルールが重要であ
るかが宣言され、どのくらい最近にルールが以前ファイ
ヤーされたか、等のような、候補ルールに関する情報を
考慮することによってなされる。これは、ルールのオー
ダリングによって又はあるタイプのルールを他のものよ
りも優先する演繹データベース・エンジンの構成（即
ち、より多くのルール）によって決定することができ
る。

【００７４】候補リスト４１２の中からどのルールをフ
ァイヤするかを決定した後、演繹データベース・エンジ
ン２００は、ルールのボディー３０８で特定されたアク
ションを実行する処理４２０を含む。ボディー３０８で
特定されたアクションは、物理的から論理的への変換シ
ステム２８０、インデックス・アクセス・システム２６
０、又は検証システム２４０におけるルーチンを参照す
ることができる。また、アクション３０８は、状態の変
更を特定することもできる。ボディー３０８で特定され
たアクションが物理的から論理的への変換システム２８
０、インデックス・アクセス・システム２６０、又は検
証システム２４０におけるルーチンを参照するならば、
ルーチンが呼び出されかつ実行される。ルーチンが実行
された後、ルーチンは、演繹データベース・エンジン２
００へ戻りかつ演繹データベース・エンジン２００のオ
ペレーションは、ステップ４０２へ折り返す（ループ・
バック）ことによって継続する。ボディー３０８におい
て特定されたアクションが状態の変更のためであるなら
ば、状態が変更されかつ（状態変数４０６に）保管され
そして演繹データベース・エンジン２００のオペレーシ
ョンは、ステップ４０２へ折り返す（ループ・バック）
ことによって継続する。

【００７５】演繹データベース・エンジン２００のオペ
レーションは、このように継続する。

【００７６】Ｄ．ルールとしてのデータの処理 演繹データ・モデルでは、データベース４２のデータの
各行（ロー）（即ち、各“記録”）は、ナビゲーション
・システムの状態の一部と考えられる。そこで、各行
は、データ・テーブルにおける列（カラム）と同じ位多
くの部分を含むロジック・ステートメントであると考え
られる。例えば、レストラン及びそれらのロケーション
の表は、“ネーム”、“料理”、“緯度”、“経度”、
“番地”、及び“ブロック”の列（カラム）（即ち、
“フィールド”）を有しうる。この例では、“ブロッ
ク”は、ストリート・ネーム及びシティーを含む記録の
表への行番号である。ルートとして処理された、レスト
ラン表の行は、“ネーム”が“New China Restaurant
（ニュー・チャイナ・レストラン）”に等しくかつ“Cu
isine（料理）”が“Chinese（中国料理）”に等しく
“緯度”が“ｎｎｎ’ｍｍｍ”に等しくかつ“経度”が
“ｑｑｑ’ｒｒｒ”に等しくかつ“番地”が“１１８
５”に等しくかつ“ブロック”が“２３４５”に等しい
ようになる。データベースの演繹問合わせは、ルールの
ボディーがシステムの状態を変更することができるよう
にルールのヘッドに“真”であると考慮させるデータに
対する検索として処理される。行がルールのヘッドを
‘真’にさせるように検索される場合には、行の全ての
列（カラム）値は、システム状態を変更するためにルー
ルのボディーに利用可能である。

【００７７】一度行が検索されたならば、それは、別の
行がファイヤするまでそれを検索したルールをファイヤ
する権利がない。そこで、全ての中国料理レストランを
検索する問合せは、“Restaurant.Cuisine = 'Chinese'
and Block.BlockID = Restaurant.Block = > print(Re
staurant.Name, Restaurant.AddressNumber, Block.Str
eetName, Block.City)”のようになる。選択されたデー
タを含むデータベースの行が再びファイヤすることを許
されていないので、このルールは、レストラン表の中国
料理レストラン毎に一度ファイヤされる。

【００７８】データベースのインデックス（例えば、図
３のインデックス６６）は、まったくデータのように処
理されかつ同じルール及び問合わせエンジンで問合せさ
れる。

【００７９】リレーショナル・データベースに対する演
繹データベースの利点は、列が簡単なタイプとしてでは
なくセットの構成要素（エレメント）として規定される
ということである。レストラン表のブロック列(Restaur
ant table's Block column)は、を別の表のＩＤである
よりもブロック・データ(Block data)のセット全体を含
みうる。

【００８０】Ｅ.アプリケーション・インタフェース 図７を再び参照すると、アプリケーション・インタフェ
ース２２０は、ナビゲーション・アプリケーション２８
とインタフェースする。アプリケーション・インタフェ
ース２２０は、ナビゲーション・アプリケーション２８
からの地図的参照データ(geographically-referenced d
ata)に対するリクエストを受け入れかつリクエストに対
して応答を供給する。アプリケーション・インタフェー
ス２２０は、ナビゲーション・アプリケーション２８に
機能呼出しインタフェース(function call interface)
を供給する。機能呼出しインタフェースは、ナビゲーシ
ョン・アプリケーション・プログラム２８に対する記憶
媒体３２の地図データのデータ構造ビュー（“ロジカル
・データ・モデル”又は“ＬＤＭ”と称する）を規定す
る。ロジカル・データ・モデルは、相互参照することな
く完全に圧縮解除された形式のデータ又はデータを用い
ることができる前に処理を必要とする他のタイプの情報
を表す。一実施例において、アプリケーション・インタ
フェース２２０によって規定されるデータ構造ビュー
は、Ｃ言語である。

【００８１】Ｆ．問合せ検証システム 上記したように、データ・アクセス・レイヤー・コンポ
ーネント３９は、データ検証システム２４０を含む。デ
ータ検証システム２４０は、ナビゲーション・アプリケ
ーション２８からアプリケーション・インタフェース２
２０によって受取ったリクエストをチェックする。問合
せ検証システム２４０は、ナビゲーション・アプリケー
ション２８からの地図的参照データ・リクエストが有効
かどうかを決定することをチェックする。機能２４０
は、それによってデータに対する有効リクエストを決定
することができるデータを受取る。機能は、演繹データ
ベース・エンジン２００からこれらのデータを受取る。
演繹データベース・エンジンがオペレーションを開始す
る場合には、それは、その目的のために設計された一組
のロジック・ルールを用いて初期化される。これらの初
期化ロジック・ルールは、媒体に存在するデータ及びイ
ンデックスのタイプを識別しかつ結果としてどのような
タイプの問合せがサポートされるを識別する。これらの
初期化ロジック・ルールを用いて、サポートされる問合
せおよびデータ・タイプの表を準備することができる。
この表は、地図的参照データに対するリクエストがナビ
ゲーション・アプリケーション２８によってリクエスト
される場合に問合せ検証システムによって用いられる。

【００８２】Ｇ．インデックス・アクセス・システム インデックス・アクセス・システム２６０は、データ・
アクセス・レイヤー３９の一部である。インデックス・
アクセス・システム２６０は、媒体３２の地図データベ
ース４２のインデックス６６をアクセスしかつ用いるた
めのデータ検索ルーチン２６２を含む。インデックス６
６は、アプリケーション・インタフェース２２０によっ
て受取った地図的参照データに対するリクエストを満た
すために媒体に記憶されたデータを探し出すために用い
られる。インデックス６６は、媒体の一つ以上のどのパ
ーセルが地図的参照データに対するリクエストに応答す
るために必要なデータを含むかを識別するために用いら
れうる。これは、所望のデータのパーセルが媒体に配置
（設置）されるアドレス・ロケーション又はファイル・
オフセットの識別を含みうる。また、インデックス６６
は、各パーセル内の所望のデータのロケーションを決定
するために用いられうる。

【００８３】上記したように、インデックスは、ルール
・ベース４０６の別のルールになりかつ更なるメカニズ
ムなしでそれに対してマッチ（整合）される。問合せに
おけるターム（用語）としてインデックスを用いる方法
を示すルール・ベースにロジック・ステートメントを加
えることによってインデックスをアコモデートすること
ができる。

【００８４】データ検索ルーチン２６２は、低レベル・
データ・アクセス・プリミティブとして作用（動作）す
る。インデックス・アクセス・レイヤー２６０のデータ
検索ルーチン２６２は、一般的である、即ち、それら
は、データベース４２又はインデックス６６に対して特
定されない。その代わり、媒体のインデックス６６のロ
ケーション、インデックスのタイプ、インデックスによ
って関連するデータのタイプ、インデックス・キー、等
は、インデックス・アクセス・システム２６０のデータ
検索ルーチン２６２が演繹データベース・エンジン２０
０によって呼び出される場合に含まれるパラメータによ
って特定される。演繹データベース・エンジン２００
は、上述したように、ロジック・ルール３００を読み出
しかつ組合せることによってインデックス・アクセス・
システムのデータ検索ルーチン２６２を呼び出す場合に
用いられるパラメータをフォーミュレート（公式化）す
る。

【００８５】Ｈ．物理的から論理的への変換 物理的から論理的への変換システム２８０は、データ・
アクセス・レイヤー３９の別の部分である。物理的から
論理的への変換システム２８０は、それら（データ）が
媒体に記憶されるフォーマットからナビゲーション・ア
プリケーションがそれら（データ）を用いることができ
るようなフォーマット（例えば、論理的データ・モデル
・フォーマット）にデータを変換するためのデータ検索
ルーチン２８２を含む。インデックス・アクセス・シス
テム２６０のデータ検索ルーチン２６２のように、物理
的から論理的への変換システム２８０のデータ検索ルー
チン２８２は、低レベル・データ・アクセス・プリミテ
ィブとして動作（作用）する。物理的から論理的への変
換システム２８０のデータ検索ルーチン２８２は、一般
的である、即ち、それらは、データベース４２のデータ
のタイプに特定されない。その代わり、記録のサイズ、
記録のロケーション、相互参照情報、必要な解凍及び／
又はアンパッキング、等は、データ検索ルーチン２８２
が演繹データベース・エンジン２００によって呼び出さ
れる場合に含まれるパラメータによって特定される。演
繹データベース・エンジン２００は、ロジック・ルール
３００を読み出しかつ組合せることによってデータ検索
ルーチン２８２を呼び出す場合に用いられるパラメータ
をフォーミュレート（公式化）する。

【００８６】Ｉ．カーソル カーソル管理システム２９０は、データ・アクセス・レ
イヤー３９の一部である。ナビゲーション・アプリケー
ション２８からの地図的参照データに対するあるリクエ
ストは、多重データ・エンティティを含む応答を結果と
してもたらすことが期待される。例えば、特定の境界を
示す矩形地域内の道路を表している全てのカートグラフ
ィック・データ記録に対するリクエストは、数百の（多
くの）データ記録を含みうる。カーソル管理システム２
９０は、多重記録を含むナビゲーション・アプリケーシ
ョン２８への応答を取り扱うことを供給する。

【００８７】演繹データベース・エンジンの一実施例に
おいて、結果が得られかつ一度に一つの処理がなされ
る。地図データベースのデータの問合せは、演繹データ
ベース・エンジン２００によるロジック・ルール３００
の実行によって呼び出されるインデックス・アクセス管
理システム２６０のルーチン２６２によって実行され
る。問合せは、問合せを規定するロジック・ルールによ
って命令（口述）されるように、地図データベースのデ
ータの全て又は一部で実行されうる。データ記録のセッ
ト内には、問合せを満たすセットの第１の記録は、物理
的から論理的への変換システム２８０の適当なルーチン
２８２を用いて処理される。演繹データベース・エンジ
ンによって実行される別のロジック・ルールは、第１の
記録が問合せを満たすことが見出された後に、問合せ
は、問合せを満たすセットにおける次の記録を見出す、
等、もはや問合せを満たすセットにおいて記録が見出さ
れなくなるまでその地点からセットにおいてフォワード
に継続するように、“GetNext”オペレーションを実行
する。

【００８８】カーソル管理システム２９０は、バッファ
リング及びゲートキーピング機能を実行する。カーソル
管理システム２９０は、多重記録を含むナビゲーション
・アプリケーション２８への応答を取り扱う。結果のセ
ットが大きい場合には、カーソル管理システム２９０
は、ナビゲーション・アプリケーションがキャッチ・ア
ップできるまで演繹データベース・エンジンにより“Ge
tNext”オペレーションを一時的に停止することができ
る。また、カーソル管理システム２９０は、メモリ・バ
ッファに多重結果を一時的に記憶することができる。 ＩＶ．アプリケーション Ａ．更新データを供給すること 図１０は、ナビゲーション・システムに新しいデータを
供給できる方法を示す。図１０は、図１に関して説明さ
れた同じナビゲーション・システム１０を示す。ナビゲ
ーション・システム１０は、図７〜図９に関して上述し
たように、演繹データベース・エンジン２００を有する
データ・アクセス・レイヤー３９を含んでいるナビゲー
ション・システム・プログラミング１８を含む。図１０
において、先の地図データベース（例えば、図７の４
２）は、新しい地図データベース５４２（例えば、バー
ジョン２．０）で置き換えられている。新しい地図デー
タベース５４２は、新しい媒体５３２に記憶されるか、
または代替的に、新しい地図データベース５４２は、新
しい地図データ５４０を含む。新しい地図データ５４０
は、先の地図データ４０と同じ地図網羅地域に関する。
代替的に、新しい地図データ５４０は、異なる地図網羅
地域に関しうる。

【００８９】新しい地図データベース５４２は、新しい
タイプのデータを含みうる。例えば、地図データベース
４２の先のバージョンは興味のある地点の電話番号を示
すデータ含んでいたが、新しい地図データベース５４２
は、また、興味のある地点のファックス番号、電子メー
ル・アドレス及びウェブ・アドレスを示すデータを含
む。更に、新しい地図データベース５４２は、また、古
い及び新しいタイプのデータを相互参照するために用い
ることができる新しいインデックス５６６を含む（例え
ば、そこで興味のある地点を、そのファックス、電子メ
ール、及びウェブ・アドレスによって見出すことができ
るし、その逆もできる）。

【００９０】新しい地図データベース５４２の新しい地
図データ５４０及びインデックス５６６に関連付けられ
るものは、新しいロジック・ルール５５０である。新し
いロジック・ルール５５０は、新しい地図データベース
５４２と同じ媒体５３２に配置（設置）されるかまたは
代替的に、新しいロジック・ルール５５０は、異なる媒
体に配置されうる。

【００９１】新しいロジック・ルール５５０は、上述し
た先のロジック・ルール３００と同じ構造を有する。従
って、各新しいロジック・ルール５５０は、先のロジッ
ク・ルール２００のように演繹データベース・エンジン
２００によって同じように処理することができる。新し
いロジック・ルール５５０は、新しいデータベース５４
０のデータ５４０及びインデックス５６６に関する。従
って、新しいロジック・ルール５５０は、新しい地図デ
ータベース５４２に含まれる新しいタイプのデータ、デ
ータ記憶される媒体５３２の新しいロケーション、先の
タイプのデータ又は新しいタイプのデータのいずれかに
関する新しいインデックス、等を説明する。例えば、媒
体の興味がある地点のデータ記録のロケーションが変わ
ったならば（例えば、興味がある地点のデータがより多
く記憶されるので）、媒体上の新しいロケーションは、
ロジック・ルール５５０によって特定される。そこで、
演繹データベース・エンジン２００が興味がある地点に
対する問合せに対して応答するためのデータを取得する
ために動作される場合には、それは、媒体上の興味があ
る地点のデータを探し出すために新しいロジック・ルー
ルを用いる。

【００９２】また、新しいロジック・ルール５５０は、
新しい表を追加することを説明する。新しい表を追加す
ることは、表に対するデータを追加すること及び表が既
存のデータに接続する方法を示しているロジック・ルー
ルのステートメントを追加することから構成される。既
存の演繹データベース・エンジン２００は、データを検
索する場合に新しいロジック・ルールのこれらの新しい
ステートメントをアクセスする。

【００９３】データ・アクセス・レイヤー３９に含まれ
る演繹データベース・エンジン２００は、フォワード互
換性を供給する。演繹データベース・エンジンを含むデ
ータ・アクセス・レイヤーを有しているナビゲーション
・システムは、ここの説明するように、更新された地図
データ並びに新しいタイプのデータの両方を含む地図デ
ータベースの新しいリリースをアクセスしかつ用いるこ
とができる。これは、地図データベースの同じ新しい、
更新されたバージョンを新しい及び古いナビゲーション
・システムの両方で供給しかつ用いることができるとい
う利点を供給する。

【００９４】演繹データベース・エンジンを含むデータ
・アクセス・レイヤーは、また、バックワード互換性を
供給することができる。データ・アクセス・レイヤーの
演繹データベース・エンジンにより、新しいナビゲーシ
ョン・システムは、古いバージョンの地図データを用い
ることができる。これは、ナビゲーション・システム製
造業者が、データが利用可能である前に新しいタイプの
データを用いるシステムを設計することができるという
利点を供給する。これらのナビゲーション・システム
は、新しいタイプのデータを含む新しいバージョンの地
図データベースが利用可能になるまで現在利用可能なバ
ージョンの地図データベースで実行することができる。
新しいタイプのデータを有する新しいバージョンの地図
データベースが利用可能になった場合には、新しいバー
ジョンの地図データベースをナビゲーション・システム
に取付けることができ、次いでそれ（ナビゲーション・
システム）は、新しい種類のサービスを供給するために
新しいタイプのデータを用いることができる。

【００９５】Ｂ．オン・ボード及びオフ・ボード・デー
タを組合せること 図１１は、車両ナビゲーション・システムに、オフ・ボ
ード・データ・サプライヤから供給される更なるデータ
と組合せて車両にオン・ボード配置（搭載）された地図
データベースを用いらせることができる手段を示す。オ
フ・ボード・データをアクセスしかつ用いることは、車
両ナビゲーション・システムのデータ・アクセス・レイ
ヤーに配置される演繹データベース・エンジンにより処
理されるロジック・ルールによって可能になる。

【００９６】図１１において、車両ナビゲーション・シ
ステム６００及び遠隔データ・サプライヤ６１０は、地
図領域６１３に設置される。領域６１３は、メトロポリ
タン・エリア、州、プロビンス、国、又は一つ以上のメ
トロポリタン・エリア、州、国、等の組合せでありう
る。図１１に示すシステムにおいて、多くの車両及び多
くの遠隔データ・サプライヤが存在しうるということが
理解されるけれども、一つの車両及び一つの遠隔データ
・サプライヤだけが示されている。図１１のナビゲーシ
ョン・システム６００は、図１に関して説明したナビゲ
ーション・システム１０と同様であり、同じコンポーネ
ントは、同じ参照番号によって識別される。図１１のナ
ビゲーション・システム６００は、図７〜図９に関して
上述したように演繹データベース・エンジン２００を有
するデータ・アクセス・レイヤー３９を含んでいるナビ
ゲーション・システム・プログラミング１８を含む。ナ
ビゲーション・システム６００は、上述したように、デ
ータ４０、インデックス６６及びロジック・ルール３０
０を含む地図データベース４２を用いる。地図データベ
ース４２は、ナビゲーション・システム６００に設置さ
れる、例えば、車両１０のナビゲーション・システム６
００にローカル的に取付けられた、媒体３２に記憶され
る。

【００９７】図１１において、ナビゲーション・システ
ム６００は、それによってナビゲーション・システム６
００が遠隔データ・サプライヤ６１０と無線で通信しか
つデータを交換することができる、受信機、送信機、等
のような、通信ハードウェア及びソフトウェア６１１を
含む。セルラー、無線、衛星、ＰＣＳ／ＧＳＭ、等を含
んでいる、あらゆるタイプの無線通信技術が適する。図
１１の実施例において、データ・アクセス・レイヤー３
９は、それによって演繹データベース・エンジン２００
が補助データ・サプライヤ６１０にデータを送りかつそ
れからデータを受取るために通信ハードウェア及びソフ
トウェア６１１とインタフェースすることができる手段
を供給する機能６４１を含む。

【００９８】補助データ・サプライヤ６１０は、補助デ
ータ６４０を含む。補助データ６４０は、車両１０から
遠隔のロケーションにある媒体６３２に記憶される。補
助データ・サプライヤ６１０は、また、補助インデック
ス６６６及び補助ロジック・ルール６５０を含む。補助
インデックス６６６及び補助ロジック・ルール６５０
は、補助データ６４０と一緒に記憶されるうか又はそれ
以外に記憶されうる。

【００９９】補助データ・サプライヤ６１０は、また、
それによって補助データ・サプライヤ６１０がナビゲー
ション・システム６００と通信しかつデータを交換する
通信ハードウェア及びソフトウェア６５８を含む。補助
データ・サプライヤ６１０は、また、データ・フルフィ
ルメント・プログラム６７５を含む。

【０１００】車両ナビゲーション・システムがオフ・ボ
ード・データ・サプライヤによって供給されるデータを
アクセスしかつ用いることができる方法は、以下の例に
おいて説明される。

【０１０１】例１ 図１１の実施例を用いて、ナビゲーション関連機能が供
給されている場合に車両に供給されるナビゲーション機
能が補助データを考慮することができるように車両にロ
ーカル的に存在しない補助データを車両のナビゲーショ
ン・システムに利用可能にすることができる。

【０１０２】ナビゲーション・システム６００のオペレ
ーション中、車両のロジック・ルール３００は、補助デ
ータ・リクエスト・プログラム６４１のルーチンを呼び
出すように実行される。補助データ・リクエスト・プロ
グラム６４１のこのルーチンは、補助データが利用可能
であるかどうかを決定し、もしそれらが利用可能であれ
ば、補助データを取得すべく車両の通信ハードウェア及
びソフトウェア６１１を介してリクエストを送る。この
ロジック・ルールは、それがスタート・アップにより処
理されかつ車両がオペレートされている間に潜在的に時
間に応じて処理されるように書かれている。

【０１０３】データ・リクエスト・プログラム６４１か
らのリクエストに応じて、遠隔データ・サプライヤ６１
０は、応答を送る。遠隔データ・サプライヤ６１０から
車両１０への応答は、ロジック・ルール６７０を含む。
ダウンロードされたロジック・ルール６７０は、データ
のシームレス統合のために車両にオン・ボード配置され
たロジック・ルール３００に結合される変数を含みう
る。ダウンロードされたロジック・ルール６７０は、一
時データ記憶装置６７７に車両にローカル的に記憶され
る。車両慮に設置された演繹データベース・エンジン２
００は、ローカル的に既に記憶されたロジック・ルール
３００を取り扱うのと同じ方法でダウンロードされたロ
ジック・ルール６７０を取り扱う。ダウンロードされた
ロジック・ルール６７０は、演繹データベース・エンジ
ン２００によって実行される全てのルールのセット（例
えば、ルール・ベース）に追加される。ダウンロードさ
れたロジック・ルール６７は、ある一定のタイプのリク
エストの処理中にそれらがまず実行されるように書かれ
うる。

【０１０４】例として、車両１０にローカル的に存在す
るデータ４０が所与の地図エリアにおける全てのレスト
ランに対するリスティング（作表）を含むと想定する。
この例によれば、遠隔データ・サプライヤ６１０は、あ
る一定のクレジット・カード保持者に対してディスカウ
ントを供給するビジネス（レストランを含む）をリスト
する補助データベース６４２において利用可能なデータ
を有する。ナビゲーション・システム６００のユーザ
は、クレジット・カード保持者に対してディスカウント
を供給する現在の車両ポジションの近くにあるレストラ
ンを検索することを欲する。ユーザは、（図１に示し
た）ユーザ・インタフェースを介してナビゲーション・
システム６００に彼／彼女のリクエストを入力する。ナ
ビゲーション・アプリケーション２８の機能は、データ
・アクセス・レイヤー３９を呼び出す。演繹データベー
ス・エンジン２００がレストランを見付けるためにロジ
ック・ルールを処理する場合、ダウンロードされたロジ
ック・ルールをまず処理してクレジット・カード保持者
に対するディスカウントについてのデータが利用可能で
あるということを示す。ダウンロードされたロジック・
ルールは、クレジット・カード保持者に対してディスカ
ウントを供給するユーザの現在のロケーションに近いユ
ーザによってリクエストされたタイプのビジネス（即
ち、レストラン）にに関するデータを取得するためにデ
ータ・リクエスト・アプリケーション６４１のルーチン
を呼び出す。リクエストは、データ・フルフィルメント
・プログラム６７５がクレジット・カード・ユーザに対
してディスカウントを供給するユーザのロケーションに
近いレストランに関するデータを取得するような遠隔デ
ータ・サプライヤ６１０に車両１０の通信装置６１１を
介して送信される。これらのデータは、通信装置６５８
及び６１１を介して遠隔データ・サプライヤ６１０から
エンド・ユーザの車両１０に送信される。これらのデー
タは、車両１０において受信されかつ一時データ記憶装
置６７７に記憶される。これらのダウンロードされたデ
ータは、車両において既に利用可能なロジック・ルール
３３並びにダウンロードされたロジック・ルール６７０
を用いて演繹データベース・エンジン２００によってア
クセスされかつ用いられる。

【０１０５】例２ 別の例によれば、図１１に示すシステム６００のよう
な、車両搭載ナビゲーション・システムは、オフ・ボー
ド・データ・サプライヤから供給される交通関連データ
を取得しかつ用いることができる。交通関連データは、
先の例で説明したものと同様な方法で供給することがで
きる。

【０１０６】交通関連データの場合には、遠隔データ・
サプライヤ６２０は、車両１０が配置されるような地域
６１３における交通及び道路条件（状態）に関係するデ
ータを取得しかつ供給する。遠隔データ・サプライヤ６
１０（又は別のエンティティ）は、交通及び道路条件デ
ータを収集し、アセンブルし、編成し、分析しかつフォ
ーマットするための装置及びプログラミングを有する。
交通及び道路条件（状態）データは、一つ以上の適当な
所定のフォーマットで準備される。一実施例において、
代替システム及び／又はプロトコルを用いることができ
るけれども、交通関連データは、ＲＤＳ−ＴＭＣシステ
ムにおいて設定されたＡＬＥＲＴ−Ｃメッセージに対す
る標準フォーマットに従う。

【０１０７】交通関連データの場合には、車両のロジッ
ク・ルールは、交通関連データを取得すべきことをリク
エストするとき及び取得すべき交通関連データの種類を
決定する。例えば、車両のロジック・ルールは、交通に
よって影響を受けうるナビゲーション機能が実行される
ようになっているときにだけ交通関連データに対するリ
クエストを開始しうる。例えば、ユーザが特定されたロ
ケーションまでのルートを計算することをリクエストし
た場合、ロジック・ルールは、ルート計算機能（図２の
３３）が交通条件（状態）に関する最新のデータを考慮
して最も速いルートを決定するように交通関連データに
対するリクエストを開始する。オペレーションの代替方
法によれば、車両のロジック・ルールは、定期的に更新
された交通関連データに対するリクエストを開始しかつ
必要なときにデータが直ぐに利用可能なように一時デー
タ記憶装置６７７に交通関連データを記憶しうる。

【０１０８】車両のロジック・ルールは、ダウンロード
された交通データをナビゲーション・アプリケーション
２８によって用いることができるようなフォーマットに
変換するために適当なルーチンを呼び出す。ダウンロー
ドされた交通データを変換するルーチンは、物理的から
論理的へのシステム２８０又はこの機能を供給する別の
システムに含まれうる。ルーチンは、必要によりデータ
・サプライヤ６１０からダウンロードされうる。

【０１０９】また、ロジック・ルールは、あるタイプの
ナビゲーション関連機能のオペレーション中に最新交通
データが定期的に取得されるように実行されうる。例え
ば、ユーザが所望の目的地に到達するためのルート・ガ
イダンス命令を供給されている間に、ロジック・ルール
は、追従するルートに関する最新交通データをリクエス
トしかつ取得しうる。ルートが開始された後に交通渋滞
が始まったならば、適当であるならば、代替ルートが決
定されうる。

【０１１０】ロジック・ステートメントが小さいので、
このデータ・アクセス・ロジックをダウンロードするこ
とは、容易である。そして、データ（例えば、ある一定
の量よりも少ない交通遅延を有するシカゴの区間を選択
する）を組合せることを必要とするリクエストは、適当
なレポーティング・サービスを選択しかつ問合せに回答
するために必要なデータだけをダウンロードする。

【０１１１】例３ 上述した例におけるように、オフ・ボード・データが車
両ナビゲーション・システムに利用可能になった場合に
は、どのようにオン・ボード・データとオフ・ボード・
データを一緒に用いるかを決定するためにロジック・ル
ールを用いることができる。例として、ロジック・ルー
ルは、遠隔データ・ソースからダウンロードされなけれ
ばならないデータの量を低減するためにローカル的に
（即ち、車両において）利用可能なデータを用いて更な
る処理が実行されるということを供給することができ
る。検索の順番を変えるロジック・ルールは、車両に既
に存在しうる（例えば、図１１のロジック・ルール３０
０）か又は車両のユーザに遠隔データを利用可能にする
ために遠隔データ・プロバイダ６１０からダウンロード
されるロジック・ルールの中にありうる。

【０１１２】例４ 別の例は、特定された矩形内の境界横断(border crossi
ngs)を決定することに関する。先の方法を用いて、矩形
内の全てのＰＯＩを探して境界横断をフィルタすことが
できるか又は境界横断をフィルタしてそして矩形により
フィルタすることができる。別の先の方法によれば境界
ポリラインを選択するために矩形をまず用いそして何も
見つからなかったならば検索を中止する。演繹データベ
ースの実施例により、これらのオプションは、ユーザの
ステートメントからデータ表をアクセスする実行可能な
ステップのセットに問合せを変形するリライティング・
ルール（書換え規則）によって表現される。この例で
は、矩形インデックスがローカルでありかつＰＯＩタイ
プ・データがリモート（遠隔）であるならば、“表１を
アクセスしかつ表２をアクセスするために結果を用いる
ならば、表１はリモートであり、表２をアクセスするた
めに問合わせを書換えかつ表１をアクセスするために結
果を用いる”という結果をもたらすルールが存在しうる
しかつこのルールは、ＰＯＩを検索するものを含む全て
の適用可能な問合せを変更しうる。

【０１１３】上述した例により説明したように、演繹デ
ータベース・エンジンは、オン・ボード計算に基づくオ
フ・ボード・データ選択に対するサポートを供給する。

【０１１４】Ｃ．他のデータ・プロバイダのデータを統
合すること 図１１に関連して、車両のナビゲーション・システムが
オフ・ボード・データ及びオン・ボード・データを組合
せかつ用いる方法を説明した。また、ナビゲーション・
システムは、地図データを車両に設置された更なるデー
タと組合せるために演繹データベース・アーキテクチャ
を用いることができる。これらの更なるデータは、車両
において個別の媒体に設置されうるか又は代替的に、こ
れらの更なるデータは、地図データとして同じ媒体に設
置されうる。これらの更なるタイプのデータは、特別に
向上された特徴に関係しうる。例えば、更なるタイプの
データは、レストラン・レーティング、ビデオ・クリッ
プ、ツーリスト・アトラクション、等に関係しうる。

【０１１５】図１２は、車両ナビゲーション・システム
１０の図を示す。図１２のナビゲーション・システム６
００は、図１に関して説明したナビゲーション・システ
ム１０と同様である。ナビゲーション・システム１０
は、地図データ４０、第１のタイプの補助データ７４０
及び第２のタイプの補助データ８４０を用いる。第１の
タイプの補助データ７４０は、地図データ４０と同じ媒
体３２に設置される。第２のタイプの補助データ８４０
は、第２の媒体８３２に配置される。第１のタイプの補
助データ７４０に関連付けられるものは、インデックス
７６６とロジック・ルール７５０である。第２のタイプ
の補助データ８４０に関連付けられるものは、インデッ
クス８６６とロジック・ルール８５０である。

【０１１６】車両の演繹データベース・エンジン２００
は、地図データ４０及び更なるタイプのデータ７４０及
び８４０をアクセスしかつ用いるためにロジック・ルー
ル３００、７５０、及び８５０を読み出しかつ用いる。
ロジック・ルールは、更なるデータ７５０及び８５０を
地図データ４０に関連付ける方法を決定する。

【０１１７】Ｄ．パーソナル・コンピュータ及びＰＤ
Ａ’ｓのナビゲーション・アプリケーション 上に開示した実施例において、地図データベースに関連
付けられたロジック・ルールを用いた演繹データベース
・エンジンを含んでいるデータ・アクセス・レイヤー
は、ナビゲーション・システムの一部として記述され
た。ロジック・ルールを用いる演繹データベース・エン
ジンを含んでいるデータ・アクセス・レイヤーは、ワー
クステーション、パーソナル・コンピュータ、パーソナ
ル・ディジタル・アシスタント、ネットワーク、ページ
ャ、テレビジョン、無線受信機、電話機、等を含んでい
る、様々な異なる種類のプラットフォームに取付けられ
及び／又は用いられうる。

【０１１８】Ｅ．ナビゲーション・システム構成 異なるナビゲーション・システムは、異なるハードウェ
ア資源、例えば、だいたいメモリ、速い又は遅いプロセ
ッサ、等を有する。ナビゲーション・システムのハード
ウェア資源は、ナビゲーション・システムが地図データ
を用いる方法に影響を及ぼしうる。例えば、ナビゲーシ
ョン・システムは、比較的大量のメモリを有するが、遅
いプロセッサを有しうる。そのようなナビゲーション・
システムでは、大量のデータをキャッシュすることを含
むソフトウェア処理及びアルゴリズムは、多くの計算を
含む処理及びアルゴリズムに対してより良い性能を供給
しうる。ロジック・ルールは、ナビゲーション・システ
ムのデータ・アクセス・レイヤーのソフトウェアがナビ
ゲーション・システムのハードウェア資源を考慮するた
めに地図を用いる方法を調整（チューン）しかつ構成す
るために用いることができる。例えば、ナビゲーション
・システムがより多くのメモリ資源を含むならば、より
多くのデータをキャッシュする処理が用いられる。

【０１１９】ナビゲーション・システムのハードウェア
資源を考慮するロジック・ルールは、ナビゲーション・
システムの一部である個別のメモリ（例えば、ＲＯＭ）
に含まれうる。個別のメモリのロジック・ルールは、個
別のデータ・サプライヤ（例えば、図１１の遠隔データ
・サプライヤ６１０）によって供給されるロジック・ル
ールと同様な方法で演繹データベースによって用いられ
る。演繹データベース・エンジンは、ある一定のデータ
・アクセス機能が実行される方法に影響を及ぼすルーチ
ンを呼び出すか又は情報を変えるために個別のメモリか
らロジック・ルールを読み出しかつ用いる。

【０１２０】代替的実施例において、ナビゲーション・
システムのハードウェア資源を考慮するロジック・ルー
ルは、地図データベースに記憶されるロジック・ルール
の中に含まれうる。ナビゲーション・システムのハード
ウェア資源を考慮するロジック・ルールが地図データベ
ースに記憶されるロジック・ルールの中に含まれるなら
ば、それらは、どの資源が利用可能であるかを決定する
ためにナビゲーション・システムのハードウェアを問合
わせるデータ・アクセス・レイヤーのルーチンを呼び出
す。これらの問合せに対する応答に基づき、データ・ア
クセス機能を実行する場合にナビゲーション・システム
の利用可能なハードウェア資源を考慮する。ロジック・
ルール及び演繹データベース・エンジンを用いて、それ
が設置されているナビゲーション・システムに対してデ
ータ・アクセス・レイヤーを自動的に構成することがで
きる（例えば、プラグ・アンド・プレイ構成）。更に、
新しいハードウェア資源、例えば、より多くのメモリが
追加される場合、ロジック・ルールによって呼び出され
たルーチンは、新しいハードウェアを自動的に検出しか
つ従ってデータ・アクセス機能を変更する。

【０１２１】このコンセプトを更に拡張すると、演繹デ
ータベース・エンジンによって用いられるロジック・ル
ールは、また、データ・アクセス・レイヤーを異なるハ
ードウェア・プラットフォームにポートするために用い
ることもできる。

【０１２２】

【発明の効果】Ｖ．効果 上記したように、演繹データベース・エンジンを含むデ
ータ・アクセス・レイヤーは、フォワード及びバックワ
ード互換性を供給することができかつ 同じ地図デ
ータベースをこれらの異なるプラットフォームで交換可
能に用いらせるように異なるハードウェア・プラットフ
ォームで用いることもできる。

【０１２３】開示した実施例の効果は、ナビゲーション
・システムがあらゆるタイプの地図データベースを用い
ることができるということである。データ・アクセス・
レイヤーは、データベースでもちいるあらゆるインデッ
クスを含んでいる、データベースに含まれたデータをア
クセスし、読み出しかつ用いるための用いられる問合わ
せルーチンをフォーミュレートするためにデータベース
に関連付けられたロジック・ルールを用いる。それによ
ってデータベースがアクセスされる手段をフォーミュレ
ートするためにデータ・アクセス・レイヤーがデータベ
ースに関連付けられたロジック・ルールを用いるので、
（ナビゲーション・システムの見地から）固定されたデ
ータ・タイプを必ずしも必要としない。

【０１２４】上述したことからの一つの効果は、パーセ
ライゼーション技術を制限することなく地図データをパ
ーセライズすることができるということである。適切な
データだけがアクセスされるようにどのパーセルを検索
すべきかを示すためにロジック・ルールを用いることが
できる。別の効果は、新しいデータ・タイプ又は表を容
易に追加できるということである。新しいデータ・タイ
プ又は表を追加するために、新しいデータ・タイプ又は
表を参照する新しいロジック・ルールがデータベースに
関連付けられる。

【０１２５】別の効果は、演繹データベース・エンジン
のオペレーションを並列処理に適応することができると
いうことである。ロジック・ステートメントの処理は、
必要に応じて組合される並列オペレーションの結果と並
列で（特定の依存性が存在しない限り）行うことができ
る。例えば、データ検索処理は、問合わせに対して応答
することが必要なデータを含んでいる全てのパーセルを
まず検索しそして、ならば、一つよりも多くのパーセル
が検索されるならば、並列オペレーションが各パーセル
で実行されるようにフォーミュレートすることができ
る。そして、全ての並列オペレーションが実行された
後、結果が組合される。

【０１２６】上述した実施例は、システムの組込まれた
部分を形成するデータベースに対して特定の効果を供給
する。ナビゲーション・システムで用いられる地図デー
タベースは、そのようなシステムの一例である。それは
低レベルのディテール(例えば、行アクセス、インデッ
クス・ナビゲーション、等)を抽象して取り除かせる
が、スキーマ・ジェネレーション、キャッシュ・マネー
ジメント、トランザクション・サポート、記憶された手
順、トリガ・サポート、保証、及び最適ＳＱＬ実行のよ
うなエレメントに対する制御を許容するので、開示した
実施例における演繹データベース・エンジンの使用は、
効果的である。

【０１２７】上述した実施例は、第３者のデータの統合
を容易にする。

【０１２８】また、上述した実施例は、容易なソフトウ
ェア及びデータベース保守を供給しうる。

【０１２９】上述した詳細の説明は、限定するためでは
なく説明のためであることを意図しており、全ての同等
物を含んでいる特許請求の範囲が本発明の範疇を規定す
ることを意図している、ということが理解されるべきで
ある。

【図面の簡単な説明】

【図１】ナビゲーション・システムを示すブロック図で
ある。

【図２】図１のナビゲーション・アプリケーション・ソ
フトウェアの部分を示すブロック図である。

【図３】図１及び図２の地図データベースに含まれる異
なるタイプのデータを示す図である。

【図４】図３に示すルーティング・データの個別レイヤ
ーを示す図である。

【図５】空間的に編成された地図データに対するパーセ
ライゼーション方法(parcelization method)の応用を説
明するために用いる地図領域のマップ（地図）を示す。

【図６】図５に示すパーセライゼーション方法による図
１及び図２の地図データベースのデータのパーセル(par
cels)の構成（配列）を示す図である。

【図７】図２のデータ・アクセス・レイヤーのブロック
図である。

【図８】図７に示す規則の構成部分を示すブロック図で
ある。

【図９】図７に示す演繹データベース・エンジンの動作
のフローチャートである。

【図１０】更新地図データを有する図７のデータ・アク
セス・レイヤーの使用を示すブロック図である。

【図１１】無線通信リンクで供給される追加データを有
する図７のデータ・アクセス・レイヤーの使用を示すブ
ロック図である。

【図１２】車両に搭載配置された(located on-board th
e vehicle)追加データを有する図７のデータ・アクセス
・レイヤーの使用を示すブロック図である。

【符号の説明】

１０ ナビゲーション・システム １１ 車両 １２ プロセッサ １４ ドライバ １６ 不揮発性メモリ １８ ソフトウェア １９ パラメータ ２０ ＲＡＭ ２４ 測位システム ２５ センサ ２６ 出力信号 ３１ ユーザ・インタフェース ３２ 記憶媒体 ４０ 地図データ ３００ ロジック・ステートメント

Claims (18)

【特許請求の範囲】
1. 【請求項１】 ナビゲーション・システム用データベー
   ス・アーキテクチャであって、 地図データ及び該地データへの複数のインデックスを含
   む地図データベースと；地図的参照データに対するリク
   エストを受け入れ、前記地図データが記憶される媒体か
   ら該地図データをアクセスしかつ該地図的参照データに
   対する該リクエストに応答を供給するデータ・アクセス
   ・プログラミングと；前記地図データベースに関連付け
   られたロジック・ルールと；及び前記データ・アクセス
   ・プログラミングに関連付けられた演繹データベース・
   エンジンとを備え、 前記演繹データベース・エンジンは、前記媒体からどの
   前記地図データをアクセスするかを決定するためにどの
   前記インデックスを用いるかを決定すべく前記ロジック
   ・ルールをアクセスしかつ組合せることを特徴とするデ
   ータベース・アーキテクチャ。
2. 【請求項２】 ナビゲーション・システム用データベー
   ス・アーキテクチャであって、 第１のフォーマットで媒体に記憶される地図データを含
   む地図データベースと；第２のフォーマットで供給され
   るべき地図的参照データに対するリクエストを受け入
   れ、前記媒体から前記地図データをアクセス、該地図デ
   ータを前記第１のフォーマットから前記第２のフォーマ
   ットに変換し、かつ該地図的参照データに対する該リク
   エストに応答を供給するデータ・アクセス・プログラミ
   ングと；前記地図データベースに関連付けられたロジッ
   ク・ルールと；及び前記データ・アクセス・プログラミ
   ングに関連付けられた演繹データベース・エンジンとを
   備え、 前記演繹データベース・エンジンは、前記地図データを
   前記第１のフォーマットから前記第２のフォーマットに
   変換する方法を決定すべく前記ロジック・ルールをアク
   セスしかつ組合せることを特徴とするデータベース・ア
   ーキテクチャ。
3. 【請求項３】 前記ロジック・ルールのそれぞれは、条
   件を特定する第１の部分とアクションを特定する第２の
   部分とを備えていることを特徴とする請求項１または２
   に記載のデータベース・アーキテクチャ。
4. 【請求項４】 前記演繹データベース・エンジンは、ど
   の前記ロジック・ルールが満たされた第１の部分を有す
   るかを決定し、満たされた前記第１の部分を有する前記
   ロジック・ルールのどの一つを最初に実行すべきかを決
   定し、かつ最初に実行すべく決定された前記ロジック・
   ルールの前記第２の部分で特定された前記アクションを
   実行することを特徴とする請求項３に記載のデータベー
   ス・アーキテクチャ。
5. 【請求項５】 前記第２の部分は、プログラミング・ル
   ーチン及び状態の変化の一つを示すことを特徴とする請
   求項３に記載のデータベース・アーキテクチャ。
6. 【請求項６】 前記条件は、前記地図データに関する本
   質的条件及び前記演繹データベース・エンジンによって
   先に決定された状態に関する付帯的条件の一つを備えて
   いることを特徴とする請求項３に記載のデータベース・
   アーキテクチャ。
7. 【請求項７】 前記地図データは、第１のフォーマット
   で前記媒体に記憶されかつ前記地図的参照データに対す
   るリクエストへの前記応答は、第２のフォーマットで供
   給され、かつ前記演繹データベース・エンジンは、前記
   地図データを前記第１のフィーマットから前記第２のフ
   ォーマットに変換する方法を決定するために前記ロジッ
   ク・ルールをアクセスしかつ組合せることを特徴とする
   請求項１に記載のデータベース・アーキテクチャ。
8. 【請求項８】 遠隔的に配置されたデータを更に備え、
   かつ前記ロジック・ルールは、利用可能な場合に前記遠
   隔的に配置されたデータへのアクセスを供給するロジッ
   ク・ルールを含むことを特徴とする請求項１又は２に記
   載のデータベース・アーキテクチャ。
9. 【請求項９】 前記地図データベースは、更新されたデ
   ータを備え、かつ前記ロジック・ルールは、前記更新さ
   れたデータへのアクセスを供給するロジック・ルールを
   含むことを特徴とする請求項１又は２に記載のデータベ
   ース・アーキテクチャ。
10. 【請求項１０】 前記データ・アクセス・プログラミン
    グは、 前記ロジック・ルールによって呼び出されるデータ検索
    ルーチンを含むインデックス・アクセス・システムを更
    に備え、前記データ検索ルーチンは、前記インデックス
    をアクセスすることを特徴とする請求項１に記載のデー
    タベース・アーキテクチャ。
11. 【請求項１１】 前記データ・アクセス・プログラミン
    グは、 地図データを前記第１のフォーマットから前記第２のフ
    ォーマットに変換するためにロジック・ルールによって
    呼び出されるデータ検索ルーチンを含む物理的から論理
    的への変換システムを更に備えていることを特徴とする
    請求項２に記載のデータベース・アーキテクチャ。
12. 【請求項１２】 地図データベースをアクセスするため
    のオペレーションの方法であって、 ナビゲーション関連データに対するリスエストを受け入
    れる段階と；媒体に記憶された地図データベースをアク
    セスする段階と；前記地図データベースからデータを取
    得する段階と；前記リクエストに対して応答を供給する
    ために前記地図データベースから取得した前記データを
    用いる段階とを具備し、 前記アクセスする段階、前記取得する段階及び前記用い
    る段階は、前記応答を供給するために必要な全てのデー
    タが前記地図データベースから取得されかつ応答が前記
    リクエストに供給されるまで、以下の段階を繰り返し実
    行することを含む：前記地図データベースに関連付けら
    れたロジック・ルールをアクセスする段階；どの前記ロ
    ジック・ルールが満たされるかを決定する段階；満たさ
    れた前記ロジック・ルールのどれが最も高い優先度を有
    するかを結締する段階；及び前記最も高い優先度を有す
    ることが決定された前記ロジック・ルールによって特定
    されたアクションを実行する段階を具備することを特徴
    とする方法。
13. 【請求項１３】 ナビゲーション・システム用の改良さ
    れたデータベース・アーキテクチャであって、 前記データベース・アーキテクチャは、地図データ及び
    該地図データへの複数のインデックスを含む地図データ
    ベースを備え、更に前記データベース・アーキテクチャ
    は、地図的参照データに対するリクエストを受け入れ、
    該地図データが記憶される媒体から該地図データをアク
    セスしかつ前記地図的参照データに対するリクエストに
    対して応答を供給するデータ・アクセス・プログラミン
    グを含み、 前記改良は、 前記地図データベースに関連付けられたロジック・ルー
    ル；及び前記データ・アクセス・プログラミングに含ま
    れる演繹データベース・エンジンを備え、 前記演繹データベース・エンジンは、どの前記地図デー
    タを前記媒体からアクセスするかを決定するために用い
    る前記インデックスのどれかを決定するために前記ロジ
    ック・ルールをアクセスしかつ組合せることを特徴とす
    るデータベース・アーキテクチャ。
14. 【請求項１４】 前記ロジック・ルールのそれぞれは、
    条件を特性する第１の部分とアクションを特定する第２
    の部分とを備えていることを特徴とする請求項１３に記
    載の発明。
15. 【請求項１５】 前記演繹データベース・エンジンは、
    どの前記ロジック・ルールが満たされた第１の部分を有
    するかを決定し、満たされた前記第１の部分を有する前
    記ロジック・ルールのどの一つを最初に実行すべきかを
    決定し、かつ最初に実行すべく決定された前記ロジック
    ・ルールの前記第２の部分で特定された前記アクション
    を実行することを特徴とする請求項１４に記載のデータ
    ベース・アーキテクチャ。
16. 【請求項１６】 前記第２の部分は、プログラミング・
    ルーチン及び状態の変化の一つを示すことを特徴とする
    請求項１４に記載のデータベース・アーキテクチャ。
17. 【請求項１７】 前記条件は、前記地図データに関する
    本質的条件及び前記演繹データベース・エンジンによっ
    て先に決定された状態に関する付帯的条件の一つを備え
    ていることを特徴とする請求項１４に記載のデータベー
    ス・アーキテクチャ。
18. 【請求項１８】 ナビゲーション・システム用の改良さ
    れたデータベース・アーキテクチャであって、 前記データベース・アーキテクチャは、第１のフォーマ
    ットで媒体に記憶される地図データを含む地図データベ
    ースを備え、 更に、第２のフォーマットで供給されるべき地図的参照
    データに対するリクエストを受け入れ、前記媒体から前
    記地図データをアクセス、該地図データを前記第１のフ
    ォーマットから前記第２のフォーマットに変換し、かつ
    該地図的参照データに対する該リクエストに応答を供給
    するデータ・アクセス・プログラミングと；前記地図デ
    ータベースに関連付けられたロジック・ルールと；及び
    前記データ・アクセス・プログラミングに含まれた演繹
    データベース・エンジンとを備え、 前記演繹データベース・エンジンは、前記地図データを
    前記第１のフォーマットから前記第２のフォーマットに
    変換する方法を決定すべく前記ロジック・ルールをアク
    セスしかつ組合せることを特徴とするデータベース・ア
    ーキテクチャ。