上限に達する前にキーの使用状況を監視する
割り当てヘッダーを随時確認しておけば、リクエストが実際に拒否されるよりずっと前に、上限が近づいていることが分かります。
標高プロファイルとは、各地点に高さを付けた地点のリストを、ルートに沿った距離に対してプロットしたものにすぎません。標高のエンドポイントは、送った地点の数だけその高さを1回の呼び出しで返します。
pointsパラメーターで緯度と経度の組を連続して渡します。組と組はパイプで区切り、各組の中はカンマで区切ります。
GET /v1/elevation?points=45.8326,6.8652|45.8400,6.8700|45.8475,6.8750{
"status": "ok",
"results": [
{"lat": 45.8326, "lon": 6.8652, "elevation_m": 1035},
{"lat": 45.8400, "lon": 6.8700, "elevation_m": 1210},
{"lat": 45.8475, "lon": 6.8750, "elevation_m": 1390}
]
}results内の各項目は、送った地点と同じ位置に対応しています。elevation_mを、座標から自分で計算する連続した地点間の累積距離と組み合わせれば、追加の検索なしでプロファイルグラフのx値とy値がそろいます。
パイプ区切りのpointsパラメーターではなく構造化された配列を送りたい場合は、他のエンドポイントが一括ボディを受け付けるのと同じ方法で、座標オブジェクトのJSON配列を/v1/elevationにPOSTします。
POST /v1/elevation
Content-Type: application/json
[{"lat": 45.8326, "lon": 6.8652}, {"lat": 45.8400, "lon": 6.8700}]どちらの方法でも費用は同じで、1地点につき1リクエストです。そのため、配列から組み立てるクエリ文字列か、同じように組み立てるJSON配列か、手元にあるデータ構造から作りやすいほうを選んでください。
数メートルごとに100個のGPS地点があるルートでも、読みやすいプロファイルを描くためにそのすべての標高が必要なわけではありません。pointsパラメーター内の各地点は1リクエストとして数えられるため、長いルートでは20番目や50番目ごとの地点を抽出したり、等距離の間隔で再サンプリングしたりすれば、グラフをなめらかに保ちながらリクエスト数を減らせます。
elevation_mをセンチメートル単位まで正確だとみなすのは、標高プロファイルに必要な以上のものをデータに求めることになります。この値は、なめらかで読みやすいプロファイルを描き、妥当な累積標高を計算するには十分な精度がありますが、平地で1メートル離れた2地点がわずかに異なる値を返すことがあり、それは実際の地形について何も意味しません。グラフと累積標高の計算は、すべての変動をルートの実際の特徴として扱うのではなく、こうした小さなノイズを許容するように作ってください。
開けた水面上や標高データが少ない地域にある地点は、エラーではなく低い値や平坦な値を返すことがあります。ルートにフェリーでの横断や人里離れた地形の区間が含まれる場合は、その数値が常に陸地を表していると考えず、プロファイルの不自然に平坦な区間を地図そのものと照らし合わせて確認してください。
100地点のプロファイルは100リクエストで、すべてのキーに含まれる、またはキーなしで1つのアドレスから利用できる1日あたりの無料リクエスト2,500件の範囲に十分収まります。ただし、1日に多くのユーザーにサービスを提供するルート計画ツールでは、人気ルートの標高プロファイルは単発の検索より早く積み上がるため、割り当てのヘッダーを監視してください。
標高データは、平面の地図を、ハイカーやサイクリストが実際に計画を立てられるものに変えます。パラメーターの全一覧は標高検索のドキュメントのページに掲載しています。