これはすべて、へのハイキング旅行から始まりました Žbevnica 10年以上前。私は新しいGPSを持っていて、友人はGPSをWindowsME電話に接続していました。ハイキングは素晴らしかったが、車に戻ったとき、一方のGPSが6.2 km歩いたと主張し、もう一方のGPSが6.7kmを報告したことに驚いた。 1つは、標高の増加(つまり、ハイキングのすべての上り坂の部分の合計)が300mであったと主張し、もう1つは500mと報告しました。
プログラマーであること(そして最終的には GISプログラム )、私はすぐに問題に興味をそそられました。私は自分に言いました ない 簡単なスクリプトで修正するのは難しいでしょう。」結局のところ、GPSトラックは、次の形式のタプルの単なるリストです。 (緯度、経度、標高) 、 正しい?
まあ、そうではありません。
そして、このようにして、GPSトラック、トラッキングエラー、そしてより一般的にはGISプログラミングの魅力的な世界への遠足が始まりました。
地理空間情報システム(GIS)は巨大で複雑なドメインであり、地図投影法と測地系データ))、ラストとベクトのデータ処理、リモートセンシングが含まれます。このドメインの包括的な紹介は、この記事の範囲をはるかに超えています。また、特定の問題に焦点を当てることは、とにかく新しいドメインを紹介するのに役立つことが多いため、私が遭遇したいくつかの特定のGISの課題といくつかの可能な解決策を紹介します。すなわち:
手始めに、GPSトラックは ない ただの一連の (緯度、経度、標高) タプル。多くのGPS対応デバイスは、時間や心拍数などのメタデータも提供します。一部のGPSデバイスは、データの正確性に関する情報を提供します。 a.k.a.、「 精度の希釈 」。しかし、残念ながら、ほとんどのGPSデバイス、特に市場を支配しているローエンドのデバイスはこの情報を提供せず、デバイスの精度を自分で推測する(そして理想的には可能な場合はそれに応じて修正する)という課題が残されています。 )。
フィギュアグラウンドのゲシュタルト原理
通常は低品質のGPSデータを持つローエンドのGPSデバイス(ほとんどのスマートフォンなど)を検出するための1つの可能なアルゴリズムから始めましょう。
世界の特定の地域に住んでいる場合、スマートフォンでトラックを記録すると、GPSの高度の精度に奇妙なことに気づいたかもしれません。標高を確認すると、正しい標高よりも高いまたは低い(一定の値で)として一貫して記録されます。たとえば、私はVišnjan(クロアチア)に住んでいて、Androidから、実際の標高より約35〜40メートル上にいると言われ続けています。
たとえば、数か月前に行った短いハイキングのGPS標高グラフを次に示します。
ここで注意すべき2つのこと。
最初、 記録されたGPSデータの最初の部分の「丘」は、デバイスによって完全に作成されました 。グラフは、ハイキングの最高点が開始からわずか数百メートルであることを示しているように見えますが、実際には約4km後です。
第二に、おそらくもっと重要なこと(そして ない グラフに表示されます)は グラフ全体が不正確です 。高度の値は、この記事でさらに詳しく説明するように、実際よりも約30〜40メートル高いと一貫して報告されています。
トラックにこれらのエラーがあることを検出できれば、そのデバイスはおそらく低品質のGPSであると推測できます。これらは、安価なGPSデバイスで発生する可能性のある種類のことです。また、トラックにこれらのエラーがあることを検出できれば、デバイスはおそらく低品質のGPSであると推測できます。したがって、標高エラーだけでなく、そのようなデバイスに共通する他のエラーも発生することが予想されます。
GPSデバイスが高度を決定するために使用する基本的に2つの手法があります。「GPS高度」(GPS衛星システムによってデバイスに報告される)と「気圧高度」(気圧の読み取り値に基づいてデバイスによって計算される)です。どちらも完璧ではありません。
GPS高度値には、多くの小さなエラー(通常は+/- 10mの範囲)が含まれる可能性があります。これは、後で累積高度ゲインを計算することにした場合に特に問題になる可能性があります。一方、気圧高度は、高度だけでなく気象条件にも敏感であるため、独自の不正確さが生じる可能性があります。
したがって、一部のデバイスは、気圧の読み取り値を使用して標高を記録し、GPSの読み取り値を使用してこれらの値を(再)較正し、天気(圧力)の変化などを説明するハイブリッドアプローチを採用しています。このようなデバイスでは、トラックを開始するときに気圧高度が完全に間違っている可能性がありますが、GPS衛星データを増やして再校正することで、高度データの信頼性が高まります。 したがって、このようなデバイスでは、標高グラフで以前に観察したタイプの「偽の丘」の起動エラーが発生することは珍しくありません。
高度レポートの一貫したエラーを説明するには、小学校の地理に戻る必要があります。地理の教師は通常、地球は球体ではなく、 楕円 。これが実際に厳密に当てはまる場合、高度は数学的に簡単に計算できます。しかし、そうではありません。地球は不規則です。実際には、それは 楕円体に似たジャガイモ 完全な楕円体よりも、GIS開発では、地球上のほぼすべてのポイントの詳細な高度データセットが必要です。に 測地学 、この準拠楕円体(別名データム)は、数学的に定義された表面であり、 ジオイド 、地球の「真実」の姿。
さらに、これらのデータでさえ、単なるデータであることを認識することが重要です。 近似 地球の表面の実際の形の。世界の特定の地域でうまく機能するものもあれば、他の地域でうまく機能するものもあります。例として、以下の画像( 私のRubyライブラリ )は、地球が最も一般的に使用されている楕円体モデルの1つ( WGS84の日付 )。黒の部分は上の地球の一部を表し、白は下の地球の一部、理想的な楕円体を表します(大陸と島の輪郭は赤で示されています)。
インドはWGS84楕円体の下にあり、南部は絶対最小値(ほぼ-100メートル!)であり、ヨーロッパはその上にあることがわかります。
低品質のGPSデバイスはそのようなデータを使用しないため、実際には完全な楕円体を想定して標高を計算しているだけです。したがって、それらの一貫した不正確さ。
GPSアプリの開発では、トラックを記録したデバイスにこれらのタイプのエラーがあることを検出するには、 地球重力モデルEGM2008データセット 、「ジオイドうねり」データセットとも呼ばれます。 EGM2008を使用すると、実際の地球表面と理想的な楕円体の差を概算できます。
EGM2008を使用すると、実際の地球表面と理想的な楕円体の差を概算できます。しかし、 私たちの GPSトラックにはこのエラーがあり、もう1つ必要なものがあります。 リアル 標高。この目的に役立つ可能性のある公開データベースは、 シャトルレーダートポグラフィーミッション(SRTM) 。 SRTMはラスターベースのデータベースであり、米国では約30m(赤道)ごと、その他の地域では90mごとの解像度で標高値を提供します。たとえば、上記のトラックのポイントのSRTM値を計算すると、別のグラフ(青い線)が表示されます。
ここでの小さな煩わしさはグラフの粗いエッジですが、これは簡単に滑らかになります。 SRTM自体は等距離の位置に離散点しか提供しないため、平滑化によって精度がほとんど失われないことに注意してください。これらの間では、どのような場合でも補間する必要があります。これは、平滑化されたSRTMデータを表す赤い線のオーバーレイが付いた前のグラフのバージョンです。
ちなみに、私のGPS Pythonライブラリを使用すると、これらすべてを簡単に行うことができます。
ために Rubyユーザー 、私もいます Geoelevations.rbパーサーライブラリ SRTMおよびEGM2008のうねり用。
これらの異常を検出すると、使用しているソフトウェアのタイプに応じて、(a)自分でエラーを自動修正するか、(b)標高データで不正確さが検出されたことをユーザーに通知することができます。
アジャイルスクラムとかんばんの違い
また、これらのGPS標高エラーをプログラムで修正するために使用できるさまざまなアルゴリズムがあるため、使用するアルゴリズムを選択するオプションをユーザーに提供したい場合があります(たとえば、ユーザーは平滑化されたSRTMデータのみを使用する必要がありますか? 「現状のまま」、またはユーザーはSRTMデータを使用して、デバイスによって報告された標高を修正することを望んでいますか)。
サッカー選手がGPSデバイスを着用してゲームを記録すると、結果のトラックは混乱します。競技場は、急カーブ、加速、減速がたくさんあるトラックで密集しているでしょう。
幸いなことに、人々がGPSを使用するほとんどの場合、これと同じパターンはありません。GPSのトラックライン(および加速度)は比較的スムーズになります。このような場合、トラック内の不規則なポイントはエラーによって引き起こされたと推定できるため、このような外れ値は平滑化機能を使用して合理的に除去できます。
GIS開発者として、スムージングは最も一般的にポイントを反復することによって達成され、 変化 隣接する座標の値に基づく座標。たとえば、次のようなアルゴリズムを使用して、すべての緯度と経度を変更できます。
points[n].latitude = points[n-1].latitude * 0.3 + points[n].latitude * .4 + points[n+1].latitude * .3 points[n].longitude = points[n-1].longitude * 0.3 + points[n].longitude * .4 + points[n+1].longitude * .3
係数が大きいほど、現在のポイントの変更された位置に対する対応する隣接ポイントの影響が大きくなります。この例で使用する係数(0.3、0.4、0.3)は多少任意ですが、ほとんどの場合、それらの合計を1.0に等しくする必要があります。 (たとえば、より洗練されたアプローチは、ポイント間の距離を使用し、ポイントが近いほど、対応する係数が大きくなることです。)
ランダムエラーが多いトラックの例を次に示します。
トラックがパスにうまく従わず、鋭くギザギザの曲がり角が多く、予想されるパスから完全に外れる場合があることに注意してください。
数回の「スムージング」の反復の後、この同じトラックは次のように変換されます。
それははるかに優れていますが、それでも確かに不完全です。トラックがまだ道路から外れている場所(特にパスの中央付近)がまだあることに注意してください。
あなたが試すことができる他のことがあります。特定の地域、および特定のGPSアプリケーションでは、 OpenStreetMap(OSM) データを使用して正しいパスを推測し、ポイントをこの新しい線に「スナップ」します。これは役立つことがよくありますが、OSMデータに2本の平行線(高速道路と近くの道路など)や多くの近いパスが含まれている場合など、不完全な場合もあります。
トラックがハイキングトラックであると推測でき、高速道路または近くの小道にスナップするオプションがある場合、ハイキングは高速道路ではなく小道に沿っていたと安全に推測できます。このような場合、考えられる解決策は、この記事でさらに説明するいくつかの手法を使用して、アクティビティのタイプを検出しようとすることです。たとえば、そのトラックがハイキングトラックであり、高速道路または近くの小道にスナップするオプションがあると推測できる場合、ハイキングは高速道路ではなく小道に沿っていたと安全に推測できます。
htmlcssとjavascriptを使用してモバイルアプリを構築する
また、この例は表面座標(つまり、経度/緯度)の平滑化を示していますが、平滑化は、標高や時間データ、さらには心拍数や自転車のケイデンスデータの収差を排除するための同様に有効な手法である可能性があることにも注意してください。
追加の利点と平滑化の使用例には、次のものがあります。
このアルゴリズムが不十分な問題の1つがあります。場合によっては、GPSは滑らかなパスを記録しますが、パスはある方向の一定の差によって「シフト」されます。このような場合、スムージングによってラインがさらにスムージングされる可能性がありますが、このシフトエラーは修正されません。
ここで説明した単純化された平滑化手法に関する、それほど明白ではありませんが重要な追加の問題は、変換によって、エラーではない可能性があるポイントも含めて、パス内のすべて(またはほぼすべて)のポイントが変更されることです。この単純なアプローチは、平均的なGPSユーザーにとって合理的な解決策になる傾向がありますが、GISプログラミングでは、より高度な平滑化アルゴリズムを使用できます。ユーザー、デバイス、およびアプリケーションによっては、平滑化を実行せずに、単に外れ値を削除する方がよい場合もあります。
ルート上のすべてのポイントの座標とタイムスタンプがあれば、トラックの最高速度の検出は非常に簡単です。ポイント間の速度を計算して、最高値を見つけるだけです。簡単そうです。
ただし、私たちはローエンドのGPSデバイスを扱っており、データを完全に信頼していないことを忘れないでください。これは、計算に重大な影響を与える可能性があります。デバイスが5メートルごとに位置を記録し、あるポイントでポイントを10メートルずれて間違えた場合、トラックのその部分は以前の3倍の速さで表示される可能性があります。
GIS開発の世界で一般的なアプローチの1つは、ポイント間のすべての速度を抽出し、削除された5%がエラーの大部分を表すことを期待して、上位5%を削除する(つまり、95パーセンタイルを使用する)ことです。しかし、これは明らかに非科学的であり、正しい結果を保証するものではありません。この手法を試したところ、パーセンタイルにさまざまな値を試してみたところ、あるGPSデバイスでうまく機能するものもあれば、他のデバイスでもうまく機能するものもありました。ハイキングに適したものもあれば、サイクリングに適したものもあります。しかし、ほとんどの場合、結果はそうではありませんでした 感じる 私に権利。
多くのアルゴリズムを試した後、何 した 私の仕事は簡単でした。次のように、速度だけでなく距離によっても極値を削除するために別のフィルターを追加しました。
私の経験から、このアルゴリズムは、ランダムエラーのある安価なGPSデバイスからのトラックでも、かなり信頼できる結果をもたらします。
多くの場合、アクティビティタイプを決定するには、平均速度で十分です。たとえば、平均速度が5kmhの場合は、ウォーキング/ハイキングトラックである可能性がありますが、平均速度が30kmhの場合は、サイクリングトラックである可能性があります。
ただし、平均速度が12 kmhの場合、ユーザーがマウンテンバイキングをしているのかランニングをしているのかはわかりません。そのような場合、 最大 速度は、2つのタイプのアクティビティを区別するのに役立つ場合があります。具体的には、ランナーが平均の2倍を超える速度に達することはめったにないのに対し、サイクリストは定期的に到達するという事実を利用できます(たとえば、それほど挑戦的ではない道を下り坂を進むとき)。
したがって、走行中は平均速度12kmh、最高速度18kmhのトラックが記録されたと考えられ、マウンテンバイクでは平均速度12kmh、最高速度30kmhのトラックが記録された可能性があります。 (もちろん、これが確実に機能するためには、計算された最大速度が正しいことを確認する必要があります。)
各GPS測定の精度(つまり、緯度、経度、標高)は、記録時に表示されていた衛星の数に大きく依存します。したがって、各記録の時点で「視界にある」衛星の数を何らかの方法で判断できれば、その記録の精度を概算する方法としてそれを使用できます。たとえば、必要なすべてのGPS衛星が表示されていることがわかっていれば、対応するGPSデータの精度は高いと見なすことができます。逆に、GPS衛星が表示されていないことがどういうわけかわかっていれば、データにエラーが発生しやすいと見なすことができます。
しかし、興奮しすぎる前に、そのようなGIS問題を解決しようとすることの複雑さを考慮してください。まず、デバイスがどのGPS衛星システムと通信できるかを知る必要があります。オリジナルのアメリカを拠点とする 全地球測位システム 、ヨーロッパ人 ガリレオ 、およびロシア語 GLONASS システム。一部のデバイスはこれらすべての衛星タイプで動作しますが、多くは動作しません。また、多くのデバイスは、使用しているシステムを報告していません。
しかし、この複雑さを回避し、視野にある衛星の数の大まかな概算を達成するための賢い方法があります。 可視衛星の数の代用として可視空のパーセンテージを使用する 。空が見えにくいということは、GPSがより少ない衛星で「見る」(または見る)ことができることを意味します。しかし、地球上の任意の点で見える空の割合をどのように計算できますか?解決策は実際には非常に単純です。前述のSRTMデータを使用して、周囲の地平線を計算できます。
たとえば、SRTMを使用して計算された、トリグラウ山(スロベニアの最高峰)の下の谷にいる場合、これは地平線です。
corp to corp vsw2計算機
(興味のある方は、この画像を作成するための私のコードを見つけることができます ここに 。)
この画像は基本的に、中心点から見た等距離の標高グラフのレイヤーで構成されています。青い領域が暗いほど、標高レイヤーは遠くなります。青い領域が明るいほど、標高レイヤーは近くなります。描かれた最も高い点は地平線を表しています。 GPS衛星が空のこの線より下にある場合、デバイスはおそらくGPS衛星から見ることができません(または見ることができません)。 (ただし、画像は平らな長方形として描画されますが、実際には、地平線の下の領域を適切に計算するには、球面幾何学の基本的な知識が必要になることに注意してください。)
この方法は、山のハイキングなど、深い峡谷(GPSの受信状態が悪い)から山の尾根(受信状態がはるかに良い)に移動する場合に役立ちます。これは、トラックのどの部分がエラーを起こしやすいかを示すのに役立ちます。覚えておくべきもう1つのことは、これはGPS高度エラーを検出するための特効薬ではないということです。まず第一に、地球のほとんどの部分は山岳地帯ではなく、山岳地帯であっても、標高を過大評価することは私たちの心理学にあります。 目に見える空の実際の割合は、居住地域の大部分で75%を超えています 。しかし、それでも、この方法は、深い峡谷(GPS受信が不十分)から山の尾根(衛星の受信がおそらくはるかに優れている)に行く山のハイキングなど、特定の状況で役立ちます。この方法は、トラックに含まれるエラーの数を絶対的に測定するものではありませんが、トラックのどの部分が他の部分よりもエラーが発生しやすいかを示すのに役立ちます。
ローエンドのGPSデバイスで予想されるより一般的なタイプのGPSトラッキングエラーのいくつかについて説明しました。それらの原因の理解と、それらを修正するためのGISプログラミング手法をいくつか提供しました。
場合によっては、自信を持ってトラックを修正できることもあります。それ以外の場合は、少なくとも、トラックの疑わしい部分についてユーザーに警告することができます。不明な場合は、航空写真と地図を利用して、ユーザーが自分でトラックを修正できるようにするオプションが常にあります。確率論的な推測は、エラーの可能性が高いことが検出されたトラックの部分を強調するのに役立ちます。
多くの場合、ここで概説した手法は、満足のいく「80%ソリューション」であり、ローエンドGPSデバイスのユーザーにGPSトラックの精度の合理的なレベルの自動改善を提供します。