チェックアウトの前に住所と記載された郵便番号が一致するか確認する
注文フォームの郵便番号と市区町村の不一致は、小さな入力ミスに見えますが、やがて国内のまったく別の地域に荷物が送られる事態につながります。
ランニングアプリのルート標高グラフを作る
ルートを計画するランナーは、平面の地図だけでは判断しにくい形で坂を気にします。同じ距離の2つのルートでも、どれだけの登りが詰め込まれているかによって、走った感覚はまったく異なるからです。あるランニングアプリの機能要望ボードでは、1つの項目が何か月も上位にありました。実際に走ると決める前に、計画したルートの標高プロファイルを表示してほしいというものです。
アプリのルート作成機能は、スタート地点、ゴール地点、そして実際の道路やトレイルに沿ったアプリ独自の経路探索ロジックから、計画したランを表す座標の列をすでに生成していました。欠けていたのは、その経路上の各地点の標高データでした。/v1/elevationがその穴を直接埋めました。1回のリクエストで送った座標のリストが、同じ順序で対応する標高値のリストとして返ってくるため、ルートに沿ったランナーの累積距離に対してそのままプロットできます。
こうしてできた、距離に対する標高のグラフは、機能要望が求めていたものをまさにランナーに提供しました。計画したランのどこに登りがあるか、それぞれの登りがルートの他の部分と比べてどれほど急に見えるかがはっきりわかり、累積標高の数値は、距離や推定ペースと並んで、アプリに保存されたすべてのルートに表示される主要な数値の1つになりました。
ここでは、サイクリングアプリが同じ問題に取り組む場合と同様に、サンプリングの密度が費用管理にとって重要でした。近所を走る短いランでは、なめらかで正確に見えるグラフにするために標高をかなり頻繁にサンプリングする必要がありましたが、長いルートでは、グラフをちらりと見るランナーにとって目に見える違いが出ない範囲で、より粗いサンプリング間隔を使えました。一括の標高リクエストでは各地点が1件の課金対象として数えられるため、アプリのエンジニアリングチームは、グラフの視覚的な解像度に実際に必要な数をはるかに超える地点をリクエストしないよう、ルートの長さに応じてサンプリング間隔を調整しました。
アプリは同じデータを使って、もう1つ小さな機能を追加しました。保存したルートに付く「登りの難易度」バッジです。距離に対する累積標高から計算され、似た長さの2つのルートを、それぞれの完全なグラフを読まずにすばやく比較できるようにしました。考え方としては、ハイキングアプリが同じ計算をコースの難易度に使うのと似ていますが、ハイキングではなく一般的なランの短い距離と異なるペースの想定に合わせて調整されています。
機能の公開後、保存したルートへのユーザーの関与が高まりました。アプリのチームはその理由として特に、初めて走る途中でルートの難しさに気づくのではなく、登りの面で何に挑むのかを事前に確認できるようになったことで、ランナーがなじみのないルートにも自信を持って挑戦できるようになった点を挙げています。
ルートの標高プロファイルは何度走っても変わらないため、標高検索はランごとではなく保存したルートごとに1回だけ実行されました。これにより、リクエストの総量はアプリ全体の利用量ではなく、ユーザーが作成した個別のルートの数に比例し、アクティブユーザーが中規模のアプリであれば1日あたりの無料枠に余裕で収まりました。
リクエストあたりの地点数の上限を含むエンドポイントのドキュメントは/docs/elevation-lookup/にあります。