GPSトラックの標高プロファイルを取得する方法は？

GPSで記録されたトラックの合理的に正確な標高プロファイルを取得したい（モデルによっては非常に信頼性の低い標高データがあり、場合によってはまったくありません）。

これを行う最も簡単な方法についてのヒントはありますか？私がこれまで検討している2つの手法は次のとおりです。

• Google Elevation APIを使用する

  このAPIは比較的簡単に使用できますが、それでも使用制限のために簡単ではないいくつかの手順が必要です：リクエストごとに返される最大512サンプル、およびパスに沿ったポイントの数も（URLの長さによって）制限されます。

  私は期待gpsbabel簡素化フィルタは、点の適切な数（それらは高度データの解像度による一緒に近いよりも100メートル程度であるでない点）にトラックを減らすために調合することができるが、マッピングする方法の、問題が残っています長さが異なるため、この単純化されたトラックは元のパスに戻ります。

  または、これが自動化に適していない場合、最良のアプローチは、ユーザーがマップ上のトランセクトポイントを手動で選択できるようにすることです。

• Shuttle Radar Topography Mission（SRTM）データをダウンロードし、ローカルでクエリを実行します。

  これは私が経験したことのないものですので、これがどの程度実現可能かについての提案は大歓迎です。データセットの大きさは？どのGISソフトウェアが必要ですか？適切な方法でスクリプト化できますか？苦痛のように聞こえるサンプリングおよび補間アルゴリズムを記述する必要はありません。そのようなアプローチのパフォーマンスはどの程度でしょうか？（私はそれが非常に速く、メモリが制限されたVPS Webサーバーで実行する必要があります...）

http://srtm.csi.cgiar.org/SELECTION/inputCoord.aspからデータを再度ダウンロードする@MerseyVikingの回答を具体化するための詳細：

72 x 24のタイルがあり、各タイルは72.1mb 16ビットTIFファイル（6001x6001ピクセル）に解凍される20mb zipファイルです。

これは最大120 GBであり、保存できる量を超えています。圧縮したままにして、海を無視すると、10GBになりますが、これはまだ少し大きすぎます。データをオンデマンドでロードすると、必要なストレージスペースが劇的に削減されますが、ソースサイトは低速で（10 kb / sしか取得できませんでした）、非常に実用的ではありません。

ローカルソリューションの場合、GRASSをスクリプト化してこれを行うことができます。

# extract raster values at our points
# use cubic convolution for interpolation between DEM locations
v.drape in=my_pts out=pts_srtm_elev type=point rast=srtm_dem method=cubic

私は自分のユースケースの1つでこの拡張バージョンを実行しましたが、v.drapeのパフォーマンスはまったく問題ありませんでした。

gpsvisualizer.comがこれを行います。バックグラウンドでGPSBabelとGoogle APIを使用していると思います。

これは一般的なソリューションとして必要なようです。つまり、処理したいすべてのトラックで世界中のすべての標高データを使用できるため、すべてのCGIARデータをローカルに保存する必要はありません。上記のgpsvisualizer.com（@Llaves）が最善の策かもしれません。

高解像度を必要としない場合、GTOPOデータセット（1kmグリッド）は惑星全体でわずか300MBです。それ以外の場合、ASTER GDEM（30m）および元のSRTM（90m）データセットは利用可能ですが、指摘するように、大量のデータがあります。（ASTERデータのサイズは、実際の標高データよりも大きいことが多いバンドルされたPDFを削除することにより、ダウンロード後に縮小できます-これを行うと、アフリカデータセットが40％削減されました！）

Rでは、これらのデータセットのいずれかから標高プロファイルをかなり迅速に抽出できますが、ラスタの読み込みには大部分の時間がかかる場合があります。これは、小さなカスタムreadGPX関数とgpsbabelを使用してGPXデータを処理します。

#Load elevation model and process track:
dem <- raster("E020N40.DEM")
track <- readGPXt("trackfile.gpx")
coordinates(track) <- ~Longitude+Latitude
proj4string(track) <- "+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs"
#Overlay (extract) the elevation data for the track points:
track$profile <- extract(dem, track)
track <- as.data.frame(track)

「トラック」は現在、緯度/経度、他の標準GPXデータ（速度、GPS高度など）、およびそのポイントの高度を示す「プロファイル」列を含むGPSポイントの表です。

SRTMデータは特定のエリアで簡単にダウンロードできます。過去にこのサイトを使用しました。ファイルは巨大ではなく、ジオリファレンスされたTIFFとして取得できます。全世界のダウンロードには時間がかかる場合がありますが、いくつかのタイルがかなり広い領域をカバーしています。あなたが持っているかもしれない問題は、ほとんどの世界で約90メートルである水平解像度にあります。また、垂直方向の誤差は、スパイクや欠落データのある領域で非常に大きくなる可能性があります。

ASTER GDEMデータセットは、水平解像度約30mの最新の高解像度調査ですが、多くの場合、品質は対応するSRTMデータよりも低くなっています。

Googleの標高データの解像度はわかりませんが、SRTMに基づいていれば驚かないでしょう。したがって、Google APIを使用すると、ローカルプロセスを使用した場合と同様の結果が得られます。

@underdarkの回答に続いて、これが単純なWebベースのシステムである場合、GRASS GISがおそらく道です。私はr.profileを使用して単純な相互可視性プロットを実行しましたが、いくつかの成功を収めましたが、どの補間方法を使用するのかわかりません。おそらく最も近い隣人かもしれません。編集：を見てソースコードを、r.profileあなたには、いくつかの階段状のアーティファクトを取得する可能性がありますので、隣最寄りの使用を行います。

別のオプションとしては、GDALとNumPyを使用してPythonスクリプトを作成することもできますが、これはもう少し手間がかかるかもしれませんが、素晴らしいカスタムソリューションになります。

まず、満足できる水平/垂直精度の種類を指定する必要があります。

しかし、実用的な観点からこれを見てみましょう。

• 各SRTM3タイルには1200x1200のセルがあり、各セルは標高をメートル単位で表す2バイトの整数値です。これは約2.75 MBの未圧縮の未加工データです。
• 14042 SRTM3タイルがあります。それはccaです。38 GBの未加工データ。
• あなたは本当に全世界をカバーする必要がありますか？サハラ砂漠、ゴビ砂漠、またはシベリアの真ん中にGPSトラックの標高プロファイルを表示することにあまり関心がないので、現金で縛られている場合、それをカバーすることは経済的に実行不可能です（BTW：SRTM3はカバーしていません）全世界なので、グリーンランドや南極大陸のような場所を心配する必要はありません;））。
• 巧妙な圧縮とデータエンコーディングを使用すると、データセットのサイズを大幅に削減できます。標高値は0〜8848であるため、残りの2ビットは使用されません。デルタ圧縮を使用して標高をエンコードし、さらに削減することもできます。また、垂直精度の一部を放棄することもできます（たとえば、2mにすると、セルごとに1ビット余分に節約できます）。
• これを使用するGPSトラックの種類（ウォーキング、サイクリング、運転など）に応じて、データをディスク上のファイルまたはデータベーステーブルの行として小さなタイル（0.25x0.25度など）に保存する必要があります。
• 頻繁に使用されるタイルをリロードする必要がないように、タイルに賢いメモリキャッシュを使用します。
• セルからの標高の計算は、このビジネス全体の簡単な部分です。