1

GPS 情報を利用して、ユーザーがどの道路/小道 (または OpenStreetMaps 用語では「道」) にいるかを判断するアプリを作成しています。OSM のウェイには幅の情報は含まれず、一連のポイントが接続されているだけなので、GPS 座標がどのポリ ボックスにあるかを把握することは問題ではありません。

私が持っている情報は、曲がりくねったトレイルを定義するポイントのリストです (もしそれがただのまっすぐなトレイルであれば、2 ポイント 1/2 マイル離れている可能性があります)。これらのトレイルは通常、樹木の境界線 (たとえば 50 ～ 300 m 離れた場所) で区切られており、公園内に多くのトレイルが存在する可能性があるため、幅の情報がない場合の精度は、エッジ ケースでは注意が必要です。通常、ウェイの定義はトレイルの中央を下ります。

トレイル上の個々のベクトルをすべて計算してから、最も近いベクトルを見つける必要があるようです。新しい GPS 更新のたびに (1 ～ 4 秒ごとに?)、これがかなり集中的に行われることを懸念しています。少なくとも、事前に各トレイルのポイントを入力して (x メートルごとにポイントを強制)、GPS の更新時に最も近いポイントを取得することができます。

計算を支援するために、ポイントデータを事前に適応させることができる構造はありますか? モバイル制約に適した、この問題を解決するための他の既知のアルゴリズムはありますか? これはすでに解決済みの問題のようです。

4

2 に答える 2

0

おそらく、何らかのデータ形式からマップを描画するマップ レンダリング API を使用していると思われます。これは基本的に、空間データベースと呼ばれる専用のデータベースです。理想的な世界では、一定の距離 (たとえば 50 メートル) 内にあるすべての道路と小道を見つける効率的な機能を備えている必要があります。

近くの道路や小道のリストができたら、ジャンクションのすぐ隣にある密集したエリアでも数が 10 を超えないので、それらを 1 つずつ調べて、最も近い道路を見つけることができます。あなたのGPS修正。線に最も近い点を見つける標準的な方法があります。ここに議論があります:線に最も近い点を取得します。

このシステムは (私の経験から) 1 秒ごとに GPS を更新するのに十分な速さです。

事前に決められたルートをたどっている場合は、ルートのセグメントを確認するだけでよいため、さらに高速です。もちろん、ユーザーがルートから離れすぎてルート上にいると見なされない場合は、ユーザーに通知します。そして、新しいルートを作成します。それがナビシステムの役割です。

于 2013-04-22T20:46:51.217 に答える
0

これを解決するのがマップマッチングです。
私は通行料の目的でそのようなシステムを書きました。ナビゲーション システムのようなリアルタイム マッチングに関連するバリアントや、GPS データの後処理用の私のような非リアルタイム マッチングに関連するバリアントがあります。
しかし、いずれの場合も、少なくとも数か月は努力を重ねる必要があります。

2 つのパスに分岐する 1 つのトレイルがある場合、事態は難しくなります。
このような状況で間違ったパスが一致したときに問題がなければ、最も近いパスを検索するだけで済みます。

多くの CPU パワーを回避するには、quad tree や kd tree などの地理空間インデックスを使用します。

于 2013-03-28T12:26:52.470 に答える