チェックアウトの前に住所と記載された郵便番号が一致するか確認する
注文フォームの郵便番号と市区町村の不一致は、小さな入力ミスに見えますが、やがて国内のまったく別の地域に荷物が送られる事態につながります。
サイクリングアプリの標高プロファイルを作る
ルートを計画するライダーが何よりも気にする数字は1つです。それは、どれだけ登りがあるかです。平坦な40マイルと起伏の多い40マイルはまったく別のライドであり、ルート計画用に作られたサイクリングアプリには、その違いを、坂を3つ越えたところで後悔してからではなく、ライドを始める前に示す方法が必要でした。
アプリには、独自のルーティングエンジンが出発点と到着点から生成した座標の並びとして、すでにルートがありました。欠けていたのは、それぞれの地点の標高です。/v1/elevation はこれを直接解決しました。単一の地点でもルートに沿った長い並びでも、座標のリストを送れば、それぞれの地表の標高が返ってきます。200地点からなるルートは、送信したときと同じ順序のまま200個の標高値として返され、そのまま走行距離に対するプロファイルとしてグラフに描けます。
このリストを累積距離に対してグラフにしたものこそ、ライダーが本当に見たい登りのグラフです。どこに坂があるのか、隣接する地点と比べて登りがどれだけ急に見えるのか、平坦な区間がどこにあるのかがわかります。アプリはこれを使ってルートの獲得標高の合計を計算しました。この1つの数字は、ルートに挑戦するかどうかを決めるライダーにとって、総距離よりも重要であることがわかりました。
ルートは長さによって数十から数百の地点を持ちうること、そして一括標高リクエストでは各地点が1件の課金対象として数えられることから、アプリはすべてのライドで可能な限り細かい解像度で標高をリクエストするのではなく、ルートごとにサンプリングする地点の数を調整しました。数百メートルごとにサンプリングした緩やかなルートでも、10メートルごとにサンプリングしたものと同じくらい役立つプロファイルが得られ、リクエスト量はほんの一部で済みました。完成したグラフを見るライダーには、その違いはまったくわかりませんでした。
アプリでは、ライダーが必要に応じて単一の地点を確認することもできました。地図上のどこかをタップすると、そのちょうどの地点の標高が表示されます。これには、ルート全体ではなく1地点のリクエストで同じエンドポイントを使いました。単一地点の場合も一括の場合も同じ呼び出しで処理されるため、アプリのコードはシンプルに保たれました。座標のリストを受け取り、対応する標高のリストを返す1つの関数を、ちょっとしたタップにもルート全体の計画にも使えたのです。
保存したルートのプロファイルは一度計算すれば済むため、トラフィックはライダーが実際に走った回数ではなく、計画したルートの数に比例して増えました。アクティブではあるものの巨大ではないユーザー層を持つアプリにとって、これにより標高の検索は1日あたりの無料割り当てに十分収まりました。人気の新機能によってルート計画が急増した場合には、プリペイドクレジットが自然な次のステップになります。
標高は、実例を示しやすい数少ないエンドポイントの1つです。海沿いのライドなら、序盤の地点では海抜に近い標高値が、ルートが内陸へ登るにつれて上昇していく値が表示されます。ライダーにとって一目で意味のわかるグラフです。リクエスト形式と地点数の上限の詳細は /docs/elevation-lookup/ にあります。