JP6397531B2 - 車両エッジプラットフォームからクラウドへの送信のためのｇｐｓデータのｇｉｓベースの圧縮及び再構築 - Google Patents

Description

本開示は、概してネットワーク装置に関し、特に、車両に関連するネットワーク装置のためのデータ送信の仕組みに関する。

モノのインターネット（ＩｏＴ）の出現とともに、データ送信の関連技術のモデルもそれに従って調整されてきた。特に、関連技術のＩｏＴ 装置は、従来の適用よりもはるかに大容量、高速度、かつ多種のデータを含み得るデータを生成する。データが中央処理用のクラウドに送信される場合、図１に示されるように、根底にあるアプリケーションの待ち時間とエラーの性能が影響を受け得る。一例では、ネットワークの混雑が原因のドロップされたパケットは、データがクラウドで処理されるのを遅らせるかもしれず、またＩｏＴ装置の実際の状況を反映しないかもしれない。

関連技術のソリューションは、処理されたデータをクラウドに送信する前にデータの容量、速度、多様性を低減させるために、生成されたデータに対する局所的な決定及び処理を実行できるＩｏＴエッジソリューションを含む。エッジ処理の概念は、図２に示されるように、分散データ処理及びデータ圧縮を促進にするために、関連技術に実装されてきた。エッジ処理の使用を通して、データ処理の一部をクラウドからエッジに移動できる。

関連技術では、エッジ処理アルゴリズムは、入ってくるＩｏＴセンサデータの圧縮を実行する。関連技術のソリューションは、エッジ処理においてデータ圧縮のアルゴリズムを含む。図３は、関連技術のエッジ処理プラットフォーム機能３００を示す。このようなエッジ処理のフローは、センサデータ取得３０１、データ処理３０２、及びクラウド３０３への処理済データの送信を含む。しかし、図３に示されるように、関連技術の実装は、３０２で古典的圧縮アルゴリズムを使用してデータを圧縮する。関連技術のソリューションでは、デルタ圧縮（すなわち、実際の値を送信する代わりに、２つの連続的なセンサ読取値の間の差分のみを送信する）の適用があり、これは、連続的なセンサ読取値が相関関係にあるために機能する。このようなソリューションの例には、米国特許出願第２０１５／２９３２３２Ａ１号（その全体があらゆる目的のために本明細書に参照として組み込まれる）で開示される通り、全地球測位衛星（ＧＰＳ）データを圧縮するためのシステム及び方法が含まれ得る。別の関連技術ソリューションでは、米国特許出願第２００６／０２４４５８７Ａ１号（その全体があらゆる目的のために本明細書に参照として組み込まれる）で開示される通り、追跡システムにおいて圧縮された遠隔測定データの送信を提供するための方法及び装置がある。

別の関連技術のソリューション例では、データを集約し、クラウドサーバーに送信するためのシステムがある。このようなソリューションの例には、米国特許第８，２６４，７５８Ｂ２号（その全体があらゆる目的のために本明細書に参照として組み込まれる）に記載されている通り、クラウドサービスに接続された車両のための遠隔測定装置を含む通信システムが含まれ得る。

本開示の態様は、全地球測位衛星（ＧＰＳ）情報から、第２のＧＩＳ中間地点に対する第１の地理情報システム（ＧＩＳ）中間地点への第１の装置の近さを判定し、第２のＧＩＳ中間地点に対する第１のＧＩＳ中間地点への装置の近さを示すインデックス情報を生成し、インデックス情報を第２の装置に送信するように構成される第１のプロセッサを含む第１の装置を含み得るシステムを含む。

本開示の態様はさらに、ＧＰＳ情報から、第２のＧＩＳ中間地点に対する第１のＧＩＳ中間地点への装置の近さを判定し、第２のＧＩＳ中間地点に比較した第１のＧＩＳ中間地点への装置の近さを示すインデックス情報を生成し、インデックス情報を別の装置に送信するように構成されたプロセッサを含み得る装置を含む。

本開示の態様はさらに、別の装置の位置を示す受信情報がＧＰＳ情報を対象とする場合は、ＧＰＳ情報及び ＧＩＳ情報に基づいた別の装置の位置を計算し、インデックス情報を受信した別の装置から受信された情報については、インデックス情報から第２のＧＩＳ中間地点に比較した第１のＧＩＳ中間地点への別の装置の近さを判定し、前記近さに基づいて別の装置のＧＰＳ座標を推測するように構成されたプロセッサを備え得る装置を含む。

図１は、データ送信の関連技術のモデルを示す。 図２は、エッジ処理の関連技術のモデルを示す。 図３は、関連技術のエッジ処理プラットフォーム機能を示す。 図４は、一実施形態例に係るエッジ処理を示す。 図５は、ＧＩＳ情報なしの適用例を示す。 図６は、一実施形態例に係るＧＩＳコンテキストの適用例を示す。 図７は、一実施形態例に係るＧＩＳコンテキスト情報及び量子化の適用例を示す。 図８は、一実施形態例に係る道路インデキシングの実施例を示す。 図９は、一実施形態例に係る道路処理を示す。 図１０は、一実施形態例に係る交差点シナリオを示す。 図１１は、一実施形態例に係る交差点処理を示す。 図１２は、実施形態例が適用できるアーキテクチャ例を示す。 図１３は、一実施形態例に係るコンテキストアウェア圧縮規則のフロー図を示す。 図１４は、一実施形態例に係るコンテキストアウェア再構築規則機能のフロー図を示す。 図１５は、一実施形態例に係る管理フロー例を示す。 図１６Ａ〜図１６Ｃは、一実施形態例に係る空間サンプリングの例を示す。 図１７は、実施形態例を適用し得るコンピュータ環境を示す。

以下の詳細な説明は、本出願の図面及び実施形態例のさらなる詳細を提供する。図面間の重複する要素の符号及び説明は、明確性のために省略されている。説明全体に亘って使用されている用語は例として提供されており、制限することを意図したものではない。例えば、「自動的」という用語の使用は、本出願の実施形態を実践する当業者の望ましい実施に応じて、完全自動の実施形態か、又はユーザ又は管理者が当該実施の特定の態様を管理することを含む半自動の実施形態を含み得る。「リクエスト」及び「操作」という用語も置き換えて使用されてもよい。

実施形態例は、データのコンテキストを考慮して、及びコンテキストベースの圧縮の使用を通して、図３の関連技術の圧縮を改善し得る。圧縮技術は、データセットの相関関係を活用することを目指す。しかし、すべてのデータが同等というわけではない（例えば、車両からの全地球測位衛星（ＧＰＳ）データを、同じ車両からの温度読取値と対比させる）。根底にあるアプリケーションを事前に考慮に入れず、圧縮の過程で相関関係を発見することを試みる圧縮アルゴリズムは、データのコンテキスト（すなわち、データにおける根底にあるアプリケーション及び相関関係の構造）が事前に圧縮アルゴリズムに利用可能となるアルゴリズムよりも性能がよくないかもしれない。

図４は、一実施形態例に係るエッジ処理４００を示す。図４は、センサ４０１からのデータ取得及びクラウド４０３へのデータ送信のために図３と類似の実施を使用する。しかし図４では、コンテキスト情報は、車両が４０２で示されるように位置追跡の目的で送信しなければならない位置情報（例えば、ＧＰＳ座標）の圧縮のために適用される。位置追跡を使用できる多くの適用がある。このような適用は、フリートの所有者がそのフリート及びその動きを追跡することを望むフリート管理システムや、クライアント群に対してその最初の位置をブロードキャストし、かつ当該運転者車両が選択されると、その後の動作をブロードキャストする、運転者車両によって有効にされる相乗りアプリケーションを含む。

実施形態例は、ＧＰＳデータをクラウドに送信するオーバーヘッドを大幅に圧縮するための方法を含む。ｒａｗ ＧＰＳ情報は、少なくとも６４ビット（緯度及び経度それぞれぶ３２ビット）に含まれる。このようなＧＰＳ情報が頻繁に及び多数の車両のために送信されなければならない場合、全体の負荷は、圧縮技術を必要とするくらい大きくなり得る。

ＧＰＳデータについては、コンテキスト情報は、地理情報システム（ＧＩＳ）情報、すなわち、車両が位置づけられる道路の情報を含むことができる。図５は、ＧＩＳ情報なしの適用例を示す。図５では、矩形領域５００で描かれる都市部に車両がある。領域のＧＩＳ情報なしでは、車両の可能な位置に対応する可能なＧＰＳ座標の集合は、矩形領域の全体を含む必要があるかもしれず、可能な位置を絞り込むためのコンテキスト情報がないために、過度に大きな集合になり得る。

しかし、その領域にあるすべてのＧＰＳ座標の集合を考慮することは、リソースの無駄につながる可能性がある。前記集合は、矩形領域に位置する道路のみをカバーすべきであるが、それは、車両が駐車場ビル及び他の一時的な道路以外の場所の外にあるいかなる一般的なＧＰＳ座標にも位置することができないからである。

図６は、一実施形態例に係るＧＩＳコンテキストの適用例を示す。このような情報は、ＧＰＳデータのＧＩＳコンテキストによって提供され、図６に示されている。図６の例で示されるように、ＧＩＳコンテキスト情報が矩形領域６００に提供された後であれば、ＧＰＳ座標の集合｛アヴェニューＡ、アヴェニューＢ、ストリート１、ストリート２｝だけを考慮すればよい。

図７は、一実施形態例に係るＧＩＳコンテキスト情報及び量子化の適用例を示す。実施形態例では、可能なＧＰＳ座標の集合を制限することによって、さらに圧縮することが可能である。適用によっては、非常に細かい粒度の位置追跡は必要とされないかもしれない。よって、本明細書で説明される実施形態例は、図７で例示されるようにサンプルのＧＰＳデータの集合のみを考慮すればよく、ここでは、可能なＧＰＳ座標の集合が、矩形領域７００内のＸ印で示される。

図８は、一実施形態例に係る道路インデキシングの例を示す。以下の例では、ＧＩＳデータベースを使用するＧＰＳ情報の集合は、道路及び交差点の情報を含み得る。ＧＩＳ情報を使用することによって、エッジ処理プラットフォームとクラウドは、道路の共通データベースを有することができる。データベースは、すべての道路のインデックス及び道路に沿ったすべての地点のインデックスを維持することができる。図８に示されるような直線の道路の場合を考える。道路のインデックスは「Ｓ」で示され、地点のインデックスは「ｋ」で示される。よって、可能な地点は、Ｓ［ｋ］、Ｓ［ｋ＋１］などである。各道路のＧＩＳ中間地点をｒａｗ ＧＰＳ座標に関連付けるＧＩＳインデックス地点の表の例が、下の表１に示されるように提供される。車両のエッジプロセッサ、並びにクラウドプロセッサは、表１の情報にアクセスし、ＧＰＳ位置をＧＩＳ中間地点と比較し、エッジプロセッサの道路インデックス及びＧＩＳ中間地点のインデックス情報を判定するように構成される。道路インデックスのＧＩＳ中間地点の各々は、インデックスにマッピングされる。すなわち、ＧＩＳ中間地点の集合は、道路インデックスのベクトルとして示され、Ｓ［ｋ］として示され、ここでｋは道路インデックスのＧＩＳ中間地点に対応する。

表１：位置マッピング用のＧＩＳインデックス地点

図９は、一実施形態例に係る道路処理を示す。図９の上部は車両エッジの実際の位置を示し、中央部はクラウドに送信される情報を示し、下部はエッジによって送信される情報に基づいてクラウドで再構築される車両位置を示す。

イベントのシーケンスは以下のように理解できる。

時間ｔ１では、車両はＧＰＳ位置Ｓ［ｋ］ に位置し、ＧＰＳ位置がエッジとクラウドの両方で既知であり、さらに車両が地点Ｓ［ｋ＋１］の方向に向かって動いていることが、エッジとクラウドの両方で既知であると仮定する。実施形態例の開始時では、車は、クラウドが最初に位置と方向を追跡するまでｒａｗ ＧＰＳ地点を送信し、その後でコンテキストアウェア圧縮を開始することができる。一実施形態例では、ｒａｗ ＧＰＳ地点に最も近いインデックス地点を判定するために、表１に例示されるようにｒａｗ ＧＰＳ地点をインデックス表と最初に比較することによって、Ｓ［ｋ］及びＳ［ｋ＋１］と最初に判定することができる。ｒａｗ ＧＰＳ地点を表１の対応するインデックス地点と比較することから、Ｓ［ｋ］及びインデックス表の後続の地点Ｓ［ｋ＋１］を初期化できる。

車両は、インデックスフィールドを送信する。この実施形態例では、インデックスフィールドは１ビットであるが、インデックスフィールドは、望ましい実施形態に従って他の方法で実施することができる。インデックス＝０の値は、車両が地点Ｓ［ｋ＋１］よりも地点Ｓ［ｋ］に近いことを意味することができ、一方、インデックス＝１の値は、車両が地点Ｓ［ｋ＋１］により近いことを意味することができる。

時間ｔ１では、車両のエッジプロセッサは、上の規則に基づいてインデックス＝０を送信する。クラウドは、地点Ｓ［ｋ］ における車両の位置を再構築する。

時間ｔ２では、車両のエッジプロセッサは、ＧＰＳ情報からその現在の位置を判定する。この例の現在の位置をＡ１と呼ぶことにするが、ここで、Ａ１はＳ［ｋ＋１］よりもＳ［ｋ］に近い。エッジプロセッサは、車両の現在のｒａｗ ＧＰＳ座標を処理し、かつ表１に例示されるように位置をインデックス表と比較することによって、それがＳ［ｋ］とＳ［ｋ＋１］のどちらに近いかを判定できる。そのＡ１の位置のｒａｗ ＧＰＳ座標がＳ［ｋ＋１］よりもＳ［ｋ］に近いと判定すると、エッジプロセッサは、インデックス=0を送信する。クラウドは、インデックス＝０を受信し、この値が最後に受信した値と同一であることを注記する。従って、クラウドは、この車が最後のレポートの時点で既にＳ［ｋ］に近く、その介在時間に先に移動したが、インデックス＝１のレポートを誘発するほど十分にはＳ［ｋ＋１］に接近していないと判定する。クラウドは、この判定を用いて、車両の位置を予測するための推定アルゴリズムを設計することができる。示される例では、クラウドは、位置がＢ１にあることを推定する。位置推定誤差｜Ａ１−Ｂ１｜が存在する。許容誤差マージンは、この適用によって与えられ、道路のＧＰＳサンプルの間の距離がどれくらい近いかを考慮することによって相殺することができる。

時間ｔ３では、エッジプロセッサは、それが地点Ｓ［ｋ＋１］により近い地点Ａ２に位置すると判定し、よってインデックス＝１を送信する。クラウドは、車の位置が地点Ｓ［ｋ＋１］にあると推定する。よって、クラウドは、エッジがｒａｗ ＧＰＳ座標を送信する必要なしにＧＰＳを推測し、よって圧縮を達成することができる。

実施形態例では、エッジプロセッサは、車両が交差点に位置しているか、交差点で１つの道路から別の道路に曲がろうとしているかを判定できる。図１０は、一実施形態例に係る交差点シナリオを示す。図１０では、車両は交差点にある。この例では、車両は、３つの可能な選択肢を有し、当該選択肢は、直線で進む、左折する、右折するである。すべての道路が列挙されるように、計画を定義することができる。図１０に示されるように、３つの道路は、それぞれ「１１」、「０１」、「１０」と列挙される。再度注記するが、車両の最初の位置がエッジ及びクラウドで既知であると仮定し、かつＧＩＳ情報が両端で共通であるため、両方の存在は、列挙アルゴリズムが最初に合意されている場合は、交差点における可能な道路及びその列挙について通知を受けることができる。よって、ＧＩＳ情報が両端で共通で利用可能となることによって、すべての可能な交差点に対して片側が道路を列挙し、これを反対側と共有する必要性を取り除く。むしろ、列挙アルゴリズムは、最初に一回共有する必要がある。このような類似の一回の初期化を実施するために、実施形態例は、エッジとクラウドの両方の管理プレーンを使用する。

今度は、エッジプロセッサが、車両が例えば左折する過程にあると判定する場合は、このイベントのインデックス（この例では０１）を送信するだけでよい。車両が直線の道路にある場合（例えば、０又は１の可能性については１ビット）から交差点（ビット数は交差する道路の数による）へのインデックスをレポートするための異なる種類の可能性を区別するために、LocationTypeという追加の１ビットフィールドは、車両が直線の道路（例えば、LocationType=0又は論理値「Road」）又は交差点（例えば、LocationType=1又は論理値「Intersection」）にあることを伝えるために送信することができる。

図１１は、一実施形態例に係る交差点処理を示す。各交差点は、それぞれ交差点（開始地点）及び交差点（終了地点）のラベルが付いた開始地点及び終了地点で定義することができる。交差点（開始地点）に近づいているときに、エッジプロセッサは、次のＧＩＳインデックス地点が表１からの情報に基づいた交差点であることを認識する。エッジプロセッサが、その現在のＧＰＳ位置を、交差点のＧＩＳ中間地点のＧＰＳ位置と比較することに基づいて、交差点（開始地点）を最終的に通過すると、車両のエッジプロセッサは、LocationType = 1（又は図１１で示される論理値「Intersection」）及びインデックス（この場合は０１）を送信する。エッジプロセッサは、表１の交差点（開始地点）から可能な後続のＧＩＳ中間地点を特定することに基づいて、交差点（終了地点）を判定する。車が交差点を通過し、交差点（終了地点）にある道路にいる（例えば、エッジプロセッサの次のインデックス地点を判定するために表１でｒａｗ ＧＰＳ位置をＧＩＳ中間地点と比較することに基づいて）と、エッジプロセッサが見なすとすぐに、エッジプロセッサは、LocationType = 0（又は論理値「Road」）及びインデックスの値（車がちょうど道路に入る時に、最初は０）を送信する。クラウドは次に、図９で説明した直線道路の場合に類似した方法で受信されたインデックス=「０１」メッセージの数に基づいて、車両の位置を再構築する。

図１２は、実施形態例が適用され得るアーキテクチャ例を示す。クラウドとエッジアーキテクチャの両方が、どのように相互接続されるのかと共に示されている。アーキテクチャは、データプレーン及び制御プレーンを含む。

データプレーン１２０２、１２０３は、実際のセンサデータを管理し、これを圧縮するための規則を形成し、かつ当該規則を実施するように構成される。制御プレーン１２００、１２０１は、後続の圧縮が機能するように、クラウドとエッジの間の制御情報の最初の交換を処理するように構成される。これは限定的であり、ほとんどセッションの開始時の一回か、又は追加の更新は稀であることに留意する。よって、制御プレーンのメッセージングのオーバーヘッドは最小限である。

エッジの多様な機能は、以下のとおりである。データ層１２０３−１は、センサを管理し、データを生成する。圧縮アウェア圧縮実施機能１２０３−２は、 すべての圧縮アルゴリズムを実行し、次に圧縮データをコンテキストアウェア再構築実施機能１２０２−２のためのクラウド上の対応するモジュールに送信する。圧縮アウェア圧縮規則機能１２０３−３は、圧縮がどのように行われるべきかの規則を決定する（これらの規則を実施する実施機能に対して）ように構成される。管理機能１２０１−１は、制御プレーン機能を実行するためにクラウド上の対応する管理機能１２００−１と相互作用するように構成される。

クラウドの多様な機能は以下のとおりである。データ層１２０２−１は、 再構築された位置情報を取り込み、これを後続の適用に渡す。圧縮アウェア再構築実施機能１２０２−２は、エッジの対応するモジュールから受信した圧縮された位置データに対するすべての再構築アルゴリズムを実行する（コンテキストアウェア圧縮実施機能１２０３−２）。コンテキストアウェア再構築規則機能１２０２−３は、再構築がどのように行われるべきかのすべての規則を決定する。管理機能１２００−１は、制御プレーン機能を実行するためにエッジ上の対応する機能と相互作用する。

エッジ及びクラウドのデータプレーン圧縮及び再構築規則機能は、実施形態例の機能を促進し、他の機能は、データプレーン圧縮及び再構築をサポートするように構成されることに留意する。図１２で分かるように、データプレーン及び再構築機能は、実施形態例を促進するために互いに直接通信する必要はない。エッジとクラウドの間のすべての制御関連の通信は、望ましい実施形態によっては、低負荷で低頻度に通信するように実装できる管理プレーンを通して発生する可能性がある。圧縮機能と再構築規則機能を分けることは、ＩｏＴのためのエッジ処理を可能にするために必要なクラウドとエッジの間の分散された動作を達成するのに役立つ。

図１３は、一実施形態例に係るコンテキストアウェア圧縮規則のフロー図を示す。特に、図１３は、コンテキストアウェア圧縮規則機能１２０３−３のフロー例を示す。１３００では、ある地点のｒａｗ ＧＰＳデータは、データ層からの入力として供給される。１３０１では、最後地点のＧＩＳ位置が既知であるか否かを判定するためのチェックを行う。すなわち、参照として使用される前のインデックス地点が存在するかのチェックが行われる。例えば、前のＧＩＳ中間地点のインデックスがエッジプロセッサによって判定されずにクラウドプロセッサに送信された場合、又はエッジプロセッサが初めて起動された場合、最後地点はわからず、最後のＧＩＳ位置インデックスはNULLになるであろう。前のＧＩＳ中間地点インデックスが計算され、クラウドプロセッサに送信された場合、前のＧＩＳ中間地点インデックスは、道路インデックスの形式になるであろう（例えば、Ｓ［ｋ］）。図１０に示されるように、この位置は、論理値 「Road」及び「Intersection」を取り込む変数「LocationType」、並びにこれらの変数の実際の値（すなわち、道路又は交差点を作る複数の道路の名前）、並びに入力地点に最も近い位置の地点（道路又は交差点）で表すことができる。この情報が既知ではない場合（Ｎｏ）（例えば、データ層セッションによって入力された第１の地点であるため）、フローは１３０２に進み、ＧＩＳ情報データベースを使用して、未来の地点のために使用される情報を計算する。すなわち、地点p(current）のｒａｗ ＧＰＳデータは、表１のＧＩＳ情報データベースのｒａｗ ＧＰＳデータと比較されて、道路インデックス（図１３の例のＳ）及びＧＩＳ情報の対応するＧＩＳ中間地点ｋを判定する。道路インデックス及びＧＩＳ中間地点が判定された後、道路インデックスＳに沿った後続のＧＩＳ中間地点は、可能な未来のＧＩＳインデックス地点を判定するために使用できる。フローは１３０６に進み、この地点のｒａｗ ＧＰＳ座標をクラウドの再構築機能に送信する。

最後のデータのＧＩＳ情報が既知である場合（ＹＥＳ）、同じデータを使用して、現在のデータのＧＰＳを圧縮する（すなわち、ｒａｗ ＧＰＳ座標の代わりにインデックス値を送信する）可能性がある。しかし、これは可能ではないかもしれない。なぜならば、最後地点のＧＩＳ情報が有効ではないかもしれず、これは十分に追跡されていない交差点で起こる可能性がある。フローは１３０３に進んで、最後のデータ地点のＧＩＳ情報が、現在の地点の推定に基づいてまだ有効であるかを判定し、１３０４に進んで、最後のデータ地点が有効であるかを判定する。

例えば、図８で例示される状況を考える。最後地点p(last）では、エッジは、距離 ｜p(last) − S[k]｜ 及び ｜S[k+1] − p(last)｜ を知っており、これから、エッジは、｜p(current) − S[k]｜ 及び ｜S[k+1] − p｜、すなわち ｜p(last) − S[k]｜ < ｜p(current) − S[k]｜ 及び ｜S[k+1] − p(last)｜ > ｜S[k+1] − p｜の期待される動作を推定することができる。この距離からの大きな逸脱がある場合は、最後地点のＧＩＳ位置情報がもはや有効ではない可能性がある。車両が道路を離れたり、追跡されていない交差点を通ったり、又はその速度が、最後地点が送信された時点から大きく増減したり、などの複数の理由があり得る。

ＧＩＳ位置情報がもはや有効ではない（Ｎｏ）と見なされる場合、フローは１３０２及び１３０６に進み、ＧＩＳデータベースを使用して、新しいＧＩＳ位置情報を取得し、ｒａｗ ＧＰＳ座標を送信する。

最後地点の位置が有効（Ｙｅｓ）であるように見える場合、フローは１３０５に進み、最初に現在地点のLocationType、すなわち、道路にあるのか又は交差点にあるのかをチェックする。これは、値「Int_Est_Val」の設定、すなわち、車両が交差点にあるのか（「ＹＥＳ」）否か（「ＮＯ」）の判断につながる。

LocationTypeとInt_Est_Valの変数の１つの違いは、前者の変数が車両が実際に交差点にあると示すことを試みるのに対し、後者はむしろ、後続のアルゴリズムが、車両が交差点にあることを仮定すべきか否かについての後続のアルゴリズムのモードである。LocationTypeは、車両が交差点にあることを示し得るが、このような推定は正確ではないかもしれず、後続のアルゴリズムはInt_Est_Val = NOを設定することによって、この情報を無視することを選択してもよい。このような場合に起こるであろうことは、車両が交差点にあるＧＰＳ地点となった時に、位置が最後地点（普通は直線の道路の地点）と一致しないかもしれず、よってｒａｗ ＧＰＳ地点が送信される。よって、一実施形態例では、車両が交差点にある場合は、常にｒａｗ ＧＰＳ情報が送信され、車両が直線の道路に沿って動いている場合は、常にデータが圧縮されている。

１３０７では、Int_Est_Valがチェックされる。Int_Est_Val = ＮＯである場合は、１３０８でp(current) がＳ［ｋ］とＳ［ｋ＋１］のどちらに近いかを推定し、それに従って１３０９及び１３１０で、インデックス＝０又は１の値を設定する。この結果は次に１３１１で送信時間判定モジュールによって処理され、これが、この圧縮ＧＰＳ情報をいつ送信すべきかを判定する。このモジュールの詳細は、システムの送信モードに依存し、図１５でより詳細に説明される。モードが「規則的空間サンプリング」である場合は、インデックス＝１である時に常に送信する。モードが「規則的時間サンプリング」である場合は、ＧＰＳ座標は、時間間隔Ｔｓで規則的に送信され、その値は図１５の管理機能で設定される。

Int_Est_Val = ＹＥＳである場合は、フローは１３１２に進み、車が交差点で向かっている方向、交差点の開始及び終了のＧＰＳ地点を判定し、これをクラウドに送信する。１３１３では、交差点セグメントのインデックスは、地点p(current）が位置するところで計算される。

１３１４では、パケット符号化モジュールは、先行するアルゴリズムで生成される情報（ｒａｗ ＧＰＳ又は圧縮されたＧＰＳ、LocationType情報など）を取得し、送信のための可変サイズのパケットを形成する。表１についてのさらなる詳細が以下で説明される。

図１４は、一実施形態例に係るコンテキストアウェア再構築規則機能１２０２−３のフロー図を示す。１４００では、コンテキストアウェア再構築規則機能は、エッジ実施層からパケットを受信する。１４０１では、コンテキストアウェア再構築規則機能は、送信パケットを復号化する。１４０２では、ｒａｗ ＧＰＳ座標が存在するか否かを判定するためのチェックが行われる。

ｒａｗ ＧＰＳ座標が存在する（Ｙｅｓ）場合は、フローは１４０３に進み、ｒａｗ ＧＰＳ座標をデータ層に渡す。さらに、１４０３では、ＧＩＳ情報データベースは、図１３で説明されるエッジの場合と同様の方法で、地点の位置情報（LocationType、最も近い道路の地点など）を計算するために使用される。存在しない（Ｎｏ）場合は、送信パケットが圧縮された座標を含むので、フローは１４０４に進む。１４０４では、LocationTypeが判定される（すなわち、地点が交差点にあるのか直線の道路にあるのか）。

地点が道路にあると判定された（Ｎｏ）場合は、フローは１４０６に進み、図９で開示される直線道路を仮定するＧＰＳ座標を推定する。ＧＰＳ座標は、インデックス値のシークエンスでは、任意の望ましい実施形態によって推定することができる。例えば、１つの特定の方法は以下のとおりである：インデックス＝１の場合は、ＧＰＳ位置がＳ［ｋ+１］であると推定し、そうでない場合、インデックス＝０の場合は、連続的なインデックス＝０ 値の数を計算し、それをＰと呼ぶ。アルゴリズムがループのこの部分にある場合には、Ｐ>１であることに留意する。次に、rho=1/(1+a*(P-1)を定義するが、ここでａは集合{{1、0.5、0.25、0.1}から選択できる定数である。次に、ＧＰＳ座標は、rho*S[k] +(1−rho)*S[k+1]と推定される。

地点が交差点にあると判定される場合（Ｙｅｓ）、フローは１４０５に進み、交差点を仮定するＧＰＳ座標を推測する。任意のアルゴリズムを使用して、図１１で説明される実施形態に従った交差点のためのＧＰＳ座標を判定することができる。

１４０７では、推定値は、次に図１３のフローで使用できるデータとして処理される。

図１５は、一実施形態例に係る管理フロー例を示す。図１５の管理層は、エッジとクラウドの両方について示される。管理層は、以下のモジュールを含むことができる。送信モード判定モジュール１５０１−１、１５０１−２は、アルゴリズムが以下の２つのモードのどちらを実行すべきかを判定する。実行できるアルゴリズムは、規則的時間サンプリング（ＧＰＳ情報が規則的な時間間隔でエッジから送信されることを示す）及び規則的空間サンプリング（ＧＰＳ情報が、車両がＧＩＳデータベースの次のＧＰＳ地点に到達する際などの規則的な空間間隔でエッジから送信されることを示す）を含む。アルゴリズムの選択は、エッジとクラウドの間のネゴシエーションを通して共同で実行でき、根底にあるアプリケーションの要件によって決定できる。

空間サンプリングレート判定モジュール１５０２−１、１５０２−２は、ＧＩＳデータベースのＧＰＳ地点の間の間隔を変更するように構成される。間隔は、エッジ（瞬間的な車両速度１５０２−４の情報を有する）及びクラウド（平均の道路速度１５０２−３に関する情報を有する）のモジュールを通したネゴシエーションによって決定され、さらに図１６Ａ〜図１６Ｃに関して説明される。

クラウドのマップビルダーモジュール１５０３は、空間サンプリングレートの情報、ＧＩＳ情報１５０５、及び車両の個別の移動パターン１５０６も取得し、ある車両に特定のＧＩＳデータベースを決定する。この情報は、次にマップストレージモジュール１５０４のエッジと共有される。車両に特定のデータベースのニーズは、使用事例（例えば、フリート管理）から生じるかもしれない。車両のルートは、ルート内で決定及び追跡できる。

図１６Ａ〜図１６Ｃは、一実施形態例に係る空間サンプリングの実施例を示す。特に、図１６Ａ〜図１６Ｃは、ＧＰＳサンプリングレートの逸脱の例を示し、これが第１のＧＩＳ中間地点と第２のＧＩＳ中間地点の間の距離を判定するのに使用される。ＧＰＳサンプリングレートは、表１に示されるように、ＧＩＳ中間地点との比較のために実行されるＧＰＳ座標の空間サンプリングのレートである。図１６Ａは、道路に沿ったそのより細かな粒度の解像度でＧＰＳ地点（×で示される）を示す。低速で動いている車両又は道路の状態では、ＧＩＳデータベースは、図１６Ｂに示されるこれらすべての地点を有することができる（○で示される）。しかし、交通が高速で動いている場合を考えてみる。この場合は、サンプリングされたＧＰＳ地点の集合がより分散して広がる必要があるかもしれないし、さもなければ、非常に頻繁な更新（規則的空間サンプリングの場合）又は不正確さ（規則的時間サンプリングの場合［次のレポートの瞬間が来るまでには、車両は地点Ｓ［ｋ＋１］を優に過ぎているので］）が生じる可能性がある。よって、実施形態例は、道路速度の状態に応じてＧＰＳ座標の空間サンプリングレートを調整する。図１６Ｃで示されるように、道路速度が速い場合は、より高いサンプリングレートが選択される。

さらに、実施形態例には、符号化送信パケットモジュールが存在する。エンコーダーの主な課題は、ｒａｗ ＧＰＳ又は圧縮されたＧＰＳ情報を運んでいる際に起こる異なる長さを有する異なる種類の情報を組み込むことである。パケット及びそのフィールドの構造を下の表１に示す。

表２：パケットコーディングフォーマット

実施形態例は、その位置情報をクラウドベースのサーバに運ぶため、車両から送信する必要があるデータの５０％〜９０％の削減を達成することができる。この削減によって、システム容量が増え、位置追跡サービスが以前よりも多くの車両で利用できるようになる。実施形態例は、クラウド処理に対応する車両での最小限のエッジ処理で達成することができる 。

図１７は、実施形態例が実施できる実施例の演算環境を示す。図１３、図１４のフロー図と共に、図４、図１２及び図１５で示される通り、エッジアーキテクチャ及びクラウドアーキテクチャのための実施形態例は、それぞれ、エッジ装置であるように構成されたコンピュータ装置１７０５、又はクラウド装置であるように構成されたコンピュータ装置１７０５で実行できる。演算環境１７００のコンピュータ装置１７０５は、１つ以上の処理装置、コア、又はプロセッサ１７１０、メモリ１７１５（例えば、ＲＡＭ、ＲＯＭなど）、内部ストレージ１７２０（例えば、磁気、光、ソリッドステートストレージ、及び／又は有機）、及び／又はＩ／Ｏインターフェース１７２５を含むことができ、これらのいずれも情報通信のために通信の機構又はバス１７３０上で接続するか、コンピュータ装置１７０５に埋め込むことができる。

コンピュータ装置１７０５は、入力／ユーザーインターフェース１７３５及び出力装置／インターフェース１７４０に通信可能に接続することができる。入力／ユーザーインターフェース１７３５及び出力装置／インターフェース１７４０のいずれか１つ又は両方は、有線又は無線のインターフェースであることができ、取り外し可能である。入力／ユーザーインターフェース１７３５は、入力（例えば、ボタン、タッチスクリーンインターフェース、キーボード、ポインティング／カーソル制御、マイク、カメラ、点字、動作センサ、光学リーダー、及び/又はその他）を提供するために使用できる、任意の装置、構成要素、センサ、又はインターフェース（物理又は仮想）を含み得る。出力装置／インターフェース１７４０は、ディスプレイ、テレビ、モニター、プリンター、スピーカー、点字などを含み得る。いくつかの実施形態例では、入力／ユーザーインターフェース１７３５及び出力装置／インターフェース１７４０は、コンピュータ装置１７０５に埋め込むか、又はこれに物理的に接続することができる。他の実施形態例では、他のコンピュータ装置は、コンピュータ装置１７０５のための入力／ユーザーインターフェース１７３５及び出力装置／インターフェース１７４０として機能するか、又はかかる機能を提供することができる。

コンピュータ装置１７０５の例は、高度なモバイル装置（例えば、スマートフォン、車両及び他の機械の中の装置、人間及び動物が持ち運ぶ装置など）、モバイル装置（例えば、タブレット、ノートブック、ラップトップ、パーソナルコンピュータ、ポータブルテレビ、ラジオなど）、及び移動用に設計されていない装置（例えば、デスクトップコンピュータ、他のコンピュータ、情報キオスク、１つ以上のプロセッサがその中に埋め込まれているか、それに接続されているテレビ、ラジオなど）を含み得るが、これらに限定されない。

コンピュータ装置１７０５は、任意の数のネットワーク化された部品、装置、及びシステム（同じ又は異なる構成の１つ以上のコンピュータ装置を含む）と通信するために外部ストレージ１７４５及びネットワーク１７５０に通信可能に接続できる（例えば、Ｉ／Ｏインターフェース１７２５を介して）。コンピュータ装置１７０５又は任意の接続されたコンピュータ装置は、サーバ、クライアント、シンサーバ、汎用マシン、専用マシン、又は別のラベルとして機能し、サービスを提供し、又は言及することができる。

Ｉ／Ｏインターフェース１７２５は、演算環境１７００の少なくともすべての接続された部品、装置、及びネットワークに対してかつ／又はこれらから情報を通信するための任意の通信又はＩ／Ｏプロトコルもしくは規格を使用する有線及び／又は無線のインターフェース（例えば、イーサーネット、８０２.１１ｘ、ユニバーサルシステムバス、ＷｉＭａｘ、モデム、セル方式のネットワークプロトコルなど）を含むが、これらに限定されない。ネットワーク１７５０は、任意のネットワーク又はネットワークの組合せ（例えば、インターネット、ローカルエリアネットワーク、ワイドエリアネットワーク、移動体通信ネットワーク、ネットワーク、サテライトネットワークなど）であり得る。

コンピュータ装置１７０５は、一時的媒体及び非一時的媒体を含むコンピュータ使用可能又はコンピュータ可読の媒体を使用でき、かつ／又はこれらを用いて通信できる。一時的媒体は、通信媒体（例えば、金属ケーブル、光ファイバー）、信号、搬送波などを含む。非一時的媒体は、磁気媒体（例えば、ディスク及びテープ）、光媒体（例えば、ＣＤ ＲＯＭ、デジタルビデオディスク、ブルーレイディスク）、ソリッドステート媒体（例えば、ＲＡＭ、ＲＯＭ、フラッシュメモリ、ソリッドステートストレージ）、及び他の不揮発性ストレージ又はメモリを含む。

コンピュータ装置１７０５は、いくつかの例示的な演算環境で技術、方法、アプリケーション、プロセス、又はコンピュータ実行可能命令を実施するために使用できる。コンピュータ実行可能命令は、一時的媒体から取得することができ、非一時的媒体に格納又はそこから取得することができる。実行可能命令は、１つ以上の任意のプログラミング、スクリプト、及びマシン言語（例えば、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（登録商標）、Ｖｉｓｕａｌ Ｂａｓｉｃ、Ｐｙｔｈｏｎ、Ｐｅｒｌ、ＪａｖａＳｃｒｉｐｔ（登録商標）など）で書くことができる。

００７７ プロセッサ１７１０は、ネイティブ又は仮想の環境で、任意のオペレーティングシステム（ＯＳ）（図示されていない）で実行できる。論理ユニット１７６０、アプリケーションプログラミングインターフェース（ＡＰＩ）ユニット１７６５、入力ユニット１７７０、出力ユニット１７７５、及び異なるユニットが相互に、ＯＳと、かつ他のアプリケーション（図示されていない）と通信するためのユニット間通信機構１７９５を含む１つ以上のアプリケーションが配備される。説明されたユニット及び要素のデザイン、機能、構成、又は実装は様々であり、提供される説明に限定されない。

いくつかの実施形態例では、情報又は実行命令がＡＰＩユニット１７６５で受信される場合に、１つ以上の他のユニット（例えば、論理ユニット１７６０、入力ユニット１７７０、出力ユニット１７７５）に通信し得る。いくつかの例では、論理ユニット１７６０は、上記のいくつかの実施形態例で、ユニット間の情報フローを制御し、ＡＰＩ装置１７６５、入力ユニット１７７０、出力ユニット１７７５によって提供されるサービスを指示するように構成することができる。例えば、１つ以上のプロセス又は実施形態のフローは、論理ユニット１７６０だけで、又はＡＰＩ装置１７６５と連携して制御してよい。入力ユニット１７７０は、実施形態例で説明される計算のための入力を取得するように構成してよく、出力ユニット１７７５は、実施形態例で説明される計算に基づいた出力を提供するように構成してよい。

コンピュータ装置１７０５がエッジアーキテクチャの機能性を促進するように構成される場合、プロセッサ１７１０は、図４、図１３、図１５に示される通り、全地球測位衛星（ＧＰＳ）情報から、第２のＧＩＳ中間地点に比較した第１の地理情報システム（ＧＩＳ）中間地点へのコンピュータ装置１７０５の近さを判定し、第２のＧＩＳ中間地点に比較した第１のＧＩＳ中間地点への装置の近さを示すインデックス情報を生成し、インデックス情報をクラウドアーキテクチャに送信するように構成することができる。第２のＧＩＳ中間地点に比較した第１のＧＩＳ中間地点へのコンピュータ装置１７０５の近さが判定不能な場合、プロセッサ１７１０は、図１３で開示されるように、ＧＰＳ情報をクラウドアーキテクチャに送信するように構成される。プロセッサ１７１０はまた、表１に例示されるように、プロセッサ１７１０がＧＰＳ情報を送信する際に非圧縮データを示し、かつプロセッサ１７１０がインデックス情報を送信する際に圧縮データを示す、圧縮情報を含むパケットを送信するように構成できる。プロセッサ１７１０は、ＧＰＳサンプリングレートに基づいてＧＰＳ情報を取得するように構成され、また図１６Ａ〜図１６Ｃに示される通り、それに従ってＧＰＳサンプリングレートを調整することができる。

コンピュータ装置１７０５がクラウドアーキテクチャの機能性を促進するように構成される場合、プロセッサ１７１０は、図１４に説明されているように、エッジ装置からのＧＰＳ情報の受信については、ＧＰＳ情報及びＧＩＳ情報に基づいてエッジ装置の位置を計算し、インデックス情報の受信については、インデックス情報からエッジ装置のＧＰＳ座標を推定するように構成することができる。インデックス情報は、第２のＧＩＳ中間地点に比較した第１のＧＩＳ中間地点へのエッジ装置の近さに基づいて設定される第１の値と、交差点に近いエッジ装置の場合は、交差点の複数の経路のうちの一つの経路へのエッジ装置の別の近さを示す第２の値とを含むことができる。プロセッサ１７１０はまた、図１６Ａ〜図１６Ｃで示される通り、エッジアーキテクチャのためのＧＰＳサンプリングレートを判定し、ＧＰＳサンプリングレートをエッジアーキテクチャに送信するように構成することができる。

詳細な説明のいくつかの部分は、コンピュータ内の操作のアルゴリズム及び象徴的な表現によって示される。これらのアルゴリズムの説明及び象徴的な表現は、データ処理の当事者がその革新性の本質を他の当事者に伝えるために使用される手段である。アルゴリズムは、望ましい最終的な状態又は結果につながる一連の定義されたステップである。実施形態例では、実行されるステップは、具体的な結果を達成するための具体的な量の物理的な操作を必要とする。

別段の記載がない限り、以下の解説から明らかなように、当然のことながら説明全体を通して、「処理」、「演算」、「計算」、「判定」、「表示」等の用語を用いた解説は、コンピュータシステムのレジスタ及びメモリ内の物理的（電子的）数量として表わされるデータを、コンピュータシステムのメモリもしくはレジスタ又はその他の情報記憶、送信もしくは表示装置の中の物理的数量として同様に表わされるその他のデータに操作しかつ変換する、コンピュータシステム又はその他の情報処理装置の動作又はプロセスを含み得る。

実施形態例は、本明細書におけるオペレーションを実施する装置にも関し得る。この装置は、必要とされる目的のために特別に構築してもよく、又は1つ以上のコンピュータプログラムによって選択的に起動又は再構築された1つ以上の汎用コンピュータを含み得る。当該コンピュータプログラムは、コンピュータ可読記憶媒体又はコンピュータ可読信号媒体などのコンピュータ可読媒体に記憶してよい。コンピュータ可読記憶媒体は、光ディスク、磁気ディスク、読取専用メモリ、ランダムアクセスメモリ、ソリッドステート装置及びドライブ、又は電子情報の格納に適したその他あらゆるタイプの有形又は非一時的な媒体を含むが、これらに限定されない、有形媒体を含み得る。コンピュータ可読信号媒体は、搬送波などの媒体を含み得る。本明細書において示されるアルゴリズム及び（情報）提示は、特定のコンピュータ又はその他の装置に本質的に関係しているわけではない。コンピュータプログラムは、望ましい実施形態のオペレーションを実施する命令を含む純粋なソフトウェアの実施を含み得る。

様々な汎用システムを、本明細書における実施例に従ってプログラム及びモジュールと共に使用してもよく、又は望ましい方法ステップを実施するためにより特化した装置を構築することが都合がよいということが判明するかもしれない。さらに、実施形態例は、特定のプログラミング言語を参照して説明されてはいない。当然のことながら、本明細書に記載されている通りに本実施形態例の教示を実施するために、様々なプログラミング言語を使用してもよい。プログラミング言語の命令は、1つ以上の処理装置、例えば中央処理装置（ＣＰＵ）、プロセッサ、又はコントローラによって実行され得る。

当技術分野では周知であるように、上述のオペレーションは、ハードウェア、ソフトウェア、又はソフトウェアとハードウェアの組み合わせによって実行することができる。実施形態例の様々な態様は、回路や論理装置（ハードウェア）を用いて実施してよく、その一方で、その他の態様は、機械可読媒体（ソフトウェア）上に記憶された命令を用いて実施してもよく、これがプロセッサによって実行された場合には、本出願の実施形態を実行する方法をプロセッサに実施させるものである。さらに、本出願のいくつかの実施形態例は、ハードウェアのみにおいて実施されてよく、その他の実施形態は、ソフトウェアのみで実施されてよい。さらに、説明された様々な機能は、1つのユニットで実施することができ、又はあらゆる方法によって多くの構成要素に分散することができる。ソフトウェアによって実施された場合、上記の方法は、コンピュータ可読媒体に記憶された命令に基づいて、汎用コンピュータなどのプロセッサによって実行され得る。望ましい場合には、圧縮及び／又は暗号化形式で命令を媒体に記憶することができる。

また、本出願の教示内容の明細及び実践を考慮することにより、本出願の他の実施形態が、当業者にとって明白となるであろう。記載された実施形態例の多様な態様及び／又は構成要素は、単独で又は組み合わせて使用してよい。本明細書及び実施形態例は例示のみとして考慮され、本出願の真正なる範囲及び精神は以下の請求項によって示されることが意図されている。

Claims (11)

1. 全地球測位衛星（ＧＰＳ）情報から、第２のＧＩＳ中間地点に対する第１の地理情報システム（ＧＩＳ）中間地点への第１の装置の近さを判定し、
   前記第１の装置は、
   前記第２のＧＩＳ中間地点に対する第１のＧＩＳ中間地点への前記第１の装置の前記近さを示すインデックス情報を生成し、かつ、第２の装置に前記インデックス情報を送信するように構成された第１のプロセッサを備え、
   前記第１のプロセッサは、
   前記第２のＧＩＳ中間地点に比較した前記第１のＧＩＳ中間地点への前記第１の装置の前記近さが判定不能である場合に、前記第２の装置に前記ＧＰＳ情報を送信するように構成され、
   前記第１のＧＩＳ中間地点が前記ＧＰＳ情報について有効ではない場合に、前記第２の装置に前記ＧＰＳ情報を送信するように構成され、
   前記ＧＰＳ情報を、１つ以上のＧＩＳ中間地点のＧＰＳ情報と比較することによって、前記ＧＰＳ情報から前記第１のＧＩＳ中間地点及び前記第２のＧＩＳ中間地点を判定するように構成される、
   システム。
2. 前記第２の装置は、前記インデックス情報を受信するために、前記インデックス情報から前記第１の装置の地点を推定するように構成された第２のプロセッサを備える、請求項１に記載のシステム。
3. 前記インデックス情報は、前記第２のＧＩＳ中間地点に比較した前記第１のＧＩＳ中間
   地点への前記第１の装置の前記近さに基づいて設定される第１の値と、前記第１の装置が
   交差点に近い場合は、前記交差点の複数の経路のうちの一つの経路への前記第１の装置の
   別の近さを示す第２の値とを備える、請求項１に記載のシステム。
4. 前記第１のプロセッサはさらに、前記第１のプロセッサが前記ＧＰＳ情報を送信する際の非圧縮データを示し、かつ前記第１のプロセッサが前記インデックス情報を送信する際の圧縮データを示す、圧縮情報を送信するように構成される、請求項１に記載のシステム。
5. 前記第２のプロセッサは、前記第１の装置のための前記第２のＧＩＳ中間地点から前記第１のＧＩＳ中間地点への距離を判定するＧＰＳサンプリングレートを判定し、かつ前記第１の装置に前記ＧＰＳサンプリングレートを送信するように構成され、
   前記第１のプロセッサは、前記ＧＰＳサンプリングレートに基づいて前記ＧＰＳ情報を
   取得するように構成される、請求項２に記載のシステム。
6. 全地球測位衛星（ＧＰＳ）情報から、第２のＧＩＳ中間地点に対する第１の地理情報シ
   ステム（ＧＩＳ）中間地点への装置の近さを判定し、
   前記第２のＧＩＳ中間地点に対する前記第１のＧＩＳ中間地点への前記装置の前記近さ
   を示すインデックス情報を生成し、かつ
   別の装置に前記インデックス情報を送信する
   ように構成されたプロセッサを備え、
   前記プロセッサは、前記第２のＧＩＳ中間地点と比較される前記第１のＧＩＳ中間地点への前記装置の前記近さが判定不能である場合に、前記別の装置に前記ＧＰＳ情報を送信するように構成され、
   前記プロセッサはさらに、前記ＧＰＳ情報を送信する際の非圧縮データを示し、かつ、前記インデックス情報を送信する際の圧縮データを示す、圧縮情報を送信するように構成される、
   装置。
7. 前記インデックス情報は、前記第２のＧＩＳ中間地点に比較した前記第１のＧＩＳ中間
   地点への前記第１の装置の前記近さに基づいて設定される第１の値と、前記第１の装置が交差点に近い場合は、前記交差点の複数の経路のうちの一つの経路への前記第１の装置の別の近さを示す第２の値とを備える、請求項１に記載のシステム。
8. 前記プロセッサは、前記別の装置から受信したＧＰＳサンプリングレートに基づいた前記ＧＰＳ情報を取得するように構成され、前記ＧＰＳサンプリングレートは、前記第２のＧＩＳ中間地点から前記第１のＧＩＳ中間地点への距離を判定する、請求項６に記載の装置。
9. 別の装置の位置を示す受信情報が全地球測位衛星（ＧＰＳ）情報を対象とする場合は、
   前記ＧＰＳ情報及び ＧＩＳ情報に基づいた前記別の装置の位置を判定し、
   インデックス情報を受信した前記別の装置から受信された情報について、前記インデックス情報から第２のＧＩＳ中間地点に対する第１の地理情報システム（ＧＩＳ）中間地点への前記別の装置の近さを判定し、かつ前記近さに基づいて前記別の装置の地点を推測する
   ように構成されたプロセッサを備え、
   前記プロセッサはさらに、前記情報が前記ＧＰＳ情報を対象とする際の非圧縮データとしての前記情報を示し、かつ前記情報が前記インデックス情報を対象とする際の圧縮データとしての前記情報を示す、圧縮情報を処理するように構成される、
   装置。
10. 前記インデックス情報が、前記第２のＧＩＳ中間地点に比較した前記第１のＧＩＳ中間地点への前記別の装置の前記近さに基づいて設定される第１の値と、前記第１の装置が交差点に近い場合は、前記交差点の複数の経路のうちの一つの経路への前記別の装置の別の近さを示す第２の値とを備える、請求項９に記載の装置。
11. 前記プロセッサが、前記別の装置のためのＧＰＳサンプリングレートを判定し、かつ第１の装置に前記ＧＰＳサンプリングレートを送信するように構成されており、前記ＧＰＳサンプリングレートが、前記第２のＧＩＳ中間地点からの前記第１のＧＩＳ中間地点への距離を判定する、請求項９に記載の装置。