マップマッチングリンクとアイデア?[閉まっている]


44

OpenStreetMapとそのベクター道路ネットワークを使用しています。マップマッチャーアルゴリズムを実装したいと思います。

現在、私は、各GPS位置について、最も近い道路セグメントを取得し、この画像のようにその位置へのこの位置の投影を計算することができます(赤いピンは純粋なGPS位置で、青い部分はマッピングされた部分、緑はマッピングされた位置):

ここに画像の説明を入力してください

ただし、GPSの精度が不足しているため、マップされた位置がセグメント間でジャンプし、マップの位置に矛盾が生じることがあります。

私の現在のアルゴリズムは非常に基本的です。純粋なGPS位置から、最も近いセグメントを取得し、マッピングされた一致した位置がこの位置にあると判断します。これは本当に改善できることを知っています。

車両の方向を考慮するとマップマッチングが改善されると想像できますが、マップマッチャーを改善できる他のアプローチを知っていますか?

リンクやオープンソースソフトウェアを探していますか?


4
円を追加できます-Googleはセル受信を使用して、おおよその位置を示す水色の円を作成します。あなたのアプリは見栄えが良く、良い仕事です。ベクターデータがある場合は、GPSポイントから最も近いラインにスナップできます-Paul
Mapperz

4
お探しのキーワードはマップマッチングです。大きな主題。
Uffe Kousgaard

1
Uffeは正しい、マップマッチング。いくつかのアプローチについては、このペーパーを確認してください。cens.ucla.edu/
mhr

ありがとう!lexicore、これを入力すると、用紙がプリンターに送信されます。概要を取得する時間です。リンクありがとうございます。
scrrr

頂点だけでなく、実際の道路にもスナップしようとすることで、アルゴリズムを改善します。
Devdatta Tengshe

回答:


11

すでに行っているようにポイントをラインに投影することは、PostGISで直接行うことができます。少し前に書い

しかし、ポイントが正しいセグメントよりも間違ったセグメントに近い場合の問題を解決するには、おそらくこれが可能なアプローチかもしれません。

  1. ポイントのラインストリングを作成します
  2. セグメントのマッチングのアルゴリズムで提案された解決策を試して、ポイントごとにではなく、行全体に 一致させてください

返信のThx。投影は大丈夫です。すでに使用しています(ST_Closestを使用していないため、使用している空間ライトでは使用できませんが、大丈夫です)。また、あなたが言及した質問を見て、この「ハウスドルフ距離」の存在について学びました。
ヨネル

10

あなたの質問とさまざまな回答を読んだ後、私はこの問題に興味を持ちました。Map-matchingアルゴリズムについて少し読んだ後、次のことを理解しました。

  • GPSロケーションを道路に一致させるには、ベクター形式の実際の道路データが必要です
  • 道路ごとに重みが異なる場合に役立ちます。そのため、ポイントが高速道路と一致する可能性が高くなり、サイドラインと一致する可能性が高くなります。
  • あなたは、歴史、およびGPSの読み取りの速度を取る必要があります。たとえば、gpsポイントが長い間サイドレーンと一致している場合は、それを考慮に入れ、高速道路と直接一致しないようにする必要があります。-実際のマッチングは、さまざまな統計手法を使用して行われます。

さらに読むには、以下をお勧めします。


はい、私も読んでいて、私が拡張できる単純なアルゴリズムを実装することで遊び始めました。これまでのところ、OSMからいくつかのデータをダウンロードしており、目的に合わせて最適に保存(およびアクセス)する方法を試しています。面白いトピックだと思います。:)何かうまくいったら、この質問を更新します。また、リンクをありがとう!
scrrr

私は「ハイウェイとポイントが一致する可能性が高くなり、サイドラインを一致させる場合に」ウェイトを使用することに注意します。...それは入力データに依存しており、非常に間違っている可能性があります。
暗闇

@ Devdatta、2番目のリンクで404を受け取ります。編集するだけでなく、別のリンクがありますか?
チャウ

私はその記事への無料アクセスリンクを持っていません。ただし、アカデミックな設定をしている場合。記事は、クイック検索の後に利用可能であるべきである
Devdatta Tengshe


7

自分の質問に答える!

1-このテーマについて見つけた素敵な.pdf

http://safari.ce.sharif.edu/file/2011-06-06/259/2009_An%20off-line%20map-matching%20algorithm%20for%20incomplete%20map%20databases.pdf

また、ドキュメントに記載されているマップマッチャーのC ++オープンソース実装にリンクしています:http : //eden.dei.uc.pt/~camara/files/mgemma.zip
(これはオフラインマップマッチャーです。私の理解は入力としてWHOLEパスを使用してマップ一致位置を計算し、各位置に対してオンザフライで実行できないことを確認します)。

2-そして、私はこれを深く読んだばかりで、私の意見では本当に良いです: https : //dspace.lboro.ac.uk/dspace-jspui/bitstream/2134/4860/1/velaga.pdf "Developing高度道路交通システム」の強化された重みベーストポロジカルMapMatchingアルゴリズム
アルゴリズムが明確に説明されており、重量調整値もドキュメントで提供されています。


4

Map-matchingには多くの作業があります。かなり最近の作業(2007年以前)の簡単な調査については、このペーパーを参照してください。最近では、隠れマルコフモデルに基づくアプローチは、通常の状況下で非常にうまく機能するようです。たとえば、2009年のこのペーパーをご覧ください。アイデアとモデルは非常にシンプルであり、HMMに精通していなくても実装するのに苦労しないはずです(その場合、パニックにならないでください。チュートリアルと紹介オンライン)


1
私が答えで言及したベアフット-プロジェクトは、@ Nickが推奨する論文に基づいていることを認識しました。
ニック

4

この方法は、「ベクトル融合」とも呼ばれます。専用のWikiページ(http://wiki.openstreetmap.org/wiki/Conflation)があります。これは、「JOSM conflation plugin」、「Potlatch 2マージ」などの道路ベクトルconflationを実行する一般的な概要とリスト(オープンソース)ソフトウェアパッケージを提供しますツール」、「RoadMatcher」(OpenJUMP用)など。


1
混同は、ポイントをラインに一致させるのではなく、2つのラインレイヤーで行うものだといつも思っていました。本当に同じですか?
暗闇

4

マップマッチングアルゴリズムの場合、リアルタイム処理とオフライン処理のどちらが必要かによって異なります。後者の場合、最先端のアルゴリズムは1秒あたり約1000ポイントを処理できます。メモリー要件は、もちろんカバレッジによって異なります。その目的のために、約16 Gbで地球のOSM道路網を絞ることができました。

また、マップマッチングパス推論を区別する必要があります。これらは、高頻度データと低頻度データのどちらであるかによって2つの別個のプロセスです。ポイントが比較的少ない場合(たとえば、都会の状況では1キロメートルごとに1データ)、デバイスが移動している場所を推測するために通常行われるいくつかの仮定があるため、これはパス推論です。通常、パスの推測はより困難ですが、最新のデバイス/データ取得の価格では問題が少なくなっています。

OSMで直接マップマッチングを行うAPIのプロファイルを確認できます。トポロジマッチングを使用し、たとえばフローティングカーデータでうまく機能します。


使用しているアルゴリズムを拡張できますか?また、道路網のサイズを小さくするとどうなりますか?
Devdatta Tengshe

カバレッジが小さい=メモリ内に保持するネットワークが小さくなります。これにより、計算が少し速くなります。参照:trb.metapress.com/content/p31485vw72645686
Fabrice Marchal

3

Strava Slideは、道路ネットワーク上の累積トラックデータが「谷」のように振る舞う方法、および提案されたルートがビーズの列のように「所定の位置に収まる」方法について説明します。


2

前述のフレームワークのほとんどをテストした後、Barefootを見つけ、実際に推奨できます。確率的マップマッチングアプローチとして隠されたマルコフモデルを使用し(論文「地図上に車を置く」の詳細)、Javaで実装されています。オープンソースであり、BMWのCarIT部門が積極的に開発しています。


2

件名はマップマッチングと呼ばれます。しかし、最初の非常に良い近似として、すべてのgpsポイントの最も近いポイントを検索するだけで十分です(正しい方法を推測する修正はありません)。

graphhopperと呼ばれる私のオープンソースプロジェクトは、iOSで動作するものではありません(更新:iOSでも動作するようになりました)。また、必要な機能を備えた完全に機能するAndroidアプリもありません。ただし、サーバーバージョンを使用してiOSアプリを構築したり、オフラインAndroidデモを開始として使用したりできます。ここでマップマッチングアルゴリズムをリリースしました。これは大まかなプロトタイプですが、驚くほどうまく機能します。


1

いくつかの良いテストデータを取得してください。ターゲットデバイスのログポイントに加えて、GPSのログを記録する追加の高精度トラックを使用します。これにより、GPSおよび基になるOSMデータのエラーが特定されます。合理的なしきい値を知ることで、アルゴリズムの設計がはるかに簡単になります。




弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.