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

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

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

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

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

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

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

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

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

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

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

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

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

• 低サンプリングレートのGPS軌跡のマップマッチング
• パーソナルナビゲーションアシスタント用のマップマッチングアルゴリズム
• GIS環境における3ステップの一般的なマップマッチング方法：旅行/輸送研究の視点

自分の質問に答える！

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アルゴリズム
アルゴリズムが明確に説明されており、重量調整値もドキュメントで提供されています。

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

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

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

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

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

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

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

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

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

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

お住まいの地域の道路データを取得できる場合は、FOSSを使用した自動一括スナップに興味があるかもしれません

データをリアルタイムでプロットするか、または後でPCで後処理を行う予定かによって、GRASSが役立ちます。

私は、すぐに独自のソリューションを開発する努力をしなくても、仕事をするだけのAPIを見つけました。

OSMデータを使用してマップマッチングを行います。また、GPXファイルのアップロードを可能にするデモページがあり、これがどの程度うまく機能するかを確認できます。

データの品質を必ずしも改善する必要はありません。インメモリロードネットワークでトポロジアルゴリズムを使用すると、マッチングが大幅に改善されます。参照の確認：http : //trb.metapress.com/content/p31485vw72645686