JP6434440B2 - 位置コードデータを更新するための方法及びシステム - Google Patents

Description

本発明は、一般に、位置ベースのシステムに関し、より具体的には、位置コードデータを更新するための方法及びシステムに関する。

〔関連出願の参照〕
本特許出願は、同じ日に出願された同時係属特許出願、すなわち「ＭＥＴＨＯＤ ＡＮＤ ＳＹＳＴＥＭ ＦＯＲ ＡＳＳＥＳＩＮＧ ＱＵＡＬＩＴＹＯＦ ＬＯＣＡＴＩＯＮ ＣＯＮＴＥＮＴ」という名称の特許出願番号第１２／３６２,７３４号、「ＭＥＴＨＯＤ ＡＮＤ ＳＹＳＴＥＭ ＦＯＲ ＭＡＮＡＧＩＮＧ ＲＥＬＡＴＩＯＮＳＨＩＰＳ ＢＥＴＷＥＥＮ ＬＯＣＡＴＩＯＮ ＩＤＥＮＴＩＦＩＥＲＳ」という名称の特許出願番号第１２／３６２,７５１号、「ＭＥＴＨＯＤ ＦＯＲ ＲＥＰＲＥＳＥＮＴＩＮＧ ＬＩＮＥＡＲ ＦＥＡＴＵＲＥＳ ＩＮ Ａ ＬＯＣＡＴＩＯＮ ＣＯＮＴＥＮＴ ＭＡＮＡＧＥＭＥＮＴ ＳＹＳＴＥＭ」という名称の特許出願番号第１２／３６２,７８６号、及び「ＭＥＴＨＯＤ ＡＮＤ ＳＹＳＴＥＭ ＦＯＲ ＥＸＣＨＡＮＧＩＮＧ ＬＯＣＡＴＩＯＮ ＣＯＮＴＥＮＴ ＤＡＴＡ ＩＮ ＤＩＦＦＥＲＥＮＴ ＤＡＴＡ ＦＯＲＭＡＴＳ」という名称の特許出願番号第１２／３６２,８０７号に関連する。

ナビゲーション関連サービス及び地図関連サービスを提供する各種の技術が開発されている。例えば、車両ナビゲーションシステムは、車両が位置する場所を判定し、所望の目的地に移動するための方向を与えることができる。また、地図、指定されたスタート地点から所望の目的地に移動するための方向、及び他の地図関連サービスを提供するインターネットサイトも入手可能である。さらに、自分の位置を確認し、その周囲の地図を提供する手持ち式装置も利用可能である。

これらの及びその他の地図関連機能及び特徴を提供するために、ナビゲーションシステムは、地理データを使用する。地理データは、地理的地域における物理的特徴を表すデータを含む、１つ又はそれ以上の地理データベースの形態とすることができる。地理データベースは、一方通行路のような表された地理的特徴、道路の位置、道路区間に沿った速度規制、道路区間に沿った住所範囲、道路の交差点における転回規制、一方通行路のような通行方向規制についての情報を含む。さらに、地理データは、レストラン、ホテル、空港、ガソリンスタンド、スタジアム、警察署などの、関心ある地点（ｐｏｉｎｔ ｏｆ ｉｎｔｅｒｅｓｔ）を含むことができる。

この地理データは、イリノイ州シカゴ所在のＮＡＶＴＥＱ Ｎｏｒｔｈ Ａｍｅｒｉｃａ，ＬＬＣ社が発行した地理データベースのような地理データベース内に格納することができる。地図提供業者（ｍａｐ ｖｅｎｄｏｒ）が取得したデータに加えて、コンテンツ供給源は、地理的区域における位置に関するデータを保有する。コンテンツ供給源は、地理データベース内に含ませるために、それらのデータを地図提供業者に与えることができる。例えば、レストランチェーンの所有者は、それらの全ての位置の最新リストを地図提供者に与えることができ、その位置ごとに、このリストは、住所、電話番号、営業時間、メニュー、ウェブページアドレス、位置に関する他の情報を含むことができる。

地理データベース内に格納された情報量が増加すると、地図提供業者は地理データベースに第三者データを加えることがより困難になる。結果として、位置コンテンツ管理システムが開発され、複数の主体が時に「位置コンテンツ」又は単に「コンテンツ」と呼ばれる位置に関連するデータを提供できるようになった。位置コンテンツ管理システムは、位置コンテンツとコンテンツに関連付けられた地理的位置との間のリンクを提供する。リンクは、位置コンテンツ管理システムが位置に割り当てる位置コードである。

位置コードは、人が旅行できる任意の位置に割り当てられる。例えば、ある人が、ある地理的区域内の特定のビルの特定の階にある事務所に行きたい場合がある。この例を使うと、位置コンテンツ管理システムはまた、事務所、階、及びビルのそれぞれにも位置コードを割り当てる。位置コンテンツ管理システムはまた、その階がビルの１階にない場合、階段及び／又はエレベータに位置コードを割り当てることもできる。このように位置コードを割り当てることにより、ナビゲーションシステムは、ビル内の事務所へ行くための経路案内をユーザに提供することができる。

位置コンテンツ管理システムは、位置に関するコンテンツを提供する方法を複数の関係者（ｐａｒｔｙ）に提供するが、位置コンテンツ管理システムにおける新たな特徴及び改善の余地が引き続き存在する。１つの改善領域は、位置コードデータの更新である。位置コードデータは、地理的基準データ及び地図基準データを含む。位置コードデータを頻繁に更新することにより、位置コードデータのユーザが、正確なデータを取得する可能性が高くなる。

位置コードデータを更新するための方法及びシステムが開示される。このシステムは、位置コード変更システムを含む。位置コード変更システムは、地図変更を地図変更システムから取得し、位置コード変更を位置コード変更システムから取得する。地図変更システムは、地図の変更を地図システムから取得する。

位置コード変更システムは、地図の変更が位置コードに影響するかどうかを判断する。位置コードに影響する場合、位置コード変更システムは、影響された位置コードを取り出し、かつ、位置コードデータを直接操作すること、又は、ジオコーディング操作を行うことによって、関連した位置コードデータに適切な変更を加える。ジオコーディング操作は、標準（ｆｏｒｗａｒｄ）ジオコーディング操作（すなわち、位置コードは住所情報を含む）としてもよく、或いは逆ジオコーディング操作（すなわち、位置コードは住所情報を含まない）としてもよい。

位置コード変更システムが位置コードシステムから位置コードの変更を受信すると、位置コード変更システムは、地図データを更新するために、位置コード変更を地図変更システムに送るべきかどうかを判断する。送られた場合、地図変更システムは、地図更新要求を地図システムに送り、地図システムが地図データに適切な変更を加え得るようにする。

当業者には、必要に応じて添付図面を参照して以下の詳細な説明を読むことにより、これらの及び他の態様並びに利点が明らかになるであろう。さらに、この概要は、一例にすぎず、本発明の範囲を特許請求されたように限定することを意図するものではない。

現在のところ好ましい実施形態が、種々の図において同様の参照番号が同様の要素を指す、添付図面と併せて以下に説明される。

一例による、データ更新システムのブロック図である。 一例による、地図変更システムのブロック図である。 一例による、位置コード変更システムのブロック図である。 一例による、データ更新プロセスの流れ図である。 一例による、位置コード・エンティティのブロック図である。 一例による、地図基本線のシフトのプロセス図である。

図１は、データ更新システム１００のブロック図である。データ更新システム１００は、地図システム１０２、地図変更システム１０４、位置コード変更システム１０６、及び位置コードシステム１０８を含む。データ更新システム１００は、位置コードデータ及び地図データを更新し、このデータのユーザが頻繁に更新されたデータを取得できるようにする。

地図システム１０２は、地図データを付加し、更新し、削除するために、記憶装置、プログラム、及びインターフェースを提供する。地図提供業者は、地図作成及び編集手続きを管理する自らの地図データモデル及びプロセスに応じて、異なるマップシステム１０２の実装を有し得る。図１に１つの地図システムを示すが、各地図提供業者が、それぞれの地図システムを有し得ることが理解される。

地図システム１０２は、データ接続１０１を介して地図変更システム１０４に地図の変更を送る。地図の変更は、新しい地図データ、更新された地図データ、及び削除された地図データを含むことができる。データ接続１０１は、地図の変更を地図システム１０２から地図変更システム１０４に伝送するように動作可能ないずれかのタイプの有線又は無線接続とすることができる。データ接続１０１は、所定のスケジュール又は手動の要求に基づいて、地図変更を連続的又は断続的に伝送する。

地図変更システム１０４は、データ接続１０１を介して地図システム１０２から受信した地図の変更を処理する。地図変更システム１０４は、地図の変更を内部システム及び／又は外部システムに配信するために、必要に応じて変更された地図データを格納し、操作する。地図変更システム１０４は、地図データ変更要求を処理するために使用することもできる。地図変更システム１０４の一例を図２に示す。

地図変更システム１０４から地図変更を受信する外部システムの一つが、位置コード変更システム１０６である。地図変更システム１０４は、データ接続１０３を使用して変更された地図データを外部システムに送るために、データ接続１０３を使用する。データ接続１０３は、地図変更を地図変更システム１０４から位置コード変更システム１０６に伝送するように動作可能ないずれかのタイプの有線又は無線接続とすることができる。

データ接続１０３は、位置コード変更システム１０６などの外部システムに地図変更を送るためにプッシュ・プル機構をイネーブルにする。さらに、データ接続１０３は、有線及び無線ネットワーク上で地図変更を要求し、送信するために、伝送機構に加えて、多くのプログラマチック・インターフェース及びヒューマン・インターフェースを可能にする。異なるネットワーク・プロトコルを用いて、インターネット及びインターネット・ネットワーク上で地図変更を配信することができる。データ接続１０３はまた、情報を内部及び外部の消費者に送る前に、全ての必要なデータ圧縮及び暗号化も実行する。

位置コード変更システム１０６は、地図変更に基づいて位置コードデータを更新する。位置コード変更システム１０６は、データ接続１０５を介して、更新された位置コードデータを位置コードシステム１０８に提供する。データ接続１０５は、位置コード変更を位置コード変更システム１０６から位置コードシステム１０８に伝送するように動作可能ないずれのタイプの有線又は無線接続であってもよい。例えば、位置コード変更システム１０６は、データ接続１０５を介して、地図参照及び地理参照の更新を位置コードシステム１０８に送る。データ接続１０５は、更新を位置コードデータに迅速に配信するために、高処理量及び低待ち時間のネットワーク向けに最適化されることが好ましい。位置コード変更システムの一例を図３に示す。

位置コードシステム１０８は、位置コードデータを格納し保持するハードウェア、ソフトウェア、及び／又はファームウェアの組み合わせである。例えば、位置コードシステム１０８は、位置コードデータについてのデータ構造を格納するメモリを含む。メモリは、読み取り／書き込みアクセスを可能にするいずれのタイプのメモリであってもよい。同様に、いずれのタイプのデータ構造を使用してもよい。位置コードシステム１０８のメモリに格納できる位置コード・エンティティの一例を図５に示す。

位置コード変更システム１０６は、データ転送に適したいずれのタイプの有線又は無線接続にすることができるデータ接続１０７を介して、位置コードシステム１０８において生じた位置コードデータの変更を受信する。データ接続１０７は、高処理量及び低待ち時間のネットワーク向けに最適化されることが好ましいが、データ接続１０７は、より低速ネットワーク上で更新を送ることもできる。さらに、データ伝送は、非トランザクションであることが好ましく、その結果、より遅く信頼度が低い広域ネットワーク（ＷＡＮ）をサポートするために、付加的なオーバーヘッドが位置コードシステム１０８にかからない。

位置コード変更の一部は、データ接続１０９を介して地図変更システム１０４に通知することにより地図データを変更するために使用することができる。データ接続１０９は、位置コード変更を位置コード変更システム１０６から地図変更システム１０４に伝送するように動作可能ないずれのタイプの有線又は無線接続であってもよい。例えば、専門家コミュニティ（ｅｘｐｅｒｔ ｃｏｍｍｕｎｉｔｙ）が、位置コードの位置の正確度を調整するために、位置コードデータ及び地図参照を変更する場合がある。この変更は、位置コードシステム１０８により受け入れられ、次に位置コードシステム１０８が、データ接続１０７を介して位置コード変更システム１０６に通知する。

次に、位置コード変更システム１０６は、地図を更新するために、この変更を地図変更システム１０４にも伝達すべきかどうかを判断する。地図変更システム１０４は、データ接続１０９を介して変更情報を受信し、その情報を地図システム１０２と両立性のある地図更新要求に変換する。データ接続１０９は、地図更新要求を安全かつ効率的に伝送するために、データ暗号化及び／又はデータ圧縮を行うこともできる。

データ接続１１１は、地図変更システム１０４がデータ接続１０９を介して受信した要求を受け入れた場合に、地図変更を地図システム１０２に送るために使用される。データ接続１１１は、地図更新を地図変更システム１０４から地図システム１０２に伝送するように動作可能ないずれのタイプの有線又は無線接続であってもよい。データ接続１１１は、地図更新情報を迅速に配信するために、高処理量及び低待ち時間のネットワーク向けに最適化されることが好ましい。データ接続１１１はまた、情報の配信のためのトランザクションサポートも提供することができる。

図２は、図１に示す地図変更システム１０４のように使用できる、例示的な地図変更システム２００のブロック図である。他の地図変更システム設計を使用してもよい。地図変更システム２００は、地図データ記憶装置２０１、タイマー２０２、データ接続２０３、手動データ転送コンポーネント２０４、地図変更データ記憶装置２０５、及び地図変更インターフェース２０６を含む。地図データ変更システム２００は、他のコンポーネントを有することもできる。

地図データ記憶装置２０１は、特定の地図提供業者のフォーマットである地図データを含む。地図データは、リレーショナル・データベースのフォーマット、ファイルベースのフォーマット、又は永続的なデータ格納に適した他のいずれかのデータフォーマットで格納することができる。地図データ記憶装置２０１は、生の製品地図データ又は製品地図データの複写のいずれかを含む。地図データ記憶装置２０１に使用されるデータスキーマは、地図システム１０２におけるデータスキーマと同調していることが好ましい。

タイマー２０２は、地図変更を取り出し、送るためのスケジュールを作成するために使用される。タイマー２０２は、地図変更を地図変更データ記憶装置２０５に送るプロセスを開始し、停止する。故障した場合、タイマー・コンポーネント２０２がエラーを記録し、システム管理者に通知し、及び／又はプロセスの再開を試みる。

データ接続２０３は、地図変更を地図データ記憶装置２０１から地図変更データ記憶装置２０５に流すために使用される。地図データ記憶装置２０１は、地図変更を地図変更データ記憶装置２０５に連続的に流すことが好ましいが、地図変更は、非連続的に地図変更データ記憶装置２０５に提供されてもよい。データ接続２０３は、保証付きデータ配信機構により、高処理量及び低待ち時間のネットワーク向けに最適化されることが好ましい。異なる技術を用いて、各変更を記述するのに十分な差分情報（ｄｅｌｔａ ｉｎｆｏｒｍａｔｉｏｎ）のみを送ることができる。より効率的な配信のために、地図データを圧縮することができる。

手動データ転送コンポーネント２０４を用いて、地図変更を取り出し、送るプロセスを手動で開始することができる。手動データ転送コンポーネント２０４は、地図変更を地図変更データ記憶装置２０５に送るプロセスを開始し、停止するために使用できる一組のプログラマチック・インターフェース及び／又はヒューマン・インターフェースを有する。

地図データ変更記憶装置２０５は、地図変更を記述するデータを格納する。地図変更データ記憶装置２０５は、リレーショナル・データベースのフォーマット、フラット型及び階層型ファイルフォーマット、又は永続的データ格納に適した他のいずれかのデータフォーマットで地図変更を保持する。地図変更データ記憶装置２０５は、時系列順での効率的なデータアクセスのために最適化されることが好ましい。

地図変更インターフェース２０６は、地図変更を取り出すために使用できる一組のプログラマチック・インターフェース及び／又はヒューマン・インターフェースである。地図変更インターフェース２０６は、地図変更を取り出すためにプッシュプル機構の両方をサポートすることが好ましい。内部及び／又は外部のエンティティは、１つ又はそれ以上の選択された基準に基づいて、変更された地図データを自動的に受信するよう登録することができる。例えば、外部システムは、ユーザ定義の地理的区域内に新しい道路の幾何学的形状が付加されたときに地図の更新を受け取るように登録することができる。プルベースのＡＰＩは、既定の基準なしに、地図変更をオンデマンド（アドホック）で抽出したいと思うユーザに適している。これらのＡＰＩは、特に外部システムが広域ネットワーク（ＷＡＮ）を介してデータセットにアクセスしている際、より小さいデータセットの交換に適している。プッシュプル・インターフェース及びＡＰＩの両方とも、地図変更の安全なトランザクションの配信を可能にする。

図３は、図１に示した地図変更システム１０４のように使用できる、例示的な位置コード変更システム３００のブロック図である。他の位置コード変更システム設計が使用されてもよい。位置コード変更システム３００は、地図変更レシーバ３０１、地図変更リクエスタ３０２、要求スケジューラ３０３、ユーザ・インターフェース３０４、地図変更プロセッサ３０５、変更プロセス・メタデータ・リポジトリ３０６、地図変更キュー３０７、キュー・リスナ（ｌｉｓｔｅｎｅｒ）３０８、キュー・フィルタ３０９、位置コード・アップデータ（ｕｐｄａｔｅｒ）３１０、ジオコーダ３１１、ジオコーダデータ記憶装置３１２、位置コード変更レシーバ３１３、及び位置コード変更ノーティファイア（ｎｏｔｉｆｉｅｒ）３１４を含む。地図変更システム３００は、他のコンポーネントを有してもよい。

地図変更レシーバ３０１（ここではレシーバ３０１と呼ぶ）は、データ接続１０３によって、地図変更システム２００から地図変更を受信する。レシーバ３０１は、地図変更インターフェース２０６からデータパケットを受け取ることにより、地図変更データを「リッスン（ｌｉｓｔｅｎ）」する。レシーバ３０１は、ネットワーク上には地図変更を受け取る多くの物理的コンポーネントがあるため、ローカル・ネットワーク又は公的ネットワーク上で一意に識別可能であり、アクセス可能であることが好ましい。レシーバ３０１は、地図更新を送る地図変更システム２００の認証及び許可を行う。

レシーバ３０１は、同時に異なる地図提供業者から地図更新を受信できることが好ましい。さらに、好ましくは、レシーバ３０１は、同時に異なる地図バージョンからの地図更新を受信することができる。地図変更システム２００は、地図提供業者及び地図バージョン情報により地図変更を識別する。地図変更システム２００及びレシーバ３０１は、地図変更を取り出すためのプッシュベースの機構を形成する。データプッシュは、トランザクション操作又は非トランザクション操作として行うことができる。

地図変更リクエスタ３０２（ここではリクエスタ３０２と呼ぶ）は、地図変更システム２００からの地図変更の要求を担当する。リクエスタ３０２は、地図変更インターフェース２０６を介して地図変更システム２００と対話し、地図変更を取り出すためのプルベースの機構を形成する。データ要求は、トランザクション方式で実行されることが好ましい。リクエスタ３０２は、地図変更インターフェース２０６の仕様に従う要求を出す。各々の要求について、リクエスタ３０２は、プロセス・メタデータ・リポジトリを読み取り、有効な要求メッセージを形成する。要求の重複を避けるために、うまくいった要求は、プロセス・メタデータ・リポジトリ３０６内に記録される。うまくいかなかった要求は記録され、予想される地図変更を取り出すために、繰り返し要求が試みられる。

要求スケジューラ３０３（ここではスケジューラ３０３と呼ぶ）は、地図変更を要求するためのスケジュールの作成及びその維持のために使用される。スケジューラ３０３は、スケジュールデータをプロセス・メタデータ・リポジトリ３０６内に格納する。スケジューラ３０３は、地図変更要求を出す時間になるとリクエスタ３０２に信号を送る。各地図データ提供者ごとに、異なる更新スケジュールを定めてもよい。さらに、単一の地図提供者における個々の地図バージョンについて、異なる更新スケジュールを定めることもできる。例えば、地図提供者は、２００８年第１四半期の地図バージョンの地図変更は、毎週日曜日の中部標準時（ＣＳＴ）２時に取り出されると、指定することができる。

ユーザ・インターフェース３０４は、地図変更スケジュールをセットアップし、地図変更要求を手動で開始し、停止するために、システムオペレータ及び他の権限のあるユーザにより使用される。ユーザ・インターフェース３０４を用いて、位置コード変更システム３００内で全ての実行中のプロセスを監視することもできる。

地図変更プロセッサ３０５（ここではプロセッサ３０５と呼ぶ）は、レシーバ３０１及びリクエスタ３０２により配信された地図変更データを変換する。プロセッサ３０５は、入ってくるデータを地図変更キュー３０７に押し込む。プロセッサ３０５は、プロセス・メタデータ・リポジトリ３０６を更新し、必要な場合は重複情報を削除する。例えば、同じ地図データを何度か変更し、最新の変更が必要な情報の全てを含んでいる場合、プロセッサ３０５は、以前の変更を除去する。プロセッサ３０５は、変更データを構文解析し、正規化して、システムの残りのものにも分かりやすい共通の地図変更データを作成する。

プロセス・メタデータ・リポジトリ３０６は、要求の重複を回避し、更新スケジュールを維持し、古くなったデータを排除するため、プロセスデータを格納する。プロセス・メタデータ・リポジトリ３０６は、一組の物理的データベースとして実装できるが、図３では、簡単にするために単一の論理データベースとして示される。

地図変更キュー３０７は、変更メッセージが位置コード・アップデータ３１０によって処理される前に変更メッセージを格納するデータ構造である。地図変更キュー３０７は、変更情報を保存する共通フォーマットでメッセージを保持するが、異なる地図提供者と地図バージョンとの間のメッセージ構造の変化を抽出する。一例においては、地図変更キュー３０７は、ＦＩＦＯ（先入れ先だし）原則に準拠する。勿論、地図変更キュー３０７は、変更メッセージを位置コード・アップデータ３１０に与えるための他の規則を用いることができる。

キュー・リスナ３０８は、地図変更キュー３０７からのメッセージを読み取る。図３に１つのキュー・リスナ３０８が示されるが、位置コード変更システム３００内に１つより多いキュー・リスナが存在し得る。例えば、地図変更メッセージの各々のタイプごとに、キュー・リスナ３０８が存在し得る。柔軟な構成の選択肢により、特定の地図提供業者及び／又は地図バージョンに対して付加的なリスナを作成することが可能になる。

キュー・フィルタ３０９は、位置コードデータに適用可能でない地図変更を無視する。キュー・フィルタ３０９は、プロセス・メタデータ・リポジトリ３０６を確認して適用可能な地図変更タイプのリストを取得する。結果として、位置コード変更システム３００は、特定のタイプの地図変更タイプを無視したり又は認識したりするように動的に再構成することができる。プロセス・メタデータ・リポジトリ３０６内に格納された構成に基づいて、無視された地図変更メッセージを記録するか又は地図変更キュー３０７に戻すことができる。

位置コード・アップデータ３１０は、地図変更データを処理し、影響される位置コードを見つけ、直接位置コードデータ（地理基準又は地図基準）を操作すること、又は標準ジオコーディング操作若しくは逆ジオコーディング操作を行うことにより、位置コードの情報を更新する。標準ジオコーディング操作及び逆ジオコーディング操作を行うために、ジオコーダ３１１が使用される。各々のジオコーディング要求が、地図提供業者及び地図バージョン情報により達成されるので、ジオコーダ３１１は、ジオコーダデータ記憶装置３１２内に適用可能なジオコーディング・データを見つけることができる。ジオコーダ３１１は、位置コードの地理及び地図基準データを更新するために、位置コード・アップデータ３１０により使用されたデータを戻す。

ジオコーダデータ記憶装置３１２は、ジオコーディング・データを格納するために使用される。ジオコーダデータ記憶装置３１２は、地図変更と同調しているので、ジオコーダ３１１が更新された地理基準及び地図基準を戻すことができる。各々の地図提供業者及び地図バージョンは、別個の論理データベースを有することができる。

位置コード変更レシーバ３１３は、位置コードシステム１０８から位置コードデータの更新を受信する。位置コード変更レシーバ３１３は、特定の変更に関連しないデータを除去し、データを他のシステムが許容できる共通フォーマットにフォーマットする。位置コード変更ノーティファイア３１４（ここではノーティファイア３１４と呼ぶ）は、位置コード変更レシーバ３１３から位置コード更新情報を受信する。ノーティファイア３１４は、特定の位置コード更新に関する通知を受け取ることに関心をもつシステムのリストを維持する。それらのシステムの１つは、地図変更システム１０４とすることができる。

図４は、位置コード更新プロセス４００の流れ図である。ブロック４０１において、地図変更レシーバ３０１は、地図変更システム２００から地図変更を受信する。さらに、地図変更レシーバ３０１は、位置コード変更システム３００への許可されていないアクセスを防止するためにメッセージの認証及び許可ステップを実行する。認証ステップは、特定の地図提供業者及び地図バージョンのためにとる必要がある何らかのカスタムアクションを決定する。例えば、特定の地図提供業者は、通常の優先順位の又は優先順位が低い更新よりも迅速に処理する必要がある優先順位の高い更新を送ることができる。

ブロック４０２において、地図変更プロセッサ３０５は、地図提供業者及び地図バージョン規則に応じて、地図変更データを構文解析し、正規化する。地図変更プロセッサ３０５はまた、プロセス・メタデータ・リポジトリ３０６をチェックし、ブロック４０３において受信した地図変更が位置コード更新プロセス４００に関連しているかどうかについての判断をなす。受信された地図変更が認識されるが、位置コードデータとの関連がない場合には、受信済み地図変更は単純に無視される。受信した地図変更が認識されない場合、ブロック４０４において、このイベントは、ログによりサポートされていないイベント・アクションとして記録される。

受信された地図変更が位置コード更新プロセス４００に関連している場合、ブロック４０５において、地図変更プロセッサ３０５が、正規化された地図変更データを地図変更キュー３０７内に入れる。各々の地図提供業者、地図バージョン、及び／又は地図変更タイプは、より容易なシステムのスケーリング及びプロセス優先順位付けのための別個のメッセージキューを有することができる。例えば、最新の地図バージョンに関連した変更を、最高の重要度を有するように処理する必要がある場合、プロセス・メタデータ・リポジトリ３０６は、別個のキューを使用するように、地図変更プロセッサ３０５に命令することができる。これらの判断は、いずれのシステムコンポーネントも再配置する又は再始動させることなく、実行時に行うことができる。

地図変更データを成功裏に地図変更キューに入れると、ブロック４０６において、地図変更プロセッサ３０５は、イベントデータをプロセス・メタデータ・リポジトリ３０６に記録する。地図変更システム２００が同じ情報を再び送った場合に同じ地図変更を繰り返し処理するのを回避するために、プロセス・メタデータの更新を行う。

図４の点線は、新たな地図変更を受信するたびにブロック４０１−４０６が反復されることを示している。これらの動作は、大量のデータの処理に必要とされるので、位置コードの更新のためにほんの一部しか使用されないとき、位置コード更新プロセス４００は、別個のハードウェア上でホストすることができる。

ブロック４０７において、キュー・リスナ３０８は、データ取り出し規則に従って、地図変更キュー３０７から１つ又はそれ以上の地図変更を取り出す。位置コード更新プロセス４００が成功裏に完了しない場合、地図変更メッセージは、地図変更キュー３０７に戻される。

ブロック４０８において、位置コード・アップデータ３１０は、地図変更を分析して、どの位置コードの更新が必要かを判断する。この動作の間、地図提供業者、地図バージョン、及び地図変更タイプを調べて、どのように影響された位置コードを収集するかを決定する。例えば、地図提供業者Ａが、２００８年の第１四半期の地図バージョンで定められた地点の住所に関する経路指定地点が、ある組の座標から別の組に移動したという地図変更イベントを送った場合、この地点の住所と関連した位置コードが取り出される。

ブロック４０９において、位置コード・アップデータ３１０は、位置コード更新プロセス４００を継続するかどうかを決定する。地図変更が少なくとも１つの位置コードに影響する場合、位置コード・アップデータ３１０はプロセスを継続する。位置コードに影響しない場合、ブロック４１６において、位置コード・アップデータ３１０は、プロセス・メタデータ・リポジトリ３０６を更新し、地図変更メッセージを地図変更キュー３０７から永続的に除去する。少なくとも１つの位置コードが影響される場合、位置コード・アップデータ３１０は、ジオコーダ３１１を用いて標準ジオコーディング操作又は逆ジオコーディング操作を行うか、或いは直接操作を行う。

ブロック４１０において、影響される位置コードが住所情報を含み、地図変更データに基づいて位置コードの地図基準を更新できない場合、位置コード・アップデータ３１０は、標準ジオコーディング操作を行う。標準ジオコーディング操作は、地図提供業者及び／又は地図バージョンに特有のジオコーディング・データを使用する。

ブロック４１１において、位置コード・アップデータ３１０は、影響される位置コードが住所情報を含んでおらず、地図変更データに基づいて位置コードの地図基準を更新できない場合、逆ジオコーディング操作を行う。逆ジオコーディング操作は、地図提供業者及び／又は地図バージョンに特有のジオコーディング・データを使用する。

ブロック４１２において、位置コード・アップデータ３１０は、如何なるジオコーディング操作も使用することなく、どのように位置コードを更新するかを決定する。位置コード・アップデータ３１０は、どのように位置コードを更新すべきかを判断するために地図変更データが十分な詳細を提供する場合、位置コードデータの更新を決定する。例えば、地図変更が、ある道路リンクが削除され他の道路リンクと置き変わったことを指定する場合、位置コード・アップデータ３１０は、削除されたリンクを基準とする全ての位置コードを新たに付加されたリンクに再添付する。別の例は道路名の変更である。ある道路の名前が、綴り間違いのため変更された場合、地図変更データは、旧道路名と新道路名を含むことができる。旧道路名を基準とする全ての位置コードは、ジオコーダ３１１を呼び出すことなく、新たな情報による地理基準を有することができる。

ブロック４１３において、位置コード・アップデータ３１０は、地理基準及び地図基準を作成又は更新する。地図基準は、各々の地図提供業者及び地図バージョンについて一意の情報を含むことができる。地図変更が、影響される位置コードの地図基準セクション内に存在しない地図提供業者又は地図バージョンについての情報を保持する場合、新たな地図基準が作成される。例えば、地図提供業者Ａは、その地図の新しい地図バージョンを発表したばかりである。新しい地図バージョンにおいては、新たな地点住所が付加された。この地点住所は、以前に定められた住所より高度な位置の精度を与えるものである。この住所を指し示す位置コードの地図基準は、地点住所データを加えることにより更新される。

ブロック４１６において、位置コード・アップデータ３１０は、プロセス・メタデータ・リポジトリ３０６を更新し、地図変更キュー３０７から地図変更メッセージを永続的に除去する。

ブロック４１４において、地図変更プロセッサ３０５は、地図基準セクション内の地図バージョン数が限度値を上回るかどうかを判断する。位置コードは、無制限の数の地図バージョンに対する地図基準を格納することができる。しかしながら、古くなった地図データを伝送するオーバーヘッドをなくすために、地図バージョンをサポートする数についての制限があることがある。この制限は、地図提供業者によって変わり得る。例えば、地図提供業者Ａについては、各位置コードは、８つの地図バージョンまでの地図基準を保持できる。提供業者Ｂについては、各位置コードは、４つの地図バージョンまでの地図基準を保持できる。ブロック４１５において、影響される位置コードに格納された地図バージョン数が限度値を上回った場合、最も古い地図バージョンの地図基準が上記の地図バージョンにシフトされる。図６に地図バージョンのシフトの例を示す。

図５は、位置コード更新プロセス４００の際に更新することができる位置コード・エンティティ５００のブロック図である。位置コード・エンティティ５００は、地理基準セクション５０１及び地図基準セクション５０２を含む。地理基準セクション５０１は、住所、位置の名前、地理的地点の情報（例えば、緯度、経度、及び高度）、及び他の情報を含む。地図基準セクション５０２は、１又はそれ以上の地図提供業者５０３に関する地図情報を含む。各々の地図提供業者５０３について、１つ又はそれ以上の地図バージョン５０４に関連したデータがあり得る。

図６は、地図基準線のシフト６０３の際に地図基準セクション５０２内の地図基準エンティティが受け得る変更を示す概略図である。地図基準線シフトを開始する前、地図基準６０４、６０５、及び６０６は、前の状態６０１にある。本例において、前の状態６０１における最も古い地図バージョンは、２００７年第４四半期である。２００７年第４四半期の地図バージョンについて、この位置コード、すなわち第１の地図基準６０４及び第２の地図基準６０５により使用される２つの地図基準がある。

２００７年第４四半期の地図基準は、２００８年第１四半期の地図バージョンデータへのシフトが必要な基準線６０８を形成する。第１の地図基準６０４についての２００８年第１四半期のデータはないため、第１の地図基準６０４は、単純に２００８年第１四半期のデータに移動される。しかしながら、第２の地図基準６０５については、２００８年第１四半期における更新された情報、つまり更新された第２の地図基準６０６がある。第２の地図基準６０５は削除され、更新された第２の地図基準６０６は、基準線６０８内に使用されるままである。

地図基準線のシフト６０３が行われた後、２００７年第４四半期の地図バージョンが、地図基準セクション５０２から除去され、２００８年第１四半期の地図バージョンが、新しい基準線６０９として確立される。２００８年第１四半期の地図バージョンは、第１の地図基準６０４及び更新された第２の地図基準６０６を含む。２００８年第２四半期のデータは、地図基準セクション５０２内にこれまで含まれていなかった第３の地図基準６０７を含む。次の基準線シフトにおいて、第３の地図基準６０７が、次の基準線バージョンに加えられる。

地図システム１０２、地図変更システム１０４、位置コード変更システム１０６、及び位置コードシステム１０８間の通信の結果、位置コードデータが頻繁に更新される。有利なことに、位置コードデータのユーザは、自分が利用するために最新の位置コードデータを取得する。位置コードデータに影響を与えたときに地図データも更新され、種々の地理データベースを維持の労力が減少する。

上記の詳細な説明は、限定ではなく例証とみなされることが意図され、全ての同等物を含む以下の特許請求の範囲は、本発明の範囲を定義するよう意図されることが理解される。特許請求の範囲は、その旨の記述がない限り、説明された順序又は要素に限定されるものとして読むべきではない。従って、以下の特許請求の範囲及び精神内に含まれる全ての実施形態、並びにその同等物を、本発明として特許請求する。

１００：データ更新システム
１０１、１０３、１０５、１０７、１０９、１１１、２０３：データ接続
２００：地図変更システム
３００：位置コード変更システム
３０１：地図変更レシーバ
３０２：地図変更リクエスタ
３０３：要求スケジューラ
３０４：ユーザ・インターフェース
３０５：地図変更プロセッサ
３０６：変更プロセス・メタデータ・リポジトリ
３０７：地図変更キュー
３０８：キュー・リスナ
３０９：キュー・フィルタ
３１０：位置コード・アップデータ
３１１：ジオコーダ
３１２：ジオコーダデータ記憶装置
３１３：位置コード変更レシーバ
３１４：位置コード変更ノーティファイア
５００：更新された位置コード
５０１：地理基準
５０２：地図基準
６０８：基準線

Claims (19)

1. 位置コードデータを更新する方法であって、
   地図変更レシーバにおいて、第１の地図データベースに関連付けられたフォーマットの地図変更データを含み、かつ、削除された道路リンク及び新しい道路リンクを識別し、第１の地図提供業者及び前記第１の地図データベースの地図バージョンを識別する第１のメッセージを受信し、
   前記地図変更レシーバにおいて、第２の地図データベースに関連付けられたフォーマットの地図変更データを含む、第２の地図提供業者及び前記第２の地図データベースの地図バージョンを識別する第１のメッセージを受信し、
   地図変更プロセッサによって、前記第１の地図データベースに関連付けられた前記フォーマット及び前記第２の地図データベースに関連付けられた前記フォーマットを共通フォーマットに変換し、
   位置コードシステムによって、前記地図変更データが前記位置コードシステム内に格納された位置コードに影響するかどうかを判断し、ここで前記位置コードは地理的座標を前記第１の地図提供業者及び前記第２の地図提供業者のためのコンテンツにリンクさせるものであり、
   前記位置コードシステムによって、前記地図変更データに基づいて、前記位置コードと関連付けられた位置コードデータを、前記削除された道路リンクへの参照を削除し、前記新しい道路リンクを前記位置コードに添付することによって更新し、
   前記位置コードシステムによって、前記更新された位置コードデータをその内に格納する、
   ステップを含むことを特徴とする方法。
2. 前記第１の地図提供業者に対する仕様を識別するために、前記第１のメッセージを認証するステップをさらに含むことを特徴とする、請求項１に記載の方法。
3. 前記第１のメッセージの前記地図変更データが前記位置コードデータに影響するかどうかを判断するステップは、前記第１の地図提供業者、前記第１の地図データベースの前記地図バージョン、及び地図変更タイプを調べるステップを含むことを特徴とする、請求項１に記載の方法。
4. 前記位置コードについてのデータを更新するステップは、前記位置コードが住所情報を含む場合に標準ジオコーディング操作を行うステップを含むことを特徴とする、請求項１に記載の方法。
5. 前記位置コードについての位置コードデータを更新するステップは、前記位置コードが住所情報を含まない場合に逆ジオコーディング操作を行うステップを含むことを特徴とする、請求項１に記載の方法。
6. 前記位置コードについてのデータを更新するステップは、前記地図変更データを用いて、前記位置コードデータを操作するステップを含むことを特徴とする、請求項１に記載の方法。
7. 前記位置コードデータが所定の量を上回る地図バージョン数のデータを含む場合、地図基準線のシフトを行うステップをさらに含むことを特徴とする、請求項１に記載の方法。
8. 前記地図基準線のシフトは、最も古い日付と関連付けられた地図バージョンについての前記位置コードデータを削除することを含むことを特徴とする、請求項７に記載の方法。
9. 位置コードシステム内に格納された位置コードデータを更新するために用いられる位置コード変更システムであって、
   地図変更データと関連付けられた第１の地図提供業者及び第１の地図バージョン並びに地図変更データと関連付けられた第２の地図提供業者及び第２の地図バージョンを識別する地図変更データを含む、メッセージを受信するように動作可能な地図変更レシーバと、
   前記地図変更レシーバにより取得された前記地図変更データを、前記第１の地図提供業者及び前記第２の地図提供業者と両立性のある共通フォーマットに変換するように動作可能な地図変更プロセッサと、
   前記共通フォーマットを用いて前記地図変更データにより影響された位置コードを識別するように動作可能であり、かつ、メッセージを更新された位置コードデータを含む前記位置コードシステムに送るように構成され、ここで前記位置コードは地理的座標を位置コンテンツにリンクさせるものである、位置コード・アップデータと、
   を含むことを特徴とするシステム。
10. 前記地図変更データを要求するように動作可能な地図変更リクエスタをさらに含むことを特徴とする、請求項９に記載のシステム。
11. 前記地図変更データを要求するために前記地図変更リクエスタに信号を送るように動作可能な地図変更スケジューラをさらに含むことを特徴とする、請求項１０に記載のシステム。
12. 前記位置コード・アップデータが前記影響された位置コードを識別する前に、前記変換された地図変更データを格納する地図変更キューをさらに含むことを特徴とする、請求項９に記載のシステム。
13. 前記位置コード・アップデータに対してジオコーディング操作を行うように動作可能なジオコーダ、及び
    前記ジオコーダが用いるジオコーディング・データを格納するジオコーダデータ記憶装置をさらに含むことを特徴とする、請求項９に記載のシステム。
14. 位置コード変更データを含むメッセージを前記位置コードシステムから受信する位置コード変更レシーバをさらに含むことを特徴とする、請求項９に記載のシステム。
15. 位置コードデータを更新するデータ更新システムであって、
    記憶装置、プログラム、地図データベース中の地図データを変更するためのインターフェースを含む地図システムと、
    前記地図システムから地図変更データを含む複数のメッセージを受信し、ここで前記複数のメッセージのそれぞれは地図提供業者及びバージョン番号を識別するものであり、前記地図変更データを複数の地図提供業者のフォーマットと両立性があるようにフォーマットし、前記地図提供業者及び前記バージョン番号に基づいてアクションを識別する、地図変更システムと、
    前記フォーマットされた地図変更データを前記地図変更システムから受信し、前記フォーマットされた地図変更データに基づいて位置コードデータを更新し、ここで前記位置コードデータはコンテンツを地理的位置にリンクされるものである、位置コード変更システムと、
    更新された位置コードデータを前記位置コード変更システムから受信する位置コードシステムと、を含むことを特徴とするデータ更新システム。
16. 前記位置コードシステムは、位置コード変更データを含む前記位置コード変更システムに位置コード変更データを含むメッセージを送信する、請求項１５に記載のシステム。
17. 前記位置コードシステムは、前記位置コード変更データを前記地図変更システムに送信する、請求項１６に記載のシステム。
18. 前記地図変更システムは、前記位置コード変更データを前記地図システムに送信する、請求項１６に記載のシステム。
19. 前記位置コードは、複数の地図提供業者に前記コンテンツを更新することを可能にするように構成されている、請求項１に記載の方法。

Images