チェックアウトの前に住所と記載された郵便番号が一致するか確認する
注文フォームの郵便番号と市区町村の不一致は、小さな入力ミスに見えますが、やがて国内のまったく別の地域に荷物が送られる事態につながります。
ライドシェアの乗車地点の範囲チェックを作る
キャンパスと周辺地域に関する協定のもとで運営されているある小規模なライドシェアサービスには、決して破れない厳格なルールが1つありました。乗車と降車は、そもそもサービスを承認した地元当局と合意した、定められた運行エリア内に収めなければならないというものです。ドライバーがその境界の外で降車させると、たとえわずかな距離であっても運行協定全体が危うくなり、ドライバーが紙の地図上の境界を目測で判断することに頼っていては、決して確実にはなりませんでした。
サービスは、住所ではなく座標を中心にチェックを作りました。乗客の乗車ピンは、入力されたテキストではなく、アプリ内の地図上に置かれた座標だったからです。その生の座標に対して、サービスは/v1/reverseを使って読みやすい住所とその行政区域を取得しました。これは、確定した乗車地点を乗客に表示するのに役立ち、フラグが付いた乗車を後からスタッフが確認する際にも役立ちました。座標だけでは人がすばやく妥当性を確認するのは難しいですが、解決された住所なら簡単だからです。
実際の境界チェックそのものは、乗客の座標と承認済み運行エリアを表すポリゴンとの単純な幾何学的な比較で、アプリ自身のバックエンドが実行しました。確認する座標さえあれば、この計算に外部サービスは必要ありません。位置情報のエンドポイントが役立ったのは、そのチェックに常に実際の座標があるようにすることでした。乗客がピンを置く代わりに住所を入力した場合は、アプリの乗客側に入力された内容を、まず/v1/forwardで座標に変換しました。
境界内の乗車リクエストは通常どおり処理されました。境界の外にあるリクエストは、たとえわずかでも、ドライバーを配車する前に断られ、承認済みエリアの外では法的に運行できないことを説明するメッセージが表示されました。ドライバーが到着してから乗車させられないとわかる事態を避けるためです。早めに断ることで、ドライバーと乗客の両方の時間を節約でき、サービスが違反を後から発見するだけでなく、自らの境界を積極的に守っていることを示す整った記録も残りました。
サービスは、フラグが付いた乗車や異議のある乗車にも逆ジオコーディングした住所を使いました。少数の乗車地点はちょうど境界の縁にあり、リクエストが実際に承認済みエリアの内側か外側かを人が確認する必要があったからです。これは、社内のダッシュボード上の生の座標の組よりも、解決された番地と地区名からのほうがはるかに判断しやすいものでした。
位置情報の要素がそろえば、この種の境界の管理は技術的に複雑な問題ではありません。難しかったのは、すべての乗車と降車が、アプリにどう入力されたとしても、必ずバックエンドの幾何学的チェックで実際に使える座標になるようにすることでした。それを担ったのが、データがどちらの方向から来たかに応じて連携して動く/v1/forwardと/v1/reverseでした。
利用量は乗車数に直接連動し、1回の乗車につき1〜2回の検索でした。1つの限られたエリアで運行するこの規模のサービスであれば、1日あたりの無料枠に収まる作業量でした。両エンドポイントのドキュメントは/docs/forward-geocoding/と/docs/reverse-geocoding/にあります。