My Geocode

ガイド

GPXルートファイルに標高データを追加する

· 約3分で読めます · My Geocode · #elevation#gpx#routes#data-enrichment

スマートフォンや一般的なGPS機器で記録したGPXファイルでは、標高の値がまったくなかったり、明らかに不正確だったりすることがよくあります。一般向けのGPSの高度の値は、記録される緯度や経度よりもはるかに信頼性が低いのが普通だからです。

ポイントを抽出する

GPXファイルのトラックポイントを解析して、各ポイントの緯度と経度だけを取り出し、置き換える予定の既存の標高の値は破棄します。

<trkpt lat="45.8326" lon="6.8652"><ele>1050</ele></trkpt>

正しい標高を検索する

抽出した座標を/v1/elevationに送信します。小さなファイルであればpointsパラメーターで、大きなファイルであれば一括POSTの配列で送ります。

POST /v1/elevation
Content-Type: application/json

[{"lat": 45.8326, "lon": 6.8652}, {"lat": 45.8400, "lon": 6.8700}]
{
  "status": "ok",
  "results": [
    {"lat": 45.8326, "lon": 6.8652, "elevation_m": 1035},
    {"lat": 45.8400, "lon": 6.8700, "elevation_m": 1210}
  ]
}

2つ目の例：1つの登山口を確認する

すべての用途でトラック全体を処理する必要があるわけではありません。ハイキングコースの説明を公開する前に、1回の呼び出しで登山口そのものの標高を確認できます。

GET /v1/elevation?lat=45.8326&lon=6.8652

これは同じ形の結果を1件だけ返します。GPXファイル全体に手を付けなくても、コースのメモに書かれた出発地点や到着地点の標高の数値をスポットチェックするのに便利です。

値を書き戻す

結果は送信した座標と同じ順序で返ります。そのため、位置を対応させてelevation_mを各トラックポイントのeleタグに書き戻し、元の記録値を検索した値に置き換えます。

<trkpt lat="45.8326" lon="6.8652"><ele>1035</ele></trkpt>

避けるべきよくある間違い

1つのジョブの中でpointsクエリパラメーター形式と一括POSTの本文を混在させる場合は、結果をトラックポイントに対応させる方法を一貫させてください。pointsパラメーターとJSON配列はどちらも指定した順序で結果を返しますが、あるポイントの座標をクエリパラメーターで、残りを一括POSTで取得し、2つのレスポンスを明示的な座標の照合ではなく思い込みで結合すると、書き戻したファイルに1つずれのエラーが簡単に入り込みます。

補完するポイントの数を決める

GPXファイルには、短い間隔で記録された数千ものトラックポイントが含まれることがあります。そのすべてを補完すると1ポイントにつき1リクエストとなり、長いトラックでは件数が膨らみます。標高の検索前に粗い間隔にダウンサンプリングし、間のポイントは検索した値の間を補間する方法は、リクエスト数を減らしつつ正確に見えるプロファイルを作る妥当なやり方です。

エッジケース：沿岸部や低地のポイント

海岸線に沿って下りたり、低地のデルタを通ったりするトラックでは、elevation_mの値がゼロかそれに近い値、あるいは海面より低い土地では小さな負の値になることが正当にあります。どちらもエラーではありません。ゼロに近い値は、不正なデータポイントとして除外するのではなく、その地形にとってもっともらしい実際の値として扱ってください。

コスト

補完するポイント1つにつき1リクエストです。はるかに大きな元の記録からダウンサンプリングした、数百ポイント程度の一般的なハイキングトラックであれば、すべてのキーに含まれる1日あたりの無料リクエスト2,500件の範囲内に十分収まります。

このように標高データを整えると、スマートフォンで記録した不安定なトラックが、共有や分析に値するものになります。標高検索のドキュメントでは、pointsパラメーターと一括リクエストの形式の両方を説明しています。

ガイドのその他の記事

· 4分で読めます

住所と郵便番号を照合する

住所と郵便番号をそれぞれ個別に解決して実際に示す内容を比較することで、注文の発送前に番地と郵便番号の不一致を見つけます。