チェックアウトの前に住所と記載された郵便番号が一致するか確認する
注文フォームの郵便番号と市区町村の不一致は、小さな入力ミスに見えますが、やがて国内のまったく別の地域に荷物が送られる事態につながります。
倉庫を中心に配送エリアを設定する
ある地域のスーパーマーケットチェーンが2つ目の倉庫を開設し、当日配送を約束する前に、ある単純な問いに答える必要がありました。新しい建物から妥当な運転時間で実際に届けられる顧客はどこで、引き続き元の拠点から配送したほうがよい顧客はどこか、という問いです。
最初はコンパスと道路距離の推測を頼りに手作業で境界線を引いてみましたが、その結果できた配送エリアは、見た目はもっともらしいものの、実際の成績は良くありませんでした。円の内側にある住所の中には、そこへ通じる唯一の道路を使うと40分かかるものがありました。逆に円のすぐ外側にある住所の中には、地図が示すよりも近いものがありました。
より良い方法は、住所を座標に変換するところから始まります。/v1/forwardを呼び出すと、住所を受け取って一致した結果を返し、その中には緯度と経度のフィールドが含まれます。ルーティングツールが推測しなければならない通りの名前ではなく、距離計算に必要な構造化された位置情報です。倉庫の住所は一度だけジオコーディングします。顧客リストにあるすべての注文住所も同じバッチでジオコーディングします。一括リクエストでは、呼び出しごとではなく住所1件ごとに1件の課金対象として数えられるからです。
両端に座標がそろえば、倉庫から各顧客までの直線距離は、このスーパーマーケット自身のシステムで実行できる単純な計算になります。配送エリアは手描きの円ではなくなり、実際に配送している場所から作られた境界になって、新しい顧客の住所が入るたびに自動的に更新されるようになりました。配送時間が遅れ気味になり、倉庫の実質的な配送範囲を縮める必要が生じたときも、境界は目分量で引き直すのではなく、同じデータから引き直せました。
逆方向も重要でした。カスタマーサービスには、配達アプリから座標だけが届き、整った住所がないことが時々あり、その地点がどの配送エリアとどの店舗に属するかを知る必要がありました。/v1/reverseは座標の組を受け取り、その場所の住所の構成要素を返します。地図上のピンを、倉庫のルーティング表で使える情報に戻してくれるのです。
このスーパーマーケットは、地図プラットフォームを自社で構築したりライセンスを取得したりする必要は一切ありませんでした。欠けていたのはジオコーディングの工程だけで、それは会社がすでに社内で運用していた物流ソフトウェアに組み込めました。新しい倉庫の開設時に数千件の住所をジオコーディングし直し、その後は毎日少しずつ新しい注文をジオコーディングしました。この規模の業務の多くが使う1日あたりの無料割り当てに十分収まり、注文量が増えればプリペイドクレジットに移行する余地もあります。
この教訓は食料品の配送以外にも当てはまります。倉庫、修理拠点、当日設置の作業チームなど、物理的な拠点の周りにサービス境界を引く事業には、同じ2つのものが必要です。住所を確実に座標へ変換する手段と、データが逆方向から届いたときに座標を確実に住所へ戻す手段です。どちらも同じキーで利用できます。
両方のエンドポイントのリクエストとレスポンスの形式は、/docs/forward-geocoding/と/docs/reverse-geocoding/で説明しています。