多数の地図ビルディングブロックにおけるオブジェクトの相互参照と重複排除を行う方法と装置
ディジタル地図データベースを提供するシステムと方法において、一つ以上のビルディングブロックに含まれる注目点(POI)および/または三次元(3D)オブジェクトに関連するジオコード付加オブジェクトの多数のインスタンスは、望まれない重複ジオコード付加オブジェクトを見付けるために比較される。相互参照情報は格納され、選択あるいはナビゲーション装置(10)または他の適切な計算装置の表示画面(12)上の提示に関する優先度を判定するために、使用すべきジオコード付加オブジェクトまたはオブジェクトプロパティ/属性についての優先情報が査定される。相互参照は、コンパイル時に予め計算されるか、ナビゲーションアプリケーションの実行時にオンザフライで計算され、専用のデータ構造に永続的に格納される。重複ジオコード付加オブジェクトが見付かると、最も正確な情報または（属性）情報のスーパセットがアプリケーションによって使用されるかユーザに提示され、それによって混乱が防止される。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、2009年12月14日に出願された米国仮特許出願61/286,036号の優先権を主張し、参照と依拠により、その全開示がここに組み入れられる。
【０００２】
本発明は、ディジタル地図の提供に関し、とくに、一つ以上のサードパーティソースが提供する情報によってディジタル地図コンテンツを強化する方法とシステムに関する。
【背景技術】
【０００３】
現代社会において、ディジタル地形データまたはディジタル地図データの使用は珍しくなくなった。通常「電子地図」または「ディジタル地図」と呼ばれるこの種のデータは、現在、地上ベースの車両ナビゲーション、経路計画など、様々なアプリケーションで使用される。インターネットベースの企業-消費者(B2C)企業は現在、顧客を劇場、店舗、レストラン、その他の商業施設に誘導するためにディジタル地図を使用する。ディジタル地図は、例えば、配送ドライバのための経路を計算する、あるいは、緊急呼び出しに応じて、それに従事する緊急医療クルーに道順を提供するなど、しばしば民間環境(commercial settings)において使用される。
【０００４】
ディジタル地図プロバイダは、例えば、ストリートアドレス、交通ネットワーク、水域、風致地区、行政区分、国勢調査データ、人口統計情報、商業ビジネス、娯楽施設などを含む地図データにおける、これまで以上の多様性の採集者、かつ、まとめ役になった。同時に、地図データの用途の多様性は、車載のドライビング補助、携帯電話ベースのナビゲーション、地域にフォーカスしたニュース、メディア、および、イエローページ情報サービスのようなアプリケーションを含むように拡大した。コンテンツとユーティリティにおけるこの増加とともに、基礎となる地図データと、場所に関する情報の他のソースとの結合が、より有用な最終製品の提供を可能にすることが明らかになった。
【０００５】
地図データの統合への典型的なアプローチは、ディジタル地図を基礎地図として使用する「オーバレイ地図」を作成し、そして、一つ以上のソースからの追加情報を基礎地図上に置いて、より複雑な地図の少なくともイリュージョンを提供することである。このアプローチは、多数のインターネットベースの地図情報システムにおいて使用された。例えば、オンラインレストラン検索ユーティリティの提供を望む会社は、（通り、公園、その他の場所を伴う典型的な地図である）基礎地図「A」を提供する。そして、同社は、レストラン情報とそのレビューを含む第二の地図「B」をオーバレイする。地図AとBは同じソースから来るかもしれないし、ユーザへの提供が独立に行われないかもしれない。レストランの地図に関するユーザリクエストに応えて、同社は、マッチするレストランを地図上にフラグとしてピンポイントした地図Bの一部または全部をオーバレイした地図Aの一部または全部を表示する。この処理は、基礎地図上に多数の地図をオーバレイする拡張が可能であり、非常に情報が豊富な地図を知覚させる。
【０００６】
しかし、この手法の問題は、地図情報が異なるソースから統合されるため、統合すべき様々な地図の間の一貫性の維持が難しいことである。単一のアプリケーションがデータ収集成果の多様性から集めた情報を使用する場合、一貫性を失うリスクがある。データが社内のリソースから収集されたとしてもリスクが存在し、データがサードパーティから収集されるとリスクは大きくなる。一つのアプローチは、望む情報のすべてを共通の収納場所またはデータベースに維持し保存することだった。しかし、データ量を増加させるデータがデータベースに追加されることでデータベースはかなり複雑になり、かつ、雑然として、パフォーマンス要件とメンテナンス要件が受け入れられなくなる。多くの場合、サードパーティは、彼らの特定のデータの精度と鮮度を維持することについて最も有能なエンティティである。オリジナルソースから頻繁なアップデートをもはや受信しない一枚岩的な(monolitic)データベースにデータが統合されている場合、データの精度が失われる可能性がある。
【０００７】
地理空間データの問題を考慮する場合、これらの精度と一貫性の考慮すべき事項がますます働き始める。例えば、顧客を引き付けるようとするホテルチェーンは、彼らの顧客に正確な道順を提供することが極めて重要だと考えている。インタラクティブな地域地図は、彼らの広告の最重要なソースの一つかも知れない。ローカルノレッジ(local knowledge)が近所やコミュニティの情報のような地域の情報を示すようになると、それはまた最高のノレッジと見做される。これら事例のそれぞれにおいて、サードパーティが作成した独自の地域データは、中央の地図データ会社が単一のデータベースを操作する場合よりも、地域を指向した、または、地域にフォーカスしたデータを作成し更新するのに最適だろう。
【０００８】
集中保存や一枚岩的な地図データベースの欠点にもかかわらず、ある会社が様々なデータソースから望まれる情報の統合をエンドユーザに提供しようとする場合、データ収集成果が標準化され包括的であることを保証するデータの集中的な協調(central coordination)の幾つかの型(form)が必要である。
【０００９】
これらの問題に対処する従来の試みの一例は、2008年9月4日に公開された、Fuchsらの米国特許出願公開第2008/0215524号明細書に記載され、その全開示が参照によりここに組み入れられる。Fuchsらは、データの制御を保持する特定のデータソースをサポートするために最善なエンティティを同時に確保しながら、首尾一貫した方法により様々なソースからの地図データの統合を可能にする間、明らかに対立する考慮すべき事項のバランスをとるための「仮想データベースシステム」(VDB)を開示する。VDBは、ディジタル地図プロバイダと一つ以上のサードパーティの間、または、幾つかのサードパーティの間で、最終的な総合地図製品に収容されるジオコード付加オブジェクト（geocoded object：地理座標付加オブジェクト）の管理(control)と所有権の共有（または、管理と所有権を委任する幾つかの事例）を可能にする。実施例によれば、VDB環境は、サードパーティデータプロバイダが彼らのデータ（「サードパーティファイル」と呼ばれる）をディジタル地図プロバイダの「基礎地図」や「参照ファイル」に簡単に関連付けたり、ジオコード（geocode：地理座標）の付加を可能にして、ディジタル地図の特徴と他のサードパーティデータプロバイダの間の動的な関係の作成を可能にする。アプリケーションプロバイダは、単一のメカニズムを経由して、多数のベンダからのシームレスに統合されたデータを購入し検索するためにVDBにアクセスすることができ、VDBはそのデータをエンドユーザに提供する。ある実施例では、統合が動的またはリアルタイム方式で行われ、必要に応じてまたはオンデマンドに、様々なソースから最新情報を受信し、リンクを作成し、バーチャル地図を構成する。補足的な利点として、情報は地図プロバイダと様々なサードパーティの間でリンクされていて、参照ファイルの何れか、または、サードパーティファイルの一つにおいて複数の項目の間の一つの情報項目またはリンクが更新される都度、更新された情報が全サードパーティに伝播され、彼ら独自のソフトウェアアプリケーションに更新された情報を使用させることができる。
【００１０】
従来の技術におけるこれらの進歩にもかかわらず、重複したオブジェクトの識別と解決の必要性が残る。産業界のナビゲーションシステムサプライヤほかは、地図ベンダが、ナビゲーションデータ標準(NDS)または他の物理ストレージフォーマット(PSF)へコンパイルする前に、彼らの地図製品内で、この問題を解決することを好むかも知れない。コンテンツのパーソナライズとユーザ定義のコンテンツダウンロードを含む、ネットワークが利用可能な環境(connected)におけるソーシャルナビゲーションの概念が促進されることになり、地図のベンダは、永続的な信頼性とともにコンテンツの独自性を保証することが益々難しくなることに気付く。従って、従来の技術において、多数のソースからのコンテンツの重複を査定するシステムおよび方法を提供する必要がある。そのシステムおよび方法により、重複オブジェクトを見付けるために優先度を付与し、表示の提示および/またはフラグ付けか記録による確定した情報の後の使用のような、実際の使用において最高の信頼性をもつ/最高にリッチな情報だけを確定する。
【発明の概要】
【００１１】
システムおよび方法は、ディジタル地図における一つ以上の外部ソースからのジオコード付加オブジェクト形式のデータを統合することで、ディジタル地図のコンテンツの価値を高めるために提供される。ディジタル地図は、現実の道路ネットワークに対応するディジタル化情報を含む。ディジタル地図は、現実の特定の物体または場所に対応するディジタル化ジオコード付加オブジェクトを有する少なくとも一つのビルディングブロック(building block)を含む。追加のビルディングブロックは、現実の同一物体または同一場所に対応するディジタル化ジオコード付加オブジェクトを含む。（あるいは、現実の同一物体または同一場所に対応する二つのジオコード付加オブジェクトが同一ビルディングブロックに含まれる。）追加のビルディングブロックはディジタル地図に統合される。改良は、現実の同一物体に対応する各ビルディングブロックから（または、同一ビルディングブロック内で）二つ以上のジオコード付加オブジェクトを識別することを含む。優先度が各ジオコード付加オブジェクトに付与され、そして優先度が互いに比較される。ディジタル地図で使用するために、または、識別された複数のデータセットの間において確定された優先度の永続的な保存のために、最高の優先度を有する一つのジオコード付加オブジェクト（またはその属性）が選択される。
【００１２】
本発明は、ディジタル地図に既存のジオコード付加オブジェクトの更新をサードパーティ（つまり、ディジタル地図プロバイダ以外）が提起または提案する場合、ディジタル地図における三次元(3D)および注目点(POI)のコンテンツのようなジオコード付加オブジェクトを管理する必要性に対処する。本発明によって示される方法とデータ構造ストラテジは、（例えば、ナビゲーションデータ標準(NDS)を使用する）ナビゲーション地図のコンパイル処理、および/または、ナビゲーションアプリケーションにおいて、有益な役割を果たすことができる。本発明の原理は、前処理操作または実行時のオンザフライ処理において重複ジオコード付加オブジェクトの間の相互参照を導く多数のPOIまたは3Dオブジェクトデータベースと、ホスト役のデータに同等に適用される。
【００１３】
これらおよび他の特徴と本発明の利点は、以下の詳細な説明と添付する図面に関連して熟考する場合、より容易に理解されるだろう。
【図面の簡単な説明】
【００１４】
【図１】地図データ情報を提示するように構成された、本発明の一実施例によるナビゲーション装置の表示画面を例示する図、
【図２】従来技術に従う、図1に示す携帯ナビゲーション装置の表示画面を例示して、起り得る混乱を導く、現実の同一物体に対応する多数の注目点(POI)エントリの表示を示す図、
【図３】異なるデータソースに由来する重複ラベリングされた特徴によって識別される現実の物体の3Dビューと、生み出される混乱の可能性を示す従来技術の表示画面を例示する図、
【図４】各相互参照情報が可能にする重複の識別とともに、現実の同一物体に対応するが、異なるソース（ソースA、B、C）に由来する3Dオブジェクトの典型的な比較を示す図、
【図５】図4に示す多数のソースからの重複3Dオブジェクトの別のビューと、重複オブジェクトそれぞれに付与されて比較目的に使用される優先情報を示す図、
【図６】本発明の基本的な手順を説明する簡易フロー図。
【発明を実施するための形態】
【００１５】
図を参照すると、同じ番号は、幾つかの図を通して同一または対応する部分を示す。本発明は、ディジタル地図に利用するように構成されたナビゲーション装置に関連する。ナビゲーション装置は、GPSまたは他のデータストリームからの正確な位置決めデータと組み合わされる場合もあり、また組み合わされない場合もある。本発明は、例えば図1の10に示すようなモバイルナビゲーション装置に限定されず、ディジタル地図にアクセスし表示画面に同様の提示が可能なパーソナルコンピュータ、車載型のインフォテイメントシステム、携帯電話やその他のハンドヘルド機器を含む任意の装置を介して実行することができる。図1に示すように、ナビゲーションシステム10は、格納ディジタル地図の一部を道路14のネットワークとして表現する表示画面12を含む。GPS対応ナビゲーション装置10にアクセスする旅行者は、通常、特定の道路14またはそのセグメントに近いディジタル地図上に配置されるか、特定の道路14またはそのセグメントに関連してディジタル地図上に配置される。一方、例えばデスクトップコンピュータのような、GPS非対応装置を介してディジタル地図にアクセスする個人は、地図に関して配置されることはないが、その他の点では、ディジタル地図からのコンテンツにアクセス可能である。
【００１６】
ディジタル地図プロバイダは、継続的に、自身の地図を改善し更新することに努める。ディジタル地図に含まれる不正確または不完全な情報は、粗末なまたは誤ったナビゲーション指示に帰着し、望ましくない経路/旅行の決定を導く。疑義を回避するため、本発明は、インターネット対応のコンピュータ、タブレットPC、パーソナルディジタルアシスタント(PDA)、携帯電話、携帯ナビゲーション装置10、車載ナビゲーションシステムなどを介してアクセス可能なディジタル地図を含むディジタル地図アプリケーションの全種類のみならず、ナビゲーションシステムの全種類に使用されるディジタル地図に関連する。
【００１７】
本発明は、ディジタル地図に含めるために、ジオコード付加オブジェクトのディジタル化形式であるビルディングブロックを介して付託される三次元(3D)および注目点(POI)のコンテンツを効率的に管理する手順を提供する。本発明は、ナビゲーションデータベースを標準化する現在の努力に関連して、唯一有用とは言えないが、とりわけ有用である。例えば、自動車のPSFの標準化イニシアチブ(PSI)は、地図コンテンツの異なる種類（例えば、地図表示、名前、道路形状(road geometry)、経路データ、ADAS属性、POI、3Dオブジェクト、3D地形モデルほか）に関して、ビルディングブロックと呼ばれるデータ構造のモジュールの範囲を認定した。
【００１８】
例えばNDS形式において定義される用語「ビルディングブロック」は、ある種類または区分のコンテンツ（例えばPOI、地図表示データ、3Dデータ、名前データほか）を意味し、所定のPOIインスタンスのデータレコードを意味するわけではない。PSIは、これら異なる種類のビルディングブロックに関連してナビゲーションデータ標準(NDS)形式を開発した。各ビルディングブロックは、一つ以上のジオコード付加オブジェクトを含む。一般的に言えば、ジオコード付加オブジェクトは、所定のPOI、3Dオブジェクト、または、他のコンテンツ特徴に関連する関連情報または属性のデータセットである。用語ジオコード付加オブジェクトは、地理参照オブジェクトと呼ばれることもある。コンパイルされたNDSデータベースにおいて、現実の同一特徴に関連する二つ以上のジオコード付加オブジェクトが同一または異なるビルディングブロックにおいて発生する可能性がある。例には、サードパーティソース（例えばイエローページ）に由来する他のPOIビルディングブロックと共存する（ディジタル地図プロバイダによって提供されるような）基礎POIを伴うPOIビルディングブロック、および、同時に存在する3Dオブジェクト（例えば、他のソースからの3Dランドマークと同様のブロックモデル）の多数のビルディングブロックが含まれる。
【００１９】
NDS仕様の変化と企画は、例えば、重複ジオコード付加オブジェクトについての格納と取扱情報のデータ構造や概念を予知していなかった。これは、（例えば）図2に破線で囲んで示す検索リストにおける同一POIの多数エントリを防ぐために、かつ、図3に示す実際に参照される同一オブジェクトであるアイコン/3D建造物の多数表示を防ぐために、NDSアプリケーションに負担を掛ける。これらは、表示画面12に提示される情報を読む個人を混乱させ、および/または、苛立たせる。さらに、この問題に対する実用的な解決策は、重複ジオコード付加オブジェクト問題を実行時だけでなく後の参照用に記録または保存して解決せねばならず、永続的である必要がある。一方、実行時の後の参照のためのプリコンパイルされた情報を導く、ジオコード付加オブジェクトの重複排除の努力はNDSのコンパイル時に発生する。
【００２０】
本発明の概念は、NDSまたは他の適切な物理ストレージ形式(PSF)のビルディングブロックに内側または外側で関連する拡張データ構造を提案して、相互参照情報の格納、並びに、ジオコード付加オブジェクト（あるいは、オブジェクトプロパティまたはオブジェクト属性）が有すべき選択または提示の優先度についての優先情報(preference information)を扱うことである。後述するように、優先情報は、最新の更新に基づく、属性のリッチさ、動的補助コンテンツへのリンク、または、他の関連ファクタである。
【００２１】
本発明の一実施例によれば、相互参照情報は、異なる製品データベースのジオコード付加オブジェクトの間の相互参照を確定するためにオーバヘッドデータ構造として例えばテーブルに全世界レベルで格納されている。定義として、製品データベースは、特定のコンテンツプロバイダによってコンパイルされた地図コンテンツである。各製品データベースは、所定のPSF地図データベースの個別のインスタンスとして扱われる。参照されるデータまたはテーブルは、オブジェクト情報として、オブジェクト1、オブジェクト2、および、補足情報を含む。オブジェクト1と2の参照データは、Product Database Identification（製品データベースID）、Update Region Identification（更新地域ID） 、Building Block Type（ビルディングブロックタイプ）、Building Block Identification（ビルディングブロックID）およびObject Identification（オブジェクトID）などの詳細を含む。この参照データは例えば図4に示される。補足情報は優先データなどを含む。
【００２２】
これら相互参照は、異なるビルディングブロックが一緒に生成される際のコンパイル時に予め計算されるか、あるいは、実行時にナビゲーションアプリケーションによってオンザフライ計算されることが好ましい。結果は、ナビゲーションアプリケーションによって、そのようなテーブルに永続的に格納される。現実の同一物体に対応するジオコード付加オブジェクトをそれぞれ含む異なるデータソースに由来するビルディングブロックを識別する原理は、さらに、空間的な近さ、並びに、オブジェクトプロパティ、属性、オブジェクトタイプ、オブジェクトクラス、オブジェクト名、および、オブジェクトアドレスほかの比較に基づく考慮を含む。
【００２３】
本発明の別の実施例によれば、地図ベンダおよび/またはNDSコンパイルハウスはオールインワンNDS製品をコンパイルする。POIコンテンツや3Dコンテンツは一つ以上のビルディングブロックに細分化され、相互参照情報が生成される。以前から、NDS製品は、コア製品（例えば、POIがないか単一POIのビルディングブロック）と、ネットワークに接続されたナビゲーション装置10によって後にダウンロードされるアドオン製品（例えば拡張POIコンテンツ）に分けて市場に供給されている。ナビゲーション装置10が使用するNDS製品は、ディレクトリ形式において、Google Earthからの3Dオブジェクトの転送などのユーザソースコンテンツによって拡張される。このユーザソースコンテンツは別のビルディングブロックに格納される。装置10によって実行されるナビゲーションアプリケーションは、実行時に、重複ジオコード付加オブジェクトが一つ以上のビルディングブロックに存在するかを判定する。重複ジオコード付加オブジェクトが識別された場合、ナビゲーションアプリケーションは、後の再利用のためのオーバヘッド構造に相互参照情報を記録する。ユーザは、ナビゲーションアプリケーションが検出したジオコード付加オブジェクトが本当に重複しているか否かの確認を求められる場合がある。
【００２４】
別の実施例において、相互参照情報は、ビルディングブロックの内側でのみ相互参照を記録し維持する意図で、POIや3Dオブジェクトに関連するコンテンツのような既存のビルディングブロックに関して提供される。ビルディングブロックのコンテンツが少しずつ更新かつ拡張されるならば、プリコンパイルされた相互参照は（これまでに確定されているなら）、実行時に決定される追加の相互参照により動的に維持することができる。
【００２５】
相互参照データ構造の異なる実施例が適切な可能性がある。ある場合、データ構造が実際のビルディングブロックの外側に実装され、二つ以上の他のビルディングブロックからのオブジェクトがリンクされる。別の実装において、データ構造は実際のビルディングブロックの内側にあり、ビルディングブロックの一つだけに実装する第一の方法か、相互参照ジオコード付加オブジェクトを伴う、二つのビルディングブロックに実装する第二の方法の何れかである。これらデータ構造は、一つ以上の他のビルディングブロックにおけるジオコード付加オブジェクトにリンクする。
【００２６】
本発明によれば、（相互参照と優先情報(priority information)の形式における）特別なオーバヘッドがNDSのようなナビゲーションランタイム形式内部の3DオブジェクトとPOIのデータ構造に追加され、3DビルディングブロックまたはPOIビルディングブロックが多数回発生し、整合性または独自性がビルディングブロックの内側だけで管理され、別のビルディングブロックの間で管理されることはない。本発明によるオーバヘッドデータ構造は、異なるビルディングブロックにおける重複ジオコード付加オブジェクトの間の永続的な相互参照のための手段の提供と、その後、ナビゲーション装置10を介して実行される、ナビゲーションアプリケーションによる実行時重複努力(run-time duplication efforts)の構造的なサポートにより、NDSにおける概念的ギャップを埋める。
【００２７】
図6は、簡易な用語により、上述した本発明の方法の手順を説明する。相互参照と重複排除のための、ここに提案する方法とデータ構造は、NDSコンパイル処理において役割を果たす。製品コンセプトに依存して、地図ベンダは、複数のPOIビルディングブロック（または3Dオブジェクトビルディングブロックほか）を追加(populate)のために選択する。さらに、方法とデータ構造は、ソフトウェア開発と実行時動作の両面に関して、ナビゲーションアプリケーションにおいて使用することができる。対応する原理は、対応する（つまり重複する）ジオコード付加オブジェクトの間の相互参照を導く前処理において、または、当該相互参照を導く実行時に存在する処理として、多数のPOIまたは3Dオブジェクトデータベースとともに（NDS以外の形式を使用する）ホスト役のデータにも適用される。
【００２８】
従って、同一ビルディングブロックの内側または異なるビルディングブロックに由来する重複ジオコード付加オブジェクトの識別に使用される方法を実行する方法と地図データベースシステムが実装された装置とともに、本発明の方法は、適切な優先度を付与し、それら優先度を比較する。そして、アプリケーションにおいて使用するために最高の優先度をもつ、一つのビルディングブロックを選択するか、ビルディングブロック内のジオコード付加オブジェクトの特定のインスタンスの一つの属性/プロパティを選択する。そして、装置と本発明の方法は、「クリーンアップされた」行き先リストまたは地図表現形式における、適切な装置10の表示画面12上の排他的な表示を含む。
【００２９】
上述の発明は、関連する法的基準に従って記載され、従って説明は本質的な制限ではなく例示である。開示した実施例の変形および変更は、本発明の範囲内において、当業者には明らかである。
【技術分野】
【０００１】
本出願は、2009年12月14日に出願された米国仮特許出願61/286,036号の優先権を主張し、参照と依拠により、その全開示がここに組み入れられる。
【０００２】
本発明は、ディジタル地図の提供に関し、とくに、一つ以上のサードパーティソースが提供する情報によってディジタル地図コンテンツを強化する方法とシステムに関する。
【背景技術】
【０００３】
現代社会において、ディジタル地形データまたはディジタル地図データの使用は珍しくなくなった。通常「電子地図」または「ディジタル地図」と呼ばれるこの種のデータは、現在、地上ベースの車両ナビゲーション、経路計画など、様々なアプリケーションで使用される。インターネットベースの企業-消費者(B2C)企業は現在、顧客を劇場、店舗、レストラン、その他の商業施設に誘導するためにディジタル地図を使用する。ディジタル地図は、例えば、配送ドライバのための経路を計算する、あるいは、緊急呼び出しに応じて、それに従事する緊急医療クルーに道順を提供するなど、しばしば民間環境(commercial settings)において使用される。
【０００４】
ディジタル地図プロバイダは、例えば、ストリートアドレス、交通ネットワーク、水域、風致地区、行政区分、国勢調査データ、人口統計情報、商業ビジネス、娯楽施設などを含む地図データにおける、これまで以上の多様性の採集者、かつ、まとめ役になった。同時に、地図データの用途の多様性は、車載のドライビング補助、携帯電話ベースのナビゲーション、地域にフォーカスしたニュース、メディア、および、イエローページ情報サービスのようなアプリケーションを含むように拡大した。コンテンツとユーティリティにおけるこの増加とともに、基礎となる地図データと、場所に関する情報の他のソースとの結合が、より有用な最終製品の提供を可能にすることが明らかになった。
【０００５】
地図データの統合への典型的なアプローチは、ディジタル地図を基礎地図として使用する「オーバレイ地図」を作成し、そして、一つ以上のソースからの追加情報を基礎地図上に置いて、より複雑な地図の少なくともイリュージョンを提供することである。このアプローチは、多数のインターネットベースの地図情報システムにおいて使用された。例えば、オンラインレストラン検索ユーティリティの提供を望む会社は、（通り、公園、その他の場所を伴う典型的な地図である）基礎地図「A」を提供する。そして、同社は、レストラン情報とそのレビューを含む第二の地図「B」をオーバレイする。地図AとBは同じソースから来るかもしれないし、ユーザへの提供が独立に行われないかもしれない。レストランの地図に関するユーザリクエストに応えて、同社は、マッチするレストランを地図上にフラグとしてピンポイントした地図Bの一部または全部をオーバレイした地図Aの一部または全部を表示する。この処理は、基礎地図上に多数の地図をオーバレイする拡張が可能であり、非常に情報が豊富な地図を知覚させる。
【０００６】
しかし、この手法の問題は、地図情報が異なるソースから統合されるため、統合すべき様々な地図の間の一貫性の維持が難しいことである。単一のアプリケーションがデータ収集成果の多様性から集めた情報を使用する場合、一貫性を失うリスクがある。データが社内のリソースから収集されたとしてもリスクが存在し、データがサードパーティから収集されるとリスクは大きくなる。一つのアプローチは、望む情報のすべてを共通の収納場所またはデータベースに維持し保存することだった。しかし、データ量を増加させるデータがデータベースに追加されることでデータベースはかなり複雑になり、かつ、雑然として、パフォーマンス要件とメンテナンス要件が受け入れられなくなる。多くの場合、サードパーティは、彼らの特定のデータの精度と鮮度を維持することについて最も有能なエンティティである。オリジナルソースから頻繁なアップデートをもはや受信しない一枚岩的な(monolitic)データベースにデータが統合されている場合、データの精度が失われる可能性がある。
【０００７】
地理空間データの問題を考慮する場合、これらの精度と一貫性の考慮すべき事項がますます働き始める。例えば、顧客を引き付けるようとするホテルチェーンは、彼らの顧客に正確な道順を提供することが極めて重要だと考えている。インタラクティブな地域地図は、彼らの広告の最重要なソースの一つかも知れない。ローカルノレッジ(local knowledge)が近所やコミュニティの情報のような地域の情報を示すようになると、それはまた最高のノレッジと見做される。これら事例のそれぞれにおいて、サードパーティが作成した独自の地域データは、中央の地図データ会社が単一のデータベースを操作する場合よりも、地域を指向した、または、地域にフォーカスしたデータを作成し更新するのに最適だろう。
【０００８】
集中保存や一枚岩的な地図データベースの欠点にもかかわらず、ある会社が様々なデータソースから望まれる情報の統合をエンドユーザに提供しようとする場合、データ収集成果が標準化され包括的であることを保証するデータの集中的な協調(central coordination)の幾つかの型(form)が必要である。
【０００９】
これらの問題に対処する従来の試みの一例は、2008年9月4日に公開された、Fuchsらの米国特許出願公開第2008/0215524号明細書に記載され、その全開示が参照によりここに組み入れられる。Fuchsらは、データの制御を保持する特定のデータソースをサポートするために最善なエンティティを同時に確保しながら、首尾一貫した方法により様々なソースからの地図データの統合を可能にする間、明らかに対立する考慮すべき事項のバランスをとるための「仮想データベースシステム」(VDB)を開示する。VDBは、ディジタル地図プロバイダと一つ以上のサードパーティの間、または、幾つかのサードパーティの間で、最終的な総合地図製品に収容されるジオコード付加オブジェクト（geocoded object：地理座標付加オブジェクト）の管理(control)と所有権の共有（または、管理と所有権を委任する幾つかの事例）を可能にする。実施例によれば、VDB環境は、サードパーティデータプロバイダが彼らのデータ（「サードパーティファイル」と呼ばれる）をディジタル地図プロバイダの「基礎地図」や「参照ファイル」に簡単に関連付けたり、ジオコード（geocode：地理座標）の付加を可能にして、ディジタル地図の特徴と他のサードパーティデータプロバイダの間の動的な関係の作成を可能にする。アプリケーションプロバイダは、単一のメカニズムを経由して、多数のベンダからのシームレスに統合されたデータを購入し検索するためにVDBにアクセスすることができ、VDBはそのデータをエンドユーザに提供する。ある実施例では、統合が動的またはリアルタイム方式で行われ、必要に応じてまたはオンデマンドに、様々なソースから最新情報を受信し、リンクを作成し、バーチャル地図を構成する。補足的な利点として、情報は地図プロバイダと様々なサードパーティの間でリンクされていて、参照ファイルの何れか、または、サードパーティファイルの一つにおいて複数の項目の間の一つの情報項目またはリンクが更新される都度、更新された情報が全サードパーティに伝播され、彼ら独自のソフトウェアアプリケーションに更新された情報を使用させることができる。
【００１０】
従来の技術におけるこれらの進歩にもかかわらず、重複したオブジェクトの識別と解決の必要性が残る。産業界のナビゲーションシステムサプライヤほかは、地図ベンダが、ナビゲーションデータ標準(NDS)または他の物理ストレージフォーマット(PSF)へコンパイルする前に、彼らの地図製品内で、この問題を解決することを好むかも知れない。コンテンツのパーソナライズとユーザ定義のコンテンツダウンロードを含む、ネットワークが利用可能な環境(connected)におけるソーシャルナビゲーションの概念が促進されることになり、地図のベンダは、永続的な信頼性とともにコンテンツの独自性を保証することが益々難しくなることに気付く。従って、従来の技術において、多数のソースからのコンテンツの重複を査定するシステムおよび方法を提供する必要がある。そのシステムおよび方法により、重複オブジェクトを見付けるために優先度を付与し、表示の提示および/またはフラグ付けか記録による確定した情報の後の使用のような、実際の使用において最高の信頼性をもつ/最高にリッチな情報だけを確定する。
【発明の概要】
【００１１】
システムおよび方法は、ディジタル地図における一つ以上の外部ソースからのジオコード付加オブジェクト形式のデータを統合することで、ディジタル地図のコンテンツの価値を高めるために提供される。ディジタル地図は、現実の道路ネットワークに対応するディジタル化情報を含む。ディジタル地図は、現実の特定の物体または場所に対応するディジタル化ジオコード付加オブジェクトを有する少なくとも一つのビルディングブロック(building block)を含む。追加のビルディングブロックは、現実の同一物体または同一場所に対応するディジタル化ジオコード付加オブジェクトを含む。（あるいは、現実の同一物体または同一場所に対応する二つのジオコード付加オブジェクトが同一ビルディングブロックに含まれる。）追加のビルディングブロックはディジタル地図に統合される。改良は、現実の同一物体に対応する各ビルディングブロックから（または、同一ビルディングブロック内で）二つ以上のジオコード付加オブジェクトを識別することを含む。優先度が各ジオコード付加オブジェクトに付与され、そして優先度が互いに比較される。ディジタル地図で使用するために、または、識別された複数のデータセットの間において確定された優先度の永続的な保存のために、最高の優先度を有する一つのジオコード付加オブジェクト（またはその属性）が選択される。
【００１２】
本発明は、ディジタル地図に既存のジオコード付加オブジェクトの更新をサードパーティ（つまり、ディジタル地図プロバイダ以外）が提起または提案する場合、ディジタル地図における三次元(3D)および注目点(POI)のコンテンツのようなジオコード付加オブジェクトを管理する必要性に対処する。本発明によって示される方法とデータ構造ストラテジは、（例えば、ナビゲーションデータ標準(NDS)を使用する）ナビゲーション地図のコンパイル処理、および/または、ナビゲーションアプリケーションにおいて、有益な役割を果たすことができる。本発明の原理は、前処理操作または実行時のオンザフライ処理において重複ジオコード付加オブジェクトの間の相互参照を導く多数のPOIまたは3Dオブジェクトデータベースと、ホスト役のデータに同等に適用される。
【００１３】
これらおよび他の特徴と本発明の利点は、以下の詳細な説明と添付する図面に関連して熟考する場合、より容易に理解されるだろう。
【図面の簡単な説明】
【００１４】
【図１】地図データ情報を提示するように構成された、本発明の一実施例によるナビゲーション装置の表示画面を例示する図、
【図２】従来技術に従う、図1に示す携帯ナビゲーション装置の表示画面を例示して、起り得る混乱を導く、現実の同一物体に対応する多数の注目点(POI)エントリの表示を示す図、
【図３】異なるデータソースに由来する重複ラベリングされた特徴によって識別される現実の物体の3Dビューと、生み出される混乱の可能性を示す従来技術の表示画面を例示する図、
【図４】各相互参照情報が可能にする重複の識別とともに、現実の同一物体に対応するが、異なるソース（ソースA、B、C）に由来する3Dオブジェクトの典型的な比較を示す図、
【図５】図4に示す多数のソースからの重複3Dオブジェクトの別のビューと、重複オブジェクトそれぞれに付与されて比較目的に使用される優先情報を示す図、
【図６】本発明の基本的な手順を説明する簡易フロー図。
【発明を実施するための形態】
【００１５】
図を参照すると、同じ番号は、幾つかの図を通して同一または対応する部分を示す。本発明は、ディジタル地図に利用するように構成されたナビゲーション装置に関連する。ナビゲーション装置は、GPSまたは他のデータストリームからの正確な位置決めデータと組み合わされる場合もあり、また組み合わされない場合もある。本発明は、例えば図1の10に示すようなモバイルナビゲーション装置に限定されず、ディジタル地図にアクセスし表示画面に同様の提示が可能なパーソナルコンピュータ、車載型のインフォテイメントシステム、携帯電話やその他のハンドヘルド機器を含む任意の装置を介して実行することができる。図1に示すように、ナビゲーションシステム10は、格納ディジタル地図の一部を道路14のネットワークとして表現する表示画面12を含む。GPS対応ナビゲーション装置10にアクセスする旅行者は、通常、特定の道路14またはそのセグメントに近いディジタル地図上に配置されるか、特定の道路14またはそのセグメントに関連してディジタル地図上に配置される。一方、例えばデスクトップコンピュータのような、GPS非対応装置を介してディジタル地図にアクセスする個人は、地図に関して配置されることはないが、その他の点では、ディジタル地図からのコンテンツにアクセス可能である。
【００１６】
ディジタル地図プロバイダは、継続的に、自身の地図を改善し更新することに努める。ディジタル地図に含まれる不正確または不完全な情報は、粗末なまたは誤ったナビゲーション指示に帰着し、望ましくない経路/旅行の決定を導く。疑義を回避するため、本発明は、インターネット対応のコンピュータ、タブレットPC、パーソナルディジタルアシスタント(PDA)、携帯電話、携帯ナビゲーション装置10、車載ナビゲーションシステムなどを介してアクセス可能なディジタル地図を含むディジタル地図アプリケーションの全種類のみならず、ナビゲーションシステムの全種類に使用されるディジタル地図に関連する。
【００１７】
本発明は、ディジタル地図に含めるために、ジオコード付加オブジェクトのディジタル化形式であるビルディングブロックを介して付託される三次元(3D)および注目点(POI)のコンテンツを効率的に管理する手順を提供する。本発明は、ナビゲーションデータベースを標準化する現在の努力に関連して、唯一有用とは言えないが、とりわけ有用である。例えば、自動車のPSFの標準化イニシアチブ(PSI)は、地図コンテンツの異なる種類（例えば、地図表示、名前、道路形状(road geometry)、経路データ、ADAS属性、POI、3Dオブジェクト、3D地形モデルほか）に関して、ビルディングブロックと呼ばれるデータ構造のモジュールの範囲を認定した。
【００１８】
例えばNDS形式において定義される用語「ビルディングブロック」は、ある種類または区分のコンテンツ（例えばPOI、地図表示データ、3Dデータ、名前データほか）を意味し、所定のPOIインスタンスのデータレコードを意味するわけではない。PSIは、これら異なる種類のビルディングブロックに関連してナビゲーションデータ標準(NDS)形式を開発した。各ビルディングブロックは、一つ以上のジオコード付加オブジェクトを含む。一般的に言えば、ジオコード付加オブジェクトは、所定のPOI、3Dオブジェクト、または、他のコンテンツ特徴に関連する関連情報または属性のデータセットである。用語ジオコード付加オブジェクトは、地理参照オブジェクトと呼ばれることもある。コンパイルされたNDSデータベースにおいて、現実の同一特徴に関連する二つ以上のジオコード付加オブジェクトが同一または異なるビルディングブロックにおいて発生する可能性がある。例には、サードパーティソース（例えばイエローページ）に由来する他のPOIビルディングブロックと共存する（ディジタル地図プロバイダによって提供されるような）基礎POIを伴うPOIビルディングブロック、および、同時に存在する3Dオブジェクト（例えば、他のソースからの3Dランドマークと同様のブロックモデル）の多数のビルディングブロックが含まれる。
【００１９】
NDS仕様の変化と企画は、例えば、重複ジオコード付加オブジェクトについての格納と取扱情報のデータ構造や概念を予知していなかった。これは、（例えば）図2に破線で囲んで示す検索リストにおける同一POIの多数エントリを防ぐために、かつ、図3に示す実際に参照される同一オブジェクトであるアイコン/3D建造物の多数表示を防ぐために、NDSアプリケーションに負担を掛ける。これらは、表示画面12に提示される情報を読む個人を混乱させ、および/または、苛立たせる。さらに、この問題に対する実用的な解決策は、重複ジオコード付加オブジェクト問題を実行時だけでなく後の参照用に記録または保存して解決せねばならず、永続的である必要がある。一方、実行時の後の参照のためのプリコンパイルされた情報を導く、ジオコード付加オブジェクトの重複排除の努力はNDSのコンパイル時に発生する。
【００２０】
本発明の概念は、NDSまたは他の適切な物理ストレージ形式(PSF)のビルディングブロックに内側または外側で関連する拡張データ構造を提案して、相互参照情報の格納、並びに、ジオコード付加オブジェクト（あるいは、オブジェクトプロパティまたはオブジェクト属性）が有すべき選択または提示の優先度についての優先情報(preference information)を扱うことである。後述するように、優先情報は、最新の更新に基づく、属性のリッチさ、動的補助コンテンツへのリンク、または、他の関連ファクタである。
【００２１】
本発明の一実施例によれば、相互参照情報は、異なる製品データベースのジオコード付加オブジェクトの間の相互参照を確定するためにオーバヘッドデータ構造として例えばテーブルに全世界レベルで格納されている。定義として、製品データベースは、特定のコンテンツプロバイダによってコンパイルされた地図コンテンツである。各製品データベースは、所定のPSF地図データベースの個別のインスタンスとして扱われる。参照されるデータまたはテーブルは、オブジェクト情報として、オブジェクト1、オブジェクト2、および、補足情報を含む。オブジェクト1と2の参照データは、Product Database Identification（製品データベースID）、Update Region Identification（更新地域ID） 、Building Block Type（ビルディングブロックタイプ）、Building Block Identification（ビルディングブロックID）およびObject Identification（オブジェクトID）などの詳細を含む。この参照データは例えば図4に示される。補足情報は優先データなどを含む。
【００２２】
これら相互参照は、異なるビルディングブロックが一緒に生成される際のコンパイル時に予め計算されるか、あるいは、実行時にナビゲーションアプリケーションによってオンザフライ計算されることが好ましい。結果は、ナビゲーションアプリケーションによって、そのようなテーブルに永続的に格納される。現実の同一物体に対応するジオコード付加オブジェクトをそれぞれ含む異なるデータソースに由来するビルディングブロックを識別する原理は、さらに、空間的な近さ、並びに、オブジェクトプロパティ、属性、オブジェクトタイプ、オブジェクトクラス、オブジェクト名、および、オブジェクトアドレスほかの比較に基づく考慮を含む。
【００２３】
本発明の別の実施例によれば、地図ベンダおよび/またはNDSコンパイルハウスはオールインワンNDS製品をコンパイルする。POIコンテンツや3Dコンテンツは一つ以上のビルディングブロックに細分化され、相互参照情報が生成される。以前から、NDS製品は、コア製品（例えば、POIがないか単一POIのビルディングブロック）と、ネットワークに接続されたナビゲーション装置10によって後にダウンロードされるアドオン製品（例えば拡張POIコンテンツ）に分けて市場に供給されている。ナビゲーション装置10が使用するNDS製品は、ディレクトリ形式において、Google Earthからの3Dオブジェクトの転送などのユーザソースコンテンツによって拡張される。このユーザソースコンテンツは別のビルディングブロックに格納される。装置10によって実行されるナビゲーションアプリケーションは、実行時に、重複ジオコード付加オブジェクトが一つ以上のビルディングブロックに存在するかを判定する。重複ジオコード付加オブジェクトが識別された場合、ナビゲーションアプリケーションは、後の再利用のためのオーバヘッド構造に相互参照情報を記録する。ユーザは、ナビゲーションアプリケーションが検出したジオコード付加オブジェクトが本当に重複しているか否かの確認を求められる場合がある。
【００２４】
別の実施例において、相互参照情報は、ビルディングブロックの内側でのみ相互参照を記録し維持する意図で、POIや3Dオブジェクトに関連するコンテンツのような既存のビルディングブロックに関して提供される。ビルディングブロックのコンテンツが少しずつ更新かつ拡張されるならば、プリコンパイルされた相互参照は（これまでに確定されているなら）、実行時に決定される追加の相互参照により動的に維持することができる。
【００２５】
相互参照データ構造の異なる実施例が適切な可能性がある。ある場合、データ構造が実際のビルディングブロックの外側に実装され、二つ以上の他のビルディングブロックからのオブジェクトがリンクされる。別の実装において、データ構造は実際のビルディングブロックの内側にあり、ビルディングブロックの一つだけに実装する第一の方法か、相互参照ジオコード付加オブジェクトを伴う、二つのビルディングブロックに実装する第二の方法の何れかである。これらデータ構造は、一つ以上の他のビルディングブロックにおけるジオコード付加オブジェクトにリンクする。
【００２６】
本発明によれば、（相互参照と優先情報(priority information)の形式における）特別なオーバヘッドがNDSのようなナビゲーションランタイム形式内部の3DオブジェクトとPOIのデータ構造に追加され、3DビルディングブロックまたはPOIビルディングブロックが多数回発生し、整合性または独自性がビルディングブロックの内側だけで管理され、別のビルディングブロックの間で管理されることはない。本発明によるオーバヘッドデータ構造は、異なるビルディングブロックにおける重複ジオコード付加オブジェクトの間の永続的な相互参照のための手段の提供と、その後、ナビゲーション装置10を介して実行される、ナビゲーションアプリケーションによる実行時重複努力(run-time duplication efforts)の構造的なサポートにより、NDSにおける概念的ギャップを埋める。
【００２７】
図6は、簡易な用語により、上述した本発明の方法の手順を説明する。相互参照と重複排除のための、ここに提案する方法とデータ構造は、NDSコンパイル処理において役割を果たす。製品コンセプトに依存して、地図ベンダは、複数のPOIビルディングブロック（または3Dオブジェクトビルディングブロックほか）を追加(populate)のために選択する。さらに、方法とデータ構造は、ソフトウェア開発と実行時動作の両面に関して、ナビゲーションアプリケーションにおいて使用することができる。対応する原理は、対応する（つまり重複する）ジオコード付加オブジェクトの間の相互参照を導く前処理において、または、当該相互参照を導く実行時に存在する処理として、多数のPOIまたは3Dオブジェクトデータベースとともに（NDS以外の形式を使用する）ホスト役のデータにも適用される。
【００２８】
従って、同一ビルディングブロックの内側または異なるビルディングブロックに由来する重複ジオコード付加オブジェクトの識別に使用される方法を実行する方法と地図データベースシステムが実装された装置とともに、本発明の方法は、適切な優先度を付与し、それら優先度を比較する。そして、アプリケーションにおいて使用するために最高の優先度をもつ、一つのビルディングブロックを選択するか、ビルディングブロック内のジオコード付加オブジェクトの特定のインスタンスの一つの属性/プロパティを選択する。そして、装置と本発明の方法は、「クリーンアップされた」行き先リストまたは地図表現形式における、適切な装置10の表示画面12上の排他的な表示を含む。
【００２９】
上述の発明は、関連する法的基準に従って記載され、従って説明は本質的な制限ではなく例示である。開示した実施例の変形および変更は、本発明の範囲内において、当業者には明らかである。
【特許請求の範囲】
【請求項１】
一つ以上の外部ソースからのビルディングブロック形式のデータをディジタル地図に統合して、ディジタル地図のコンテンツの価値を高める方法であって、
現実の道路ネットワークに対応するディジタル化情報を含み、現実の物体に関連するディジタル化されたジオコード付加オブジェクトを含むビルディングブロックを少なくとも一つ有するディジタル地図を提供するステップと、
現実の同一物体に対応する追加のディジタル化されたジオコード付加オブジェクトを含む追加のビルディングブロックを提供するステップと、
前記追加のビルディングブロックを前記ディジタル地図に統合するステップと、
前記現実の同一物体に対応するビルディングブロックそれぞれからジオコード付加オブジェクトを識別するステップと、
前記識別されたジオコード付加オブジェクトそれぞれに優先度を付与するステップと、
前記優先度を相互比較するステップと、
前記識別された複数のジオコード付加オブジェクトの中から、ディジタル地図アプリケーションに使用される場合に最高の優先度を有する一つのジオコード付加オブジェクトを選択するステップとを有することを特徴とする方法。
【請求項２】
一つ以上の外部ソースからのビルディングブロック形式のデータをディジタル地図に統合して、ディジタル地図のコンテンツの価値を高める方法であって、
現実の道路ネットワークに対応するディジタル化情報を含み、現実の物体の属性に関連するディジタル化されたジオコード付加オブジェクト属性を含むビルディングブロックを少なくとも一つ有するディジタル地図を提供するステップと、
現実の同一物体属性に対応する追加のディジタル化されたジオコード付加オブジェクト属性を含む追加のビルディングブロックを提供するステップと、
前記追加のビルディングブロックを前記ディジタル地図に統合するステップと、
前記現実の同一物体属性に対応するビルディングブロックそれぞれからジオコード付加オブジェクト属性を識別するステップと、
前記識別されたジオコード付加オブジェクト属性それぞれに優先度を付与するステップと、
前記優先度を相互比較するステップと、
前記識別された複数のジオコード付加オブジェクト属性の中から、ディジタル地図アプリケーションに使用される場合に最高の優先度を有する一つのジオコード付加オブジェクト属性を選択するステップとを有することを特徴とする方法。
【請求項３】
前記少なくとも一つのビルディングブロックと前記追加のビルディングブロックは共通のビルディングブロックに関係し、前記現実の同一物体に対応する前記二つのジオコード付加オブジェクトおよび/または属性は前記同一のビルディングブロックに含まれることを特徴とする請求項1または請求項2に記載された方法。
【請求項４】
前記ディジタル地図アプリケーションの使用は、後の参照のための記録と保存を含むことを特徴とする請求項1から請求項3の何れか一項に記載された方法。
【請求項５】
前記ディジタル地図アプリケーションの使用は、前記ディジタル地図における表示を含むことを特徴とする請求項1から請求項4の何れか一項に記載された方法。
【請求項６】
さらに、電子計算装置(10)の表示画面(12)上にディジタル地図の少なくとも一部を提示するステップを有し、
前記提示するステップは、前記現実の物体のグラフィカル表現として前記ビルディングブロックのコンテンツを表示するステップを含むことを特徴とする請求項1から請求項5の何れか一項に記載された方法。
【請求項７】
前記提示するステップは、ジオコード付加オブジェクトのリストの一部として前記ビルディングブロックのコンテンツを表示するステップを含むことを特徴とする請求項5に記載された方法。
【請求項８】
前記優先度を付与するステップは、各ジオコード付加オブジェクトおよび/またはその属性の前記ディジタル化情報が最後に更新された最新の日付を査定するステップを含むことを特徴とする請求項1から請求項7の何れか一項に記載された方法。
【請求項９】
前記優先度を付与するステップは、各ジオコード付加オブジェクトおよび/またはその属性の属性コンテンツのリッチさのレベルを査定するステップを含むことを特徴とする請求項1から請求項8の何れか一項に記載された方法。
【請求項１０】
前記優先度を付与するステップは、各ジオコード付加オブジェクトおよび/またはその属性の動的リンク補助コンテンツの存在を査定するステップを含むことを特徴とする請求項1から請求項9の何れか一項に記載された方法。
【請求項１１】
前記優先度を付与するステップは、各ジオコード付加オブジェクトおよび/またはその属性の使用条件を査定するステップを含むことを特徴とする請求項1から請求項10の何れか一項に記載された方法。
【請求項１２】
前記重複を識別するステップは、ジオコード付加オブジェクトの前記道路ネットワークに対する空間的近さ、および/または、互いの空間的近さを見積るステップを含むことを特徴とする請求項1から請求項11の何れか一項に記載された方法。
【請求項１３】
前記重複を識別するステップは、各ビルディングブロックに付与されたオブジェクト名および/またはオブジェクトストリートアドレスを評価するステップを含むことを特徴とする請求項1から請求項12の何れか一項に記載された方法。
【請求項１４】
前記優先度を付与するステップおよび/または前記重複を識別するステップは、他のジオコード付加オブジェクトの特定のインスタンスを選択するためのユーザインタラクションを含むことを特徴とする請求項1から請求項10の何れか一項に記載された方法。
【請求項１５】
請求項1または請求項2の方法に従って、ディジタル地図を表示し、並びに/あるいは、参照情報の記録および/または格納を行うナビゲーション装置(10)。
【請求項１】
一つ以上の外部ソースからのビルディングブロック形式のデータをディジタル地図に統合して、ディジタル地図のコンテンツの価値を高める方法であって、
現実の道路ネットワークに対応するディジタル化情報を含み、現実の物体に関連するディジタル化されたジオコード付加オブジェクトを含むビルディングブロックを少なくとも一つ有するディジタル地図を提供するステップと、
現実の同一物体に対応する追加のディジタル化されたジオコード付加オブジェクトを含む追加のビルディングブロックを提供するステップと、
前記追加のビルディングブロックを前記ディジタル地図に統合するステップと、
前記現実の同一物体に対応するビルディングブロックそれぞれからジオコード付加オブジェクトを識別するステップと、
前記識別されたジオコード付加オブジェクトそれぞれに優先度を付与するステップと、
前記優先度を相互比較するステップと、
前記識別された複数のジオコード付加オブジェクトの中から、ディジタル地図アプリケーションに使用される場合に最高の優先度を有する一つのジオコード付加オブジェクトを選択するステップとを有することを特徴とする方法。
【請求項２】
一つ以上の外部ソースからのビルディングブロック形式のデータをディジタル地図に統合して、ディジタル地図のコンテンツの価値を高める方法であって、
現実の道路ネットワークに対応するディジタル化情報を含み、現実の物体の属性に関連するディジタル化されたジオコード付加オブジェクト属性を含むビルディングブロックを少なくとも一つ有するディジタル地図を提供するステップと、
現実の同一物体属性に対応する追加のディジタル化されたジオコード付加オブジェクト属性を含む追加のビルディングブロックを提供するステップと、
前記追加のビルディングブロックを前記ディジタル地図に統合するステップと、
前記現実の同一物体属性に対応するビルディングブロックそれぞれからジオコード付加オブジェクト属性を識別するステップと、
前記識別されたジオコード付加オブジェクト属性それぞれに優先度を付与するステップと、
前記優先度を相互比較するステップと、
前記識別された複数のジオコード付加オブジェクト属性の中から、ディジタル地図アプリケーションに使用される場合に最高の優先度を有する一つのジオコード付加オブジェクト属性を選択するステップとを有することを特徴とする方法。
【請求項３】
前記少なくとも一つのビルディングブロックと前記追加のビルディングブロックは共通のビルディングブロックに関係し、前記現実の同一物体に対応する前記二つのジオコード付加オブジェクトおよび/または属性は前記同一のビルディングブロックに含まれることを特徴とする請求項1または請求項2に記載された方法。
【請求項４】
前記ディジタル地図アプリケーションの使用は、後の参照のための記録と保存を含むことを特徴とする請求項1から請求項3の何れか一項に記載された方法。
【請求項５】
前記ディジタル地図アプリケーションの使用は、前記ディジタル地図における表示を含むことを特徴とする請求項1から請求項4の何れか一項に記載された方法。
【請求項６】
さらに、電子計算装置(10)の表示画面(12)上にディジタル地図の少なくとも一部を提示するステップを有し、
前記提示するステップは、前記現実の物体のグラフィカル表現として前記ビルディングブロックのコンテンツを表示するステップを含むことを特徴とする請求項1から請求項5の何れか一項に記載された方法。
【請求項７】
前記提示するステップは、ジオコード付加オブジェクトのリストの一部として前記ビルディングブロックのコンテンツを表示するステップを含むことを特徴とする請求項5に記載された方法。
【請求項８】
前記優先度を付与するステップは、各ジオコード付加オブジェクトおよび/またはその属性の前記ディジタル化情報が最後に更新された最新の日付を査定するステップを含むことを特徴とする請求項1から請求項7の何れか一項に記載された方法。
【請求項９】
前記優先度を付与するステップは、各ジオコード付加オブジェクトおよび/またはその属性の属性コンテンツのリッチさのレベルを査定するステップを含むことを特徴とする請求項1から請求項8の何れか一項に記載された方法。
【請求項１０】
前記優先度を付与するステップは、各ジオコード付加オブジェクトおよび/またはその属性の動的リンク補助コンテンツの存在を査定するステップを含むことを特徴とする請求項1から請求項9の何れか一項に記載された方法。
【請求項１１】
前記優先度を付与するステップは、各ジオコード付加オブジェクトおよび/またはその属性の使用条件を査定するステップを含むことを特徴とする請求項1から請求項10の何れか一項に記載された方法。
【請求項１２】
前記重複を識別するステップは、ジオコード付加オブジェクトの前記道路ネットワークに対する空間的近さ、および/または、互いの空間的近さを見積るステップを含むことを特徴とする請求項1から請求項11の何れか一項に記載された方法。
【請求項１３】
前記重複を識別するステップは、各ビルディングブロックに付与されたオブジェクト名および/またはオブジェクトストリートアドレスを評価するステップを含むことを特徴とする請求項1から請求項12の何れか一項に記載された方法。
【請求項１４】
前記優先度を付与するステップおよび/または前記重複を識別するステップは、他のジオコード付加オブジェクトの特定のインスタンスを選択するためのユーザインタラクションを含むことを特徴とする請求項1から請求項10の何れか一項に記載された方法。
【請求項１５】
請求項1または請求項2の方法に従って、ディジタル地図を表示し、並びに/あるいは、参照情報の記録および/または格納を行うナビゲーション装置(10)。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公表番号】特表２０１３−５１３８２９（Ｐ２０１３−５１３８２９Ａ）
【公表日】平成２５年４月２２日（２０１３．４．２２）
【国際特許分類】
【出願番号】特願２０１２−５４３６１８（Ｐ２０１２−５４３６１８）
【出願日】平成２２年１２月９日（２０１０．１２．９）
【国際出願番号】ＰＣＴ／ＥＰ２０１０／０６９２８７
【国際公開番号】ＷＯ２０１１／０７３０８１
【国際公開日】平成２３年６月２３日（２０１１．６．２３）
【出願人】（５１２１０６６７６）トムトム ジャーマニー ゲーエムベーハー ウント コー． カーゲー (3)
【氏名又は名称原語表記】ＴＯＭＴＯＭ ＧＥＲＭＡＮＹ ＧＭＢＨ ＆ ＣＯ． ＫＧ
【住所又は居所原語表記】Ａｍ Ｎｅｕｅｎ Ｈｏｒｉｚｏｎｔ １ Ｄ−３１１７７ Ｈａｒｓｕｍ Ｇｅｒｍａｎｙ
【Ｆターム（参考）】
【公表日】平成２５年４月２２日（２０１３．４．２２）
【国際特許分類】
【出願日】平成２２年１２月９日（２０１０．１２．９）
【国際出願番号】ＰＣＴ／ＥＰ２０１０／０６９２８７
【国際公開番号】ＷＯ２０１１／０７３０８１
【国際公開日】平成２３年６月２３日（２０１１．６．２３）
【出願人】（５１２１０６６７６）トムトム ジャーマニー ゲーエムベーハー ウント コー． カーゲー (3)
【氏名又は名称原語表記】ＴＯＭＴＯＭ ＧＥＲＭＡＮＹ ＧＭＢＨ ＆ ＣＯ． ＫＧ
【住所又は居所原語表記】Ａｍ Ｎｅｕｅｎ Ｈｏｒｉｚｏｎｔ １ Ｄ−３１１７７ Ｈａｒｓｕｍ Ｇｅｒｍａｎｙ
【Ｆターム（参考）】
[ Back to top ]