IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ トムトム ナビゲーション ベスローテン フエンノートシャップの特許一覧

<>
  • 特許-地図マッチングの方法及びシステム 図1
  • 特許-地図マッチングの方法及びシステム 図2
  • 特許-地図マッチングの方法及びシステム 図3
  • 特許-地図マッチングの方法及びシステム 図4
  • 特許-地図マッチングの方法及びシステム 図5
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-10-24
(45)【発行日】2023-11-01
(54)【発明の名称】地図マッチングの方法及びシステム
(51)【国際特許分類】
   G01C 21/30 20060101AFI20231025BHJP
【FI】
G01C21/30
【請求項の数】 12
【外国語出願】
(21)【出願番号】P 2022048361
(22)【出願日】2022-03-24
(62)【分割の表示】P 2018568385の分割
【原出願日】2017-07-28
(65)【公開番号】P2022095722
(43)【公開日】2022-06-28
【審査請求日】2022-04-14
(31)【優先権主張番号】1613105.4
(32)【優先日】2016-07-29
(33)【優先権主張国・地域又は機関】GB
(31)【優先権主張番号】1617407.0
(32)【優先日】2016-10-13
(33)【優先権主張国・地域又は機関】GB
(73)【特許権者】
【識別番号】515288214
【氏名又は名称】トムトム ナビゲーション ベスローテン フエンノートシャップ
【氏名又は名称原語表記】TomTom Navigation B.V.
【住所又は居所原語表記】De Ruijterkade 154, 1011 AC, Amsterdam, Netherlands
(74)【代理人】
【識別番号】110003281
【氏名又は名称】弁理士法人大塚国際特許事務所
(72)【発明者】
【氏名】コポネン, ラウリ
(72)【発明者】
【氏名】サン, ルイ
【審査官】高島 壮基
(56)【参考文献】
【文献】特開2015-001520(JP,A)
【文献】特開2011-226950(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G01C 21/00-21/36
G09B 29/00
(57)【特許請求の範囲】
【請求項1】
装置の現在位置を、地理的エリア内のナビゲート可能要素のネットワークを示す電子地図とマッチングする方法であって、前記電子地図は前記ナビゲート可能要素を表す複数の区分を含む、前記方法は、
前記装置の移動を示す位置データを取得することであって、前記位置データは、異なる時間における前記装置の位置を示す複数の位置データサンプルを含む、ことと、
前記電子地図によってカバーされる前記エリアの少なくとも部分に関する電子地図データを取得することと、
前記電子地図に対する候補パスのプールを管理することであって、各候補パスは前記装置の現在位置がマッチングされ得る前記電子地図を通る可能なパスであり、各候補パスは電子地図の1つ以上の区分を含み、前記管理することは、前記候補パスの1つ以上を拡張することによって候補パスの前記プールを更新して、元の候補パスの先端を提供する区分に接続された少なくとも1つの区分を含む拡張候補パスを提供することをさらに含む、ことと、
複数の前記位置データサンプルに基づいて、前記位置データとの最良の一致を提供する前記プールからの候補パスを特定することであって、前記特定することは、
候補パスの前記プールの各候補パスについて、前記現在位置が前記候補パスにマッピングされ得る尤度を示す第1の基準に基づく第1のスコアを提供するために第1のマッチャーを使用することと、
候補パスの前記プールの各候補パスに対して、前記現在位置が前記候補パスにマッピングされ得る尤度を示す第2の基準に基づく第2のスコアを提供するために第2のマッチャーを使用することと、
候補パスの前記プールの各候補パスについて、前記現在位置が前記候補パスにマッピングされ得る尤度を示す全体スコアを決定するために、少なくとも前記第1および第2のスコアを使用することと、
前記全体スコアに基づいて、前記位置データとの最良の一致を提供する前記候補パスを特定することと、
を含む、こ
地図マッチングされた現在位置としての出力のために前記電子地図の区分に対する前記装置の推定現在位置を取得する際に、前記特定された候補パスを使用することであって、前記特定された候補パスを使用することは、前記地図マッチングされた現在位置としての出力のために前記電子地図の候補パスの区分に対する前記装置の前記推定現在位置を取得するために、候補パスの前記プールの前記候補パスの各々に関して決定された前記全体スコアを使用することを含む、こ
前記地図マッチングされた現在位置を示すデータを生成することと、
を含む方法。
【請求項2】
候補パスの前記プールの前記候補パスの各々を、前記現在位置が前記候補パスにそれらのそれぞれの全体スコアを使用してマッピングされ得る尤度に少なくとも基づいてランク付けすることをさらに含む、請求項1に記載の方法。
【請求項3】
前記第1または第2のマッチャーが前記現在位置が前記候補パスにマッピングされ得る尤度を示すスコアを提供するステップは、前記第1または第2のマッチャーが、前記第1または第2のマッチャーのそれぞれの基準に基づいて前記位置データを前記候補パスにマッチングすることを含む、請求項1または2に記載の方法。
【請求項4】
前記全体スコアを決定するステップは、ビリーフ理論に基づく技術を使用して実行される、請求項1乃至3の何れか1項に記載の方法。
【請求項5】
前記最良の一致を提供する前記候補パスの前記特定は、前記候補パスのそれぞれのマッチングスコアと、位置データトレースと前記候補パスとの間のオフセットとに基づくものである、請求項1乃至4の何れか1項に記載の方法。
【請求項6】
候補パスのための前記第1または第2の基準の各々に関連する前記マッチングは、前記装置の前記現在位置に関する最良の推定を提供する前記候補パス上の地点を特定するステップを含む、請求項1乃至の何れか1項に記載の方法。
【請求項7】
前記第1または第2の基準は、少なくとも方位及び位置を含む、請求項1乃至の何れか1項に記載の方法。
【請求項8】
前記装置の1つ以上の予測更新位置を示すデータの生成用に、地図マッチングされた現在位置を示す前記生成されたデータを予測エンジンに入力することと、前記装置の位置の指標を電子地図上に表示する際に、前記予測エンジンによって提供される前記予測更新位置のデータを使用することとをさらに含む、請求項1乃至の何れか1項に記載の方法。
【請求項9】
装置の現在位置を、ナビゲート可能なネットワークを示す電子地図とマッチングするための地図マッチャーであって、前記電子地図は区分によって接続された複数のノードを含み、前記地図マッチャーは、請求項1乃至の何れか1項に記載の方法を実行するための手段を含む、地図マッチャー。
【請求項10】
前記地図マッチャーは、サーバおよび/またはナビゲーション装置によって提供される、請求項に記載の地図マッチャー。
【請求項11】
装置の現在位置を、地理的エリア内のナビゲート可能な要素のネットワークを示す電子地図とマッチングするためのシステムであって、前記電子地図は、前記ナビゲート可能な要素を表す複数の区分を含み、前記システムは、
請求項1乃至の何れか1項に記載の方法を実行するための手段を含む、システム。
【請求項12】
システムの1つ以上のプロセッサによって実行されると、任意選択で非一時的なコンピュータ可読媒体に格納された、請求項1乃至の何れか1項に記載の方法を前記システムに実行させる命令を含むコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、装置の現在位置を、ナビゲート可能ネットワークを示す電子地図とマッチングする方法及びシステムに関する。
【背景技術】
【0002】
GPS(全地球測位システム)信号受信/処理機能性を含むポータブルナビゲーション装置(PND)は周知であり、車両搭載型のナビゲーションシステム又は他の車両ナビゲーションシステムとして広く採用される。一般に、最近のPNDは、プロセッサ、メモリ(揮発性及び不揮発性の少なくとも一方であり、通常は双方)及びメモリ内に格納された地図データを備える。プロセッサ及びメモリは協働して、ソフトウェアオペレーティングシステムが確立される実行環境を提供する。更に、PNDの機能性を制御可能にするため及び種々の他の機能を提供するために1つ以上の追加のソフトウェアプログラムが提供されることは一般的である。通常、これらの装置は、ユーザが装置と対話し且つ装置を制御できるようにする1つ以上の入力インタフェースと、情報がユーザに中継されるようにする1つ以上の出力インタフェースとを更に備える。出力インタフェースの例は、表示装置及び可聴出力用スピーカを含む。入力インタフェースの例は、装置のオン/オフ動作又は他の特徴を制御するための1つ以上の物理ボタン(これらのボタンは、必ずしも装置自体に存在する必要はなく、装置が車両に組み込まれる場合はステアリングホイール上に存在してもよい)及びユーザの音声を検出するためのマイクを含む。特に好適な構成において、出力インタフェースディスプレイは、ユーザが触れることにより装置を操作できるようにする入力インタフェースを更に提供するためにタッチセンシティブディスプレイとして(例えば、タッチセンシティブオーバーレイにより)構成される。
【0003】
ナビゲーション装置は通常、車両が移動しているナビゲート可能ネットワークを表すデジタル地図にもアクセスする。デジタル地図(又は、知られているような数学的グラフ)は、最も単純な形式において、効果的には、ノード、最も一般的には道路交差点を表すデータ、及び、交差点間の道路を表すノード間の線を含むデータベースである。より詳細なデジタル地図においては、線は、始点(又は“尾端(テール)”)ノード及び終点(又は“先端(ヘッド)”)ノードにより規定された区分(又は“弧”)に分割されてもよい。これらのノードは、最低限3つの線又は区分が交差する交差点を表すという点で“リアル”であるかもしれないし、或いは、これらのノードは、とりわけ、道路の特定のストレッチ(区間)の形状情報、又は、道路のいくつかの特性、例えば速度制限が変化する当該道路に沿った位置を特定する手段を提供するために、リアルノードにより一端又は両端で規定されていない区分のアンカとして提供される点で“人工的(人為的)”であるかもしれない。実際、全ての現代のデジタル地図、ノード及び区分は、データベース内のデータにより再び表される様々な属性により更に規定される。例えば、各ノードは、その現実世界の位置、例えば緯度経度を規定するために通常地理的座標を有するだろう。ノードは、交差点においてある道路から別の道路へ移動することが可能かどうかを示す、関連付けられた操作データも通常有するだろうし、区分は最大許可速度、車線サイズ、車線数、間に中央分離帯があるかどうか等の関連する属性も有するだろう。区分は関連する移動方向も有しており、移動方向は区分が移動されうる可能な(複数の)方向を示す。
【0004】
ナビゲーション装置は通常、衛星ブロードキャスト信号にエンコードされたタイミングデータ及び位置データが受信されて次に速度、方位(向き)等の他の情報と共に現在の時間における装置の位置を判定するために処理される全球測位衛星システム(GNSS)センサを含む。GNSSはしばしば、正式にはNAVSTARとして既知のGPSに基づくものであるが、更に又は或いはロシアのGLONASS、欧州のガリレオ測位システム、COMPASS測位システム又はIRNSS(インド地域航法衛星システム)に基づくことができる。車両ナビゲーション装置は通常、装置の相対位置を判定するために使用されうるデッドレコニング(DR)センサとも称される内部ナビゲーションセンサにアクセスもする。新規の位置は、(GNSSセンサが該当するような)絶対位置ではなく、方位及び前回の位置から移動した距離に基づくものである。DRセンサは、速度計、走行距離計(オドメータ)、加速度計等の移動距離を測定するセンサ、及び、ジャイロスコープ等の方位を測定するセンサを含む。多くの場合、GNSSセンサ及びDRセンサからのデータは、衛星信号が部分的に又は完全にブロックされる時に装置の現在位置が常に利用可能であるように組み合わされる。
【0005】
そのようなナビゲーション装置の有用性は、第1の場所(通常は出発地又は現在地)と第2の場所(通常は目的地)との間の経路を判定する機能において主に示される。これらの場所は、例えば郵便番号、道路名及び番地、事前に格納された「既知の」目的地(有名な場所、市営の場所(運動場又は水泳プール等)又は他の地点情報等)、並びにお気に入りの目的地又は最近訪問した目的地である種々の異なる方法のうちのいずれかによって、装置のユーザにより入力可能である。通常、ナビゲーション装置は、地図データから出発地の住所の場所と目的地の住所の場所との間の「最善」又は「最適」な経路を検索することが経路計画ソフトウェアにより可能になる。「最善」又は「最適」な経路は所定の基準に基づいて判定され、必ずしも最速又は最短の経路である必要はない。運転者を案内する経路の検索は非常に高度であり、検索は、履歴交通道路情報、既存の交通道路情報、及び/又は、予測された交通道路情報を考慮してもよい。計算された経路に沿うナビゲーション中、そのような装置が、選択された経路に沿ってその経路の終点、すなわち所望の目的地にユーザを案内するための視覚命令及び/又は可聴命令を提供することは一般的である。また、装置がナビゲーション中に地図情報を画面上に表示することも一般的であり、そのような情報は、表示される地図情報が装置の現在地を示し、従って装置が車両ナビゲーションに使用されている場合はユーザ又はユーザの車両の現在地を示すように、画面上で定期的に更新される。
【0006】
理解されるように、ナビゲーション装置での重要なプロセスは、例えば、GNSS及び/又はDRセンサに基づいて位置決めエンジンにより判定されるように、装置の現在位置に対応するデジタル地図上の位置を判定することである。このプロセスは通常、地図間マッチングと称される。地図マッチングアルゴリズムの様々な例が、Quddus et al による論文“Current map-matching algorithms for transport applications: state-of-the art and future research directions” Transportation Research Part C: Emerging Technologies, vol.15, no.5, pp. 312-328 (2007).に記載されている。
【0007】
図1は、位置決め及び地図マッチングシステムの例示的な機能設計を示す。システムにおいて、位置データを継続的に出力するためにGNSSセンサ10及びDRセンサ12のうち少なくとも1つからデータが位置決めエンジン(例えばソフトウェアモジュール)20により受信されて処理される。この位置データ、例えば各位置サンプルは、緯度及び経度等の地理的座標の少なくとも1つのセットを含むが、通常は方位、速度及び(以前の位置サンプルからの)移動距離も含むだろう。位置サンプルは、記憶手段32内のデジタル地図データにアクセスして、且つ、各位置サンプルについて、地図とマッチングされた対応位置を、例えばデジタル地図の区分、及び、先端ノード及び尾端ノードからのオフセットを特定するデータとして出力する地図間マッチングエンジン30へ出力される。地図とマッチングされた位置は、例えば、現在位置から目的地までの経路の判定用、装置の現在位置を示すアイコンを有するデジタル地図の視覚表現の生成用等に、1以上のクライアント装置又はソフトウェアモジュール40により受信される。
【0008】
最も早い地図マッチングアプローチは、距離計測に基づいて個々の位置サンプルをデジタル地図の最も近くのノード又は区分にスナップするポイントトゥポイント(point-to-point)マッチング及びポイントトゥカーブ(point-to-curve)マッチングを含む。これらのアプローチは、例えば、White et alによる論文“Some map matching algorithms for personal navigation assistants”, Transportation Research Part C, vol. 8, pp. 91-108 (2000)に詳細に記載されている。しかしながら、位置決めエンジンから受信される位置サンプルと(例えば道路ネットワークであるナビゲート可能ネットワークを表す)デジタル地図との両方に包含される二重の不確実性及び不正確性のため、そうしたアプローチは極めて誤差を起こしやすい。特に、高い道路密度、複雑な交差点、及び、平行道路又は積層道路を有する幹線道路を有する都市エリアは特に正確に解決することが難しい。2つの通常のアプローチが、これらの早期マッチングアルゴリズムを改良ために使用されている。1つのアプローチは、距離計測に加えて、方位、移動距離、及び区分の高度、ターン制限等のより多くの計測を導入することである。もう1つのアプローチは、ネットワークトポロジーを組み込むこと、及び、地図とマッチングされた結果の位相的な完全性を維持することである。しかしながら、そうしたシステムは不必要に複雑になるかもしれない。
【0009】
出願人は、位置データを地図マッチングする改良された方法及びシステムの必要性があることを認識している。
【発明の概要】
【0010】
本発明の第1の態様によれば、装置の現在位置を、地理的エリア内のナビゲート可能要素のネットワークを示す電子地図とマッチングする方法であって、前記電子地図は前記ナビゲート可能要素を表す複数の区分を含む、前記方法は、
前記装置の移動を示す位置データを取得することであって、前記位置データは異なる時間での前記装置の位置を示す複数の位置データサンプルを含む、前記取得することと、
前記電子地図によりカバーされる前記エリアの少なくとも部分に関する電子地図データを取得することと、
前記電子地図に対する候補パスのプールを維持することであって、各候補パスは前記装置の前記現在位置がマッチングされてもよい前記電子地図を通る可能なパスであり、各候補パスは前記電子地図の1以上の区分を含み、前記維持することは、元の候補パスの先端を提供する区分に接続される少なくとも1つの区分を含む拡張候補パスを提供するために1つ以上の前記候補パスを拡張することにより、候補パスの前記プールを更新することをさらに含む、前記維持することと、を含み、
前記方法は、
複数の前記位置データサンプルに基づいて、前記位置データとの最適なマッチングを提供する候補パスを前記プールから特定することと、
前記地図とマッチングされた現在位置として出力のために前記電子地図の区分に対する前記装置の推定現在位置を取得する際に、前記特定された候補パスを使用することと、
前記地図とマッチングされた現在位置を示すデータを生成することと、
をさらに含む方法が提供される。
【0011】
本発明は、本明細書に記載の本発明の態様又は実施形態の何れかに従った方法を実行するシステムに及ぶ。従って、本発明の第2の態様によれば、装置の現在位置を、地理的エリア内のナビゲート可能要素のネットワークを示す電子地図とマッチングするシステムであって、前記電子地図は前記ナビゲート可能要素を表す複数の区分を含む、前記システムは、
前記装置の移動を示す位置データを取得する手段であって、前記位置データは異なる時間での前記装置の位置を示す複数の位置データサンプルを含む、前記取得する手段と、
前記電子地図によりカバーされる前記エリアの少なくとも部分に関する電子地図データを取得する手段と、
前記電子地図に対する候補パスのプールを維持する手段であって、各候補パスは前記装置の前記現在位置がマッチングされてもよい前記電子地図を通る可能なパスであり、各候補パスは前記電子地図の1以上の区分を含み、前記維持することは、元の候補パスの先端を提供する区分に接続される少なくとも1つの区分を含む拡張候補パスを提供するために1つ以上の前記候補パスを拡張することにより、候補パスの前記プールを更新することをさらに含む、前記維持する手段と、を備え、
前記システムは、
複数の前記位置データサンプルに基づいて、前記位置データとの最適なマッチングを提供する候補パスを前記プールから特定する手段と、
前記地図とマッチングされた現在位置として出力のために前記電子地図の区分に対する前記装置の推定現在位置を取得する際に、前記特定された候補パスを使用する手段と、
前記地図とマッチングされた現在位置を示すデータを生成する手段と、
をさらに備えるシステムが提供される。
【0012】
当業者により理解されるように、本発明のこの更なる態様は、必要に応じて、本発明の他の態様の何れかに関して本明細書に記載された本発明の好適且つ選択的な特徴のうちの1つ以上又は全てを含みうるし、好適には含む。明示的に述べられていなくても、本発明のシステムは、何れかの態様又は実施形態における本発明の方法に関して記載された何れかのステップを実行する手段を備えてもよく、その逆もまた同様である。
【0013】
本発明はコンピュータ実施発明であり、本発明の何れかの態様又は実施形態に関連して記載した何れかのステップは、1以上のプロセッサのセットの制御下で実行されてもよい。前記システムに関連して記載した何れかのステップを実行する手段は、1以上のプロセッサのセットであってもよい。
【0014】
本発明の前記方法は、ナビゲーション動作との関連で実施されてもよい。従って、前記方法は、好適にはナビゲーション機能性を有する装置又はシステムの1つ以上のプロセッサのセットにより実行されてもよい。しかし、前記方法は、地図マッチング機能性を有するものの必ずしもナビゲーション機能性を有さない任意の適当なシステムにより実行されてもよいことが理解されるだろう。例えば、前記方法は、ナビゲーション機能性を有さない、例えばデスクトップ又はラップトップシステムであるコンピュータシステム、及び/又は、車両内の1以上のシステムを自動的に制御するように構成されうる先進運転支援システム(ADAS)により実施されてもよい。
【0015】
本発明の前記方法は、述べられた機能性を提供するように構成された任意のシステムを使用して実施されてもよい。前記ステップは地図マッチングエンジンにより実行されてもよい。
【0016】
本発明の前記方法は、移動装置により実行されてもよい。前記移動装置はメモリ及び1以上のプロセッサのセットを有する。そのような装置は、例えば上記の背景技術に記載された特徴の何れかを有する専用ナビゲーション装置であってもよい。そのような装置はポータブルナビゲーション装置又は一体型車載装置であってもよい。前記システムは、先進運転支援システム(ADAS)の部分を形成してもよい。しかしながら、他の実施形態において、前記移動装置は、適切なソフトウェアを動作する移動電話又はタブレット装置等の任意の適当な移動装置であってもよい。一般に、前記移動装置は位置判定機能性を有するだろう。通常、前記移動装置は、前記電子地図に対する前記現在位置の指標をユーザへ表示するディスプレイを有するだろう。或いは、本発明の前記方法は、サーバにより実行されてもよい。本発明の前記方法がサーバ及び移動装置の組み合わせによって実行される他の実施形態が想定される。従って、本発明の前記システムは、記載された前記ステップを実行するように構成された移動装置及び/又はサーバを備えてもよい。本発明の前記地図マッチングステップは、前記地図とマッチングされたデータを使用してもよい他のモジュール、例えば経路指定エンジン、から分離される地図マッチングモジュールにより実行されてもよいこと、同様に、前記地図マッチングモジュールは、当該地図マッチングモジュールが動作する位置データを提供するモジュールから分離されてもよいことが理解されるだろう。
【0017】
前記方法は、電子地図及び当該地図とのマッチングのための装置の移動を示す位置データを取得することを含む。前記電子地図及び前記位置データは前記地図マッチングエンジンへの入力データを提供する。
【0018】
前記方法は、前記地図マッチング方法用の地図データベースから電子地図データを取得するステップを含んでもよい。前記電子地図を取得する前記ステップは、ローカルソース又はリモートソースから前記データを要求することを含んでもよい。前記方法は、マッチングされるべき前記位置サンプル(すなわち最も直近の位置サンプル)に基づいて選択された領域に関する電子地図データを要求することを含んでもよい。例えば、前記電子地図データは、所定の形状の領域に関するデータであってもよい。マッチングされるべき前記位置サンプルに基づいて選択された、所定の形状の領域、例えば矩形等のポリゴン、に関するデータであってもよい。前記領域は、前記位置を含んでもよく、例えば前記位置を中心としてもよい。いくつかの実施形態において、前記地図マッチング方法は、地図データベースを格納するメモリを備えるシステムにより実行されてもよい。しかしながら、他の実施形態において、前記地図データベースは、例えばサーバのリモート地図データベースであってもよい。電子地図データを要求する前記ステップは、例えば、電子地図データが以前に格納された領域の境界の近くに現在位置がある時に、更なる電子地図データを取得するために必要に応じて繰り返されてもよい。
【0019】
前記電子地図は、前記電子地図によりカバーされる前記エリア内のナビゲート可能ネットワークのナビゲート可能要素を表す、ノードにより接続された複数の区分を含む。前記電子地図の前記区分により接続される前記ノードは、現実世界のノード、例えば前記ナビゲート可能ネットワークの要素の交差点、又は、上述したように、現実世界のノードにより規定されていない少なくとも1つの端部を有する区分のアンカを提供するために電子地図に導入されてもよい人工ノードを示してもよい。これは、異なる道路特性、例えば速度制限、形状情報等の異なる属性を、当該区分の部分と関連付けることが可能であるように、現実世界のノード間に延びる区分を分割するのに役立つかもしれない。本発明の実施形態は道路区分の形式でのナビゲート可能要素に関連して説明されるが、パス、河川、運河、自転車道路、航路又は鉄道線路などの区分のような他のナビゲート可能区分にも本発明を適用可能であってもよいことを理解すべきである。参照を容易にするために、これらは一般に道路区分として表される。
【0020】
電子地図の各ノードは、前記ノードの現実世界の位置を示す位置データと関連付けられている。各ノードは、前記ノードの経度及び緯度の位置を示す位置データと関連付けられてもよい。前記電子地図の各区分は、前記地図のノード間の接続性(コネクティビティ)を示す。区分は方向性があってもよく、前記区分は一方向(すなわち前記区分により表される前記ナビゲート可能要素が一方向にのみ移動されうる)又は双方向(すなわち前記区分により表される前記ナビゲート可能要素が双方向に移動されうる)であることを示してもよい。各区分は尾端ノード及び先端ノードの間に延びてもよい。通常、各区分は直線区分である。換言すれば、前記電子地図は、それが表す前記ナビゲート可能ネットワークの前記トポロジー及び接続性(コネクティビティ)を示してもよい。
【0021】
前記方法は、装置の前記移動を示す位置データを取得することを含む。前記位置データは、異なる時間での前記装置の前記位置を示す、複数の位置サンプルを含む。各位置サンプルは、それが関連する時間での前記装置の前記位置を示す。最も近い時間に関する前記位置データ、例えば位置サンプルは、“現在位置”と称されてもよい。前記方法は、前記位置データに従った前記現在位置を前記電子地図上の位置とマッチングしようとする。前記位置データは、任意の適当な位置判定エンジンから取得、例えば受信されてもよい。前記位置判定エンジンはローカル又はリモートであってもよい。前記位置データを取得する前記ステップは好適にはリモート位置判定エンジンから前記位置データを取得することを含む。
【0022】
本発明は、前記地図マッチング機能性、例えばエンジンが、位置判定機能性、例えばエンジンから分離されることを可能にすることが理解されるだろう。前記地図マッチングエンジンは、前記位置データを、当該データが前記地図マッチングエンジンにより受信されるレートとは異なるレートで、すなわち、位置判定エンジンが位置サンプルを提供するレートとは異なるレートで、マッチングしてもよい。例えば、前記地図マッチングエンジンは、前記位置データが受信されるレートよりも低いレートで前記データを処理してもよい。さらに、前記地図マッチングエンジンにより受信される位置データは、前記地図マッチングプロセスで即座に使用されなくてもよい。
【0023】
前記方法は、前記取得された位置データ(どのようにしてそれが取得されようとも)をメモリに格納することをさらに含んでもよい。これは、前記データが、前記地図マッチングエンジンにより、より後の段階で、すなわち非同期的に処理されることを可能にしてもよい。
【0024】
取得される前記位置データは好適にはタイミングデータと関連付けられる。好適には前記位置データは複数の位置サンプルを含み、各位置サンプルは、前記装置の前記位置を示すデータ、及び、前記位置が関連する時間を示すデータを含む。好適な実施形態において、前記位置データはタイムスタンプ付き位置データである。その場合、各位置サンプルはタイムスタンプと関連付けられる。前記位置データのタイミング情報を含むそのような実施形態は、前記地図マッチング及び位置判定エンジンが互いに分離される場合に適切である。しかしながら、前記位置データは、これが前記地図マッチングエンジンにより他の方法で推論されてもよい場合、又は、例えば前記位置判定エンジン及び前記地図マッチングエンジンが同時に動作するなら、それが必要とされない場合には、必ずしもタイミング情報と関連付けられる必要がないことが想定される。これは、前記地図マッチングエンジンが前記位置判定エンジンから分離されないなら当てはまるかもしれない。前記方法は、複数の位置サンプルを含み、且つ、増加するタイムスタンプと関連付けられている、位置データを取得することを含んでもよい。
【0025】
いくつかの実施形態では、前記方法は、前記位置データを判定するステップに及んでもよい。前記位置データは、前記装置の前記位置を示す任意の適当なデータを含んでもよい。前記装置は、その位置が地図とマッチングされることが望まれる任意の装置であってもよい。前記装置は任意の移動装置であってもよく、専用ナビゲーション装置、又はナビゲーション機能を有する任意の装置、例えば移動電話、又は類似の動作をする適切なソフトウェアであってもよい。前記装置は、本発明の前記地図マッチングステップを実行する装置であってもよく、或いは、前記地図マッチングがサーバにより実行される場合にはリモート装置であってもよい。前記装置は通常は車両と関連付けられる。
【0026】
前記位置データは、上記の何れのタイプの位置データを含んでもよい。前記位置データは、GPSセンサ等の1又は複数のGNSSセンサにより提供されるデータ、又は、1つ以上のGNSSセンサ、例えばGLONASS、COMPASS又はIRNSSにより取得されてもよい任意の他のデータ、に基づいてもよい。前記位置データは、更に又は或いは、前記装置の相対位置を示すデータを提供するように構成された、例えば車両の1以上のデッドレコニング(DR)センサから取得されたデータに基づいてもよい。従って、前記位置データは、(複数の)GNSSセンサ及び/又は(複数の)DRセンサに基づいて位置決めエンジンにより判定された任意の位置データであってもよい。その場合、各位置サンプルは、上記の何れかのタイプの位置データを含むだろう。
【0027】
各時間に関する前記位置データ、すなわち前記位置データサンプルは、少なくとも、地理的座標、例えば緯度及び経度のセットを含む。いくつかの実施形態では、各位置データサンプルは、方位(向き)、速度及び移動距離のうちの1つ以上を示すデータをさらに含む。前記方位及び移動距離のデータは、以前の位置サンプルに関連しているだろう。各位置サンプルは、前記データの推定精度、勾配、方位レート等を示すデータ等の更なるデータを選択的に含んでもよい。
【0028】
前記方法は通常、地図マッチングされるべき前記装置の位置を示す位置データサンプルを継続的に受信することを含む。位置決めエンジンは、どのように構成されようとも、そのようなデータを継続的に出力してもよい。前記位置データは、複数の位置データサンプルを含んでもよく、各々は異なる時間に関し、例えば複数の項目のタイムスタンプ付き位置データである。そのような各位置データサンプルは、本明細に記載の本発明の前記方法に従って前記地図とマッチングされてもよい。前記位置サンプルは前記地図と順次マッチングされてもよく、各地図とマッチングされた位置サンプルは、更新された地図とマッチングされた現在位置を提供する。上述したように、前記地図マッチングプロセスは、前記位置サンプルの受信よりも遅いレートで行われてもよく、或いは、いくらか遅れて行われてもよい。最も直近のマッチングされた位置サンプルは、前記地図とマッチングされた現在位置を提供することが考慮されるだろうが、実際には前記装置の前記現在位置はその時までに進んでいるかもしれない。
【0029】
本発明によれば、前記方法は、前記電子地図に対する候補パスのプールを維持することを含む。各パスは、前記装置の前記(現在)位置がマッチングされてもよい前記電子地図を通る可能なパスである点で候補パスである。従って、前記プールは、前記プール内の前記候補パスが時間とともに変化する点で動的プールである。パスは、前記プールから、修正、追加又は消去されてもよい。通常、前記電子地図の各区分は直線形(リニア)である。従って、各候補パスは、各々が前記電子地図の複数の区分を含むポリラインであってもよい。
【0030】
停止期間後の開始時、又は、オフロード位置から来る時等の、初期の開始状況において、前記方法は、前記現在位置、すなわち複数の候補パスの開始セットの提供用に最初に受信された位置サンプル、に近接する前記電子地図における複数の区分を特定することを含んでもよい。前記方法は、前記現在位置に基づいて前記電子地図上のポリゴン、例えば矩形、又は任意の他のエリアを判定することと、候補パスの開始セットの各候補パスを提供する際に使用されるべき前記ポリゴン又は他のエリアと交差する前記電子地図の複数の区分を特定することとを含んでもよい。前記方法は、前記開始セットの前記複数の区分を選択する際に、前記現在位置からの距離、方角等の要因を考慮することを含んでもよい。前記現在位置は、ここでは開始後の前記最初に受信された位置サンプルだろう。
【0031】
開始後、候補パスの前記プールは、既存のパスを拡張すること、及び/又は、新規のパスを追加することにより、追加されてもよい。そのようなステップは、受信された位置データに応じて実行されてもよい。前記プールは、異なる運転方向に関して候補パスの第1のセット及び第2のセットを含んでもよく、或いは、前記現在の運転方向における候補パスのみを含んでもよい。
【0032】
各候補パスは、前記電子地図の1つ以上の前記区分を含む。各パスは連続パスである。前記パスは単一の地点位置というよりはむしろ拡張パスでる。これにより、前記現在位置の前記地図とのマッチングが、以前の位置サンプル、ひいては前記現在位置までの移動パスを考慮することが可能となる。これは、上述した従来のポイントトゥポイント(point-to-point)地図マッチング技術と関連付けられた誤差を低減することを助けるかもしれない。しかしながら、本発明は、拡張位置も考慮した、先行技術のカーブトゥカーブ(curve-to-curve)タイプの地図マッチング方法を使用して取得されるよりも地図マッチング精度の更なる改良を提供する更なるステップを含む。
【0033】
好適には、前記候補パスの少なくともいくつかは、前記電子地図の第1の区分と、前記第1の区分と接続された少なくとも1つの区分とを含む。換言すれば、前記候補パスの少なくともいくつかは、接続された区分間の、前記電子地図のノードにわたって延びる。
【0034】
本発明によれば、前記方法は、1つ以上の前記候補パスを拡張することにより候補パスの前記プールを更新することを含む。前記電子地図の各区分は、先端(ノード)及び尾端(ノード)を有しており、前記先端(ノード)は、前記区分が向いている方向における前記区分の前方端であり、前記尾端(ノード)は前記区分が生じる前記区分の後方端である。同様に、各候補パスは、前記パスが向いている方向における前記前方端に先端を有し、前記パスの前記後方端に尾端を有する。前記方法は、元の候補パスの先端を提供する前記区分と接続された少なくとも1つの区分を含む拡張候補パスを提供するために前記候補パスを拡張することを含む。前記区分は、ノードで相互に接続されるだろう。前記接続された区分は通常、前記元の候補パスの前記区分の前記先端が終了するノードにおいて出ていく区分である。候補パスが前記接続された区分に沿って拡張される距離は所望に選択されてもよい。例えば、これは所定の距離であってもよく、或いは、次のノードまで等であってもよい。前記距離は区分のタイプに依存してもよい。例えば、前記区分が幹線道路区分である場合は、前記区分が都市道路の一部である場合よりも、次のノードと更に遭遇するように前記パスを拡張することが必要であるかもしれない。前記パスは、前記最初に接続された区分と接続された更なる区分に拡張されてもよいことが想定される。拡張は移動方向に行われることが理解されるだろう。前記拡張候補パスは候補パスの前記プールに追加される。
【0035】
記載された方法で候補パスを拡張することによって、生成される候補パスの前記プールは、本質的に、道路接続性(コネクティビティ)情報を含むだろうし、前記現在位置が環状交差路(roundabout)に近接している場合或いは平行道路が存在する場合など、より複雑な状況であっても、前記現在位置を正確に地図マッチングする改良された能力となる。そのようなトポロジー情報を前記候補パスデータに組み込むことによって、前記マッチングプロセスの後段部分を実行する際に、例えばどの区分が前記位置とマッチングするかを決定する際に、区分間のトポロジー特徴、例えば接続性(コネクティビティ)を考慮する必要性、つまり前記地図マッチングプロセスが単純化される。前記元の候補パスを拡張する前記ステップは、前方方向、すなわち移動方向に実行される。
【0036】
拡張されるべき前記又は各パスは好適には前記位置データに基づいて選択される。拡張される前記又は各パスは好適には前記装置の前記位置が以前にマッチングされたパスである。前記パスを拡張する前記ステップは、(最も直近に)前記地図マッチングされた前記装置の位置が前記パスの前記先端に近接している時にトリガされてもよい。例えば、これは、前記地図マッチングされる位置が前記パスの前記先端の所定距離の範囲内にある時であってもよい。この状況では、地図マッチングされるべき位置データの次のサンプルは、既存のパスの前記先端を超えた領域に入る可能性がある。前記地図マッチングされる位置がその端部の近くにある時に前記パスを拡張することによって、交差点等の猟奇でさえ前記マッチングプロセスの継続を提供する、位置データの次のサンプルのマッチングのための適当な候補パスを提供するために、接続された区分上に延びる候補パスが作成される。しかしながら、前記地図マッチングされる位置が前記パスの前記先端の近くにある時にだけ前記パスを拡張することによって、前記候補パスプール内の前記パスの数及び長さが、より管理可能なレベルに保持されてもよい。
【0037】
多くの場合、候補パスの前記先端を提供する前記区分は、多数の出ていく区分を有する、ノードで終了してもよい。その場合、前記候補パスの前記先端を提供する前記区分は、多数の区分と接続される。この状況では、前記方法は、前記ノードにおいて前記元の候補パスの先端を提供する前記区分と接続された少なくとも1つの前記出ていく区分を含む拡張候補パスを提供するために前記候補パスを拡張することと、前記ノードにおいて前記元の候補パスの前記先端を提供する前記区分と接続された少なくとも1つのその他の出ていく区分を含む少なくとも1つの追加の候補パスを生成することとを含んでもよい。前記又は各追加の候補パスは、前記元の候補パスに対応する前記ノードに続く部分をさらに含んでもよい。換言すれば、前記元の候補パスは、1つ以上の更なる固有の候補パスを提供するために、コピーされて異なる方法で拡張されてもよい。このプロセスは、前記トンネルの出口に至る前記ノードから生じる各区分について実行されてもよい。
【0038】
各拡張候補パスは、前整然とした順序の記電子地図の2つ以上の区分として記載されてもよい。判定された各候補パスは異なる、すなわち固有のパスである。上述したように、各候補パスは固有であるが、異なる候補パスは、例えば、拡張される前記元の候補パスに対応する共通部分を共有してもよい。前記元の候補パスは、多数の新規の候補パスの部分を提供するためにコピーされてもよい。
【0039】
前記方法は、前記候補プールにおける前記候補パスの各々を示すデータを候補パスデータベースに格納することを含んでもよい。パスが拡張又は追加される場合、前記方法は、前記拡張パス又は新規のパスを示すデータを前記データベースに格納することを含んでもよい。候補パスを示す前記データは、整然とした順序の、前記パスを規定する地図区分を示してもよい。前記データベースは、ローカルメモリ又はリモートメモリ、或いはそれらの組み合わせ、に格納されてもよいが、好適にはローカルに格納される。
【0040】
前記複数の候補パスのうちの異なるパスは、異なる時間に、すなわち現在位置がそれぞれの元の候補パスの端部の近くにある時に、候補パスの前記プール内に拡張候補パスを提供するために拡張されてもよいことが理解されるだろう。
【0041】
時間とともに、前記装置が移動して、新規の位置サンプルが受信されるにつれて、候補パスの前記プールにおける候補パスの数は増加するだろうことが理解されるだろう。本発明の実施形態によれば、ステップは、好適には、候補パスの前記プールをアクティブに管理するために行われる。これは、候補パスの数及び/又は前記パスの長さを管理可能なレベルに保持すること、及び、前記地図マッチングプロセスが効率的に進行するのを可能にすることを助けるかもしれない。前記方法は、パスを破棄すること、及び/又は、候補パスの前記長さを低減することを含んでもよい。前記方法は、パスの重複部分のうち少なくとも1つの部分を除去することを含んでもよい。前記候補パスプールをアクティブに管理することは、変化を前記候補データプールに反映するために前記候補パスデータベースを更新することを含んでもよい。
【0042】
これらのステップは、様々な基準に基づいてもよい。例えば、候補パスは、重複部分、例えば尾(テール)の部分を含んでもよい。これは、上記のように前記現在位置が2つ以上の出ていく区分を有する交差点の近くにある時に候補パスを拡張する結果となるかもしれない。前記元の候補パスは、前記交差点から異なる区分に沿って継続する複数の新規の固有のパスの一部を形成するためにコピーされてもよい。前記候補パスプールを管理する前記方法は、候補パスの尾(テール)の部分を取り除くステップを含んでもよい。前記方法は、前記候補パスのうちの異なるパスの間で共有される尾(テール)の部分を特定して取り除くこと、例えば前記パスの共通祖先部分を除外すること、を含んでもよい。これら尾(テール)の部分は通常、前記現在位置は前記元の候補パスの先(ヘッド)を超えて進行するにつれて、前記マッチングプロセスにおいて冗長となる。
【0043】
パスは、前記位置データと最もマッチングする候補パスを判定するために候補パスとの前記位置データのマッチングの結果に基づいて破棄されてもよい。これは、パスが前記位置データに関連して大きすぎるオフセットを有することが分かる場合、及び/又は、パスが、前記移動パスのマッチングの低いレベルの可能性を有することが分かる時に、当てはまるだろう。
【0044】
候補パスの前記プールの前記管理は、移動されている領域内の前記ナビゲート可能ネットワークの特性に基づいて制御されてもよい。例えば前記ナビゲート可能ネットワークが高密度の都市道路ネットワークである場合、比較的多くのノードが存在するだろう。これは、パスの頻繁な拡張及び増加となるだろう。一方、幹線道路に沿って移動する場合は、比較的少ないノードが存在するだろうし、地図区分はより長くなる傾向にあるだろう。このシナリオでは、候補パスの前記プールは、それほど大きなレートで増加しないだろう。それ故、より積極的な前記プールの管理は、前記プールを管理可能なレベルに維持するために前記都市環境において有益である。
【0045】
ある特別なケースでは、前記候補プールの適合が、役立つ候補パスを提供するために必要とされてもよい。そのような1つのケースは、前記現在位置がトンネル内にある場合である。いくつかの実施形態では、前記方法は、前記現在位置がトンネル内にある、或いはトンネルに近づいていることを判定することを含んでもよい。これは、所与の閾値を超過する期間、衛星ベースの位置データが不存在であることから推論されてもよい。近づいているトンネルは、地図データを使用して検出されてもよい。前記方法は、前記トンネルの出口に至る区分のみに沿って候補パスを拡張することを含んでもよい。
【0046】
本発明の更なる態様によれば、装置の現在位置を、ナビゲート可能要素のネットワークを示す電子地図とマッチングする方法であって、前記電子地図は前記ナビゲート可能要素を表す複数の区分を含む、前記方法は、
前記装置の移動を示す位置データを取得することであって、前記位置データは異なる時間での前記装置の位置を示す複数の位置データサンプルを含む、前記取得することと、
前記電子地図によりカバーされる前記エリアの少なくとも部分に関する電子地図データを取得することと、
前記電子地図に対する候補パスのプールを維持することであって、各候補パスは前記装置の前記現在位置がマッチングされてもよい前記電子地図を通る可能なパスであり、各候補パスは前記電子地図の1以上の区分を含み、前記維持することは、前記現在位置がトンネル内にあること或いはトンネルに接近していることを検出することに応じて、元の候補パスの先端を提供する区分に接続される少なくとも1つの区分を含む拡張候補パスを提供するために1つ以上の前記候補パスを拡張することにより、候補パスの前記プールを更新することをさらに含み、前記区分は前記トンネルの出口に至る区分である、前記維持することと、を含み、
前記方法は、
複数の前記位置データサンプルに基づいて、前記位置データとの最適なマッチングを提供する候補パスを前記プールから特定することと、
前記地図とマッチングされた現在位置として出力のために前記電子地図の区分に対する前記装置の推定現在位置を取得する際に、前記特定された候補パスを使用することと、
前記地図とマッチングされた現在位置を示すデータを生成することと、
をさらに含む方法が提供される。
【0047】
本発明は、本明細書に記載の本発明の態様又は実施形態の何れかに従った方法を実行するシステムに及ぶ。従って、本発明の別の態様によれば、装置の現在位置を、ナビゲート可能要素のネットワークを示す電子地図とマッチングするシステムであって、前記電子地図は前記ナビゲート可能要素を表す複数の区分を含む、前記システムは、
前記装置の移動を示す位置データを取得する手段であって、前記位置データは異なる時間での前記装置の位置を示す複数の位置データサンプルを含む、前記取得する手段と、
前記電子地図によりカバーされる前記エリアの少なくとも部分に関する電子地図データを取得する手段と、
前記電子地図に対する候補パスのプールを維持する手段であって、各候補パスは前記装置の前記現在位置がマッチングされてもよい前記電子地図を通る可能なパスであり、各候補パスは前記電子地図の1以上の区分を含み、前記維持することは、前記現在位置がトンネル内にあること或いはトンネルに接近していることを検知することに応じて、元の候補パスの先端を提供する区分に接続される少なくとも1つの区分を含む拡張候補パスを提供するために1つ以上の前記候補パスを拡張することにより、候補パスの前記プールを更新することをさらに含み、前記区分は前記トンネルの出口に至る区分である、前記維持する手段と、を備え、
前記システムは、
複数の前記位置データサンプルに基づいて、前記位置データとの最適なマッチングを提供する候補パスを前記プールから特定する手段と、
前記地図とマッチングされた現在位置として出力のために前記電子地図の区分に対する前記装置の推定現在位置を取得する際に、前記特定された候補パスを使用する手段と、
前記地図とマッチングされた現在位置を示すデータを生成する手段と、
をさらに備えるシステムが提供される。
【0048】
当業者により理解されるように、本発明のこの更なる態様は、必要に応じて、本発明の他の態様の何れかに関して本明細書に記載された本発明の好適且つ選択的な特徴のうちの1つ以上又は全てを含みうるし、好適には含む。明示的に述べられていなくても、本発明のシステムは、何れかの態様又は実施形態における本発明の方法に関して記載された何れかのステップを実行する手段を備えてもよく、その逆もまた同様である。
【0049】
これらの更なる態様に従った本発明はコンピュータ実施発明であり、本発明の何れかの態様又は実施形態に関連して記載した何れかのステップは、1以上のプロセッサのセットの制御下で実行されてもよい。前記システムに関連して記載した何れかのステップを実行する手段は、1以上のプロセッサのセットであってもよい。
【0050】
候補パスの前記先端が、前記トンネルの出口に至る多数の出ていく区分を有するノードで終了する実施形態では、前記方法は、前記ノードにおいて前記元の候補パスの先端を提供する前記区分と接続された少なくとも1つの前記出ていく区分を含む拡張候補パスを提供するために前記候補パスを拡張することと、前記ノードにおいて前記元の候補パスの前記先端を提供する前記区分と接続された少なくとも1つのその他の出ていく区分を含む少なくとも1つの追加の候補パスを生成することとを含んでもよい。前記又は各追加の候補パスは、前記元の候補パスに対応する前記ノードに続く部分をさらに含んでもよい。換言すれば、前記元の候補パスは、1つ以上の更なる固有の候補パスを提供するために、コピーされて異なる方法で拡張されてもよい。このプロセスは、前記トンネルの出口に至る前記ノードから生じる各区分について実行されてもよい。
【0051】
別の特別なケースはUターンが検出される場合である。この状況では、以前に前記プールに含まれているものと反対の方向を伴う追加の候補パスが作成されてもよい。実施形態において、候補パスの前記動的プールは候補パスの第1のセットを含み、各パスは、前記装置の前記現在位置がマッチングされてもよい前記電子地図を通る第1の運転方向における可能なパスであり、前記方法は、前記装置によりUターン操作が実行されたことを検出することに応じて、前記動的プールに含めるための候補パスの追加のセットを作成することを含み、各候補パスは前記装置の前記現在位置がマッチングされてもよい前記電子地図を通る反対の第2の運転方向における可能なパスであり、各候補パスは前記電子地図の1以上の区分の少なくとも1つの部分を含む。候補パスの前記追加のセットは、前記運転方向が逆のままである間、地図マッチングに使用されてもよい。しかしながら、前記Uターン検出が誤りであり且つ前記運転方向が不変のままである場合、例えばUターンと混同される急カーブの場合、好適には候補パスの前記元のセットは維持される。パスの両方のセットを維持することは、運転方向が変化するにつれて継続的な地図マッチングを可能にする。以前の運転方向に関するパスは、マッチングが進むにつれて段階的に破棄されてもよい。
【0052】
本発明の更なる態様によれば、装置の現在位置を、ナビゲート可能要素のネットワークを示す電子地図とマッチングする方法であって、前記電子地図は前記ナビゲート可能要素を表す複数の区分を含む、前記方法は、
前記装置の移動を示す位置データを取得することであって、前記位置データは異なる時間での前記装置の位置を示す複数の位置データサンプルを含む、前記取得することと、
前記電子地図によりカバーされる前記エリアの少なくとも部分に関する電子地図データを取得することと、
前記電子地図に対する候補パスのプールを維持することであって、各候補パスは前記装置の前記現在位置がマッチングされてもよい前記電子地図を通る第1の運転方向における可能なパスであり、各候補パスは前記電子地図の1以上の区分を含み、前記維持することは、前記装置によりUターン操作が実行されたことを検出することに応じて、前記プールに含めるための候補パスの追加のセットを作成することをさらに含み、各候補パスは前記装置の前記現在位置がマッチングされてもよい前記電子地図を通る反対の第2の運転方向における可能なパスであり、各候補パスは前記電子地図の1以上の区分を含む、前記維持することと、を含み、
前記方法は、
複数の前記位置データサンプルに基づいて、前記位置データとの最適なマッチングを提供する候補パスを前記プールから特定することと、
前記地図とマッチングされた現在位置として出力のために前記電子地図の区分に対する前記装置の推定現在位置を取得する際に、前記特定された候補パスを使用することと、
前記地図とマッチングされた現在位置を示すデータを生成することと、
をさらに含むことを特徴とする方法。
【0053】
本発明は、本明細書に記載の本発明の態様又は実施形態の何れかに従った方法を実行するシステムに及ぶ。従って、本発明の別の態様によれば、装置の現在位置を、ナビゲート可能要素のネットワークを示す電子地図とマッチングするシステムであって、前記電子地図は前記ナビゲート可能要素を表す複数の区分を含む、前記システムは、
前記装置の移動を示す位置データを取得する手段であって、前記位置データは異なる時間での前記装置の位置を示す複数の位置データサンプルを含む、前記取得する手段と、
前記電子地図によりカバーされる前記エリアの少なくとも部分に関する電子地図データを取得する手段と、
前記電子地図に対する候補パスのプールを維持する手段であって、各候補パスは前記装置の前記現在位置がマッチングされてもよい前記電子地図を通る第1の運転方向における可能なパスであり、各候補パスは前記電子地図の1以上の区分を含み、前記維持することは、前記装置によりUターン操作が実行されたことを検出することに応じて、前記プールに含めるための候補パスの追加のセットを作成することをさらに含み、各候補パスは前記装置の前記現在位置がマッチングされてもよい前記電子地図を通る反対の第2の運転方向における可能なパスであり、各候補パスは前記電子地図の1以上の区分を含む、前記維持する手段と、を備え、
前記システムは、
複数の前記位置データサンプルに基づいて、前記位置データとの最適なマッチングを提供する候補パスを前記プールから特定する手段と、
前記地図とマッチングされた現在位置として出力のために前記電子地図の区分に対する前記装置の推定現在位置を取得する際に、前記特定された候補パスを使用する手段と、
前記地図とマッチングされた現在位置を示すデータを生成する手段と、
をさらに備えるシステムが提供される。
【0054】
当業者により理解されるように、本発明のこの更なる態様は、必要に応じて、本発明の他の態様の何れかに関して本明細書に記載された本発明の好適且つ選択的な特徴のうちの1つ以上又は全てを含みうるし、好適には含む。明示的に述べられていなくても、本発明のシステムは、何れかの態様又は実施形態における本発明の方法に関して記載された何れかのステップを実行する手段を備えてもよく、その逆もまた同様である。
【0055】
これらの更なる態様に従った本発明はコンピュータ実施発明であり、本発明の何れかの態様又は実施形態に関連して記載した何れかのステップは、1以上のプロセッサのセットの制御下で実行されてもよい。前記システムに関連して記載した何れかのステップを実行する手段は、1以上のプロセッサのセットであってもよい。
【0056】
別の特別なケースは逆方向の運転が検出される場合である。逆運転は、Uターン後等の、反対方向の前方運転ではなく、前記車両の逆モードおける後方運転を指す。従って、装置、又は前記装置が関連付けられた車両は、逆方向時、前方移動時と同一方向をまだ向いているだろう。地図マッチングの目的で、反対方向における前方運転として逆方向の運転を取り扱うこと、及び、それにより前記候補プールを適合させる及び/又は生成することが望まれることが分かっている。これは、前記地図マッチングプロセスが逆方向の運転中に前方方向へ動作することを可能とする。地図マッチングが前方運転方向に実行されることを可能にするために前記地図マッチング方法を実行する前に、前記装置の方位は内部的に逆になるかもしれない。その場合、前記地図マッチングされた位置と関連付けられた前記方位は、前記地図マッチングプロセス後にもう一度、内部的に逆になるべきである。
【0057】
逆方向の運転に関する本発明の実施形態では、逆方向の運転の検出は、任意の適当な方法で検出されてもよい。通常、逆方向の運転は、デッドレコニングセンサベースの位置データを使用して検出される。DRセンサベースの位置データは、逆方向の運転が実行されている時、負の移動距離を示してもよい。逆方向の運転は、例えば前記車両内のカメラ等の撮像装置からの画像を解析することによって検出することもでき、例えば、前方を向くカメラの場合、特徴は、前方運転時に撮像画像におけるサイズが増加するだろうし、後方運転時にサイズが減少するだろうし、後方を向くカメラについて逆もまた同様である。
【0058】
逆方向の運転が検出される場合、どのようにしてこれが達成されようと、以前に前記プールに含まれたものと反対の方向を伴う候補パスのセットが作成されてもよい。実施形態において、候補パスの前記動的プールは、前記装置が逆方向へ移動していることを検出することに応じて、候補パスの新規のセットと置換され、各候補パスは、前記装置の前記現在位置がマッチングされてもよい前記電子地図を通る反対の第2の運転方向における可能なパスであり、各候補パスは前記電子地図の1以上の区分を含む。候補パスの前記新規のセットは、逆方向の運転が継続する間、地図マッチングに使用されてもよい。逆方向の運転が停止し、前記車両が前記第1の方向に再び移動し始めると、候補パスの前記動的プールは、候補パスの新規のセットと再び置換され、各候補パスは、前記装置の前記現在位置がマッチングされてもよい前記電子地図を通る前記第1の運転方向における可能なパスであり、各候補パスは前記電子地図の1以上の区分を含む。
【0059】
本発明の更なる態様によれば、装置の現在位置を、ナビゲート可能要素のネットワークを示す電子地図とマッチングする方法であって、前記電子地図は前記ナビゲート可能要素を表す複数の区分を含む、前記方法は、
前記装置の移動を示す位置データを取得することであって、前記位置データは異なる時間での前記装置の位置を示す複数の位置データサンプルを含む、前記取得することと、
前記電子地図によりカバーされる前記エリアの少なくとも部分に関する電子地図データを取得することと、
前記電子地図に対する候補パスのプールを維持することであって、各候補パスは前記装置の前記現在位置がマッチングされてもよい前記電子地図を通る第1の運転方向における可能なパスであり、各候補パスは前記電子地図の1以上の区分を含み、前記維持することは、逆方向の運転が行われていることを検出することに応じて、前記プール内の候補パスを置き換えるために候補パスの新規のセットを作成することをさらに含み、前記新規の候補パスの各々は前記装置の前記現在位置がマッチングされてもよい前記電子地図を通る反対の第2の運転方向における可能なパスであり、各候補パスは前記電子地図の1以上の区分を含む、前記維持することと、を含み、
前記方法は、
複数の前記位置データサンプルに基づいて、前記位置データとの最適なマッチングを提供する候補パスを前記プールから特定することと、
前記地図とマッチングされた現在位置として出力のために前記電子地図の区分に対する前記装置の推定現在位置を取得する際に、前記特定された候補パスを使用することと、
前記地図とマッチングされた現在位置を示すデータを生成することと、
をさらに含む方法が提供される。
【0060】
本発明は、本明細書に記載の本発明の態様又は実施形態の何れかに従った方法を実行するシステムに及ぶ。従って、本発明の別の態様によれば、装置の現在位置を、ナビゲート可能要素のネットワークを示す電子地図とマッチングするシステムであって、前記電子地図は前記ナビゲート可能要素を表す複数の区分を含む、前記システムは、
前記装置の移動を示す位置データを取得する手段であって、前記位置データは異なる時間での前記装置の位置を示す複数の位置データサンプルを含む、前記取得する手段と、
前記電子地図によりカバーされる前記エリアの少なくとも部分に関する電子地図データを取得する手段と、
前記電子地図に対する候補パスのプールを維持する手段であって、各候補パスは前記装置の前記現在位置がマッチングされてもよい前記電子地図を通る第1の運転方向における可能なパスであり、各候補パスは前記電子地図の1以上の区分を含み、前記維持することは、逆方向の運転が行われていることを検出することに応じて、前記プール内の候補パスを置き換えるために候補パスの新規のセットを作成することをさらに含み、前記新規の候補パスの各々は前記装置の前記現在位置がマッチングされてもよい前記電子地図を通る反対の第2の運転方向における可能なパスであり、各候補パスは前記電子地図の1以上の区分を含む、前記維持する手段と、を備え、
前記システムは、
複数の前記位置データサンプルに基づいて、前記位置データとの最適なマッチングを提供する候補パスを前記プールから特定する手段と、
前記地図とマッチングされた現在位置として出力のために前記電子地図の区分に対する前記装置の推定現在位置を取得する際に、前記特定された候補パスを使用する手段と、
前記地図とマッチングされた現在位置を示すデータを生成する手段と、
をさらに備えるシステムが提供される。
【0061】
当業者により理解されるように、本発明のこの更なる態様は、必要に応じて、本発明の他の態様の何れかに関して本明細書に記載された本発明の好適且つ選択的な特徴のうちの1つ以上又は全てを含みうるし、好適には含む。明示的に述べられていなくても、本発明のシステムは、何れかの態様又は実施形態における本発明の方法に関して記載された何れかのステップを実行する手段を備えてもよく、その逆もまた同様である。
【0062】
これらの更なる態様に従った本発明はコンピュータ実施発明であり、本発明の何れかの態様又は実施形態に関連して記載した何れかのステップは、1以上のプロセッサのセットの制御下で実行されてもよい。前記システムに関連して記載した何れかのステップを実行する手段は、1以上のプロセッサのセットであってもよい。
【0063】
逆運転を含む本発明の態様及び実施形態によれば、候補パスの前記新規のセットを作成するステップは、候補パスの元のセットのうちの1以上、好適には各々について、前記第1の運転方向に所定距離、前記候補パスを拡張することと、前記候補パスに沿って前記所定距離だけ前記地図マッチングされた現在位置を人工の地図マッチングされた現在位置へ進めることと、前記人工の地図マッチングされた現在位置に基づいて前記第2の、反対の運転方向に候補パスを生成することとを含んでもよい。前記地図マッチングされた現在位置をこのようにして人工的に進めること、そして、前記実際の現在地図マッチングされた位置に基づくのではなく、前記人工的な地図マッチングされた現在位置に基づいて前記反対方向に候補パスを生成することには利点があることが分かっている。これは、前記地図マッチングされた現在位置の前の任意の交差点が、逆候補パスが生成される前に考慮されることを保証するかもしれず、作成された候補パスの前記追加セットにおける接続性を維持するのを助ける。これにより、トポロジー情報が本質的に考慮されるので、上で議論された理由で改良された地図マッチングになるかもしれない。
【0064】
前記第1の運転方向に所定距離、候補パスの前記元のセットのうちの候補パスを拡張するステップは、前記元の候補パスの先端を提供する前記区分と接続された少なくとも1つの区分を含む拡張された候補パスを提供するために前記パスを拡張することを含んでもよい。前記区分は、ノードで相互に接続されるだろう。前記接続された区分は通常、前記元の候補パスの前記区分の前記先端が終了するノードにおける出ていく区分である。元の候補パスの前記先端を提供する前記区分が多数の出ていく区分を有するノードで終了する場合、前記候補パスの前記先端を提供する前記区分は、多数の区分と接続される。この状況では、前記方法は、前記ノードで前記元の候補パスの先端を提供する前記区分と接続された前記出ていく区分の別の1つを含む追加の候補パスを提供するために、前記第1の運転方向に所定距離、前記候補パスを拡張することをさらに含んでもよい。このプロセスは、前記ノードから生じる各区分について実行されてもよい。
【0065】
前記第2の、反対の運転方向における前記候補パスの生成は好適には、前記人工の地図マッチングされた現在位置と関連付けられた前記区分を特定することと、前記区分の前記先端(ノード)及び尾端(ノード)が切り替えられる(スイッチされる)ように前記区分を逆にすることとを含む。従って、前記第2の運転方向に前記候補パスを作成するために前記パスを拡張するステップは、前記人工的な地図マッチングされた現在位置が存在する前記区分と接続された少なくとも1つの区分を含めるために前記パスを拡張することを含んでもよい。前記区分は、ノードで相互に接続されるだろう。前記区分は、前記第1の運転方向に対して前記区分の尾端と、又は、前記第2の運転方向に対して前記区分の前記先端と、接続された区分だろう。
【0066】
前記第2の、反対の運転方向におけるこれらの新規の候補パスは、候補パスの前記プールにおける前記元のパスを置換する。理解されるように、これは、Uターン操作の実行が検出された時とは異なっており、この後者の場合では、前記第1の運転方向及び前記反対の、第2の運転方向における両方の候補パスが前記プールに維持される。
【0067】
人工的な地図マッチングされた現在位置から前記第2の運転方向にパスを拡張することによって、候補パスの前記新規のセットが生成される実施形態では、前記方法は、好適には、前記新規の候補パスの1以上、好適には各々について、前記新規の候補パスにおける1以上の地図マッチングされた位置を特定するために前記第2の運転方向に前記所定距離だけ前記人工的な地図マッチングされた現在位置を移動することを含む。このステップは、好適には(前記第2の、反対の運転方向における)前記新規の候補パスを生成するために実行された前記第1の運転方向における前記所定距離だけの前記地図マッチングされた現在位置の前記人工的な移動を補う。従って、前記現在位置が、前記第1の運転方向における候補パスの前記元のセットからの候補パスの区分と以前地図マッチングされた一方で、それは今、前記第2の、逆の運転方向における候補パスの一部を形成する区分上の対応位置にある。
【0068】
新規の、すなわち前記第2の運転方向における、候補パスの前記セットは、前記元の候補パスを作成する時に考慮された前記制限のいくつかを使用すること無しに判定されることが理解されるだろう。例えば、前記道路ネットワークの一方通行路に関する区分は、前記第2の運転方向において、候補パスを生成する時に常に移動可能であると考えられており、その一方で、前記第1の運転方向において、それらの区分は、候補パスを生成する時に、一方向、すなわち法律上の方向に移動可能であるのみであると考えられている。
【0069】
本発明によれば、その何れかの態様又は実施形態において、前記方法は、前記位置データとの最適なマッチを提供する前記プールから候補パスを特定するステップを含む。
【0070】
好適には、前記方法は、前記位置データとの最適なマッチを提供する前記候補パスを判定するために複数の候補パスの各々と前記位置データをマッチングすることを含む。好適には、前記候補パスの各々と前記取得された位置データをマッチングする前記ステップは、候補パスごとに独立して実行される。好適には、前記マッチングするステップは、前記候補プールの各候補パスに関して実行される。
【0071】
前記取得された位置データを所与の候補パスとマッチングすることは、(最近の又は現在の位置データサンプルを含む)複数の前記取得された位置データサンプルを使用して実行される。従って、前記位置データに従った位置トレース(位置追跡)、又はパスが、前記候補パスと比較される。考慮された位置サンプルの数、すなわち前記位置トレース(位置追跡)の長さは、所望に選択されてもよく、動的に変化してもよく、異なるマッチング基準に対して異なっていてもよい。前記複数のデータサンプルは、最近のデータサンプル、すなわち前記地図とマッチングされるべき前記現在位置、および、前のデータサンプルのうちの1以上(好適には複数)のセットを含む。多数の位置データサンプルに基づく本明細書での候補パスと前記位置データをマッチングすることへの任意の言及は、このようにして理解されてもよい。
【0072】
前記方法は、好適には、前記位置データを複数の前記候補パスの各々と、好適には前記候補パスプールの各候補パスと、マッチングすることを含む。各場合において、複数の前記データサンプルが考慮される。データサンプルの同一の1又は複数のセットは通常、各パスに関して前記マッチングプロセスで使用される。上述したように、異なるサイズの、データサンプルの異なるセットが異なるマッチング基準に関して使用されてもよい。
【0073】
好適な実施形態では、前記方法は、考慮される各候補パスについて、複数のマッチング基準に従って前記位置データを前記候補パスとマッチングすることを含む。前記マッチング基準は所望に選択されてもよい。しかしながら、好適には、前記取得された位置データを所与の候補パスとマッチングする前記ステップは、前記位置データを使用して判定されるような少なくとも方位及び位置を考慮する。好適には、マッチングは、前記基準の各々に関して独立して実行される。これは、前記基準、例えば方位及び位置、の各々について独立したマッチングエンジンを使用して達成されてもよい。前記マッチングエンジンは、ある基準に関する前記マッチングが、他の基準に関する前記マッチングに影響しないという点で独立している。
【0074】
前記方法は、好適には、考慮される各候補パスについて、前記位置データが前記候補パスにマッチングする程度を示すスコアを提供することと、それら各々のスコアに少なくとも基づいて前記候補パスをランク付けすることとを含む。候補パスとのマッチングが多数の基準に基づいて実行される場合、好適には、前記位置データが前記候補パスとマッチングする程度を示す各スコアは、前記マッチング基準の各々について取得され、前記方法は前記候補パスについての全体のマッチングスコアを提供するために各スコアを統合することを含む。これは、上で議論されたように、前記基準の各々に関して独立したマッチングを実行することによって達成されてもよい。それ故、好適な実施形態では、少なくとも方位及び位置に関する各マッチングスコアは、各候補パスについて取得されて、前記候補パスについての全体のマッチングスコアを取得する際に使用される。複数のマッチング基準の各々に関する個々のスコアに基づいて候補パスについての全体のマッチングスコアを取得するステップは、任意の適当な方法で実行されてもよい。好適には、ビリーフ理論(belief theory)に基づく技術、例えばデンプスター・シェ-ファー理論(Dempster-Shafer theory)が使用される。しかしながら、隠れマルコフ、ファジィ論理又はカルマンフィルタ等の他の技術が使用されてもよい。
【0075】
所与の候補パスに関する前記マッチングスコアは、前記位置データサンプルにより規定された前記位置トレースが前記パスとマッチングする可能性、すなわち確率を示す。これは、任意の全体のマッチングスコア、及び、スコアが判定される好適な実施形態における特定の基準に関するスコアに当てはまる。
【0076】
考慮される各候補パスに関してスコアが取得されると、それが、多数の異なるマッチング基準に基づいて判定されたスコアに基づく全体のスコアであろうとなかろうと、前記方法は、前記位置データとの最適なマッチングを提供する候補パスが判定されるのを可能にするために前記候補パスをランク付けすることを含んでもよい。前記ランク付けすることは、各候補パスに関して判定された前記スコアに少なくとも基づくものである。前記ランク付けすることは、以下に記載されるような、オフセット等の他の要因(ファクタ)を考慮してもよい。
【0077】
前記候補パスプールをアクティブに管理する前記ステップは、更に又は或いは、前記マッチングプロセスの結果に基づいて前記プールから1以上の候補パスを破棄することを含んでもよい。これは、候補パスデータベースから前記(複数の)パスを除外することを含んでもよい。前記マッチングプロセスの間に前記位置データトレースと比較して大きすぎるオフセットを有することが発見されたパスが、破棄されてもよい。候補パスの前記プールの管理は、更に又は或いは、候補パスの前記判定されたランク付けを考慮してもよい。前記方法は、前記候補の前記判定されたランク付けに基づいて前記プールから前記候補パスの1つ以上を破棄することを含んでもよい。これは、パスと関連付けられた絶対スコアに基づいてパスを破棄するよりも、効果的であることが分かっている。前記ランク付けすることは、周辺道路ネットワークの密度等の要因(ファクタ)に影響されない候補パスの相対的適合性の指標を提供する。
【0078】
多数の基準に関して独立したマッチングを実行し、候補パスのマッチ度を示す全体のスコアを提供するために前記マッチングプロセスの結果を統合することは、前記異なる基準に関するマッチングが、前記位置データ及び前記地図データの両方における異なる誤差スコアを解析してもよい点で、利点がある。これにより、より正確な判定された推定位置となるだろう。そうした特徴は、候補パスのプールを使用する状況とは独立して、又は、マッチングが多数の位置サンプルを考慮する場合とは独立して、利点があると考えられている。
【0079】
本発明の更なる態様によれば、装置の現在位置を、地理的エリア内のナビゲート可能要素のネットワークを示す電子地図とマッチングする方法であって、前記電子地図は前記ナビゲート可能要素を表す複数の区分を含む、前記方法は、
前記装置の前記位置を示す位置データサンプルを含む位置データを取得することと、
前記電子地図によりカバーされる前記エリアの少なくとも部分に関する電子地図データを取得することと、
前記電子地図の区分のセットにおける複数の区分の各々について、前記現在位置が前記電子地図の前記区分にマッピングされてもよい可能性を示す第1の基準に基づいて第1のスコアを提供するために第1のマッチングエンジンを使用することと、
前記セットにおける前記複数の区分の各々について、前記現在位置が前記電子地図の前記区分にマッピングされてもよい可能性を示す第2の基準に基づいて第2のスコアを提供するために第2のマッチングエンジンを使用することと、
前記セットにおける前記複数の区分の各々について、前記現在位置が前記区分にマッピングされてもよい可能性を示す全体スコアを判定するために少なくとも前記第1及び第2のスコアを使用することと、
前記地図マッチングされた現在位置としての出力のために前記電子地図の区分の前記セットの区分に対する前記装置の推定現在位置を取得するために、前記電子地図の前記複数の区分に関して判定された前記全体スコアを使用することと、
前記地図マッチングされた現在位置を示すデータを生成することと、
を含む方法が提供される。
【0080】
本発明は、本発明の態様又は実施形態の何れかに従った当該方法を実行するシステムに及ぶ。前記システムは、本発明のより前の態様に関して記載されたような、サーバ、移動装置、或いはその組み合わせにより提供されてもよい。従って、本発明の更なる態様によれば、装置の現在位置を、地理的エリア内のナビゲート可能要素のネットワークを示す電子地図とマッチングするシステムであって、前記電子地図は前記ナビゲート可能要素を表す複数の区分を含む、前記システムは、
前記装置の前記位置を示す位置データサンプルを含む位置データを取得する手段と、
前記電子地図によりカバーされる前記エリアの少なくとも部分に関する電子地図データを取得する手段と、
前記電子地図の区分のセットにおける複数の区分の各々について、前記現在位置が前記電子地図の前記区分にマッピングされてもよい可能性を示す第1の基準に基づいて第1のスコアを提供するために第1のマッチングエンジンを使用する手段と、
前記セットにおける前記複数の区分の各々について、前記現在位置が前記電子地図の前記区分にマッピングされてもよい可能性を示す第2の基準に基づいて第2のスコアを提供するために第2のマッチングエンジンを使用する手段と、
前記セットにおける前記複数の区分の各々について、前記現在位置が前記区分にマッピングされてもよい可能性を示す全体スコアを判定するために少なくとも前記第1及び第2のスコアを使用する手段と、
前記地図マッチングされた現在位置としての出力のために前記電子地図の区分の前記セットの区分に対する前記装置の推定現在位置を取得するために、前記電子地図の前記複数の区分に関して判定された前記全体スコアを使用する手段と、
前記地図マッチングされた現在位置を示すデータを生成する手段と、
を備えるシステムが提供される。
【0081】
当業者により理解されるように、本発明のこの更なる態様は、必要に応じて、本発明の他の態様の何れかに関して本明細書に記載された本発明の好適且つ選択的な特徴のうちの1つ以上又は全てを含みうるし、好適には含む。明示的に述べられていなくても、本発明のシステムは、何れかの態様又は実施形態における本発明の方法に関して記載された何れかのステップを実行する手段を備えてもよく、その逆もまた同様である。
【0082】
これらの更なる態様に従った本発明はコンピュータ実施発明であり、本発明の何れかの態様又は実施形態に関連して記載した何れかのステップは、1以上のプロセッサのセットの制御下で実行されてもよい。前記システムに関連して記載した何れかのステップを実行する手段は、1以上のプロセッサのセットであってもよい。
【0083】
前記第1及び第2のマッチングエンジンは、好適には、相互に独立している。前記第1及び第2の基準は、方位及び位置であってもよい。1つ以上の追加の独立したマッチングエンジンが、各々の更なる基準に関する更なるスコアを提供するために使用されてもよい。
【0084】
前記方法は、各区分についての各基準に関するスコア提供するように、前記電子地図の多数の区分に関して前記第1及び第2のマッチングエンジンを使用して、且つ、前記現在位置が前記区分にマッピングされてもよい前記可能性に関して各区分に関する全体スコアを取得するために各基準に関する前記スコアを使用して、前記マッチングプロセスを実行することを含む。換言すれば、前記第1及び第2のスコア、及び前記全体スコアを取得する前記ステップは、前記地図の多数の区分について繰り返される。前記区分に対する前記全体スコアは、前記電子地図の区分に対する前記装置の前記現在位置を推定する際に使用される。
【0085】
前記方法は、前記全体スコアに基づいて前記位置データとの最適なマッチングを提供する前記区分を特定することを含んでもよい。前記方法は、好適には、前記区分について判定された前記全体スコアを使用して、前記現在位置が前記区分にマッピングされてもよい可能性に少なくとも基づいて前記区分の各々をランク付けすることを含む。
【0086】
前記マッチングは、本発明のより前の態様に関して記載された何れかの方法で、すなわち述べられた前記基準に基づいて、実行されてもよく、前記個々のスコア及び全体スコアは、例えばビリーフ理論を使用して前記全体スコアを提供する、より前の態様の何れかに関して記載されたように取得されてもよい。
【0087】
これらの更なる本発明の態様及び実施形態では、少なくとも前記位置データすなわち最近の位置データサンプルに従った前記現在位置が、各区分について前記スコアを判定する際に使用される。それ故、本発明のより前の態様とは対照的に、単一の地点位置が前記スコアリングするステップで使用されてもよい。しかしながら、他の実施形態では、複数の位置データサンプルが使用される。これは、本発明のより前の態様のように進行してもよい。前記位置データサンプルは、最近の、すなわち現在位置データサンプルを含むだろう。前記位置データは、前に記載された何れかの種類であってもよい。多数の位置データサンプルが使用される場合、これらは、異なる時間に関するものであり、タイムスタンプ付きの位置データサンプルであってもよい。
【0088】
これらの更なる態様及び実施形態では、前記現在位置が前記区分にマッピングされてもよい可能性を示す各基準に基づいてマッチングエンジンがスコアを提供するステップは、好適には、前記マッチングエンジンが、その基準に基づいて前記区分と前記位置データをマッチングすることを含む。前記スコアは、前記マッチングの近さに基づくものである。
【0089】
前記マッピングプロセスで使用される前記位置データは、前記位置データ、すなわち最近の(直近の)位置データサンプルに従った現在位置を少なくとも含む。使用される前記位置データは、単一のデータ地点、すなわち前記現在位置のみであってもよく、或いは、複数の位置データサンプル、すなわち、前記現在位置、及び、本発明のより前の態様に関して記載されたような1つ以上のより前の位置データ地点を含んでもよい。前記マッチングプロセスは、本発明のより前の態様に関して記載された何れかの方法で実行されてもよく、マッチングは前記電子地図の区分に対するもの以外でもよく、必ずしも候補パスでなくてもよい。他の実施形態では、前記マッチングプロセスがパスに関して実行されるように、前記区分は、前記電子地図を通るパスの一部を形成してもよいことが想定される。これは、本発明のより前の態様と同様にして進行してもよい。前記パスはパスのプールの一部を形成してもよいし、形成しなくてもよい。
【0090】
本発明によれば、その何れかの態様又は実施形態において、前記基準の各々に関する前記マッチングは、好適には、前記装置の前記現在位置に関する最適な推定を提供する前記候補パス(又は前記更なる態様における区分)上の地点を特定するステップを含む。前記地点は前記候補パスの区分上の地点である。それ故、所与の基準(例えば各マッチングエンジン)に関する各マッチングプロセスの前記出力は、好適には、前記適用可能なマッチング基準、及び、前記候補パス(又は区分)についての各マッチングスコアに従って、前記装置の前記現在位置に関する最適な推定を提供する前記候補パス(又は区分)上の地点を示すデータである。当該データは、好適には、位置及び方位に基づくマッチングに少なくとも関して取得される。異なる基準に基づいてマッチングエンジンによって判定された候補パス(又は区分)上の前記装置の現在位置に関する最適な推定は、異なっていてもよい。前記方法は、前記パス(又は区分)上の前記現在位置に関する全体の最適な推定を判定するために各マッチングプロセスにより提供された所与の候補パス(又は区分)上の前記装置の前記現在位置に関する最適な推定を使用するステップをさらに含んでもよい。これは、パス(又は区分)のランク付けの前又は後に実行されてもよい。そのようなステップは、評価される各候補パス(又は区分)に関するステップを必ず実行するのではなく、前記位置データとの最適なマッチングである判定される候補パス(又は区分)に関して実行されるのみであってもよいことが想定される。候補パス(又は区分)について判定された前記推定された現在位置は、前記パス(又は区分)が、判定された最も可能性が高いパス(又は区分)であっても、必ずしも、前記出力される地図マッチングされた位置として使用される前記現在位置でなくてもよいことが理解されるだろう。これは、以下でより詳細に記載される。
【0091】
本発明の何れかの態様によれば、マッチングは、候補パス(又は区分)に沿って前記装置の前記現在位置に関する判定された最適な推定を使用する1つ以上の更なる基準に関して実行されてもよいことが理解されるだろう。当該マッチングは、そのような推定を判定する他の基準に関する前記マッチングの結果に、ある程度依存していると考えられてもよく、前記結果の更なる検証を提供してもよい。そのような方法は、多数のマッチングプロセスに基づく現在位置の全体の最適な推定を使用してもよい。そのような更なる基準の例は、移動距離及び速度制限マッチャーを含む。後者は、前記パス又は区分上の最適なマッチング位置での速度が、前記地図データに従った当該位置の速度制限に対応(一致)する程度を判定してもよい。前者は、前記推定位置までの前記パス又は区分に沿った移動距離を考慮してもよい。任意の更なるそのようなマッチングの結果は、例えばビリーフ理論を使用して、上記のような前記候補パス又は区分についての全体のマッチングスコアを判定する際に考慮されてもよい個々のスコアを提供するために使用されてもよい。
【0092】
候補パスを使用する本発明のそれらの態様では、前記方法は、前記位置データとの最適なマッチングを提供する候補パスを特定することを含む。このステップは、意思決定エンジンにより実行されてもよい。最適なマッチングを提供すると考えられる候補パスの特定(識別)は、前記(複数の)マッチングスコアのみに従ったランク付けに基づいてもよいし、或いは、追加の要因(ファクタ)を考慮してもよい。これらの要因(ファクタ)は、前記ランク付けプロセスにおいて考慮されてもよい。好適な実施形態では、前記特定(識別)は、考慮される候補パスごとに、前記位置データトレース及び前記候補パスの間のオフセットにさらに基づくものである。前記パスの前記スコアにより示されるように、前記パスが正確なマッチングである可能性、及び、前記位置データにより規定された前記候補パスおよび前記パスの間のオフセット、の両方を考慮することには利点がある。オフセットは、前記位置データトレースが、前記候補パスとマッチングするためにシフトされる必要がある程度を示す。これは、前記マッチングプロセスで考慮される所与の数の位置データサンプルにより判定された長さを有するトレースに基づくだろう。前記オフセットは、地図バイアス、例えば地図単純化、地図誤差等の要因(ファクタ)、及び、入力位置データバイアス、例えば、マルチパス効果、クロック誤差等に依存するだろう。確率及びオフセットベースの測定はある時失敗するかもしれないことが分かっている。例えば、確率又は可能性ベースの測定は、平行道路間を区別しないだろうし、一方、オフセットは、DRデータのみが利用可能である場合、DRドリフトにより、トンネル内で継続的に増大するだろう。それ故、地図マッチングの精度を向上させるために、オフセット及び確率の両方を考慮することには利点がある。
【0093】
同様に、必ずしも候補パスを使用するわけではない本発明の更なる態様において、前記方法は、前記位置データとの最適なマッチングを提供する区分を特定することを含んでもよい。このステップは意思決定エンジンにより実行されてもよい。最適なマッチングを提供すると考えられる区分の特定(識別)は、前記(複数の)マッチングスコアに従ったランク付けにのみ基づいてもよいし、或いは、追加の要因(ファクタ)を考慮してもよい。好適な実施形態では、前記選択は、考慮される各区分について前記位置データ及び前記区分の間のオフセットにさらに基づくものである。前記パスの前記スコアにより示されるように、前記区分が正確なマッチングである可能性、及び、前記区分および前記位置データの間の前記オフセット、の両方を考慮することには利点がある。オフセットは、前記位置データが、前記区分とマッチングするためにシフトされる必要がある程度を示す。前記オフセットが前記地点及び前記区分の間のオフセットに基づいてもよいように、使用される前記位置データが単一のデータの地点であってもよい一方、他の実施形態では、考慮される前記位置データは、(本発明のより前の態様のように)位置データトレースを規定する複数の位置データサンプルを含んでもよい。これは、前記マッチングプロセスで考慮される所与の数の位置データサンプルにより判定された長さを有するトレースに基づくだろう。
【0094】
候補パスのプールを使用する本発明のそれらの態様及び実施形態では、前記方法は、前記地図とマッチングされた現在位置として出力のために前記電子地図の区分に対する前記装置の前記現在位置の推定を取得する際に、前記特定された最適なマッチング候補パスを使用するステップを含む。前記方法は、前記特定された最適なマッチング候補パスの区分に沿った前記現在位置に関する推定を取得することと、出力されるべき前記現在位置を取得する際に前記すいていされた現在位置を使用することとを含んでもよい。前記推定された現在位置は、出力されるべき前記現在位置として使用されてもよいし、或いは、出力されるべき現在位置を判定する際に使用されてもよい。上述したように、現在位置に関する推定は、考慮される各候補パスについて判定されてもよい。これは、異なるマッチング基準を使用して前記パスについて判定された多数のそのような推定に基づいてもよい。出力のために現在位置の前記推定を取得する際に前記特定された候補パスを使用する前記ステップは、前記特定された候補パスの区分に沿った前記現在位置の推定を取得することを含んでもよい。そのような現在位置データは、例えば前記マッチングプロセスの結果として、前記候補パスと関連付けられてもよい。従って、前記ステップは、前記データにアクセスするステップを含んでもよいし、或いは、例えば前記異なるマッチング基準を使用して取得された前記パスに沿った現在位置の多数の推定に基づいて、前記データを生成することを含んでもよい。
【0095】
出力のための前記推定された現在位置は、前記特定された最適なマッチング候補パス上に存在していてもよいし、存在していなくてもよい。前記位置データと最もマッチングする候補パスを特定する前記ステップは、各新規の位置データサンプルについて繰り返されてもよいことが理解されるだろう。従って、最適なマッチング候補パスの前記特定(識別)は、継続的に更新されてもよい。前記位置データとの最適なマッチングとして特定される前記候補パスは、最後の位置データサンプルがマッチングされた候補パスに対応してもよい。しかしながら、いくつかの状況では、前記新規の位置データサンプルと最もマッチングする前記特定された候補パスは、以前のデータサンプルに関して特定されたものとは異なっていてもよい。そのような場合、前記決定エンジンは、たとえ、もはや最適なマッチングではなくても、前記新規の候補パスへ“ジャンプ”するかどうか、或いは、以前の候補パスのままにするかどうかを決定してもよい。そのような判定は、様々な要因(ファクタ)に依存してもよい。前記決定エンジンはジャンプを最少化するように構成されてもよい。例えば、ジャンプは、例えばトンネルにより、入力位置データ間に比較的大きなギャップがある場合に許可されてもよい。一方、ジャンプが以前通過した区分に戻るなら、前記決定エンジンは前記以前に特定された候補パスのままとすることを決定してもよい。いくつかの実施形態では、出力のための前記推定された現在位置は、位置データの以前のセットに基づいて前記位置データと最もマッチングするものとして特定された候補パスの区分上にある。
【0096】
いくつかの好適な実施形態では、出力のための前記推定された現在位置は、前記特定された最適なマッチング候補パス、又は、前の位置データサンプルに基づいて特定された最適なマッチング候補パス、に沿った位置である。前記新規に特定された最適なマッチングパスは、既存の最適なマッチング候補パスと比較されるという点で、前記装置の前記推定された現在位置を取得するプロセスで使用される。前記方法は、前記特定された候補パスを、以前に特定された候補パスと比較することと、前記パスの一方又は他方の区分上にある出力のための前記装置の推定現在位置を取得することとを含んでもよい。前記現在位置のベースとなるべきパスの選択は、上記のような様々な基準に基づいてもよい。このプロセスは、最適なマッチング候補パスが、前記以前の位置データサンプルがマッチングされた最適なマッチング候補パスと異なる場合に使用されてもよい。更に又は或いは、出力のために前記装置の前記推定された現在位置を取得する際に前記特定された候補パスを使用する前記ステップは、最適なマッチング候補パス、及び、追加的に、それと接続された1つ以上の候補パス、の区分上の現在位置の推定を取得することと、前記推定された現在位置のうちの1つを、出力のための前記位置として選択することとを含んでもよい。これは、交差点及び分岐点での入力位置データの不正確さを説明するのを助けるかもしれない。
【0097】
必ずしも候補パスを使用しない本発明の更なる態様又は実施形態では、前記方法は、前記電子地図の区分に対する前記装置の現在位置を推定するために、前記電子地図の前記複数の区分に関して判定された前記全体スコアを使用することを含む。このステップは、好適には、前記スコアに基づいて前記位置データとの最適なマッチングを提供する区分を特定することを含む。前記方法は、前記スコア、及び、例えば選択的にオフセットに少なくとも基づいて前記区分をランク付けすることを含んでもよい。前記全体スコアは、出力のための前記装置の前記現在位置の推定を取得するために使用される。候補パスを使用する態様及び実施形態のように、出力のための前記推定位置は、判定された最も可能性のある区分上に存在してもよいし、存在しなくてもよい。例えば、前記推定位置は、最も可能性のある区分、及び、それと接続する1つ以上の区分のうちの1つ上で選択されてもよい。前記候補パスの実施形態に関して使用された任意の技術が使用されてもよい。
【0098】
本発明の何れかの態様又は実施形態に従った出力のための前記推定された現在位置への言及は、前記地図マッチャーから出力される最後に判定された現在位置を指す。前記位置は、必ずしもユーザへ出力されなくてもよい。例えば、前記判定された位置は、システム、例えばADASシステム、経路指定エンジン等、の別の部分へ入力されてもよい。
【0099】
地図マッチングされた現在位置を示す前記生成されたデータは、所望のように使用されてもよい。例えば、前記データは、ユーザに対して前記電子地図上の前記現在位置の指標を表示するために使用されてもよく、且つ/又は、経路指定エンジンにより使用されてもよい。前記方法は、前記生成されたデータを格納することを含んでもよい。前記データは、前記装置による使用のためにリモート装置へ送信されてもよい。
【0100】
各受信された位置サンプルは、前記電子地図の区分上の位置とマッチングされてもよいことが理解されるだろう。しかしながら、前記電子地図を通る前記装置の前記移動が円滑な進行として、すなわち、ある離散的な地図マッチング位置から次の位置へジャンプすること無しに、ユーザに対して表示されるのを可能にするために、前記装置の将来位置の予測は、前記地図マッチングされた位置データに基づいて判定される。前記予測された位置は、前記電子地図上の前記装置がある前記パスの表現をレンダリングする際に使用されてもよい。本発明によれば、その何れかの態様又は実施形態において、地図マッチングされた現在位置を示す前記生成されたデータは、前記装置の1つ以上の予測更新位置を示すデータの生成用の予測エンジンへ入力されてもよい。前記予測エンジンは、1つ以上の将来時間における前記装置の前記位置を予測するために、前記地図マッチングされた現在位置を示す前記生成されたデータを使用するように構成されてもよい。換言すれば、前記予測エンジンは、前記又は各地図マッチングされた現在位置を推定する。所与の地図マッチングされた現在位置は、1つ又は複数の予測更新位置サンプルを提供するために使用されてもよい。前記予測エンジンは、地図マッチングされた位置データサンプルの入力セットよりも大きい頻度を有する複数の予測位置データサンプルの出力セットを提供してもよい。前記方法は、電子地図上に移動する装置の位置の指標を表示する際に前記予測エンジンにより提供された前記予測位置データを使用することを含んでもよい。前記予測エンジンは、前記地図マッチングされた現在位置データサンプルが比較的まばらである場合でも、例えば受信された衛星ベースの位置データの頻度に基づいて、前記装置の前記移動の表現が所望のフレームレートで表示されるのを可能にするための適当な位置予測を提供するために任意の適当な方法で動作してもよい。前記予測エンジンは、位置決め及び地図マッチングプロセスの待ち時間を考慮してもよい。前記エンジンは、前記装置の加速度及び減速度を考慮してもよい。運転が逆方向の時、すなわち逆運転中に地図マッチング位置が判定される場合、前記予測エンジンは、前記逆方向における前記位置を予測するように構成されるべきである。従って、前記出力される予測位置は、前記逆の、例えば第2の運転方向におけるパスをたどるだろう。
【0101】
本発明によれば、その何れかの態様又は実施形態において、単一の地図マッチングされた現在位置が、好適には各位置決め入力サンプルに関して生成される。前記生成されたデータは、前記電子地図の所与の区分に対する前記位置を示すデータを含んでもよい。前記データは、前記位置が存在する前記区分、及び前記区分の端部からのオフセットを少なくとも示してもよい。前記方法は、前記以前の地図マッチング位置以来移動された一連の区分を示すデータを生成することを含んでもよい。前記生成された現在位置データは、前記位置が関連する時間を示すデータ、例えばタイムスタンプと関連付けられてもよい。
【0102】
本発明に従った前記方法は、少なくとも部分的にソフトウェアを使用して実施されてもよいことが理解されるだろう。従って、更なる態様及び更なる実施形態から見ると、本発明は、適当なデータ処理手段での実行時に、本明細書に記載に方法の何れか又は全てを実行するように構成されたコンピュータ可読命令を含むコンピュータプログラム製品に及ぶことが分かるだろう。本発明は、そのようなソフトウェアを含むコンピュータソフトウェアキャリヤにも及ぶ。そのようなソフトウェアキャリヤは、物理(又は継続性のある)記憶媒体であることができ、或いは、有線の電気信号、光学信号又は衛星等の無線信号等の、信号であることができる。
【0103】
更なる態様又は実施形態の何れかに従った本発明は、相互に矛盾しない程度に、本発明の他の態様又は実施形態に関連して記載された何れかの特徴を含んでもよい。
【0104】
更なる実施形態の利点は、以降に提示され、これらの更なる実施形態の各々の更なる詳細及び特徴は、添付の従属請求項及び以下の詳細な説明のどこかに規定される。
【図面の簡単な説明】
【0105】
本発明の実施形態は、一例としてのみ、添付の図面を参照して記載されるだろう。
図1図1は、位置決め及び地図マッチングシステムの例示的な機能設計を示す。
図2図2は、実施形態に従った地図マッチャーの全体のアーキテクチャを例示する。
図3図3は、アムステルダム(Amsterdam)の都市(ビル)の谷間における地図マッチングの結果(左のパネル)及び移動に沿って維持されたアクティブなパスの数(右のパネル)を示す。
図4図4は、GNSS停止中にトンネルを通るパス拡張を例示する。
図5図5は、ドリフトしたDR位置トレースからトンネルパスまでの地図マッチングを例示する。
【発明を実施するための形態】
【0106】
本明細書に記載の技術は、道路トポロジーを本質的に候補パスのセットに組み込む高度な地図マッチングアルゴリズムに関するものである。候補パスは、あるノードから別のノードへ或いはある道路区分から別の道路区分へ通過する、地図を移動するための全ての可能な方法として規定され、それ自体、道路区分の順序付けられたシーケンスである。本明細書に記載の地図マッチングアルゴリズムは、拡張及びトラブルシューティングが容易になるように、スケーラブルに且つモジュール式に設計される。アルゴリズムは、位置データトレースに対してマッチングするために使用される、可能なパス候補を構築して維持するために道路接続性(コネクティビティ)及び制限を最大限利用する。平行道路及び環状交差路等の多くの難しい状況を解決するのを容易にする、道路接続性(コネクティビティ)が自然に候補プールに組み込まれているので、トポロジーの完全性(インテグリティ)は、意思決定プロセスにおいて、もはや考慮される必要はない。
【0107】
図2に、実施形態に従った地図マッチャーの全体のアーキテクチャが例示される。示されるように、地図マッチャーは、2つの分離したレイヤ、入力処理レイヤ100及び地図マッチングアルゴリズムレイヤ200、から成る。地図マッチングアルゴリズムレイヤ200は、パス候補プールを構築し、候補に対する入力軌跡のマッチングを評価し、論理的にパスをランク付けしてパス間のジャンプを最少化することによりパスマッチング結果を維持する責任がある。入力処理レイヤ100は、位置入力を受け付け、それをサニタイズし、大きな入力ギャップ、逆運転、Uターン及びトンネル等の特別な運転条件(状況)を検出する責任がある。従って、Uターン、トンネル及び逆運転等の特別な状況は、地図マッチングアルゴリズムの最初に分離して取り扱われる。特別な操作が検出されると、地図マッチングは、パス候補を適切に構築又は拡張することによって準備(作成)され、その操作に関連する入力データはスキップされる。トポロジー地図マッチングアルゴリズムは決して操作を処理しない。
【0108】
実施形態に従った地図マッチャープログラムフローが、要約して記載されるだろう。
【0109】
初期ステップでは、新規の入力データが到達すると、実際のパス候補処理及びマッチングの開始前に、前記地図マッチャーは、任意の特別な状況を特定し、それらに反応する。これらの特別な状況の特定は、トンネル入/出チェックモジュール105、Uターンチェックモジュール104、逆運転チェックモジュール103、入力ジャンプチェックモジュール101、及び定常チェックモジュール102等の専用モジュールにより入力処理レイヤ100で扱われる。これらの状況の何れかの検出後、マップマッチャーはそれに応じて反応してもよい。例えば、自動車が定常(静止)であると検出されるなら、地図マッチャーは動作する必要はない。入力データにおけるジャンプ、Uターン又はトンネルが検出される場合、パス候補はそれに応じて修正される必要がないかもしれない。自動車が逆に移動していることが検出される場合、地図マッチャーがそれを前方移動として処理できるように、運転方向は入力及び出力に関して内部で反転されてもよい。入力処理レイヤ100でのこれらの状況の検出は、特別イベント処理モジュール220により処理される地図マッチングアルゴリズムレイヤ200でのそれらへの反応とは分離される。特別イベント処理モジュール220は、入力チェックが特別な条件を検出した際にパスを修正又は再構築する。これは、共に起こってもよい異なる特別な条件の組み合わせを処理するヒューリスティックスの余地を与える。例えば、トンネル出口と組み合わせて検出されたUターンは、誤検出であるかもしれず、更なる解析を必要としてもよい。
【0110】
入力処理の後、地図マッチングアルゴリズムレイヤ200において、地図マッチャーは、地図に格納された道路ネットワークに沿ってそのパス候補を最初に拡張する。道路トポロジーがパスに組み込まれることを保証するために、各パスは、多数の接続道路区分を含み、他の接続道路区分に向かって拡張される。この拡張は、パス拡張モジュール210により実行されてもよい。Uターンは上記のように入力処理レイヤ100で、分離して処理されるので、パスは、例えば任意のUターンを含むことができないことに留意されたい。
【0111】
地図マッチャーは、パスに対する入力データのマッチングを評価するために異なる基準及びヒューリスティックスを適用する“マッチャー”と呼ばれる多数のより小さなアルゴリズムを維持している。この評価は、プール内の各候補パスについて独立して実行される。各候補パスに関する各マッチャーは最初に新規の入力データを用いて前方に伝搬され、それにより入力が投影することが予期されるパスに沿った正確な場所の推定を生成する。次に各マッチャーは、任意の数の以前の入力データサンプルに渡って、パスおよび入力データのマッチングのスコアを評価する。マッチャーは位置マッチャー231及び方位マッチャー232を含んでもよく、それらはパス伝搬モジュール230において両方が提供されてもよい。位置マッチャー231は、入力位置座標(緯度、経度)を評価し、パスの地図ジオメトリに対してこれらを比較する。方位マッチャー232は、入力方位及び移動距離を評価し、パスのターン関数に対してこれらを比較し、それは地図ジオメトリから判定されてもよい。たとえ、これらのデータセットが非独立であるように見えても、マッチャー231、232は、データの異なる態様に関していまだ動作しており、それ故、位置入力データ及び地図データの両方における誤差の異なるソースを解析可能である。パス伝搬モジュール230は、以下で更に記載されるように、候補管理にも責任があってもよい。
【0112】
各マッチャーは、入力及びパスの間の最適な可能なマッチングを見つけることを試み、それ故、結局、パスに沿った異なる位置に伝播することになってもよい。ヒューリスティックスは、各パスに関する単一の最適な位置を選択するために適用される。更なるモジュール240が、最適位置を選択するために各パスに関する伝搬位置を比較するために提供されてもよい。
【0113】
移動距離マッチャー251及び速度制限マッチャー252等の更なるマッチャーも使用されてもよい。例えばスロープ(傾斜、勾配)等の、より多くの入力情報が利用可能であるなら、より多くのマッチャーが考慮されうる。マッチャーの各々についてのマッチングスコアは、パススコアリングモジュール250で取得されてもよい。マッチャー231、232、251、252の各々からのマッチングスコアは、各パスについて独立して、パスが正しいパスである信頼度(ビリーフ)のレベルを推定するために、マルチマッチャー信頼度融合モジュール260で統合される。融合モジュール260での統合における多数の基準を融合することは、信頼できる高いマッチング信頼性を可能にする。
【0114】
各パスに統合されたマルチマッチャー信頼度融合スコアが割り当てられると、パスランク付けモジュール270は、このスコアに従ってパスをランク付けし、このランク付けは最適なパスを見つけるために使用される。不十分なマッチングパスはこの段階で破棄されてもよい。最終の地図マッチング位置は、好適なパスにおける最適位置と共に、それと接続される他のパスにおける最適位置を評価することによって選択される。このステップは、例えば交差点及び分岐点での入力の不正確さを説明するのを助けるかもしれない。
【0115】
意思決定部280は、後処理ステップで使用され、パスランク付けモジュール270により判定されるような、新規の最適なパスが、以前に判定された最適なパスと比較されて、新規の最適なパスを好適なパスとして選択するかどうかについての決定が行われる。このステップは、あるパスから別のパスへのジャンプをクライアント、結局はユーザへ示すかどうか、いつ示すかを決定するためのヒューリスティックスを含む。最終の地図マッチング位置は、好適なパスにおける最適な位置と共に、それと接続される他のパスにおける最適な位置を評価することにより選択される。このステップは、例えば交差点及び分岐点での入力の不正確さを説明するのを助けるかもしれない。
【0116】
最後に、最終の地図マッチング位置は、入力が実際に道路をたどっているかどうか、或いは、入力がオフロードかどうかを判定するために解析される。すなわち、オフロードチェック290は、パスにおける最適なマッチング位置が、入力に対して十分選択されるかどうかを評価するために及び、必要に応じて、ポイントトゥカーブ(point-to-curve)マッチング原則に依存するであろうオフロード地図マッチングをトリガするために、実施されてもよい。
【0117】
地図マッチングされた現在位置が取得されると、それは、予測エンジンへの入力として提供されてもよい。予測エンジンは、地図マッチングされた位置サンプルを取り、装置の移動の表現をディスプレイにレンダリングする際に使用されてもよい予測軌跡を取得するために位置を推定する。これにより、滑らかな軌跡がユーザに対して表示されることが可能となる。このステップ無しに、地図マッチングされた現在位置が単に表示されるなら、地図マッチングされた位置サンプルの各々の間で離散的なジャンプがあるだろう。予測エンジンは、比較的まばらであってもよい位置サンプルデータを取り、適切な高頻度で、そこから推定された現在位置データを提供する。各地図マッチングされた位置データを推定する際、位置決め及び地図マッチングプロセスにより追加される待ち時間が考慮されてもよく、動的モデルが、車両の加速度及び減速度に従うように使用されてもよい。従って、位置データサンプルが地図マッチングのために受信されて以来、現在位置が進行していてもよい量を考慮して、最後の地図マッチングされた現在位置に基づく現在位置の推定である現在位置がユーザに対して表示されてもよい。
【0118】
地図マッチングアルゴリズムは、カーブトゥカーブ(curve-to-curve)マッチング及びパススコアリングを2つのモジュールに分離するために固有のパス伝搬ステップを提案する。マッチングの相違を直接スコアとする既存のほとんどのアプローチとは違って、アルゴリズムは、センターラインの単純化による地図誤差又はドリフトによる位置入力バイアスのどちらかとして部分的な相違を取り扱い、それらは最適なパス選択のためのパススコアリングからさらに除去される。この手順により、アルゴリズムが低品質な地図で動作することが可能となり、非常にドリフトしたデッドレコニングデータのみに頼らなければならない時にトンネル等のGNSS否定環境での信頼できるマッチングも可能となる。マッチングアルゴリズムが、マッチング相違を扱い、異なる状況での道路接続性(コネクティビティ)を維持するように構成される方法により、全ての輸送環境での使用の完全性(インテグリティ)が可能となる。
【0119】
図2に示された地図マッチャーの様々なステップ/モジュールが、より詳細に記載されるだろう。
【0120】
道路トポロジーに基づくパス候補プール
初期のパス選択
地図マッチャーがパスマッチングモジュールへ切り替えると、新規の初期パスが最適なアーク(弧)候補から構築されなければならない。パス候補は、距離及び方位の両方において最初の位置入サンプルに十分近接している個々の道路区分として初期化される。例えば、入力精度により、最初の位置入力サンプルの周囲の包含矩形において囲まれる道路区分が、初期のパス候補として選択されてもよい。初期のパスは、例えば、現在の方位と揃っている且つ/又は短い距離離れている道路区分について構築されてもよい。現在の方位と揃っているパスを選択することは、入力位置が誤っているが方位が正しい場合、例えばマップマッチャーが運転中にリセットされた場合、を説明するかもしれない。方位が信頼できない場合、ユーザが近傍道路上にあることが最も可能性が高い。さらに、多すぎる道路区分を選択して処理することは実践的ではない。初期のパスは、当該初期のパスをランク付けするために位置及び方位の差異に関するコストを割り当てられてもよい。従って、候補パスのプールが生成される。
【0121】
パスの拡張
新規の位置データサンプルが受信されると、プール内のパスは、パス先端から、接続された道路区分へ拡張される。このようにして、パスは多数の接続された道路区分を含むので、候補パスは自然に道路のトポロジーを反映する。
【0122】
交差点に到達すると、新規に追加された道路区分を伴う異なる拡張が収容されるように、パス候補がコピーされる。コピーされたパスは、アルゴリズムの残りによって独立して扱われる。新規の区分は“子区分”と称されうるが、分岐地点前の以前の区分は全ての分岐パスの共通祖先である。
【0123】
パス候補の数が指数関数的に増大することを回避するために、各候補についてのパス拡張は、当該パス上の以前の最適なマッチング場所がパス先端に近接している時にのみトリガされ、新規の入力はパスを超えて潜在的にマッチングされうる。パスは、それらが到達する当該同一の道路区分に沿って、後方へは決して拡張されない。パスは、幹線道路等の、明確に禁止された道路に対する交通フローと反対の方向にも拡張されない。しかしながら、通常の一方通行道路上の交通の方向に対する拡張は回避されない。
【0124】
候補管理
候補管理は、十分なマッチング候補を保持しながらパスプールのサイズを低減するために採用される。候補プールのサイズを低減することは、位置決めエポック(期)が進行するにつれてパスをより短くするために各パスに関する不使用パスの尾(テール)を積極的に取り除くことと、候補プールから正しくないパスを破棄することと、の2つの方法で行われる。パスは独立して追跡される。可能性が低いパスが結局のところ正しいパスと判明するかもしれない。それ故、正しくないパスを破棄することは、誤りを回避するために保守的であるべきである。アルゴリズムは、パスを破棄するためにいくつかの特性を評価する。最初の1つは、位置入力からマッチング場所へのオフセットを評価することである。この距離が多数回、入力水平精度よりも大きくなるなら、そのパスは破棄される。精度が正しく使用されないなら、デッドレコニング位置決めソリューションにより引き起こされるドリフトにより、パスが不正確に破棄されるかもしれない。第2に、最も良いスコアに対して悪いスコアの比率を有するパスが破棄される。アルゴリズムは、絶対スコアは異なるシナリオで変化するのでスコアに変えてスコア比率を使用する。例えば、悪いスコアはGNSS信号妨害を伴う深い都市(ビル)の谷間で現れる一方、良好なスコアは広々とした空のある幹線道路上で起こる。第3に、任意の距離後ろを見ることにより任意の2つのパスが正確に重複しないという意味では、全てのパスを固有に維持することは極めて重要である。より高いランキングのパスと重複するパスは破棄されるだろう。重複する状況は、大抵、パスが分岐を通って拡張されて、後に以降の交差点で結合(マージ)する時に起こる。
【0125】
パスを破棄する全ての閾値は、リアルタイム量販装置(大衆市場の装置)のため候補サイズを実行可能な計算領域に常に維持するために様々なシナリオでも適応的であるべきである。図3は、自動車がアムステルダムの密集した都市(ビル)の谷間を運転する時のパスサイズ変化の例を示す。示されるように、アルゴリズムは、適切な候補管理戦略及び適切なパス拡張により、候補パスを大きく制御する。
【0126】
特別な状況での道路接続性(コネクティビティ)の維持
Uターン検出及び処理
Uターンが検出されるなら、ゼロから地図マッチングを再スタートするというよりもむしろ、道路接続性(コネクティビティ)を維持する方がよりよい。Uターンは、専用モジュール104により入力処理レイヤ100において早期に地図マッチングプロセスで処理される。入力トレースがUターン形状であると判定される時にUターンが検出される。Uターンが検出された後、反対方向を伴う新規のパスが構築されて候補パスに追加されるべきである。しかしながら、元のパスは破棄されず、地図マッチングは両方のグループの候補を平等に取り扱う。これは、ヘアピンカーブ又は環状交差路等の特別な道路形状で、又は、特別な入力トレースがUターンとして間違われた場合に、地図マッチングが継続的に動作できることを保証する。地図マッチャーは全ての候補上で動作し、スコアに基づいてそれらをランク付けする。(Uターンパス、又は例えばヘアピンパスであってもよい)不十分なマッチングパスは、地図マッチャーにより判定されて、結局のところ破棄されるだろう。従って、元のパスの1つが新規に構築されたパスよりも実際に良好なマッチングであるなら、地図マッチャーは混乱なしにマッチングを継続できる。これは、入力処理レイヤ100でのUターンの検出及び地図マッチングアルゴリズムレイヤ200でのUターンの扱いの分離に依存する。
【0127】
多数のUターンが同じパスで起こる場合、例えば構築された反対のパスが元のパスと重複している場合、重複パスをフィルリングする必要があるかもしれない。最初のUターン後、反対のパスが元のパスと重複することなしに構築されうる。一方、第2のUターン後、反対のパスの反対のパスは元のパスと同じであるかもしれず、その場合、これらはランク付けに基づいて消去されてもよい。
【0128】
トンネル検出及び処理
GNSS信号は一般的に完全にブロックされ、新規のGNSSデータはトンネルの出口でのみ受信されるので、トンネルは別の特別な状況である。本明細書に記載の地図マッチングアルゴリズムは、新規のGNSSfixが受信されるまで道路接続性(コネクティビティ)を維持可能である。GNSS停止がある時は何時でも、地図におけるトンネル属性をたどり、トンネル出口に到達するトンネルパスのみ拡張することが可能である。このようにして、パス拡張は、トンネル出口でキャプチャされて継続的にパスとマッチングされうる最初に取り戻されるGNSSfixのために正確に準備される。図4は、パリのトンネルを例にとって、この状況を例示する。パスは、GNSS停止中且つ最初に取り戻されるGNSSfixを待っている間、全てのトンネル出口に向かって拡張される。
【0129】
GNSSのみに適用可能であるトンネル入口検出は、地図データに基づいてトンネル前の任意の距離を探索して各パスについてフラグを設定することと、それらのタイムスタンプに大きな入力ジャンプ(例えば10秒超)があるかどうかをチェックすることとの、2つのステップを含んでもよい。区分がトンネルとしてフラグを立てられているなら、トンネルが検出される。より小さなジャンプ(10秒未満)は、小さなトンネルに対応するかもしれないが、パス拡張がこの小さな時間ギャップをカバーする限り、このトンネルについて特別な処理を行う必要はない。
【0130】
一般的にトンネル内に入力データはない。そのような場合、GNSSfixが取り戻されるのを待っている期間(GNSS停止期間)、パスは、GNSSfixが取り戻された時にパスマトリックスを保持するために、トンネル出口に向かって(第1のパス拡張において)拡張される。このパス拡張はトンネル出口で停止する。最初のGNSSfixがトンネル出口で取得されると、新規の入力位置から遠すぎるトンネル出口は破棄されうる。新規の入力位置はトンネル出口からまだ離れているかもしれないので、パスは2度目のために拡張される。
【0131】
逆運転検出及び処理
入力処理レイヤ100での逆運転チェックモジュール103により逆運転検出が実行される。GNSSに関する逆運転検出は無い。しかしながら、自動デッドレコニング位置は、運転が逆であるなら入力として負の移動距離を与えるだろうし、それは逆運転を検出可能にする。
【0132】
地図マッチャーは、運転が逆方向である時、前方へさらに動作すべきである。そこで、入力方位は、地図マッチングアルゴリズム前に反転させられるべきであり、地図マッチング結果は、その後、反転させられるべきである。予測パスビルダは、地図マッチング後にパスを反対のパスへ逆転させるべきである。
【0133】
逆運転状況が検出された時、候補パスのプールは、逆方向のパスのセットと置換される。パスの新規のセットは、以下の方法で構築される。最初に、前方の、第1の運転方向における候補パスの既存のセットの1つの各々が、所定距離、例えばdメートル、前方の、第1の運転方向に拡張される。候補パス上の現在の地図マッチング位置は、この所定距離だけ、例えば前記dメートル、前方の、第1の運転方向に、人工的に前方へ移動される。このステップは、逆パスのセットを作成する前に、現在位置の前における任意の交差点を見逃すことを回避するために実行される。人工的に進められた現在の地図マッチング位置がある区分が特定され、その区分は、反対の、第2の運転方向に新規の候補パスの初期部分を形成するために逆転される。反対の運転方向における新規の候補パスのこの初期部分は、反対の、第2の運転方向に拡張候補パスを作成するために拡張される。(逆運転が必要である1つのイベントは、運転者が間違った方向の一方通行道路へ誤って入ったことが想定されるので、)本明細書の前方運転方向における候補パスのプールを取得することに関して記載された方法と同じ方法で拡張が実行されるが、一方通行道路等の任意の制限を通常は使用しない。逆運転方向における拡張候補パスが作成されると、地図マッチングされた現在位置は、すなわち所定距離だけ、例えば前記dメートル、逆のパス上で位置を前方に移動することによって、新規の候補パスに対して、そのリアルな位置に戻される。従って、新規の候補パスの各々上の区分について、地図マッチングされた現在位置に対応する可能な位置があり、その可能な位置を使用して後続の地図マッチングが行われる。
【0134】
入力ジャンプチェック
入力処理レイヤ100の入力ジャンプチェックモジュール101で実施される入力ジャンプチェックの目的は、現在位置が既存のパスの到達可能性の外側に離れてジャンプしたかどうかを判定することである。この場合、古いパスは、破棄されて新規のパスと置換されることが必要であってもよい。ジャンプは入力異常値(例えばGNSSデータのエラー)によるかもしれないので、アルゴリズムは最初のサンプルをリセットしないように構成される。
【0135】
定常チェック
定常チェックは、定常チェックモジュール102で実施され、停止条件(状況)が存在するかどうかを検出する働きをする。移動がないことが検出されたなら、地図マッチャーアルゴリズムは動作される必要がない。
【0136】
オフロードチェック
オフロードチェックは、オフロードチェックモジュール290による後処理で実施される。
【0137】
この機能は、現在の入力位置を、地図マッチングアルゴリズムにより判定された最適なマッチング位置と比較する。現在位置から最適パスへの投影までの距離の間の差が大きすぎる場合、地図マッチャーはオフロードへ進む。同様に現在位置の方位と最適パス上の方位との間の差が大きすぎる場合、地図マッチャーはオフラインになる。また、最適なパスが行き止まりに到達する場合、地図マッチャーはオフラインになってもよい。一般的に、速度が十分速い限り、地図マッチャーは自動車専用道路上を移動している時にオフラインにはならないだろう。
【0138】
地図マッチャーがオフラインになると、十分マッチングする弧を探す弧マッチングモードへ切り替えてもよい。十分マッチングする弧が見つかると、地図マッチャーはパスマッチングモードに切り替えて、上記のように初期のパス候補等を構築してもよい。
【0139】
パス伝搬
地図マッチングの更新中、各候補パスに関する各マッチャーは、最初に新規の位置入力を用いて前方に伝搬され、それにより、入力がマッチングすることが予期される、パスに沿った正確な場所の推定を作成する。これは粒子フィルタの特別な場合として考慮されることができ、地図マッチャーは、各パスに沿った1つの最適な位置を探す。
【0140】
位置マッチャー231では、デジタル地図及び入力トレースの両方がシフトしうるという事実により、シフトを補償せずに入力トレース及びパスの間で正確なカーブトゥカーブ(curve-to-curve)マッチングを常に取得することは不可能である。パスに沿った最適なマッチング位置は、全ての可能なシフトを列挙した後、カーブの相違を最小化する位置として規定されるべきである。しかしながら、スコアにより表されるカーブの相違は計算するのに広大である。従って、スコアリング前にパス伝搬モジュールにおいてシフトを伝播するために地図マッチングアルゴリズムにおいて妥協がなされる。初期のシフトは、最初の入力サンプル及びパスカーブの間のクロストラックオフセットとして単純に推定される。入力が進むと、入力トレースは、新規のオフセットを更新するために使用される新規のクロストラックエラーを計算する前には、以前のオフセットにより調整される。それ故、オフセットは、エポック単位で蓄積され、計算が効率的である。しかしながら、パスに沿った最適な位置は常にパスに垂直に投影されるものなので、ターン前のクロストラックオフセットは、ターン後のアロングトラックエラーとなり、それは補償することが難しい。従ってオフセット最適化が提案される。それは、変換された入力トレースをパスに沿って後方へ伝搬し、オフセット補正のために、取得された様々なオフセットを平均化する。オフセット最適化は、パスとのより良好な形状ベースのマッチングを保証するが、それは比較的広大であり、ある条件で、例えばターン後に、のみ動作する。
【0141】
位置マッチャー231のように、方位マッチャー232も、蓄積された移動距離及び方位から成る2次元データを処理する。地図道路ジオメトリは、蓄積されたパス長さ及び道路区分方位により表される。パスに沿って蓄積された距離は、単純化された地図及び道路幅情報の欠如により、真の運転距離とは異なっている。例えば、いくつかの連続した道路区分により構成されたコーナーは、大抵、運転者が移動するであろう実際の距離よりも長く、広い直線道路に沿った車線変更により、道路区分蓄積よりも長い入力移動距離となる。これは、入力移動距離をオフセットにより調整することによって方位マッチャーのパス伝搬で補償されうる。オフセット最適化は、2つのターン関数の相違を最小化するために、及び、方位マッチャー232が、移動距離が増加する時、パスに沿った問題のあるターンに渡ってスキップすることを防止するためにも、実施される。
【0142】
パス伝搬は、オフセットを最適化するだけではなく正確なマッチング場所の推定を作成もするモジュールである。1次元データのみを入力とする、速度制限マッチャー及び移動距離マッチャー251等の他のマッチャーは、結果として得られるマッチング場所に依存するので、パス伝搬ステップをスキップしうる。
【0143】
パスに沿った入力変換及び伝搬は、大きなドリフトを伴う有効なマッチングを保証するために必須である。例えば、トンネル内でのGNSS停止中に、デッドレコニング位置決めシステムは、まだ位置データを提供することができるが、蓄積されたジャイロドリフト及び加速度計バイアスにより真の軌跡からドリフトするだろう。図5は、ドリフトされたデッドレコニング位置決めを使用するパリのトンネルのケースを描写する。分かるように、トンネル出口に近接する入力トレースは500m超ドリフトしているが、正確なパスとまだ十分にマッチングされている。取り戻されたGNSSfix前に平行道路への間違ったジャンプがあり、GNSSfix後の分岐点後の2、3のサンプルについて間違った選択があるものの、アルゴリズムは、位置構成要素及び地図マッチング構成要素の間の任意のフィードバックループを含むこと無しにトンネルとの成功したマッチングを達成する。
【0144】
パススコアリング及びマルチマッチャー融合
位置マッチャー231は、合計ノルム(norm)をスコアとして利用する一方、方位マッチャー232は、2つのターン関数間の合計の矩形のエリアをスコアとして扱う。それらは、変換された入力トレースと実際のパスとの間でそれぞれ、幾何的なズレ及び代表的なカーブ相違を定量的に測定するための比較的単純な方法である。移動距離マッチャー及び速度制限マッチャー252等の他のマッチャーは、各パスに関する結果をさらに承認又は否定するためにパス伝搬後に結果として得られる最適なマッチング場所に基づくものである。より多くの測定がマッチングプロセスに含まれるにつれて、異なる基準間のコンフリクトを区別するために、且つ、パスが正確なパスである可能性を推定するために各パスについて独立して、ビリーフ理論ベースのマルチ基準融合がアルゴリズムで使用される。デンプスター-シェーファー理論とも呼ばれるビリーフ理論は、例えビリーフ値のソースが完全に規定されていなくても動作できるので、適当に使用されてもよい。その一方、デンプスター結合則は、拡張及び計算的に安価にすることを容易にする、完全に累積操作である。しかしながら、隠れマルコフチェーン、ファジー論理又はカルマンフィルタ等の様々な他の適当な確率理論も使用されてもよい。
【0145】
パスランク付け及び意思決定
パスランク付け及び意思決定は、全てのパス候補のうちの最適なマッチングパスの選択のための地図マッチングの最後である。パス伝搬及びパススコアリングの分離により、最適なパスを選択するために使用された情報は、オフセット及びビリーフ可能性(尤度)の両方を含む。それらは2つの異なるマッチング領域にある。尤度は、カーブトゥカーブ(curve-to-curve)の形状ズレを表すための0から1の間の定量的指標であるが、オフセットは、入力トレースをシフトするためのベクトルでああり、それ故、入力又は地図のバイアスを表す。それらの何れも、真に信頼できるものではない。例えば、尤度は、同じ幾何的形状を有しており且つ等しく入力トレースとマッチングするので、2つの平行道路を区別しない。この場合、オフセットが重要な役割を果たすだろう。対照的に、オフセットは、マッチングを単純にジャッジすることもできない。デッドレコニングのトンネルのケースでは、オフセットは、形状ベースの尤度に依存しなければならない場合、デッドレコニングドリフトにより継続的に増加するだろう。
【0146】
パスのランク付けは、これら2つのマッチング領域をレイヤ設計で結合(マージ)する。最初に、オフセットに基づいて全てのパス候補を2つのグループに分類し、次に、尤度に基づいて、より良好なオフセットを有するグループを、サブグループにサブ分類し続ける。各グループ内で、パスは尤度により降順にさらにランク付けされる。ランク付けは、現在の入力について最適なマッチングパスを作成する。しかしながら、それは、最適なマッチングがあるサンプルから次のサンプルへ変化する時にパス間をジャンプすることを妨げない。意思決定部は、ジャンプを最少化するために使用され、それは、現在の最適なランク付けされたパスを、新規の最適なものジャンプするか或いは以前のまま固執するかの決定のために、以前の最適なものと比較する。
【0147】
カーブトゥカーブ(curve-to-curve)マッチングの相違を直接スコアとする既存のアプローチの殆どとは違って、このアルゴリズムは、部分的な相違を、センターライン単純化による地図誤差又はドリフトによる位置入力バイアスとして扱い、それらは、最適なパス選択のためにパススコアリングからさらに排除され、結果としてより良好な形状マッチングとなる。アルゴリズムは、パススコアリングでのマルチ基準として、位置、方位、移動距離及び速度制限等の全入力情報を利用し、それにより、より信頼性のあるパフォーマンスとなる。アルゴリズムは、量販ナビゲーション装置での使用に適した、マッチング精度及び計算速度の間の良好なバランスを有する。
【0148】
ジャンプ検出
ジャンプは、最も可能性のある候補として選択されたパスが、最後のサンプルから異なるパスへ変化する場合である。2つのパスは、ジャンプ検出に関心がある。そこへジャンプされてもよいパスである、ランク付け後の“最適な”パス、及び、そこからジャンプされてもよいパスである、地図マッチャーアルゴリズムの以前の動作の最適なパスである“好適な”パスである。
【0149】
ジャンプ検出アルゴリズムは、早すぎるジャンプ及び再びジャンプして戻らなければならないことを回避するために、ジャンプを最少化又は遅延させることを試みる。例えば、アルゴリズムは、トンネル出口での新規の位置入力の受信後、この入力は雑音があるかもしれず正確ではないかもしれないので、好適なパスに固執してもよい。一般的に、アルゴリズムは、最適なパスの確率が好適なパスの確率よりも低い場合、又は、最適なパスの総(mass)距離が好適なパスの総距離を超過する場合、又は、リアルなジャンプが近傍の履歴において起こっている場合、好適なパスに固執することを選択してもよい。このようにして、ジャンプは、アルゴリズムが適切であると判定した時にのみ行われるだろう。
【0150】
本発明の実施形態は、1つ以上の道路区分により規定された経路を移動する自動車ユーザ(運転者)を参照して記載されるが、本明細書に記載の技術は、パス、河川、運河、自転車道路、航路又は鉄道線路などの区分のような他のナビゲート可能区分にも適用可能であってもよいことが認識されるべきである。従って、ユーザは、自動車の運転者だけである必要はなく、例えば、ナビゲーション命令を受信する歩行者又は自転車乗りであってもよい。
【0151】
(任意の添付の特許請求の範囲、要約書及び図面を含む)本明細書に開示された特徴の全て、及び/又は、そのような開示された任意の方法又はプロセスのステップの全ては、そうした特徴及び/又はステップの少なくともいくつかが相互に排他的である組み合わせを除いて、任意の組み合わせで組み合わされてもよい。
【0152】
(任意の添付の特許請求の範囲、要約書及び図面を含む)本明細書に開示された各特徴は、そうではないと明確に述べられていない限り、同一物、均等物又は類似目的を供給する代替特徴により置換されてもよい。従って、そうではないと明確に述べられていない限り、開示された各特徴は、一連の汎用の均等物又は類似特徴のほんの一例である。
【0153】
本発明は、前述の任意の実施形態の詳細に制限されない。本発明は、(任意の添付の特許請求の範囲、要約書及び図面を含む)本明細書に開示された特徴の任意の新規な1つ又は任意の新規な組み合わせ、又は、そのように開示された任意の方法又はプロセスのステップの任意の新規な1つ又は任意の新規な組み合わせに及ぶ。特許請求の範囲は、前述の実施形態をカバーするように構成されるだけではなく、特許請求の範囲に含まれる任意の実施形態をカバーするように構成されるべきである。
図1
図2
図3
図4
図5