今月のリリース:ジオコーディング、IP、タイムゾーンなど
APIの最近の取り組みのまとめです:新しい互換ホスト、より高速なタイムゾーンと標高の検索、ダッシュボードの機能、割り当ての見やすさの向上。
長いルート向けに高速化した標高エンドポイント
ハイキングコースや車のルートの標高プロファイルが、1つの座標だけで済むことはほとんどありません。経路に沿った数十、ときには数百の地点があり、それぞれについて、登りのグラフを描いたり途中の負荷を見積もったりするための標高の値が必要です。1つの連続したルートのために多数の座標を扱うというこの使い方こそ、最近/v1/elevationを見直した際に特に最適化した点です。
エンドポイントのリクエストとレスポンスの形式は変わっておらず、/docs/elevation-lookup/に記載されている内容はすべて、書かれているとおりにそのまま当てはまります。変わったのは、ルートに沿った大量の座標のバッチを内部でどれだけ効率的に処理するかという点で、単独の地点ではなく長い経路の標高プロファイルが返ってくるまでの時間を短縮することを目的としています。
バッチリクエストでは、これまでどおり各座標を1項目としてカウントするため、この改善が影響するのは速度であり、料金や割り当ての挙動ではありません。200の座標点を持つルートは、適用される割り当てが1日あたりの無料割り当て、1リクエストあたり€0.0001のプリペイドクレジット、Unlimitedパッケージの対象のいずれであっても、引き続き200件のリクエストとしてカウントされます。変わるのはレスポンスが返ってくるまでの時間であり、これはバックグラウンドのジョブではなく対話的にルートのプロファイルを作成するものにとって直接重要です。
同じ改善は、/compatibility/open-elevation/にあるOpen-Elevation互換ホストにも反映されます。同じ標高エンドポイントを基盤としているからです。すでにこのホストを通じてルート規模のバッチを送信しているものは、連携側で何も変更することなく、高速化された処理の恩恵を受けられます。
この種の改善が最も直接的に実感されるのは、ルート検索やハイキングのアプリケーションです。ルート自体よりも標高プロファイルの読み込みに明らかに時間がかかると、地図を見て待っているユーザーには目に見える遅れが生じます。長いルート形式のバッチに対するレスポンスが速くなることで、その差が解消されます。
ハイキング、サイクリング、車の経路案内などで、多数の座標からなるルートの標高をアプリケーションでリクエストしている場合は、プロファイル全体が返ってくるまでの速さがさりげなく改善されていることに気づくはずです。連携のそれ以外の部分は何も変更する必要がありません。エンドポイントの完全なドキュメントは引き続き/docs/elevation-lookup/にあります。